文章总结： 本文解析智能体可靠性的三层架构：Harness提供工具与权限环境，Loop强调基于证据而非模型信心验证，Graph管控任务流转秩序。文章指明换模型无法掩盖工程缺陷，总结五类错误，建议先收集轨迹再固化流程，区分生成与审核，建立检查清单，用确定性工程结构承载模型不确定性。 综合评分： 92 文章分类： AI安全,安全建设,安全开发

Agent可靠性的三个层次：从Harness、Loop 到 Graph

原创

裴伟伟 裴伟伟

洞源实验室

2026年8月1日 15:06 山西

在小说阅读器读本章

去阅读

最近，关于 Agent Harness Engineering、Loop Engineering 和 Graph Engineering 的讨论越来越多，这三个概念都围绕大模型展开，也都涉及工具调用、状态管理和任务循环，但目的都是一致的，就是解决 Agent 尤其是多 Agent 运行时候的可靠性，因而经常被混在一起。

这种混淆在非常简单的场景下几乎没什么区别：模型能调用一次工具、返回一个看起来合理的结果，足以让 Demo 跑起来就够了。但当 Agent 开始操作文件、访问数据库、调用生产 API，甚至直接影响客户和业务数据时，这三者的区别就会非常大，所以根本上 Harness、Loop 和 Graph 是架构设计的区别。

如果用一句话来形容这三者的不同，最简单的理解方式是：

Harness Engineering 解决 Agent 在什么环境中工作；

Loop Engineering 解决 Agent 如何根据反馈反复工作；

Graph Engineering 解决不同任务按照什么路径流转。

它们分别对应的是环境、反馈与流程。

一、很多所谓的模型问题，其实是工作条件有问题

一个裸模型能做的事情其实很有限，它接收上下文，然后输出文本或工具调用意图。至于如何真正执行工具、保存项目状态、恢复中断任务、限制权限、检查结果，以及在失败后重新开始，都要由模型外部的软件系统完成。

LangChain 将 Agent 概括为“Model + Harness”，并把 Harness 定义为模型之外的代码、配置和执行逻辑，包括系统提示词、工具、Skill、MCP、文件系统、沙箱、模型路由、状态管理和中间件。这正也是 Harness 最有价值的地方：它把注意力从“模型崇拜”拉回了工程现实。

如果两个团队使用完全相同的基础模型，其最终效果可能截然不同。一个团队给模型提供清晰的工具说明、稳定的工作空间、最小权限和可以追踪的状态；另一个团队只给出一段模糊的提示词，再套上一层时好时坏的 API。这有点像让两个能力相近的工程师处理同一场生产故障。一个人有完整日志、资产信息、测试环境和回滚权限，另一个人只有一句“系统好像有点慢”。最后结果必然不同，但这很难简单归因于个人智力的差距。

二、Harness 不是工具箱，而是 Agent 的工作环境

一套面向生产的 Harness，通常至少需要包含六类能力。

第一类是上下文注入，包括任务指令、检索资料、会话状态、Skill 和针对当前任务的策略。

第二类是行动能力，例如 API、浏览器、Shell、代码解释器、数据库以及 MCP 工具。

第三类是持久化能力，包括文件、会话、检查点、进度记录、Git 历史和长期记忆。没有这些能力，Agent 每次上下文重建都像一名失忆的员工重新上班。

第四类是执行控制，例如超时、重试、预算、模型路由、子 Agent 调度和人工审批。

第五类是安全控制，包括权限隔离、命令白名单、网络边界、密钥管理、沙箱和人工授权。

第六类是可观测性，需要记录工具输入输出、状态变化、成本、延迟和评估结果。

这里最容易产生的误区是把 Harness 当成一个可以不断往里添加工具和记忆的容器。实际上，工具越多，模型选错工具的概率越高；上下文越嘈杂，模型越难找到真正相关的信息；权限越宽，错误操作造成的影响越大。能力边界不清晰，并不会让它更智能，只会让一次普通判断错误变成生产事故。

三、Loop 的核心不是重复，而是用证据纠正结果

每个能够调用工具的 Agent，内部都存在一个基础循环：

• 调用模型
• 获得结果
• 执行工具
• 把执行结果返回模型
• 继续判断
• 直到任务结束

Loop Engineering 关注的不是简单增加一个循环，而是如何把一次模型调用变成可以验证、可以恢复、可以终止的工作过程。一个设计良好的 Loop，需要明确几个问题：

• 什么事件会触发下一轮执行？
• 这一轮要达到什么具体目标？
• 下一轮需要继承哪些状态？
• Agent 可以调用什么、修改什么、消耗多少资源？
• 用什么证据证明任务成功？
• 失败后返回什么样的反馈？
• 最多允许重试多少次？
• 什么时候转交人工处理？

以上问题本质上都在说明一个原则：不要围绕模型的信心建立循环，而要围绕证据建立循环。

也就是说：

Agent 说自己已经完成不是停止条件。测试全部通过、链接可以访问、数据结构校验成功、引用能够找到来源、审核人员确认通过，这才是停止条件。

这一区别看起来很小，实际上决定了 Agent 是在完成任务，还是在生成一段关于“任务已经完成”的文字。语言模型擅长表达确定性，但表达得很确定，并不等于事实已经成立。

当然 Loop 也有成本。每增加一个审核器、测试步骤或重试过程，都可能增加模型调用、工具执行和等待时间。因此，不是所有任务都要建立复杂的验证循环。更合理的原则是：当失败造成的损失高于验证成本时，再增加相应的验证。比如：一段内部会议纪要需要进行人工抽查；一次涉及资金、账号权限或生产发布的操作，则不能把模型觉得没问题当作审核结论。

四、Graph 解决的不是执行能力，而是执行秩序

Graph Engineering 关注的问题又向外扩展了一层：完成当前节点之后，系统允许哪个节点继续运行？

在工作流图中，节点代表 Agent、模型调用、确定性函数、工具或人工审批；边代表任务之间的流转关系。边可以表示顺序执行、条件分支、并行展开、结果汇总、失败回退、循环和人工中断。

Graph Engineering 需要设计的内容包括：

• 哪些工作交给确定性代码，哪些交给模型或专业 Agent；
• 每个节点可以读取和修改哪些状态；
• 并行节点产生的结果如何合并；
• 什么证据决定流程前进、回退或升级；
• 哪些任务可以并行，哪些任务必须等待；
• 哪些节点允许重试，最多重试多少次；
• 在什么位置保存检查点，中断后如何继续。

当然，图也不是越复杂越好。对于给一个 Agent 三个工具，让它完成一项相对开放的任务，提前把所有可能路径都画成固定流程，反而可能限制模型的动态规划能力。

Graph 可以让流程更容易检查，也可能过早固化团队对任务的错误理解。其最大的问题不是复杂，而是复杂得很有秩序，看起来特别像已经完成了架构设计。

五、三层架构如何在一个系统中协同

假设我们要设计一个自动生成行业研究报告的 Agent。

Harness 为它提供浏览器、搜索工具、文件系统、引用检查器、持久化状态和权限边界，同时记录工具调用、成本和执行轨迹。

Graph 定义整体流程：任务拆解、并行搜索、资料汇总、撰写初稿、事实核查、人工审批和最终发布。

Loop 则存在于具体节点内部。例如，事实核查没有通过，就把缺失的证据返回给研究节点；初稿未达到质量要求，就把明确的审核意见返回给写作节点；达到最大重试次数后，不再让 Agent 无限改写，而是转交人工处理。

在三者的协作中，Graph 运行在 Harness 提供的环境中，Graph 的节点中包含一个或多个 Loop，而 Loop 所需要的状态、工具、验证器和权限又由 Harness 提供。三者存在交叉，但责任又各不相同，这种区分最大的价值是在系统失败时知道应该修改哪里：

• 如果 Agent 无法安全访问数据，应该检查 Harness。
• 如果 Agent 总是提前结束，或者没有证据仍然反复重试，应该检查 Loop。
• 如果多个节点执行顺序混乱、并行结果无法合并，应该检查 Graph。

所以，不是所有问题都是模型的问题，我们常常说换模型，不过是其代价最小，责任最小罢了。

六、Agent 架构背后的几个昂贵错误

第一个是在不了解实际工作方式之前就开始实行Graph。

有些团队拿到业务流程后，立即将其转换成几十个节点，却没有观察一个能力较强的 Agent 实际会如何处理任务。更稳妥的做法，是先用简单 Harness 运行并收集执行轨迹，再把反复出现、相对稳定的路径固化为 Graph。

第二个是让相同模型同时负责生成和审核。

模型的自我审核有一定价值，但同一模型、相似上下文和相同认知偏差，很容易让生成者与审核者共同忽略一个问题。能够用测试、Schema 校验和规则检查的地方，应优先使用确定性验证；需要模型审核时，也应隔离上下文，并为高影响操作保留人工审批。

第三个是把“继续尝试”当成 Loop 设计。

没有目标、证据、最大次数和升级路径的重试，本质上只是持续消耗成本。Agent 没有因为多运行十轮就更接近正确答案，它也可能只是在十种不同的表达方式中重复同一个错误。

第四个是把所有能力都塞进 Harness。

更多工具、更长记忆和更高权限不会自动产生更强的 Agent。复杂的工具集合会增加选择错误，冗长上下文会增加理解负担，宽泛权限则扩大风险范围。

第五个是用更强模型掩盖编排问题。

状态过期、工具描述模糊、API 不稳定、权限配置错误和退出条件缺失，都不是模型升级能够稳定解决的问题。哪个层次拥有问题，就应该修改哪个层次。

七、生产环境真正需要检查什么

在将 Agent 接入生产系统前，团队至少应该回答以下问题。

• 在 Harness 层，工具是否足够专一并有清晰说明？状态能否持久保存？权限是否遵循最小化原则？运维人员能否暂停、检查和恢复任务？
• 在 Loop 层，用什么证据证明任务成功？失败后会向模型返回什么反馈？最多允许重试多少次？预算耗尽后如何处理？
• 在 Graph 层，哪些路径必须由确定性代码控制？哪些工作可以并行？哪些状态允许共享？人工审批和故障恢复位于哪里？
• 在评估层，团队能否重放真实执行轨迹、比较不同版本，并证明性能变化来自某个具体修改，而不是主观感觉？
• 在运营层，是否持续监测成本、延迟、失败率、人工介入率以及任务级成功率？

结语

过去一段时间，行业讨论的重心一直在从模型本身向模型周围的系统迁移。这不是因为模型不重要，而是因为模型能力越强，它能够触达的工具、数据和业务流程越多，外部工程结构的重要性就越高。

可靠的 Agent 系统，不是依靠模型永远不犯错，而是用确定性的工程结构承载模型的不确定输出。模型负责判断和生成，系统负责边界、证据和秩序。如果 Agent 架构没有设计清楚，那么模型越聪明，系统未必越可靠。它可能只是更擅长绕过模糊的流程，并用一段更像正确答案的文字告诉我们：任务已经完成。

参考资料

1. Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering
2. LangChain：The Anatomy of an Agent Harness
3. OpenAI：Agents SDK
4. Anthropic：Building Effective AI Agents

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：洞源实验室 裴伟伟 裴伟伟《Agent可靠性的三个层次：从Harness、Loop 到 Graph》