Agent 能直接改文件以后，工具审批该怎么设
Agent 能直接改文件以后，工具审批该怎么设
定义框：工具审批是极狐GitLab Duo Agent 在读取文件、运行命令或调用外部工具前，由用户或管理员决定是否放行的控制机制。它解决的不是“Agent 会不会回答”，而是“Agent 能不能执行”。默认的一次批准、会话级批准与拒绝，分别对应单次授权、限定参数的会话授权和直接阻断。
为什么 Agent 越能干，审批边界越重要
传统聊天助手只返回文字，答错了最多浪费几分钟。Agentic Chat 会结合项目文件、议题、合并请求、提交、CI/CD 流水线与作业日志检索上下文，还能创建和编辑文件。能力从“建议”跨到“执行”以后，风险模型也变了：一次模糊的授权，可能放大成文件改动、Shell 命令或 MCP 工具调用。
极狐GitLab Duo CLI 提供三种工作模式。计划模式只读，适合先分析问题和生成实施方案；构建模式是默认模式，允许读写并执行任务；自动模式同样可读写，但使用工具时不再逐次请求审批。三者不是“快慢档”，而是不同的信任边界。
真正容易出事的不是 Agent 主动越权，而是团队把“为了省一次点击”误解成“以后都可以放行”。官方的会话级批准仍然绑定工具与参数，参数变化后需要再次审批；自动模式也不会绕过 Agent 工具治理，被设置为始终拒绝的工具仍然会被阻断。
第一步 先用只读计划把目标说清楚
不要一上来就让 Agent 修改仓库。先在项目目录启动极狐GitLab Duo CLI：
glab duo cli进入会话后切换到计划模式，要求它先回答三件事：准备读取哪些文件、准备调用哪些工具、准备产生哪些改动。确认计划没有越过需求范围，再切回构建模式执行。
一个可复用的提示词可以这样写：
先只分析，不修改文件。列出你需要读取的目录、准备运行的命令、
可能写入的文件，以及每一步失败后的回滚方式。等我确认后再执行。这一步的价值不是让提示词变长，而是把隐含动作变成可审查清单。对于生产配置、权限文件和流水线脚本，这比执行完再看 diff 更便宜。
第二步 按风险选择一次批准或会话批准
当 Agent 请求使用工具时，CLI 会给出三种选择：
批准：仅允许这一次调用，适合写文件、运行迁移、推送提交等有副作用的动作。
在会话中批准：本会话内允许使用同一工具与同一组参数；参数变化后仍要重新审批，适合重复读取日志或查询只读 API。
拒绝：当前调用不执行，适合命令范围不明、目标路径过宽或包含敏感目录的情况。
管理员需要先在群组或实例层开启会话批准，用户才会看到该选项。建议把审批策略按工具风险分层，而不是按“这个 Agent 看起来可信”分层：只读搜索与状态查询可以会话批准；写文件、Git 推送、Shell 和外部 MCP 写操作坚持单次批准；删除、覆盖和生产变更默认拒绝，改由人工执行。
工具类型 | 建议审批 | 原因 |
|---|---|---|
项目搜索、只读 API | 会话批准 | 参数固定时副作用低 |
读取指定文件 | 会话批准 | 仍需限制目录范围 |
创建或编辑文件 | 单次批准 | 每次改动范围不同 |
Git 提交与推送 | 单次批准 | 会改变共享仓库状态 |
Shell 与 MCP 写操作 | 单次批准或拒绝 | 真实影响取决于参数 |
第三步 用项目规则固定上下文与禁区
审批只能控制“能不能调用”，还要控制 Agent “依据什么做决定”。极狐GitLab Duo Agentic Chat 可以使用整个项目中受 Git 跟踪的文件，并自主检索议题、合并请求、流水线和作业日志。团队应把工程约束写进版本库，而不是靠每个人重复口述。
可在仓库根目录放置 AGENTS.md：
# 项目规则
- 修改流水线前先解释变量来源与权限影响。
- 禁止改动 production/ 与 secrets/ 目录。
- 任何数据库迁移只生成方案，不直接执行。
- 输出变更后必须附回滚步骤与验证命令。自定义规则适合个人与团队偏好，AGENTS.md 适合项目结构、目录约定和共享工程规范。两者可以同时使用。对于密码、私钥或生产配置，还应在项目“设置 > 通用 > 极狐GitLab Duo”中配置上下文排除项；排除后，Agent Platform 的相关功能都会忽略这些文件和目录。
第四步 自动模式只放进可丢弃的边界
自动模式会让 Agent 在允许范围内运行 Shell、执行 Git 写操作、创建或更新极狐GitLab 资源，并调用 MCP 工具或任务流，而且不再逐次请求批准。它适合隔离分支、临时工作区与可重建环境，不适合装有生产凭据的终端。
官方安全建议很直接：只在可信仓库和可以丢弃的分支使用；不要在含敏感凭据的设备或 Shell 中开启；人要留在会话里，并在合并前审查全部变更；任务结束后切回构建模式。自动模式不会覆盖 Agent 工具治理，因此管理员仍应把高风险工具设为始终拒绝，避免个人误操作突破组织底线。
五个落地坑，配置前先避开
把会话批准当永久授权：会话结束后授权会重置；参数变化时也需要重新审批。
只看工具名不看参数：同一个 Shell 工具，
git status与删除文件的风险完全不同，审批时必须展开参数。把计划模式当安全扫描器：计划模式只保证不改文件，不代表分析结果一定正确，关键结论仍要核对来源。
规则写得太抽象：“遵循最佳实践”无法执行，应该明确目录、命令、验证与回滚要求。
自动模式开在日常主分支：自动化越顺，错误扩散越快；先在隔离分支验证，再走正常合并请求与审批流程。
常见问题
问：会话批准后，Agent 能随意换参数吗？ 不能。官方说明会话批准针对工具及其参数，不同参数需要额外审批。这也是为什么审批界面里必须同时检查工具名和调用参数。
问：开启自动模式后，管理员的工具治理还生效吗？ 生效。自动模式不会覆盖 Agent 工具治理，被策略设置为始终拒绝的工具仍会被阻止。
问：哪些团队暂时不适合开启自动模式？ 没有隔离分支、没有代码评审、终端长期保存生产凭据，或无法回滚变更的团队都不适合。先把只读计划、单次审批和审查闭环跑顺，再谈自动执行。
先把 Agent 的执行边界画清楚：建议从“计划模式分析、构建模式单次审批、敏感目录上下文排除”这组三件套开始，再根据真实调用记录决定哪些只读工具可以升级为会话批准。想系统梳理自定义 Agent、MCP 工具与审批策略，欢迎联系极狐GitLab 团队获取 Agent 治理实践清单。
