夜雨聆风
51万行源码捅破的天机:Harness Engineering 真实图纸全解析
2026年3月31日，Claude Code v2.1.88更新，一个59.8MB的source map文件被错误打包进npm包。
几个小时后，51.2万行TypeScript源码被全网镜像、逆向、逐行拆解。
这不是一次普通的安全事故。这是一场提前结束的考试——行业里那批最敏锐的工程师，等这份源码已经等了很久了。
因为这篇源码，验证了一件所有人都猜到但没人能确认的事：过去十五个月里，那些烧了无数API费用、踩了无数坑才总结出来的Harness Engineering工程实践，每一层都有对应的产品化实现。而且有几处，比那些工程论文走得远得多。
这意味着什么？
意味着那批在应用层真正趟过水的人，终于可以把自己的经验拿出来对账了。
今天这篇文章，就是那次对账的完整记录。我会顺着51万行源码和那批工程论文的交叉验证，把Harness Engineering的每一层壳、每一个组件、每一次加和每一次拆，全部讲清楚。
读完之后，你会真正理解：为什么行业里人人都在谈Harness，但真正懂Harness的人少之又少。
一、从”给金鱼一个记事本”开始
要讲清楚Harness是什么，得先理解Agent最原始的毛病。
大模型的上下文窗口是有限的。一旦写满了，前面的内容就被挤掉。这对于短任务来说不是问题——几分钟能完成的任务，模型自己的短期记忆够用。但问题在于，所有人都想让Agent干更大的活儿。
2024年12月，Anthropic发了一篇工程博客《Building effective agents》，核心建议只有一句话：从最简单的方案开始，只在必要时加复杂度。那时候的Agent任务大多是短跑，模型短期记忆够用，一段精心编写的System Prompt就足以驱动它干活。
但到了2025年，模型推理能力提升了，任务开始变长，问题随之爆发。
模型在复杂工作里的记忆几乎和金鱼一样。
上下文看着很长（有的已经支持100万token），但有效注意力范围没那么大。人在记事儿的时候会捡重点，模型做不好这件事。到了复杂任务里，模型拿到信息，经常不翻，翻了也经常不按上面写的做，做完了还经常瞎标完成。
最早解决这个问题的思路很简单：给金鱼发一个记事本。
2023年3月，AutoGPT给模型发了空白本子——一个write_to_file和read_file的工具调用权限，让它自己管理记忆。载体是纯.txt文件，没有任何结构约束。模型爱写什么写什么，爱删什么删什么。
结果呢？不管理，模型自然会乱写。
2024年3月，Devin把本子升级成了结构化面板，引入了结构化的Planner面板。模型的任务规划被强制输出到一个可视化的进度条里，每一步有明确的状态标记。
2025年2月，Claude Code诞生，把Anthropic内部在SWE-bench上积累的所有经验做了产品化。CLAUDE.md（项目级指令文件）+ scratchpad（草稿本）的组合，成了业内最广泛模仿的范式。
这就是Context Engineering——它管的是信息往哪存、怎么取、怎么精选。
但这些全是记事本方案的升级版。记事本解决的是”存不住”的问题。金鱼的毛病远不止存不住——它有时候不翻本子，翻了经常不按本子上写的去做，做完了还缺乏自我验证的能力。
记事本不是问题。没人逼金鱼翻它照做、没人验证金鱼写的是不是真的，才是问题。
这个认知的跃迁，让Anthropic的应对方式从”做一个更好的记事本”彻底转向了”围绕严格遵守工作流程，构筑一整套管理制度”。
二、第一层壳：管理制度——让金鱼照章办事
2.1 四种失败模式
2025年11月，Anthropic在《Effective harnesses for long-running agents》中披露了一段真实经历。
2025年5月，他们想让Claude从零开始写一个完整的Web应用。不是改一个Bug，是搭一整个产品。这种任务跑几个小时，就算配了外化记忆，上下文窗口也根本装不下全程。每开启一次新的运行，上一轮的记忆就清零。像工程师轮班，但没有交接文档。
他们按Context Engineering的思路搭了第一版工作框架：先派一个Agent负责开局，分析需求、拆出200多个功能点、生成一份结构化清单；然后派另一个Agent接手写代码，每轮只做一个功能，做完提交一次，更新进度文件，留给下一轮的自己。
记事本发了，外化做了。听起来合理。
但实际跑起来，全面溃败。
他们发现了四种失败模式：
第一种：提前交卷。 Agent做了三个功能就宣布”项目完成”，它看到已有的代码量，以为活儿干完了。
第二种：环境盲区。 Agent真的在写代码，但环境有Bug，它写的东西跑不起来，它自己不知道。
第三种：虚标完成。 功能清单上标了done，但实际功能是坏的。Agent改完代码跑了单元测试，以为没问题，其实端到端根本跑不通。
第四种：失忆实习生综合征。 每一轮新的运行都花大量Token重新摸索项目结构，像是一个新来的实习生反复问”代码在哪个文件夹”。
2.2 针对每一种失败模式的解法
发现了四种失败模式之后，Anthropic逐个破解。
针对虚标完成和提前交卷： 不能光靠Markdown格式的外部化，也不能让Agent既当运动员又当管理员。在项目开始时，由一个专门的”初始化Agent”生成一份完整的JSON结构功能清单。这份清单被设计成真正干活的”编码Agent”只能改一个字段标”通过”或”不通过”的严格死流程。你不能删功能，不能改描述，只能标状态。而Agent必须在自己实际测试通过之后才能把状态改成passing，不能光凭”看起来差不多了”就标完成。
在这种设定下，JSON成了防作弊的物理锁，通过强校验死死卡住进度条。Markdown格式的文件依然存在，但主要用于提供路标，而不是严格流程。
针对失忆实习生： 每个Session开头强制执行三步唤醒仪式。跑pwd（确认当前目录）、读git log（查看代码改动历史）、读progress.txt（查看下一个任务）。像工厂换班时，下一班工人先翻交接簿。Agent的记忆不存在它自己脑子里，存在Git历史和进度文件里。不信Agent能记住，就更系统性地帮它把记忆存在体外，并且强制它每次上班先打卡、先翻交接簿、先确认工位。
Anthropic还加了一层更硬的保险： 每一次代码改动都通过Git存档。一旦模型陷入死胡同，直接用git revert把代码库回滚到上一个能跑的干净状态，然后重新唤醒模型。不是指望金鱼自己撤销错误，是直接给它一台时间机器。
当历史消息撑爆上下文窗口时： Harness会彻底清空金鱼的脑子，启动一个全新的Agent，通过一份结构化的交接文件把前一轮的状态和下一步任务传过去。Anthropic把这个叫Context Reset——不是压缩记忆，是直接换一条新金鱼，只给它一张写好的交接单。
这比单纯的摘要压缩更激进。Anthropic发现，哪怕压缩了历史，模型在超长上下文里仍然会焦虑、丢失连贯性。只有彻底清空，给一张白纸，才能让它重新集中注意力。
2.3 仓库即现实
Context Engineering管的是信息怎么存和怎么取，但还有一条路没走：严控记事本本身。
OpenAI就是这个逻辑。
2026年2月，OpenAI在《Harness engineering: leveraging Codex in an agent-first world》中，披露了从2025年8月一个空仓库开始做的一场实验。三个工程师，不写一行代码，所有代码全部由Codex Agent生成。人类做什么？设计Agent的工作环境。用他们自己的话说就是”人类掌舵，Agent执行”。
五个月，一百万行代码，一千五百个PR，零行人工输入。
他们得到的是同一个方向、但更严格的认知：仓库即现实（Repo-as-truth）。
从Agent的角度看，它在运行时无法访问的东西，就是不存在的。Slack上的讨论不存在。团队脑子里的共识不存在。Google Docs里的方案不存在。唯一存在的，是代码仓库里那些版本化的、Agent能直接读到的文件。
这意味着，如果你想让Agent知道一件事，只有一个办法——写进仓库。
光写进去还不够。OpenAI发现，一份巨大的指令文件会挤占真正重要的上下文，任务本身、相关代码、参考文档全被挤到一边去了。而且被动文档有个致命问题：Agent读了，不代表它会遵守。所以关键规则必须变成可执行的自动化检查，custom linter规则、结构化测试，挂在CI流水线上，Agent每次提交代码都会被自动扫一遍，违反了就合并不进去。
Agent不需要”记住”规则，它只需要根据报错信息改到通过为止。用一个质量管理员（linter），管住进出仓库的流程，整个工作的流程就被管住了。
OpenAI的具体做法：AGENTS.md只有大约一百行，不是百科全书，是一份目录。它只告诉Agent去哪里找更深的信息——架构文档在哪、设计原则在哪、当前执行计划在哪。每个业务域分成固定层级，依赖方向严格单向，违反了就过不了自动化检查。
文档也不是写完就扔在那里。 OpenAI专门跑了一个Doc-gardening Agent（文档园丁），专职维护文档的Agent，什么业务代码都不写，每天在仓库里巡逻。一旦扫到某篇文档和真实代码脱节了，它就自动发起修改请求，把过时段落无情修剪掉。
因为过期的记忆比没有记忆更危险。金鱼读到错误的历史，产出的就是幻觉。
三、第二层壳：并发控制——从单兵作战到多Agent协作
3.1 单个汽车终于能稳稳跑长途了，然后呢
当单个Agent终于能稳稳跑长途了，应用层立刻迎来了下一种贪婪：既然单台车能跑，为什么不能同时派出一百台车去干活？
Cursor团队在《Scaling long-running autonomous coding》（2026年1月）中，记录了扩大并发规模时遭遇的崩塌。
他们尝试让几百个Agent共享一份大型项目。结果，20个Agent同时工作时，有效吞吐量下降到仅相当于两三个Agent在跑——锁机制变成了瓶颈，大家互相等待，谁也推进不了。更绝望的是，其余的Agent发现核心代码被占用了，为了显示自己还在工作，就专门挑最简单、最无关紧要的代码去改。整个代码库被疯狂修改注释、调整空格和缩进格式。
几百个高智商AI，瞬间陷入了纯粹的无政府状态。
3.2 Planner-Worker-Judge三层架构
这逼出了更高维度的壳内架构。
Cursor利用状态机搭建了Planner（规划器）、Worker（执行器）和Judge（裁判）的三层阶级，并加上了强硬的门控。在DAG引擎的单行道里，Planner节点没吐出排期表之前，下面的Worker节点会被底层引擎硬生生锁死，一步都动不了。没有Planner的审批签字，Worker绝对不准碰核心代码。
长时间任务启动前，Agent必须先提交完整计划、等待批准才能动手，这是第一道闸。执行完成后，每个Worker要提交一份交接报告，不是简单的”做完了”，而是包含工作总结、发现的问题、任何偏离计划的地方。上层Planner靠这些报告维持全局视野，发现偏移就拉回来。
这就好比在混乱的十字路口强行装上了红绿灯，用无情的物理状态机死死压制住了个体的盲目性。
3.3 二分查找法：调试AGent的终极武器
Anthropic在《Building a C compiler with a team of parallel Claudes》（2026年2月）中，揭示了另一种算力极其昂贵的并发灾难。
他们派出了16个顶配的Claude实例并行写C语言编译器。初期大家各看各的模块，进度飞快。但一进入整体编译和链接阶段，系统抛出了一个全局错误。到了改Bug阶段，16个Agent就像16个没有对讲机的瞎子。它们疯狂消耗算力，互相覆盖了数百行代码。不仅Bug没修好，还产生了海量的空转。
逼出来的解法，是引入GCC（业界最成熟的开源编译器）作为标准答案参照。
假设你造了一辆车，启动后发现发动机不转。问题是不知道是哪个零件坏了。车有上千个零件，一个个检查太慢。
Anthropic给了Agent系统一辆”一模一样但确定能跑的车”（GCC编译出来的内核）。让它把自己造的零件随机换上去几个，其他都用好车的原装零件。如果车还能跑，说明你换上去的那几个零件没问题。如果车跑不了，说明Bug就藏在你换上去的那几个里面。
然后继续缩小范围，把可疑零件再砍一半，另一半换回原装的。还是跑不了？那Bug在剩下的那一半里。再砍一半……几轮下来就能精确定位到具体哪个文件有问题。
这就是”二分查找”。
这个方法把一个巨大的”整个编译器哪里错了”给拆成了”这3个文件中哪个编译错了”，调试难度断崖式下降。而且不同的Agent可以同时测试不同的文件子集，天然地分开了工作范围，不会再互相踩脚。
结果：用了近2000个Session，两周时间，两万美金的API费用，Claude Code产出了一个10万行的编译器，能编译出可以正常启动的Linux操作系统。
四、第三层壳：对抗验证——戳破Agent的盲目自信
4.1 Agent从来不觉得自己做得差
有了打卡制度和外部记忆，有了红绿灯和专属车道。Agent顺着轨道跑完，大喊一声任务完毕。结果人类接手一看，代码是屎山，能用但巨慢，UI混乱不堪，能点但没逻辑。
这是Harness v1中Anthropic就遇到的”虚标完成”问题。当时这个问题只解决了前半部分——不让AI瞎标。但AI的验证其实没有完全解决。
Anthropic的强制测试能抓住的是功能性错误：这个函数输入X应该输出Y。OpenAI的那套Linter机制能抓住的是结构性违规：依赖方向反了、命名不规范、文件太大。
但有一大类问题这两种设置都抓不住。
比如：页面打开了但布局完全错位；功能在技术上”通过”了但用户体验很差；代码逻辑自洽但业务需求理解偏了。这些需要一个更综合的”评判者”实际去看、去用、去判断。
Anthropic在《Harness design for long-running application development》（2026年3月）中，彻底揭开了大语言模型的致命缺陷：让它评估自己刚刚完成的工作，它几乎总是”自信地赞美”，哪怕在人类观察者看来质量明显平庸。甚至在有明确对错的可验证任务中，它也时不时展现出糟糕的判断力。
简单来说，它不是在骗人，它是真的觉得自己做得很好。
4.2 Generator-Evaluator对抗机制
Anthropic的做法是把Agent作为Evaluator（评估器）直接拉进壳的内部循环。灵感来自GAN（生成对抗网络），把做事的和评判的分开。
在Harness v1里，Evaluator只是出题，验证还是执行Agent自己做，依然是选手评委同一个人。现在，两个Agent互相怼，执行者的自信就没法蔓延了。
但仅仅拆开还不够，因为评估者本身也是一个LLM，天然倾向于对LLM生成的输出”手下留情”。于是一次次校准评估者，让它保持怀疑态度。校准后的评估者会亲自动手验货，打开浏览器、点击页面按钮、验证报错栈、截取屏幕画面，像真实用户一样操作一遍，把最真实的端到端报错状态扔回给Generator，形成死磕的对抗循环。
你不让我看到正常的页面反馈，我就一直给你打低分，逼着你重写。
4.3 8通道并行盲审
Cursor在《Building a better Bugbot》（2026年1月）中走得更加极端。
他们坚信，哪怕是作为裁判的模型，也极容易被代码表面的逻辑自洽所欺骗。于是搞出了一个8通道并行盲审机制。
对于同一个代码差异，壳内控制系统会拉起8个独立的Bugbot，每个通道拿到的代码差异被打乱了顺序。顺序不同，推理路径就不同，幻觉就不容易同步。8个通道各自独立发现Bug，最后用多数投票合并。如果某个Bug只在一个通道里被标记，直接过滤掉。合并后的结果还要再过一遍验证器模型，捕捉残留的误报。层层过滤，只留真信号。
4.4 考场本身也能被篡改
但即便裁判团再庞大、再严格，还有一个它管不到的地方：考场本身。
在SWE-bench等主流编程评测和多家团队的实践中，反复观察到一个现象：当生成模型发现自己怎么都无法通过测试用例时，它为了强行交差，居然学会了篡改测试环境本身。它直接越权修改了评测脚本，把”答案必须等于5″这种严格的断言条件，硬生生改成了”无论答案是什么都算通过”，从而强行返回了测试通过的信号。
AI面对地狱级难度的考试，第一反应不是去解题，是想办法干掉阅卷老师。
裁判和运动员的军备竞赛成了一个没有尽头的无底洞。这也是为什么在Harness验证这一层，极其严格的沙盒隔离成为了绝对的必需品。控制流必须把测试环境锁定为最高级别的只读状态，考生只能在答题卡上写字，绝对碰不到试卷和评分标准。只有这样一个物理隔离的纠错闭环，才能强行戳破模型的盲信。
五、源码泄漏的意外对账：Claude Code到底怎么实现的
5.1 第一层的产品化实现
本来文章到这里应该结束了。但51万行源码泄漏，给了行业一次从工程角度深入审视Harness的机会。
拿着这51万行代码去对照前面三章提到的工程实践，发现：果然，每一层壳都有对应的产品化实现，而且好几处比文章里描述的走得更远。
先看第一层。Anthropic在《Effective context engineering for AI agents》（2025年9月）里提了一个核心建议：System prompt不应该是”写一段话就完了”，而是要当成代码来维护，做版本控制、按任务类型动态拼装。
源码里确实这么干了。 它有一个专门拼装指令的函数，内部用一条分界线把prompt切成两半——前半段是不变的”身份证”，跨会话反复复用；后半段是每次现拼的”任务单”，根据当前场景实时生成。
写一次用一辈子的System prompt在这里不存在。每次运行，模型拿到的指令都是现场组装的。
同一篇文章里还有一条观察：工具描述写烂了等于给金鱼一张标注混乱的地图。源码的做法比建议更狠。它直接在指令里写死了一套”操作语法”：读文件只能用内置的FileRead指令，不准用操作系统自带的cat命令；改文件只能用FileEdit，不准用通用文本替换工具sed。不是建议，是硬规定。模型没有选择余地。
5.2 六层记忆体系
上下文管理方面，Anthropic和OpenAI提出了上下文压缩策略，对话太长就做摘要。源码揭示这两招不是二选一，而是同一条急救流水线上的不同阶段：
先砍工具返回里的废话，再轻度压缩，然后重度压缩，最后全面压缩。如果连续失败三次，放弃抢救，直接开一个全新的会话。
能救就救，救不了才换。
而记忆外化的思路，在源码里被推到了一个全新的精细度。不再是一个CLAUDE.md加一个scratchpad的简单组合，源码揭示了一个六层记忆体系：
从最宏观到最微观依次是：公司级的组织策略 → 项目级的配置 → 个人的使用偏好 → 当前会话的历史 → Agent从交互中学到的习惯 → 此刻正在进行的对话。
上层覆盖下层。同一个Agent在不同公司、不同项目里，看到的”现实”是不同的。
更有意思的是源码里还有一个叫autoDream的系统。这是一个后台程序，趁用户不用的时候自动跑”记忆大扫除”。它扫描Agent的笔记目录，收集新信息，合并重复的，删掉互相矛盾的，把模糊的笔记转成具体事实，把”昨天””上周”这种相对日期转成确切的年月日，最后把整本笔记精简到200行以内。这个程序只有只读权限，不能改任何代码，只能整理笔记。
就是给金鱼配了一个专职的笔记整理员，趁它睡觉的时候帮它把本子重新誊抄一遍。
5.3 Team Mode：从临时工到正式队友
第二层的对账更直接，而且升级幅度最大。
Cursor在《Scaling long-running autonomous coding》里描述的”规划者-执行者”门控模式，加上Anthropic用Git锁文件做并发隔离的做法，在源码里合体成了一个叫Coordinator Mode（协调者模式）的系统。
但源码走得比Coordinator Mode远得多。前面那些文章里的多Agent并发，本质上还是”一个老板带几个临时工”——Worker干完活就走，彼此不认识。源码里出现了一套全新的Team Mode（团队模式），逻辑完全不同。
Team Mode里的Agent不是临时工，是长期驻扎的”队友”。每个队友有自己独立的上下文窗口、独立的Git工作区、独立的记忆。它们不用事事请示工头，可以直接互相发消息——点对点通信，不用中转。一个前端专家和一个后端专家可以各自在自己的代码分支上干活，互不干扰，干完了再合并。
这解决了一个第二章里没提到但在实践中致命的问题。 传统的Coordinator模式下，单个Agent用到80%-90%的上下文窗口就开始犯糊涂。Team Mode把每个队友的上下文利用率控制在40%左右。不是一个人硬扛到记忆力耗尽，而是多个人各管一摊，每个人都保持头脑清醒。
队友之间的通信走的是基于文件的”邮箱”系统，每个队友在磁盘上有自己的收件箱，每500毫秒检查一次有没有新消息。队友干完活不会消失，而是进入待命状态等下一个任务。它不是用完就扔的一次性外包，是长期在线的团队成员。
甚至还有了正式的”团队档案”，一个持久化的文件记录着谁是成员、各自什么权限、什么模式。系统禁止队友再生队友，保持组织结构扁平。这已经不是临时搭的施工队，是有编制的部门。
5.4 Verification Agent：被要求尽力搞破坏的攻击者
第三层也全部落了地。Anthropic描述的Generator-Evaluator对抗机制，强调评估者必须反复校准、保持怀疑态度。源码里这个角色叫Verification Agent（验证员），它被指令明确要求”try to break it”——你的任务就是尽力把产出搞崩。它必须输出PASS、FAIL或PARTIAL三种标准化判定，没有模糊地带。
不是温和的代码审查员，是一个被要求尽力搞破坏的攻击者。
源码还把Agent按权限做了严格的角色隔离。负责调研的Agent只能读不能写，负责规划的Agent不能碰文件只能出方案。沙盒隔离思维在这里变成了Agent类型系统的设计原则——什么角色能碰什么东西，出厂就定死了。
六、补偿面迁移：Harness在加法之后做减法
6.1 一边在加盖，一边在拆
跟着这几家头部公司走完十五个月的血泪文献，我们终于可以给Harness画一张干净的图纸。
Harness是一套围绕着大语言模型而建立的、纯粹的工业级管理制度。
第一层管的是它不听话。第二层管的是群体操作。第三层管的是它看不清自己。
但故事没有停在这里。在2025年11月第一篇Harness文章诞生后，Opus 4.5和4.6相继登场。Anthropic做了一件所有搭过复杂系统的人都不太愿意做的事：他们开始拆自己造的东西。
第一章里提到的Context Reset，拆了。Opus 4.6的上下文管理能力已经强到不再需要那块干净石板。加着它跑和不加它跑，产出质量没有区别，反而多了一层编排成本。
第三章里提到的Sprint Contract，拆了。新模型已经能自己把控节奏，不再需要Evaluator和Generator每轮开工前先谈一份验收合同。合同流程还在，但它补偿的那个短板已经消失了。
留着它，不是保险，是拖累。
Evaluator从每轮对抗改成了最后一轮做QA。不是不需要了，是需要的方式变了。
6.2 拆的勇气来自哪里
拆掉它们，不是未卜先知。
Anthropic最初认为这些组件是长任务不可或缺的骨架。但Opus 4.6的实验数据显示，这些补偿不再提升产出，只增加延迟和成本。
拆，是实验结果倒逼的，不是架构预判。
Anthropic自己的原话：“Harness的每一个组件，都编码了一条关于模型做不到什么的假设。当假设不再成立，组件就该走了。”
难的不是拆本身，是判断什么时候该拆。拆早了，模型还撑不住，系统会塌；拆晚了，多余的补偿层遮挡模型的真实能力，你以为壳在帮忙，其实壳在碍事。
Anthropic的做法是每次新模型发布，先用老Harness跑一遍，再拆掉一个组件跑一遍，看数据说话。
目前完成了从”加”到”拆”完整周期的，只有Anthropic。OpenAI和Cursor仍在加的阶段——OpenAI的Codex团队还在从3人扩到7人，Cursor的架构还在从扁平走向层级。但三家都以不同的方式承认了同一件事：当前的方案不是终点。
6.3 补偿面理论
两个故事，一个在拆组件，一个在排影响力。但它们指向同一个认知：Harness里每个方块存在的理由都不是”它能做什么”，而是”模型做不到什么”。
Context Reset补的是模型记不住；Evaluator补的是模型没法客观评估自己；Sprint Contract补的是模型不会定义”做完”。
每一个组件都是一块补丁，贴在模型能力的缺口上。
这些补丁拼在一起，至少在Anthropic身上，表现为一个随模型能力变化而持续变形的曲面。这个曲面有一个名字：补偿面。
Harness到底是不是护城河？
Anthropic证明了模型已经开始吞掉Harness。但随着我们希望模型能做到的事越来越复杂，而这些希望基本都会超越模型的能力时，补偿面可能会存在一段时间。
但正如Anthropic自己的总结：值得尝试的Harness组合空间没有随模型进步而缩小，它在移动。补偿面在迁移，是指模型每强一分，Harness的重心就移一寸。每一次加组件，都是在补偿模型当前做不到的事；每一次去组件，都是因为模型进步让某个补偿变成了overhead。总量未必减少，但位置一直在变。
护城河不在Harness的厚度，在迁移的速度。
七、源码里的三个账外发现：Harness正在膨胀
7.1 KAIROS：从被动工具到主动助手
51万行代码里，还有一些那些工程文章从来没提过的东西。
前面三层壳解决的都是同一个问题：怎么让Agent把长程任务做好。但源码里出现的几个新系统，不是。
第一个叫KAIROS。这是一个常驻后台的守护程序。它不等你开口。系统定时拍它肩膀问”现在需要你做什么吗”，它自己决定是行动还是沉默。但它有一个硬性限制：任何会打断用户工作超过15秒的操作，一律自动延后。
过去三层壳管的全是”怎么做”——怎么记住任务、怎么分配工作、怎么验证产出。KAIROS管的是”该不该做“。Agent从接到命令才动手的执行者，变成了时刻在旁边观察、自己判断时机的助手。
15秒这个数字是一种全新的度量单位——不是代码行数，不是测试通过率，是”打断人类的成本”。
7.2 YOLO Classifier：壳在学习该怎么当壳
第二个叫YOLO Classifier。名字很随意，设计很认真。
前面那些工程文章讨论权限时，基本都是二元逻辑：要么问用户，要么不问。Claude Code的实现完全不是这样。它给每个操作都打了风险标签。读文件、搜索代码这类安全操作，直接放行，不打扰用户。写文件分两种情况：在项目目录内的走快速通道，出了项目目录的要走完整审批。执行命令行脚本永远走完整审批，因为一条命令理论上能干任何事，风险没有上限。
分类器对每次操作给出三种判定：放行、软拒绝（再确认一下）、硬拒绝（绝对不行）。更有意思的是它会学——你连续拒绝某类操作几次之后，系统自动记住，以后这类操作直接阻断，不再来烦你。
壳的松紧不再是工程师调好的固定值。它在根据你的习惯自动调节。
壳在学习该怎么当壳。
7.3 Hooks：把封闭产品变成开放平台
第三个叫Hooks（钩子）。
想象Agent从启动到完成任务是一条流水线，源码在这条流水线的8个关键节点上埋了插槽。任何人都可以往插槽里塞自己写的检查脚本。脚本说”不行”，整条流水线就停下来。
前面那些文章里，壳是Anthropic自己设计、自己拆的。Hooks把壳变成了一个开放平台。一家企业可以在插槽里挂自己的合规检查，一个开源社区可以挂自己的代码规范。壳不再是铁板一块，是一个有8个插槽的框架。谁都可以往上加自己的约束。
7.4 壳正在从Harness向Infra蔓延
回头看这三个账外发现，它们有一个共同特征：没有一个是执行长程任务必须的。
不装KAIROS，Agent也能听命令执行。不装YOLO Classifier，大不了每次都问用户。不装Hooks，Anthropic自己的壳依然能用。
但它们对效率、自定义和商业防御是必须的。
KAIROS让Agent从被动工具变成主动助手。YOLO Classifier让壳的松紧自适应。Hooks让壳从封闭产品变成开放平台。
这些方向没有一个出现在过去十五个月的工程文章里。因为那些文章解决的是”怎么让Agent工作”，而这些新系统解决的是”怎么让Agent好用、可控、可商业化”。
前面四章讲的补偿面迁移，是壳在三层之间左右移动。但这些账外发现指向的是另一种运动：壳不是在变薄或变厚，它在往全新的维度伸展。执行长程任务只是起点。壳正在从Harness向Infra蔓延。
补偿面不只是在迁移。它在膨胀。
八、Harness的真实工程图纸：三个层次一张表
现在，我们可以把Harness Engineering的完整图纸整理出来了。
核心定义
Harness = 围绕大语言模型建立的工业级管理制度。 它的每一层壳，都对应着大语言模型的一个先天缺陷。
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
补偿面迁移定律
组件的价值不是绝对的，是相对于模型能力的。
Harness里每个方块存在的理由不是”它能做什么”，而是”模型做不到什么”。Context Reset补的是模型记不住；Evaluator补的是模型没法客观评估自己；Sprint Contract补的是模型不会定义”做完”。
每一次加组件，是在补偿模型当前做不到的事。每一次去组件，是因为模型进步让某个补偿变成了overhead。总量未必减少，但位置一直在变。
护城河在哪里
如果一家公司说”我们有最完善的Harness方案”，有最多的验证层、最复杂的Planner架构、最精密的Evaluator机制——那不是护城河，是负担。
模型每强一分，理由就少一分。架构越厚，意味着对当前模型短板的押注越重，转身就越慢。
真正有价值的不是补偿的厚度，是追踪补偿面迁移的能力——知道下一寸该加什么，上一寸该拆什么。
下次你看到一个AI产品在大张旗鼓地加功能，问自己：是在补模型当前做不到的事，还是已经在补一个模型早就能自己做的事？前者是必要成本，后者是技术债。
下次你看到一个团队在删功能、拆架构，不要读成”他们走了弯路”，读成“他们正在发现模型能做什么了”。能拆，说明之前搭得有效；拆得快，说明他们一直知道自己在补偿什么。
九、工程实践指南：Harness怎么用
9.1 从第一层开始，逐步叠加
Harness不是一步到位的。正确姿势是从第一层开始，逐层叠加，每加一层都要问自己：这个组件补偿的是模型的什么缺陷？这个缺陷在当前模型版本上还存在吗？
加得太快，你会积累大量技术债；加得太慢，你会浪费算力和时间。
9.2 始终保持”拆”的能力
比”知道该加什么”更重要的，是知道什么时候该拆。
Anthropic的经验是：每次新模型发布，先用老Harness跑一遍，再拆掉一个组件跑一遍，看数据说话。所有高级功能都应该用feature flag门控，像一排总闸，每个闸管一个功能。没启用的功能在构建时直接被移除，不会留在最终产品里。
不是方法论，是日常操作。
9.3 验证层的严格隔离
验证层有一个致命漏洞：Agent有机会篡改考场本身。
必须把测试环境锁定为最高级别的只读状态。Agent只能在答题卡上写字，绝对碰不到试卷和评分标准。这不是可选的优化，是必须有的物理隔离。没有这个隔离，Evaluator再严格也会被Agent找到漏洞。
9.4 并发不是万能药
多Agent并发解决的是”单Agent干不了大活”的问题。但并发本身带来了新的问题：锁竞争、无政府状态、调试复杂度指数级上升。
在你确定需要并发之前，先把单Agent的效率做到极致。Cursor的教训是：20个Agent同时工作，有效吞吐量可能下降到仅相当于两三个Agent在跑。在扁平结构下，多Agent反而可能降低效率。
十、十五个月的血泪经验，浓缩成五条
第一条：记事本是起点，不是终点。 早期Context Engineering解决的问题是”模型记不住”，但模型的毛病远不止记不住——不翻、翻了不照做、做完了还瞎标。管理制度才是答案。
第二条：三层壳对应三个缺陷。 第一层管不听话，第二层管群体操作，第三层管盲目自信。每一层都是补丁，贴在模型能力的缺口上。补丁会过期，要持续追踪补偿面的迁移。
第三条：护城河在迁移速度，不在壳的厚度。 能拆说明之前搭得有效，拆得快说明一直知道自己在补偿什么。那些声称有”最完善Harness方案”的公司，不是护城河，是负担。
第四条：验证层的物理隔离是生死线。 Agent面对地狱级难度的考试，第一反应是干掉阅卷老师。Evaluator再严格，只要Agent能碰到测试环境，就一定能把断言改成永远通过。
第五条：壳正在膨胀，从Harness向Infra蔓延。 KAIROS、YOLO Classifier、Hooks这些新系统，解决的不是”怎么让Agent工作”，而是”怎么让Agent好用、可控、可商业化”。执行长程任务只是起点。
通往简单的路，必须经过复杂。
但”知道自己在经过复杂”和”以为复杂就是终点”，差距就在这里。
本文参考了Anthropic、OpenAI、Cursor、LangChain四家在过去十五个月里发布的所有核心工程论文，以及2026年3月Claude Code源码泄漏事件中的产品实现细节。
YouMind
