@DeRonin_: 任何使用或学习智能体系统的人都应该读一读这个。我在每个新智能体项目前执行的安装顺序：1.…

X AI KOLs Following 工具
agentic-systems secrets-management model-proxy developer-tools security caching git-workflow

摘要

一条分享智能体项目结构化安装顺序的推文：使用 direnv 配合密码管理器保障凭证安全，使用 litellm 或 portkey 作为模型代理管理成本和回退，使用 uv + git 在评估通过时提交以确保可复现性，使用 mitmproxy 实现 LLM 调用的全面可观测性。重点介绍了常见故障模式和安全漏洞。

任何使用或学习智能体系统的人都应该读一读这个 我在每个新智能体项目前执行的安装顺序： 1. 隐私：direnv + 真正的密码管理器 安装 direnv，然后将其接入你团队的密码管理器（通过 op run 使用 1Password CLI，Doppler、Infisical、Vault，任选其一） direnv 的作用：当你 cd 进入文件夹时，加载该文件夹的环境变量；cd 出去时，卸载这些变量。真正的操作是将其与密码管理器连接起来，这样凭证就永远不会以纯文本形式存在于磁盘上 这能阻止什么： - API 密钥意外提交到 Git 历史中——2026 年最常见的 AI 智能体漏洞模式 - 凭证通过 Shell 历史从一个项目泄露到另一个项目 - 共享的 .env 文件被某个团队成员悄悄备份到 Dropbox - 因凭证存放在 /Users/you/projects 中而在笔记本被盗后仍存在 没人提到的部分：大多数“我的智能体被越狱”的故事，归根结底是智能体访问了它本不该拥有的某个凭证。将密钥限定到项目，将项目限定到文件夹，任何单一泄露的爆炸半径都会大幅缩小 在切换之前，我发布过 2 个在 .env 文件中存放密钥的智能体。自从将 direnv 接入 op run 后，我再也没有遇到整类噩梦 2. 令牌：litellm 或 portkey 作为你的模型代理 一个 URL 前端对接所有 AI 提供商（Anthropic、OpenAI、Google、Mistral、本地模型）。所有开销通过一个地方流动 这能为你节省什么： - 基于提示词哈希的响应缓存，将重复任务的账单降低 30-60% - 遇到速率限制时自动回退（Sonnet 返回 429？回退到 Opus，再到 GPT，再到你的本地备份，用户不会中断） - 按功能和按用户的预算上限，在调用花费 200 美元之前就阻止它，而不是事后审计 - 模型路由规则：廉价任务用 Haiku，昂贵任务用 Opus，永远不会用错 - 请求离开你网络前的 PII 脱敏，这是安全方面的额外好处 没人提到的部分：我听到的每一个“4000 美元 AI 账单”故事都以“我们前面没有代理”结尾。这就是在开销发生之前设置护栏的地方 我自己构建路由器花了 2 周时间。用 litellm 替换只用了 20 分钟。这件事我会永远感到尴尬 3. 上下文：uv + 在每次评估通过时 Git 提交 安装 uv（新的 Python 包管理器，比 pip+venv 快 10-100 倍，由 ruff 背后的 Astral 团队开发）。然后每次评估套件通过时提交，提交信息中包含模型版本和通过率 这保留了什么： - 通过 uv.lock 确定的精确依赖集，你始终知道智能体使用了哪些包，不会因静默更新而遇到意外 - 精确的提示词和代码状态，你可以从单个 Git 哈希重现任何过去的运行 - 精确的模型版本与精确的通过率配对，在几周后生产环境出问题时给出线索 - 当重构出现问题时，一键回滚到已知的正常状态 - 合规记录：每个提示词版本都与提交日志中的模型版本相关联 安全方面：当生产环境出问题时，你希望说“提示词版本是 X，模型是 Sonnet 4.6.1，上次评估通过率是 94%”。而不是“我大概是星期二部署的？”前者是事故报告，后者是辞职信 我因为“在一个会话中改了 3 个提示词然后搞坏了某个东西”而丢失的智能体，比任何实际 bug 都多 4. 可见性：在每个 LLM 调用前放置 mitmproxy 它基本上是智能体的窃听器。安装它，让智能体通过它发出请求，现在你可以实时看到智能体与模型的每一次对话 实际能看到什么： - SDK 在调用失败时偷偷进行的每次静默重试 - 发送的完整提示词（包括你意外嵌入的任何凭证） - 在你代码响应之前模型返回的内容 - 每次调用、每个工具、每次循环迭代的确切令牌成本 - 静默触发你的代码执行你未预期之事的响应——这里就是提示注入的栖息之地 没人谈论的部分：如果你的智能体抓取的某个网站将指令混入数据中，mitmproxy 能让你看到智能体决定遵循这些指令的那一刻。没有这一层，你只是相信智能体做了正确的事，而不是去验证 我在添加这个之前发布了 3 个智能体。我完全不清楚它们在生产环境中做了什么 5. 评估：inspect-ai（实验室实际使用的框架） 评估框架用数字而非感觉告诉你“这个智能体有效”。inspect-ai 正是 Anthropic、DeepMind 和英国 AI 安全研究所用于你论文中看到的评估报告的那个框架。开源，MIT 许可 你自建版本所不具备的功能： - 在 5 个不同模型上运行同一任务，并排比较分数 - 针对风险智能体行为（撒谎、操纵、滥用工具）的预构建测试 - 评估工具使用智能体的正确结构，而不仅仅是聊天 - 可重复的评分：相同的输入始终获得相同的评分 - 可重现的评估种子：这样一次不稳定的测试真的是不稳定，而不是单纯运气不好 我在 4 个项目上写了 4 次自己的评估工具。扔掉了 4 次 如果你曾经想大声说“我的智能体通过了安全检测”，那么检测必须来自一个其他人可以重新运行的框架。这就是那个框架 将这一切串联起来的关键操作：在每个仓库中保留一个 /lessons.md 文件。每个奇怪的智能体行为、每个边缘情况、每个凌晨 2 点发现的配置更改，都写下来 你不会记住它们的。三周后你回来时，这个教训文件是你仍然了解情况的唯一原因 锁定这 5 步，保留教训文件，你的下一个智能体系统只需要 2 天而不是 2 个月 附言：网上一半的“AI 智能体”内容来自那些从未在自己的循环上运行过 mitmproxy 的人。他们实际上并不知道自己的智能体在做什么。他们只是在发布演示视频。不要成为那样的人
查看原文
查看缓存全文

缓存时间: 2026/05/18 00:24

任何使用或学习代理系统的人，都该读读这篇

我在每个新代理项目开始前执行的安装顺序：

  1. 隐私保护：direnv + 真正的密钥管理器

安装 direnv，然后把它接入你们团队的密码管理器（通过 1Password CLI 的 op run、doppler、infisical、vault，选一个）。

direnv 的作用：当你cd进一个文件夹时自动加载该文件夹的环境变量，退出时卸载。真正的妙处在于把它和密钥管理器连起来，这样凭据永远不会以明文形式存在磁盘上。

它能避免的问题：

  • API 密钥意外提交到 git 历史——2026 年最常见的 AI 代理入侵模式
  • 凭据通过 shell 历史记录从一个项目泄露到另一个项目
  • 共享的 .env 文件被某个队友悄悄备份到 Dropbox
  • 密钥因存放在 /Users/你/项目 下而随电脑丢失去向

没人提到的那部分：大多数“我的代理被越狱了”的故事，最终都追溯到代理本不该有的一个凭据上。把密钥按项目限定范围，把项目按文件夹限定范围，任何一个单一漏洞的爆炸半径都会大幅缩小。

在改用 direnv + op run 之前，我靠 .env 文件发布过两个代理，后来改的那天起，再没遇到过那类噩梦。

  1. 令牌管理：litellm 或 portkey 作为模型代理

一个 URL 即可对接所有 AI 提供商（Anthropic、OpenAI、Google、Mistral、本地模型）。所有开销都经由此处流转。

它能为你节省：

  • 按提示哈希缓存响应，重复任务可减少 30-60% 费用
  • 遇到速率限制时自动降级（Sonnet 返回 429？自动回退到 Opus，再到 GPT，再到你的本地备份，用户无感）
  • 按功能、按用户的预算上限，在调用前就阻止开销超过 $200，而不是事后审计
  • 模型路由规则：简单任务走 Haiku，昂贵的走 Opus，永远不会搞错
  • PII（个人身份信息）在请求离开你网络前脱敏——安全性的附带好处

没人提到的那部分：我听说过的每一个“$4000 AI 账单”故事，结尾都是“我们前面没有加代理”。这是个在开销发生前就设置护栏的地方。

我自己动手写过 2 周的路由器，后来换成 litellm 只花了 20 分钟。这件事我会永远感到惭愧。

  1. 上下文：uv + 每次评估通过时自动提交

安装 uv（新的 Python 包管理器，比 pip+venv 快 10-100 倍，由 ruff 背后的 Astral 团队开发）。然后在每次评估套件 通过 时自动提交，提交信息中包含模型版本和通过率。

它能保留什么：

  • 通过 uv.lock 确定的精确依赖集，你知道代理使用的是哪些包，不会因静默更新而出现意外
  • 精确的提示词 + 代码状态，从单个 git 哈希即可重现任何历史运行
  • 精确的模型版本与精确的通过率配对，为几周后生产环境出问题时提供追溯证据
  • 一键回滚到已知正常工作状态，当重构搞砸时
  • 合规故事：每个提示版本都与 commit 日志中的模型版本绑定

安全方面：当生产环境出了大问题时，你想说的是“提示版本是 X，模型是 Sonnet 4.6.1，上次评估通过率是 94%”，而不是“我猜我们是周二部署的？”前者是一份事件报告，后者是一封辞职信。

我因为“在一次会话中改了 3 个提示导致某处出错”而丢失的代理，比实际 bug 导致的还要多。

  1. 可见性：在每个 LLM 调用前放置 mitmproxy

它基本上就是代理的监听器。安装它，让你的代理流量经过它，然后你就能实时看到代理与模型之间的每一次对话。

实际能看到的内容：

  • SDK 在调用失败时悄悄执行的每一次静默重试
  • 发送的完整提示（包括你意外嵌入的任何凭据）
  • 模型在你的代码做出反应 之前 返回的内容
  • 每次调用、每个工具、每次循环迭代的精确令牌成本
  • 那些静默触发你的代码执行你本意之外的响应的内容——这就是提示注入所在之处

没人提到的那部分：如果一个被代理抓取的网站把指令悄悄塞进数据里，mitmproxy 可以看到你的代理 何时 决定服从这些指令。没有这一层，你只能信任代理做了正确的事，但无法验证。

我发布过 3 个代理后才加了这个，我现在根本说不清它们在生产环境中到底在干什么。

  1. 评估：inspect-ai（各大实验室实际使用的框架）

一个评估框架能通过数字而不是感觉告诉你“这个代理是有效的”。inspect-ai 是 Anthropic、DeepMind 和英国 AI 安全研究所用来撰写论文中评估报告的工具。开源，MIT 许可。

你自己写的版本不会有：

  • 在同一任务上运行 5 个不同模型并排对比评分
  • 针对代理风险行为（撒谎、操纵、滥用工具）的预置测试
  • 评估使用工具的代理的合适结构，而不仅仅是聊天
  • 可复现的评分，同一输入总是得到相同的评分
  • 可重现的评估种子，这样不稳定的测试就是真的不稳定，而不是运气不好

我自己在 4 个项目里写过 4 次评估框架，然后 4 次都扔掉了。

如果你曾经想在公开场合说“我的代理通过了安全检查”，那这个检查必须来自一个别人也能重新运行的框架。就是这个框架。

把这些串起来的关键操作：在每个仓库里保留一个 /lessons.md 文件。任何奇怪的代理行为、任何边界案例、任何凌晨 2 点发现的配置变更，都写下来。

你不会记住它们的。三周后你再回来，这个 lessons 文件是你唯一还能理解发生了什么的凭借。

锁住这 5 步，保留 lessons 文件，你的下一个代理系统只需要 2 天而不是 2 个月。

p.s. 网上半数关于“AI 代理”的内容来自那些从未在自己的循环上跑过 mitmproxy 的人。他们实际上不知道自己的代理在做什么。他们只是在放产品演示视频。别做那种人。

对我而言，这些是在我搭建任何系统、开始任何会话之前必须拥有的东西。

正确的环境设置 = 开发效率提升 10 倍。

相似文章

@paulmillr: https://x.com/paulmillr/status/2075335421920239651

X AI KOLs Following

这篇推文描述了一种安全且可靠的代理AI开发环境设置，使用通过SSH访问的专用服务器，配合tmux实现会话持久化，带有原生tmux集成的终端模拟器，以及用于安全访问的VPN。作者主张采用这种方式而非本地代理执行，原因是安全和可靠性方面的考虑。