模型越来越强后，Harness 是越来越重，还是越来越轻？OpenAI 和 Anthropic 两家顶尖模型公司的工程师给出了截然相反的结论。
“随着模型进步，系统里的开发者消息会越来越短，Codex 的 Harness 本身也会越来越轻。”这是 OpenAI Codex 团队的 Tibo 在最近的播客中给出的判断。这可能也是相对普遍的观点。
但是，Anthropic Claude Code 团队工程师 Thariq Shihipar 却在另一档节目中表示：“模型越强，Harness 反而需要越来越复杂，因为你要让模型能够做更多事情。”
Tibo 给出了自己的解释。
他明确表示，Codex 的 Harness “通常会比模型领先一点”。在模型已经具备某种潜在能力、但还无法稳定发挥时，Harness 会先通过额外指令和控制机制给模型加上“拐杖”，让它能够更可靠、更高效，也更符合用户预期地完成任务。但随着模型能力提升，新模型会更准确地理解用户真正想要什么，也会主动反思任务是否已经完整完成，因此过去依赖开发者消息强制约束的行为，可以逐渐由模型自己学会。
在实际运行中，Codex 的最终表现并不能简单归因于模型或者 Harness 中的某一方。Tibo 透露，当团队希望加入一个新的产品能力时，首先要判断的是这个问题应该由 Harness 解决，还是应该由模型本身解决。
如果模型合适，团队会进一步评估模型侧最快什么时候能够解决；如果某个问题预计很快就可以在模型层被修复，团队甚至可能选择完全不在 Harness 中增加临时补丁，而是直接等待下一版模型。
这意味着，Codex 的工程团队并不会把所有已知问题都固化成外部规则。相反，一部分 Harness 逻辑从一开始就是临时性的，当模型能力追上来之后，相应的规则和提示就会被删除。
而 Thariq 则认为，由于 Agent 开始承担更长时间、更高自主度的任务，模型越强，Harness 反而需要更复杂。
他以自动模式为例解释，过去 Claude 一轮任务只运行几分钟，遇到权限确认时用户手动操作即可；现在 Claude 可以连续工作数小时，系统就必须通过分类器、沙箱等机制，让它在长期运行中保持安全并遵循指令。
同时，Agent 工作时间变长后，“怎么让人看懂它做了什么”也成为新的问题。Thariq 举例，如果 Claude 已经连续工作 8 小时，用户不可能逐步回看全部过程，因此 Anthropic 会借助 Artifacts 来呈现结果和工作进展。
Thariq 认为，Harness 工程正变成一门“科学和艺术的混合体”。Auto Mode、Workflow、Sandbox 等原本像辅助能力的组件，正在成为整个 Agent 系统的“承重结构”。
一定程度上，这两种结论并不真正矛盾，两人都描述了 Agent Harness 正在发生的一次结构性变化：模型越强，负责“教模型怎么做事”的 Harness 会变轻，但负责“让模型安全、长期、并行地做更多事”的 Harness 会变重。
我们整理了 Thariq 在 Ryan Peterman 节目中的对话，其中他详细解释了自己的观点。此外，Thariq 还分享了 Anthropic 工程团队当下究竟如何把模型能力发挥到极致。下面是两人的对话，以飨读者。
太长不看版：
Q：模型越来越强，Harness 会不会越来越不重要？
A：实际情况几乎相反。模型越强，Harness 反而需要越来越复杂，因为你要让模型能够做更多事情。现在 Claude 可以连续运行数小时，你就必须让它长时间安全工作、遵守指令。自动模式、沙箱、工作流这些东西，本身都是很复杂的软件，但正在变成整个系统的承重结构。
Q：Prompting 以后还值得专门学吗？
A：还是非常有价值的。Prompting 不只是你最后输入的那一句 Prompt。有时大家看到我们的 Prompt 很短，是因为我们已经在 Harness、验证和 Skills 上花了很多时间。不同模型确实有不同怪癖，但你真正积累下来的能力，是学会怎样适应一个新模型。
Q：对模型说“相信自己”有效？
A：我觉得真正起作用的不是“我相信你”这几个字，而是在告诉模型：这个问题值得使用更多算力，我允许你这么做。我现在会直接说：“这是一个很难的问题，如果需要就使用子 Agent，可以用工作流。”模型默认会尽快回应、尽快开始工作，不会主动无限消耗计算，所以有时候你需要明确给它这种许可。
Q：Claude Code 的系统提示词删掉了约 80%，怎么证明变好了？
A：我们发现以前必须放进工具描述里的很多示例，现在反而会产生负作用。过去你得告诉模型“这是正确工具”“这里应该这样写文件”，还要给好例子和坏例子。现在 Claude 已经更有想象力，也更能理解你的意图，所以除非真的看到它持续做错，否则很多示例可以删掉。
Q：怎样让模型做出真正“有品位”的结果？
A：人类得在闭环里，而且要给它参考。HTML 比截图更好，Figma 比栅格图更好，因为模型可以直接读里面的结构。如果你自己都不知道什么叫好，那第一步不是让 Claude 设计，而是先让自己变得更有设计品位。越来越重要的是成为一个“高品位用户”，真正知道什么结果值得要、什么时候还应该继续往前推。
Q：AI 已经能写大量代码，大 PR 该怎么 Review？
A：如果我要发一个 PR，我通常会同时附一个 Artifact，把我发给 Claude 的所有 Prompt 都列出来，包括失败的尝试。如果就是 One-shot，我也会直接说：“这是一次 One-shot，这是我用的 Prompt。”我最想避免的是突然扔给别人一个 1 万行 PR，对方完全不知道我到底看过多少、我和 Claude 到底怎么一起做的。
Q：测试代码是不是应该更多？
A：我甚至觉得，你今天应该拥有比过去多大约 100 倍的测试代码。几乎所有东西都应该有 Fixtures，可以从生产数据生成数据库 Mock，前端可以准备 Storybook，还可以建立很多不同的测试和验证方式。对我来说，这些验证能力才真正提高了可维护性。
Q：技术债是不是可以等下一代模型再还？
A：我觉得这个想法并不完全错。关键还是问：“这次重构现在能不能帮我更快交付客户价值？”我现在更倾向于用短时间尺度看项目，比如未来 1 到 2 个月怎样交付价值。如果一个项目 6 个月、12 个月以后才产生价值，也许确实可以稍微等等下一代模型。
Q：AI 写代码越来越快，会不会导致事故更多？
A：这确实可能是“跑得更快”的副作用，我们也还在解决。我不觉得 Anthropic 现在的 uptime 已经到了理想水平。但你也可以用 Claude 去改善 uptime。AI 不只是让你写更多代码，也让过去负担不起的验证和故障演练变得可以大规模执行。
Q：Anthropic 内部的算力优势是不是普通用户无法复制？
A：我觉得这个差异被夸大了。周末我也用自己的订阅，几乎从来没有撞到过 5 小时限制。我们内部大量消耗算力时，很多时候是在探索模型到底还能做什么，而不是为了完成更多日常工作。普通用户也可以复制很多做法，关键是把抽象层级提高，而不是一开始就盯着某个中间层的小任务反复改。
Q：Claude 已经能做过去很多实习生的实现工作，那实习生现在做什么？
A：现在出现了大量以前从来没人做过的新类型工作，比如怎样评测新的 Coding Agent 行为，怎样衡量 Claude 在数百万用户、各种不同任务里的表现。现在做实习生，我觉得最有意思的不是“去写那段 React 代码”，而是去找那些以前没人做过的问题，然后把它解决。
新人入职 Anthropic 需要注意什么
主持人：我这次最想问的是，在软件工程场景里，怎样才能尽可能发挥这些模型的能力，让行业里其他人也能从 Anthropic 已经验证有效的实践中学到东西。我们先从入职说起。假设我来自一家没那么“AI 原生”的公司，现在加入你的团队，你觉得最重要的几件事是什么？
Thariq：我们给 Anthropic 内外部的人最重要的一条建议都是：把 Claude 当成一个“思考伙伴”，并把它需要的上下文给足，这样通常你们就能一起找到下一步该做什么。一个很重要的出发点是先问：“Claude 能不能做？如果不能，为什么不能？”然后顺着这个思路继续往下走。
另一个习惯是不断问自己，能不能把抽象层级再提高一点。你能不能先搭一个系统？能不能去构建“那个构建系统的系统”，而不是只完成眼前这个产品本身？
主持人：以前新人入职时，通常会分配一个“入职搭档”，对方很熟悉代码库，你可以问他各种很琐碎的环境配置问题。听起来 Claude 已经补上了其中很多空白。那是不是已经到了完全不需要入职搭档、技术问题全问模型的程度？
Thariq：入职搭档还是需要的，但更多是社会关系和文化层面的需要，而不是技术层面的。
纯技术问题基本可以直接和 Claude 协作，如果你比较会用它，入职所需的技术信息都能拿到。但你仍然需要知道怎么和团队协作，怎么为自己做的东西争取认同，团队内部怎么配合，甚至只是有一个能一起工作的朋友，这些都很重要。所以，我们还是会给新人配入职搭档，只不过现在它承担的技术支持工作，远没有以前那么多了。
主持人：我感觉外界对 AI 能力的认知，和 Anthropic 内部真正的使用方式差别很大。我和朋友聊天时会说：“对，Boris 说的那些其实就是现实。”为什么内部认知和外部认知之间会有这么大的落差？
Thariq：我觉得我们过去在这类事上的判断还不错。很多话刚说出来时，人们会觉得太夸张，但过很久往往真的会发生。
现在很多工程师其实已经不怎么用 IDE 了。我和一些大型企业客户聊过，有人已经 6 个月没有亲手敲过一行代码。对我们来说，工作的一部分就是不断把自己提升到更高的抽象层级。如果我花一整天研究“怎样让 Claude 自主完成这件事”，最后失败了，对我来说也没关系，甚至可能是好事，因为我就知道 Claude 这里做得还不够好，接下来可以思考怎么把它变好。
但普通岗位不一样。你的工作目标通常是产出结果。自动化总有成本，其本质上是一种投资：如果自动化成功，长期会得到回报；如果失败，那之前投入的时间就浪费了。好的一点是，随着模型越来越聪明，这种投资最终成功的概率一直在提高。但作为个人，你还是得先迈出那一步。要是你整天都在调 Harness，却一直没有交付代码，你的老板大概率不会特别高兴。
所以，很大一部分其实是文化问题。我们把“活在未来”当作自己的工作，然后尽量把这些实践做进产品和 Harness 里，让其他用户不需要手工完成那么多步骤。
主持人：有没有哪些事，你觉得在 Anthropic 内部已经产生很大影响，但外面尤其是 Twitter 上还没多少人在做？
Thariq：用 Claude Code 做知识工作非常有价值。我觉得现在技术人员做知识工作的方式，已经和非技术人员很不一样了，因为技术人员可以把很多任务交给模型执行。
很多时候，你可以把一个任务拆成类似代码的步骤，然后思考该怎样把这些步骤告诉模型。只要这样做，能完成的事情会多很多。比如，我个人会用 Claude Code 做不少财务处理，我会写 Python 脚本，而不是用 Excel；做视频编辑时，我会用 FFmpeg 和一些程序库来渲染视觉内容。
仔细想，很多知识工作其实都可以归约成代码，再让 Coding Agent 去执行代码。我觉得这是技术人员和其他人目前一个很明显的差别，而外面很多人还没有充分利用这一点。
模型越强，Harness 反而要越复杂
主持人：很多人用 Claude Code 做目标明确、标准客观的工作时，结果都很好。但如果让模型做“漂亮”“有品位”这种更主观的东西，比如前端设计，结果就会更不稳定。你怎样把一种非常具体的风格或审美传递给模型？
Thariq：Harness 非常重要。常见的一种想法是：模型会越来越好，等到模型什么都能完美完成的时候，Harness 就不重要了，那为什么还需要 Harness？但我们实际看到的情况几乎相反：模型越强，Harness 反而需要越来越复杂，因为你要让模型能够做更多事情。
自动模式（auto mode）就是一个例子。它会在那些原本需要 Claude 向用户弹出权限确认的任务上，通过分类器来判断后续行为。以前在 Opus 4、甚至 Opus 4.5 阶段，一轮任务通常只跑几分钟，碰到权限提示时手动按一下回车并不算什么。但现在 Claude 可以连续运行数小时，你就必须让它在很长时间里既能安全工作，又能遵守你的指令。自动模式本身就是非常复杂的软件，沙箱同样也是很复杂的软件。
另外，Claude 现在能连续做非常多的工作。假设它已经工作了 8 个小时，你怎么知道这 8 个小时里究竟完成了什么？所以我们会用 Artifacts。Artifacts 本身其实也是一种提示方式，因为你必须决定 Claude 怎样呈现这些工作，才能让人真正有用地理解。同一批信息可以有很多完全不同的表达方式。
因此，Harness 工程其实是一门科学和艺术的混合体，很多地方非常反直觉。但它能解锁模型很多新的行为能力。我的观察是，Harness 正在变得越来越复杂，想自己“凭感觉”做一个 Harness 也越来越难，这一点反而和“模型越来越强”形成了很有意思的反差。像自动模式、工作流这些东西，本身都是很复杂的软件，却正在成为整个系统中不可缺少的承重结构。
3Anthropic 有多少改动已经完全自动化
主持人：随着大模型越来越强，人类能从执行链路里退出的环节也越来越多。在 Anthropic，你或者你们团队现在有多少改动是完全自主完成的？还有多少仍像一年前那样，靠人和模型结对完成？
Thariq：这取决于你怎么定义“自主完成”，也取决于具体团队和职能。比如设计师先做了一份 Figma 文件，工程师再把它交给 Claude Code。Claude Code 很擅长调用 Figma MCP，但设计师显然已经在前面做了大量工作。所以这算不算 Claude 自主完成，其实很难简单划线。
我们的目标大致是，让 Claude 尽可能承担那些连接不同环节的“胶水工作”。既然已经有一份 Figma 设计，还需要人再手工把它翻译成 React 吗？大概率不需要，那部分工作其实已经做过一遍了。
我更愿意问的是：我每天真正需要亲自做的、真正有独特性的工作是什么？这种独特工作，我做得越多越好。现在对独特思考和独特判断的需求非常大。反过来，只要我发现自己在做一件以前做过的事，我就会问：“Claude 能不能做？”如果我只是把别人已经做过的东西翻译成另一种形式，我也会问：“这能不能交给 Claude？”
主持人：这也让“自主完成”的边界越来越模糊。哪怕一个 PR 里的代码全部由 Claude 生成，你在过程中也可能做了很多决策、补了很多上下文。那离这样一种世界还有多远：有人直接说“Claude，这是任务单，做完之前别来找我”？
Thariq：取决于任务单写得多好。如果有人已经把它写成一份非常完整的软件 spec，那 Claude 现在其实很可能就能直接完成。
但现实里，一个 GitHub Issue 往往没这么清楚。你首先得判断它值不值得修、是不是一个功能需求。很多 Issue 其实混杂着多个问题，也许该重新组合成完全不同的方案。真正难的工作常常是：产品愿景是什么？我们到底想往哪走？怎么保证做出来的东西在整体上是连贯的？
所以，对于足够具体的 spec，Claude 可以执行。问题是，现实里人们往往自己都没想清楚到底想要什么，也没想清楚未知因素是什么、问题到底是什么。以前你可能一边写代码一边发现：“等等，我下一步到底该做什么？”然后在实现过程中把问题想明白。现在，我们需要新方法去发现那些“自己还不知道自己不知道”的东西。当然，你仍然可以直接和 Claude 讨论，但这才是真正困难的部分。
一种很典型的失败做法，就是直接在 Claude Tag 里 @Claude，只说一句“帮我做这个”，描述可能还不到一句话，没有之前的上下文，也没有记忆。然后 Claude 做完，你一看：“不对，我不喜欢。”接下来就陷入无穷无尽的迭代。更好的做法，是尽快先弄清楚自己真正想要什么。
主持人：我以前在 Meta 工作时，一个任务的模糊程度，某种程度上和工程师级别相关。当然，级别不是软件工程的一切，但大体上，高级工程师会把模糊的业务需求变成具体问题，职业早期的人更多负责实现。实习生项目甚至经常细化到接近逐行说明。如果我还在 Meta，手下有个实习生，我可能直接把原本给实习生的规格交给 Claude，它基本就能完成。
那在 Anthropic，如果 Claude 已经能做这些，实习生现在做什么？
Thariq：实际上，现在出现了大量以前从来没人做过的新工作，所有人都得一起摸索。比如，面对这些新的 Coding Agent 行为，到底该怎么做评测？Claude 服务着数以百万计的用户，他们在做各种不同的任务，有些任务之间甚至存在取舍，该怎么衡量它在这些场景里的表现？
尤其在研究侧，还有非常多新工作。现在越来越难写出那种完整明确的 spec，但与此同时，过去经验的相关性也越来越低。经验当然仍然有价值，因为你知道怎么把事情做完，也知道怎么学习，但这些能力其实刚毕业的人也可能具备。
所以现在做实习生，我觉得最有意思的不是“去写那段 React 代码”，而是去找那些以前没人做过的问题，然后把它解决。新问题太多了，需要有人去解决，而拥有一双“新鲜的眼睛”反而很有价值。和过去更像流水线式的培养路径相比，现在实习生必须更主动，也更需要抓住机会。
主持人：我们刚才聊了知识工作，这让我想到计算机使用（computer use）和浏览器使用（browser use）。它们距离真正大规模进入行业、产生明显影响还有多远？Anthropic 内部现在怎么用？你们通常会比外界早一些。
Thariq：这两块，模型确实已经进步很多。我觉得 Opus 5 已经是一个非常好的计算机使用模型，但仍然有一些很奇怪的边缘情况。比如，它没法替我输入密码，因为密码在 1Password 里，它访问不到，于是任务就卡在那里。这类问题更多是用户体验层面的。
另一方面，越来越多人正在把 API 和 MCP 变成 Claude 的新入口。这样一来，原本必须靠“操作电脑”完成的很多事情，其实可以绕过图形界面。回到刚才“知识工作的一切都可以变成代码”这个思路，确实还有一些事情没有 API，也没法直接用代码执行，只能打开浏览器点来点去。但这种情况正在减少。Claude Tag 就是很好的例子，我们一直在尽量把各种能力封装成它可以直接调用的 API。于是，即使 Claude 并没有真的启动一台虚拟电脑、移动鼠标点击，它仍然能替你完成大量工作。
主持人：我用任何 computer use 工具时，都有一个很明显的感受：太慢了。光标可能在那儿停 10 秒，移动一下，又停 10 秒。这个延迟到底来自哪里？
Thariq：很难做出一个既小又特别擅长计算机使用的模型，因为这个任务需要掌握非常多知识，还要理解很多东西之间怎么配合。所以你需要一个足够聪明的模型，而聪明的模型通常就需要更多时间。很多人原本以为我们会更早解决这个问题，但事实证明它比想象中更难。
以前有人给过我一个很好的说法：计算机其实是一台你无法完全控制状态的状态机。比如你在 DoorDash 上往购物车里加东西，结果加错了。为了撤销，你又得进入新的操作流程，去点按钮、删除，而且这个撤销过程本身也可能再出错。代码就不一样，你基本能控制全部状态，可以撤销，可以回退。计算机使用里，每一个动作即使不是不