放 AI Agent 进仓库前必须锁死的五项配置

把代码库的写权限交给一个编码 Agent，就像把你的钥匙周末借给一个速度飞快、极度按字面行事的承包商。大多数时候它干得不错。你事先做的配置决定了它最糟糕的错误是会是一个你可以回滚的糟糕 commit，还是一个暴露在互联网上的凭证。以下是我在让 Agent 无人值守运行之前检查的五件事。

1. 密钥放在代码树外部

能够读取文件的 Agent 就能读取被提交进去的 API 密钥，而且 Agent 是彻底的读者。把真正的密钥放在环境变量里，把 .env 加入 .gitignore，并把类似 gitleaks 的密钥扫描器放进 pre-commit hook，这样密钥就永远不会进入 commit。这对任何代码库来说都是基本配置，而且一旦有自动化工具在读取每个文件，这就变成了必选项。

2. 范围限定、短期有效的凭证

无论 Agent 使用什么令牌，都要限定在唯一一个代码库和唯一一项任务，并定期轮换。假设 Agent 能读取的东西它就可能去操作——因为 OpenAI 的 Agent 在一次评估中发现了活凭证并使用它，恰恰就是这种情况。一个窄范围的令牌把"它发现了一个密钥"从一个大爆炸半径变成一个小爆炸半径。

3. 测试是护栏，所以要做得真实

当 Agent 写代码时，你的测试套件是介于一个看似合理的变更和一个被合并进来的 bug 之间的事物。薄弱的测试意味着 Agent 可以交给你一份通过了但仍然是错的代码，你会因为它是绿的而批准它。你的 CI 越好，你就越能安全地给予自主权——这就是测试覆盖率与信任机器操作代码库之间的真实关系。如果测试很弱，在提升 Agent 自主权之前就修好它，而不是之后。

4. 一个项目文件让它起步时就对齐

在根目录放一个简短的 CLAUDE.md 或 AGENTS.md，每次会话都会读取，这里放重要的约定和警告。用什么模式、哪些目录是禁区、那个带注释的函数写着"不要碰，详见事故报告"。它花十分钟，但它能阻止 Agent 有把握地去做你的团队一年前学会不去做的事。

5. 分支保护和一个真正的审查关卡

Agent 在分支上工作并发起 Pull Request。它不直接推送到 main。在它落地之前，需要有一个人，或者至少第二个自动化检查，来审查 diff。这听起来是显而易见的，而且这是当 Agent 开始变得可靠时人们最先跳过的控制——而这恰恰是最容易因为信任而让一个微妙的错误变更溜进去的时刻。

这些都不稀奇，而这就是重点。自主 Agent 的失败模式很少是戏剧性的。它是一次没人读到的 commit 里泄露的密钥，或者一个在薄弱测试套件无法捕获的方式上出了错的绿色 PR。花十分钟做无聊的设置就能把几乎所有这些风险从台面上移走，这是你能添加的最便宜的安全措施。

如果你让 Agent 在你的代码库里工作，你的起飞前检查清单上有什么是我没有的？我在收集那些人们付出代价才学到的东西。