本文是对 B 站课程《最近爆火的 Harness Engineering 到底是啥？一期讲透！》的学习整理，并结合 OpenAI、Anthropic 的官方工程实践进行了补充。不是逐字稿，而是一篇面向开发者与 AI 产品经理的工程化教程。

一、为什么“模型更强了”，Agent 还是经常把事情做砸？

很多团队搭建 AI Agent 时，会把主要精力放在模型和提示词上：换更强的模型、写更长的 Prompt、塞入更多上下文。但一旦任务从“一问一答”升级为需要连续执行几十步的真实工作，问题很快就会暴露：

• 上下文变长后忘记最初目标；
• 工具调用失败后不断重复；
• 修改了代码，却不知道如何启动、测试和验证；
• 当前会话结束，下一个会话不知道前面做过什么；
• 输出看起来合理，却没有可审计的证据；
• 一个误操作就可能越权访问数据或影响生产环境。

这说明 Agent 的能力不只取决于模型。真正决定其能否稳定交付的，是模型外部那套负责提供环境、工具、约束、记忆和反馈的工程系统——也就是 Harness（执行支架/运行框架）。

可以把 Agent 系统简化成下面这个公式：

Agent 实际能力 ≈ 模型能力 × 上下文质量 × 工具可用性 × 反馈闭环 × 安全约束

其中任何一项接近零，最终交付能力都会大幅下降。

二、三次工程重心迁移：Prompt → Context → Harness

1. Prompt Engineering：教模型“怎么回答”

Prompt Engineering 关注角色、目标、格式、示例和推理要求。它适合边界清晰、单轮或短流程任务，例如摘要、分类、文案生成。

它解决的是“模型是否理解我的指令”，但无法单独解决长期记忆、工具可靠性、权限控制与结果验证。

2. Context Engineering：让模型“拿到正确的信息”

Context Engineering 不只是把资料全部塞进上下文，而是动态选择当前步骤最需要的信息，包括：

• 用户目标与验收标准；
• 代码、文档、数据库结构；
• 历史决策和当前进度；
• 可用工具及调用规范；
• 失败记录和环境状态。

关键不是“上下文越多越好”，而是让上下文保持相关、可发现、可压缩、可更新。

3. Harness Engineering：让 Agent“持续完成工作”

Harness Engineering 进一步关注：如何把模型放进一个可执行、可观察、可纠错、可治理的环境，让它跨多个步骤甚至多个会话稳定推进任务。

阶段	核心问题	典型产物
Prompt Engineering	该怎么向模型表达任务？	系统提示词、模板、Few-shot 示例
Context Engineering	当前步骤该给模型什么信息？	检索、记忆、压缩、上下文路由
Harness Engineering	怎样让 Agent 可靠完成并交付？	工具、沙箱、状态、测试、观测、审批与恢复机制

三者不是互相替代，而是层层叠加：Prompt 是指令层，Context 是信息层，Harness 是运行与治理层。

三、一个完整 Harness 应该包含什么？

1. 清晰的目标与验收标准

“帮我优化系统”不是可执行任务。更好的任务描述应包含范围、约束和成功标准，例如：

goal: 将搜索接口的 P95 延迟降到 800ms 以内
scope:
  - search-service
  - query-cache
constraints:
  - 不改变现有 API 协议
  - 不读取生产用户数据
acceptance:
  - 单元测试全部通过
  - 压测 10 分钟无错误率回升
  - 输出变更说明与回滚方案

验收标准越可机器验证，Agent 越容易闭环。

2. Agent 可读的知识系统

OpenAI 的实践强调“给地图，而不是一本一千页的说明书”。一个短小的入口文件负责导航，更详细的架构、产品、可靠性和安全规则分层放在仓库内，并通过版本管理保持一致。

参考目录：

project/
├── AGENTS.md                 # 入口地图：如何在仓库中工作
├── ARCHITECTURE.md           # 系统边界与依赖方向
├── docs/
│   ├── product/              # 产品目标和验收标准
│   ├── decisions/            # 架构决策记录 ADR
│   ├── plans/active/         # 正在执行的计划
│   ├── plans/completed/      # 已完成计划
│   ├── reliability/          # SLO、故障处理和降级策略
│   └── security/             # 权限、数据与合规要求
└── scripts/
    ├── check.sh              # 统一验证入口
    └── bootstrap.sh          # 可重复的环境初始化

关键原则是：知识必须能被 Agent 找到、验证并随代码一起更新。只存在聊天记录或某个人脑中的规则，对 Agent 来说等于不存在。

3. 标准化工具与可重复环境

Agent 不应依赖人工复制日志或手工操作页面。Harness 应提供稳定、语义明确的工具，例如：

• 文件搜索、代码修改与静态分析；
• 数据库只读查询；
• 浏览器页面检查与截图；
• 独立工作区或容器；
• 一键启动、测试、构建和回滚；
• 日志、指标、链路追踪查询。

工具设计要避免“万能接口”。接口越窄、参数越明确、返回结果越结构化，越容易控制风险与调试失败。

4. 可持续的状态与交接

Anthropic 在长任务 Harness 中指出，复杂任务会跨越多个上下文窗口。新会话如果不知道旧会话完成了什么，就像换班工程师没有交接记录。

因此应把关键状态写入外部、可恢复的载体：

## 当前目标
- 完成订单查询性能优化

## 已完成
- 定位到 N+1 查询
- 新增复现测试，当前稳定失败

## 下一步
- 修改 repository 层批量查询
- 运行性能基准

## 风险
- 需要确认旧版 MySQL 的兼容性

不要把“记忆”完全寄托在对话历史中。计划、进度、决策和失败原因应当可持久化，并能被下一次运行快速读取。

5. 测试、观测与反馈闭环

Agent 必须能够回答三个问题：

1. 我刚才做了什么？
2. 结果是否满足验收标准？
3. 如果失败，下一步依据什么修正？

可用的反馈信号包括单元测试、集成测试、UI 截图、结构化日志、P95 延迟、错误率、Token 消耗和人工评审意见。没有反馈闭环的 Agent 只是“自动生成器”，有反馈闭环后才接近“自动执行者”。

6. 权限边界、人工确认与失败降级

生产级 Harness 不能只追求自动化，还要控制 Agent 失败时的影响半径。

风险	Harness 机制
越权读取敏感数据	最小权限、字段脱敏、只读凭证、审计日志
错误修改生产系统	沙箱执行、环境隔离、发布审批、灰度开关
重复调用造成成本失控	调用预算、重试上限、熔断与超时
高风险决策自动执行	在付款、删除、发版等节点强制人工确认
模型或工具不可用	备用模型、规则引擎、只读模式、转人工

核心思想不是要求模型永不犯错，而是让错误可发现、可限制、可恢复。

四、OpenAI 与 Anthropic 的实践带来了什么启示？

OpenAI：让仓库和应用对 Agent“可读”

OpenAI 公布的 Agent-first 实践中，一个小团队让 Codex 生成应用逻辑、测试、CI、文档与内部工具。真正的工作重心逐渐从手写代码转向：

• 设计 Agent 能理解的仓库结构；
• 把架构规则转为 Lint 和结构测试；
• 让每个工作区都能独立启动应用；
• 将 UI、日志、指标和追踪暴露给 Agent；
• 把人的评审意见沉淀为文档或自动化规则；
• 用持续清理机制控制文档与代码熵增。

这说明高质量 Harness 不是套一层 SDK，而是重塑整个软件交付环境。

Anthropic：用可恢复交接支撑长时间任务

Anthropic 的长时运行 Agent 实践则强调初始化、增量推进和会话交接。与其让 Agent 一次完成巨大任务，更可行的方法是：

• 第一次运行先搭建环境、生成任务清单与基线；
• 后续每次只完成一个可验证的小目标；
• 每轮结束前运行测试、记录进度、提交清晰状态；
• 下一轮从结构化状态恢复，而不是从头猜测。

两家的共识很清楚：模型负责推理和决策，Harness 负责让工作过程具备连续性、可验证性和边界。

五、从零搭建一个最小可用 Harness

不需要一开始就建设庞大平台，可以从一个四阶段闭环开始。

第 1 阶段：把成功标准机器化

• 为任务定义输入、输出和禁止事项；
• 提供统一的 check 命令；
• 要求 Agent 在结束前展示验证证据。

第 2 阶段：把知识仓库化

• 建立短小的导航文件；
• 补齐架构、产品、可靠性和安全文档；
• 用 CI 检查失效链接、过期文档和依赖违规。

第 3 阶段：把环境工具化

• 每个任务使用独立工作区；
• 将启动、测试、日志和回滚封装为稳定命令；
• 为外部系统提供最小权限工具。

第 4 阶段：把反馈产品化

• 记录成功率、人工接管率、P95 完成时间；
• 跟踪每个成功任务的 Token 与工具成本；
• 将重复失败转成测试、规则、文档或新工具；
• 高风险动作增加审批，低风险动作逐步自动化。

六、AI 产品经理应该关注哪些指标？

Harness Engineering 也是产品问题。AI 产品经理不应只比较模型榜单，而应建立端到端指标：

指标	说明
任务成功率	最终是否通过真实业务验收，而非“生成了答案”
首次通过率	不需要返工便完成的任务比例
人工接管率	哪些环节仍频繁需要人介入
平均修复轮次	从第一次失败到成功需要多少轮
P50/P95 完成时间	关注长尾任务是否失控
单次成功成本	总模型与工具成本 ÷ 成功任务数
越权/高风险拦截率	安全机制是否真正生效
可追溯率	输出能否还原输入、工具调用、证据与审批记录

好的产品目标不是“让 Agent 调用更多工具”，而是让它在可接受的成本和风险下，稳定完成更多真实任务。

七、常见误区

误区 1：换一个更强模型就够了

模型升级可能提高单步能力，但不自动提供权限、状态、工具、测试和恢复机制。评估模型时应固定或明确 Harness，否则比较结果可能反映的是运行框架差异，而非模型差异。

误区 2：把所有规则写进一个超长提示词

说明越长，不代表执行越稳。应将稳定规则变为代码约束，将详细知识分层存储，让 Agent 按需检索。

误区 3：只看 Demo，不看失败路径

Demo 展示正常流程，生产环境却充满超时、脏数据、权限不足和依赖故障。Harness 必须优先设计失败后的行为。

误区 4：自动化程度越高越好

真正的目标是风险调整后的业务价值。删除数据、付款、发布等高风险环节保留人工确认，往往比追求“全自动”更专业。

八、总结

Prompt Engineering 让模型听懂，Context Engineering 让模型知道，Harness Engineering 让 Agent 做完并交付。

当模型越来越强，团队的竞争力会逐渐从“会不会写 Prompt”转向：是否能把知识、工具、环境、反馈、权限和成本治理设计成一个可靠系统。未来优秀的 AI 工程师与 AI 产品经理，核心能力之一就是为智能体设计这套可持续工作的支架。

如果你准备在企业中落地 Agent，可以先问自己五个问题：

1. Agent 的成功标准能否自动验证？
2. 它能否访问完成任务所需的信息与工具？
3. 跨会话后能否恢复目标、进度和决策？
4. 失败是否可观测、可降级、可回滚？
5. 权限、人工确认和成本预算是否明确？

这五个问题都有答案时，你搭建的才不只是一个聊天机器人，而是一个真正可工作的 Agent 系统。

---

参考资料

• 课程原视频：最近爆火的 Harness Engineering 到底是啥？一期讲透！，作者：code秘密花园
• OpenAI：Harness engineering: leveraging Codex in an agent-first world
• Anthropic：Effective harnesses for long-running agents
• Anthropic：Building effective agents

版权说明：本文配图为 AI 原创生成；课程观点已按主题进行重新组织，并加入工程化分析。转载请注明本文与课程来源。