作者：王林Lincoln | MindsLeap创始人 | Founders Space合伙人 | 企业家AI俱乐部创始人
代码越来越多，理解代码的人越来越少
Traversal 的联合创始人 Anish Agarwal 在 LangChain 这场对谈里，说了一句很值得企业家警醒的话。
“会有越来越多代码被写出来，而对代码的理解会越来越少，因为已经没有人真正写下这些代码了。”
这句话不是在批评 AI 编程。
恰恰相反，它是在描述 AI 编程普及以后，企业马上会遇到的下一层问题：当代码生产速度被 AI 放大，软件系统会变得更快、更复杂，也更难被单个人完整理解。
过去，一个系统出问题，工程师还能凭经验追日志、看指标、翻代码、拉人进会议室。未来，系统的规模、变更频率和依赖关系都会继续膨胀。AI 帮你写了更多代码，但谁来理解这些代码在生产环境里的行为？
Traversal 想做的，是一个 AI SRE，也就是帮助企业排查生产事故、理解系统异常的 AI智能体。
Harrison Chase 这次和 Traversal 两位联合创始人 Anish Agarwal、Raj Agrawal 聊的，不只是一个新的开发者工具。更深的信号是：AI智能体正在从“帮人写代码”，走向“帮组织理解复杂系统”。
这对中国企业也很重要。因为未来很多公司都会经历同一个过程：先用 AI 提升开发效率，然后很快发现，真正的瓶颈不是写得够不够快，而是系统出了问题以后，组织还能不能看得懂、管得住、救得回来。
故障排查不是聊天题
Traversal 最早不是从运维工具出发的。
Anish 和 Raj 的背景来自 MIT 的 AI 研究，他们研究过因果机器学习、强化学习，以及如何在巨大搜索空间里有效寻找答案。后来另一位联合创始人 Ahmed 把生产事故排查这个问题带到他们面前。
他们很快发现，这可能是 AI智能体最难、也最真实的战场之一。
Anish 说，刚开始他们觉得这个问题“比预期难得多”。原因很朴素。
第一，故障排查发生在压力最高的时候，不能随便错。
第二，没有好的标注数据。大模型并不是天然在企业遥测数据、日志、trace 和指标上训练出来的。
第三，也很难照搬人的做法。Anish 半开玩笑地说：
“人类其实很不擅长故障排查。”
这句话有点刺耳，但真实。
很多企业系统出事故时，会拉起一个 war room，几十个人围在一起，实时拼上下文：谁改了代码，哪个服务异常，哪个指标先变，哪个依赖出问题。这个过程不是一个清楚的 SOP，而是一场混乱的信息搜索。
如果 AI智能体只是模仿这种混乱，它不会变强，只会把混乱自动化。
所以 Traversal 看到的问题，不是“让模型读几行日志”，而是在 PB 级数据、无标准答案、高压力、强时效的环境里，让 AI智能体找到真正有用的线索。
Anish 讲到他们的大客户时说，有些公司一天会产生大约 PB 级的数据。如果把这些数据硬塞给大模型，不仅放不进上下文，就算能放进去，一次调查的成本也可能荒唐到不可接受。
他说得很直接：
“你必须在两分钟内给出答案，否则人们会非常生气，而且你还不能错。”
这就是生产环境和 demo 的区别。
Demo 可以慢一点，可以错一点，可以重来。
生产事故不行。
企业需要自己的 production world model
Traversal 的核心概念叫 production world model，可以翻译成“生产世界模型”。
这个词听起来很技术，但本质很简单：一个 AI智能体要排查生产事故，不能只看一段日志。它必须理解这个系统是怎么连接起来的。
代码在哪里，服务之间如何调用，Slack 里讨论过什么，哪些指标和哪些 trace 相关，哪些错误日志曾经一起出现，哪些服务名只是命名不同但实际属于同一个业务链路。
Raj 说，他们会把 telemetry、代码、GitHub、Slack 等信息综合起来，构建一个关于生产系统如何连接的知识表示。
Harrison 问，这是不是有点像给生产日志做一个“DeepWiki”。Traversal 的回答是：部分像，但还不够。真正难的，是把代码和文档里的系统知识，和实时的观测数据连接起来，让 AI智能体可以有效搜索。
他们说，理想状态下，你希望 AI智能体可以对整个可观测性系统做一次“Control F”。
但真正做到这一点非常难。
因为企业里的系统命名并不统一。session id、correlation id 会不断变化。不同服务、不同工具、不同团队的字段和口径都不一样。没有足够的系统上下文，AI智能体很难把这些碎片关联起来。
这对传统企业同样成立。
今天很多企业说自己要做 AI智能体，但内部数据、流程、系统和知识本来就是碎的。客户数据在 CRM，履约信息在 ERP，客服记录在企微，经营分析在飞书表格，很多关键判断还在微信群聊天里。
如果没有自己的“业务世界模型”，AI智能体就只能在表层问答里打转。
Traversal 做的是生产系统的 world model。企业真正要思考的是：我的销售、供应链、门店、财务、客服、研发，有没有自己的业务 world model？
在线搜索和离线计算，要一起设计
Traversal 这场对谈里，有一个很实用的技术判断：AI智能体的搜索能力，不只是 RAG 或向量数据库问题，而是在线计算和离线计算的权衡。
他们说，离线计算越多，系统在单位时间里能搜索的数据就越多，但粒度会差一些。完全在线查询，比如实时查 DataDog，粒度更细，但一次能搜索的范围有限。
所以真正的系统，要在两者之间建立数据结构，再让一个智能层判断什么时候看什么。
这句话放到企业经营里，也很有启发。
不是所有问题都应该等人问了以后才现场查。
真正高效的 AI智能体，应该有很多提前做好的准备：指标预聚合、异常模式整理、业务对象关系图、关键客户变化、流程历史、常见问题、过往决策记录。
当问题发生时，它再做在线搜索和推理。
这也是为什么 Traversal 会有一些 AI智能体 24 小时运行，用来更新 production world model；另一些 AI智能体则在事故发生时实时运行。
他们还提出两个时间指标：time to first insight 和 time to last insight。
第一个有用线索，必须在两分钟内出现。最后一个完整洞察，可能要持续学习一小时。
这个设计很像真实组织的工作方式。
领导或客户最需要的，往往不是一开始就完美的最终报告，而是先告诉我：现在最可能的问题在哪里？我们应该先看什么？风险有没有扩大？
AI智能体要进入生产，不能只追求“最终答案”，还要设计“第一条有用线索”。
记忆不是越多越好
Harrison 问 Traversal：当用户在事故频道里告诉 AI智能体“不要看 X 日志，要看 Y 日志”，这个反馈会不会更新 production world model？
这个问题很关键。因为今天很多 AI 产品都在谈 memory，好像记得越多越好。
Traversal 的回答更克制。
他们把 production world model 和用户交互记忆分开。前者是关于系统真实连接关系的表示，来自 telemetry、代码、GitHub 等数据；后者更像 knowledge bank，记录用户反馈、偏好和重要文档。
他们解释说，生产系统里有很多连接关系，是任何一个人都不知道的。如果让人不断手动输入，很可能会把一些“部落知识”里的错误也写进去，反而污染系统。
这句话对企业非常重要。
AI智能体需要记忆，但记忆要分层。
哪些是系统事实？哪些是员工偏好？哪些是临时判断？哪些是过期 SOP？哪些是用户反馈？如果全都混在一个记忆池里，AI智能体会越来越像一个自信但混乱的老员工。
企业未来管理 AI智能体，不能只问“它记不记得”，而要问“它记的是什么类型的知识，谁能审计，什么时候过期，和事实系统如何区分”。
这才是 AI 原生组织的知识治理。
最难的问题，反而最适合做评估
当 AI智能体越来越复杂，怎么知道它到底有没有变好？
Traversal 说，评估这类智能体非常难。有些轨迹可以达到 500 万 tokens。为了让人有感觉，他们说整套《哈利·波特》大约 200 万 tokens。也就是说，一个智能体完成一次复杂排查，留下来的执行轨迹可能比两套小说还长。
你不可能靠人工从头看到尾。
但生产事故排查有一个优势：它最后多少有可验证性。你可以看智能体给出的根因，是否和 war room 最终找到的原因一致。
更有意思的是，Traversal 提出一个评估原则：
“你应该评估最难的事情。”
因为如果一个系统能在最难、最可验证的任务上做好，能力往往会泛化到其他场景。相反，如果只评估简单聊天、日常问答，数据未必好，结论也未必能迁移到真正困难的问题。
这对企业做 AI智能体评估很有参考价值。
不要一开始就问它能不能闲聊、能不能写一段漂亮总结。要找那些对业务最关键、最痛、最能验证结果的任务。
比如销售预测里，能不能找出真实流失风险？
比如工厂异常里，能不能缩短定位时间？
比如客服升级里，能不能更早发现高风险客户？
比如软件事故里，能不能在两分钟内给出第一条有用线索？
AI智能体的评估，不应该从容易的地方开始，而应该从组织最需要判断力的地方开始。
L3 到 L4，是 DIY 失效的分界线
对很多企业来说，这场对谈最实用的一段，是 Traversal 对 DIY AI智能体的分级。
他们借用了自动驾驶 L0 到 L5 的框架。
L0 是完全人工排查。
L1 是有 runbook，有规则，人照着执行。
L2 是人还在驾驶位，大模型帮你写一些烦人的查询，比如 Splunk 查询，或者在根因已经明确后写复盘。
L3 是团队级智能体。比如数据库团队、结算团队、某个前端团队，只负责十几个、二十个微服务。在这个规模下，一个聪明团队自己搭一个 AI智能体，可能真的能工作。
真正困难的是 L4。
到了 L4，问题需要跨整个生产环境推理。上千个微服务，PB 级数据，复杂依赖关系，任何一次查询都可能需要穿越多个系统。
Anish 的判断很直接：
“从 L3 到 L4 的差距，就是 DIY 开始失效的地方。”
这句话不只适用于运维。
企业做 AI智能体也会遇到类似边界。部门内的小工具很好做，个人效率型应用也很好做。一旦跨部门、跨系统、跨数据口径、跨权限边界，问题就不再只是 AI 问题，而是数据结构、组织流程、权限治理和系统架构问题。
很多企业会在 L3 阶段误判自己已经完成 AI 转型。
真正的挑战在 L4：AI智能体能不能跨越整个组织的生产环境去理解问题。
写在最后：救火的人，会先变少
Traversal 说，他们的目标不是做一个事故管理工具。市面上已经有很多工具管理人：谁被叫醒，谁进会议室，谁负责协调，谁写复盘。
他们真正想改变的是 SOP 本身。
过去生产事故发生时，组织靠一群人围在一起找针。未来，如果 AI智能体能承担更多搜索、关联、验证和初步判断，人类的角色就会从“到处排查”转向“验证关键判断”。
这其实是所有企业 AI 转型都会发生的方向。
AI智能体不是简单替代一个人，而是改变一套工作流里人应该站的位置。
在客服里，人可能从重复回答变成处理高风险判断。
在销售里，人可能从查资料变成建立信任。
在研发里，人可能从写代码变成定义系统边界和验证结果。
在运维里，人可能从混乱救火变成审计 AI 给出的因果路径。
这篇内容给我的最大启发是：AI智能体真正进入企业，不会从最轻松的场景证明价值，而会从最痛、最复杂、最需要快速判断的地方逼出新架构。
AI 写代码只是前半场。
当系统出事，AI 能不能理解系统，才是后半场。
关于 MindsLeap 心智悦动
MindsLeap 心智悦动是 AI原生组织转型加速平台。
我们与硅谷创新孵化器 Founders Space 深度合作，持续连接全球 AI 前沿认知、硅谷科技创业生态与中国企业家的真实转型场景。
围绕 AI 原生组织建设，MindsLeap 正在构建一个面向企业家、创业者、AI 工程师、产业专家和投资人的转型生态，帮助企业把 AI 从认知、战略和工具，真正落到组织能力、业务流程、产品创新和增长系统中。