Agent 上生产，先过这四关：Trace、Eval、Guardrail、Token 用量
Agent 上生产，先过这四关：Trace、Eval、Guardrail、Token 用量
别急着上线，先回答这四个问题。
把 Agent 从 demo 推到生产，最常见的结果不是"跑不起来"，而是"跑起来了但没人敢信"：它昨天表现很好，今天不知道为什么开始答错；它在测试集上得分很高，上线后用户遇到的情况全没见过；它调用了外部 API，出问题了你连它干了什么都说不清；月底账单下来，Token 费用比预想高了三倍。
这些问题没有一个靠"更好的 prompt"能解决。它们是工程问题，需要一套生产标准。我把它总结成四个关卡：Trace（全链路可观测）、Eval（回归评测）、Guardrail（安全护栏）、Token 用量治理。这篇文章讲清楚每一关要解决什么问题、怎么落地、以及常见的坑。
本文提纲
- 为什么 Agent 比传统服务难治理
- Trace：让每次 Agent 行为都可复现
- Eval：用评测把"感觉还行"变成"数字合格"
- Guardrail：在模型出错之前拦住它
- Token 用量：成本不是事后算账，是要实时盯
- 四关的顺序与常见误区
为什么 Agent 比传统服务难治理
先说清楚为什么传统那套监控手段不够用。
传统后端服务的行为是确定的：同样的输入，同样的代码路径，同样的输出。你靠日志、指标、链路追踪就能定位问题，因为逻辑是可枚举的。
Agent 不一样。它是概率系统：同一个输入，两次运行可能走完全不同的工具调用路径，可能产生不同输出。这带来三个治理难题：
- 状态爆炸：Agent 每一步的思考、工具调用、中间结果都是状态，出错点可能藏在任意一步。
- 不可复现：你很难用"重放请求"复现线上问题，因为模型采样有随机性。
- 越权面广：Agent 会主动调用工具、访问外部系统，出事的边界远大于一个被动接口。
所以 Agent 的治理不能靠"出了问题再查"，得靠全程记录 + 前置拦截 + 持续验证。这正是下面四关各自承担的职责。
Trace：让每次 Agent 行为都可复现
Trace 解决的是"它到底干了什么"。
一个 Agent 调用链可能长成这样：收到用户请求 → 规划 → 调用工具 A → 工具返回 → 再规划 → 调用工具 B → 生成回答。中间任何一步出错，你都该能回放。
要记录什么
一条合格的 Agent trace 至少包含：
| 层 | 记录内容 |
|---|---|
| 请求层 | 输入、用户/会话 ID、时间戳 |
| 思考层 | 每次 LLM 调用的 prompt、输出、token 数、延迟 |
| 工具层 | 每次工具调用的名称、参数、返回值、状态码 |
| 状态层 | Agent 的步骤序列、上下文快照、分支决策 |
| 结果层 | 最终输出、是否成功、是否有 Guardrail 触发 |
怎么落地
主流的做法是用 OpenTelemetry（OTel） 作为统一底座，把 LLM 调用、工具调用、Agent 步骤都打点成 span，然后接到 Langfuse、Opik、LangSmith、Langtrace 这类专门为 LLM 设计的追踪平台。它们和传统 APM 的区别在于：能理解 prompt/response 的结构、能关联 eval 结果、能按 session 聚合一次完整的 Agent 对话。
常见坑
- 只记成功不记失败。失败的 trace 才最值钱，但很多实现只把成功路径打了点。
- 不存原始输入输出。为了省存储把 body 截断，结果排查时缺关键上下文。
- 没有 session 关联。每次 LLM 调用是独立的 span，但看不出它们属于同一次用户会话。
Eval：用评测把"感觉还行"变成"数字合格"
Eval 解决的是"它到底做得好不好"。
人工抽查永远只能覆盖 1% 的场景，而且不可回归——上周你觉得没问题，这周改了 prompt 可能就悄悄退化了。Eval 的目标是把"质量"变成可重复测量的数字，让每次改动都有据可依。
三类评测指标
- 任务级指标：这个任务本身怎么算对。分类任务的准确率、检索任务的相关性（Recall@K）、问答的答案正确性。这类最可靠，但需要你定义"正确"。
- LLM-as-a-judge：没有标准答案的开放任务，用一个更强的模型给输出打分（相关性、连贯性、无害性）。速度快、覆盖广，但 judge 本身可能偏。
- 用户反馈：点赞/点踩、采纳率、用户修改率。这是最真实但最滞后的信号，适合做长期趋势，不适合做上线闸门。
怎么落地
- 建回归集：把真实生产流量里采集的输入输出沉淀成 eval set，标注正确答案。规模不用大，几百条高质量样本就比几千条脏数据有用。
- 每次改动都跑：改 prompt、换模型、改工具定义，都触发同一套 eval，对比分数。这是防止"悄悄退化"的关键。
- 阈值当闸门：给关键指标设红线，低于阈值不进生产。这和 CI 里跑单测是同一个心智模型。
常见坑
- 评测集和训练分布同源：模型见过测试样本，分数虚高，上线就露馅。
- 只测离线不测在线：离线 eval 合格的 Agent，上线后因为真实输入分布不同而翻车。要在灰度环境用真实流量持续采 eval。
- LLM-as-a-judge 不校验：judge 模型本身的偏差没校准过，你只是在用一个模糊的尺子量另一个模糊的东西。
Guardrail：在模型出错之前拦住它
Guardrail 解决的是"它不该做的别做"。
Trace 和 Eval 都是事后验证，Guardrail 是前置拦截——在 Agent 的行为越界之前拦住它。这是和传统后端差别最大的一块，因为模型的输出不可枚举，你必须用规则来约束它的行为空间。
三类护栏
- 输入护栏（Input Guardrails）：请求进来先查。检测提示注入（prompt injection）、敏感数据（PII/密钥）、恶意意图。核心问题是"用户想利用 Agent 做什么"。
- 输出护栏（Output Guardrails）：Agent 要吐内容前先验。过滤有害内容、校验格式、防止 prompt 泄露（模型把系统 prompt 吐出来）。核心是"模型想说什么不该说的"。
- 行为护栏（Action Guardrails）：Agent 要调工具、改数据前审批。这是企业最关心的——权限最小化 + 高危操作人工确认。写库、删数据、发消息、转账这类动作，必须有独立于 Agent 判断的拦截层。
怎么落地
- 护栏是独立层，不是 prompt 里的一句话。写在 prompt 里的"你不要访问这个接口"只是建议，模型可能无视。真正的护栏要放在代码层、工具代理层，硬性拦截。
- 权限最小化：给 Agent 的凭证只够它完成当前任务，而不是一把万能钥匙。高危操作（删除、支付、外发）单独走人工审批流。
- 用策略即代码：把护栏规则（谁能调用什么、什么操作需要审批）写成可审计的配置，而不是散落在代码里。
常见坑
- 把 Guardrail 当 prompt 规则写。模型遵守不了，等于没设。
- 只护输入不护输出。防止了用户注入，却没防住模型自己泄露系统提示词或生成有害内容。
- 护栏误伤正常流量。规则太严，Agent 的正常操作也被拦，业务跑不动。护栏要有可观测性——每次拦截都要能回溯是不是误判。
Token 用量：成本不是事后算账，是要实时盯
Token 治理解决的是"它到底花了多少钱"。
Agent 的 token 消耗和普通 LLM API 调用完全是两个量级。一个普通聊天请求几百 token，一个 Agent 任务可能几万甚至几十万 token——因为它要多次调用 LLM、每个工具返回都塞进上下文、还要做规划。更隐蔽的是，上下文会累积：多轮对话里，历史全塞进 prompt，token 数随轮数线性增长。
三个核心监控维度
| 维度 | 看什么 | 异常信号 |
|---|---|---|
| 单任务成本 | 一次完整 Agent 任务的 token 数 | 同类任务成本突然翻倍 |
| 上下文增长 | 多轮对话的 token 累积曲线 | 线性膨胀，没有压缩/截断 |
| 工具调用开销 | 每次工具返回占的 token | 大段工具输出反复塞进上下文 |
怎么降
- 上下文管理：给多轮对话设窗口、做摘要压缩（context compaction）、截断旧历史。这是降本最立竿见影的一招。
- 模型分级：规划、总结这类简单步骤用便宜小模型，复杂推理才用大模型。很多 Agent 框架（如 Claude Agent SDK 的 token-efficient 模式）已内置这套。
- 缓存：对重复的固定上下文（系统提示、工具定义、常用文档）用 prompt 缓存，命中部分几乎免费。
- 预算告警：按项目/用户/任务设 token 预算，超了就告警或熔断。
常见坑
- 只记总账不记明细。知道这个月花了 5 万，不知道是哪个任务、哪个模型、哪个用户烧的。
- 不看上下文膨胀。单次调用看着便宜，但上下文累积让每次调用越来越贵，最后失控。
- 没有按用户/租户分账。企业里成本无法摊到部门或客户头上，治理无从谈起。
四关的顺序与常见误区
建议的顺序是：Trace → Guardrail → Eval → Token 治理。
- 先上 Trace，因为它是其他三关的地基。Guardrail 触发、Eval 失败、成本异常，都需要 trace 才能定位。
- 再上 Guardrail，因为这是风险最直接的一关——先保证"不会出事"，再谈"做得好不好"。
- 然后上 Eval，把质量数字化，让改动可回归。
- Token 治理可以并行启动，因为它和前三关没有依赖，但建议一开始就埋点，别等账单爆了才补。
几个常见误区：
- 以为 Eval 能替代 Trace。Eval 告诉你"错了"，Trace 告诉你"为什么错"，两者互补，缺一个你都只能瞎猜。
- 以为 Guardrail 一次配好就完事。模型、工具、业务规则都在变，护栏和 eval 集一样需要持续维护。
- 把四关当成一次性项目。它们是持续运营的体系，不是上线前补一次作业。
说到底，这四关的共性是同一个：把 Agent 从"不可预测的黑盒"变成"可观察、可拦截、可验证、可计费的系统"。模型本身是概率的，但你的治理不能是概率的。
参考链接
- Anthropic 官方 Agent 最佳实践 - Agent 构建与治理的官方指南
- OpenTelemetry GenAI 语义约定 - LLM/Agent 打点的 OTel 标准，Trace 落地的基础
- Langfuse - 开源 LLM 可观测性与 Eval 平台
- Opik (Comet) - 开源 Agent 追踪、评测、优化一体平台，2.2 万星
- LangSmith (LangChain) - 覆盖 Trace/Eval 的 Agent 开发平台
- Guardrails AI - 输出验证与护栏开源库
- NeMo Guardrails (NVIDIA) - 可编程护栏套件，覆盖输入/输出/行为
- LiteLLM - 多模型网关，带 Token 用量与预算管理
- 我的 Langflow LLM Tracing 拆解 - 从 Trace View 到 Langfuse/Opik 六大集成的落地案例
- 我的 Opik 评测平台文章 - Agent 追踪 + 评测 + 优化一体的平台拆解
你们团队给 Agent 上线设了哪些标准？四关里哪一关最让你头疼？评论区聊聊，觉得有用点个赞让更多做 Agent 的人看到。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
