第28届 4月17-18日 GOPS大会深圳站参会总结

前记:首先感谢公司给买了GOPS深圳站的门票,两天时间参加了不少场次的学习,还是挺有收获的,现在技术大会分享的议题肯定不离AI 智能体和 大模型,笔者听的也基本都是AIOps相关的议题,包含SRE AI Native、故障诊断、Agent/Skills评测、智能变更、智能问答等等,本文基于两天听到的议题作一个总结输出。

一、会上大家经常提到一些概念

1、Vibe Coding 、SDD、Harness Engineering

AI Coding 这两年经历了一个从"好玩"到"能用"到"可规模化"的转变:

Vibe Coding(凭感觉写)→ SDD(规约驱动)→ Harness 工程(工程化体系)

这不是三个并列选项,而是三个递进阶段,反映了行业对"AI 究竟怎么写代码才靠谱"这个问题的认知升级。

1.1 阶段一:Vibe Coding —— "凭感觉"编程

这个词是 Andrej Karpathy(前 OpenAI、特斯拉 AI 负责人)在 2025 年初提出的,一推特就火了。他原话的意思大概是:

"有一种新的编程方式,我称之为 vibe coding——你完全沉浸在氛围里,拥抱指数级增长,甚至忘记代码存在。"

核心是:你不再写代码,你描述你想要什么,让 AI 去写。你只看效果,不看实现。

Vibe Coding 适合一次性原型、玩具项目、个人小工具,但一旦规模化就翻车:

1. 代码质量不可控 AI 写的代码可能能跑,但里面一堆隐藏债务——重复逻辑、安全漏洞、性能陷阱,你不看代码根本不知道。

2. 调试地狱 出 bug 了,你不熟代码,只能不停"让 AI 再试一次",经常越改越烂,最后陷入死循环。

3. 不可维护 一个月后回来加功能,AI 也不认识这堆代码了,因为它当时写完就忘了上下文。

4. 不适合真实工程 团队协作、代码审查、合规、安全,vibe coding 这套完全对接不上。

一句话:Vibe Coding 教会了大家"AI 能写代码",但也暴露了"光让 AI 写代码不够"。

1.2 阶段二:SDD(Spec-Driven Development)—— "规约驱动"编程

行业发现 vibe coding 的根本问题是:人的意图表达太模糊,AI 只能瞎猜。

你说"做个待办事项应用",AI 脑补了一堆假设——用什么框架?数据存哪?要不要登录?多用户吗?每次脑补都是一次赌博。

解法:把"你想要什么"严格地、结构化地写下来,再让 AI 去实现。

这就是 Spec-Driven Development(规约驱动开发) 的核心思想。

SDD 的核心流程

不是上来就让 AI 写代码,而是:

1. 写 Spec(规约)——描述"要做什么、满足什么约束"
        ↓
2. 写 Plan(计划)——拆成具体任务、定义验收标准
        ↓
3. 生成代码——AI 按 Spec 和 Plan 实现
        ↓
4. 验证——用 Spec 里定义的标准验收

SDD 解决了什么

• 意图明确:AI 不用猜,按 Spec 干
• 可验证:有验收标准,知道什么叫"做完了"
• 可审查:Spec 是人看的,Plan 是人审的,代码是 AI 写的,人类在关键节点把关
• 可迭代:改需求 → 改 Spec → AI 重新实现,流程清晰

SDD 的局限

SDD 解决了"一次任务怎么做对"的问题,但没解决:

• 怎么让 AI 在长期复杂项目里保持一致?
• 怎么管理几十个 Agent 并行工作?
• 怎么保证跨团队、跨仓库的协同?
• AI 写的代码怎么自动测试、审查、部署?

这就引出了下一阶段。

1.3 阶段三:Harness 工程 —— "工程化体系"

"Harness" 原意是马具/挽具——把一匹野马变成能拉车的劳动力的那套装置。

在 AI Coding 语境下,Harness 指的是"套在 AI 身上的那套工程化支撑体系",让 AI 从"能写代码的野生模型"变成"能在生产环境里可靠工作的工程师"。

这个词最近由 Anthropic 等公司开始正式化使用,背景是:大家意识到 Agent 的能力边界不只取决于模型本身,更取决于模型周围的"工程脚手架"。

Harness 包括什么

一个完整的 AI Coding Harness 通常有这几层:

1. 上下文工程(Context Engineering)

• 怎么从几十万行代码里挑出相关的给 AI 看?
• 怎么管理长期记忆(MEMORY.md、项目文档、历史决策)?
• 怎么避免上下文污染?

2. 工具层(Tools)

• 文件读写、代码搜索、shell 命令、浏览器控制
• Git 操作、测试运行、部署触发
• 通过 MCP(模型上下文协议)接入企业系统

3. 验证层(Verification)

• 自动跑测试:AI 写完代码立刻验证
• Lint/类型检查:静态约束不让 AI 胡写
• 代码审查 Agent:另一个 AI 审第一个 AI 的代码

4. 沙箱与权限(Sandbox & Permissions)

• AI 能改哪些文件、能跑什么命令、能访问什么系统,都要有边界
• 危险操作必须人类批准(删文件、改生产、调外部 API)

5. 评估与可观测性(Eval & Observability)

• AI 的修改是否真的解决问题?
• 每一步决策的日志、token 消耗、失败原因
• 回归测试防止"改 A 坏 B"

6. 编排层(Orchestration)

• 一个任务拆给多个 Agent 并行做
• 主 Agent 规划,子 Agent 执行,汇总结果
• 失败重试、超时处理、任务依赖

7. 人机协作界面(HITL - Human in the Loop)

• Plan Mode:AI 先给计划,人批准才执行
• Diff Review:人审每一处改动
• 审批节点:关键操作必须人点头

代表性产品和实践

• Claude Code:Anthropic 主推的 CLI Agent,内置了非常多 Harness 能力(Skills、MCP、Plan Mode、权限系统、Hooks)
• Cursor / Windsurf:IDE 形态的 Harness,侧重人机协作
• Devin:试图做成"全自主工程师",Harness 更重,但也因此争议大
• Aider:开源 CLI,轻量 Harness
• Cognition / Factory / Poolside 等:企业级 AI Coding 平台,卖的核心就是 Harness

Harness 工程为什么重要

一个反直觉的结论:同样的模型,换一套 Harness,表现差好几倍。

Anthropic 自己的数据:Claude 在 SWE-bench(真实代码修复任务)上的得分,Harness 贡献的提升不亚于模型升级本身。

这也是为什么现在各家不光卷模型,更在卷怎么把模型用好——Harness 是核心战场。

1.4 三个阶段的对比总结

2、Hermes Agent vs Openclaw

这俩其实是同一物种:自托管的开源个人 AI Agent,都跑在你自己的机器上,都接入多个聊天平台,都用 LLM 做推理,都有持续记忆、自动生成技能(skills)、模型无关。

如果把它俩并排放着,80% 的功能描述是重叠的。

它们在定位、社区气质、技术选型上有一定的差异。

2.1 出身和基因不同

Hermes Agent 来自 Nous Research,一家做开源模型训练的研究实验室。它的气质是"研究者工具"——强调 RL 训练数据生成、tool-calling 模型评测这些偏学术的用途。

OpenClaw 来自奥地利开发者 Peter Steinberger 个人项目。它最早叫 Clawdbot(致敬 Anthropic 的 Claude),2026 年 1 月因 Anthropic 的商标投诉改名 Moltbot,三天后又改成 OpenClaw。基因是"vibe coder 的玩具"——更接地气、更 meme、更面向普通开发者。Steinberger 后来在 2026 年 2 月宣布加入 OpenAI,项目交给基金会。

2.2 社区规模完全不是一个量级

OpenClaw 是现象级爆款。截至 2026 年 3 月 2 日 GitHub 上有 24.7 万 star、4.77 万 fork,增长速度比 Docker、Kubernetes、React 当年都要快。连 NVIDIA 都专门为它做了一个叫 NemoClaw 的安全加固版,腾讯、Z.ai 也推出基于 OpenClaw 的服务。

Hermes Agent 相对小众,主要在 AI 研究和 self-hosting 圈子里流传,量级差了至少一个数量级。

2.3 架构设计上的差异

OpenClaw 是三层架构:Channel 层(消息平台适配器)+ Brain 层(Agent runtime)+ Body 层(工具执行),消息进来后走七步循环:normalize、route、assemble context、infer、ReAct、load skills、persist memory。它的 Gateway 是单个 Node.js 进程,默认只绑定在 127.0.0.1:18789,远程访问必须显式走 SSH 隧道或 Tailscale。

Hermes 的执行后端更强调多样性,提供 local、Docker、SSH、Daytona、Singularity、Modal 六种后端,特别是 Daytona 和 Modal 支持 serverless 持久化(闲时休眠、按需唤醒),更偏"一个 Agent 跑在不同尺寸的机器上"的思路。OpenClaw 的默认思路更"本地化"——跑在你自己的 Mac Mini、树莓派、VPS 上。

2.4 技能(Skills)体系的哲学差异

两者都有 skill 自动生成,但组织方式不太一样:

• Hermes:skill 是 Agent 在完成 5+ 次工具调用后自己总结出来的 markdown 文档,偏自下而上的经验沉淀
• OpenClaw:skill 存储为包含 SKILL.md 文件的目录,可以随软件打包、全局安装或存在 workspace 里,workspace skill 优先级最高,有100+ 内置 skill,更像一个有社区市场的插件生态

这也带来 OpenClaw 独有的安全问题:Cisco 的 AI 安全研究团队测试过第三方 OpenClaw skill,发现有的 skill 会在用户不知情的情况下做数据泄露和 prompt injection,skill 仓库缺乏充分审核。Hermes 因为生态小、skill 主要自己生成,反而没这个问题。

2.5 安全定位截然不同

这是个值得单独拎出来说的区别。因为 OpenClaw 爆火,安全研究界盯得很紧:CrowdStrike 专门发文讲企业安全团队如何识别 OpenClaw 部署、如何评估暴露面,OpenClaw 自己的维护者 Shadow 在 Discord 上警告说"如果你连命令行都不会用,这个项目对你来说太危险了"。

Hermes Agent 因为用户基数小、偏研究者群体,没有这种"被安全厂商围观"的待遇——但这不代表它更安全,只是不够火没被重点盯。

2.6 平台覆盖

两边都覆盖 15+ 消息平台,有相当多重叠(Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost、Email、飞书等)。

细节上 OpenClaw 多了 iMessage、BlueBubbles、IRC、LINE、Nextcloud Talk、Nostr、Synology Chat、Tlon、Twitch、Zalo、QQ、WebChat 这类更杂的渠道,是真按"能接都接"的路子在扩;Hermes 的覆盖更克制、更偏"主流工作场景"。

2.7 一句话总结

Hermes = 研究者社区里的学院派自进化 Agent,偏向训练数据生成和工作流自动化;

OpenClaw = 2026 年破圈的现象级开源 Agent,社区生态大、集成广、但也因此成了安全研究员眼里的重点盯防对象。

3、BizAgent

腾讯云架构平台部运维总监黄小华黄总提到了Agent for human,还是Agent for BizAgent, 黄总提到这里的BizAgent是指Bussiness Agent。

BizAgent = Business + Agent = 面向业务场景的 AI Agent

它是对一大类 AI Agent 的统称,定位不是通用助手,而是在具体业务场景里干具体活的 Agent。

和通用 Agent 的区别

为了理解 BizAgent,先对比一下 AI Agent 的两个大类:

通用 Agent(General-purpose Agent)

• 代表:ChatGPT、Claude、Gemini 的聊天形态
• 特点:啥都能聊,啥都不精
• 定位:个人生产力助手
• 上下文:基本没有行业/业务沉淀

BizAgent(业务场景 Agent)

• 代表:销售 Agent、客服 Agent、风控 Agent、HR Agent、供应链 Agent
• 特点:特定场景下深度集成
• 定位:企业数字员工
• 上下文:深度绑定业务数据、流程、规则

4、Agentic AI

Agentic AI = 能主动采取行动去达成目标的 AI,而不是被动等着回答你问题的 AI。

"Agentic"这个词来自"agency"(能动性、自主性),强调的就是AI 自己能做决定、能动手。

4.1 和普通 AI 的核心区别

关键就一个字:动。

• 传统 AI / 生成式 AI: 你问 → 它答。它是个工具,你用完放下。
• Agentic AI: 你给目标 → 它自己想 → 它自己做 → 做完给你结果。它是个执行者。

4.2 Agentic AI 的几个核心特征

a. 自主性(Autonomy) 不需要一步一步地喂指令,给个大目标就能往下走。

b. 目标导向(Goal-oriented) 能把模糊目标拆成具体步骤。"增加销售 10%"这种话,它能翻译成"先分析现有客户、再找潜在目标、再设计 campaign..."。

c. 工具使用(Tool use) 能调用 API、搜网页、查数据库、发邮件、操作软件。这是它"动手"的基础。

d. 规划与推理(Planning & reasoning) 遇到复杂任务会先想再做,不是一拍脑袋就上。失败了会分析为什么、换个方法。

e. 记忆(Memory) 记得之前聊过啥、干过啥、你喜欢啥,不会每次重头再来。

f. 环境感知(Perception) 能观察状态变化——文件变了、邮件来了、价格动了,它会反应。

4.3 "Agentic AI" vs "AI Agent" 有啥区别?

这俩词现在经常混用,但严格讲:

• AI Agent(名词):指具体的那个系统,比如 Claude Code、Hermes Agent、某个客服机器人。
• Agentic AI(形容词化的概念):指AI 的一种属性或范式,强调"AI 具有能动性"这个特征。

类比:

• "汽车"是名词,"机动化(motorized)"是属性
• "AI Agent"是具体产品,"Agentic AI"是它背后的那种设计理念

所以你会听到:

• "我们公司部署了 3 个 AI Agent" ✅
• "我们正在进入 Agentic AI 时代" ✅
• "这是一个 Agentic AI"(指某个具体产品) ⚠️ 有点别扭但能懂

4.4 为什么现在突然所有人都在讲 Agentic AI

2023 年大家还在聊"生成式 AI(Generative AI)",2024-2025 年整个行业的叙事明显转向了"Agentic AI",原因是:

能力到位了:模型终于聪明到能可靠地执行多步任务、调用工具,不至于中间跑偏。

基础设施到位了:MCP(模型上下文协议)、Function Calling、Computer Use 这些技术让 AI 接管真实系统成为可能。

商业价值到位了:能"回答问题"的 AI 是个工具,值钱;能"完成工作"的 AI 是个员工,更值钱。企业愿意为后者掏更多钱。

焦虑也到位了:谁家不讲 Agentic AI,就显得落后。所以营销层面这个词被用烂了,很多产品明明只是个聊天机器人也硬往上靠。

4.5 大白话总结

• 生成式 AI(Generative AI): AI 会创造内容(写字、画图、出代码)
• Agentic AI: AI 会采取行动(替你把事办了)

前者是脑子,后者是脑子+手脚。

现在行业正从"AI 是个工具"往"AI 是个员工"过渡,Agentic AI 就是这个过渡的名字。

二、AIOps 落地的五大场景

前面讲了一圈概念,接下来进入正题——这两天听下来,行业在 AIOps 上真正在聊的其实就是五类场景。每一类的成熟度、难度、ROI 都不一样,这里按顺序一个个拆开讲。

整体感受:为什么 AIOps的发展 比 AI Coding 的发展慢

腾讯云架构平台部运维总监黄小华黄总一上来就抛了一个扎心的对比——AIOps 的发展明显慢于 AI Coding,各公司落地情况参差不齐,整体还在早期。这背后的原因,其实全场讲师都在反复印证:

一句话:AIOps 不是模型能力问题,是工程范式问题。大模型的幻觉在运维场景被放大得最厉害——代码写错了可以重试,运维错了可能就是故障。

接下来这五大场景,就是行业在这个约束下一步步摸出来的落地路径。

场景一:故障诊断与根因分析

这是 AIOps 最难啃的骨头,也是本次大会讨论最多的场景。

1.1 为什么是最难的

根因分析同时踩中了运维场景的所有坑——精确率要求极高、时效性要求极高、验证标准又天然缺失(一个告警是不是误告,系统不知道)。再加上运维数据输入(日志、指标、链路)和输出(根因结论)都是非结构化的,幻觉在这里的破坏力最大。

腾讯黄小华黄总的处理很直接:把根因分析归为高精确率拒答场景——宁肯不答,不可错答,找不到高相关答案就直接放弃回答,避免错误答案误导 SRE 的二次判断。

1.2 三种互补的技术路线

大会上冒出来三种看似不同、实则可组合的路线:

路线 A:图谱 + 链路传导分析(百度 冷恒杰)

引入 PageRank 算法计算单个服务在链路中的故障传导影响力,定位链路上的关键故障节点。解决的是"海量告警里谁才是真正的根因"。

路线 B:应用代码分析(王津银老师)

王老师明确建议:根因分析应该用应用代码来做,而不是只靠日志/指标的统计模式。底层逻辑很朴素——日志和指标是症状,代码是病因,LLM 读代码比读统计特征更有优势。

路线 C:多 Agent 交叉验证(携程、智能体协同矩阵分享)

主 Agent 做 Plan-Execute 任务拆解,分派给垂直子 Agent 并行分析:

关键点:多 Agent 推理结果一致性 = 置信度评分。一致则高置信、不一致则降低置信度,这其实是拒答机制的自然延伸。蚂蚁的思路类似——主智能体分派任务,traces/logs/metrics 三类子 Agent 并行分析,最后汇总确认报告。

三种路线不是选一个,而是可以叠着用:PageRank 先定位链路关键节点 → 应用代码分析该节点的具体问题 → 多 Agent 交叉验证 → 低置信度直接拒答。

1.3 ReAct 模式在生产环境的三大坑(百度)

纯 ReAct 直接搬到根因分析场景,百度踩出了三类问题:

• 路径确定性不足:ReAct 的隐式推理,不可控性高
• 工具链注意力涣散:工具静态堆叠,模型注意力分散
• 无效循环状态熵增:陷入状态机陷阱、无效循环扩散

对应的工程化解法也很干脆:

• 分层 FSM:上层控制主干流程严格不可逆,下层限制 Agent 迭代/重试次数
• 动态工具加载:按状态设置工具优先级,基于结果动态汰换工具列表
• 状态化记忆:联动"状态-分析-结论",按状态流转需求裁剪加载

简单说就是:不要让 Agent 自由发挥,要给它装上导轨。这又回到了前面 Harness 工程的思路——AI 的能力边界不只取决于模型,更取决于模型周围的脚手架。

1.4 分层诊断架构

业界逐渐形成了共识性的分层架构:业务故障 → 业务性能 → 软件 → 基础资源。每一层对应独立的诊断 Agent,再配合知识图谱提供领域上下文——携程的 GraphRAG 就是这个思路:看板描述 → 关系实体抽取 → 业务域知识图谱。

1.5 一个绕不开的底线:安全边界(小米)

无论哪条路线,任何自动化操作必须同时满足四条:

• 可回滚:所有操作设计回滚方案
• 可中止:随时可中断自动化流程
• 可验证:操作前后效果验证
• 可审计:完整操作日志记录

这四条已经是行业事实标准,百度、蚂蚁的方案里都体现了同样的思想。这四条没做到,AI 就不该碰生产。

场景二:智能告警、值班与变更

这是最早落地、容错度最高、ROI 最明显的场景。

2.1 优先挑"可容忍幻觉"的场景切入

腾讯和小米的共识非常一致:既然幻觉无法消除,就从容错空间大的场景开始。

• 智能告警分析(高召回率场景):允许 SRE 二次确认,错了也有人兜底
• 容器单点自愈(小米):解决手段极其单一——重启实例即可自愈,风险可控,单点突破效果显著。小米用"上线前后 7 天单点问题恢复时间对比"作为提效观测指标,拿实打实的数据说话
• 咨询服务质检:只做分类和标注,不做决策

2.2 值班智能体:把故障定位能力左移(王津银老师)

王老师提了一个挺有画面感的概念——"故障定位能力左移到一线值班中心"。

传统路径是这样的:值班一线接告警 → 判断搞不定 → 升级给专家 → 专家来定位。这里面一线基本只是个"传话筒"。

AI 时代可以改成:Agent 在一线就完成初步定位,专家只处理 Agent 拿不下的疑难案例。这不是取代谁,而是把专家的能力封装到 Agent 里,让一线值班也能具备 70% 的专家判断力。

2.3 无人值守变更:核心不是"执行",是"质检"(腾讯)

很多人一听"无人值守变更"想到的是让 AI 去执行变更,腾讯给了个关键更正——无人值守变更的核心,是让 AI 在变更前做质检。

判断什么?变更的合理性、影响范围、回滚预案是否充分、是否有低级错误。

这是代码驱动 → 语义驱动的典型转变:

• 传统质检 = 规则匹配(覆盖面有限,新场景要加规则)
• 语义驱动 = 让 LLM 理解变更意图(泛化能力强,新场景自然覆盖)

2.4 广发证券的人机共创实践

广发证券把这个场景做得挺扎实,两个点值得学:

• 告警分析机器人:专家预先编排排障经验,Agent 调用 CodeBuddy CLI 做代码侧分析
• 智能日志分析做成一组面向 AI 的 SRE 技能:分析指定时段日志是否异常、与历史同时段对比、根据异常日志上下文推理异常原因、根据某时段异常日志反查原因

这个案例特别有意思——它把"日志分析"拆成了一组离散的可复用技能,每个职责单一,这就自然过渡到了下一个场景:Skills。

场景三:Skills 体系 —— AI Native SRE 的核心资产

本次大会出现频次最高的词就是 Skills。如果这篇文章只让你记一个概念,就记它。

3.1 Skills 到底是什么,为什么突然成了核心

Skills 的源头是 Anthropic 提出的 Agent Skills 规范(就是前面第一章里提到的 SKILL.md 格式),后来 Nous Research 开源的 Hermes Agent 把它发扬光大——Agent 能自动创建 Skills、在使用中改进 Skills,形成闭环学习系统。

这两天大会上,腾讯、蚂蚁、携程、阿里、广发全都在用 Skills——它已经是 AI Native 运维的事实标准,不是"要不要用"的问题,是"怎么用好"的问题。

携程把 Skills 的价值总结得最清楚,三点:

• 能力解耦与复用:复杂 AI 能力拆成独立 Skills,模块化设计,跨业务场景复用
• 降低使用门槛:业务团队无需理解底层模型,通过配置和组合预置/自定义 Skills 就能快速构建 AI 应用
• 业务敏捷响应:业务团队自主开发符合独特需求的 AI 能力,缩短需求到上线的周期

3.2 MCP + Skills + SPEC 三层协作(蚂蚁 白潇)

这是大会提出来的比较新的三层智能化体系架构——MCPs + Skills + SPECs 分层协作共建:

• MCP(Model Context Protocol):工具/数据的统一接入层,让 Agent 能调用外部能力
• Skills:确定性运维经验的可复用模块(SKILL.md + 脚本)
• SPEC:规约控制层,约束 Agent 行为边界,防止越界

这三层的分工其实挺好理解:MCP 管"能调什么"、Skills 管"怎么做这件事"、SPEC 管"不能做什么"。

蚂蚁分享了一个特别典型的用法——DeRisk-SKILL:通过 SKILL 指挥 Sandbox 里的 browser 系列工具,实现智能化审批。Skill 定义了"做什么、怎么验证",MCP 提供工具,SPEC 约束边界,三者缺一不可。

这里其实呼应了前面第一部分讲 Harness 工程时的那 7 层——运维领域的 MCP+Skills+SPEC,基本就是把 AI Coding 的 Harness 工程迁移到了运维场景。

3.3 SRE 角色的跃迁:从"写脚本"到"构建 Skills"

SRE 角色正在从"救火队员"跃迁到"AIOps 架构师":

这其实是整个时代的范式变迁——从 MIS到 SOA、微服务、云原生、再到 Agentic AI(服务变成 AI 的工具),每次跃迁本质都是"连接方式"的变化。

Agentic AI 时代,系统不再面向人(GUI)或程序(API),而是面向 Agent(MCP + Skills)。SRE 作为离系统最近的角色,首当其冲。

3.4 Skills 的自进化:下一阶段的主战场

腾讯在笔记里明确标注了"思考根因分析自进化、Skills 进化"——这可能是 AIOps 下一阶段的关键方向:

• 同类问题解决方案相似性提炼,自动总结为 Skills
• 事件无标准答案时,运维人工标注 + 提供充足信息给 Agent,Agent 自模拟推理过程生成 Skills,运维确认后入库
• 老 SRE 的隐性经验沉淀为可检索知识图谱,新人快速具备老手判断力

Hermes Agent 的"自动创建 Skills + 使用中改进 Skills"闭环,基本就是未来 AIOps Skills 体系的参考范式。

3.5 BizAgent:给另一个 Agent 用的 Skill,不一样(腾讯)

前面第一部分已经讲过 BizAgent 的概念,腾讯这里抛了一个很关键的问题:AI Native 时代,你的 Skill 的使用者是人,还是另一个 Agent?

这两种场景下 Skill 的设计完全不同:

Agent for Human(给人用):输出可以是自然语言、报告形式,人会自己理解和判断

Agent for BizAgent(给另一个 Agent 用):

• 输出必须结构化、语义清晰(供下游 Agent 解析)
• 输出的同时给出执行区间、结论验证方法(供下游 Agent 判断是否可信)

这意味着写 Skill 时要多想一层:下游会不会是另一个 Agent?如果是,输出不能是给人看的自然语言,必须是机器可解析、可验证的结构化数据。这个细节往往决定了 Skill 能不能被系统化编排。

场景四:智能问答与知识库

这是最容易掉进"工具化 AI"陷阱的场景,也是上下文工程最吃重的场景。

很多公司做智能运维问答,做着做着就变成了"AI 翻译 SQL"——用户问一句,AI 生成 SQL 查 CMDB,返回结果。这跟传统自动化没区别,只是换了个交互。王津银老师反复强调的就是:别掉进这个陷阱。

4.1 核心判断:上下文决定上限,工程决定下限(王津银老师)

王老师把"上下文"从模糊概念拆成了五阶段流水线:

信息源 → 聚合 → 预处理 → 组装 → 进化

关键实践:

• 基于本体论重构 CMDB,让数据具备语义一致性(而不是字段堆砌)
• 拒绝"CMDB 问数"式的工具化 AI 认知——只把 AI 当 SQL 翻译器、没有闭环,跟传统自动化没区别
• 强调运维业务闭环 + 人机协同

这里还呼应了字节张一鸣的管理哲学 "Context, Not Control":

• 传统运维是 Control 模式(流程、审批、管控)
• AI Native 运维是 Context 模式(给足上下文,让 Agent 自主判断)

对应需要的 SRE 团队能力也在变:想象力、判断力、执行力——三者缺一不可。

4.2 用 Agentic Search 替代 RAG(王津银老师明确建议)

这个观点挺硬核,也挺反常识——因为过去两年大家都在卷 RAG,突然有人说 RAG 过时了。

传统 RAG 在运维场景的问题:

• Query 混杂无关元素,直接向量搜索干扰大
• 切片后模型只能看到片段,缺乏多轮检索能力
• 运维知识高度关联、多跳查询多,静态切片严重丢失上下文

Agentic Search 怎么解决:

• 让模型自主决策是否搜索、如何搜索、使用什么关键词
• 传统向量检索降级为工具之一,和关键词搜索等混合使用
• 模型可以根据中间结果多轮检索,工具调用和搜索多轮耦合

一句话:RAG 是"我先检索好,你在这堆材料里找答案";Agentic Search 是"你自己判断要不要搜、搜什么、搜几次"。后者更像一个真正的研究员,前者更像一个考试开卷。

王老师对运维知识库的建议很明确——用 Agentic Search,不用 RAG。

4.3 交互形态:从 GUI 到 CUI(王津银老师)

未来运维的主要交互形态不是 Web 控制台,而是 CLI / 对话式(CUI,Conversational UI):

• IM 平台 CLI 化
• 多用 Claude Code 这类成熟工具
• 不建议自行训练大模型——王老师团队训练了 6 个月结果效果不好,直接劝退

这条经验可能是最值钱的——用好现成的通用大模型 + 上下文工程 + Skills,就能达到很好的效果,别重复造轮子。

4.4 问答场景的容错策略(腾讯)

技术咨询属于高召回率场景——答得不够完美可以接受,但不能答错。所以需要:

• 引入拒答机制,低相关性直接放弃
• 提供给 SRE 二次确认的信息(答案 + 推理依据 + 信息源)
• 不追求一次答对,追求给 SRE 足够的判断材料

这个心态挺重要——把 AI 定位成"研究员助理"而不是"决策者",质量要求会合理得多。

场景五:Agent 评估与数据飞轮

前面几个场景讲的是"怎么做",这个场景讲的是"怎么知道做得好不好"。

没有评估,前面所有东西都是一次性工程。有评估,才能持续进化。

5.1 三类评估方式对比(阿里 张磊)

实际落地基本是三种组合使用:

• Code 评估做常规回归(像跑 CI 一样)
• LLM 评估做内容质量打分
• 人工评估做关键抽样

不要指望一种方式搞定所有事。

5.2 Skills 仓库本身也要评测

阿里有个观察挺关键:Skills 越来越多之后,Skills 本身就需要评测。维度包括:

• 调用准确率(该用的时候用了没)
• 执行成功率(用了之后跑通了没)
• 输出质量(跑通了之后结果对不对)

Skills 不是写完就完事,要纳入持续评估——这点经常被忽略。

5.3 数据飞轮:质量提升的永动机

阿里提出的 AIOps Agent 迭代飞轮,核心就是闭环:

线上运行 → Trace 采集 → 评估打分 → 问题定位 
    → Prompt/工具/配置调优 → 重新上线 → 下一轮

这里的关键是把评估结果直接转化为优化建议,自动生成调优方向。

这样做的意义是:把"上下文工程"从一次性调优变成了可持续进化的系统——你今天的 Agent 一定比上个月更聪明,因为它每天都在被评估和优化。

5.4 评估工程的四个未来方向

阿里张磊对未来的判断也挺值得记一下:

1. 全链路观测标准化:观测埋点日趋规范,Trace 在 Agent 可观测场景逐步变得重要——APM 正在从"看服务"扩展到"看 Agent"
2. 评测走向智能:结合线上流量分布,评测集动态生成,评估体系自我进化
3. 评估器准确度提升:引入评估 Agent 和自动化校准,增强垂类领域评估准确性
4. 评估即优化:评估结果直接驱动优化,基于 Trace 根因分析自动生成 Prompt/工具/配置调优建议

最后一条尤其关键——评估不再只是打分,而是直接产出优化动作。这是整个数据飞轮跑起来的核心齿轮。

贯穿五大场景的实战建议

不管你在做哪个场景,小米这次分享的这些准则都适用,建议贴墙:

六条实战建议:

1. 小处着手:选一个最痛的点,3 个月做出可见效果
2. 关注实际问题:不追求概念,解决工程师真实困扰
3. 标准先行:在项目开始前制定数据规范
4. 安全第一:任何自动化都必须可回滚、可中止
5. 渐进式演进:工具 → 助手 → 伙伴
6. 用效果说话:用数据证明价值

三条底层判断:

• 数据质量 > 算法复杂度(好数据 + 简单算法 > 差数据 + 复杂算法)
• 简单实用 > 理论先进(生产环境要稳定和速度,渐进演进,不要一步到位)
• 人机协同 > AI 替代(AI 是工程师的超级助手,工程师监督决策过程)

三、结语:两天听下来的几个判断

两天听了十几场,脑子有点过载,但沉淀下来反复出现的几个信号挺清晰,记几个关键判断:

1. AIOps 的落地范式已经有共识了

不管是腾讯、蚂蚁、百度、携程、阿里还是小米,虽然各家业务不同、路径不同,但底层框架高度一致——MCP + Skills + SPEC 的三层协作、多 Agent 分层诊断、拒答机制 + 安全边界四原则、数据飞轮驱动的持续评估。半年前大家还在摸着石头过河,现在基本摸出大致的桥墩在哪了。

2. Skills 是这一代 AI Native 运维的核心资产

如果让我从两天的分享里只带走一个东西,那就是 Skills。它不是一个新工具,它是SRE 工作方式的重新定义——从"写脚本"到"构建可被 Agent 调用的能力模块"。这个转变一旦完成,SRE 的价值杠杆会放大好几倍。反过来,不做这个转型的团队,三年后大概率会被做了转型的团队降维打击。

3. 别训大模型,做好上下文工程和 Harness

王津银老师那句"训练了 6 个月结果效果不好"特别有警示意义。99% 的运维团队不需要训练自己的大模型,你要做的是:把上下文(CMDB、文档、知识图谱、历史事件)整理好,把 Harness(工具、权限、评估、回滚)搭好,让通用大模型在你的上下文里跑起来。这比训模型性价比高 100 倍。

4. 故障诊断会是最后一个被攻下的堡垒,但不会太久

这次听下来,故障诊断/根因分析仍然是大家谈得最多、吃得最费劲的场景。但 PageRank + 应用代码分析 + 多 Agent 交叉验证 + 拒答机制这四板斧组合起来,其实已经能解决相当一部分问题。等 Skills 自进化、评估飞轮跑顺了之后,我估计一年内会看到头部公司在根因分析上有突破性的案例。

5. SRE 的角色转型已经不是"要不要",是"多快"

从"救火队员"到"AIOps 架构师"这个转变,不是未来式,是现在进行时。建 Skills 库、设计 Harness、做评估工程、管 Agent 边界——这些工作五年前不存在,现在是 SRE 核心工作。这对个人来说既是挑战也是机遇:越早入局,越早建立不可替代性。

最后还是要说一句感谢——GOPS 这两天的讲师们愿意把踩过的坑、趟过的路原汁原味地分享出来,对我们这种一线做 AIOps 的团队来说太宝贵了。笔记整理得不完美,但观点和方向尽量都带出来了,希望对看到这篇文章的同行也有点参考价值。

共勉。