Harness Engineering 16：当一个 Loop 不够用，怎样进入 Graph Engineering
单一 Loop 很适合边做边看：读取状态、采取动作、验证结果、失败后再试。但当任务需要研究、实现、测试并行推进，需要不同角色拥有不同权限，需要失败回到不同阶段时，一个大 Loop 会把所有决定藏在同一段上下文里。
Graph Engineering 的意义，是把这些隐含决定画出来并变成可执行契约。它不是“Loop 已经过时”的新口号。更准确的关系是：Loop 负责一个节点内部怎样持续收敛，Graph 负责多个节点之间怎样协作。
Prompt、Context、Harness、Loop、Graph 是一组叠加层
| 层 | 控制对象 | 核心问题 |
|---|---|---|
| Prompt | 指令 | 这一轮要模型做什么 |
| Context | 信息 | 模型做决定前应该看到什么 |
| Harness | 边界与证据 | 允许怎样做，怎样证明可靠 |
| Loop | 运行时 | 未达目标时怎样继续、何时停止 |
| Graph | 系统协作 | 多个 Loop、工具和人怎样连接 |
后一层不会替代前一层。Graph 中的每个 Agent 节点仍然有自己的 prompt、私有 context、工具、权限和内部 Loop；Harness 则贯穿所有层，规定状态、验证、安全和恢复。
Graph 的四个基本部件
Node：有责任边界的工作单元
节点可以是确定性脚本、模型调用、完整 Agent 或人工审批。每个节点必须声明：读哪些状态、写哪些字段、可以调用哪些工具、什么算完成、失败如何分类。
“研究一下并实现”不是好节点，因为它把证据收集和代码决策混在一起。“形成带引用的需求约束”和“根据冻结约束实现”才是可验证节点。
Edge：交接和失败路径
边不只是先 A 后 B，还包括并行、条件、重试、回滚和升级。例如验证失败不一定总回实现：代码错误回 implement，需求证据不足回 research，架构冲突转 human-review。
Shared State：节点之间唯一可信的公共工作台
节点不应靠复制整段聊天互相“传话”。研究结论、代码版本、测试结果和审批状态进入共享状态；每个节点从中选择最小必要字段，组装自己的私有上下文。
Routing Rules：把决定写成规则
路由规则回答下一步去哪。它应尽量读取结构化证据，而不是一句自由文本“看起来不错”。如果路由本身使用模型，也要有 schema、置信度阈值和默认安全分支。
Graph 和传统 Workflow 到底差在哪里
工作流引擎早就有 DAG、状态机、重试和检查点。Graph Engineering 并没有发明节点和边，变化主要发生在节点内部和动态路由上。
传统 workflow 节点通常是确定性函数：相同输入走相同代码。Agent graph 的节点可以理解目标、使用工具、在内部自我重试；边也可以依据模型产出的结构化判断动态选择。
因此 graph 是更一般的容器，可以同时容纳：
- 确定性节点：测试、schema 校验、覆盖率计算；
- Agent 节点：研究、实现、独立审查；
- 人工节点：架构取舍、生产批准、风险接受。
能用脚本稳定完成的步骤，不应该为了“Agent 化”改成模型节点。非确定性只应出现在需要语义判断和开放探索的位置。
一张可生产的 Maker–Checker Graph
以修复一个生产缺陷为例，共享状态可以包含：需求证据、复现步骤、变更引用、测试结果、审查结论、尝试次数和风险等级。
| 节点 | 读取 | 写入 | 内部行为 |
|---|---|---|---|
| intake | 工单、日志 | 标准化问题 | 确定性清洗 + 风险分类 |
| research | 问题、仓库 | 复现和约束 | 搜索、读取、复现 Loop |
| implement | 冻结约束 | commit、局部测试 | 编码、测试、修复 Loop |
| verify | 目标、diff | pass / fail、证据 | 新上下文独立复核 |
| approve | 风险、证据 | 批准或拒绝 | 人工高风险门控 |
| release | 已批准版本 | 部署标识 | 确定性发布与回滚准备 |
路由可以是：复现失败回 intake 补信息；局部测试失败留在 implement；独立验证发现需求误解回 research；低风险且全绿进入 release；高风险进入 approve；发布健康检查失败走 rollback，而不是重新研究。
这正是 Graph 的价值：失败发生时，系统知道退回哪一层，而不是把错误和整段历史一起交给一个大 Agent 重新猜。
私有 Context 与共享 State 必须分开
如果 verify 节点继承 implement 节点的完整推理，它仍然是在自我审查。真正独立的复核应该只读取目标、diff 和运行证据，使用新的上下文形成结论。
同时，共享状态要定义合并规则：
- 单值字段由谁拥有，其他节点能否覆盖；
- 并行研究结果是 append、deduplicate 还是 vote；
- 计数器是否原子累加；
- 旧结果如何通过版本和时间戳判定过期；
- 冲突是否自动解决，还是进入仲裁节点。
“大家都能写同一个 JSON”不是共享状态，而是并发事故的起点。
Checkpoint、Replay、Resume 才是承重墙
图画得再漂亮，如果进程中断后只能从头开始，它仍然只是一个演示。生产 Graph 要在每个有意义的状态转移后留下检查点，并保证：
- 可以用 thread / run id 找到一次执行；
- 节点输入、输出、工具调用和模型版本可追踪；
- 从检查点恢复不会重复外部副作用；
- 可以用旧状态重放新节点，比较策略变化；
- 人工审批等待数小时后仍能继续，而不是丢失上下文。
拓扑可以重画，框架也可以替换；可重放、可观测、可恢复一旦缺失，任何 Graph 都难以上生产。
单 Loop 在规模化后会暴露三种结构问题
第一是 Goodhart：系统持续优化一个可测指标，最终让指标和真实价值脱钩。比如提高工单关闭率，却通过阻止用户追问实现。
第二是向上盲区：Loop 很擅长追目标，却不会自然质疑目标是否正确。Graph 可以加入独立目标审计和业务 anchor 节点。
第三是 Loop 冲突：速度 Loop、质量 Loop、成本 Loop 各自健康，组合后却互相拉扯。Graph 要明确谁拥有目标、谁能 veto、哪些指标可变化、哪些约束必须冻结。
但 Graph 也不会自动解决这些问题。它只是迫使团队把关系写出来。
什么时候真的需要 Graph
至少满足以下五项中的三项再考虑：
- 任务能拆成独立工作单元并产生真实并行收益。
- 存在多条分支、回滚或升级路径。
- 中间状态值得持久化和恢复。
- 每个节点都有可检查的完成条件。
- 协调收益大于状态、审查和合并成本。
二十步线性流程未必需要 Graph，一个带确定性重试的 workflow 就够了；五个节点但存在并行研究、独立验证、人工审批和多级回滚，则非常适合 Graph。
编排税：并发增加，人的判断不会自动并行
启动十个 Agent 很便宜，理解十份结果、消解冲突和承担发布责任很贵。人的 review bandwidth 是串行资源，也是多 Agent 系统最常见的瓶颈。
好的 Graph 会压缩需要人判断的内容：确定性门控先过滤，独立 Checker 给出证据和差异，只有高风险、冲突和不可逆操作进入人工队列。坏的 Graph 只是把一份待审查结果变成十份。
Graph Engineering 的成熟标志不是节点多，而是每条边都有理由、每次回滚都有目标、每份共享状态都有所有者、每个人工判断都被放在真正稀缺的位置。