一次 CI 中的最小代理权限记录

把编码代理放进 CI 流水线，最容易忽略的不是模型能力，而是它在流水线里能做什么。一个代理可以读取仓库、修改文件、运行测试，甚至访问部署凭据。对初学者来说，最稳妥的起点是把 CI 看成一个权限边界：代理只应获得完成当前任务所必需的能力。

§ 先区分两类任务

CI 中的编码代理通常负责两类工作。第一类是观察，例如分析失败的测试、总结变更、检查格式或提出修复建议。第二类是行动，例如编辑文件、提交补丁、创建分支或触发部署。前一类通常可以自动运行，后一类应当增加限制和人工确认。

可以先问三个问题：代理需要读取哪些目录，需要写入哪些目录，完成任务后是否允许访问网络。很多检查任务只需要读取代码和测试结果，不需要写权限，也不需要生产环境凭据。

§ 从最小权限开始

读取权限应当覆盖当前仓库和必要的构建产物，不要默认暴露整个工作区。写入权限可以限制在临时工作目录，或者限制为明确的源代码路径。锁文件、部署配置和 CI 配置最好单独处理，因为一次看似普通的修改可能改变依赖来源或流水线行为。

命令权限也需要具体化。允许运行单元测试，通常比允许运行任意 shell 命令更容易审查。对网络访问尤其谨慎：代理可能下载依赖、上传日志，或把仓库内容发送到不应访问的服务。

• 默认只读，只有明确的修复任务才开放写入。
• 把测试、构建和部署拆成不同阶段。
• 生产凭据不放进代理可以直接访问的环境。
• 为每次运行设置超时、资源上限和可追踪的日志。

§ 密钥不是普通环境变量

调用模型时，API 密钥应放在 CI 平台的密钥管理功能中，并按仓库、环境和分支限制范围。不要把密钥写进配置文件、命令行参数、提交信息或调试日志。拉取请求来自外部贡献者时，默认不要向其代码运行环境提供高权限密钥。

Vana API 提供一个兼容 OpenAI 的接口，也支持 Anthropic Messages 和 Gemini 原生协议，因此可以沿用现有 SDK 或 CLI 的调用方式。它按实际 token 计费，没有月费；接入 CI 时仍应设置预算、速率和单次运行上限。完成一次小范围试运行后，再决定是否扩大权限。需要 API 账号时，可以创建 Vana API 账户。

§ 让代理提出变更，而不是直接发布

对新手而言，最清晰的流程是：代理读取问题，生成补丁，运行有限的测试，然后把变更交给人工审查。只有审查通过，后续步骤才允许合并或部署。这样即使代理理解错误，影响也通常停留在一个分支或一次构建中。

审查时重点看四件事：改动是否只涉及任务范围，测试是否覆盖真实风险，是否新增了依赖或权限，日志中是否出现密钥和用户数据。不要只看测试是否通过，因为测试通过并不代表权限边界正确。

§ 逐步增加信任

可以把自动化分成三个等级。第一等级只读分析，不修改仓库。第二等级允许在临时分支修改代码并运行测试。第三等级才允许创建合并请求或触发受保护环境的后续流程。每提高一级，都应有明确的审核记录和回滚方式。

CI 中的编码代理不需要一开始就获得完整权限。把任务拆小、权限写清楚、输出留下记录，再根据实际结果逐步放开，通常能同时保留自动化的效率和工程流程的可控性。