让 AI 真正接管运维:Resolve AI 的六大支柱
关联
现场举手提问很能说明问题:在座的工程师几乎都值过班,不少人试过用 AI 帮忙值班,但没有人敢说 90% 的值班工作已经被 AI 接管。
Varun 是 Resolve AI 团队的成员,这家公司的产品是让智能体(AGENT)去运行和修复软件。他在这场演讲里分享了他们的教训:
为什么这事儿这么难,以及一个能在真实生产环境里干活的智能体系统,需要哪六根支柱。
为什么 AI 写代码很强,救生产事故却不行?
第一波 AI 改变的是写代码,Varun 认为这有三个原因:代码本身是自解释的,容易解析;代码是模块化的,容易被拆解处理;
代码是单一领域,不需要跨领域推理,所以才有明确的基准测试。
但工程师生涯里约 70% 的时间不是在写新软件,而是在运维和修软件。这类工作恰恰相反:跨多个领域、跨一堆工具。
Varun 用医疗做比喻,把它分成三类:日常值班的小毛病,像头痛要吃 Tylenol;需要全员上阵的大事故,像做手术;
以及每天吃的维生素——定期看基础设施、成本、做平台工程来维持系统健康。
直接把最强模型怼上去,为什么不行?
演示的时候效果很好,一旦要跨用例、跨团队扩展,裂缝就出现了。Varun 列了几种失败模式。
模型有锚定偏见,天生要给你一个连贯的答案。
而且每个工作流里有几百种任务——推理任务、确定性任务、看图、查日志、写 SQL——不同模型各有所长,你得不断评估该用哪个模型,还得跟上模型更新的跑步机。
上下文窗口也是坑。窗口太大会过度探索,编出根本不存在的假设;太小又会探索不足,看不到其他可能的路径。
而生产事故里,遥测数据几乎是无限的,日志和指标要多少有多少,再叠加代码和基础设施,问题就来了。
最要命的是:模型不找因果,只求连贯
Varun 最喜欢讲的一点:模型是来取悦你的。你逼得够狠,它就会朝任何方向同意你。
模型被设计成给出连贯的答案,而不是因果关系。
但生产事故要的恰恰是因果证据链——像侦探一样,搞清楚是哪些步骤导致了这次事故,才能修对问题,而不是打个补丁了事。
【背景】GCP 是 Google Cloud,谷歌的云服务平台;Slack 是常用的团队聊天工具。
六大支柱:一个生产级智能体系统的骨架
针对这些裂缝,Resolve AI 总结出六根支柱。
一,模型编排:跟上新模型,并为每个任务匹配最合适的模型——图像推理用 Gemini,确定性步骤用 OpenAI,开放式调查用 Claude。
二,上下文工程:目标不是选什么数据库或方案,而是给 AI 恰好够用的上下文,通常是多种技术的组合。
三,因果推理:根因必须建立在证据链上。建立不起证据链,就低置信度输出,并把用户引向别的方向,而不是硬编一个答案。
四,受治理的行动:AI 可能认为删掉一段代码甚至一个文件系统是最干净的修法——你不能怪它,这是特性不是缺陷。
所以必须给它最小权限,明确什么能读、什么条件下能写。
五,学习系统:每一次交互都是学习机会,不仅从调查本身学,也从用户怎么引导它学。
六,评测:这是架构的起点和终点。
像给工程师打分一样给 AI 打分——用户的正反馈负反馈、能否追溯它的推理路径、和最好的工程师比差在哪、置信度校准得准不准。
演示:一个真实告警是怎么被调查的
现场演示里,Grafana 的告警打进 Slack,Resolve 自动接手调查。它把告警当成提示词,派出两类智能体干活:
调查员像工程师一样,从指标、链路追踪、日志里找线索,再和变更事件、部署记录、代码、基础设施做关联。
它给出的结论是:某个日志技能失败率升高,根因是系统里还残留着失效的集成。
有意思的是它同时列出了被排除的其他理论——比如当时正好赶上 GCP 大范围故障,时间上完美相关,很符合“连贯答案”的套路,但它没有被带偏。
系统还设计成最小信任:新工程师可以追问“这和 GCP 故障有关吗”,甚至硬推它往某个方向走。
因为答案只基于证据链,推它也不会顺着你说。你还能直接从 Slack 把同事拉进来,变成一个多人虚拟作战室。
本集带走
- 写代码只占工程师工作的一部分,更大一部分时间在运行和修软件,后者才是 AI 的硬骨头,因为它跨领域、跨工具。
- 把最强模型直接怼上去演示很好看,扩展后必然出现裂缝:锚定偏见、上下文过载或不足、只有连贯没有因果。
- 生产事故需要因果证据链,而不是讨人喜欢的答案;建立不起证据链就该承认低置信度。
- 六大支柱:模型编排、上下文工程、因果推理、受治理的行动、学习系统、系统化评测。
- AI“删库”是最干净修法这类行为是特性不是缺陷,解法是最小权限加明确护栏。
但现实中,在工程工作里,我们 70% 的时间花在另一头,不是生成新软件,而是在生产系统上,基本上就是运行和修复软件。
But in reality, for engineering, 70% of our time is spent on the other side, not generating new software, but rather in production systems, basically running and fixing software.
—— Varun Krovvidi · [02:31]
这时候失望就开始出现了,在大多数情况下,大多数人把它称为“最后一英里”,但那是你和 AI 一起要跑的最漫长的一英里。
That is when the disappointment starts to set in, which in most cases, most people dub it as the last mile, but that is the single longest mile that you have to run with AI.
—— Varun Krovvidi · [05:13]
我们真诚地相信,你在生产系统上所做的所有这些工作——比如修复问题或者日常运行你的软件——在大部分情况下都应该由智能体来完成。
So we genuinely believe that all of this work that you do on production systems, like fixing issues or running your software on a day-to-day basis, should be done by agents in most part.
—— Varun Krovvidi · [05:57]
而工程师应该只是运行那些智能体,由智能体负责修复和运行你的软件。
And engineers should just be running those agents, where agents take care of fixing and running your software.
—— Varun Krovvidi · [06:14]
这会成为一个巨大的问题,因为遥测数据实际上是无限的。
This becomes a huge issue because telemetry is literally infinite.
—— Varun Krovvidi · [09:31]
模型是用来取悦你的。
So models are there to please you.
—— Varun Krovvidi · [09:52]
所以模型是专门被设计来给你连贯的答案,而不是因果关系。
So models are specifically designed to give you coherent answers but not causality.
—— Varun Krovvidi · [10:01]
现在,当你在其上叠加时间维度的讨论时,你的 AI 系统应该在第 100 次调查中仍保有之前那次调查的上下文,否则你就是在再次从零开始转轮子。
Now, when you add temporal discussions on top of it, your AI system should have the same context of a previous investigation in the 100th investigation, or else you’re starting the wheel from the same time again.
—— Varun Krovvidi · [11:30]
但作为目标真正重要的是,AI 解决那个具体问题所需的精确上下文量是多少。
But what matters as a goal is what is the precise amount of context AI needs to solve that specific problem.
—— Varun Krovvidi · [12:59]
就像我提到的,这是我们在 Resolve AI 的系统里构建的首要原则之一,即根因始终基于一条因果证据链。
Like I mentioned, so this is one of the first principles that we’ve built into our system at Resolve AI, where the root cause is always based on a causal chain of evidence.
—— Varun Krovvidi · [13:35]
回到我之前提到的,如果你把一个 AI 逼得够紧,它就会开始同意你。
Going back to what I mentioned, if you push an AI hard enough, it will start to agree with you.
—— Varun Krovvidi · [19:25]
顺着「智能体」挖下去
- Braintrust CEO Ankur Goyal:做 AI 评估的纪律八年不变,但玩法正在剧变同概念:护栏 (guardrails)、智能体 (agent)、评测 (evals)
- Vibe debugging:代码生成之后,生产环境才是真正的硬仗同公司:Resolve AI · 同概念:护栏 (guardrails)、智能体 (agent)
- Anthropic 平台负责人:Claude 平台的「三层蛋糕」与给 token 分工的「策略」同概念:上下文工程 (context engineering)、智能体 (agent)、评测 (evals)
换个口味
- DevOps 之父 Patrick Debois:AI 时代组织比技术更难成熟同概念:智能体 (agent)、评测 (evals)、护栏 (guardrails)
- Gamma 联创复盘:押注空白页,赌出一亿用户同概念:护栏 (guardrails)、评测 (evals)、Slack
- 评测优先:Braintrust 创始人谈 AI 产品开发的真正工程同概念:智能体 (agent)、评测 (evals)
