DeepSeek Harness 架构拆解（二）：概念地图

一场对不上频道的讨论聊 Agent 架构时这几个词总是同时出现ReAct、Agent Loop、Harness、Loop Engineering、Graph Engineering大多数人会下意识地把它们排成一个从小到大的同心圆ReAct 最里面外面套 Agent Loop再外面套 Harness最外面是 Loop Engineering。这个排法是错的。而且错得很隐蔽——它看起来很整齐但会让两个人在讨论架构时一直对不上频道。真正的原因是这些词根本不在同一个分类轴上。它们分别是一个模式、一个程序、一个系统、两个工程方法。你没法把菜谱、厨师、餐厅、管理方法排成大小顺序——它们压根不是同类东西。先看这张表概念它是什么类型一句话ReAct模式推理 → 行动 → 观察再根据观察继续推理Agent Loop程序真正去调模型、执行工具、回填结果、管生命周期的那段代码Harness系统包含 Agent Loop再加上模型、工具、状态、权限、沙箱、存储、界面Loop Engineering工程方法怎么把一个循环设计得可靠触发、目标、验证、重试、预算、停止Graph Engineering工程方法怎么把多个工作单元连成图节点、边、共享状态看清类型这一列混乱就消失了大半。用一家餐厅讲清楚上一篇用公司理解 Harness 的部件这一篇换个更贴切的比喻——餐厅ReAct 菜谱 做这道菜的思路先尝味道再决定加什么 Agent Loop 厨师 按菜谱真正动手的那个人 Harness 整个餐厅 厨房、仓库、门禁、订单系统、前台缺一不可 Loop Eng. 厨师的工作规程 做失败了重做几次谁来验菜超时怎么办 Graph Eng. 后厨的流水线设计 配菜 → 炒制 → 摆盘 → 质检谁接谁失败退回哪一步菜谱比厨师小吗—— 这个问题本身就不成立。它们不是一个维度的东西。ReAct一种工作节奏经典的 ReAct 长这样想得先看看登录代码 做read(login.ts) 看文件里 Token 没有设过期时间 想需要改一下再测 做edit(login.ts) 看改好了 做test 看测试通过 答问题已修复有个容易误会的点现代模型不需要真的输出想/做/看这些标签。在 DeepSeek Harness 里它表现为模型请求 → 结构化的 tool-call → 系统执行 → tool-result → 新的模型请求所以准确的说法是ReAct 风格——描述的是行为结构不代表系统里实现了一套独立的 ReAct 协议层。Agent Loop把节奏跑起来的那段程序它回答的是一个很具体的问题谁负责真正调用模型、收集工具调用、执行工具、决定要不要再问一次模型除了这条主线它还管待办队列、轮次和步骤、流式输出、工具并行与结果顺序、取消和错误收敛、事件边界。DeepSeek Harness 里这个程序的类名就叫ReactLoopAgent——名字本身就说明了它和 ReAct 的关系它是 ReAct 风格的一个实现不是 ReAct 的子模块。Harness让循环能真实、安全、可恢复地跑Harness 回答的是另一个问题要让这个循环在真实世界里跑起来还缺什么缺的东西相当多模型适配器、工具注册表、提示词组装、会话日志、持久化、审批与沙箱、上下文压缩、子 Agent 与工作流、各种入口网页 / 终端 / SDK。厨师会做菜 ≠ 你有一家餐厅。还得有厨房、进货、门禁、订单和前台。唯一严格的包含关系这些概念之间只有一条是严格的软件结构关系Harness ──包含──► Agent Loop一个插件 Agent Loop ──实现──► ReAct 风格 ← 这是采用不是包含 Loop / Graph Engineering ┄┄分析和设计┄┄► 上面这些 不是代码里的模块三条线三种关系别混包含Harness 里真的有 Agent Loop 这个插件可以在插件清单里找到实现Agent Loop 采用了 ReAct 这种行为模式但 ReAct 不是一个能被卸载的服务分析Loop / Graph Engineering 是你用来设计和评价这套系统的思维工具代码里没有同名的东西最后一条特别重要因为它最容易被当成系统里的一层Loop Engineering 和 Graph Engineering 不是运行时抽象是行业讨论和教学用的术语。你在源码里搜不到LoopEngineering这个类因为它本来就不该在那儿。Loop Engineering到底在问什么既然它不是代码那它是什么它是一组你必须回答的设计问题问题在问什么Trigger什么事件触发一次工作Goal目标是什么、怎么保持不跑偏Gate谁来判断真的完成了State跨轮次的进度存在哪Retry失败了退回到哪一步Budget最多几轮、多少 token、多少钱、多长时间Stop什么时候强制停下、或者交给人一句话概括两者分工Agent Loop 解决这一轮里模型下一步做什么。Loop Engineering 解决这一轮结束后要不要再来一轮、谁来验收。用修 Bug 举例最清楚Agent Loop 负责让同一个 Agent 读文件、改代码、跑测试Loop Engineering 负责规定测试必须由独立程序判定、失败最多重启 5 轮、超过 30 分钟就停下报告后面那句是部署者的流程设计不是循环本身自带的保证。这里有个特别值得注意的现实DeepSeek Harness 提供了一些搭外循环的积木连续轮次、子 Agent 轮次、工作流编排、定时触发但这些积木不自动等于一套好的 Loop Engineering。比如有的多轮工具是否完成主要靠执行者自己上报缺少独立评估器和完整的费用/时间预算。积木是系统给的怎么搭是你的事。这也是为什么它叫工程方法而不是功能。Graph Engineering多个单元怎么连如果说 Loop 关注一个单元怎么反复改进Graph 关注的是多个单元怎么连。它只有三个概念概念是什么餐厅里对应Node节点干活的单元配菜工、炒锅、质检员Edge边干完之后去哪配好菜送去炒炒糊了退回重来State状态大家共享的档案订单、当前进度、返工次数、预算关键一点节点不一定是 Agent。它可以是普通函数、自动化测试甚至是人工审批这一步。需求分析 ─┬─► 前端 Agent ─┐ └─► 后端 Agent ─┴─► 合并 ─► 自动测试 ─┬─ 通过 ─► 人工审批 ─► 发布 ▲ │ └── 失败退回 ─┘什么时候用 Loop什么时候画 Graph一个很实用的判断标准情况选什么为什么下一步取决于探索结果单个 Agent Loop比如查一个未知的 Bug——读完才知道下一步查哪画不出图流程能稳定画在白板上Graph比如需求 → 两路实现 → 合并 → 测试 → 审批路线固定图更可控而且大多数真实系统是混着来的外层用 Graph 规定节点之间的路线每个复杂节点内部跑一个 Loop。顺便破一个迷思Graph 不一定比自由发挥的 Agent更先进。稳定、可审计的流程适合画成显式图高度探索性的任务反而应该让 Agent 自己决定下一步。顺带澄清DAG 和那个DCGDAG Directed Acyclic Graph有向无环图箭头有方向且沿箭头走不回原点。一个常见误解是DAG 只能是一条直线——错的DAG 完全可以分支和并行需求 ─┬─► 前端 ─┐ └─► 后端 ─┴─► 合并 ─► 测试 ─► 发布这依然是 DAG。无环限制的是回路不是分支。但 Agent 的工作经常需要回路编码 ──► 测试 ▲ │ └── 失败 ─┘ 通过 ──► 发布这就是一张有环的有向图。这里有个术语上的坑值得提醒DCG不是有向有环图的通用标准缩写。它在不同领域可能指别的东西。想表达图里允许有环最稳妥的说法就是直说允许环的有向图别用未定义的缩写。还有一点有环 ≠ 一定死循环。工程上必须补退出规则——测试通过、达到最大尝试次数、超时、预算耗尽、用户取消、或者转人工。这又绕回 Loop Engineering 了。五个常见误解误解实际ReAct 就是 React.js毫无关系只是名字像Agent Loop 就是整个 HarnessAgent Loop 只是 Harness 里的一个插件Loop / Graph Engineering 是系统里的一层是分析设计方法代码里没有同名模块Graph Engineering 是 Loop Engineering 的下一代不是替代关系关注轴不同可以组合图一定是 DAGAgent 的图经常包含受限的重试环下一篇《DeepSeek Harness 架构拆解三Agent Loop》会钻进那个厨师内部Turn 和 Step 到底怎么划分、待办队列怎么工作、历史是怎么每次重新拼出来的、工具并行执行时结果怎么保证不乱序。