Agent 在生产环境中的应用，因其“模型 + 数据 + 工具链”的复杂黑盒特性，普遍面临故障排查困难、性能优化缓慢、成本与质量难以平衡的挑战。为解决此问题，我们构建了一套从端到端可观测到工程化闭环的 Agent 质量保障体系。方案通过统一探针OneAgent实现从 App/Web/小程序到 AI 网关、Agent、工具乃至 LLM 的全链路 MTL 统一采集，打通了观测数据的孤岛。基于此，我们建立起从观测数据加工与转换、到故障排查与性能优化的工程闭环，实现从埋点到根因的快速定位。同时，观测数据的回流与离线/在线评测、Agent 轨迹评测相结合，驱动了 Agent 的持续改进与成本优化，为 Agent 的可靠、高效、经济运行提供坚实保障。

演讲提纲

1. 背景与挑战：当 Agent 遇上生产环境

• Agent 的“黑盒”特性：不只是代码，更是模型与数据的结合体
• 我们面临的核心问题：排障难、优化慢、成本失控、质量不可靠

2. 端到端可观测

• 全链路 Trace 打通：从用户终端(App/Web/小程序) -> AI网关 -> Agent -> 工具调用 -> LLM 的全链路追踪
• MTL 统一采集：通过统一探针OneAgent，实现 Log、Trace、Metric 数据的高效采集
• 观测数据加工、转换和管理：如何灵活的进行加工转换，生成更贴近观测目标的数据，并提供体系化的指标管理能力
• 故障排查与性能优化：观测数据之上的故障排查与性能优化分析能力

3. 统一与预置：提升可观测性平台的工程效率

• 全栈可观测门户：在一个界面看尽所有，从业务大盘到单次 Trace到云产品观测
• 统一的集成中心：提供标准化的数据接入与治理能力，支持不同来源、不同形态的观测数据统一接入，通过预置的解析与校验规则，确保多源数据的口径一致性与高质量
• 预置看板：为典型 Agent 场景（如 RAG、代码生成）提供开箱即用的分析视图
• 预置告警规则注入：新 Agent 服务上线时，自动获得一套基础告警规则（如高延迟、高失败率）

4. 数据回流与评测：Agent 的质量保障体系

• 数据回流：打通观测体系与评测体系的最后一公里
• 在离线评测：如何利用观测数据回流的评测集，对 Agent 进行效果比对与回归检测
• Agent 轨迹评测：如何验证 Agent 决策链条的合理性

5. 总结与展望

您认为，这样的技术在实践过程中有哪些痛点？

• 跨端 Trace 关联复杂
• 采样策略与性能开销的平衡
• 观测口径不一致
• AI 指标的定义与验证难
• 评测体系的置信度与维护成本

演讲亮点

• 从“黑盒 Agent”到“可解释系统”的端到端打通
  • 从端侧(App/Web/小程序)一路打到 AI 网关、Agent、工具、LLM，配合 OneAgent 的 MTL 统一采集，让本来高度黑盒的 Agent 链路变得可追踪、可还原、可解释。
• 观测数据加工 + 故障排查的工程化闭环
  • 不停留在“看到数据”，而是通过观测数据加工和转换，叠加故障排查与性能分析能力，给出一套“从埋点到数据、从数据到根因”的工程实践，而不是泛泛而谈的可观测性概念。
• 统一门户 + 集成中心 + 预置化能力，支撑多场景复用
  • 通过全栈可观测门户和统一集成中心，将服务端、客户端、云产品、AI 应用观测打在一个界面，并用预置看板、预置告警规则，把典型 Agent 场景沉淀成可复用资产，降低新团队、新 Agent 的接入门槛。
• 数据回流驱动的评测体系，而不是“拍脑袋调参”
  • 依托观测数据回流构建评测集，在离线评测阶段做版本对比与回归，在在线评测阶段基于真实 Trace 做持续质量监控，再结合 Agent 轨迹评测验证决策链条，把“观测”变成“可量化的优化循环”，真正形成质量保障闭环。

听众收益

• 一套可落地的 Agent 可观测性架构蓝图
• 可直接复用的工程实践清单与踩坑经验
• 观测—数据回流—评测一体化的思路模板

2025 年，Qwen/Deepseek 等为代表的开源模型能力接近闭源模型，vLLM/SGLang 等为主流推理引擎的飞速进化使得推理成本大幅下降，掀起了全年 Agent 应用的火爆。大模型驱动的推理链路，呈现出多语言，异构技术栈等复杂特性，原有的微服务可观测体系存在明显盲区，全链路全栈可观测性面临巨大挑战。对于链路中关键节点推理引擎，传统请求粒度的 Trace 无法下探 Token 粒度生成过程，让引擎相关的性能优化以及生产稳定性定位困难重重。在此背景下，蚂蚁可观测团队率先构建了业界首个覆盖全链路、全栈、Token 级的深度可观测体系，将可观测性从宏观请求下沉至微观 Token 维度，实现对推理全过程的白盒化透视。我们不仅实现了对每个 Token 生成过程及候选概率分布的精细化观测，还创新地引入多请求并发分析能力，分析多租户请求间的干扰。该体系已在生产大规模稳定运行，观测开销控制在千分点，问题定位效率提升 10 倍以上，填补了社区空白。本次演讲我将系统分享我们在大模型推理可观测性领域的前沿探索与工程实践，涵盖核心架构设计、关键技术突破、典型场景案例及未来演进方向，为行业构建下一代 AI 基础设施提供可复用的方法论与技术参考。

演讲提纲

1. 大模型时代 - 可观测性面临范式重构

• 链路盲区：多语言、异构技术栈等带来的观测盲区
• 引擎黑盒：请求 Trace 粗粒度可观测的局限

2. 从业务到引擎 - 全栈全链路架构与核心技术

• 全栈全链路的技术挑战
• 整体架构
• 产品实践

3. 引擎显微镜 - Token 级深度可观测

• 性能可观测：Token 生产耗时过程拆解
• 精度可观测：实时捕获候选 Token 候选概率分布
• 极致轻量：不采样以及千分点开销的高保真观测
• 产品实践与典型案例

4. 引擎广角镜 - 多请求并发分析

• 并发导致的性能劣化
• 多请求并发分析
• 产品实践与典型案例

5. 社区贡献：覆盖三大主流引擎，形成 Trace 统一可观测标准

6. 总结与展望

您认为，这样的技术在实践过程中有哪些痛点？

深入引擎内部埋点，覆盖多个主流引擎/异构硬件，维护成本较高。

演讲亮点

业界首个覆盖多引擎、Token 级的深度可观测 Trace，将可观测性从宏观请求下沉至微观 Token 维度，实现对引擎内部 Token 生产过程的白盒化透视。在生产环境大规模运行，实时采集，观测开销控制在千分点。

听众收益

• 掌握大模型推理全链路、全栈可观测的架构设计思路
• 获得 Token 级推理可观测的工程实现方法
• 了解在主流推理引擎 vLLM/SGLang 社区-可观测方面的工作

Agent 在生产环境中的应用，因其非确定性推理与动态工具交互的特性，普遍面临质量难以量化、问题发现滞后、优化方向不明确的挑战。一个案例是：某旅游搜索 Agent 用户参与度下降 15%，传统监控显示所有技术指标正常，但用户体验持续降级长达 7 周才被发现和修复。根本原因在于缺乏系统化的评估体系。

为解决此问题，我们构建了一套从离线评测到在线监控的 Agent 评估工程体系。通过 Ground Truth + LLM-as-Judge 的混合评估范式，覆盖从单次响应到完整会话的多层次评估；建立能力评估 → 回归评估 → 生产监控 三阶段演进路径，将评估融入从开发到生产的全生命周期；结合可观测性数据实现自动化采样评估，从" 4 周发现问题 + 3 周修复"缩短到" 2小时发现 + 1 天修复"。同时，通过评估任务设计的最佳实践、非确定性处理方法（pass@k/pass^k）、以及评估器校准机制，为 Agent 的可靠、高质量运行提供坚实保障。

演讲提纲

1. 开场：从"盲目调优"到"数据驱动"

• 真实案例：旅游搜索 Agent 的 7 周隐形降级
  • 用户参与度下降 15%，无效反馈增加 23%
  • 传统监控盲区：响应时间、错误率全部正常
  • 根本原因：缺乏系统化的评估体系

2. Agent 评估的本质挑战

• 为什么传统测试方法不够用？
  • 非确定性：同一输入产生不同输出
  • 主观性：有用性、语气等难以量化
  • 多维度：需同时评估正确性、效率、成本
• 旅游搜索 Agent 的评估缺失
  • 工具调用成功率 98%（技术指标正常）
  • 工具选择准确性从 92% 降至 67%（质量指标异常）
  • 如果有评估体系：提示词修改前就能发现问题

3. Agent 评估工程的方法论

• 评估的两种范式：Ground Truth vs LLM-as-Judge
• 评估的三个层次：Output, Trace , Session
• 评估体系的构建流程（核心方法论）: 能力评估/回归评估/生产监控
• 评估任务设计的最佳实践：任务来源真实，任务质量要严格，评估器要校准。完整案例：客服退款场景的评估设计
• 处理非确定性：pass@k 与 pass^k
• 结合可观测性的自动化评估

4. 工程实践与落地路径

• 从零到一：构建评估体系
• 工具选型建议：评估框架/可观测性平台/选型原则
• 真实案例：三个不同场景 Agent 的评估设计：编码,、客服、研究
• 避坑指南

5. 总结与展望

您认为，这样的技术在实践过程中有哪些痛点？

• 评估任务设计的质量控制难
• LLM-as-Judge 的可靠性与成本平衡
• 非确定性带来的评估复杂度
• 评估与开发流程的集成难度
• 生产环境评估的采样策略与性能开销

演讲亮点

• 从"问题驱动"到"方法论沉淀"的完整路径
  • 以真实生产事故（7周降级）开场，引出评估体系的必要性
  • 系统化讲解评估方法论：两种范式、三个层次、三阶段演进
  • 提供可落地的 8 周实施路线图，而不是泛泛而谈的概念
• Ground Truth + LLM-as-Judge 的混合评估范式
  • 不是简单的"用 LLM 评估一切"，而是根据场景选择合适的评估方式
  • 提供完整的客服退款场景 YAML 案例，展示如何设计多层次评估
  • 讲解评估器校准机制，确保 LLM-as-Judge 的可靠性
• 自动化评估 + 可观测性数据的工程化闭环
  • 不停留在"手动运行评估"，而是通过可观测性数据实现自动化采样评估
  • 完整代码示例：从采样 → 评估 → 告警 → 诊断的全流程
  • 效果量化：7周 → 2小时发现 + 1天修复，展示实际价值
• 处理非确定性的 pass@k 和 pass^k 方法
  • 深入讲解 Agent 非确定性带来的评估挑战
  • 提供 pass@k（至少一次成功）和 pass^k（全部成功）两种指标
  • 明确不同产品场景的指标选择：开发阶段 vs 生产部署
• 三个不同场景的评估设计案例
  • 编码 Agent、客服 Agent、研究 Agent 的评估设计对比
  • 展示评估方法论在不同领域的适用性
  • 提供可复用的评估设计模板

听众收益

• 一套可落地的 Agent 评估体系构建方法论
• 可直接复用的工程实践清单与踩坑经验
• 自动化评估 + 可观测性数据的集成思路
• 处理 Agent 非确定性的量化方法
• 真实生产案例的诊断与优化经验

随着 AI Agent 在小红 ToC、ToB 以及内部平台场景的规模化落地，传统 DevOps 体系面对 Agent 已经开始”水土不服“，Agent 的故障模式从”异常型“转型向”漂移型“，可用性和效果劣化问题并存，有可能可用性监控一切绿灯，但是用户体验逐渐下降。其根本原因在于 Agent 的变更单元从单一代码扩展为 Prompt、Model、Skill/Tool、Knowledge 等多种组合，任意维度的变化都可能引发效果的不可预期波动，而传统的监控、测试手段难以有效覆盖。

为此，我们需要构建一个面向生产的 AgentOps 工程体系，聚焦解决三类核心问题：Agent 如何从黑盒转向可控、工程迭代的闭环问题、线上效果的观测与持续优化。在 AI 应用观测的基础上，我们建设了以评估为中心的可靠性体系，通过离线+在线双轨评估，实现上线变更的自动化拦截，并针对不同业务场景建立从线上 Good/Bad Case 自动回流到评测数据集的机制，形成迭代与验证的正循环。

本次分享我会结合小红书在 AgentOps 领域解决的痛点问题，详细分享其中的工程落地实践，希望能给听众带来一些启发和思考，欢迎多多交流。

演讲提纲

1. 为什么需要 AgentOps

• Agent 应用在小红书的现状
• Agent vs 传统软件：工程挑战的本质差异
• AgentOps 的行业趋势
• AgentOps 技术架构全景

2. 面向 Agent 的可观测性体系建设

• Agent Runtime：为 Agent 量身定制的"操作系统"
• 以评估为中心，驱动 Agent 可靠性建设

3. AI 应用评估在不同业务场景的建设和落地

• 为什么需要 AI 评估？
• AI 应用评估的整体设计
• 高质量数据：评估体系的地基
• 在线 + 离线双轨评估：两条腿走路
• 业务最佳实践

4. 未来规划

您认为，这样的技术在实践过程中有哪些痛点？

• 评测数据集的维护是一个被严重低估的长期成本，不仅需要结合多种方式获取高质量的数据，而且需要保持持续运营
• Agent 实现内部是百花齐放的，对于评估工程来说难以覆盖所有用户场景
• Judge 的评估成本与延迟，需要在成本和性能之间平衡

演讲亮点

• 面向未来 AgentOps 工程体系的建设思路，解决效果可靠问题
• 以 Agent 可用性和效果为目标，建设可归因、可回放、可评估 Agent 可观测体系
• 构建以 AI Trace 为核心的数据底座，实现在线 + 离线的双轨评估机制，构建 AI Agent 迭代的工程闭环

听众收益

• 了解 AgentOps 工程体系的建设思路
• 了解评估工程的方法论和生产落地实践经验
• 获取实操层面的 tradeoff 分析与应对方案

当我们将 Agent 从原型推向核心生产系统时，真切遇到了传统软件体系无法解决的落地难题：Agent 的非确定性推理、动态工具交互形成了 “语义黑盒”—— 故障发生时查不到决策断层、优化时缺细粒度数据、多 Agent 协同后复杂度失控。更关键的是，QPS、延迟等传统指标根本无法衡量 “任务能不能成、决策合不合理”。我们在多个重要业务场景中踩过服务不稳定、质量漂移、成本超支的坑，最终意识到：必须针对 Agent 特性，从可观测和评估两个维度搭建落地保障体系。本次分享将复盘阿里云对内对外多业务场景的实践经验 —— 如何从 0 到 1 构建可落地的观测与评估方案，破解 Agent 生产落地的核心困局。

演讲提纲

1. 从原型到生产，我们踩过的 3 类核心坑

• 不确定性：用低代码和高代码不同范式落地长周期多轮交互场景时，状态管理混乱、异常无法恢复、推理链路不固定等等
• 观测痛点：线上服务首包响应慢、成本不可控，但传统监控看不到 完整的Agent 执行链路
• 评估缺失：Agent 上线后质量逐渐退化，新功能发布导致部分场景不可用

2. Agent 可观测体系生产落地全流程实践

• 数据采集：AI 场景采集挑战以及解法
• 全链路追踪：跨系统打通的实操技巧
• 领域建模：数据关联的落地经验

3. Agent 评估体系从 0 到 1 搭建与闭环优化

• 评估价值：为什么传统测试没用？
  • 用传统软件测试方法评估 Agent，出现 “质量验证手段失效”，“评估结果与用户反馈严重脱节”，“无法覆盖长尾意图” 的若干问题
• 评估准备：我们试过的方案与取舍
  • 数据对比：LLM-as-Judge vs Code-as-Judge vs 人工标注的适用场景，多种混合评估方式兼顾以及置信度交叉验证
  • 实践总结：选择高质量评估模板经验总结，构建黄金数据集核心原则，满足应用生命周期不同阶段的评估需求
• 评估架构：自动化落地的关键步骤
  • 搭建流程：评估运行时环境部署→Experiment多版本并行配置→评估器综合设置，实现评估结果到调优动作转化路径
  • 避坑指南：如何解决“评估覆盖不充分”、“评估结果不可复现”、“批量评估耗时过长等待” 等问题
• 闭环优化：嵌入全生命周期实践
  • 落地路径：将评估嵌入 “开发→测试→上线→运维” 的关键节点，基于效果度量机制设定 Agent 应用质量准入门槛的最佳实践

4. 案例分享：阿里云内部落地实践案例

5. 实践反思与未来探索

• 演进：Multi-Agent 协同场景中，跨智能体链路追踪以及执行轨迹的观测实现
• 思考：在长上下文多轮对话中，用户意图演化导致评估指标失效的应对思路
• 探索：尝试 “基于业务特征自动推荐评估策略”，降低人工成本的自动化机制

您认为，这样的技术在实践过程中有哪些痛点？

• 不同语言技术栈及 AI 框架（如LangChain、LlamaIndex等）快速演进，导致埋点适配成本高、数据格式碎片化
• 全链路追踪中客户端与服务端实体缺乏统一语义元信息（如session_id、user_id、Agent_id），难以有效关联
• Agent 实现路径多样、依赖环境复杂，难以覆盖长尾用户意图等，高质量评估常面临冷启动困难与基准缺失痛点

演讲亮点

• 全程基于核心业务场景的真实落地经验，复盘 “踩坑→解决→迭代” 的完整过程
• 基于多个真实生产场景的迭代经验，总结出可复用的 Agent 观测以及评估实操流程

听众收获

• 掌握构建面向 Agent 特性的可观测核心能力，从效果、性能、成本等维度建立生产级实践
• 理解 Agent 效果评估的关键设计原则，具备从 0 到 1 构建可落地、可扩展评估落地踩坑经验

当 Agent 从"能用"走向"好用"，强化学习（RL）成为关键路径——但 AI Agent 的执行链路正在变得前所未有的复杂——LLM 推理产生意图，Agent 框架编排决策，沙箱平台调度容器，运行时执行系统调用——但现有的可观测工具只能看到其中的碎片。APM 看到 HTTP 请求，K8s 看到 Pod 生命周期，日志系统记录文本片段，没有任何一个方案能回答最核心的问题："Agent 想做什么？实际做了什么？结果怎样？"

本次演讲将分享我们如何基于 eBPF 构建覆盖"LLM → Agent → 沙箱平台 → 运行时"全链路的无侵入式可观测体系。eBPF 工作在内核层，天然穿透所有基于容器的沙箱实现，不需要 Agent 修改一行代码，不需要沙箱预装任何组件。我们将完整展示这套体系如何打通四个观测层：在 LLM 层还原每次对话的 Token 消耗与延迟；在 Agent 层关联意图与行为；在沙箱平台层通过审计日志与运行时事件的时空关联建立完整 Trace；在运行时层捕获每个命令的 Stdio、退出码和资源消耗。所有数据通过 OTLP 标准协议输出，可直接接入 Jaeger、Grafana 等现有可观测基础设施，同时为 RL 训练提供结构化的 Reward Signal。

演讲提纲

1. 为什么 Agent 需要一种全新的可观测方案

• 现有工具问题：APM 看 HTTP、K8s 看 Pod、日志看文本，串起"想做什么→做了什么→结果怎样"
• Agent 的执行链路跨越四个层：LLM 推理、Agent 编排、沙箱调度、运行时执行，每一层都有独立的上下文
• 沙箱是 Agent 安全执行的基石，但也是可观测性断裂最严重的边界
• 零侵入是刚需：不能要求每个沙箱镜像预装 SDK，不能要求 Agent 框架改代码
• eBPF 方案的优势：海量并发下的零侵入采集、内核态高效过滤、零进程重启，适配多种沙箱环境

2.  深度感知：构建 Agent 执行的"全息画像"

• 监控工具调用从 fork 到 exec 到 exit 的完整生命周期，构建进程树，识别异常退出的子进程
• 捕获 stdout/stderr 的关键输出，直接获取工具执行的原始回显，这是判定 Agent 行为真实性的核心依据
• 精确统计每个执行步骤的 CPU 时间和内存（RSS）微观波动，量化 Agent 解决问题的"效率成本"
• 通过 eBPF Uprobes 在内存态还原加密的 Prompt 意图与外部 API 调用的真实响应，打通 Agent 与环境的交互盲区
• eBPF 天然穿透所有基于容器的沙箱——Docker、K8s Pod、各类 Agent 专用沙箱，一套方案全部覆盖

3. 打通全链路：从 LLM 对话到内核 Syscall 的完整视图

• LLM 层：通过 eBPF 透明解密 TLS 流量，还原每次对话的 Prompt/Response、Token 用量、首 Token 延迟和请求耗时。在 eBPF 层透明拦截 Agent 的出站 HTTP 请求，自动注入 W3C Trace Context
• Agent 层：自动识别 Agent、Tool、LLM Source 三类资产及其调用拓扑，无需配置声明
• 沙箱平台层：K8s 审计日志与 eBPF 运行时事件的时空关联，将平台侧的调度意图与沙箱内的实际执行精确绑定到同一 audit_id
• 运行时层：捕获沙箱内每个进程的命令行、Stdio 输出、退出码、执行时长、CPU 和内存消耗
• 构建" LLM 对话 → Agent 决策 → 平台调度 → 命令执行 → 子进程链" 的完整 Span 树

4. 数据交付：标准化输出与业务赋能

• 所有观测数据统一导出为 OTLP Traces 和 Metrics，直接接入 Jaeger、Grafana、Datadog 等现有基础设施
• Prometheus 端点暴露 LLM 延迟分布、Token 吞吐（RPM/TPM）、首 Token 延迟、Exec 成功率、资源消耗等运营指标
• 基于 audit_id 的精确查询 API：凭一个 ID 实时获取某次执行的完整进程树、每个命令的退出码、耗时、资源消耗和 stdout/stderr
• 为 RL 场景提供结构化的 Reward Signal：exit_code 作为 Outcome、cpu_time 作为 Efficiency、stdout 与退出码的矛盾作为 Behavior 验证的内核级证据

5. 总结与展望

• 回顾从"沙箱黑盒"到"四层打通"的完整方案，以及在生产环境中的实践效果

您认为，这样的技术在实践过程中有哪些痛点？

• eBPF 的内核兼容性仍是首要落地障碍，CO-RE 需要 5.x+ 内核，部分云厂商定制内核 BTF 信息缺失
• 内核态只能看到系统调用级别的行为，应用内部的推理逻辑仍需协同方案补充

演讲亮点

• 不是单点技术展示，而是完整串联 LLM → Agent → 沙箱平台 → 运行时四层，回答"Agent 想做什么、做了什么、结果怎样"
• eBPF 天然穿透容器边界，一套方案适配所有基于容器的沙箱，不破坏隔离语义
• 结合实际训练场景，构建包含 OTLP 标准输出和 reward 的观测结果，既能接入现有可观测栈，又能支持 RL 训练

听众收益

• 了解一种覆盖 LLM 到 Syscall 全链路的 Agent 无侵入式可观测架构
• 理解 eBPF 为何是沙箱可观测的最优解，以及大规模场景下的性能控制策略
• 在实际训练场景下 Agent 可观测性的实践

目前可观测实践多停留在运行态（指标/日志/链路）层面，能发现异常，却难以快速回答“为什么发生、回滚哪个变更、改哪段代码”。本演讲以腾讯 IEG 的蓝鲸可观测平台实践为背景，提出并落地“Code + Change + Runtime”的全链路可观测实践：打通 CI/CD、PR/Commit 与运行态信号；在同一份数据流之上，分别为运维、运营、管理者构建差异化SaaS 应用；并引入 AI 的代码理解能力，将定位与代码及变更进行关联，实现真正的根因定位，并利用平台实现更多的 AI 提效场景。

演讲提纲

1. 为什么观测平台要做 PaaS 化， 如何打通从研发过程到代码，再到最后的生产环境

• 公司里面不同的角色，对观测数据和企业微信的消费需求是不一样的
• 传统“只做运行态”可观测的天花板：只能更快发现异常，难以定位到变更与代码
• 要进行 PaaS 化 打通从研发过程到代码，才能获得线上环境到 Commet id 的逻辑映射关系

2. 如何在 PaaS 化平台上构建面向 SRE、运营与管理者三大场景

• 运维视角（SRE）：告警降噪、定位提速、止血与回滚决策、复盘沉淀
• 运营视角：影响面量化（用户/订单/转化/核心旅程）、对外口径与运营策略
• 管理者视角：SLO/错误预算、发布风险、稳定性与效率驾驶舱、治理成效

3. 从日志告警到代码级根因分析的解决方案

• 实践方案
  • 蓝鲸监控告警：检测日志异常并触发告警
  • 蓝盾流水线：作为编排引擎联动告警处理，打通线上日志与线下代码仓库
  • Agent（Gemini CLI internal / CodeBuddy）：结合错误日志做代码理解与根因分析，并将结果推送到企业微信
• 核心难点：线上日志如何关联到正确的代码版本？
  • 容器场景的多层关联链：线上日志（Pod/时间）→ Pod 信息 → 镜像版本（app_version）→ Git Commit（commit_id）→ 代码仓库（git_repo）
  • 通过观测平台元数据管理与 CI/CD 构建上报实现自动化版本定位，避免人工维护版本映射
• AI 如何落到流水线里（非交互式、可规模化）
  • 在流水线构建机中使用 Gemini-cli-internal 非交互模式，通过注入 prompt 生成 Markdown 分析报告
  • 输出结构：原始错误日志、可能原因（Top3，带源码片段说明）、总结；并将报告落地为构建产物供推送/留存
• 效果对比（从“10+ 步人工”到“4 步自动化”）
  • 处理步骤：10+ 步 → 4 步（减少 60%+）
  • 人工介入：全程参与 → 仅查看结果
  • 版本切换与代码定位：手动 → 自动关联 + 智能分析
  • 平均耗时：30 分钟~数小时 → 分钟级（提升 10x+）

4. 其他 AI + 观测提效场景

•  Coredump 解析与关联代码
• OpneClaw 在 SRE 场景的应用落地

 您认为，这样的技术在实践过程中有哪些痛点？

• 目前主要的卡点是在信息安全部分，优秀模型均为公网海外的模型，效果的上限取决于模型的上限

演讲亮点

• 大部分的可观测平台不能够实现全链路的打通（这里的全链路不是指从后端到前端，而是指从代码的提交到代码的发布，再到代码运行的全链路。而 AI 最擅长处理的是代码，如果不进行这样打通，AI 的威力其实没有办法很好地发挥。）
• 一条观测数据流统一运维/运营/管理者三大场景（视图不同，底座一致）
• Openclaw 的实践案例， 能帮助到用户实现数字员工的自动化执行

听众收益

• 可复用的全链路方法：Code × Change × Runtime
• 三类角色的落地路径与衡量指标：MTTR、影响面、错误预算/发布风险
• 可以看到大厂在数字员工 OpenClaw 上面的最新实践