企业官网建设流程全解析

AI代理替人跑腿这件事，最近一年从"玩具"变成了"工程"。我最早接触多智能体协同是在一个内部知识库问答项目里，当时只是想让几个Agent分工查资料、写摘要、做校验，结果一上手就发现：单个Agent跑得挺欢，一旦让它们互相通信、共享上下文、按角色协作，各种问题全冒出来了——消息乱序、上下文爆炸、某个Agent卡死拖垮整条链路、输出内容踩合规红线。后来我把这套东西逐步抽象成一套"多人多AI协同"的架构，核心思路是：人不再直接操作每个AI，而是由一个代理层代为交互，人只在关键节点做决策和审核。这套架构我反复迭代了几轮，踩过的坑足够写一篇长文，今天就把设计思路、关键取舍和实操细节完整摊开讲。

这篇文章适合两类人看：一类是正在做多智能体系统、想让多个AI协同干活的工程师；另一类是对"AI代理代为交互"这个概念感兴趣、想知道背后到底怎么落地的人。我会从架构分层讲到消息总线、从角色编排讲到合规拦截，尽量把每个"为什么这么设计"讲透，而不是只丢一堆名词。

1. 先搞清楚"代理代为交互"到底代理了什么

很多人一听到"AI代理代为交互"，第一反应是"不就是让AI帮我点按钮吗"。这个理解太窄了。在我这套架构里，代理层代理的是三件事：交互动作、上下文维护、决策预筛。这三件事的难度是递增的，很多人只做了第一件就以为大功告成，结果系统一上规模就崩。

1.1 交互动作代理：最表层但最容易做歪

交互动作代理，指的是人不再直接对每个AI发指令，而是把意图交给代理层，由代理层拆解、分发、汇总。举个具体场景：用户说"帮我调研一下多智能体协同在电网调度里的应用，出一份带引用的报告"。在传统模式下，用户得自己开好几个对话窗口，分别让AI查资料、写大纲、润色。在代理模式下，用户只说一句话，代理层负责把任务拆成"检索—筛选—撰写—校验—引用核对"几个子任务，分给不同的Agent。

这里第一个坑就来了：任务拆解的粒度。拆得太粗，单个Agent负担过重，容易跑偏；拆得太细，Agent之间通信开销爆炸，一个简单任务要来回几十条消息。我实测下来的经验是，单个子任务的预期输出控制在300到800字之间比较合适，超过1000字就该考虑再拆，低于200字就没必要单独开一个Agent，合并处理更划算。

第二个坑是意图歧义。用户说"调研一下"，到底是只要事实罗列，还是要带分析观点？代理层如果不在分发前做一次意图澄清，后面所有Agent都会基于各自的猜测干活，最后汇总出来的东西四不像。我的做法是在代理层加一个轻量的"意图确认"环节，对于模糊指令，先返回一个任务拆解预览让用户确认，确认后再执行。这一步看似多了一次交互，但省下的返工成本远超这点开销。

1.2 上下文维护代理：真正决定系统上限的部分

如果说交互动作代理是"手脚"，那上下文维护代理就是"记忆和判断"。多智能体系统里最要命的问题不是算力，而是上下文的一致性。Agent A基于版本1的资料写了初稿，Agent B基于版本2的资料做了修改，Agent C又基于版本1做了校验——最后三份东西对不上，你还得人工去比对。

我的解法是引入一个共享上下文仓库，所有Agent的读写都走这个仓库，而不是各自维护私有上下文。仓库里每条信息带版本号和来源标记，Agent在读取时能知道"这条信息是谁在什么时候写的、基于什么依据"。写入时走乐观锁，版本冲突就重试。这套机制听起来像数据库事务，本质上就是——多智能体协同的上下文管理，和分布式系统的数据一致性是同一类问题。

提示：共享上下文仓库不要存原始大文本，存摘要加指针。原始资料放对象存储，仓库里只放"谁引用了哪份资料的哪一段"。否则上下文仓库会迅速膨胀到无法维护。

1.3 决策预筛代理：把人的注意力用在刀刃上

人在这套系统里的角色不是"操作员"，而是"决策者"。但人的注意力是稀缺资源，如果每个Agent的每个中间结果都要人确认，那还不如自己干。所以代理层要做的第三件事是决策预筛：把大量低风险的、可自动化的决策直接放行，只把高风险的、模糊的、涉及合规红线的决策推给人。

预筛的规则怎么定？我一般分三档：自动放行（格式转换、摘要生成、事实检索）、抽样复核（内容改写、观点归纳，按比例抽检）、强制人工确认（涉及对外发布、涉及敏感表述、涉及金额或承诺）。这个分档不是拍脑袋定的，而是根据历史出错率和出错后果的严重程度来调的。跑一段时间后，把出错率高的环节往上升一档，把长期零出错的环节往下降一档，系统会越跑越顺。

2. 消息总线：多智能体协同的血管怎么铺

多智能体系统里，Agent之间怎么通信，直接决定了系统的吞吐、延迟和可维护性。我见过太多项目一上来就搞"全连接"——每个Agent都能直接调每个Agent，结果就是一张蜘蛛网，加一个Agent要改一堆代码，排查问题像大海捞针。

2.1 为什么我最终选了"总线+主题订阅"而不是点对点

点对点通信的优点是简单直接，A调B，一个函数调用就完事。但它的致命伤是耦合。当你有5个Agent时，点对点还能忍；到10个以上，调用关系就变成了一团乱麻。更麻烦的是，点对点很难做广播和聚合——你想让所有Agent都收到"资料更新了"这个事件，点对点就得挨个通知。

总线模式的核心是发布订阅：Agent不直接互相调用，而是往总线上发消息，谁关心谁订阅。这样一来，新增一个Agent只需要让它订阅相关主题，完全不用改其他Agent的代码。我用的主题划分大致是这样的：

这张表是我实际项目里用的，你可以根据自己的场景调整，但核心原则不变：主题按"事件语义"划分，不按"Agent名称"划分。按Agent名划分主题（比如agentA.output）会导致主题数量随Agent数量线性增长，很快就失控。

2.2 消息的幂等与顺序：两个必须提前想清楚的问题

总线模式带来两个新问题：消息可能重复投递，消息可能乱序到达。这两个问题在点对点模式下不明显，但在总线模式下是常态。

幂等怎么保证？我的做法是每条消息带一个全局唯一的消息ID，接收方维护一个"已处理消息ID"的滑动窗口，重复ID直接丢弃。这个窗口不用太大，保留最近1000条就够，因为重复投递通常发生在短时间内。

顺序怎么保证？严格全局有序代价太高，也没必要。我的做法是按任务ID保证局部有序：同一个任务下的消息带递增序号，接收方按序号处理，序号跳跃就等待或请求重发。不同任务之间的消息可以并行，互不影响。这样既保证了正确性，又保留了并发能力。

注意：不要试图用"时间戳"来排序消息。分布式环境下各节点的时钟不可能完全同步，时间戳排序在跨节点场景下会出错。用逻辑序号，别用物理时间。

2.3 背压与熔断：别让一个慢Agent拖垮全局

多智能体系统里最隐蔽的故障是慢节点拖垮全局。某个Agent因为模型响应慢或者卡在某个循环里，它订阅的主题消息越积越多，最终把总线堵死，所有Agent都受影响。

我在总线上加了两道防线。第一道是背压：每个Agent的待处理队列有上限，超过上限就拒绝新消息并返回"忙"信号，发布方收到"忙"信号后可以选择重试或降级。第二道是熔断：如果某个Agent连续多次超时或报错，总线暂时把它从订阅列表里摘掉，等它恢复后再加回来。这两道防线加上之后，系统的稳定性提升非常明显——以前一个Agent卡死会导致整个任务链停摆，现在最多是那个子任务失败，其他部分照常推进。

3. 角色编排：让多个AI各司其职而不是各说各话

多智能体系统里，Agent不是越多越好。我见过一个项目开了十几个Agent，结果大部分时间在互相等待和重复劳动。角色编排的核心是：用最少的Agent覆盖任务所需的能力，并且让每个Agent的职责边界清晰。

3.1 我常用的四类角色及其职责边界

经过几轮迭代，我稳定下来的角色划分是四类：检索者、撰写者、校验者、汇总者。这四类不是随便定的，而是对应了"信息获取—内容生产—质量把关—结果整合"这条完整链路。

检索者负责从各种来源拉取原始资料，它的输出是"带来源标记的素材片段"，不做任何加工和判断。撰写者负责把素材组织成连贯的内容，它的输入是素材片段，输出是草稿。校验者负责检查草稿的事实准确性、逻辑一致性和合规性，它的输出是"问题清单"而不是"修改后的稿子"——这一点很关键，校验者如果直接改稿，就和撰写者的职责重叠了，出了问题分不清是谁的责任。汇总者负责把各方的输出整合成最终结果，并处理格式和引用。

这四类角色的边界必须写死在系统提示里，不能让Agent"自由发挥"。我踩过的坑是：早期没限制撰写者的行为，结果它自己去检索了新资料，和检索者的输出冲突，最后汇总时两份资料对不上。后来我在撰写者的系统提示里明确写了"你只能使用输入中提供的素材，不得自行检索或引入外部信息"，问题才解决。

3.2 角色之间的"交接协议"比角色本身更重要

角色定好了，接下来是交接。Agent A把结果交给Agent B，这个"交"不是简单地把文本丢过去，而是要带上一组元信息：任务ID、来源标记、置信度、待确认事项。没有这组元信息，接收方就不知道该怎么处理这份输入。

我定义的交接协议大致包含这几个字段：

• task_id：任务唯一标识，用于串联整条链路
• source_refs：这份结果引用了哪些原始资料，带定位信息
• confidence：产出方对这份结果的置信度（高/中/低）
• open_questions：产出方不确定、需要下游注意的点
• compliance_status：合规检查状态（通过/待查/拦截）

这套协议看起来繁琐，但它解决了一个大问题：下游Agent能基于上游的置信度和待确认事项做差异化处理。比如校验者看到置信度"低"的结果，就会重点核查；看到"高"的结果，就做常规抽检。这比无差别处理效率高得多。

3.3 什么时候该加Agent，什么时候该合并

判断标准很简单：如果两个角色的输入输出格式不同、或者对失败的容忍度不同，就该分开；如果只是同一类工作的不同实例，就该合并。

举个例子，"检索学术资料"和"检索新闻资料"看起来是两件事，但它们的输入输出格式一样（都是查询→素材片段），失败容忍度也一样（检索不到就换关键词重试），所以应该合并成一个检索者Agent，通过参数区分检索源，而不是开两个Agent。反过来，"撰写"和"校验"虽然都处理文本，但撰写要创造性、校验要批判性，两者的提示词和失败模式完全不同，就必须分开。

我见过最离谱的设计是给每个数据源开一个Agent，结果十个数据源十个Agent，光调度逻辑就写了几百行。后来合并成一个检索者加数据源配置表，代码量降到原来的五分之一，效果反而更好。

4. 内容合规：多智能体系统里最不能省的一环

多智能体系统有个特性：Agent之间会互相放大内容。一个Agent产出的轻微偏差，经过几个Agent的转述和加工，可能被放大成严重问题。所以合规检查不能只在最后做一次，而要嵌入到链路的关键节点。

4.1 合规检查应该放在哪几个位置

我的做法是在三个位置设检查点：输入检查、中间检查、输出检查。

输入检查针对用户指令，拦截明显不当的请求。中间检查针对Agent之间的交接内容，重点查"是否引入了未经核实的信息"和"是否出现了不该出现的表述"。输出检查针对最终结果，做全面的合规扫描。

这三个检查点的严格程度是递增的：输入检查可以宽松一些，避免误伤正常请求；中间检查中等严格，主要防放大；输出检查最严格，因为这是最终对外的东西。

4.2 规则引擎和模型判断怎么配合

纯规则引擎的问题是覆盖不全，纯模型判断的问题是可能漏判和误判。我的做法是规则引擎做第一道粗筛，模型判断做第二道细筛。

规则引擎负责拦截明确的红线词和模式，这部分用正则和关键词表就能搞定，速度快、零漏判（对已知模式而言）。模型判断负责处理规则覆盖不到的语义层面问题，比如"这段话虽然没有敏感词，但整体倾向有问题"。两道筛子串行，规则引擎拦下的直接拦截，规则引擎放行的再过模型判断。

提示：规则引擎的词表要定期更新，但不能频繁大改。频繁大改会导致行为不稳定，今天能过的明天过不了，用户会困惑。我的做法是词表分"稳定层"和"实验层"，实验层的新规则先跑一段时间观察误伤率，稳定后再并入稳定层。

4.3 被拦截之后怎么办：不能只是简单报错

合规拦截之后，如果只是给用户返回一个"内容不合规"，用户体验很差，而且用户不知道该怎么改。我的做法是拦截时给出可操作的反馈：指出哪一部分触发了拦截、触发的是哪类规则、建议怎么修改。

比如用户让Agent写一段营销文案，文案里出现了夸大表述，拦截时不应该只说"不合规"，而应该说"第三段的'绝对领先'属于绝对化表述，建议改为'在某某维度表现突出'"。这样用户知道问题在哪，也知道怎么改，体验就好很多。

对于中间检查拦截的情况，处理方式又不一样：不是返回给用户，而是回退给上游Agent重新生成。比如撰写者产出的草稿在中间检查时被拦截，系统会自动把拦截原因附在提示里，让撰写者重新生成一版。重试次数设上限（我一般设2次），超过上限就升级到人工处理。

5. 本地模型与代理层的配合：什么时候该用本地，什么时候该用云端

最近"AI代理助手加本地模型"这个方向很热，我实际跑过几套组合，说说真实感受。本地模型的价值主要在数据不出域、响应延迟低、成本可控这三点，但它的能力上限确实比云端大模型低一截。所以关键不是"用本地还是用云端"，而是怎么分工。

5.1 我实际用的分工策略

我的分工原则是：高频、低复杂度、涉及敏感数据的任务走本地；低频、高复杂度、需要强推理的任务走云端。

具体到角色上：检索者的查询改写和素材初筛可以走本地，因为这部分任务模式固定、对创造力要求低；撰写者的初稿生成走云端，因为需要较强的语言组织能力；校验者的事实核查走云端，因为需要较强的推理和判断；汇总者的格式整理走本地，因为这部分基本是规则性工作。

这套分工跑下来，本地模型承担了大约60%的调用量，云端只承担40%，成本降了一半多，而最终质量几乎没有下降。关键是本地和云端之间的接口要统一，Agent不需要知道自己在调本地还是云端，代理层根据任务类型路由就行。

5.2 本地模型的上下文窗口限制怎么绕

本地模型普遍上下文窗口偏小，这是硬约束。我的绕法是分块处理加摘要传递：长文档先分块，每块单独处理，处理结果汇总成摘要，摘要再传给下游。这样每个环节处理的上下文都不超过窗口限制。

但分块会带来一个新问题：块与块之间的信息丢失。比如一份文档的前半部分定义了某个术语，后半部分用了这个术语，分块处理后后半部分的Agent不知道这个术语的含义。我的解法是在分块时保留一个"全局上下文头"，把文档的关键定义和背景信息提取出来，附在每个块的前面。这个头不用太长，几百字就够，但能显著减少块间信息丢失。

5.3 本地模型的稳定性问题

本地模型还有一个容易被忽视的问题：长时间运行后的性能衰减。我遇到过本地模型跑几个小时后响应变慢、输出质量下降的情况，重启后又恢复正常。后来排查发现是显存碎片和缓存累积导致的。

我的应对是定期重启加健康检查：本地模型服务每隔一段时间（我设的是4小时）自动重启一次，重启前把待处理任务排空。同时加一个健康检查接口，代理层在路由前先探一下本地服务是否健康，不健康就临时切到云端。这套机制加上之后，因为本地模型不稳定导致的任务失败率降到了可以忽略的水平。

6. 实测中那些文档不会写的坑

前面讲的都是架构层面的东西，这一节讲几个具体到操作层面的坑，都是我在实际跑系统时踩出来的，常规文档里基本不会提。

6.1 Agent的"过度自信"问题

大模型有个通病：不知道自己不知道。检索者没检索到相关资料，它不会说"我没找到"，而是会基于训练数据里的记忆编一段看起来很像那么回事的内容。这个问题在多智能体系统里会被放大，因为下游Agent倾向于信任上游的输出。

我的解法是强制检索者标注来源：每条素材必须带来源引用，没有来源的素材一律标记为"未经核实"，下游Agent看到这个标记就必须做额外核查。同时在检索者的提示里明确写"如果检索不到相关资料，必须明确返回'未找到'，不得基于记忆编造"。这条规则加上之后，编造问题减少了八成以上。

6.2 上下文仓库的"脏读"问题

共享上下文仓库在并发写入时会出现脏读：Agent A正在写一条记录，Agent B同时读到了写了一半的内容。这个问题在低并发时不明显，一旦Agent数量上去就会频繁出现。

我的解法是写入原子化加版本号：每条记录的写入是原子的，要么全写进去要么完全不写；读取时带版本号，如果读到的版本和预期不符就重读。这套机制和数据库的MVCC（多版本并发控制）是一个思路，实现起来不复杂，但能彻底解决脏读。

6.3 任务链路的"断头"问题

多智能体系统跑长任务时，偶尔会出现某个环节的Agent没有响应，导致整条链路卡住。如果没做超时处理，这个任务就会永远挂在那里。

我的解法是每个环节设超时加兜底：每个Agent处理任务有超时限制，超时后总线把任务标记为"失败"，并触发兜底逻辑。兜底逻辑分两种：可重试的（比如检索超时）自动重试；不可重试的（比如校验发现严重问题）升级到人工。同时整条链路有一个总超时，超过总超时就整体终止并通知用户，避免用户无限等待。

6.4 日志和可观测性：出事之后能查才是关键

多智能体系统出问题时，最难的不是修复，而是定位。一条任务链路经过五六个Agent，每个Agent又调了若干次模型，没有完善的日志根本查不出问题出在哪。

我的做法是全链路追踪：每个任务从创建到结束，所有环节的输入输出、耗时、状态都记录在案，用task_id串联。日志分两级：一级是摘要日志，记录每个环节的关键信息，用于快速定位；二级是详细日志，记录完整的输入输出，用于深入排查。摘要日志常开，详细日志按需开启（比如某个任务失败时自动开启该任务的详细日志）。

这套日志体系加上之后，排查问题的平均时间从小时级降到了分钟级。我强烈建议在系统设计初期就把日志和追踪考虑进去，后期补的代价要大得多。

7. 从单机Demo到生产系统，中间隔着什么

最后聊聊规模化的问题。很多多智能体项目在Demo阶段跑得很好，一上生产就各种问题。我总结下来，中间主要隔着三样东西：并发控制、故障恢复、成本控制。

并发控制方面，Demo阶段通常只有一两个任务在跑，生产环境可能几十上百个任务并发。这时候上下文仓库的锁竞争、总线的消息堆积、模型服务的限流都会成为瓶颈。我的做法是分层限流：总线层面限制总消息速率，Agent层面限制单Agent并发数，模型服务层面限制调用速率。三层限流配合，系统在高并发下也能保持稳定。

故障恢复方面，Demo阶段挂了重启就行，生产环境不能随便重启。我的做法是状态外置：Agent本身无状态，所有状态存在上下文仓库和任务队列里。Agent挂了直接重启，从队列里重新拉任务继续跑。这样单点故障不会导致任务丢失。

成本控制方面，多智能体系统的模型调用量是单Agent的好几倍，不加控制很容易超预算。我的做法是按任务设预算上限：每个任务预估一个模型调用次数上限，超过上限就降级（比如从云端切到本地）或终止。同时监控各Agent的调用量，异常增长的及时排查。

这套东西跑下来，我的体会是：多智能体协同系统的难点从来不在"让AI干活"，而在"让AI可靠地、可控地、可负担地干活"。架构设计的大部分精力应该花在后三个词上，而不是第一个。我见过太多项目把精力全花在提示词调优上，结果系统一上规模就崩，就是因为忽略了可靠性、可控性和成本这三个维度。

如果你正在做类似的东西，我的建议是：先把单Agent的边界和职责定清楚，再考虑多Agent协同；先把消息总线和上下文仓库搭起来，再往里填Agent；先把合规检查和日志追踪做好，再追求功能丰富度。顺序反了，后面返工的代价会很大。