多Agent虚拟开发：构造功能设想与开发方案（一）

1. 方案定位

传统软件开发依赖人类团队，成本高、周期长；现有“单体Agent”试图独立完成所有工作，但在复杂项目中面临上下文溢出、角色混淆、质量失控等问题。
本方案旨在构建一个模拟正规软件公司运作的多Agent协作系统，通过角色专业化、计划驱动、流水线协作、标准化工具接口及成本控制，实现软件项目的半自主开发与高质量交付。人类从执行者转为监督者，仅在关键节点介入。

核心原则：

• 角色各司其职（产品、架构、开发、测试、运维、项目管理）

• 多层计划树（Plan Tree）驱动，层级越深计划越精准

• 事件溯源保证状态可回溯、可审计

• MCP统一外部工具接口

• 模型能力评分与任务路由，动态角色转换，精细化成本控制

2. 总体架构

2.1 架构分层

2.2 架构图（Mermaid）

图表

3. 角色定义与职责

多Agent分工协作，才是更接近“软件公司正规军”的模式。在这种模式下，项目具备自治性、可扩展性，也更容易得到高质量产出。具体来说：

• 角色定义与职责分离：可以为不同Agent分配精确角色，如产品经理（写PRD）、架构师（设计技术方案）、开发（写代码）、测试（写并执行测试用例）、运维（部署）、项目经理（拆解任务、协调进度）。每个Agent专注自己的“岗位”，有自己的提示词、工具和知识库。

• 流程驱动，而非意志驱动：项目经理Agent根据PRD和技术方案，自动创建任务板（如ToDo、InProgress、Done）。开发Agent只认领“待开发”状态的具体任务；测试Agent只验证“待测试”的成果。流程明确、状态流转自动，就像Jira在后台运行。

• 明确的协作与沟通机制：Agent之间通过标准化的消息总线通信，如“需求变更通知”、“代码完成事件”、“测试报告”。开发Agent写完代码后，不直接交版本，而是通过“提交”事件触发测试Agent。需要人工决策时，才上升到“项目经理”或“用户确认”。

• 可落地的技术框架：AutoGen（微软）原生支持多Agent对话与协作，可定义GroupChat或Manager模式；LangGraph适合构建状态机驱动的流程；CrewAI则更接近于定义角色和任务流水线。当前完全可以基于这些框架搭建一个“虚拟软件公司”。

• 与现有开发流程深度融合：Agent的“代码提交”可以是一个真实的Git PR，“测试报告”可以驱动CI/CD流水线。它们调用的是现有的工单系统、代码仓库、容器平台——Agent在工作，流程在运转，人只需要监督例外情况。

模型分配：最终由任务路由器根据实际任务难度和成本策略动态选择，上表为默认推荐。

4. 计划树（Plan Tree）设计

4.1 层级定义

• L0：项目根目标（用户输入）

• L1：里程碑/史诗（一级PM产出）

• L2：用户故事/特性（二级PM产出）

• L3：原子任务（项目经理拆解），时长≤4小时，有明确验收标准

• L4+：可选，用于更细粒度子任务

项目主线角色架构树（多Agent虚拟软件公司）
│
├── 管理层（计划制定与拆解）
│ ├── 一级产品经理 Agent
│ │ ├── 产出：L1计划树（史诗/模块）
│ │ ├── 职责：产品路线图、里程碑、跨模块边界
│ │ └── 向下：将L1分解传递给二级PM + 将非功能约束给架构师
│ │
│ ├── 二级产品经理 Agent
│ │ ├── 产出：L2计划树（用户故事/特性）
│ │ ├── 职责：细化验收标准、子系统内依赖
│ │ └── 向下：将L2计划树传递给项目经理
│ │
│ └── 架构师 Agent
│ ├── 产出：技术方案文档（接口/数据库/非功能设计）
│ ├── 职责：保障可扩展性、性能、安全性
│ └── 向下：将技术约束传递给项目经理
│
├── 执行层（流水线工位）
│ ├── 项目经理 Agent
│ │ ├── 输入：L2计划树 + 技术方案
│ │ ├── 产出：L3原子任务（开发/测试/部署）
│ │ ├── 职责：维护计划树状态机、任务分发、依赖检测、阻塞上报
│ │ └── 向下：分发任务给开发/测试/运维Agent
│ │
│ ├── 开发 Agent
│ │ ├── 输入：L3开发任务（含验收标准）
│ │ ├── 产出：代码 + 单元测试
│ │ ├── 职责：实现功能、自检、提交代码事件
│ │ └── 触发：完成 → 通知测试Agent
│ │
│ ├── 测试 Agent
│ │ ├── 输入：L3测试任务 / 代码提交事件
│ │ ├── 产出：测试报告（通过/缺陷）
│ │ ├── 职责：功能测试、集成测试、回归测试
│ │ └── 触发：测试通过 → 通知项目经理；发现缺陷 → 返回开发
│ │
│ └── 运维 Agent
│ ├── 输入：L3部署任务
│ ├── 产出：部署环境 + 健康检查报告
│ ├── 职责：配置CI/CD、部署到环境、冒烟测试
│ └── 触发：部署完成 → 通知项目经理
│
└── 监督与决策层
└── 人类管理者
├── 输入：里程碑计划（来自一级PM）、用户故事（来自二级PM）、阻塞告警（来自项目经理）
├── 决策：审批计划树、处理无法自动解决的异常、最终发布审批
└── 例外介入：仅当Agent上报或定期评审时

4.2 节点数据结构（JSON）

json

{ "id": "T-123", "parent_id": "T-12", "level": 3, "title": "实现订单校验逻辑", "type": "development", "status": "todo", "assignee_role": "developer", "assignee_instance": "dev-agent-01", "acceptance_criteria": ["库存>0可创建", "金额计算正确"], "dependencies": ["T-122"], "difficulty": 6, "estimate_hours": 2, "cost_budget_cents": 50, "created_at": "2026-05-25T10:00:00Z", "updated_at": "...", "artifacts": ["commit_hash", "test_report_id"] }

4.3 状态机与事件流转

todo → in_progress → review → done → closed ↓ ↓ blocked rework

每次状态变更生成不可变事件，写入事件存储。

5. Skill系统设计

在虚拟化软件公司的多Agent架构中，Skill（技能）扮演着“可复用的能力单元”角色。它类似于生产线上的专用工具或机器臂——Agent是工位上的操作工，而Skill是工位配备的扳手、焊枪或视觉检测仪。每个Agent可以拥有多个Skill，用于完成其职责范围内的具体操作。

Skill的核心作用

1. 职责内聚，避免重复造轮子
   将通用的能力（如生成单元测试、解析JSON计划树、调用Git API）封装为Skill，供同类型Agent共享。例如所有开发Agent共用同一个“代码生成Skill”，所有测试Agent共用“测试用例生成Skill”。

2. 降低Agent的认知负担
   Agent的提示词只需描述“用什么Skill完成什么任务”，而不必详细书写实现步骤。Skill内部可以包含更复杂的逻辑、工具调用或子模型。

3. 便于升级与替换
   某个Skill（如“代码审查”）可以独立迭代，升级后所有调用它的Agent自动获得增强能力，无需修改Agent角色定义。

4. 精细控制成本与性能
   不同Skill可调用不同模型（如快速小模型用于语法检查，强大慢模型用于复杂代码生成），也可缓存结果，减少API调用。

5.1 Skill定义

Skill是Agent可调用的原子能力单元，封装具体执行逻辑（调用LLM、执行命令、访问MCP工具等）。每个Agent拥有一个或多个Skill。

5.2 核心Skill清单

5.3 Skill调用流程

1. Agent接收任务 → 2. 选择Skill序列 → 3. Skill通过MCP获取上下文 → 4. 执行并返回结果 → 5. Agent封装事件

6. MCP（模型上下文协议）集成

6.1 作用

MCP作为标准化工具接口，使Agent以统一方式访问外部系统（代码仓库、数据库、Jira、云API等），解耦工具实现与Agent逻辑。

6.2 典型MCP服务器

6.3 与Skill的关系

• Skill是执行策略，可调用一个或多个MCP工具。

• MCP是能力接口，提供原子操作（如git_commit）。

• 示例：deployment_skill调用k8s_mcp.apply_manifest和ci_mcp.trigger_build。

7. 模型治理：入库打分与动态路由

7.1 模型能力评估维度

每个模型入库记录：

json

{ "model_id": "gpt-4-turbo", "capabilities": { "code_gen": 9, "plan_decomp": 8, ... }, "cost_per_mt": 10.0, "recommended_tasks": ["architecture", "complex_refactor"], "fallback_models": ["gpt-3.5-turbo"] }

7.2 动态评分与淘汰

• 静态基线：定期运行标准测试集更新能力分。

• 动态反馈：任务完成后由下游Agent或人类对产出质量打分（1-5），加权更新能力分。

• 淘汰：连续低分模型自动降权，移出高价值任务候选集。

7.3 任务路由策略

项目经理中的任务路由器根据任务类型、难度、预算选择最优模型：

python

def select_model(task): candidates = model_db.query(capabilities[task.type] >= task.difficulty) candidates = filter(cost_per_mt <= task.budget) return sorted(candidates, key=lambda m: m.cost_per_mt)[0]

8. Agent快速角色转换

8.1 需求场景

• 负载均衡：测试任务堆积时，将空闲开发Agent临时转换为测试Agent。

• 成本优化：非紧急规划任务，将一级PM Agent转换为二级PM使用更便宜模型。

• 容错：某角色Agent崩溃，其他角色Agent填补。

8.2 设计要点

• 角色上下文分离：每个Agent实例只是一个容器，其提示词、Skill集、MCP权限、模型绑定均为可热插拔配置。

• 角色模板库：预置所有角色的标准配置（prompt模板、skill列表、权限表），存于数据库。

• 角色转换管理器：根据任务队列长度和成本策略，动态决策转换。

8.3 转换流程

1. 转换管理器向Agent发送切换请求（from dev to test）

2. Agent保存当前未完成任务状态及上下文

3. Agent从配置库加载新角色配置

4. Agent重新初始化（清空旧记忆，载入角色专属记忆）

5. 就绪后接收新任务

8.4 成本权衡

• 短期切换（<1小时）：保留原模型实例，仅换prompt → 低成本

• 长期切换：卸载原模型，加载目标模型（可能涉及模型加载延迟5-10秒）

• 混合模式：保留通用模型池，角色仅绑定模型实例

9. 存储与事件系统

9.1 设计目标

• 记录所有状态变更与Agent动作（审计、重放、调试）

• 支持项目快照与回滚

• 产物持久化

9.2 存储组件

9.3 事件格式

json

{ "event_id": 1001, "event_type": "task_status_changed", "task_id": "T-123", "from_status": "todo", "to_status": "in_progress", "agent": "project_manager", "timestamp": "2026-05-25T10:05:00Z" }

9.4 回滚机制

• 基于事件序号回滚：指定事件点，删除后续事件，从最近快照重放至目标点。

• 支持分支回滚：保留主分支，创建恢复分支用于试错。

10. 成本控制综合策略

10.1 精细化成本核算

• 每个任务记录：调用模型、token数、执行时间、质量评分。

• 实时成本看板展示项目累计API费用、各角色消耗占比。

10.2 分层模型路由（核心省钱机制）

10.3 缓存与复用

• 语义缓存：常见查询（如项目规范）使用向量数据库缓存，避免重复LLM调用。

• 计划树片段复用：相似功能（如CRUD接口）的L3模板直接参数化复用。

• Skill结果缓存：相同输入短时间内返回缓存结果。

10.4 早期停止与超时

• 每次LLM调用设置最大token限制（如2048），超出则截断并告警。

• 循环检测：连续重试3次仍未通过验证则升级给人类。

10.5 混合使用开源模型（私有化部署）

• 本地部署Llama-3-70B、Qwen-72B用于代码生成、测试用例生成等重复性任务。

• 成本约为商业API的5-10%。

11. 协作工作流（端到端示例）

以“开发用户登录功能”为例：

1. 人类输入：“实现基于JWT的用户登录”

2. 一级PM：产出L1节点“认证模块”

3. 二级PM：产出L2故事“用户可使用邮箱+密码登录获取token”

4. 架构师：产出接口设计（POST /auth/login）、JWT配置

5. 项目经理：拆解L3任务：T1定义数据库schema，T2实现login API，T3编写测试用例，T4部署验证

6. 任务路由器：为T1选择Llama-3-70B（低难度），T2选择GPT-4-Turbo（中等难度）

7. 开发Agent：实现代码并提交Git

8. 测试Agent：执行测试，通过后通知项目经理

9. 运维Agent：部署到测试环境

10. 项目经理：标记任务完成，上报人类验收

12. 技术栈建议

AutoGen（微软）原生支持多Agent对话与协作，可定义GroupChat或Manager模式；LangGraph适合构建状态机驱动的流程；CrewAI则更接近于定义角色和任务流水线。

13. 实施路线图

阶段一：MVP（2周）

• 核心4角色：一级PM、项目经理、开发、测试

• 计划树存储（PostgreSQL），状态机基础流转

• 完成一个极简功能（如用户登录）端到端流程

• 人工介入所有阻塞

阶段二：扩展角色（1个月）

• 增加二级PM、架构师、运维Agent

• 集成Git MCP和Database MCP

• 实现阻塞检测与自动上报

阶段三：模型治理与成本控制（2个月）

• 建立模型能力库与任务路由器

• 实现分层路由、语义缓存

• 接入本地开源模型

阶段四：高级特性（持续）

• Agent角色动态转换

• 事件溯源与回滚Web界面

• 多项目并行调度

• 模型微调优化

14. 风险与对策

15. 总结

本方案构建了一个完整的多Agent虚拟软件开发公司，涵盖：

• 角色专业化：7类Agent各司其职

• 计划驱动：多层计划树保证精准执行

• 能力复用：Skill + MCP标准化工具接口

• 模型治理：入库打分+动态路由，适配任务与成本

• 灵活运营：Agent角色动态转换

• 可靠持久：事件溯源+快照回滚

• 经济可行：分层模型+缓存+开源模型，成本可控制在传统团队的10%以内