生产环境AI Agent运维：观察、评估与优化三步框架

构建一个能跑起来的 AI Agent 并不难，难的是让它在生产环境里稳定、高效、可预测地运行。Azure Cosmos DB 团队在 "Code with Azure Cosmos DB" 系列的最新一期中，给出了一个清晰的运维框架：观察（Observe）、评估（Evaluate）、优化（Optimize）。这套方法论的价值不在于它引出了某个新产品，而在于它把 AI Agent 当作真正的软件系统来对待——先理解行为，再验证质量，最后控制成本。

为什么生产环境的 Agent 需要一套运维框架

传统软件上线后有日志、有监控、有回归测试，而很多 AI Agent 项目在演示阶段表现良好，一进生产就问题频出：用户偏好被遗忘、路由决策漂移、某个改动悄悄破坏了原本正常的功能。据主持人 Marko Haari 与 Madeline Egan 在视频中的说法，问题的根源往往不是模型能力不够，而是团队缺乏对 Agent 实际行为的可见性。

他们提出的框架遵循一个朴素逻辑：在修复任何问题之前，你必须先知道 Agent 到底在做什么。这三个阶段并非一次性流程，而是持续循环——生产系统在不断演进，观察、评估、优化的动作也要持续进行。

观察：让 Agent 的每一步都有迹可循

观察阶段的核心是 trace（追踪记录）。每一次 Agent 请求都会生成一条完整的 trace，记录工具调用、路由决策、记忆检索等关键动作。当 Agent 从 Azure Cosmos DB 中读写信息时，这些交互也被纳入同一条 trace，并在 LangSmith 中完整呈现。

这里的设计思路值得注意：由于记忆数据和应用数据都存放在 Cosmos DB 中，团队可以在一个地方获得端到端的完整视图，而不必在多个系统之间拼接线索。Microsoft Agent Framework Tracing 负责展示请求如何在系统中流转，包括路由、交接和工具调用；Microsoft Foundry 则提供面向生产 AI 负载的观测能力。整套方案基于 OpenTelemetry，trace 可以直接流入团队已有的观测栈。

一个容易被忽视的细节是：可观测性本身不产生价值，它产生的是"理解"。只有先看清 Agent 当前如何行为，后续的评估和优化才有依据。

trace（追踪记录）与 span：在分布式追踪体系中，一次完整的请求称为一个 trace，trace 由若干 span 组成，每个 span 代表一个操作单元（如一次工具调用、一次数据库查询、一次模型推理）。OpenTelemetry 是目前业界通用的可观测性标准，它定义了 trace、metric、log 三类信号的采集与导出协议，使同一份追踪数据可以流入 Jaeger、Datadog、LangSmith 等不同后端，而不必为每个观测平台重复埋点。这正是文中强调「trace 可直接流入团队已有观测栈」的技术前提。

LangSmith：LangChain 团队推出的 LLM 应用可观测与评估平台，支持记录 Agent 的调用链、查看每次 LLM 输入输出、构建数据集并运行评估。它在本文中承担的是把 Cosmos DB 交互与应用侧动作合并呈现的角色。

评估：像测试软件一样测试 Agent

观测告诉你发生了什么，评估则回答"这是否正确"。Madeline Egan 在视频中强调，Agent 应该像软件一样被测试——从单个路由决策、工具调用，到端到端的整体表现，都可以纳入评估范围。

具体手段包括三类。第一类是 LLM as a judge，用模型自动完成大规模质量检查，避免人工逐条审阅响应。第二类是回归测试，用来捕捉意外副作用，确保新改动不会破坏已经正常的功能。第三类是把评估嵌入 CI/CD 流水线，让每次变更在进入生产前都经过验证。

针对 Cosmos DB，还有一个颇具代表性的专项评估：验证跨会话的记忆召回是否准确。在系列第三集中，用户明确表示不喜欢红眼航班；那么在全新会话中，Agent 是否记得并遵守这一偏好？由于 Cosmos DB 是这份记忆的唯一持久化存储，评估可以直接针对持久化的用户状态进行，无需跨系统核对数据。

这引出了整个框架里最务实的一句话：发现 Agent 出问题的应该是你的评估套件，而不是你的用户。

LLM as a judge：一种用大模型充当评分者的自动化评估范式。其做法是给定原始输入、Agent 输出以及评分标准（rubric），让评审模型输出分数或判定理由。相比精确匹配或 BLEU 等传统指标，它更能处理开放式回答的质量判断，适合大规模抽样质检。其局限在于评审模型本身存在偏差与不稳定，通常需要人工标注样本做校准，并对评分结果做一致性检验。

回归测试与 CI/CD：回归测试指在每次变更后重跑既有测试集，确认原本通过的行为没有被破坏；CI/CD 则是把构建、测试、部署自动化的流水线。把 Agent 评估嵌入 CI/CD，意味着每次提示词、工具定义或检索配置的改动都会触发评估集重跑，未达标则阻断合并或发布。

优化：四层协同，而不是单点压榨

确认 Agent 工作正常之后，下一个问题是让它跑得更快、更省。Egan 的判断很直接：最贵的 Agent 很少是最优选择。优化要缩小的是"实际支出"与"用户体验"之间的差距。

他们把优化拆成四层，且这四层建立在同一套数据基础之上：

• RU 优化：在 Cosmos DB 层做对索引策略、分区模型和查询模式，避免为不需要的吞吐量付费。这是整个体系的地基。
• 检索优化：调优向量搜索与混合搜索，让 Agent 更快找到最相关的上下文，同时避免过度获取数据。
• 记忆优化：不再无限携带完整对话历史，而是通过摘要与压缩只保留关键信息，减少往返 Cosmos DB 的次数。
• LLM 层优化：通过更紧凑的提示词、更小的上下文窗口和更少的模型调用降低 token 消耗。

这四层并非孤立存在。更好的检索意味着 LLM 需要处理的内容更少，更好的记忆摘要意味着更少的数据库往返。正如视频中所说，数据库层的改进不只降低 RU 消耗，还会提升整个应用的效率——这正是四层共用同一数据基础带来的优势。

值得强调的是，优化不是上线前临时附加的步骤。系列第一集里，编码助手在写下第一行代码时就已经在传授 Cosmos DB 的最佳实践。好的架构决策在开发初期做出，并在生产环境中持续产生回报。

RU（Request Unit）：Azure Cosmos DB 的吞吐量与成本计量单位，把读写操作消耗的 CPU、IO 和内存归一化为一个数值。每秒钟可用的 RU 数（RU/s）决定了数据库的处理能力，费用也按预置或自动伸缩的 RU/s 计收。因此「RU 优化」的实质是让每次查询消耗更少的 RU：合理的分区键避免跨分区查询，恰当的索引策略减少不必要的索引写入与扫描，查询只取需要的字段而非全量文档。这些调整直接对应账单金额，也是文中称其为整个优化体系地基的原因。

向量搜索与混合搜索：向量搜索基于嵌入向量的相似度检索；混合搜索则把向量相似度与关键词（如 BM25）打分融合排序，兼顾语义召回与精确匹配。调优方向包括控制返回条数 top-k、设置相似度阈值、选择合适的分区与索引类型，避免一次性取回过多无关上下文而浪费 RU 与 token。

这套框架的适用边界

需要客观看待的是，这期内容本质上是 Azure Cosmos DB 的产品布道，观察、评估、优化三个环节深度绑定了 LangSmith、Microsoft Agent Framework、Microsoft Foundry 等自家或合作生态组件。对于不使用 Azure 技术栈的团队，具体的工具链无法照搬。

但方法论本身具有普适性：Agent 上线前要有 trace 级别的可见性，质量验证要自动化并进入 CI/CD，成本优化要从数据层、检索层、记忆层和模型层同时入手。把 AI Agent 当软件系统来运维，而不是当黑盒来祈祷，这才是这套框架真正的启示。