此为预览文档，正式版本尚未发布。
管理 API
所有路径相对 Service 地址，使用用户 Bearer token 和已授权空间。列表请求必须提供tenant、namespace；创建时将两者写入 JSON。示例与认证函数见 Team API 指南。
PATCH Team 目前要求提交名称和 Leader，并会应用请求中的 policy，不是任意字段的局部合并。先 GET 当前定义再改写需要的字段，避免遗漏原策略。更新成员时同样保留要沿用的配置；其 agentId 不可在该 PATCH 中更换，改换 Agent 应移除后重新添加。
Team 响应的 id、version、members[].id 用于后续操作；members[].agentId 是注册 Agent 的身份，不能拿成员记录 ID 当作 Agent ID。Leader 不再重复放入成员列表，成员 Agent 和 role 均须唯一。
团队和成员字段
例如 Researcher 必须交付来源和结论，Reviewer 必须指出证据缺口；Leader 负责消除冲突、说明未完成项并提交一份最终结果。成员角色不能代替 Agent 自己的模型、工具和资源配置。
协作限制
“名单外委派”不是指 External Agent 运行模式。一个在成员名单中的 External Agent 仍然是本团队成员。
API 可显式设置策略；控制台创建表单也可能传入自己的初始值。以读取到的
team.policy 为准，不要把所有零值都解释为无限制或禁用。所有数值限制不能为负；maxHops 最大 64、maxChildDepth 最大 32、maxFanout 最大 256，具体操作仍受平台约束。
下面是一个小团队的策略片段，可用于理解字段组合：
expectedVersion 做版本检查。并发、层级和人数限制不构成外部模型账单的硬上限；还需按实际 provider 的用量与账户策略管理预算。
其他策略参数用于限制交付与资源消耗：
预算依赖运行时如实回报用量，内容检查也不能代替工具与数据权限。不要将这些字段理解为外部提供商账单的实时硬限额或完整的数据防泄漏系统。
可以混用哪些成员
Leader 必须具备团队协调能力，包括委派、查看结果和节点完成/失败。普通成员只需完成其承担的角色；并非所有能进行 Chat 的 Agent 都适合当 Leader。
Runtime policy
runtimeBindingPolicy 包含有序 candidates、selectionMode、fallbackMode 和可选 retryPolicy。候选中的 binding 指定执行后端，requiredCapabilities 与 securityConstraints 限制选择条件。成员覆盖要求显式设置 selectionMode:"ordered"、fallbackMode:"disabled" 或 "fresh"，并提供至少一个有效 candidate。候选 binding 使用实际运行绑定结构，不填写主机进程号或任意 URL。
选择遵循节点覆盖、成员覆盖、Agent 策略的层次。显式 fresh fallback 是新执行上下文，保留的工作证据必须在 Issue、评论与 Artifact 中。先验证单候选，再增加回退；扩容与回退都不会自动解决共享文件冲突。
Agent 级默认策略通过 GET/PUT /api/v1/agent-runtime-policies/{agentId} 管理。PUT 提交 tenant、namespace、非空 candidates，每个 candidate 的 binding.bindingId 必须属于该 Agent 且可用；服务会解析实际后端。可设置 selectionMode、fallbackMode、maxConcurrency、queueTimeoutSeconds、attemptTimeoutSeconds、retryPolicy，响应为 {policy}。GET 查询仍需携带 tenant/namespace。
下一步：协作用法 · 工作原理。