如果你正在搭建多智能体协作系统那么有一个现象你迟早会碰到智能体数量从 3 个加到 8 个任务不升反降甚至全军覆没。这不是模型不够聪明也不是 Prompt 写得不好而是多智能体协作架构本身的稳定性和可扩展性出了问题。很多人以为“智能体越多能力越强”实际结果往往是“智能体越多熵值越大”。当参与者从 3 个增加到 8 个时任务失败率不是线性上升而是断崖式恶化。这篇文章会围绕“8 个智能体时任务全失败”这个现象拆解背后的原因、复现路径、调试方法和工程解法。如果你正在用 LangGraph、Coze、Dify 或其他 Agent 编排框架做多智能体协作这篇文章能帮你少走很多弯路。我会先讲清楚多智能体协作的核心概念和失败机理然后给出一套可在本地运行的实验设计包含代码示例、配置文件和排查清单最后给出可落地的工程建议。整篇文章的重点只有一个让多智能体协作从“能演示”变成“能上线”。1. 这篇文章真正要解决的问题先说说这个题目背后的紧迫感。当前多智能体系统已经不是一个实验室概念而是大量开发者在实际业务中尝试的方向。拆解复杂任务、分配角色、让多个智能体共同完成一个目标听起来非常合理。但真实的工程反馈经常是智能体数量少的时候任务还能完成智能体数量一多对话开始失控互相打断、重复执行、上下文混乱任务最终失败而且失败原因很难定位。为什么 8 个智能体时任务全失败这不是一个孤例而是一个典型的规模化瓶颈问题。核心矛盾在于Agent 协作和人类团队协作有一个本质区别人类团队有组织结构和默认的沟通规则而大多数多智能体系统只是把多个 LLM 的上下文拼接在一起。这篇文章要解决的具体问题有三类第一类架构问题。多智能体系统是共享上下文、轮询调度、还是分层管理不同架构在智能体数量增加时失败模式完全不同。第二类成本问题。8 个智能体同时工作意味着上下文窗口被反复复制Token 消耗指数级增长。很多任务并不是“做不到”而是“还没做到就超预算了”。第三类可观测性问题。智能体一多链路变长出问题时根本不知道是哪个智能体说错了话、哪一步出现了死循环、哪一个上下文被污染了。如果你正在做以下类型的项目这篇文章的参考价值最大用 LangGraph、AutoGen、CrewAI 搭建多智能体协作应用在 Coze、Dify 等平台上设计多 Agent 工作流开发企业级 Agent 系统需要处理较多子任务和角色拆分正在经历“智能体一多就崩”的线上问题想找到系统化的排查方法。先给一个明确判断8 个智能体任务全失败大概率不是单点智能体的能力问题而是协作拓扑和任务拆解机制出了问题。解决这个问题的方向不是换更强的模型而是重新设计协作结构。2. 多智能体协作的核心概念与失败边界2.1 什么是多智能体系统多智能体系统Multi-Agent SystemMAS是指由多个自主智能体组成的系统每个智能体具备独立的感知、决策和行动能力通过通信和协作完成单个智能体难以完成的任务。在 AI Agent 开发语境下多智能体协作通常有两种形态一种是编排型多智能体。由一个中央调度器Orchestrator负责任务拆解、智能体调用和结果汇总。调度器不直接完成业务而是像项目经理一样安排工作。另一种是对等型多智能体。多个智能体之间没有中心调度器通过消息传递进行协商和互补。这种模式更自由但更容易失控。实际项目中纯对等型很少见大多数是可运行的 MAS 都采用“中心调度 角色执行”的混合结构。但即便是混合结构智能体数量增加到 8 个后也会出现严重的协作退化。2.2 8 个智能体时任务全失败的直接原因从工程角度看智能体数量增加到 8 个时以下四类问题会集中爆发第一上下文污染。多智能体系统为了让每个智能体都能理解全局通常会把历史消息、各智能体的输出、工具调用结果全部塞进上下文。当参与者变多每个智能体看到的上下文不再是“清晰的任务背景”而是一堆互相矛盾的中间结论。LLM 对矛盾信息的处理能力有限很容易丢弃关键信息或错误地采信过时结论。第二任务重复执行。没有严格的任务去重机制时多个智能体可能被分到同一个子任务。两个智能体同时做“查数据库”和“分析用户意图”最后产出的结果互相覆盖系统无法判断哪个结果更可信。第三链路雪崩。多智能体协作通常是链式调用。3 个智能体时链路深度只有 2 到 3 层错误传播有限。8 个智能体时链路深度可能达到 5 层以上。上一层的错误判断没有被及时纠正而是被下一层当作事实继续推理最终结果偏离正确方向越来越远。第四控制循环失控。智能体在协作中经常需要“确认”“驳回”“重新执行”等操作。智能体数量一多这些控制消息会形成循环依赖。A 等 B 的结果B 等 C 的结果C 又在等 A 的确认系统进入死锁状态。这四种问题叠加在一起最终呈现的结果就是任务全失败甚至没有一条子链路能成功返回。2.3 一个容易被忽视的边界上下文预算很多人忽略了一个硬约束上下文窗口是有限的Token 预算也是有限的。8 个智能体协作时每个智能体至少需要携带三部分信息系统提示词角色定义、任务规则任务描述和中间结果全部协作历史。如果有 8 个智能体每个智能体的上下文里都包含这 3 类信息那么 Token 消耗不是 8 份而是 8 份乘以各自的交互历史。更准确地说在轮询模式下每轮调度都会把主控上下文复制给当前执行的智能体。如果执行 20 轮那么至少产生了 20 份主控上下文拷贝。这种上下文膨胀会带来两个后果一是成本超限任务还没跑完Token 已经耗尽 二是模型注意力散焦因为无关信息太多模型抓不住真正关键的那一小段指令。所以8 个智能体时任务全失败很多时候不是什么玄学就是上下文预算被击穿了。2.4 成功与失败的分界线基于多个项目的实践可以给出一个经验性的分界线2 到 3 个智能体协作收益最明显任务稳定性高4 到 5 个智能体需要引入角色隔离和任务队列否则开始出现轻微混乱6 到 8 个智能体必须引入分层管理、独立上下文和结果校验机制否则失败率大幅上升8 个以上不建议采用平面协作架构必须改成“主管-专员”结构或任务并行隔离结构。这不是绝对数值但可以作为设计多智能体系统时的安全边界参考。3. 环境准备与前置条件为了讲清楚“8 个智能体时任务全失败”的问题下面会给出一套实验设计。这套实验不需要昂贵的算力只需要一台能运行 Python 的电脑以及一个可用的 LLM API。你完全可以用本地模型如 Ollama 部署的 Qwen 或 Llama替代云端 API。3.1 推荐环境组件建议操作系统Windows 10/11、macOS、Linux 均可Python3.9 及以上语言模型OpenAI API、DeepSeek API 或 Ollama 本地模型编排框架LangGraph推荐或 CrewAI开发工具VS Code、Jupyter Notebook 均可依赖管理pip 或 poetry版本说明本文示例基于 LangGraph 0.2.x 的常见 API 风格编写具体版本请以你安装时的官方文档为准。整体思路适用于大部分 Agent 编排框架。3.2 安装依赖新建一个 Python 虚拟环境然后安装以下依赖python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activatepip install langgraph langchain-core pip install openai如果使用本地模型可以安装 Ollama 客户端pip install ollama3.3 配置文件准备在项目目录下创建.env文件保存 API Key 和模型配置OPENAI_API_KEYyour_api_key_here OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODEL_NAMEgpt-4o-mini如果使用 DeepSeek可以改成对应的 Base URL 和模型名。注意不要把自己的 API Key 提交到 Git 仓库.env文件要加入.gitignore。4. 实验复现多智能体协作失败这一节的核心是跑通一个最小实验用 A/B 对比验证“3 个智能体成功、8 个智能体失败”的现象。4.1 实验设计思路实验任务设定为“撰写一份社区活动策划方案”。任务本身并不复杂难点在于拆成多个子任务后每个智能体都需要依赖前一个智能体的结果继续工作。如果某个环节出错后续所有智能体都会受影响。我会用两种配置跑同一份任务配置 A3 个智能体任务角色为基础撰写、细节补充、最终审核配置 B8 个智能体任务角色为背景分析、目标人群分析、时间计划、场地建议、预算估算、风险分析、内容整合、最终审核。实验目标不是证明 8 个智能体必然失败而是观察失败发生在哪一层以及失败原因是什么。4.2 使用 LangGraph 构建基线系统为了简单这里用一个基于 LangGraph StateGraph 的通用多智能体编排器。import os from typing import TypedDict, List, Dict, Any from langgraph.graph import StateGraph, END class AgentState(TypedDict): task: str agent_count: int current_step: int messages: List[Dict[str, Any]] results: Dict[str, str] def create_agent_node(role: str, system_prompt: str): 创建一个简单的智能体节点实际生产环境可替换为任意 Agent 实现。 from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) def agent_node(state: AgentState) - AgentState: # 每个智能体都接收全局消息列表这是导致上下文膨胀的关键设计 history state[messages] prompt f你的角色是{role}\n全局任务{state[task]}\n当前步骤{state[current_step]}\n if history: prompt \n【全局协作历史】\n \n.join( f{item[role]}: {item[content]} for item in history[-20:] ) prompt f\n\n你的专属指令{system_prompt} response client.chat.completions.create( modelos.getenv(OPENAI_MODEL_NAME, gpt-4o-mini), messages[ {role: system, content: 你是一个专业的多智能体协作参与者。}, {role: user, content: prompt}, ], temperature0.3, ) content response.choices[0].message.content # 更新状态 state[messages].append({role: role, content: content}) state[results][role] content state[current_step] state[current_step] 1 return state return agent_node这段代码的作用是创建一个“智能体节点工厂”。每次调用create_agent_node都会得到一个可以挂载到 StateGraph 上的节点函数。这里有一个关键设计需要说明所有智能体共享同一个messages列表也就是共享全局上下文。这是很多初版多智能体系统的默认做法也恰恰是 8 个智能体时上下文爆炸的根源。4.3 构建 3 智能体配置def build_graph_3_agents(): import os from langgraph.graph import StateGraph, END roles [ (策划初稿, 请输出活动主题、目标、核心流程大纲。控制在 300 字以内。), (细节补充, 基于初稿补充嘉宾邀请、现场互动、宣传渠道等细节。), (最终审核, 检查方案完整性和逻辑冲突输出最终版本。), ] graph StateGraph(AgentState) for idx, (role, instruction) in enumerate(roles): node_name fagent_{idx}_{role} graph.add_node(node_name, create_agent_node(role, instruction)) if idx 0: graph.set_entry_point(node_name) else: # 串行连接 prev_node fagent_{idx - 1}_{roles[idx - 1][0]} graph.add_edge(prev_node, node_name) last_node fagent_{len(roles) - 1}_{roles[-1][0]} graph.add_edge(last_node, END) return graph.compile()4.4 构建 8 智能体配置def build_graph_8_agents(): roles [ (背景分析, 分析社区背景、资源现状。), (目标人群分析, 定义目标人群画像和需求。), (时间计划, 制定时间线。), (场地建议, 推荐场地并说明理由。), (预算估算, 给出预算范围和费用项。), (风险分析, 列出 3 个主要风险及应对。), (内容整合, 将前面所有输出整合成完整方案。), (最终审核, 检查完整性和冲突输出终稿。), ] graph StateGraph(AgentState) history [] for idx, (role, instruction) in enumerate(roles): node_name fagent_{idx}_{role} graph.add_node(node_name, create_agent_node(role, instruction)) history.append(node_name) if idx 0: graph.set_entry_point(node_name) else: graph.add_edge(history[idx - 1], node_name) graph.add_edge(history[-1], END) return graph.compile()可以看到8 智能体配置在代码上和 3 智能体配置几乎没有区别只是角色更多、链路更长。这正是问题所在如果协作机制本身不具备扩展性那么智能体数量增加只会放大原有的缺陷。4.5 运行实验def run_experiment(): task 策划一场面向社区青年的周末读书会活动预算 2000 元以内。 print( 配置 A3 个智能体 ) graph_3 build_graph_3_agents() result_3 graph_3.invoke({ task: task, agent_count: 3, current_step: 0, messages: [{role: user, content: task}], results: {}, }) print(3 智能体结果 keys:, list(result_3[results].keys())) print(最终审核内容长度:, len(result_3[results].get(最终审核, ))) print(\n 配置 B8 个智能体 ) graph_8 build_graph_8_agents() result_8 graph_8.invoke({ task: task, agent_count: 8, current_step: 0, messages: [{role: user, content: task}], results: {}, }) print(8 智能体结果 keys:, list(result_8[results].keys())) final_content result_8[results].get(最终审核, ) print(最终审核内容长度:, len(final_content)) print(\n最终结果前 200 字) print(final_content[:200]) if __name__ __main__: run_experiment()运行方式python multi_agent_experiment.py注意由于每次调用 LLM 都会产生费用建议先跑 3 智能体配置确认流程正常后再跑 8 智能体配置。也可以把模型切换为本地模型降低调试成本。4.6 预期现象根据多智能体协作系统的一般规律你会观察到以下现象3 智能体配置下输出质量相对完整。每个智能体都能收到清晰的上游结论最终审核也能给出有效修改。8 智能体配置下出现多项退化后续智能体开始遗忘上游关键信息出现重复分析部分智能体输出与角色定义不符例如“场地建议”智能体开始讨论预算最终审核智能体面临过长的上下文只输出了大量空话链路可能出现超时或 Token 超限错误。如果你的实验结果是部分成功、部分失败也是正常的。因为具体的失败点受模型能力、Prompt 设计和任务复杂度影响。重点不是追求“必然失败”而是理解失败发生的机制。5. 核心失败原因拆解在实验跑通之后我们把“8 个智能体时任务全失败”拆成四个关键技术原因。5.1 原因一任务拆解粒度不当8 智能体配置中我故意按照常规思维把任务拆成了 8 个子任务。但“时间计划”和“场地建议”这两个子任务实际上是弱依赖关系。前者不依赖后者后者也不依赖前者。在串行链路中它们却被强制排成了线性顺序。这带来一个隐形问题后一个智能体必须处理前一个智能体的不相关输出。当不相关信息累积到一定程度系统开始出现“任务漂移”。例如“预算估算”智能体看到了“时间计划”中的日期信息可能误以为自己的任务是结合日期估算每日预算从而偏离原始目标。关键结论多智能体协作失败第一步不是因为模型能力而是因为任务拆解时没有分析依赖关系。串行执行所有子任务本质上是用随机顺序解释依赖关系这必然导致部分智能体在错误的基础上工作。更合理的做法是先做依赖分析找出哪些子任务可以并行弱依赖子任务不放进同一条串行链路只把强依赖的子任务保持在前后顺序中。5.2 原因二全局上下文机制缺陷在实验代码中每个智能体都读取整个messages列表。这是最简单的方式也是最容易导致上下文污染的方式。问题不在于“历史消息太多”而在于“历史消息中既有正确结论也有中间垃圾”。比如“背景分析”智能体的输出被“内容整合”智能体直接采用但如果“目标人群分析”智能体在前面步骤中产生了一个错误判断这个错误判断会一直存活到最终结果。全局上下文的另一个问题是信号冲突。当多个智能体输出了相互矛盾的建议时后续智能体很难判断谁更可信。在人类团队中我们会通过讨论解决矛盾。但在简单的全局上下文机制中没有“讨论”这个步骤只有一个接一个的单向输出。解决思路是引入“结论汇总节点”。在关键节点之后增加一个汇总智能体它读取所有上游输出去除冲突产出一份干净的“决策基线”。后续智能体只基于这份基线继续工作而不是直接面对全局原始消息。5.3 原因三缺乏结果校验反馈机制8 个智能体串行执行时没有一步是“校验上一步输出是否正确”。例如“背景分析”智能体如果分析错了目标人群后面所有智能体都会在错误的人群假设下工作。如果没有校验节点错误会静默传播直到最终结果漏洞百出。为什么 3 个智能体时这个问题不明显因为链路短错误传播的步数少。即使第 1 个智能体出一点小差错第 2 个智能体还有机会修正第 3 个智能体可以再做一轮整体把关。但 8 个智能体时任何早期错误都会被放大而且没有中间校验点来截断错误传播。实际工程中应该在每条链路中至少设置 1 到 2 个“校验节点”。校验节点不负责生成内容只负责判断上游输出是否满足要求。如果不符合要求可以触发重试或将该子任务返回上游重新执行。5.4 原因四控制逻辑限制目前很多多智能体框架的图编排是“静态图”。换句话说节点之间是写死的连线不允许运行时根据中间结果动态改变路径。这种静态图在小规模场景下没问题但在 8 个智能体时灵活性严重不足。例如某个智能体发现任务描述不清晰应该触发“任务澄清”路径某个智能体发现自己缺少必要数据应该触发“数据获取”路径某个智能体完成了 80% 的工作剩下的 20% 需要另一个智能体介入。静态图无法表达这些分支逻辑。系统只能按预设链路走完哪怕链路已经明显偏离目标。从工程角度看8 个智能体的系统更推荐“分层管线 条件路由”。主管智能体负责任务拆解和结果汇总专员智能体只负责执行单一任务。当需要额外信息时专员请求主管协调。6. 改进方案从 8 个智能体全失败到稳定协作下面给出一套可落地的改进方案。这套方案不追求“极致的智能”而是追求“工程上的可预期”。6.1 改进一缩小上下文范围核心原则每个智能体只看到“完成自己任务所需的上下文”而不是全局上下文。具体做法是在调用每个智能体之前从全局状态中筛选出与该子任务相关的字段拼装成一份精简的局部上下文。例如为“预算估算”智能体构造上下文时只传入全局任务描述目标场地建议如果有时间计划如果有预算上限。而不是将所有智能体的原始输出全部传入。6.2 改进二加入结果校验节点在关键节点后加入一个“校验器”节点。校验器的 Prompt 设计为你是质量校验员。你的任务是检查上游输出是否满足以下要求 1. 是否直接回应了任务问题 2. 是否包含明显逻辑错误 3. 是否缺少必要信息。 如果通过请只输出文本PASS 如果不通过请输出FAIL: 原因该校验器可以在代码层面控制图的分支如果输出包含FAIL则将子任务重新调度如果输出PASS则进入下一个节点。6.3 改进三采用主管-专员分层结构主管-专员结构是解决多智能体扩展性问题最稳妥的方案之一。主管智能体Supervisor负责任务拆解、结果汇总和下一步决策不直接执行具体业务。专员智能体Specialist只负责一个具体的子任务。这种结构的优势在于上下文隔离更好专员不需要了解全局任务分配更明确不会出现多个智能体做同一件事错误传播范围变小即使某个专员出错也不会污染其他专员。下面是一个简化版的主管-专员实现思路def run_supervisor_specialist(task: str, specialists: Dict[str, str]): 主管-专员简化模拟。 specialists 是一个 dictkey 为角色名value 为角色指令。 from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) supervisor_prompt f 你是一个项目经理。你的任务是拆分以下任务并分发给专员。 任务{task} 可用的专员角色 {list(specialists.keys())} 请输出 JSON格式如下 {{plan: [{{step: 1, specialist: 角色名, sub_task: 子任务描述}}]}} resp client.chat.completions.create( modelos.getenv(OPENAI_MODEL_NAME, gpt-4o-mini), messages[ {role: system, content: 你是一个严谨的项目经理。}, {role: user, content: supervisor_prompt}, ], temperature0.1, ) plan_text resp.choices[0].message.content # 这里实际应解析 JSON并按照 plan 依次调用 specialist print(plan_text)这个函数只是一个最小示例重点展示分层思路主管先产出计划再按计划调度专员。使用分层结构后即使有 8 个专员也不会出现“8 个智能体全失败”的问题。因为每个专员都只处理单一任务主管负责全局协调链路深度保持在一个可控范围内。6.4 改进四使用任务队列代替全量广播在多智能体协作中不要用“广播式”通信而是用“任务队列”模式。每个智能体从队列中领取任务处理后把结果放在指定位置。伪代码如下from collections import deque class TaskQueue: def __init__(self): self.queue deque() self.results {} def add_task(self, task_id: str, agent_role: str, payload: dict): self.queue.append({ task_id: task_id, agent_role: agent_role, payload: payload, }) def pop_next_task(self): if self.queue: return self.queue.popleft() return None def submit_result(self, task_id: str, result: str): self.results[task_id] result任务队列模式的好处是每个智能体不再需要“了解所有历史”它只需要读取队列中属于自己的任务执行完毕后提交结果。这种模式天然适合异步调度和并行执行也更容易做失败重试和日志追踪。7. 常见问题与排查思路下面列出现场排查多智能体协作问题时最常见的几个场景。问题现象可能原因排查方式解决方案智能体回复与角色不符系统提示词被全局历史淹没打印最终拼装给该智能体的完整 Prompt精简该智能体接收的上下文任务重复执行没有任务去重机制查看调度日志中每个智能体的调用时间戳引入任务队列或任务状态标记上下文超限全局上下文被反复复制统计每轮调用发送的 Token 数改为局部上下文按需读取链路长时间无响应多个节点循环等待查看各智能体输出是否出现相互确认增加超时机制和循环检测最终结果不连贯中间校验缺失检查关键节点输出是否符合要求增加校验节点和失败重试成本急剧上升每轮都向所有智能体广播全局历史对比不同智能体数量的 Token 消耗使用局部上下文或向量检索同一个任务在多个智能体间反复传递没有明确的职责边界审查路由逻辑和 Prompt 中职责描述使用主管-专员结构实际排查时建议先查看每个智能体实际收到的完整 Prompt。很多问题在打印出 Prompt 后就能当场看出原因。这里有一个生产环境容易踩的坑日志中只记录“智能体名称和输出”不记录“智能体输入”。结果出问题时无法复现当时的上下文。建议在生产环境的日志中至少记录智能体名称调用时间戳输入 Prompt 的摘要输出内容Token 消耗调用的上游任务 ID。有了这些信息排查效率会提升一个量级。8. 最佳实践与工程建议8.1 从 3 个智能体起步如果你的项目还没有上线不要一上来就设计 8 个智能体。从 3 个智能体起步跑通业务闭环后再按需扩展。每新增一个智能体都需要回答三个问题它是否承担了不可替代的职责它需要哪些上游信息如果它失败了会对下游产生多大影响如果某个智能体只是把已有智能体的职责细分了一下没有新增业务价值那么不加这个智能体是更优选择。8.2 先画依赖图再写代码在实现多智能体协作前先用表格画出子任务之间的依赖关系。子任务依赖项是否可并行背景分析无是目标人群分析背景分析否时间计划目标人群分析否场地建议目标人群分析否预算估算场地建议、时间计划否内容整合所有上游否这张表格能帮你识别出哪些子任务可以并行哪些必须串行以及哪些智能体其实是不需要的。8.3 给每个智能体明确的“完成定义”很多智能体输出质量差不是模型能力问题而是 Prompt 里没有定义“什么叫完成”。一个合格的智能体 Prompt 应该包含四部分角色输入内容说明输出格式要求完成标准。示例你是活动预算分析师。 输入活动方案文本、场地建议、时间计划。 输出JSON 格式的预算表包含费用项、估算金额、备注。 完成标准所有费用项都有金额估算总预算不超过输入中的预算上限。用这种方式写 Prompt后续接入校验节点会容易很多。校验节点可以精确比对输出格式和完成标准。8.4 设置超时与重试在生产环境每个智能体调用都应该设置超时时间。如果超过 30 秒没有返回应视为失败并触发重试或降级。from openai import APITimeoutError try: response client.chat.completions.create( modelmodel_name, messagesprompt_messages, timeout30, ) except APITimeoutError: # 记录日志触发重试或降级 print(Agent call timeout)同时建议设置最大重试次数避免因为单个智能体卡死导致整个任务无法结束。8.5 重视可观测性多智能体协作系统本质上是一个分布式系统。分布式系统最重要的工程实践就是可观测性。建议至少做到每次智能体调用都输出一条结构化日志每个任务都有一个全局唯一的 trace_id每个智能体输出都记录父任务 ID。如果你用 LangGraph可以启用 LangSmith 或自定义回调来追踪链路。如果自己实现编排器务必在关键节点打印“当前状态摘要”。8.6 安全与权限边界当多智能体系统接入工具调用或数据库操作时必须注意安全边界。建议遵守以下规则每个智能体只能调用授权给自己的工具高危操作删除、修改、写入必须经过人工确认节点智能体的系统提示词中要明确“禁止执行未授权操作”工具调用结果必须经过校验后才能进入后续智能体上下文。在实际项目中多智能体系统最容易出现的安全问题不是模型被攻击而是权限过度放大。把全部工具权限都交给一个“统筹智能体”一旦该智能体的上下文被注入恶意指令风险会非常大。8.7 成本优化多智能体系统的成本优化核心是减少无效上下文传输。推荐三个手段用小模型处理简单节点的任务只在关键节点使用大模型对中间结果做摘要而不是直接传递完整输出在上下文中加入“只读局部字段”机制而不是把整个结果集传给每个智能体。对于一个 8 智能体协作场景如果能把每个节点的输入上下文从 8000 Token 压到 2000 Token整体成本会下降 75% 左右同时稳定性还会上升。9. 总结与后续学习方向“8 个智能体时任务全失败”不是一个需要避讳的现象而是多智能体系统规模化过程中的必经阶段。它提醒我们多智能体协作的技术难点不在“让每个智能体更聪明”而在“让多个智能体之间的信息流动更有序”。这篇文章讲清楚了几件事多智能体系统在智能体数量增加时失败的主要原因不是单个模型能力而是上下文管理、任务拆解、结果校验和链路控制3 个智能体和 8 个智能体不是简单的数量差异而是架构复杂度的质变解决 8 个智能体问题的关键路径是缩小上下文范围、增加校验节点、采用主管-专员分层结构、引入任务队列工程上要重视日志、超时、重试和安全权限边界。如果你正在做多智能体项目下一步可以这样做第一步把你当前系统的智能体数量和角色画成一张图审查每个角色的依赖关系和上下文传递范围。第二步选择一个核心业务链路用“主管-专员”结构重构一遍对比重构前后的成功率、Token 成本和定位问题的耗时。第三步在关键节点接入校验器和结构化日志把所有智能体输入输出跑通一次确认问题可追踪。多智能体协作领域值得继续深入的方向包括动态任务拆解、基于强化学习的协作策略、多智能体间的记忆共享、以及模型能力不足时的替换与降级策略。这些方向在工程上都有大量待解决的问题。回到现实世界如果你的系统目前只有 3 个智能体先别急着加到 8 个。多一个智能体就多一份不确定性。真正健壮的多智能体系统不是靠“人多力量大”而是靠清晰的结构和严格的边界管理。