智能体为何总在线性链条里空转：图拓扑如何成为真正的成本杠杆

大多数人动手做多步AI智能体时都会落到同一种形状步骤一然后步骤二然后步骤三每一步都礼貌地等上一步彻底完成才开始。它能跑。但它也白白浪费了自己大量时间因为其中相当一部分步骤根本不需要等待任何东西。这是替代方案的实践指南把智能体系统当成图而不是链来设计。不是比喻而是真正不同的系统设计方式——独立工作同时跑结果只在真正需要的地方汇合图的形状本身成为你对成本、速度和可靠性的最大杠杆。我们从零开始拆线性方式到底哪里坏了看清图真实形状的词汇几乎覆盖所有场景的几种拓扑怎么落地它们安静失败的地方以及接下来往哪走。贯穿全文的具体实现是Claude Code已经上线的动态工作流但底层思考适用于任何协调多个AI智能体的场景。我起初以为线性链条只是“自然”的写法后来对着实际长任务和Anthropic团队的复盘看下去才发现它在三个明确的失败模式上几乎必然崩坏。Agentic laziness——智能体在多部分任务中途停下只完成部分却宣布结束安全审查悄悄覆盖50项里的35项就是教科书案例。Self-preferential bias——当智能体被要求检查或评判自己的输出时它倾向于偏爱自己已经产出的东西。Goal drift——多轮之后对原始要求的保真度下降尤其是对话被总结后边缘情况和“不要做X”的约束最先丢失。这些都不是靠在链上再加几步能解决的。它们靠改变形状解决给每块工作自己干净的上下文在结果被信任前先检查而不是让一个越来越重的上下文既干活又给自己的作业打分。同一个任务画两种方式。在链里C卡住会把A已经做完的工作晾在半路。在图里三个独立节点从头就没必要互相等待。一个简单诊断能暴露典型链条里有多少其实不必要对流程里每一个“然后”问下一步是否真的读取了上一步的输出。“总结文件然后查明天的天气”——天气并不消费总结这是两个独立工作被线性脚本硬链在一起买来的等待毫无价值。一旦注意到这点重构就变得明显线性链本身也是图只是你能画出来的最小、最脆弱的一种——单条无分支路径每个节点恰好一条入边和一条出边。没有冗余。一个环节卡住下游全部停上游结果也无处可去。修复不是更长的链而是更宽的图。节点是一个有界工作单元一个智能体一个清晰范围的任务一个输入进一个输出出。不是“处理客户对话”而是更窄的“分类这一张工单”或“检查这个文件里某一类特定bug”。边是依赖它说这个节点的输出喂那个节点的输入。仅此而已。顺序不是边。提示词里的邻近也不是边。让边真正成立的唯一条件是数据确实跨过它——一个节点产生、另一个节点真正需要的结果。对已经建好的任何智能体跑这个测试你画的每条箭头能不能指出跨过它的具体数据如果没有东西跨过两步就是独立的中间的等待纯属开销。节点只有带着契约才安全接入更大的图有界输入以及定义好的、最好经过验证的输出形状——可直接使用的结构化数据而不是下一节点还要解析并祈祷它成立的自由文本。这让你能在边的两端替换智能体或并行跑多个节点而不会在输出稍微变样时整系统悄悄散架。一旦节点和边清楚了少数几种形状就能覆盖几乎所有真实智能体系统。按你通常会先碰到的顺序Fan-out。有多个独立任务——N个来源要查、N个文件要审——就同时跑而不是轮流。这里真正重要的设计纪律是韧性一个节点失败不该拖垮整批。把fan-out建成失败单元返回空值而不是崩溃再在下一阶段过滤空值。Fan-in在屏障处。Fan-out只有在有东西汇合时才有用。屏障是上游每个结果都必须到齐才能启动下一步的点它应该是例外而不是默认。只有当某阶段真正需要整套结果在一起时才用跨所有来源去重、给完整列表排序、因为什么都没回来而决定提前停止。钻石形。把fan-out和fan-in合在一起就得到几乎每个严肃智能体系统背后的形状拆分、工作、合并。经典版本有三部分值得单独命名——fan-out收集广度用几行普通代码做压缩展平列表、去重确定性且免费因为没有智能体参与再用一个最终智能体在完整压缩集上真正写出答案。路由。图里的路径不都是固定的。路由节点检查结果并决定下一条边触发——分类支持工单再送到正确处理者检查代码变更有多大再选择快速审查或完整审计。分类可以来自智能体的判断但路由本身是普通代码同样输入永远走同样路径没有埋在模型脑子里的意外决策。验证。图的真正杠杆不是更多智能体干活而是包在它们周围、用来产生对发现结果信心的结构。验证器坐在边上下游之前唯一工作是尝试证伪这个发现。它活下来就向前传活不下来就永远不到你的报告里。收敛的循环。有些任务事先不知道规模——开放式bug猎取找到一个问题会暴露另外三个。这需要受控回环到更早节点。危险很明显没有退出条件的循环是无限循环整预算都花在重新发现同一片地面上。真正能工作的版本是loop-until-dry继续直到连续几轮都没有新东西然后停止——并且关键的是把每个新发现与你见过的一切比较而不只是已确认的否则被拒绝的结果会永远浮出水面。这六种形状不是图论练习它们干净映射到Anthropic Claude Code团队命名并文档化的动态工作流模式classify-and-act路由、fan-out-and-synthesize钻石、adversarial verification验证器、loop until done收敛循环。另外两个补全官方集合也值得知道generate-and-filter批量生成候选只保留通过量规的和tournament智能体在同一任务上竞争评判两两比较直到一个胜出适合命名、排名或任何更比较性的判断。隔离失败隔离写入。并行跑节点时两件不同的事可能出错需要两种不同修复。第一种是节点直接失败——把fan-out设计成抛错解析成空值而不是拖垮整次运行。第二种更微妙节点写同一批文件时会互相碰撞。当真发生时——多个智能体编辑共享代码库——给每个独立工作区之后再合并而不是让它们中途踩脚。这是需要它的拓扑的安全带不是每张图都要交的税。跨图分层模型。不是每个节点重量一样。提取一个字段或分类一张工单的节点有界且重复合成最终报告或裁决争议发现的节点才是真正判断所在。前者用更便宜的模型后者留给最好的模型。这必须故意做默认情况下你生成的每个节点继承启动它的会话模型所以分层只有你逐节点指定才会发生。拓扑才是你真正的成本杠杆。这是最容易绊倒人的选择。屏障让每个下游步骤等待最慢的上游完成即使其他九个只花了零头时间。让每个项目独立流过每一阶段、没有同步点意味着快的项目可以领先慢的三阶段而不是无故在它后面空转。默认让项目独立流动。只有当某阶段真正不能在没有完整集合时继续——跨集去重、基于总量的提前退出、与其他所有发现的比较——才伸手拿屏障。“这样代码更干净”不是那些理由之一额外等待是真实可测量的时间它必须赚到自己的位置。在Claude Code里你可以直接描述目标并说你想要它作为工作流完成或用触发词ultracode确保生成工作流而不是普通来回处理。对任何你想再跑的东西——周期性分流、每周研究摘要——配上循环调度和硬完成条件并封顶一次运行允许花的token免得雄心勃勃的工作流胀到超出预期。一次运行效果好时保存它生成的脚本它变成可版本化的可复用资产而不是下次还要从头描述。真实案例是大型迁移。Bun的运行时从Zig到Rust的重写正是这个形状把工作拆到一个智能体能自信hold住的单元——一个调用点、一个失败测试、一个模块——每个修复在自己隔离工作区起一个子智能体再有第二个智能体对抗性审查每个变更然后合并。没有人写五十个顺序提示。一个脚本协调舰队审查被建进拓扑本身而不是事后螺栓上去。虚假边。因为你按那个顺序打字就链两步而不是第二步读取第一步输出。等待买不到任何东西。默认屏障。因为感觉更整洁就伸手拿同步等待而下一阶段其实不需要完整集合。延迟是真实的而且是浪费的。给自己的管道付租金。起一个智能体去展平列表或去重数组——几行确定性代码就能做、成本为零的工作。把智能体留给判断而不是接线。永远不干的循环。只对新发现与已确认的去重而不是与曾经浮现的一切。被拒绝的结果每轮再出现循环永远付费重新发现同一个死胡同。时间压力下跳过验证。在任何东西尝试证伪之前就放行发现安静地把懒惰、自我偏好这些验证本来要抓的失败模式重新引进来。在你不需要时伸手拿它。Anthropic自己的指导很直接大多数任务不需要五人评审团图必须像任何其他架构决策一样赚到自己的协调成本。快速单次提示对大多数快速单次工作仍是正确工具。手绘的图已经是线性链的一大步但还不是天花板。更有趣的前沿不是手动画图而是描述目标让系统自己分解任务、选择自己的fan-out、写出为那次具体运行量身定制的编排脚本而不是你希望能适配所有进来案例的固定形状。它也让图变成共享资产而不是个人习惯。一次特别好的运行生成的脚本可以保存、提交仓库、交给队友按名字启动——团队里任何人都能复用的图而不只是碰巧第一次建它的人。如果你想找具体起点这六种真实形状值得建映射到上面的模式跨所有路由的安全扫描——每个文件一个子智能体各自猎取特定类别问题验证器在每个发现到达报告前确认。有引用的研究报告——并行搜索、拉取来源、每个声明对抗性对照来源实际所说再合成。逐文件移植模块——每个修复一个智能体在自己工作区第二个智能体审查每个变更再合并。diff的对抗性审查——按大小路由小变更一次快速通过大变更触发多透镜完整审计。快速变动空间的周期性扫描——多来源并行检查屏障处排序保存后下周不用从零重建再跑。开放式发现——寻找者并行跑每个新结果与见过的一切去重循环直到连续几轮没有新东西。再试两种tournament用于更比较性的决策——命名某物、给短名单排序generate-and-filter用于你宁愿生成二十个候选再保留通过量规的三个而不是一次就想做对。就像启发这篇的那条线所说提示者问一个问题。架构师画一张图。转变不是让智能体多做几步而是对每一个来到你面前的工作问它真正在哪里分裂又在哪里需要重新汇合我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。