那晚我们原本的计划是睡个好觉一个负责“资料收集→方案生成→写客户说明”的单智能体在我们的模拟项目X里已经连续跑了两周。结果凌晨三点日志里出现第17次重复输出——它把同一个带明显漏洞的方案原样又输出了一遍而且每次回答都“信心十足”。问题的根子不在 Prompt 写得不够好也不在模型不够聪明而在于我们把太多相互制约的任务塞进了同一个大脑里。一个模型既要做资料调研又要做方案设计还要自己给自己做质量检查最后还负责对外输出——这种“一条龙”模式在简单任务上没问题一旦任务链条拉长它就会自己骗自己因为它只看到自己的产出缺少外部反馈错误会被一遍遍当成正确答案继续往前推。那之后我花了差不多两周时间重构把系统改成了 agency-agents 风格的多智能体协作架构按职责拆出计划者、执行者、评审者各自带专用工具共享一块工作区用明确的协作协议把复杂任务拆开、并行、校验、闭环。这篇文章就把这套架构的原理、落地路径、以及我踩过的四个大坑完整写出来。适合已经被单智能体“卡脖子”的开发者也适合刚打算引入多智能体架构、但不知道从哪下手的人。1. 单智能体的“天花板”与多智能体协作的破局思路1.1 单智能体为什么会在复杂任务上卡壳先说一个我观察了很久的现象很多团队抱怨“我的上下文爆了”“模型记不住前面说的话”其实真正的毛病不是模型能力不够而是职责没有分开。单智能体处理长流程任务时Prompt 里往往要塞进这么多东西用户目标、当前进度、历史对话、工具返回结果、质量要求、输出格式……这些东西混在一个上下文里相互之间的信号会被稀释。模型并不知道哪些信息是“当前这个环节必须盯住的”哪些是“背景噪音”。于是它会做出看起来很合理、实际上已经跑偏的决定。更麻烦的是自校验在长流程里基本失效。人在自己写完的方案里挑错都困难模型也一样它在生成文本时已经走了那条推理路径回头检查时大概率还会沿着同一条路再走一遍最后得出“没问题”的结论。我做过一次实验同一个三阶段任务调研→汇总→写建议单智能体模式下跑 10 次平均每 4 次就会出现一次“把上一个环节的错误事实当成基础继续推理”的情况把任务拆给三个角色并行后同样跑 10 次只有 1 次是因为模型本身的知识错误导致的其余都被评审环节拦住了。这个差距不是模型带来的而是架构带来的。1.2 用“人力外包”的类比理解多智能体把多智能体理解为给任务外包会非常直观。一个公司不可能让同一个人顶着产品经理、开发、测试、客服四个身份去交付一个项目。产品经理做了决策直接去写代码会不自觉地在代码里固化自己的错误假设开发自己测自己的代码总容易漏掉边界情况客服接到用户投诉时又得重新翻所有过程才知道问题出在哪个环节。多智能体协作就是把这件事拍平计划者负责拆任务、定优先级执行者负责调用工具、生产内容评审者只做质量检查不参与内容产出调度器维护全局状态决定下一步让谁上场。每个角色不需要知道全过程只需要把自己那一环做到位然后把结果写进共享工作区由下一个环节读取。这带来一个很实际的好处错误不会再沿着同一条推理路径无限放大。执行者写错的东西评审者会以“另一个视角”读一遍大概率能抓出来就算抓不出来下一个执行者在工作区里读到的也不是一股脑的上下文而是一份带结构、带状态的产出物它可以对照自己的任务目标去发现问题。1.3 agency-agents 与其他多智能体思路的核心差异我接触过多智能体的几种常见做法放在一起对比会更清楚维度对话式多智能体传统工作流引擎agency-agents 风格职责划分角色靠 Prompt 区分节点靠代码固定角色 技能注册动态组合状态管理全局对话历史外部数据库保存状态共享工作区 结构化产出物决策路径模型自由发挥完全预定义分支计划者定主干执行者保留局部决策权错误反馈靠用户/人工纠正靠异常处理评审者独立检查并修正可维护性低改一个角色影响全局高但改流程要改代码中高角色可替换、技能可插拔最让我意外的一点是agency-agents 风格并不过度追求“让模型自由发挥”反而很强调“确定性”。主干流程是确定的先计划、再执行、再评审复杂分支由计划者在运行时决定。这和传统工作流不一样的地方是它允许执行者根据实际工具返回结果临时调整做法而不是死板地走预置分支。我后来的经验是不确定性只留在“执行”这一层其余层全部用代码和协议锁死系统稳定度会高非常多。2. 理解核心计划者、执行者与评审者的三角制衡2.1 每个角色需要拆到什么程度才算合理拆分角色的粒度是 agency-agents 里最容易搞砸的一件事。我见过有人把一个文档翻译任务拆成八个智能体术语提取者、初译者、润色者、格式检查者、风格检查者、质量检查者、发布者、归档者……结果光协调它们就需要大量额外 token而且角色之间职责重叠经常互相打架。拆分的原则应该是每个角色只做“一种不可再被拆成子任务的职责”并且拥有至少一个独立工具来完成它。以一个内容生产任务为例我会这样拆计划者负责把“生成一份季度总结报告”拆成“收集数据、整理亮点、写初稿、校对、定稿”五个子任务并为每个子任务指定执行者和检查条件。执行者数据收集调用数据库接口、读取文档产出结构化数据文件。执行者文案生成基于数据文件写初稿。执行者校对基于写作规范检查和修正文本。评审者在定稿前做一次独立审核输出通过/不通过的结论。如果某个执行者同时要做“数据收集”和“文案生成”它就得在两种思维方式之间切换切换时必然带来信息损耗。拆开之后每个角色只看自己需要的输入思维模式稳定工具接口也简单。2.2 “职责分离”为什么是有权重的设计决策表面上看评审者可以放在执行者内部让每个执行者“先自查再提交”这样省掉一个角色成本也更低。我一开始就是这么想的结果很惨。原因很简单让执行者自查等于让学生自己改自己的卷子。模型在生成答案时已经对推理路径产生了“偏好”让它重新审视同一份产出它大概率会认可自己的原始结果最多修几个无关痛痒的表达问题。而且执行者 prompt 里的“自查要求”越多它的主任务执行质量反而越差——因为它要在输出之前同时扮演“生产者”和“裁判”这两份指令会互相干扰。评审者必须满足三个独立条件独立的上下文不接收执行者的完整思考过程只接收最终产出物和对应的工作区条目避免被执行者的思路带偏。独立的工具路径可以调用与执行者不同的数据源或校验函数而不是把同样的计算重复一遍。明确的否决权评审通过/不通过是硬性的调度器必须遵循不能靠“比例尺”糊弄过去。这三点加在一起评审才真正变成外部纠错机制而不是一个形式化流程。2.3 协作协议里的三个信号Plan、Extend、Correct多智能体之间沟通最忌讳的是互相传递一大段自然语言。自然语言冗余度高、歧义大、模型解读也不稳定。我后来把所有跨角色消息都收敛成三种结构化信号调度器只认这三种信号发送方含义调度器动作Plan计划者本轮任务拆解结果分发子任务给执行者Extend执行者需要额外信息或工具按需补充上下文/注册工具Correct评审者产出物不合格附修改意见将产物回退给对应执行者修订每种信号都带任务 ID、目标角色和负载负载里只放必要的结构化字段。调度器根据信号类型决定下一步走向而不是读一段自然语言去猜意图。举个例子伪代码大概是这种感觉class AgencyScheduler: def __init__(self, agents, workspace): self.agents agents # role - agent instance self.workspace workspace # shared state store def run_task(self, task): plan self.agents[planner].plan(task) for sub in plan[subtasks]: result self.execute_with_review(sub) if result[status] rejected: sub self.agents[planner].revise(task, result[feedback]) result self.execute_with_review(sub) return self.workspace.get(task.id) def execute_with_review(self, subtask): output self.agents[subtask[assignee]].run(subtask, self.workspace.read(subtask[inputs])) review self.agents[reviewer].check(output, subtask[criteria]) if review[verdict] rejected: output self.agents[subtask[assignee]].revise(review[feedback]) return review写代码的 10 分钟能跑通真正难的是后面把“评审意见”真正变成下一次修订的依据——这恰恰是第三节要说的关键。3. 从单智能体迁移到多智能体一条可行的落地路径3.1 第一步不急着重构先圈出适合拆分的场景不是所有任务都必须改成多智能体。判断标准很简单如果任务链路上有超过两次“生成→检查”的循环或者跨越了明显的知识领域比如既要写代码又要写文档既要查数据又要做翻译那就值得拆。如果只是单次问答、单文件处理直接用单智能体反而更快。我当时先圈出模拟项目X里最稳定的一个环节做试点把“周报自动生成”从单智能体改成三个角色计划者、内容执行者、评审者跑通之后才逐步扩展到其他流程。这个策略很重要——先在一个低风险场景验证协议不要第一次就上核心业务。多智能体架构刚开始会比你想象中慢因为消息传递、工作区读写都有额外开销跑通几个星期后稳定性收益才会超过启动成本。适合拆分的任务还有一个特征可以明确写出“验收标准”。比如“必须包含五个关键指标”“必须落在指定日期区间内”“必须引用工作区中的三个数据文件”。验收标准越硬评审环节越容易落地。如果验收标准写不清楚评审者就会变成一个“给执行者打气”的虚设角色。3.2 为每个执行者注册“技能”而不是注册“角色”这是我迭代半个月后最有价值的一个改动。早期版本里我为每个角色写死一套 Prompt比如“你是一个数据分析师”“你是一个财务专家”效果很差。因为模型对这些头衔的理解非常模糊“数据分析师”到底要做什么、能调用什么工具完全取决于 Prompt 细节。改成技能注册模式之后角色定义分成了三层角色名对外标识便于调度和日志。技能列表它能调用的工具和接口比如read_workspace、query_db、gen_chart。行为约束输入输出的格式、工作区写入规则、出错时的上报方式。提示词里不再需要写“你是一个 X 专家”而是写“你可以调用这些接口输入输出必须符合这些字段定义”。模型不需要扮演谁它只需要按照接口契约做事情。这一步直接让错误率下降了接近一半——不是模型变聪明了而是它的行为边界变得清晰了。提示技能越多不代表越强。我在后期把每个执行者的可用技能控制在 2~3 个。技能一多模型在调用选择上的失误率指数级上升所谓的“工具选择失误”几乎全是这么来的。3.3 Prompt 里最容易写坏的三种约束很多开发者一开始多智能体就跑不通不是工具问题是 Prompt 约束方式错了。我总结了三类最常见的错误写法第一类用“你应该记得”来做状态管理。比如“你应该记得前面收集的数据”这种话模型真的不一定会记得。正确方式是把关键数据直接放进工作区并在执行者收到任务时显式传入该数据字段。状态不能靠记忆要靠数据流。第二类让执行者同时遵守互相矛盾的指令。比如“既要发挥创意又要严格按模板输出”模型会被迫做一个模糊的中间选择。正确的写法是把“创意”限制在某个字段内模板结构仍然用 schema 约束。这样两边不打架。第三类把评审标准埋在执行者的输出 Prompt 尾部。这会让执行者觉得自己已经被评审了从而少做真正的自查。评审标准应该属于评审者的输入而不是执行者的输出要求。3.4 串联协议逐级检查点与退出条件确定好角色和技能之后还要把“检查点”设计好。我用的模式是这样每个子任务完成先将结果写入工作区再交给评审者评审者通过后才算结束。如果评审不通过执行者拿着具体修改意见回到工作区修订。为了防止死循环必须给每个子任务设置“最大修订轮次”一般是 2~3 轮。超过轮次仍不合格就将该子任务标记为“有风险”并上报给计划者由计划者决定是降低验收标准、更换执行者、还是额外补充资料。退出条件也很关键。不是“评审通过”就一定退出——我还会加上一条硬性的“轮次上限”和“时间上限”。因为模型有概率连续两次误判通过这两个上限能在极端情况下兜底。我当时在日志里见过一个任务跑了 8 轮评审每次都返回 approve但其实前 3 轮之后结果早就不变了后面全是评审者在自说自话。轮次上限一加这类问题立刻消失。4. 我在迭代中真实踩过的四个坑以及完整排查过程这一节是整个改造里最值钱的部分。前面说的是理论下面是真实翻车现场。4.1 上下文爆炸执行者把全部对话历史塞给了模型症状某次运行中任务 token 消耗从平时约 8 千飙升到接近 40 万响应速度肉眼可见地变慢最夸张的时候单个子任务要跑近半小时。排查链路我先看了 token 统计曲线发现爆点在“执行者调用评审者”之后。然后我翻了执行者的实际请求体发现输入里带了一份完整的“全量会话转写”包括前 12 轮无关任务的完整记录。再往下查定位到调度器代码我当时为了让调试方便把全局session对象直接传给了执行者的调用函数Prompt 模板里又一个{history}占位符无条件渲染就把所有历史都灌了进去。修复把执行者的输入从“全量会话”改成“当前子任务的工作区快照”只传入必要字段任务描述、相关数据文件、工作区版本号。同时给执行者增加了一个last_updated时间戳要求它发现问题时可以主动请求更新而不是被动接收全部历史。注意共享工作区不是让你把所有数据都在每个环节复制一份而是只拉取与当前子任务有关的条目。这在 token 成本上差出来一个数量级。4.2 任务粘滞某个执行者变成了“只执行、不复查”的工具人症状某个执行者在连续三轮修订中输出完全一致的错误结论。评审者的反馈已经明确指出了问题但它每次给出的新版本都换汤不换药。排查链路我看执行者的日志发现它在每一次“修订”请求中根本没有重新读取工作区里评审反馈的更新。它拿到的是上一轮自己的输出和“请根据反馈继续修订”一句提示但它把自己的旧输出本身当成唯一参考因此新答案几乎就是旧答案的措辞换皮。修复在调度器层强制“每次执行前必须重新拉取一次最新工作区快照”而不是沿用上一次的上下文。同时我在工作区里加了版本哈希校验执行者提交结果时带上它读到的版本号如果与最新版本不一致调度器直接拒绝接收。这等于用技术手段强迫执行者“睁眼重看”而不是闭眼续写。4.3 评审闭环失效评审通过但结果依然错误症状有一次执行者给出的方案里关键时间区间整体算错了一天评审者仍然返回“通过”。这个错误经过三层角色流转最终被模型之外的一个规则脚本抓到。排查链路我查看了评审者的调用记录发现它用的校验函数和执行者用的是同一个工具、同一个数据源等于评审者只是用同样的计算重跑了一遍自然得到同样结果。更隐蔽的是评审者和执行者的输入里都包含了执行者输出的“时间计算公式”所以它是被执行者的推导过程带偏了。修复给评审者配置了独立的校验路径执行者调用实时数据接口 A评审者调用独立数据接口 B互不共享。同时把一批“硬性约束”做成独立规则引擎比如“日期范围必须落在 [2024-01-01, 2024-12-31] 内”“总量必须等于各分项之和”先跑规则引擎再跑模型评审。规则引擎拦截不了的语义问题才交给模型判断。4.4 消息风暴一小时内没有产出一个有效提交症状探索新任务类型时整个系统突然像瘫痪了一样日志里全是角色之间的沟通请求但没有一个子任务进入评审环节。排查链路顺着日志往前翻我发现某个子任务完成之后计划者广播了一条“任务状态已更新”消息给所有角色。两个执行者同时读取工作区都认为自己可以接手后续的子任务各自生成了任务请求并写回了工作区。调度器没有任务领取的锁机制两个请求被同时接受于是一人抢到、另一人也觉得自己抢到了双方各自推进消息越滚越多有效产出为零。修复给每个子任务添加所有权标记只能由指定 assignee 读取和修改其他角色只能看到“已完成”状态的公告不能抢占待办。同时加了一个简单的队列锁任务被领取后立刻标记为进行中防止重复处理。问题症状根因修复上下文爆炸token 异常升高、响应极慢把全量历史传给执行者工作区快照只传必要字段任务粘滞修订轮次内产出无变化执行者未读取最新反馈强制重读工作区 版本哈希评审失效错误被评审通过评审用同一工具路径重算独立数据源 规则引擎前置消息风暴大量无效沟通缺少任务所有权标记指派 assignee 队列锁这四个坑都有一个共性根子都在“确定性不够”。模型的推理是概率性的但调度、状态、所有权这些基础设施必须是确定性的。把尽可能多的规则用代码锁死模型承担的不确定部分就越少整体系统就越稳。5. 成本、优先级以及一个人就能跑起来的起步配置5.1 量化成本的关键维度多智能体架构最大的顾虑永远是成本。我用一组内部跑过的数据说明问题同一份“行业调研→方案输出→邮件成稿”任务单智能体模式下消耗约 12 万 token主要浪费在模型反复读同一份材料拆成计划者、执行者、评审者三个角色后总消耗降到约 2.8 万 token同时耗时缩短接近一半。多出来的开销只有评审环节的提示词但对比它拦下的错误绝对划算。核算成本时要盯三个数字单任务平均 token、单任务平均调用次数、上下文命中率也就是模型输入中真正需要的字段占比。我给自己定的健康线是上下文命中率不低于 30%超过一半的输入都是活跃字段如果某个角色老是输一大堆但只用其中一小部分就该压缩它的输入字段了。5.2 四条给单人团队的降本技巧第一缩小角色输入而不是缩小模型。同样的任务给执行者传 2000 token 的精准数据和传 20000 token 的全量数据模型表现差距不大成本差十倍。我每次优化都是先从“少传”入手。第二用规则代替部分模型推理。凡是能写成正则、schema 校验、枚举映射的地方不要交给模型。日期校验、字段完整性检查这类用代码写死成本为零效果还稳定。第三给工具返回结果加预处理器。数据库查询结果动辄几百行 JSON但执行者真正需要的可能只是其中几个字段。预先聚合、采样、结构化模型就不需要在一大段噪声里自己挑选。这一步对 token 消耗的压缩效果非常明显。第四按角色区分模型规格。计划者和评审者可以用相对轻量的模型因为它们主要是格式判断和结构决策真正需要强推理能力的是执行者把预算集中在这个角色上。我实际对比过两次整体质量没下降成本下降两成多。优化项改动前改动后收益上下文命中率18%52%token 降约 60%评审规则引擎无前置运行错误拦截率明显提升工具返回预处理器无字段聚合输入压缩约 40%角色模型规格统一规格按角色区分总成本降约 22%5.3 当前局限以及我下一步想试的方向这套架构目前只在 5~8 个角色的小型系统里验证过。角色一旦超过 10 个调度复杂度就会迅速上升纯粹靠代码维护规则会越来越吃力。另一个明显的短板是“长期记忆”每个新任务都是冷启动之前的评审结论、执行经验不会自动沉淀。我正在试着把历次评审中的有效反馈转成结构化的“团队规则”下次同类任务直接灌给执行者而不是让模型重新摸索一遍。另外我最近在琢磨的是“临时子团队”方向——让计划者在遇到复合型任务时不只是派活给固定角色而是动态创建一组角色、定义它们之间的协作关系、任务完成后自动解散。这样既保留了小团队的高可控性又能扩展到大系统的复杂度。等我跑出稳定数据再来把完整过程写出来。最后分享一个我自己的体会这套架构带给我的最大收益不是“模型更聪明”而是“出错边界更清晰”。单智能体出错时错在哪一片混沌里都找不到多智能体跑起来之后哪个角色、哪个环节、哪一次评审出的问题日志里一目了然。这种可排查性是我愿意为它持续投入的核心理由。