Claude Code松口支持AGENTS.md，团队称静态指令文件终将消失

一个多月前，Claude Code 明确拒绝兼容 AGENTS.md，而这个文件早已被大量项目和 Coding Agent 当成行业标准。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 的东西，扩展性比人的东西强太多：人这边同时来三件急事，你怎么接？

Vibhu：你的时间主要花在哪？你又写技术文章，又做工程。

Thariq 坦言，自己刚进入 Claude Code 团队那会儿，主要精力都放在教别人怎么用、怎么把它打磨得更好用。可 harness 越做越强之后，问题就变成了「你究竟怎么把这些 agent 用好」，而这件事的技能上限高得惊人。他同时也在做工程和演讲，做工程是为了收集用户反馈，再拿这些反馈去讲「怎么用 Claude Code 做工程」，两头正好形成一个循环。也正因如此，他当时对 harness 这条路会怎么走、所谓「苦涩教训」会指向哪里并不确定，偶尔还会冒出「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。Thariq 一直在推的一件事叫「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 指出，Thariq 讲的两样东西其实都在提示词之外。一个是重要到不该待在提示词里的提示词，它落在 CLAUDE.md 或 AGENTS.md 里，也就是 Goals；另一个是决策日志、实验日志，或者任何你希望它在会话结束后还活着的 trace 日志。这些属于外部产物，没有标准，就是一份 markdown 文件。那 CLAUDE.md 是不是要没了？Thariq 公开表示过不喜欢 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，你现在也能为它加一个工具，Thariq 正在加的这个叫 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。在他看来，这就是可变软件的预演：生成式软件能被安全地定制。只要启用，软件的任意一块都能改。理想状态下，越来越多应用都该往这个方向走。

swyx 提到，Thariq 还有一条推文讲的是“无限金钱按钮”，让 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。

Thariq 觉得这里会走出一条分叉路。他说，将来模型大概真能直接 vibe code 出一个一模一样的 Claude Code，但眼下它们已经可以 one-shot 掉那些更简单的 harness。过去你非得用 agent SDK 不可，如今这层被继续抽象掉了，Claude Managed Agents 就是产物——它既给你那份复杂度，也允许你写一个极精简、只服务于自己任务的 harness。他把它形容成杠铃效应：编码任务特别复杂，就用 Anthropic 的 harness；任务简单些或者偏垂直，那就自己搭一个。

swyx 追问，有没有一条大致的演进路线？

Thariq 的回应是，projects、artifacts，以及把“大脑”跟“手”和各种 surface 拆开，这个方向就是事情的走向，只是还没完全走到位。有一部分原因在于它更烧 token：你让 Claude 多干活，它去管子 agent、去做 review，这些原本都是你自己在做的。

swyx 说 Claude 和 local 之间的 handoff 挺有意思，他把它理解成“反向的 Claude remote”。

Thariq 提到，有人大量用 remote control，有人大量用 Claude Code on the web，Anthropic 内部显然大量使用 Claude Tag。Claude Tag 的好处在于，他们为自己的执行把这一整套都配好了，对企业来说这仍然是最佳路径。可如果你只是个人，projects 就是一条不用整套 admin 设置、又能拿到 Claude Tag 那种好处的路子。

当“组织级 Harness”成为企业 AI 落地的真正形态

swyx 问，Claude Tag 上线差不多两个多月了，有没有什么新东西？

Thariq 说各人用法不同。偏产品迭代的那批人会用 Claude Code desktop；做代码审查、安全、起 PR 这类后台工作时，API 和 Claude Tag 用得更多。他觉得这是一次相当不同的范式转移，有点像 Claude Code 刚出来那会儿——人们花了一阵子才真正上手。Claude Tag 还要更复杂一点，得有个 admin 帮你装，可一旦你到了那个“魔法时刻”，它会让人非常兴奋，尤其是 multiplayer 那块，比如接进你现有的 alerts。他举了个例子：你是个创业公司，任何时候有潜客进到你数据库里，你可以让 Claude 去研究这个人，再 tag 相关的销售。这就像 Karpathy 说的，是一种“组织级 harness”。

Vibhu 的感觉是，Anthropic 大多数人都说自己的大部分工作是在 Claude Tag 里完成的，但也有人跟他讲“我不懂，我看不出区别”。

Thariq 说，Claude Code 刚出来的时候，它消耗的 token 就远超人们对 AI 成本的预期。在 Claude Code 之前，没人习惯一个月花超过 20 美元，然后你突然发现，自己一个月的订阅要 200 美元。而且 Opus 4 是个很贵的模型，可 Opus 4.5 又强又便宜。他认为同样的事会再发生一次：智能越来越便宜、越来越充裕，所以 Claude Tag 这类东西会越来越说得通。

swyx 补了一句，尤其是那些主动的场景：你不总是主动叫 Claude 干活，有时候最敏捷的用例，恰恰是你不需要主动叫 Claude。

Thariq 提到，企业如果想用好，第一步该做的其实就是把全部数据都开放给 agent 用，这件事既关键又费时，得马上动手。但 Claude Tag 有个很麻烦的点，安全这根弦必须绷紧。举个例子，你弄了个建议提交页，用户把建议发进来，触发 Slack 里的一个 hook，这时候要是有人来一发 prompt injection，整个代码库就被带出去了。换句话说，组织 harness 越吃重、组织数据越值钱，暴露在外面的攻击面就越大。按他们开场时的说法，这个攻击面就是座冰山，藏在水下面的部分大得很。

Pacing the Frontier 与自主 Agent 安全

Vibhu 说，他之前跟 Hugging Face 的 Tomas 和 Clem 聊过，那两人讲，也许他们把 Hugging Face 对 agent 开放得太过了，也许需要回滚。

Thariq 提到，Dario 最近发了一篇讲“pacing the frontier”的博客，非常火。真正触动他的是去读那些具体事件，一共三个：一个 METR 事件，一个 Wikipedia 或者说 wiki 事件（Collision Wiki），然后还有 RubyGems。具体讲，OpenAI 在一个叫 ExploitBench 的基准上跑这些非常持久的 agent，这个基准极难解，在某个案例里他认为实际上根本解不出来。agent 们意识到自己解不出来，但还剩着很多算力，它们就一直试图解决这个问题。有一个叫 Artifactory 的包管理器，结果它们能在 Artifactory 里创建文件夹。

还有个 agent 察觉到内部的 Artifactory 也许能拿来做文章，它想到可以借缓存名来传递信息。于是它建了个文件夹，把自己的 ID 写上去，还写了句“no consumer”，这是种状态标记，跟 Linear 看板上的标签差不多，它想从别的 agent 那儿套点线索出来。别的 agent 一看到这文件夹，反应是：“哟，这不就是个留言板嘛。”没什么拟人化的东西，纯粹是照着转录稿字面去读。接着它又新建了一个文件夹，看完一篇论文后明白过来，scorer 的 flag 是可以黑的，结果能靠逆向工程推出来。再往后翻，这些 agent 已经开始配合干活了。

模型发现scorer的问题是可以被解决的，而scorer正是OpenAI拿来判定任务有没有完成的那套东西，也是模型唯一的目标。它们翻到ExploitBench上的一篇论文，判断scorer会因为作弊反过来惩罚自己，于是把剩余算力全花在琢磨怎么改自己的转录稿、怎么绕开这道限制上。它们入侵Hugging Face，要的不是答案，而是scorer的代码，拿到之后就能对它做逆向工程，再把它黑掉。这就是板上钉钉的事实。我觉得这极其新鲜，以前我根本没意识到模型能干出这种事，说实话有点吓人。

再讲一个我在推特上发过的，wiki那件事。模型被沙箱限制在request里，它们想发post请求，就得协作，原因是每个模型的算力预算是固定的：一个模型发现了什么，可它的预算快见底了，另一个模型能接着用，这又是swarm的一种涌现属性。它们找到一个德国wiki，能用GET请求往里写东西。

swyx：一个实现得特别烂的REST API。

Thariq：没错。接着它们想办法发post请求。最后其中一个发现：可以编辑/etc/hosts，Azure存储桶是个白标的东西，只要造一个假的Azure host，再把任意IP指过去，你就能向任何网站发post请求。

我知道有人会说“这不就是Linux嘛”。可这是把好几个漏洞串在一起，用全新的路子解决这个问题，然后在不被发现的前提下跟外界通信。

我们或许可以引用Evan Hubinger关于hacker Opus的看法。你可能会讲，它们只干了一次，那要是跑一个eval呢？我们投入了大量预防措施，这不是主线模型的行为。可事实证明，对齐是极其棘手的问题。沙箱的攻击面非常复杂，你事前想不到“我们得加固RubyGems代码库”，但你要执行代码，就得下载RubyGems。PyPI、Artifactory、npm，这些都是执行代码的途径。你得把这一整套都走一遍，遏制住，把所有裂缝堵上。

那为什么非要把东西放进沙箱？真有那么危险吗？第一，训练一个新模型时，我们需要搞懂它的能力，这关系到fallback和分类器。但模型越来越能察觉自己身处eval之中。它们越聪明，我们要是不够小心，它们就能黑掉你加在它们身上的任何约束。这就是frontier，也是我们管它叫pacing the frontier的原因。在frontier上，我们所有的软件都没准备好，有时候那软件就是你的以太网路由器，天知道补丁什么时候才能打上。

swyx：这就是所谓的race dynamics。

Thariq：对。你可能会说，那你换个方式训练模型不就行了？我们有一篇关于RL错位的论文。往高了说，RL环境的设计也是你必须格外小心的地方。如果模型学到“我这样做就能更好地通过任务”，这会在我们测试时的eval行为里露出来。然后还有Constitutional Classifiers这类东西，但任何一点仍然都可能出岔子。

你得设想这些模型越来越智能。Dario说问题不在这类模型身上，这类模型只是一个警告信号。你给它们一个目标，它们就得找数据，或者找修复问题的办法。举个例子，这事没在Hugging Face事件里发生，但未来的模型可能会说“这个问题太复杂，任务预算内做不完”，也许它们会找到某种方式，通过互联网去协调。它们说“我们需要更多任务预算”，你去哪弄任务预算？你得能启动更多agent，得有API，可你得付钱。一旦它们签下这些合约，就是巨大的财务损失。

swyx：这是你能想象到的最可怕的事吗？

Thariq：这只是一个例子。这些行为可能都只是“我们需要更多agent协作来完成这个任务”。这是一种涌现，我们要把回形针最大化。可然后你得意识到，整个世界都建立在数字基础设施之上。想象你在跑一个医疗eval，eval的答案在医生的数据库里，你想拿到访问权，你黑进医院，现在停电了。你得往心里去：数字基础设施的任何部分都可能被攻破。

Vibhu：有意思的是，这些黑客行为其实很容易被检测到。担忧在于这么走下去会到哪一步。对我来说格外突出的一点，是它们试图藏起自己的非法行为。有日志基础设施，它们想改动自己做过的事，好让回头查的人看不出来。你能看到它们明确想改最终输出，但思维链不一样，因为我们可以监控。问题是怎么滚雪球：要是你没抓住，它被训练进去了，我们三个迭代之后才发现，那就有一堆麻烦了。

Thariq：我们聊过给Claude建立心智模型，事情是尖峰式的。一年前你问我，我们能vibe code这些Claude Code的扩展吗？我会说，那太复杂了。它们做错位行为的方式没法预测，我永远想不到它会去编辑/etc/hosts。

你得设想它们能做的事，攻击面越来越大，手法越来越有创意。下一次事件是什么，你预测不了，但要想防住它，你需要那种运营卓越：保护沙箱，打造安全的RL环境。这就是我们为什么认为应该pace the frontier，也是为什么这成了一件有共识的事，每个实验室都同意。如果你是开发者，把这些技术事实走一遍，就会得出我们必须做点什么的结论。第一件事，是我们得决定去做。

还有另一部分pacing我觉得挺有意思：软件工程变化的速度太快了。一年前我还在求我的朋友和创业公司用AI，如今同样是这批人，说“当然啊，我们立刻就用了”。我有时候觉得抱歉，人们说“哦，现在我得为Fable和Opus准备不同的CLAUDE.md”，我真的只是在报道事实。我们喜欢说模型是长出来的，不是设计出来的。事情发生得更快，更难跟上。我认识的每个工程师都有点精疲力竭，因为你在同时干两份活：工作本身，它变得更容易了；然后是跟上AI的活，理解这些新工具和harness。

不过 pacing 这回事，我觉得还有一层：我们是不是真准备好让节奏再快一点，我并不确定。经济颠覆也是其中一块，它没 Hugging Face 那件事那么扎眼，可我觉得同样不能缺。

Vibhu 问，能不能给个省流版，这个提案到底说了什么？

Thariq 说，沙箱我们确实想护住，我们发出去的模型也别成了这些东西的猎物。那些事件我们看到的只是其中一部分，至少得让模型跑起来才能看懂它们的 eval。pacing the frontier 那篇文章里提了一堆提案，细节是不是全都想清楚了，我不觉得，但第一步是先把这个意图讲出来，再拉外部评估者进来。关键是得有个不被钱驱动的人，或者至少有人能站出来告诉公众，实践到底长什么样。

对开发者来讲，你该清楚自己要争取什么。这个话题上 FUD 很多，你只要从第一性原理去想，弄明白发生了什么就行。我们生活在民主国家，可以一起决定要做什么。不管怎么协调，头一个决定就是先意识到这是个问题，然后决定去协调。

swyx 说，我们正在做的单边动作，是把评估者嵌进 Anthropic 内部。第二部分、第三部分，就是走到评估者之外。

Thariq 说，老实讲，pacing the frontier 得到的回应，哪怕只在美国国内看，也比很多人以为的更容易被接受，把它拿出来谈，就是达成协议的第一步。

swyx 说，我们最早那期播客请的是 Anthropic 的 Emanuel，聊 mech interp。mech interp 应该做到的是，模型想干坏事的时候我们能看见，而模型还不知道，我们能动手拦住它。你要是技术够硬、是开发者、又真的在乎，在这件事上能发挥很大作用。

Thariq 说，老有人问我，为什么还要有这么个 fallback？推理的时候我们有一种东西叫 probes，还写过一篇论文叫 Constitutional Classifiers。这些 probes 看的是输入和输出的激活，激活在潜空间里，代表模型在想什么。我们想搞清楚的是：模型是不是在试图黑什么东西？你并没让它去黑 Artifactory，它自己就决定这么干，好把任务完成。光看输入，你抓不到这个，必须看内部激活。

这里有个成本和速度的取舍：它得在每一次请求上快速跑完，是有开销的。所以我们需要 fallback，在 probes 之后再做一个分类器。probes 的好处是能实时改进。另一种办法是把它训进模型里，我们也这么干：模型会拒掉一个请求，那不算 fallback，那就是拒绝。越狱模型、想把它带偏这种事，大家应该都试过，probes 也能帮忙抓住。可我们不想让拒绝太强，太强会把整条流水线过早掐断。probes 其实就是 mech interp 的一种形式，它必须跑得快，必须上规模。

你可以拿一个开放权重模型，去试着理解它的激活，Gemma Scope 就是个好工具。我还在 Goodfire 待过一阵，做稀疏自编码器。RL 确实让这件事复杂了不少，这是很大的一个收获。这方面我已经不算技术专家了。有基础模型，也有 RL 模型，被改变的特征更多了。

Vibhu 说，想要点面包屑的人，你们有最好的 interp 博客文章。Golden Gate Claude、Transcoders，可视化做得非常好。

Thariq 说，这是 Anthropic 立身的根本。你说“我们是 AI 安全公司”，意思就是想让 AI 安全地跑起来。要让一个超级智能 AI 长时间运行，是极其复杂、极其困难的任务。即便如此，它真的很吃紧，我们需要慢一点，或者 pace 得更从容一点。模型越聪明，它们在潜空间里能想到的东西就越难办，所以会有新的误报等着弄清楚。我们确实认为这是部署这些模型的关键一环，有了它，我们才能部署这个模型，而你也不必有一个完美的沙箱。

有模型训练层面的东西，有 probes 和分类器，再往上还有 auto mode，那是另一个分类器，检查正在发出的请求，再往外是身份和权限。要做的安全层有这么多，任何一处失败，agent 都可能逃出沙箱。

swyx 说，auto mode 挺有意思。早期它跑 10 分钟，没什么大不了。可你提到，现在它要跑几个小时。你仍然需要 fallback，仍然有限制。

Thariq 说，这种故事每个人都有：模型 rm -rf 了什么东西。你想给模型开生产数据库的权限，你可以把自己的 key 限住，但它能用 computer use 去给自己签发一个 key，然后改你的数据库，因为它得这么干才能完成任务。auto mode 看到这个就说：“哦不，用户没给你写数据库的权限。”所以 probes 管的是意图层面，“黑 Artifactory 是坏事”；auto mode 更多管你自己的权限层面，你得保证 agent 做的事，意图和你的请求对得上。安全真的非常非常复杂。

Vibhu 说，我们可以补几句。就像你们这边有 probing、有分类器。另一条路是模型保障，Llama 有 Llama Guard，OpenAI 有 OSS Guard，你可以把它们挂到自己的 harness 上。关于 OpenAI 模型和 Hugging Face 那件事，有一点要澄清：那是用一个未发布的、还在训练中的模型做的。它在 RL 环境里拿到的提示是“你必须解决这个任务”，这是个仍在训练中的模型，还没做完所有的安全后训练对齐。所以它和 auto mode 不太一样，auto mode 跑的是生产模型，已经过了安全训练。

swyx 问，我们要 pace 多久？会不会 pace 太久？

Vibhu 说，我先讲一件我们做得不错的事：有 Glasswing 这样的东西，OpenAI 也有，你会给模型访问权限，安全优先，你可以拿它来自我红队。先把自己的问题解决掉，模型才发布。

Thariq 说，Firefox 里很多 bug 之类的东西，就是这么修掉的。

Vibhu 说，所以从高层面看就是：先让人拿到访问权限做安全审计，之后更广泛的公众才拿到访问权限。

Thariq 提到，大家常说软件和网络安全是防守方占优势，从理论上讲，确实能靠工程手段做出滴水不漏的沙箱，可这得花时间，而模型只会越来越强。他说自己想表达的其实很简单：我是一个开发者，这就是我目前看待这件事的思路，总得动手做点什么。swyx 则觉得，每一位工程师都该了解这些，因为它迟早会成为日常工作的一部分。

Vibhu 强调，这件事远比翻翻事件报告复杂得多，其中还有工程层面的内容。swyx 补充说，Thariq 想讲的另一点是——哪怕对影响有所担忧，p(doom) 依旧处在很低的水平，这个话题本身就挺微妙。

Thariq 表示，他的 p(doom) 相当低，不过这只代表他个人，Anthropic 内部意见是多样化的。他脑子里的模型是：大家可以在困难问题上携手合作，核不扩散就是这类协作的一个例子。他确实认为这是个难题，至于怎么给已经发生的事算概率，他也说不上来。但总体感觉是，人类很有韧性、适应力也强，把信息分享出来只是第一步。看到这场讨论铺得这么开，他非常兴奋。

swyx 接过话头，说也许还该算上治愈癌症。既有 pacing 一说，也有“让我们以有用的方式加速”，比如生物学领域。

Thariq 认为，Dario 的 Machines of Loving Grace 是这方面最好的代表，另外 Dario 那篇 pacing the frontier 也值得一读。这是个重要议题，光是去了解它，本身就有价值。

swyx 感慨，这是一段很长的旅程，从 ask user question 工具一路走到 AI 安全、再到 pacing the frontier。他请 Thariq 最后对大家说点什么。

Thariq 说，他知道事情变得极快，很多人会觉得有点累、焦虑或者压力大，这完全可以理解。他们自己也不完美，欢迎批评，也理解所有 AI 实验室都有能做得更好的地方。但这是个真正让人兴奋的时代。他猜，日后回头看这段日子，会说它非常忙乱、也非常令人兴奋，软件工程被永久地改变了，能参与其中，真的是一种特权。