标记消耗从十五万掉到两千，响应速度立刻能感受到。

接下来我把这事儿拆开说清楚点。以前把一堆外部工具接进模型时，往往把这些工具的说明、接口一次性塞给模型读，结果就像把整栋楼的说明书放到你面前看。工具多了，上下文就撑爆了，模型得先读一堆接口说明才能动手，来回搬运中间结果，标记和延迟蹭蹭往上窜。把工具当成代码来用后，流程就变得利落——需要啥就拉啥，不需要的就留在服务器里，不往模型那儿搬运。

举个生活化的例子：让代理去把一个两小时的会议录音处理好，传统做法是把录音转文本、把全文丢给模型来摘要、再把摘要写回 CRM。模型要反复读整段文本，中间结果像接力赛跑一样被不断复制。改成代码执行后，代理在本地先把录音转成文字、做清洗、抽取要点，最后只把关键要点交给模型。这样一来，标记量从几万、十几万锐减到几千甚至几百，延迟和费用都掉不止一截，体验马上好起来。

技术实现上，核心是把 MCP（模型到外部工具的协议）当成代码 API 来看。不要把一大堆工具定义一次性塞进上下文，而是在服务器端把每个工具生成成文件树：每个工具一份文件，里面写 getDocument、updateRecord 这种具体接口。代理按需读取某个工具文件，看懂接口后就在执行环境里跑代码把事情做完。想象一下，目录里只有 google-drive、salesforce 两个文件夹，你只列出你要用的那几项，就能把不必要的说明屏蔽掉。这样做，标记消耗从十五万降到两千不是玄学，是流程优化带来的直观结果。

把工作往代码端搬还有别的好处。比如面对一万行的表格，你不会把整表塞给模型，而是在代码里先筛出关键字段、做聚合，交给模型的只有精华部分。复杂逻辑、循环判断、重试失败这些，也更适合用代码写，比让模型在对话里反复判断靠谱得多。还有安全性：中间结果留在本地，敏感信息先做脱敏或用占位符，真正的明文只在需要的系统间安全传输，模型根本看不到真实 PII，合规好做很多。

这事儿也不是完全没代价。要跑代理生成的代码，得建受控执行环境——沙箱、资源限制、监控、超时策略都要到位。要防止恶意代码跑飞了、要限制内存和 CPU、要记录日志，这些运维和工程投入不能省。权衡时，得把减少标记成本、提高稳定性带来的收益和搭建这些基础设施的成本一并算清楚。

一些细节上还能再省点开销。可以在服务器做个 search_tools 接口，代理发现工具时先只要名字和简短描述，必要时才去拉完整定义。文件系统式呈现贴合人类阅读习惯，按需读取远比把全家桶一次性塞进去经济。长时间坚持下来，代理写的实现可以保存成脚本或函数，说明写成 SKILL.md，慢慢就积累出一套可复用的技能库。新任务组合这些技能就像搭积木，速度自然上来。

社区里的发展也印证了这条路的可行性。自从 2024 年 11 月 MCP 出来以后，大家迅速扩展，已经有数千个 MCP 服务器，主流语言都有 SDK。正因如此，很多团队一上来就把大量工具接进来，结果遇到的痛点就是上下文撑爆、延迟和成本上涨。于是把代码执行引入代理，成了应对扩张带来问题的一个实际做法。Cloudflare 的相关研究把这种方式叫成“代码模式”，也认为让模型去写代码、由代码去操作，比直接把接口全喂给模型更高效。

再说几个实际操作的小技巧，方便落地。先把常见流程拆成小步：发现工具（只取名字）、读取接口（按需拉取）、在执行环境做数据清洗和聚合、把精简结果给模型、把最终操作交给目标工具。遇到跨多个数据源汇总时，先在代码里做连接和聚合，避免在模型上下文里拼接海量字符。对敏感字段，先在代码层面用占位符替换或令牌化，只有工具间必须的环节才解标记。出错重试、超时处理这些本来就是程序的拿手活，不用再让模型在对话里反复折腾。

长期来看，最大的变化是可复用性和确定性。把常用实现和说明存成库，后续遇到类似任务只要复用或稍作改造，就能迅速上线。代理不会每次都从零开始试错，稳定性和效率都会逐步上去。换句话说，越把可重复的工作搬到代码里，代理表现越像工程化的工具，而不是临时起意的“智囊团”。

整体上，把 MCP 和代码执行结合，不是把所有复杂度丢给模型，而是把能确定、能程序化的部分交给代码去做，把需要判断和生成的部分留给模型。这样既能控制成本，又能提高准确性。不过要记得，搭好这套体系需要工程投入，安全和监控不能偷懒。动手去做之前，先把常见场景列出来，模拟一下按需加载和本地处理流程，看看标记和延迟到底降多少，再决定是否全面铺开。