从 AI First 到 Harness 工程
核心观点
Agent 效能 = 模型质量 × Harness 质量
AI First 解决了"用不用 AI"的问题，Harness 工程解决了"AI 用得好不好"的问题。
模型决定上限，Harness 决定下限。
分享结构
开场：一个问题引入（5 分钟）
核心问题：你的团队已经 AI First 了，为什么产出质量还是不稳定？
- AI First 的承诺 vs 现实落差
- 模型演示时很强，进入真实仓库、真实权限和真实交付链后就不稳定
- 引出核心公式：Agent 效能 = 模型质量 × Harness 质量
课堂互动：让听众先回答"为什么不稳定"，通常会出现三类直觉：
- 模型还不够强
- Prompt 写得不够好
- 数据和上下文不够多
然后引出判断：更常见的短板是 Harness 没有设计完整。
第一部分：AI First 为什么不够（10 分钟）
1. 模型能力天花板已到
- GPT-4、Claude 4 系列已经很强，但"裸用"模型的收益在递减
- 模型再强，如果工具层、状态层或恢复层接近 0，系统整体效果仍然接近 0
2. 三个常见失败模式
| 失败模式 | 表现 | 根因 |
|---|---|---|
| 只换模型不换流程 | 升级了最新模型，工作方式没变 | 没有 Harness 意识 |
| Prompt 即全部 | 把所有期望塞进一条 prompt | 缺少工具、状态、验证层 |
| 无验证就交付 | AI 写完直接合并 | 没有质量门禁和恢复路径 |
3. 竞争焦点已转移
- 从"模型能不能写" → "谁来编排和调度"
- 模型经常可替换，Harness 更容易沉淀为组织资产
第二部分：什么是 Harness 工程（15 分钟）
核心定义
Harness = 模型之外、让 Agent 可靠工作的一切工程机制
不是"模型外面的一层壳"，而是 Agent 的操作系统。
1. Harness 能力栈（六层）
| 子系统 | 解决什么问题 | 典型实现 |
|---|---|---|
| Prompt 编排 | 模型当前该按什么角色、目标和约束工作 | system prompt、task contract、instruction files |
| 工具路由 | 模型怎样接入外部能力 | function calling、MCP、API gateway |
| 记忆管理 | 哪些上下文要保留，哪些要淘汰 | 会话上下文、长期记忆、压缩摘要 |
| 状态机 | 当前任务进行到哪里，下一步该走哪条边 | task state、event log、workflow engine |
| 运行时/沙箱 | 代码、浏览器、文件系统在哪执行 | sandbox、container、browser runtime |
| 护栏与恢复 | 出错、越界、注入或结果异常时怎么办 | schema validation、approvals、retry、rollback |
关键：不是"多加几个工具"，而是把工具、记忆、状态和恢复连成一套闭环。
2. Workflow vs Agent 的区分
- Workflow：由预定义代码路径编排，步骤和分支更可预测
- Agent：由模型动态决定下一步动作，自主性更高
判断顺序：
- 先问能不能用固定 workflow 解决
- 只有当任务分支多、信息不完整时，再引入更高自治的 agent
- 即使引入 agent，也要保留 harness 对执行边界和恢复路径的控制
Harness 的第一职责不是"放大自由度"，而是"在必要自由度之外收紧不确定性"。
3. 工程重心转移
| 时代 | 主要关注点 | 工程重心 |
|---|---|---|
| 传统应用开发 | 业务逻辑、接口、页面 | 模块设计、接口契约、测试 |
| Copilot 辅助开发 | 生成速度、提示词、局部补全 | prompt、上下文、人工 review |
| Agent 系统开发 | 计划、工具、状态、执行、恢复 | harness、workflow、guardrails、evals |
从"写功能" → "组织模型的工作"。软件工程从功能编码上移到了执行回路设计。
第三部分：如何落地（15 分钟）
六步实施清单
| # | 维度 | 你要设计什么 |
|---|---|---|
| 1 | Task contract | 输入、目标、边界、完成条件是否明确 |
| 2 | Tool schema | 工具描述、参数约束、权限范围是否清晰 |
| 3 | State model | 阶段、重试、等待、人工接管等状态是否显式 |
| 4 | Verification | 有哪些命令、断言、截图、日志可以证明任务完成 |
| 5 | Recovery path | 失败后是重试、降级、回滚还是人工接管 |
| 6 | Observability | 能否追踪提示词、工具调用、中间结果和最终证据 |
如果这 6 件事没有设计清楚，系统大概率还停留在"有一点 agent 味道的 demo"。
配套工程实践
上下文分层：
- Rules file → 长期硬约束
- Spec/Contract → 当前任务边界
- Working Memory → 当前会话状态
- Long-term Memory → 习惯和偏好
执行模式选择：
- Chat 模式 → 讨论、规划、问答
- 本地 Agent → 高交互任务
- 后台 Agent → 明确范围、可验证的任务
- 云端异步 Agent → Issue/Jira/PR 驱动的任务
质量门禁最小栈：
- lint → test → build/type check → 高风险 目录审批 → PR 证据字段
教学案例：自动化研报助手
需求：分析最近三个月某行业的技术趋势，输出 5 页摘要。
- Model 能做的：理解行业、给出提纲、产出总结
- Harness 要承担的：
- 标准化任务参数
- 调用搜索和知识库工具
- 材料去重、切片、时间过滤
- 保存中间结果，避免上下文丢失
- 检查输出是否覆盖关键维度
- 缺项时触发补检索或人工接管
- 工具失败时切换备用路径
关键：不是"模型会不会写摘要"，而是"系统能不能把摘要生产做成可重复、可校验的流水线"。
第四部分：常见误区与团队采纳（5 分钟）
四个误区
- 把 Agent 理解成"会调用工具的聊天框" — 没有状态管理和恢复，工具越多失败面越大
- 把 Memory 当作唯一真相源 — 旧记忆比没有记忆更危险
- 以为模型升级等于系统升级 — 模型升级不会自动补齐权限、重试、回滚能力
- 把高风险任务直接交给高自治 Agent — 正确做法是把审批、验证和观测前置进 harness
团队采纳路径
- 不同角色（产品/前端/后端/QA/DevOps）的切入点不同
- 从一个工作流开始：推荐 Spec-First 或 Bugfix 工作流作为第一步
- 渐进式引入：先契约化 → 再自动化 → 最后多 Agent 协作
收尾（5 分钟）
三句话总结
- 一句话：Agent 不是"更强一点的模型"，而是"模型能力 × 工程系统"
- 一个判断：未来 AI 工程的核心竞争力，不是"会不会用模型"，而是"能不能把模型组织成可靠系统"
- 一条行动建议：与其只卷提示词技巧，不如把时间投入到 workflow 编排、工具协议、验证恢复和评估链路
行动号召
回去给你的下一个任务写一份 Task Contract，这就是 Harness 工程的第一步。
讨论题（可选，用于互动环节）
- 你所在团队目前遇到的 Agent 问题，更像是模型问题，还是 harness 问题？
- 哪些任务其实更适合固定 workflow，而不是高自治 agent？
- 你们现在是否已经有显式的状态机、验证命令和失败恢复路径？
- 如果明天要把一个异步 agent 接进真实研发流程，最先该补哪 3 个基础设施？
- 在你们的业务场景里，什么样的任务必须保留人工审批或人工接管？
参考素材
- Agent = Model + Harness — 核心概念文章
- 2026 年 3 月 AI Coding 四个主线变化 — 趋势背景
- 上下文、记忆与规则 — 分层策略
- 异步 Agent 交付链 — 交付流程
- 质量门禁与 Review — 验证体系
- Agent 执行模式 — 模式选择