从工具调用到代码生成：AI Agent范式转变与工程实践

1. 被工具调用框住的那两年我到底在做什么2023年那会儿我接的第一个Agent项目是给一家做工业质检的团队搭一套自动巡检流程。需求听起来很朴素让模型读日志、判断异常、调接口触发告警。我当时的第一反应就是——这不就是LLM Function Calling吗把工具描述写成JSON Schema塞进system prompt模型输出一个tool_call我解析出来执行把结果再喂回去循环几轮完事。那套东西我写了大概两周跑通了demo演示的时候效果还不错。但接下来半年我几乎所有的Agent项目都长一个样一个ReAct循环一堆工具定义一个while循环判断要不要继续。客户提新需求我的第一反应永远是这个能不能做成一个工具让模型调。做不出来我就觉得是模型能力不够或者工具描述写得不够清楚。直到有一次一个做服装检测的客户问我你们的AI能不能自己决定今天用哪套检测标准我愣了半天。因为在我的范式里标准是写死在代码里的模型只能调用我预设好的东西它没有权力去决定什么。那一刻我才意识到Agent这个词被我理解窄了。我把它当成了一种技术架构而不是一种设计思路。工具调用只是Agent的一种表现形式甚至可能是最受限的那一种。这篇东西不是教程也不是框架对比。我想聊的是当我们说Agent范式的时候我们到底被什么限制住了以及我这两年踩过的坑、换过的思路哪些是真的有用。2. 工具调用不是Agent的全部它只是最容易被实现的那部分2.1 为什么大家一上来就做Function Calling先说个现象。你去搜AI Agent怎么搭十篇里有八篇在讲怎么定义tools、怎么解析tool_call、怎么用LangGraph或者扣子搭一个能查天气的助手。这不是偶然。Function Calling是OpenAI在2023年6月正式推出来的能力它把模型输出结构化指令这件事标准化了。在此之前你要让模型稳定输出一个JSON得靠prompt engineering反复调还得写正则兜底。Function Calling出来之后这件事变得极其简单你给模型一个工具列表它要么回文本要么回一个结构化的调用请求。开发者只需要处理这两种情况。从工程角度看这是巨大的进步。但从认知角度看它带来了一个副作用大家把Agent等同于会调工具的模型。我见过不少团队做Agent的第一件事就是列工具清单仿佛工具越多Agent越强。结果做出来的东西本质上是一个带自然语言入口的if-else。我自己的教训是2023年底做一个运维助手我给它定义了二十多个工具查CPU、查内存、查磁盘、重启服务、拉日志……结果模型经常在该查CPU还是该查内存之间反复横跳一轮对话调了七八次工具最后给出的结论还不如直接写个脚本。问题不在于模型笨而在于我把一个本该由代码逻辑决定的事情交给了模型去选择。2.2 工具调用的三个隐性天花板我后来总结了一下纯工具调用范式有三个绕不过去的限制。第一工具是离散的但现实是连续的。你定义了一个查询订单状态的工具但用户问的是我上周买的东西怎么还没到是不是因为下雨延误了。这个问题需要查订单、查物流、查天气还要做因果推断。你可以把这三个都做成工具但模型怎么知道要按这个顺序调它只能靠猜。而现实中的因果关系往往不是几个离散工具能覆盖的。第二工具的描述能力有限。一个工具的JSON Schema能描述参数类型、必填项、枚举值但它描述不了什么时候该用这个工具的微妙判断。你写当用户询问订单状态时使用但用户可能是在投诉、在咨询、在闲聊中顺带提了一句。模型只能靠语义相似度去猜猜错的概率不低。第三工具调用是单轮的。大部分实现里模型调一次工具拿到结果再决定下一步。但真实的决策往往是并行的、嵌套的、需要中途改变计划的。比如一个做数据分析的Agent它可能需要先抽样看看数据长什么样再决定用哪种统计方法而不是一开始就定好调A工具再调B工具。这三个限制不是模型能力问题是范式问题。你把Agent设计成模型在预设工具集里做选择那它的上限就是工具集的上限。2.3 一个反直觉的观察工具越少Agent越稳我后来做项目有个习惯能不用工具就不用工具。听起来很反直觉但实测下来工具数量从20个降到5个以内Agent的成功率反而上升。原因很简单。工具多了模型的注意力被分散它要在更多的选项里做判断出错概率自然上升。而且工具之间的边界往往模糊模型很容易选错。我做过一个对比测试同一个任务5个工具时成功率78%20个工具时掉到52%。这不是模型不行是我给它出了太多选择题。所以我现在设计Agent第一步不是列工具而是问这件事真的需要模型来决定吗如果答案是其实用代码判断就行那我就不做成工具。模型只负责它真正擅长的那部分——理解模糊意图、处理非结构化信息、在开放场景下做权衡。3. 跳出工具调用之后我试过的几种非典型Agent形态3.1 把Agent当成会写代码的同事而不是会调工具的助手这是我转变最大的一次。2024年初做一个数据处理项目需求是给一堆杂乱的Excel自动清洗、合并、生成报表。按老思路我得定义读取Excel去重合并生成图表一堆工具。但我试了另一条路让模型直接写Python代码我执行代码把结果返回给它。这个思路的核心区别在于工具调用是模型选一个我预设的动作代码生成是模型自己创造一个动作。前者受限于我的想象力后者受限于模型的编程能力。而现在的模型编程能力已经相当可观了。我当时的实现很简单给模型一个Python执行环境沙箱告诉它你可以写代码来解决这个问题执行结果会返回给你。然后它自己写了pandas的清洗逻辑自己处理了日期格式自己画了图。整个过程我只提供了数据和一个执行器没有定义任何工具。这个范式的好处是显而易见的我不需要预判所有可能的情况。用户的数据有奇怪的编码、有合并单元格、有隐藏列这些我事先想不到但模型在写代码的时候能根据实际报错去调整。这比我在工具里写一堆if-else要灵活得多。当然代价是安全性和可控性。代码执行需要沙箱需要限制网络访问和文件系统权限。但这是工程问题不是范式问题。3.2 让Agent规划而不是反应ReAct循环的本质是反应式的观察→思考→行动→观察。它没有全局规划走一步看一步。这在简单任务上没问题但复杂任务上容易迷路。我后来试了一种先规划再执行的结构让模型先输出一个完整的计划比如第一步做什么第二步做什么每步的预期结果是什么然后我再逐步执行每执行一步把结果反馈回去让模型决定是否调整计划。这个思路不是我的原创LangGraph里的plan-and-execute模式就是这个。但我想说的是规划和反应的区别不是技术区别是设计哲学的区别。反应式Agent把决策权完全交给模型每一步都重新判断规划式Agent让模型先想清楚再动手执行过程中只在必要时调整。实测下来规划式在步骤超过5步的任务上明显更稳。因为模型有了全局视角不会在第3步的时候忘了第1步的目标。但规划式也有问题如果第一步的实际结果和预期差很远整个计划可能就废了需要重新规划。所以我现在一般是混合用简单任务用反应式复杂任务先规划执行中允许局部重规划。3.3 多Agent协作不是越多越好是要有分工的边界多Agent是这两年被炒得很热的概念。我试过几种形态一个主Agent调度多个子Agent、多个Agent平级协作、Agent之间互相审查。踩过的坑是Agent数量一多通信成本就爆炸。你让三个Agent讨论一个问题它们会来回传递消息每一轮都要消耗token而且很容易陷入你说得对但我觉得这种无效循环。我后来总结出一个原则只有当子任务之间真的需要不同的上下文、不同的工具集、不同的角色设定时才拆多Agent。比如一个做代码审查的场景一个Agent负责读代码找问题一个Agent负责验证问题是否真实存在这两个角色的关注点完全不同拆开是有意义的。但如果只是一个Agent做前半段一个Agent做后半段那不如一个Agent串行做省得通信开销。还有一个细节多Agent之间的消息格式要严格定义。我见过太多项目Agent之间传的是自然语言结果下游Agent理解错了上游的意思整个流程跑偏。我现在会让Agent之间传结构化数据JSON只在需要解释的时候才用自然语言。4. 那些被忽略的工程细节才是Agent能不能落地的关键4.1 并发问题Agent不是无状态的函数热词里有个ai agent 怎么扛并发这个问题很实在。很多人把Agent当成一个API来设计以为请求进来、处理、返回就完事了。但Agent是有状态的它可能跑几十秒甚至几分钟中间要调多次模型、多次工具。我做过一个客服Agent高峰期同时有几百个会话。最初的实现是每个会话一个独立的Agent实例结果内存直接爆了。后来改成会话状态存在Redis里Agent本身是无状态的每次请求从Redis加载状态、处理、写回。这样虽然多了一次序列化开销但并发能力上了一个数量级。还有一个坑是模型调用的限流。Agent一次任务可能调十几次模型如果并发上来很容易触发API的rate limit。我的做法是在Agent和模型之间加一层队列控制并发数超出的请求排队。听起来简单但不做的话高峰期会大量失败。4.2 状态管理Agent的记忆到底该存什么Agent的状态管理是个容易被低估的问题。我见过两种极端一种是什么都不存每次请求都是全新的另一种是什么都存把每一轮对话、每一次工具调用结果都塞进上下文。前者的问题是Agent没有连续性用户说刚才那个订单它不知道是哪个。后者的问题是上下文爆炸token消耗巨大而且模型在超长上下文里容易迷失。我现在的做法是分层存储短期记忆当前任务的中间结果放在上下文里长期记忆用户偏好、历史交互摘要放在外部存储需要的时候检索回来。关键是摘要这一步——不是把原始对话存下来而是让模型定期把对话压缩成要点。这样既保留了关键信息又控制了上下文长度。4.3 错误处理Agent失败的时候怎么优雅地退场Agent一定会失败。模型会幻觉、工具会超时、外部API会挂。问题是失败之后怎么办。我早期的实现是出错就抛异常整个任务失败。用户体验很差因为跑了半天什么都没得到。后来改成分级降级如果模型调用失败重试如果工具调用失败把错误信息返回给模型让它决定是换工具还是放弃如果整个任务无法完成返回已完成的部分结果并说明哪一步卡住了。这个改动看起来小但用户满意度提升很明显。因为用户能知道做到哪一步了而不是面对一个冷冰冰的系统错误。一个经验Agent的错误信息不要直接抛给用户要让模型把它翻译成人话。比如HTTP 503翻译成订单服务暂时不可用我稍后再试。5. 从能跑到能用我踩过的三个认知坑5.1 坑一以为模型越强Agent就越好这是我最早犯的错。2023年的时候我总觉得Agent效果不好是因为模型不够强所以一有新模型就换GPT-4出来换GPT-4Claude出来换Claude。但换了一圈发现效果提升有限。后来我想明白了Agent的效果 模型能力 × 架构设计 × 工程实现。模型只是其中一个因子。如果你的架构是错的比如工具定义混乱工程是糙的比如没有错误处理那模型再强也救不回来。我做过一个对比同一个任务用GPT-4加糟糕的架构成功率60%用当时较弱的模型加精心设计的架构成功率75%。这个差距说明架构和工程的重要性不亚于模型本身。5.2 坑二以为Prompt写得越详细越好Prompt engineering是Agent开发里最玄学的部分。我早期写system prompt恨不得把所有的规则、示例、边界情况都写进去结果prompt长达几千字。效果呢模型经常忽略其中的某些部分或者被过多的规则搞晕。后来我学乖了prompt要分层。核心指令放最前面简短明确示例和边界情况放在后面用结构化的方式组织能写成代码规则的就不要写在prompt里。比如如果用户输入包含敏感词拒绝回答这种用代码过滤比写在prompt里可靠得多。还有一个技巧把prompt当成代码来管理。版本控制、A/B测试、回归测试一样都不能少。我现在的项目里prompt是存在配置文件里的每次修改都要跑一遍测试用例确保没有回归。5.3 坑三以为Agent能处理一切这是最危险的认知。我见过太多项目把Agent当成万能药什么需求都想用Agent解决。结果做出来的东西又慢又贵又不稳定还不如传统的规则引擎。我现在判断一个需求适不适合用Agent会问三个问题第一这个任务的输入是不是高度非结构化如果是结构化的用规则就行。第二这个任务的路径是不是不确定如果步骤是固定的用工作流就行。第三这个任务对错误的容忍度是不是较高如果是金融交易这种零容忍的场景Agent目前还不适合。三个问题都是是才考虑用Agent。否则老老实实用传统方法。6. 如果重新开始我会怎么设计一个Agent6.1 先画任务流程图再决定哪里放模型我现在做Agent项目第一步不是写代码是画流程图。把整个任务的步骤画出来标注每一步的输入、输出、判断条件。然后问哪一步是真正需要模型来判断的大部分任务里真正需要模型的只有一两步。比如一个合同审核Agent读取合同、提取条款、比对模板、生成报告这些步骤里只有提取条款和比对模板需要模型其他都可以用代码做。把模型放在关键位置而不是让模型驱动整个流程这样既稳定又省钱。6.2 给Agent设计退出条件而不是让它无限循环Agent最容易出的问题是死循环。模型调一个工具结果不对再调还不对再调……token烧完了任务也没完成。我的做法是给Agent设三个退出条件最大步数比如10步、最大token消耗比如5万token、最大时间比如60秒。任何一个触发就强制退出返回当前结果。同时在prompt里明确告诉模型如果连续两次尝试都失败就停止并报告问题。这个机制看起来简单但能避免大量的资源浪费。我见过一个项目因为没有退出条件一个失败的请求跑了20分钟烧了几十万token。6.3 把可观测性当成一等公民Agent是个黑盒模型在想什么、为什么做这个决定你很难知道。所以可观测性特别重要。我现在每个Agent都会记录每一轮的输入输出、模型的思考过程如果有、工具调用的参数和结果、每一步的耗时和token消耗。这些数据存在日志里出问题的时候可以回溯。更进一步我会做一个回放功能把一次失败的执行过程完整回放出来看看是哪一步出了问题。这个功能在调试的时候极其有用比看日志高效得多。7. 关于Agent范式我现在的几个判断第一个判断工具调用会长期存在但它不会是Agent的主流形态。就像汇编语言还存在但没人用它写业务系统一样。工具调用适合简单、确定的场景复杂场景需要更灵活的范式。第二个判断代码生成会成为Agent的核心能力之一。当模型能写代码、执行代码、根据结果调整代码的时候它的能力边界就从我预设的工具扩展到了任何可以用代码表达的操作。这个想象空间大得多。第三个判断Agent的竞争会从模型能力转向工程能力。模型大家都能用但怎么设计架构、怎么管理状态、怎么处理错误、怎么保证可观测性这些工程细节才是拉开差距的地方。第四个判断不要为了Agent而Agent。我见过太多项目明明用规则引擎就能解决非要上Agent结果又慢又贵。技术选型要看场景不是看热度。最后说个我自己的体会。做Agent这两年最大的收获不是学会了某个框架或者某个技巧而是学会了区分模型该做的事和代码该做的事。模型擅长处理模糊、开放、非结构化的问题代码擅长处理确定、重复、需要精确控制的问题。把这两者放在合适的位置Agent才能真正发挥作用。工具调用只是Agent的一种实现方式不是Agent的定义。当我们把Agent从会调工具的模型这个框里解放出来会发现能做的事情多得多。