当 Harness 变薄，人类还剩下什么？

半年前，我还很愿意给一个 Coding Agent 配齐所有东西：长长的 AGENTS.md，一套一套的 Skill，精心打磨的 Prompt，还有固定的工作流。每一步该做什么、调用哪个工具、以什么格式汇报，最好都提前写清楚。那时我把 Harness 理解成一套精装修，水电、家具、灯光和收纳都做好，模型拎包入住，就可以开始工作。

最近几周，我开始怀疑这套装修是不是做得太满了。GPT-6 Astra 发布后，我在实际使用中第一次明显感到，模型会被一部分“帮助”拖累。过去为了弥补模型能力而写下的指导，现在可能占用上下文、制造冲突，甚至把本来能自行完成任务的模型带向错误方向。OpenAI 随后也公开提醒开发者重新审视积累下来的 Skills、AGENTS.md 和任务 Prompt：更强的模型已经不需要那么多手把手的指导；Skill 描述太多、太长或互相矛盾，反而会让模型更难选对 Skill。¹

Anthropic 也观察到了类似的变化。旧 Harness 为了解决 Claude Sonnet 4.5 在接近上下文上限时提前收尾的“上下文焦虑”，加入了 context reset。换成更强的 Claude Opus 4.5 后，提前收尾的行为已经消失，同样的 reset 反而成了多余的负担。⁴

这些变化让我开始重新理解 Harness。过去我们不断给模型补上它缺少的东西，如今，一部分补丁已经到了该拆的时候。Harness 正在变薄，而我也开始想到另一个更难回答的问题：如果模型已经能完成许多人自己都完成不了的工作，人该把自己放在什么位置？

Harness 这个词已经变了

过去谈 Harness，容易想到测试 Harness：把一个不稳定的东西放进受控环境，重复运行、观察和校验，尽可能避免它出错。后来 Agent 开始处理长任务，这个词的含义逐渐扩展，指向支撑模型持续工作的整套工程层，包括上下文管理、工具调用、执行循环、记忆、权限、验证、恢复和反馈。

我们也开始比较“模型加 Harness”的整体表现。同一个模型放进不同的 Coding Agent，结果可能完全不同。Claude Code、Codex 各自决定了模型能看见什么、能调用什么工具，失败后如何继续，什么时候向人提问，以及怎样证明自己完成了任务。只看里面装的是哪个模型，已经不足以理解它们的差别。

这个阶段的 Harness 很厚，有它的原因。模型不会做的事情太多，我们只好把人脑中的流程拆出来，一层层补到外面：要求它先规划再实现，读完指定文件再调用工具，遇到某类错误走固定分支，完成后按清单自查。我们试图靠这些外置流程，让一个容易犯错的模型更长久、更可靠地工作。

模型的能力却一直在变。半年前合理的假设，今天可能已经过期。Harness 中每一个“模型做不到，所以系统替它做”的设计，都需要随着模型升级重新检验。我现在越来越觉得，Harness 中相当一部分是在填补暂时的能力差额。模型缺什么，就在外面补什么；模型学会之后，补上去的那一层也该退出。

从精装房退回毛坯房

精装房式的 Harness 很有诱惑力。流程已经定义，步骤已经排好，最佳实践也写进了 Skill，我们自然会觉得系统更可控：只要 Agent 照做，结果就不会太差。但精装修也替住进来的人决定了太多事情。

模型能力较弱时，这种安排是在帮它。等它已经能理解代码库、判断下一步，并根据反馈调整路径，那些安排就可能开始碍事。一个这样的模型，仍被要求机械执行几个月前写下的十几步 SOP，就像一个经验丰富的工程师，被要求严格照着新手操作手册工作。它一边要完成任务，一边还得处理过时规则之间的冲突，解释自己为什么绕过某些步骤。

GPT-6 Astra 的发布介绍提到，面对留有解释空间的指令，它比上一代更能结合上下文补全常规空白；只有那些会改变结果的关键决定，才需要向人提问。² Harness 因而不必提前写完所有路径，很多过去必须外置的操作过程，可以重新交给模型判断。

我所说的 Thin Harness，更接近一间毛坯房。承重结构、水电和门窗都在，房间的边界也清楚，只是不替住户决定沙发必须摆在哪里。放到 Agent 系统里，我想缩减的是那些替模型思考的部分，保留甚至加强的，则是让模型接触真实世界、承担实际后果并获得反馈的部分。

从精装房退回毛坯房，依然有大量基础工作要做。如果只记住了“少写 Skill”，什么都不提供，最后又把失败归咎于模型，那也只是在偷懒。

三个月后，还需要留下的七层

我试着问自己：如果模型继续以过去半年的速度进步，三个月以后，一个合理的 Thin Harness 还应该留下什么？我能想到的仍有七层，只是它们大多不再负责教模型一步步做事。

模型仍然需要可查询、可更新的状态，知道任务从哪里开始、现在进行到哪里，哪些尝试失败过、为什么失败。一股脑塞进 Prompt 的历史记录，很难承担好这个作用。长上下文并不自动等于好上下文。Anthropic 仍把上下文视为稀缺资源，主张按需检索、压缩和结构化记录，因为更大的窗口同样会受到上下文污染和相关性下降的影响。³

模型要真正做事，还得有工具和环境。文件系统、Shell、浏览器、数据库、调试器、代码执行环境，是它接触现实的手和脚。再聪明的模型，也不会凭空知道某个私有仓库当前的内容，更不能只靠推理证明一个服务已经部署成功。这些设施的作用，不会随着模型智力提高而消失。

工具能用到什么程度，要由权限与隔离来约束。模型能读什么、写什么、访问哪张表，能否联网，哪些操作必须由人确认，都需要明确的边界。模型越强，一句“请小心”就越不足以控制风险，权限也越需要设计清楚。

执行的结果需要验证与反馈。测试、编译、基准测试、静态分析、浏览器验证，以及线上指标和人工审查，都要把模型的说法接回事实。一个 Agent 说“完成了”，并不能说明任务已经完成，还得看环境中是否出现了正确的结果。Harness 可以少教模型怎么走，但必须让它撞到真实的墙。

知识与检索要留给模型无法从训练中获得、也不该猜测的信息。相比“React 应该怎么写”这类公共常识，我更在意公司的历史决定、私有数据、产品约束、客户承诺、业务术语，以及仍在变化的现实。这些知识也不必全部常驻上下文，应该能在需要时查到，并及时更新。

可观测性与审计，让人有机会回头看清过程：Agent 调用了什么工具，改了哪些文件，用了什么依据，在哪里失败，又为什么重试。模型能力越强、连续工作的时间越长，人越不可能靠盯着屏幕理解这一切。过程无从追查，自主执行出了问题，也就无从追责。

最后还有目标与评价。究竟要降低延迟还是降低成本，要提高留存还是提高短期转化，什么叫“完成”，什么样的副作用不可接受，都不能藏在一条模糊的 Prompt 里。模型可以自己寻找实现路径，目标是谁的目标、代价由谁承担，仍然要有人说清楚。

我希望这七层搭起来的是一个能工作的世界。模型有事实和工具可用，知道行动的边界，也能根据反馈判断自己是否正在接近目标。具体怎么走，可以让它自己决定。

Skill 不会一起消失

社区里关于 Skill 的争论，常常被分成两派：一派认为模型越强，Skill 越多越碍事；另一派认为通用模型依然缺少资深工程师的 procedural knowledge，必须把经验写成 Skill。我更愿意把这两种观点放到时间里看。如果模型能力一直在变，这个分歧很可能只是时间差。

今天仍有价值的 Code Review Skill，可能包含模型尚未稳定掌握的检查习惯。三个月后，这些习惯进入模型的默认能力，就不再值得继续占据上下文。Skill 这种文件形式可以留下，只是里面那部分认知工作，已经被模型吸收了。

另一些内容却不会随着能力提升自动补齐。模型可以学会 Review，也可以学会数据库迁移，却不会因此知道某家公司坚持兼容承诺的原因，或某张表背后的历史事故。至于增长、隐私、成本与人的尊严该如何取舍，懂得评估代码质量的模型，也不能代组织作决定。

因此，我希望未来的 Skill 少写一些通用的“怎么做”，多记下这里的事实、边界的来由和成功的标准，也讲清楚什么事绝不能发生。公共能力会被模型吸收，私有事实和价值选择却不会自动进入模型。

衡量 Harness 的厚度，也该看看它替模型承担了多少认知工作，光数 Skill 的数量和 Prompt 的行数已经不够。它需要能随着模型进步主动减去一些东西：每次模型升级，都重新验证已有假设，确认哪些部分已经不再必要，再把它们删掉。Anthropic 所说的“assumptions go stale”，对我来说是一项持续的维护工作，不能只在设计之初记住，之后就放在一边。⁴

人的位置也在被迫上移

想到这里，我很难只把 Harness 变薄看成一个系统设计问题。模型接手了原先由外部流程承担的工作，也在把人推向更高的抽象层。

过去，一个工程师通常通过多年具体工作慢慢往上走。先从写代码和修 Bug 入手，在处理故障的过程中积累经验，之后逐渐理解系统设计、业务取舍和组织协作。抽象能力很难在课堂里直接学会，它要从具体经验里长出来。做错了，返工，承担后果，一次次经历这些，最后才形成所谓判断力。

AI 正在压缩人们走完这段路的时间。资深工程师相对容易适应，因为他已经有了较高层次的抽象能力。实现工作可以交给 AI，自己继续定义问题，评估结果，处理边界。他还有经验可以依靠，也能判断 AI 做得对不对。

难的是刚入行或仍处在成长中段的人。我把他们叫作“夹心层”：下面那部分具体工作，正在快速被模型吞掉；上面要求的判断、抽象和业务理解，又需要长期经验才能形成。他们还没有通过足够多的实践走到高处，脚下的台阶却已经开始消失。

我们当然可以建议年轻工程师更早学习提问、比较、解释和反思，更早理解“为什么”，不要只学“怎么做”。我赞同这个方向，但这背后有一笔成长成本。过去，公司承担了这笔成本，年轻人在资深同事的指导下，用几年甚至十几年完成积累，企业也愿意等待一个人逐步成熟。

现在，AI 同时提高了产出速度和质量基线。管理者、客户和资本已经看见更快的交付，就很难再愿意为传统的成长节奏付费。我们一边要求新人直接拥有高级判断力，一边拿走他们形成判断力所需的练习时间。

“学会使用 AI”还回答不了这个困境。AI 替新人完成任务时，也可能替他们完成了原本用来获得能力的过程。如果没有新的训练机制，我担心他们连形成判断力的机会都不会再有。

“Agent 降临派”的危险捷径

面对这种压力，有人会走向一个看似合理的方向：既然我的价值在私有数据、SOP、Skill 和历史经验里，那就把它们全部打包交给 Agent。

我把这种倾向叫作“Agent 降临派”。他们相信，只要先把旧系统里的知识准备齐全，AI 降临那一天，组织就能完成自动化。很多身处夹心层的人正在做这件事：整理自己的工作流程，把经验结构化，连接私有数据，教 Agent 复现自己的日常任务。

这项工作有价值。没有组织知识，模型只能做通用工作。但如果一个人的全部角色，就是把自己的做法完整外包给 AI，那么交接完成的那一天，也可能就是组织不再需要这个角色的那一天。

人得继续参与目标的定义，检验结果，理解后果，并随着模型变化重新划定边界，才有机会在交接之后继续发挥作用。如果只是不断给 AI 喂数据，把它教到能够接手自己的工作，交出去的就不只是重复劳动。人也可能放弃了自己继续形成判断力的机会。我在意的是，人把 SOP 交给 AI 之后还做什么。如果答案只是维护更多 SOP，那条路会越来越窄。

当写代码不再稀缺，人开始负责删

讨论到这里，我觉得“人的抽象层级上移”虽然准确，却太温和，也太像管理学术语。说得直接一点：当人写代码已经写不过 AI，人可能开始负责删代码。

这里的“删”，包含了对一个东西是否应该存在的判断。哪个功能不值得做，哪层抽象已经过时，哪份 SOP 在妨碍新模型，哪个假设不再成立，哪段自动化因引入太多复杂度而得不偿失，都属于这个范围。再往上，还要判断什么目标值得追求，哪些代价不能接受。

AI 擅长生成，可以在很短时间里铺开许多方案，把实现和文档一并写出来。产出变得廉价之后，判断什么值得留下，就成了更稀缺的工作。

删除需要上下文。你得知道一段代码为何出现、解决过什么问题、谁依赖它，以及删掉之后，后果会落在谁身上。删除也需要承担责任。生成十个方案很容易，决定只保留一个，意味着你要为放弃另外九个承担后果。

这或许是人暂时还能站得住的位置：模型不断扩展可能性，人来决定其中哪些值得带进现实。不过，这个位置有一个前提，尤其不能对新人省略。

在学会删除之前，必须先有东西可删

不能因为“删除比创造更稀缺”，就让一个还没有创造过的人，从第一天开始负责删。

你得先借助 AI 大量生成、大量尝试，经历一轮原始积累。有些东西马上有用，有些看上去没用；有的只在某个阶段有效，有的会随着模型能力上升而过期。只有把这些东西真正用过，比较过，也验证过，才有依据判断什么应该留下。

还没有经历这轮新的创造，就急着删除，很容易删到经典时代留下的 Context、SOP 和组织经验。那些东西也许写得啰嗦，结构不够优雅，却是真实失败和实际代价换来的。它们承载的未必是 AI 时代的冗余，不能因为新模型看起来足够聪明，就在没有验证的情况下被清空。

所以，我理解的循环要从大量创造开始，经过真实使用和方案比较，在验证结果、理解反馈的过程中形成判断，最后才轮到删除。有了前面这段积累，删除才是实践之后的取舍。它不能代替创造，也不能只剩一个极简主义的姿态。

这也是夹心层需要的机会。给新人一条“什么该删”的规则很容易，难的是让他参与前面的完整过程：看 AI 生成的东西如何在真实环境里运行，比较不同方案的表现，在失败和反馈中理解取舍，再逐渐参与决定哪些保留、哪些淘汰。判断力只能从这些具体经验里长出来。

企业需要设计的培养方式，或许也得跟着变。过去可以让新人先做简单任务，如今简单任务已被 AI 接手，就得让新人进入 AI 生成物的使用、验证、对比和复盘过程。只让他按下生成按钮，不足以获得这些经验；直接要求他像资深工程师一样给出最终判断，又跳过了积累的过程。他需要亲眼看见判断是怎样形成的，也有机会练习。

如果企业连这段时间也不愿意给，那么“人应该转向评估和价值判断”，就只是一句对已经站在高处的人才成立的话。

两条线最后汇合在同一个动作上

Harness 变薄和人的位置上移，最后汇合在“删除”这个动作上。模型吸收了越来越多原本由外部流程承担的工作，过时的 Skill、SOP 和固定流程需要退出，支撑它工作的那七层仍要留下。人则从执行走向评估和取舍，要从 AI 大量生成的结果中，删掉不值得存在的东西。前一种删除让模型能在边界内自由工作，后一种删除让现实不被无限产出淹没。

这两种取舍都得经过实践的检验。没有接触真实后果的系统，无从判断哪条规则已经过时；没有经历创造、使用和验证的人，也很难作出有依据的选择。资深工程师还有过去的经验可依靠，夹心层却需要在台阶消失之前，获得完成这轮积累的机会。

我现在已经不太担心人还会不会写代码。代码当然还会写，只是越来越多由模型完成。如果未来最稀缺的是决定什么值得存在，就得有人经历过创造、失败和后果，知道自己为什么按下删除键。而这样的人，需要时间和实践才能长出来。

当组织一边享受 AI 带来的速度，一边不再愿意支付人成长的成本，我们最终会把判断权交给谁？