运维的数据早就齐了——指标、日志、Trace、变更、CMDB 都在线上，但一个告警落地后，人仍要跨多个平台拼上下文、做初判、推处置。瓶颈不在工具覆盖度，在事件处理链路没被系统串起来。
我们没有把工具都挂到一个问答框里，而是把运维事件做成一等公民：告警、巡检、变更、应急触发后，先由确定性 pipeline 完成上下文预取，再交给 Agent 做归因推理与方案生成，并且在上下文中持续更新运维事件的状态。
但跑通一次只是起点。运维场景的长期难题是经验只沉淀在个别人身上、同类误判反复出现。所以我们把改进助手本身也做成闭环：从事件处理过程中提取运维经验，在同类事件中召回复用，用线上反馈驱动迭代，并配套可回归、可回滚的验证机制。体系已在公司多条核心业务线的大盘巡检、告警初判、应急定位场景落地。本次分享会讲清这套运维事件驱动的Agent架构，以及如何让运维Agent能持续进化。

演讲提纲：

1. 为什么工具都齐了，运维还是这么累
   • 一个告警到闭环要走十来步，真正耗时的不是决策，而是前面重复的信息查询和上下文拼接
   • DevOps 解决交付协同，AIOps 解决发现异常，但还没有理解事件的处理流程
   • 一个判断：Agentic AIOps 的第一个技术问题不是选模型，是上下文从哪来
2. 事件驱动而非对话驱动：运维助手的架构内核
   • 为什么不做运维版 ChatGPT：对话入口只服务"我主动问"，而运维的高价值场景是事件自己找上门
   • 运维事件与上下文的交互机制
3. 领域经验怎么进助手：Skill 与记忆的双层沉淀
   • Skill 承载流程，记忆承载结论，两者的边界与各自的适用场景
   • 关键设计是作用域绑定团队而非个人
4. 运维助手的自进化
   • 自进化的切入点：运维经验
   • 运维经验的提取、召回与迭代
   • 怎么验证效果：运维助手的评测能力
5. 总结与展望
   • 快手AgenticOps的实现路径和效果总结
   • 下一步：处置边界继续扩大，让助手从辅助判断走向风险可控的自主处置

实践痛点：

1. 上下文该放什么，运维事件可关联的信息几乎没有边界，放多了撑爆上下文、稀释注意力，真正的证据被淹没；放少了缺失关键信息，归因直接跑偏。
2. 人工沉淀下来的知识会劣化，业务写好的 Skill 和知识，随着时间推移和架构演进逐渐不再适配，助手会稳定地按过时的步骤做错事——怎么防劣化，甚至让它自己持续优化。
3. 运维 Agent 怎么评测。 只看准确率、时延或关键步骤达成率都不足以判断一次改进的好坏，而运维依赖的时序数据会过期，昨天的告警今天已经回放不出当时的现场。

演讲前沿亮点：

1. 以运维事件为一等公民而非以对话为入口，配合确定性上下文预取，让运维模式由"人决定查什么"变成"系统先跑一遍、人做确认"。
2. 自进化的对象是结构化的运维经验而非模型权重，反馈只回流到可 diff、可审计、可单独回滚的经验资产上，因此"助手为什么变好了"和"这次为什么变坏了"都能追溯到具体某次变更——这是低容错场景做自进化的前提。

听众收益：

1. 一套 Agentic Ops 的完整落地架构：事件模型、上下文预取、经验沉淀与自进化闭环，以及每个环节的取舍依据。
2. 一条不依赖模型微调的 Agent 自进化路径：运维经验怎么提取、怎么召回、怎么迭代、怎么验证效果。