Agent 的差距，正在转向底盘工程

同一个模型，交到两个开发者手里，产出可能差出一个数量级。一个人让 Agent 连续跑完一整条重构任务，中途自己查日志、改测试、回滚出错的提交；另一个人的 Agent 三步之后就开始胡编文件路径，最后交回一堆无法运行的代码。他们用的模型版本相同，上下文窗口相同，差异主要在模型外面的系统层——那层通常没有名字，也很少有人认真设计。

Lilian Weng 最近把这层东西明确定义为 harness：围绕基础模型的一整套执行系统。它决定模型怎么思考、怎么规划、怎么调用工具、怎么读写记忆、怎么检查自己的结果。她的判断很直接：现代 AI 想要自我改进，未必先去改写模型权重，更现实的近路是改进它周围的训练管线和部署系统。换句话说，Agent 变强的下一段路，很多不在模型里，而在模型的底盘上。

这对一线开发者意味着一件具体的事：当你选一个 Agent 产品，或者自己搭一套工作流，更该追问两个问题：它如何组织任务，以及它如何验证结果。

模型能力之外的系统差异

模型能力的提升正在变得越来越平缓、越来越贵，而且各家很快会拉到同一水位。一旦模型不再是稀缺资源，稀缺的就变成了怎么用好它。

底盘工程解决的，正是模型解决不了的那部分问题。模型负责单次推理，底盘负责让成百上千次推理串成一件可靠的事。它要在模型跑偏时把它拉回来，要在上下文超限前决定丢掉什么、留下什么，要在一个动作失败后决定重试还是换路。这些能力无法仅靠更换模型自动获得，必须通过明确的系统设计沉淀下来。

Claude Code、Codex 这类编程 Agent 之所以好用，多数功劳其实在底盘：它们知道怎么把任务拆成步骤，怎么在文件系统里留下可追溯的痕迹，怎么在提交前跑一遍测试。模型是同一批模型，产品体验的差距几乎全落在这一层。

这个趋势在 Claude Code 的官方设计里已经很具体。Anthropic 文档把 memory、hooks、permissions 都作为独立能力来说明：memory 用项目文件保存长期上下文，hooks 在特定生命周期事件上自动执行命令或检查，permissions 则控制工具和操作边界。这些能力本身并不改变模型权重，却直接决定 Agent 能否记住项目约束、执行确定性校验，并在危险动作前受到限制。

这也是很多自建 Agent 工作流容易失败的地方。它们通常已经接上了很强的模型，也能调用工具，但缺少稳定的状态记录、权限分级和结果校验。单次演示看起来顺利，一旦任务跨越多个文件、多个步骤、多个会话，就开始失忆、越权或重复犯错。Lilian Weng 的 harness 文章给了理论框架，Claude Code 的公开设计给了产品层面的工程证据：模型之外的系统层，正在变成真正的分水岭。

Agent 底盘的五个组成层

把底盘拆开，大致是五层。下面这张表可以直接拿来评估一个 Agent 产品，或者检查自己搭的工作流缺了哪一环。

这五层共同构成一条闭环：观察、行动、记忆、验证、改进。少任何一层，闭环就断在那里。多数不好用的 Agent，问题都能定位到其中某一层的缺失，而不只是模型不够聪明。

从模型选型转向系统校验

选产品时，把宣传里的模型参数放到一边，直接对着五层去问。一个只谈模型、答不上后四层的产品，大概率只是给你套了层壳。

自己搭工作流时，顺序也清楚：先有工作流和记忆，让任务能拆、能续；再补权限，降低误操作风险；最后加评估和复盘，让它能自己发现并纠正问题。

这个判断在国内大厂的工程协作里尤其明显。一个功能能否稳定上线，通常不取决于某段代码看起来多聪明，而取决于需求是否被拆清楚、权限边界是否明确、测试是否自动执行、失败后能否回滚。跨团队联调、灰度发布和线上事故复盘，本质上都在要求系统留下状态、证据和责任边界。Agent 进入这类工程链路以后，也必须接受同样的约束。它越接近真实交付，就越需要像运行时系统一样被设计，而不能停留在聊天窗口里的聪明回答。

模型仍然重要，但它已经是台面上人人都有的牌。真正拉开差距的，是能否把模型周围的底盘认真当成一件工程来做。