当AI Agent进入研发流程，代码生成不再是瓶颈，验证与信任成为关键。阿里开源的Better Harness通过检查Agent的工作闭环，而非仅看结果，试图解决这一难题。本文深入解析其前馈与反馈机制，并探讨产品经理如何从写需求转向设计Agent的工作制度，揭示AI竞争正从模型能力转向工作系统。

过去一年，企业谈论 AI Agent，最常问的是：用哪个模型？上下文窗口多大？接了多少 MCP？配置了多少 Skill？

但当 Agent 真正进入研发流程后，一个更现实的问题出现了：

Agent 可能十分钟就完成了一次代码修改，人却要花两个小时确认它有没有理解错需求、绕过规范、漏掉测试，或者给系统埋下新的风险。

表面上，代码生成速度提高了；实际上，瓶颈只是从“生产代码”转移到了“验证代码”。

阿里开源的 Better Harness，试图解决的正是这个问题。它并不是让模型变得更聪明，而是检查和改进 Agent 背后的工作方式：目标是否清楚、执行是否受控、结果是否经过验证、交付是否可靠，以及本次任务的经验能否被下一次任务复用。

这背后释放出一个重要信号：

AI Agent 的竞争，正在从模型能力竞争，进入工作系统竞争。

一、当生成不再稀缺，信任开始成为瓶颈

在传统软件研发中，代码生产能力相对稀缺。需求排期、开发资源和工程师时间，决定了产品迭代速度。

Agent 改变了这个前提。

代码可以快速生成，测试可以自动补充，文档可以即时整理，甚至一个需求可以同时交给多个 Agent 并行处理。产能突然变得充足，但团队并没有因此自动获得更高的生产力。

因为企业真正需要的从来不是更多代码，而是可信的结果。

AI 时代的实际生产力，更接近这样一个公式：

实际生产力 = 生成速度 × 首次正确率 × 可验证性 × 经验复用率

如果 Agent 生成得很快，但每次都需要人工从头检查；如果任务完成了，却没有证据证明结果正确；如果同一种错误在下一次任务中继续发生，那么所谓的效率提升就会被审查、返工和风险成本抵消。

Better Harness 的意义，是把“Agent 能不能做”推进到了下一个问题：

“团队凭什么相信它做对了？”

二、Better Harness 检查的不是代码，而是代码背后的工作闭环

大多数代码审查工具关注的是最终结果，例如代码是否符合规范、测试是否通过、是否存在安全漏洞。

Better Harness 更关注结果产生的过程。

它试图回答五个问题：

1. Agent 是否真正理解了任务，以及什么才算完成？
2. Agent 是否沿着团队认可、可以复现的路径执行？
3. 是否存在足够证据证明变更有效？
4. Agent 的速度是否绕过了审查、审批和交付保障？
5. 本次任务暴露的问题，能否沉淀为下一次任务可以使用的经验？

这五个问题看似属于研发管理，实际上也适用于绝大多数企业 Agent。

一个客服 Agent 是否理解了用户真正的问题？一个营销 Agent 是否遵循了品牌与合规要求？一个数据分析 Agent 是否说明了数据来源和计算口径？一个采购 Agent 是否在授权范围内做出了决策？

Agent 的应用场景不同，但背后的治理逻辑相同：

不仅要看它交付了什么，还要看它如何得到这个结果。

Better Harness 还有一个值得关注的设计原则：没有观察到的行为，不轻易判断为“好”或“坏”，而是明确标记为证据不足。

这点非常重要。

企业在评估 Agent 时，很容易陷入一种虚假的确定性：测试通过就认为任务完成了，配置了规则就认为 Agent 一定遵守了规则，生成了报告就认为过程已经可追溯。

但“机制存在”不等于“机制被执行”，“检查通过”也不等于“业务结果正确”。

Better Harness 更像是一套工作过程的审计与改进系统，而不只是一张评分表。

三、真正有效的 Agent 管理，需要“前馈”和“反馈”同时存在

Better Harness 背后的核心逻辑，可以概括为两个方向：前馈与反馈。

前馈发生在 Agent 行动之前。

例如任务说明、产品规范、项目规则、可调用工具、执行边界、验收标准，都在提前告诉 Agent：应该做什么、不能做什么，以及什么样的结果才是可以接受的。

反馈发生在 Agent 行动之后。

例如测试、代码检查、运行日志、Hook、自动评审和人工审批，都在观察 Agent 的实际结果，并帮助它发现问题、重新修正。

只有前馈，没有反馈，团队会积累越来越多的规则，却不知道这些规则是否真的起作用。最终形成一份越来越长、Agent 却未必能够正确执行的“说明书”。

只有反馈，没有前馈，Agent 就会不断试错。每次出错后再修正，但类似的问题仍会在下一个任务中重复出现。

一个成熟的 Agent 工作系统，应该形成这样的闭环：

明确意图—约束执行—获取信号—修正结果—沉淀经验

这也意味着，Prompt 并不是 Agent 管理的终点。

Prompt 只能表达一次任务意图，而 Harness 需要把任务意图、权限边界、执行路径、验收证据和复盘机制组合成一个持续运转的系统。

四、产品经理的工作，也将从“写需求”走向“设计工作闭环”

Better Harness 虽然首先面向编码 Agent，但它对产品经理的启发可能更大。

因为当 Agent 开始承担具体工作，产品经理需要设计的不只是产品功能，还包括 Agent 的工作制度。

1. 从写 PRD，升级为设计“证据合同”

过去写需求，重点是说明要实现什么功能。面对 Agent，只写功能描述已经不够。

产品经理还需要定义：

• 目标是什么，哪些内容明确不在本次范围内；
• Agent 可以调用什么数据和工具；
• 哪些操作可以自动完成，哪些必须获得人工确认；
• 任务完成后需要提交哪些证据；
• 出现什么结果时，任务必须停止或回滚。

最关键的问题不再是“需求有没有写清楚”，而是：

“当 Agent 告诉我任务已经完成时，它需要拿出什么证据，我才会相信？”

这可以称为产品与 Agent 之间的“证据合同”。

2. 从追求完全自动化，转向设计分级自治

不少企业衡量 Agent 的方式，是看它替代了多少人工步骤。但完全自动化并不一定是正确目标。

更合理的方式，是按照风险设计不同的自治等级：

• 低风险、可逆的任务，可以自动执行并自动验证；
• 中等风险的任务，可以由 Agent 执行，但在交付前设置人工确认；
• 高风险、不可逆或涉及合规的任务，应限制 Agent 的操作范围，让人保留最终决策权。

Agent 治理的目标不是让人彻底退出，而是让人的注意力集中到真正需要判断、权衡和承担责任的地方。

企业需要追求的不是最大化自治，而是最大化安全且可验证的自治。

3. 从保存聊天记录，升级为沉淀组织能力

今天很多团队使用 Agent 的方式，仍然停留在个人层面。

一个员工在对话里纠正了 Agent，下一位员工却要重新经历同样的问题；一次任务找到了一条更好的执行路径，这条经验仍然留在聊天记录里；Agent 犯过的错误被人工修复，却没有进入团队下一次任务的运行环境。

真正有价值的经验，不能只停留在对话里，而应该被转化为规则、Skill、模板、测试、检查器或审批节点。

可以建立一条简单的改进原则：

第一次出现的问题可以是偶然，第二次重复出现的问题就应该被视为系统问题。

每一次重复错误，都应该推动团队增加一条更清晰的前馈指引，或者增加一个能够自动发现问题的反馈传感器。

这样，Agent 完成的不只是当前任务，还在持续改进团队未来完成任务的方式。

五、企业真正的 AI 壁垒，可能不是模型，而是 Harness

模型能力正在快速扩散。

同一个模型可以被不同企业使用，相似的 Agent 产品也很容易被采购和接入。单纯依靠模型，很难形成长期差异。

但 Harness 不同。

它承载的是一家企业特有的业务规则、决策边界、质量标准、审批制度和历史经验。这些内容很难从外部直接复制。

未来企业的 Agent 能力，可能由三类资产共同决定：

1. 模型提供通用的理解和生成能力；
2. 工具提供访问数据、操作系统的能力；
3. Harness 提供组织特有的工作方式和纠错机制。

如果把模型比作发动机，那么 Harness 就是道路、仪表盘、护栏和维护体系。

发动机决定了车辆理论上能跑多快，Harness 决定了它能否稳定、安全地到达目的地。

因此，企业的 AI 转型并不只是购买更多 Agent 账号，而是要把原本存在于员工经验中的隐性规则，转化为机器可以理解、执行和验证的组织系统。

谁能更快完成这一步，谁才可能真正把 Agent 从个人效率工具，变成企业生产力基础设施。

六、Better Harness 也解决不了所有问题

Better Harness 提供了一个很有价值的方向，但不能把它理解成 Agent 治理的最终答案。

首先，证据充分不等于业务正确。

测试通过，只能证明结果满足了测试；流程完整，只能证明 Agent 按照流程执行。它们无法自动证明团队解决的是正确问题，也无法证明用户真的愿意使用这项功能。

特别是在涉及用户体验、商业判断和复杂业务取舍时，人的判断仍然不可替代。

其次，任何评分体系都有被“优化”的风险。

一旦团队把 Harness 报告中的分数变成绩效指标，Agent 和团队就可能开始追求报告好看，而不是真正降低风险。最终出现测试越来越多、文档越来越全，业务结果却没有改善的情况。

因此，与其关注一次报告的绝对分数，不如观察多次任务中的长期变化，例如返工率是否下降、人工审查时间是否缩短、重复错误是否减少。

最后，Harness 自身也会产生债务。

规则可能过时，Skill 之间可能相互矛盾，检查器可能长期误报，过多约束也可能让 Agent 失去处理特殊情况的能力。

所以 Harness 也需要负责人、版本管理、定期清理和有效期。它不是一次配置完成的静态制度，而是一项需要持续运营的产品。

七、产品团队可以怎样开始？

团队不必一开始就建立一套庞大的 Agent 治理平台，可以先选择一个高频、边界清晰、结果可验证的任务进行试验。

例如修复常见缺陷、生成数据周报、整理用户反馈，或者完成标准化的运营配置。

围绕这个任务建立四类最小资产：

1. 一张任务卡：写清目标、非目标、限制条件和完成标准。
2. 一条受控路径：明确 Agent 可以使用的工具、数据和权限。
3. 一组结果证据：要求提交测试结果、数据来源、变更记录或验收截图。
4. 一条学习规则：重复出现的问题必须转化为新的指引或检查机制。

连续运行几个任务后，重点观察四项指标：一次通过率、人工审查时间、重复错误率和问题定位时间。

如果这些指标持续改善，说明团队建立的不只是一个更复杂的 Agent，而是一套正在学习的工作系统。

结语

Better Harness 最值得关注的地方，不是它提供了一份 Agent 评估报告，而是它重新定义了企业应该如何管理 Agent。

过去，企业管理的是人、岗位和流程；未来，企业还需要管理由人、Agent、工具、规则和反馈共同组成的工作闭环。

产品经理也将因此获得一个新的职责：不仅设计用户如何使用产品，还要设计 Agent 如何理解目标、执行任务、证明结果并吸取经验。

下一阶段，真正领先的企业未必是使用 Agent 数量最多的企业，而是最早把不确定性转化为证据、把重复错误转化为系统能力的企业。

模型决定了 Agent 的能力上限，而 Harness 决定了这种能力能否成为稳定的组织生产力。