Skip to main content
此为预览文档，正式版本尚未发布。
Team 由一个 Leader 和可委派的成员组成。先按创建团队准备成员，再在 Roles & members、协作策略和 Runtime policy 中细化配置。

​
团队和成员字段

例如 Researcher 必须交付来源和结论，Reviewer 必须指出证据缺口；Leader 负责消除冲突、说明未完成项并提交一份最终结果。成员角色不能代替 Agent 自己的模型、工具和资源配置。

​
协作限制

“名单外委派”不是指 External Agent 运行模式。一个在成员名单中的 External Agent 仍然是本团队成员。 当前创建表单会写入显式策略，例如并发 32、fanout 8、hops 8、child depth 8、child issues 64；这些初始值与上表的零值处理不同。保存前检查详情页实际值。不要把零值统一解释为无限制或禁用。 下面是一个小团队的策略片段，可用于理解字段组合：
修改 Team 时 API 使用 expectedVersion 做版本检查。并发、层级和人数限制不构成外部模型账单的硬上限；还需按实际 provider 的用量与账户策略管理预算。

​
可以混用哪些成员

Leader 必须具备团队协调能力，包括委派、查看结果和节点完成/失败。普通成员只需完成其承担的角色；并非所有能进行 Chat 的 Agent 都适合当 Leader。

​
Runtime policy

runtimeBindingPolicy 包含有序 candidates、selectionMode、fallbackMode 和可选 retryPolicy。候选中的 binding 指定执行后端，requiredCapabilities 与 securityConstraints 限制选择条件。配置时使用控制台/API 提供的有效绑定标识，不填写主机进程号或任意 URL 代替。 选择遵循节点覆盖、成员覆盖、Agent 策略的层次。显式 fresh fallback 是新执行上下文，保留的工作证据必须在 Issue、评论与 Artifact 中。先验证单候选，再增加回退；扩容与回退都不会自动解决共享文件冲突。 下一步：协作用法 · 工作原理。