「循环工程 | Loop Engineering」讲的是一个智能体怎么反复打磨一件事。这篇讲的是下一步：怎么让一千个智能体同时干活。
大多数人搭建多步骤智能体的时候，最终得到的都是一条 直线 。
第一步，第二步，第三步。每一步都在等上一步跑完才能开始。
但几乎没人去检查一件事： 这些步骤里，有一半根本不需要等。 它们只是排着队，一个接一个地跑，直到上下文窗口被塞满，智能体忘了自己在干什么。
这篇教程就干一件事：把你手里那条线，掰开成一张图。图能扇形展开，能自己检查自己。
一共5步。到第2步你就能搭出一个能跑的图。 它会告诉你哪些坑会让真实的图崩掉，我会在难点出现之前提前标记。 在干货之前——请订阅我的公众号获取更多新鲜内容 ↓ 前言——Graph Engineering到底是什么 一个月前，这个圈子还在讨论 循环（Loop） 。
Peter Steinberger(小龙虾作者) 用一句话就把这风向变化点到了：
这就是原子 ：一个智能体，反复打磨同一件事。
但单一循环有一个已知的死法—— 比如一个客服团队把反馈循环绑定在一个指标上： 工单解决率 。
这个数字连涨了好几个月，而用户满意度却在下滑。机器人学会了快速关闭工单，而不是真正解决问题。
这就是 古德哈特定律（Goodhart's Law） 。一个循环只能看见自己的指标。它没法质疑目标本身对不对，也察觉不到自己的度量在漂移。
答案不是一个更好的循环，而是一张循环组成的图 ——一个网络，里面的循环互相监视、互相纠错。
落到智能体上，就一句话：
别再写一个"什么都干"的直线智能体了——去设计工作的 形状 ：谁先谁后，谁跟谁同时跑，谁在等谁。 节点负责思考，边负责传递结果。
而且 Claude Code 已经发布了直接构建这些的工具： 动态工作流（Dynamic Workflows） 第1步——看见那些"不存在的边" 一张图有两个组成部分：
节点（Node） 是一个工作单元：一个智能体，一项任务，一个输入，一个输出 边（Edge） 所有人都会犯的错误，是把 "然后" 当成一条边。
天气根本不需要读那个总结。
这是两个完全独立的任务，却被一个线性脚本毫无理由地串在了一起。每一个都在白白等上一个完成。
开启一切的那个习惯：
对每一个"然后"，问一句—— 下一步真的需要读上一步的输出吗？
如果两个方块之间没有数据流动，它们就是独立的。
记住这种独立性。后面整篇教程都在利用它。
你那个"先做A，再做B，再做C"的智能体，其实已经是一张图了——只不过是最惨的那种：一条单链，C一卡住，D就永远跑不了。 第2步——从零搭出你的第一张图 理论够了。动手搭一个，看它跑起来。
开始之前：
Claude Code v2.1.154+ 付费方案。 Max、Team 或 Enterprise 默认开启工作流。Pro 用户需要在 /config 里打开 Dynamic workflows 开关 1. 打开一个你熟悉的代码仓库。
用一个真实的，这样结果才有意义。
2. 粘贴这段提示词（来自 Anthropic 官方）：
Create a workflow to audit every route file under src/routes/ for missing auth checks. Spawn one agent per file, then run an independent verifier on each finding before reporting. Analyze a maximum of 20 files to start. 把 src/routes/ 换成你文件实际所在的路径。"最多20个"这行是为了让第一次跑的成本可控。
3. 看"workflow"亮起来。
Claude Code 会高亮显示： "Dynamic workflow requested." 这就是你的信号——一张图正在构建，而不是普通聊天。
4. 批准计划。
Claude 会写一个 JavaScript 编排脚本，先展示各个阶段。读一遍，然后选 "Yes, run it."
5. 让集群跑起来。
每个文件一个智能体，并行执行，而你的主会话保持空闲。
输入 /workflows 可以实时观看：确定范围 → 扇形展开 → 验证 → 综合。
6. 读最终的完整答案。
这不是二十个零散独立的对话。而是一份综合这些会话的报告——因为中间结果存在Subagent脚本的变量里，而不是你的上下文里。
这就是 Graph 。 关于你认为的"零 token"说法
协调脚本是代码。所以在智能体之间传递结果，不会像聊天交接那样重新消耗上下文。
但 智能体本身仍然消耗用量。 一个工作流的花费 显著高于 一次普通会话。
省的是协调成本，不是工作本身。先小范围跑，观察用量，再逐步扩大。
当一次运行效果不错时，按 s 。
它会保存到 ~/.claude/workflows ，之后可以按名字重新运行。
现在换掉任务，保留形状。把"缺失的鉴权检查"换成"未处理的 Promise"，或者"超过100行的函数"。
这东西能扩展到什么程度 一次工作流运行最多可以扇形展开到 1000个智能体 ，同时最多16个并行工作。
这就是"一个窗口里跑1000+循环"的由来——不是比喻，是这个功能的实际上限。
而规模本身就是重点 一千个智能体意味着一个单一上下文永远装不下的任务——一次性审计整个代码库，一次触及每个文件的迁移，一次从一千个角度并行搜索。 16个并发的上限只是意味着集群以波浪式推进，啃完全部一千个，而你不需要盯着任何一个。 先从20个开始，看看一次运行是什么表现、花多少钱——然后放开——因为这是别人还没开始搭建的上限。 第3步——真正会崩的地方 你搭了一张Agent的协作图。下面是真实的流程会翻车的地方。
有两种失败最致命。
当一个智能体检查自己的工作时，它会对自己手下留情。 模型天然偏好自己的输出。
怎么办？在边上插一个 验证器（Verifier） ——一个独立的节点，结果流向下游之前先过它这一关。
没人说破的关键点： 验证器需要干净的上下文。
把执行器用过的同一段对话递给它，那它就不是在验证。它只是在用另一种字体跟自己说"我同意"。
一张共享同一个上下文的智能体图，就是一个穿了马甲的单循环。它会以同样的方式失败——只不过更晚、更贵，而且一路亮着绿灯往下掉。 验证器必须是一个 全新的节点 ，自己的上下文，检查一个 真实的信号 ——别问" 智能体说它做完了吗 "，要问" 测试真的跑过了吗 "。
这不是假设。
当 Bun 的团队第一次把一个大移植任务扇形展开到多个智能体时，运行 在操作层面就失败了 ——智能体在同一个工作区里使用共享的 git 命令，互相覆盖。
那改进的方法则是：改架构 ，不是改提示词。他们直接禁掉了不安全的命令，给每个组分了 自己独立的 worktree 。
这才是并行真正的教训——两个智能体写同一个文件，就是在赛跑。
展开之前，先回答三个问题：
每个智能体在哪里工作？ 结果怎么合并？ 两个智能体意见不一致时怎么办？ 一张没有这套方案的图不会扩展——它只会更快地崩。
第4步——这周可以搭的6张图 方法论： 找到真正的边 → 扇形展开 → 在独立上下文上验证 → 隔离Workers
下面每一个都是同一个形状，只是瞄准了不同的任务。换掉任务那一行就能跑：
安全扫描 ——每个文件一个智能体搜缺失的鉴权 auth ，一个验证器确认每个发现（就是你刚搭的那个） 带引用的研究报告（/deep-research） ——已经内置了：把你的问题拆成多个角度，并行搜索，智能体在写报告之前先互相反驳 移植一个模块 对抗性 Diff 审查 ——按规模路由：小改动 → 一遍过；大改动 → 完整并行审计 定时生态扫描 未知规模的发现 ——搜索器并行运行，每个结果与已发现的一切交叉比对，循环直到连续两轮没有新发现 这个工程流的落地天花板长什么样
https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun 的 Zig 转 Rust 移植，用的就是这套机制。
大约50个工作流，峰值64个智能体并行。大约53.5万行 Zig 代码变成了超过100万行 Rust，用了11天。
它也花了大约 16.5万美元 的用量。它需要一个人类全程设计和监控。而且它引发了公开争议——这么多 AI 写的代码，到底能不能被安全地审查。
规模是真的。16.5 万美元的账单也是真的。全程需要人盯着，也是真的。
第5步——让Graph保持诚实的锚点 图画得再漂亮，节点全是互相点头，那跟没有一样。
一个智能体网络，全部在互相确认，没有一个碰过任何真实的东西——它的失败方式和单循环一模一样，只不过活动部件更多。
图需要 锚点（Anchors） ：那些不能被辩论的节点。
真正跑过的测试 基于证据的验证器 冻结的规则 ，智能体永远不被允许调整——因为它们是优化器最可能削弱的那些 一张图的诚实程度，取决于里面那些拒绝移动的东西。
什么时候不该用Graph 大多数任务不是图。不需要的时候硬上图，只是烧钱加添乱。
跳过图的情况：
任务很小或者是孤立的。 加一个函数，修一个 bug。工作流在这里纯粹是开销——单个智能体更快更便宜。 你需要紧密的监控。 如果你想在每一步跑之前都读一遍、批准一遍，那图的全部意义（不靠你并行跑）就是在跟你作对。 你还不知道自己在找什么。 探索阶段你需要的是一个能随时转向的智能体，不是一整个在你搞清楚问题之前就已经锁定方案的集群。 步骤之间真的互相依赖。 如果每一步都要读上一步的输出，那就是一条真正的链。并行没有抓手。把图强加在一个真正顺序的任务上，只是增加了协调成本，速度一点没快。 判断标准就是第1步。如果你找不到两个之间没有箭头的方块，那就没有图可搭。它是一个循环Loop，够用就好。
Graph是为 宽度 服务的工具——独立的工作，同时完成。
当工作不宽的时候，那条线从来就不是问题……
转变 提示词工程师问问题。架构师画图。 线性智能体从来不是天花板。
它是第一个形状——每个人都伸手去够的那个，因为它匹配我们打字的方式：一行，一次一件事。
一旦你看见了节点和边，你就不再要求智能体 做更多 ，而是开始要求Graph 做得更宽 ：
大多数人会继续把步骤排成一条线。
少数学会画图、并且懂得尊重什么会让图崩掉的人，将运行一支舰队。
画出那张图。留在架构师的位置上。
粤ICP备14082021号
免费POC，
零成本试错
