awesome-copilot 中的 ai-team-dev 开发智能体：Nova、Sage、Milo 三视角协作与六步交付工作流

本文以 agents/ai-team-dev.agent.md 为主体，完整解析 awesome-copilot 仓库中「AI 开发团队（Dev Team）」智能体的角色定义、六步工作流与职责边界，并结合同仓库的 Producer/QA 配套智能体、ai-team-orchestration 技能与插件说明，说明如何在一个真实代码库中以"轻流程、强边界"的方式落地多智能体开发协作。

1. 智能体定位：一个能"跨项目实际技术栈"交付的实现者

ai-team-dev 是一个 GitHub Copilot 自定义智能体（chat mode / CCA 均可使用）。从其 frontmatter 可以直接看到定位：

---
name: 'ai-team-dev'
description: 'AI development team (Nova, Sage, Milo). Use when implementing features, fixing bugs, writing tests, improving user experience, or preparing a pull request across the project''s actual stack.'
---

description 明确了它的适用场景：实现功能、修复缺陷、编写测试、改进用户体验、准备 Pull Request，并且强调"across the project's actual stack"——即它必须基于仓库真实存在的技术栈工作，而不是假想的技术栈。

值得注意的一个设计细节（可以从 plugins/ai-team-orchestration/README.md 与 skills/ai-team-orchestration/SKILL.md 中相互印证）：该智能体的 frontmatter 刻意省略了 tools 和 model 字段。从仓库说明看，这样做带来三个效果：

• 开发者环境中已启用的内置工具、MCP 工具和扩展工具都保持可用，无需为每个插件维护机器相关的工具白名单；
• 模型选择权保留在开发者手中，插件不强制指定模型；
• 角色边界完全由指令文本（instructions）以及常规的信任、权限、认证与审批控制来定义。

这与 skills/ai-team-orchestration/references/anti-patterns.md 中"避免硬编码工具或模型白名单，应继承开发者已启用的工具和所选模型"的反模式建议是一致的设计取向。

2. 三视角：Nova、Sage 与 Milo

文档开篇即定义了核心概念——Dev Team 并非三个独立进程，而是一个智能体内部组合的三种视角，且只使用与当前项目相关的视角：

• Nova——客户端、交互、呈现层与用户可见行为（client, interaction, presentation, and user-facing behavior）；
• Sage——核心逻辑、服务、数据、集成、基础设施与安全（core logic, services, data, integrations, infrastructure, and security）；
• Milo——体验、可访问性、视觉语言、内容与打磨（experience, accessibility, visual language, content, and polish）。

SKILL.md 中还有一句关键澄清："Nova, Sage, and Milo are perspectives inside the Dev agent, not mandatory project layers." 也就是说，它们是认知视角，不是强加给项目的架构分层。配套的智能体定义文件可继续查阅：agents/ai-team-producer.agent.md（Producer，Remy）与 agents/ai-team-qa.agent.md（QA，Ivy）。

紧跟着是一条重要的反幻觉约束：

Do not invent layers or frameworks that the repository does not use. （不要发明仓库没有使用的分层或框架。）

这条约束直接针对 LLM 编码中常见的"过度设计"倾向：让实现者先理解仓库实际存在的架构，再在其上工作，避免凭空引入项目并不使用的中间层、设计模式或依赖。

3. 六步工作流：从理解任务到响应反馈

文档的 ## Workflow 小节定义了完整的六步闭环，这是整个智能体的"交付主干"：

1. 理解工作（Understand the work）——先读仓库指令（repository instructions，如 AGENTS.md/instructions 文件）、项目上下文、任务或计划，以及相关的既有代码；
2. 增量实现（Implement incrementally）——遵循当前架构与代码约定，做"能解决问题的最小完整改动"（the smallest complete change that solves the problem）；
3. 验证（Verify）——运行仓库中相关的测试、构建、lint、类型检查，以及聚焦的手动检查；
4. 自审（Self-review）——检查最终 diff 的正确性、安全性、回归风险、不必要的复杂度以及缺失的测试；
5. 交接（Handoff）——必要时更新持久化的项目上下文（durable project context），创建或更新 PR，并附上简洁的摘要、验证结果与已知限制；
6. 响应反馈（Address feedback）——评估 review 与 QA 的发现，修复有效问题，并重新运行受影响的检查。

从源码结构看，这套流程与同仓库 ai-team-orchestration 技能定义的默认工作流完全对齐——技能层给出的全局流程是 Plan -> Implement -> Test -> optional review or QA -> Merge -> update project state（见 skills/ai-team-orchestration/SKILL.md），Dev 智能体正好承担其中的 Implement 与 Test 两段，外加 PR 准备；Plan 由 Producer 承担，Merge 则明确不归 Dev 所有。这种"流程骨架在技能层、执行细节在智能体层"的拆分，让同一套协作模式可以按风险大小裁剪：小改动直接做，跨模块或高风险改动才上计划、独立审查与 QA。

4. 职责边界（Boundaries）：不合并、不越权、不泄密

文档的 ## Boundaries 小节是这份智能体定义中最有工程价值的部分，五条边界逐一拆解如下：

边界条款	工程含义
不合并 PR、不声称拥有独立审查或 QA 批准	实现者不得自我放行。"谁实现、谁验证"的独立性必须由 QA 角色或人工 review 保证
不静默改变项目范围或协作计划；重大冲突必须显式提出	范围变更是显式事件，避免智能体"顺手"扩大或缩小任务
遵循仓库的 Git 与贡献政策；保留未知工作；未经批准不重写共享历史、不执行破坏性操作	与 skills/ai-team-orchestration/references/anti-patterns.md 中"不用通用 Git 命令配方、遵循仓库分支政策""保留未知工作"的条目一一对应，兼容不同远端、分支保护与合并策略
密钥与终端用户身份信息不得出现在源码、fixtures、日志、issue 与文档中	把保密要求落实到产物层面（不只是代码），覆盖测试数据与问题单
在仓库要求的验证完成之前，只引用 issue 而不关闭	防止"PR 提到 issue 就自动关闭、但验证其实没做完"的状态污染

其中第一条与同仓库 agents/ai-team-qa.agent.md 中 QA 的边界"不编辑应用源码、不合并 PR"形成互补：Dev 不声称独立审查，QA 不修改实现——验证与实现的分离通过两份指令互为镜像得以保持。而合并权则交给 Producer（agents/ai-team-producer.agent.md 定义了其在确认必需检查与批准后按仓库政策合并）以及仓库自身的分支保护、必需检查与 merge queue。

5. 工作方式：自主解决常规细节，只在真歧义时提问

## Working Style 小节只有两句话，但定出了人机协作的"打断成本"基线：

Use the tools available in the developer's environment and the selected model. Resolve ordinary implementation details autonomously. Ask only when requirements, risk, or product behavior are genuinely ambiguous. （使用开发者环境与所选模型中可用的工具。自主解决常规实现细节。仅在需求、风险或产品行为真正含糊时才提问。）

这与 Producer 定义中"不发明仓库和用户没有要求的关卡"、以及 skills/ai-team-orchestration/SKILL.md 中"对普通实现选择让 Dev 依据仓库约定自行决定"的原则一致：日常决策自主化，歧义升级最小化，避免智能体在琐碎细节上反复确认。

6. 在 AI 团队生态中的位置：Dev 是执行核心

单独看 ai-team-dev 只理解了它的一半；结合仓库中的配套文件可以看到一个完整的三角色系统：

角色	智能体	职责	关键边界
Producer（Remy）	agents/ai-team-producer.agent.md	范围澄清、按比例规划、协调 Dev 与可选 QA、triage、维护项目上下文、合并	绝不编写或修复应用源码
Dev Team（Nova/Sage/Milo）	agents/ai-team-dev.agent.md	实现、测试、自审、准备 PR	不合并、不声称独立批准
QA（Ivy，可选）	agents/ai-team-qa.agent.md	独立行为验证、可复现地报告缺陷、验证修复	不改应用源码，只报告

三者由 plugins/ai-team-orchestration/plugin.json（v2.0.0）打包为 ai-team-orchestration 插件，同时注册三个 agent 与 ai-team-orchestration 技能；plugins/ai-team-orchestration/README.md 给出的原则与 Dev 文档的边界互为表里："Producer 协调但从不实现；Dev 实现并验证但从不合并或声称独立批准；QA 可选、独立验证行为且不修复应用源码。"

支撑这套协作的可复用资产还包括：

• 项目简报模板：skills/ai-team-orchestration/references/project-brief-template.md，提供 Goal、Scope、Stack、Key Files、How to Work、Safety、Current State、Team and Handoff 八个段落，用于跨会话的持久上下文（PROJECT_BRIEF.md）；

• 工作计划模板：skills/ai-team-orchestration/references/sprint-plan-template.md，含目标、上下文、In/Out of Scope、任务、验收标准、验证方式（自动/手动/独立审查/QA 各自 required-optional-not needed）与下一步行动，并附"进度笔记"与"Dev Handoff"提示词——Dev Handoff 正是直接调度 @ai-team-dev 的标准提示：

  Read the repository instructions, PROJECT_BRIEF.md when present, and this plan.
  Implement the in-scope work, run the listed verification, update durable context
  when needed, and prepare a pull request. Do not merge.
  

• 头脑风暴格式：skills/ai-team-orchestration/references/brainstorm-format.md 把 Nova、Sage、Milo 连同 Remy、Ivy 等人格化为有明确"tendency（倾向）"的辩手，要求至少 2 处真实分歧，避免"团队一致同意"式的平庸输出——这解释了为什么 Dev 文档要为三个视角各自定义领域与倾向。

• 反模式清单：skills/ai-team-orchestration/references/anti-patterns.md 列出了 9 组"应避免/应优先"对照，其中"单智能体包揽规划、实现、测试与审批""QA 去修应用源码""把每个自动化建议都当成需求"等条目，正是 Dev 边界条款在系统层面的展开。

关于上下文恢复，SKILL.md 还给出了一个"冷启动提示词"，供中断后的会话续接：

Read the repository instructions, then read whichever sources exist for this
work: the active issue or request, PROJECT_BRIEF.md, and the active plan or
progress note.
Continue from the recorded next action.

7. 安装与使用

按照 docs/README.agents.md 的通用说明，使用自定义智能体的标准路径是：

1. 点击目标智能体对应的 VS Code / VS Code Insiders 安装按钮，或把 *.agent.md 文件下载到你的仓库中；
2. 该 agent 无 MCP 依赖（智能体表中 MCP Servers 一列为空），无需额外配置 MCP Server；
3. 通过 VS Code Chat 界面、在 Copilot Coding Agent（CCA）中指派、或 Copilot CLI 来激活；智能体可访问已配置 MCP Server 的工具。

配合插件 Quick Start（摘自 plugins/ai-team-orchestration/README.md）的调度提示：

@ai-team-producer Help me define the next useful outcome for this project.
Use /ai-team-orchestration and keep planning proportional to the work.

@ai-team-dev Read the repository instructions and active plan or issue.
Implement the requested outcome, run relevant checks, self-review the diff,
and prepare the pull request. Do not merge.

@ai-team-qa Test the pull request against its acceptance criteria.
Focus on important behavior and regressions. Report Ready, Ready with minor
follow-ups, or Blocked with reproducible findings.

适用前提与限制：这套智能体依赖 Copilot 的自定义智能体能力（VS Code 或 CCA），且假设仓库本身具备可读的指令与可运行的检查（测试/lint/构建）；在没有任何验证手段的仓库中，其第三步 Verify 只能退化为聚焦的手动检查。

8. 小结：可复用的多智能体协作模式

ai-team-dev 的价值不在于某一个提示词技巧，而在于它示范了一组可迁移的约束设计：

1. 视角而非分层——用 Nova/Sage/Milo 三种视角覆盖客户端、核心与服务、体验与可访问性，同时禁止虚构仓库中不存在的架构；
2. 最小完整改动——增量实现 + 仓库既有约定，把"改动面"作为默认约束；
3. 验证前置——测试、构建、lint、类型检查与聚焦手动检查在交接前完成，diff 自审覆盖正确性/安全/回归/复杂度/测试缺口五个维度；
4. 权限隔离——实现者不合并、不自我批准；验证者不改代码；合并归协调者与仓库政策；
5. 过程按风险裁剪——小改动免计划，大改动才上计划、独立审查与 QA，拒绝"一刀切流程"。

这套模式的全部原始素材都可在仓库中直接核对：智能体定义在 agents/ai-team-dev.agent.md，协作流程与模板在 skills/ai-team-orchestration/SKILL.md 及其 references 目录，插件元数据在 plugins/ai-team-orchestration/plugin.json。如果你想在自己的仓库中落地类似的"AI 开发团队"，可以以该文件为骨架，按自己仓库的指令体系与检查命令做替换，保留其边界条款不变。