# Graph Engineering: build 1000+ agent loops in one window, from one prompt (full 5-step course)
**作者**: codila
**日期**: 2026-07-18T00:34:54.000Z
**来源**: [https://x.com/0xCodila/status/2079597821511020996](https://x.com/0xCodila/status/2079597821511020996)
---
THE Loop Engineering's successor and the workflow that runs your agents 10x wider...
Most people who build a multi-step agent end up with a straight line
step one, step two, step three. Each one waiting for the last to finish before it starts
> Here's what almost nobody checks: half those steps never needed to wait
They just queue, one job at a time, until the context window fills and the agent forgets what it was doing
- It wasn't slow because the model was weak
- It was slow because you drew a line where the work was a graph
This guide takes you from that line to a graph that fans out across a fleet and checks its own work
> Five steps. By Step 2 you'll have built one - It gets you a working graph and names the traps that break real ones and I'll flag where the hard parts begin
> before the alpha - subscribe to my substack for more fresh alpha ↓
> https://substack.com/@0xcodila
## Chapter 0 - What graph engineering actually is
A month ago the field was talking about loops.
Peter Steinberger caught it in nine words:
> **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2078277297791189132)
>
> Are we still talking loops or did we shift to graphs yet?
A loop is one cycle of getting better:
> try something → check the result → adjust → go again
That's the atom: a single agent improving one thing on repeat
(If you've read my Loop Engineering piece, this is that)
> **codila@0xCodila**: [原文链接](https://x.com/0xCodila/status/2072329149520232639)
>
But the single loop has a known failure - a support team ties a feedback loop to one metric: ticket resolution rate
The number climbs for months while satisfaction drops. The bot learned to close tickets fast instead of solving them
That's Goodhart's law. A loop can only see its own metric. It can't ask whether the target is right, or notice its own measurement drifting.
The answer isn't a better loop. It's a graph of loops - a network where cycles watch and correct each other
For agents, that means one thing:
> Stop writing one agent that does everything in a line - design the shape of the work - what runs before what, what runs at the same time, what waits.
Nodes do the thinking. Edges carry the results
And Claude Code shipped the tooling to build these directly: dynamic workflows
## Step 1 - See the edges that aren't there
A graph has two parts:
- A node is one unit of work: one agent, one job, one input, one output
- An edge is a dependency: this node's output feeds that node's input
The mistake everyone makes is treating "and then" as an edge.
> "Summarize this file and then tell me the weather"
The weather doesn't read the summary.
Those are two independent jobs a linear script chains for no reason. Each one waits on the last for nothing
The habit that starts everything:
For every "and then," ask - does the next step actually read the previous step's output?
- If yes → real edge. Keep the order.
- If no → no edge. The wait is wasted. Run them side by side.
If no data crosses between two boxes, they're independent.
That independence is what you'll exploit for the rest of this guide
> Your plain "do A, then B, then C" agent is already a graph - just the saddest one: a single chain where if C stalls, D never happens.
## Step 2 - Build your first graph (start to finish)
Enough theory. Build one and watch it run.
Before you start:
- Claude Code v2.1.154+ (check with claude --version)
- A paid plan. On Max, Team, or Enterprise, workflows are on by default. On Pro, switch on the Dynamic workflows row in /config
1. Open a repo you know.
A real one, so the result means something.
2. Paste this prompt (off by 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.
```
Swap src/routes/ for where your files live. The "max 20" line keeps your first run cheap.
3. Watch "workflow" light up.
Claude Code highlights it: "Dynamic workflow requested." That's your signal a graph is building, not a normal chat
4. Approve the plan.
Claude writes a JavaScript orchestration script and shows the phases first. Read them, pick "Yes, run it."
5. Let the fleet run.
One agent per file, in parallel, while your session stays free.
Type /workflows to watch it live: scope, fan-out, verify, synthesize.
6. Read the one answer.
Not twenty separate chats. One report - because the intermediate results lived in the script's variables, not your context.
> That's a graph. A dozen agents, from one sentence.
About the "zero tokens" claim you'll hear
The coordination script is code
So passing results between agents doesn't re-spend context the way a chat handoff does.
But the agents still cost usage. A workflow costs meaningfully more than a normal session.
The saving is in coordination, not the work. Start scoped, watch usage, then widen.
- Make it yours
When a run is good, press s.
It saves to ~/.claude/workflows, re-runnable by name
Now change the task and keep the shape. Swap "missing auth checks" for "unhandled promises," or "functions over 100 lines
## How far this scales (article name)
One workflow run can fan out to 1,000 agents, with up to 16 working at once
That's where "1000+ loops in one window" comes from - not a metaphor, the feature's actual ceiling
- And the scale is the point
A thousand agents means a job no single context could ever hold - a whole codebase audited at once, a migration that touches every file, a search that runs a thousand angles in parallel
The 16-at-once limit just means the fleet moves in waves, chewing through all thousand without you babysitting a single one
> Start at 20 to see how a run behaves and what it costs - then open it up - because this is the ceiling nobody else is building against
## Step 3 - The part that actually breaks
You built a graph. Here's where real ones fall over.
Two failures matter most
- Failure one: the graph agrees with itself
When an agent checks its own work, it goes easy on itself. Models prefer their own outputs
So you put a verifier on the edge - a separate node that confirms a finding before it flows downstream.
The catch nobody names: the verifier needs clean context
Hand it the same conversation the executor had, and it isn't verifying. It's agreeing with itself in a different font
> A graph of agents sharing one context is a single loop in a costume. It fails the same way - later, more expensively, with more green lights on the way down
So the verifier is a fresh node - Own context - Checking a real signal - not "did the agent say it's done," but "does the test actually pass"
- Failure two: agents stepping on each other
This isn't hypothetical
When Bun's team first fanned a large port across many agents, the run failed operationally and agents used shared git commands in one workspace and overwrote each other
The fix was structural, not clever prompting. They forbade the unsafe commands and gave each group its own isolated worktree
That's the real lesson of parallelism - two agents writing the same file race
Before you fan out, answer three questions:
- Where does each agent work?
- How do results merge?
- What happens when two disagree?
A graph without that plan doesn't scale - It fails faster
## Step 4 - Six graphs to build this week
The method: find the real edges → fan out → verify on independent context → isolate the workers
///
Each of these is that same shape, aimed at a new job. Change the task line and go:
- Security sweep - one agent per file hunting missing auth, a verifier confirming each hit (the one you built)
- Cited report with /deep-research - ships already: splits your question into angles, searches in parallel, agents refute each other before writing
- Port a module - file by file, tests as a gate, failures looped back
- Adversarial diff review - routed by size: small change → one pass; big one → full parallel audit
- Scheduled ecosystem scan - save once, re-run by name
- Discovery of unknown size - finders run in parallel, each result checked against everything seen, looping until two rounds find nothing new
///
What the ceiling looks like
https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun's Zig-to-Rust port ran on this exact machinery.
Around 50 workflows, a peak of 64 agents in parallel. Roughly 535,000 lines of Zig turned into over a million lines of Rust, in 11 days.
It also cost about $165,000 in usage, It needed a human designing and monitoring the whole thing
And it drew public criticism over whether that much AI-authored code can be safely reviewed.
The scale is real. So is the price, and the supervision
## Step 5 - The anchors that keep a graph honest
Topology alone doesn't buy truth
A network of agents all confirming each other, none of them touching anything real, fails exactly like the single loop did - just with more moving parts
The graph needs anchors: nodes that can't be argued with
- Tests that actually ran - not "should pass," did pass
- A verifier on evidence, not vibes
- Frozen rules the agents are never allowed to tune - because they're the ones an optimizer would weaken
The graph is only as honest as the things in it that refuse to move
## When a graph is the wrong choice
Most tasks are not graphs. Reaching for one when you don't need it just burns money and adds ways to fail.
Skip the graph when:
- The task is small or isolated. Adding a function, fixing one bug. A workflow is pure overhead here - a single agent is faster and cheaper.
- You need tight oversight. If you want to read and approve every step before the next one runs, a graph's whole point (running wide without you) works against you.
- You don't know what you're looking for yet. Exploratory work wants one agent you can steer, not a fleet committed to a plan before you understand the problem.
- The steps genuinely depend on each other. If every step reads the last step's output, it's a real chain. Parallelism has nothing to grab. Forcing a graph onto a truly sequential task just adds coordination cost for zero speedup.
The tell is Step 1. If you can't find two boxes with no arrow between them, there's no graph to build. It's a loop, and a loop is fine.
A graph is a tool for width - independent work, done at once
When the work isn't wide, the line was never the problem...
## The shift
> A prompter asks a question. An architect draws a graph.
The linear agent was never the ceiling.
It was the first shape - the one everyone reaches for because it matches how we type: one line, one thing at a time.
Once you see the nodes and edges, you stop asking the agent to do more and start asking the graph to do it wider:
- Fan out where the work is independent
- Gate the edges where confidence matters
- Freeze the nodes that hold the truth
Most people will keep queueing steps in a line.
The few who learn to draw the graph, and to respect what breaks it, will run a fleet.
> Draw the graph. Stay the architect.
> Start with the prerequisite: Loop Engineering - the single loop this is built on
> @0xCodila
## 相关链接
- [codila](https://x.com/0xCodila)
- [@0xCodila](https://x.com/0xCodila)
- [https://substack.com/@0xcodila](https://substack.com/@0xcodila)
- [Jul 18](https://x.com/steipete/status/2078277297791189132)
- [2.9M](https://x.com/steipete/status/2078277297791189132/analytics)
- [Jul 1](https://x.com/0xCodila/status/2072329149520232639)
- [4.7M](https://x.com/0xCodila/status/2072329149520232639/analytics)
- [dynamic workflows](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)
- [https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/](https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/)
- [Loop Engineering](https://x.com/0xCodila/status/2072329149520232639)
- [@0xCodila](https://x.com/@0xCodila)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:02 AM · Jul 22, 2026](https://x.com/0xCodila/status/2079597821511020996)
- [8,057 Views](https://x.com/0xCodila/status/2079597821511020996/analytics)
- [View quotes](https://x.com/0xCodila/status/2079597821511020996/quotes)
---
*导出时间: 2026/7/22 09:53:25*
---
## 中文翻译
# 图工程：在一个窗口、一个提示词下构建 1000+ 个智能体循环（完整 5 步教程）
**作者**: codila
**日期**: 2026-07-18T00:34:54.000Z
**来源**: [https://x.com/0xCodila/status/2079597821511020996](https://x.com/0xCodila/status/2079597821511020996)
---
循环工程的后继者，以及能让你的智能体运行范围扩大 10 倍的工作流……
大多数构建多步骤智能体的人最终得到的都是一条直线：
第一步、第二步、第三步。每一步都在等待上一步完成后才开始。
> 这里有一个几乎没人注意到的点：这些步骤中有一半根本不需要等待。
它们只是排队，一次处理一个任务，直到上下文窗口填满，智能体忘记自己在做什么。
- 它慢不是因为模型弱。
- 它慢是因为在本该是图的地方画了一条线。
本指南将带你从那条线过渡到一个图，它会分散到一个集群中并自我检查。
> 五个步骤。到了第 2 步，你就能构建出一个——它让你得到一个能工作的图，并指出破坏真实图的各种陷阱。我会在 alpha 版本发布前标记出难点开始的地方——订阅我的 substack 获取更多一手资讯 ↓
> https://substack.com/@0xcodila
## 第 0 章 - 图工程到底是什么
一个月前，这个领域还在谈论循环。
Peter Steinberger 用九个字抓住了本质：
> **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2078277297791189132)
>
> 我们还在谈论循环，还是已经转向图了？
循环是一次变好的周期：
> 尝试某事 → 检查结果 → 调整 → 再来一次
那是原子单位：一个智能体重复改进一件事。
（如果你读过我的《循环工程》文章，就是那个东西。）
> **codila@0xCodila**: [原文链接](https://x.com/0xCodila/status/2072329149520232639)
>
但单循环有一个已知的缺陷——一个支持团队将反馈循环绑定到一个指标上：工单解决率。
几个月来数字在攀升，但满意度却在下降。机器人学会了快速关闭工单，而不是解决问题。
这就是古德哈特定律。一个循环只能看到它自己的指标。它无法询问目标是否正确，也无法注意到自己的测量发生了漂移。
答案不是更好的循环。而是循环的图——一个循环之间相互监督和纠正的网络。
对于智能体来说，这意味着一件事：
> 停止编写一个按直线做所有事情的单智能体——设计工作的形状——什么在什么之前运行，什么同时运行，什么等待。
节点负责思考。边负责传输结果。
而 Claude Code 推出了直接构建这些图所需的工具：动态工作流。
## 第 1 步 - 看见那些不存在的边
一个图有两部分：
- 节点是一个工作单元：一个智能体、一个任务、一个输入、一个输出。
- 边是一个依赖关系：这个节点的输出馈送到那个节点的输入。
每个人都会犯的错误是把“然后”当作边。
> “总结这个文件，然后告诉我天气。”
天气不看总结。
这是两个独立的任务，线性脚本毫无理由地把它们串在一起。每一个都在白白等待上一个完成。
一切的开端习惯：
对于每一个“然后”，问一下——下一步真的会读取上一步的输出吗？
- 如果是 → 真正的边。保持顺序。
- 如果否 → 没有边。等待是浪费。并行运行它们。
如果两个框之间没有数据交叉，它们就是独立的。
这种独立性是你将在本指南其余部分利用的东西。
> 你那个简单的“做 A，然后 B，然后 C”的智能体已经是一个图了——只是最悲哀的那种：一条单链，只要 C 卡住了，D 就永远不会发生。
## 第 2 步 - 构建你的第一个图（从头到尾）
理论够了。构建一个，看着它运行。
开始之前：
- Claude Code v2.1.154+（使用 claude --version 检查）。
- 付费计划。在 Max、Team 或 Enterprise 计划中，工作流默认开启。在 Pro 计划中，在 /config 中开启“Dynamic workflows”行。
1. 打开一个你熟悉的仓库。
一个真实的仓库，这样结果才有意义。
2. 粘贴这个提示词（由 Anthropic 提供）：
```
创建一个工作流，审查 src/routes/ 下的每个路由文件
是否缺少身份验证检查。为每个文件生成一个智能体，
然后在报告之前对每个发现运行一个独立的验证器。
开始最多分析 20 个文件。
```
将 src/routes/ 替换为你的文件所在位置。“max 20”这一行让你的第一次运行保持低成本。
3. 观察“workflow”亮起。
Claude Code 会高亮显示它：“请求了动态工作流”。这是你的信号，表明正在构建一个图，而不是普通的聊天。
4. 批准计划。
Claude 编写一个 JavaScript 编排脚本并首先显示各个阶段。阅读它们，选择“Yes, run it”。
5. 让集群运行。
每个文件一个智能体，并行运行，而你的会话保持空闲。
输入 /workflows 实时查看它：scope（范围）、fan-out（扩散）、verify（验证）、synthesize（综合）。
6. 阅读那唯一的答案。
不是二十个独立的聊天。一份报告——因为中间结果存在于脚本的变量中，而不是你的上下文中。
> 这就是一个图。十几个智能体，来自一句话。
关于你会听到的“零 token”声明
协调脚本是代码。
所以在智能体之间传递结果不会像聊天移交那样重新消耗上下文。
但智能体仍然消耗使用量。一个工作流的成本比普通会话要高得多。
节省在于协调，而不在于工作。从小范围开始，监控使用量，然后再扩大。
- 定制为你自己的
当运行效果良好时，按 s。
它会保存到 ~/.claude/workflows，可以按名称重新运行。
现在更改任务但保持形状。将“缺少身份验证检查”换成“未处理的 Promise”，或“超过 100 行的函数”。
## 它能扩展到多远（文章名称）
一次工作流运行可以扩散到 1,000 个智能体，最多同时运行 16 个。
这就是“一个窗口中 1000+ 个循环”的来源——不是比喻，是该功能的实际上限。
- 扩展就是重点
一千个智能体意味着一项没有任何单个上下文能容纳的工作——一次性审计整个代码库，触及每个文件的迁移，并行运行一千个角度的搜索。
一次 16 个的限制只是意味着集群以波浪式移动，咀嚼完所有一千个任务，而无需你盯着任何一个。
- 从 20 个开始，看看运行表现如何以及成本多少——然后放开它——因为这是其他人都在追赶的上限。
## 第 3 步 - 真正会出问题的部分
你构建了一个图。这里是真实的图崩溃的地方。
有两种失败最为重要：
- 失败一：图自我认同
当一个智能体检查自己的工作时，它会对自己手下留情。模型更喜欢自己的输出。
所以你在边上放了一个验证器——一个单独的节点，在发现结果向下游流动之前对其进行确认。
没人说出来的陷阱：验证器需要干净的上下文。
把执行器用过的同一个对话交给它，它就不是在验证。它只是在用不同的字体同意自己。
> 共享一个上下文的智能体图是一个穿着戏装的单循环。它会以同样的方式失败——只是更晚，代价更高，一路上有更多的绿灯。
所以验证器是一个新节点——独立的上下文——检查真实的信号——不是“智能体说它做完了吗”，而是“测试真的通过了吗”。
- 失败二：智能体相互踩踏
这不是假设。
当 Bun 团队首次将一个大型移植分散到许多智能体时，运行在操作上失败了，智能体在一个工作区中使用共享的 git 命令并相互覆盖。
修复是结构性的，而不是聪明的提示词。他们禁止了不安全的命令，并给了每组自己的隔离工作树。
这才是并行性的真正教训——两个智能体写同一个文件就是竞态。
在扩散之前，回答三个问题：
- 每个智能体在哪里工作？
- 结果如何合并？
- 当两个意见不一致时会发生什么？
没有那个计划的图无法扩展——它只会失败得更快。
## 第 4 步 - 本周要构建的六个图
方法：找到真正的边 → 扩散 → 在独立上下文上验证 → 隔离工作者
///
每一个都是同样的形状，针对一项新工作。更改任务行然后开始：
- 安全扫描——每个文件一个智能体寻找缺少的身份验证，一个验证器确认每个命中（你构建的那个）。
- 带引用的报告，使用 /deep-research——已发布：将你的问题拆解为角度，并行搜索，智能体在撰写前相互反驳。
- 移植一个模块——逐个文件，测试作为关卡，失败循环返回。
- 对抗性 diff 审查——按大小路由：小改动 → 一次通过；大改动 → 完全并行审计。
- 定时生态系统扫描——保存一次，按名称重新运行。
- 未知规模的发现——查找器并行运行，每个结果与所有已见结果核对，循环直到两轮都没有发现新东西。
///
天花板长什么样
https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun 从 Zig 到 Rust 的移植就是在这套机器上运行的。
大约 50 个工作流，峰值 64 个智能体并行。大约 535,000 行 Zig 在 11 天内变成了超过一百万行 Rust。
这也花费了大约 165,000 美元的使用量，它需要一个人设计和监控整个过程。
而且它还招致了公众关于如此多 AI 编写的代码是否可以被安全审查的批评。
规模是真实的。价格和监管也是如此。
## 第 5 步 - 保持图诚实的锚点
仅靠拓扑结构买不来真理。
一个相互确认的智能体网络，没有任何一个接触真实事物，它的失败方式和单循环完全一样——只是有更多活动部件。
图需要锚点：无法被反驳的节点。
- 实际运行了的测试——不是“应该通过”，是“通过了”。
- 基于证据的验证器，而不是感觉。
- 冻结的规则，智能体永远不允许调整——因为它们是优化器会削弱的东西。
图的诚实程度，取决于其中那些拒绝变动的东西。
## 什么时候图是错误的选择
大多数任务不是图。在不需要的时候伸手去用图只会烧钱并增加失败的方式。
跳过图的情况：
- 任务很小或很孤立。添加一个函数，修复一个 bug。在这里工作流纯粹是开销——单个智能体更快更便宜。
- 你需要紧密的监督。如果你想阅读并批准每一步再运行下一步，图的整个意义（没有你而广泛运行）就会与你作对。
- 你还不知道你在找什么。探索性工作需要一个你可以引导的智能体，而不是一个在你理解问题之前就致力于计划的集群。
- 步骤真的相互依赖。如果每一步都读取上一步的输出，那就是真正的链。并行性无处着手。将图强加于真正的顺序任务只会增加协调成本，而速度提升为零。
判断的关键在第 1 步。如果你找不到两个框之间没有箭头，就没有图可构建。它是一个循环，循环也没问题。
图是用于宽度的工具——独立的工作，一次完成。
当工作不宽时，线从来就不是问题……
## 转变
> 提示者问问题。架构师画图。
线性智能体从来都不是上限。
它是第一种形状——每个人都会伸手去用的那个，因为它匹配我们的打字方式：一行，一次一件事。
一旦你看到了节点和边，你就不再要求智能体做得更多，而是开始要求图做得更宽：
- 在工作独立的地方扩散。
- 在置信度重要的地方对边设卡。
- 冻结那些掌握真理的节点。
大多数人会继续在线中排队步骤。
少数学会画图，并学会尊重会破坏它的东西的人，将运行一个集群。
> 画图。保持为架构师。
> 从先决条件开始：循环工程——这是建立在其基础上的单循环
> @0xCodila
## 相关链接
- [codila](https://x.com/0xCodila)
- [@0xCodila](https://x.com/0xCodila)
- [https://substack.com/@0xcodila](https://substack.com/@0xcodila)
- [Jul 18](https://x.com/steipete/status/2078277297791189132)
- [2.9M](https://x.com/steipete/status/2078277297791189132/analytics)
- [Jul 1](https://x.com/0xCodila/status/2072329149520232639)
- [4.7M](https://x.com/0xCodila/status/2072329149520232639/analytics)
- [dynamic workflows](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)
- [https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/](https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/)
- [Loop Engineering](https://x.com/0xCodila/status/2072329149520232639)
- [@0xCodila](https://x.com/@0xCodila)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:02 AM · Jul 22, 2026](https://x.com/0xCodila/status/2079597821511020996)
- [8,057 Views](https://x.com/0xCodila/status/2079597821511020996/analytics)
- [View quotes](https://x.com/0xCodila/status/2079597821511020996/quotes)
---
*导出时间: 2026/7/22 09:53:25*