AIAgent进入生产后,如何做到可观测、可评估、可运营?

导读 本文整理自云器科技技术专家蔡瀛在 DataFun × 云器科技直播中的分享。随着 AI Agent 从 Demo 进入真实业务，团队需要回答的问题已经从“能不能跑”变成“任务到底有没有做对”。围绕这一问题，云器科技介绍了 SingSight 的产品设计、生产环境中的持续评估方法，以及如何借助云器 AI Lakehouse 将 Trace、Evaluation 与业务数据统一起来，形成从问题定位、批量评估到运营分析的完整链路。

主要内容包括以下几个部分：

1. SingSight：从运行数据到质量运营

2. Agent 进入生产：为什么传统监控不够

3. 零售客服案例：一次“退错货”的排查闭环

4. AI Lakehouse：统一数据底座与技术价值

分享嘉宾｜蔡瀛 云器科技 技术专家

内容校对｜韩珊珊

出品社区｜DataFun

SingSight：从运行数据到质量运营

Agent 进入业务系统后，一次任务会留下大量运行数据：会话上下文、模型输入输出、检索内容、Tool Call、工具参数以及业务系统的返回结果。单看其中任何一项，都很难判断任务是否真正完成。SingSight 的定位，就是把这些分散证据串起来，对齐“用户想做什么、Agent 实际做了什么、业务系统最终发生了什么”，再据此定位问题和评估质量。

这套能力分为四个模块。数据接入负责通过 OpenTelemetry、主流 SDK 和自定义埋点采集运行数据；Trace 与 AI 分析负责还原调用链，并在链路较长时辅助总结异常步骤；Evaluation 按业务标准创建评估器，对同类任务进行批量评分；Lakehouse 与运营分析则把 Trace、Evaluation 与业务数据放到同一数据底座中，继续做长期趋势和业务关联分析。四个模块并不是彼此独立的工具，而是一条从数据接入、问题定位、质量评估到持续分析的链路。

Agent 进入生产：为什么传统监控不够

AI Agent 正从试点进入规模化生产。演讲引用的行业数据给出三个趋势：33% 的企业已有 Agentic AI 架构运行，多 Agent 工作流在不到四个月内增长 327%，采用 Evaluation 的组织，推进到生产的 AI 系统数量约为未采用者的近 6 倍。数字本身不是重点，变化更直接：Agent 开始连接真实业务系统、调用工具并执行动作，生产质量因此成为新的工程问题。

进入生产后，最常见的三类问题并不是传统意义上的系统故障。第一类是结果不稳定，同样的请求可能因为上下文、模型判断或工具返回不同，走出不同路径；第二类是过程不清，接口都成功，却不知道为什么选了某个工具、为什么传了某组参数；第三类是质量回归，模型、Prompt、工具或接口升级后，原本能做对的任务可能重新出错。

传统 APM 和日志监控擅长回答接口是否成功、延迟是否正常、资源是否充足，但 Agent 的执行带有概率性。系统层面全部正常，不代表业务任务正确完成。生产环境因此需要同时观察两层：一层是系统稳定性，另一层是 Agent 的决策、工具调用和最终业务结果。

上线前的确定性测试仍然需要保留，例如下单接口能否正确返回、退款金额是否正确计算。但真实用户的表达、对话上下文和工具返回无法在上线前完全穷举，评估必须延伸到生产环境。这里采用的是 EDD（Evaluation-Driven Development）：从真实任务中发现问题，把问题样本沉淀下来；修改模型、Prompt 或工具后重新跑评估，同时检查旧问题是否修复、正常任务是否被破坏，再把新出现的问题补进样本集。

要让持续评估真正跑起来，前提是把一次任务产生的数据收全、存下来并能快速查询。模型输入输出、检索上下文、工具参数、业务返回、评估分数和评分理由都需要统一保存；只有把执行记录、评估结果和业务数据关联起来，团队才能回答哪些任务容易出错、哪个工具影响任务完成、新版本上线后质量是否回归，以及问题是否集中在某类客户、订单或商品上。

零售客服案例：一次“退错货”的排查闭环

SingSight 工作台把概览、Trace、评估和后续分析放在同一入口。首页可以查看任务量、质量、延迟和 Token 消耗；需要排查单次执行时进入 Trace，需要判断一批任务质量时进入 Evaluation，进一步的 SQL 和业务分析则回到 AI Lakehouse 中继续完成。

演示使用的是一个零售客服 Agent。用户只说一句“取消订单并退掉已经收到的手表”，后台却要查询用户与订单、确认商品状态、选择工具、传入订单号和商品编号，并执行取消或退货。任何一次查询错误、参数错误或模型判断偏差，都可能让最终业务动作与回复不一致。

实际案例里，Agent 最终回复“手表已经成功退货”，业务系统真正退掉的却是 Hiking Boots。问题不在回复文本本身，而在执行链路：第一次退货调用没有找到对应商品，Agent 随后重试时更换了 item ID，第二次调用因此指向了另一件商品，最后又把“手表已退货”返回给用户。

定位这类问题时，不必先拿到 Trace ID。客服团队通常掌握的是用户、商品和发生时间等业务线索。SingSight 可以先按 wristwatch 搜索，再叠加 user ID 和时间范围缩小记录，找到对应执行记录。

进入 Trace 后，可以核对完整对话、工具调用参数和返回结果。先还原原始证据，再让 AI 对长链路做异常汇总，可以减少直接依赖自动归因带来的误判。这个案例中，工具参数、实际退回的 Hiking Boots 与最终“wristwatch 已完成”的回复被放在同一条证据链中，错误位置就能被明确还原。

单条 Trace 找到问题后，下一步不是继续人工逐条检查，而是把同类任务拉出来批量评估。演示选择 Task Completion 评估器，按照预先定义的业务标准，将用户请求、执行过程和业务结果放在一起判断任务是否完成。评测结果中，3 条样本里 2 条通过，1 条为 0.5 分；低分记录可以再回到原始 Trace 做人工复核，验证评估理由是否可靠。

当关注点从“一次异常”转向“一段时间的运行情况”，同一批数据还可以继续进入运营分析。Trace 与 Evaluation 数据被沉淀为可查询的数据表，团队可以用 SQL 查看最近 7 天某个退货工具的调用量、失败次数、成功率和平均延迟，再与任务完成度一起分析。工具调用成功不等于用户任务完成，只有把工具指标与 Evaluation 结果放在一起，才能判断问题来自工具稳定性、参数传递还是上游决策。

AI Lakehouse：统一数据底座与技术价值

支撑这条链路的是云器 AI Lakehouse。结构化的订单、客户表，半结构化的 Trace、JSON，以及对话文本、Evaluation 结果都可以落在同一底座中。这样，问题定位不再停留在可观测平台内部：如果某类退货任务评分长期偏低，可以继续关联订单状态、商品类型或客户数据，也可以接到 BI、SQL 和其他 AI 应用中做后续分析。

针对 Agent 可观测数据的结构、检索和写入特征，底层做了三类优化。第一是 JSON 列式化，把 Trace 的 input/output 拆分为列式子列存储，提高压缩率，材料给出的估算是存储下降约 60%—85%；第二是原生倒排搜索，为对话内容和工具返回建立索引，按业务线索检索异常样本，估算检索可提升约 5—10 倍；第三是存算分离加实时写入，数据写一份并下沉对象存储，减少副本和中间缓冲，估算资源下降约 50%。这些数字是同类技术能力的估算值，实际效果仍需以具体数据和负载测试为准。

这也是为什么企业需要的不只是 Trace。Trace 能回答“这一次做了什么”，但生产质量还要回答“做对了没有”和“接下来怎么改”。SingSight 把原生证据、Evaluation、Lakehouse 与业务分析放在同一条数据链路中，避免执行数据只停留在单一可观测工具里，后续排查、评估和业务关联可以继续复用同一份数据。

在使用侧，这套方案强调的是一体化后的工程成本。业务线索可以用于秒级定位；压缩与存算分离降低长期保存成本；全托管方式减少额外运维；Trace、评分和业务数据能够继续进入报表、SQL 与其他 AI 应用；Analytics Agent、MCP、CLI 可以接入原有工作流；数据接入则兼容主流 SDK 和自定义埋点。最终目标不是增加更多独立工具，而是让问题定位、质量评估和运营分析共享同一条数据链路。

最终要形成的不是一次性的排障流程，而是一套可重复的工程动作：用 Trace 看清每一次执行，用 Evaluation 衡量每一次改进，再把运行数据沉淀到 Lakehouse 中持续复用。模型更换、Prompt 调整、工具升级后，效果变化都能够被重新记录、评估和跟踪，Agent 的运行也就从不可解释的黑盒，变成可以持续运营和优化的工程对象。

以上就是本次分享的内容，谢谢大家。