Claude Code 没有“魔法”

InfoQ 中文 2026-08-14T18:21:47.507907

Daisy Hollman，Claude Code 插件与 Agent 团队负责人，在 NDC Copenhagen 演讲中拆解了 Agent 背后真实的运作机制：从聊天机器人到自主工具调用循环，从“查找替换”式的原始编辑工具到上下文工程。本文第一部分梳理 Agent 的进化路径与核心设计思想——所谓“魔法”，不过是一连串原始工具调用的叠加。

过去一年，编程 Agent 的能力突飞猛进，软件工程师对它们的期望也水涨船高。然而，模型的上下文窗口（模型一次性能“看到”的文本量）却几乎原地踏步——一年前，100 万 token 已是最顶尖的水平，如今依旧如此。当 Agent 开始日常处理单体仓库（Monorepo）级别的任务，如何把更多信息塞进固定的上下文窗口，已经成了一项实打实的全职工程。

Daisy Hollman 是一位资深工程师，曾在 C++ 标准委员会深耕近十年，并担任过两年主席。如今她在 Anthropic 的 Claude Code 团队，负责插件与 Agent 团队的设计。在近期 NDC Copenhagen 的大会上，她围绕 Claude Code 插件的设计、背后的上下文工程原语，以及 Anthropic 内部的多 Agent 工作流，展开了一场演讲。本文基于演讲视频整理而成。

她的核心观点如下：

从聊天机器人到 Agent

大语言模型最初的应用形态是聊天机器人：人说一句，模型回一句，再人一句、模型一句，如此往复。

到了 2024 年，业界引入了工具调用（Tool Calling）：让模型主动请求计算机执行某个操作。一开始，模型只是执行一个操作、获取输出、根据结果做出决策，然后再把控制权交回人类。随后，它可用的工具越来越多，还能基于第一次调用的结果发起第二次、第三次调用。到某个节点，工具调用链足够长、自主性足够强，我们跨过了一条模糊的边界，于是有了新名字——Agent。

所谓 Agent，就是这么来的：从零次调用，到一次、几次，直到某一天它的自主性足以独当一面。

编码 Agent——或者说 Agent 化编程框架（Agentic Harness）——如 Claude Code、Codex、Cursor，本质上就是 Agent，只不过配给它们的工具和普通程序员日常用的是同一套：文件编辑、CI 工具、运行代码、编译代码，这些基本都能归入 shell 命令。换句话说，我们把“程序员能做的事”整体交给了 Agent。

Agent 的本质：一个工具调用循环

但说实话，工具调用的机制原始得令人吃惊。它的工作方式是：告诉模型可以输出 JSON；当它写出特定结构的 JSON 时，就有某个动作被触发；随后这个动作的结果被塞回模型的上下文窗口，紧跟在其原有内容之后。整套机制就这么简单。

模型在 bash 里跑命令时也是如此：它声明要使用的工具是 bash，附上命令；框架（Harness）负责执行，再把输出打包成一个工具结果块。Agent 编程框架里的一切都围绕这个循环展开：根据输出采取行动、生成新的工具调用、继续循环——这就是 Agent 的本质。

编辑工具：原始但足够好用

真正支撑编码 Agent 运转的主力工具是编辑工具。下面这个就是 Claude Code 里编辑工具的字面定义（Schema）。

顺带一提，Daisy 的演讲幻灯片全部出自 Claude Code 之手。她当时的需求是：“嘿，你能把你系统提示里的一个工具调用放到这里来吗？”于是模型给出了文件名、旧字符串和新字符串。说白了就是查找替换：没有光标，没有选区，没有引号转义，旧字符串必须逐字节精确匹配；如果它出现多次，要么模型提前声明预期有多个匹配，要么直接失败。

“这些工具真的很原始，”Daisy 说，“而且我认为这个领域还有巨大的迭代空间。”

模型的表现早已远超人工

既然幻灯片

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

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

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

四月份，Mozilla 基金会发布了一张图表，展示他们用我们最新模型修复的安全漏洞和缺陷数量，比过去 15 个月修复的总和还要多。注意，他们过去 15 个月不是没有 AI 工具，而是最新的 AI 工具和之前工具之间的差别。

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

为什么要定制化

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

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

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

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

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

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

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

模型权重在发布时就已固定，所有定制化都发生在文本层。对开发者来说，最快的提升不是换一个更聪明的模型，而是把早已熟悉的检查与反馈做成 Agent 的“红色波浪线”；与此同时，上下文窗口空间有限，学会挑选内容比盲目堆叠更重要——这正在成为软件工程的核心技能。

文本空间里，程序员有天然优势

模型能力的这种“现学现用”，在技术上有个专门说法，叫“语境学习”（In-context Learning）。说穿了，就是往输入文本里加信息。

大模型的权重在发布那一刻就冻结了，不会因为你用了一阵子就自动变聪明。尤其最近，外面的微调接口和微调 API 越来越少，想通过改权重来定制模型的路子收窄了。于是，你几乎所有的定制化工作，都只能发生在文本层面。

这其实是个对程序员很有利的事实：我们最擅长的就是控制文本。你不需要懂 LLM 权重的数学原理，不需要理解底层机制，只需要知道怎么组织输入。把不同的文本放进模型，就会得到不同的输出——虽然它不确定，但你可以通过精心设计输入来改善输出。

红色波浪线：Agent 也需要实时纠错

先看一个现状：Claude 目前的工具调用方式，大概相当于 Unix 的 ED 编辑器——也就是 VI 最底层的那点功能。如果你只能靠“查找替换”来完成所有编辑，那大概就是今天各类 Agentic 工具的真实水平。

还没有人真正搞清楚：Claude 的 IDE 应该长什么样？模型的实时反馈应该是什么样的？从 ED 或原始 VI 到 VS Code 之间的巨大鸿沟，就是机会所在。而这一切都发生在文本空间里，不是把信息写回权重，而是把更多反馈文本交给模型。

举个例子：Agent 的红色波浪线应该是什么？程序员靠 IDE 里的红色波浪线发现变量不存在、引用无效；可模型读取的是纯文本，看不到富文本，也没有输入过程中的实时反馈。所以我们必须自己动手补上这个机制。

Claude Code 里提供了一种能力，叫做 post tool use hook（工具调用后置钩子）。每次 Claude 执行完一个工具调用，我们可以在返回给它的工具结果里，附加一段你自己提供的信息。关键在于：怎么生成这些信息，你的代码库早就知道了——以前靠鼠标悬停查看红色波浪线的背后，那套检查逻辑已经存在，用脚本就能产出来。

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

两种工具：补短板与随智能扩展

工具大体可以分两类：一种用来弥补智能的不足，另一种是随着智能一起扩展。这一条对人和模型都成立。

你可以给初级工程师一些限制性工具，比如禁止编辑某些文件、禁止运行某些命令，防止出错。但当他们成长为高级工程师、你信任他们做更多事了，就得换一套新工具。可如果你做的是一种“轻推式提醒”工具，情况就不一样：高级工程师偶尔也会犯同样的错，而且他们知道什么时候那不是错误。这类工具可以跨越级别，一直有用。

所以，构建给 Agent 的工具时，别只想着“现在什么能帮到它”，也要想着两代之后、当它变得更强时，什么还能帮到它。

上下文窗口是一个盒子

上下文窗口，可以理解为模型在预测下一个 token（文本单元）时能看到的全部 token 集合。它是一个有限的、固定大小的“盒子”，也是你做定制化、放文本的唯一空间。

过去一年里，模型能力从“花哨的自动补全”进化到“长时间跨度的自主工作”，但上下文窗口的大小几乎没动。第一百万 token 级别的上下文窗口出现在 2024 年底；2025 年 2 月，最前沿的模型是 100 万 token；到了现在，最前沿模型依然是 100 万 token 左右。它的增长速度远远赶不上模型能力的膨胀。

这带来一个现实问题：随着任务越来越复杂，你在这个盒子里放什么、不放什么，必须变得越来越聪明。我们很早就发现，不能把整个代码库都扔进去。但文档、内部代码库、提醒这些内容，又不得不往里塞——于是“如何填好这个盒子”正在变成一门全职的工程学科。

我注意到不少“软件工程师”对“上下文工程师”这个头衔很抵触。但在我看来，这两件事其实是同一件事。随着 Agent 越来越能写软件、做真正的软件工程，“教它们怎么做”这件事，会成为软件工程的主要学科。其实这一直都是主要学科——只不过以前你得做到足够资深，全职工作才是确保更初级的工程师能做好他们的活儿。现在只是换成了 Agent，而且你需要把它做在每一个级别上。

盒子里放的，是所有对预测下一个 token 有贡献的东西：系统 Prompt、工具定义、CLAUDE.md、Skills、读过的文件、工具结果……问题在于，前面堆得越多，留给后面真正做任务的空间就越少。每一项定制都在和工作空间竞争，而你的整个代码库根本放不进去。你不能天真地把所有内容倒进盒子，那样效果远不如非常仔细地挑选与当前任务相关的上下文来得好。

关键要点

摘要：Claude Code 的每次调用都受制于 token 预算和缓存成本。MCP（模型上下文协议）插件足够通用，但会快速挤占上下文窗口；Skill 通过按需展开的方式大幅降低成本，却仍难以支撑超大型代码库。本文拆解这些插件抽象的取舍与扩展性瓶颈。

token 预算是第一约束

在资源受限的单片机上跑 npm，你会处处感到捉襟见肘。Claude Code 定制上下文时的情况与此类似——每一轮调用都必须为可用的 token 精打细算。

传统的依赖管理里，如果 npm 出现菱形依赖冲突，你可以同时引入两个不同版本来解决。但定制上下文做不到这一点：你面对的只有“相关信息”和“不太相关信息”的取舍，必须判断哪部分内容更相关、放进去，把不相关的内容挡在外面。原则只有一个——不为用不到的内容付费，也就是零开销原则，否则 token 很快就会被耗尽。

另一个约束来自 KV 缓存。现代 LLM 在预测下一个 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 那种大型企业的代码库规模。而最有趣的问题正是：我们怎么让这些东西真正去做软件工程？它们必须能这样扩展。

本文梳理 Claude Code 中各类上下文工程抽象（Skill、子 Agent、钩子、CLAUDE.md、记忆）的扩展性与成本取舍，并给出多 Agent 并行工作流的起步思路。核心结论是：真正可持续的抽象，应该按需注入上下文，而不是把内容无差别地塞给模型。

Skill 与子 Agent：上下文内外的选择

Skill 目前还没有层级结构，这跟工具搜索面临的是同一个问题。工具搜索靠一条描述来触发，描述写得越长，触发效果越好。于是问题来了：我们需不需要一个 Skill 搜索工具？答案是已经在做了。这件事比工具搜索更难——工具搜索只需要模型知道自己做不到什么，而 Skill 搜索要求模型知道自己不知道什么。后者显然更难实现。

子 Agent 和 Skill 在形式上很像：都是给一段简短描述，放进系统 Prompt。区别在于，Skill 是让 Claude 把这段描述直接展开到自己的上下文窗口里；子 Agent 则是把描述展开到一个独立的上下文窗口中，单独跑一个子任务，最后只返回一份摘要。从这个角度看，子 Agent 的扩展性更好。但在大型 Monorepo（单一代码仓库）里，如果存在成百上千个子 Agent，大量上下文空间就会被这些描述字符串白白占掉。理解两者差异的关键，就一句话：Skill 在上下文内运行，子 Agent 在上下文外运行。

钩子：真正可以扩展的抽象

在所有抽象里，我个人最喜欢的是钩子（Hooks），因为它是唯一真正能扩展的机制。

设计抽象的基本原则应该是：除非你以某种方式判定它相关，否则完全不往上下文窗口里塞任何东西。钩子正是这样做的。当特定事件发生——一次工具调用、用户提交 Prompt、模型因故停止、上下文发生压缩——你可以运行一个指定的脚本。脚本的输入和输出都有明确协议，系统会根据脚本返回的内容决定是否往上下文窗口里补充信息。

举个例子：你在做一个 Rust 项目，配置了 10 个 JavaScript 相关的 Skill，即使你的活儿和 JavaScript 毫无关系，你依然要为那 10 条描述支付上下文成本，还得手动逐个关闭。而如果用钩子，同样场景下，你为 10 个 lint JavaScript 的钩子脚本付费，但脚本启动后立刻发现你没在写 JavaScript，随即退出。你只为真正用到的逻辑付费（CPU 资源），而不是为用不到的上下文付费。CPU 资源可比上下文空间宽裕得多。

钩子在上下文窗口之外运行，可以写成脚本，也可以塞进一个 Agent，但通常要谨慎使用，否则 token 会烧得很快。它的工作模式是：触发 → 执行脚本 → 快速判断是否相关 → 不相关则退出，相关则处理并决定是否向模型汇报。这正是此前讨论过的“红色波浪线”能力的落点。

CLAUDE.md：实现便宜，使用昂贵

也有一些抽象我认为不适合成为插件的一部分，首当其冲的是 CLAUDE.md。很多人问我：为什么插件不做成 CLAUDE.md 那种形式？因为它在“不为没用到的功能付费”这件事上表现最差。如果允许插件在每个上下文的最开始无条件注入大量文本，那我们就只能同时激活五到十个插件，再多就崩了。

最麻烦的地方在于：它看起来不贵。写插件的人第一件事可能就是建一个 CLAUDE.md 来解释插件是什么，实现成本极低，但使用端要为此支付高昂的上下文成本。这种不对称容易让人掉进陷阱。如果你确实想这么干，可以用一个会话开始的钩子，在每个会话开头注入大量 token——但至少那样做会让你意识到，你在做的事情对谁来说都代价不菲。

记忆：另一条边界

记忆（Memory）在插件边界上划了一条不同的线。记忆是模型策展的文本文件：你告诉模型写一个文件，然后在某个特定时间点读回来。但正因为它是模型策展的，我不认为它属于上下文工程的基元。

我们真正关心的是：可持续、可复用的上下文工程基元到底是什么。我想把这套东西和所谓的“插件”区分开。即使记忆长得像 Skill，即使它会更新、包含与 Skill 同类型的知识——超大规模软件工程的未来，必须明确区分“上下文工程”和“记忆”这两条路线，因为它们需要各自独立运作。

多 Agent 工作流：并行才是提速之道

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

Git worktrees 是最简单的起步方式。把每个会话放进独立的 worktree，各 Claude 就不会互相踩脚。再搭配 /color 功能——给每个会话标注任务并分配一种颜色。当你切换窗口时，大脑先看到颜色，就能立刻唤起对那边工作的记忆。研究表明，非色盲人群回忆颜色关联事物的速度，比回忆文字关联事物更快。

查看原文