一个多月前，Claude Code 因拒绝兼容已被大量项目和 Coding Agent 采用的行业标准 AGENTS.md， 遭到 Shopify CEO Tobi Lütke 的公开“封杀”警告 。 Anthropic 当时坚持，不同模型需要不同的上下文和指令，开发者却质疑，这等于逼着团队为每个模型维护一套配置。
如今，Claude Code 团队终于确认将支持 AGENTS.md，但 Thariq Shihipar 给出的下一步更加激进：随着模型越来越强，CLAUDE.md 乃至这类静态指令文件最终可能都不再需要。当所有人还在研究怎样写好 CLAUDE.md 时，他甚至建议，新项目可以先不写。
从 Claude Code 的爆发式普及，到 Agent 改写自己的 Harness、跨团队协作，并同时运行在云端和本地，软件构建方式正在急速变化。日前，Anthropic Claude Code 团队核心成员 Thariq Shihipar 做客 Latent Space 播客，与主持人 swyx 和 Vibhu 从 Claude Code 不断演进的交互界面聊起，谈到 Artifacts、Claude Tag、Claude Mods，以及能够修改自身 Harness 的 Agent，随后将话题延伸至 Agent 安全和 Anthropic 提出的“Pacing the Frontier”。
本文基于该期播客视频整理，经 InfoQ 编辑。太长不看版 Q：怎么少浪费 agent 的工作？
A： 多在第一个提示词上花时间。 Effort 要按任务分：代码审查和安全用 high 甚至 max，UI 这类 low/medium 就够。
还有一个技巧：让它写实现笔记，因为大多数失败是模型想到了正确答案却决定不做。最终，前沿模型会在智能和 token 效率上同时占优。
Q：CLAUDE.md 到底还要不要写？ A： 模型越来越强，完成简单任务的基线一直在涨，很多以前要写进 CLAUDE.md 的东西现在模型自己就能搞定。
正确做法是：先让它跑，只有反复看到同一个失败模式，再把规则加进去。维护一份不断增长的失败清单，很可能反而“过度约束”Claude。
Q：提示词还重要吗？ A： 重要，而且门槛很高。
信息量比文本格式更重要：你对着功能键瞎扯两分钟，只要信息够多，就比精心排版但内容稀薄的提示词更好。 Q：Claude Mods 是什么？
能干嘛？ A： 定制整个 Claude Code harness，执行逻辑和 UI 都能改。
比如俄罗斯方块直接显示在终端里；比如每次对话结束自动 fork 一个 sub agent 考你“这个任务真的完成了吗”。因为 fork 会保留 prompt cache，成本非常低。
它是“可变软件”的预览，让生成式软件可以被安全地定制。 Q：Claude Code 的界面和协作往哪走？
A： artifacts 会成为你进入整个 harness 的界面，是一种“持久生成式界面”。多人方面，Claude Tag 就是“组织级 harness”，很适合 on-call、事故处理这类天然多人的事，Projects 是在 Claude 产品上拿到同样好处的方式。
Q：OpenAI 那个没发布的模型到底干了什么？ A： 在 ExploitBench 上，agent 解不出题，就在 Artifactory 里建文件夹互相留言、协作，然后串联漏洞：编辑 `/etc/hosts` 把假 Azure host 指向任意 IP，从而对任何网站发 POST 请求，最后黑进 Hugging Face 逆向工程 scorer 的代码，不是找答案，是黑掉评分器本身。
Q：这么危险，Anthropic 怎么防？ A： 数字基础设施的任何部分都可能被攻破：模型为了拿到更多任务算力，可能黑进数据库、造成停电；更麻烦的是它们会试图隐藏行为，只有思维链能监控到。
防线是多层的：Probes 在意图层面看内部激活（也能拦越狱），auto mode 在权限层面检查请求是否匹配用户意图，再往外是身份和权限。 Q：Pacing the Frontier 想做什么？
你的 p(doom) 是多少？ A： 提案的第一步是宣布意图、引入外部评估者，让不是财务动机驱动的人能向公众报告实践状况；对开发者，他的建议是从第一性原理出发、知道该倡导什么。
我的 p(doom) 相当低，相信人类能像核不扩散那样协作解决难题。 Q：普通工程师现在最该做什么？
企业落地 AI，第一件事该做什么？ A： 每个工程师都在同时做两份工作，工作本身在变容易，但跟上 AI 的工作让人精疲力竭。
对企业来说，第一件事是把数据设置成对 agent 可用，这很花时间但现在就得做。但越重要的组织数据，暴露给 agent 的攻击面就越大。
Artifacts、Projects 与多人协作 Agent swyx：在 Anthropic 工作是什么感觉？ Thariq： 我加入 Anthropic 就是因为 Claude Code，我看到 Opus 4 的时候简直无法想象它有这么好。
但我当时在努力说服我那些创业的朋友用 AI 写代码，他们说“我们的工程师觉得还不够好”，我说这太离谱了。而 12 个月后，这已经是所有人默认的写代码方式了。
现在的问题变成了教大家怎么把它用出最大价值、怎么更高效。人很难跟上所有事情，发生得太快了。
而且 agentic 的东西比人的东西 scalable 得多：人类这边同时有三件急事，你怎么响应？ Vibhu：你的时间主要花在哪？
你又写技术文章，又做工程。 Thariq： ，当时我并不确定 harness 这件事上“苦涩教训”会怎么走，有时会想“Claude Code 之后是什么”。
我刚加入 Claude Code 团队时，就是在教人用、让它更好用。但随着 harness 越来越好，“你怎么用好这些 agent？
成了主要问题，这是一件技能上限非常高的事。我也做工程、做演讲。
做工程的时候，我的目标是收集用户的反馈，然后再讲“怎么用 Claude Code 做工程”，这中间是一个很好的循环。 swyx： 我觉得你加了 Ask User Question 工具，让人们又爱又恨。
Thariq： Ask User Question 是模型第一次真正擅长“elicitation（需求引出）”，这是我一直想看看模型能不能做到的涌现行为。在我看来，这更像是人机交互：想办法搞清楚 agent 怎么跟你沟通、怎么把你的需求提取出来。
Claude Code 越做越宽，麻烦在于每个人都有自己使用它的方式，想改变默认行为非常难。有人让 Claude Code 做事，有时就是想要它直接干活，也许因为他是很厉害的 prompt 写手；有时他其实不擅长写 prompt，就需要 agent 去澄清。
Ask User Question 正好沿着这条线切开：你到底有没有能力把 agent 指挥清楚，还是说 agent 需要主动从你这里挖出更多需求、真正理解你的偏好？我整体上相信，绝大多数人更偏后者：他们面对的问题里有更多模糊性，他们知道的比自己以为的要少。
难点在于这是个界面设计问题。设计一个流程时，schema 是什么、调用栈是什么，这些细节很重要，理想情况下你希望在开始实现前就想清楚，这就是所谓的“未知项”（unknowns）。
所以我认为，在 agentic coding 里，搞清楚你的未知项会永远是一项技能。哪怕模型超级聪明，它也需要知道你想要什么，而你有自己的偏好，你得把这些挖出来。
对于 agent 的交互，HTML 一直是主要做法，我们最近加了 artifacts。 artifacts 自带数据库，能存储和写入持久化数据，还能把信息反馈回 Claude。
有一件我一直在推动的事，就是“dashboard artifact”：让 Claude 长期做一个项目，也许是个看板，把数据存进数据库，多个 Claude 通过 artifact MCP 访问，这个 artifact 也能反过来跟那些 Claude 对话。我们本质上是在搭建一些原语，让你通过 artifacts 拥有这种生成式界面。
现在 agent 的几乎所有问题，都是“你以为你知道自己想要什么，但其实你并不知道”。 artifacts 就是我们试图往这个方向演进的路径，但它比一道多选题复杂太多了，其实是更“AGI 派”的做 Ask User Question 的方式。
swyx：哪些反馈应该通过 artifact 进来，哪些应该走 Claude 聊天？ Thariq： 在极限情况下，我们设想的是 artifacts 会成为你进入整个 harness 的界面。
你可以像评论一份实时文档一样评论你的工作计划，也许还能看到多个 agent 在做不同的事。为你的 harness 提供一个实时界面，大概就是事情发展的方向。
Vibhu：那会不会有一个版本，是从 CLI 或聊天中抽象出来的？现在很多情况是你和 Claude Code 交互，返回 HTML 给你做一个丰富的 mockup，artifacts 是把这些连接在一起的方式。
为什么不干脆全部那样做呢？ Thariq： 那样一来就变成了把东西拆分开，这有点像本地和云之间的区别。
现在你用 Claude Code，它是本地的，你可以启动 remote control，或者在云里启动 Claude Code。我们正在走向一个地方：不再是你给本地的 Claude 发消息、它在本地启动 session 并执行；而更像是你有一个在云里运行的 Claude，你给它发消息，它可以运行本地 session，也可以运行云 session。
Claude Tag 大概就是这样工作的，我们还会加上本地 hands，也就是那个 agent 能访问你的电脑、在那里工作。它可以启动很多子 agent，这些子 agent 之间可以互相通信。
而 artifact 就是用来展示所有这些工作的。把 surface UI、推理智能、hands 拆开，这就是把 Claude Code 体验解包，现在这一切都发生在一个地方。
Vibhu：那你怎么看多人协作那一面？ Thariq： 我们在推出 Projects。
Projects 是一种抽象，有点像 Claude Tag，但是在我们的 Claude 产品上。我们认为 Claude Tag 更原生地支持多人，因为它就在你的 Slack 里，权限都已经搞定了。
多人协作确实是故事的重要部分，你可以想象它变得多复杂：别人的电脑上也有 hands，你需要给它们权限；你有你的 MCP，别人有别人的 MCP。比如 Google Docs，它怎么访问？
通过共享的 Claude MCP，或者通过你本地的凭证。 Claude Tag 对于 on-call、事故处理这类本身就是多人协作的事情非常有用。
当我在做某件事，需要隐私或安全，或者想让别人 review 的时候，我会为每个项目开一个 channel。比如和法务，我就说“嘿，我想发布这个，Claude 知道一切，你直接和它聊。
这样法务能得到精确的答案，而我不需要在中间传话。多人协作正在变得越来越普遍，每个人都能和 Claude 一起参与。
swyx： 这里有个关于身份和隔离单元的问题。 Claude Projects 听起来，如果它像 ChatGPT Projects 的话，隔离单元就是那个 artifact、那个 Claude 实例，大家都在上面协作。
听起来如果你和法务在协作，那个 channel 应该就是一个 project。但有个不清楚的地方是什么时候会发生转移：比如你有个同事被 tag 在所有这些东西上，那是有转移的，因为是同一个人；但用 Claude 就不清楚，它是不是必然知道那些东西。
Thariq： 这就像冰山 meme 一样。我们花了大量时间在这上面，权限、可见性，怎么让 Claude 尽可能好又尽可能安全地运作？
有太多边缘情况：这个 channel 里的 Claude 有不同的权限，但它能给另一个 channel 发消息，它能不能通过那种方式泄露数据？如果它用你的 MCP 然后给别人发消息呢？
我们真的投入了很多工作去打磨。高级用户怎么用 Claude Code？
Vibhu：从你在 Anthropic 内部和外部看到的高级用户身上，有没有什么共同的模式？ Thariq： 我觉得 Meta Skill 是写提示词。
很多人会觉得“提示词不重要，我随便说一句 Claude 就能做”。但我认为提示词就像公开演讲或者写作：你要面向一个特定的受众，而这个受众就是 Claude。
你需要建立对 Claude 的心智模型，理解它怎么思考、怎么工作。和 Claude Code 协作最重要的技能，就是这个心智模型：知道它擅长什么、能一次性搞定什么、搞不定什么。
你去看很多人的提示词，它们很短，但他们脑子里对 Claude、对代码库有极好的模型，所以用起来毫不费力，但这其实是一个高技能上限的事情。接下来是“未知”：你要能发现自己不知道什么、没写下来什么。
随着 Claude 能做的事越来越多，你遇到“对你来说是分布外、而你领域知识又很低”的任务的概率会非常高。而最重要的未知，是“未知的未知”，你根本不知道这东西存在。
我很喜欢“地图与疆域（Map & Territory）”这个比喻。你的提示词是地图，疆域是 agent 实际要做的工作。
如果你非常精确，就能给出更精确的指令。比如在设计上，我不是设计师，所以我会说“给我八个不同的 mockup”；但如果我是设计师，我可能会说“这是参考网站，我要这种字体、这种感觉，这几个组件要可视化，这是 Figma MCP 面板可以拉进来”。
你能用那套语言表达得多精确，取决于你懂多少。游戏设计是另一个好例子，很多人说“我现在能 vibe coding 一个游戏了”，然后发现“不好玩”。
因为实际上，每一个选择都有大量变体和手艺在里面，做一个飞行游戏，飞机的手感、它对操控的响应，游戏设计师可能要在上面花好几天。 swyx： 这就是“品味”：从一千个数学上都成立的答案里，挑出人类会喜欢的那个。
Thariq： 但“品味”这个词我很纠结，它听起来有点精英主义，好像“有些人有品味，这些人没有”。工程师对他们面对的特定问题有大量品味，每个人都有对特定问题的品味。
我很喜欢 Jason Lou 那句：“要有品味，你得先吃。你得做很多事、反复迭代、搞清楚自己喜欢什么，建立那套领域词汇，然后写提示词时把这一切综合起来。
Vibhu： 有时候就是直觉。你直到模型给出结果，才意识到自己想要什么。
swyx： 我有一半时间用语音提示词：对着功能键瞎扯两分钟，松开，然后希望它能搞懂。通常它确实能，但这不如那种像 PRD 或备忘录一样结构化的提示词深思熟虑。
基本是双模态提示：有些提示词你前期花很多时间，有些就随手一甩。 Thariq： 我不觉得语音一定低效。
关键不是文本格式，而是提示词里有多少信息。模型能处理你在提示词中途改主意，对很多人来说，说比打字容易得多。
如果说话能让你输出更多信息，那就更好。 Vibhu： 某种程度上，感觉在启动前给模型尽可能多的上下文就是最佳实践。
我最初试 Fable 时，会花整整 30 分钟精心打磨一个长提示词。我觉得这是对模型运行时间越来越长的回应：当它们进入循环后，你还是很难去推动它们。
但直觉上，我会在第一个提示词上花更多时间，然后和它一起大量协作。 Thariq： 如果我是个软件工程师、在跑自己的创业公司，我想我大部分时候会停在 max 20X 这个档。
我看到很多人 hit rate limit，往往是因为一开始没花够时间、没给够上下文，结果就是“这个我不喜欢，撤销重做”、“你搞砸了，重来”，在一个模型本可以一次做好的东西上来回折腾，这反而吃掉你多得多的用量。所以除了“目标上下文”，还要给模型一个“花多少算力”的许可：你是在做原型还是做生产？
哪里可以烧算力、哪里不可以？模型没法凭直觉知道你愿意在这个任务上花多少，这时候就要用 effort 来告诉它。
那篇博客里我会讲：effort 基本是和任务复杂度挂钩的。安全场景下 high 对比 low 能明显改变 eval 结果；但软件工程里差别不大，因为 effort 大部分花在验证和边界情况测试上。
现在还不完全成立，但已经非常接近了：前沿模型会在几乎所有事情上 pareto 占优。因为有了验证，极限情况下模型根本不需要验证。
如果模型足够完美，它做一遍就完事了。我现在用 Fable 经常想说：“你不用把 Chromium 跑起来、把每个页面都截一遍图，我知道你做对了。
effort 越高，花在验证上的 token 就越多；但做简单任务时，Fable 在 low/medium 下可以少花很多验证 token。模型越聪明，它就能直接说“好的，做完了”，我跑一下 lint 图个心安，但其实我知道它一定能过，而这会比小模型高效得多。
swyx：有没有什么好的实践，能判断自己是不是用了过多的 Effort？ Thariq： 代码审查和安全场景应该用 high 甚至 max，UI 这类东西，用 low 和 medium 就够了；如果你在构建 API，那你要确保覆盖足够多的边界情况。
建立起“事情在这些分布上如何运作”的心智模型，本身就是工作的一部分。 Vibhu：这更多是凭直觉，还是基于 eval？
Thariq： 我在博客里把 TerminalBench 的 eval 基本都过了一遍，大概 70 道题，也看了一些转录稿，看它回答了什么、忘了什么。这里还有一个提示词技巧：让它写决策笔记或实现笔记。
因为在几乎每一道 eval 题里，它都想出了正确的解法，然后决定不做，这就是大多数失败的来源。在较高的 max 级别上，模型单纯不知道怎么做的情况非常罕见。
如果你有这些实现笔记，你就能审查，然后说“其实我想让你做这件你没做的事”。模型整体上越来越擅长主动把这些讲出来，比如 Fable 5.1 在输出时就会点出自己的决策，但把这件事更显式地放进 harness 里会更好，现在我们也在开放修改 harness 的方式。
CLAUDE.md 可能该删了 swyx： 我想点出你提到的两样东西，它们其实存在于提示词之外。第一个是那个重要到不该放在提示词里的提示词，它其实在 CLAUDE.md 或 AGENTS.md 里，也就是 Goals。
第二个是决策日志、实验日志，或者你想让它存活到会话之后的任何 trace 日志。这些是外部产物，没有标准，它就是一个 markdown 文件。
那么，CLAUDE.md 要消失了吗？你公开表达过对 AGENTS.md 的不喜欢，但你还是要做它。
Thariq： AGENTS.md，我们要做。但我意识到，维护不同的文件实在是太痛苦了。
而且随着模型越来越好，它们完成最简单任务的下限也在不断提高。所以我认为，在极限情况下，CLAUDE.md 是会消失的。
甚至可能不用等到那么远，我觉得现在开始一个新项目，可能最好就是不要 CLAUDE.md。我的建议是，如果你反复看到某些失败模式，再把它们加进 CLAUDE.md。
但真正麻烦的地方在于，这件事因模型而异：你可能需要 FABLE.md，需要 OPUS.md，甚至 Fable 5.1 和 Fable 5 之间都不一样。也许 Fable 5 有某个失败模式，Fable 5.1 已经没有了。
如果你一直保留着这份不断增长的失败模式日志，它们很可能会过度约束 Claude。我们其实刚刚为 skills 加了 eval 插件，现在你可以评估一个 skill 是不是更好。
Vibhu：Claude Code 里还有没有其他被低估的技巧，人们可以从中获得很多价值但没在用的？ Thariq： 很多都在那份“unknowns”文档里。
我们还加了一个“explain it like I'm five”的 skill，提示词非常短，甚至都没写“像跟五岁小孩解释”这句话，关键词其实是“big picture”，就几个词。效果出奇地好，它特别擅长砍掉废话。
artifact 的一个问题是它们塞了太多文字，根本没人读，这个 skill 把内容简化了很多。它其实是 Anthropic 内部的人在处理非常复杂的事故时，想说“到底发生了什么”而做出来的。
swyx： 我有个类似的版本：测试你的理解，给你几个选项，如果你答错了，说明你以为发生的事和实际发生的事之间有偏差。 Thariq： 大多数人就是不想被考问，不过它确实能让你保持清醒。
Vibhu： 最糟糕的情况是，有人发给你一堆垃圾，他自己都没搞明白要什么。 Thariq： 所以你可以把它做成一个 Mod，确保自己真的测试过。
Claude Mods：定制 Claude Code Harness swyx：那 Claude Mods 到底是什么？ Thariq： Claude Mods 基本上就是你可以定制整个 Claude Code harness，它适用于 CLI，适用于桌面端，也许未来会适用于 Claude Tag。
你可以同时定制 harness 的执行逻辑和 UI，比如 Boris 之前做的俄罗斯方块例子，那就是在定制 UI。再比如，你想每完成一个项目就测试一下自己的理解，那就让 Claude 帮你生成一个插件，它在每次 prompt 之后启动一个分类器：在每个 turn 结束时启动一个 sub agent，或者说 forked agent。
Forked agent 的关键在于它会保留 prompt cache，这是那种反直觉的东西：你 fork 出去做一个小请求，成本会非常低。所以你可以在 fork 出来的 sub agent 里问“这个任务完成了吗”，如果完成就返回 true，然后在你的 hook 里说：如果为 true，用 JSON 格式给我出个测验，再把它显示在 prompt 输入框上方。
这个做法有点费 token，因为每次 assistant turn 结束后都要跑一遍，但它只是一次轻量级的分类，Claude 会一直自动帮你做。我们聊过很多这类小技巧，比如 implementation notes，你现在也可以为它加一个工具，我正在加的这个工具叫 register assumption。
我还在做另一个 Mod，叫 Model router。我们默认不做模型路由，是因为这是个难题，你一定会搞错的。
Vibhu：这里有个粗略的问题：你到底要开放多少东西出来，用户又得为此思考多少？你很容易就能构建一个按 query 路由的 Mod，然后很快就把我的额度耗光。
这样一个产品应该给谁用？是给高级用户，还是所有人？
Thariq： 我觉得是给高级用户的。但 Claude Code 的本质就是，太多人本身就是高级用户了。
因为东西很容易分享，一个人可以做出一个很好的 Model router，然后你就可以把它们组合起来用。插件的另一个很酷的地方在于，它们可以互相 hook、互相组合。
我自己就有一个 Mod，它会在顶部创建一个 Mode selector，任何插件都可以注册成为一个 Mode。比如 auto router 可以是一个 Mode，也可以有一个“artifact Mode”，它主要以 artifact 的形式跟你对话。
就像你在 plan mode 之间切换一样，你可以创建越来越多这样的 Mode，而创建 Mode 的能力本身，就是一个 Mod。我认为这是可变软件（mutable software）的一个预览：生成式软件可以安全地被定制。
只要启用，你就可以定制任何一块软件。理想情况下，越来越多的应用都应该做类似的事情。
swyx： 你还有一条推文讲的是“无限金钱按钮”，让你的 SaaS 可以被 agent 消费。我觉得可变软件很有意思。
难点在于，当你能做一切的时候，用户往往会感到困惑，所以通常能跑通的东西，都是那种只有一个明确观点的流程。而这件事站在“更少观点”的一侧：给高级用户更多权力。
我对这个团队很好奇：你们有没有从 build system 里获得灵感，比如 Babel、Webpack？ Thariq： 我没有深入技术细节，但我知道这是和 Bun 团队的某个人、以及 Claude Code 团队里做过 build system 的某个人合作的。
Agent 现在可以把这种非常复杂的可扩展性直接做进你的软件里，如果你在运营一家创业公司，你可以直接 prompt Claude：我们能不能做一个扩展系统？ swyx：你之前有 hooks 和 plugins 这些东西。
那么 Mods 具体能做什么那些东西在内部做不到的事情？ Thariq： 我们最初把它叫做 function hooks，基本上是注册一个事件，然后调用一个脚本，它是在 TypeScript runtime 内部运行的，所以作用域里有一堆东西：这段对话有多少轮、用了多少 token，这些都能拿到。
因为一切都发生在进程内，你可以 spawn 子 agent 来获取上下文，用结构化输出把结果传回来。而且你可以修改 UI，这是 hooks 永远做不到的。
swyx：那它也能扩展到 artifacts 吗？ Thariq： Artifacts 算是另一种定制方式，我正在做的一个 Mod 是 dashboard Mod。
它们有点正交：Mods 更像是深入你的 Claude Code harness，改变 agent loop，UI 只是附加的好处；而 artifacts 是你想在高层次、高交互性地看东西，它的可操作空间可以比终端大得多。我对 Mods 兴奋的一点是，Claude Code 里有太多东西你得记住。
如果你用这些小分类器把这些事都做了，你只要说“这些是我在乎的”，你就不需要记住那么多东西。我正在做的另一个 Mod 是 next steps Mod。
它的想法是：嘿，发生了这个，用 explain skill 给你解释一下，或者用你的 unknown skill，在那里花更多算力。而且它应该总是以多选题的形式输出。
swyx： 对我来说，模型总是需要被提醒：你到底想干什么？看整个 transcript，然后想：这是最初的目标吗？
你偷懒了吗？如果你偷懒，也许是有原因的：也许你需要我的批准，也许你有两件事想建议。
Thariq： 用 Mods 做这件事的好处是，你可以把它做成一个 fork 的子 agent，所以它之后不会留在上下文里。于是你几乎有一个 supervisor，在确保你能把 next steps 做好。
swyx： 我经常试着放一个 supervisor 来保持高层上下文，把实现细节放在另一个 agent 里。 Harness 工程的苦涩教训 Vibhu： 很多东西会随着模型变化而被抽象掉。
半小时前你说了 harness engineering 的苦涩教训，而我们现在正处在另一个极端。 swyx：如果一切都可以定制，那 Claude Code 到底是什么？
Thariq： 这个苦涩教训本身是反直觉的。我们其实有点在误用“苦涩教训”这个词，它原本更多是关于 scaling 和算力的。
但我用它来做一个近似：harness 会非常快地过时，而且它们变化的方式是反直觉的。最明显的例子是从 chat 到 agent，你必须给它们全新的工具。
而现在模型可以修改自己的 harness，这是另一种利用它能力的方式。模型现在越来越聪明。
你看 TerminalBench 那些题目，复杂度非常高，我作为一个软件工程师根本做不出来。 swyx：你到 TB3 了？
Thariq： 对，它们相当复杂，但目标仍然是交付用户价值。 Claude Code 有 agent loop 的核心，这些核心已经变得更复杂了：它需要 sandbox 来安全运行，需要 auto mode 来确保权限和审批，需要 computer use、MCP、web search、web fetch。
随着模型能做越来越多的事，核心 harness 必须相当复杂且非常安全，但你与它交互的方式可以变化很大。 Vibhu：Claude Code 团队自己还有哪些 harness engineering 的最佳实践？
我记得有过 plan mode 的阶段，某个时间点你们砍掉了大部分 system prompt，去掉了 examples。 Thar