从一个目标到一个 Agent 团队：xAgent Agent Teams 实测
把一个目标交给多个 Agent，首先要解决的是怎样分工：谁接目标，谁做研究，谁整理表达，最后由谁核对结果。角色名字写进提示词以后，还要能看到每个角色实际做了什么。
2026 年 10 月 23 日，我们在 xAgent 演示站 新建了一个独立演示团队，用本次界面中观察到的三条产品事实做了一次小任务。本文保留真实界面和人工介入过程，把团队配置、任务执行和结果核对分开记录。
Agent Teams：把一个目标分给多个独立执行者
Agent Teams（智能体团队）组织多个 Agent 为同一目标工作。这里的“团队”说的是执行角色和协作关系。本文采用常见的协调者 / 执行者结构：一个 Agent 负责协调，其他 Agent 接受有边界的工作，各自推进，再把结果交回来；这不是所有 Agent 团队都必须采用的唯一结构。一个用户也可以带一个 Agent 团队；多用户账号管理属于另一层问题。
多智能体编排（Multi-agent Orchestration）负责组织这条链路：目标如何拆分、谁来执行、哪些任务要先后衔接、何时等待，以及怎样检查和汇总结果。任务委托（Task Delegation）是其中的具体动作，需要给接收方明确的任务、必要材料、限制和返回要求。派发成功只说明委托进入了某个环节，最终还要看执行与交付。
这种分工的价值，在于让研究、编辑、核对等工作有清晰的职责与验收点。成员可以保留独立上下文，不必把所有角色的全部历史混入一个会话。协调者通过必要的信息、消息和产物引用接收结果，再决定如何汇总。共享资料为协作提供共同材料，不等于所有成员共享同一个模型上下文。
任务之间存在依赖时，可以先研究再编辑；互不依赖的任务则可以采用并行编排。这是通用设计选择。本次观察到的是前一种分阶段协作，没有验证并行加速。
xAgent 怎样实现这些概念
xAgent 的“虚拟团队”是 Agent Teams 的产品入口。虚拟团队手册与 0.1.0 发布说明给出的对应关系如下：
| 通用概念 | xAgent 中的实现 | 使用时核对什么 |
|---|---|---|
| 协调者 / 执行者 | 专用经理、成员会话树 | 谁接目标、谁收到具体任务 |
| 角色与任务委托 | 岗位模板复用、经理派工、经理间委托 | 职责是否清楚，任务是否真正到达 |
| 上下文与结果汇总 | 独立成员会话、回复和共享业务目录 | 材料是否足够，回复与产物是否一致 |
| 人工参与 | 所有者指导与审批机制 | 纠偏是否被接收，重要动作是否符合授权 |
Agent Harness（智能体运行体系）是更大的范围：工具调用、上下文组织、任务恢复、协作和人工审阅等机制一起支撑 Agent 执行。Agent Teams 是其中组织多个执行者的一部分，不是只靠一个角色提示词就能保证任务完成。
这张映射表描述产品能力，不意味着下面一次小任务覆盖了全部功能。岗位模板复用、经理间委托、归档恢复没有在本次验证；共享目录和产物引用也不能仅凭有文件就判定交付成功。
真实示例：研究、编辑和经理核对
这次选择的是一个很小的资料整理任务：把提供的三条界面事实整理成一段短说明。材料固定，不需要联网搜索，方便核对成员是否增加了未经支持的信息。
配置证据：经理已经建立，成员按需招募
创建入口要求填写“团队名称”和“团队职责”，并说明会初始化一位职责固定的团队经理，具体目标在创建后发送，成员按工作需要招募。
本次团队名为“Agent Teams 文章演示 2026-10-23”。职责设为整理公开产品资料，经理拆分任务、按需招募研究与编辑成员、核对并汇总；任务范围限制在提供的演示资料内，不访问其他会话、私人文件或业务数据，不对外发布、不修改代码、不购买、不部署，只做一次性任务。
图 1 创建前的真实表单。截图仅裁剪对话框，没有重绘界面。
创建后的团队信息显示“已就绪”“团队经理”“有效成员 1”，目标区域仍提示“暂无目标，请在经理会话中下达具体目标”。这些字段确认了团队与经理已经建立，此时还没有证据表明研究、编辑两位执行成员已经加入。
图 2 新团队的初始状态。团队标识已遮挡，其余可见内容保留原样。“已就绪”是组织状态，不是业务完成状态。
这里还有一次实际介入：团队初始化后自动开始了首轮需求审查。观察约 2 分 24 秒仍未得到最终结果，演示操作者先停止这轮运行，再发送带明确范围的任务。这段等待不是完整任务耗时，也没有用于计算效率提升。
委托约束：两位成员，一份可验收结果
随后提交的具体任务只使用这次界面观察得到的三条材料，没有让 Agent 再去搜索外部资料。要求招募恰好两位成员：研究员提炼事实，编辑把事实写成 150 字以内的说明，经理检查是否夸大并汇总。每位成员最多派发一次任务，交付后停止。
预期交付为三条事实、一段短说明和一条证据边界，并明确禁止把“已就绪”写成任务已经完成，也不能推断性能收益。这里的“两位成员”是提交时的要求，需要后续实际成员和结果记录来确认。
图 3 具体任务提交后的界面。此刻经理显示“执行中”，左侧仍只显示经理，不能仅凭这张图宣称两位成员已经完成协作。
执行证据：成员收到任务，并按依赖交接
执行过程中，团队树出现了“团队经理”“研究专员”“编辑专员”。进入研究专员会话，可以看到来源为经理的“团队派工”，以及“一次性派工，仅此一次，请完整执行后回报”的要求。这比只看到经理说“我会安排两个人”多了一层证据：成员会话和收到的任务已经可见。
图 4 研究任务已进入成员会话，截图时仍在执行。来源会话标识和消息标识已遮挡。成员存在、任务到达和任务完成是不同状态。
研究专员随后完成任务并回报，经理收到的正式报告包含与输入材料一致的三条事实，之后再推进编辑环节。可见顺序是“经理派工 → 研究回报 → 编辑整理”，因此本文将其记为分阶段协作，没有把它描述成并行研究，也没有据此计算加速比。
结果核对：编辑交付了什么
编辑会话最终显示“会话空闲”，正文显示任务完成并已向经理正式回报，留下的短说明如下：
点击“新团队”后只需填写团队名称、团队职责。创建时初始化一位职责固定的团队经理，具体目标在创建后于经理会话中下达，成员按工作需要招募。创建后页面显示“已就绪”“团队经理”“有效成员 1”，其中“已就绪”仅为显示状态，不表示任务已完成。
对上面这段文本逐字符核对，含标点与“有效成员 1”中的空格共 117 个字符，符合本次不超过 150 字的限制。内容覆盖了输入的创建字段、经理初始化与目标下达、初始状态三条事实，也保留了“已就绪不代表任务完成”的边界。
图 5 编辑结果可直接核对，相关标识已遮挡。界面历时 8 分 44 秒描述该次编辑运行，不是整项任务耗时，更不是速度优势的证据。
经理随后验收两位成员的回报，最终以会话文字完成交付。收尾时经理显示“会话空闲”，团队树保留经理和两位成员，未归档。最终回执说明每位成员各派工一次，没有周期任务；这些是本次回执与界面的观察，不推断其他团队的行为。
图 6 最终交付与保留的团队。会话内结果可见，但这不抹去过程中出现的失败、范围偏差或附件问题。
实测暴露的问题：执行恢复与范围控制
经理在派工时曾提交空的 assignment_id，未通过参数校验，随后自行修正并成功派发，没有人工补改参数。
等待阶段随后出现了 task_wait 的 wait_ref 错误，经理的首轮执行显示“执行失败”，界面历时为 13 分 11 秒。之后编辑的正式报告到达，触发经理的新一轮运行。这是一段包含失败和接续的过程，不能写成一次无异常完成。
图 7 等待阶段的真实失败记录，派工与工作记录标识已遮挡。界面显示 13 分 11 秒；后续回报触发接续，不等于这次失败没有发生。
这次任务明确要求“不访问文件”，预期交付是会话内的三条事实、短说明和边界。经理却生成了一份备用 Markdown 产物；文件栏后来又出现了最终交付文件。在该演示会话的产物预览中，确认备用文件确实存在，内容为演示事实、说明和边界。这是超出本次无文件操作范围的行为，需要单独记录；它并不能证明读取了其他私人文件。
图 8 备用产物的真实预览，消息标识已遮挡。它证明文件实际生成，也暴露了与本次无文件操作要求的偏差。截图中的字数是 Agent 自报值，不作为本文独立测量结果。
经理还准备在交付后归档。演示操作者因此补充一次纠偏：不要归档，不再写文件、不创建新任务，完成交付后保持空闲。提交时界面先显示“引导已排队”，之后该指导进入会话。最终经理确认取消归档步骤，保持团队与空闲状态；这才补上了指导被实际采纳的证据。
交付还出现了无效 file_ref 附件引用，经理最终改为文字交付。因此本次验证了会话内的结果汇总，没有验证成功的文件引用交付。
整个过程中，人工介入有两处：开始时停止初始化需求审查，以及后来补充范围纠偏。这次任务最终交付了可核对内容，但不是无干预、无偏差的成功样本。后续改进应分别检查等待引用的处理、文件交付校验，以及自然语言范围约束如何在执行前得到有效约束。
怎样判断编排真正有效
这类任务值得留下三层证据：
- 配置层：团队是否建立，经理是谁，成员和职责是什么。
- 执行层：具体目标是否提交，委托到达哪个成员，各自做了什么，是否需要人工补充或停止。
- 结果层：成员回复、经理汇总与实际产物是否一致，来源与内容是否符合要求。
这次新团队与早先主会话加两个子会话的演示分开记录，没有混用运行数据。具体消息语义见会话协作说明。
只有第一层截图，最多证明团队配置存在；看到发送成功，也还需要核对接收与执行。判断协作是否有效，最终应回到交付物与验收标准。
本次不统计相对单 Agent 的速度、成本或成功率，没有对照组，也没有把页面上的模型标签当作全部调用的证明。团队共享资料也不会自动扩大跨用户或外部系统的访问权限。要把这一流程用于真实工作，应先用非敏感材料验证，再按业务风险设置授权和审批。