模型不是产品
这个行业里的每个人都在谈论模型能力。哪个模型最聪明。哪个基准测试进步了。哪个供应商这个季度领先。
我怀疑有一段时间了，模型能力并不是真正产品差异化所在。然后51.2万行Anthropic的生产代码意外泄露到互联网上，我得到了我所见过的最清晰的证据。
2026年3月31日，Claude Code 2.1.88版本发布，npm包中包含了source map。有人忘记了.npmignore文件。几小时内，完整的TypeScript代码库在GitHub上获得了8.4万+星标。Anthropic确认这是人为错误，不是安全漏洞。
泄露的不是模型。没有权重，没有训练管道。泄露的是其他一切——编排、权限系统、故障恢复、内存架构、参与设计，以及44个完全构建的功能，隐藏在编译时标志后面，没有任何用户见过。
我把这一层称为harness——决定一个有能力的模型是成为人们可以进行数小时实际工作的东西，还是一个只会让人印象深刻十分钟然后就崩溃的东西的工程。
我一直在阅读泄露后发布的社区分析。我反复回味的设计决策不是关于模型能做什么。而是关于harness。而且我认为大多数构建AI产品的团队都在这方面投资不足。
以下是我发现值得分享的内容。
1、自我回报的压缩
我从这里开始，因为这个代码库中的一个小机制可能是整个泄露事件中最具商业价值的决策。
Claude Code用三个压缩层级管理其上下文窗口。最轻的在每次API调用前清除旧的工具输出。中等的大约在93.5%的上下文使用率时触发并生成摘要。最重的进行全面重建——总结所有内容，然后只用最相关的材料重建会话。
扎实的系统工程。但吸引我眼球的是一个叫做cache_edits的最轻层机制。
这是它解决的问题。提示缓存削减了token成本，但缓存需要在消息数组中有稳定的前缀。如果你的压缩逻辑修改了该数组以清理陈旧内容，缓存就会失效，你就会失去折扣。大多数团队将压缩和缓存视为两个独立的关注点。这个团队没有。当缓存处于热状态时，压缩层保持本地消息数组不变。相反，它随API调用一起发送服务器端删除。陈旧内容被清理，而不会触碰缓存。
在大规模下，这很重要。保留你的缓存与在每次API调用时使其失效，跨越数千个会话，累积起来是很快的。我还没有在agent构建社区中看到太多关于这种共同设计的讨论。它值得更多关注。
压缩系统还有一个断路器：连续三次摘要失败，重试循环就会停止。如果没有它，agent可能会在没有在任务上取得任何进展的情况下，燃烧掉剩余的token预算试图压缩自己。任何构建过摘要循环的人都知道这种失败模式。硬编码的停止告诉我他们在生产中遇到过这种情况，并决定确保它再也不会发生。
这背后的所有东西都是一个我认同的产品决策。Token预算不仅仅是一个成本数字。它是一个质量数字。随着上下文被填满，agent输出会变得更糟。将这种退化视为一个工程问题——而不是警告用户的事情——是把人们使用十分钟的工具与使用数小时的工具区分开来的东西。
2、无法被说服穿透的权限墙
大多数团队通过指令来处理agent安全。告诉模型它不应该做什么。希望指令能够坚持。
Claude Code做了不同的事情。生成动作的系统与决定这些动作是否被允许的系统是作为独立组件构建的。不是通过约定。而是通过架构。
每个工具调用都要经过一个deny-first管道。Deny规则首先运行并总是获胜。即使是自动化绕过标志——命名为--dangerously-skip-permissions，这告诉你团队对它的感觉——也无法覆盖某些保护。
权限分类器分两个阶段运行。第一个是快速且保守的——偏向阻止。当它阻止时，第二阶段用更大的推理预算运行，以检查误报。连续三次阻止，就由人类来做决定。
这是我一直在思考的决策。分类器只看到工具请求——动作及其参数。它从不看到模型的推理。没有助手文本。没有理由。这不是一个提示说"不要被说服性的论点左右"。说服通道根本不存在。权限系统无法被说服做任何事，因为它从未听到对话。
还有一个关于什么保持受保护的聪明区分。像.bashrc和.gitconfig这样的系统文件即使在完全绕过模式下也保持门控。为什么？因为对.bashrc的错误编辑不会在发生时造成伤害。它会在之后的每次shell打开时造成伤害，持续数周。保护比会话持续更长时间，因为伤害会比会话持续更长时间。
如果你正在构建agent产品，这值得诚实地问自己：你的安全边界是模型遵循的指令，还是模型无法穿透的墙？指令随着模型变得更有能力而变弱。墙不会。
3、有边界的agent，显式升级
多agent系统——内部称为swarm——运行在严格的层级结构上。协调器拥有完整任务。worker拥有有边界的子任务。角色不混合。
Worker在生成时锁定权限。这些权限在执行期间无法增长。Worker只发回输出——而不是它们的工作上下文。并行工作流保持隔离。
当worker遇到超出其批准阈值的事情时，它不会即兴发挥。它通过基于文件的邮箱将请求发送给协调器。升级是内置于系统的，而不是在提示中建议的。
一个我喜欢的细节：团队在他们的代码注释中写道，在他们完全强制执行资源限制之前，他们在292个并发agent的情况下遇到了36.8 GB的内存使用。这种诚实——写下你通过破坏东西发现的上限——对未来工程师比对假装极限一直都知道的干净文档更有用。
这里的产品逻辑与我从企业买家那里一直听到的东西有关。他们不想要最大并行。他们想要理解发生了什么以及为什么。一个无界agent与其他无界agent并行运行会产生难以调试和难以解释的结果。有界范围和显式升级会产生可以推理的结果。在大多数企业环境中，"agent自己决定那么做"不是一个可接受的答案。可预测性就是功能。
4、每个失败都有回头路
查询引擎处理每个LLM API调用、每个流式响应、所有缓存和编排。它是一个46,000行的单文件。看起来应该被拆分。但理由是合理的：这一层的失败模式相互影响。上下文溢出影响模型可用性。速率限制影响会话状态。模型退化影响任务连续性。把所有东西放在一起使这些交互可见。
系统是一个状态机，其中每个失败都有定义的处理。上下文满了？压缩并恢复。模型连续三次过载？切换到更轻的模型继续——用户永远看不到错误。任务中途输出预算不足？静默注入继续指令，连续三次低进展完成后硬停止。进程被杀死？从上次磁盘写入恢复并继续。会话状态在每次API调用前保存到磁盘。没有死胡同。
重试逻辑中还有一个聪明的非对称性。前台任务——用户正在等待的——用退避重试。后台任务如摘要器和分类器完全不重试。在负载下重试的后台任务只会让负载更糟。这种区分只来自在真实压力下观察真实系统。
这对我来说是整个代码库中最重要的想法之一。一个向用户展示每个超时、每个溢出、每个打嗝的agent教会他们期待东西会坏。一个吸收这些失败并继续工作的agent教会他们信任它。这两种体验之间的差异不是模型质量。而是harness质量。
5、怀疑自己的记忆
记忆系统违背了存储一切的直觉。agent被构建为将自己的记忆视为提示，而不是事实。
顶层是MEMORY.md——限制为200行，每次查询加载。它只存储指针。指向真实知识所在的简短引用。没有内容。真正的知识放在按需加载的主题文件中——用户偏好、项目约束、反馈。原始会话转录是第三层，放在磁盘上，只有前两层没有内容时才搜索。
索引只在确认成功写入后更新——从不猜测。agent被要求在根据记忆的事实行动之前，针对当前状态验证它们。如果某事可以直接在代码库中检查，新鲜检查胜过存储版本。
一个叫做autoDream的后台进程在空闲时整合记忆。它作为一个具有只读访问权限的分叉子agent运行，与主agent隔离。这种隔离就是重点。一个可能损坏它正在维护的状态的整合过程会造成它本应防止的问题。
这超越了技术细节。在任何长期运行的agent关系中，记忆关乎信任。当我与工具分享上下文——我如何工作，我尝试过什么，什么没用——我是在打赌它会很好地使用这些信息，不会盲目地根据陈旧信息行动。记忆系统是否被构建来赢得那种信任，还是只是为了囤积数据，塑造了数月的关系。
6、展示哲学的小决策
上面的章节涵盖了结构工程。但这个代码库中最能说明问题的东西有些更小。它们展示了团队如何看待产品与其用户之间的关系。
187个加载消息。有人写了187个独特的spinner消息——"召唤缪斯"、"构建神经通路"。不是五个。不是二十个。187个，所以同一条消息在会话中几乎从不重复。这是件小事。但它告诉你团队将等待状态视为一个产品时刻，而不是死时间。系统思考时说的话影响用户是否感到掌控或被蒙在鼓里。
KAIROS和15秒规则。一个未发布的守护进程，关于时间推理。不仅仅是是否主动行动，而是何时。任何会阻塞用户超过15秒的主动行动都会被延迟。这在调度算法中。大多数构建主动agent的团队没有仔细考虑过时间。这个团队显然有。
执行层中的挫败感检测。编排器中的模式匹配——不是UI——检测用户输入中的挫败感信号并改变系统行为。这种放置方式说明了我认为正确的东西：当用户对agent感到挫败时，问题通常是执行，而不是语气。他们不需要更富有同理心的回复。他们需要系统改变它正在做的事情。
BUDDY。一个Tamagotchi风格的宠物，有18个物种、稀有等级和叫做CHAOS和SNARK的属性。理由说得通：agent工具随着它们学习你的代码库在数月内变得更有价值，但早期会话是艰苦工作，然后这种学习才会得到回报。游戏机制可以平滑留存差距，而无需核心价值在第一天就显而易见。无论它是否发布，它被构建的事实——通过真正的迭代——告诉你团队认真对待冷启动问题。
44个功能标志，零个暴露。44个完全构建的功能，在生产环境中不可用，从外部构建中编译掉。工程师持续交付。产品控制发布。对于一个错误功能意味着agent在某人的代码库上采取破坏性行动的产品，"已构建"和"已发布"之间的差距是有道理的。
7、我从中学到的
我一直在思考模型能力和产品可靠性之间的差距。这次泄露让我看到了这种差距在实践中是什么样子的最清晰视图，以及需要做什么来弥合它。
Harness就是产品。与缓存经济共同设计的上下文压缩。作为架构而非指令构建的权限边界。没有死胡同的故障恢复。自我检查的记忆。由理解等待是体验一部分的人编写的加载消息。
这些都不是模型能力。所有这些都决定了一个有能力的模型是否成为人们信任的持续工作的东西。
最后一件事。代码库包含一个叫做Undercover Mode的功能。当Anthropic员工在公共仓库上工作时，它从提交中剥离AI归属。系统提示写道： "你正在UNDERCOVER行动。不要暴露你的掩护。"它可以被强制开启，从不会被强制关闭，并且从外部构建中编译掉。
Undercover Mode有效。它从未被攻破。
泄露发生是因为发布管道中缺少.npmignore。
代码库中最谨慎的安全功能完美地完成了它的工作。失败是在一个完全不同的系统中。应用工程和发布管道卫生是独立的问题，解决一个并不能解决另一个。任何没有将安全思维扩展到构建产物、包配置和部署管道的AI产品团队，其堆栈中都有相同的漏洞。唯一的区别是还没有人找到他们的。
原文链接: The Model Isn't the Product: What the Claude Code Leak Reveals About Harness Engineering
汇智网翻译整理，转载请标明出处