Expedia Group 内部 AI 辅助可观测性平台 STAR（Service Telemetry Analyzer）已投入生产使用。该平台通过预定义诊断工作流——而非自主 AI Agent——分析服务遥测数据并生成结构化根因评估。团队明确弃用函数调用、RAG、记忆能力与自主工具调用，核心理由是：生产环境需要可预测、可审计的分析链路。
STAR 已在 Expedia 生产环境中投入使用，覆盖四类核心运维场景：
实时分析服务遥测数据，生成根因评估与建议后续步骤，压缩问题定位时间。
对已解决事故做结构化回顾，输出可归档的诊断报告。
分析容器重启、探针失败等 K8s 层面的异常信号。
针对 Java 堆内存使用率与垃圾回收活动做专项分析。
注：TTK = Time to Know（理解问题所需时间），TTR = Time to Restore（恢复时间）。团队未公开具体降幅数据。
在行业涌向自主 AI Agent 的当下，Expedia 团队做了一个明确的反向选择：
模型自主决策何时调用什么工具，链路动态生成。
预定义诊断步骤，LLM 在固定环节做分析，不做决策。
团队明确说明：当前实现未使用函数调用（function calling）、检索增强生成（RAG）、记忆能力（memory）或自主工具调用。分析结果的一致性，靠的是预定义工作流而非模型自主性——这在生产事故场景中意味着同样的输入，跑出同样的诊断。
STAR 采用提示词链（prompt chaining）机制，允许在生成最终诊断前执行多个专门化分析：
数据来源为 Datadog（服务指标获取）与 Expedia 内部生成式 AI 网关（LLM 访问与身份认证）。平台以 FastAPI 应用形式实现。
架构演进：团队后续将 FastAPI 后台任务替换为基于 Celery 的异步架构，Redis 同时担任消息代理与结果存储后端。原因很直接——大部分处理属于 I/O 密集型操作（遥测数据获取 + LLM 请求），异步模型可并发处理多任务，同时适应 Datadog 与内部 AI 网关的速率限制。
FastAPI 后台任务，同步处理，并发受限。
Celery 异步 + Redis 消息代理 / 结果存储，支持并发与速率限制适配。
STAR 主要关注 Kubernetes 服务与 JVM 应用的标准化基础设施遥测数据。团队强调：基础设施指标能为不同编程语言和框架开发的服务提供统一视角。
提示词管理、追踪与评估能力通过 Langfuse 提供支持；系统性能则通过领域专家评审与用户反馈进行评估。
本文信息来源为 Expedia 工程团队的公开技术博客，属单方披露：平台架构与设计思路描述详尽，但未见第三方独立测试，TTK/TTR 的具体降幅数据也未公开——读者宜将其视为「工程实践参考」而非「效果已验证的方案」。博客同时披露了未来计划（MCP 集成、对话式交互、混沌工程），说明平台仍处于持续迭代阶段。
值得注意的信号是：一家大型互联网公司的生产运维平台，在 2026 年依然选择不用自主 Agent。这不是技术保守，而是生产事故的试错成本不允许链路不可预测。
STAR 为 Expedia 内部平台，暂不对外开放。Expedia 工程团队已公开完整技术细节与架构演进过程，详见公开报道。
文中提及的提示词管理工具 Langfuse 已开源：github.com/langfuse/langfuse