企业官网建设流程全解析

如果你正在搭建多智能体协作系统，那么有一个现象你迟早会碰到：智能体数量从 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 System，MAS）是指由多个自主智能体组成的系统，每个智能体具备独立的感知、决策和行动能力，通过通信和协作完成单个智能体难以完成的任务。

在 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 推荐环境

版本说明：本文示例基于 LangGraph 0.2.x 的常见 API 风格编写，具体版本请以你安装时的官方文档为准。整体思路适用于大部分 Agent 编排框架。

3.2 安装依赖

新建一个 Python 虚拟环境，然后安装以下依赖：

python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate

pip install langgraph langchain-core pip install openai

如果使用本地模型，可以安装 Ollama 客户端：

pip install ollama

3.3 配置文件准备

在项目目录下创建.env文件，保存 API Key 和模型配置：

OPENAI_API_KEY=your_api_key_here OPENAI_BASE_URL=https://api.openai.com/v1 OPENAI_MODEL_NAME=gpt-4o-mini

如果使用 DeepSeek，可以改成对应的 Base URL 和模型名。注意不要把自己的 API Key 提交到 Git 仓库，.env文件要加入.gitignore。

4. 实验：复现多智能体协作失败

这一节的核心是跑通一个最小实验，用 A/B 对比验证“3 个智能体成功、8 个智能体失败”的现象。

4.1 实验设计思路

实验任务设定为“撰写一份社区活动策划方案”。

任务本身并不复杂，难点在于拆成多个子任务后，每个智能体都需要依赖前一个智能体的结果继续工作。如果某个环节出错，后续所有智能体都会受影响。

我会用两种配置跑同一份任务：

• 配置 A：3 个智能体，任务角色为基础撰写、细节补充、最终审核；
• 配置 B：8 个智能体，任务角色为背景分析、目标人群分析、时间计划、场地建议、预算估算、风险分析、内容整合、最终审核。

实验目标不是证明 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_key=os.getenv("OPENAI_API_KEY"), base_url=os.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( model=os.getenv("OPENAI_MODEL_NAME", "gpt-4o-mini"), messages=[ {"role": "system", "content": "你是一个专业的多智能体协作参与者。"}, {"role": "user", "content": prompt}, ], temperature=0.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 = f"agent_{idx}_{role}" graph.add_node(node_name, create_agent_node(role, instruction)) if idx == 0: graph.set_entry_point(node_name) else: # 串行连接 prev_node = f"agent_{idx - 1}_{roles[idx - 1][0]}" graph.add_edge(prev_node, node_name) last_node = f"agent_{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 = f"agent_{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("===== 配置 A：3 个智能体 =====") 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===== 配置 B：8 个智能体 =====") 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 是一个 dict，key 为角色名，value 为角色指令。 """ from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL"), ) supervisor_prompt = f""" 你是一个项目经理。你的任务是拆分以下任务并分发给专员。 任务：{task} 可用的专员角色： {list(specialists.keys())} 请输出 JSON，格式如下： {{"plan": [{{"step": 1, "specialist": "角色名", "sub_task": "子任务描述"}}]}} """ resp = client.chat.completions.create( model=os.getenv("OPENAI_MODEL_NAME", "gpt-4o-mini"), messages=[ {"role": "system", "content": "你是一个严谨的项目经理。"}, {"role": "user", "content": supervisor_prompt}, ], temperature=0.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。很多问题在打印出 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( model=model_name, messages=prompt_messages, timeout=30, ) 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 个。多一个智能体，就多一份不确定性。真正健壮的多智能体系统，不是靠“人多力量大”，而是靠清晰的结构和严格的边界管理。