s前言Harness 决定模型在什么环境中工作Loop 决定它如何根据反馈持续改进Graph 决定任务接下来可以流向哪里。最简单的记忆方式是环境、反馈、流程。Agent Harness Engineering、Loop Engineering 和 Graph Engineering 经常出现在同一场讨论中。它们都围绕大模型构建都可能包含工具调用、状态管理与循环因此很容易被当成三个近义词。但当 Agent 离开演示页面开始读写文件、调用 API、联系客户或修改生产代码时这种混淆就会导致错误的架构决策。三者解决的是不同问题Harness模型凭什么完成工作Loop结果不合格后系统如何继续Graph当前状态下哪个组件可以接着运行更直观地说Harness 工作环境Loop 反馈机制Graph 流程拓扑它们相互嵌套却不能彼此替代。一、为什么现在必须区分这三层一个原始语言模型本身不能稳定完成以下工作跨会话保存项目状态访问文件、数据库和浏览器调用 Shell 与外部 API运行测试并读取结果控制权限、成本与执行时间在任务失败后恢复等待人工审批记录完整执行轨迹。这些能力并不来自模型参数而来自模型外部的工程系统。随着 Agent 开始承担长期任务一套相对清晰的结构逐渐形成Harness 提供上下文、工具、状态和权限Loop 负责执行、检查、反馈和有限重试Graph 组织多步骤、多角色和多分支流程实际系统中Graph 由 Harness 执行其中部分节点包含 LoopHarness 则持续为两者提供工具、状态和安全边界。区分三层的目的不是创造术语而是让系统出错时能够修改真正拥有问题的那一层。二、Harness Engineering为模型建设工作环境Agent Harness 是包裹在模型外部的运行系统。Agent 不只是一个模型Agent 模型 上下文 工具 状态 执行控制 权限 可观测性两个团队即使采用同一款基础模型也可能得到完全不同的结果。一方提供结构清晰的工具、稳定的工作区、最小权限和可恢复状态另一方只有模糊提示词与不稳定的 API。模型能力可能接近工作条件却完全不同。当 Agent 出现以下问题时应优先检查 Harness无法安全访问必要数据工具参数模糊频繁调用错误新会话开始后忘记进度拥有超出任务需要的权限环境变化后行为不一致任务中断后无法恢复无法追踪它执行过什么。长期编码任务尤其依赖 Harness。仅扩大上下文通常不够还需要初始化说明、进度文件、Git 历史和检查点让新的上下文知道已经完成什么、接下来要做什么。Harness Engineering 关注的不是让模型想得更聪明而是让它在稳定、受控、可恢复的环境中工作。️三、Loop Engineering设计可验证的反馈循环几乎所有能够调用工具的 Agent内部都有一个基础循环调用模型→ 选择动作→ 执行工具→ 返回结果→ 继续或结束Loop Engineering 不只是写一个 while 循环而是有意识地设计执行后的反馈机制。常见循环包括验证循环生成结果、运行测试、根据错误修复事件循环收到定时任务、Webhook 或新文件后启动改进循环分析失败调整指令或工具再运行回归测试审批循环准备方案等待人类反馈后继续恢复循环失败后根据错误类型重试、降级或升级。一个完整 Loop 至少要回答七个问题要素核心问题触发什么会启动下一轮目标什么状态才算成功状态下一轮需要保留什么权限Agent 可以修改或调用什么证据用什么证明结果正确反馈失败后返回什么信息停止何时成功、超时或交给人最重要的原则是不要围绕信心循环要围绕证据循环。Prompt 规定模型在一次调用中应该做什么Loop 则规定回答之后系统如何观察结果、生成反馈、决定继续还是停止。每轮重试都会增加成本和延迟。只有当失败成本高于验证成本时增加 Loop 才值得。好的 Loop 不是让 Agent 一直尝试而是让每一轮获得新证据并在明确边界内接近终点。四、Graph Engineering让执行路径显式可控Graph Engineering 关注的是当前节点完成后哪些组件可以继续运行图中的节点可以是普通代码函数一次模型调用专业 Agent确定性验证器人工审批步骤外部服务请求。边则表示允许发生的状态转移Graph 可以表达顺序、条件分支、并行分发、多路汇合、有限循环、人工中断和异常恢复。设计 Graph 时需要确定六件事节点边界哪些任务交给代码、模型、专业 Agent 或人类状态结构每个节点可以读取和修改什么路由条件哪些证据让任务前进、返回或升级并发关系哪些任务可以并行哪些资源不能同时修改循环出口最多重试几次什么情况必须停止持久恢复在哪些节点保存检查点中断后从哪里继续Graph 的价值是把原本隐藏在临时代码和对话中的分支、并行、审批与恢复路径变成可以检查的系统结构。Graph Engineering 管理的不是模型如何思考而是系统允许工作向哪里流动。️五、三层如何组成一个真实系统假设要构建一个“研究并发布行业简报”的 Agent。Harness 提供能力搜索和浏览工具文件工作区来源数据库凭据代理权限控制运行日志成本和超时限制人工审批接口。Graph 定义流程接收主题↓并行研究↓汇总去重↓事实验证├── 通过 → 撰写简报├── 失败 → 返回研究└── 冲突 → 人工复核↓发布审批Loop 改进节点结果研究节点可能反复检索直到获得足够来源写作节点可能生成草稿、运行事实检查、接收反馈并有限修订发布节点则等待人工批准。三层的嵌套关系可以概括为Harness 承载运行环境└── Graph 组织任务路径└── Loop 在部分节点内反复改进Harness 让系统能够工作Loop 让结果能够改进Graph 让复杂流程能够被控制。⚙️六、五种常见的昂贵错误1. 不了解工作就先画巨型 Graph先使用简单 Harness 收集真实运行轨迹识别稳定路径后再将其固化为 Graph。2. 让同一个模型既写又评优先使用确定性测试。需要模型评审时应使用独立上下文高影响操作仍需人工批准。3. 把“继续尝试”当作 Loop无限重试只是费用泄漏。每个循环都需要目标、证据、最大次数、预算和升级路径。4. 把 Harness 变成工具垃圾场工具过多会增加选择错误噪声记忆会干扰判断宽泛权限会扩大事故范围。5. 用 Graph 掩盖 Harness 缺陷流程图无法修复陈旧数据、不可靠工具和缺少权限控制的问题。Graph 只能安排路径不能替代底层运行质量。架构复杂度应该来自已经观察到的真实需求而不是来自对“高级 Agent”的想象。七、最合理的建设顺序生产系统可以按照以下顺序演进第一步建立可靠 Harness第二步为高价值失败增加 Loop第三步将稳定的复杂路径固化为 Graph优先建设 Harness解决工具、状态、权限、恢复和可观测性。当单次结果经常接近正确却需要测试和修订才能稳定交付时再增加 Loop。只有任务出现明确分支、并行工作、多个专家、人工审批和恢复路径时才值得引入 Graph。上线前至少检查工具是否职责单一、参数明确状态能否跨会话保存权限是否遵循最小化原则什么证据能够证明成功最多重试多少次哪些任务可以并行哪些资源不能并发修改人工审批位于哪里是否监控成本、延迟、失败率和人工介入率最成熟的架构不是三层都做到最复杂而是每一层只承担它真正需要解决的问题。✅结语环境、反馈、流程记住三者的最简单方式Harness Engineering建设工作环境给模型能力和边界Loop Engineering设计反馈循环给执行过程反馈和终点Graph Engineering控制执行流程给复杂任务清晰、可检查的路径它们不能互相替代。没有持久状态和安全工具再漂亮的 Graph 也无法稳定运行没有外部证据与停止规则再好的 Harness 也可能让 Agent 不断消耗预算当分支、并行和审批藏在临时代码里时再精心设计的 Loop 也会难以调试。下一次 Agent 出现故障时不要先问“是不是模型不够强”。先问三个更准确的问题它缺少正确的工作环境吗它缺少基于证据的反馈循环吗它的执行路径是否需要显式控制找到拥有问题的那一层才是 Agent 工程真正开始的地方。