随着 Qoder、Codex、Claude Code、OpenClaw 以及各类自研 Agent 在研发、运维和业务系统中持续落地，团队面对的问题正在发生变化。
过去，我们更关注一次接口调用是否成功、一个服务是否异常、某条 Trace 是否变慢。现在，AI Agent 带来了更复杂的运行过程：一次任务可能包含多轮推理、多次模型调用、多次工具执行、上下文持续膨胀、失败重试、Token 消耗、成本波动以及潜在的安全风险。当一个团队同时运行多个 Agent 时，真正需要回答的问题已经变成：
- 哪个 Agent 消耗了最多 Token？
- 哪个模型、工具或操作是主要成本来源？
- 失败重试浪费了多少预算？
- 某个 Agent 的投入产出比到底如何？
- 风险命中能否回溯到具体的 Trace、Session 或 Run？
- 一次真实执行链路能否被完整复盘？
为了解决这些问题，我们正式发布阿里云 RDS Agent 可观测：一套面向 AI Agent 应用的运行观测与治理平台。
平台以 RDS MySQL DuckDB 的列式分析能力作为底座，围绕 Workspace、Project、Service 建立资源模型，将 Qoder、Codex、Claude Code、OpenClaw 以及自研 Agent 的运行事件统一沉淀到同一个查询平面中，帮助团队完成多 Agent 接入、Token 与成本治理、ROI 分析、风险回溯和单 Agent Trace 下钻。
RDS Agent 可观测的核心不是再提供一个单点 Trace 页面，而是把 Agent 的运行过程转化为可查询、可关联、可审计的数据资产。
01 一键接入多类 Agent 运行时
Agent 可观测的第一步，是让不同类型的 Agent 能够快速、稳定地接入平台。
RDS Agent 可观测提供两种接入方式：curl 命令行接入和 Skill 接入。用户只需要在控制台中选择 Project、创建 Service，并选择对应的 Agent 类型，平台就会自动生成接入指令。
目前平台优先支持四类常见研发 Agent：Qoder、Codex、Claude Code 和 OpenClaw。
对于命令行用户，平台会生成一条可直接执行的 curl 命令。执行后即可完成 exporter 安装、基础配置写入和上报地址初始化。对于已经在使用 Agent 的研发团队，也可以通过 Skill 接入方式，让 Agent 根据平台提供的接入说明自动完成配置修改、hook 注册和连通性检查。
接入完成后，平台会通过 probe 检查最近上报状态，并在 Service 管理页展示是否已经成功接入、最近上报时间和接入方式。这样，用户不需要理解底层数据模型，也不需要手动配置复杂的 Trace、Session 或 Token 字段，就可以把 Agent 的运行数据接入到统一的观测平台中。
从产品体验上看，整个流程可以概括为四步：选择项目 → 创建服务 → 复制接入指令 → 验证上报状态。接入成功后，后续的 Trace、Session、Run、Token、Cost 和 Risk 都会自动归因到对应的 Project 与 Service 上，为成本分析、ROI 评估、风险回溯和 Trace 下钻提供基础。
02 项目级横向比较 Agent 的 Token 与成本
单个 Agent 的成本并不难看，真正困难的是在一个项目里横向比较多个 Agent 的成本结构。
RDS Agent 可观测使用 Project Scope 聚合项目下所有 Service 的运行数据，适合从管理视角查看不同 Agent 的 Token 消耗、成本趋势和主要成本来源。
平台在 Project Scope 中观察整体分布，在 Service Scope 中继续下钻到单个 Agent，从而把“成本看板”升级为“成本归因工具”。
RDS MySQL DuckDB 的优势在这里进一步放大。Token、Cost、Run、Trace 都是持续写入的明细数据，字段宽、维度多、查询组合灵活。列式存储更适合按 Service、Model、Operation、Time Range 做交互式聚合与扫描，支撑高频的成本分析和问题定位。
03 用 Agent ROI 分析投入产出比
只看 Token 和成本还不够。Agent 上线后，团队更关心的是：这些成本是否换来了足够的收益。
RDS Agent 可观测提供 Agent ROI 视角，用来把运行数据从“消耗统计”进一步推进到“投入产出分析”，帮助团队判断某个 Agent 是否值得继续扩大使用。详细评估指标如下：
- 投入侧：Token 消耗、模型成本、工具调用成本、失败重试成本；
- 产出侧：成功 Run 数、任务完成率、自动化处理量、业务价值分；
- 质量侧：失败率、错误类型、平均耗时；
- 风险侧：敏感内容、高危工具调用、异常行为和风险惩罚。
04 风险扫描结果回到运行链路
Agent 风险扫描不能只停留在“命中了某条规则”。对于生产环境中的 Agent 来说，更重要的是知道风险发生在哪里、由什么行为触发、是否影响了真实任务，以及后续能否被审计和复盘。
RDS Agent 可观测的风险能力强调把 finding 和 alert 关联回运行上下文，使团队可以从风险列表直接回到具体 Agent 行为。适合支撑几种常见场景：
- 敏感内容输出：定位触发风险的 response、session 或 run；
- 高危工具调用：回到具体 tool execution，查看输入、状态和上下文；
- 异常失败聚集：按 Service、Rule、Status、Time Range 查看风险分布；
- 安全审计：从 alert 回溯到 source event、trace 和相关 Agent 行为。
这使安全、运维和研发团队可以围绕同一条执行链路协同分析：安全团队看到风险，研发团队看到上下文，平台团队看到 Agent 行为，最终形成可追踪、可解释、可处置的风险闭环。
05 深入挖掘单个 Agent 的真实 Trace
项目级横向比较适合发现问题，真正定位原因还需要回到单个 Agent 的真实执行链路。
进入单 Agent 后，可以围绕 Trace、Session、Run 继续下钻，完整复盘一次任务从发起到结束的执行过程:
- Trace：一次执行的 span、耗时、状态和上下游关系；
- Session：多轮对话、上下文变化和用户交互路径；
- Agent Trace：run、model inference、tool execution 的时间线；
- Logs / Metrics：服务运行指标、错误日志和异常状态；
- Token / Cost：单次执行中的 Token 分布和成本来源；
- Risk：该 Agent 触发的风险命中与处置状态。
这条链路的关键是 ID 连续性。平台用 trace_id / session_id / run_id 把模型调用、工具调用、日志、成本和风险结果串起来。定位一次慢调用、高成本调用或风险命中时，不需要在多个系统之间复制 ID，而是可以从服务级页面一路下钻到真实事件，让团队快速判断问题到底发生在哪一层。
06 什么场景需要 RDS Agent 可观测
RDS Agent 可观测适合以下场景：
- 已经使用 OpenTelemetry，但缺少 Agent 过程观测的团队；
- 正在建设 Qoder、Codex、Claude Code、OpenClaw 或自研 Agent 平台的团队；
- LLM 成本增长快，需要按项目、Agent、模型、操作做归因的团队；
- Agent 应用上线后需要风险审计和运行复盘的团队；
- 希望把应用、数据库和 Agent 行为统一纳入 RDS 分析底座的团队。
对于这些团队来说，Agent 可观测不只是“多看几张图表”，而是把 Agent 的运行过程、成本结构、风险证据和执行链路统一纳入一个可治理的数据体系。
07 为什么选择 RDS MySQL DuckDB
Agent 可观测数据天然具有分析型特征：写入持续、字段丰富、维度多、查询范围灵活。一条运行链路里可能同时包含 trace_id、session_id、run_id、service_name、model、provider、tool_name、Token、cost、risk、status 等字段，并且这些明细需要长期保留，用于排障、复盘、审计和趋势分析。传统行式存储更适合高并发事务访问，但在宽表、多维聚合、长时间范围扫描和交互式分析场景下，往往需要额外建设复杂的分析链路。RDS MySQL DuckDB 在保持 MySQL 协议、访问方式和运维习惯的基础上，引入 DuckDB 列式分析能力，适合承接 Agent 可观测这类大规模明细与多维分析场景。对于 RDS Agent 可观测来说，它主要承担三类基础能力：
- 高吞吐写入：持续接收 OTLP、Agent event、browser session event、数据库审计事件等明细；
- 长周期留存：保存用于排障、复盘和合规审计的证据数据；
- 多维分析：按项目、服务、模型、工具、会话、Token、成本和风险维度快速下钻。
这也让 RDS Agent 可观测不仅是一个 Agent 运行看板，而是一个基于 RDS 分析底座构建的 Agent 运行数据平台。
08 结语
RDS Agent 可观测的目标，是帮助团队从“使用 Agent”走向“治理 Agent”。
借助 RDS MySQL DuckDB 的列式分析能力，平台可以承接长期、细粒度、多维度的 Agent 明细数据；借助 Workspace、Project、Service 的资源模型，平台可以把观测数据纳入清晰的组织和服务边界；借助 Trace、Session、Run、Token、Cost、ROI 和 Security 等能力，团队可以持续分析 Agent 的真实运行状态。
在 AI Agent 开始进入研发、运维和业务系统的阶段，可观测能力不应只停留在单次调用是否成功，而应该进一步回答：它是否稳定、是否高效、是否安全、是否值得继续扩大使用。
这正是 RDS Agent 可观测希望解决的问题。
免费试用
👉即日起，RDS Agent 可观测正式开放邀测。点此https://page.aliyun.com/form/act1880443186/index.htm 立即申请邀测。
申请通过后，我们将为您专属分配技术对接人，提供接入指导、数据建模建议及定制化分析支持。
邀测期间，免费试用 RDS Agent 可观测全部能力：Token 归因、ROI 分析、风险回溯、全链路 Trace 下钻、多 Agent 统一治理。
