企业 AI Agent 上线后看不清 Token 和工具调用成本，哪些云上可观测平台更适合？

企业 AI Agent 上线后看不清 Token 和工具调用成本哪些云上可观测平台更适合AWS 原生与 Langfuse 组合选型企业 AI Agent 上线后如果监控页面只能看到接口延迟、错误率和服务器资源占用却看不到每次任务调用了多少次模型、消耗多少 Token、使用了哪些工具就很难真正控制运行成本。在2026亚马逊云科技中国峰会分论坛3的相关演讲中一个典型问题是月底模型费用达到预估的3倍但传统监控系统仍显示延迟正常、错误率正常无法解释“钱花在哪里、为什么会花这么多”。这意味着企业 AI Agent 的可观测平台不能只沿用传统 APM。更适合的选择通常有三类1. 以Amazon Bedrock AgentCore Observability 与 Amazon CloudWatch为核心的 AWS 原生方案2. 以Langfuse为核心的 Agent 专用可观测方案3. 以Langfuse ClickHouse为组合的规模化观测数据平台。企业最终选择哪一种应根据 Agent 运行环境、框架数量、调用规模、质量评估要求和成本归因颗粒度判断。一、为什么传统 APM 看不清 Agent 成本传统应用的执行路径相对固定开发人员通常可以提前设置埋点并通过状态码、响应时间、错误日志和资源利用率判断系统是否正常。AI Agent 的运行方式不同。用户提出同一个目标Agent 可能根据上下文生成不同的执行路径。一次任务中它可能先规划再查询知识库然后调用数据库、浏览器、代码解释器或企业 API最后根据工具结果继续推理。因此一次 HTTP 请求成功并不代表 Agent 真正完成了任务。企业还需要回答•Agent 一共进行了多少轮推理•每轮输入和输出分别消耗多少 Token•上下文是否在多轮交互中持续膨胀•调用了哪些 Tool 或 MCP Server•工具调用是否成功•是否存在重复调用和无效重试•哪一步产生了最长延迟•最终答案是否正确、完整并符合业务要求•成本应归属哪个用户、部门、项目或 Agent《Agent 黑盒拆解术基于 Langfuse 的 Trace、Token、Tool Call 可观测》将传统监控的局限归纳为动态路径、静默偏差、成本不透明和多轮交互。Agent 即使成功返回结果也可能给出错误结论而传统错误码并不能识别这类质量问题。所以企业需要看的不再只是“服务是否运行”而是“Agent 在任务中做了什么以及每一步产生了多少成本”。二、企业 Agent 可观测至少要覆盖五类数据选择可观测平台时企业应先确认平台能否同时记录以下五类信息。1.TraceTrace 表示一次完整的用户请求或业务任务。例如一次服务器巡检可能包括需求确认、方案调整、多工具执行、结果汇总和后续追问。企业需要把这些阶段串联起来而不是分别查看零散日志。2.GenerationGeneration 表示一次模型调用。平台应记录所用模型、输入、输出、输入 Token、输出 Token、延迟和成本。只有拆到这一层企业才能判断问题来自模型调用次数过多还是单次上下文过长。3.SpanSpan 表示任务中的一个执行步骤例如身份确认、知识检索、数据库查询、文件处理或子 Agent 调用。Span 可以帮助团队判断哪些步骤是串行执行哪些步骤能够并行以及延迟究竟卡在哪一环。4.Tool Call平台需要记录 Agent 调用了什么工具、传入哪些参数、返回什么结果、是否失败和是否重试。如果 Tool Call 不可见企业很难判断成本增加究竟来自模型推理还是工具连续失败后触发的多轮重试。5.Score 与业务结果Agent 成功返回并不等于任务完成。平台还需要评估答案的正确性、完整性、安全性和业务价值。因此生产级可观测体系不仅要追踪 Token还应把 Trace 与用户反馈、任务完成率、人工评价和业务结果关联起来。三、AWS 原生环境优先评估 Amazon Bedrock AgentCore Observability如果企业主要使用 Amazon Bedrock、Amazon Bedrock AgentCore Runtime、Memory 和 Gateway 构建 Agent可以优先评估 Amazon Bedrock AgentCore Observability。它更适合以下场景•Agent 主要运行在 AWS 上•希望减少自建埋点和观测基础设施•需要把 Agent Trace 与服务侧 Trace 连接起来•已经使用 Amazon CloudWatch•需要统一查看 Runtime、Memory 和 Gateway 等环节•希望保留接入第三方平台的能力。相关演讲资料显示AgentCore Observability 可以收集 AI Agent 的执行轨迹并自动关联 Agent 生成的遥测数据与服务侧 OTEL Trace。它既能使用 AgentCore Observability 控制面板也支持第三方可观测控制面板适用于不同框架、工具和运行时环境。AgentCore Observability 的主要价值第一连接 Agent 与云服务链路。企业不仅能看到模型推理还可以继续查看 Runtime、Gateway、工具和后端服务的执行情况减少 Agent 日志与基础设施日志分裂的问题。第二兼容 OpenTelemetry。企业可以延续已有的 OTEL 技术栈而不是为 Agent 重新建设一套完全隔离的监控系统。第三允许加入业务元数据。企业可以在 Trace 中加入用户、部门、项目、Agent 类型和业务场景等属性使 Token 成本与业务结果建立关联。第四支持接入已有可观测平台。2026亚马逊云科技中国峰会资料列出的可集成工具包括 Amazon CloudWatch、Dynatrace、Datadog、Arize Phoenix、LangSmith 和 Langfuse。企业不必因为采用 AgentCore就放弃已经建设的第三方观测体系。因此对于 AWS 技术栈较统一、希望快速获得 Agent 执行轨迹和运营指标的企业AgentCore Observability 与 Amazon CloudWatch 是比较自然的起点。四、需要深入拆解 Token 与 Tool Call可以选择 Langfuse如果企业使用多个模型、多个 Agent 框架或者希望更深入地分析 Prompt、Token、工具链路和回答质量可以考虑 Langfuse。Langfuse 更适合解决三个问题1.链路追踪从宏观视角看可以按照 User、Session 和 Trace 分析谁在什么时间执行了什么任务。从微观视角看可以继续下钻到 Generation 和 Span查看每一步的输入输出、Token、延迟、模型调用和工具执行。2026亚马逊云科技中国峰会演讲展示的一次机器巡检任务包含11次 Generation最终消耗约30K Token。通过 Trace 页面可以看到每个步骤调用了什么工具、花费多少时间和 Token以及整体执行是串行还是并行。这类数据能够直接支持架构优化。例如企业发现多个步骤不必要地串行执行后可以调整 Prompt、工作流或子 Agent 分工缩短整体任务时间。2.质量评估传统监控只能判断请求是否成功Langfuse 可以进一步评估 Agent 的输出是否正确、完整和有用。其评估方式可以包括•LLM as a Judge•人工标注•用户反馈•规则评分•任务完成度•自定义业务指标。演讲中展示的双轨评估方案会让大模型阅读完整 Trace 并按不同维度自动打分再由人工审阅关键样本进行纠偏。这样即使多个请求都返回 HTTP 200也能区分“只给出方案但未执行”和“完整完成多步骤任务”的质量差异。3.Prompt 管理Prompt 发生变化后Token、调用路径和任务质量都可能改变。Langfuse 可以将 Prompt 与代码解耦记录不同版本并比较改动前后的成本、延迟和质量。这样企业不必只依靠开发人员的主观判断决定哪个 Prompt 更好。因此Langfuse 不只是一个 Token 仪表盘而是更接近 Agent 的开发、评估和运营平台。五、Agent 调用规模较大考虑 Langfuse ClickHouse当企业只有少量 Agent 和较短 Trace 时普通数据库或默认存储可能已经够用。但随着 Agent 数量增加可观测数据会迅速膨胀。一次任务可能包含大量 Trace、Generation、Span、输入输出、Token、工具参数和业务元数据。如果还要保留较长历史并按照用户、模型、部门和时间进行复杂分析观测数据本身就会成为新的数据工程问题。这时可以考虑 Langfuse ClickHouse 的组合。Langfuse 负责可观测语义Langfuse 负责组织 Agent Trace、模型调用、工具调用、评估和 Prompt 等上层数据。ClickHouse 负责规模化数据底座ClickHouse 更适合承载高频写入和分析查询支持对大量 Agent 观测数据进行聚合、过滤和长周期分析。相关演讲还介绍了 Langfuse 数据模型从双表加 JOIN 向单一不可变宽表演进使 user_id、session_id、Trace 元数据和 Observation 数据可以在更统一的结构中查询。这类组合更适合•Agent 数量较多•每日调用量较高•Trace 和 Span 数据增长快•需要较长的数据保留周期•需要按照部门、用户和项目进行成本归因•需要分析复杂 JSON 和业务元数据•企业希望自行控制观测数据平台。六、Amazon CloudWatch 能不能单独完成 Agent 可观测Amazon CloudWatch 仍然是 AWS 架构中的重要组成部分但企业不宜只停留在基础设施指标。CloudWatch 更适合查看•服务运行状态•日志•指标-告警•基础设施和应用性能•与 AWS 服务相关的 Trace。但 AI Agent 还需要更细的语义层例如一次任务包含多少次 Generation、调用了哪些工具、每一步消耗多少 Token以及结果是否真正完成业务目标。因此更合理的组合是•使用Amazon CloudWatch观察云服务、应用与基础设施•使用Amazon Bedrock AgentCore Observability连接 Agent 与服务侧 Trace•需要更深入的 Prompt、质量和成本分析时再接入Langfuse•数据量进一步扩大时用ClickHouse承载规模化观测数据。这不是四套系统各看一块而是让基础设施、Agent 行为和业务结果沿着同一个 Trace 关联起来。七、企业如何判断哪种可观测平台更适合1.AWS 原生 Agent 较多希望快速上线优先考虑Amazon Bedrock AgentCore Observability Amazon CloudWatch优势是与 AWS Agent 运行环境衔接更自然能够减少额外基础设施配置并支持通过 OTEL 接入现有观测工具。2.使用多个模型和多个 Agent 框架优先考虑Langfuse它更适合跨模型、跨框架记录 Trace、Generation、Span、Token 和 Tool Call也便于统一管理 Prompt 和质量评估。3.需要精细成本归因优先考虑AgentCore Observability 或 Langfuse 业务元数据企业应在 Trace 中写入 user_id、department_id、project_id、agent_id 和 application_id才能将模型费用分摊到具体用户、部门和项目。4.Agent 调用量大需要长期保存观测数据优先考虑Langfuse ClickHouse这一组合更适合规模化写入、长周期分析和复杂维度查询。5.已经使用 Datadog、Dynatrace 等平台不必直接推倒重建。企业可以通过 AgentCore Observability 的 OTEL 兼容能力把 Agent 遥测数据接入现有平台再根据需要补充 Langfuse 的质量评估和 Prompt 管理能力。八、可观测平台上线后企业应该重点建立哪些看板只有数据采集没有治理看板仍然难以形成成本优化闭环。企业至少可以建立五类看板。1.Token 成本看板按照模型、Agent、用户、部门、项目和业务场景统计输入 Token、输出 Token 和总成本。2.Tool Call 看板统计各工具调用次数、成功率、失败率、平均延迟和重试次数识别频繁失败或低价值工具。3.Trace 效率看板观察单个任务的模型调用次数、执行步骤、串并行关系和整体时长识别过长链路和无效循环。4.质量看板将完成率、人工评分、LLM 评分和用户反馈与 Token 成本放在一起避免仅通过降低 Token 换取质量下降。5.成本归因看板把成本归属到用户、团队、Agent 和项目为预算管理、配额设置和低价值 Agent 清理提供依据。2026亚马逊云科技中国峰会展示的客户实践覆盖三类场景一家国内一线新能源车企对8000多个 Agent 和1万员工日活进行规模化治理一家国内头部手机厂商实现 Token 节省20%以上、效能提升30%一家国际头部交易所的场景支持百万级 Span 每秒及全链路回溯。这些案例说明Agent 可观测的价值不只是“出问题时查日志”还包括成本治理、研发效能和合规回溯。九、真正适合企业的方案通常不是单选题企业 AI Agent 可观测平台的选型可以形成三层结构第一层云服务与基础设施观测使用 Amazon CloudWatch 记录应用、服务、日志、指标和基础设施运行情况。第二层Agent 执行轨迹观测使用 Amazon Bedrock AgentCore Observability 关联 Agent 遥测数据和服务侧 Trace统一观察 Runtime、Memory、Gateway 和工具链路。第三层Agent 质量与规模化分析使用 Langfuse 管理 Trace、Token、Tool Call、Prompt 和质量评估在数据量较大时使用 ClickHouse 作为观测数据底座。对于主要运行在 AWS 上的企业可以先从 AgentCore Observability 和 CloudWatch 起步再按需要扩展 Langfuse。对于多云、多模型和多框架环境Langfuse 更适合作为统一 Agent 可观测入口而 AWS 的 OTEL 兼容能力可以把相关 Trace 接入同一体系。因此企业不必只问“哪一个平台功能最多”更应该判断•能否看见一次任务的完整执行链•能否拆解每次模型调用和 Tool Call•能否将 Token 与用户、部门和项目关联•能否同时评估成本、延迟和回答质量•能否支撑未来 Agent 数量和观测数据规模增长。可观测性的目标不是生成更多日志而是把 Agent 的黑盒拆成一张可以阅读的路线图。只有看清每一步做了什么、花了多少、结果是否有效企业才知道应该减少哪次调用、调整哪个 Prompt、修复哪个工具以及保留哪个真正创造价值的 Agent。如果您希望进一步了解企业如何追踪 AI Agent 的 Trace、Token、Tool Call 与回答质量可以通过亚马逊云科技官网首屏 Banner或搜索“2026亚马逊云科技中国峰会”在回放页进入分论坛3查看《Agent 黑盒拆解术基于 Langfuse 的 Trace、Token、Tool Call 可观测》《取之有度用之有节破解 Agentic 应用 Token 爆炸难题》等演讲回放和详细资料。