大多数agent系统失败不是因为模型太弱。而是因为围绕模型的系统从未被当作系统来设计。工具不可靠状态在运行之间消失agent重试却不学习任何东西工作流以无人可检查的方式分支——然后每一次失败都被归咎于模型。这是错误的诊断。一个严肃的agent背后有三个不同的工程层harness给模型一个工作场所loop给工作一个反馈循环graph给过程一条明确的路线。它们重叠它们可以相互包含但它们解决不同的问题。核心框架30秒版本·模型决定 →Harness让它行动 →Loop让它证明结果 →Graph控制接下来允许发生什么·Harness工程构建模型周围的操作环境工具、记忆、文件、权限、沙箱、路由、检查点、追踪、人工审批·Loop工程设计重复工作和反馈产出→检查→失败信号→有界重试·Graph工程让控制流显式化节点、分支、合并、并行、合法循环、状态转换、退出路径01 第一层Harness EngineeringHarness工程Harness工程构建模型周围的操作环境。工具、记忆、文件、权限、沙箱、路由、检查点、追踪和人工审批——所有这些都在这里。当任务持续时间超过一个上下文窗口时harness工作变得至关重要。一个工作数小时的编码agent不能仅依赖聊天历史。它需要持久的产物让另一个会话能够理解。一个实用的harness配置可能包括·初始化器检查工作空间·进度文件解释已完成和待完成的事项·Git提交保留工作状态·检查点在风险操作之前保存·验证工具产出清晰的证据这不是一个更好的prompt而是一个更好的工作环境。何时需要harness工程· Agent无法访问正确的功能· Agent在会话之间丢失进度· 权限过于宽泛· Agent在不同环境中表现不同· 无法暂停、检查或恢复运行· 产出的失败无人能重建02 第二层Loop Engineering循环工程每个使用工具的agent都已经有一个小的内部循环model → action → observation → model。Loop工程始于你有意识地设计围绕这一行为的循环。目标不是让agent永远重复自己而是将一次性尝试转化为一个可管理的过程。验证循环最有用的外循环最简单的验证循环是这样的BUILD构建 ↓ CHECK AGAINST EVIDENCE对照证据检查 ↓ PASS? ── yes ── STOP通过是 → 停止 │ no ↓ RETURN SPECIFIC FEEDBACK返回具体反馈 ↓ RETRY WITH A LIMIT有限重试检查可以是确定性的测试通过、schema验证、链接解析、数字核对、文件编译也可以需要评审员论证是否完整、语气是否匹配受众、证据是否支持结论、变更范围是否正确。循环的七个组成部分1.触发器启动下一次循环的条件2.目标一个可测量的状态而非持续改进3.状态下一次尝试必须知道的信息无需重放整个历史4.行动策略Agent可以更改、调用、委托或花费什么5.证据测试、引用、diff、指标、schema或人工评审6.反馈什么失败了、必须改变什么的简洁解释7.停止规则成功、最大尝试次数、预算耗尽、超时、硬错误或人工升级循环可以堆叠EVENT LOOP事件循环 └── VERIFICATION LOOP验证循环 └── AGENT LOOPAgent循环 TRACE IMPROVEMENT LOOP追踪改进循环 └── 更新 prompts、工具、策略和评分器这就是为什么loop工程大于prompt工程。Prompt定义一次模型调用期间应该发生什么。Loop定义那次调用之后系统做什么。每次重试、评分器和评审员都会增加延迟和开销——当失败的预期成本高于验证的成本时添加一个循环。03 第三层Graph Engineering图工程Graph工程问的是不同的问题。不是agent应该如何工作而是接下来允许运行什么。工作变成节点允许的转换变成边状态在图中流动。这种结构可以表示固定序列、条件分支、并行展开、合并、有界循环、恢复路径、人工中断。图工程师实际决定什么·节点边界哪些工作属于普通代码、LLM调用、专业agent还是人工评审步骤·状态schema每个节点可以读取或更新什么以及并行结果如何合并·路由条件哪些证据推动工作向前、向后、向侧面或进入升级·并发控制哪些路径可以并行共享什么状态·审批和恢复加入点、审批点和恢复路线在哪里·合法循环哪些循环是合法的它们如何终止04 三者如何在一个真实系统中协同工作想象一个研究-发布agent它产出一份事实性的行业简报。Harness提供· 浏览器和搜索工具· 源存储· 写作工作空间· 引用检查· 权限和审批规则· 检查点和追踪Graph控制路线RESEARCH研究 ↓ DRAFT起草 ↓ FACT CHECK事实检查── fail ── RESEARCH │ pass ↓ EDITORIAL REVIEW编辑评审── fail ── DRAFT │ pass ↓ HUMAN APPROVAL人工审批 ↓ PUBLISH发布Loop存在于路线内部· 研究节点可以持续搜索直到源覆盖足够· 起草节点可以反复修改直到风格评分器通过· 事实检查节点可以返回精确的不支持声明而非模糊的拒绝嵌套是重要的部分。Graph运行在harness内部loop运行在graph的某些部分内部harness提供那些loop需要的工具、状态和证据。层级重叠因为真实软件层级重叠。但当系统失败时它们给你三个不同的杠杆。05 诊断失败症状 → 起点 → 可能的修复症状从哪开始可能的修复Agent无法安全访问正确数据Harness更好的工具契约、权限、沙箱和上下文注入Agent在会话间忘记进度Harness持久状态、检查点、进度产物和压缩第一次尝试接近但不稳定Loop外部评分器、确定性测试、可操作的反馈和有界重试Agent在成功后继续或在证明前停止Loop基于证据的终端状态和预算感知停止规则专业agent必须以受控顺序运行Graph显式节点、边、路由条件和合并06 常见反模式别再犯这些错1. 把harness变成仓库。更多工具不会自动创造更好的agent。拥挤的工具集增加选择错误嘈杂的上下文增加困惑宽泛的权限增加风险。给agent最小但能完成工作的环境。2. 把编排失败归咎于模型。一个更强的模型无法可靠修复陈旧的状态、损坏的API、模糊的工具schema或缺失的退出条件。在证明模型是问题之前不要升级模型。3. Loop没有新鲜证据。每次循环都需要新鲜证据、最大尝试次数和一条明确的升级路径。4. Graph隐藏复杂性。当分支、并行和审批隐藏在临时代码中时一个强大的loop也会变得难以操作。07 生产就绪检查清单Harness· 工具是否 narrow、有文档且可观察· 状态是否在会话间持久· 权限是否最小权限· 操作员能否暂停、检查和恢复运行· 每个重要动作能否从追踪中重建Loop· 什么证据能证明成功· 失败后返回什么反馈· 允许多少次重试· 预算耗尽时发生什么· 哪里需要人工判断Graph· 哪些路径必须是确定性的· 哪里可以并行运行· 共享什么状态· 合并、审批和恢复路线在哪里· 哪些循环是合法的它们如何终止评估与运维· 团队能否重放真实追踪· 版本能否在相同任务上比较· 改进能否归因于特定变更· 成本和延迟是否被监控· 失败率是否按节点和工具可见· 人工干预是否被衡量· 任务级成功是否在生产中被衡量结语记住三者区别的最简单方式ENVIRONMENT → HARNESS环境FEEDBACK → LOOP反馈FLOW → GRAPH流程Harness工程让模型可操作。Loop工程让工作可迭代和可验证。Graph工程让复杂执行显式和可控。没有谁可以取代其他。一个完美的graph无法拯救丢失状态的agent。一个完美的harness在没有证据或停止规则的loop中仍然会浪费钱。一个强大的loop当分支、并行和审批隐藏在临时代码中时会变得难以操作。可靠的agent出现在三层被一起设计时——当每一层都有一个明确的职责时。这就是整个框架。