企业官网建设流程全解析

微信机器人处理简单业务一个智能体够用——理解意图、查个信息、回个结果。处理复杂业务就吃力——用户说"帮我看下这个订单要不要退款，如果要退帮我发起申请"，这涉及判断、执行、校验三个不同能力。单智能体全干容易每件都干不好，多智能体协作是按能力分工，由编排器统一调度，协作完成一个复杂请求。

一、职责划分——按业务能力而非按流程步骤

职责划分常见误区是按流程步骤拆——一个智能体接收消息、一个理解意图、一个执行。这种拆法把流水线切成几段，本质还是单智能体加了层中转。正确的拆法是按业务能力——咨询智能体（回答政策/产品问题）、执行智能体（发起退款/改地址等动作）、校验智能体（检查动作合规性）。

按能力拆的工程价值是职责正交——咨询不关心执行、执行不关心咨询、校验不关心前两者怎么干。正交意味着可以独立迭代——咨询换模型不影响执行，校验加规则不影响咨询。按流程步骤拆做不到正交，接收消息的智能体改了下游全得改。消息分发和智能体调度的接口能力在 Eyun 开发文档 中有对应支撑。

二、编排器调度——中心化分配而非智能体间直接通信

多智能体协作需要编排器做中心化调度。用户请求进来，编排器判断调用哪些智能体、什么顺序、结果怎么合并。智能体之间不直接通信——咨询智能体把结果返回给编排器，编排器决定下一步。中心化调度的价值是调度逻辑集中可维护，点对点通信会让协作关系网状交织，改一个影响一片。

编排器调度的核心是任务分配和结果归约。任务分配判断当前请求需要哪些智能体——咨询类调咨询智能体、动作类调执行智能体。结果归约做合并、冲突检测、仲裁——执行说"可以退"，校验说"超期不可退"，编排器仲裁校验优先级更高，结论是不可退。消息收发和编排调度的接口在 Eyun 开发文档 中有对应能力。

三、协作握手协议——智能体间的标准化契约

多智能体协作要定义握手协议——智能体之间怎么传递上下文、怎么确认接收、怎么报告异常。握手协议不是通信协议（那是传输层），是业务契约——输入什么格式、输出什么格式、异常怎么标记。执行智能体收到的输入必须包含场景ID、动作参数、上下文摘要、来源标识，输出包含执行结果、置信度、异常信息、需要后续处理的事项。

握手协议的价值是协作可组合。今天咨询+执行协作，明天加一个校验智能体，只要遵循协议就能接入，不需要改已有智能体。没有协议，每加一个智能体都要改其他智能体的适配代码，智能体越多改动越大。握手协议让智能体成为可插拔的标准化组件。

智能体职责与编排对照

编排器调度与结果归约实现

class Orchestrator: AGENTS = { "consult": ConsultAgent(), # 咨询智能体 "execute": ExecuteAgent(), # 执行智能体 "verify": VerifyAgent(), # 校验智能体 } PRIORITY = {"verify": 3, "execute": 2, "consult": 1} def handle(self, request): agents = self.route(request) # 任务分配 results = {} for name in agents: results[name] = self.AGENTS[name].run(request, results) return self.reduce(results) # 结果归约 def route(self, request): needed = set() if request.has_question: needed.add("consult") if request.has_action: needed.add("execute") needed.add("verify") # 有动作必校验 return needed def reduce(self, results): # 冲突仲裁：校验优先级高于执行 if "verify" in results and results["verify"].blocked: return results["verify"] return results.get("execute", results.get("consult"))

落地建议

多智能体从两个协作起步——咨询+执行是最小协作单元，跑通了再加校验。一上来就三个以上智能体协作，调度复杂度陡增，调试困难。编排器中心化调度别省——点对点通信看似灵活，后续扩展成本极高。握手协议先定再写代码，没有标准化契约每加一个智能体都要改适配。微信侧的消息分发、智能体调度和结果回传由Eyun这类个人微信API平台 提供，编排器和智能体逻辑在自建服务实现，接口字段以平台开发文档为准。