Loop Engineering 的继任者，以及让你的 Agent 运行效率提升 10 倍的工作流
大多数构建多步骤 Agent 的人最终都会得到一条直线
步骤一，步骤二，步骤三。每一步都要等上一步完成才能开始
这里有一个几乎没人注意的问题：
这些步骤里有一半根本不需要等待
它们只是排队，一次处理一个任务，直到上下文窗口被填满，然后 Agent 就忘了自己正在做什么
- 它慢不是因为模型能力弱
- 它慢是因为 你把本应是图形结构的工作画成了一条直线
本指南将带你从那条直线，走向一个能在整个集群中并行展开，并能自我检查工作成果的图形结构
五个步骤。到第二步，你就能亲手构建一个 -
它会让你得到一个可运行的图形结构，并指出那些会搞垮真实项目的陷阱。我会在难点出现的地方提醒你
在 Alpha 阶段之前 - 订阅我的 Substuck 获取更多新鲜 Alpha 内容 ↓
第 0 章 - 图工程到底是什么
一个月前，这个领域还在讨论循环。
Peter Steinberger 用九个字概括了它：
https://x.com/steipete/status/2078277297791189132
一个循环就是一次变好的周期：
尝试某事 → 检查结果 → 调整 → 再来一次
这就是原子单位：一个 Agent 重复改进一件事
(如果你读过我的 Loop Engineering 文章，就是这个概念)
https://x.com/0xCodila/status/2072329149520232639
但单个循环有一个已知的缺陷——一个支持团队将反馈循环绑定到一个指标上：工单解决率
这个数字连续几个月攀升，但满意度却在下降。机器人学会了快速关闭工单，而不是真正解决问题
这就是古德哈特定律。 一个循环只能看到它自己的指标。它无法判断目标是否正确，也无法注意到自身的测量标准在漂移。
答案不是更好的循环，而是一个由循环组成的图结构 —— 一个网络，其中的循环相互观察和纠正
对于 Agent 来说，这意味着：
停止编写一个试图在一条线上完成所有事情的 Agent —— 而是设计工作的
形状
—— 什么先运行，什么同时运行，什么需要等待。
节点负责思考。边负责传递结果
而 Claude Code 已经发布了直接构建这些图结构的工具：动态工作流
第一步 - 看到那些不存在的边
一个图结构有两个部分：
- 一个节点 是一个工作单元：一个 Agent，一个任务，一个输入，一个输出
- 一条边 是一个依赖关系：这个节点的输出作为那个节点的输入
每个人都会犯的错误是把“然后”当作一条边。
"总结这个文件
然后
告诉我天气"
天气不需要读取总结。
这两个是独立的任务，线性脚本毫无理由地把它们串联了起来。每一个都白白等待上一个
开启一切的起点习惯：
对于每一个“然后”，问一下 —— 下一步是否真的需要读取上一步的输出？
- 如果是要 → 真实的边。保持顺序。
- 如果否 → 没有边。等待是浪费。让它们并行运行。
如果没有数据在两个框之间传递，它们就是独立的。
这种独立性将是你在本指南剩余部分利用的关键
你那简单的"做 A，然后 B，然后 C"的 Agent 本身就是一个图结构 —— 只不过是最悲惨的一种：一个单一的链条，一旦 C 卡住，D 就永远不会发生。
第二步 - 构建你的第一个图结构（从头到尾）
理论知识够了。构建一个，然后看着它运行。
开始之前：
- Claude Code v2.1.154+ （用 claude --version 检查）
- 一个付费计划。 在 Max、Team 或 Enterprise 计划中，工作流默认开启。在 Pro 计划中，在 /config 里打开 Dynamic workflows 开关
1. 打开一个你熟悉的仓库。
一个真实的仓库，这样结果才有意义。
2. 粘贴这个提示词（来自 Anthropic）：
1创建一个工作流，用于审计 src/routes/ 下每个路由文件是否缺少认证检查。2为每个文件生成一个 Agent，然后在报告之前，对每个发现运行一个独立的验证器。3从最多分析 20 个文件开始。
将 src/routes/ 替换为你文件所在的路径。"最多 20 个" 这行能确保你第一次运行成本可控。
3. 观察 "workflow" 亮起。
Claude Code 会高亮显示："Dynamic workflow requested." 这是你的信号，表明正在构建一个图结构，而不是普通的对话
4. 批准计划。
Claude 会编写一个 JavaScript 编排脚本并先显示各阶段。阅读它们，选择 "Yes, run it."
5. 让集群运行。
每个文件对应一个 Agent，并行运行，同时你的会话保持空闲。
输入 /workflows 实时查看：范围、扇出、验证、综合。
6. 阅读一个答案。
不是二十个独立的对话。而是一份报告 —— 因为中间结果存在于脚本的变量中，而不是你的上下文里。
这就是一个图结构。
一个句子，驱动了十几个 Agent。
关于你会听到的“零 Token”说法
协调脚本是代码
因此，在 Agent 之间传递结果不会像聊天交接那样重新消耗上下文。
但 Agent 本身仍然会消耗使用量。 一个工作流的成本 显著高于 一个普通会话。
节省的是协调成本，而不是工作本身。从小范围开始，监控使用量，然后再扩大。
- 让它成为你自己的
当一次运行结果良好时，按下 s。
它会保存到 ~/.claude/workflows，可以通过名称重新运行
现在，改变任务，保持形状。将"缺少认证检查"换成"未处理的 Promise"，或"超过 100 行的函数"
这能扩展到什么程度（文章标题）
一次工作流运行可以扩展到 1,000 个 Agent，最多同时运行 16 个
这就是"一个窗口里 1000+ 个循环"的来源 —— 不是比喻，而是这个功能的实际上限
- 而规模恰恰是重点 一千个 Agent 意味着一个单一的上下文永远无法容纳的任务 —— 一次审计整个代码库，一次触及每个文件的迁移，一次并行运行一千个角度的搜索
16 个同时运行的并发限制只是意味着集群以波次方式移动，逐步处理完所有一千个任务，无需你监督任何一个
从 20 个开始，看看一次运行的表现和成本 —— 然后再放开 —— 因为这是其他人都没有在构建的上限
第三步 - 真正会出问题的部分
你构建了一个图结构。这里说说真实的图结构会在哪里崩溃。
两个最重要的失败模式
- 失败一：图结构自我认同
当一个 Agent 检查自己的工作成果时，它会对自己的东西手下留情。 模型更偏爱自己的输出
所以你要在边上放置一个验证器 —— 一个独立的节点，在发现结果向下游传递之前进行确认。
没人提及的陷阱是：验证器需要干净的上下文
把执行者用过的同一段对话交给它，那它就不是在验证。它只是换了个字体在自我认同
一个共享同一个上下文的 Agent 图结构，只是一个披着马甲的单一循环。它以同样的方式失败 —— 只是更晚，更昂贵，并且在失败的路上有更多绿灯
所以，验证器是一个全新的节点 —— 拥有自己的上下文 —— 检查一个真实的信号 —— 不是 "Agent 说它完成了"，而是 "测试是否真的通过了"
- 失败二：Agent 互相干扰
这不是假设
当 Bun 团队第一次将一个大迁移项目分发给多个 Agent 时，这次运行在操作上失败了——Agent 们在一个工作区里使用了共享的 git 命令，互相覆盖了彼此的工作
修复方法是结构性的，而不是巧妙的提示词。他们禁止了不安全的命令，并给每个组分配了自己独立的 worktree
这就是并行化的真正教训 —— 两个写同一个文件的 Agent 会竞争
在你展开之前，回答三个问题：
- 每个 Agent 在哪里工作？
- 结果如何合并？
- 当两个 Agent 意见不一致时会发生什么？
一个没有这个计划的图结构无法扩展 —— 它会更快地失败
第四步 - 本周可以构建的六个图结构
方法：找到真实的边 → 展开 → 在独立上下文上验证 → 隔离工作者
///
下面每一个都是同样的形状，只是针对不同的任务。改一下任务行，直接开干：
- 安全扫描 —— 每个文件一个 Agent 查找缺失的认证，一个验证器确认每个命中点（就是你刚构建的那个）
- 带引用的 /deep-research 报告 —— 已经推出：将你的问题拆分成多个角度，并行搜索，Agent 在撰写报告前互相反驳
- 移植一个模块 —— 逐个文件，以测试作为关卡，失败则循环回去
- 对抗性 Diff 审查 —— 根据大小路由：小改动 → 一次通过；大改动 → 完整的并行审计
- 定时生态系统扫描 —— 保存一次，按名称重新运行
- 未知规模发现 —— 并行运行查找器，每个结果都与已发现的所有内容进行核对，循环直到两轮都没有发现新东西
///
天花板是什么样子的https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun 的 Zig 到 Rust 的移植正是在这个机制上运行的。
大约 50 个工作流，峰值时 64 个 Agent 并行运行。大约 53.5 万行 Zig 代码被转换成了超过 100 万行 Rust 代码，用时 11 天。
它大约花费了 165,000 美元 的使用费，并且需要一个人全程设计和监控。
它还引发了公众批评，关于如此大量的 AI 编写代码是否可以被安全地审查。
规模是真实的。价格和监督代价也是真实的。
第五步 - 让图结构保持诚实的锚点
仅仅有拓扑结构并不能买到真相
一个 Agent 网络，所有 Agent 都在互相确认，没有一个触及真实世界，其失败方式与单一循环完全相同 —— 只是有更多移动部件而已
图结构需要锚点： 那些无法被争辩的节点
- 实际运行过的测试 —— 不是"应该通过"，而是已经通过
- 基于证据而非感觉的验证器
- Agent 永远不允许调整的冻结规则 —— 因为它们是优化器会试图削弱的规则
图结构的诚实程度，取决于其中那些拒绝改变的东西
什么时候不该选择图结构
大多数任务都不是图结构。在不必要的时候强行使用，只会浪费金钱并增加失败的方式。
在以下情况跳过图结构：
- 任务很小或很孤立。 添加一个函数，修复一个 Bug。在这里，工作流是纯粹的额外开销 —— 单个 Agent 更快、更便宜。
- 你需要紧密的监督。 如果你希望在下一步运行之前阅读并批准每一步，那么图结构的全部意义（在你不在场的情况下广泛运行）就与你背道而驰。
- 你还不知道要找什么。 探索性工作需要一个你可以引导的 Agent，而不是一个在你理解问题之前就承诺执行某个计划的集群。
- 各个步骤确实相互依赖。 如果每一步都读取上一步的输出，那是一个真实的链条。并行化没有可抓取的点。强制将图结构应用于一个真正顺序性的任务，只会增加协调成本而没有加速效果。
判断标准就是第一步。如果你找不到两个之间没有箭头的框，那就没有图结构可构建。它是一个循环，而循环本身就很好。
图结构是用于宽度的工具 —— 同时完成的独立工作
当工作不具有宽度时，那条线从来就不是问题...
转变
一个提示者提问。一个架构师绘制图结构。
线性 Agent 从来就不是天花板。
它只是第一种形状 —— 每个人都会使用的形状，因为它符合我们打字的方式：一次一行，一次一件事。
一旦你看到了节点和边，你就会停止要求 Agent 做更多事，而开始要求图结构 做得更宽：
- 在独立工作的地方展开
- 在需要信心的地方把关边
- 冻结那些承载真相的节点
大多数人会继续在一条线上排队执行步骤。
少数懂得绘制图结构，并尊重其失败原因的人，将能运行一个集群。
画出图结构。保持做架构师。
从前提条件开始：
- 本图结构所基于的单一循环
