Agent 工具调用一多就塞满上下文？Claude Code 改让脚本接手

让 Agent 连着查代码、跑测试、读日志、调 MCP，最容易卡住的往往不是某一次调用失败，而是每一步的原始结果都要回到模型面前。几十行文件列表、重复的测试输出、分页接口的中间页，堆起来以后，真正要做的判断反而被埋在里面。

Claude Code 的 v2.1.323 官方 Release 给了一个新的实验性选项：Code Mode。官方对它的描述很短——Claude 会写 JavaScript 来调用工具，且它需要主动开启。换个角度看，它把“模型每叫一次工具，就读回一次完整结果”的流程，变成了“模型先写一段小程序，让程序在工具之间做循环、筛选和汇总”。

这不是让 Agent 获得更多权限，也不是宣布每个复杂任务都应该自动化。官方 Release 没有承诺节省多少上下文、脚本在哪里运行、它如何改变每种权限提示。把这些未知部分补成结论，比暂时不开功能更危险。

图：传统逐次回流与先在工具侧筛选、再汇总回流的差别。图为本文原创示意，不是官方运行截图。

它解决的是“中间结果太多”，不是“工具不够多”

普通工具调用很适合需要即时判断的场景。Agent 读一份配置，看到一个值不对，再决定要不要改文件；或者跑一条命令，先确认输出没有碰到敏感目录。这里每一次停顿都很有价值，因为人和模型都应该看见发生了什么。

但也有另一类活：任务路径已经明确，中间结果只是机械材料。比如在一批目录中找符合规则的文件，再为每个文件读同一种字段；对多个测试结果抽出失败项；从几页工具返回中只留下某个项目的状态。让模型反复看完整原始结果，既占上下文，也会让它更容易在无关噪声里改主意。

Code Mode 的价值只在后者。可以把它理解成把 for、条件分支和结果整理交给一段临时程序，而不是把每轮循环都展开成一长串对话。最终回到模型的，理想状态应当是“哪些东西命中、哪些失败、下一步需要人判断什么”。

别把“少回传”理解成“少记录”。 中间结果不必全部进入模型上下文，不等于团队不该保留命令、参数、失败原因和最终汇总。对生产任务来说，能回看比能跑完更重要。

一个容易被忽略的成本在于：逐次调用并不只消耗 token。每个大结果回到对话后，模型都要重新判断“哪些内容是真的重要”。当任务里混着构建日志、依赖告警、测试快照和临时文件名时，它有时会把一次无关的差异，当成值得继续追的线索。脚本先按明确规则压缩材料，能让模型把注意力留给例外和选择。

不过，规则必须由人先写得足够窄。“找出所有失败的测试名称”是清楚的规则；“找出可能有问题的东西”就不是。后者把筛选标准交给模型临场发挥，即使最终只回传几行字，也未必更可靠。想试 Code Mode 的团队，先把准备交给脚本的动作写成一句能被同事复述的话；写不出来，就先不要把它从对话里搬走。

还有一个边界：Code Mode 是 Claude Code 的实验功能，不是一份关于 MCP、插件或权限策略的通用规范。不同工具的返回大小、失败方式、审批流程都不一样。本文的判断框架可以复用，具体开关、日志位置和权限表现仍要回到你正在使用的版本与官方文档核对。

先用一张判断表，决定要不要试

任务特征	先试 Code Mode	继续逐步调用
多个工具调用遵循相同规则	是，先让脚本做遍历、筛选、去重	—
每次结果都会改变下一步业务判断	—	是，保留每一步推理和确认
结果只是大段重复日志或列表	是，先提取失败项、计数和摘要	—
涉及删除、付款、权限修改、发布	—	是，逐动作确认并保留人工关口
团队还看不清工具调用记录	—	是，先补审计再谈批处理

表里的分界线不是“读操作安全、写操作危险”这么简单。一次读操作也可能把大量内部信息带回上下文；一次写操作也可能是被严格限定的临时文件。真正该看的，是脚本能否把工作缩成确定的机械步骤，以及团队能否在结束后说清它到底做过什么。

一个低风险的试用范围

官方把 Code Mode 标为实验性，最稳妥的做法不是全员打开，而是挑一个可回退、可比较的任务跑一周。我的建议是把试用任务限制在下面四条：

1. 输入来源固定，例如一个测试目录、一组只读 API 或一份脱敏的样例仓库。
2. 工具动作只包含读取、列举、过滤和生成摘要，不接删除、部署、授权或付费动作。
3. 结果有可对照的人工基线。比如同一批测试失败项，原先用普通工具调用能得到，Code Mode 也必须得到。
4. 把最终摘要、失败列表和执行时间留下来。没有这三样，团队只会记得“好像快一点”，无法判断它是否漏过关键结果。

试用时别只盯耗时。更有用的比较是：同一批输入下，普通流程和 Code Mode 流程得到的失败项是否一致；普通流程里的一个已知异常，汇总后还能不能追到原始工具结果；遇到空返回、超时或权限拒绝时，流程会不会明确停下来。前两项检查完整性，后一项检查失败是否可见。

如果你们已有运行记录，可以把一次试用写成一行很朴素的对照：输入数量、工具调用数、最终摘要、遗漏项、人工介入次数。它不需要漂亮的仪表盘，却能防止团队在几次顺利的演示后，把实验模式当成默认路径。等这张对照积累到几个真实任务，再决定是否扩大范围。

对于要交付给外部客户、会改动共享环境、或涉及凭据和敏感文件的任务，最好的第一步通常不是 Code Mode，而是先缩小工具权限和工作目录。工具编排能减少模型看到的噪声，却不能替代输入隔离、最小权限和人工复核。这三件事没准备好，任何“更顺的自动化”都只是更快地把问题推进下一步。

图：把输入、动作、输出和回退条件圈小，才适合把实验功能放进团队流程。图为本文原创示意。

这里有个很实际的退出条件：一旦脚本需要为异常情况自行扩展工具范围，或者最终摘要无法解释一个关键结论来自哪一步，就退回逐步调用。别让“少一些轮次”变成“少一条证据链”。

这个版本还有一条更适合团队的配套变化

同一版本为插件增加了 engines["claude-code"] 版本范围，并让 claude plugin validate 能检查 TypeScript hooks 的类型，--strict 可将警告变成失败。它和 Code Mode 放在一起看，信号很清楚：Agent 的可编排能力在变强，周边的兼容性和验证也得跟上。

如果团队维护插件、MCP 或自定义 hooks，可以先做两件小事：给关键插件写出明确的 Claude Code 版本范围；在更新 CLI 前把验证命令放进现有检查里。这样即使暂时不启用 Code Mode，也能减少“工具链升级后悄悄换了行为”的情况。

这类检查的价值不在于给每个插件多加一道仪式，而在于把升级风险从运行时提前到安装时。某个 hook 只在旧版本里恰好能跑，或者插件声明的能力与新版本不再匹配，越早被 validate --strict 拦住，越不会在一个长任务跑到中段时才变成难解释的空结果。Code Mode 要试，插件与 hooks 的版本边界也应一并写清。

更新前不用急着问“要不要开”，先问“这段活需不需要看见每一步”

Code Mode 最适合的，不是替 Agent 争取一次更长的自由发挥，而是替团队收走重复、确定、噪声很大的中间工作。要是任务的价值恰好在每一步的判断、授权和证据，那么慢一点、看得见一点，反而是正确的成本。

你现在的 Agent 工作流里，哪一段工具调用最像“重复搬运结果”，又最容易被原始输出淹没？

小岛AI｜记录一线实战、踩坑与成长