跨国深谈← 返回←当系统出故障时，让 AI 代替作战室里的 50 个人——Traversal 谈如何造 AI SRE

当系统出故障时，让 AI 代替作战室里的 50 个人——Traversal 谈如何造 AI SRE

关联

人物 Anish · Raj · Harrison

公司 Traversal

概念 智能体 · 生产世界模型 · 可观测性 · 遥测数据 · 上下文 · 文件系统 · 评估 · 成本 · harness · SRE

系统出故障时，把五六十个人拉进作战室一起翻日志，是现在的标准操作——一家叫 Traversal 的公司想把这件事交给智能体。

这是 LangChain 联合创始人 Harrison 主持的一集对谈，嘉宾是 Traversal 的两位联创。Traversal 做的是「AI SRE」（站点可靠性工程，专门负责系统平稳运行的岗位），也就是用智能体来自动排查生产事故。这一集里他们讲了三件事：为什么这个领域偏偏没有现成标签数据、数据量又大到塞不进上下文，他们怎么用「生产世界模型」和文件系统绕过去；从手动触发到主动出手的智能体，应该怎么设计交互与护栏；以及一家公司想自己内部搭一套这样的系统，到底会卡在什么地方。

先说他们为什么觉得这个问题值得做。Anish 说，他自己原本在学术界做因果机器学习（一种试图从数据里找出因果关系的方向），团队在 MIT 相识，随后把目光转向了智能体能干什么。

给他们提出这个问题的是第四位联创 Ahmed，他来自 Citadel Securities（一家金融公司），那里对系统正常运行时间（系统不出故障的时长）要求极高，一旦出事代价极大。他们顺着这个问题摸进来，发现了两股力量正在撞在一起：代码编写智能体（帮人自动写代码的工具）越来越强，这意味着未来系统里绝大多数代码是机器写的，没有人再真正理解这些代码的内部逻辑；一旦系统出故障，想去问「这段代码当初为什么这么写」根本无从问起。到那时，靠智能体来自动排查事故，就不是锦上添花，而是必然的了 。

可这个方向听起来美好，真做起来为什么难？Anish 拉了一张长长的清单 。

第一，故障排查的 stakes（风险代价）极高，人都在高压状态下，智能体不能给错答案。第二，LLM 没有在遥测数据（系统运行时产生的指标、日志等监控数据）上受过训练，天生不擅长。

第三，你很难去模仿人类专家——因为人类自己其实很不擅长排查，你没法靠录屏插件记录专家的操作来当训练数据。第四也是最致命的一点：他们服务的大客户，每天能产生约 1 PB 的日志 。

这个量级别说塞进 LLM 的上下文窗口（模型一次能读进的文本长度），哪怕硬塞，「一次调查可能要花掉一个小国的 GDP」。更别提排查必须快，两分钟内得给出第一个有用线索，错一次都不行。Raj 接着补充，这催生了一个极难的搜索问题：智能体很擅长在文本里 grep（精准搜索特定词），但现有的可观测性平台（帮人监控系统状态的工具）本身不是为 AI 设计的，加上各家系统命名混乱，想跨系统检索信息极为困难 。

既然数据塞不进上下文，他们的解法是搭一个离线和在线结合的架构。Anish 解释说，这需要在不同粒度上搭建数据结构，形成一个连续体 ：把大量数据离线（提前算好）处理，换取在给定时间内极大的搜索面；再把细粒度的实时数据留在线上（当下查），牺牲搜索量但保住新鲜度。Raj 补充，决定一段数据该放线上还是离线的关键指标是基数（数据的可区分程度）——比如会话 ID 这种一过一大把、瞬息万变的高基数数据，和服务名这种相对稳定的低基数数据，查询模式截然不同。

【背景】上下文窗口指模型一次能读入的文本长度。集里提到他们目前用到了约 100 万 token 的窗口（现代 LLM 处理文本的基本单位）。即便如此也远不够装下所有日志，所以他们必须用智能体主动去搜索、调取细节。

顺着上下文限制这个难题，Harrison 抛出了一个很具体的问题：你们怎么管理那么庞大的上下文？答案出乎意料——文件系统（电脑里组织和存放文件的系统）。

Raj 解释说，哪怕 LLM 有了百万级的上下文，全塞进去既慢又贵。更好的做法是把摘要交给智能体，具体的原始数据落在文件里，让模型在需要时再用精准搜索去「向下钻取」。

因为当下的模型训练方式让它们非常擅长在文件里做精准搜索，这是最自然高效的方式。Harrison 听完顺口提到，他们开源的 Deep Agents 智能体框架也内置了类似功能。

有了底层的数据处理，上面跑的智能体长什么样？Anish 说他们最终收敛成了「一个核心智能体，调用多个子智能体」的结构 。

这套架构在交互上的演变很有意思：一开始是人工手动触发；后来变成基于规则触发（比如发警报就跑）；现在进化到了「主动型智能体」，它们拥有自己的主观能动性，觉得该出现时就会在 Slack（办公聊天软件）里开口 。但 Raj 提醒，对于刚入门的开发者，千万别一上来就搞复杂的多智能体协作，从一个简单的单智能体加技能（特定的工具组合）开始，能解决大部分问题 。只有在出现智能体在某个数据源上空转卡死的 thrashing behavior（抖动行为）时，才需要把它单独隔到一个子智能体里，宁可牺牲一点延迟也要换取稳定性 。

顺着智能体怎么干活，Harrison 问了个关键问题：智能体一跑就是很久吗？Anish 的回答揭示了这个领域的真实工作节奏 。

在他们的场景里，有一批智能体是 24/7 全天候在跑的，它们负责不断更新那个「生产世界模型」（整个生产系统的数字化全景表示）。一旦真有事故发生，负责实时排查的智能体接手，核心指标是「首次洞察时间」必须在两分钟内，而「末次洞察时间」可能长达一小时，因为随着排查深入，智能体会不断学习新信息。这套逻辑催生了对智能体架构的全新要求：你需要一个非常聪明的 harness（为智能体提供运行环境和工具的外壳），由它来决定什么时候启动核心智能体。

在这个架构里，最核心也最特别的概念就是「生产世界模型」。Harrison 打比方问：这就像你们生产环境的 Deep Wiki（一种由 AI 生成的代码库说明书）吗？

Raj 说只对了一半 。它确实融合了大量的非遥测数据，但另一半重头戏是如何从根本上让海量的遥测数据变得可搜索。

Anish 强调，有意思的是，关于系统里各种组件的关联，LLM 自己找出的路径，可能比人类告诉它的还要准。如果让人不断手动往里输入系统的关联关系，反而可能被虚假的 tribal knowledge（团队里口口相传的隐性知识）污染 。

所以他们把「关于系统的客观认知」和「关于人的个人偏好」分开了，后者属于用户级别的记忆，专门用来记住特定用户的习惯。至于要不要把智能体自己记下的笔记展示给用户看、让他们来「审计」记忆，则是他们目前正在摸索的产品设计细节 。

前面提到数据量太大，那评估这套复杂系统的表现（业内称为 evals）就成了大难题。Raj 直叹气，说这远超他的工资等级 。

他打了个比方：一套完整的排查轨迹可能长达 500 万 token，而整个《哈利·波特》系列才 200 万 token。要在这么长的轨迹里找出到底是逻辑错了、工具坏了还是超时了，极其困难。

但 Anish 补充了一个很有洞察力的观点：做评估，要专挑最难的硬骨头啃 。因为如果你能在最难的事故排查这种强推理任务上做好评估，这种能力往往会泛化（迁移到其他任务上）到那些不好做评估的日常问题上；反过来，如果你只挑容易的评估，既没有好数据，也迁移不到更难的事情上。

这就是为什么他们非要死磕 SRE（最难的部分）不可。这种对评估的看重，也直接决定了他们对大模型的态度。

Anish 坦言，他们一开始是某些大厂的死忠粉，后来换了阵营，但现在只忠于评估结果——每次有新模型出来就跑一轮评估，看成绩说话 。不过一个新变化是：以前只看性能不看价格，现在随着使用量暴涨，智能体跑一次动辄 500 万 token，成本变成了不得不考虑的现实约束 。

既然成本和难度都这么高，如果有公司想自己在内部搭一套 AI SRE，会卡在哪？Anish 用了一个自动驾驶的类比来拆解这个过程 。

L0 是纯手动排查；L1 是有固定操作手册，靠规则执行；L2 是 LLM 开始帮你打下手，比如写复杂的数据库查询语句，但人还在驾驶座上。L3 是 DIY（自己动手）的极限：为单一团队（比如结账组）的十几个微服务搭一个专属智能体，只要够聪明是能跑通的。

但真正的分水岭是 L4：当你要排查的事故需要横跨上千个微服务、PB 级的数据时，这就不再是一个 AI 算法问题，而是一个彻底的数据工程问题 。你必须花大把的时间，去重新设计一套能承载这种规模的数据处理引擎。

这也是为什么大多数尝试自建的大公司最终都失败了。而在 Traversal 内部，编码智能体不仅帮他们交付了多得多的代码，还逼着他们重构代码库，让架构变得更加对 AI 友好，顺带也让产品经理能直接上手写代码了 。对新手，Raj 的核心建议是：先别搞复杂的多智能体群体（多个智能体协同），从一个简单的智能体循环加技能起步，能走得很远 。

本集带走

最后收个尾，这一集值得带走的是三个判断。第一，代码越来越多是人看不懂、机器写的，出故障时只能靠机器自己查，AI SRE 是避不开的未来；但这事的难点不在大模型够不够聪明，而在你怎么把每天 1 PB、跨了上千个系统的遥测数据重新组织好，让智能体能高效检索。

第二，想管好超长上下文，别死磕大窗口，用文件系统存放细节，让智能体自己去精准搜索和钻取，这是目前最务实的办法。第三，如果你要自己搭智能体，千万别一上来就搞多智能体协作，先从一个简单的单智能体加技能跑通，遇到某个工具反复让模型卡死时，再把它拆成子智能体。评估也一样，专挑最难的事故排查做评估，只要在那里跑通了，能力自然会泛化到简单的日常问题上。

对代码的理解将会变少，因为没有人再编写代码了。
So much less understanding of code is going to be present because no one wrote the code anymore.
—— Anish · [02:07]

即使你可以，一次调查可能会让你花费一个小国的 GDP。
Even if you could, a single investigation is probably going to cost you the GDP of a small country.
—— Anish · [03:49]

我希望我没有冒犯任何人，但人类真的很不擅长故障排查。
I hope I’m not offending anyone, but humans are really bad at troubleshooting.
—— Anish · [03:19]

我认为，我的意思是，我们的一些轨迹可能是 500 万个 token，而整个《哈利·波特》系列是 200 万个 token。
I think, I mean, some of our trajectories can be 5 million tokens and the entire Harry Potter series is 2 million tokens.
—— Raj · [19:06]

我认为我们学到的一个见解是你应该评估最难的事情，因为如果你开始在那里做得好它往往会泛化，对吧
I think one insight that we have learned is that you should eval the hardest thing because if you start doing well there it tends to generalize right
—— Anish · [20:18]

所以当它开始像是一 PB 级的数据，你有一千个微服务，那就是它变成的时候，与其说是一个 AI 问题，它变成了一个数据问题。
So where it starts getting like a petabyte of data, you have a thousand microservices, that’s when it becomes, as much as it’s an AI problem, it becomes a data problem.
—— Anish · [27:42]

但我想说从 L3 到 L4 的差距是 DIY 停止有效的地方。
But I’d say the gap from L3 to L4 is where DIY stops working.
—— Anish · [28:20]

我认为人们有时犯的一个错误是太快地把事情拆分，并说像，噢是的，让我尝试创建一个真正复杂的多智能体系统并做事情。
I think one mistake that people sometimes make is splitting things up too quickly and saying like, oh yeah, let me try to create like a really complex multi-agent system and do stuff.
—— Harrison · [31:06]