企业官网建设流程全解析

1. 为什么AI原生应用离不开多代理系统

1.1 单个Agent撑不住的真实场景

过去一年里，我前前后后参与了几个AI原生应用的落地项目，最早的做法和大多数团队一样：一个大模型实例，接上Prompt和工具，希望通过一个Agent搞定所有事情。最初的效果确实惊艳，但一旦场景复杂起来，问题就接二连三地冒出来。

举个例子，我们当时做的是一个智能客服加销售助手的AI原生应用，要求它不仅回答产品问题，还要查库存、算价格、写报价单、跟踪订单状态。第一版用单Agent方案的时候，所有功能都堆在一个系统提示词里，所有工具也一次性全挂上去。结果就是上下文很快就塞满了不相关的工具说明，模型经常在查库存和算折扣之间来回横跳，偶尔还会把订单状态的查询结果当成报价依据，数据错得离谱。

还有一个更隐蔽的坑：当单个Agent需要同时承担“理解用户意图”“判断需要哪个工具”“生成回复内容”这三件事时，它对每一件事的能力都会打折扣。就像一个人又当前台又当会计又当仓库管理员，每件事都知道一点，但每件事都做不到精细。我们当时还试过通过修改提示词来提高精度，加了很多约束条件，结果效果反而更差，因为上下文越复杂，模型决策的稳定性越低。

1.2 拆开之后反而更强

后来我们换了一种思路：把一个大而全的Agent，拆成多个专职的小Agent。这个转变对应的正是“多代理系统”的核心思想。也就是说，不是让一个Agent处理所有事情，而是让多个Agent各管一段，由一套机制负责调度它们之间的协作。

拆开之后的第一个变化是上下文变干净了。每个Agent只需要加载和自己职责相关的系统提示词和工具，不会被无关内容干扰。比如负责查库存的Agent，它的提示词只需要聚焦在库存数据上，上下文长度大大缩短，模型理解的准确度明显提升。负责写报价单的Agent，只需要关心报价规则和模板格式，输出的质量也更稳定。实测下来，同样的任务，拆成多代理后，准确率能提升百分之二三十，耗时反而因为上下文短而有所下降。

第二个变化是容易出现故障的位置变得可控了。单Agent方案里，任何一个环节出错，整个流程就断了。多代理方案里，如果负责查库存的Agent出问题，调度层可以重试或者走降级逻辑，其他Agent照常工作，对用户的整体体验影响更小。

1.3 什么场景才值得上多代理

当然，并不是所有项目都需要多代理系统。我不建议你听到这个名词就立刻把现有的单Agent架构推翻重做。根据我的实践经验，这几种场景最适合引入多代理系统：

• 流程中涉及三种以上不同类型工具，而且这些工具之间的调用顺序经常变化。
• 任务需要多轮状态跟踪，比如从“理解需求→查询数据→生成文档→审核发送”，每一步的输入依赖前一步的输出。
• 需要针对不同角色做定制化输出，比如同一个查询结果，给销售人员和给管理层看的摘要要点完全不同。
• 单Agent方案的上下文频繁超过模型窗口的一半，Prompt里不得不砍功能才能塞下所有内容。

如果只是问答、翻译、简单的文本生成，用单Agent就够了。强行上多代理反而会因为调度开销让简单任务变慢，得不偿失。

2. 多代理系统的整体架构与核心角色

2.1 调度者：所有Agent的大脑

多代理系统里最重要的角色不是那些干活的专业Agent，而是最上层那个负责分派任务的调度者，也就是常说的协调者或编排器。它的职责可以理解为：接收用户请求，拆解任务，决定调哪些Agent、按什么顺序调、如何汇总结果。

在设计调度者的时候，我有一个特别深的体会：调度者几乎不需要调用业务工具，它要做的是一个纯粹的“分诊台”。我们把用户请求先交给调度者，由它输出一个结构化的任务清单，包含所需Agent的标识、输入参数和期望输出。这一步看似简单，却决定了整个系统能否稳定运行。如果调度者自己也要查数据、算结果，那它很快就会被细节拖住，失去大局判断力。

在实际实现的时候，调度者的决策方式一般有两种。一种是用大模型来做动态规划，也就是每次拿到新请求，让模型根据请求内容灵活决定下一步调用谁。另一种是预定义工作流，把“先查库存再算价格”这种固定路径固化下来。我个人建议用两者的混合：主流程走预定义模板，遇到模板覆盖不了的情况再由模型动态扩展。这样既能保证核心路径的稳定性，又能保留灵活应变的能力。

2.2 专业Agent：各司其职的执行单元

专业Agent是多代理系统的执行层，它们各管一个领域、一个工具集或一类输出。和单Agent方案里那个全能的Agent不同，专业Agent的目标很纯粹：把一件小事做好。

在实际落地时，我给专业Agent定的设计原则是“小而专”。比如做一个“翻译Agent”，它只负责翻译，不负责判断译文风格是否符合客户偏好；判断风格这件事留给另一个“审校Agent”。如果让翻译Agent同时干这两件事，它的系统提示词就会变长，决策就会变乱。

另一个需要注意的点是专业Agent的输出格式。调度者要调用它的结果去做下一步判断，如果它的输出是自由文本，调度者解析起来很费劲。我们通常会让每个专业Agent输出JSON结构，并且强制规定字段名称和类型。比如查库存Agent的输出至少包含产品ID、可用数量、预计补货日期这三个字段。这样一来，下游Agent和调度者都能稳定地拿到结构化数据。

2.3 工具层与记忆层的分工

多代理系统的底层还有两个容易被忽略的支撑层：工具层和记忆层。

工具层负责封装真正的外部系统调用，比如数据库查询、第三方API、文件读写、消息发送等。关键是要把工具从Agent的决策逻辑中解耦出来。也就是说，Agent只负责决定“我要查库存”，通过一个统一的函数调用来完成，而不用关心库存数据到底存在MySQL还是存在Redis里。工具层做得好，Agent之间的调用就稳定。

记忆层则负责保存两种信息：长期记忆和短期上下文。长期记忆通常存在向量数据库里，存的是用户偏好、历史决策、常见问题等。短期上下文则是当前会话里各Agent之间流转的消息集合。我的建议是长期记忆和短期上下文必须分开存储，否则时间一长，向量数据库的热查询性能会明显下降，而且检索时容易把历史信息误当成当前任务输入。

2.4 通信协议与任务编排

多代理系统里，Agent之间的通信方式直接决定了系统的健壮性。我见过不少项目把Agent之间的消息写成随便的字符串，结果下游Agent解析字符串时因为格式不统一频繁报错。更稳妥的做法是所有Agent之间统一使用JSON格式的“消息信封”，里面至少包含消息ID、发送者、接收者、消息类型、负载数据、时间戳这几个字段。

任务编排方面，有三种基本模式需要掌握：顺序编排、并行编排和条件编排。顺序编排适合“先查库存再报价”这种依赖关系明确的任务；并行编排适合可以同时进行的独立子任务，比如同时查不同区域的库存数据；条件编排则根据某个中间结果决定后面走到哪个分支，适合“如果用户是企业会员则调用折扣计算Agent，否则直接进入报价流程”这种场景。

我们团队的实践结论是，至少要把顺序和条件这两种模式在自己的代码里实现并测试通过，然后再考虑并行。因为并行编排涉及并发控制、结果合并，调试难度比前两者高不少，不适合新手一上来就挑战。

3. 核心机制与关键配置经验

3.1 任务分解的粒度怎么定

多代理系统设计得好不好，很大程度取决于任务分解的粒度。太大，每个Agent又重新变成小全能选手，问题依旧；太小，Agent数量爆炸，调度开销和Token消耗都会猛涨。

我的判断标准很简单：如果一个子任务不需要依赖其他Agent提供的信息，而且能够用工具独立完成，那它就适合单独拆一个Agent。反过来说，如果两个子任务总是成对出现，且必须共享中间结果，比如“查外部公开数据→翻译成中文”，那宁可合成一个Agent，内部做两次处理，也别拆成两个，否则调度层面反而更复杂。

另外，任务分解时还要考虑实用粒度——不要设计超过七个Agent。我们做过实验，五个以上的Agent工作时，调度者做任务分派的准确率明显下降，因为选项太多，模型容易分错。如果你觉得确实需要更多Agent，建议给调度者加一个“Agent选择”的辅助工具，让它通过检索而不是靠记忆来选Agent，虽然复杂一些，但稳定很多。

3.2 状态机与循环控制参数

多代理系统的编排逻辑本质上是一个有限状态机。无论你的实现是用框架还是自己写，脑子里都要有一个清晰的状态流转图：初始状态、等待调度者决策状态、执行Agent运行中状态、等待工具结果状态、汇总输出状态、失败重试状态。

在状态机的实现上，我在代码里配置了几个关键参数，这些参数是从实际调试里一点一点试出来的，直接分享给大家：

• 单Agent最大重试次数：一般设为2次。超过2次重试还失败，大概率不是偶发错误，而是Agent配置或数据出了问题，再重试就是浪费资源。
• 调度者决策超时时长：45秒到60秒比较合理。大模型推理时间有时候会飘，给太短容易误判超时，给太长用户等待体验差。
• 工具调用最长等待时间：根据第三方API的响应时间定，网络良好时10到15秒足够，内网API还可以压缩到5秒。
• 整条流程的最大步数：建议限制在20步以内。如果超过20步还没出结果，说明编排逻辑可能进入了一个无意义的循环，此时应该终止并返回兜底文案。

3.3 记忆管理与上下文窗口分配

多代理系统的上下文管理比单Agent复杂得多，因为每一轮交互都可能涉及多个Agent的中间输出。如果不加控制，上下文会迅速膨胀。

我现在用的方法叫“分层摘要压缩”：每当调度者准备接收一个新的子Agent的结果时，先让结果进入一个压缩通道，由一个小号模型把较长内容压缩成要点摘要，只保留“与最终目标相关的关键信息”。这个做法可以把上下文减少到原来的三分之一左右，而且对决策质量几乎没有负面影响。

另外，长期记忆写入的时机也很重要。我踩过的一个坑是在每个Agent执行完就立刻把结果写入长期记忆，结果导致待查询记忆库里塞满了临时中间状态。经过重构，我们只在以下三种情况下写入长期记忆：

• 用户明确表达了长期偏好，比如“以后报价都用美元”。
• 一次完整的多Agent流程执行完毕，结果验证无误。
• 出现错误决策，系统需要记住这个错误以便下次避免。

除此之外的中间信息都只留在短期上下文里，流程结束就清除。

3.4 评估与反馈回路

多代理系统上线之后，最容易被忽视的是评估机制。因为系统由多个Agent组成，任何一个Agent的行为偏差都可能被下游放大。所以我把评估分成两层：单Agent评估和整体流程评估。

单Agent评估针对每个Agent的输出做校验，重点看格式是否正确、字段是否完整、是否出现幻觉式信息。整体流程评估则关注最终结果对用户问题的覆盖率、准确率、以及整个流程消耗的Token数和耗时。我建议每周跑一轮回归测试，用固定的测试用例集来对比本周和上周的效果差异。一旦某指标下降超过5%，立刻查看是哪一层的Agent出了问题。

这套评估体系的价值，在我们后来的一次模型升级中体现得特别明显——新模型在单Agent层指标全部正常，但整体流程的完成率下降了一大截。后来排查发现是新模型在调度者的工具选择环节出现了偏好偏移，经常漏选“折扣计算Agent”。如果不是有整体流程评估，这个问题可能要过很久才能在用户投诉中暴露出来。

4. 实操：从零搭建一个可运行的多代理系统

4.1 技术选型与工作环境

先说到底用什么来实现多代理系统。目前业界已经有开源的多代理编排框架，核心能力就是定义Agent、设置工具、编排流程、管理状态。如果你熟悉Python生态，直接基于这类框架做二次开发是最快的一条路。我自己更倾向在框架基础上加上自己设计的调度提示词和消息协议，而不是完全依赖框架自带的默认逻辑。

如果你所在的团队已经有成熟的AI应用服务，不想引入太多新依赖，也可以自己手写一个轻量调度层。做法不复杂：一个总控制器接收请求并调用大模型API完成任务分解，然后依次或并行发起对其他Agent的调用，每个Agent本质上也是一段独立的函数或微服务。手写方案的控制力更强，但需要自己处理重试、超时、状态存储，代码量大约多出一千行左右，看团队维护能力来决定。

我这里先以一个自定义的调度层为例，向大家展示最核心的代码结构，方便理清执行逻辑。

4.2 定义Agent配置与消息协议

第一步定义消息协议。我自己定义了一个简单的消息信封结构，同时在配置文件中声明每个Agent的基础信息：

# message.py from dataclasses import dataclass, field from typing import Any import uuid import time @dataclass class AgentMessage: msg_id: str = field(default_factory=lambda: uuid.uuid4().hex) sender: str = "" receiver: str = "" msg_type: str = "task" # task / result / error / status payload: dict[str, Any] = field(default_factory=dict) context: dict[str, Any] = field(default_factory=dict) timestamp: float = field(default_factory=time.time) def to_dict(self) -> dict[str, Any]: return { "msg_id": self.msg_id, "sender": self.sender, "receiver": self.receiver, "msg_type": self.msg_type, "payload": self.payload, "context": self.context, "timestamp": self.timestamp }

然后写一个简单的Agent配置文件，描述每个Agent的职责、可用工具和系统提示词模板。这里的提示词模板有一个设计要点：要明确告诉Agent它需要的输入字段和输出字段，以及遇到什么情况应该返回错误而不是乱猜。我在实际项目里发现，给Agent定义“不知道就明说”的行为约束，比让它硬答更能保护下游流程。

# agent_config.py AGENT_REGISTRY = { "intent_agent": { "name": "意图识别Agent", "description": "分析用户请求，提取关键参数，输出结构化的任务元信息", "tools": [], "prompt_template": "你是一个意图识别引擎。只输出JSON，包含intent字段和params字段。不要尝试回答问题。", }, "stock_agent": { "name": "库存查询Agent", "description": "查询商品库存，返回产品ID、可用数量、预计补货日期", "tools": ["query_stock_api"], "prompt_template": "你是库存查询助手。根据给定的产品ID列表查询库存。如果数据不存在，status设为error。", }, "quote_agent": { "name": "报价计算Agent", "description": "基于库存和用户等级计算报价，返回最终价格和折扣说明", "tools": ["calc_discount_api"], "prompt_template": "你是报价助手。根据库存信息和用户等级计算报价。最终输出JSON，包含final_price和discount_detail。", }, }

4.3 调度层实现：编排与状态流转

接下来是调度层。调度层要维护当前的状态，决定调用哪个Agent接收哪个任务。下面这段代码是我在实际项目中简化后的骨干，重点不是每一行的语法，而是它的状态流转思路：

# scheduler.py from message import AgentMessage from agent_config import AGENT_REGISTRY class MultiAgentScheduler: def __init__(self, llm_call_fn): self.llm_call_fn = llm_call_fn # 统一的LLM调用入口 self.max_steps = 20 self.max_retries = 2 def run(self, user_request: str) -> dict: current_step = 0 state = {"status": "running", "final_answer": "", "context": {}} # 第一步：交给调度者做任务分解 plan = self._call_planner(user_request) current_step += 1 while current_step <= self.max_steps: if plan.get("next_action") == "finished": state["status"] = "finished" break agent_name = plan.get("agent") if agent_name not in AGENT_REGISTRY: state["status"] = "error" break # 执行Agent并处理重试 for attempt in range(self.max_retries + 1): result = self._execute_agent(agent_name, plan.get("payload", {}), state["context"]) if result["status"] == "success": state["context"].setdefault("intermediate", []).append(result["data"]) break else: if attempt >= self.max_retries: state["status"] = "error" return state # 把Agent执行结果交回调度者，规划下一步 plan = self._call_planner(f"用户请求：{user_request}\n当前状态：{state['context']}") if not plan: state["status"] = "error" break current_step += 1 if state["status"] != "finished": state["status"] = "stopped" return state def _call_planner(self, prompt: str) -> dict: # 调用大模型，解析JSON决策 raw = self.llm_call_fn(prompt, system="你是一个任务编排器...") return parse_json_safely(raw) def _execute_agent(self, agent_name: str, payload: dict, context: dict) -> dict: # 拼装Agent提示词，调用LLM，解析结构化输出 agent_conf = AGENT_REGISTRY[agent_name] prompt = build_agent_prompt(agent_conf, payload, context) raw = self.llm_call_fn(prompt, system=agent_conf["prompt_template"]) return parse_agent_result(raw)

这段代码最值得关注的地方是循环内的两步操作：先启动Agent执行，然后把最终状态回传给调度者来做下一步决策。这种模式保证了整个过程是“每一步都基于最新状况”的动态编排，而不是一条固定的静态流水线。

4.4 运行效果与调优记录

我当初把上面这套结构运行起来后，第一次跑通时还有很多细节不尽如人意。最主要的两个问题，一是Agent返回的JSON解析失败频率很高，二是调度者偶尔会把本应交给库存Agent的任务发给意图识别Agent。

针对第一个问题，我加了强制JSON输出的提示词模板，同时在解析失败时额外调用一次修复模型，专门负责把乱七八糟的返回文本整理成合法JSON。针对第二个问题，我给每个Agent的注册信息里加了“输入样例”和“不适合处理的请求示例”，调度者参考正反例做选择，分错的问题明显减少。

调整之后我又跑了一个完整的模拟任务：“用户询问某商品今天的售价并催促发货”。系统经过调度者、库存Agent、报价Agent、发货状态Agent四轮协作，最终输出的结果格式正确、信息完整，整体等待时间从单Agent版本的四十五秒下降到三十秒左右。重要的是，这套系统后续加新业务线时，只需要新增Agent和对应工具，主流程代码一行没改。

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

5.1 Agent陷入死循环

多代理系统最常见的问题就是流程卡在循环里出不来。具体表现为：调度者反复把任务交给同一个Agent，或者两个Agent来回传递相同的信息，日志里同一段上下文出现很多次。

我排查这类问题的第一招是查看状态流转日志。给每个Agent调用都打上带消息ID的日志，沿着ID追踪，能很快发现是哪一步开始重复的。如果确认是调度者决策问题，优先在调度提示词里加一个限定：“只有当前请求需要新的信息时，才调用下一个Agent；如果已有信息足以作答，直接进入输出阶段”。如果循环发生在固定路径上，比如A做完给B，B做完又触发A，那就直接在代码层加去重，记录最近N条消息的消息ID，如果新消息与最近某条完全一致，就阻断执行。

5.2 上下文超限与Token浪费

上下文窗口超限在多代理系统里几乎是必然遇到的。每个Agent执行结果都拼进上下文，几轮下来就超了。我建议用前面说过的分层摘要压缩，把中间结果全部做压缩摘要。维护一份“当前最新状态摘要”，而不是保留所有原始输出。

另外，可以给每个工具调用的返回结果加一个截断参数。比如库存查询接口本来返回几百条记录，我们规定只返回前50条加一个总数标记。这样既满足Agent做决策的信息需求，又不会把上下文撑爆。这个处理让小模型Agent的推理成本下降了大概一半，输出速度却快了不少。

5.3 Agent间的信息传递丢失

不少新手实现多代理时，发现下游Agent拿到上游的输出后，经常答非所问。原因多半是消息信封里的payload字段设计得不好，或者下游Agent的提示词没有说明应该从哪拿关键字段。解决办法是给每个Agent的输入做显式映射：在提示词模板里明确写出“你将收到一个JSON对象，请使用其中的product_id和sales_channel字段作为输入，忽略其他字段”。实测下来，加上这句话之后，信息传递错误率能降低到原来的四分之一以下。

5.4 成本失控

多Agent系统的Token消耗有时是单Agent方案的三到五倍，因为增加了调度者的多轮调用。我的成本控制经验是：

• 调度者使用参数规模较小的模型，只做决策不做事。
• Agent执行阶段用任务复杂度匹配模型大小，简单的分类任务用中等模型就够，不需要每次都上旗舰模型。
• 开启缓存机制，同一用户在同一会话内的重复请求，结果直接复用。
• 对流程最大步数做严格限制，从源头上防止无意义调用。

我们上线优化以后，单次会话的平均成本降到了原来的40%左右，而任务完成率没有下降，效果很明显。

6. 一个容易被忽略的工程化要点

多代理系统上线容易，维护难。多数团队把目光放在Agent的数量和工具数量上，却忽略了可观测性设计。我在实际维护中的体会是，一个没有日志追踪和指标看板的多代理系统，排查问题时就像蒙着眼睛找一颗掉进沙漠里的钉子，寸步难行。

所以建议在第一天就搭建一套日志链路：整个流程有一个全局流程ID，每个Agent调用、每次工具调用、每次LLM响应都挂在这个ID下。看到线上用户反馈异常，先按流程ID把整条链路捞出来，问题在哪个环节基本一目了然。这套机制救过我很多次，没有它，哪怕是三五个Agent的小系统，排查一次问题也能耗费一整天。

工具监控也不能缺。不同Agent共用同一个第三方API时，如果API出现抖动，单看Agent日志很容易误判为Agent本身的问题。我现在的做法是对每个工具都单独记录调用耗时和错误码，单独画一张耗时趋势图。如果某一段时间工具调用耗时长且错误多，那就是基础设施问题，先修接口再调Agent，排查顺序对了，效率才会高。

多代理系统的价值不在于概念有多新，而在于怎样把复杂度收拢到可控的范围内。个人经验是先从两三个专职Agent起步，把消息协议、状态流转、日志追踪跑顺，再逐步增加Agent数量和编排模式。等到框架稳定了，你手上这多代理架构就会成为真正能落地的应用新引擎，而不再是试错模型。