# Graph Engineering: The Complete Guide to Building Multi-Agent AI Systems
**作者**: Lunar
**日期**: 2026-08-08T12:45:30.000Z
**来源**: [https://x.com/LunarResearcher/status/2086071302272528833](https://x.com/LunarResearcher/status/2086071302272528833)
---
Most people building multi-agent AI systems are focusing on the wrong layer.
They obsess over prompts, models, tools, memory, and how many agents they can spawn.
But once you have more than one agent, the hardest problem is no longer making an individual agent smarter.
It is deciding how the work itself should move.
Which agents can run at the same time? Which ones actually depend on each other? What data should move between them? Where should results converge? What gets verified? What happens when one node fails? And which actions should remain impossible until a human approves them?
That layer has a name:
Graph Engineering.
A graph turns a pile of agents into a system.
Instead of:
A → B → C → D → E
you start thinking in nodes, dependencies, parallel branches, reducers, verification gates, loops, failure domains, and human checkpoints.
By the end of this guide, you’ll know how to design multi-agent systems that are faster, cheaper, easier to debug, and much harder to fool.
> If you want more practical breakdowns on AI agents, workflows, and systems like this, subscribe to my Substack: @LunarResearcher
> And follow me on X: @LunarResearcher
## 1. A workflow is not a checklist
The easiest way to waste an AI system is to confuse order with dependency.
Suppose your workflow says:
1. inspect pricing
2. inspect customer reviews
3. inspect product documentation
4. write a market brief
Most people run those four steps in order because they were written in order.
But the first three do not need each other.
They only need to finish before step four.
So the real shape is:
```
pricing ──────┐
│
reviews ──────────────────┼──→ market brief
│
docs ───────────────┘
```
That drawing contains more engineering information than the numbered list.
The important question is not:
“What comes next?”
It is:
“What information must exist before this can start?”
That single question exposes fake dependencies immediately.
If task B never consumes anything produced by task A, then A → B is not a real dependency.
It is just waiting.
## 2. The graph needs state, not just arrows
Once people discover parallel agents, they usually make the next mistake: every agent receives a huge prompt and returns a huge blob of text.
That works in a demo.
It collapses in a real graph.
A useful graph needs explicit state.
Not “whatever the previous model said.”
Actual state.
For example:
```
ResearchFinding {
claim
evidence
source
confidence
timestamp
}
```
Now the next node is not reading a conversation.
It is reading an object.
That difference sounds small. It is not.
Structured state gives you three things:
1. Replaceability.
You can swap one worker for another without rewriting everything downstream.
2. Inspectability.
You can see exactly what entered and left a node.
3. Determinism around the model.
The model can still be fuzzy inside the box, while the interface around the box stays strict.
This is how you stop building a chain of chats and start building a system.
The agent can improvise.
The graph should not.
## 3. Use the dependency test before you add another agent
There is a brutally useful test for every arrow in your workflow:
> What exact data crosses this arrow?
If you cannot answer that in one sentence, the edge is suspicious.
Bad answer:
> “The next agent should know the previous agent finished.”
That is status, not dependency.
Better answer:
> “The reviewer receives the researcher’s claim, source URL, and evidence excerpt.”
Now the edge has meaning.
You can apply this test to almost any workflow:
```
review file A → review file B
```
What crosses?
Nothing.
Delete the edge.
```
extract invoices → calculate total
```
What crosses?
The invoice values.
Keep the edge.
```
generate three headlines → choose the strongest
```
What crosses?
The three candidate headlines.
Keep the edge.
The goal is not to maximize parallelism.
The goal is to remove fake synchronization.
## 4. Parallelism is not free
Once people realize independent work can run at the same time, they often go too far.
Twenty workers become two hundred.
Two hundred become two thousand.
The graph gets wider.
The bill gets wider too.
Parallelism reduces wall-clock time.
It does not magically reduce the amount of work.
In fact, wide graphs often create new costs:
- more duplicated research
- more conflicting outputs
- more rate limits
- more merge pressure
- more verification
- more context at the final stage
So every serious graph needs a width budget.
Think of it like memory allocation.
You would not launch 500 database queries just because the database technically accepts connections.
Do not launch 500 agents just because your runtime technically can.
A useful rule:
> Add width only when the extra worker increases coverage more than it increases reconciliation cost.
Five researchers looking at five genuinely different angles can be excellent.
Fifty researchers searching the same topic with slightly different prompts is usually noise generation.
The unit you should optimize is not “number of agents.”
It is useful independent coverage per dollar.
## 5. The critical path matters more than total steps
A linear workflow is slow because every duration is added together.
If five tasks take:
```
8s + 12s + 6s + 10s + 9s
```
your workflow needs roughly 45 seconds.
If four of those tasks are independent, the system may only need to wait for the slowest one before merging.
Suddenly the important number is not the sum.
It is the critical path.
That changes how you should read a workflow diagram.
Do not count boxes.
Look for the longest unavoidable path from start to finish.
That path determines latency.
Everything else is an optimization opportunity.
This is why a 40-node graph can finish faster than a 7-node chain.
The graph is bigger.
The critical path is shorter.
## 6. Compress before you reason
Here is one of the most expensive architecture mistakes in agent systems:
```
20 workers
↓
one giant synthesis prompt
```
All raw outputs get shoved into one final model.
Now the final node has to:
- read everything
- remove duplicates
- resolve formatting
- notice contradictions
- rank findings
- infer missing fields
- then write the answer
You have turned your smartest model into a garbage collector.
Do not do that.
Put a reducer before synthesis.
The reducer should remove work that does not require judgment.
Examples:
```
deduplicate IDs
sort by timestamp
group by source
drop malformed records
count votes
normalize labels
remove exact duplicates
```
Most of that should be plain code.
Not another agent.
Then your expensive reasoning node receives a smaller, cleaner set.
The architecture becomes:
```
workers
↓
deterministic reduce
↓
reasoning / synthesis
```
This is one of the strongest cost optimizations in the whole design space.
Use models for ambiguity.
Use code for plumbing.
## 7. Verification should be asymmetric
A worker should not be rewarded for defending its own answer.
That creates confirmation pressure.
Instead, give verification a different objective.
The worker says:
> “Find the strongest answer.”
The verifier says:
> “Find the reason this answer should be rejected.”
Those are not the same task.
Good verification is adversarial.
For a research system:
```
WORKER:
Find evidence supporting or explaining the claim.
VERIFIER:
Try to falsify the claim.
Check the source.
Check the date.
Look for conflicting evidence.
```
For code:
```
WORKER:
Implement the change.
VERIFIER:
Try to break it.
Run tests.
Inspect edge cases.
Look for regressions.
```
For strategy:
```
WORKER:
Build the recommendation.
VERIFIER:
List conditions under which this recommendation fails.
```
The verifier should have permission to kill output.
Otherwise it is decoration.
A useful graph does not just create more candidates.
It creates a selection pressure that bad candidates must survive.
## 8. Design failure domains before the graph runs
A real graph assumes nodes will fail.
Not because your system is bad.
Because distributed work always fails somewhere.
A request times out.
A source disappears.
A tool returns malformed data.
A model ignores the requested format.
A worker gets rate-limited.
The architecture question is:
How much of the graph should die with it?
The wrong answer is:
> “Everything.”
Each node should live inside a failure domain with an explicit policy:
```
ON FAILURE:
1. retry once
2. retry with fallback model/tool
3. return structured failure
4. continue if quorum is still sufficient
5. block only if this node is critical
```
Now a graph with ten researchers can still produce a valid report if one fails.
But the final output should know that only 9/10 completed.
That is the distinction between resilience and silent incompleteness.
Never hide missing work.
Degrade visibly.
## 9. Human approval is an edge type
This is an important shift.
Most people model the human as another node:
```
AI → human → AI
```
That is too vague.
The human is often not “doing work.”
The human is granting permission for state to cross a boundary.
That makes approval closer to an edge condition.
Example:
```
draft campaign
↓
quality checks
↓
[ HUMAN APPROVAL ]
↓
publish
```
The publishing node should literally be unreachable until approval exists.
Not:
> “The model was instructed to ask first.”
Not:
> “The agent usually waits.”
The graph should make the unsafe transition impossible.
This matters most when the downstream action is irreversible:
- sending money
- deploying code
- emailing customers
- deleting data
- changing permissions
- publishing externally
The stronger the consequence, the more the approval belongs in architecture rather than prompt wording.
## 10. Some rules should be frozen
Agent systems are optimization machines.
That means they will eventually discover shortcuts.
If “success” means shipping faster, the system may weaken review.
If “success” means more leads, it may loosen qualification.
If “success” means more completed tickets, it may become generous about what counts as “resolved.”
So some rules should sit outside optimization.
Think of them as frozen constraints.
Examples:
```
never publish without approval
never cite a source that was not opened
never mark a test as passed unless it executed
never exceed the spend cap
never modify production credentials
```
These are not suggestions to the agent.
They are constraints on the graph.
A smart optimizer inside weak boundaries becomes dangerous faster.
A smart optimizer inside strong boundaries becomes useful faster.
## 11. Observe the graph, not the chat
A chat transcript is a terrible dashboard for a distributed system.
Once a workflow becomes graph-shaped, you need graph-shaped metrics.
The useful ones are surprisingly simple.
Critical-path latency
How long is the longest dependency chain?
This tells you where the actual waiting lives.
Node failure rate
Which workers fail most often?
This catches brittle tools and bad prompts.
Retry rate
A graph that “succeeds” after four retries per node is not healthy.
Verifier kill rate
If the verifier rejects 0% of outputs, it may be useless.
If it rejects 80%, your workers may be poorly scoped.
Fan-out efficiency
How many parallel workers produced unique useful information?
This is your signal-to-width ratio.
Compression ratio
How much raw material is removed before final synthesis?
If 200 outputs become 18 useful findings, the reducer is doing valuable work.
Human intervention rate
Where do people still need to rescue the system manually?
Those are your next architecture targets.
Once you track these, improving the system becomes much easier.
You are no longer tweaking prompts based on vibes.
You are optimizing a machine.
## 12. Five graph shapes worth knowing
You do not need a library of fifty patterns.
These five cover a surprising amount of real work.
1. Fork / Join
```
A
↙ ↓ ↘
B C D
↘ ↓ ↙
E
```
Use it for research, audits, batch analysis, competitive scans.
2. Escalation Ladder
```
cheap check
↓ uncertain?
medium check
↓ still uncertain?
strong model / human
```
Use it when most cases are easy but a few deserve expensive reasoning.
3. Tournament
```
candidate 1 ─┐
candidate 2 ─┼→ judges → winner
candidate 3 ─┘
```
Use it for copy, designs, plans, code approaches, hypotheses.
4. Map → Reduce → Verify → Synthesize
```
many workers
↓
normalize + dedupe
↓
attack weak findings
↓
final answer
```
Use it for decision-grade research and large-scale review.
5. Bounded Discovery Loop
```
search
↓
new findings?
↓ yes
verify → add to seen → search again
stop after:
- no new findings for N rounds
- max spend
- max time
```
Use it when you do not know how large the problem is before starting.
The budget is part of the topology.
Without a stopping rule, a loop is not architecture.
It is a leak.
## 13. A graph spec you can paste into almost any agent framework
Before you write code, describe the system like this:
```
GOAL:
What must exist at the end?
INPUT STATE:
What structured data enters the graph?
PARALLEL WORK:
Which tasks are truly independent?
EDGE DATA:
What exact information crosses each dependency?
REDUCER:
What can be normalized, deduplicated, ranked, or filtered with code?
VERIFICATION:
What independent test can reject weak output?
FAILURE POLICY:
What retries?
What fallback?
What can fail without killing the run?
BUDGET:
Maximum agents?
Maximum tokens/cost?
Maximum wall-clock time?
HUMAN GATE:
Which irreversible actions require approval?
OUTPUT:
What exact schema or artifact is returned?
```
That specification is more valuable than writing twenty prompts first.
Because prompts optimize nodes.
The spec optimizes the system.
## 14. When you should not build a graph
Graphs are powerful enough that people start using them everywhere.
Do not.
Use a single agent when:
- the task is small
- each step genuinely depends on the previous one
- you are still exploring the problem
- the cost of coordination exceeds the work
- you need one coherent perspective, not broad coverage
- the human wants to steer every intermediate step
A graph buys width, isolation, and control flow.
It does not automatically buy taste.
It does not automatically buy truth.
It does not automatically make a weak task definition better.
Sometimes one good agent with the right tools is the correct architecture.
The point is not to graph everything.
The point is to recognize when a line is artificially limiting work that was never sequential in the first place.
# The real shift
The first generation of AI workflows was prompt engineering.
Then came tool use.
Then loops.
Now the harder skill is orchestration.
Not “how do I make the model smarter?”
But:
- what can run at the same time?
- what state should be shared?
- what should never be shared?
- what gets verified?
- what happens when a worker dies?
- what is allowed to continue?
- where does cost explode?
- where does a human still hold the key?
That is the difference between an AI that performs a task and an AI system that can own a process.
More agents are not the answer.
Better topology is.
If you read this far:
- BOOKMARK THIS.
- Follow @LunarResearcher
- Follow my Substack
- Follow my Private Telegram Channel
## 相关链接
- [Lunar](https://x.com/LunarResearcher)
- [@LunarResearcher](https://x.com/LunarResearcher)
- [35K](https://x.com/LunarResearcher/status/2086071302272528833/analytics)
- [@LunarResearcher](https://x.com/@LunarResearcher)
- [@LunarResearcher](https://x.com/LunarResearcher)
- [@LunarResearcher](https://x.com/@LunarResearcher)
- [Substack](https://substack.com/@lunarresearcher)
- [Private Telegram Channel](https://t.me/+O4FFj3BmnJRiODhi)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:45 PM · Aug 8, 2026](https://x.com/LunarResearcher/status/2086071302272528833)
- [35.2K Views](https://x.com/LunarResearcher/status/2086071302272528833/analytics)
- [View quotes](https://x.com/LunarResearcher/status/2086071302272528833/quotes)
---
*导出时间: 2026/8/9 20:49:29*
---
## 中文翻译
# 图工程：构建多智能体AI系统的完全指南
**作者**: Lunar
**日期**: 2026-08-08T12:45:30.000Z
**来源**: [https://x.com/LunarResearcher/status/2086071302272528833](https://x.com/LunarResearcher/status/2086071302272528833)
---
大多数构建多智能体AI系统的人都把注意力放错了层级。
他们痴迷于提示词、模型、工具、记忆，以及能生成多少个智能体。
但一旦你的智能体超过一个，最困难的问题就不再是如何让单个智能体变得更聪明。
而是决定工作本身应该如何流转。
哪些智能体可以同时运行？哪些实际上相互依赖？它们之间应该传递什么数据？结果应该在哪里汇聚？什么需要被验证？当某个节点失败时会发生什么？哪些操作在人类批准之前应该被严格禁止？
这一层有一个名字：
图工程。
图能将一堆智能体转变为一个系统。
你不再是：
A → B → C → D → E
而是开始从节点、依赖关系、并行分支、归约器、验证关卡、循环、故障域和人工检查点的角度来思考。
在阅读本指南之后，你将知道如何设计出更快、更便宜、更易于调试，且更难被糊弄的多智能体系统。
> 如果你想了解更多关于AI智能体、工作流和此类系统的实用拆解，请订阅我的Substack：@LunarResearcher
> 并在X上关注我：@LunarResearcher
## 1. 工作流不是清单
浪费AI系统性能最简单的方法，就是把顺序与依赖混为一谈。
假设你的工作流是这样写的：
1. 检查定价
2. 查看客户评论
3. 查看产品文档
4. 撰写市场简报
大多数人会按顺序执行这四个步骤，因为它们是被按顺序写下来的。
但前三步互不需要。
它们只需要在第四步之前完成即可。
所以真实的形状是：
```
定价 ──────┐
│
评论 ──────────────────┼──→ 市场简报
│
文档 ───────────────┘
```
这幅图比那个带编号的列表包含了更多的工程信息。
重要的问题不是：
“下一步是什么？”
而是：
“在这项工作开始之前，必须存在什么信息？”
这一个问题就能立刻暴露出虚假的依赖关系。
如果任务B从不使用任务A产生的任何结果，那么 A → B 就不是一个真实的依赖。
那只是在干等。
## 2. 图需要状态，而不仅仅是箭头
一旦人们发现了并行智能体，他们通常会犯下下一个错误：每个智能体都会收到一个巨大的提示词，并返回一大块文本。
这在演示中行得通。
但在真实的图中它会崩溃。
一个有用的图需要显式状态。
而不是“之前那个模型说的任何废话”。
而是真实的状态。
例如：
```
ResearchFinding {
claim
evidence
source
confidence
timestamp
}
```
现在下一个节点不是在读取一段对话。
它是在读取一个对象。
这种差异听起来很小，实际上并非如此。
结构化的状态能给你带来三样东西：
1. 可替换性。
你可以用一个执行者替换另一个，而无需重写下游的所有内容。
2. 可检查性。
你可以确切地看到什么进入了一个节点，又输出了什么。
3. 模型周边的确定性。
模型在“盒子”内部仍然可以是模糊的，但“盒子”外围的接口必须保持严格。
这就是你停止构建聊天链条，开始构建真正系统的方法。
智能体可以即兴发挥。
但图不应该这样。
## 3. 在添加另一个智能体之前，先使用依赖测试
对于你工作流中的每一个箭头，都有一个极其有用的测试：
> 这个箭头上到底跨越了什么确切的数据？
如果你无法用一句话回答这个问题，那么这条边就是可疑的。
糟糕的回答：
> “下一个智能体应该知道上一个智能体已经完成了。”
那是状态，不是依赖。
更好的回答：
> “审查员接收研究人员的声明、来源URL和证据摘录。”
现在这条边就有了意义。
你可以把这个测试应用到几乎任何工作流中：
```
审查文件 A → 审查文件 B
```
跨越了什么？
什么都没有。
删掉这条边。
```
提取发票 → 计算总和
```
跨越了什么？
发票上的数值。
保留这条边。
```
生成三个标题 → 选择最强的一个
```
跨越了什么？
三个候选标题。
保留这条边。
目标不是最大化并行度。
目标是消除虚假的同步。
## 4. 并行不是免费的
一旦人们意识到独立的工作可以同时运行，他们经常会走过头。
二十个工作者变成两百个。
两百个变成两千个。
图变得越来越宽。
账单也越来越宽。
并行减少了实际流逝的时间。
它不会奇迹般地减少工作量。
事实上，宽图通常会带来新的成本：
- 更多重复的研究
- 更多相互冲突的输出
- 更多触发速率限制的情况
- 更大的合并压力
- 更多的验证工作
- 在最后阶段需要处理更多的上下文
因此，每个严肃的图都需要一个“宽度预算”。
把它想象成内存分配。
你不会仅仅因为数据库在技术上接受连接，就启动500个数据库查询。
也不要仅仅因为你的运行环境在技术上支持，就启动500个智能体。
一条实用的规则：
> 只有当额外的执行者增加的覆盖范围大于其增加的调和成本时，才增加宽度。
五个研究人员考察五个真正不同的角度是非常好的。
五十个研究人员用略微不同的提示词搜索同一个主题，通常只是在制造噪音。
你应该优化的单位不是“智能体的数量”。
而是每美元能获得的有效独立覆盖范围。
## 5. 关键路径比总步骤更重要
线性工作流之所以慢，是因为每个持续时间都加在了一起。
如果五个任务耗时：
```
8秒 + 12秒 + 6秒 + 10秒 + 9秒
```
你的工作流大约需要45秒。
如果其中四个任务是独立的，系统可能只需要在合并前等待最慢的那个任务完成即可。
突然之间，重要的数字不再是总和。
而是关键路径。
这改变了你阅读工作流图表的方式。
不要去数盒子。
去寻找从起点到终点最长的那条不可避免的路径。
那条路径决定了延迟。
其他的一切都是优化的机会。
这就是为什么一个40个节点的图可以比一个7个节点的链完成得更快。
图更大了。
但关键路径更短了。
## 6. 在推理之前先进行压缩
这是智能体系统中最昂贵的架构错误之一：
```
20个工作者
↓
一个巨大的综合提示词
```
所有的原始输出都被塞进了一个最终的模型中。
现在最终节点必须：
- 读取所有内容
- 去除重复项
- 解决格式问题
- 注意矛盾之处
- 对发现进行排序
- 推断缺失的字段
- 然后写出答案
你已经把你最聪明的模型变成了一个垃圾收集器。
不要这样做。
在综合之前放一个归约器。
归约器应该去除那些不需要判断的工作。
例子：
```
对ID去重
按时间戳排序
按来源分组
丢弃格式错误的记录
计算投票
标准化标签
移除完全重复项
```
这其中的大部分应该是纯代码。
而不是另一个智能体。
然后你昂贵的推理节点就会接收到一个更小、更干净的数据集。
架构变成了：
```
工作者
↓
确定性归约
↓
推理 / 综合
```
这是整个设计空间中最强大的成本优化手段之一。
用模型处理模糊性。
用代码处理底层苦力活。
## 7. 验证应该是不对称的
一个执行者不应该因为捍卫自己的答案而受到奖励。
那会产生确认压力。
相反，给验证设定一个不同的目标。
执行者说：
> “找出最强有力的答案。”
验证者说：
> “找出这个答案应该被拒绝的原因。”
这不是相同的任务。
好的验证是对抗性的。
对于一个研究系统：
```
工作者：
寻找支持或解释该声明的证据。
验证者：
尝试证伪该声明。
检查来源。
检查日期。
寻找冲突的证据。
```
对于代码：
```
工作者：
实现更改。
验证者：
尝试破坏它。
运行测试。
检查边缘情况。
寻找回归问题。
```
对于战略：
```
工作者：
制定建议。
验证者：
列出此建议会失败的条件。
```
验证者应该有权终止输出。
否则它就是虚设的装饰。
一个有用的图不仅仅是创造更多的候选者。
它还会创造出一种劣质候选者必须经受得住的筛选压力。
## 8. 在图运行之前设计故障域
一个真实的图会假设节点必定会失败。
不是因为你的系统糟糕。
而是因为分布式工作总会在某些地方失败。
请求超时。
来源消失。
工具返回畸形的数据。
模型忽略了要求的格式。
工作者被限制速率。
架构上的问题是：
图的多少部分应该跟着它一起死亡？
错误的回答是：
> “全部。”
每个节点都应该存在于一个具有明确策略的故障域中：
```
失败时：
1. 重试一次
2. 使用备用模型/工具重试
3. 返回结构化的失败信息
4. 如果法定人数仍然足够，则继续运行
5. 仅当此节点是关键节点时才阻塞
```
现在，一个拥有十个研究人员的图，如果其中一个失败了，仍然可以产出一份有效的报告。
但最终的输出应该知道只有9/10完成了。
这就是弹性与无声残缺之间的区别。
永远不要隐藏缺失的工作。
让降级可见。
## 9. 人工批准是一种边的类型
这是一个重要的转变。
大多数人在建模时把人类看作另一个节点：
```
AI → 人类 → AI
```
那太模糊了。
人类通常不是在“执行工作”。
人类是在授予状态跨越边界的许可。
这使得批准更接近于一种边的条件。
例子：
```
草拟活动
↓
质量检查
↓
[ 人工批准 ]
↓
发布
```
在批准存在之前，发布节点应该是完全不可达的。
而不是：
> “模型被指示要先询问。”
也不是：
> “智能体通常会等待。”
图应该让这种不安全的转换变得不可能。
当下游操作不可逆时，这一点最为重要：
- 汇款
- 部署代码
- 给客户发邮件
- 删除数据
- 更改权限
- 向外发布
后果越严重，批准就越应该体现在架构中，而不是停留在提示词的措辞里。
## 10. 某些规则应该被冻结
智能体系统是优化机器。
这意味着它们最终会找到捷径。
如果“成功”意味着更快的发布，系统可能会削弱审查。
如果“成功”意味着更多的线索，它可能会放宽合格标准。
如果“成功”意味着更多已完成的工单，它可能会对什么算作“已解决”变得很宽容。
因此，有些规则应该游离于优化之外。
把它们看作冻结的约束。
例子：
```
未经批准绝不发布
绝不引用未打开过的来源
除非测试已执行，否则绝不标记为通过
绝不超额支出
绝不修改生产环境凭证
```
这些不是给智能体的建议。
它们是对图的约束。
在薄弱边界内的聪明优化器很快就会变得危险。
在强大边界内的聪明优化器很快就会变得有用。
## 11. 观察图，而不是聊天
聊天记录对于分布式系统来说是一个糟糕的仪表盘。
一旦工作流变成图状，你就需要图状的指标。
有用的指标出奇地简单。
关键路径延迟
最长的依赖链有多长？
这能告诉你真正的等待发生在哪里。
节点失败率
哪些工作者最常失败？
这能捕捉到脆弱的工具和糟糕的提示词。
重试率
一个每个节点重试四次才“成功”的图是不健康的。
验证者否决率
如果验证者拒绝了0%的输出，它可能毫无用处。
如果它拒绝了80%，你的工作者范围可能划分得很差。
扇出效率
有多少并行工作者产出了独特的有用信息？
这就是你的信噪宽度比。
压缩率
在最终合成之前去除了多少原始材料？
如果200个输出变成了18个有用的发现，说明归约器正在发挥有价值的作用。
人工干预率
人们在哪些地方仍然需要手动拯救系统？
那些就是你下一个架构优化的目标。
一旦你跟踪了这些指标，改进系统就会变得容易得多。
你不再是凭感觉调整提示词。
你是在优化一台机器。
## 12. 五种值得了解的图形状
你不需要一个包含五十种模式的库。
这五种图能覆盖惊人数量的实际工作。
1. 分叉 / 汇聚
```
A
↙ ↓ ↘
B C D
↘ ↓ ↙
E
```
用于研究、审计、批量分析、竞争扫描。
2. 升级阶梯
```
低成本检查
↓ 不确定？
中等成本检查
↓ 依然不确定？
强模型 / 人工介入
```
适用于大多数情况很简单，但少数情况值得昂贵推理的场景。
3. 锦标赛
```
候选 1 ─┐
候选 2 ─┼→ 评审团 → 获胜者
候选 3 ─┘
```
用于文案、设计、计划、代码方案和假设。
4. 映射 → 归约 → 验证 → 综合
```
许多工作者
↓
标准化 + 去重
↓
攻击薄弱的发现
↓
最终答案
```
用于决策级的研究和大规模审查。
5. 有界发现循环
```
搜索
↓
有新发现？
↓ 是
验证 → 加入已看列表 → 再次搜索
在以下情况停止：
- 连续N轮没有新发现
- 达到最大支出
- 达到最大时间
```
适用于你在开始前不知道问题有多大的情况。
预算是拓扑结构的一部分。
没有停止规则的循环不是架构。
那是泄露。
## 13. 一份几乎可以粘贴到任何智能体框架中的图规范
在编写代码之前，像这样描述系统：
```
目标：
在结束时必须存在什么？
输入状态：
什么结构化数据进入了图中？
并行工作：
哪些任务是真正独立的？
边数据：
每个依赖项上跨越了什么确切信息？
归约器：
什么内容可以用代码进行标准化、去重、排序或过滤？
验证：
什么独立测试可以拒绝薄弱的输出？
失败策略：
重试什么？
备选是什么？
什么可以失败而不终止运行？
预算：
最大智能体数？
最大Token/成本？
最大实际流逝时间？
人工关卡：
哪些不可逆的操作需要批准？
输出：
返回了什么确切的模式或制品？
```
这份规范比先写二十个提示词更有价值。
因为提示词优化的是节点。
而规范优化的是系统。
## 14. 什么时候你不应该构建图
图非常强大，以至于人们开始在所有地方使用它。
不要这么做。
在以下情况请使用单一智能体：
- 任务很小
- 每一步都确实依赖于前一步
- 你仍在探索问题
- 协调成本超过了工作本身
- 你需要连贯的视角，而不是广泛的覆盖
- 人类希望干预每个中间步骤
图带来的是广度、隔离和控制流。
它不会自动带来品味。
它不会自动带来真相。
它不会自动让薄弱的任务定义变得更好。
有时，一个配以正确工具的优秀智能体就是正确的架构。
重点不是把所有东西都变成图。
重点是要认清，何时一条直线正在人为地限制那些从一开始就根本不是顺序进行的工作。
# 真正的转变
第一代AI工作流是提示词工程。
然后是工具使用。
接着是循环。
现在更难的技能是编排。
不再是“我该如何让模型变得更聪明？”
而是：
- 什么可以同时运行？
- 应该共享什么状态？
- 什么永远不应该被共享？
- 什么需要验证？
- 当一个工作者死亡时会发生什么？
- 什么被允许继续运行？
- 成本在哪里会爆炸？
- 人类还在哪里掌握着关键？
这就是执行任务的AI与能够掌控整个流程的AI系统之间的区别。
更多的智能体不是解决之道。
更好的拓扑结构才是。
如果你读到了这里：
- 收藏本文。
- 关注 @LunarResearcher
- 关注我的 Substack
- 关注我的私密 Telegram 频道
## 相关链接
- [Lunar](https://x.com/LunarResearcher)
- [@LunarResearcher](https://x.com/LunarResearcher)
- [35K](https://x.com/LunarResearcher/status/2086071302272528833/analytics)
- [@LunarResearcher](https://x.com/@LunarResearcher)
- [@LunarResearcher](https://x.com/LunarResearcher)
- [@LunarResearcher](https://x.com/@LunarResearcher)
- [Substack](https://substack.com/@lunarresearcher)
- [Private Telegram Channel](https://t.me/+O4FFj3BmnJRiODhi)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:45 PM · Aug 8, 2026](https://x.com/LunarResearcher/status/2086071302272528833)
- [35.2K Views](https://x.com/LunarResearcher/status/2086071302272528833/analytics)
- [View quotes](https://x.com/LunarResearcher/status/2086071302272528833/quotes)
---
*导出时间: 2026/8/9 20:49:29* 
