引言：当 AI 不再只是坐在工具栏里
在上一篇文章中，我们讨论了 AI 正在改变需求、设计、开发、测试和项目协同，而不只是提高代码生成速度。当 AI 的能力继续向任务规划、工具调用、代码执行和结果验证延伸，一个更深层的变化开始出现：AI 不再只是项目成员使用的工具，而是逐渐成为项目流程中的参与者。
早期的 AI 更像一个随叫随到的助手，能够回答问题、生成内容，却不会持续跟踪任务；今天的 AI Agent 已经可以读取项目资料、调用开发工具、修改代码、运行测试并提交结果；当多个专业 Agent 被编排进需求、开发、测试和交付流程后，团队又开始接近一种新的形态——软件工厂。
这里所说的“数字员工”是一种组织和工作方式上的比喻。AI 可以承担部分任务，却不是法律意义上的员工，也不能成为项目责任主体。真正发生变化的，是人与 AI 之间的工作分工，以及项目经理管理任务、质量和责任的方式。
一、AI 助手：提高个人效率，但没有改变团队结构
AI 最早进入软件项目团队时，主要扮演个人助手的角色。
需求人员让 AI 整理会议纪要，架构师让 AI 比较技术方案，开发人员让 AI 补全代码，测试人员让 AI 生成测试用例，项目经理则用 AI 编写周报、提炼风险和整理任务清单。
在这个阶段，典型的工作方式仍然是：
人提出问题
↓
AI 生成建议或内容
↓
人判断、修改并继续执行
AI 提高了单个动作的效率，却没有真正取得任务的执行权。它通常只理解当前对话中的局部上下文，不持续维护任务状态，也不会主动进入代码仓库、测试环境或项目管理系统完成后续工作。
因此，项目团队的基本结构并没有发生变化。AI 仍然附着在某个成员身上，项目经理管理的主要对象依旧是人员、任务和交付物。
这一阶段的核心价值是辅助生成，主要风险则是内容看起来完整，却可能存在事实错误、上下文遗漏和业务理解偏差。
二、AI Agent：从回答问题转向完成任务
AI Agent 与普通助手的区别，不只是回答得更准确，而是具备了更完整的任务执行循环。
一个编码 Agent 接收到任务后，可以分析代码仓库、制定执行计划、修改文件、调用构建工具、运行测试、检查错误并提交代码变更。当执行结果不符合要求时，它还可以根据测试结果或人工反馈继续修正。
目前，多种编码 Agent 已经支持从任务或 Issue 出发，在隔离环境中修改代码并创建 Pull Request；OpenAI Codex 可以在云端并行处理多个软件工程任务，Google Jules 可以克隆仓库、安装依赖、修改代码、运行测试并提交变更，GitHub Copilot 的云端 Agent 也已进入从 Issue 到 Pull Request 的开发流程。
其工作模式更接近：
人定义目标与验收标准
↓
Agent 获取项目上下文
↓
制定计划并调用工具
↓
执行任务、检查结果
↓
提交可评审的成果
↓
人审核、反馈或批准
AI 在项目团队中的角色演进
从项目管理的角度看，AI Agent 已经不再只是生产资料的工具，而是获得了有限的任务执行能力。不过，这种能力必须建立在四个条件之上：任务目标明确、项目上下文充分、工具权限受控、输出结果可以验证。
Agent 可以承担任务执行责任，但不能承担项目交付责任。代码是否合并、方案是否采纳、需求是否确认、系统是否上线，仍然需要由相应的人工负责人决定。
三、软件工厂：从单个 Agent 走向生产系统
当多个 Agent 分别承担需求分析、架构设计、代码开发、测试验证和文档整理工作时，项目团队开始出现类似软件工厂的形态。
在这种模式下，一个复杂任务不会全部交给同一个 Agent，而是由不同角色协同完成：
| Agent 角色 | 主要工作 | 人工责任人 |
|---|---|---|
| BA Agent | 整理需求、识别业务规则、生成验收标准 | 产品经理或业务分析师 |
| Architect Agent | 分析系统影响、生成设计草案、提示技术风险 | 架构师 |
| Dev Agent | 修改代码、补充单元测试、执行构建 | 开发负责人 |
| Test Agent | 生成测试场景、执行测试、分析失败原因 | 测试负责人 |
| Doc Agent | 更新接口文档、部署说明和用户手册 | 交付负责人 |
| PM Agent | 汇总状态、识别阻塞、生成风险和进度报告 | 项目经理 |
到 2026 年，部分工程工具已经出现这种多角色协作特征。GitHub 支持为不同专业任务配置具有独立提示词、工具和 MCP 服务的自定义 Agent，并由主 Agent 将子任务委派给拥有独立上下文的子 Agent；Google Jules 也引入了负责审查执行计划的 Planning Critic，并能够在 CI 失败后自动分析、修复和重新提交代码。
这些能力可以被视为软件工厂的局部雏形，但“多个 Agent 同时工作”并不等于真正的软件工厂。一个可控的软件工厂至少需要具备：
- 统一的需求、代码和设计基线；
- 清晰的 Agent 角色与工具权限；
- 标准化的任务输入、输出和验收条件；
- 可观察、可暂停、可回退的执行流程；
- 自动化测试、安全扫描和质量门禁；
- 明确的人工审核节点和责任人。
缺少这些基础条件，多 Agent 不仅不会减少项目管理工作，反而可能造成上下文不一致、重复修改、错误传递和任务冲突。
四、一个需求在三种模式下如何完成
以云文档系统新增“文件夹权限继承与打断继承”功能为例，同一个需求在不同阶段中的执行方式存在明显差异。
AI 助手模式
需求人员将业务描述发给 AI，由 AI 整理需求条目、输出权限模型草案；开发人员再让 AI 生成部分接口代码和 SQL；测试人员使用 AI 补充测试用例。
AI 参与了多个环节，但每一次调用都由人发起，环节之间的上下文需要人工传递，最终任务仍由团队成员逐步完成。
AI Agent 模式
开发负责人向编码 Agent 提交一个结构化任务，附带需求文档、代码仓库、开发规范和验收标准。Agent 分析现有权限模型，修改接口与数据结构，补充单元测试，运行构建并创建 Pull Request。
人工负责人主要负责审查方案、代码和测试结果，而不是亲自完成每一步修改。
软件工厂模式
需求进入项目任务系统后，BA Agent 首先整理业务规则和验收标准，Architect Agent 分析权限计算链路，Dev Agent 完成代码实现，Test Agent 生成并执行测试，Doc Agent 更新接口和使用文档，PM Agent 汇总任务状态和风险。
每个阶段都通过结构化交付物连接，并设置人工质量门禁。
软件工厂中的任务流转
这三种模式并不是简单的产品版本差异，而是三种不同的人机分工关系：助手提高个人动作效率，Agent 承担相对完整的任务，软件工厂则把多个 Agent 纳入统一生产流程。
五、角色演进之后，项目管理对象发生了什么变化
1. 团队不再只是人员名单，而是能力组合
传统资源计划主要统计产品、开发、测试和运维人员。AI 深度参与后，模型能力、Agent 数量、工具账号、上下文窗口、知识库、运行环境和调用额度，也开始成为项目资源。
项目经理需要知道的不只是“有几名开发人员”，还包括哪些任务可以交给 Agent、Agent 可以访问哪些系统、并发执行能力如何，以及失败后由谁接管。
2. 任务分配需要升级为任务契约
给人分配任务时，很多背景可以通过经验和沟通补充；Agent 缺少隐含的组织经验，因此任务必须更加结构化。
一张适合 Agent 的任务卡，需要明确任务目标、输入资料、约束条件、允许使用的工具、预期输出、验收标准、禁止操作和人工审核人。任务描述越模糊，Agent 自主执行带来的偏差越大。
3. 进度管理从百分比转向可验证状态
Agent 可以快速生成大量代码和文档，但“已经生成”不能等同于“已经完成”。
项目进度应当建立在可验证证据上，例如代码是否提交、构建是否成功、测试是否通过、安全扫描是否完成、文档是否更新、人工审核是否结束，而不是只统计 Agent 已经运行了多少时间或生成了多少内容。
4. 质量管理从结果检查转向过程门禁
AI 的生产速度越快，错误也可能越快进入后续环节。如果需求理解出现偏差，后续的设计、代码和测试都可能围绕错误前提继续扩展。
因此，质量检查必须分布在需求确认、方案审核、代码审查、自动化测试和业务验收等多个节点。任何 AI 生成物都需要检查正确性、完整性、一致性、可执行性和可追责性。
5. 执行可以交给 AI，责任不能交给 AI
项目失败后，不能把原因简单归结为“Agent 生成错了”。
业务负责人仍然需要确认需求，架构师仍然需要批准设计，开发负责人仍然需要对合入代码负责，测试负责人仍然需要确认质量，项目经理仍然需要保证交付过程受控。
AI 可以成为任务执行者，却不能成为责任承担者，这是人机协同项目团队最重要的边界。
六、不是所有团队都需要立即进入软件工厂
AI 的角色演进并不意味着所有项目都应该直接采用多 Agent 模式。
对于文档整理、代码模板、测试用例初稿等标准化程度较高的工作，AI 助手已经能够带来明显价值；对于边界清晰、自动化测试完善的开发任务，可以逐步引入 Agent；只有当项目具备稳定的工程规范、结构化知识、自动化流水线和完整质量门禁后，才适合探索软件工厂。
本系列将 AI 参与度划分为从 L0 不使用 AI，到 L1 个人辅助、L2 任务辅助、L3 流程参与、L4 Agent 协同和 L5 软件工厂。L5 目前仍主要处于探索阶段，尤其是复杂业务、定制交付和强合规项目，仍然需要人主导关键决策与最终验收。
因此，合理的升级路径通常是：
先规范个人使用
↓
再选择标准任务交给 Agent
↓
建立任务卡与质量门禁
↓
引入专业 Agent 分工
↓
逐步形成可观察、可回退的软件生产流程
如果团队连需求基线、代码规范和测试流程都没有建立，就直接引入多 Agent，只会把原有的管理问题自动化和规模化。
七、项目团队真正发生的变化
从 AI 助手到 Agent，再到软件工厂，变化的不是一个更有吸引力的产品名称，而是 AI 在项目中的参与深度。
AI 助手改变的是个人工作效率，AI Agent 改变的是任务执行方式，软件工厂改变的则是项目生产组织方式。随着 AI 获得更多执行能力，人类成员的价值也会从亲自完成每一个操作，逐步转向理解业务、定义任务、设计规则、审核成果、处理异常和承担责任。
这意味着未来的软件项目团队不会简单变成“更少的人加更多的 AI”，而会逐渐形成一种新的协作结构：
人负责目标、决策、判断和责任，Agent 负责执行、分析、生成和反馈，项目流程负责连接二者并保证结果可控。
AI 不会直接管理项目。AI 被嵌入项目流程，而人必须持续定义目标、边界、标准和责任。
上一篇回顾：
【AI时代软件项目管理系列】1. AI 正在改变软件研发项目管理，而不只是改变写代码 - 文章 - 开发者社区 - 火山引擎
下一篇将进一步讨论：
当项目团队中真正出现了人和 AI Agent 的混合协作，项目经理的职责、能力模型和管理方式将发生哪些变化。
— 持续更新 · 欢迎关注 —