Harness、Loop 与 Graph Engineering：AI Agent 为什么会失败

本文根据 Divy Yadav 于 2026 年 7 月 26 日发表在 AI Engineering Simplified 的文章改编整理，并结合原文引用的工程资料重新组织为中文版本。原文标题为《Harness Engineering vs Loop Engineering vs Graph Engineering: Why AI Agents Actually Fail》。

当 AI Agent 把任务做砸时，我们最容易得出的结论是：模型不够聪明，换一个更大的模型就好了。

但在真实系统中，失败往往并不发生在模型本身。即使使用同一个模型、面对同一个任务，只要给它不同的工具、检查方式和执行顺序，结果就可能完全不同。真正决定 Agent 是否可靠的，常常是包裹在模型外面的三层工程：

• Harness Engineering：Agent 可以使用什么工具、读取什么信息，以及被哪些权限和边界约束。
• Loop Engineering：Agent 如何尝试、观察结果、接受反馈、修正错误并决定何时停止。
• Graph Engineering：任务按照什么顺序流转，何时分支、并行、汇合，何时交给人工审批。

这三个概念听起来像新术语，但它们其实对应很朴素的管理问题：给员工什么设备，如何检查工作，以及团队如何协作。

先把 AI 想象成一名新员工

假设你刚招来一位非常聪明的新员工。他知识丰富、学习很快，也能写出漂亮的答案。但如果你没有给他电脑、文件访问权限和明确职责，他仍然无法真正完成工作。

如果你只说“把这件事做好”，却没有说明什么叫“完成”、如何检查结果、失败后能重试几次，他可能会交出一份看起来很自信、实际上无法使用的成果。如果工作还要经过研究、审核、批准和发布，那么没有清晰的交接顺序，再聪明的人也会在组织里迷路。

因此，一个 Agent 是否好用，可以先拆成三个问题：

1. 它拥有哪些能力和权限？
2. 它怎样知道自己做对了？
3. 完成一步之后，下一步由谁来做？

Harness：AI 到底被允许做什么

基础语言模型本身只能接收输入并生成输出。它不能天然打开你电脑里的文件，不能运行测试，不能浏览网页，也不会自动记住上一次会话做到了哪里。Harness 就是把模型变成“能干活的 Agent”的那套外部装备。

一个典型 Harness 可能包含：

• 文件读写、浏览器、终端、数据库和第三方服务等工具；
• 项目说明、历史记录、进度日志和长期记忆；
• 允许访问的目录、数据、账户和操作范围；
• 沙箱、权限确认、敏感操作拦截和资源限制；
• 把工具返回结果整理为模型可理解上下文的机制。

可以把 Harness 理解为新员工的“设备间”：电脑、工牌、资料柜、操作手册和安全规定都在这里。设备不足，员工什么也做不了；设备太多、说明混乱，他又会把时间浪费在找工具和理解噪声上。

Anthropic 在构建长时间运行的编码 Agent 时发现，简单地把旧对话不断压缩成摘要并不可靠：重要状态会被稀释，错误假设会被保留。更有效的做法是留下明确的启动文件、结构化进度日志和干净的交接记录，让下一次会话可以快速恢复工作状态。

这说明“记忆”不是把一切都塞进上下文。好的 Harness 会保留完成任务所需的最小充分信息，同时清楚地管理工具和边界。

Loop：工作如何被检查和修正

Agent 不应该只执行一次就宣布完成。可靠系统通常让它进入一个有意设计的循环：

1. 尝试执行；
2. 观察真实结果；
3. 用外部标准检查；
4. 根据反馈修改；
5. 满足完成条件后停止，或达到限制后退出。

Loop Engineering 的重点不是“让 AI 多想几遍”，而是安排可信反馈。模型说“我很有信心”不能算证据。代码要通过测试，网页要实际打开，数据要和来源核对，邮件要满足指定格式，关键操作要经过人工确认。

常见的 Loop 有三类：

• 检查与重试：执行后运行测试；失败则根据错误修复，再测试。
• 事件与唤醒：等待新邮件、定时器或人工输入，然后继续未完成任务。
• 持续改进：生成草稿、接受评审、修订，直到达到质量标准。

什么时候值得增加 Loop？一个简单判断是：当失败成本高于检查成本时，就应该设计验证循环。不过循环必须有上限。没有重试次数、时间预算或退出条件的“继续努力”，只会制造成本失控和无限重复。

Graph：任务接下来应该流向哪里

Graph Engineering 描述的是任务的允许路径。节点代表一个步骤或角色，连线代表下一步可能去哪里。它可以包含分支、并行执行、结果汇合、失败回退和人工审批。

例如，一份研究报告可能采用以下流程：

1. 研究 Agent 收集事实和来源；
2. 事实核查 Agent 验证关键主张；
3. 写作 Agent 生成初稿；
4. 编辑或人工进行评审；
5. 未通过则返回写作步骤，通过后才发布。

Graph 在任务确实存在不同路径、多名专业 Agent、复杂依赖或高风险审批时非常有用。但不是所有任务都需要一张复杂流程图。对于一步即可完成的工作，图越复杂，维护成本和故障点越多。

原文给出的实用建议是：先观察 Agent 实际如何工作，再画 Graph。不要先设计一张漂亮图，然后强迫真实任务适应它。流程应该来自被观察到的工作模式、失败点和交接需求。

为什么普通用户也应该关心这三层

你不需要亲自开发 Agent，也会直接感受到这些设计差异。两个产品可能使用同一类模型，一个稳定、可控，另一个却经常忘记上下文、重复执行或自信地交付错误结果。差别可能来自：

• 前者给了模型更合适的工具和更干净的上下文；
• 前者用真实测试验证结果，而不是相信模型自评；
• 前者在高风险步骤加入人工审批；
• 前者设置了重试预算和停止条件；
• 前者让不同角色以正确顺序协作。

所以，评估一个 AI 工具时，不要只问“它用了什么模型”。还应该问：它接入了什么工具？怎样处理记忆？如何验证完成？遇到失败会怎样？哪些动作需要我批准？

团队最容易忽略的五种失败

1. 还没观察工作，就先画流程图

团队一开始就设计复杂节点和连线，结果真实任务不断绕开或打破这套流程。先记录 Agent 实际执行步骤、等待点、失败点和人工介入点，再把稳定模式固化为 Graph。

2. 让 AI 给自己的工作打分

模型非常擅长为自己的答案提供合理解释，但解释不等于正确。验证必须尽量依赖外部信号，例如测试结果、真实页面状态、数据库约束、来源证据或人工审核。

3. 只说“继续尝试”，却没有退出规则

无限重试会浪费时间、Token 和 API 费用，甚至重复产生副作用。每个循环都应明确最多尝试次数、时间或成本预算，以及无法完成时如何升级给人工。

4. 把 Harness 变成杂物间

工具越多并不一定越强。重复工具、过期记忆和无关文档会增加选择难度与上下文噪声。更好的做法是让每个工具职责清晰，并只在当前任务需要时提供。

5. 把系统问题都归咎于模型

Agent 忘记任务，可能是交接记录过期；执行错误，可能是工具描述模糊；不停运行，可能是没有停止条件。换模型之前，先检查 Harness、Loop 和 Graph，往往更便宜，也更有效。

60 秒诊断：任何 AI Agent 都可以这样检查

Harness 检查

• Agent 是否拥有完成任务所需的正确工具？
• 它是否获得了最新、相关且足够的上下文与记忆？
• 权限、数据边界和危险操作是否清楚？

Loop 检查

• “完成”的定义是否明确且可测试？
• 结果是否有外部验证，而不是只靠模型自评？
• 是否设置重试次数、时间预算和停止规则？

Graph 检查

• 工作步骤和依赖关系是否按正确顺序执行？
• 真正需要分支、并行或人工批准的地方是否明确？
• 是否跳过了必要的评审者或上游依赖？

这套清单的价值在于，它把模糊的“AI 不好用”转化为可定位、可修复的工程问题。

结语：模型是人才，系统才是工作环境

模型提供推理与生成能力，但它不会自动获得工具、反馈和组织结构。Harness 决定它拥有什么装备与边界；Loop 决定它如何从结果中纠错；Graph 决定工作如何在步骤、角色和审批之间流转。

因此，当 Agent 再次失败时，不要立刻更换模型。先问三个问题：它是否拿到了正确工具？是否有可信的验证循环？是否沿着正确流程工作？很多时候，答案不在更大的模型里，而在更好的系统设计里。

参考资料

• Anthropic：Building Effective AI Agents
• LangChain：The Anatomy of an Agent Harness
• LangChain：The Art of Loop Engineering
• LangChain / LangGraph 1.0
• OpenAI：Agents SDK Guide
• OpenAI：A Practical Guide to Building AI Agents
• Microsoft AutoGen：GraphFlow
• Microsoft Research：AutoGen Studio

作者与来源：Divy Yadav，AI Engineering Simplified。本文为中文改编整理，文中观点和插图主要来自原文；参考资料链接沿用原文所列来源。