企业官网建设流程全解析

多Agent这几年算是LLM应用开发里被讨论最多、也最容易踩坑的方向之一。我大概在一年多前开始把单Agent拆成多Agent架构，从最初的生搬硬套到后来逐步沉淀出一套可落地的设计方法，中间经历了三轮大重构。这篇内容不是学术综述，而是把我实际设计、部署、维护多Agent系统时总结的经验整理出来。包括什么时候不该用多Agent、角色怎么分、消息结构怎么设计、编排模式怎么选、记忆系统怎么分配，以及那些文档里查不到但实战中一定会遇到的坑。适合正在做Agent应用、被多Agent协作搞到头大、或者准备从单Agent切到多Agent的工程师参考。

1. 设计前的全局思考：先想清楚要不要上多Agent

很多人在看到多Agent这个概念后的第一反应是“我是不是也该上”。我建议你先冷静下来，把需求重新梳理一遍。多Agent是一种架构手段，不是目标。它的代价是系统复杂度指数级上升，通信开销、调试难度、token消耗都跟着涨。如果不值得，单Agent加一个计划循环完全够用。

1.1 单Agent与多Agent的真实边界

单Agent本质是一个“大脑”带多种技能的循环：接收任务、规划步骤、调用工具、检查结果、迭代修正。在不少业务场景里，这套机制已经能覆盖大部分需求了。比如一个客服场景的Agent，它可以自己判断是查订单还是退换货，然后调用相应的工具，整个过程不需要别人帮忙。

什么时候开始觉得单Agent不够用了？我遇到的典型信号有几个。首先是提示词（prompt）变得极长，system prompt里要塞角色设定、领域知识、工具说明、输出规范，经常超过一万字。其次是工具数量膨胀，Agent需要同时知道几十个工具的存在，调用时频繁出现选择困难。第三，一个循环里的“角色”互相冲突，比如同一个Agent既要严格审查合规，又要灵活推荐方案，这两个要求本质上打架，塞在一起必然互相干扰。

多Agent解决的是角色分离问题。它把不同职责、不同约束、不同知识背景拆到多个独立的Agent里，让每个Agent的prompt短小聚焦，上下文窗口压力小，行为更可控。如果你没有这种职责冲突或规模化压力，多Agent大概率会给你增加运维成本，而不是提升效果。

1.2 多Agent适用的三个关键特征

判断一个场景要不要上多Agent，我一般看三个核心特征。

第一个是任务具有天然的分工结构。所谓天然分工，是指任务本身可以拆成几个内聚度高的子模块，而且子模块之间接口清晰。举个例子，一个内容生产管线可以拆成选题策划、资料检索、初稿撰写、事实校对、风格润色五个环节，每个环节的输入输出都比较明确。这种结构用多Agent梳理是顺水推舟。

第二个是不同子任务对能力和约束的要求差异大。有的环节需要代码执行能力，有的环节需要检索网络，有的环节需要严格遵循格式。这些能力各不相同，如果塞进一个Agent，工具列表和约束条件容易混杂，导致Agent频繁选错工具。拆开后每个Agent只面对自己那部分工具和规则，准确率会好很多。

第三个是单Agent核心里存在“自我反驳”需求。比如你希望系统先出一个方案，再找一个人严格挑毛病。这种对抗式校验在单Agent里很难做好，因为同一个模型很难在同一轮对话里既扮演创作者又扮演批评者。拆成两个Agent后，一个负责生成，一个负责审查，效果立竿见影。

如果满足其中一个特征，可以考虑多Agent。如果三个都满足，基本可以确定值得上。如果一个都不满足，我建议你老老实实把单Agent的规划和工具调用调好。

1.3 成本与收益的冷静评估

多Agent最容易被忽视的成本是token消耗和延迟。一次包含三个Agent的协作任务，如果每个Agent都要多轮对话和多次工具调用，总token量可能是单Agent的三到五倍，响应时间也相应拉长。如果你的业务对成本或延迟敏感，需要提前评估方案能否接受。

另一个成本是调试复杂度。单Agent出了问题，你只需要看一段对话记录。多Agent出问题，你要追踪多个Agent之间的消息流转，确认是A的产出没表达清楚，还是B的理解出了偏差，还是编排逻辑本身有漏洞。这种分布式排查的难度比单Agent高很多。

我做了一个简单的决策清单，每次设计前都会过一遍：

• 任务是否能被拆成边界清晰、内聚度高的子模块？
• 子模块之间的交互是否有明确输入输出，而不是模糊的“讨论”？
• 系统里是否存在必须由不同角色来承担的冲突性约束？
• 团队是否有足够的预算和时间来调试协作机制？
• 延迟和成本是否在可接受范围内？

如果以上问题有一半以上是“否”，我会非常谨慎。宁可先用单Agent做一版，等出现明显瓶颈再逐步引入多Agent。

2. Agent角色体系设计：分工决定协作复杂度

多Agent系统里，角色设计是地基。角色分得合理，协作自然顺。角色分得模糊，后面所有环节都会出问题。我的经验是，角色设计要服从“职责单一、接口明确”两个原则。

2.1 角色划分的两个核心原则

第一个原则是职责单一。每个Agent只做一件事，或者只承担一个明确的职能。一个Agent既要写代码又要做测试，必然存在角色混乱。你可以说“先写后测”，但Agent在实际执行时容易跳过测试环节，或者用同一个prompt约束两件事导致风格漂移。拆成Developer和Tester两个Agent后，各自的system prompt可以深度定制，Developer专心写代码，Tester专心找问题，效果差异非常明显。

第二个原则是接口明确。每个Agent的输入输出要是结构化的、可预期的。如果Agent A的输出是一段自由文本，Agent B需要从中“理解”出关键信息，那么系统就会不稳定。正确做法是把输出约束为JSON或固定字段，让B可以直接消费结构化数据。我不太建议让Agent之间传递大段自由对话，尤其是依赖隐式语义理解的信息交接，出错率极高。

在实际项目里我会先做一个职责映射表。列出所有需要完成的功能，然后归并相似功能，划出Agent边界，最后为每个Agent定义输入字段、输出字段和失败行为。这一步做完，后面的通信设计才有依据。

2.2 角色定义模板

我每次创建一个新Agent时，都会用一个标准化文档来定义它。这个文档不仅给模型看，也方便团队评审和后续调试。模板大概长这样：

Agent名称： 一句话职责： 核心能力列表（每个能力对应哪些工具）： 输入格式： 输出格式： 不允许做的事： 协作对象（上游/下游）： 失败时的默认行为： 敏感词/风格约束：

举个例子，一个“事实核查Agent”的定义可能长这样：

Agent名称：FactChecker 一句话职责：核验文本中的事实性陈述，返回问题清单 核心能力：搜索引擎检索、知识库查询、新闻源比对 输入格式：待核查文本（string） + 已知事实来源（optional） 输出格式：JSON数组，每项含 { claim, verdict, evidence, confidence } 不允许做的事：不修改原文，不给出修改建议 协作对象：上游为Writer，输出交给Reviewer 失败行为：如果检索结果为空，标记verdict=unverifiable

这份定义既是system prompt的基础，也是日志和监控的字段来源。它帮我解决了一个本质问题——让Agent的行为边界可预期。

2.3 角色数量的经验法则

早期的多Agent系统特别激进，动辄五六个、七八个Agent。后来我发现，Agent数量越多，系统整体效果不一定越好。理论上每个Agent可以更专业，但实际上消息传递会变得更加频繁，信息损耗变大，上下文累积越来越严重，最后的产出反而可能变差。

我现在的经验法则是：业务阶段数量，即每个内聚业务环节对应一个Agent，总数尽量控制在四个以内。超过四个，我会优先考虑合并职责，或把同类的工具托管到一个Agent里而不是线性加Agent。

有一个例子我记得很清楚。早期设计一个研报生成系统时，我拆了选题、资料、撰写、图表、校对五个Agent，结果发现资料Agent和撰写Agent之间的接口总是不稳定，后来把两者合并成一个“研究+写作Agent”，问题明显减少。原因在于资料和撰写都依赖同一个上下文语义，硬拆开反而割裂了信息流。

所以我建议你先从最少的Agent起步，比如两到三个，等跑通主流程后，再根据实际瓶颈增加Agent数量。不要一开始就把系统设计成八爪鱼，也不要为了演示效果堆砌Agent角色。

3. 通信与协作机制：让Agent们真正“对话”

角色分完之后，核心问题变成了：Agent之间怎么交换信息。这一块设计得好，系统就像一条顺畅的生产线；设计得不好，每个Agent都在猜别人想说什么，整个系统就是不稳定的“传话游戏”。

3.1 消息传递与共享黑板的取舍

Agent之间的协作模式，本质上可以分为两种：消息传递（Message Passing）和共享黑板（Shared Blackboard）。

消息传递的典型形态是一个Agent把处理结果发给下一个Agent，每个Agent独立消费前一个Agent的输出。这种方式的优点在于责任链清晰，日志方便追踪，出问题容易定位。管道式生产、多阶段处理，都比较适合。缺点是如果信息需要在多个Agent间来回流转，消息会形成复杂的回路，协调逻辑变得麻烦。

共享黑板是另一个思路。所有Agent读写同一块动态存储区，比如一个共享的JSON状态对象或向量数据库。任何Agent都往黑板上写自己的产出，也能读取其他Agent写入的信息。这种方式适合不确定性高、需要反复迭代的任务。缺点是并发写容易冲突，状态一致性不好保证，调试时看黑板的状态变化不如看消息流直观。

我个人更偏好消息传递为主，在局部需要共享信息时辅以轻量级黑板。具体到技术实现，常见的有两种形态。一种是纯应用层消息，比如Python里的队列、Redis Streams，或直接通过函数调用传参。另一种是语义层面的结构化对象，比如LangGraph里通过State对象传递的字典。后者更常见，修改成本低，跟模型直接交互也方便。

这里多说一句，很多人用LangGraph或AutoGen这类框架时，第一反应是先看它提供了什么通信原语，然后硬套。这个思路反了。应该先确认你的场景是流水线还是共享黑板，再去框架里找对应能力。

3.2 结构化消息协议设计

Agent之间的消息二八法则：20%是任务指令，80%是上下文和数据。我发现很多系统出问题，根子在于消息内容是模糊的自然语言长文，而不是结构化的字段。

我现在的做法是，每个Agent的输出必须是一个固定schema的JSON.Pydantic或TypedDict来定义。比如ResearchAgent输出：

class ResearchReport(BaseModel): topic: str findings: list[Finding] summary: str confidence: float used_sources: list[str] class Finding(BaseModel): claim: str evidence: str source: str

下游的WritingAgent拿到这份结构化产出后，直接消费字段即可。如果某个字段缺失，流程会显式报错，而不是让WritingAgent在自然语言里“找找看”。这个设计看似简单，但带来的稳定性提升是巨大的。

除了输出Schema，消息还应包含一些元数据。我常用的元数据字段有：

• sender：发送方名称
• intent：消息意图（请求审批、提供资料、通知完成等）
• trace_id：整条会话的追踪ID，用于关联日志
• timestamp：时间戳
• version：协议版本号，方便Schema演进

这些字段构成消息信封，核心数据放body，协作语义放header。收到消息的Agent可以先读header决定如何处理，再解析body。这个模式帮我解决了很多协作层面的歧义问题。

3.3 同步与异步的选择

多Agent协作里，同步和异步的选择直接关系到任务完成时间与资源消耗。

同步协作的含义是，Agent A调用Agent B后必须等待结果返回，才能继续执行后续逻辑。这种模式实现简单，逻辑清晰，适合任务依赖关系明确的场景。比如“写完内容必须等校验结果才能发布”，用同步调用就很自然。

异步协作则是消息发出后不等待，各自独立推进，最终汇总。这种模式适合并行处理多个独立子任务，比如同时让三个Agent分别检索三个不同方向的资料，然后汇总。它可以显著提升整体吞吐，但代价是系统复杂度上升。你需要处理超时、部分失败、结果合并等问题。

我的建议是：默认用同步，只有遇到明确的并行场景才上异步。很多初学多Agent的朋友一上来就搞异步任务队列，结果日志混乱、超时频发。异步的收益只有当任务之间存在真实并行性才能体现，否则徒增复杂度。

另外，无论同步还是异步，超时和重试机制都必须保证。给每个Agent调用设置合理的超时时间，比如30秒。超时后触发重试或降级策略，而不是无限等待。我自己遇到过不止一次因为漏配超时，导致整条Pipeline挂起十几分钟的灾难现场。

4. 编排模式：四种主流架构怎么选

编排模式是系统的主干。不同的任务结构对应不同的编排方式。我把常见的多Agent编排模式归纳为四类：Supervisor模式、Pipeline模式、Debate模式、分层自组织模式。每一种都有对应的适用场景和代价。

4.1 Supervisor模式：一个管家协调多个专家

Supervisor模式的特色是有一个中心调度Agent，其他Agent都是执行者。中心调度Agent负责理解任务、制定计划、把子任务派发给对应Agent，然后收集结果、决定下一步动作。你可以把它理解成一家公司里的项目经理，它不负责具体执行，但负责安排和协调。

这个模式的优点在于控制力强。一切任务分配和决策都经过Supervisor，系统行为好掌控，加约束也比较容易。缺点是Supervisor容易成为瓶颈——它需要理解所有子Agent的能力，并频繁调用它们，token开销和延迟都比较高。而且在复杂任务里，如果Supervisor对子Agent能力理解不准，任务派发就会出错。

实现上，我一般用有限状态机来描述Supervisor的决策逻辑。Supervisor的输出被约束为一个Action，比如“assign_task_to(X)”、“need_more_info_from(Y)”、“finalize”。这样比完全自由的自然语言规划可靠得多。

class SupervisorAction(BaseModel): action: str target_agent: str | None = None message: str = ""

使用Supervisor模式时，一个关键经验是给Supervisor明确的Atom能力清单。不要让Supervisor从工具描述里瞎猜子Agent能做什么。可以在system prompt里给一个表格，列出每个子Agent名称、职责、输入输出、典型调用场景。这会显著提升派发准确率。

4.2 Pipeline模式：流水线式依次处理

Pipeline模式比较朴素，Agent按固定顺序依次处理任务。A完成后把结果交给B，B再交给C。这个模式适合处理流程高度固定的场景，比如内容审核管线：生成→事实核查→风格润色→发布。

这个模式的好处是简单可靠、逻辑透明、非常容易调试。每个环节只需要关心上游数据和自己的输出。坏处是不够灵活，一旦某个环节需要动态分支或者并行处理，它就力不从心。

Pipeline模式还有一种变体叫条件Pipeline，即在环节之间加入路由判断。比如一个分类Agent先判断输入类型，然后路由到不同的下游Agent。这个变体在小规模多Agent系统里非常实用。

我在实际项目中，很多时候会先用一个简单的Pipeline跑通主流程，再根据瓶颈逐步改造成更复杂的模式。这比一开始直接上Supervisor或自组织架构稳妥得多。

4.3 Debate模式：多角色讨论与对抗式校验

Debate模式的核心是让多个Agent带着不同观点或不同角色参与同一个任务，通过讨论、质疑、反驳来收敛出最终结论。这种模式在处理需要严格校验、思路发散、立场多样化的问题时很有用。

常见的案例是代码审查系统：一个Agent写代码，一个Agent当安全审查员，一个Agent当性能优化师，三者反复讨论直到达成一致。还有事实核查系统，我可以让一个Agent负责找支持性证据，一个Agent负责找反驳性证据，最后用一个仲裁Agent综合判断。

实现Debate模式时，最需要注意的是控制讨论轮数和收敛条件。如果放任Agent们无限讨论，它们可能陷入冗长的“正义循环”，每次都说“你说得有道理，但是……”。我的经验是设定最大讨论轮数，比如三轮，并加入一个明确的收敛函数。比如要求每轮输出必须包含自己的结论及其置信度，当置信度超过阈值且无异议时终止。

另一个经验是给每个讨论Agent赋予清晰的立Zhang，不要让两个Agent拿着几乎相同的system prompt在那儿“讨论”。如果两个Agent的立场本质相同，讨论只会产生无效信息。Debate模式要有效，各方必须真的带着差异化的约束和目标进场，否则就是两个复读机互相对话。

4.4 分层自组织模式

分层自组织模式更高阶一些。它的核心思想是Agent可以自主创建子任务和子Agent来处理复杂问题，同时形成层级关系。顶层有一个主导Agent，它负责整体目标，可以将任务分解给中间Agent，中间Agent再拆给更细粒度的Agent。任务完成后结果逐层汇总。

这种模式的典型优势是扩展性极强，适合开放式任务，用户提出一个模糊目标，系统可以自主规划。Autogen和LangGraph里都有类似的分层结构实现。它的缺点也很明显，控制力弱，波动大。多个层级之间会出现意图丢失，子任务的规划质量不可控，调试的复杂度极高。

我的建议是，只有前几类模式都无法满足需求时，再考虑分层自组织。它更适合研究性或高度探索性的应用，不适合对稳定性有要求的生产环境。

4.5 模式选型对照

选型时的操作建议是这样的。流程固定、环节清晰，选Pipeline。角色多但对中心控制要求高，选Supervisor。需要审查、共识、对抗检验，选Debate。目标模糊且需要系统自主扩展，才考虑分层自组织。我很少见到一个系统自始至终只用一种模式。大多数成熟系统都是混合编排，主线用Pipeline，局部环节用Supervisor或Debate。这也是我想提醒大家的：不要拘泥于一种模式，按任务结构动态混搭往往效果更好。

5. 记忆与上下文管理：多Agent最容易翻车的环节

多Agent系统的记忆管理比单Agent难了一个量级。单Agent只需要管一段会话历史，多Agent却面临共享记忆、独立记忆、上下文分配、消息压缩等问题。这一块几乎是我见过的所有多Agent项目翻车的高发区。

5.1 共享记忆与独立记忆的划分

每个Agent都需要两类记忆：共享记忆和独立记忆。

共享记忆是整个系统的公共信息池，比如用户的原始需求、全局约束条件、历史决策记录。所有Agent都可以读取这个池子，避免信息重复传递。典型的实现是全局State对象或向量库。比如用户在系统最开始时说“预算控制在1000元以内”，这应该放进共享记忆，否则在第七个Agent调用时，这个关键约束可能已经被层层转发弄丢了。

独立记忆则是某个Agent独有的领域上下文，比如代码审查Agent自己积累的常见安全问题模式，或负责客户沟通的Agent掌握的客户偏好。独立记忆不传递给其他Agent，避免信息噪音。

我在实践里的原则很简单：全局约束放共享区，领域中间产物放独立区。共享记忆里的字段数量和颗粒度要收敛，不然每次消息传递都会把一大坨不需要上下文加载进每个Agent，Token消耗增长不说，还容易让Agent被无关信息误导。

5.2 上下文窗口的分配策略

每个Agent的上下文窗口都是有限的，需要精心分配。我的经验是按消息内容、Agent自身prompt、领域示例、历史记录的顺序来分配。

Agent自身prompt占用的context应当尽量压缩。我见过不少团队的system prompt本身就有三千甚至五千字，这种情况下可用的上下文空间被严重挤占。建议把system prompt控制在1000字以内，用简洁的指令交代职责、能力、约束、输出格式。更详细的细则放进工具的description里，或者做成单独的参考资料，按需加载。

领域示例是context占用大户，但也往往能提升效果。对于稳定场景，我建议把示例放在向量库里做动态检索，而不是全量怼进prompt。每个Agent只加载与自己当前任务最相关的两到三个示例。

历史记录的多轮会话是另一个大头。我会用摘要压缩来应对。比如当对话轮次超过一定阈值时，把之前的对话摘要成一个简洁段落，塞进context。这个策略能显著降低Token消耗，同时保留关键语义。

5.3 消息压缩与语义摘要

前面提到摘要压缩，这里展开说一下具体做法。一个Agent每处理一次任务，对话历史里就多一些中间信息。如果这些信息全部保留到下一个Agent，上下文会膨胀。我的做法是设置压缩阈值，比如消息数量超过10条或Token超过6000时，触发摘要Agent。

需要注意的是，压缩一定要保留动作相关信息和约束相关信息，而不是只做概括。比如一条历史中出现了“用户要求数据脱敏后再输出”，这条必须保留。而“用户对某个回答点头了”这类弱信号则可以去掉。建立一个“必须保留字段”白名单，让摘要Agent按白名单提取。

我还遇到过一个问题：摘要Agent在压缩时过于倾向压缩，把关键数据丢了。解决办法是摘要的输出格式固定为结构化字段，比如任务目标、约束条件、已产出数据、未完成事项。每个字段单独填，缺失字段要显式标为unknow，而不是靠摘要Agent用自然语言自行发挥。这样下游Agent至少知道哪些信息是缺失的，不至于盲目假设。

6. 工具与外部系统集成

多Agent系统的价值很大一部分来自工具调用。每个Agent如果能高效调用自己需要的工具，系统的能力边界就可以扩展到纯LLM之外的领域。工具集成设计得好与不好，直接决定系统的靠谱程度。

6.1 工具注册与权限控制

工具接入的第一步是注册。每个Agent能看到的工具列表应该是一个白名单，而不是全量工具。这个白名单基于Agent职责来生成。写代码的Agent只看到代码执行工具，文章润色Agent只看到文本处理工具，事实核查Agent只看到搜索工具。

这样做的好处很直接。Agent的工具选择空间小了，误选工具的几率降低；工具描述可以写得非常精细；安全性也更好，每个Agent根本没有能力触及不该用的工具。

权限控制还包括写权限。有些工具是可以读外部信息的，有些是可以写数据的。比如检索工具只提供只读，数据库Agent才有写库权限。我在实际实现里会把工具按权限等级分组，Agent在注册时声明自己需要哪个等级的工具，由系统侧的注册表统一校验。这不是复杂的安全系统，但能挡住一大部分误操作。

6.2 谁来决定调用工具

很多多Agent框架把工具调用权限直接给Agent，让它自己决定调哪个工具。这在小规模场景里没问题，但当工具数量增多时，LLM的工具选择准确率会下降。我最近一年越来越倾向于用规则或者另一个小型Agent做工具分发，而不是让领域Agent自己做决定。

拿内容生产系统举例。写作Agent的输出是一篇草稿，它自己要调用“翻译工具”“语法检查工具”还是“Markdown转换工具”？如果让它自己选，很可能选错。我在这之间加了一个“工具路由Agent”，把写作Agent的意图和输出传入，这个路由Agent用一套小模型或简单规则来决定调用哪个工具。效果提升明显，特别是工具数量超过10个之后。

当然，如果工具数量只有三五个且互不冲突，让Agent自己判断也完全够用。工具调用的判断权和执行权的分离，是我建议在多Agent系统里尽早考虑的设计决策。

6.3 工具调用的观测与审计

多Agent系统里工具调用贯穿整个任务生命周期，观测与审计绝不能少。我在系统里为每次工具调用都打一条日志，记录Agent名、工具名、输入参数摘要、返回结果的截断内容、耗时、成功与否。这套日志让我能回答三个关键问题：哪个Agent在什么环节调用了什么工具，花了多久，成功没有。

工具调用日志还有一个重要用途：构建调试时的“时间线回放”。当系统产出异常结果时，我可以沿着trace_id把每个Agent在什么时刻看了什么数据、用了什么工具的动作链重新走一遍。这个回放能力是定位多Agent系统问题的最有效工具，甚至比看模型输出日志更有价值。没有这套记录，就只能靠猜。

我在设计时还有一个经验，对于外部API型的工具，比如调用收费的第三方接口，一定要在工具层加额外的熔断和额度限制。多Agent系统远比单Agent更频繁地调用外部工具，一旦某个Agent陷入循环，可能几秒钟就把额度打爆。给每类工具设置每日调用上限和单次任务调用上限，能挡住大多数事故。

7. 可观测性、评估与持续迭代

很多人把多Agent系统写出来之后，就专心调prompt，却忽略了可观测性和评估。结果就是系统上线后出了问题只能靠用户反馈，数据也拿不到手。我吃了不少苦头才意识到，可观测性是生产级多Agent系统的基础设施，不是辅助功能。

7.1 日志记录的关键字段

多Agent系统在调试时最缺的往往是信息，而不是智能。日志设计优先从“我之后可能需要什么问题”这个方向倒推。

我需要知道每个Agent从上游收到了什么消息，这是判断问题根源的第一线索。收到的消息id、长度、内容摘要都要记录。Agent在处理过程中输出了什么中间思考或tool call，这能看出它的处理思路是否偏了。最后的输出是什么，是否通过了schema校验。调用链的父级id是什么，能还原整棵调用树。耗时和token量也要记录，特别是定位性能瓶颈时。

我把这些字段统一放到一个结构化日志库或像LangSmith这类Trace工具里，支持按trace_id查询完整链路。这个线性的调试体验，是生产级系统最基础的保障。

7.2 评估指标：任务成功率与协作效率

多Agent系统的评估，不能只看最终任务的通过率。还需要维度更丰富的指标。我把它们分成两组。

第一组是结果类指标。任务成功率是核心，指用户任务是否在允许的步骤内完成了。任务完成质量可以用人工抽检或LLM-as-Judge打分，比如内容生产的质量分、客服话术的满意度分。这些指标能反映系统整体效果。

第二组是过程类指标。协作效率至关重要，包括每个任务的平均调用Agent数量、平均消息往返次数、超时和重试频率。过程类指标的价值在于指出系统瓶颈所在。比如发现某个Agent在80%的任务里都要被重试，这通常意味着它上游的信息质量有问题，而不是它自己能力不足。再比如平均消息往返次数超过10次，这就提示你的编排逻辑可能存在低效的循环。

我目前的评估方式是把结果指标和过程指标搭配使用。先看最终效果，再拿过程指标做归因分析，而不是单看一个数字来调参。一个大促前的系统优化周，我和团队几乎全靠这套指标体系来定位问题。

8. 常见问题与排查技巧实录

多Agent上线稳定运行一段时间后，我开始积累一份问题排查清单。每次生产环境出现异常，我基本能根据现象快速归类到某个根因类别。

8.1 Agent陷入无限循环

多Agent场景里最常见的故障之一，是Agent之间进入“争论回合”，互相抛球，各说各的，但任务没有任何进展。表现为消息数快速增长，任务长时间不结束，Token消耗飙升。

排查思路是从日志里看消息通道是否出现两支互相应答的消息。比如Reviewer输出“有3个问题，请修改”，Writer输出“已修改”，Reviewer又输出“仍有2个问题”，如此往复。造成无限循环的原因通常是缺少收敛条件或收敛条件定义模糊。

解决这类问题需要在系统层面加两条硬约束。第一，设置最大任务步数上限，到达后强制进入“生成结论”模式，不让Agent继续迭代。第二，在消息信封里增加iteration_index字段，大于阈值时要求Agent必须输出最终结论。不要寄希望于模型自带收敛能力，靠系统约束才稳。

8.2 上下文污染与信息丢失

上下文污染的表现是Agent的最终输出里混入了不该有的旧信息或无关信息。信息丢失的表现是某个关键约束经过多层传递后消失了。

排查时沿着消息链检查每个Agent的输出是否把上游关键字段原样传导到下游。我遇到过不止一次，ResearchAgent的核心结论字段没有放进WriterAgent的输入里，WriterAgent只能靠自己的“想象力”补充内容，产出自然偏了。解决之道是给每个Agent的输出Schema加必填字段校验。Schema是强校验，某字段缺失就让任务报错，而不是继续往下游传递。

上下文污染通常来自共享记忆体里塞了太多无关字段。建议定期清理共享State里已过期的变量，并限制每个Agent能读的键名范围，不要让它扫一眼整个共享区然后自己挑。

8.3 角色职责重叠导致的结果混乱

当两个Agent职责边界重叠时，会出现任务执行重复或结果冲突。典型场景是“资料整理Agent”和“写作Agent”都在做资料筛选，筛选标准不同，最终产出两边打架。

排查方式是看哪些Agent在日志里访问了同样的工具，或者输出了语义上相似的中间产物。如果出现了这种重叠，我一般会直接调整职责边界，把重叠部分明确划给其中一个Agent，而不是让它们靠沟通去协调。让两个Agent去讨论“谁来做”是低效且不稳定的。职责边界的确定性，要强于任何协作上的灵活性。

8.4 排查清单速查

每类问题基本都有对应的设计防线。提前设计这些防线，比事后排查省力得多。这也是我为什么强调在设计阶段就要把Schema校验、协商收敛、职责边界这些“乏味的工程细节”做扎实。多Agent系统的天花板取决于模型能力，但地板很大程度上取决于工程约束。

9. 个人实操经验与扩展建议

最后聊一点项目沉淀下来的感受。

多Agent设计最容易被低估的，是“约束工程”的重要性。大家往往把注意力放在Agent角色和模型类别上，忽略了链路里的硬约束。我在反复试验中体会到，真正让多Agent稳定运行的不是更聪明的prompt，而是更强的约束。包括输出Schema校验、最大步数限制、工具白名单、共享State的字段收敛，这些约束每加一道，系统的可控性就上一个台阶。

另一个体会是异步与并行的度要克制。我早期很迷信并行，把大量Agent调度改成异步，结果换来的是系统复杂度和故障率上升。后来收敛为“只有真正需要才并行，其余同步”，整体稳定性明显提升。多Agent设计跟软件工程里的很多原则是相通的：能简单就不复杂，能确定就不要“让Agent自己想”。

还有一个心得是重视trace能力。上线之初就配套好完整的日志链路，后续调优会顺畅很多。没有trace系统的多Agent项目，在出问题时的排查成本会高得让人崩溃。我建议至少做到每条消息都能通过trace_id回放整条链路的程度。

后续扩展方向上，我目前在尝试把“可复用的子Agent”做成组织级资产，比如内容创作管线里的Writer和FactChecker，跨项目复用。这样新项目可以直接引用已有Agent配置，效果经过验证，省去大量重复调优。另一个方向是给系统外部引入强化学习和评测闭环，逐步用自动评测替代人工抽检。这条路还比较长，但方向是确定的。

多Agent设计没有万能公式，但确实存在一套经过验证的工程思路。把角色划清楚、把消息结构定好、把编排模式选对、把记忆和约束管住，这套方法论已经帮我稳定落地多个生产系统。希望这篇内容能给你一些参考。