AI可观测性之争的胜负取决于互操作性
内容提要
企业评估AI不能只看模型质量、速度和token成本，更需可靠、可控地交付业务成果。OpenTelemetry的GenAI规范为对话、消息等提供统一语义，减少重复集成，便于比较模型与供应商。衡量AI应关注“每次成果成本”而非单纯token成本，并结合评估与遥测数据判断价值。对AI代理还需监控其工具调用与行为，设置防护措施，确保安全、可控并支撑规模化决策。
延伸解读
标准化不等于统一存储，而是共享语义
文章指出，OpenTelemetry的GenAI规范并不要求所有系统以相同方式存储每个细节，而是要求对关键概念有足够的共享含义，以便比较。这意味着企业无需推翻现有数据架构，只需在对话、消息等核心概念上对齐语义。对于需要跨模型、跨供应商比较AI行为的企业，这种“最小共识”能显著降低集成与切换成本，同时保留各系统在存储和实现上的灵活性。
从token成本转向每次成果成本
文章强调，token计数只能解释花费，不能说明AI支出是否带来有用工作或业务价值。更便宜的模型可能消耗更多token或需要更多重试，而更贵的模型若一次成功反而更高效。因此，企业应定义“成功成果”（如完成工作流或达到质量标准的准确回答），并结合遥测数据衡量每次成果成本。这要求组织先明确成功标准，再利用OpenTelemetry收集的模型调用、延迟、错误等一致数据做判断。
代理可观测性需连接防护措施
对于能选择工具、重试操作并触发动作的AI代理，文章提醒团队不仅要看其是否响应，还要看其行动是否有用、是否遵守安全规则、是否知道何时停止求助。错误动作可能加剧故障并损害客户信任，反复重试则推高成本。因此，代理可观测性应能评估行为并追踪性能与成本，当与执行系统连接时，还可支持阻止有害动作或输出的防护措施。共享遥测能将控制与代理步骤、工具调用及业务影响的证据关联起来。
遥测质量需在投产前可见
文章提到，遥测质量需要在生产前就可见。开源工具Observability Studio提供了一个开发期示例：团队可以检查本地遥测并验证其是否符合OpenTelemetry约定，甚至借助工具添加从一开始就合规的埋点。尽早发现缺失或不一致的数据，可以减少返工，并在故障排查或评估发布时给运维人员更强证据。这提示企业应将可观测性左移，把数据规范验证纳入开发流程，而非等到上线后再补救。
Q&A
为什么说AI可观测性的胜负取决于互操作性？
因为AI应用涉及多个组件（模型提供商、编排框架、检索系统、工具等），每个组件处理对话或代理动作的方式不同，团队需要花费时间统一差异才能调查故障或比较结果。OpenTelemetry提供统一的语义规范，减少重复集成工作，使不同提供商和模型更容易比较，从而支持质量、成本和风险的决策。
OpenTelemetry的GenAI规范具体解决了什么问题？
它描述了常见的对话和消息概念，为AI行为提供统一的语义表示，同时允许大型内容存储在外部并在遥测中保留引用。这减少了为每个集成维护单独数据模型的需要，降低了重复集成工作，使团队能够比较不同提供商和模型，并基于一致数据做出质量、成本和风险决策。
为什么衡量AI成本应该看“每次成果成本”而不是token成本？
Token数量只能解释花费，不能说明AI支出是否与有用工作或业务价值相关。更便宜的模型可能消耗更多token或需要更多重试才能完成任务，而更高成本的模型如果首次尝试就能可靠达到预期结果，可能更高效。因此，每次成果成本是更有用的业务衡量指标。
如何利用评估和遥测数据来判断AI模型是否适合特定任务？
通过OpenTelemetry收集一致的模型调用、延迟、错误、使用量和工具交互数据，结合评估结果（如应用侧评估提供快速反馈，平台侧评估比较不同模型和发布版本），团队可以决定哪个模型适合任务、发布是否提升了性能以及支出在何处产生价值，且不受模型、提供商或工具调用变化的影响。
对于AI代理，可观测性需要额外关注哪些方面？
除了响应，还需关注代理是否采取有用行动、遵守安全规则、知道何时停止并寻求帮助。代理可能选择工具、重试操作、触发动作，错误行动可能加剧故障或损害信任，重复重试可能导致意外成本。可观测性应能评估行为、跟踪性能和成本，并与执行系统连接以支持防护措施，阻止有害动作或输出。
在开发阶段如何确保遥测数据质量？
可以使用开源工具如Observability Studio，在开发时检查本地遥测数据并验证其是否符合OpenTelemetry规范，甚至帮助添加符合规范的插桩。尽早发现缺失或不一致的数据可以减少返工，并为运维人员排查问题或评估发布提供更强证据。
