为什么“会调工具”不等于“会用工具”过去一年里我做过的 AI Agent 项目少说也有十几个。从最早给大模型套 Function Calling 外壳到最近两个月全面转向 Code Mode 架构中间踩过的坑、推翻过的设计足够写满一本血泪史。先说一个让我彻底转变观念的案例半年前做一个数据清洗 Agent需求很简单——用户上传 ExcelAgent 自动去重、补全缺失值、生成统计报表。第一版用工具调用实现我给模型注册了load_data、drop_duplicates、fill_missing、plot_chart四个函数。结果呢遇到稍微复杂一点的需求比如“把销售额大于 1000 的记录按地区汇总同时剔除近 30 天的异常值”模型就开始频繁地折腾参数有时连续调用七八次工具每次都做微小调整像是一个笨手笨脚的人在一堆按钮面前反复试错。后来我把同样的任务切换到 Code Mode——让模型直接生成 Pandas 脚本由执行器跑完后把结果和报错信息反馈给模型让它自己改代码。同样的需求模型通常只迭代两三次就能给出正确结果。这个对比让我意识到一个核心问题工具调用让模型充当了“调度员”而 Code Mode 让模型真正变成了“执行者”。两者对模型能力的利用率完全不在一个量级。这也是我想在这篇博文里展开聊透的话题——从工具调用到 Code ModeAI Agent 正在经历的这场范式转移背后的技术逻辑到底是什么工程落地时该怎么选型以及实践中那些文档里不会写的坑。1. 理解工具调用范式的本质与天花板1.1 工具调用的核心机制模型是调度员工具调用Tool Calling / Function Calling的本质是把模型当作一个“智能路由器”——它不负责具体干活只负责决定“该调用哪个工具、传入什么参数”。具体流程分三步第一步开发者预先定义一组函数每个函数包含名字、描述、参数 SchemaJSON Schema 格式第二步把这些函数清单随用户问题一起发给模型第三步模型在生成回复时如果判断需要调用某个工具就输出一个结构化的 JSON 对象包含函数名和参数然后由代码去实际执行这个函数把结果再喂回给模型。这种设计的好处很明显——可控性好、逻辑清晰、不会跑偏。比如你做一个天气查询 Agent注册一个get_weather(city, date)工具模型永远不会自己瞎编天气数据因为它在“查询”和“编造”之间被强行隔离了。但问题也随之而来模型的能力边界取决于工具的设计粒度。如果工具粒度太粗比如就一个execute_sql模型基本就是瞎猜如果粒度太细几十个单一功能函数模型光决策就要消耗大量 token而且还容易选错。我见过团队把一个内部数据平台做成 40 多个函数的工具集结果模型的工具选择准确率只有 60% 出头——不是模型蠢是决策空间太大了就像让你闭着眼在 40 个水龙头里找洗菜用的那一个。1.2 工具调用的工程复杂度拐点工具调用范式真正难受的地方是函数数量一多工程复杂度会以非线性方式暴涨。首先是参数 Schema 维护。每个工具的参数定义一旦变化所有依赖它的 Agent 都要跟着改。其次是上下文膨胀——所有工具描述都要塞进 Prompt40 个工具的描述加起来可能超过 3000 token这些 token 不是免费的它们挤占了模型有限的注意力。三是错误处理链条变长。工具返回异常怎么办重试策略是什么连续调用失败要不要切换方案这些逻辑如果写死在代码里Agent 就失去了灵活性如果交给模型决策又回到了“选择困难”的泥潭。我在一次电商客服 Agent 的实践中深有体会我们注册了订单查询、物流查询、退款申请、优惠券计算等 18 个工具。需求本身不复杂但模型时常在“查物流”和“查订单”之间犹豫——因为用户的问法漂移不定。最终我们不得不在工具描述里加了大量示例还给每个工具加了“适用场景”和“不适用场景”字段才把准确率拉到 85% 以上。但代价是 Prompt 越堆越长单次请求的 token 消耗翻了两倍多。这不是说工具调用没有价值——恰恰相反它是当前落地最稳的方案。我想说的是工具调用框架更适合“确定性任务 有限选项”的场景一旦任务开放、选项发散它的天花板就露出来了。1.3 确定性优势什么场景仍该继续用工具调用在这个阶段依然不可替代原因是它的另一个特性——可审计、可回滚、可容错。对金融、医疗这类强监管场景来说AI 不能“自由发挥”。模型只负责输出“调用哪个接口、传什么参数”真正执行的是经过测试的函数每步都有日志。这种“人在环上”的设计比让模型写代码然后执行要安全得多。我做过的合同审核 Agent 就是典型例子——给模型注册extract_clauses、check_compliance、flag_risk这类工具模型不会自己去改合同文件它只输出判断结果。这个场景如果用 Code Mode让模型直接操作文件我晚上根本睡不踏实。**所以范式转移不是新旧替代而是场景分化。**工具调用依然有它的主场只是它的“主战场”正在收缩。2. Code Mode 的兴起让模型真正动手干活2.1 Code Mode 是什么从“说”到“做”的质变Code Mode 的核心思想很简单不再让模型去“选择”一个预设动作而是让模型直接编写一段代码来完成目标。系统负责执行这段代码收集执行结果包括报错信息再反馈给模型进行下一步迭代。拿我最常用到的文件批处理场景举例工具调用范式下我需要注册list_files、read_file、write_file、rename_file、move_file等一系列函数然后期望模型能在这些函数之间做出正确的组合调用。Code Mode 范式下模型直接写一段 Pythonimport os import shutil # 批量重命名将当前目录下所有 .txt 文件按修改时间排序后加上序号前缀 files [f for f in os.listdir(.) if f.endswith(.txt)] files.sort(keyos.path.getmtime) for idx, f in enumerate(files, 1): new_name f{idx:03d}_{f} shutil.move(f, new_name) print(frenamed: {f} - {new_name})看到差别了吗工具调用时模型只能从“预设动作集合”里挑Code Mode 里模型可以针对具体问题写任意逻辑——循环、条件、正则、第三方库、临时文件处理全部自由组合。这相当于把模型从一个只会按按钮的机器人升级成了一个小型开发团队。2.2 Code Mode 为什么更省 token 和延迟很多人会直觉以为“让模型写代码”比“让模型做选择题”更费 token。其实恰恰相反。工具调用范式下每一个有歧义的任务都可能引发多轮工具往返。模型每轮输出一个函数调用 JSON代码执行后把结果塞回上下文模型再决定下一步。一个中等复杂度的任务动不动 5 到 10 轮往返每轮都在消耗上下文空间。Code Mode 下模型一次性生成一段完备的代码往往还自带注释和打印语句执行完后只看结果和报错再针对性地修复。以我实际测试的一份数据清洗任务为例——需要处理缺失值、去重、类型转换、异常值剔除、输出统计报告——工具调用范式平均需要 8 轮交互总耗时约 3 分钟Code Mode 通常 3 轮以内第一次写代码第二次跑结果最多第三次修 bug总耗时不到 1 分钟。原因在于代码是“压缩过的高级指令”。模型在输出代码时相当于一次把整个操作流程都表达完了不需要像工具调用那样一步一步地“挤牙膏”。更重要的是代码执行是沙箱内单进程完成的中间状态不需要通过上下文传递——变量、内存、临时文件都在执行环境里只有最终结果需要返回给模型。2.3 Code Interpreter 类产品对行业的影响真正让 Code Mode 被大众接受的关键产品是各类 Code Interpreter——最有代表性的是 OpenAI 的 ChatGPT 高级数据分析功能、Claude 的 Artifacts 中的代码执行能力以及开源社区里大量基于沙箱的 Agent 项目。这类产品改变了用户的交互方式用户不再期望 AI“直接给出答案”而是期望 AI“展示它是怎么算出来的”。我见过一个很有意思的现象——用户在让 ChatGPT 处理 Excel 数据时经常会主动说“你用 Python 算一下”这在工具调用时代是不可想象的。从工程角度看Code Interpreter 产品验证了几件事第一沙箱隔离是安全的可以放心让模型执行任意代码第二迭代式调试写代码→执行→看报错→改代码模型完全能胜任甚至比人类开发者更擅长处理报错第三代码执行获得的结果可以直接可视化比如生成图表、HTML 页面体验远胜过干巴巴的函数返回结果。也是从那时起我开始认真思考一个问题与其给 Agent 搭一套复杂的工具注册体系不如直接给 Agent 一个 Python 解释器让它用代码“无中生有”。3. 真实业务场景中的选型什么时候切换、怎么切换3.1 我的决策框架四象限判断法被问了太多次“到底该用工具调用还是 Code Mode”我根据自己的项目经验整理了一套决策框架本质是一个四象限判断——横轴是任务复杂度纵轴是环境约束强度低复杂度 强约束首选工具调用。典型场景是“查询类 权限控制”比如查库存、查订单、查客户信息。动作简单、边界清晰、必须走鉴权用函数调用最合适。高复杂度 强约束混合架构。比如你既要访问内部数据库又需要做复杂分析那就让工具负责数据访问带权限让代码负责分析计算。这正好也是我最常用的架构模式。低复杂度 弱约束工具调用和 Code Mode 都行但我个人更倾向工具调用因为可控性更好且输出稳定。高复杂度 弱约束这是 Code Mode 的主场。数据分析、文本处理、爬虫、文件批处理、报告生成、重放考试题……这种“开放目标、自由操作”的任务Code Mode 的效率碾压工具调用。我做的决策维度细化一下有三个核心指标动作空间大小——可能的操作组合是几十种还是无限种中间状态需求——任务执行过程中需不需要记住中间变量比如“把每行数据算完再汇总”这种反馈循环频率——需不需要根据中间结果调头比如“遍历文件遇到格式不对的跳过”如果三个指标都偏“高”那基本可以确定应该选 Code Mode。3.2 一个混合架构的实战配置工具管数据、代码管计算过去三个月我为自己日常的数据分析工作搭了一套混合架构 Agent主要处理各类 CSV 和 Excel 的分析报表任务。架构设计如下工具层只保留三个函数list_workspace_files()列出沙箱里有哪些文件、read_head(file_path, n5)预览前 n 行数据、read_schema(file_path)读取文件的列名和数据类型。代码层是一个沙箱 Python 执行器能跑任意模型生成的代码pip 预装了 pandas、numpy、matplotlib、openpyxl。工作流是模型先调工具“看一眼”文件结构和前几行数据然后写代码做完整处理执行后看输出和报错再迭代。这套配置让我彻底告别了“一个字段一个工具”的噩梦。以前我要注册compute_average、compute_sum、compute_median、filter_by_value……现在模型自己写df.groupby().agg()想怎么算就怎么算。一个关键设计点是工具管“读”、代码管“算”这样保证模型永远不会去改原始文件读工具只读同时给了它全权的计算自由度。折中了安全和灵活是我目前体验最好的架构。3.3 从工具调用平滑迁移的改造步骤如果你已经有了一套工具调用的 Agent 系统想迁移到 Code Mode不需要推倒重来。我总结的最小改造路径第一步盘点现有工具函数把“纯计算型”工具标记出来。判断标准这个工具是不是只是“输入参数→计算→返回结果”如果是那就是 Code Mode 可以替代的候选。第二步把“数据访问型”工具保留下来改成只读模式加上清晰的权限控制。不要让模型写代码去连数据库或访问敏感目录这部分的入口仍然保持工具形式。第三步搭建一个受限的代码执行沙箱。开源的方案有 Docker-based 的沙箱、Firecracker 微虚拟机、或者是云厂商的 Serverless 函数服务。选型标准是冷启动快、资源隔离好、能设 CPU/内存限额。第四步改 Prompt 策略。在 System Prompt 里告诉模型“你可以直接编写 Python 代码来完成任务代码将在沙箱环境中执行你会看到执行结果和错误信息请根据反馈迭代。涉及数据文件时先调用 file_list 和 file_preview 了解数据”。第五步加一个“代码质量护栏”。比如禁止os.remove、subprocess、网络请求除非白名单、文件写入范围限制到/workspace目录。这些是在编译或执行前做静态检查的硬规则。我迁移一个旧工具调用项目时大概花了两天时间完成这五步之后的效果是“需求响应能力”上了一个台阶——以前用户提一个超出工具设计预期的新需求我得先加函数再测试现在直接让模型写代码基本不用改系统。4. Code Mode 工程落地的关键技术细节4.1 沙箱架构选型从 docker exec 到微虚拟机Code Mode 对安全性的要求远高于工具调用——工具调用只是调度代码是实打实在跑所以沙箱是系统最关键的一环。我尝试过三种沙箱方案各自的取舍很清楚直接在宿主机跑 Python适合纯本地开发调试。但在生产环境完全不建议——一旦模型写出os.remove(/etc/passwd)或者import shutil; shutil.rmtree(/)祖先托梦都救不了你。而且还有资源竞争的问题一个 Agent 里的死循环可能拖垮整个服务。Docker 容器最常规的选择。每个会话启动一个容器挂载一个临时工作目录执行完销毁。我用过docker-py库在 Python 里管理容器生命周期稳定可靠。缺点是冷启动时间500ms 到 2 秒不等看镜像大小以及容器数量一多对宿主机的资源开销。Firecracker / Kata 微虚拟机这是生产级的方案每个会话一个微 VM安全隔离级别最高启动时间控制在 200ms 左右。但这个方案对运维要求高网络配置和存储管理都比较复杂适合团队落地不适合个人项目初期就上。我的建议是个人项目或 MVP 阶段用 Docker 就足够了重点是设置资源的硬限制——CPU 配额、内存上限、磁盘大小、无网络或白名单网络。这些配置都要提前做好别指望模型“自觉”。4.2 迭代闭环怎么设计拿到报错之后做什么Code Mode 的核心循环是模型写代码 → 执行器跑代码 → 采集输出和报错 → 反馈给模型 → 模型修代码。这个循环的反馈质量直接决定了 Agent 的成功率。我踩过一个大坑一开始只返回“退出码 stdout stderr”结果模型经常一头雾水——因为报错堆栈信息太长token 消耗大而 stdout 混杂了 print 的调试信息模型分不清哪些是关键的。后面我改成结构化反馈执行器返回四个字段{ exit_code: 1, error_type: NameError, error_message: name df is not defined, error_traceback: Traceback (most recent call last):\n File string, line 23, in module, stdout_tail: Loading data... 10000 rows loaded, stderr_tail: }关键改动是只返回 traceback 的最后几行前几百个字符只返回 stdout 的最后几百个字符。上下文里塞几千行日志对模型毫无帮助反而稀释了注意力。另外一个重要设计是——要主动截断陷入死循环的迭代。我设置最大迭代轮数是 5 轮超过之后会切换到“专家模式”不再让模型自己闷头修而是把代码、报错、上下文摘要交给另一个更强模型的实例让它做一次“复盘”输出修改方案。相当于给 Agent 找了一个“reviewer”。4.3 代码生成的 Prompt 技巧约束比自由更重要给模型说“你可以写代码”这种开放式指令的效果并不好。经验是代码生成的 Prompt 要把执行环境的约束写清楚这反而能显著提高代码一次通过率。我目前的 System Prompt 里会明确告诉模型几个环境事实工作目录有哪些文件、预装了哪些库、代码执行超时时间、禁止用哪些操作网络、删除文件、系统调用、文件保存路径约定。比如现在你在一个 Python 3.11 沙箱环境中工作。 - 当前工作目录: /workspace - 可用库: pandas, numpy, matplotlib, openpyxl, requests(仅限白名单域名) - 禁止: os.remove, shutil.rmtree, subprocess, socket - 图片请保存为 /workspace/output/chart.png - 执行结果请用 print 输出不要用 return - 如果代码执行报错你会看到报错信息请修复后重新生成完整代码这个 Prompt 里最容易被忽略的是最后两条——明确“用 print 输出而不是 return”和“修复后重新生成完整代码”。前者避免模型写一个函数定义但忘了调用太常见了后者避免模型只给一个“补充修改”建议而不是可直接执行的完整代码。我实测了不同约束强度下的“一次通过率”约束清晰的 Prompt 比开放式 Prompt 高 30 个百分点左右。原因是模型在生成代码时也需要“上下文安全感”环境细节越明确它编出来的代码越贴近实际可跑的形态。5. 常见问题与排查技巧实录5.1 模型反复报错修不好同一个 bug这是 Code Mode 里最让人崩溃的情况——同一个错误让模型修了 5 次它每次都“尝试”不同的改法但始终修不好。我的排查经验是问题大概率出在反馈信息给得不够。举个例子模型生成代码去读取 Excel报错xlrd.biffh.XLRDError: Excel xlsx file; not supported模型可能会尝试换xlrd的配置、转格式等绕来绕去。但如果反馈信息里明确告知“系统已预装 openpyxl建议用pd.read_excel(path, engineopenpyxl)”它一次就能改对。所以我在执行器里加了一个“hint”机制——针对高频错误预置一套“修复建议”。比如碰到ModuleNotFoundError就提示“请使用以下已安装库清单”碰到FileNotFoundError就提示“请先调用文件列表工具确认路径”。本质上是把你的人工经验固化到执行环境里了。5.2 沙箱里依赖缺失怎么办模型想用某个第三方库但环境里没有这是每个 Code Mode 实践者都会遇到的问题。我的处理策略不是开放 pip install——太危险了模型可能装一个恶意包或者把系统弄乱。我在执行器里做了一个“白名单 pip”机制模型可以在代码里写# pip: requests执行器会解析这个标记在白名单内检查该库是否允许安装、是否已缓存若允许则自动安装。白名单列表维护在配置文件里分门别类数据分析类pandas、scipy、statsmodels、可视化类plotly、seaborn和网络类仅限特定域名场景。既保住了灵活性又避免了随意安装的风险。5.3 一次跑了很久没输出怎么办模型生成了一段重度计算代码比如处理几百万行数据跑了一分多钟都没结束。用户已经在冒汗了。我做了两个机制来兜底第一是最长执行时间限制默认 60 秒到点强制杀死进程并返回超时错误第二是“中间进度反馈”——执行器会捕获代码里的print输出实时回流给前端展示用户看到“正在处理第 30 万行数据”这种进度提示耐心会好很多。另外还要提一个资源泄露的坑模型写代码时经常忘记释放资源比如 matplotlib 反复plt.figure()不plt.close()连续执行十几段代码后内存飙升。我在执行器里引入了进程级别的重启策略——每个会话的状态文件存在磁盘上但 Python 进程每跑完一段代码就销毁重建保证内存残留不跨任务堆积。5.4 安全防护不是模型想干坏事是它会失误最后聊一个最容易被忽视的问题。很多团队担心“模型故意做坏事”但实际运行中更常见的是模型在“非恶意”情况下做出危险操作。举个真实例子有一次模型需要清理临时文件写了个for f in os.listdir(/tmp): os.remove(f)——它本意是只删自己创建的临时文件但因为没限定目录前缀把其他进程的临时文件一起清掉了。这类失误型危险比恶意攻击常见的多。所以我强烈建议在代码执行前加一层静态扫描器主要检查危险调用模式文件删除类os.remove、unlink、rmtree必须限定在/workspace目录内网络类requests、urllib、socket必须匹配白名单域名系统类subprocess、os.system、eval、exec直接拦截除非特殊情况环境变量类os.environ的写入操作直接拦截这层扫描不用构建多复杂正则 白名单就够了。它不能防住所有恶意代码但能拦截 99% 的失误型危险操作。6. Token 消耗与成本优化6.1 代码模式的 Token 账单算清楚再上线很多想迁移到 Code Mode 的团队第一个顾虑是“模型生成代码是不是很贵”。这个话题需要算细账。我拿一个真实任务测试对比过任务是从一个 500MB 的 CSV 中做数据清洗并生成 5 张统计图表。工具调用模式单次任务消耗约 80 万 token包含多轮工具调用的上下文重复累积费用约 2 到 4 美元视模型定价Code Mode单次任务消耗约 15 万 token第一轮生成代码 1.5 万 token、执行结果 2000 token、第二轮修复 1 万 token、最终结果 2 千 token费用约 1 到 1.5 美元差距主要来自上下文重复——工具调用的每一轮都要把之前的完整对话历史塞回去随着轮数增加消耗是指数级增长的。但要注意Code Mode 省的是“过程 token”不省“代码 token”。模型生成一段 200 行的 Python 代码token 开销可不少。如果任务复杂度高到模型需要生成 500 行以上代码单次生成的 token 可能就达到 2 到 3 万这个成本必须提前评估。6.2 省 token 的几个实操技巧结合我自己的项目经验这几个技巧能实打实降低 Code Mode 的 token 消耗第一限制代码行数。在 System Prompt 里加一句“尽量用简洁的代码完成任务避免冗余操作”。模型真的会遵守。我实测加了这句话之后平均生成的代码行数下降了 20% 左右。第二反馈裁剪。上一节提到的“只返回报错尾部 stdout 尾部”非常关键。我见过一个项目把 2MB 的 stdout 全返回给模型那一次请求的 token 消耗直接爆表。裁剪到几百个字符效果完全够用。第三执行中间状态不回溯。工具调用模式中为了给模型足够的上下文你得把每次工具返回结果都留在对话里。Code Mode 中执行中间产生的大量变量和中间输出不需要保留只需要让模型知道“执行成功”即可。第四复用代码片段缓存。对于相似任务比如每周生成同样的业务报表我会把上次成功的代码存下来作为示例挂在 System Prompt 里。模型很擅长模仿示例做小幅修改这比每次都从零写要省得多。第五分流到便宜模型。Code Mode 的主循环中“首次生成代码”我用强模型比如 GPT-4o 级别“看报错改代码”这种简单迭代用便宜模型就够。因为“修复已知问题”的任务难度远低于“从零生成方案”小模型往往能胜任。7. 未来演进与我的应对策略7.1 Agent 能力的“接口”正在从 Function 变为 Filesystem和几个做 Agent 框架的朋友聊了一圈一个明显的趋势是下一代 Agent 的“感知接口”正在从函数Function变为文件系统Filesystem。为什么因为函数是“开发者为模型预设的抽象”而文件系统是“任务本身的自然形态”。当你给 Agent 一个目录让它自己读、自己写、自己组织文件结构时你其实给了它无限的表达空间。这就像给人类员工一个办公桌和一台电脑而不是给一张“只能按这八个按钮操作”的机器。我最近在做的一个研究性质的小项目就是让 Agent 在一个虚拟文件系统里“自由工作”——用户可以浏览 Agent 的“工作目录”看它写了哪些中间文件、生成了什么图表。这个体验比聊天窗口里的工具调用日志直观得多用户能真正感受到“Agent 在给我干活”而不是“Agent 在跟我对话”。7.2 端到端学习的潜流模型正在“内化”代码能力从模型侧的演进看代码生成能力正在成为 Agent 的默认底座。一个重要信号是新发布模型的代码能力评测分数一路攀升这不仅仅是“数学能力提升”的副产物——因为代码训练数据里包含了丰富的过程监督信号模型在生成代码时学会了“规划步骤、顺带自查”。也就是说代码能力不只是一个技能它成了模型“结构化思考”的载体。另一个潜流是“self-play”式训练——模型写代码、跑测试、看反馈、自我迭代这个循环本身就是强化学习的天然数据来源。我判断未来半年到一年代码执行类 Agent 的能力上限会有一波明显跃升因为训练数据不再是人工标注而是环境反馈自动生成。7.3 我目前坚持的技术判断与储备建议如果要说我对这个趋势的判断三句话第一工具调用不会消失但会“退居二线”——变成 Code Mode 的补充专门处理“必须走固定鉴权流程的操作”。第二Code Mode 会从“专门设计”变成“默认能力”——未来的 Agent 框架会把代码执行、文件系统、沙箱打包成“开箱即用”的标准运行时开发者不再需要自己拼装。第三“代码生成正确率”将成为衡量 Agent 质量的硬指标——就像今天的“工具调用准确率”一样。对于想提前布局的团队我的建议是做三件事一是给团队补 Python 规范知识因为要能审查模型生成的代码质量二是搭一套沙箱基础设施这是未来 Agent 能力拓展的地基三是建立“代码运行反馈”的数据积累习惯把每次 Agent 的失败案例和修复过程收集起来这是最有价值的训练数据。最后聊一点我个人在实际项目中摸爬滚打出来的体会吧。从工具调用转向 Code Mode 之后最大的感受不是“效果变好了”这个结果而是“开发心态”的转变——以前我是在给模型设计一条条轨道让它别跑偏现在我更像是在给模型搭建一个安全的工地然后在旁边看着它自己折腾。这个转变一开始让人心里没底但跑顺之后Agent 能做的事情范围确实大了不止一个量级。如果你现在正卡在工具调用的各种限制里我的建议是可以找一个边界清晰的任务比如让 Agent 做一份数据分析报告先试水 Code Mode感受一下从“选择题”到“解答题”的体验差异。有些东西真的只有跑过一遍才知道好在哪——以及坑在哪。