Claude Code没有“魔法”

编译｜宇琪

策划 | Tina

过去一年，编程 Agent 的能力大幅提升，软件工程师对它们的要求也比以往任何时候都高，但上下文窗口的大小却基本停滞不前——一年前，一百万个 token 大致就是最先进的水平，如今依然如此。随着我们逐渐进入 Agent 日常处理 Monorepo（单体仓库）级任务的世界，将越来越多的信息塞进模型那固定的上下文限制中，这种需求已经变成了一项实实在在的全职工程任务。

Daisy Hollman，这位曾在 C++ 标准委员会深耕近十年、当过两年主席的资深工程师，如今在 Anthropic 的 Claude Code 团队主导插件与 Agent 团队的设计。近日，她在 NDC Copenhagen 的演讲中，详细介绍了 Claude Code 插件的设计与其构成的上下文工程原语，以及 Anthropic 内部是如何运作多 Agent 工作流的。基于该演讲视频，InfoQ 对内容进行了整理。

核心观点如下：

• 如果 Claude 不能做所有你能做的事，它就无法和你一起做你的工作。

• 给 Claude 或者给你的模型，访问你完成工作所需信息的权限，会帮助它更好地做你的工作，或者和你一起做你的工作。我们并不是真的要取代自己，我们是想要成倍地放大自己。

• 定制化就是知识，定制化是在弥合模型天生所知与你们团队所知之间的差距。

• 钩子是唯一真正能扩展的插件抽象，不匹配就不注入，只在触发时才往上下文里放东西。

• 2026 年的核心转变是，从“把信息输入模型”转向“把信息从模型输出给用户”，人的注意力才是系统中最小的盒子。

从聊天机器人到 Agent

最初让大语言模型跑起来的时候，我们用它们构建的是聊天机器人，交互方式大致是：人类说一句，模型回应一句，然后又回到人类说话，模型再回应，就这样循环往复。

到了 2024 年，我们搞出了一个叫工具调用的东西，它让模型可以请求计算机去做某件事。一开始，模型就是能去执行个操作、拿到输出、基于那个结果做个决策，然后再回到人类这边。后来我们慢慢给它加越来越多的工具，比如它可以基于第一次工具调用的结果做第二次工具调用，然后再做第三次，到某个节点，我们跨过了一条边界，觉得得给这东西起个新名字了，于是开始叫它们 Agent。这就是“Agent”这个术语的由来：从零次工具调用，到一次，到几次，再到某个时刻它有了足够的自主性，我们就管它叫 Agent 了。

编码 Agent，或者叫 Agentic 编程 Harness，像 Claude Code、Codex、Cursor 这类东西，本质上就是 Agent，只不过我们给它们的工具是普通程序员用的工具：文件编辑、CI 相关工具、跑代码的能力、编译代码的能力，这些基本都能归入 shell 命令，但本质上是我们给了 Agent 一个程序员能做的事。

但说实话，工具调用原始得令人震惊。你告诉模型它可以写 JSON，当它写了某种 JSON 之后就会有事情发生，然后你把做那件事的结果喂回给模型，塞进它上下文窗口里紧跟其后的位置，整个机制就这么简单。模型在 bash 里跑命令就是这么干的：它说它想用的工具是 bash，这是命令。然后 Harness 去执行命令，把输出放进一个工具结果块里。Agentic Harness 里所有东西都是围绕这个想法构建的：基于这个输出采取行动、再生成一个基于它的新工具调用、然后继续这个循环，这就是 Agent 的本质。

真正让编码 Agent 跑起来的主力工具是编辑工具，这就是 Claude Code 里编辑工具的字面 schema。顺便说一句，我这些幻灯片全是 Claude Code 做的。当时我想要这个的时候，我就说：“嘿，你能把你系统提示里的一个工具调用放到这里来吗？”所以它得给出旧字符串、文件名、旧字符串和新字符串。就是个查找替换，没有光标，没有选区，没有引号转义，旧字符串必须逐字节匹配。如果旧字符串出现多次，它要么提前声明自己预期有多个匹配，要么就直接失败。这些工具真的非常原始，而且我认为这个领域还有大量迭代空间。

既然这些幻灯片是 Claude 做的，那么生成上一张幻灯片的工具调用长这样：它写出的 JSON 里嵌套着引用旧幻灯片的 JSON。模型在这方面的表现好得惊人，整个过程中一个 token 都没错，至少对我来说这相当震撼。我对 Agent 如何工作、擅长什么、不擅长什么的心智模型，到现在都跟这个表现对不上。如果要逐字符去写的话，这不是人类能做到的事，所以这给你一些关于 Agent 在做什么、可能擅长什么、可能不擅长什么的微妙感知。它生成这个毫无困难，没有错误，没有多次尝试。我上次看到字符串替换错误或编辑工具错误，大概是在 2025 年 2 月或 4 月。模型已经远远超越了那个阶段，因为这是很容易训练的东西。

因为模型能处理这种复杂度，你可以让工具调用变得越来越复杂，让它能做越来越多复杂的事情，这就让更长时长的任务成为可能。

这里有一张来自 AI 研究机构 METR 的图表，它被称为 Agent 的摩尔定律：模型能以 50% 成功率完成的任务时间跨度，大约每四个月翻一番。你会看到这个趋势在今年年初开始停滞了。这张图里没有 Opus 4.7 和 4.8，是因为该机构实际上认定，过了 Opus 4.6 之后，“什么算作 16 小时任务”的误差范围太大了，所以这张图表几乎不再有用了，但在过去三年里，它一直是一个相当稳定的趋势。

你可以一开始就假设这会在某个时刻趋于平稳，它会的。但我认为，如果你在七八十年代打赌摩尔定律会趋于平稳，你的处境会与当时不打赌的人截然不同。我认为，至少值得考虑这种可能性：这个趋势至少还会再持续一两年。而且你知道，指数趋势在改变我们工作方式方面的疯狂程度是难以想象的。

四月份，Mozilla 基金会发布了一张图表，展示了他们在四月份使用我们最新模型所修复的安全漏洞、缺陷的数量，这个数量比他们过去 15 个月修复的总和还要多。这并不是说他们在过去 15 个月里没有 AI 工具，而是最新的 AI 工具与他们过去 15 个月拥有的工具之间的区别。

所以，接下来我想探讨一个假设：如果 Agent 写的代码比你好，工程会变成什么样？我是一个曾经热衷于讲 C++ 元编程细枝末节的人，我曾为自己的编码能力感到无比自豪。但在 Anthropic 这一年半的经历，真的让我确信这些都不重要了。在这个假设的基础上继续构建： Agentic 编程会是什么样子？Harness 设计会是什么样子？上下文工程要怎么做，才能让我们把这个东西构建成真正能管理 Monorepo 级软件项目的系统？

为什么要定制化

我们先谈谈：为什么你需要定制模型？如果我们正朝着所谓的 AGI 前进，它应该是普遍智能的。那为什么我还需要告诉它任何事？

第一，它需要能访问它完成工作所需访问的东西。第二，它需要了解你公司里任何员工都能获得的全部机构知识。第三，它必须有工具去获取这些。

核心论点是：如果 Claude 不能做所有你能做的事，它就无法和你一起做你的工作。开箱即用时，它真的只能看到一个代码仓库和一个 shell。而且默认情况下，我们甚至不允许它走出你启动它的那个文件夹，这有很好的安全理由，但我不认识任何一个专业软件工程师会说：“我打算一整天都不看我这个文件夹以外的任何信息。”

这对于零到一的项目来说还行，我认为这就是为什么人们在快速原型和零到一项目上看到更多成功的原因之一，部分原因在于那确实更容易，即使对普通的人类软件工程师来说也是如此；但另一部分原因在于，我们给它设置的受限上下文和边界，对 Agent 的负面影响甚至更大，这很少足以在真正大规模的范围内做高质量的软件工程。

还有一件我认为人们想得不够多的事：大多数专业软件工程并不存在于源代码里。编程是关于源代码的，但软件工程涉及的远不止编程。所以，给 Claude 或者给你的模型，访问你完成工作所需信息的权限，会帮助它更好地做你的工作，或者和你一起做你的工作。我们并不是真的要取代自己，我们是想要成倍地放大自己。

你的工作到底在哪里？大多数决策是在哪里做出的？决策其实不是在源代码里做出的，除非你有一个和我所习惯的非常不同的软件工程环境。你有团队聊天工具，你有 CI 来发现事情是否正常运转，你有仪表盘展示生产环境的情况，你有内部文档、设计文档等等。我给人们的建议是，试着离开终端，做一整天的工作。如果你不能完成你的全部工作，那么 Claude 也无法和你一起完成你的工作。如果你收到一条 Slack 消息，而你无法通过告诉 Claude 该替你说什么来回复那条消息，那么 Claude 就无法替你回复那条 Slack 消息，也无法针对那个线程里的信息采取行动。如果你遇到 CI 失败，而你需要把 CI 失败的信息复制粘贴到 Prompt 里，那是你在替它做事，而它无法再为你做这件事了。

当我说“知识（Knowledge）”的时候，人们往往过度强调“这只是不在训练数据里”。现实是，有些东西根本没法训练进模型，因为不同公司的做法各不相同，比如你代码库的 Conventions，你的机构记忆，你们团队两个季度前尝试过但从未见天日的事情。即使我们有一个完美训练的模型，我们也需要一种方式让模型访问这些非公开信息。上周刚发生变化的事情，但模型有训练截止日期。还有些东西只属于你们自己：内部 API、内部词汇、你们代码库和设计文档中使用的术语定义，以及如何找到这些定义。所以定制化就是知识，定制化是在弥合模型天生所知与你们团队所知之间的差距。

这个现象的时髦术语叫做上下文学习（In-context learning），本质上就是指文本文件。模型的权重在我们发布模型的那一刻就被冻结了，你不会去改变那些权重。尤其是最近随着微调接口和微调 API 的逐渐收缩，外面的微调越来越少。你将要做的几乎所有定制化，都发生在文本层面。这其实是个非常酷的事实，因为程序员最擅长的就是控制文本。你不需要知道任何关于 LLM 权重的数学原理，不需要懂任何底层机制，你只需要知道如何操控文本。你把文本放进模型，就会得到不同的输出。它当然不是确定性的，但你可以通过改变输入来改善模型的输出。

Claude 现在工具调用的方式，差不多相当于 Unix 的 ED 编辑器（相当于 VI 最底层的功能集合）。如果你不得不靠查找替换来完成全部编辑工作，那大致就是今天 Agentic 工具化的水平。

还没有人真正搞清楚：Claude 的 IDE 应该长什么样？模型的实时反馈应该是什么样？从 ED 或原始 VI 到 VS Code 之间的这个巨大鸿沟，就是机会所在，而这一切都发生在文本空间里，这非常令人兴奋。我们不是把信息反馈回权重里让模型在编程时不再犯错，我们实际上就是把文本反馈给模型。

所以我想举的例子是：Agent 的红色波浪线应该长什么样？Agent 怎么知道自己在工具调用中做错了什么？人类怎么知道自己编辑错了？如果某个变量不存在，或者在此上下文中引用无效，你会看到一条红色波浪线。但显然模型拿到的是纯文本，它们得不到这种富文本反馈，也无法在输入过程中实时获得反馈。所以我们必须自己动手补上这个机制。

我们在 Claude Code 里提供的机制叫做 post tool use hook——当 Claude 执行我们之前演示过的工具调用时，作为工具响应块的一部分，我们会把你提供的信息附加进去。但关键是，这已经是你知道怎么产出的东西了，你的代码库本来就知道怎么生成这些信息，因为你以前就是靠它来鼠标悬停查看红色波浪线的，那段文本已经存在了。

它是在错误发生的那一刻给出的轻推，而不是等模型回头编译时才意识到“哦，我原来想表达的是什么意思”那会消耗更多 token。你可以在这里放很多东西：类型检查、linting、标记那些你在 CLAUDE.md 里想让它做但它没做的事。但让 Agent 在你代码库里表现更好的最快方式，不一定是更聪明的模型，而是更紧密的反馈循环，尽早告诉它犯了错，而不是等到更晚，而且这些脚本大部分你早就有了。

工具分两种：一种是在弥补智能的不足，另一种是随智能一起扩展，这对人类或模型都适用。你可以给一个初级工程师一些工具，阻止他们编辑某些文件、修改某些东西、运行某些命令。但等他们成长为高级工程师、你信任他们做那些事了，你就得给他们一套新工具。但如果你有一个能给出轻推或提醒的工具，它可以跨越级别，因为你知道高级工程师偶尔也会犯这些错，但他们也知道什么时候不是错误。所以你要专注于构建第二种工具给你的 Agent，不只是想着现在什么能帮到模型，还要想着两代之后、当它变得更强时什么能帮到它。

上下文窗口是一个盒子

上下文窗口是一个盒子，是模型为了预测下一个 token 所能看到的那一组 token，是一个有限的、固定大小的东西。它是你做定制化的空间，是你放文本的地方。过去一年里，模型的能力爆炸式增长，从花哨的自动补全走到了长时间跨度的自主工作，但上下文窗口的大小没有变过。

第一批 100 万 token 的上下文窗口出现在 2024 年底，2025 年 2 月最前沿的模型是 100 万 token 的，而现在最前沿的模型大约还是 100 万 token 的上下文窗口。它的扩展速度远远赶不上模型能力的增长。这意味着，随着任务越来越复杂，你在往这个上下文窗口里放什么这件事上，必须变得越来越聪明。

我们很早就发现，你不能把整个代码库都扔进去。但文档、内部代码库、提醒等东西，你得把它们塞进这个上下文窗口里，所以这正在变成一门全职的工程学科。

我注意到很多“软件工程师”对“上下文工程师”这个头衔有抵触情绪。我想说的是，这两件事其实是同一件事。随着 Agent 在写软件、做真正的软件工程方面越来越强，教它们怎么做这件事，将会成为软件工程的主要学科。其实这一直都是软件工程的主要学科。只不过在过去，你得做到足够资深的级别，你的全职工作才是确保更初级的工程师能做好他们的工作。现在，只是换成了 Agent 而已，而且你得在每个级别上都能做到这一点。

上下文窗口就是我们必须把所有对预测下一个 token 有贡献的东西都放进去的地方，你的系统 Prompt、工具定义、CLAUDE.md、Skills、读过的任何文件、任何工具结果，所有这些都在里面。而且，你在前面堆的东西越多，留给后面做实际任务的空间就越少。每一项定制都在和工作空间竞争，你的整个代码库根本放不进去。你不能天真地把所有东西都倒进这个盒子里，你可以这么做，但效果远不如非常仔细地挑选相关上下文来得好。

我喜欢用的一个类比是，这就像在 Arduino 上跑 npm。当你在电脑上运行包管理器时，你可以用各种手段来处理传统的依赖管理问题。如果 npm 里有菱形依赖冲突，你直接导入两个不同版本的库就能解决。但你在定制上下文时做不到这样，你必须智能地判断哪个是更相关的信息，把它放进去，把不相关的排除掉。所以定制化的原则必须是：不为你不用到的东西付费，零开销原则，否则你很快就会把 token 用光。

还有一个约束——KV 缓存。现代 LLM 的 next token 预测机制，如果这些 token 和上一次完全一样，那么计算成本会便宜非常多。我们在计算领域其实早就遇到过这类问题，你有相关信息、不太相关的信息，还有一个非常有限的存储空间，通常的做法就是 LRU 缓存，CPU 缓存和 Web 缓存都是这么做的。但问题在于，LLM 的预测机制有个硬约束：要预测下一个 token，前面所有的 token 都必须保持一致。这就导致一个结果——这次的预测成本比那次贵 10 倍。如果你每次工具调用都这么做，你的 token 消耗会变得极其庞大。

Cursor 早期在 Cursor Rules 上就吃过这个亏。他们最初的做法是：根据当前处理的任务，把最相关的规则换进来，把不相关的旧规则驱逐出去，本质上就是一个 LRU 缓存。结果他们很快就发现，这个方案的成本高得离谱。所以这个问题比单纯做一个 LRU 缓存要复杂得多、微妙得多。预测机制的缓存能力让某些操作变得非常便宜，而另一些操作则极其昂贵。

选择可扩展的插件抽象

如果你有 5,000 个不同的仓库，每个仓库都想提供三四个 Skill 来解释如何在自己的那部分代码上工作，会发生什么？如果每个仓库都提供自己的 MCP 服务器呢？

MCP 这个协议本质上就是为你的系统 Prompt 增加更多的工具调用 schema。它是一个基于 JSON 的协议，从客户端角度看非常轻量，客户端可以说“我想添加额外的工具来处理这个东西”。它是传输无关的，对消费者来说有很多不错的属性，但对软件工程师来说不一定友好。

那什么时候它是正确的工具？如果你需要为任何客户端设计集成，它需要能和聊天机器人配合。服务端拥有认证权，这是一个很大的可移植性优势，但代价是你得让这套东西在任何环境下都能工作。而事实是，你是在你公司的开发环境中编程。如果你已经有一个命令行界面，那么创建一个解释如何使用该 CLI 的 Skill，可能比搞一个 MCP 服务器要好得多。

那么，它能扩展吗？如果你在 Monorepo 里有一千个 MCP 服务器，你试图把它们全部加载进上下文，会发生什么？每个工具都有名称、描述和 schema，这些都要放在系统 Prompt 里，模型才知道怎么用它。如果你有 20 个 MCP 服务器，每个有 15 个工具，那你的上下文窗口大部分都被工具描述占满了，留给实际工作的空间就非常少了。所以，它没法在没有帮助的情况下扩展。

我们最近在做的一个东西叫做工具搜索，它先加载所有工具的名称。这样它仍然不能完全扩展，因为如果你有一百万个工具，你照样会把整个上下文用光，但它比“名称加描述加 schema”的方式要好一些。我们先把名称给 Claude，然后给 Claude 一个搜索工具的工具，就像套娃。但问题是，这里没有太多免费的午餐。你给工具起的名字越有描述性，或者你在名称里包含一部分描述，Claude 就越有可能记得去搜索这个工具。如果你给的工具名很随意，比如就叫“query”，那 Claude 很少会在正确的时机去搜它。所以如果你用 Claude Code，你应该认真考虑给它接入多少 MCP 服务器，因为这会稀释它找到所需工具的能力。工具搜索能稍微扩展一点，但效果并不算好。

Skill 其实就是文件夹，里面放一个 markdown 文件。核心思想是，Skill 是一种惰性系统 Prompt。它有一堆指令，还有对这些指令的某种摘要，模型可以用这个摘要来决定何时展开系统 Prompt 的这一部分。这种机制在软件工程里其实一直都有，你先有一个小的东西，然后在需要的时候把它变成大的东西，这是扩展的老套路了。你还可以在 Skill 文件夹里放其他资源，Claude 知道怎么去访问它们。我觉得很多人对 Skill 产生共鸣的原因是它的形式极其简单，就是一个文件夹，没有特殊的协议。skill.md 文件里有 front matter 字段，比如 description，你放一段简短的描述告诉模型要不要展开完整的 Prompt。

那它能扩展吗？整个正文是按使用付费的，你不用就不花钱。在小规模代码库比如 50 万行代码下，正文是按次付费的。但描述是始终加载的，描述永远在系统 Prompt 里。如果你有十万个 Skill，把十万个描述都塞进系统 Prompt，你的上下文窗口照样会被用光。所以它还是没法完全扩展到谷歌或 Facebook 那种大型企业的代码库规模。这正是最有趣的问题：我们怎么让这些东西真正去做软件工程？它们必须能这样扩展。

Skill 目前也还没有层级结构的能力，跟工具搜索面临的是同一个问题。工具搜索有一条描述，你把它写得越长，触发效果就越好。那问题来了：我们需不需要一个 Skill 搜索工具？我们正在做。这比工具搜索要难一些，因为它要求模型知道自己不知道什么，而工具搜索只需要模型知道自己做不到什么。意识到自己做不到某件事，比意识到自己不知道某件事要容易得多。

子 Agent 和 Skill 其实挺像的：你给它一段简短的描述，这段描述会被放进系统 Prompt 里。区别在于，Skill 是让 Claude 把那段描述直接展开到自己的上下文窗口里；而子 Agent 是把描述展开到一个独立的上下文窗口里，单独跑一个子任务，然后只返回一个它所做事情的摘要。所以从这个意义上说，它的扩展性其实更好。但放到一个大型 Monorepo 里，如果你有成百上千个、甚至上万个这样的子 Agent，你就会开始把上下文窗口的很大一部分浪费在这些描述字符串上。不过，理解这两者区别的关键点在于：Skill 是上下文内的，子 Agent 是上下文外的。

钩子（Hooks）是我在聊到这些抽象时最喜欢的一个，因为它是真的能扩展的。我认为我们大体上应该构建的抽象，是那种除非你以某种方式判定它相关，否则完全不往上下文窗口里塞任何东西的抽象。钩子是：当某个特定事件发生时，比如一次工具调用、用户提交了一个 Prompt、模型因为某种原因停止工作、或者整个上下文发生了压缩，你都可以运行一个特定的脚本。对于这个脚本的输入长什么样、你必须交付什么样的输出，是有一套协议的。根据你交付输出的方式，我们会决定是否往上下文窗口里放一些内容。

但你要理解钩子怎么扩展，如果你在做一个 Rust 项目，你有 10 个 JavaScript 相关的 Skill，你仍然要为那 10 条跟 JavaScript 相关的短 Prompt 付费，尽管你做的活儿跟它一点关系都没有，而且你还得记得手动把它们关掉才能不用。反过来，如果你有 10 个用于 lint JavaScript 代码的 Skill，而你在一个 Rust 代码库上工作，你不会为它们付费，你会为运行那个脚本付费，但那个脚本立刻发现你没在写 JavaScript，然后就退出了。除了 CPU 资源之外，你不会为任何你用不到的东西付费，而 CPU 资源，比上下文空间要宽裕得多。

钩子在上下文窗口之外运行的，你可以把它们写成脚本，也可以把一个 Agent 塞进去。但大概要谨慎使用，因为你会非常快地烧掉大量 token。钩子只在触发的时候、匹配的时候才注入内容。我们现在的模式是：调用脚本，立刻判断它是否相关，如果不相关就快速退出，否则就做一些处理，看看有没有什么相关的东西可以告诉模型。这就是之前聊到的红色波浪线所在的地方。

那有哪些抽象是我认为不适合作为插件的一部分的？我最喜欢拿来说的是 CLAUDE.md。有太多人问我：“为什么插件没有 CLAUDE.md 这种抽象？”因为它在“不为没用到的功能付费”这件事上是最糟糕的，因为如果我们提供一个允许插件在每个上下文的最开始无条件注入大量文本的抽象，那我们就会被限制在同时只能激活五到十个插件。而这最大的问题在于，它看起来并不贵，如果你在写你的插件，你做的第一件事可能就是创建一个 CLAUDE.md 文件来解释这个插件是什么。它在实现端的成本太低了，但在使用端的成本却太高了，所以你仍然可以这样做：设置一个会话开始的钩子，在每个会话一开始就注入一大堆 token 到上下文里。至少那样做会让你清楚地意识到，你正在做的事情，无论对谁来说，都在消耗大量成本。

记忆（Memory）在我所谓的插件边界上划出了一条不同的线。记忆是模型策展的，它全是文本文件。你只是告诉模型写一个文本文件，然后在之后的某个特定时间点读那个文件，但因为它是模型策展的，我不认为它是一个上下文工程的基元。我们真正想关注的是，可持续、可复用的上下文工程的基元是什么，我想把那个和我们所谓的插件区分开来。所以即使它们长得像 Skill，即使它们会被更新、包含和 Skill 相同类型的知识，超大规模软件工程的未来，将不得不在“上下文工程”和“记忆”的东西之间做出非常明确的区分，这两样东西需要非常独立地运作。

多 Agent 工作流

要扩展规模、要提速的唯一方式，就是同时做多件事。如果你能舒服地同时管理 20 个 Claude，你能完成的工作量差不多是管理 5 个时的 4 倍。2026 年的大量工作，就是找出合适的抽象，给开发者提供快速切换上下文所需的认知空间。

Git worktrees 是起步最简单的方式。把每个会话放到不同的 worktree 上，这样各个 Claude 就不会互相踩脚。谁用过 /color 这个功能？它超级容易，只要给它标注正在做什么，给它一个颜色。当你切换到那个窗口时，你的大脑会看到那个颜色，会触发你对那边在干什么的记忆。有研究表明，非色盲的人类，回忆与颜色相关的事物，比回忆与文字相关的事物更快。

我实际的设置是这样的，我确实运行着这些长期存活的 Agent。这张图有点过时了，因为我觉得只有 16 个常驻 worktree 已经不够我高效运转了。所以现在这个一直排到了 Z，而不是 A 到 F，但每一个都是独立的，并且有一个 Agent 知道自己的职责就是长期维护那个 worktree。

对于在大组织里当过 tech lead 的人，拥有持续身份标识的 Agent 真的很有帮助。一个有着固定名字和固定记忆的 Agent，它在自己的 worktree 分支里管理自己的临时文件，这让人能更好地组织工作。

图示上大概就是这样：我有长期存活的 worktree，名字对应着 Agent 的名字。它们都跟踪上游 main 分支，并且知道自己要负责管理对上游 main 的跟踪。所以它们不会互相踩脚，它们就像是独立的开发者在各干各的。

Agent 团队，就是给模型提供与其他 Agent 对话的途径。如果你同时运行两个 Claude，你告诉其中一个某件事，你可以让它把这件事转告给另一个，Send message 工具是最基础的原始能力，它让 Claude 能够从一个会话向另一个会话发送消息。你可以有一个团队领导，把任务委派给团队成员。你也可以让一堆 Agent 互为平级，如果其中一个发现了什么，你可以让它分享给其他 Agent，这一切都掌控在你手中。

如果你以某种方式登录并给予权限，那么你在任何一台机器上的任何会话，都可以与你在任何其他机器上的任何会话对话。这样一来，你就能直接告诉模型去和其他实例交流。这又是一个“把 Claude 能访问的东西扩展到你所拥有的一切”的例子，因为它需要能看到你能看到的东西。如果另一个 Agent 是你能看到的东西之一，那你就应该让它也能访问那个 Agent，

/loop 是我们大概两个月前发布的功能。它本质上就是一个 cron 命令，一个给模型用的定时工具，可以让模型安排一条消息每隔 10 分钟自动出现一次。它还能在某个时间点自行关闭，比如它会说：“我已经每 10 分钟看一次这个，看了 3 天了，我现在就把它关掉。”当然这会消耗一些 token，但相比人类得亲自去检查 CI，然后复制粘贴、再把任务重新启动起来，这点消耗简直微不足道。我经常发现，问题在于模型在完成任务之前就“睡着”了，而 /loop 真的能解决这个问题。它给了 Claude 工具，确保自己不会在任务完成前就停下来。而且我们看到，模型越来越擅长理解这样一个事实：如果某个结果会在 3 小时后才产生，那它就应该设置一个机制，让自己在 3 小时后被唤醒。

自动模式，这是实现多 Claude 协作的关键，也是你能同时跑 20 到 30 个 Agent 的方式，你不需要整天坐在那里按回车键。它比 YOLO 模式更好，我们有一套复杂的安全保障机制，会经过多轮模型和分类器的筛查，在阻止或放行之前检查某个操作是否危险。它会检查你所有的 Prompt，看你是否真的指示它去做某件事。如果你没有明确指示它去做某件看起来危险的事，它就会阻止。正是这个机制让 /loop、Agent 团队和过夜运行真正变得可行。不过它有点贵，根据模型不同，成本会增加 10% 到 40%。

2025 年是把信息输入模型以获得更好的结果，因为 Agent 编程还处于萌芽期，我们一直在不断补偿模型犯下的错误。2026 年，我相信会转向把信息从模型传递给用户。用户给模型的信息质量会随着模型变强而变得越来越不重要，不再是瓶颈。今年，更多的问题在于你能多快地切换上下文，你能多快地扩展你的工作流，以获取关于模型正在做什么的信息。Claude 是这样说的：你的注意力是系统中最小的盒子。

Claude Agents 就是我们在这一方向上推出的产品之一，它也叫 Fleet View。负责这个功能的团队成员，用它在一周内合并了大概一千个 PR。这是一种显著扩展你注意力的方式，因为它把所有正在运行的东西都显示在一个地方。我们有一些轻量级的分类器模型，给出模型需要什么、刚刚完成了什么的简短描述。10 个不同的 Claude Code 会话，全部显示在一个视图里。你可以直接从那里跳进任意一个会话，再也不用开 20 个标签页了。

远程控制，这是另一个我一直在用的、非常棒的东西。我在云服务器上运行着一些持久化的 Agent，我可以在手机和 Claude Code 桌面版上与它们交互。我写这次演讲的其中一部分内容，就是一边从酒店走过来，一边通过手机与 Agent 交互完成的，那个 Agent 跑在我的开发机上。

最后，重申三件事：1、给模型访问权限。2、思考那个盒子，思考你往盒子里放了什么，以及这会如何影响你从盒子里得到什么。3、选择那些能够扩展到大规模、真实世界软件工程的抽象。

演讲原视频链接：

https://www.youtube.com/watch?v=shZgedW15vg

声明：本文为InfoQ 整理，不代表平台观点，也不构成投资建议，未经许可禁止转载。

会议推荐

2026 年 AICon 人工智能开发与应用大会 · 深圳站（https://aicon.infoq.cn/2026/shenzhen/track）将于8 月 21 日—22 日举办，聚焦 AI 基础设施、大模型系统、智能体工程、数据智能、多模态技术与行业落地等关键方向，邀请来自腾讯、阿里、华为、百度、蚂蚁集团等 50 + 头部科技企业技术负责人、科研机构一线专家，系统性分享前沿洞察与实战干货，共同探讨 AI 技术从能力到系统、从实验到生产的真实路径。更多详情可扫码或联系票务经理 13269078023 进行咨询。