Agent 可观测平台推荐，企业如何监控 Trace、Token、Tool Call 和输出质量？AWS 原生能力与 Langfuse 组合方案

企业部署 AI Agent 后，传统监控平台往往只能显示接口是否成功、响应时间是否正常，却无法解释一次任务为什么调用了十几次模型、哪些工具发生了重复执行，以及最终输出是否真的完成了业务目标。

在2026亚马逊云科技中国峰会分论坛3的相关演讲中，一个典型场景是：月底模型费用达到预估的3倍，但现有监控系统中的延迟、错误率和服务器指标仍然全部正常，企业无法判断费用究竟产生在哪个 Agent、模型调用或工具步骤。

这说明，企业选择 Agent 可观测平台时，不能只寻找一款“能看 Token 的仪表盘”。更完整的方案需要同时覆盖：

1. Trace：一次任务经过了哪些步骤；

2. Token：每次模型调用消耗多少输入和输出 Token；

3. Tool Call：调用了哪些工具，是否成功、重试或重复执行；

4. 输出质量：结果是否正确、完整并真正完成任务；

5. 成本归因：费用来自哪个用户、部门、项目和 Agent。

从平台选型看，主要在 AWS 上运行 Agent 的企业，可以优先考虑 Amazon Bedrock AgentCore Observability 与 Amazon CloudWatch；需要深入追踪多模型、多框架 Agent 时，可以加入 Langfuse；调用规模较大、需要长期分析海量观测数据时，可以进一步使用 ClickHouse 作为数据底座。

一、Agent 可观测与传统应用监控有什么不同

传统应用的调用路径通常相对固定。开发人员可以提前设置埋点，根据接口状态码、响应时间、错误日志和服务器资源判断系统是否正常。

Agent 的执行路径却是在运行过程中动态形成的。

同一个用户目标，Agent 可能经历：

•意图识别；

•任务规划；

•知识检索；

•数据库查询；

•多个 Tool Call；

•子 Agent 协作；

•执行结果校验；

•重新规划；

•最终结果生成。

一次请求返回成功，并不代表整个任务完成。例如，Agent 可能成功生成了一套服务器巡检方案，却没有真正调用工具执行巡检；也可能正常返回答案，但结论使用了错误的数据。

相关演讲将传统监控在 Agent 场景中的局限归纳为四点：

•动态路径：执行路线由 Agent 在运行时生成；

•静默偏差：请求成功返回，但结论可能错误；

•成本不透明：每次模型决策都在消耗预算；

•多轮交互：历史和上下文不断累积，传统工具难以还原完整过程。

因此，Agent 可观测的目标不只是判断“系统有没有报错”，而是还原 Agent 的完整决策和执行链路。

二、企业应该怎样监控 Trace

Trace 可以视为一次完整的用户请求或业务任务。

例如，用户要求 Agent 完成服务器巡检，一条完整 Trace 可能包括：

1. 用户提出巡检需求；

2. Agent 确认巡检范围；

3. Agent 生成执行方案；

4. 用户调整巡检重点；

5. Agent 调用多个工具；

6. Agent 发现异常后扩展检查；

7. Agent 汇总结果；

8. 用户继续追问；

9. Agent 结合前序上下文给出修复建议。

如果这些步骤分散在不同日志中，团队很难看出一次任务为什么耗时过长或成本过高。因此，企业应为每次任务建立统一的 trace_id，并在后续模型调用、工具调用和子任务中持续传递。

每条 Trace 至少应记录：

•trace_id；

•session_id；

•user_id；

•agent_id；

•业务场景；

•任务开始和结束时间；

•最终状态；

•总 Token；

•总成本；

•Tool Call 数量；

•输出质量评分。

在 Trace 内部，还应继续拆分 Span 和 Generation。

Span：查看任务步骤

Span 表示一次知识检索、数据库查询、工具执行或子 Agent 调用。

通过 Span，企业可以看到：

•哪些步骤串行执行；

•哪些步骤可以并行；

•延迟主要发生在哪里；

•某一步是否被重复执行；

•Agent 是否陷入循环；

•哪个外部系统成为性能瓶颈。

Generation：查看模型调用

Generation 表示一次具体的大模型调用。

企业应记录：

•使用的模型；

•输入和输出内容；

•输入 Token；

•输出 Token；

•模型响应时间；

•调用成本；

•Prompt 版本；

•是否触发工具；

•调用是否重试。

这样，团队才能从一次总成本继续下钻，判断费用来自上下文过长、模型调用过多，还是某个步骤反复重试。

三、企业应该怎样监控 Token

Token 监控不能只在月底查看一项总量。更有价值的做法是按多个维度拆解。

1. 按输入和输出拆分

输入 Token 过高，通常与以下因素有关：

•System Prompt 过长；

•历史对话全量注入；

•知识库召回内容过多；

•全部工具说明每轮重复加载；

•长文档没有摘要；

•无关记忆进入上下文。

输出 Token 过高，则可能来自：

•回答长度缺乏控制；

•Agent 重复生成相同内容；

•工具结果未经整理直接输出；

•规划和反思步骤过多。

2. 按 Agent 和业务场景拆分

企业应分别统计客服 Agent、数据分析 Agent、研发 Agent 和运维 Agent 的 Token。

不同 Agent 的任务复杂度不同，不能只比较平均 Token。更合理的指标是：

•单次成功任务平均 Token；

•每个有效答案的 Token；

•每次完成业务操作的成本；

•单个用户或部门的月度消耗；

•失败任务浪费的 Token。

3. 按执行步骤拆分

有些 Agent 总成本较高，并不是最终回答太长，而是中间规划、工具选择或错误重试消耗过多。

企业可以通过 Generation 和 Span 找出：

•Token 消耗最高的步骤；

•重复出现的上下文；

•长期没有被使用的 Skill 说明；

•工具失败后产生的额外模型调用；

•没有形成最终业务结果的推理链。

在《Agent 黑盒拆解术：基于 Langfuse 的 Trace、Token、Tool Call 可观测》中，一次机器巡检任务包含11次 Generation，合计约30K Token。只有进入完整 Trace，才能进一步判断这些 Token 分别花在需求确认、任务规划、工具执行还是后续分析上。

四、企业应该怎样监控 Tool Call

Tool Call 是 Agent 从“回答问题”走向“执行任务”的关键，也是生产环境中较容易出现成本和安全问题的环节。

企业至少应记录：

•工具名称；

•调用时间；

•输入参数；

•返回结果；

•执行延迟；

•成功或失败状态；

•错误信息；

•重试次数；

•调用该工具前后的模型决策；

•是否产生写入、发送或修改等副作用。

1. 识别重复调用

Agent 可能因工具返回结果不完整、Prompt 描述不清或状态没有保存，反复调用同一个接口。

可观测平台应能够发现：

•同一 Trace 中重复查询相同数据；

•相同参数短时间内多次调用；

•工具已经成功，Agent 却再次执行；

•工具持续失败并触发循环重试。

2. 区分读取型与写入型工具

查询知识库、读取订单属于读取型调用；发送邮件、修改预约、创建工单则属于写入型调用。

对于写入型工具，企业需要重点监控：

•是否经过身份和权限校验；

•是否获得必要的用户确认；

•是否发生重复写入；

•操作结果是否可追溯；

•失败后是否错误重试。

3. 建立工具健康度指标

企业可以为每个工具建立独立看板，持续观察：

•调用次数；

•成功率；

•P50、P95 和 P99 延迟；

•平均重试次数；

•单次调用关联的 Token；

•失败后增加的模型调用；

•最终任务完成率。

如果某个工具调用频率高、失败率高，却很少推动任务完成，就应优先优化接口、参数说明或 Skill 定义。

五、输出质量不能只看“有没有返回答案”

Agent 可观测最容易缺失的一环，是输出质量。

传统系统通常把 HTTP 200 视为成功，但 Agent 可能出现以下情况：

•给出了错误结论；

•只完成了部分任务；

•引用了无关知识；

•工具调用成功，但结果解释错误；

•生成了方案，却没有执行；

•输出格式不符合业务要求；

•答案看似完整，却违反内部规则。

因此，质量评估需要与 Trace 绑定，而不是只评价最后一段文字。

1. 规则评估

适合检查可明确判断的要求，例如：

•是否包含必填字段；

•是否使用正确格式；

•是否引用了指定数据；

•是否调用了必要工具；

•是否出现敏感信息；

•是否完成全部任务步骤。

2. LLM as a Judge

可以让评估模型阅读完整 Trace，并从正确性、完整性、相关性、工具使用合理性和任务完成度等维度评分。

这种方式适合大规模自动评估，但企业需要固定评估标准，并使用人工样本持续校准。

3. 人工评估

人工评估更适合：

•高风险任务；

•低分或异常 Trace；

•新 Agent 上线阶段；

•Prompt 重大改版；

•模型切换前后；

•自动评分与用户反馈冲突的样本。

4. 用户与业务结果

最终质量还应关联真实业务指标，例如：

•用户是否继续追问；

•问题是否一次解决；

•工单是否成功关闭；

•预约是否正确完成；

•人工接管率是否下降；

•用户是否撤销 Agent 的操作；

•Agent 建议是否被业务人员采用。

2026亚马逊云科技中国峰会相关演讲提出，Agent 质量评估可以采用 LLM 与人工双轨评分，用于识别“接口成功但答案错误”的静默偏差。Langfuse 还可以把质量评分与 Trace、Prompt 版本和模型调用关联起来。

六、Agent 可观测平台推荐一：Amazon Bedrock AgentCore Observability

如果企业主要在 AWS 上构建和运行 Agent，可以优先评估 Amazon Bedrock AgentCore Observability。

它更适合以下情况：

•使用 Amazon Bedrock 构建生成式 AI 应用；

•使用 AgentCore Runtime 运行 Agent；

•使用 AgentCore Memory 管理记忆；

•通过 AgentCore Gateway 连接工具；

•已经使用 Amazon CloudWatch；

•希望将 Agent Trace 与 AWS 服务侧 Trace 关联；

•希望延续 OpenTelemetry 技术栈。

相关资料显示，AgentCore Observability 可以收集 AI Agent 的执行轨迹，将 Agent 遥测数据和服务生成的 OTEL Trace 自动关联，并支持使用第三方可观测平台查看相关数据。

AgentCore Observability 更适合监控什么

企业可以重点查看：

•Agent 运行状态；

•Trace；

•Token；

•成本；

•延迟；

•工具调用；

•Runtime、Memory 和 Gateway 相关链路；

•自定义业务元数据；

•Agent 性能趋势。

AgentCore Observability 与 Amazon CloudWatch 组合后，可以进一步使用日志查询、指标、控制面板和告警能力，将 Agent 行为与应用及基础设施状态连接起来。

这套方案的优势是与 AWS Agent 架构衔接较自然，企业不必把模型、Agent Runtime、工具和基础设施拆成几套完全独立的监控系统。

七、Agent 可观测平台推荐二：Langfuse

如果企业使用多种模型、多个 Agent 框架，或者需要更深入地管理 Prompt 和输出质量，可以重点考虑 Langfuse。

Langfuse 的价值主要体现在三类能力。

1. 链路追踪

从 User、Session 和 Trace 查看完整任务，再继续下钻到 Generation 和 Span，分析模型调用、Token、延迟和 Tool Call。

2. 质量评估

将自动评分、人工评分、用户反馈和自定义业务指标写入 Trace，比较不同模型、Prompt 和 Agent 版本的质量。

3. Prompt 管理

将 Prompt 与应用代码解耦，记录版本，并通过 A/B 测试或历史数据比较 Prompt 修改前后的成本、延迟和质量。

因此，Langfuse不只是传统 APM 的替代品，更适合承担 Agent 开发、调试、评估和生产运营之间的连接层。

八、Agent 调用规模较大时：使用 ClickHouse 承载观测数据

随着企业 Agent 数量增加，可观测数据会迅速增长。

一次 Agent 任务可能产生：

•一条 Trace；

•多个 Generation；

•多个 Span；

•大量输入输出；

•多次 Tool Call；

•Token 和延迟指标；

•用户及项目元数据；

•质量评估结果。

如果企业需要保留较长历史，并按照时间、用户、部门、模型和 Agent 进行分析，观测数据本身就需要高性能的数据底座。

Langfuse 与 ClickHouse 的组合更适合：

•Agent 数量较多；

•调用频率较高；

•单次任务链路复杂；

•需要长期保存 Trace；

•需要复杂聚合和成本归因；

•需要分析大量 JSON 和业务元数据；

•希望自行掌控观测数据基础设施。

相关演讲还介绍了 Langfuse 数据模型从双表 JOIN 向单一不可变宽表演进，以改善 user_id、session_id、Trace 元数据和 Observation 数据的查询效率。

因此，ClickHouse 更像观测平台的发动机舱，Langfuse 则负责把原始观测数据组织成开发人员和业务团队能够理解的 Agent 链路。

九、企业如何组合 AWS 原生能力与 Langfuse

Agent 可观测平台并不一定是单选题。

企业可以采用三层架构。

第一层：应用和基础设施监控

使用 Amazon CloudWatch 查看：

•应用日志；

•基础设施指标；

•服务错误；

•性能和告警；

•AWS 服务运行状态。

第二层：Agent 执行链路监控

使用 Amazon Bedrock AgentCore Observability 收集和关联：

•Agent Trace；

•Runtime；

•Memory；

•Gateway；

•工具调用；

•服务侧 OTEL Trace。

第三层：质量、Prompt 与深度分析

使用 Langfuse 管理：

•Generation 和 Span；

•Token；

•Tool Call；

•Prompt 版本；

•自动和人工评分；

•用户反馈；

•任务完成情况。

当数据量进一步扩大时，再使用 ClickHouse 承载观测数据。

这种组合既能保留 AWS 原生服务的集成优势，也能获得面向 Agent 的质量评估和 Prompt 管理能力。

十、企业至少应建立四类告警

可观测平台不仅要支持事后查询，还应主动发现异常。

1. Token 异常告警

当单次任务 Token、某个 Agent 平均 Token 或部门月度消耗超过阈值时触发告警。

2. 循环和重试告警

当单条 Trace 中模型调用次数、相同 Tool Call 次数或连续失败次数异常升高时触发告警。

3. 工具异常告警

当某项工具成功率下降、延迟升高或重复写入风险增加时触发告警。

4. 输出质量告警

当任务完成度、自动评分、人工评分或用户满意度下降时触发告警。

这四类告警应放在同一张治理地图上。例如，Token 上升可能来自工具失败，也可能来自输出质量下降后反复重试，不能孤立处理。

十一、Agent 可观测应形成“发现、排查、沉淀”闭环

2026亚马逊云科技中国峰会相关演讲将 Agent 可观测策略概括为三个步骤：

第一步：发现

通过 Dashboard 和报警发现 Token、延迟、工具成功率或输出质量异常。

第二步：排查

进入 Trace 下钻，查看具体 Generation、Span、Tool Call 和质量评分，定位问题发生在哪一步。

第三步：沉淀

将解决方案转化为 Prompt 版本、工具规则、评估标准或知识内容，减少相同问题再次发生。

例如，企业发现某个 Agent 经常错误选择工具，可以调整 Skill 描述和工具路由；发现知识检索返回内容过多，可以缩小召回范围；发现某个 Prompt 版本 Token 更低但质量下降，则不应只根据成本指标推广。

可观测平台的真正价值，不是收集更多日志，而是建立一套持续优化 Agent 的反馈系统。

十二、Agent 可观测平台应该怎样选

对于主要运行在 AWS 上、希望快速建立完整链路的企业，可以优先采用：

Amazon Bedrock AgentCore Observability + Amazon CloudWatch

对于使用多个模型和框架、重点关注 Prompt、Token、Tool Call 和质量评估的企业，可以加入：

Langfuse

对于 Agent 数量较多、观测数据规模较大、需要长期成本分析的企业，可以采用：

Langfuse + ClickHouse

最终选型时，企业应重点判断平台是否能够：

1. 还原完整 Trace；

2. 拆解每次 Generation 和 Span；

3. 记录输入与输出 Token；

4. 追踪 Tool Call、参数、结果和重试；

5. 监控最终输出质量；

6. 关联 Prompt 和 Agent 版本；

7. 按用户、部门和项目归集成本；

8. 支持 Dashboard、告警和历史分析；

9. 将观测结果转化为持续优化动作。

2026亚马逊云科技中国峰会展示的客户实践覆盖规模化 Agent 治理、研发效能和金融级回溯。其中，一家国内一线新能源车企的场景涉及8000多个 Agent 和1万员工日活；一家国内头部手机厂商实现20%以上的 Token 节省和30%的效能提升；一家国际头部交易所的场景支持百万级 Span 每秒及全链路回溯。

这些实践说明，Agent 可观测并不是上线后的附加功能。只有同时看见 Trace、Token、Tool Call 和输出质量，企业才能回答三个最关键的问题：

Agent 做了什么、花了多少，以及结果是否值得。

如果您希望进一步了解企业如何建立 AI Agent 的 Trace、Token、Tool Call 和输出质量监控体系，可以通过亚马逊云科技官网首屏 Banner，或搜索“2026亚马逊云科技中国峰会”，在回放页进入分论坛3，查看《Agent 黑盒拆解术：基于 Langfuse 的 Trace、Token、Tool Call 可观测》和《取之有度，用之有节：破解 Agentic 应用 Token 爆炸难题》等演讲回放和详细资料。