在一场围绕 Claude Code 的技术演讲中，Anthropic 插件与 Agent 团队负责人 Daisy Hollman 给出的判断是：当 Agent 开始处理 Monorepo 级任务，真正稀缺的已经不只是模型能力，而是**如何把正确的信息、工具和反馈，在正确的时间送进系统**。
Agent 并不是突然出现的新物种。它的起点很朴素：模型生成一个工具调用，程序执行工具，把结果放回上下文，模型再根据结果决定下一步。工具调用次数从零次增加到多次，系统拥有了足够的自主性之后，人们才开始把它称为 Agent。
变化不在名字，而在任务时长。
人类输入一句话，模型输出一句话，控制权在两者之间反复切换。
文件编辑、Shell、编译、CI 等程序员日常工具被接入，模型可以根据前一步的结果继续发起下一步调用。
但窗口扩大速度没有跟上模型自主工作时长的增长，复杂任务开始争夺有限的上下文空间。
多 Agent、持久化 worktree、定时唤醒、远程控制和统一视图，开始解决人与 Agent 协作时的切换成本。
注：时间轴描述的是演讲中的技术演进框架，不代表每项能力都在同一时间点普遍可用。
对编码 Agent 来说，工具就是程序员能做的事：编辑文件、运行命令、执行测试、查看 CI。今天的工具调用仍然相当原始，但模型已经能稳定处理复杂的嵌套 JSON、精确字符串替换和连续工具链，这让更长时段的自主任务成为可能。
这场演讲的价值，不在于宣称“模型已经替代工程师”，而在于把 Agent 的能力拆到了工具 schema、上下文成本和反馈循环这些可以检查的工程细节上。
曾在 C++ 标准委员会工作近 10 年，担任主席约 2 年，目前负责 Anthropic 的插件与 Agent 团队设计。
需要提交文件名、旧字符串和新字符串；旧字符串必须逐字节匹配，重复匹配时还要提前声明，否则直接失败。
METR 图表显示，模型以 50% 成功率完成的任务时间跨度，过去约每 4 个月翻一倍。
演讲中提到，Mozilla 基金会在 4 月使用最新模型修复的安全漏洞和缺陷数量，超过此前 15 个月的总和。
不过，证据也有边界。任务时长趋势在 2026 年初开始出现停滞，Opus 4.7 和 4.8 没有被放进相关图表，因为“什么算作 16 小时任务”的误差已经太大。漏洞修复案例同样是组织经验，并非严格控制变量的对照实验。
注：上述数据与案例均按演讲内容整理；“能力跃升”可以作为工程信号，但不能直接等同于所有团队都会获得同等收益。
当 Agent 能够连续运行数小时，评价它的方式就不再是“回答得像不像”，而是能不能完成一条有依赖关系的任务链，并且在出错时及时得到反馈。
注：案例中的效率数字和产品体验来自演讲者描述，不能直接作为不同团队之间的生产力承诺。
上下文窗口容纳的不只是用户 Prompt。系统提示、工具定义、CLAUDE.md、Skills、已经读过的文件、工具执行结果，以及模型自己的历史输出，都会共同占据这个有限空间。前面放入的内容越多，留给后续实际工作的空间就越少。
所以，最重要的原则不是“尽可能多放”，而是“不为不用到的东西付费”。
每一项定制都在与“真正用于完成任务的空间”竞争。整个代码库不可能被天真地一次性塞入窗口。
还有 KV 缓存约束：如果前缀完全一致，后续计算会便宜很多；一旦每次工具调用都改变前面的内容，预测成本可能显著上升。演讲中提到，某些缓存失效场景的成本差距可以达到约 10 倍，这也是简单 LRU 式规则切换很快变贵的原因。
| 抽象 | 如何进入上下文 | 规模瓶颈 | 工程判断 |
|---|---|---|---|
| MCP | 把工具名称、描述和 schema 加入系统提示 | 工具越多，常驻描述越挤占工作空间 | 跨客户端集成有优势，但不适合无差别全量加载 |
| Skill | 先加载简短描述，需要时展开 Markdown 指令 | 正文可惰性加载，但所有描述仍需常驻 | 简单、可读，适合局部知识；超大规模仍会膨胀 |
| 子 Agent | 在独立上下文中执行任务，只返回摘要 | 大量子 Agent 的描述字符串仍会占空间 | 上下文外执行，扩展性优于直接展开 Skill |
| Hooks | 事件触发后运行脚本，匹配时才注入结果 | 脚本与 Agent 本身也可能消耗 CPU 或 token | 只为相关内容付费，是最接近可扩展的抽象 |
注：表格比较的是上下文注入机制，不是对不同产品或协议的整体排名。
这也解释了为什么“定制化就是知识”。团队约定、内部 API、两季度前失败的方案、代码库里的特殊词汇和刚刚发生的线上变化，都无法完整地依靠模型训练获得。工程师真正要做的，是把这些知识变成可检索、可触发、可验证的文本和工具。
一套真正可用的编程 Agent，至少要同时解决五个问题：能否看到工程师能看到的东西，能否避免无关信息常驻，能否尽早获得错误反馈，能否让人快速管理并行任务，以及成本和权限是否可控。
一个诚实的注脚：这套路线仍然没有解决所有问题。上下文窗口扩展落后于任务复杂度；Skill 和 MCP 在超大规模组织中都会遇到描述膨胀；Hooks 虽然节省上下文，却可能消耗额外计算和 token；自动模式的成本增加约为 10%–40%，权限错误也可能带来真实风险。
因此，所谓“上下文工程”不是给 Agent 配一份更长的系统提示，而是持续做取舍：哪些信息应该常驻，哪些信息只能按事件触发，哪些任务应该交给子 Agent，哪些操作必须保留人工确认。
编程 Agent 的下一轮竞争，不是把更多代码塞进模型，而是用最小上下文、最短反馈和可控协作，把工程师的注意力放大成一套可审计的生产系统。
原始内容没有提供公开体验地址，本文不硬凑链接。若你已经在使用 Claude Code、Codex 或 Cursor，可以先从一个真实仓库做四个小实验：
列出 Agent 当前看不到、但工程师每天必须看的系统和文档。
把团队规范拆成可按需展开的 Skill，而不是全部塞进常驻提示。
把类型检查、lint 和 CI 摘要接入工具执行后的反馈循环。
用 worktree 隔离并行任务，同时记录 token、耗时和人工介入次数。
先测“少花多少注意力”，再测“多写多少代码”。这两个指标并不等价。