微信机器人处理简单业务一个智能体够用——理解意图、查个信息、回个结果。处理复杂业务就吃力——用户说帮我看下这个订单要不要退款如果要退帮我发起申请这涉及判断、执行、校验三个不同能力。单智能体全干容易每件都干不好多智能体协作是按能力分工由编排器统一调度协作完成一个复杂请求。一、职责划分——按业务能力而非按流程步骤职责划分常见误区是按流程步骤拆——一个智能体接收消息、一个理解意图、一个执行。这种拆法把流水线切成几段本质还是单智能体加了层中转。正确的拆法是按业务能力——咨询智能体回答政策/产品问题、执行智能体发起退款/改地址等动作、校验智能体检查动作合规性。按能力拆的工程价值是职责正交——咨询不关心执行、执行不关心咨询、校验不关心前两者怎么干。正交意味着可以独立迭代——咨询换模型不影响执行校验加规则不影响咨询。按流程步骤拆做不到正交接收消息的智能体改了下游全得改。消息分发和智能体调度的接口能力在 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平台 提供编排器和智能体逻辑在自建服务实现接口字段以平台开发文档为准。