Agent 图工程：跑得远不等于跑得对

来源：X @wohsj110

本月，作者在 Orca 中将一个大需求拆分为一百多个任务，交给一批 agent 执行。一个典型案例是：新功能开工前被拆成 12 个任务，依赖关系已标好；执行到第五个任务时，agent-device 的设备端验收未通过——在真机运行后确认，runner 和 scheduler 不支持这个新类型。诊断结果指向的不是实现，而是计划里的一条前提：「后端和 Runner 已就绪」不成立，而任务 010、011 都依赖该前提。随后 orchestrator 自动补充了一个任务 013（后端服务实现，P0），并将 010、011 的依赖改为等待它；该任务的备注是「task-005 真机暴露：后端/Runner『已就绪』是假前提」^[0]。

整个过程作者未干预：agent-device 提供了明确证据，orchestrator 依据证据判断前提不成立，补充节点、重新连接依赖，并继续派发。它能够做出这个判断，是因为该验收是作者预先设计并允许其拦截下游任务的 ^[0]。要理解这套系统，需先了解两个工具。Orca 是 Stably AI 的开源 ADE（Agent 开发环境），它不替代 Git、也不是模型，而是将开发者原本就在用的 Claude Code、Codex、OpenCode 等 CLI agent 并行运行在同一个桌面 IDE 中，每个任务拥有自己的 Git worktree、agent 终端和浏览器环境 ^[1,3,4]。agent-device 是 Callstack 开源的移动设备控制 CLI，采用 MIT 协议，让 agent 直接操作 iOS、Android 等设备 ^[11,15,16]。

地图不是疆域：unknowns 藏在计划里

「地图不是疆域」是一句常见的说法：现实复杂多变，人们倾向于将其简化；如果将地图当作疆域，就会误以为掌握了所有答案，并用静态规则应对不断变化的图景 ^[21]。而地形变化往往快于地图，好的地图依靠探索者的反馈回路不断修正 ^[21]。作者将这一概念引入 agent 系统：提供给 agent 的 prompt、skill、spec 和 case 代码都属于地图，真实的代码库、线上约束和未成文的规则属于疆域，两者之间的差异称为 unknowns，最困难的是 unknown unknowns——你甚至不知道自己遗漏了什么 ^[0]。

时间线可证实该词的流行。7 月 7 日 @trq212 在《A Field Guide to Fable: Finding Your Unknowns》中讲述了这个说法 ^[0]；7 月 18 日 @steipete 发表了一句调侃：「are we still talking loops or did we shift to graphs yet」^[0]。该说法随后被 Carlos E. Perez 等人扩展为网络理论式论述，7 月中旬在 X 上获得关注 ^[25]；同一天，一篇综合文章提出了「graph engineering」这一说法——但其来源并不确定，且与更早的知识图谱用法重名 ^[27,41]。八天内，时间线上出现了一个新的工种名称 ^[0]。

开头所述事件就是该词的标准实例：「后端已就绪」这个条件写在计划中，看起来与其他条件无异；它不报错，也没有专门节点验证它，只是被默认为真，下面挂了一串任务 ^[0]。这是本文要解决的问题。

图是长出来的，不是画出来的

图工程所讨论的是：将多 agent 系统作为显式图进行设计与运营——节点可以是 agent，也可能是确定性函数、router、join、工具或人工检查点；边表示通信与委派；共享状态沿边流动，从而使一组 agent 构成系统，而非相互遗忘的群聊 ^{[39,40,41,44]}。单循环只是最简单的图：一个节点、一条指向自己的边 ^[39,41]。这条谱系从 prompt engineering 走到 multi-prompt，再到 loop engineering——2026 年 6 月由 Addy Osmani 命名，plan→act→observe→retry——最后到 graph engineering ^[26,29]。图的价值在于结构：拆分为两个节点，就能为不同节点配置不同工具，为困难步骤配置更强的模型，为廉价步骤配置较便宜的模型，这是单循环无法做到的 ^[29]。

作者的实际做法是让图自行生长。开始工作时只写两个任务：第一个任务使用 wayfinder skill 探路，不写代码，仅摸清边界——相关代码所在位置、未写入文档的约束、哪些改动会影响其他模块，最后交出一份「我原先不知道的东西」清单；第二个任务才进行第一块实现 ^[0]。worker 完成后将 worker_done 和结果交回 orchestrator，后者据此补充任务、修改依赖，或回答 worker 的 ask；多数情况下是创建两三个新任务，deps 指向刚完成的任务 ^[0]。如此逐轮添加，直到没有新任务可加 ^[0]。

运行数据印证了这一机制：一个月 570 个任务，跨度 31 天、实际动手 15 天；其中带依赖关系、成规模的编排只有 4 组，共 76 个任务（41、15、13、7）^[0]。最大的一组包含 41 个任务，开工时只有 2 个——首个任务创建 11 秒后即被派出 ^[0]。按创建时间归批，41 个任务分布在 33 个创建时间点：头一分钟创建了 2 个，其余 39 个分布在另外 31 个时间点；名称中含 recovery、reverify、correction 的任务，都是前一任务实际运行并暴露问题后才出现的 ^[0]。作者提醒，任务数不能直接等同于工作量，其中很大一部分是试错留下的 ^[0]。相比之下，alex_frantic 的路径「先画 graph，再让 Codex 生成并运行脚本，没有第三步」仅在疆域已知时成立——标准 SOP 的形状运行一百遍不变，编译成脚本即为最优解；写新需求则不同，开工那一刻无法回答：该考虑的点是否遗漏？改动是否会牵动未预料的模块？上游接口是否存在未写入文档的约束？^[0]

作者直接引用了四条常见的做法：先判断任务是否需要 graph（ericosiu 认为 rails/motor 最合适）、砍掉不传数据的边、把执行和复核分开、按节点难度选模型 ^[0]。关于成本的说法很直白：「people discover this on the invoice」——你不会在设计时意识到一次宽并行按顶配计费，而是在账单上意识到 ^[0]。这四条做好，能得到一张运行得较远的图；作者遇到的问题都发生在这之后 ^[0]。

跑得对：把前提验成事实

假成功的根源在于未经验证的前提：「后端和 Runner 已就绪」不报错，被默认视为真，每一步执行和报告都是真实的，但整张图却建立在虚浮的基础上 ^[0]。graph 无法解决这个问题——它只规定先后顺序，不判断前提真伪 ^[0]。增加 verifier 也不一定足够：humzaakhalid 列出的 adversarial、多视角、judge panel 三种模式，评判的仍然是模型输出 ^[0]。对模型互评的怀疑有研究支持：多模型辩论常坍缩为多数意见，甚至可被对抗性合谋利用 ^[32]。Carlos Perez 说得更直接：一堆 agent 互相检查，可能产出「组织得极其整齐的废话」——二十个同模型 agent 阅读同一份错误上下文，能够工业规模地相互认同；他的解决方法是，证据必须来自 agent 系统之外：真实运行过的测试、真实到账的款项 ^[30]。

作者将「anchor」落实为三项具体措施，这个顺序是根据实际教训排定的：第一项是先将前提验证为事实——该功能所依赖的后端、Runner 和配置，需要有一条真实运行过的证据表明其存在，而非「计划中写了它在」；如果对不上就立即停止，后续各项都无需执行，开头那个 013 就是这样补充进来的 ^[0]。通过这一项后再看三类证据：单元测试覆盖数据和方法层；agent-device 覆盖设备端的真实行为；系统日志补充时序和权限信息，但不要绝对化——缺少某一行可能意味着确实未发生，也可能意味着埋点失效；只有在日志链路本身正常的前提下，它才能作为证据 ^[0]。

agent-device 能作为这类证据，因为它将设备控制转换为 agent 可读的形式：紧凑的结构化 UI 快照、refs 实时探索、selectors 持久化回放，快照体积控制在 LLM 上下文可容纳的范围内 ^[11,18]；它还能用 UI 状态、截图、视频、日志、网络活动、trace 和性能数据来验证结果 ^[16]。它使 agent 能够接触真实环境，但「什么算过」需由外部决定——这正是作者后文强调的分工 ^[0]。

总结起来只有一句话：这一步未通过，依赖它的任务就不予派发 ^[0]。关键在于「不派发」：作者最初只是让未通过项写入报告，由人看到后决定，结果头几次还会查看，后来警告越积越多，看到红字的第一反应变成「先让它跑着，回头再说」，那条警告实际上就失效了；拦截下游，不留下这种余地 ^[0]。一个完整例子：agent-device 的验收在 03:32 和 03:39 连续失败三次，前两次失败之间没有新增任务；诊断先后触发 P0 恢复实现和交互确认修正——两者在开工时都不存在，直到 04:41 才最终放行 ^[0]。

还有一种失败不会主动报错：遗漏而未察觉。某个节点列了八项检查，完成了六项，遗漏两项，然后交回一份「完成」报告——它并非欺骗，而是那两项从未进入其视野，且门禁未逐项核验，遗漏不会留下痕迹 ^[0]。因此作者将可单独验收的步骤拆分为独立节点，每遗漏一项就有一项显示红色；任务粒度在十几分钟这个尺度，是他目前的经验值，而非从单个案例推导出的阈值 ^[0]。

拐得回来：运行中谁有权改图

有了 eval，就能知道哪里不对；但下游是否停止、是否添加节点、由谁决策，这是第三件事 ^[0]。作者阅读了这些讨论中分析最详细的几篇文章——Hamza Khalid 的 Graph Engineering、Carlos Perez 的 From Loop Engineering to Graph Engineering、Mike Piccolo 的 Loops, graphs, and the layer that matters、LangChain 的 3 Years of Graph Engineering with LangGraph——没有一篇说明运行中谁能修改这张图 ^[0]。有人讨论 autonomy boundaries 和 approvals，但那是在图中预先定义好的审批节点，而非运行中谁有权增删任务或修改依赖 ^[0]。编排体系中最接近的原则是：orchestrator 拥有拓扑和运行时图状态 ^[27]。IntuitMachine 的文章讲出了道理，尽管它讨论的是控制回路：循环将变量推向参考值，但循环内部无人能质疑参考值是否正确；循环越努力，错误目标反而越被彻底实现 ^[0]。

作者的解决方案是将放行权从执行者手中剥离。图中有三道 gate 本月均在运行，它们的共同点是放行权均不在执行任务的 agent 手中 ^[0]。一个典型场景：提案方希望在项目仓库中新建一份验收流程，orchestrator 未同意，要求其修改公共流程库；提案推荐 A，最终裁决为 A′，前后历时 6 分钟——提案方只提交了局部方案，而裁决端掌握跨仓库的约束 ^[0]。第三道 gate 中，worker 完成任务后想提交，必须先列出三轮独立复核的结果，逐条说明——「规范轴通过、架构对抗通过、上一轮两个 P1 已修并被 follow-up 复审确认」——然后才是那句「请放行提交」^[0]。

这套机制分三层：worker 拿不准时询问 orchestrator；orchestrator 无法裁决的问题，才上报到人 ^[0]。

失败之后：诊断、熔断与整段作废

失败后首要任务是弄清失败原因，而非原地重试——一次失败所提供的信息远多于一次成功，它指示地图与疆域在哪一处不符；这是付出代价得到的，直接重跑等于丢弃它 ^[0]。真正的技巧在于后续：如何根据这份反馈进行调整 ^[0]。

作者为验收链路设置了熔断机制：诊断、修复、再次 verify 一次，使用同一套机器证据；通过则继续，未通过则再试一轮，三轮仍不过即停止并上报 ^[0]。这与 Orca 自带的 dispatch 熔断不同——后者统计的是同一任务连续派发失败三次；该熔断本月并未实际触发，因此所述的是流程设定，而非已发生的结果 ^[0]。达到三轮上限后不再自动重试，三轮的诊断结果一并交由 orchestrator 裁定：多数情况下是局部调整——实现有问题就回去改实现，判断标准有误就修正判断标准 ^[0]。有一种情况需要整体推翻：前置任务本身有误，后续众多任务建立在虚假前提上，修改依赖没有意义，应整体作废，并按新的理解重新建图 ^[0]。保留 superseded 记录也是为了如此：一次推翻可能牵连一串任务，事后必须能看出它们为何同时消失，否则过两周回头，只会觉得这里莫名断了一截 ^[0]。开头 agent-device 连续三次挂掉就是例子：如果只「再跑一遍」，它会挂第四次——问题不在那次执行，而在于此前缺少一个恢复步骤；那三次失败换来的答案是「缺了什么」^[0]。

难点不在于图能否修改，而在于如何知道需要修改。作者依据以下几点形成判断：某个前提从未被验证，直到 agent-device 在实践中暴露，说明验收链路存在漏洞，应在 graph 中补充一道前置 gate；同一个 gate 连续失败时，不应盲目重试，诊断可能指向实现、环境、判断标准或前置步骤，只有证据指向上游时才修改 graph；若诊断指向上游，则说明依赖连接有误，需要重新接线；spec 中的禁止项被触发，说明该路径此前已失败过，不应再次尝试 ^[0]。agent-device 的结果、gate 判据和禁止项命中均属机器证据；但是否修改 graph、修改哪条边，仍由 orchestrator 依据这些证据作出裁定 ^[0]。

三者结合：反脆弱的闭环

三者的结合方式如下：graph 使任务持续运行，eval 指出问题所在，权限决定由谁修改 ^[0]。eval 的实际作用比表面更靠前——「需要修改」这一判断正是由它产生；缺少它，能够修改 graph 反而会让错误被更快地传播 ^[0]。013 事件带来的不止一个补充任务：自此以后，「依赖的东西必须先验证为事实，不能仅凭计划中的文字」成为作者所有编排的第一道 gate，即此后每单都适用的规则 ^[0]。目前能证明的仅限于此：规则确实已沉淀，但同类问题日后是否真的减少，作者尚无跨月数据可以证明 ^[0]。

eval 最容易被低估。图能自行生长、任务能自动补充，看起来像系统在自我修复 ^[0]。但 agent-device 本身不是 eval——它与 computer-use 属于同类，仅让 agent 接触真实环境，不知道什么算通过、什么该拦截 ^[0]。真正构成 eval 的是以下三项：代码架构本身必须可验证（有稳定的锚点可供断言，而非依赖截图猜测）；任务约束（这一步允许做什么、禁止什么、以什么为证据）；判据与阻塞范围（什么算通过，未通过时拦截哪些下游）^[0]。这三项均需逐条由人编写；作者本月在这些事项上的投入，多于花在编排上的时间 ^[0]。

关于边界再做说明：PawelHuryn 主张这类流程最好做成带 evals 和 guardrails 的状态机。作者并不反对——验收、装包、取证等稳定步骤，作者同样将其写死，不修改；分歧在于，本单尚未确定的任务和依赖，是否需要保留灵活性 ^[0]。

本月得出的结论只有一条：graph 能让 agent 运行更远，并行时也能更快，但跑得远不等于跑得对；要使长任务站得住脚，还需要 eval 指出问题所在，并有明确权限决定谁能修改 ^[0]。在工具方面，作者推荐 Orca：其一，编排本身足够灵活，运行中可增删任务、修改依赖、阻塞提问，裁决也会写回记录；其二，worktree 隔离，每个 worker 拥有独立工作区，可并行修改代码 ^[0]。