Copilot Agentic Workflows CLI：构建受控的多代理交付系统

本项目将GitHub Copilot CLI转变为一个受控的多代理交付系统，通过定义明确的代理角色、技能和工作流，实现更高效的AI辅助软件开发。

随着AI编程助手能力的不断增强，开发者们逐渐意识到单一AI代理的能力边界。虽然GitHub Copilot等工具在代码补全和简单任务上表现出色，但在面对复杂的软件开发任务时，往往需要更精细的分工和协作机制。ABIvan-Tech的copilot-agentic-workflows-cli项目正是为了解决这一问题而设计——它将GitHub Copilot CLI转变为一个受控的多代理交付系统，通过定义明确的代理角色和工作流，实现更高效的AI辅助软件开发。

该项目的设计哲学是围绕Copilot CLI已有的能力构建控制平面，而不是重新发明轮子。它充分利用Copilot CLI的原生功能：

• 自定义代理：为特定阶段和任务定义专用代理
• 内置代理：利用Copilot CLI提供的通用发现、命令执行、研究和审查代理
• 技能系统：通过领域专业化技能扩展代理能力
• 钩子机制：使用确定性护栏确保工作流符合策略

这种设计既保留了Copilot CLI的易用性，又增加了企业级的治理和控制能力。

项目定义了一套清晰的代理角色体系，每个代理负责特定的职责范围：

Orchestrator（编排器）：作为系统的主入口点，负责路由和阶段控制。它是用户交互的第一接触点，决定工作应该流向哪个代理处理。

Planner（规划器）：负责将模糊的需求转化为明确的执行计划。它处理不确定性，规划任务路径，并设置准备就绪检查点。

Implementer（实现者）：专注于文件变更和执行就绪的交付工作。它是实际编写代码的主力代理。

Debugger（调试器）：专门处理可复现的bug诊断和最小化修复。与实现者不同，它专注于问题定位和修复验证。

Verifier（验证器）：独立进行验收验证，确保交付物符合预期。它提供了客观的质量检查，避免实现者自我验证的偏见。

Memory Curator（记忆策展人）：负责在工作完成后更新持久化的项目记忆。它确保有价值的知识被沉淀下来，供未来任务使用。

项目有意复用Copilot CLI的内置代理，而不是重新创建功能相似的代理：

• explore：用于只读侦察，了解代码库结构
• task：用于命令密集型执行，如构建、测试等
• research：用于外部研究，获取技术文档和最佳实践
• code-review：用于针对性的代码审查
• general-purpose：作为通用专家的回退选项

这种复用策略减少了维护负担，同时确保与Copilot CLI的兼容性。

项目引入了三种规划轨道，根据任务复杂度选择合适的路径：

Quick Change（快速变更）：适用于简单、明确的变更，可以直接进入实现阶段。

Feature Track（特性轨道）：适用于中等复杂度的功能开发，需要规划但不需要系统级重构。

System Track（系统轨道）：适用于影响系统架构的重大变更，需要全面的设计和验证。

每个非平凡的规划都必须以"实施准备就绪：通过或阻塞"作为结束，确保在进入执行阶段前所有前提条件都已满足。

执行本身并不自动关闭工作循环。非平凡的工作应该流经验证器，然后在结果产生持久知识时进入记忆策展人。这个闭环设计确保了：

1. 质量把关：独立的验证步骤防止了低质量代码的流入
2. 知识沉淀：有价值的经验被记录下来，形成组织记忆
3. 可追溯性：每个工作项都有完整的处理记录

项目定义了一套清晰的路由规则，指导用户如何与系统交互：

• 除非明确只需要规划会话，否则从编排器开始

• 当范围、行为或验证不明确时，让规划器在编码前解决模糊性

• 一般交付工作使用实现者，只有可复现的bug才使用调试器

• 完成的工作通过验证器路由

• 通过记忆策展人持久化持久教训，而不是随意记录