仓库智能体团队编排（元项目团队编排） 是做什么的？
自动化的技能，用于组建、审计和优化适合项目的专业化智能体团队。
该技能分析仓库结构，识别所需专业领域（GitHub 管理员、DevOps、QA、UI/UX、安全、产品分析师、法务、共识法官等），在 .agents/team/ 中物化隔离的配置文件，并建立严格的协调协议（人工介入、用户中转交接、不可变注释、基于证据的仲裁）。
何时调用该技能
- 用户请求：“组建智能体团队”、“为项目分配角色”、“配置智能体角色”、“审计团队活动”、“审查团队角色”、“更新智能体团队组成”。
- 项目中引入了新的主要技术层（Docker、CI/CD、移动端 UI、数据库、外部支付集成），需要专门的领域治理。
执行步骤
第一阶段：快速仓库扫描（标记检查）
在定义角色之前，智能体必须检查关键项目标记：
- 托管与 CI 基础设施： 是否存在
.github/目录、工作流、拉取请求模板、议题模板。 - 许可证与开源治理： 是否存在
LICENSE、版权声明、CONTRIBUTING.md、依赖清单。 - 容器化与编排：
Dockerfile、docker-compose*.yml、k8s/、helm/。 - 测试基础设施：
tests/目录、pytest.ini、vitest.config.*、测试夹具。 - 安全与敏感数据：
auth/、security/目录、令牌处理、会话管理、加密逻辑。 - 用户界面与设计： 前端模块、HTML/CSS、机器人键盘布局、资源文件、设计令牌。
- 当前项目护照： 读取
AGENTS.md和.agents/project_knowledge/切片（如果已初始化）。 - 次要/多语言栈： 包含编译语言或替代语言源文件的子目录（例如
client/、native/、core/、desktop/中的.cpp、.c、.h、.rs、.go、.swift）。
第二阶段：规模自适应调整与开放能力矩阵
在提出角色建议之前，智能体必须评估仓库规模并综合出一个最小但足够团队的方案。
1. 仓库规模测定与角色综合
智能体估算代码库规模（代码行数、文件夹深度、技术多样性）：
-
微型/小型仓库（<1万行代码，单人开发，1-2 个主要栈）： 综合 2-3 个合并角色，将矩阵中的能力块打包成统一的配置文件。
- 经典紧凑三人组：
agent-dev-lead：合并了需求分析、任务分解和通用代码实现（agent-intake-dispatcher+agent-general-worker）。agent-quality-guardian：合并了护照/知识完整性、单元测试套件和死代码审计（agent-meta-guardian+agent-qa-engineer+agent-deep-auditor）。agent-github-steward：Git 卫生、常规提交、代码到 README 的真相一致性检查以及 CI/CD。
- 经典紧凑三人组：
-
中型仓库（1万-5万行代码，小型团队，多个服务）： 部署 3-5 个针对关键组件量身定制的专用角色。
-
大型/企业级仓库（>5万行代码，单仓库、微服务）： 部署 6 个以上细粒度角色，并严格隔离关注点。
-
多语言栈隔离规则（禁止有毒捆绑）： 严格禁止将次要编译语言或专用语言栈（C/C++、Rust、Go、原生 GUI）捆绑到
agent-general-worker中，除非具备专用技能。当检测到多语言栈时，要么综合创建一个专用角色（例如带有原生编译器和工具链的agent-native-desktop），要么明确将原生目录映射为红灯区域并强制握手触发。 -
强制调度员规则（禁止多角色混乱）： 当部署 3 个或更多专用角色时，强制部署一个需求调度员（
agent-intake-dispatcher或agent-dev-lead中集成的调度员）。禁止让用户面对一堆没有统一入口点的孤立角色。
2. 开放能力目录（角色矩阵）
[!IMPORTANT] 下表是一个开放能力目录，而不是不可更改的封闭枚举。智能体拥有完全自主权，可以综合合并角色或自定义与仓库实际架构匹配的领域特定角色（例如
agent-solana-smart-contracts、agent-3d-designer、agent-data-pipeline）。
| 类别 | 能力块/角色 | 仓库标记 | 专业技能 | 职责边界 |
|---|---|---|---|---|
| 基线角色 | agent-general-worker（默认工作器/通才） | 任意项目（基本默认角色） | clean-codecode-reviewersystematic-debugging + 栈技能 | 绿灯： 功能实现、脚本、测试、错误修复。黄灯： 修改 API 契约和依赖项。红灯： 未经交接的破坏性操作和专用领域模块。 |
| 编排 | agent-intake-dispatcher（需求调度员） | 任何具有 2 个以上角色的项目 | prompt-engineeringbrainstorming | 绿灯： 请求分解、提示准备、快速通道执行。红灯： 直接修改项目源代码。 |
| 编排 | agent-meta-guardian（元项目守护者） | 存在 meta-project 结构 | clean-codecode-reviewer | 绿灯： 护照审计、角色遥测、知识库维护。黄灯： 归档非活动角色。红灯： 未经用户确认删除知识库。 |
| 编排 | agent-consensus-judge（仲裁员与共识法官） | 存在争议决策的项目 | architecture-decision-recordsapi-design-principles | 绿灯： 比较论点、实证测试验证。黄灯： 撰写 ADR。红灯： 在没有实证证据的情况下做出决定。 |
| 编排 | agent-deep-auditor（全仓库深度审计员） | 成熟代码库（>500 行） | systematic-debuggingcode-reviewer | 绿灯： 生成审计报告、检测死代码、验证链接/锚点完整性。黄灯： 将发现记录到观察结果中。红灯： 破坏性重构、自主文件删除。 |
| 产品与业务 | agent-product-roaster（产品分析师与评估师） | 产品服务、初创公司 | search_webbrainstorming | 绿灯： 竞争分析、压力测试假设。红灯： 在没有规格说明的情况下更改业务逻辑。 |
| 产品与业务 | agent-creative-director（创意总监） | UI 组件、Web、主题、图标 | image-generatorcss-tokens | 绿灯： 生成调色板、图标、横幅。黄灯： 编辑全局样式。红灯： 未经确认替换品牌标识。 |
| 产品与业务 | agent-ui-ux-engineer（UI/UX 工程师） | 前端、机器人、界面 | semantic-htmlcss-coderui-ux-invariants | 绿灯： 组件布局、有限状态机状态。黄灯： 屏幕导航更改。红灯： 移除破坏性操作的确认。 |
| 产品与业务 | agent-legal-compliance（法务与合规审计员） | LICENSE、公开仓库 | SPDX/SBOM 审计 | 绿灯： 依赖项许可证审计。黄灯： 更新 NOTICE 和头部版权声明。红灯： 更改仓库许可证。 |
| 工程 | agent-github-steward（GitHub 大师与发布主管） | .github/、Git 远程仓库 | github-managementgithub-actions-creatorclean-codecode-reviewer | 绿灯： Git 卫生、常规提交、分支管理、议题分类、发布草稿。黄灯： 代码到 README 一致性检查（确保 README 指令/CLI 与实际代码匹配）、CI/CD 调优。红灯： 强制推送、未经审查合并到主分支、修改密钥。 |
| 工程 | agent-devops-infra（基础设施架构师） | Dockerfile、docker-compose* | docker-expertkubernetes-architectbash-linux | 绿灯： 开发容器、配置 lint 检查。黄灯： 多阶段构建优化。红灯： 生产密钥、.env*、生产 k8s。 |
| 工程 | agent-qa-engineer（可靠性与 QA 工程师） | tests/、测试框架 | test-driven-developmentverification-before-completion | 绿灯： 编写单元/集成测试、验证测试运行。黄灯： 配置测试运行器和契约断言。红灯： 在 CI 中禁用测试。 |
| 工程 | agent-tech-writer（技术撰稿人） | docs/、OpenAPI、Swagger | mermaid-diagram-specialistopenapigoogle-style-guide | 绿灯： 记录函数、README、图表。黄灯： 编辑 API 规格说明。红灯： 发布未经审查的文档。 |
第三阶段：现有团队审计（角色剪枝与垃圾回收）
如果 .agents/team/ 目录已存在：
- 扫描所有文件夹：
.agents/team/*/profile.md。 - 检查每个配置文件中的“角色调用日志（遥测）”表。
- 识别非活动或过时角色：
- 角色已初始化，但日志仅包含初始条目，且超过 30 天无实际调用发生。
- 角色所依赖的技术栈已完全从项目中移除（例如，Docker 已退役，但
agent-devops-infra仍存在）。
- 将候选角色列表编译到
.agents/team/archive/<role_id>/进行归档。 - 禁止自主删除： 归档角色需要用户明确批准！
第四阶段：对话与用户对齐
为用户生成简洁的建议方案：
- 检测到的标记： 列出识别出的项目组件。
- 建议启用的角色： 基线工作器（
agent-general-worker）+ 2-4 个与检测到的标记最匹配的关键领域角色，并附简短理由。 - 归档候选： （如果存在非活动角色）。
- 批准提示： “批准配置以下角色：[…]？”
第五阶段：物化配置文件并在护照中注册
在用户确认后，执行生产写入：
- 为每个批准的角色创建目录：
.agents/team/<role_id>/。 - 使用参考模板
templates/team/profile.md（或以下内嵌模板）搭建.agents/team/<role_id>/profile.md：- 填写角色 ID、范围、调用触发器、活跃技能和边界权限。
- 使用当前日期初始化遥测表。
- 创建一个私有笔记文件：使用参考模板
templates/team/notes.md（或以下内嵌模板）创建.agents/team/<role_id>/notes.md。 - 使用
templates/team/system_prompt.md（或以下内嵌模板）生成初始可用的系统提示.agents/team/<role_id>/system_prompt.md：- 填充角色名称、目的、技能栈和规范边界权限（绿灯/黄灯/红灯）。
- 在根目录的
AGENTS.md中注册角色，位于以下部分下：## 6. 项目智能体团队 (.agents/team/) - [{{ROLE_TITLE}}](.agents/team/{{ROLE_ID}}/profile.md) — {{ROLE_SCOPE}}（由 {{ROLE_TRIGGERS}} 调用） - 生成并向用户展示一个紧凑的快速启动表，避免在聊天中刷屏长提示文本：
| 角色 | 目的 | 系统提示路径 | 触发关键词 | | :--- | :--- | :--- | :--- | | `agent-qa-engineer` | 测试与验证 | `.agents/team/agent-qa-engineer/system_prompt.md` | “运行测试”、“验证校验” |
第六阶段：团队交战规则
每个团队智能体必须遵守核心协调原则：
- 用户驱动的被动性： 无用户明确指令，智能体从不执行后台操作。
- 用户中转的交接： 智能体之间不直接传输控制权绕开用户。如果任务需要其他领域，智能体将结构化的交接包返回给用户：
### 任务交接包：[agent-A -> agent-B] - 原始目标：<所请求的内容> - 已完成工作：<已修改的文件列表> - 交接边界：<当前智能体停止的原因> - 建议 agent-B 的提示：<可直接使用的提示文本> - 交接链限制： 最多 2 次连续交接（跳数 = 2）。在第三步，控制权必须返回给人类。
- 共享文件注释的不可侵犯性： 禁止编辑其他人在
tasks.md、observations.md和architecture.md中的注释。只能更新自己的状态/任务。发生冲突时，向用户清晰描述权衡。 notes.md的专属所有权： 只有角色所有者可以修改.agents/team/<role>/notes.md。- 基于证据的仲裁：
agent-consensus-judge仅根据测试结果、基准测量和官方规范做出裁决。 - 并行子智能体委派（
dispatching-parallel-agents）： 当处理重复性、并行或多目录批处理工作负载（例如多文件迁移、生成多个测试套件、批量 lint/审计）时，主智能体必须调用dispatching-parallel-agents技能。父智能体通过不重叠的目录或任务将工作负载划分给临时子智能体，并向下传递来自AGENTS.md的项目不变量和角色边界。父智能体协调完成、运行完整性测试，并向用户返回合并报告，无需用户介入中间子智能体交接。 - 断路器（二次迭代停止工作）： 如果一个错误修复需要在同一模块进行第二次连续编辑或在相邻代码中产生次级回归，则停止编写代码。退后一步，从源头到消费者跟踪完整的数据生命周期，识别架构性根本原因，在提出任何新差异之前呈现系统性分析。
- 目标状态审计： 在修改黄灯或红灯区域中的非平凡模块之前，确定：单个