YC 掌门人说出了 AI 编程的秘密：模型不重要，Harness 才重要

最近两周，X 上有两篇关于 AI 编程的长文火得不行。一篇是 Akshay Pachaar 写的 "The Anatomy of an Agent Harness"，106 万浏览；另一篇是 YC CEO Garry Tan 写的 "Thin Harness, Fat Skills"，142 万浏览。两篇放一起看，讲的其实是同一件事：那些用 AI 编程效率提升 100 倍的人，和只提升 2 倍的人，用的是同一个模型。差别在哪？在模型外面那一层叫 Harness 的东西。

我用 Claude Code 写了半年代码，读完这两篇的感觉是，终于有人把我模模糊糊感觉到的事情讲明白了。这篇不打算搬运原文，就讲讲我自己的理解，外加一些踩过的坑。

太长不看版

1. Harness 是包裹 LLM 的全部基础设施：编排循环、工具、记忆、上下文管理、错误处理、安全护栏等，一句话概括："如果你不是模型，你就是 Harness"
2. LangChain 只换了 Harness（同模型同权重），在 TerminalBench 2.0 上从 30 名开外跳到第 5，证明 Harness 比模型选择更影响效果
3. Garry Tan 提出"薄 Harness，厚 Skill"：Harness 保持极简（循环+读写+上下文+安全），把智慧塞进 Skill 文件
4. Skill 文件本质上是"用 Markdown 写的方法调用"，同一个流程传不同参数，产出完全不同的能力
5. 上下文管理是最容易出错的环节，关键内容落在窗口中间位置会导致性能下降 30%以上
6. 验证循环是区分玩具和生产工具的关键，给模型一个验证自己工作的方法，质量提升 2-3 倍
7. 确定性操作和 LLM 判断要严格分开，搞混了就是灾难
8. 每写一个 Skill 都是对系统的永久升级，模型换代后所有 Skill 自动变强

Harness 到底是什么？

Harness 这个词在 2026 年初才被正式提出，但它指代的东西早就存在了。一句话：LLM 是 CPU，Harness 是操作系统。

裸 LLM 像一块没有内存、没有硬盘、没有 I/O 的处理器。上下文窗口当 RAM（快但小），外部数据库当硬盘（大但慢），工具集成是设备驱动。Harness 把这些东西串起来，让这块 CPU 真的能干活。

这个类比是 Beren Millidge 2023 年提出来的，他原话是我们"重新发明了冯诺依曼架构"。听着夸张，但你想想 Claude Code 平时怎么工作的：读文件（I/O）、记上下文（RAM）、调工具（外设）、在循环里思考再行动（CPU 指令周期）。这不就是一台计算机吗。

Akshay 给的数据挺有说服力。LangChain 在 TerminalBench 2.0 上做了个实验，模型不变、权重不变，只换了外面包的 Harness，排名从 30 名开外直接跳到第 5 名。还有个研究团队让 LLM 自己去优化 Harness 设计，通过率干到 76.4%，比人手搭的还高。

模型能力是地板，Harness 是天花板。

我自己也有同感。同样是 Claude Sonnet，普通对话框里写代码，和 Claude Code 里写代码，完全两个东西。不是模型变聪明了，是 Claude Code 给了模型对的上下文、对的工具、对的验证手段。

一个生产级 Harness 长什么样？

Akshay 梳理了 Anthropic、OpenAI、LangChain 这些主流框架，总结出 12 个核心组件。我不打算逐个搬，挑几个我在实际使用中感受最深的讲。

编排循环：看起来蠢，但它是心脏

Harness 的核心就是一个 while 循环：组装提示词，调 LLM，解析输出，执行工具，结果喂回去，重复。

Anthropic 自己说 Claude Code 的运行时就是个"笨循环"（dumb loop），所有智能都在模型里。Harness 只管轮次调度。

这话听着谦虚，背后的设计哲学挺深的：不在 Harness 层面替模型做决策。Harness 只负责提供条件。很多人一上来就想把业务规则、判断逻辑硬编码在 Harness 里，结果越写越复杂，模型反而没空间发挥。

上下文管理：最容易翻车的地方

这是我觉得整篇文章里最值钱的部分。

Chroma 做过一个研究，关键内容如果落在上下文窗口的中间位置，模型性能会掉 30% 以上。斯坦福的 "Lost in the Middle" 论文也验证过。就算你有百万 token 的窗口，塞太多东西进去，模型反而更容易忽略重要内容。

这解释了一个困惑了我很久的现象：为什么有时候 Claude Code 明明"知道"某个文件的内容（之前读过），问它的时候就是想不起来？大概率是那部分内容沉到窗口中间去了，被"忘了"。

生产级 Harness 通常有这么几个解法：

• 压缩（Compaction）：对话历史太长时做摘要。Claude Code 会保留架构决策和未解决的 bug，丢弃重复的工具输出
• 观察屏蔽：JetBrains 的 Junie 会把旧的工具输出隐藏掉，但保留工具调用记录。模型知道自己做过什么，但不被历史细节拖住
• 按需加载：不把整个文件塞进上下文，用 grep、glob、head、tail 这些工具动态读取需要的部分
• 子代理委托：派子代理去深入调查，只带 1000-2000 token 的摘要回来

Anthropic 的上下文工程指南里有句话我挺喜欢：目标是找到最小的、高信号 token 集合，最大化期望输出的概率。不是越多越好，是越精准越好。

Garry Tan 自己也在这事上翻过车。他的 CLAUDE.md 写到过 2 万行，把所有经验教训都塞进去。结果模型注意力反而退化了，Claude Code 甚至主动提醒他砍掉。最后他改成 200 行的索引，指向具体文档，需要的时候再加载。2 万行知识按需调用，不污染上下文窗口。

这个我深有体会。我之前也干过类似的蠢事，把大量规则堆在 CLAUDE.md 里，觉得写得越详细效果越好。实际上模型根本消化不了。不如精简到核心原则，细节放在单独文件里让它自己去找。

验证循环：玩具和工具的分界线

Boris Cherny（Claude Code 的作者）说过一句话我记到现在：给模型一个验证自己工作的方法，质量提升 2 到 3 倍。

Anthropic 推荐三种验证方式：

• 规则验证：跑测试、跑 lint、跑类型检查。这些东西是确定性的，对就是对，错就是错
• 视觉验证：用 Playwright 截图看 UI 效果。模型改完前端代码，截个图自己看看像不像
• LLM 裁判：派另一个子代理评估输出质量，相当于代码 review

我在用 Claude Code 时有个习惯：改完代码就让它跑一遍测试。听起来理所当然，但很多人不这么做，改完就觉得"应该没问题"。差距就在这儿。一个 10 步流程，每步成功率 99%，端到端成功率只有 90.4%。步骤越多，验证越关键。

错误处理：不是 try-catch 那么简单

LangGraph 把错误分成四类，我觉得分得挺干净：

关键是第二类。传统编程里，函数报错就报错。但在 Agent 系统里，你可以把错误信息作为观察结果喂给模型，让它自己修正。有点像一个高级程序员看到报错会换个思路重试，而不是傻站在原地。

Claude Code 就是这么干的：工具执行失败时不崩溃，把失败信息作为结果返回给模型，让循环继续跑。Stripe 的生产系统限制每次最多重试两次，避免死循环。

"薄 Harness，厚 Skill" 是什么意思？

这是 Garry Tan 文章的核心论点，也是我觉得最有启发的部分。

他把系统分成三层：

┌─────────────────────────────┐
│   厚 Skill（Markdown 流程） │ ← 90% 的价值在这里
├─────────────────────────────┤
│   薄 Harness（~200 行代码）│ ← 循环+读写+上下文+安全
├─────────────────────────────┤
│   确定性基座（SQL/搜索等） │ ← 同输入同输出，永远可靠
└─────────────────────────────┘

智能往上推（进 Skill），执行往下推（进确定性层），Harness 保持薄。

反面教材是啥样？40 多个工具定义吃掉一半上下文窗口。一个 MCP 调用要 2 到 5 秒。把每个 REST API 端点都包成一个工具。三倍的 token，三倍的延迟，三倍的失败率。

Garry Tan 举了个具体例子：一个 Playwright CLI 做一次浏览器操作只要 100 毫秒，通过 Chrome MCP 做截图-查找-点击-等待-读取要 15 秒。75 倍的速度差距。工具不需要通用，需要快和准。

这让我想起自己写 Skill 的经历。刚开始我总想让一个 Skill 覆盖尽可能多的场景，结果 Skill 文件越写越长，模型执行时反而犯迷糊。后来学会拆分，一个 Skill 做一件事，做到位。看起来"笨"的 Skill 反而效果更好。

Skill 是"用 Markdown 写的方法调用"

这个观点让我眼前一亮。Garry Tan 说，Skill 文件本质上像一个方法：它定义流程，接受参数，不同的参数产出完全不同的能力。

他举了一个叫 /investigate 的 Skill，只有 7 步：界定数据范围、建立时间线、标注每份文档、综合分析、正反论证、引用来源。传给它不同的 TARGET、QUESTION、DATASET，它可以是医疗研究分析师，也可以是竞选资金调查员。

同一个 Skill，同一份 Markdown 文件，同样 7 步。区别只在传入的参数。

他有句话说得挺准的：Markdown 实际上是比硬编码更完美的能力封装形式，因为它用模型本身思考的语言来描述流程、判断和上下文。

确定性 vs 潜在空间：搞混了就是灾难

这是 Garry Tan 文章里我觉得最实用的一个区分：

潜在空间（Latent space）：LLM 擅长的地方。阅读、理解、判断、综合、模式识别。

确定性操作（Deterministic）：同样输入永远同样输出。SQL 查询、编译、算术。

他举了个例子：让 LLM 给 8 个人安排晚餐座位，考虑性格和社交关系，它做得挺好。但让它给 800 人排座位？它会"幻觉"出一张看起来合理、实际完全错误的座位表。因为这是组合优化问题，该用确定性算法解决，硬塞进 LLM 就是灾难。

最差的系统把错误的工作放在错误的一侧。最好的系统在这条线上毫不手软。

这个原则帮我避开了不少坑。数据统计、格式校验、文件操作这类事，别让 LLM 算，用脚本搞定。LLM 负责判断"要做什么"和"结果好不好"，执行交给确定性工具。

Skill 是永久升级

Garry Tan 文章最后讲了一个 YC Startup School 的实际案例，6000 个创始人的匹配和分组问题。传统做法是 15 人团队手工评估。他们用 Skill 系统来做。

一个 /enrich-founder Skill 把所有数据源拉过来，做 diarization（结构化档案），发现创始人"说的"和"实际在做的"之间的 gap。比如一个创始人说自己在做"AI 可观测性平台"，但 80% 的 commit 都在 billing 模块 —— 她其实在做 FinOps 工具。这种判断关键词搜索和 embedding 相似度都抓不到，必须让模型读完完整档案后自己下判断。

活动结束后，一个 /improve Skill 读 NPS 调查，专门分析那些给了"还行"评价的反馈（不是差评，是差一口气的好评），提取模式，把新规则写回 Skill 文件。下次运行就自动用更新后的规则。

第一次活动："还行"评价占 12%。下一次：4%。Skill 自己学会了什么叫"还行"，然后自我改进。

这才是 Skill 最让人上头的地方：每写一个 Skill 都是对系统的永久升级。它不会退化，不会忘记，凌晨 3 点自动运行。下一代模型出来时，Skill 里的潜在空间步骤自动变强，确定性步骤保持可靠。

Garry Tan 给他的 AI 立了一条规矩：

这条规矩在 X 上获得了上千个赞和两千多个收藏。大家以为这是提示词技巧，其实是架构设计。

三个可以立刻上手的动作

读完这两篇文章，我总结了三个能马上用的东西。

• 别再纠结用哪个模型了。 Claude 还是 GPT，Opus 还是 Sonnet，当然有差别，但差别远没有 Harness 设计带来的差距大。同一个模型，在好的 Harness 里是 100x，在差的 Harness 里是 2x。精力应该花在优化工作流上，不是追新模型。
• 把经验写成 Skill。 你在 AI 编程中发现一个有效的工作模式时，别让它停留在脑子里。写成 Markdown 文件，定义清楚步骤和参数。下次遇到类似问题，直接调用。这是复利，你的系统会越来越强。
• 管好上下文。 CLAUDE.md 不要写成百科全书。精简核心原则，细节放在单独文件里按需加载。这不是偷懒，这是工程设计。Garry Tan 的 2 万行 CLAUDE.md 就是反面教材。

Harness 的未来方向其实也很明确：模型越强，Harness 应该越简单，不是越复杂。Manus 团队在 6 个月内重写了 5 次，每次都是删代码。复杂的工具定义变成通用 shell 执行，"管理代理"变成简单的结构化交接。

Harness 是脚手架，不是大楼本身。建筑完工后脚手架应该拆掉。模型进化后，多余的 Harness 复杂度也应该被削减。如果你的系统在模型升级后不用加 Harness 复杂度就能自动变强，说明设计是对的。