Princeton NLP 做过一个实验：同一个 GPT-4，只换了外部环境接口，SWE-bench 性能提升了 64%。模型没变，训练数据没变，提升全部来自模型之外的工程层。
Anthropic 用另一种方式验证了同样的结论。Claude Code 的源码在 2026 年 3 月意外泄露——55 个目录、331 个模块、超过 50 万行 TypeScript。社区拆开一看：真正让 Claude 从聊天机器人变成能连续工作数小时的 coding agent 的，不是模型本身，是包裹在模型外面的那层工程系统。
这层系统，行业里现在统一叫它 Harness。
什么是 Harness：上下文窗口是一个计算盒子
LangChain 的 Vivek Trivedy 给了一个清晰的心智模型：上下文窗口是模型做计算的盒子，模型只能基于盒子里的东西推理。盒子外面的一切——工具定义、系统提示、技能描述、记忆存储——都是外部上下文，必须经过"检索→塑形→注入"三步才能进入盒子。
每一个被注入的对象，Vivek 称之为 Context Fragment（上下文片段）。System prompt 是一个片段，工具描述是一个片段，从记忆库里检索出来的历史经验也是一个片段。Harness 的核心工作，就是决定在每个时刻，哪些片段该进入盒子、以什么形式进入。
这里有一个信噪比问题：片段越精准，模型推理越好；片段越嘈杂或互相矛盾，模型越容易犯错。把一个 1MB 的日志直接塞进上下文窗口，不叫"给模型更多信息"，叫"用噪声淹没信号"。
Vivek 把这个问题推到了更长的时间尺度上。Agent 在每次交互中都会产生大量数据（Trace），这些数据可以被积累为经验记忆。Agent 的记忆有一个人类不具备的优势：它可以在所有 Agent 实例之间共享。一个 Agent 踩过的坑，所有 Agent 都能避开。
但记忆规模增长之后，存储不再是瓶颈，检索才是。能不能在正确的时刻找到正确的记忆片段注入上下文，决定了 Agent 的实际表现。Vivek 引用了 Rich Sutton 的 Bitter Lesson：搜索 + 规模，最终会赢。这个教训正在从模型训练领域蔓延到上下文管理领域。
来自行业一线的Harness落地经验
Y Combinator CEO Garry Tan在X发了一篇长文，解释为什么用同一个AI模型，有人效率2倍、有人100倍：差距不在模型，在架构——他把这个架构叫"thin harness, fat skills"
他的核心观点：模型的智能从来不是瓶颈。模型已经会推理、综合、写代码。它们的失败是因为不理解你的数据——你的模式、你的约定、你问题的具体形状。解决方案不是做一个更复杂的驾驭，而是把智能推到技能层。
技能文件是一个可复用的 Markdown 文档，教模型怎么做事。不是做什么——用户提供这个。技能提供流程。关键剖析：一个技能文件就像一个方法调用，它接受参数，用不同的参数调用就产生完全不同的能力。
他举了一个例子：一个叫/调查的技能，7个步骤（确定数据范围、建立时间线、为每份文档做摘要、综合、正反算法、标注来源）。指向一个安全科学家和210万封邮件，变成医疗研究分析师。指向一个壳公司和FEC备案记录，它变成追踪募集的法务调查员。同一个技能，同一个Markdown。
Harness本身呢？Garry认为它应该只做四件事：循环运行模型、读写文件、管理上下文、执行安全策略。大约200行代码。
他明确指出了反模式：Fat Harness，Thin Skills。40多个工具定义吃掉一半下游窗口。每个REST端点包装成一个单独的工具。MCP一次调用要2-5往返秒。三倍的令牌，三倍的延迟，三倍的失败率。他说他自己的CLAUDE.md曾经写到20000行，结果模型对话焦点，Claude Code自己建议他砍到200行——只获取指向文档的指针，在需要时加载时使用解析器。
技能能自我进化，这才是100倍生产力的来源
Garry 使用 YC 的创业学校活动做了一个完整的案例。Chase Center，2026 年 7 月，6000 个创始人。每个人都有包装申请、表格答案、1:1 顾问聊天记录、GitHub 提交数据、社交媒体信号。
传统做法是15人团队阅读申请、凭直觉判断、更新表格。在200个人时能用，用户增长到6000人时系统就崩溃了。没有人能同时记住6000人的个人资料，更不可能察觉到分配在拉各斯、新加坡和布鲁克林的三个创始人在1:1的聊天中描述了同一个痛点。
模型可以。 丰富创始人技能拉取所有数据源，进行分类（重构摘要），然后抓住创始人所说的和实际在做的之间的差距。
这个判断需要同时阅读 GitHub 提交历史、申请书和顾问聊天记录，然后进行综合推理。没有任何关键词搜索或缩小度搜索才能找到这种洞察。只有模型实际阅读完整的配置文件并做出判断才行。
更关键的是学习循环。活动结束后，一个/提高技能读NPS调查，专门分析那些评分“还行”的反馈（不是差评，是差一点的那些），提取模式，把新规则写回技能。然后第一次活动12%的“还行”评分，下一次降到4%。技能自己学会了“还行”到底意味着什么。
Garry 给了一条规则：如果我要求你做一件事，而这件事以后还要再做，你必须先手动做 3-10 次，给我看结果，我确认后，写成技能文件。如果需要自动运行，放在 cron 上。测试标准：如果我需要要求你做同一件事两次，你就失败了。
Claude Code 的源码验证了这套逻辑
2026 年 3 月，Claude Code 的源码意外泄露—— 55 个目录、331 个模块、50 万行 TypeScript。Rohit（@rohit4verse）做了逐文件拆解，发现 Claude Code 正是 Yegge 所说的那种架构的工业级实现。
几个要点的工程决策：
工具串分类。45+工具不是全串行也不是全串行，每个工具定义时标记并发类型：串行的串行运行（最多10个），写入的串行运行。串行的速度+串行的安全。
系统提示进行缓存设计。一个边界标记把提示放弃静态区和动态区，80% 的内容命中全局提示缓存，不需要每次重新标记化。这个设计决定了每个会话的成本是 $0.02 还是 $0.20。
四级成本的微紧凑（存储引用替换重复内容）到昂贵的上下文崩溃（多级分层压缩），便宜的先跑，贵的只是在极端情况下启动。大多数利用一上来就做总结，Claude Code 90%的情况下靠前两级零成本压缩就够了。
Rohit还发现了一个被忽略的第四层：基础设施。CLAUDE.md四级层次（企业→项目→用户→本地）是多枢纽RBAC。Git worktree隔离让各个子子工作的Agent各自在独立分支相互。文件锁防止各个Agent踩踏。这些不是线束，是让线束在环境生产中的基础设施。
用 Eval 让 Harness 自动变好
写好 harness 不是终点。Vivek 在 LangChain 博客上分享了 Better-Harness 方法论：用 eval 作为信号，自动迭代优化 harness。核心类比：
模型 + 训练数据 + 梯度下降 → 更好的模型
Harness + Eval + Harness Engineering → 更好的 Agent
Eval 就是 harness 工程的训练数据。每个 eval 案例贡献一个信号："Agent 是否采取了正确的动作？"这个信号指导下一次 harness 编辑。
实操流程分四步走：
从手写案例、生产 Trace、外部数据集三个来源采集 eval，按行为类别打标签（工具选择、多步推理等），划分优化集和留出集。每轮迭代的逻辑是：诊断错误，做一个针对性的 harness 修改，验证通过新 eval 且不破坏已通过的。最后人工审核，检查是否过拟合到优化集。
Vivek 用 Claude Sonnet 4.6 和 GLM-5 做了实验，在 tool_selection 和 followup_quality 两个类别上，优化后的 harness 在留出集上几乎完全泛化。很多收益来自更明确的工具使用说明和失败模式描述。
一个有趣的发现：对于注入新工具（比如 search-then-email）的 eval，优化循环自动发现了更好的工具组合描述。这对做垂直领域 Agent 的团队很有参考价值——优化循环能自动适配特定领域的任务细节，不需要人工猜测该怎么写工具描述。
Harness 是 Agent 竞争的真正分水岭
2026 年的 Agent 竞争已经不在模型层了。GPT-4、Claude、Gemini、GLM 的能力差距在收窄，但基于同样模型构建的 Agent 产品，用户体验差距巨大。差距来源就是 harness。
短期看，掌握 harness 工程的团队能用同样的模型做出明显更好的产品。上下文管理、工具编排、错误恢复、权限系统——这些听起来不性感的工程决策，每一个都直接影响用户是否愿意把真实工作交给你的 Agent。
长期看，Vivek 指出的 Bitter Lesson 会成为主旋律：Agent 积累的经验数据将呈指数增长，能高效搜索和检索这些数据的系统会持续获得优势。Harness 不是一次性工程，而是一个需要持续迭代的学习系统。
对开发者的具体建议：从 Claude Code 的架构中挑任意一个组件开始实践——工具并发分类、上下文压缩层次、或者 eval 驱动的迭代循环。不需要一次性搭建完整 harness，但每一个正确的工程决策都会叠加成竞争壁垒。