Codex 0.134.0更新，聊聊一人公司如何防范 AI Agent 删库跑路

看到这两天 Codex 0.134.0 的更新日志，我的第一反应是：Codex 团队里终于有真正做过重度工程、踩过大坑的人了。

这次更新最值得聊的，不是 “它又提高了多少百分比的代码生成率”，而是它开始回过头来，补一些听起来很基础、甚至有点枯燥的 “基础设施”：

权限控制：谁能动哪些文件？哪些命令绝对不能跑？
上下文追溯：以前聊过什么，改过什么，能不能一键找回来？
MCP 安全协议：接入外部工具和 API 的时候，哪些凭证能给，哪些必须关起来？

这些东西听起来一点都不酷，肯定没有 “一个 Prompt 做出一个 App” 那么好传播。

但如果你真的每天开着 AI 编程工具改项目、跑命令、做自动化，你就会知道：这些看似枯燥的工程管理建设，才是 AI 编程工具从 “尝鲜玩具” 变成 “真生产力工具” 的转折点。

01. 当 AI 真的能动你的项目，你能不能管住它？

现在的 AI 编程工具，已经过了只看 Demo 演示的阶段。大家最爱问的不再是 “谁写得快”，而是 “谁能直接帮我把项目改好”。

但当 Codex、Claude Code、Cursor 这类工具真的拥有了读写本地文件、执行终端命令的权限时，一个更现实的隐患浮出水面：它太会干活了，以至于一旦理解错边界，动作快得让你来不及阻止。

刚开始用 AI 编程，大家主要是 “爽感” 驱动：改个页面、修个 Bug，行云流水。但用久了，在真实的项目场景下，你会遇到一类更隐蔽、也更致命的问题：

历史代码被误重构：你让它优化内容系统，它可能热心地顺手把你三年前写的、没写单元测试的历史老代码给重构了，直接导致线上崩溃。
未知依赖乱引入：你让它整理依赖，它可能顺手执行了 npm install 引入了未经验证的第三方包。
敏感密钥外泄：更严重的是，它在读取上下文时，不小心读取并暴露了 .env 或 config/secure.json 里的敏感密钥。

这些问题对大团队来说有 QA 和 CI/CD 兜底，但对一人公司（One-person Business）或独立开发者来说，很多时候就是你一个人开着工具直接干，根本没有精力去死盯着每一行自动化操作。

这时候，工具强不强是其次，它能不能被你放进一套清晰的 “规矩” 里，才是决定你敢不敢长期用它的关键。

02. 给 Agent 画边界：利用 Profile 实现权限最小化

这也是我看这次 0.134.0 更新时，觉得最实用的地方 ——--profile 变成了主要的权限选择方式。

它的底层逻辑很简单：以后用 Agent，不能只靠 “我这次执行命令时小心点”，而是要提前把安全线画死。

有些任务只能看不能改；
有些任务能改业务代码，但绝对不能碰配置文件。

我自己在外挂内容系统和第二大脑时，对这个痛点感受极深。现在我倾向于在本地为 Codex 预设明确的策略。比如，我们可以通过类似的 Profile 配置文件，直接在底层锁死 Agent 的手脚：

json

// .codex/profiles/content-runner.json { "profile_name": "content-system-safe-runner", "description": "用于日常内容系统维护的低权限模式", "file_access": { "allow_read": ["src/components/**/*", "src/utils/", "docs/"], "allow_write": ["src/skills/**/*", "src/views/"], "deny": [ ".env", "config/secure.json", "**/*.pem", "pnpm-lock.yaml" ] }, "execution_policy": { "allowed_commands": ["pnpm run test", "git status", "git diff"], "requires_approval": ["pnpm install", "pnpm run build"], "blocked_commands": ["rm -rf", "npm publish", "git push origin main"] } }

把规则写进底层，比你在 Prompt 里苦口婆心地叮嘱十遍 “千万不要动某文件” 有用得多。

用 AI Agent 的第一课，不是学怎么写 Prompt 调教它，而是学会怎么在工程架构上给它画边界。

哪些事可以直接干，哪些事必须停下来弹窗问你，哪些文件永远不许碰，越早定好，后面越省心。