上一篇讨论了项目启动阶段如何给 AI 分任务：重复、标准化工作可以让 AI 多做，可生成、可验证的工作可以采用“AI 生成 + 人确认”，复杂判断仍由人主导，责任决策则继续由人承担。
但当任务真的交给 AI，特别是从普通聊天工具进一步发展到能够访问代码、调用工具和执行操作的 Agent 后，一个更现实的问题随之出现：AI 可以参与，但到底可以参与到哪一步？
例如 Dev Agent 可以读取整个代码仓库吗？能不能直接修改主分支？可以连接测试数据库吗？发现一个权限问题以后，能不能自己修改数据库？PM Agent 可以自动创建项目任务，那么能不能直接调整里程碑？AI 生成的代码通过测试以后，能不能自动发布？这些问题已经不是“模型能力”问题，而是项目治理问题。
对于正式的软件项目来说，成熟的人机协作并不是简单地给 Agent 更多权限，而是让每一种 AI 能力都运行在明确的边界内：能看什么、能做什么、做到哪一步、谁来确认、出了问题谁负责。
一、AI 的能力越强，越不能只靠“大家注意安全”
AI 作为个人助手时，风险相对有限。例如用 AI 整理会议纪要、解释一段代码或者润色文档，主要风险集中在输入信息和输出质量上。但当 AI 进一步获得工具调用能力后，情况就不同了。一个 Dev Agent 可能具备：读取代码+搜索项目知识库+修改文件+执行构建+运行测试+调用 Git+操作 Issue+调用业务 API。如果再进一步连接数据库、部署平台或生产环境，它就不只是“生成建议”，而是在对真实项目产生状态变化。因此，可以把 AI 的参与大致区分为两类：1.生成型 AI➜产生建议 / 文档 / 代码➜结果不自动生效和2.执行型 Agent➜调用工具 / 修改数据 / 改变系统状态➜可能直接影响项目。两者需要的管理机制完全不同。普通 AI 最重要的是输入和输出边界，Agent 还必须增加工具、权限和执行边界。所以，项目启动阶段不能只形成一句：“允许团队使用 AI。”而应该进一步明确：允许哪一种 AI，在什么范围内，以什么权限参与哪些任务。
二、第一条边界：AI 能“看到”什么
AI 要完成任务，需要上下文。但上下文越完整，并不意味着所有项目资料都应该无条件交给模型。一个软件项目可能同时存在：
- 需求规格说明书；
- 架构设计；
- 源代码；
- 数据库结构；
- 测试数据；
- 客户业务资料；
- 项目合同；
- 生产日志；
- 用户个人信息；
- Access Key、Token、密码等敏感凭证。
因此，第一个需要明确的是数据与上下文边界。可以按照项目资料的敏感程度进行简单分级：
| 资料类型 | AI 使用策略 |
| 公开技术资料 | 可直接使用 |
| 通用项目模板 | 可直接使用 |
| 项目需求、设计 | 授权 AI 使用 |
| 内部源代码 | 限定企业批准工具 |
| 测试数据 | 脱敏后使用 |
| 客户业务数据 | 严格授权 |
| 生产日志 | 脱敏、过滤后使用 |
| 用户隐私信息 | 默认限制 |
| 密钥、密码、Token | 禁止进入模型上下文 |
| 涉密资料 | 按安全要求限制或禁止 |
这里真正需要控制的不是“AI 有没有读取能力”，而是：当前任务是否真的需要这些信息。例如，一个 Doc Agent 生成用户手册，只需要产品功能、页面说明和操作流程，并没有必要访问数据库。一个 Test Agent 生成接口测试，需要接口定义和测试数据，却不应该因此自动获得生产数据库权限。因此，AI 的上下文最好遵循一个很重要的原则：按任务提供最小必要上下文，而不是为了让 AI 更聪明，把整个项目都交给它。
这四层可以贯穿整个项目：数据决定 AI 能看到哪里，工具决定能触达到哪里，权限决定能执行到哪里，审核决定结果能不能正式生效。
三、第二条边界：Agent 能调用哪些工具
Agent 与普通 AI 最大的区别之一，是它能够使用工具。工具本身没有问题，真正的风险在于：一个 Agent 获得了多少工具，以及这些工具拥有什么权限。例如一个 Dev Agent 可能连接：Git Repository、Issue 系统、代码搜索、构建工具、测试工具、数据库、CI/CD、服务器 Shell。如果全部开放，Agent 理论上就可能完成：修改代码➜提交代码➜修改数据库➜触发构建➜部署应用。这虽然接近“自动开发”，但也意味着单个 Agent 拥有了一条完整的高风险执行链。更合理的做法是按照角色配置工具。例如：
| Agent | 建议开放 | 不应默认开放 |
| BA Agent | 需求库、知识库、项目文档 | 代码提交、数据库修改 |
| Architect Agent | 代码只读、设计库、技术资料 | 生产环境 |
| Dev Agent | 开发分支、构建、测试 | 生产数据库 |
| Test Agent | 测试环境、测试数据、Issue | 生产部署 |
| PM Agent | 项目任务、进度、风险数据 | 代码库写权限 |
| Doc Agent | 产品文档、交付资料 | 数据库和生产系统 |
这里的核心仍然是：Agent 应该获得完成当前职责所需的工具，而不是获得项目里所有可用工具。这和传统 RBAC 权限设计其实非常类似。只是过去授权对象主要是：
用户 → 角色 → 权限
AI Agent 加入以后需要扩展为：
人 + Agent ↓ 角色 ↓ 工具权限 ↓ 资源范围 ↓ 允许操作
四、第三条边界：能调用工具，不代表可以直接执行
工具权限还需要继续细分。因为“读取 Git 仓库”和“向主分支提交代码”，风险完全不同；“查询数据库”和“执行 DELETE”，也不能使用相同权限。因此，对 Agent 最实用的控制方式，是按照操作风险继续划分执行等级。可以设计成四级：
| 等级 | Agent 能力 | 典型操作 |
| E1：只读 | 获取和分析信息 | 查文档、查代码、查日志 |
| E2：生成 | 产生候选结果 | 生成代码、SQL、方案 |
| E3：受控修改 | 可以修改，但需要确认 | 修改代码、创建任务 |
| E4：自主执行 | 可以直接改变系统状态 | 自动提交、执行、部署 |
很多团队真正应该大量使用的，其实是 E1～E3，而不是一开始就追求 E4。例如 Dev Agent：
读取代码 E1 ↓ 生成修改方案 E2 ↓ 修改工作分支 E3 ↓ 自动运行测试 E3 ↓ 创建 Pull Request E3 ↓ 人工 Review ↓ 合并主分支 人负责
这样已经能够节省大量开发工作，但仍然把关键状态变化控制在人手里。所以需要区分：Agent 可以执行任务和Agent 可以自主决定任务结果生效这是完全不同的两件事。
五、真正关键的是“不可逆操作”
AI 边界设计不需要把每一个工具调用都审批，否则 Agent 很快退化成一个操作极其繁琐的助手。真正值得设置人工门禁的，是高影响或不可逆操作。例如：
- 删除数据；
- 修改生产数据库；
- 合并主分支；
- 发布生产版本；
- 修改权限模型；
- 调整项目范围；
- 修改项目里程碑；
- 给客户发送正式结论；
- 批量通知用户；
- 执行资金或合同相关操作。
可以采用一个很简单的判断：
低影响 + 可回退 ↓ 允许 Agent 自动执行 高影响 / 难回退 ↓ 必须人工确认
这样项目治理不会因为 AI 而变得过于繁琐，又能守住真正重要的控制点。
六、第四条边界：AI 生成物什么时候才算“项目成果”
这是软件项目中非常容易混淆的一点。AI 生成了一份需求文档，并不代表需求已经确定；Dev Agent 写完代码，并不代表开发完成；Test Agent 执行完测试，也不代表质量已经达到标准；PM Agent 给出“项目风险较低”，更不代表项目经理可以取消风险跟踪。应该建立非常明确的关系：AI Output➜候选成果➜验证 / Review➜人工确认➜正式项目成果➜进入项目基线。也就是说：AI 产出默认是候选结果，而不是项目基线。只有经过项目规定的审核、测试或审批以后，才能成为正式成果。这一点尤其重要，因为 Agent 越自动化，产生内容的速度越快。如果缺少基线机制，项目很容易同时存在大量：
- AI 初稿；
- 人工修改稿；
- Agent 新版本；
- 测试版本；
- 未确认方案。
最终反而不知道哪一个才是正式版本。AI 生成内容必须进入统一项目基线，本身也是人机混合项目保持整体一致性的关键。
七、责任机制不能只写一句“人工负责”
明确“最终责任由人承担”只是第一步。系列本身也明确要求 AI 可以建议、生成和辅助，但最终责任必须由人承担。真正落到项目中，还需要继续回答：到底由哪个人负责？例如：
这种设计有两个价值。第一，避免出现：“这段代码是 AI 写的，所以没人负责”；第二，也避免另一种极端：“所有 AI 结果都由项目经理负责”。项目经理负责整个项目治理，并不意味着他需要承担每个专业成果的技术责任。更合理的是：AI 的专业输出，仍然回到对应的人工专业责任链。已有角色设计中也采用了相同结构：PM Agent 对应项目经理、BA Agent 对应业务分析师、Architect Agent 对应架构师、Dev Agent 对应开发负责人、Test Agent 对应测试负责人。
八、可以借用 RACI，但增加一个 AI 角色
传统项目常用 RACI：
- R：Responsible，执行；
- A：Accountable，最终负责；
- C：Consulted，协商；
- I：Informed，知会。
AI 加入以后，可以增加一个角色：X：AI / Agent Execution。于是一个任务可能变成：
| 任务 | AI/Agent | R 执行人 | A 责任人 | 审核门禁 |
| 用户故事初稿 | BA Agent | BA | 产品负责人 | 需求评审 |
| API 代码 | Dev Agent | 开发 | 开发负责人 | PR Review |
| 单元测试 | Test Agent | 开发 | 开发负责人 | CI |
| 架构分析 | Architect Agent | 架构师 | 技术负责人 | 架构评审 |
| 项目周报 | PM Agent | PM | 项目经理 | PM 确认 |
| 上线部署 | Ops Agent 辅助 | 运维 | 发布负责人 | 上线审批 |
这里要强调：AI 可以成为执行角色，但不进入最终责任角色 A。这比单纯写“人工最终负责”更加容易落地。
AI 参与项目的责任闭环
编辑
这个闭环的重点不是“每一步都人工审批”，而是让AI 执行、自动验证、人工责任和项目基线形成完整链路。
九、以“离职成员文件交接”为例，看看边界如何落地
以企业云文档系统中的“离职成员文件交接”为例。需求看起来并不复杂：员工离职后，将其拥有的企业文件交接给指定成员，并取消原账号访问权限。如果让 Agent 自动开发，它首先可能需要：
- 阅读组织架构代码；
- 阅读用户与部门模型；
- 查询文件 Owner 关系；
- 查看权限继承逻辑；
- 修改交接服务；
- 生成迁移 SQL；
- 编写测试；
- 执行测试数据迁移。
如果只告诉 Agent：“完成离职文件交接功能。”权限很容易过大。更合理的边界可以设计成下面这样。
数据边界
Agent 可以读取：用户模型、组织关系、文件权限设计、相关代码、脱敏测试数据。但不能读取：真实客户文件内容、生产成员个人信息、密钥和数据库密码。
工具边界
Dev Agent 可以：读取代码仓库、修改开发分支、执行 Maven / Gradle、运行测试、读取测试数据库。不能：连接生产数据库、直接修改正式环境、执行生产部署
执行边界
Agent 可以自动：修改代码、生成迁移脚本、生成单元测试、执行测试、创建 Pull Request。但：数据库迁移脚本不能因为测试通过就自动进入生产。
输出边界
最终流程应该是：Dev Agent➜代码 + SQL➜自动测试➜开发 Review➜权限场景测试➜数据库变更审核➜人工批准➜发布。
这里 AI 已经承担了大量开发工作，但真正高风险的节点仍然被保留下来。这就是“AI 参与”与“AI 失控”之间最重要的区别。
十、项目启动阶段最好形成一张 AI 权限与责任矩阵
这篇文章最终可以落到一个项目经理能够直接使用的模板。
| Agent | 数据范围 | 工具 | 允许操作 | 禁止操作 | 人工责任人 |
| BA Agent | 需求、业务资料 | 知识库 | 分析、生成 | 修改正式需求 | BA |
| Architect Agent | 设计、代码只读 | Repo、知识库 | 分析、方案 | 修改生产配置 | 架构师 |
| Dev Agent | 代码、测试数据 | Repo、Build、Test | 修改分支、测试 | 生产部署 | 开发负责人 |
| Test Agent | 需求、测试环境 | Test、Issue | 执行测试 | 修改生产数据 | 测试负责人 |
| PM Agent | 计划、任务、风险 | PM 系统 | 汇总、建议 | 自动改变范围 | 项目经理 |
| Ops Agent | 部署资料、监控 | CI/CD、监控 | 检查、建议 | 未授权生产操作 | 运维负责人 |
这张表真正解决了六个问题：谁➜可以看什么➜可以调用什么➜可以执行什么➜什么不能做➜最终谁负责。只要这六件事情清楚，很多所谓“AI 治理”问题其实就已经有了基础。
十一、边界不是越严越好，而应该与风险匹配
AI 治理很容易走向两个极端。一个极端是：Agent 什么都可以做，结果是风险不可控。另一个极端是：Agent 每做一步都必须人工确认，结果是自动化价值几乎消失。更合理的方式应该是：
Agent 执行策略 │ ┌─────────┴─────────┐ │ │ 低风险任务 高风险任务 │ │ 可验证 难验证 │ │ 可回退 不可逆 │ │ ▼ ▼ 提高自主执行程度 收紧执行权限 │ │ 自动执行 / 自动验证 人工确认 / 审批门禁 自动提交候选结果 审计留痕 / 人工负责
风险越低、验证越容易、回退能力越强，Agent 可以获得越高的自主权；风险越高、结果越难验证、操作越不可逆，越需要收紧权限并增加人工门禁。
所以 AI 边界本质上不是限制 AI，而是在设计一条：自动化效率与项目风险之间的平衡线。Agent 的执行能力越强，这条线越重要。
十二、结语：真正成熟的 AI 项目，不是 Agent 权限最大，而是边界最清楚
从前面的几篇文章可以看到，项目启动阶段正在多出一套过去没有的管理动作。先判断项目是否具备 AI 可行性，再确定哪些任务交给 AI；任务确定以后，还要继续明确 AI 的数据、工具、执行和输出边界，并把每一项 AI 工作重新接回人工责任链。因此，一个真正可控的 AI 项目应该形成这样的逻辑：任务➜AI / Agent➜最小必要数据➜最小必要工具➜受控执行权限➜自动验证➜人工责任人➜项目基线。项目经理不需要审核 Agent 的每一次思考，也不应该管理每一次模型调用。真正应该管理的是那些会影响项目结果的关键边界：AI 能看到哪里、能操作到哪里、什么结果可以正式生效，以及最终谁承担责任。所以，AI 项目治理的目标并不是：让 Agent 什么都不能做。也不是：让 Agent 什么都可以做。而是：让 AI 在明确边界内尽可能高效地执行，同时让关键决策、质量和最终责任始终有人承担。AI Agent 可以承担越来越多执行工作，但它本身不是项目责任主体；最终确认、审核和交付责任仍然必须落到人。
上一篇回顾：
https://developer.aliyun.com/article/1757646?spm=a2c6h.13148508.setting.16.14634f0e6HvtUA
下一篇：AI 工具选型为什么也应该纳入项目启动范围？
当任务、人机分工、权限边界和责任机制都基本明确以后，下一个问题自然变成：到底应该用什么 AI？通用大模型、AI 编程工具、RAG 知识库、Agent 平台和私有化模型解决的并不是同一种问题；即使模型能力相近，在数据策略、企业权限、审计能力、工具集成、成本和部署方式上也可能完全不同。
因此，下一篇将从项目管理而不是单纯“模型排行榜”的角度讨论：AI 工具选型如何进入项目启动流程，以及企业项目应该如何从能力、成本、安全、部署、稳定性和可替换性等方面进行评估。
