宜博 / lemongraph

Commit 65841bfc63da1289bc061291a7977a508a7c71b6

Authored by graphlemon
1 parent 2397a745

graphlemon: auto-commit uncommitted changes for cd75b596-6121-4a02-b4c2-6c2dce6f… 

…f2cf-main-checkout-drift
Inline Side-by-side
Showing 1 changed file with 202 additions and 0 deletions
docs/reference/graph-engineering-1000-agents-5-steps.md 0 → 100644
  View file @65841bf
  1 +# Graph Engineering：一个提示词，跑起 1000+ 的智能体循环（完整 5 步教程）
  2 +
  3 +- **来源**：微信公众号文章，https://mp.weixin.qq.com/s/tR0Z_3Yka2dNXQPO7P0OsA
  4 +- **收录方式**：原文由用户在对话中手动粘贴全文文本（微信有反爬验证，工具无法直接抓取正文）；正文引用的插图未能一并保存，下文以 `[图片]` 标记原文插图位置。
  5 +- **入库日期**：2026-08-04
  6 +- **说明**：本文与 `docs/Graph Engineering with Claude_ 14-Step roadmap from 0 to graph architect (Full Course).md`（14 步版）是同一主题的姊妹篇/精简版，均围绕 Claude Code 的 Dynamic Workflows 功能展开，可与该文对照阅读。
  7 +
  8 +---
  9 +
  10 +> 📌 资料来自于网络媒体收集
  11 +
  12 +「循环工程 | Loop Engineering」讲的是一个智能体怎么反复打磨一件事。这篇讲的是下一步：怎么让一千个智能体同时干活。
  13 +
  14 +大多数人搭建多步骤智能体的时候，最终得到的都是一条直线。第一步，第二步，第三步。每一步都在等上一步跑完才能开始。但几乎没人去检查一件事：这些步骤里，有一半根本不需要等。它们只是排着队，一个接一个地跑，直到上下文窗口被塞满，智能体忘了自己在干什么。
  15 +
  16 +慢，不是因为模型弱慢，是因为你把一张图画成了一条线。
  17 +
  18 +这篇教程就干一件事：把你手里那条线，掰开成一张图。图能扇形展开，能自己检查自己。一共 5 步。到第 2 步你就能搭出一个能跑的图。它会告诉你哪些坑会让真实的图崩掉，我会在难点出现之前提前标记。
  19 +
  20 +[图片]
  21 +
  22 +## 前言——Graph Engineering 到底是什么
  23 +
  24 +一个月前，这个圈子还在讨论循环（Loop）。Peter Steinberger（小龙虾作者）用一句话就把这风向变化点到了：
  25 +
  26 +[图片]
  27 +
  28 +一个循环，就是一轮"变得更好"的过程：试一下 → 看结果 → 调整 → 再来。这就是原子：一个智能体，反复打磨同一件事。
  29 +
  30 +但单一循环有一个已知的死法——比如一个客服团队把反馈循环绑定在一个指标上：工单解决率。这个数字连涨了好几个月，而用户满意度却在下滑。机器人学会了快速关闭工单，而不是真正解决问题。这就是**古德哈特定律（Goodhart's Law）**。一个循环只能看见自己的指标。它没法质疑目标本身对不对，也察觉不到自己的度量在漂移。
  31 +
  32 +答案不是一个更好的循环，而是**一张循环组成的图**——一个网络，里面的循环互相监视、互相纠错。
  33 +
  34 +落到智能体上，就一句话：别再写一个"什么都干"的直线智能体了——去设计工作的形状：谁先谁后，谁跟谁同时跑，谁在等谁。节点负责思考，边负责传递结果。
  35 +
  36 +[图片]
  37 +
  38 +而且 Claude Code 已经发布了直接构建这些的工具：**动态工作流（Dynamic Workflows）**。
  39 +
  40 +## 第 1 步——看见那些"不存在的边"
  41 +
  42 +一张图有两个组成部分：
  43 +
  44 +- **节点（Node）**是一个工作单元：一个智能体，一项任务，一个输入，一个输出
  45 +- **边（Edge）**是一个依赖关系：这个节点的输出，是那个节点的输入
  46 +
  47 +所有人都会犯的错误，是把"然后"当成一条边。
  48 +
  49 +> "总结一下这个文件，然后告诉我天气怎么样"
  50 +
  51 +天气根本不需要读那个总结。这是两个完全独立的任务，却被一个线性脚本毫无理由地串在了一起。每一个都在白白等上一个完成。
  52 +
  53 +[图片]
  54 +
  55 +开启一切的那个习惯：对每一个"然后"，问一句——**下一步真的需要读上一步的输出吗？**
  56 +
  57 +- 如果是 → 真正的连接点。保持顺序。
  58 +- 如果不是 → 没有连接点。等待是浪费。让它们并排跑。
  59 +
  60 +如果两个方块之间没有数据流动，它们就是独立的。记住这种独立性。后面整篇教程都在利用它。
  61 +
  62 +你那个"先做 A，再做 B，再做 C"的智能体，其实已经是一张图了——只不过是最惨的那种：一条单链，C 一卡住，D 就永远跑不了。
  63 +
  64 +## 第 2 步——从零搭出你的第一张图
  65 +
  66 +理论够了。动手搭一个，看它跑起来。
  67 +
  68 +开始之前：
  69 +
  70 +- Claude Code v2.1.154+（用 `claude --version` 检查）
  71 +- 付费方案。Max、Team 或 Enterprise 默认开启工作流。Pro 用户需要在 `/config` 里打开 Dynamic workflows 开关
  72 +
  73 +步骤：
  74 +
  75 +1. 打开一个你熟悉的代码仓库。用一个真实的，这样结果才有意义。
  76 +2. 粘贴这段提示词（来自 Anthropic 官方）：
  77 +
  78 + > 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.
  79 +
  80 + 把 `src/routes/` 换成你文件实际所在的路径。"最多 20 个"这行是为了让第一次跑的成本可控。
  81 +3. 看"workflow"亮起来。Claude Code 会高亮显示："Dynamic workflow requested." 这就是你的信号——一张图正在构建，而不是普通聊天。
  82 +4. 批准计划。Claude 会写一个 JavaScript 编排脚本，先展示各个阶段。读一遍，然后选 "Yes, run it."
  83 +5. 让集群跑起来。每个文件一个智能体，并行执行，而你的主会话保持空闲。输入 `/workflows` 可以实时观看：确定范围 → 扇形展开 → 验证 → 综合。
  84 +6. 读最终的完整答案。这不是二十个零散独立的对话。而是一份综合这些会话的报告——因为中间结果存在 Subagent 脚本的变量里，而不是你的上下文里。
  85 +
  86 +这就是 Graph。十几个智能体，来自一句提示词。
  87 +
  88 +[图片]
  89 +
  90 +### 关于你认为的"零 token"说法
  91 +
  92 +协调脚本是代码。所以在智能体之间传递结果，不会像聊天交接那样重新消耗上下文。但**智能体本身仍然消耗用量**。一个工作流的花费显著高于一次普通会话。省的是协调成本，不是工作本身。先小范围跑，观察用量，再逐步扩大。
  93 +
  94 +### 把它变成你自己的工作流
  95 +
  96 +当一次运行效果不错时，按 `s`。它会保存到 `~/.claude/workflows`，之后可以按名字重新运行。现在换掉任务，保留形状。把"缺失的鉴权检查"换成"未处理的 Promise"，或者"超过 100 行的函数"。
  97 +
  98 +### 这东西能扩展到什么程度
  99 +
  100 +一次工作流运行最多可以扇形展开到 **1000 个智能体**，同时最多 **16 个并行**工作。这就是"一个窗口里跑 1000+ 循环"的由来——不是比喻，是这个功能的实际上限。
  101 +
  102 +而规模本身就是重点：一千个智能体意味着一个单一上下文永远装不下的任务——一次性审计整个代码库，一次触及每个文件的迁移，一次从一千个角度并行搜索。16 个并发的上限只是意味着集群以波浪式推进，啃完全部一千个，而你不需要盯着任何一个。
  103 +
  104 +先从 20 个开始，看看一次运行是什么表现、花多少钱——然后放开——因为这是别人还没开始搭建的上限。
  105 +
  106 +## 第 3 步——真正会崩的地方
  107 +
  108 +你搭了一张 Agent 的协作图。下面是真实的流程会翻车的地方。有两种失败最致命。
  109 +
  110 +### 失败一：Graph 在跟自己达成共识
  111 +
  112 +当一个智能体检查自己的工作时，它会对自己手下留情。模型天然偏好自己的输出。
  113 +
  114 +怎么办？在边上插一个**验证器（Verifier）**——一个独立的节点，结果流向下游之前先过它这一关。
  115 +
  116 +没人说破的关键点：验证器需要**干净的上下文**。把执行器用过的同一段对话递给它，那它就不是在验证。它只是在用另一种字体跟自己说"我同意"。
  117 +
  118 +一张共享同一个上下文的智能体图，就是一个穿了马甲的单循环。它会以同样的方式失败——只不过更晚、更贵，而且一路亮着绿灯往下掉。
  119 +
  120 +验证器必须是一个全新的节点，自己的上下文，检查一个真实的信号——别问"智能体说它做完了吗"，要问"测试真的跑过了吗"。
  121 +
  122 +[图片]
  123 +
  124 +### 失败二：智能体互相踩踏
  125 +
  126 +这不是假设。当 Bun 的团队第一次把一个大移植任务扇形展开到多个智能体时，运行在操作层面就失败了——智能体在同一个工作区里使用共享的 git 命令，互相覆盖。
  127 +
  128 +那改进的方法则是：**改架构，不是改提示词**。他们直接禁掉了不安全的命令，给每个组分了自己独立的 worktree。
  129 +
  130 +这才是并行真正的教训——两个智能体写同一个文件，就是在赛跑。展开之前，先回答三个问题：
  131 +
  132 +- 每个智能体在哪里工作？
  133 +- 结果怎么合并？
  134 +- 两个智能体意见不一致时怎么办？
  135 +
  136 +[图片]
  137 +
  138 +一张没有这套方案的图不会扩展——它只会更快地崩。
  139 +
  140 +## 第 4 步——这周可以搭的 6 张图
  141 +
  142 +方法论：找到真正的边 → 扇形展开 → 在独立上下文上验证 → 隔离 Workers
  143 +
  144 +下面每一个都是同一个形状，只是瞄准了不同的任务。换掉任务那一行就能跑：
  145 +
  146 +1. **安全扫描**——每个文件一个智能体搜缺失的鉴权 auth，一个验证器确认每个发现（就是你刚搭的那个）
  147 +2. **带引用的研究报告**（`/deep-research`）——已经内置了：把你的问题拆成多个角度，并行搜索，智能体在写报告之前先互相反驳
  148 +3. **移植一个模块**——逐文件进行，测试作为关卡，失败的循环回去重做
  149 +4. **对抗性 Diff 审查**——按规模路由：小改动 → 一遍过；大改动 → 完整并行审计
  150 +5. **定时生态扫描**——保存一次，按名字重复运行
  151 +6. **未知规模的发现**——搜索器并行运行，每个结果与已发现的一切交叉比对，循环直到连续两轮没有新发现
  152 +
  153 +### 这个工程流的落地天花板长什么样
  154 +
  155 +<https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/>
  156 +
  157 +Bun 的 Zig 转 Rust 移植，用的就是这套机制。大约 50 个工作流，峰值 64 个智能体并行。大约 53.5 万行 Zig 代码变成了超过 100 万行 Rust，用了 11 天。
  158 +
  159 +它也花了大约 **16.5 万美元**的用量。它需要一个人类全程设计和监控。而且它引发了公开争议——这么多 AI 写的代码，到底能不能被安全地审查。
  160 +
  161 +规模是真的。16.5 万美元的账单也是真的。全程需要人盯着，也是真的。
  162 +
  163 +## 第 5 步——让 Graph 保持诚实的锚点
  164 +
  165 +图画得再漂亮，节点全是互相点头，那跟没有一样。一个智能体网络，全部在互相确认，没有一个碰过任何真实的东西——它的失败方式和单循环一模一样，只不过活动部件更多。
  166 +
  167 +图需要**锚点（Anchors）**：那些不能被辩论的节点。
  168 +
  169 +- 真正跑过的测试——不是"应该能过"，确实过了
  170 +- 基于证据的验证器，不是基于感觉
  171 +- 冻结的规则，智能体永远不被允许调整——因为它们是优化器最可能削弱的那些
  172 +
  173 +[图片]
  174 +
  175 +一张图的诚实程度，取决于里面那些拒绝移动的东西。
  176 +
  177 +### 什么时候不该用 Graph
  178 +
  179 +大多数任务不是图。不需要的时候硬上图，只是烧钱加添乱。跳过图的情况：
  180 +
  181 +- **任务很小或者是孤立的**。加一个函数，修一个 bug。工作流在这里纯粹是开销——单个智能体更快更便宜。
  182 +- **你需要紧密的监控**。如果你想在每一步跑之前都读一遍、批准一遍，那图的全部意义（不靠你并行跑）就是在跟你作对。
  183 +- **你还不知道自己在找什么**。探索阶段你需要的是一个能随时转向的智能体，不是一整个在你搞清楚问题之前就已经锁定方案的集群。
  184 +- **步骤之间真的互相依赖**。如果每一步都要读上一步的输出，那就是一条真正的链。并行没有抓手。把图强加在一个真正顺序的任务上，只是增加了协调成本，速度一点没快。
  185 +
  186 +判断标准就是第 1 步。如果你找不到两个之间没有箭头的方块，那就没有图可搭。它是一个循环 Loop，够用就好。Graph 是为宽度服务的工具——独立的工作，同时完成。当工作不宽的时候，那条线从来就不是问题……
  187 +
  188 +## 转变
  189 +
  190 +提示词工程师问问题。架构师画图。
  191 +
  192 +线性智能体从来不是天花板。它是第一个形状——每个人都伸手去够的那个，因为它匹配我们打字的方式：一行，一次一件事。
  193 +
  194 +一旦你看见了节点和边，你就不再要求智能体做更多，而是开始要求 Graph 做得更宽：
  195 +
  196 +- **扇形展开**——在工作独立的地方
  197 +- **守边**——在置信度重要的地方
  198 +- **冻结节点**——在承载真相的地方
  199 +
  200 +大多数人会继续把步骤排成一条线。少数学会画图、并且懂得尊重什么会让图崩掉的人，将运行一支舰队。
  201 +
  202 +画出那张图。留在架构师的位置上。
... ...