AI智能体时代的工程判断力

在智能体时代，工程师最宝贵的技能是说"不"

我最近在Snowflake做了一场演讲，分享了过去两年在构建SGLang推理引擎、Omni多模态服务和AI智能体工作流过程中积累的经验。反响远超我的预期——这是第一次有这么多人在演讲结束后向我索要幻灯片。大概是因为我刻意回避了硬核的技术深挖，而是把时间花在了一件事上：解释在维护真实项目时，AI智能体究竟有多少种方式会以令人胆寒的方式出错。😂

幻灯片终究是碎片。我想把这些思考重新整理成连贯的文字——将散落在不同项目中的想法串成一条叙事主线。从我自己的工程实践出发，我想阐明在智能体编程时代，"工程判断力"究竟意味着什么。

一、站在基础设施与智能体世界的交叉点

先说说背景。

我是SGLang的核心开发者。SGLang是目前全球部署最广泛的开源推理引擎之一——GitHub星标超过25K，运行在逾40万块GPU上。我目前主导两个方向：SGLang RL Rollout（面向RLHF的高性能rollout基础设施）和SGLang Omni（多模态与TTS模型服务）。

与此同时，我是Claude Code的重度用户，对此我毫不掩饰。SGLang Omni最新的benchmark基础设施——数千行生产级代码——基本上是Claude Code依照我们的系统设计规范逐行实现的。我们团队大约十人，负责定义架构、设定阈值、规划文件路径、设计测试矩阵。AI在数十小时内完成交付。信不信由你，我自己已经很少再写实现层面的代码了。

这不是对未来的预测，这是我每天的现实。

但恰恰因为我同时站在推理引擎开发者和AI编程重度用户这两个角色的交叉点上，我对智能体编程的理解，大概与大多数人的直觉有所不同。大多数人看到的是"AI现在能写代码了，太厉害了！"而我看到的是三个被严重忽视的隐患——AI写的东西真的正确吗？系统架构应该是什么样的？以及这一切背后的token开销究竟值不值得？

本文沿着这三个问题展开，从第一个问题开始：你怎么知道AI写的东西真的正确？

二、没有度量的努力是自欺欺人

本科接近尾声时，我在做意图对齐方向的研究。在与一位我深为敬重的导师的交流中，他系统地阐述了他对对齐问题的构想，其中有一个核心步骤令我印象深刻——为对齐建立真实有效的基准测试。他的意思大致是：如果我们连对齐是否实现都无法度量，那么所有的对齐工作都是在沙滩上建城堡。

多年之后，历经智能体研究、推理和RL基础设施的磨砺，踩过无数坑之后，这句朴素的真理只会愈发沉重。而我遗憾地发现，现代benchmark并没有跟上步伐——它们已经远远落后于这个领域的发展速度。

智能体（Agent）领域尤其糟糕。每隔几天就会出现一个新的演示——它能控制浏览器、重写编译器，据说要让所有CUDA工程师失业。但深究一下：你如何衡量它是否真的好用？答案通常是几个精心挑选的案例，或一段经过精心剪辑的视频。在新智元（中国知名AI媒体）上，人类工程师已经被AI"取代"了上千次。然而顶尖的Cutlass工程师依然坐在他们的办公室里，拿着高薪，写着真正跑在生产环境中的kernel。

所以在我自己的项目里，benchmark从第一天起就是最高优先级。没有任何事情能排在它前面。

这种感受在构建how-to-sglang时最为强烈——那是一个帮助用户理解SGLang代码、回答社区问题的多智能体系统。一开始诱惑极大：加RAG、接入更多数据源、构建多轮对话、尝试花哨的智能体辩论机制。功能列表可以列到天花板。但我做的第一件事，是搭建一个LLM-as-a-Judge的评估框架。在添加任何功能之前，先回答一个基本问题：你的改动是否真的让智能体更准确了？

结果：大多数看似有希望的优化在测试中毫无改善。没有benchmark，每一个决策都是盲目猜测——我们以为在进步，其实并没有。

构建SGLang Omni的benchmark也是同样的故事。在我接手之前：一个优化PR被合并，TPS数字好看，大家都很高兴。过了一段时间准确率下降，没人能说清是哪个commit引入了回归，痛苦的bisect随之开始。我上任的第一件事：停止所有开发，先把准确率和性能CI建好，再谈优化。最终结果——S2 Pro WER 1.18%（排除坏样本），Qwen3 Omni无声音克隆1.91%，有声音克隆1.88%。验收标准±0.1%，全部通过。

至少推理系统的评估是客观的——数字高就是高，没有争议的余地。这与智能体评估截然不同——后者充斥着主观判断和模糊定义。这种确定性弥足珍贵。

没有度量的付出不是付出，而是自欺欺人。

Benchmark解决了"你怎么知道它是对的"这个问题。但还有一个更上游的问题：benchmark框架本身由谁来写？在我的案例中，是AI写的——但这只是答案的一半。

**三、Prompt本身就是系统设计**

当我说Omni的benchmark重构——数千行代码——大部分由AI完成时，这不是炫耀，而是事实。编写pytest fixture、构建subprocess调用、解析JSON结果、生成CI工作流——AI做得又快又好。

但有一个细节容易被忽视：那个prompt本身，就是我的系统设计。

整个重构中最关键的决策，是任务与模型的正交分离。旧版是一个722行的单体脚本benchmark_tts_speed.py，所有模型逻辑和任务逻辑耦合在一起。重构之后：tasks/、metrics/、dataset/、benchmarker/、eval/——五个模块。为什么这样分解？因为我知道后续会有一批新模型陆续接入。没有模型无关的抽象，每来一个新模型就要重写一遍评测框架。但也不能过度抽象——Omni模型之间的差异远比LLM之间大得多。S2 Pro用的是Dual-AR codec架构；Qwen3 Omni用的是9阶段多进程流水线。评测逻辑不可能完全统一。任务×模型正交分离，是复用与灵活性之间的平衡点。

直接让AI"重构这722行"，它会给你一个分解方案。但粒度是否恰到好处，取决于我们对项目未来走向的判断——哪些模型会来、哪些维度会变、哪里值得抽象、哪里不值得。这些上下文是模糊的、动态的、充满概率性判断的。你无法把它完整地蒸馏进一个prompt里。

AI给你一个分解。系统设计给你正确的分解。

代码是血肉，架构是骨架。在AI一天能写一万行代码的时代，架构对了，一万行是资产；架构错了，一万行是债务。而AI同时放大了走错方向的代价——它能以你难以想象的速度，把一处技术债变成一座债务帝国。

说"系统设计很重要"是空话。来看几个AI实际出错的具体案例。

**四、AI真正失败的地方**

在Omni benchmark重构过程中，Claude具体在哪里出了问题？几个有代表性的例子。

第一类：工程惯例的盲区。Claude用gdown从Google Drive下载数据集——在个人项目里没问题，但放到SGLang的CI里是定时炸弹。Google Drive有频率限制、会返回403、有confirm token问题——我们主仓库已经被不稳定的外部下载源坑过太多次了。正确做法：把数据集托管到HuggingFace，用snapshot_download。类似的问题还有：数据集fixture硬编码到/tmp/（并发job里路径冲突）、server teardown只发SIGTERM没有SIGKILL兜底、JSON key访问没有schema校验。这些问题单独拿出来看都是"常识"，但什么算常识，取决于你在哪个环境里工作。AI的常识来自互联网语料的统计分布，而不是某个具体团队踩过的坑的历史。

第二类：CI阈值设计。Claude把TPS阈值设在55 tok/s，而实测值是85-87——超过35%的余量。这个阈值能捕捉到灾难性回归（88→28），但性能从87悄悄滑到60不会触发任何告警。我反复看了四次测量值——85.8、85.9、86.9、87.1——标准差大约0.6。最终阈值定为80，所有指标统一留13-15%的余量。这个决策的核心不是算术——而是对这个具体系统运行波动的手感，知道多大的余量是"足够紧以捕捉慢性劣化，又足够松以避免误报"。做过CI的人都知道：阈值设计是系统工程问题，不是数学问题。

这些并非边缘案例，而是系统性问题。AI写代码写得很快，但"写得快"和"写得对"之间，隔着一整个工程环境的距离。

以上讨论的都是AI编程在"写出正确代码"这个维度上的局限。接下来，我想把视角拉远——不只是代码对不对，而是它背后消耗的token，是否真的物有所值。

**五、Token效率危机：用消防水管浇花**

作为一个推理引擎开发者，我日常工作就是想怎么最大化prefix cache命中率、优化KV cache内存布局、压低每次推理请求的成本。所以当我把Claude Code接到本地推理引擎、观察它实际的请求模式时——怎么说呢——感觉像是一个精心设计了循环用水系统的水务工程师，看着别人拿消防水管在浇花。

cache命中率惨不忍睹。不是"还行但有提升空间"，而是"我们在推理引擎层精心设计的prefix cache机制，几乎被完全破坏"。一个用户查询触发多次低价值工具调用，每次都携带100K+tokens的上下文窗口。Resume功能彻底打断KV cache命中——一个近乎荒诞的bug。整个session的上下文构建，从一开始就没有为cache复用做过认真的设计。

我喜欢内存膨胀这个类比。1969年，64KB内存把阿波罗送上了月球。2026年，打开一个网页轻松500MB。每一代硬件工程师把内存容量推高，每一代软件工程师开开心心地填满它。我们已经习惯了这个循环。

但LLM推理不一样。内存膨胀的代价是电脑慢一点、多花几百块钱升级。Token膨胀的代价是真实的金钱——GPU集群的电费、用户的订阅费——而且随着agent采用规模指数级放大。GPU算力的供给弹性远低于DRAM的供给弹性。当算力成为约束时，token效率不是"锦上添花"，而是决定谁能活下去的核心竞争力。

我有一个大胆的假设：那些消耗700K tokens的session，一定存在用10%的tokens完成完全相同任务的方法。不是牺牲质量——而是通过更聪明的上下文压缩、更好的prefix复用策略、更精准的工具调用调度。任何做过推理引擎优化的人，看到当前agent框架的请求模式，都会得出类似的结论。

"减少无效token消耗"不是防御性的优化，而是进攻性的能力。谁先在同等质量下实现token消耗量级的下降，谁就能用同样的算力服务十倍的用户。

但token浪费的根本原因，仅仅是agent框架设计粗糙吗？越想越觉得，更深层的问题是架构性的。

**六、Agent与推理引擎：缺失的协同设计**

当前的架构是这样运作的：agent框架把推理引擎当作无状态的API调用，每次请求都携带完整上下文。推理引擎尽力做prefix匹配，能cache的就cache。完全解耦，零协调，简单通用，但对长session而言效率低得触目惊心。

我的愿景：如果 agent 框架能够感知推理引擎的缓存状态，主动构建对缓存友好的请求；如果推理引擎能够理解 agent 的会话语义，做出更智能的缓存淘汰决策——一旦这条信息通道在两者之间打通，token 效率提升的潜力将是巨大的。

这需要三方坐在一起：模型构建者、推理引擎构建者，以及 agent 框架构建者。目前，我们距离这一目标还相差甚远。

也许市场最终会判定"算力变得足够便宜，浪费也无所谓"，就像 RAM 的故事一样。但我不相信 token 经济会走同样的路。至少在近期不会。

Agent 时代不属于那些燃烧最多算力的人。它属于那些最智慧地使用算力的人。

从推理引擎的视角审视完 token 问题之后，我想把目光转回 agent 本身。在前几节中，我一直在批评 agent——代码不正确、token 浪费、与推理引擎缺乏协调。但让我们换一个角度：agent 构建者真正的护城河是什么？

VII. Agent 护城河悖论

我在 agent 领域发现了一个引人入胜的悖论。

单个技术的实现难度低得令人发指。Agent 辩论（Debating）——许多多 agent 系统标榜的"核心护城河"——在实现难度上甚至远不及 MLA（DeepSeek 从 V2 开始的重大突破）。入门门槛几乎为零。

然而验证体系却复杂得令人望而却步。任何实证研究的第一步，都是构建正确的基准测试。推理基准测试已然成熟——TTFT、TBT、Throughput，这些客观指标早在几十年前就被数据库工程师使用，只是叫法不同。但 agent 的评估充斥着主观判断和模糊定义。OpenClaw 的基准测试与 vibe coding 基准测试几乎没有可比性。验证的复杂度远超实现的复杂度。

此外还有策略组合空间的爆炸式增长。SGLang 拥有超过一百个服务器参数。针对特定硬件和工作负载找到最优组合，复杂度极高。Agent 同样如此：单个策略很简单，但在真实约束下找到最优组合——这才是真正的核心能力。一位深刻理解系统的顶尖工程师，其价值不在于能实现某一单项策略，而在于对复杂策略空间中最优方向拥有直觉与判断力。

有一个问题我至今尚未解决。推理和训练系统的策略优化通常存在明确的权衡取舍——启用部分 rollout 就难以避免 off-policy 的影响。但 agent 策略之间存在相互权衡吗？把所有策略都打开，就一定能产生最好的 agent 吗？在我自己优化 how-to-sglang 的过程中，我发现大多数策略侵入性极强——包括 human-in-the-loop，包括循环辩论。这让我怀疑，组合问题远比我们想象的复杂得多。

护城河悖论背后还藏着另一个问题：如果单个 agent 技术实现起来如此简单，而 AI 写代码的速度又快得令人恐惧——当 AI 开始为自己写代码、扩展自身能力时，会发生什么？

VIII. 代码膨胀：AI 自我进化的恐怖速度

看看 OpenClaw 的代码库，你会发现一些令人不安的东西。

上个月初：大约 40 万行代码。一个月后：接近 100 万行。每天 500 多次提交。AI 智能体完全掌控并深度参与自身的开发，而没有人能够真正审查正在发生的一切。甚至有人构建了一个名为 nanobot 的代码库，声称用 4000 行代码就能复现核心功能——缩减了 99%。

从一个大规模软件维护者的角度来看，这令人恐惧。以惊人的效率快速增长，却毫无可理解性，熵值以骇人的效率不断攀升。

后来我在 GitHub 上与 OpenClaw 的维护者 Peter Steinberger 交流了几条消息。他的维护质量和热情给我留下了深刻印象——OpenClaw 并未陷入完全无人监督的 AI 自我维护状态。但问题依然存在：在多大程度上，我们能够维护一个处理大多数功能的简洁智能体系统，同时避免恶性代码膨胀，保留我们真正调试的能力？

AI 擅长局部优化——编写函数、修复 bug、添加功能，完全没有问题。但"保持系统简洁"并不是一个局部问题。它需要一种全局层面的克制——能够说"这个，我们不加"，并且是发自内心地这么认为，而不是因为某条规则如此规定。

这种克制，或许是人类对软件工程最后的贡献。

当然，也许我想太多了。也许下一代模型真的会拥有"品味"，就像我认识的许多顶尖工程师一样——也许它们会理解，最好的代码往往是那些从未被写出来的代码。

说到"品味"与"克制"，我们圈子里最近流行的各种新概念，恰恰是一个完美的反例。

九、新瓶装旧酒——以及真正的工程经验

我最近读了一篇关于 harness engineering 的长文，洋洋洒洒数万字。我的第一反应不是"这概念真厉害"，而是"这些人除了给旧概念造新词，还有别的想法吗？"

Prompt engineering → Context engineering → Harness engineering → 下个月大概就是 scaffold engineering 或 orchestration engineering。说来说去都是同一件事：设计你的模型所运行的环境——它接收什么信息、使用什么工具、如何拦截错误、如何管理跨会话记忆。自 ChatGPT 发布的第一天起，这些就已经存在了。给它起个新名字，并不会让它变成一门新学科。

抱怨归抱怨，我从 how-to-sglang 中学到的经验教训是真实的，与那些文章所引用的研究高度重叠。

**少即是精**。我们最初的方案是用一个巨型智能体，塞满 SGLang 的所有文档、代码和教程，回答一切问题。当然，这行不通——上下文窗口不是内存。塞得越多，注意力越分散，回答质量越差。我们最终采用了多层子领域专家架构：每个子领域配备一个专家智能体，由一个专家辩论管理器负责接收问题、分解子问题，并查询专家路由表来激活相应的智能体。这一改进带来的收益，远超直接升级到更强大的模型。

仓库是唯一的事实来源。所有专家 Agent 的知识均来自仓库内的 Markdown 文件。没有外部文档，没有口头约定。我们起初也有冲动，想写一个涵盖一切的巨型 sglang-maintain.md——很快发现行不通。OpenAI 的 Codex 团队撞上了同一堵墙：他们试图用一个庞大的 AGENTS.md 一统天下，结果可想而知，迅速腐烂。过期的文档不只是被人忽略——它会主动误导 Agent。

结构化路由，而非猜测。专家路由表将问题类型明确映射到对应的 Agent。一个关于 GLM-5 INT4 的问题会同时激活 Cookbook 领域专家和量化领域专家。不是由 Manager 凭感觉猜测——而是由索引引导。

这些经验教训都不新鲜。关注点分离、单一职责、文档即代码、约束左移——都是传统软件工程原则。只不过现在我们是在为 LLM 设计工作环境，于是有些人觉得有必要给它们起个新名字。其实不需要。

前九节主要涵盖了"软件"层面。最后，我想讨论两个我反复碰到的更难的话题——一个关于硬件，一个关于抽象。

**X. 纯 GPU 调试，与过早抽象的代价**

第一：ML 基础设施的调试成本。这个领域有一个残酷的现实——你根本无法在 CPU 上调试。真正重要的 Bug——CUDA Graph 捕获失败、多流竞争条件、FP16/BF16 数值发散、生产级批次大小下的 KV 缓存内存碎片化——只在 GPU 上、在规模化场景下、在真实 Kernel 运行时才会出现。AI 可以帮你写一个 CUDA wrapper，但它无法复现那个只在 H100、3 个并发请求、特定内存布局下才出现的 Graph 捕获失败。ML 基础设施调试需要硬件直觉——理解 GPU 实际上如何运行，而不只是代码看起来怎样。这是 AI 编程最难触及的领域。

第二：过早抽象的陷阱。在 Agent 时代，这个问题变得更加严重。以前，过度抽象至少需要时间来编写——给一个只被调用一次的函数套三层 wrapper，用一个配置系统管理三个参数，在问题边界尚未厘清之前就画架构图。现在有了 AI，这些东西几分钟就能生成。但它们留下的认知债务丝毫没有减少。过早抽象不只是无用——它是有害的，会增加每一个后来者的认知负担。而认知负担是工程成本中最隐蔽、也最致命的一种。

并不是说抽象本身是错的。时机错了。AI 让我们写代码的速度提升了十倍，但也让我们积累认知债务的速度提升了十倍。

GPU 调试考验的是硬件直觉。过早抽象考验的是克制力。归根结底，它们考验的是同一件事。

**结语：工程感是一种排序能力**

回顾这整篇文章，我其实只说了一件事。

工程师最宝贵的能力，不是构建复杂的东西，而是面对一堆看起来都值得去做的事情，识别出哪些真正重要。写代码是加法。工程感是排序。你需要能够面对一个很酷的优化想法，说"现在不行——先把基准测试做扎实"。面对一个优雅的抽象，说"删掉它，我们现在还不需要这个"。当所有人都在堆功能的时候，说"停一停——我们先确认自己到底在优化什么"。

这份判断力并非来自书本。它是从一个又一个具体的坑里爬出来之后，留下的肌肉记忆。从导师关于基准测试的一堂课，到构建 Agent 时选择先搭评估体系，到为 Omni 建立基准测试基础设施，到观察 Claude Code 的 token 浪费，再到思考 Agent 护城河的本质——同一个洞见，从"这说得通"演化成了本能。

在 AI 每天能写一万行代码的时代，执行力正在快速贬值。但系统设计从未像现在这样重要——因为 AI 在放大你前进速度的同时，也同等放大了走错方向的代价。

Agent 时代，不属于那些烧算力最猛的人，不属于那些写代码最快的人，也不属于那些最会造新概念的人。它属于那些知道什么不该建的人。