上周三凌晨两点，我盯着 AWS 账单手在发抖。

不是因为数字大——我见过更大的。是因为这笔钱花在了一个根本没人在用的服务上。

一个我们三个月前上线的 Agent，负责自动处理客户工单分类。代码审查过了，测试过了，灰度也跑了。一切正常。

然后它在某个深夜的循环里，把同一张发票重复处理了 3400 次。每次调用 GPT-4 做 OCR 识别。每次把结果写回数据库。

每次触发下游通知。

3400 次。没人知道。没人报警。没人停下来。

直到月底账单出来。

这不是我编的故事。Dev.to 上有人写了更离谱的版本——一个 Agent 在生产环境里烧掉了 47000 美元，在一个「没人注意到的循环」里跑了整整两周。

两周。运维团队以为它在正常工作。日志看起来一切正常。

API 响应码全是 200。

你上线了 Agent，但你上线了监控吗

说实话，我问过周围一圈做技术的朋友。上 Agent 之前做了什么准备？

答案让我后背发凉。

大部分团队的流程是这样的：选一个 Agent 框架（LangChain、CrewAI、AutoGen 随便哪个）→ 写几个工具调用 → 接上 LLM API → 本地跑通 → 推到生产。然后所有人松了一口气。

监控？事后再说。成本追踪？月底看账单。

行为审计？等出事。

一个在硅谷做平台工程的朋友告诉我，他们内部调研了 30 个已经上 Agent 的团队，只有 3 个团队在生产环境部署了任何形式的 Agent 专用监控。十分之一。

剩下的 27 个团队，运维方式基本靠「相信 Agent 会做正确的事」。翻译成人话就是：裸奔。

三个没人敢说的盲区

跟几个做 SRE 的朋友深聊之后，我把 Agent 生产运维的问题归纳成了三个盲区。这几个盲区，做 Agent 框架的不提，卖 LLM API 的不提，写了「Agent 上生产最佳实践」博客的人也不提。

第一，成本盲区。

Agent 和传统微服务不一样。一个 REST API 调一次就是一次，成本可预测。Agent 调一次可能触发 8 次 LLM 调用，而每次 LLM 调用的 token 消耗取决于当时的上下文长度。

你根本没法在事前算清楚「这个 Agent 一个月花多少钱」。你只能在事后看账单。

更糟的是，Agent 框架的默认重试策略是简单粗暴的——失败就重试，重试就烧 token。 一个因为网络抖动失败的调用，可能被重试 3 次，每次重试带着越来越长的错误上下文。你在为一个根本不会成功的调用付钱，而且付了三次。

第二，行为盲区。

传统服务的监控大家都很熟了——CPU、内存、QPS、错误率、P99 延迟。这些指标告诉你「服务在不在运行」。但对于 Agent，服务在运行≠服务在做正确的事。

Agent 可能在正常运行，同时也在做以下任何一件事：把同一个任务重复执行 N 次、陷入两个工具之间的无限切换、因为 prompt 里一个模糊指令开始执行你从未预期的操作、或被一个对抗性输入触发意外的工具调用。

传统的健康检查对 Agent 基本没用。 Agent 的 200 OK 可能是它在认真帮你烧钱。

今早 Dev.to 上有人提出了一个狠招——为 Agent 做故障注入。 不是注入网络故障或 CPU 故障，是注入语义故障。比如故意给 Agent 一个会让它陷入循环的输入，看它能不能自己检测并退出。或在 prompt 里埋一个模棱两可的指令，看 Agent 会不会触发意外的工具调用路径。

这才是 Agent 运维真正需要的东西，而不是又一个 Dashboard。

第三，配置漂移盲区。

Agent 的行为由三样东西决定：prompt 指令、工具定义、模型版本。这三个东西有一个变了，Agent 的行为就可能完全不同。

但有多少团队在版本管理这三样东西？大部分的 CLAUDE.md 和 system prompt 存在某个人的本地目录里，改了就改了，没有 review，没有 diff，没有回滚机制。

有个说法我印象很深——「你的 CLAUDE.md 在骗你的 Agent」。 什么意思？因为 prompt 是静态文件，但你对接的 API、数据库 schema、业务规则每天都在变。Agent 拿着过期的指令在执行任务，就像一个新员工拿着去年的 onboarding 文档在工作。

更讽刺的是，我们给代码写单元测试、集成测试、端到端测试，但给 Agent 连一个确定性的行为测试都不写。Agent 的输出本质上是概率性的——同一个输入不保证同一个输出。这意味着你的 Agent 可能在 95% 的情况下表现正确，而在剩下 5% 的情况下做你完全想不到的事。你只是在赌那 5% 不会在生产环境触发。

卖工具的不会告诉你这些

做 Agent 框架的公司正在疯狂融资。LangChain 估值 20 亿美元，CrewAI 拿了 1800 万种子轮。他们 demo 里展示的永远是——「你看，Agent 自动完成了从订机票到写代码的所有事情！」

他们不会展示的是：这个 Agent 在生产环境里运行了三个月之后的账单、事故报告和运维团队的加班记录。

做 LLM API 的更不会告诉你。OpenAI、Anthropic 的定价页面永远不会提醒你——「注意，Agent 场景下你的实际 token 消耗可能是你预估的 5 到 10 倍。」

这是整个 Agent 生态最大的利益冲突：卖工具的和卖 API 的都希望你多用，但你自己要为「多用」付钱。

Hetzner 最近又涨价了——这是六个月内第二次。官方理由很直白：AI 工作负载吃光了他们的可用内存。翻译一下：所有人都在疯狂跑 Agent 和 LLM，云计算资源正在被 AI 吃干抹净。 但你的公司为此买单的预算，可能还按着 2024 年的水平在做。

我后来做的四件事

折腾完那笔凌晨账单之后，我逼着自己做了四件事。不一定对，但至少让我能睡着觉。

• 给每个 Agent 加了一个「熔断计数器」：同一个 task_id 的重复执行超过 5 次，Agent 自己停掉，发告警。不是等外部监控发现——让 Agent 自己知道自己可能在循环。
• 把 prompt 和工具定义纳入 Git 版本管理：每次改动走 PR review。prompt 改动被当作和代码改动同等级别对待——因为对用户来说，Agent 行为改变和代码 Bug 造成的伤害是一样的。
• 对每个 Agent 预设月度预算上限：不是 LLM API 层面的限额，是 Agent 维度的。一个月花到阈值，自动降级到更便宜的模型。宁可慢一点，不要在凌晨三点烧四万七。
• 给 Agent 的每一次工具调用留下决策轨迹：不只是记日志——是在 Agent 每次选择调用某个工具时，记录它当时看到的上下文和它给出的理由。出事了你能回溯它「为什么在那个时刻做了那个决定」。Agent 不是黑箱，是你没给它装行车记录仪。

这些东西不是什么高深的架构设计。就是最土的办法——计数器、Git、预算上限、决策日志。但讽刺的是，整个 Agent 行业没有人把这四样东西打包成一个标准实践告诉你。

因为告诉你，就意味着承认 Agent 需要这些东西。

而承认 Agent 需要熔断器、版本管理、预算控制和决策审计，就等于承认 Agent 不是一个「可以自主运行的数字员工」。它就是一个需要被看着的程序。

沉默的代价

你可能会说，这不关我的事——成本是老板头疼的问题，我只要把 Agent 跑起来就行。

但问题是，当 Agent 的生产事故越来越多，背锅的不会是 LangChain 的 CEO，也不会是 OpenAI 的销售。是你。

是你凌晨三点被 PagerDuty 叫起来，发现 Agent 把生产数据库写出一堆脏数据。是你月底被财务追问「这笔四万七的 API 费用是怎么回事」。是你在年度 review 的时候发现「Agent 自动化的效率提升」被「Agent 事故的修复成本」完全抵消了。

Agent 进生产的第一天起，你就不是程序员了——你是驯兽师。 而驯兽师的第一课永远是：不要把后背留给野兽。

转给你那个正在把 Agent 推上生产的同事。他可能还不知道月底的账单长什么样。