Harness 深度图解

Harness 深度图解：模型之外，谁让 AI 把事情做完？

你让 AI 修复一个登录故障。它很快给出计划：查日志、定位原因、修改代码、运行测试。

但计划写出来之后，一连串问题才刚刚开始：谁去执行命令？测试报错后，结果怎么回到模型手里？做到一半换了会话，进度怎么办？它说"修好了"，又凭什么相信？

这些问题，把我们带到了 Agent Harness。

本文讨论 AI Agent 的执行系统；图中的结构是便于理解的概念模型，故障修复是说明性示例。

可以把 Harness 理解为围绕模型搭建的执行底座：它组织输入、承接工具调用、管理运行状态，并让行动进入可检查的循环。

模型擅长根据当前信息判断"下一步做什么"；运行系统负责把这个提议落实为一次受约束的操作，并把实际结果送回来。一个完整 Agent 的行为，来自模型、这套执行机制及任务环境的共同作用。

例如，模型输出"读取登录日志"这类工具调用请求，并不等于日志已经读取。工具是否存在、参数是否合法、访问是否被允许、执行是否超时，都需要系统实际处理。

这里也能区分三个常被放在一起的概念：

它们彼此配合。提示词可以要求先测试，但要可靠执行这个要求，还需要可用的测试工具、明确的流程，以及可以检查的结果。

把一轮执行展开，通常会看到这样的过程：准备上下文，让模型提出动作，检查并执行动作，收集结果，再判断任务是否完成。

Anthropic 对 Agent 的介绍强调了环境反馈：工具返回值、代码执行结果等真实信息，是后续判断的依据；循环也需要停止条件。来源：Building effective agents

回到登录故障。假设第一次测试返回"会话过期"。下一轮就应该带着这条新证据去检查会话处理，而不是机械重复上一条修改建议。

有反馈的循环，才有机会发现方向错了。 反馈本身也需要质量：空日志、截断的错误、过时的测试结果，都可能把模型引向错误结论。

因此，一个可用的实现还要处理正常路径之外的情况：工具超时怎么办？权限被拒绝后怎样说明阻塞？连续重试没有进展时何时停止？这些规则应有系统层面的约束，不能只寄希望于模型每次都自觉遵守。

任务越长，越容易出现一种尴尬：上一轮做了不少事，下一轮却不知道哪些已经可靠完成。

Anthropic 在长时间运行 Agent 的实验中采用了初始化与增量推进的安排，并利用功能清单、进度记录、版本历史和测试结果支持后续会话接手。这是针对其任务场景的一种实现方案。来源：Effective harnesses for long-running agents

把这个思路用到我们的例子，交接记录可以很短，但必须具体：

已复现：过期会话下登录跳转失败。已修改：会话过期时的跳转逻辑。已验证：原失败用例通过。未完成：检查首次登录和退出后的回归。下一步：运行这两组用例，再更新完成状态。

这是示意记录，并非本次实际运行的测试结果。

"已完成"应当绑定证据。只记下一句"登录已修好"，下一轮很难判断它指的是代码改完、测试通过，还是线上问题真正解决。

保存文件和读入上下文是两回事。 外部状态需要被找到、正确读取，并与当前环境核对；有进度文件不代表模型天然拥有永久记忆。

OpenAI 的 Harness engineering 实践强调：工程工作还包括让文档、应用状态和反馈对 Agent 可见，并把部分架构约束编码为自动检查。由此可见，改进 Agent 的工作环境，本身就是工程投入。来源：Harness engineering

对于登录修复，验收条件可以设为：原问题能够复现；修改后该用例通过；关键登录路径没有出现新的回归；交付说明包含改动和未解决项。实际项目还需按自身需求补全标准。

当任务失败时，可以沿着链条定位：

这套排查框架是本文给出的工程建议。它有助于决定该改提示、改工具、改上下文管理，还是重新评估模型能力。

可以从一个最小闭环开始：清楚的目标、少量可靠工具、明确的验收方式、必要的状态记录，以及停止规则。

出现具体瓶颈后，再增加更细的记忆管理或多 Agent 协作。后者也会带来协调、重复劳动和结果合并问题，是否值得要通过任务验证。

建议固定一批有代表性的真实任务，同时比较完成率、人工接管次数、耗时和总成本。否则，"这次终于成功了"可能只意味着多运行了很多轮。

Harness 的价值，是让目标、行动、反馈和证据连成一套可以持续工作的机制。 当 AI 再说"修好了"时，我们应该能继续追问并得到具体答案：改了哪里，验证了什么，还有什么没完成。

资料核对：2026-09-10。本文为基于上述一手资料的原创解释与构图；产品实现会有差异，图中流程不代表某一产品的完整内部架构。