“哈内斯”到底是什么？！关于据说能提升人工智能生产力的哈内斯

开篇

上个月3月31日，发生了一件令人难以置信的事情。Anthropic不慎将自家AI编程工具Claude Code的全部源代码公开发布到了npm上。共计51万2千行代码，1,906个TypeScript文件。发现后仅数小时，这些代码就被备份到GitHub，被复刻（fork）超过41,500次，如今仍在互联网某个角落流传。

Anthropic解释称这是“打包失误”，但开发者社区却因为另一个原因沸腾了起来。因为泄露的代码证实了此前一直只是传闻的“AI智能体生产力差距的秘密”。（关于这一点，我也曾在ZDnet撰写过专栏。）

硅谷最大的创业加速器Y Combinator的CEO Garry Tan亲自读完了泄露的51万行代码，写下了这样一句话：

“秘密不在于模型本身，而在于包裹模型的那个东西。”

今天要聊的，就是关于这个**“那个东西”**的故事。明明用的是同一个Claude，为什么有人的生产力只提升2倍，有人却能达到100倍？ 其实这场深挖最初是出于怀疑心理才开始的。我本人对“生产力提升几倍”这种说法非常不信任。但这次的情况，多少有点道理。而且，这也关系到未来企业的AI投资战略将如何被颠覆。

同一个模型，100倍的差距：不同之处在哪里

拥有40年从业经验的工程师Steve Yegge最近在一次采访中抛出了一个挑衅性的数字。他说，能够熟练驾驭AI编程智能体的工程师，其生产力是使用普通聊天机器人的工程师的10倍到100倍，比起2005年谷歌员工，更是高出约1,000倍。

一线从业者一直怀疑这个数字有夸大之嫌。但Yegge明确指出了一点：“生产力提升100倍的人和只提升2倍的人，使用的模型是完全相同的。”两者都在用Claude Opus 4.6，两者拥有的也是同一个API密钥。

差距并非来自“智能”，而是来自“结构”。而这个结构简单到一张索引卡就能装下。

这次Claude Code泄露事件用实证数据支持了这一论断。分析了51万行源代码的开发者们发现的，并非“更聪明的模型”，而是“设计得更巧妙的封装层（wrapper）”。泄露的代码中包含44个隐藏功能开关（feature flag）、三层结构的“Self-Healing Memory”系统，以及一个名为“KAIROS”的自主智能体守护进程模式。而LLM模型本身，在代码中根本找不到踪影。取而代之的，是一套“在正确的时机，将正确的上下文，无噪声地传递给模型的精密架构”。

业界将这套架构称为harness¹（哈内斯），意为为驾驭马匹而套上的马具。

“Thin Harness, Fat Skills”：架构的逆转

Garry Tan提出的框架，名字本身就非常直观——“薄哈内斯，厚技能”（Thin Harness, Fat Skills）。 这个思路，恰恰与业界迄今为止的做法完全相反。

以往的**“厚哈内斯”做法是这样的：把40多种工具定义硬塞进系统提示词（system prompt），每次调用MCP**²服务器都要等上2到5秒，还要把每一个REST API端点都单独包装成一个工具。结果如何？令牌数（token）翻3倍，延迟翻3倍，失败率也翻3倍。模型的上下文窗口有一半都被工具说明吃掉了，真正用来解题的空间反而所剩无几。

而“薄哈内斯，厚技能”则是这样的结构。

**技能（Skill）³**是用Markdown写成的、可复用的流程文档。它教给模型的不是“该做什么”，而是“该怎么做”。Tan举的例子令人印象深刻。有一个叫/investigate的技能，由7个步骤组成，接收TARGET、QUESTION、DATASET三个参数。

• 输入一名安全研究员和210万封邮件 → 变成一名医学研究分析师
• 输入一家空壳公司和FEC竞选资金申报文件 → 变成一名法证调查员 同一个Markdown文件，同样的7个步骤。变的只是输入而已。Tan将其形容为“把Markdown当作编程语言、把人类判断当作运行时（runtime）的软件设计”。他强调，这并不是提示词工程（prompt engineering）。

哈内斯（Harness）是驱动LLM的薄薄一层。按Tan的标准大约200行。它只做四件事：让模型循环运转、读写文件、管理上下文、设置安全防护。仅此而已。

最后一层，是确定性（deterministic）工具。像SQL查询、编译好的代码、算术运算这类，必须保证“相同输入永远得到相同输出”的东西。Tan有一句强调过的话：

“LLM可以为八个人安排晚宴座位，考虑到性格和社交关系。但如果让它安排800人的座位，它就会一本正经地幻想出一份看似合理、实则完全错误的座位表。”

组合优化问题是确定性问题。硬把它塞进潜在空间（latent space）⁴​，就会失败。反过来，“两位创始人虽然都在AI基础设施领域，但并非竞争对手，因为一个做成本归因，另一个做编排”——这种判断，是嵌入相似度搜索绝对捕捉不到的。“把哪项任务放在哪一边”，正是系统设计的核心所在。

总结一下：智能在上层（技能），执行在下层（确定性工具），哈内斯保持轻薄。这种结构最强大的特性在于：每当模型升级，所有技能都会自动变得更好，而底层的确定性层则始终稳定不变。

为什么这在当下如此重要：Anthropic的“技能”公开战略

这次泄露事件之所以令人震惊，并不仅仅因为源代码被公开了。而是因为Anthropic早已在推动把这套架构确立为行业标准。

2025年10月16日，Anthropic公开了名为“Agent Skills”的功能。两个月后的12月18日，将其转化为一项开放标准。这与当年把MCP（Model Context Protocol）打造成行业标准时用的，是同一套打法。只需一个名为SKILL.md的Markdown文件加上YAML元数据，就能为AI智能体注入某一领域的专业知识。Microsoft、OpenAI、Cursor、GitHub、Atlassian、Figma等公司都已经采纳了这一标准。

其中一项重要的设计原则叫渐进式披露（Progressive Disclosure）⁵。在起始阶段，只有技能的名称和说明会被加载进系统提示词（50到100个token）。当模型判断“需要用到这个技能”时，才会读取完整的SKILL.md，而其中引用的辅助文件，也只在真正需要时才被加载。这就像“把上下文窗口当作图书馆，靠索引来访问，只有需要时才把书架搬出来”。

Tan公开的一段经历，恰好展现了这一原则的核心。他曾把Claude Code的配置文件CLAUDE.md扩充到2万行，想把自己遇到的所有模式和经验教训都塞进去。结果如何？模型的注意力急剧下降。Claude Code竟然直接对他说：“把这个缩减一下吧。”解决办法，是把内容压缩成约200行的“指针文档”。原有2万行知识原封不动地保留，只是改为由解析器（resolver）在需要时才调用。

这种模式，与硬件行业所说的“分层缓存”设计颇为相似——设置L1、L2、L3缓存，常用数据放得近，不常用数据放得远。AI智能体也正是依循同样的原理，在设计一套“知识的记忆层级”。

Oswarld视角

这个框架真正的爆发力，在于它颠覆了企业内部知识资产的结构。过去数十年间，企业管理知识资产的方式无非两种：一种是文档（如Confluence、Notion等），另一种是代码（如ERP、CRM、内部工具等）。两者都有局限。文档只有人去读了才会“活起来”，代码则缺乏灵活性、维护成本高昂。而介于两者之间的那片模糊地带（比如“销售团队的报价流程”、“法务团队的合同审查标准”、“市场团队的品牌指南”），一直只存在于人的脑海之中。

技能文件正是把这片“模糊地带”资产化的新方法。只要在一张Markdown文档中记录流程、判断标准和示例，它就成了可复用的组织能力。Canva、Stripe、Notion、Zapier这类SaaS企业之所以已经开始以SKILL.md的形式公开自家服务的操作方法，原因就在于此。这与API文档性质不同。API告诉你“该怎么调用”，而技能告诉你“该在何时、以怎样的顺序、经过怎样的判断去调用”。

在这股潮流中，我最关注的是Tan的一句话——“技能是永久性的升级”。传统软件用得越久，技术债（tech debt）⁶​就积累得越多。但技能恰恰相反。一次写得好的技能，每当有新模型问世，就会自动变得更好。判断的部分随模型升级，确定性的部分则始终稳定不变。也就是所谓的“一次做好，永久运转”。

不过，有一点我想冷静地指出来。根据Snyk于2026年2月发布的报告，在经过公开审计的技能中，36.82%存在安全缺陷。带有恶意的技能可能带来数据泄露、未授权系统访问等风险。技能必须被当作“代码”而非文本来对待。版本管理、指定负责人、定期审查……这些，是企业引入技能时无法回避的成本。

“AI时代的新资产不是模型，而是技能库”这一命题固然浪漫，但目前仍是“唯有管理得当才能成立的前提”。哪个组织最先确立这一前提，谁就会是下一轮生产力差距的受益者。

结语

我一向对“生产力提升100倍”“爆发式增长”这类说法先持怀疑态度。原因很简单：既然要说提升了X倍，就必须有一个基准数字，如果没有这个基准，我们又该如何相信这种增长呢？1个人变成3个人算是3倍增长，和100人变成300人算是3倍增长，这两者的分量显然是不一样的。这期通讯，正是从“用了哈内斯，生产力真能提升100倍？”这一疑问出发的。类似的新词汇想必还会不断涌现——提示词工程、上下文工程、哈内斯工程……不必被这些名词吓到。相反，只要清楚地理解它们运作的方式就够了。

第一，AI生产力差距的本质不在于模型，而在于架构。Claude Code的泄露事件所展示的，不是“更聪明的大脑”，而是“更巧妙的结构”。

第二，“薄哈内斯，厚技能”，是一场软件设计哲学的转变。智能以Markdown的形式置于上层，执行以代码的形式置于下层，编排则保持轻薄。这一原则，已经是Anthropic、Microsoft、OpenAI、Cursor共同接受的行业标准。

第三，企业的竞争力，正在从“用了多好的模型”转向“拥有多深厚的技能库”。 只是，这种资产化也一并带来了安全与治理方面的课题。

如果你在读这篇文章时，脑中浮现出“我们组织现在的AI导入战略更接近哪一边？”这样的问题，那么这个问题本身，就是今天这期通讯的价值所在。相比花时间比对模型的规格表，不如花时间去找出团队内部那些重复性工作中，“只要用一张Markdown文档梳理清楚，就能变成永久资产”的部分——现在正是这么做更有效的时候。

如果反响不错，下一期通讯我会聊聊这套结构的另一面，也就是“拥有技能架构的组织，为何能撼动既有的大企业”。所谓反响不错，就是评论多、分享多的意思！欢迎把这期通讯分享给朋友，并邀请他们订阅！

参考资料与延伸阅读

核心来源

• Garry Tan，《Thin Harness, Fat Skills》，gbrain GitHub仓库，2026年。：本期通讯所整理框架的原始出处。“薄哈内斯、厚技能”的三层架构被浓缩在一张索引卡上。
• Anthropic，《Equipping agents for the real world with Agent Skills》，Anthropic Engineering Blog，2025年12月。：详细说明了SKILL.md标准和渐进式披露（Progressive Disclosure）的设计原则。若想亲自动手制作技能，建议先读这篇文档。
• Steve Yegge，《The AI Vampire》，Medium，2026年2月。：分析了10倍／100倍生产力的实质，以及其背后隐藏的“吸血鬼效应”（无法持续超过3小时）。
• Gergely Orosz，《Steve Yegge on AI Agents and the Future of Software Engineering》，The Pragmatic Engineer，2026年2月。——其中包含Yegge的“AI采用八阶段模型”，以及为何大企业在结构上难以吸收这种生产力提升的洞见。

背景知识

• VentureBeat，《Claude Code’s source code appears to have leaked: here’s what we know》，2026年3月31日。：分析了泄露事件的技术细节，以及被公开的“Self-Healing Memory”“KAIROS”设计。
• Zscaler ThreatLabz，《Anthropic Claude Code Leak》，2026年4月。：整理了泄露事件的时间线，以及安全风险（尤其是与Axios供应链攻击相结合的部分）。
• Snyk，《Agent Skills Security Audit Report》，2026年2月。（按新闻引用标注）：这是公开技能中36.82%被发现存在安全缺陷这一数据的依据资料。若正在考虑推进技能资产化的组织，值得参考。

作者安光涉是世宗大学经营学教授，也是 OBF（Oswarld Boutique Consulting Firm）首席顾问。他在大学教授经营数据管理、商业分析等统计与数据分析课程，同时在产业现场负责 GTM 与人工智能战略咨询，设计技术与商业的连接方式。他曾发表关于 AI 对话系统记忆架构（HEMA）的学术论文，并运营每日策展全球 AI 论文的 Daily Arxiv 项目。他毕业于高丽大学技术经营专业研究生院与 KMBA，著有《把思考交出去的人：Homo Brainless》。

注释

1. 哈内斯（Harness）：驱动LLM运转的形式。它负责让模型循环运转、读写文件、管理上下文、设置安全防护。这个名字取自套在马身上的马具。 ↩

2. MCP（Model Context Protocol）：Anthropic于2024年公开的一项开放标准，用于规范AI智能体与外部工具及数据源的连接方式。它与Agent Skills是互补关系——如果说MCP负责“连接”，那么Skills负责的就是“用法”。 ↩

3. 技能文件（Skill file / SKILL.md）：用Markdown写成的、可复用的流程文档。它教给模型的不是“做什么”，而是“怎么做”。由YAML元数据和Markdown正文组成。 ↩

4. 潜在空间（Latent space）与确定性（Deterministic）：潜在空间是AI进行判断和解读的领域，即便输入相同，每次得到的输出也可能不同。确定性领域则是像SQL查询或算术运算那样，相同输入总能得到相同输出的领域。系统设计的核心，就在于“把哪项任务放在哪一边”。 ↩

5. 渐进式披露（Progressive Disclosure）：一种不把所有信息一次性全部加载，而是在需要的时刻只调取所需部分的设计原则。就AI智能体而言，会先加载技能的名称／说明，实际内容则在需要时才被调用。这是高效利用上下文窗口的关键技巧。 ↩

6. 技术债（Tech debt）：指为求短期便利而选择的代码或设计上的“捷径”，长期累积下来所形成的成本。会导致日后修改或扩展变得困难。 ↩