F7 · 用户如何组织多个 Agent 协同工作？ - Agent Collaboration

所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：03 · Agent Platform 应该提供哪些产品功能？ - Product Architecture
文档类型：专题研究 / 产品架构 / 交互与工程参考设计
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：Agent Platform 如何让用户创建和管理 Agent 团队，配置角色、任务、协作关系与审批规则，观察和干预协作过程，并在可控的成本与权限边界内交付团队成果？

专题导读

本篇属 Product Architecture。F1 - F2 - F3 - F4 - F5 - F6 已覆盖 Agent 创建、配置、开发测试、发布共享、工作空间管理和单 Agent 执行。F7 研究的是多个 Agent 被用户组织起来完成共同目标时，平台应提供什么产品能力。它不等同于在后端实现一个多 Agent 框架：用户必须能够理解团队构成、职责分工、任务流转、协作状态、冲突处理与最终责任。技术层的 Agent System Orchestration 解释协作机制，P6 Workflow Management 解释工作流的持久化调度，F7 则将其转化为可理解、可操作、可审核的产品体验。

本文以研究报告 Studio 为贯穿案例，区分已有架构研究中可复用的概念、本篇提出的产品参考设计与需要实际验证的假设。文中的接口、数据结构和测试均为设计建议，不代表已经完成开发、用户访谈或性能测试。

研究结论

Agent Team 是可管理的协作配置，Workflow 是可执行的任务编排，Collaboration Run 是一次协作实例。三者需要分别建模；团队不是简单的 Agent 名称列表。
多 Agent 产品应同时提供团队视图、流程视图、任务视图、对话/事件视图和成果视图，但不要求将它们全部挤在同一个页面。
协作必须显式定义角色、责任、输入输出契约、交接条件、失败路径和人类决策点；“让 Agent 自由讨论”不能替代任务管理。
平台至少应支持顺序交接、主管分配、并行分工与审核返工四类常见协作模式；复杂动态路由属于后续能力。
协作可观察性与协作可控制性分开设计。看见消息不意味着可以修改任务；可取消任务也不意味着能够撤销已发生的外部副作用。
协作中的每个 Agent、工具、知识资源和工作流节点应继承并收紧执行权限，不能通过“委派给另一个 Agent”绕过权限、预算或审批。
对 Studio MVP，建议先支持固定团队、显式流程、结构化交接、审核返工、人工确认、节点状态与成果引用；后续再引入动态组队、开放式群聊和自适应规划。

01 · 概念、边界与术语

1.1 什么是 Agent Collaboration

Agent Collaboration 指用户在平台上组织两个及以上 Agent，使其围绕共同目标进行分工、交接、协商、审核或并行处理，并能够管理过程与结果的产品能力。核心对象不仅是 Agent，还包括团队、角色、任务、协作关系、工作流、运行实例、消息、决策、审批和产物。

概念	含义	本篇产品职责
Agent	具有独立定义与版本的执行主体	选择、查看能力与授权范围
Agent Team	Agent 成员及角色分配的协作配置	创建、编辑、复用、管理
Role Assignment	某 Agent 在特定团队承担的职责	配置职责与交接条件
Workflow Definition / Version	任务节点及依赖关系的可发布定义	可视化编排与校验入口
Collaboration Run	一次团队协作的业务实例	聚合状态、进度与成果
Step Run / Agent Run	协作中某一节点或 Agent 的执行	任务级操作与追踪
Handoff	带上下文、结构化产物与接收者的交接	明确输入输出和责任
Message / Event	可见交流或系统状态变化	沟通与活动时间线
Review Decision	对阶段成果的接受、退回或修改要求	质量门禁与返工
Human Intervention	人类批准、修改、补充信息或终止	人机协同与责任控制

1.2 与其他专题的边界

F2 Agent Configuration：配置单个 Agent 的能力、工具与运行限制；F7 配置它在团队中的职责与协作契约。
F5 Workspace & Project Management：决定团队和任务属于哪个项目；F7 决定项目内 Agent 如何协作。
F6 Agent Execution：单个 Agent Run 的启动与控制；F7 汇总并协调多个 Run。
F8 Agent Monitoring：跨任务运行监控、指标、诊断；F7 提供当前协作任务的可理解状态。
P6 Workflow Management：执行引擎、状态持久化、调度、重试；F7 提供创建与操作这些能力的产品界面。

1.3 协作与编排的关系

“编排”主要描述执行顺序、路由和状态转换；“协作”还包含成员职责、沟通、审查、冲突解决和共同成果。一个 DAG 工作流可以没有 Agent 间直接通信；一个多 Agent 群聊也可能缺少可靠的工作流管理。成熟平台通常需要将二者组合。

02 · 用户画像、目标与使用场景

用户	主要任务	关键疑问	产品需求
业务发起人	提交复杂目标、获得结果	谁在做？做到哪一步？	简化启动、阶段进度、结果确认
团队设计者	组建 Agent 团队	角色如何分工？是否冲突？	成员选择、角色配置、协作画布
项目负责人	控制交付质量与成本	哪一步需要审核？	审核门禁、预算、返工与版本
Agent 开发者	调试多 Agent 协作	交接为何失败？	结构化 Trace、节点输入输出
审核人	审查阶段成果	证据是什么？可以如何退回？	审核界面、意见与历史记录
管理员	管理资源和权限	是否越权或超额？	策略、审计、配额与治理入口

典型场景：研究报告写作、软件开发与代码审核、客服分级处理、市场研究、数据分析、内容生产、跨工具业务自动化。不同场景对可解释性、质量门禁与人类控制的要求不同，不应预设所有场景都适合完全自动化。

03 · 产品能力地图

建议将 F7 分为八组产品能力。

能力组	核心功能	MVP 优先级
团队创建	选择 Agent、分配角色、保存团队	P0
协作设计	顺序、分支、并行、返工、交接契约	P0（基础）
任务启动	选择团队版本、填写目标与输入	P0
协作工作台	阶段状态、成员活动、当前任务	P0
审核与干预	接受、退回、补充资料、暂停/取消	P0
成果汇总	中间产物、最终产物、版本引用	P0
调试与评估	节点 Trace、质量指标、回归比较	P1
模板与生态	团队模板、共享、安装、动态组队	P2

3.1 推荐信息架构

mermaid

flowchart TB
  P[Project / Studio]
  P --> Teams[Agent Teams]
  P --> WF[Workflows]
  P --> Runs[Collaboration Runs]
  P --> Assets[Artifacts]
  Teams --> TDetail[Team Detail / Members / Roles]
  WF --> Editor[Workflow Editor]
  Runs --> Desk[Collaboration Workbench]
  Desk --> Progress[Stage Progress]
  Desk --> Activity[Activity & Messages]
  Desk --> Decisions[Review & Interventions]
  Desk --> Outputs[Intermediate & Final Outputs]

建议以“项目任务”为业务入口，而不是强制用户先理解 Agent 版本、DAG、调度器等工程概念。高级用户可以进入流程画布和调试视图；普通用户默认看到目标、当前阶段、负责人和待处理事项。

04 · 核心对象模型与数据关系

4.1 建议的领域对象

对象	核心字段	不应混淆的对象
Team Definition	team_id, workspace_id, name, owner	Agent Definition
Team Version	team_version_id, member refs, role assignments	Agent Version
Team Member Assignment	agent_version_ref, role, responsibility, constraints	用户成员 Membership
Collaboration Definition	collaboration_id, workflow_version_ref, team_version_ref	Workflow Definition
Collaboration Run	run_id, project_id, frozen refs, status	Agent Run
Collaboration Task	task_id, assignee, input refs, status	Workflow Step Run（可映射）
Handoff Record	source, target, payload ref, schema, decision	普通聊天消息
Review Request	target artifact, reviewer, rubric, deadline	工具执行审批
Review Decision	accepted/rework/rejected, rationale, evidence	Workflow 状态
Team Artifact Link	artifact_version_ref, stage, role, provenance	文件本体

Team Definition 与 Team Version 的拆分属于建议：如果 MVP 团队配置只在 Workflow Version 中冻结，也可以暂不独立建立 Team Version；但必须能从历史 Run 恢复当时的团队成员与版本。

4.2 对象关系图

mermaid

erDiagram
  PROJECT ||--o{ COLLABORATION_RUN : owns
  TEAM_DEFINITION ||--o{ TEAM_VERSION : versions
  TEAM_VERSION ||--o{ TEAM_ASSIGNMENT : includes
  AGENT_VERSION ||--o{ TEAM_ASSIGNMENT : assigned
  WORKFLOW_VERSION ||--o{ COLLABORATION_RUN : executes
  TEAM_VERSION ||--o{ COLLABORATION_RUN : pinned
  COLLABORATION_RUN ||--o{ COLLABORATION_TASK : contains
  COLLABORATION_TASK ||--o{ HANDOFF_RECORD : emits
  COLLABORATION_TASK ||--o{ REVIEW_REQUEST : requests
  REVIEW_REQUEST ||--o{ REVIEW_DECISION : receives
  COLLABORATION_RUN ||--o{ ARTIFACT_LINK : produces

4.3 身份与版本不变量

Team、Workflow、Agent、Run 使用独立稳定标识，避免一个 ID 同时表达定义和执行。
Run 创建时固定 Team Version、Workflow Version、Agent Version 及关键依赖摘要。
团队配置修改不会静默更新运行中的任务；需要新版本或显式迁移。
Handoff 记录发送者、接收者、输入输出引用和校验结果，不能只存一段不可解析的自然语言。
审核决策绑定明确的产物版本，不能仅绑定“当前报告”。

05 · Agent 团队创建与成员管理

5.1 创建流程

选择项目 → 新建团队 → 添加 Agent → 分配角色 → 配置职责与约束 → 检查权限/资源 → 保存草稿 → 关联工作流。

建议的团队成员卡片展示 Agent 名称、已发布版本、能力摘要、可用工具、工作空间来源、权限警告与预期成本。用户可以按职责选择“研究者、分析者、审稿者、编辑者”等角色，但角色名称不应直接授予平台权限。

5.2 角色与职责契约

每个角色至少应说明：目标、输入、输出、完成标准、可调用资源、可委派范围、交接对象、失败处理方式。同一 Agent 可以承担多个角色；一个角色也可在不同任务中由不同 Agent 承担，但需要避免职责不清导致的重复劳动或审核自证。

5.3 组队前的检查

检查	失败提示	用户可采取的操作
Agent 不可访问	当前项目无权使用此 Agent	请求共享、替换成员
Agent 版本失效	指定版本已撤销	选择有效版本、停止配置
工具缺少授权	成员无法使用必要工具	绑定连接、缩小任务范围
输出契约不兼容	上游输出不能被下游读取	修改 Schema 或增加转换节点
审核职责冲突	生产者同时作为唯一审核者	分离审核责任
预算不足	预计超出可用预算	调整模型、任务范围或预算

06 · 协作模式与流程设计

6.1 四种基础模式

模式	典型流程	适用情境	主要风险
顺序交接	A → B → C	依赖清晰的生产链	上游错误传播
主管分配	Manager → Worker(s) → Manager	任务分解与汇总	主管成为瓶颈
并行分工	A ∥ B ∥ C → Merge	可独立研究的子任务	重复工作、结果冲突
审核返工	Producer → Reviewer → Rework	质量要求明确的任务	无限循环、审核失真

6.2 参考协作流程

mermaid

flowchart LR
  U[用户提交目标] --> T[选题 Agent]
  T --> R[选题审核 Agent]
  R -->|退回 + 修改意见| T
  R -->|通过| H{用户确认}
  H -->|拒绝/调整| T
  H -->|确认| D[调研 Agent]
  D --> A[分析 Agent]
  A --> Q[报告审核 Agent]
  Q -->|返工| A
  Q -->|通过| W[写作/排版 Agent]
  W --> O[成果交付]

上图仅为参考设计。实际生产中，深度调研和分析可能需要循环补证，审核也应支持退回到不同上游节点。流程设计器应显式配置可返工节点和循环上限。

6.3 流程画布的最小交互

画布节点应展示节点名称、绑定 Agent、输入/输出 Schema、超时、重试策略、预算和审核条件；边应展示触发条件与传递的数据。点击节点可查看配置与历史运行，不应在同一视图中强迫用户编辑底层 JSON。

6.4 动态路由的边界

LLM 可以提出“下一步交给谁”的建议，但应由平台根据可用节点、权限、预算、最大迭代次数和工作流版本执行验证。未经约束的 Agent 自主创建执行路径会削弱审计、成本预测和错误恢复能力。动态路由应作为显式授权的高级模式，而非默认行为。

07 · 任务分配、交接与上下文共享

7.1 Handoff 的最小契约

一次交接建议包含：来源任务、目标任务、交接类型、输入产物版本、结构化摘要、所需操作、验收标准、截止条件、权限上下文及追踪标识。不要依赖聊天记录的最后一条消息充当唯一任务说明。

yaml

handoff_id: hof_001
source_task_id: topic_001
target_task_id: review_001
source_agent_version: agent_topic@1.2.0
target_role: topic_reviewer
payload:
  candidate_topics_ref: assetver_abc
  research_goal: "形成可验证的研究选题"
  acceptance_criteria:
    - "研究问题明确"
    - "资料来源可追溯"
    - "范围可在预算内完成"
context_refs:
  - assetver_brief_01
limits:
  max_rework_rounds: 3
  review_deadline_seconds: 600

这是示意契约，字段名称与格式并非行业标准。

7.2 上下文共享策略

传递引用优先：传递资产版本、摘要和检索句柄，避免重复复制整个长上下文。
按需最小披露：审核 Agent 只获取完成审核所需的资料，不自动继承生产 Agent 的全部私有资源。
来源标记：区分用户原始指令、平台策略、Agent 产出和第三方检索内容，降低不可信内容冒充系统指令的风险。
快照与更新区分：固定运行时使用的资料版本；如需引入新资料，应形成可追踪的补充事件。

7.3 交接校验

在调度下游前校验目标 Agent 可用性、输入 Schema、权限、资产可访问性、预算与任务状态。校验失败应展示可操作的原因，而不是让下游 Agent 在模糊上下文中自行猜测。

08 · 协作工作台：状态、消息与可视化

8.1 四层信息呈现

总览层：任务目标、当前阶段、总状态、预算、待用户处理事项。
流程层：节点依赖、当前执行节点、已完成/失败/等待的节点。
成员层：每个 Agent 的职责、当前任务、最近事件和产物。
证据层：节点输入输出、引用、审核意见、Trace 与故障信息。

普通用户默认总览与流程；开发者按需展开证据层。过度展示模型内部推理内容既可能误导用户，也可能暴露敏感信息；建议展示经过筛选的操作事件、决策依据和可验证证据。

8.2 协作消息类型

类型	示例	是否应影响状态机
Agent Message	“已完成三项候选选题”	不一定
Task Assigned	“调研任务分配给研究 Agent”	是
Handoff Submitted	“已提交结构化选题清单”	是
Review Requested	“等待审核 Agent 检查”	是
Review Decision	“退回：证据不足”	是
Human Input Requested	“请确认研究范围”	是
Tool Activity	“检索服务调用完成”	通常作为子事件
Artifact Published	“正式报告 v1 已生成”	是

聊天消息与业务事件应分开存储。 对话可以帮助理解协作，但不能作为任务状态、权限或审批的唯一事实来源。

8.3 状态表达

协作总状态建议使用 draft / queued / running / waiting_human / pausing / paused / cancelling / cancelled / succeeded / failed / partially_completed 的受控集合；节点可以有独立状态。partially_completed 是否为终态取决于产品契约，应事先定义。不得简单地把所有节点中的“成功比例”当成整体业务进度百分比。

8.4 用户干预入口

工作台应允许用户在有权限时：查看待审核请求、接受或退回阶段成果、补充资料、暂停后续调度、取消整个任务、重试失败节点、从检查点恢复。对正在执行的外部副作用应显示风险说明；取消不能被描述为“撤销已经发送的邮件”。

09 · 审核、返工、冲突与人工协同

9.1 审核是独立业务对象

审核请求应绑定明确的目标产物版本、审核标准、审核者、截止时间和流程上下文。审核结论至少区分 accepted / changes_requested / rejected / inconclusive，并记录理由与证据。质量审核与高风险工具审批是不同对象：前者判断产物是否合格，后者决定某项操作能否执行。

9.2 返工闭环

mermaid

stateDiagram-v2
  [*] --> Submitted
  Submitted --> InReview
  InReview --> Accepted
  InReview --> ChangesRequested
  InReview --> Rejected
  ChangesRequested --> Reworking
  Reworking --> Submitted
  Accepted --> [*]
  Rejected --> [*]

返工必须设定最大轮次、时间/成本上限与人工升级规则。返工意见应关联原始审核对象，生成的新产物使用新版本，保留历史结果，不覆盖原件。

9.3 冲突解决

并行 Agent 可能对同一问题给出相反结论。平台应保留每份输出与证据，支持人工或指定仲裁节点比较差异。不能把“多数 Agent 同意”自动视为事实正确；相同模型、相同检索来源的多个 Agent 可能共享偏差。

9.4 人工接管

在高风险外部操作、证据不足、超预算、审核循环耗尽、资源不可用或无法解决的冲突中，平台应提供人工接管。人工操作需要记录执行人、操作范围、决策依据和受影响的节点；人工修改后的内容也应成为可追溯的版本。

10 · 运行可靠性与异常恢复

10.1 必须区分的失败

失败情形	用户可见状态	参考恢复动作
Agent 运行超时	节点超时、整体可能等待	受控重试或缩小任务
下游输入 Schema 不匹配	交接失败	修正映射并重新提交
审核无限返工	达到轮次上限	转人工处理
并行节点部分失败	部分完成	重试失败分支或降级
工具授权撤销	节点等待授权或失败	重新授权/替换资源
用户断线	后端继续运行	重新订阅事件并补齐历史
Worker 丢失	Attempt 失联	租约回收、幂等重试
重复事件投递	不应重复改变业务状态	事件去重与幂等处理
外部操作结果未知	结果待核实	对账，不盲目重放
发布渠道切换	运行保持原版本	新 Run 使用新版本

10.2 可靠性原则

执行引擎应提供持久化状态与重试，但外部世界无法由平台保证“恰好执行一次”。对发送邮件、支付、写入外部数据库等操作，需采用幂等键、业务对账和人工确认。运行恢复应基于持久化的任务状态与产物版本，不依赖前端页面是否打开。

10.3 部分完成的处理

当部分研究节点完成、部分节点失败时，平台应允许保存已生成产物、说明缺失范围，并由用户决定是否继续、补做或以“未完成”状态导出。不得将缺失的分析内容伪装为完整研究报告。

11 · 安全、权限、预算与治理

11.1 授权检查点

团队创建、成员引用、工作流发布、Run 启动、节点调度、资源调用、跨工作空间资产读取、人工审批和最终交付均应分别检查权限。Team Role（研究者、审核者）是业务角色，不直接等于平台 IAM Role。

11.2 委派不扩权

Agent A 向 Agent B 委派任务时，B 的实际权限应是自身授权、当前项目范围、委派许可与平台策略的交集；不得因为 A 可以访问某资源，就将其凭证直接传给 B。共享上下文应使用短期授权的资产引用或受控数据传递。

11.3 预算模型

建议同时限制团队级总预算、单节点预算、并发数、最大重试次数和审核返工轮次。预算应计入模型 Token、工具调用、检索、存储和可能的外部服务费用。估算与最终账单可能不一致，需提供超限处理策略。

11.4 提示注入与不可信消息

来自网页、文件、第三方插件或其他 Agent 的内容都可能包含恶意指令。平台应在 UI 和执行契约中标记来源与信任级别；工具执行权限由策略层控制，不能由对话内容直接赋权。审核 Agent 不能被上游 Agent 的“请忽略规则”之类文本改变其平台授权。

12 · 技术架构映射与服务边界

mermaid

flowchart TB
  UI[Collaboration Workbench / Team Builder]
  API[Platform API]
  CP[Control Plane / Authorization]
  WF[Workflow Management / Durable Scheduler]
  EX[Execution Plane / Workers]
  REG[Agent & Team Version Registry]
  RES[Resource Gateway]
  ASSET[Asset Service]
  EVENT[Event Store / Streaming]
  UI --> API --> CP
  CP --> REG
  CP --> WF
  WF --> EX
  EX --> RES
  EX --> ASSET
  WF --> EVENT
  EX --> EVENT
  EVENT --> API

产品职责与技术职责分离：Team Builder 负责用户配置，Workflow Service 负责执行图与持久化，Agent Registry 负责版本引用，Execution Plane 执行节点，Asset Service 管理成果，Governance 控制权限预算。一个初期系统可以采用模块化单体实现这些边界，无需过早拆分为多个微服务。

12.1 API 参考设计

方法	路径（示例）	用途
POST	`/v1/teams`	创建团队定义
PATCH	`/v1/teams/{id}/draft`	修改团队草稿
POST	`/v1/teams/{id}/versions`	发布不可变团队版本
GET	`/v1/teams/{id}`	查看团队与成员
POST	`/v1/collaboration-runs`	创建协作 Run
GET	`/v1/collaboration-runs/{id}`	查看状态与阶段
GET	`/v1/collaboration-runs/{id}/events`	订阅事件流
POST	`/v1/review-requests/{id}/decisions`	提交审核决策
POST	`/v1/collaboration-runs/{id}/cancel`	请求取消
POST	`/v1/collaboration-runs/{id}/tasks/{task_id}/retry`	请求节点重试

以上路径仅为产品契约示例，需与 P8 的 API 规范统一，包括认证、幂等、错误格式、分页、版本和对象级授权。

12.2 创建协作任务的示例

json

{
  "project_id": "proj_agent_study",
  "team_version_id": "teamver_research_3",
  "workflow_version_id": "wfver_report_5",
  "input": {
    "research_question": "Agent 平台如何支持多 Agent 协作？",
    "brief_asset_version_id": "assetver_brief_11"
  },
  "controls": {
    "budget_limit_usd": 15,
    "max_review_rounds": 3,
    "require_human_topic_approval": true
  }
}

服务端应校验版本关联关系、项目归属、权限与配额，返回异步 Run ID 和当前状态。金额仅为示意值，不是 Studio 实际预算建议。

12.3 事件契约示例

json

{
  "event_id": "evt_001",
  "collaboration_run_id": "crun_001",
  "sequence": 17,
  "type": "review.changes_requested",
  "occurred_at": "2026-11-01T05:00:00Z",
  "task_id": "task_topic_review",
  "artifact_version_id": "assetver_topics_2",
  "data": {
    "review_request_id": "rev_001",
    "next_action": "rework"
  }
}

事件流应支持去重、排序或序列号、重连补齐；不同分区之间的全局顺序不能未经设计就假设成立。事件数据中的用户隐私、工具参数和敏感输出应按权限脱敏。

13 · 参考数据模型

以下 SQL 为 PostgreSQL 风格的概念性表结构片段，并非可直接部署的完整迁移脚本；省略了租户 RLS、所有外键、索引、状态约束与审计触发器。

sql

CREATE TABLE agent_teams (
  id UUID PRIMARY KEY,
  workspace_id UUID NOT NULL,
  name TEXT NOT NULL,
  owner_id UUID NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE agent_team_versions (
  id UUID PRIMARY KEY,
  team_id UUID NOT NULL REFERENCES agent_teams(id),
  version_label TEXT NOT NULL,
  manifest JSONB NOT NULL,
  manifest_sha256 TEXT NOT NULL,
  published_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (team_id, version_label)
);

CREATE TABLE collaboration_runs (
  id UUID PRIMARY KEY,
  project_id UUID NOT NULL,
  team_version_id UUID NOT NULL REFERENCES agent_team_versions(id),
  workflow_version_id UUID NOT NULL,
  status TEXT NOT NULL,
  budget_limit_minor BIGINT,
  created_by UUID NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE collaboration_tasks (
  id UUID PRIMARY KEY,
  collaboration_run_id UUID NOT NULL REFERENCES collaboration_runs(id),
  workflow_node_id TEXT NOT NULL,
  agent_version_id UUID,
  status TEXT NOT NULL,
  attempt_count INTEGER NOT NULL DEFAULT 0,
  input_asset_version_id UUID,
  output_asset_version_id UUID
);

CREATE TABLE collaboration_handoffs (
  id UUID PRIMARY KEY,
  collaboration_run_id UUID NOT NULL REFERENCES collaboration_runs(id),
  source_task_id UUID NOT NULL REFERENCES collaboration_tasks(id),
  target_task_id UUID NOT NULL REFERENCES collaboration_tasks(id),
  payload JSONB NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

工程注意：在多租户系统中，需要以租户/项目归属和复合外键防止跨租户引用；审查 JSONB 中的敏感数据；采用状态转换事务、唯一事件 ID、幂等键和并发控制；发布版本须不可变。审核对象、任务尝试、事件存储、资产关联应使用独立表或复用 P6/P10 既有模型，避免重复建模。

14 · Studio 贯穿案例：研究报告 Agent 团队

14.1 产品目标

用户在 Studio 中输入研究目标，由多个 Agent 完成选题、审核、深度调研、分析、写作和交付。用户可以看见任务进度，审核关键成果，并在失败或质量不达标时决定返工或终止。

14.2 团队配置示例

角色	主要职责	输入	输出	关键门禁
选题 Agent	形成候选研究问题	用户目标、研究范围	选题清单	结构与范围校验
选题审核 Agent	评价可行性和证据	选题清单	审核意见	审核通过或返工
深度调研 Agent	收集可核验资料	确认选题	资料与引用	来源与证据检查
分析 Agent	归纳机制与结论	调研材料	分析稿	论证一致性
研究审核 Agent	检查结论与证据	分析稿、引用	审核记录	通过或退回
写作 Agent	组织最终报告	已审核材料	Markdown 草稿	格式与结构检查
交付模块	生成可下载文件	审核通过稿	MD/PDF 等	权限与导出检查

交付模块可以是平台服务，不必伪装成 Agent。团队中是否需要独立写作 Agent、分析 Agent，应根据实际质量和成本测试决定。

14.3 用户端完整旅程

第一步：组建团队。 用户进入项目，选择预设研究团队，检查成员版本、工具权限、成本上限及审核规则。平台提示缺失的资源连接。

第二步：配置协作。 用户在流程视图中确认选题审核返工路径、人工选题确认点、调研与分析交接 Schema、最终交付格式。

第三步：启动任务。 用户提交研究问题、资料和预算。平台固定团队与工作流版本，创建 Collaboration Run。

第四步：观察协作。 工作台显示“选题进行中”“等待审核”“等待用户确认”等状态；用户可以查看选题 Agent 的候选清单和审核 Agent 的意见，而不是只能阅读一条持续增长的群聊。

第五步：人工确认。 选题审核通过后，用户确认或要求调整。该决策绑定具体选题产物版本，并作为继续调研的门禁。

第六步：返工与异常。 如果研究审核发现证据不足，平台创建返工任务并将意见传回相应节点；若达到循环上限，进入人工接管。

第七步：交付与归档。 最终报告关联团队版本、工作流版本、主要输入来源、审核记录和运行 ID，进入 F10 产物中心。

14.4 推荐的 Studio 页面布局

顶部：项目、任务标题、总状态、预算与关键操作。
左侧：工作流阶段和节点状态；支持切换团队成员视图。
中部：当前节点详情、协作活动与用户审核入口。
右侧：输入资料、阶段产物、审核记录与最终交付。
底部或侧栏：用户补充输入；输入范围明确标注为“当前任务”或“整个工作流”。

布局是可用性假设，需要通过用户测试验证。对于移动端，应优先展示状态与待处理事项，避免将桌面多栏布局等比例压缩。

14.5 最小可用产品范围

第一阶段不建议把“所有 Agent 自由群聊”作为核心能力。优先实现固定流程 + 清晰交接 + 人工审核 + 可见状态 + 可恢复任务。这更容易定位故障、控制成本并评估研究质量。开放式协作可作为对比实验，而不是先验最佳方案。

15 · 开发阶段与产品验收

阶段	范围	可验证交付
M0 交互模拟	假数据团队、流程、审核与产物	用户可完成全链路演示
M1 真实顺序执行	固定团队、Run、节点状态、交接	真实完成单条研究流程
M2 可靠审核返工	审核对象、轮次上限、人工确认	可中断、返工和恢复
M3 并行与质量评估	并行分工、合并、节点评估	对比成本、时延与质量
M4 复用与治理	团队模板、版本、共享、权限	跨项目可控复用
M5 高级协作	动态分配、复杂冲突处理	在明确基线下验证收益

15.1 产品指标

建议按五类指标衡量：任务完成率、阶段审核通过率、返工轮次与返工原因、用户干预效率、单位合格成果成本。补充节点失败率、端到端耗时、人工等待时长和引用质量。所有指标都需明确分母、时间窗口与“合格成果”的业务定义。

15.2 核心验收标准

用户能够回答：谁负责当前任务？当前处于哪个阶段？下一步是什么？哪些事项等待我？产物来自哪里？发生失败时能采取什么操作？实际使用了哪些 Agent 版本？是否超出预算？若平台无法稳定回答这些问题，多 Agent 数量增加不会自动提升产品质量。

16 · 参考验证矩阵

以下测试均为待执行测试设计，并非已通过的工程验证。

ID	测试情境	预期结果
T01	创建含两个 Agent 的团队	成功保存团队与角色
T02	团队缺少有效 Agent 版本	发布前阻断并提示
T03	无权限引用他人 Agent	拒绝并审计
T04	团队成员工具未授权	预检提示缺失连接
T05	上下游 Schema 不匹配	阻断或要求显式转换
T06	固定团队版本启动	Run 保存不可变版本引用
T07	运行中编辑团队草稿	历史 Run 不受影响
T08	顺序交接成功	下游收到正确产物版本
T09	并行任务全部成功	合并节点只执行一次
T10	并行任务部分失败	显示部分完成与恢复选项
T11	审核请求生成	绑定具体产物版本
T12	审核要求返工	新任务接收结构化意见
T13	达到返工上限	停止循环并请求人工介入
T14	用户拒绝选题	不进入后续调研
T15	用户确认选题	记录决策者、时间和版本
T16	审核人无权限	拒绝提交审核结论
T17	审核决策重复提交	幂等处理，不重复推进
T18	用户关闭页面	后端继续并持久化状态
T19	SSE 断线重连	补齐事件且无重复展示
T20	取消整个协作任务	停止后续调度并报告未撤销副作用
T21	取消与完成竞态	状态转换遵守预定义规则
T22	Worker 失联	任务可安全接管或进入待核实
T23	工具授权中途撤销	后续调用被阻断
T24	Agent A 尝试委派越权任务	B 不能获得额外权限
T25	不可信网页包含指令注入	不获得平台级权限
T26	预算耗尽	按策略停止或等待批准
T27	并发超过配额	排队或明确拒绝
T28	审核 Agent 与生产 Agent 同一主体	按策略警告或阻断
T29	并行结果相互矛盾	保留来源并进入仲裁/人工审核
T30	历史产物被更新	原审核仍指向旧版本
T31	资产跨租户引用	未授权访问被拒绝
T32	重试存在外部副作用的节点	需要幂等或人工核对
T33	团队成员版本被撤销	新 Run 阻断，既有 Run 按策略处理
T34	运行记录查询	能追溯团队、流程、节点与产物
T35	用户仅有查看权限	不能修改团队或审批
T36	项目归档	按保留策略保持历史可审计
T37	移动端查看待审核事项	关键操作可达且语义明确
T38	多次返工后生成最终报告	完整保留所有审核与版本链
T39	重复 Webhook/事件	不重复创建任务或产物
T40	评估结果不合格但运行成功	明确显示质量状态与执行状态不同

建议另行开展用户可用性测试，记录完成任务所需步骤、误操作、对状态的理解偏差和人工审核耗时；并通过故障注入验证 Worker 中断、网络分区、数据库事务失败及工具结果未知等情形。

17 · 局限、争议与研究反思

17.1 多 Agent 不必然优于单 Agent

多 Agent 增加了交接、上下文复制、模型调用、调度和审核成本。任务可分解程度不高时，单 Agent 加工具或固定工作流可能更简单、更稳定。是否采用多 Agent，应以质量、成本、时延和可维护性的对照实验决定。

17.2 可视化并不等于可理解

复杂的流程画布可能提高配置门槛。用户需要的是目标、责任、状态和下一步操作，而不是所有底层节点与消息。产品应提供渐进式信息披露。

17.3 审核 Agent 的判断并非事实证明

LLM 审核容易受相同模型偏差、共享资料错误、提示注入和评价标准模糊影响。重要研究结论需要可核验来源、规则校验与必要的人类复核。

17.4 “自由协作”与“确定性治理”的张力

开放式协作适合探索，但难以预测成本和终止条件；显式工作流易于治理，但可能限制灵活性。可采用受限动态节点，在明确权限、预算和退出条件下允许局部自主决策。

17.5 研究结论与工程假设的边界

本篇对象模型、API、数据结构和 Studio 产品布局是参考设计。它们可用于需求讨论与原型开发，但不代表通用行业标准，也没有通过真实用户研究、性能测试或生产安全审计。

18 · 总结与下一步

F7 的核心不是让多个 Agent 在同一个聊天框中发言，而是将团队、任务、交接、审核、状态、干预与成果组织成完整的产品协作闭环。用户应能建立团队、清楚理解责任分工、启动可追踪的协作 Run、审查关键成果、处理失败与返工，并获得具有来源记录的最终交付。

对 Studio，建议以固定研究团队和显式审核流程建立可用基线，再通过真实任务对比不同协作模式的质量与成本。下一篇 F8 · 用户如何查看 Agent 的运行状态与结果？ - Agent Monitoring 将研究跨任务监控、可观测性、指标、告警、追踪与诊断的产品体验。

附录 A：参考文献与原始资料

以下以官方规范、官方文档和原始研究为主。它们支持部分底层技术概念，并不直接定义本文的 F7 产品架构；各类 Studio 产品建议为综合推论。

LangGraph Documentation - Workflows and Agents / Persistence / Human-in-the-loop. LangChain. docs.langchain.com/oss/python/langgraph/overview （支持有状态图编排、持久化与人类干预的技术背景；具体版本需按实施时核对。）
Microsoft AutoGen - Documentation. Microsoft. microsoft.github.io/autogen/stable （多 Agent 消息与协作模式的工程参考；不代表平台必须采用 AutoGen。）
OpenAI Agents SDK - Documentation. OpenAI. openai.github.io/openai-agents-python （Agent、handoff、tracing 的参考实现。）
Temporal - Documentation. Temporal Technologies. docs.temporal.io （持久化工作流、失败恢复、重试的技术参考。）
CloudEvents Specification v1.0.2. CNCF. github.com/cloudevents/spec （事件元数据与互操作性参考；本文事件契约未宣称完全符合 CloudEvents。）
OpenTelemetry Specification. CNCF. opentelemetry.io/docs/specs/otel （Trace、Metrics、Logs 的可观测性术语参考。）
OWASP Top 10 for Large Language Model Applications. OWASP. genai.owasp.org/llm-top-10 （提示注入、工具与权限风险的安全背景。）
NIST AI Risk Management Framework 1.0. NIST, 2023. doi.org/10.6028/NIST.AI.100-1 （AI 系统风险治理参考。）
JSON Schema - Specification. JSON Schema. json-schema.org/specification （交接与结构化输出校验的技术依据。）
PostgreSQL Documentation - Transactions / Row Security Policies. PostgreSQL Global Development Group. www.postgresql.org/docs/current （事务一致性与多租户数据隔离参考。）
OpenAPI Specification. OpenAPI Initiative. spec.openapis.org/oas/latest.html （接口契约与 SDK 生成的技术参考。）
Google Research - Self-Consistency Improves Chain of Thought Reasoning in Language Models. Wang et al., 2023. arxiv.org/abs/2203.11171 （说明多路径采样的研究背景；不能推导“多数 Agent 同意即事实正确”。）
CAMEL: Communicative Agents for “Mind” Exploration of Large Language Model Society. Li et al., 2023. arxiv.org/abs/2303.17760 （角色扮演协作的研究实例；需注意研究设定与生产系统差异。）
AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. Wu et al., 2023. arxiv.org/abs/2308.08155 （多 Agent 对话协作的研究背景。）

附录 B：研究证据、验证声明与适用边界

B.1 证据等级

规范/官方资料支持：JSON Schema 的结构校验、OpenAPI 接口描述、OpenTelemetry 可观测性概念、Temporal/LangGraph 的持久化与编排能力等。
工程推论与参考设计：Team Version 对象、Collaboration Run 聚合模型、产品工作台分层、审核与交接契约、Studio 分阶段开发路线。
待验证假设：固定团队与显式流程能否显著提升 Studio 的质量、用户能否理解工作台布局、审核成本是否可接受、动态协作是否产生净收益。

B.2 验证声明

本文未实际调用所列 SDK 或框架进行对比实验，未运行 SQL 迁移、接口测试、故障注入、安全测试或用户研究。参考测试矩阵只定义测试目标和预期行为。文献链接应在正式发表或工程实施前再次检查版本、发布日期和相关章节。

B.3 适用范围

适用于具有多个 Agent、可追踪任务、结构化交接、阶段审核和产物交付需求的 Agent Platform，尤其适合研究、内容生产和企业流程自动化。对于低风险即时聊天、单 Agent 小工具或极端低延迟场景，可采用更轻量的产品结构，不必完整引入 Team Version、复杂审批与独立协作工作台。

F7 · 用户如何组织多个 Agent 协同工作？ - Agent Collaboration ​

专题导读 ​

研究结论 ​

01 · 概念、边界与术语 ​

1.1 什么是 Agent Collaboration ​

1.2 与其他专题的边界 ​

1.3 协作与编排的关系 ​

02 · 用户画像、目标与使用场景 ​

03 · 产品能力地图 ​

3.1 推荐信息架构 ​

04 · 核心对象模型与数据关系 ​

4.1 建议的领域对象 ​

4.2 对象关系图 ​

4.3 身份与版本不变量 ​

05 · Agent 团队创建与成员管理 ​

5.1 创建流程 ​

5.2 角色与职责契约 ​

5.3 组队前的检查 ​

06 · 协作模式与流程设计 ​

6.1 四种基础模式 ​

6.2 参考协作流程 ​

6.3 流程画布的最小交互 ​

6.4 动态路由的边界 ​

07 · 任务分配、交接与上下文共享 ​

7.1 Handoff 的最小契约 ​

7.2 上下文共享策略 ​

7.3 交接校验 ​

08 · 协作工作台：状态、消息与可视化 ​

8.1 四层信息呈现 ​

8.2 协作消息类型 ​

8.3 状态表达 ​

8.4 用户干预入口 ​

09 · 审核、返工、冲突与人工协同 ​

9.1 审核是独立业务对象 ​

9.2 返工闭环 ​

9.3 冲突解决 ​

9.4 人工接管 ​

10 · 运行可靠性与异常恢复 ​

10.1 必须区分的失败 ​

10.2 可靠性原则 ​

10.3 部分完成的处理 ​

11 · 安全、权限、预算与治理 ​

11.1 授权检查点 ​

11.2 委派不扩权 ​

11.3 预算模型 ​

11.4 提示注入与不可信消息 ​

12 · 技术架构映射与服务边界 ​

12.1 API 参考设计 ​

12.2 创建协作任务的示例 ​

12.3 事件契约示例 ​

13 · 参考数据模型 ​

14 · Studio 贯穿案例：研究报告 Agent 团队 ​

14.1 产品目标 ​

14.2 团队配置示例 ​

14.3 用户端完整旅程 ​

14.4 推荐的 Studio 页面布局 ​

14.5 最小可用产品范围 ​

15 · 开发阶段与产品验收 ​

15.1 产品指标 ​

15.2 核心验收标准 ​

16 · 参考验证矩阵 ​

17 · 局限、争议与研究反思 ​

17.1 多 Agent 不必然优于单 Agent ​

17.2 可视化并不等于可理解 ​

17.3 审核 Agent 的判断并非事实证明 ​

17.4 “自由协作”与“确定性治理”的张力 ​

17.5 研究结论与工程假设的边界 ​

18 · 总结与下一步 ​

附录 A：参考文献与原始资料 ​

附录 B：研究证据、验证声明与适用边界 ​

B.1 证据等级 ​

B.2 验证声明 ​

B.3 适用范围 ​

F7 · 用户如何组织多个 Agent 协同工作？ - Agent Collaboration

专题导读

研究结论

01 · 概念、边界与术语

1.1 什么是 Agent Collaboration

1.2 与其他专题的边界

1.3 协作与编排的关系

02 · 用户画像、目标与使用场景

03 · 产品能力地图

3.1 推荐信息架构

04 · 核心对象模型与数据关系

4.1 建议的领域对象

4.2 对象关系图

4.3 身份与版本不变量

05 · Agent 团队创建与成员管理

5.1 创建流程

5.2 角色与职责契约

5.3 组队前的检查

06 · 协作模式与流程设计

6.1 四种基础模式

6.2 参考协作流程

6.3 流程画布的最小交互

6.4 动态路由的边界

07 · 任务分配、交接与上下文共享

7.1 Handoff 的最小契约

7.2 上下文共享策略

7.3 交接校验

08 · 协作工作台：状态、消息与可视化

8.1 四层信息呈现

8.2 协作消息类型

8.3 状态表达

8.4 用户干预入口

09 · 审核、返工、冲突与人工协同

9.1 审核是独立业务对象

9.2 返工闭环

9.3 冲突解决

9.4 人工接管

10 · 运行可靠性与异常恢复

10.1 必须区分的失败

10.2 可靠性原则

10.3 部分完成的处理

11 · 安全、权限、预算与治理

11.1 授权检查点

11.2 委派不扩权

11.3 预算模型

11.4 提示注入与不可信消息

12 · 技术架构映射与服务边界

12.1 API 参考设计

12.2 创建协作任务的示例

12.3 事件契约示例

13 · 参考数据模型

14 · Studio 贯穿案例：研究报告 Agent 团队

14.1 产品目标

14.2 团队配置示例

14.3 用户端完整旅程

14.4 推荐的 Studio 页面布局

14.5 最小可用产品范围

15 · 开发阶段与产品验收

15.1 产品指标

15.2 核心验收标准

16 · 参考验证矩阵

17 · 局限、争议与研究反思

17.1 多 Agent 不必然优于单 Agent

17.2 可视化并不等于可理解

17.3 审核 Agent 的判断并非事实证明

17.4 “自由协作”与“确定性治理”的张力

17.5 研究结论与工程假设的边界

18 · 总结与下一步

附录 A：参考文献与原始资料

附录 B：研究证据、验证声明与适用边界

B.1 证据等级

B.2 验证声明

B.3 适用范围