别再只跟 AI 聊天了，教它干活才是正经事

摘要大模型只会聊天那你可能用错了方式。函数调用让 AI 从说变成做能真正执行任务。本文分享我搭建 AI Agent 的实战经验包括工具设计、参数校验、错误处理等核心环节帮你避开那些我踩过的坑。开篇引入上个月我接到一个需求做一个能自动查天气、订会议室、发通知的助手。第一反应是用大模型 提示词搞定结果发现 AI 说得头头是道但啥也干不了。用户问明天北京下雨吗它一本正经地回答根据我的知识库北京春季多雨...——可今天是三月而且它根本没有实时数据。用户问帮我订个会议室它回复您可以联系行政部门预订——我要它能自己订不是给建议。后来我意识到问题所在光跟 AI 聊天没用得让它学会调用工具。这就是函数调用Function Calling的价值——把大模型从嘴炮王者变成实干派。这一周我折腾下来从最基础的单工具调用到多工具协作、错误恢复、安全控制踩了不少坑也积累了一些经验。今天把这些实战心得整理出来希望能帮你少走弯路。核心技术解析什么是函数调用简单说就是告诉大模型你有这些工具可以用需要的时候告诉我怎么调用。模型不会直接执行代码而是返回一个结构化的调用请求由你的代码来真正执行。这个设计很巧妙模型负责理解意图、决定用什么工具、参数是什么你的代码负责校验、执行、返回结果。两者分工明确既利用了模型的语义理解能力又保持了执行的可控性。举个例子我想让 AI 帮我查天气tools [{ type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称如北京、上海}, date: {type: string, description: 可选查询日期格式 YYYY-MM-DD} }, required: [city] } } }]用户问北京天气怎么样模型不会瞎编而是返回{ name: get_weather, arguments: {city: 北京} }然后你的代码调用天气 API把结果再喂给模型它才能给出准确回答。这个过程可能往返多次直到模型收集到足够信息给出最终答案。为什么需要这一层你可能会问为什么不直接让 AI 调用 API两个核心原因安全。模型可能产生幻觉参数可能有问题甚至可能被注入攻击。中间这层让你有机会校验、过滤、记录日志。想象一下如果模型直接调用数据库删除接口参数被篡改了怎么办可控。你可以决定哪些工具能用、什么时候用、用多少次。比如查询可以随便调但删除操作需要二次确认免费 API 可以 unlimited付费 API 要限流。这些业务逻辑模型不应该知道也不应该决定。还有一个容易被忽视的点可观测性。每次工具调用都有明确日志你能知道模型调了什么、参数是什么、结果如何。纯提示词方案是黑盒出了问题很难定位。实战案例案例一多工具协作实际项目中AI 往往需要连续调用多个工具。比如用户说帮我查下北京天气如果下雨就提醒我带伞顺便看看明天有没有会要开。这里涉及三个步骤查天气→判断是否下雨→决定是否发提醒→查日历。我的做法是让模型返回工具调用序列每次执行后把结果加回对话def run_agent(user_message, max_iterations5): messages [{role: user, content: user_message}] iteration 0 while iteration max_iterations: response client.chat.completions.create( modelgpt-4, messagesmessages, toolsall_tools ) message response.choices[0].message # 没有工具调用返回最终答案 ifnot message.tool_calls: return message.content # 执行所有工具调用 for tool_call in message.tool_calls: result execute_tool(tool_call.function.name, tool_call.function.arguments) # 把结果加回对话 messages.append({ role: tool, content: json.dumps(result), tool_call_id: tool_call.id }) iteration 1 return达到最大迭代次数未能完成任务关键点有几个每次工具执行后把结果作为 tool 消息加回对话让模型基于新信息决定下一步。这是多轮协作的基础。设置最大迭代次数防止模型陷入死循环。我一般设 5 次大部分任务 2-3 次就够了。并行调用优化。如果模型同时返回多个独立的工具调用比如查北京天气和上海天气可以并行执行减少总耗时。案例二参数校验与纠错模型返回的参数不一定靠谱。我遇到过几次典型问题日期格式不对明天vs2026-03-23城市名拼写错误Beijng、beijing必填参数缺失参数值超出合理范围比如会议室人数设为 -5我的处理流程分三层def validate_and_execute(tool_name, args): # 第一层参数格式校验 schema tool_schemas[tool_name] validation_errors validate_against_schema(args, schema) if validation_errors: return {error: f参数格式错误{validation_errors}} # 第二层业务规则校验 if tool_name book_meeting_room: ifnot is_within_business_hours(args[time]): return {error: 会议室预订时间必须在 9:00-18:00 之间} if args[capacity] 1: return {error: 人数必须大于 0} if tool_name delete_file: ifnot confirm_deletion(args[file_id]): return {error: 删除操作需要二次确认} # 第三层真正执行 try: result execute_tool(tool_name, args) return {success: True, data: result} except Exception as e: logger.error(f工具执行失败{tool_name}, {args}, {e}) return {error: f执行失败{str(e)}}经验错误信息要写得清楚让模型知道怎么改。别说参数错误要说时间格式应为 YYYY-MM-DD HH:MM且必须在 9:00-18:00 之间。模型拿到具体错误后通常能自己修正并重新调用。案例三错误恢复与降级工具调用可能失败API 超时、服务挂了、网络问题。我的策略是分级处理def execute_with_retry(tool_name, args, max_retries3): for attempt in range(max_retries): try: result execute_tool(tool_name, args) return result except TimeoutError: if attempt max_retries - 1: return {error: 服务超时请稍后重试} time.sleep(2 ** attempt) # 指数退避 except ServiceUnavailableError: # 服务不可用尝试降级方案 fallback_result try_fallback(tool_name, args) if fallback_result: return fallback_result return {error: 服务暂时不可用}降级方案举例天气 API 挂了可以返回缓存的最近数据日历服务挂了可以提示用户手动查看。关键是让用户体验到虽然不完美但还能用。技术对比函数调用 vs 提示词工程早期我试过纯提示词你是一个助手可以查天气、订会议室。用户问天气时你应该...。问题很明显维度纯提示词函数调用可靠性模型可能瞎编 API 调用结构化输出可校验安全性难以控制模型行为中间层可过滤和审计可调试黑盒难定位问题每次调用有明确日志复杂度提示词越来越长容易冲突工具定义清晰分离成本长提示词消耗更多 token工具定义一次性复用成本低结论简单问答可以用提示词但涉及实际执行的任务函数调用是必选项。我现在的做法是信息类问题直接回答任务类问题走函数调用流程。不同模型的函数调用能力我测试过几家主流模型差异挺大GPT-4最成熟支持并行调用错误处理完善。工具描述稍微写清楚点它就能理解。缺点是贵。Claude 3工具定义更灵活支持更复杂的参数结构。并行调用支持晚一些但最近也加上了。长上下文是优势适合复杂任务。国产模型通义、文心、Kimi 等进步很快价格友好。但在复杂场景下稳定性还有差距比如多轮工具调用时偶尔会忘记之前的结果。选型建议如果项目对稳定性要求高、预算充足优先选 GPT-4预算有限可以考虑国产模型但要做好降级方案和人工审核。注意事项1. 工具描述要写清楚模型靠工具描述理解什么时候用、怎么用。我见过最差的描述是查询信息最好的是查询指定城市当前天气返回温度摄氏度、湿度百分比、降水概率0-100、天气状况晴/雨/多云。原则假设模型完全不知道这个工具是干嘛的从头解释。包括什么场景下用、参数含义、返回值格式、可能的错误。2. 限制调用次数和频率防止模型陷入循环调用也防止 API 被刷爆。我一般设置max_iterations 5 # 单次任务最多连续调用 5 次工具 rate_limit 100 # 每分钟最多 100 次调用同时记录每次调用的成本超过预算就停止。3. 处理超时和失败工具调用可能超时、API 可能挂掉。我的做法设置合理超时时间查询类 10 秒执行类 30 秒失败时返回明确错误信息给模型记录日志便于排查包括时间、工具名、参数、错误关键操作支持重试但要有次数限制用指数退避4. 敏感操作要谨慎涉及删除、支付、发送消息等操作我通常会在工具描述里明确标注此操作不可逆或此操作将向用户发送消息要求模型在调用前确认用户意图可以在提示词里加规则或者在代码层增加二次确认流程比如删除前先返回确认删除吗让用户确认5. 日志和监控上线后一定要加日志和监控。我记录的内容包括每次工具调用的时间、名称、参数执行结果成功/失败、耗时用户反馈如果有这些数据能帮你发现哪些工具最常用、哪些经常失败、模型有没有滥用某个工具。我有一次发现查询用户信息被调用了上千次排查发现是模型在循环调用加了限制才解决。结尾函数调用是让大模型真正干活的关键技术。这一周折腾下来我的核心体会是别指望模型一次就做对设计好校验、重试、降级的流程比追求完美提示词更重要。工具设计要清晰错误处理要健壮日志监控要完善。这三点做好了你的 AI Agent 就能从 demo 变成真正可用的产品。如果你也在做 AI Agent 相关的项目欢迎交流。特别是那些文档里没写的坑咱们可以一起避一避。互动话题你在让 AI 调用工具时遇到过什么奇葩问题参数传错无限循环还是模型自作主张调了不该调的接口评论区聊聊我整理成下一篇避坑指南。