第一章的追问#

在第一章，我们看到了两个核心问题：AI 在长时任务中会"失忆"，以及 AI 在评估自己作品时会"自信地赞扬"。这两个问题共同指向一个结论——AI 的能力已经足以完成复杂的开发任务，但 AI 完成这些任务的过程缺乏结构。

面对这个问题，一种自然的反应是：“那给 AI 加上更多的流程不就好了？“让 AI 也开站会、写日报、做迭代评审，就像管理一个开发团队那样管理 AI。

但这个思路忽略了一个关键事实：AI 不是人。

人需要流程来弥补记忆衰减、沟通损耗和注意力分散。但 AI 之间的信息传递几乎是零损耗的——一个 Agent 写完文件，另一个 Agent 读取，信息不会遗漏、不会变形、不会被遗忘。给 AI 套上为人的缺陷而设计的流程，就像给鱼穿上救生衣：不仅多余，还会碍事。

Harness 的解法不是"给 AI 增加流程”，而是”为 AI 重新设计最小必要的协作框架"。

三个角色#

Harness 的核心由三个角色构成。它们都是 AI Agent，各自承担不同的职责，通过协作完成一个长时任务。

Planner（设计规划）#

Planner 的角色可以理解为"项目启动前的翻译官"。它接收人类用自然语言描述的需求，将其翻译为一份结构化的设计方案（Design）。这份方案不是具体的任务清单（to-do list），而是描述用户旅程、预期效果、验收标准等高级维度的抽象规格——例如"用户如何完成登录流程"“系统应该呈现什么状态"“什么算成功、什么算失败”。

具体的任务分解（如"先设计数据模型，再实现 API”）不由 Planner 负责，而是留给 Generator 在执行阶段自行拆解。Planner 的关键价值在于消除模糊性：人类在表达需求时往往存在隐性假设——“做一个用户登录功能"背后可能暗含"支持第三方登录"“需要记住登录状态"“失败三次后锁定"等未被显式说出的要求。Planner 的作用就是把这些隐性假设显性化，写成一份"做什么、做到什么程度"的设计蓝图，让 Generator 知道靶子在哪里，让 Evaluator 知道如何验靶。

Generator（实现者）#

Generator 是 Harness 中的"执行者”。它读取 Planner 产出的 Design，自行拆解为具体任务，逐个完成代码编写、文档撰写或其他形式的产出。Generator 的核心特点是专注——在一个轮次内，它只关注当前任务，不受其他任务的干扰。

Generator 与人类的程序员有一个本质区别：它不会因为"昨天写的代码今天忘了"而出错，因为它每次启动时都会读取 Planner 提供的完整任务规格和之前的上下文交接文件。但它也有一个本质局限：它不会主动质疑任务本身的合理性。如果 Planner 对需求的理解有偏差，Generator 会忠实地执行这个偏差。

Evaluator（验收方）#

Evaluator 是 Harness 中的"独立质检员”。它的职责是对 Generator 的产出进行验收——不是按照 Generator 自己的标准，而是按照一套预先定义的、与 Generator 无关的验收标准。

Evaluator 的关键价值在于打破自我评估偏差。第一章提到，AI 在评估自己作品时会"自信地赞扬”。Evaluator 通过"第三方独立验收"的机制解决了这个问题：它不看 Generator 的代码注释，也不采信 Generator 的自评报告，而是直接运行代码、测试功能、检查边界场景，给出客观的评分。

验收标准：完成定义的协商#

在 Generator 开始编码之前，Harness 有一个关键环节：验收标准协商。

Generator 和 Evaluator 会就"什么算完成"达成一致。这个过程不是人类在审查 AI 的计划，而是两个 AI Agent 之间的对话：Generator 提出"我打算这样实现，这样验证"，Evaluator 审核这个方案是否覆盖了所有必要的验收维度，双方迭代直到达成共识。

这个机制解决了一个经典问题："我以为你做完了，其实你没做完。" 在传统的开发流程中，“完成"的定义往往散落在产品经理的文档、工程师的理解和 QA 的测试用例中，各方对"完成"的认知不一致。Harness 通过"编码前就定义完成标准"的方式，把这个模糊地带提前消除。

为什么 AI 的流程可以更短#

理解了 Harness 的三个角色和验收标准机制后，一个自然的问题是：这套流程和传统的项目管理流程（如 Scrum）有什么区别？为什么 Harness 可以比人的流程更轻量？

答案在于信息传递的效率。

在传统团队中，Planner（产品经理）把需求写成文档，Generator（程序员）读文档并写代码，Evaluator（QA）测试代码——这个过程依赖大量的人工同步：站会同步进度、评审会同步理解、文档同步细节。这些同步机制的存在，是因为人脑之间的信息传递存在天然的损耗——读了文档不一定理解，听了汇报不一定记住，看了代码不一定能复现思路。

但在 Harness 中，三个角色之间的信息传递通过结构化文件完成。Planner 的输出是一份机器可读的任务规格，Generator 直接读取这份规格开始工作，Evaluator 也读取同一份规格来验收。信息不会遗漏，不会变形，不需要"开会同步”。

因此，Harness 可以删减传统流程中为弥补人类信息损耗而存在的环节：

• 不需要每日站会——AI 不需要"口头同步"，文件就是同步
• 不需要迭代评审会——Evaluator 自动验收，不需要人类召集会议
• 不需要 Retrospective——AI 不需要"团队氛围建设"，问题直接通过验收标准暴露

Harness 保留的是骨架：规划、验收标准协商、独立评估。删减的是仪式。

人类的角色：不是旁观者，而是校准层#

至此，我们描述的 Planner（设计规划）、Generator（实现者）、Evaluator（验收方）三角色，以及 AI 之间的验收标准协商机制，是 Anthropic Harness 论文提出的原生设计——一个纯 AI 自治的协作框架。在这个原生设计中，人类设计 Harness、设定初始需求、审查最终输出，但不介入中间过程的验收。

但在实际工程落地中，我们发现仅有 AI 自治还不够。人类需要在框架中扮演一个关键角色：需求校准层。这出于三个必要性。

人类的作用不是"监督 AI 的每一步"，而是作为需求校准层和业务正确性的最终校验。这出于三个必要性。

第一，需求校准。

Planner 将人类的需求翻译为 Design 时，翻译过程可能产生偏差。但偏差不一定来自 AI 的理解错误——它可能来自人自己没表达清楚，也可能来自业务环境已经变化、原来的需求不再适用。人类验收的作用不是"找 AI 的茬"，而是验证："翻译后的任务是否仍然对准真实的目标？"

第二，及时止损。

长时任务中，错误具有累积效应。Planner 在第 2 轮的任务偏差，到第 8 轮可能演变成架构级的返工。人类在关键节点的验收，相当于踩刹车——在成本尚可控时纠正方向，避免在错误的路径上越跑越远。

第三，建立可预期的信心。

标准化的人类验收模板让管理层能回答一个基本问题：“这个 AI 主导的项目，质量到底处于什么水平？“这不是心理安慰，而是组织决策的必要信息。当验收结果可量化、可比较、可追溯时，管理层才能决定是否扩大 AI 的使用范围、是否将项目投入生产环境。

一个完整轮次：用户登录功能#

让我们用一个具体场景来走一遍 Harness 的完整流程。

场景：团队需要为内部管理系统实现一个"用户登录功能”。

第一步：Planner（设计规划）接收需求，产出 Design。

人类输入：“实现用户登录功能，支持邮箱和密码登录。”

Planner 将需求翻译为设计方案：

• 用户旅程：用户进入登录页 → 输入邮箱和密码 → 点击登录 → 若成功则跳转首页并记住登录状态；若失败则显示错误提示，连续失败 5 次后锁定账户 15 分钟。
• 效果描述：
  • 登录页需包含邮箱/密码输入框、提交按钮、错误提示和加载状态；
  • 登录状态持久化：用户操作后保持登录状态，长时间无操作自动退出；
  • 密码必须安全存储，禁止以可读取的形式保存或传输。
• 验收标准：
  • 功能：正确验证邮箱和密码，登录成功后跳转首页并保持登录状态，失败时返回明确错误；
  • 安全：密码存储不可被反向还原，API 响应时间不超过 200ms，失败 5 次锁定 15 分钟；
  • 兼容：与现有用户管理模块无冲突。

Planner 不指定“先写数据模型还是先做 UI”——这些具体的任务分解留给 Generator。

第二步：Generator（实现者）读取 Design，自行拆解任务，并与 Evaluator（验收方）协商验收标准。

Generator 读取 Design 后，自行提出技术方案：“我计划按 数据模型 → 登录 API → 登录页面 UI → 状态持久化 → 安全策略 的顺序实现。登录状态用 JWT 令牌实现，支持自动续期；密码用 bcrypt 哈希存储，禁止明文。每个任务完成后，Evaluator 运行对应的自动化测试验证功能正确性。”

Evaluator 审核：“你的顺序和技术方案合理。JWT + bcrypt 满足 Design 中’密码存储不可被反向还原’的安全要求。我重点验收以下维度：登录状态是否正确保持和续期、密码存储是否不可还原、API 响应时间是否不超过 200ms、失败 5 次后是否锁定 15 分钟。”

双方就验收标准达成一致。

第三步：Generator 按自行拆解的任务逐个实现，Evaluator 逐个验收。

Generator 完成数据模型设计 → Evaluator 运行测试，验证通过 → 进入下一任务。

Generator 完成登录 API → Evaluator 运行测试，发现"并发登录时的令牌覆盖"未处理 → 返回 Generator 修正 → 重新验收，通过 → 继续推进。

以此类推，直到 Design 中定义的全部效果实现完毕。

第四步：人类验收。

所有任务通过 Evaluator 的自动验收后，人类进行最终验收：

• 功能完整性：是否满足原始需求？（发现：需求中未提及"忘记密码”，但团队认为应该一并实现）
• 代码质量：是否可读、可维护？
• 安全合规：是否符合公司的安全规范？
• 与现有系统的兼容性：是否会破坏已有的用户管理模块？

人类验收发现"忘记密码"功能缺失——这不是 AI 的错误（原始需求中确实没提），而是需求校准的结果。团队决定在下个轮次补充这个功能。

第五步：信息交接（Context Handoff）。

当前轮次结束，Planner 将本轮的完整上下文——任务清单、代码变更、验收结果、人类反馈——整理成结构化的交接文件。下一个轮次启动时，新的 Agent 直接读取这份文件，零损耗地继承全部上下文。

这个流程的关键洞察在于：Harness 不是让 AI 变得更聪明，而是让 AI 的工作方式变得可预期、可验证、可交接。 当每个角色有清晰的边界、每个产出有明确的标准、每个轮次有完整的上下文记录时，长时任务就从"黑盒"变成了"透明管道"。

下一章，我们将把 Harness 的这个核心思想与软件工程的经典理论对接——看看 DevOps 和持续交付的哪些原则可以被 Harness 吸收，哪些需要被重新诠释。

本章内容说明

• 论文原意：Planner（规划器）、Generator（生成器）、Evaluator（评估器）三角色体系，以及 AI-AI 之间的 Sprint 契约（验收标准协商）和上下文交接（Context Handoff）机制，源自 Anthropic《Harness Design for Long-Running Application Development》。
• 作者分析：Planner（任务拆解）、Generator（实现者）、Evaluator（验收方）等角色的通俗化解读（如"消除模糊性"“专注"“独立质检员”），以及"AI 流程可以比人的更短"的流程轻量化设计哲学，为本文作者基于论文框架的分析推导。
• 工程扩展：“人类的角色：需求校准层"一节中关于"需求校准"“及时止损"“建立可预期信心"的三重必要性论述，是基于论文 AI 自治框架的工程落地实践补充，非论文原文。
• 虚构示例：“用户登录功能"的完整轮次演示为作者构造的示例场景，用于说明 Harness 的运转方式，非论文中的真实案例。