多 Agent 如何通过会话事件协作
多个 Agent 共同完成任务时，最直接的做法是把所有角色、消息和工具调用都塞进同一个上下文。但任务一旦变长，不同角色的材料、历史和执行状态会相互干扰，也很难判断某条消息究竟应该由哪个 Agent 处理。
xAgent 采用独立会话加会话消息的方式组织协作。每个 Agent 会话保留自己的上下文、任务状态和工作区范围；需要交换信息或推动另一个会话继续工作时，再发送目标明确的消息。本文保留“会话事件”的概念名称；当前实现通过 MessageEnvelope 预处理后交给目标 SessionEngine。
以下消息种类、接收边界与 WorkGroup 说明按 2026-10-01 主分支 43d2698 核对。旧文档中的事件模式或自动回传描述不能直接当作当前工具参数；部署实例的实际能力仍取决于版本。
为什么使用独立会话
独立会话让不同 Agent 可以分别维护自己的任务目标、角色说明、模型上下文、Tool、Skill、计划、进度、工作区和正式产物。这样可以避免研究、写作、数据处理和外部发送等不同工作全部混在一个上下文中，也允许某个会话等待审批或外部条件时，其他会话继续运行。
会话、工作编排与远端 A2A
多 Agent 协作已经可以使用，但应先区分三个层次：
| 层次 | 管理什么 | 使用时检查什么 |
|---|---|---|
| 本地会话协作 | 同一用户的独立会话与定向消息 | 准确的目标会话、任务材料、回复和产物 |
| 工作编排（WorkGroup） | 管理会话、智能体与通信关系目录、草稿和发布版本 | 当前使用的配置版本与通信关系 |
| 远端 A2A | 外部 Agent 连接、远端任务身份、状态与结果回投 | 连接认证、原远端任务状态及本地结果接收 |
WorkGroup 是已经实现的编排配置能力，不是尚未提供的“未来 Team”占位名称。它不拥有独立的业务运行状态，实际工作由各会话执行；发布一份配置也不等于任务已经运行或完成。远端 A2A 则有单独的连接和任务生命周期，见远端 Agent 协作。
本地会话的同用户边界仍然适用。不能把工作编排或远端连接理解成跨用户共享本地会话，外部权限也不会因加入协作而扩大。
主 Agent 与子 Agent 的分工
| 会话类型 | 主要职责 |
|---|---|
| 主 Agent 会话 | 直接承接用户目标，决定是否拆分任务、创建或激活子会话，并保持用户的主要交互入口。 |
| 子 Agent 会话 | 围绕明确目标独立执行一段工作，维护自己的上下文、计划、工具和产物。 |
子 Agent 不是主会话中的一段隐藏思考，而是一个真正独立的 Agent 会话。用户可以进入子会话查看过程，也可以继续补充要求或优化结果。
什么是会话事件
会话事件是一条发送给明确目标会话的轻量消息，可以包含事件来源、目标会话、任务或状态说明、期望动作，以及工作区文件或外部资源引用。
事件不会把发送方的全部历史复制到目标会话。发送方只传递当前协作真正需要的信息，目标会话继续使用自己的上下文处理。
通知与协作事件的区别
通知事件
通知事件适合报告进度、完成状态、异常提醒、产物位置或需要用户关注的事实。
必须区分“仅展示通知”与“需要 Agent 处理的通知”。使用 context_scope=notify 的仅展示输入写入 UI 历史，不触发新的执行；当前 A2A 结果则可以使用 message_kind=notification 配合 context_scope=full 进入处理链。因此，不能仅凭“通知”这个名称判断是否会唤醒 Agent。
仅展示通知适合“让人知道”；要求另一个 Agent 继续工作时，应使用实际进入其执行队列的消息。
协作事件
协作事件适合让目标 Agent 接手或继续处理工作，例如主 Agent 向已有子 Agent 派发任务、把后续阶段移交给另一个会话，或者让目标会话根据新材料继续分析。
协作事件会进入目标会话的运行队列，转换为该会话的新输入，并激活后续处理。目标 Agent 使用自己的上下文、工具和工作区边界完成任务。
当前 session_send 统一以 full 上下文范围提交消息。forward 只表示不要求结果返回，并不等于 UI-only 或不激活执行。消息语义与上下文消费范围是两个不同维度。
为什么仅展示通知不触发执行
多 Agent 系统会产生大量“开始处理”“进度更新”“文件已生成”等状态消息。如果全部进入模型上下文，会挤占任务材料、增加无意义调用，并可能因为普通状态更新错误触发新一轮执行。
这是仅展示通知的设计目的，不是对所有 notification 消息的统一规则。当前会话发送和 A2A 结果等需要处理的输入，应按其实际上下文范围与运行队列行为判断。不要为降低通知噪声而把必须处理的结果误写成仅展示输入。
会话事件总线如何工作
当前入口与持久化接收需要分开理解：
- 发送方确定目标会话、消息正文和消息种类。
- Brain 校验目标归属并处理可信来源与资源引用。
- 普通
session_send返回accepted=true，表示 Brain 接受了异步投递工作。 - 后续由 SessionEngine 接收；
full/sliced输入进入会话队列并保存恢复快照，notify输入写入历史。 - 已可靠接收的运行输入按目标状态立即处理或排队；运行中、等待审批和恢复未就绪会影响处理时机。
- 业务结果仍由实际执行、产物和后续回复确认。
旧说明中的“持久队列”对应当前 SessionEngine 的持久化接收与恢复事实，不代表普通发送的 accepted 已经是目标 Engine 落盘回执。异步投递失败可能发生在提交成功之后；应核对目标时间线及错误提示，不能把提交成功写成业务完成。
选择正确的消息种类
message_kind | 用途 | 返回语义 |
|---|---|---|
assignment | 给已有会话一项新任务 | 不创建自动回传绑定 |
forward | 转交信息，默认种类 | 不要求结果返回，但仍可激活目标 |
collaboration_request | 请求处理并返回结果 | 可信标记提供准确来源会话，模型按标记回复 |
reply | 把结果发回请求来源 | 又一次单向发送，不是运行时完成确认 |
session_query 用于定位会话，session_create_sub 用于需要新执行者的任务，session_send 用于给确切已有会话发送一条消息。目标应使用用户提供或工具返回的精确 SessionRef，不能猜测或改写标识。
创建子会话会提交首条 assignment，但创建和发送本身均不建立等待、完成状态或自动结果回路。协作请求要求接收方完成工作后调用一次 session_send，以 reply 发回完整结果；这是受可信消息标记指导的模型行为，不是运行时保证每个子会话必然回复。
因此，“两个子会话的回复到达后，协调会话分别继续处理”与“运行时自动替子会话生成回复”不是同一件事。子会话可能因缺材料、失败或未执行回复动作而需要用户补充；应检查具体回复和产物。不要仅因发送成功就重复派发或轮询制造第二项任务。
哪些入口可以产生会话事件
Agent 会话
主 Agent 可以创建子会话并提交第一条任务消息，也可以向已有目标会话发送消息。子会话可以展示阶段结果；需要协调会话继续工作时，应向准确来源发送回复消息，而不只留下一条本地最终回复。
触发器
定时触发器或外部触发器命中后，可以把预先配置的任务发送到指定会话。触发器只负责提交事件，不等待目标会话完成整个任务。
AgentPlugin
微信、Telegram 等 AgentPlugin 收到消息后，可以将消息转换为带可信来源的会话输入。实际路由由插件入口、会话引用和前台会话职责决定，不能把“所有消息默认进入主会话”当作通用规则。
AgentPlugin 还可以携带图片或文档。xAgent 完成资源解析后，再把它们作为目标会话可使用的附件交给 Agent。
当前 session_send 只允许内部会话转发，并拒绝把 AgentPlugin 前台会话作为目标。向外部用户交付结果需要对应的插件发送能力与准确来源；在内部会话里写出最终答案，不等于外部消息已送达。
外部接口
企业系统或其他服务可以通过受控接口触发事件入口，把业务变化送到目标 Agent 会话。外部调用仍需经过对应的身份验证和权限控制。
一个协作示例
假设用户希望持续收集行业新闻，并定期生成分析报告：
- 主 Agent 创建“新闻采集”和“报告生成”两个子会话。
- 定时触发器向新闻采集会话发送协作事件，激活新一轮采集任务。
- 新闻采集会话把资料和整理结果保存到自己的会话产物中。
- 完成后展示阶段结果和产物引用；仅展示通知不会驱动报告会话继续工作。
- 需要生成报告时，主 Agent 或用户向报告生成会话提交明确任务；需要回传时使用协作请求，并附上已确认、目标有权访问的资料引用。
- 报告生成会话使用自己的上下文和 Skill 完成报告，不需要继承新闻采集会话的全部历史。
这种方式传递的是明确任务和产物，而不是合并两个 Agent 的所有对话历史。
安全边界
只允许同一用户的会话通信
事件入队前会校验目标会话归属。当前版本只允许事件发送到同一用户拥有的会话，不支持跨用户会话通信。
跨用户通信会同时涉及身份冒用、数据泄露、外部账号权限和审批责任。在没有独立授权与审计机制前，直接允许 Agent 跨用户发送事件是不安全的。
必须有明确目标
会话事件不是无边界广播。事件创建时必须确定目标会话，队列不会根据来源内容自行猜测投递对象。
事件不绕过审批
协作事件可以激活目标会话，但后续 Tool 调用、文件操作、外部发送和业务系统修改仍需遵守目标会话的权限、工作区边界和审批策略。
AgentPlugin 不扩大外部权限
AgentPlugin 只是消息和事件入口。目标系统中能够读取、发送或修改哪些内容，仍由用户授权和外部系统权限决定。
当前版本的边界
- 当前主分支已有同一用户的 Session 协作，以及 WorkGroup 管理会话、Agent/连接边目录、草稿与发布版本能力。WorkGroup 保存编排配置，不承担独立的业务运行状态；实际工作仍由各 Session 执行。
- 早期“完整项目级 Agent Team 规划中”的定位不能用于否认已实现的 WorkGroup，也不能由此推导出跨用户共享团队、自动任务闭环或任意复杂项目自主完成。
- 仅展示通知不会自动触发目标 Agent；消息种类与上下文消费范围应分别核对。
- 事件成功投递不等于业务任务成功完成。
- 当前不支持跨用户会话协作。
- 复杂协作应传递明确任务、文件产物和可验证结果，避免只发送模糊状态。