智能体上线：评测、可观测性与成本

这篇适合谁，读完能做到什么

适合已经做出智能体原型、正准备让它面向真实用户的开发者。读完你能给智能体加上追踪和指标，搭出离线与在线两层评测，并用小模型、路由和缓存控制成本。

为什么上线前要先看得见

智能体从原型走向真实应用后，就需要理解它的行为、监控它的表现，并系统地评测它的输出。没有可观测性，智能体就是一个「黑箱」：内部状态和推理过程都看不见，出了问题难以定位，也难以优化。有了可观测性，它才变成「玻璃箱」，透明度是建立信任、确保它按预期运行的基础。^[1]

上线以后，可观测性是关键能力，主要用于四件事：排查问题和根因分析、控制延迟与成本、保障信任与安全合规，以及支撑持续改进的循环。^[1]

第一步：用 trace 和 span 记录一次运行

Langfuse、Microsoft Foundry 这类可观测性工具，通常把智能体的一次运行表示为 trace 和 span。trace 是一个完整的智能体任务，从开始到结束，例如处理一次用户查询；span 是 trace 中的单个步骤，例如调用模型或检索数据。^[1]

微软 Agent Framework 原生集成了 OpenTelemetry。OpenTelemetry 被描述为 LLM 可观测性的行业标准，提供生成、收集和导出遥测数据的 API、SDK 和工具。接入方式的示例如下：^[1]

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
    # Agent execution is traced automatically
    pass

自动插桩不一定够用。业务上需要的信息，例如 user_id、session_id 和 model_version，可以作为属性加到 span 上，用于排错和分析。手动创建 span 也可以把自定义的业务逻辑包起来。下面是用 Langfuse Python SDK 手动创建 span 的示例：^[1]

from langfuse import get_client

langfuse = get_client()

span = langfuse.start_span(name="my-span")

span.end()

第二步：选定要盯的指标

不同智能体关注的指标不同，但下面几项几乎都要有：^[1]

• 延迟：每个任务和每个步骤各花多久。例如所有模型调用合计 20 秒，可以换更快的模型，或让模型调用并行执行。^[1]
• 成本：每次运行花多少钱。如果一个智能体为了一点点质量提升调用了五次大模型，就要判断这笔钱值不值，能不能减少调用次数或换便宜的模型。实时监控还能发现异常，比如某个 bug 导致 API 被反复循环调用。^[1]
• 请求错误：API 错误或工具调用失败。上线时可以设置回退或重试，例如服务商 A 不可用时切换到备用服务商 B。^[1]
• 用户反馈：显式反馈包括点赞、点踩、一到五星评分或文字评论；隐式反馈包括用户改写问题、重复提问或点击重试。连续的负面反馈，或者大量用户反复问同一个问题，都说明智能体没有按预期工作。^[1]
• 准确率：智能体的输出有多少是正确或符合预期的。准确率的定义因场景而异，第一步是定义什么算成功。可以用自动检查、评分或任务完成标签（例如「成功」「失败」）来统计。^[1]
• 自动化评估：可以让大模型给输出打分，看是否有帮助、是否准确。开源库也能从特定角度打分，例如 RAGAS 适用于检索增强的智能体，LLM Guard 可以检测有害语言和提示注入。^[1]

第三步：搭建离线和在线两层评测

评测是分析观测数据、必要时再做测试，判断智能体表现如何、怎样改进。之所以需要定期评测，是因为智能体往往具有不确定性，还会随着更新或模型行为漂移而变化。没有评测，你无法确定它是不是还在做好本职工作。^[1]

离线评测在受控环境中进行，使用预先整理、已知预期输出的测试数据集，而不是真实用户的查询。它的好处是可以重复，并且因为有标准答案，能给出清晰的准确率。例如，做一个数学应用题智能体，可以用一个有 100 道已知答案题目的数据集来测。离线评测通常在开发阶段进行，也可以放进 CI/CD 流水线，用来确认改动没有引入回归。^[1]

离线数据集的难点是要保持全面、跟上现实。智能体可能在固定测试集上表现很好，却遇到生产中完全不同的查询。因此要持续把新的边缘案例加进来。小规模的冒烟测试用例适合快速检查，较大的数据集用来看整体表现，两者结合最实用。^[1]

在线评测在真实使用中进行，持续监控智能体在真实用户交互中的表现。它能发现实验室里想不到的情况，例如随着输入模式变化出现的模型漂移，或者没有出现在测试数据中的异常查询。在线评测还可以做影子测试或 A/B 测试，让新版本和旧版本并行运行，对比效果。难点在于，线上样本很难拿到可靠的标签，通常只能依靠用户反馈或下游指标，比如用户有没有点击结果。^[1]

两者应当配合使用。在线监控发现的新类型失败案例，可以补充到离线数据集里；离线测试表现好的版本，才更有把握上线并继续监控。许多团队采用的循环是：离线评测、上线、在线监控、收集新的失败案例、加入离线数据集、改进智能体，然后重复。^[1]

常见问题怎么处理

• 任务执行不稳定：完善提示，把目标说清楚；考虑把任务拆成子任务，交给多个智能体处理。^[1]
• 智能体陷入循环：明确终止条件，让智能体知道什么时候该停；复杂的推理和规划任务，可以换成专门针对推理优化的较大模型。^[1]
• 工具调用效果差：先在智能体系统之外单独测试工具的输出；再调整工具的参数定义、提示和命名。^[1]
• 多智能体表现不一致：让每个智能体的提示更具体、彼此区分；设置一个「路由」或控制器智能体，判断应该交给哪个智能体处理。^[1]

这些问题大多靠观测数据就能定位，trace 和指标能指出工作流中具体哪一步出了问题。^[1]

控制成本的三种做法

1. 用小模型：小语言模型（SLM）在某些智能体场景中表现不错，成本明显更低。适合用来做意图分类、参数提取等简单任务，把大模型留给复杂推理。用评测来比较小模型和大模型的表现，是判断小模型是否够用的最好办法。^[1]
2. 用路由模型：使用多种规模的模型，由一个小模型或无服务器函数按复杂度分派请求。简单问题交给小而快的模型，只有复杂推理才调用昂贵的大模型。^[1]
3. 缓存回答：先识别常见的请求，在进入智能体系统之前直接返回答案。还可以用基础的 AI 模型判断新请求与缓存中请求的相似度。对高频问题和常见流程，这能明显降低成本。^[1]

限制和常见问题

• 示例只演示了插桩和手动 span 的写法，要看到完整的追踪效果，需要接入 Langfuse 或 Microsoft Foundry 之类的平台。^[1]
• 自动化评分本身也是模型输出，需要抽样人工核对，确认评分标准靠谱。这是常识性的做法，不在示例之内。
• 部署安全和可信的智能体，还要配合「可信智能体」里讲的威胁防护和人工确认一起做。^[1]

下一步

想看具体的监控和评测示例，可以打开配套的示例 notebook 10-expense_claim-demo.ipynb，里面演示了怎样用可观测性工具监控和评测一个智能体。^[1]

本文改编自 Microsoft 开源课程《AI Agents for Beginners》第 10 课^[1]，原文以 MIT 许可证发布。