上一篇讨论了项目启动阶段如何给 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自主执行可以直接改变系统状态自动提交、执行、部署很多团队真正应该大量使用的其实是E1E3而不是一开始就追求 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 角色传统项目常用 RACIRResponsible执行AAccountable最终负责CConsulted协商IInformed知会。AI 加入以后可以增加一个角色XAI / Agent Execution。于是一个任务可能变成任务AI/AgentR 执行人A 责任人审核门禁用户故事初稿BA AgentBA产品负责人需求评审API 代码Dev Agent开发开发负责人PR Review单元测试Test Agent开发开发负责人CI架构分析Architect Agent架构师技术负责人架构评审项目周报PM AgentPM项目经理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需求、业务资料知识库分析、生成修改正式需求BAArchitect 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 可以承担越来越多执行工作但它本身不是项目责任主体最终确认、审核和交付责任仍然必须落到人。上一篇回顾【AI时代软件项目管理系列】5. 项目启动阶段如何给 AI 分任务从任务清单到 L0L5 参与度设计-CSDN博客下一篇AI 工具选型为什么也应该纳入项目启动范围当任务、人机分工、权限边界和责任机制都基本明确以后下一个问题自然变成到底应该用什么 AI通用大模型、AI 编程工具、RAG 知识库、Agent 平台和私有化模型解决的并不是同一种问题即使模型能力相近在数据策略、企业权限、审计能力、工具集成、成本和部署方式上也可能完全不同。因此下一篇将从项目管理而不是单纯“模型排行榜”的角度讨论AI 工具选型如何进入项目启动流程以及企业项目应该如何从能力、成本、安全、部署、稳定性和可替换性等方面进行评估。