智能体设计模式

你大概遇到过这种情况：想让大模型自己查资料、调工具、分几步把活干完，结果 Prompt 越堆越长，改一处崩一处。或者团队里有人喊要上多智能体，做出来却比单个模型还慢还贵。这篇不讲概念史，只按「一件活交给谁、怎么拆、在哪停」三个问题，把常见设计模式过一遍，并给出什么时候不该用它们的判断标准。

你大概遇到过这种情况：想让大模型自己查资料、调工具、分几步把活干完，结果 Prompt 越堆越长，改一处崩一处。或者团队里有人喊要上多智能体，做出来却比单个模型还慢还贵。这篇不讲概念史，只按「一件活交给谁、怎么拆、在哪停」三个问题，把常见设计模式过一遍。

先说清定位：设计模式不是架构图上的名词收藏，而是帮你做取舍的检查表。每引入一个模式，你都多付一笔代价——多一跳调用、多一份上下文、多一个出错的地方。所以下面每一节都配一条判断线和一个不适用情况，照着问自己，答不上来就先别上。

先判断要不要多个智能体

顺序很重要：先问「一个够不够」，答案是不确定就不要拆。单智能体加工具调用能覆盖的范围有明确边界——任务步骤可以提前枚举出来，单次决策不需要另一个角色来交叉验证。只要这两条都成立，先做单智能体，跑通了再谈拆。

拆角色的第一条规矩：按「职责」拆，不按「技能」拆。检索、执行、审核这种能各交出一份独立产物的角色，比「会写代码的」「会写文案的」稳定得多。后者本质是按能力切，模型换个说法就串岗。

推进方式先选最简单的。常见三种：固定步数的流水线、带反馈的循环（做完检查不合格就退回）、按需分发的路由。能用流水线解决就别上循环，循环一多，排查成本指数上升。

多轮智能体是按量计费里最容易失控的一类：一次用户请求可能触发好几次模型调用，成本要按「每次任务的实际调用次数」估，不要按单次问答估。这个口径想错了，上线后账对不上会很难解释。

上线前先量延迟基线，再谈优化。站内 /tools/speed-test 可以先跑出你自己的接口延迟参考，拿这个数当基准，别用别人的体感数字做决策。

智能体设计模式有标准答案吗？

没有。同一个业务，用单智能体加工具调用和用多智能体编排都能跑通，差别在可维护性和成本。选型时优先看任务步骤能不能枚举、需不需要交叉验证、延迟能不能接受，这三点比追新架构重要得多。

多智能体一定比单智能体效果好吗？

不一定。多智能体擅长的是把一个复杂判断拆成几个独立角色互相挑错，代价是信息在多跳传递中会衰减，延迟和调用次数也会成倍上升。任务本身简单、步骤顺序固定时，单智能体反而更稳更便宜。

怎么判断一个智能体是不是该重构了？

看三个信号：提示词里条件分支越加越多、同一个工具反复被调错、出问题时说不清是哪一步坏的。出现其中两个，通常说明角色边界或终止条件没定清楚，该拆就拆，该收就收。