本文目录16 个章节
绝大多数人上手搭多步骤 Agent，最后都只画出了一条单向串行的直线：第一步、第二步、第三步——后一步非得礼貌地死等前一步跑完才肯动。
10 个人里有 9 个稍加盘点就会发现：里面至少有一半的步骤压根用不着等待。
不走路由，不做分支，更不搞并发。所有任务全在傻排队——单核脑子、单重上下文、一次只咬一件事，直到把窗口活生生塞爆，Agent 连自己最初要干啥都忘得精光。
这份 14 步路线图，就是要帮你把单排长蛇阵彻底重构成图架构：拉起 Agent 舰队横向并发扇出，自动挑刺校验，最终收敛出单体 Agent 压根吃不下的重磅成果。
Single Line vs. Graph Architecture
LINEAR (Single-file queue)
┌────────┐ ┌────────┐ ┌────────┐
│ Step 1 │ ──> │ Step 2 │ ──> │ Step 3 │ (Sequential & Slow)
└────────┘ └────────┘ └────────┘
GRAPH (Parallel fleet)
┌────────┐
┌─>│ Node A │─┐
┌────────┐ │ └────────┘ │ ┌────────┐
│Dispatch│──┼─>│ Node B │─┼─>│ Merge │ (Concurrent & Fast)
└────────┘ │ └────────┘ │ └────────┘
└─>│ Node C │─┘
└────────┘有个硬核转变绝大多数人都没说透：提示词不过是一句话，循环不过是原地转圈，运行底座只是 Agent 脚下的地板。
但任务本身的逻辑形态——谁先谁后、谁能并行、谁非得等全套拿齐——这种形态天生就是一张图。节点负责动脑推演，边负责搬运成果。
Claude Code 刚出的新武器直接把构图能力给到了底层：动态工作流（Dynamic Workflows）。
Claude 亲自写一段纯 JavaScript 编排脚本，接着拉起一整支 Agent 舰队分工去干——而中间的调度协调完全是代码控制，消耗 0 个模型 Token，压根不用浪费对话。
01. 节点管干活，边管流转
一张图归根结底就 2 样东西，把这两样揉碎搞透，大部分伪概念瞬间烟消云散。节点就是独立干活的单元：1 个 Agent，1 项有界任务，1 份明确输入，1 份明确输出。
边只代表纯粹的依赖：无非就是拿这 1 个节点的产出来做那 1 个节点的输入，再无其他。
Nodes & Edges Anatomy
┌─────────────────────────┐ EDGE ┌─────────┐
│ NODE │ (Dependency) │ │
│ • One agent │ Data Flow (JSON) │ Node B │
│ • One bounded job │ ────────────────────────> │ │
│ • Validated input/out │ └─────────┘
└─────────────────────────┘ Node B consumes
Node A's output最容易掉进去的陷阱，就是把口语里的“然后”硬当成依赖边。“帮我总结文件，然后顺便看下天气”——这两者之间压根没有边，因为查天气又不吃总结出的文本。
这明明是 2 个八竿子打不着的节点，普通脚本却硬把它们串成一串。只有当数据真正从上面流过去，这条边才成立。
养成个习惯，对着工作流里的每一个“然后”砍一刀：下一步非得吃上一步吐出的数据吗？要是不需要，那就压根没边，让你死等纯粹是浪费时间。
Draw it as boxes and arrows. A box is an agent() call.
An arrow is a variable passed from one call’s return into another’s
prompt. If you can’t draw the arrow - if no variable crosses - the two
boxes are independent, and independence is the thing you’ll exploit
for the rest of this course.02. 你的线性脚本只是退化的图
当你把 Agent 写成“先做 A、再做 B、接着做 C、最后做 D”，你其实是在画一张全天下最拉胯的图：一条没分支的死单链。每个节点只有 1 进 1 出。
能跑通归能跑通，但它又慢又脆。单链没有任何容灾能力：一旦 C 卡壳，D 终生触发不了，前面 A 费劲算出来的成果全烂在上游。
Redrawing the Linear Chain
DEGENERATE CHAIN (Fake edges, sequential wait)
┌───────────┐ fake edge ┌───────────┐
│ Audit A │ ───────────────>│ Audit B │ (File B doesn't read A)
└───────────┘ └───────────┘
REFACTORED GRAPH (Cut fake edges, run parallel)
┌───────────┐
┌─>│ Audit A │─┐
┌────────┐ │ └───────────┘ │ ┌───────────┐
│ Input │──┤ ├──>│ Synthesize│
└────────┘ │ ┌───────────┐ │ └───────────┘
└─>│ Audit B │─┘
└───────────┘图工程的第 1 招，就是重新重构这条长链。把现有的脚本拉出来，对着每个箭头照着 Step 1 的逻辑狠狠问一遍。
绝大部分脚本里都有 2 到 3 个根本不跑数据的伪箭头——无非是你按顺序顺手敲下来的代码次序罢了。
果断剪断这些伪箭头，死链瞬间拉开成宽网：好几个独立节点直接齐头并发，最后把成果一股脑喂给 1 个需要全量数据的汇总节点。
03. 给每一个节点立下硬契约
你拿捏不住边界的节点，就根本没法做并发。
输入必须显式塞进来，绝不瞎猜上下文；输出必须是校验过的固定 Schema 结构，下游节点拿过来就能直接吞，免去一切人工猜度。
Node Schema Contract
[ Input JSON ] ─────────> ┌──────────────────┐ ─────────> [ Validated Output ]
{ key: "value" } │ Subagent │ { status: "ok",
│ (Tool Layer) │ data: [...] }
└──────────────────┘
Auto-retry on
Schema Mismatch在真实工作流里，这份契约全靠 Schema 在工具调用层硬性压制。你调 agent() 传入 JSON schema，子 Agent 就非得吐出校验通过的结构化 JSON 不可；一旦对不上，底层自动触发重试，而不是塞给你一堆自由文本让你凭运气解析。
// A node with a real contract: bounded in, validated out, one job.
const ITEM = {
type: 'object', additionalProperties: false,
properties: {
title: { type: 'string' },
url: { type: 'string' },
impact: { type: 'string', enum: ['high', 'medium', 'low'] },
},
required: ['title', 'url', 'impact'],
};
const result = await agent(source.prompt, {
label: `research:${source.key}`,
schema: ITEM, // forces validated structured output
agentType: 'general-purpose',
});
// result is now a shape the next node can trust — not free text.04. 把边当成严肃的数据契约
边绝不是一句“B 在 A 后面跑”。它是传输承诺：A 吐什么格式，B 就接什么格式。按流动的数据给边命名，而不是按顺序命名，有 2 件事会瞬间变得明明白白。
The Edge as a Data Contract
┌──────────────┐ Array of JSON ┌─────────────────────────┐
│ Workers N │ ──────────────────────> │ Deterministic JS Edge │
└──────────────┘ │ .flatMap() & Set │
└────────────┬────────────┘
│ Free! Zero Tokens
▼
┌─────────────────────────┐
│ Deduplicated Results │
└─────────────────────────┘你可以一眼验出这条边是真是假（到底跑没跑数据？），而且只要结构契约不变，两头的节点你随便换，整张图稳如泰山。
工程落地上，边无非就是纯 JavaScript。扇出和最终合成之间的去重、展平、过滤，全是几行原生代码在处理节点返还的数据。
图思维最爽的一点就在于：大家原先花大把真金白银烧 Token 让模型处理的事，本质上只是一条边——而用代码写边，一个 Token 都不花。
The temptation is to spawn an agent to “combine the results.” Resist
it. If combining means flatten-and-dedupe, that’s results.flatMap(...)
and a Set — deterministic, instant, zero tokens. Save agents for
judgment, not for plumbing. A graph where every edge is an agent is a
graph paying rent on its own wiring.05. 用 parallel() 暴力并发扇出
这就是能把之前开销通通赚回来的核心大招。手上握着 N 个独立任务——N 个数据源、N 个代码文件、N 个路由接口——千万别傻乎乎串成长蛇阵。
直接让 Claude 展开扇出并发。代码里写 parallel()，Claude 拿个任务数组，直接拉起对应数量的子 Agent 齐头并进，最后把全量结果扔还给你。
parallel() Fan-Out Barrier
┌────────────────────────────────┐
│ parallel([thunk1, thunk2...]) │
└───────────────┬────────────────┘
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Worker 1 │ │ Worker 2 │ │ Worker 3 │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
└───────────────────────┼───────────────────────┘
▼ (Wait for all)
[ .filter(Boolean) ]2 个细节决定了系统的硬核稳定性。第 1，parallel() 本身是道屏障关卡，必须等所有任务跑完才返回，保证下阶段拿到完整全集；第 2，跑崩的任务自动降级成 null，绝不会因为 1 个子 Agent 发疯就砸掉整盘棋。
拿到结果顺手接个 .filter(Boolean) 把 null 扫掉。底层并发受限于 CPU 核心数，多出来的自动排队，你就算一次性塞入 100 个任务也能稳稳消化——不过是按窗口分批并发罢了。
phase('Research');
// Nine sources, nine agents, all at once.
const raw = await parallel(
SOURCES.map((s) => () =>
agent(s.prompt, {
label: `research:${s.key}`,
phase: 'Research',
schema: ITEM_SCHEMA, // each node returns validated JSON
agentType: 'general-purpose',
}),
),
);
const collected = raw.filter(Boolean); // drop the nulls from failed agents并发扇出全在 Claude 写的脚本里跑，压根没占用主对话。主会话从不用一次性吃下 9 个数据源的硬材料——子 Agent 各自背着各自的上下文，最后只把精炼答案交回主线程。
编排调度层消耗 0 个 Token，因为它纯粹是代码运行，根本不用消耗模型思考。
06. 在屏障节点完成收敛扇入
散出去的活后面得有人收场，扇出才有意义。扇入（fan-in）就是各条边交汇的汇总节点——在这里，1 个 Agent（或 1 段代码）能把上游出来的全量成果尽收眼底，做全局去重、权重排序或空包熔断。这是屏障节点赚回等待时延的唯一正当理由。
Fan-In Barrier Node
┌──────────────────┐
│ Parallel Workers │ ───┐
└──────────────────┘ │
┌──────────────────┐ ├─> ┌─────────────────────────┐ ──> [ Curated Set ]
│ Upstream Edges │ ───┤ │ Barrier Agent Node │
└──────────────────┘ │ │ (Dedupe & Rank All) │
┌──────────────────┐ │ └─────────────────────────┘
│ Complete Inputs │ ───┘
└──────────────────┘只有当后续阶段非得拿齐所有上游结果不可时，才许设屏障。
// The edge: plain JS, no agent, zero tokens.
const flat = collected.flatMap((c) => c.items);
log(`Collected ${flat.length} items`);
phase('Curate');
// The barrier node: needs the WHOLE set to dedupe + rank.
const curated = await agent(
`Dedupe and rank these by impact:\n${JSON.stringify(flat)}`,
{ phase: 'Curate', schema: CURATED_SCHEMA },
);如果只是把列表压平？那纯属代码边的活，内联搞定。架构代码坏味的识别极为残酷：你要是写成了 parallel → transform → parallel，而中间的 transform 又无跨项依赖，赶紧改成流水线（pipeline），别硬设屏障卡时间。
07. 菱形拓扑：拆分 → 执行 → 归集
把扇出和扇入凑到一块，你就得到了所有硬核 Agent 系统里最扛打的主力拓扑：菱形拓扑（The Diamond）。
1 个节点拆任务，多节点并发拉满，1 个节点收尾归集。这是竞品调研、依赖审计、代码 Review、深度研报背后的通用套路——换掉提示词和数据源，这套骨架直接到处套用。
The Diamond: Split -> Work -> Merge
┌──────────────┐
│ Split Job │
└──────┬───────┘
┌─────────────────────────┼─────────────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Worker 1 │ │ Worker 2 │ │ Worker 3 │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
└─────────────────────────┼─────────────────────────┘
▼
┌──────────────┐
│ Reduce (JS) │
└──────┬───────┘
▼
┌──────────────┐
│ Synthesize │
└──────────────┘它的工业标准范式叫：扇出并发（fan out） → 纯代码归集（reduce） → 最终合成（synthesize）。
一旦把菱形拓扑琢磨透，你就再也不会去问“怎么让 Agent 多做几步”，而是开口就问“哪里该拆并发，哪里该做归集合并”——这才是能搞定高并发的真正关键。
08. 用条件分支做动态边路由
图架构可不是死板硬编码的。走哪条边，往往看前置节点挖到了什么。路由节点（router node）看一眼结果，直接决定点火哪条下游路径：工单分类后分给对应模块，或者看 diff 体量决定走快速 Pass 还是拉起全量并行审计。
在工作流里，这无非是对节点吐出的结构化数据写几行普通 JavaScript 的 if 或 switch，控制流完全交由纯代码调度。
Runtime Conditional Edge Routing
┌──────────────────┐
│ Classify Agent │
└────────┬─────────┘
│ returns { severity }
▼
< Code Conditional >
│
┌────────────────┴────────────────┐
severity == 'high' severity == 'low'
▼ ▼
┌───────────────────────┐ ┌───────────────────────┐
│ Parallel Full Audit │ │ Single Quick Pass │
└───────────────────────┘ └───────────────────────┘确定性代码的优势就在这儿。分类决策可以让 Claude 动脑，但路由执行全由 Claude 自动写的原生代码跑——相同分类出什么结果，100% 稳定可靠。
节点用上 Claude 的脑力，边拿住代码脚本的确定性。
// Router node: an agent classifies, code picks the edge.
const { severity } = await agent(
`Classify this diff's risk:\n${diff}`,
{ schema: { type: 'object',
properties: { severity: { enum: ['low', 'high'] } },
required: ['severity'] } },
);
let review;
if (severity === 'high') {
// heavy path: full parallel audit
review = await parallel(FILES.map((f) => () => agent(`Audit ${f}`)));
} else {
// light path: one quick pass
review = await agent(`Quick review of ${diff}`);
}09. 在数据边上安插独立验证节点
图架构真正的杠杆绝不是多拉几个 Agent——而是包裹在它们外层、能带来绝对可信度的工程防线。
验证节点（Verifier Node）守在数据边出口，在结果传给下游前，它的唯一任务就是拼命找茬挑刺、打杀结论。能扛过去的放行，扛不过去当场毙掉，绝不让脏数据溜进最终答案。
Verifier Node on the Edge
[ Worker Finding ] ──> ┌────────────────────────────────┐
│ Verifier (Fresh Context) │
│ • Lens 1: Correctness │
│ • Lens 2: Security │
│ • Lens 3: Reproduction │
└───────────────┬────────────────┘
│ Majority Vote
┌────────┴────────┐
Passed Failed
▼ ▼
[ Forward Edge ] [ Dropped ]-
对抗性校验（Adversarial verify）：针对每项结论，拉起 N 个独立质疑 Agent 去驳斥它；只有通过多数裁判把关的发现才许保留。
-
多视角校验（Perspective-diverse verify）：给各个验证节点不同的侧重点（正确性、安全性、可复现性），多视角交叉审查能揪出 10 个同质化检查永远漏掉的坑。
-
裁判团机制（Judge panel）：多角度生成 N 方案，并行裁判节点打分评选，拿胜者方案当主干，顺手把亚军方案里的好点子缝合进来。
实际工程里，曾有团队把 Bun 运行时代码移植过去，靠的就是在循环里深度缝合了这套对抗审查拓扑。
10. 隔离节点运行环境，防止单点故障污染全图
单链架构下，一点故障直接级联瘫痪：C 挂掉，D 终生没法跑，全盘挂起。
但在图架构里，单个节点挂掉必须就地隔离，决不能污染全局。
写归集节点时要做好容灾准备，允许输入缺斤少两，别死板假设每次都能拿到全量数据。
Isolated Node Execution (Worktrees)
┌─────────────────────────┐
│ Main Repository Branch │
└────────────┬────────────┘
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Worktree 1 │ │ Worktree 2 │ │ Worktree 3 │
│ (Sandbox A) │ │ (Sandbox B) │ │ (Sandbox C) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
└───────────────────────┼───────────────────────┘
▼ (Clean Merge)
┌─────────────────────────┐
│ Consolidated Refactor │
└─────────────────────────┘更致命也更隐蔽的死法是节点互相踩脚：多个 Agent 并行写文件，改动直接互相踩爆覆盖。
解法叫“环境隔离”：给每个 Agent 开独立的 git worktree，在沙盒里改完代码，最后干干净净合并回来。
只有节点涉及并发写代码时才用它。这是为 1 种特定拓扑准备的安全带，不用逢跑必交这份额外税费。
11. 引入受控环路，并确保其必须收敛
有时候不深钻进去，你压根不知道任务量多大：比如未知体量的探索，排查出 1 个 Bug 顺带又炸出 3 个新漏洞。
这就需要引入环路（cycle）——一条指向前面节点的受控返回边。
坑点也非常直白：要是一直不收敛，这玩意儿就是个死循环吞金兽，疯狂生成 Agent 直到把你的钱包掏空。
Loop-Until-Dry Convergence
┌──────────────────────────────────────────────┐
│ Spawn Finders in Parallel │
└──────────────────────┬───────────────────────┘
▼
┌──────────────────────────────────────────────┐
│ Dedupe Fresh Findings vs. ALL SEEN SET │
└──────────────────────┬───────────────────────┘
│
┌──────────┴──────────┐
New Findings 0 New (Dry)
▼ ▼
[ Verify & Add ] [ dry_count++ ]
│ │
└──────────┬──────────┘
▼
< Is dry_count == 2? > ──(Yes)──> [ STOP ]
│
(No)
│
└───> (Loop back)保证收敛的标准模式叫 loop-until-dry（循环直到抽干）：不断派探针去挖，直到连续 K 轮颗粒无收，立刻停机。
决定成败的 1 个细节（也是新手 100% 踩坑的地方）：你拿什么做去重基准。
去重必须对照“全量已知发现（seen）”，绝不能只比对“已确认保留的成果（confirmed）”。
const seen = new Set(); const confirmed = []; let dry = 0;
while (dry < 2) { // stop after 2 empty rounds
const found = (await parallel(
FINDERS.map((f) => () => agent(f.prompt, { schema: BUGS }))
)).filter(Boolean).flatMap((r) => r.bugs);
const fresh = found.filter((b) => !seen.has(key(b)));
if (!fresh.length) { dry++; continue; } // nothing new → toward dry
dry = 0;
fresh.forEach((b) => seen.add(key(b))); // dedupe vs SEEN, not confirmed
// diverse-lens verify each fresh finding before it counts
const judged = await parallel(fresh.map((b) => ()=>
parallel(['correctness', 'security', 'repro'].map((lens) => ()=>
agent(`Judge "${b.desc}" via ${lens} — real?`, { schema: VERDICT })))
.then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))));
confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));
}12. 跨节点分级混配模型
绝对没必要让每个节点都顶着最高阶模型跑。图架构把分工拆得极为清晰：有的节点纯属机械劳动（提取字段、工单打标），有的节点才真吃脑力（合成研报、裁定争议）。
Tiered Model Routing Across Nodes
REPETITIVE / BOUNDED NODES (Fan-Out)
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Extractor │ │ Reviewer A │ │ Reviewer B │ ──> [ Cheaper Tier Model ]
└──────────────┘ └──────────────┘ └──────────────┘ (e.g., Haiku / Flash)
JUDGMENT / SYNTHESIS NODES (Fan-In)
┌────────────────────────────────────────────────────┐
│ Adjudicator & Report Synthesizer │ ──> [ High Tier Model ]
└────────────────────────────────────────────────────┘ (e.g., Opus / Pro)把枯燥机械活降级丢给便宜模型，把贵重 Token 集中花在核心决策节点上。
在工作流里，子 Agent 默认继承你当前的会话模型。要是不在脚本里手动覆盖，整套大并发跑下来直接顶格扣费。
只需在 agent() 调用里加上 model 参数，就能直接把这个节点的计算分流到轻量模型上。
跑大任务前先打 /model 瞄一眼，让 Claude 把并发扇出里的重复节点一律分流给低成本模型，只给归集节点保留顶级高配。不改动一行拓扑结构，瞬间把吃 Token 的吞金兽变成性价比神器。
13. 拓扑结构直接决定成本与延时
图架构的形态可不是花架子，它是控制实际时延最大的杠杆。最让人纠结的选择：parallel() 还是 pipeline()。parallel() 屏障必须硬等全批次里最慢的那 1 个节点跑完，下一阶段才能开工。
parallel() Barrier vs. pipeline() Stream
PARALLEL BARRIER (Waits for slowest item in batch)
Stage 1: [=== Item A ===] [======= Item B (Slow) =======]
Stage 2: [=== Merge ===]
PIPELINE STREAM (Items flow independently)
Item A: [=== Stage 1 ===]──>[=== Stage 2 ===]──>[=== Done ===]
Item B: [======= Stage 1 (Slow) =======]──>[=== Stage 2 ===]──>[=== Done ===]而 pipeline() 允许数据项各自流转、完全不设屏障：数据项 A 都跑完 Stage 3 了，数据项 B 可能才刚进 Stage 1。跑得快的直接先冲过终点线，不用被慢的死死拖住。
无脑优先选流水线 pipeline()。
14. 交给 Claude 动态构图——自路由
终极大招：对于无法提前预判全貌的任务，压根不用你自己手画图架构。
开起动态工作流，你只需把目标说清楚，Claude 自动现场写编排脚本——拆任务、设并发、组建 Agent 舰队、归集合成全套搞定。
Claude Code Dynamic Self-Routing Workflow
User Prompt: "workflow audit src/routes/ for missing auth"
│
▼
┌─────────────────────────┐
│ Claude Script Generator │ (Zero Token Coordination)
└───────────┬─────────────┘
▼
┌─────────────────────────┐
│ Fleet Spawn (Parallel) │
└───────────┬─────────────┘
▼
┌─────────────────────────┐
│ Verifier Pass & Merge │
└───────────┬─────────────┘
▼
[ Clean Final Report ]入口有 3 种：提示词里带上“workflow”直接让 Claude 现场写；或者跑现成的，比如自带的 /deep-research 就是个生产级真实图架构（定范围 → 并行搜索 → 抓取 → 对抗校验 → 合成），完美套用本课程的标准骨架。
或者直接开启 ultracode 模式，Claude 会为会话里每个大任务自动组装工作流。跑满意了敲个 s 键把脚本存进 .claude/workflows/——有版本控制、支持按名随时复用，同仓库任何人拉下代码都能一键启动。
› Run a workflow to audit every route under src/routes/ for missing
auth. Spawn one agent per route file, then verify each finding before
reporting. ● Claude wrote an orchestration script · launching in
background… /workflows — auth-audit · running ✓ Scope 1/1 2.1k tok ·
4s ✓ Fan-out 18/18 one agent per route file ◯ Verify 11/18 3-vote
skeptics per finding… ○ Synthesize 0/1 waiting on verify session stays
responsive — keep working while the fleet runs本周可用 Claude 搭建的 6 种图拓扑
Six Production Graph Topologies
1. Security Sweep ─────────> Parallel Audit + Verifier Gate
2. Deep Research ──────────> Scope -> Search -> Dedupe -> 3-Vote Verify
3. Module Porting ─────────> Parallel Porting + Test Suite Loop Gate
4. Diff Review ────────────> Diff-Size Router -> Multi-Lens Judge Panel
5. Scheduled Digest ───────> Parallel Fetch -> Impact Barrier -> Digest
6. Bug Discovery ──────────> Loop-Until-Dry Cycle + Seen Set Dedupe-
全路由安全扫掠：每个路由接口开 1 个子 Agent 分头排查鉴权漏洞，再由验证节点统一关卡打杀伪漏洞。这是单重上下文根本吃不下的广度。
-
自带的 /deep-research 研报图：Claude Code 厂出自带。自动拆解多角度问题，并发搜索去重，落笔前拉起 3 票裁判做对抗校验。
-
逐文件移植代码模块：把 Bun 团队的极限操作搬进你的项目。跨文件并发扇出重构，单测做死门禁，报错送回循环反复重跑。
-
Diff 对抗审查：按代码改动量做动态路由，小改动 1 次快速 Pass，大改动直接触发正确性、安全性、性能等多视角并发审计，裁判团收尾合成。
-
定时生态巡检：一次存盘、永久复用。并发抓取发布公告、技术博客、社区讨论，在屏障关卡做权重排序生成简报，存进 .claude/workflows/ 按名字随时拉起。
-
未知范围排查：不知道库里藏着多少 Bug。并发跑探针 Agent，对照已见全集去重，验证存活项，持续循环直到连续 2 轮颗粒无收自动停机。
结语
提问者抛出问题，架构师绘制图表。
单线程 Agent 从来不是性能天花板——它只是大家手头最先抓到的第 1 种形态，纯粹是因为它顺着我们平时敲代码的直觉。1 条线、1 个单核大脑、一次死磕 1 件事。
一旦你看透了节点和边，你就不再逼着单个 Agent 机械做更多步骤，而是指挥图架构向横向拉开广度：任务独立处做并发扇出，需要置信度处立数据边关卡，不吃脑力处分级下放模型。
而真正掌握图架构的人，早已在驾驭 Agent 舰队集群奔袭——再也不会撞上死困着其他人的天花板。
REFERENCES