从Demo笔记本跳到真实文件、API、客户数据和生产代码时，Agent系统最常见的失控不是模型能力不足，而是把三层完全不同的工程决策揉成了一团。Harness、Loop、Graph听起来都围着同一个模型转，都可能出现“循环”，都影响可靠性，但它们解决的是完全不同的问题。
我起初也把它们当成同义词。后来拆开LangChain、OpenAI Agents SDK和Anthropic的实际落地案例，才看清：它们分别对应环境、反馈和流程。混淆的代价是调试困难、成本失控、状态丢失和不可审计。
把模型从架构图里拿掉。剩下的一切，几乎都属于Harness。
Harness：模型之外的全部运行时机器
Harness是模型真正“能干活”的物理环境。它包括系统提示、工具定义、内存、文件系统、沙箱、模型路由、交接逻辑、中间件钩子、权限、日志和验证接口。OpenAI的Agents SDK从运行时视角描述得更直白：runner调用模型、执行工具、处理交接、携带状态，直到真正的终止条件出现。
一个合格的Harness通常覆盖五块：
- 上下文注入：指令、检索事实、会话状态、技能和任务策略
- 动作表面：API、浏览器、Shell、代码解释器、数据库、MCP工具
- 持久化：文件、检查点、会话、进度日志、Git历史、长期记忆
- 执行控制：超时、重试、预算、模型路由、子Agent生成、审批门
- 安全与可观测：权限隔离、白名单、密钥处理、人工授权、全链路追踪
两个团队用同一个基础模型，结果天差地别，往往不是模型差异，而是一个给了干净工具、稳定工作区和最小权限，另一个只给了模糊提示和不可靠的API包装。Harness解决的是“Agent有没有能力、能不能干净回来、状态会不会丢、权限会不会过大、能不能被审计”。
Loop：把单次调用变成可验证的重复过程
任何使用工具的Agent内部都有一个小循环：调用模型 → 观察结果 → 跑工具 → 把观察喂回去 → 直到最终答案。当团队有意识地在这个行为外再叠加新的循环时，Loop工程才真正开始。
一个工程化的Loop必须有明确解剖结构：
触发（用户请求、调度、失败测试、新数据或评估反馈）
目标（具体要到达的状态，而不是“继续改进”）
状态与记忆（下一轮需要知道什么，而不必重放全部历史）
动作策略（允许改什么、调什么、委托什么、花多少）
证据（测试、schema校验、引用、diff、指标或人工审查）
反馈（失败原因的紧凑可操作描述）
停止规则（成功、预算耗尽、超时、不可恢复错误或人工升级）
验证Loop用外部grader和显式通过条件包裹Agent。不要在“自信”上循环，要在证据上循环。“Agent说自己做完了”不是停止条件；“测试通过、链接可解析、schema合法且评审批准”才是。
Prompt告诉模型这一次调用该做什么，Loop规定调用之后系统要做什么：如何观察、如何反馈、是否继续、如何持久化、何时终止。代价是每次grader或重试都增加调用和延迟。Anthropic的建议依然成立：优先用最简单能工作的架构，只有当性能收益明显高于验证成本时，才叠加循环。
Graph：把控制流变成可检查的显式拓扑
Graph问的是另一个问题：下一步允许哪个组件运行。节点代表步骤，边代表允许的转移。边可以表达顺序、条件分支、并行扇出、汇合、循环和人工中断。状态在图上流动，拓扑本身就能被检查。
LangGraph把这层做成了面向长运行、有状态Agent的底层编排基础设施，强调持久执行、状态和人机回路。Microsoft AutoGen则更直接：当你需要精确控制Agent顺序、不同结果走不同下一步、确定性分支或带循环的复杂多步过程时，就用图。
Graph工程师真正决定的是：
节点边界（哪些工作该放确定性函数、LLM调用、专家Agent或人工审查）
状态schema（每个节点可读/可写什么，并行更新如何合并）
路由条件（什么证据让工作前进、后退、旁路或升级）
并发（什么可并行、什么必须汇合、共享资源如何协调）
循环与退出（重试在哪里合法、允许几次、如何保证安全）
持久性（检查点在哪里、中断后如何恢复）
这里的图是工作流控制图，不是知识图谱。它让Agent、技能和关系变成可检查的组合系统。
三层如何真正嵌套在一起
以一个负责产出行业简报的研究-发布Agent为例：最外层是Harness提供工具、状态和评估器；中间是Graph定义研究→验证→写作→审批的分支与并行；内部再嵌套验证Loop和事件驱动Loop。图跑在Harness里，Loop活在图里，Harness给Loop提供它需要的一切。
选择哪一层，取决于失败诊断：
- 能力缺失、状态丢失、权限过大、无法审计 → 先修Harness
- 没有证据、无限重试、成本泄漏 → 先修Loop
- 分支混乱、无法并行、恢复路径缺失 → 先修Graph
常见的昂贵错误几乎都来自层间错位：还没观察真实轨迹就先画几十个节点；让同一个模型既写又评且没有隔离；用“继续试”当Loop规格；把Harness当成工具和记忆的垃圾场；把编排失败怪到模型头上。
生产就绪时只需要问三组问题：
Harness：工具是否窄且可观测？状态是否持久？权限是否最小？操作员能否暂停、检查、恢复？
Loop：什么证据证明成功？失败反馈是什么？最多重试几次？预算耗尽后怎么办？
Graph：哪些路径必须确定性？哪里可并行？共享状态是什么？人工门和恢复路由在哪里？
Harness让模型真正能操作，Loop让过程可迭代、可验证、可恢复，Graph让复杂执行路径显式可控。三者互不替代。再漂亮的图，如果Harness丢了状态，也跑不起来；再好的Harness，如果没有证据和停止规则，只会烧钱；再精巧的Loop，如果分支和审批埋在临时代码里，也难以运维。
当这三层被一起设计、并且团队清楚每一层该解决什么问题时，可靠的Agent系统才会真正出现。
你当前的Agent系统里，哪一层是最先失控的？
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
