创建团队
团队是一组具名的智能体，它们拥有各自的角色、一个 lead、一个目标项目以及一段协调提示词。
推荐的第一个团队
从一个小团队起步：
| 角色 | 用途 |
|---|---|
| Lead | 拆分工作、创建任务、协调队友 |
| Builder | 实现范围明确的任务 |
| Reviewer | 审查产出、捕捉回归、提出修复请求 |
这样的构成提供了足够的协调能力，让你在不让首次启动过于嘈杂的情况下，就能看到产品价值。
TIP
你可以稍后再添加更多成员。先从小处着手，验证工作流，然后再扩大规模。
分配提供方与模型
每个团队成员都运行在某个提供方后端上。在团队编辑器中，为每个成员选择一个提供方（Claude、Codex 或 OpenCode）和一个模型。应用只会显示你已经完成身份验证的提供方。
支持在一个团队中混用多个提供方——例如，一个 Claude lead 搭配若干 OpenCode builders。
INFO
Gemini 作为受支持的提供方路径可用。有关身份验证选项和当前提供方状态，请参阅提供方与运行时。
编写一份好的团队简报
团队简报应包含：
- 你想要的结果
- 重要的文件或功能领域
- 风险边界，例如“不要重构无关的模块”
- 审查预期
- 在你知道的情况下提供验证命令
示例：
Build a focused improvement to the download flow. Keep changes inside the landing app unless a shared helper is clearly needed. Create tasks before implementation, review each task diff, and run landing lint/build checks.worktree 隔离
OpenCode 成员可以使用 worktree 隔离，在一个独立的 Git worktree 中工作，而不是在主工作目录中。这可以防止多个智能体编辑同一个项目时产生文件冲突。
WARNING
worktree 隔离要求项目处于 Git 跟踪之下，并且目前仅限于 OpenCode 成员。
要启用它，请在添加或编辑某个 OpenCode 团队成员时切换 Worktree isolation 选项。
选择自主级别
Agent Teams 支持不同级别的控制。对于常规改动使用更高的自主级别，而对于诸如提供方身份验证、IPC、持久化、Git 工作流以及发布工具等高风险领域，则采用更严格的审查。
努力级别
每个团队成员都有一个 effort（努力）设置，用于控制提供方在响应之前投入多少推理。更高的努力级别会产出更全面的结果，但代价是时间和 token。
| 级别 | 何时使用 |
|---|---|
| Low | 快速查询、小幅格式调整、常规编辑 |
| Medium | 大多数实现任务的默认级别 |
| High | 复杂的重构、横切性改动、高风险的代码路径 |
应用为支持相应能力的提供方提供了额外的级别（minimal、xhigh、max）。如果某个模型不支持可配置的努力级别，则该选择器会被禁用，并使用提供方的默认值。
快速模式
可按成员切换 Fast mode（快速模式），以优先考虑速度而非深度。当可用时，它会映射到提供方原生的 fast/speed 模式。将其设为 On 用于常规任务，设为 Off 用于需要细致处理的工作，或设为 Inherit 以遵循团队级别的默认设置。
限制上下文
启用 Limit context（限制上下文）以缩减某个成员的上下文窗口。这对于支持扩展上下文（例如 1M token）的 Claude 模型很有用——限制上下文可以避免不必要的 token 占用，并且对于不需要大上下文的任务还能改善延迟。
添加上下文
当文件、截图或特定说明会实质性地改变任务时，将它们附加进去。智能体可以将任务描述、评论和附件用作持久的上下文。
关注任务质量
优秀的团队所创建的任务应当是：
- 足够具体以便审查
- 足够小以便完成
- 与可见的产出相关联
- 有验证路径作为支撑
如果 lead 创建了含糊的任务，请发送一条私信，要求拆分成更小、可测试的任务。