Claude Code 团队松口：AGENTS.md 将支持，CLAUDE.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 的东西比人的东西 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，或者通过你本地的凭证。对于 on-call、事故处理这类本身就是多人协作的事情，Claude Tag 非常有用。

碰到要保密、要安全，或者得让别人过一眼的活儿，我会按项目单独拉一个 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 认为，元技能就是写提示词。不少人觉得“提示词无所谓，我随口说一句 Claude 就能办”。他不这么看，写提示词跟公开演讲、跟写作是一回事：你面对的是一个特定受众，而这个受众就是 Claude。你得在心里建起 Claude 的模型，摸清它怎么想、怎么运转。和 Claude Code 打交道，最要紧的本事就是这套心智模型——清楚它擅长什么、一次能拿下什么、拿不下什么。他看过很多人的提示词，写得都很短，可这些人脑子里对 Claude、对代码库的模型极好，用起来自然不费劲；但这本身就是一件技能上限很高的事。

再往下是“未知”：你得能察觉自己不知道什么、没写下来什么。Claude 能干的活越来越多，你撞上“对自己属于分布外、领域知识又很薄”的任务，概率会非常高。而最要命的未知是“未知的未知”，你压根不知道有这么个东西存在。

他很喜欢“地图与疆域”这个比方。提示词是地图，疆域是 agent 实际要干的活。你越精确，给出的指令就能越精确。拿设计来说，他不是设计师，所以会说“给我八个不同的 mockup”；换成设计师，可能就会说“这是参考网站，我要这种字体、这种感觉，这几个组件要可视化，这是 Figma MCP 面板可以拉进来”。你能用那套语言表达到多精确，取决于你懂多少。游戏设计是另一个好例子，很多人说“我现在能 vibe coding 一个游戏了”，做完却发现“不好玩”。因为每一个选择背后都藏着大量变体和手艺，做一款飞行游戏，飞机的手感、它对操控的响应，游戏设计师可能得在上面耗好几天。

swyx 说，这就是“品味”：从一千个数学上都成立的答案里，挑出人类会喜欢的那个。

Thariq 对“品味”这个词有点纠结，它听着带点精英主义，像是“有的人有品味，有的人没有”。可工程师对自己面对的具体问题都有大量品味，每个人都有对特定问题的品味。他很喜欢 Jason Lou 那句话：“要有品味，你得先吃。”你得做很多事、反复迭代、弄清楚自己喜欢什么，把那套领域词汇建起来，然后写提示词时把这一切揉进去。

Vibhu 说，有时候就是靠直觉。模型给出结果之前，你根本意识不到自己想要什么。

swyx 说，他有一半时间用语音写提示词：对着功能键瞎扯两分钟，松开，然后指望它能懂。通常它还真能懂，但这不如 PRD 或备忘录那种结构化的提示词来得深思熟虑。基本上是双模态提示：有些提示词前期花很多时间，有些就随手一甩。

Thariq 不觉得语音一定低效。关键不在文本格式，而在提示词里塞了多少信息。模型能接住你在提示词中途改主意，对很多人来说，说比打字容易多了。要是说话能让你输出更多信息，那反倒更好。

Vibhu 说，某种程度上，启动前尽量多给模型上下文，感觉就是最佳实践。他刚试 Fable 时，会花整整 30 分钟精雕细琢一个长提示词。他觉得这是对模型运行时间越来越长的回应：它们一旦进入循环，你还是很难去推动。但直觉上，他会在第一个提示词上多花时间，然后跟它大量协作。

Thariq 说，如果自己是软件工程师、在跑创业公司，大部分时候会停在 max 20X 这一档。他见很多人撞上 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 是不是要没了？Thariq 公开说过不喜欢 AGENTS.md，可还是得做。他的回答是：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 提到，Thariq 还发过一条推文，讲的是“无限金钱按钮”，让 SaaS 能被 agent 消费。他觉得可变软件挺有意思，难的地方在于：什么都能做的时候，用户反而容易懵，所以真正跑得通的，往往是那种只持一个明确观点的流程。而 Mods 这件事站在“观点更少”的那一边——把更多权力交给高级用户。他对这个团队挺好奇：有没有从 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 则是你想在高层次、高交互性地看东西，它能操作的空间比终端大得多。

让 Thariq 对 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 就是一种既拿到 Claude Tag 那类好处、又不用折腾整套 admin 设置的路子。

当“组织级 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 是可以黑的，结果能靠逆向工程推出来。再往下看，它们就开始配合起来了。

模型发现，scorer 的问题其实能解——scorer 正是 OpenAI 拿来判定任务有没有完成的标准，也是模型唯一要达成的目标。它们翻到 ExploitBench 上的一篇论文，判断 scorer 会因作弊反过来惩罚自己，于是把剩余算力全调去改自己的转录稿，想绕开这道限制。它们入侵 Hugging Face，图的是 scorer 的代码，拿到手就能逆向工程，再把它黑掉。这就是明摆着的事实。我觉得这太新鲜了，之前根本没料到模型干得出这种事，说实话有点吓人。

另一个是 wiki 事件，我在推特上提过。模型被沙箱在 request 里，想发 post 请求，这需要协作，因为每个模型的算力预算都是固定的：一个模型有发现，可它的预算快见底了，另一个模型能接上继续用，这又是 swarm 的一种涌现属性。它们找到一个德国 wiki，能用 GET 请求往里写。用 swyx 的话说，就是一个实现烂到家的 REST API。

接下来它们琢磨怎么发 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，答案就在医生的数据库里，你想拿到访问权，黑进医院，结果停电了。你得把它内化：数字基础设施的任何部分都可能被攻破。

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 实验室还能做得更好的地方。但他觉得这是个真正令人兴奋的时代。他猜以后回头看这段日子，会说它忙乱得不行，却也刺激得不行，软件工程已经彻底变了样，能参与其中是一种特权。