做 AI Agent 之前，先装好这 5 样东西
高可用架构约 6 分钟导读：本文列出启动任何新 agentic AI 项目前的 5 个必备安装顺序，重点解决密钥泄露、成本失控、调试困难等2026年常见痛点。配图展示实际运行数据：347 次 agent 运行中缓存 68.3% token、成本下降 92.5%、评估通过率 94.2%，验证这些工具能显著提升安全性和效率。
作者 Ronin，AI 初创公司 CloseAI CEO，MindoAI 顾问。专注 agentic AI 系统构建与实战落地，热衷分享高效开发实践与前沿工具链。
任何使用或学习 Agentic Systems 的人，都应该读这篇文章。
这是我在每个新的 agentic 项目开始前都会按顺序安装的东西：
1. 隐私：direnv + 真正的密钥管理器
先安装 direnv，再把它接入团队的密码管理器。可以用 op run 接 1Password CLI，也可以用 doppler、infisical、vault，选一个就行。
direnv 的作用是：当你 cd 进入某个目录时，加载这个目录专属的环境变量；离开目录时，再把它们卸载掉。真正关键的一步，是把它接到密钥管理器里，让凭证永远不要以明文形式躺在磁盘上。
它能挡住这些问题：
- API key 被意外提交进 git 历史，这是 2026 年最常见的 AI agent 泄露模式。
- 凭证通过 shell history 从一个项目串到另一个项目。
- shared.env 文件被某个队友悄悄同步到了 Dropbox。
- 笔记本被偷以后，密钥还留在 /Users/you/projects 里。
很多人没提到的是，大多数“我的 agent 被越狱了”的故事，最后其实都能追溯到一个 agent 本不该接触的凭证。把 key 限定到项目，把项目限定到文件夹，任何单点泄露的爆炸半径都会大幅下降。
在切换之前，我发过 2 个把 key 放在 .env 文件里的 agent。接入 op run 的那天起，这一整类噩梦就消失了。
2. Token：用 litellm 或 portkey 做模型代理
用一个 URL 统一代理所有 AI provider，包括 Anthropic、OpenAI、Google、Mistral 和本地模型。所有开销都从同一个地方流过。
它能帮你省下这些：
- 按 prompt hash 做响应缓存，重复任务可以把账单砍掉 30% 到 60%。
- 遇到 rate limit 自动 fallback。Sonnet 返回 429，就落到 Opus，再落到 GPT，再落到本地备份，用户侧完全无感。
- 按功能和用户设置预算上限，在一次调用花掉 200 美元之前拦住它，避免等到事后才审账。
- 模型路由规则，便宜任务给 Haiku，昂贵任务给 Opus，顺序别反过来。
- 请求离开你的网络之前先做 PII 脱敏，这是额外的安全收益。
很多人没提到的是，我听过的每一个“AI 账单烧了 4000 美元”的故事，结尾都是“我们前面没有放代理”。这里就是你在花钱发生之前，加上护栏的地方。
我花了 2 周自己写 router。后来用 litellm，20 分钟就替换掉了。这件事我会一直觉得丢脸。
3. Context：uv + 每次 eval 通过都 git commit
安装 uv。它是新的 Python 包管理器，来自 ruff 背后的 Astral 团队，比 pip+venv 快 10 到 100 倍。然后每次 eval suite 通过，就提交一次 commit，并在 commit message 里写上模型版本和通过率。
它会保存这些东西：
- 通过 uv.lock 固定的精确依赖集合，你永远知道 agent 当时用的是哪些包，不会被某次悄悄更新背刺。
- 精确的 prompt + code 状态，你可以从一个 git hash 复现任意历史运行。
- 精确的模型版本和精确的通过率配对，几周后 prod 出问题时，你有证据链可查。
- 重构走偏时，可以一条命令回滚到已知可用状态。
- 合规线索，每个 prompt 版本都在 commit log 里绑定了模型版本。
安全侧的重点是，prod 出事时，你希望能说：“prompt 是版本 X，模型是 Sonnet 4.6.1，上次 eval 通过率是 94%。”别只留下：“我觉得我们是周二部署的？”前者是事故报告，后者像辞职信。
我因为一次 session 里改 3 个 prompt 把东西搞坏而丢掉的 agent，比真正被 bug 搞掉的还多。
4. 可见性：把 mitmproxy 放在每一次 LLM 调用前面
它基本就是 agent 的窃听器。安装它，让你的 agent 通过它发请求，你就能实时看到 agent 和模型之间的每一段对话。
你实际会看到这些：
- 调用失败时，SDK 偷偷做的每一次静默重试。
- 实际发送出去的完整 prompt，包括你不小心嵌进去的任何凭证。
- 模型返回了什么，在你的代码做出反应之前就能看到。
- 每次调用、每个工具、每个循环迭代的精确 token 成本。
- 那些会悄悄触发你的代码去做意外事情的响应。prompt injection 就藏在这里。
很多人没说清楚的是，如果你的 agent 抓取的网站把指令塞进了数据里，mitmproxy 能让你看到 agent 决定跟随这些指令的那个瞬间。没有这一层，你只是在相信 agent 做对了，并没有真正验证。
我发了 3 个 agent 之后才加上这一层。老实说，我完全不知道它们之前在生产环境里到底干了什么。
5. Evals：inspect-ai，实验室真的在用的框架
eval 框架会用数字告诉你“这个 agent 能工作”，不用靠感觉。inspect-ai 是 Anthropic、DeepMind 和英国 AI Safety Institute 在论文里的 eval report 中使用的框架。它开源，MIT 许可证。
你自己手写的版本通常不会有这些：
- 在 5 个不同模型上跑同一个任务，并把分数并排比较。
- 针对高风险 agent 行为的预置测试，比如说谎、操纵、滥用工具。
- 面向使用工具的 agent 的正确评估结构，而不只是聊天。
- 可重复的评分，同一个输入每次都会用同样方式打分。
- 可复现的 eval seed，所以一个 flaky test 真的是 flaky，不会被误判成单纯运气不好。
我在 4 个项目里写过 4 次自己的 eval harness。最后 4 次都扔掉了。
如果你想认真说出“我的 agent 通过了安全检查”，这个检查就必须来自别人也能重新运行的框架。inspect-ai 就是这个框架。
把这一切串起来的动作是：每个 repo 都放一个 /lessons.md。每一次奇怪的 agent 行为、每一个边界条件、每一次凌晨 2 点找到的配置变更，都写进去。
你不会记得的。3 周后你再回来看，那个 lessons 文件是你还能搞清楚状况的唯一原因。
锁定这 5 件事，维护好 lessons 文件，你的下一个 agentic system 2 天就能跑起来，而不是 2 个月。
p.s. 网上一半的”AI agent”内容，都来自那些从来没在自己 loop 上跑过 mitmproxy 的人。他们其实不知道自己的 agent 在做什么。他们只是在发布 demo 视频。别做那种人。
原文：https://x.com/DeRonin_/status/2056083767333163044
参考阅读
如果你也在关注 AI 应用如何真正落地到生产环境，2026.6.26 - 6.27 GIAC 深圳站值得关注。这次大会会集中讨论智能应用开发、架构演进，以及来自一线实践的经验与案例。
识别二维码可申请大会体验门票，点击阅读原文了解大会详细议程。