今天 AI 行业最大的误区，是大家都在逼 Agent 尽快干活，却没有先搞清楚——让它干活的环境到底搭好了没有。
这句话出自 Andrej Karpathy。他不是在讨论什么理论问题，而是用 9 万 Star 的开源项目做了验证：Agent 性能的最大瓶颈从来不在模型本身，而在模型之外那套没人认真搭建的执行系统。
两组实验数据可以把这个观点钉死。
一、同一模型，换个"外壳"表现相差 76 分
Hugging Face 机器学习工程师 Joel Niklaus 最近做了一个极其克制的实验。他拿出开源模型 DeepSeek-V4-Pro，冻结全部权重——不做微调、不换模型、不改提示词，唯一允许的变量，是包裹在模型外层的代码和执行逻辑，也就是所谓的 Agent Harness（外层执行机制）。
结果令人瞠目：同一个模型、同一批任务、同一个评测器，仅仅因为换了五种不同的 Harness，综合得分竟然在 3.5% 到 80.1% 之间剧烈波动。
但这还不是最震撼的部分。
实验团队发现，在最初的测试里，模型在法律推理上的输出其实全对，但它总是把结果存错了文件名，导致测试程序根本读不到结果。得分是 0%。
换句话说：那个 0 分从来不是在测模型的智力，是在测 Harness 是否有效。
Niklaus 随后对最优的 Harness 进行了约 22 轮代码自动迭代优化。完全没动过权重的 DeepSeek-V4-Pro，最终性能从原始 Harness 的 63.4% 提升到 80.1%，追平了业内顶级的闭源模型 Claude Sonnet 4.6——而运行成本仅为原来的七分之一。
更关键的是，这套优化好的 Harness 迁移到同族小模型 DeepSeek-V4-Flash 上，依然带来了 14.4 分的提升。这证明：代码层面的执行机制，远比提示词调优更容易沉淀和跨模型迁移。
二、700 次自动迭代，找出 20 项被 20 年经验忽略的改进
Karpathy 的 AutoResearch 项目走的则是另一条路径——不是优化 Harness 本身，而是让 Agent 在"提出变更 → 运行实验 → 自动评估 → 保留进步"的循环中持续自我进化。
他用自己凭借 20 年经验手动调整的模型跑了整整两天。Agent 自动运行了 700 次实验，找出了 20 项连他自己都忽略的代码改进——比如注意力机制中遗漏的一个标量乘数，导致注意力过度分散到多个"头"上。
这种需要海量耐心的精细优化，人类在十几轮后就会筋疲力尽，但 Agent 不会。
Shopify 首席执行官 Tobi Lutke 连夜用内部模型测试了这套方法，醒来后发现质量提高了 19%，而优化后的模型大小也减少了一半。
顺着这条思路，研究人员进一步提出了"双层自动研究"：内层循环负责优化模型，外层循环负责优化内层循环的搜索逻辑。在使用同一个大型模型的情况下，性能比 Karpathy 的基准测试提升了 整整 5 倍——全部来自架构改进，而非模型能力提升。
三、被忽视的"操作系统"：Agent 能力的三层框架
这两组实验共同指向了一个被严重忽视的结构性问题。
Niklaus 的实验告诉我们：Benchmark 测到的从来不是裸模型，而是"模型 + Harness"的组合能力。当你连测试工具是否存在漏洞都无从知晓时，你永远无法确定性能瓶颈是出在模型本身，还是出在那漏洞百出的外层代码上。
如果把 Agent 比作一台电脑，当前行业的状态是：所有人都在争论 CPU（模型）该用 Intel 还是 AMD，却没人发现这台电脑连操作系统都没装。
前 Lightning AI 工程师 Akshay 曾用一个精准的比喻解释 Harness：一个原始的 LLM 只是一个没有内存或硬盘的 CPU。Harness 是管理内存、I/O 和驱动程序的操作系统。
生产级 Harness 至少包含 12 个核心组件：流程编排、工具调用、分层存储、上下文管理、错误处理……每一个单独拎出来都不性感，但任何一个出问题，都能让最强的模型给出 0 分。
一个具体的例子：当模型将关键信息置于上下文窗口中间时，性能会直接下降 30% 以上。成熟的 Harness 已经有一套完整的工程方法来应对这种"上下文腐烂"——压缩历史记录、屏蔽旧输出、动态摘要——其核心在于用最少的高密度 Token 获得最佳结果。
这些工程琐事，和"模型能力"毫无关系，却决定了模型能力的兑现率。
这就引出了一个 Agent 能力的三层框架：
第一层·模型层（Model）：参数规模、架构设计、训练数据——这是媒体最喜欢报道、行业最喜欢争论的话题。但 Karpathy 和 Niklaus 的实验共同表明，这一层的边际收益正在递减。
第二层·执行层（Harness）：模型之外的整套工程系统。文件处理、上下文管理、工具调用编排、错误恢复——这里才是当前绝大多数 Agent 团队的真正瓶颈。Niklaus 的实验已经把这件事说清楚了：同一个模型，Harness 换对了，76 分差距。
第三层·迭代层（Loop）：让 Agent 持续自我改进的循环机制。Karpathy 的 700 次实验证明，AI 的真正价值不在于一次性答对，而在于在低成本试错中逼近最优解。但这一层需要三个基本要素才能运作：可靠的验证器、持久的状态文件、明确的停止条件。
大部分团队卡在第二层，却以为是第一层的问题，于是一轮又一轮地换模型、砸显卡，唯独没人去看看那套模型的"外壳"是不是连文件名都存不对。
四、当试错成本趋近于零，真正的护城河在哪？
这套框架的普适性不止于 Agent 开发。
放在 SaaS 产品里，Harness 就是 API 网关、错误重试、数据管道——你做再好的功能，如果这些基础工程没搭好，用户感知到的就是"这个产品不行"，跟你的算法有多强没关系。
放在个人工作流里，Harness 就是你处理信息的 SOP——用什么工具收集、用什么规则筛选、用什么机制确保不遗漏。工具再好，SOP 崩了整个系统就崩。
Loop 层也一样。Karpathy 的方法论放到任何需要持续优化的场景都成立：内容创作的 A/B 测试、投放策略的自动调优、模型训练的超参数搜索。核心都是同一套东西——低成本试错 + 可靠评估 + 持续积累。
这就引出两个值得警惕的隐性代价。
一是理解债。循环生成的代码不是人工一行行敲的，开发者真正理解的代码和仓库里实际运行的代码差距会越来越大。一旦系统崩溃，排查成本极高。
二是认知让渡。循环一旦跑通，人极易停止思考。同样的工具，有人用来加速已理解的工作，有人却用来逃避理解工作。结果天差地别。
Karpathy 能凭借 20 年经验去判断哪些代码改进是有效的——他对模型的"品味"让 700 次实验有了方向。而大多数人启动循环时，连什么是"好的改进"都定义不清。
五、所以该怎么做？
如果你是技术决策者或 Agent 团队负责人：你的第一优先级不是"换更大的模型"，而是先把 Harness 的 12 个核心组件逐一审计一遍。文件路径对不对？错误处理有没有？上下文管理有没有防腐烂机制？把这些做好，你的 Agent 可能不需要升级模型就能涨 50 分。
如果你在做 Agent 选型：别只看模型跑分，要追问"这套跑分是在什么 Harness 上跑的？"同样的模型换个 Harness 可以从 3.5% 到 80%，跑分数字本身几乎毫无意义。
如果你是个体开发者：学会"Loop 工程"思维，而不是追求一次性做对。建一个验证器定义好坏，建一个状态文件记录过程，设一个停止条件防止放血。然后让 Agent 自己跑起来，你在旁边看它迭代。
——但记住，Codila 提出的四项适用条件缺一不可：任务需每周重复、验证需可自动化、Token 预算需能消化冗余、Agent 需访问真实环境。否则成本远超收益。
如果你在决定"是否引入更复杂的 Agent 架构"：先用 Niklaus 的方法测试你当前的 Harness 是否及格。如果你的 Agent 连最基本的文件处理都跑不对，那么引入再复杂的工具链、再昂贵的模型，都是在给一栋地基没打好的楼加装修。
来源：
1. Joel Niklaus, "Don't Train the Model, Evolve the Harness", Hugging Face Spaces, 2026
2. Andrej Karpathy, AutoResearch (Loop Cycle), GitHub 9万+ Stars
3. Codila, "Bilevel Autoresearch: Meta-Autoresearching Itself", 2026
4. Karpathy 播客《AGI is still a decade away》