企业官网建设流程全解析

多agent系统这两年从论文里的概念一路杀到生产环境，我身边不少团队都在做，但真正跑通并且能长期维护的并不多。大部分项目卡在同一个地方：demo阶段几个agent互相调用看起来很美好，一旦接入真实业务、并发上来、需求变更，整个系统就开始失控——agent之间互相甩锅、任务重复执行、日志查不到根因、改一个prompt崩掉三个下游。这不是模型能力的问题，是系统工程的问题。

我前后参与过三个多agent系统的落地，从最初的"能跑就行"到后来不得不补上治理体系，踩的坑足够写一本小册子。这篇内容想聊的是：当你决定用多agent架构解决一个真实业务问题时，从架构设计到治理体系，到底该怎么想、怎么拆、怎么落地。适合正在做或者准备做多agent系统的工程师、架构师，也适合想搞清楚"多agent到底能干什么、不能干什么"的技术负责人。全文围绕架构分层、协作机制、治理体系、落地节奏这几个核心点展开，尽量给到可以直接抄作业的结构和参数。

1. 先想清楚多agent到底解决的是哪类问题

1.1 单agent的天花板在哪里

很多人上多agent是因为单agent"不够用"，但具体哪里不够用说不清楚。我见过最常见的理由是"任务太复杂了"，这个理由太模糊。单agent真正的天花板体现在三个具体维度上。

第一个维度是上下文窗口的物理限制。一个agent要同时处理需求理解、数据查询、逻辑推理、结果格式化，所有中间状态都塞在一个上下文里。当任务涉及的工具超过七八个、需要引用的文档超过几万字，上下文就开始被稀释，模型对早期信息的注意力明显下降。这不是换个更大窗口的模型就能解决的，因为注意力机制本身在长上下文里就有衰减。

第二个维度是职责耦合导致的错误传播。单agent里，一个环节的幻觉会直接污染后续所有推理。比如它先错误地理解了一个字段含义，后面基于这个错误理解做的所有计算全是错的，而且你很难定位是哪一步开始错的。多agent的价值在于把职责切开，让每个agent的输出可以被独立验证。

第三个维度是并行化的需求。有些任务天然可以拆成互不依赖的子任务，比如同时查三个数据源、同时生成多个候选方案。单agent只能串行做，多agent可以并行，这在延迟敏感的场景里是刚需。

注意：如果你的任务用单agent加几个工具就能稳定完成，不要上多agent。多agent带来的复杂度是指数级的，它应该是被具体问题逼出来的选择，而不是技术炫技。

1.2 多agent不是"多个prompt拼起来"

这是我最想纠正的一个认知偏差。很多团队做多agent，本质上是把一个大prompt拆成几个小prompt，然后用代码串起来调用。这确实能跑，但它不是多agent系统，它只是一个流水线。

真正的多agent系统，agent之间应该有自主的协作行为：一个agent可以根据另一个agent的输出决定自己下一步做什么，可以在信息不足时主动发起询问，可以在发现异常时拒绝执行并上报。这种自主性才是多agent和流水线的本质区别。

我做过一个对比实验，同样的任务，流水线版本在正常路径下表现和多agent版本差不多，但一旦遇到边界情况——比如某个数据源返回了格式异常的数据——流水线版本会直接把异常数据往下传，最后产出一个看起来合理但完全错误的结果；多agent版本里负责校验的agent会拦截并触发重试。这个差异在demo里看不出来，在生产环境里就是事故和正常的区别。

1.3 什么场景值得上多agent

基于我的经验，下面这几类场景上多agent的投入产出比最高。

反过来，如果你的任务是单轮问答、简单的信息抽取、或者步骤少于5步的固定流程，老老实实用单agent或者直接写代码，别折腾。

2. 架构设计：把agent当成微服务来设计

2.1 分层架构是绕不开的

多agent系统最容易犯的错是把所有agent平铺在一起，谁都能调用谁。这种网状结构在agent数量少于5个时还能维护，超过10个就是灾难。我的做法是强制分层，参考微服务的思路，但针对agent的特性做了调整。

我通常把系统分成四层。接入层负责接收外部请求、做初步的意图识别和任务分发，这一层通常只有一个入口agent。编排层是核心，负责把复杂任务拆解成子任务、决定调用哪些执行agent、汇总结果，这一层可能有一个或多个编排agent。执行层是真正干活的agent，每个agent封装一组相关的工具和能力，比如"数据库查询agent""文档解析agent""代码生成agent"。基础层不是agent，而是所有agent共享的能力：记忆存储、工具注册中心、日志追踪、权限校验。

这个分层的关键约束是：只能上层调用下层，同层之间通过编排层协调，禁止跨层直接调用。执行层的agent不能直接调用另一个执行层agent，必须经过编排层。这个约束看起来降低了效率，但它让整个系统的调用链路变得可追踪，出问题时能快速定位。

2.2 agent的粒度怎么定

粒度是多agent设计里最难的决策。太粗，等于没拆；太细，通信开销爆炸。我总结了一个判断标准：一个agent应该对应一个"可独立验证的职责单元"。

具体来说，如果一个职责的输出可以被独立地判断对错，那它就适合做成一个agent。比如"从数据库查出用户订单"这个职责，输出是订单列表，可以独立验证对错，适合做成agent。"理解用户意图"这个职责，输出是意图标签，也可以独立验证，适合做成agent。但"处理用户请求"这种包含多个环节的职责，输出无法独立验证，就不适合做成单个agent。

另一个实操标准是工具数量。一个agent挂载的工具最好控制在5到8个。超过10个工具，模型选择工具的准确率会明显下降，而且prompt会变得很长。如果某个职责需要20个工具，那它应该被拆成2到3个agent。

2.3 通信机制：消息传递还是共享状态

agent之间怎么交换信息，有两种主流做法。消息传递是agent之间直接发消息，每个agent维护自己的状态。共享状态是所有agent读写同一个状态存储，通过状态变化来协作。

我的经验是：默认用消息传递，只在特定场景用共享状态。消息传递的好处是解耦彻底，每个agent可以独立测试、独立部署、独立扩展。共享状态的好处是信息同步及时，适合需要频繁读取全局信息的场景，比如多个agent需要基于同一份实时数据做决策。

实际项目里我通常混用：agent之间的任务分发和结果回传走消息传递，全局的配置、用户会话信息、共享的缓存走共享状态。但共享状态一定要有明确的读写权限控制，否则会变成新的耦合点。

# 消息传递的典型结构 class AgentMessage: def __init__(self, sender, receiver, task_type, payload, trace_id): self.sender = sender # 发送方agent标识 self.receiver = receiver # 接收方agent标识 self.task_type = task_type # 任务类型，用于路由 self.payload = payload # 实际数据 self.trace_id = trace_id # 全链路追踪ID self.timestamp = time.time()

这个结构里trace_id是关键，它让一次完整请求经过的所有agent都能被串起来，排查问题时按trace_id一查到底。

2.4 编排模式的选择

编排层怎么组织执行agent，有三种模式，各有适用场景。

顺序编排最简单，agent按固定顺序执行，前一个的输出是后一个的输入。适合流程固定的任务，比如"解析文档→提取字段→校验字段→入库"。优点是可控，缺点是僵化。

路由编排根据任务类型动态选择执行agent。比如一个客服系统，先判断用户问题类型，然后路由到对应的处理agent。适合任务类型明确但多样的场景。

自主编排最复杂，编排agent根据当前状态自主决定下一步调用谁，甚至可以动态生成新的子任务。适合开放式任务，比如复杂的研究分析。但自主编排的可预测性差，生产环境要慎用，必须配合严格的边界约束。

我的建议是：从顺序编排起步，稳定后再引入路由，自主编排只在有明确护栏的前提下使用。很多团队一上来就搞自主编排，结果系统行为完全不可预测，根本没法调试。

3. 协作机制：让agent真正"配合"起来

3.1 任务拆解的质量决定一切

多agent系统的上限，取决于编排agent把任务拆得有多好。拆解质量差，后面所有agent再强也白搭。我见过太多系统，执行agent个个精雕细琢，但编排agent的拆解逻辑一塌糊涂，最后产出惨不忍睹。

好的任务拆解要满足三个条件。子任务之间尽量正交，也就是一个子任务的执行不依赖另一个子任务的中间结果，这样才能并行。每个子任务有明确的验收标准，执行agent知道自己做到什么程度算完成。子任务的粒度适中，太粗执行agent搞不定，太细通信开销大。

实操中我会给编排agent一个拆解模板，强制它按模板输出。模板大概长这样：

任务目标：[一句话描述] 子任务列表： 1. 子任务描述 | 负责agent | 输入 | 期望输出 | 验收标准 2. ... 依赖关系：[哪些子任务有先后依赖] 汇总方式：[如何把子任务结果合成最终答案]

这个模板强制编排agent把拆解逻辑显式化，既提高了拆解质量，也让拆解结果可审查。

3.2 冲突消解：多个agent给出矛盾结果怎么办

这是多agent系统里最棘手的问题之一。比如两个agent对同一个数据给出了不同的解读，或者多个agent生成的方案互相矛盾。处理不好，系统要么卡死，要么随机选一个，要么把矛盾直接抛给用户。

我的处理策略是分三层。第一层是置信度比较，每个agent输出结果时附带置信度，编排层优先采信高置信度的结果。置信度怎么来？可以让agent自评，也可以基于历史准确率统计。第二层是仲裁agent，当置信度接近或者都偏低时，触发一个专门的仲裁agent，它的职责是分析矛盾原因并给出裁决。第三层是人工兜底，仲裁agent也无法决断时，标记为需要人工介入，而不是硬选一个。

提示：置信度自评有个坑，模型普遍过度自信，自评的置信度往往偏高且区分度低。更可靠的做法是基于历史数据统计每个agent在每类任务上的实际准确率，用统计值作为置信度。

3.3 记忆共享的边界

多agent系统里，记忆共享是个双刃剑。共享太多，agent之间互相污染，一个agent的错误认知会扩散到全局。共享太少，agent之间信息不通，重复劳动。

我的做法是把记忆分成三层，明确每层的共享范围。私有记忆是每个agent自己的，记录它自己的执行历史、中间状态，不共享。任务记忆是同一次任务内所有agent共享的，记录这次任务的上下文、已完成的子任务、关键中间结果，任务结束就销毁。全局记忆是跨任务共享的，记录长期有效的知识，比如用户偏好、业务规则，但写入要严格审核。

这个分层的关键是任务记忆的生命周期管理。任务开始时创建，任务结束时清理，避免记忆无限增长。我见过系统因为任务记忆没清理，跑了一个月后上下文里全是历史垃圾，性能断崖式下跌。

3.4 失败重试与降级

agent执行失败是常态，不是异常。网络抖动、工具超时、模型输出格式错误，都会导致失败。关键是怎么处理。

我的重试策略是分级重试。格式错误这类问题，直接重试通常能解决，重试2到3次。工具超时这类问题，重试前先检查工具状态，避免无效重试。逻辑错误这类问题，重试没用，需要把错误信息反馈给agent让它修正，这种叫"反思重试"，通常一次就够。

降级策略要提前设计。当某个执行agent持续失败，编排层应该能切换到备用方案。比如主agent失败，切到简化版agent；简化版也失败，返回部分结果并明确标注哪些部分未完成。最忌讳的是静默失败，系统返回一个看起来完整但实际残缺的结果，用户根本不知道。

4. 治理体系：让系统能长期活下去

4.1 可观测性：没有追踪就没有治理

多agent系统最怕的就是"黑盒"。用户反馈结果不对，你根本不知道是哪个agent、哪一步出的问题。所以可观测性不是可选项，是必选项。

我要求系统必须记录四类信息。调用链路，每次请求经过哪些agent、顺序如何、耗时多少。输入输出，每个agent收到的输入和产出的输出，完整记录。决策依据，agent为什么选择这个工具、为什么给出这个结果，关键推理过程要留痕。异常信息，所有失败、重试、降级事件都要记录。

这些信息通过trace_id串联，排查时按trace_id一查，整个链路一目了然。存储上，调用链路和异常信息可以长期保留，输入输出因为数据量大，通常保留最近7到30天。

# 追踪记录的核心字段 trace_record = { "trace_id": "xxx", # 全链路ID "agent_id": "xxx", # 当前agent "step": 3, # 第几步 "input": {...}, # 输入 "output": {...}, # 输出 "tools_used": [...], # 用了哪些工具 "duration_ms": 1200, # 耗时 "status": "success", # 状态 "retry_count": 0 # 重试次数 }

4.2 质量评估：怎么知道系统在变好还是变坏

多agent系统上线后，质量会随着各种变更（prompt调整、模型升级、工具更新）而波动。没有评估机制，你根本不知道某次变更到底是优化还是劣化。

我通常建两套评估。离线评估用固定的测试集，每次变更后跑一遍，对比关键指标。测试集要覆盖正常路径和边界情况，我一般准备50到100个case。在线评估监控生产环境的实时指标，比如任务完成率、平均重试次数、人工介入率、用户满意度。

关键指标我关注这几个：端到端成功率，一次请求不需要人工介入就成功的比例；平均agent调用次数，反映编排效率；重试率，反映执行稳定性；降级率，反映系统韧性。这些指标要建立基线，偏离基线超过阈值就告警。

4.3 版本管理与灰度

多agent系统里，每个agent的prompt、工具配置、模型版本都是独立的变更点。变更管理做不好，一次小改动可能引发连锁反应。

我的做法是所有agent配置版本化，每次变更生成新版本，记录变更内容和变更人。变更必须走灰度，新版本先接少量流量，观察指标无异常再逐步放量。支持快速回滚，任何版本都能一键切回上一版。

灰度策略上，我通常按流量比例灰度，从5%开始，观察24小时，没问题放到20%，再到50%，最后全量。如果中途指标异常，立即回滚。这个流程看起来慢，但比出事后再救火快得多。

4.4 成本控制：多agent的隐性开销

多agent系统的成本比单agent高得多，因为一次请求可能触发十几次模型调用。不控制成本，账单会很难看。

控制成本有几个抓手。减少不必要的agent调用，编排层要能判断哪些子任务可以跳过。缓存高频结果，相同或相似的子任务结果可以复用。分级模型，简单任务用便宜的小模型，复杂任务才用大模型。限制重试次数，避免失败任务无限重试烧钱。

我做过统计，一个设计良好的多agent系统，通过缓存和分级模型，成本能比naive实现降低60%以上。这个优化空间很大，值得投入。

5. 落地节奏：别想一步到位

5.1 从最小可用系统起步

我见过太多团队一上来就设计一个宏大的多agent架构，结果三个月过去还在调架构，一个能用的功能都没有。正确的做法是先跑通一个最小闭环。

最小闭环通常包含三个agent：一个入口agent负责接收和分发，一个执行agent负责核心任务，一个校验agent负责检查结果。这三个agent跑通一个真实场景，哪怕只覆盖最简单的case，也比设计一个完美架构但跑不起来强。

跑通最小闭环后，你会对系统的真实瓶颈有直观感受，这时候再针对性扩展，比凭空设计靠谱得多。

5.2 迭代扩展的顺序

扩展的顺序我建议是：先加执行agent，再加编排能力，最后加治理。

先加执行agent是因为执行能力是系统的价值基础，没有足够的执行能力，编排再花哨也没用。加执行agent时，每个新agent都要独立测试通过才接入。

编排能力在有了3到5个执行agent后再增强，因为agent太少时编排的价值体现不出来。编排能力的增强包括更智能的任务拆解、更灵活的调用策略、更完善的冲突消解。

治理体系在系统有了一定规模、开始接入真实流量后再补。太早做治理是过度设计，太晚做治理是技术债。我的经验是当系统每天处理超过1000次请求，或者agent数量超过10个，就该认真做治理了。

5.3 团队协作的注意事项

多agent系统的开发往往涉及多个人的协作，每个人负责不同的agent。协作上有几个坑要注意。

接口约定要先行。agent之间的消息格式、字段含义、错误码，这些要在开发前就定死，否则各写各的，集成时全是问题。prompt要集中管理，不能散落在各个人的代码里，否则改起来找不到。测试要统一标准，每个agent的测试用例格式、评估指标要一致，否则没法横向对比。

我通常会在项目初期建一个agent注册中心，所有agent的元信息（职责、接口、负责人、版本）都登记在里面。这个注册中心是团队协作的枢纽，也是后续治理的基础。

6. 几个我踩过的真实坑

6.1 编排agent的"过度自信"

早期我做的系统里，编排agent经常在信息不足的情况下强行拆解任务，导致执行agent拿到模糊的指令，产出垃圾。后来我在编排agent的prompt里加了一条硬约束：信息不足时必须先发起澄清，禁止猜测。这条约束加上后，系统的准确率明显提升，虽然多了一轮交互，但值得。

6.2 工具描述不清导致的误用

执行agent选错工具，很多时候不是模型的问题，是工具描述写得不好。我见过工具描述只写"查询数据"，模型根本不知道查什么数据、参数怎么传。后来我强制要求每个工具的描述包含：功能说明、适用场景、参数含义、返回格式、使用示例。工具描述写清楚后，工具选择准确率从70%多提升到90%以上。

6.3 日志太多反而找不到问题

可观测性做过头也是问题。有段时间我记录了所有agent的所有中间状态，日志量爆炸，排查问题时在几万条日志里找线索，效率极低。后来我改成分级日志：关键决策点记详细日志，常规执行记摘要日志，只有异常时才展开详细记录。这样日志量降了一个数量级，排查效率反而提高了。

6.4 忽视冷启动的代价

系统刚上线时，历史数据少，置信度统计、缓存命中率都低，表现会比稳定期差不少。这个冷启动阶段要有预期，不能因为初期指标不好就否定整个架构。我的做法是冷启动期放宽降级阈值，多走人工兜底，积累数据后再逐步收紧。

多agent系统的落地，技术只是一部分，更多是对系统复杂度的管理。把架构分层、协作机制、治理体系这三件事想清楚，落地节奏控制好，系统才能从demo走到生产，并且长期活下去。我个人的体会是，克制比激进更重要——不要为了多agent而多agent，不要为了架构完美而拖延落地，不要为了功能丰富而牺牲可维护性。每次想加一个新agent、新能力之前，先问自己：现有的系统真的解决不了吗？如果答案是"能解决但不够优雅"，那就先别加。