我最早写提示词的时候习惯性地把这件事理解成“把你的需求描述得更像人话”。真正把这个认知打破的是一次内部小工具的开发要让大语言模型根据一组运维数据自动判断什么时候需要扩容、什么时候可以缩容。模型输出了一堆听起来很有条理的结论但关键数字全是错的——不是它不聪明而是它从第一步就开始“凭印象算数”后面的推理链条自然跟着全歪。自那以后我开始认真研究提示词工程里讨论得最多、也最容易被做糙的一个分支使用工具的自动推理。这篇内容想分享的是我在实际开发中逐步摸出来的一套方法——怎么把大语言模型从一个“凭记忆作答的回答器”改造成一个“按步骤推理、按需调用外部工具、验证之后再交付”的任务执行者。内容适合正在做智能体Agent应用、构建自动化工作流的朋友也适合刚接触提示词工程、想少走弯路的新手。不需要你有深厚的前端或算法基础只要会写一点基础代码能看懂 JSON就可以跟着复现。1. 为什么“会聊天”的大语言模型做不了需要精确推理的实事1.1 表面智能与真实推理之间的差距很多人第一次接触大语言模型时的感受是它懂得真多。上知天文下知地理写总结、改文案、编代码样样都能搭上话。但一旦要它完成一个有精确数量关系的任务答错的方式往往让人印象很深。举个例子。你直接问模型“2.5TB 的数据在 450Mbps 带宽下持续传输需要多少秒”模型很可能会流畅地写出完整步骤然后在某个不起眼的转换里翻车把 TB 当成 Tb把字节和比特当成一个东西甚至把 Mbps 直接当 MB/s 用。单看文字每一步都顺理成章单看最终结果错得离谱。问题不在于模型不懂这些概念而在于它本质上是“根据数据分布预测下一个词”的系统没有外部状态也不会累计计算结果。它更像一个知识面很广、但算盘打得不好的人。这种表面智能和真实推理之间的差距是所有想拿大语言模型做实事的开发者迟早会撞上的墙。你今天让它写一段 SQL明天让它解释一段代码这些都还能应付。可一旦任务变成“多条件约束下的数值计算”“连续决策”“跨多个信息源汇总验证”模型的知识优势就发挥不出来甚至会起到反作用——它太会“顺着话说”了。1.2 上下文窗口是能力上限不是自由空间很多人有一个误解模型的上下文窗口越大它就越能“记住”中间过程推理就越准。实际上上下文窗口只是它能读取和引用的材料范围并不是无限可靠的工作记忆。当推理链路较长时前面推算出的中间值、后面新看到的条件、模型记忆里某些模糊的概念都会挤在同一段文本里互相干扰。我在调试这类问题的时候不止一次看到模型在第五步还在正确地引用“第 2 步的计算结果是 56.25 MB/s”到第七步突然又写了一遍“带宽为 450 MB/s”前后的说法直接矛盾。原因是模型生成文本时每一个 token 都在重新分配注意力中间变量如果没有被真正地“外置保存”就很容被后续内容冲淡。这正是外部工具的第一个价值把中间状态从模型的“内部记忆”挪到“外部可查询、可回填的事实”上。每算一步结果就是明确的一条记录下一步需要时模型可以直接引用这条记录而不必靠记忆硬扛。这也是为什么“使用工具的自动推理”不是优化项而是刚需。1.3 提示词工程在这里的真正位置明白了上述两节提示词工程的思路就得跟着转变。很多教程教你怎样把用户问题改得更清晰怎样用 COT链式思考让模型逐步解释这些当然有用但在一两个独立问题上有效不代表它能撑起“连续调用工具完成一个真实任务”的骨架。做工具化的自动推理时我们的提示词给模型的不是“一个难题的描述”而是一套“解决难题的流程”。模型在流程里扮演的也不是“万事通”而是“调度员”它要自己判断问题结构、拆解子目标、决定调用哪个工具、解读返回结果、继续规划下一步。提示词工程的功夫就从“遣词造句”变成了“流程设计 约束设计 边界设计”。也就是说你和模型之间约定的不再只是“答案应该长什么样”而是“在什么条件下你必须用哪个工具”“输出格式必须遵守什么规则”“什么情况下要停下来检查”。这些约定写得越清楚模型的自动推理就越稳定。下面我从核心机制开始一步步把这套体系展开。2. 自动推理的核心机制让模型“先想后做做完整理”2.1 ReAct 思路的本质Thought/Action/Observation 循环提起使用工具的自动推理绕不开一个经典的框架思路ReAct也就是 Reasoning 与 Acting 的结合。它的基本结构是让模型在一个循环里交替输出三类内容Thought我对当前问题的分析和判断Action我决定调用哪个工具、参数是什么Observation工具返回的结果被我作为下一步的输入。这个循环一直持续到模型确信自己拿到了最终答案再以 Final Answer 收尾。乍一看很朴素但它的价值极高模型不再是被要求“一步到位给出结论”而是被允许“一次只迈一步”。每迈出一步都能观察到真实的外部反馈再决定下一步怎么迈。你可以把这想象成一个蒙着眼走路的人突然被摘掉了眼罩每走一步都能看一眼路标而不是闭着眼睛一直到撞墙。工具所扮演的正是那个不断提供路标反馈的角色。在纯文本的问答中模型没有“检查自己算得对不对”的天然手段但在 ReAct 结构里任何一步的数值不靠谱模型都能在观察环节发现异常进而修正。2.2 工具结果回填把外部信息变成“上下文的新事实”循环能跑通的关键在于每个工具返回的结果都要被当成“新的一句话”追加进多轮对话上下文里。比如模型输出一个行动calculate: 56.25 * 21600程序在外部执行完这个计算返回1215000.0然后把这句 “Observation: 1215000.0” 传回给模型。从模型的角度看这就是一个刚刚被验证过的事实。后续的思考都会建立在这个数字之上而不是模型自己编的“大概是多少”。这一步看似简单却是很多自研 Agent 做不稳定的元凶要么忘了回填把工具调用结果丢掉了要么回填格式混乱模型不知道该把哪句话当成工具输出。稳定的做法是给观察结果一个固定的前缀标记比如Observation (tool_name): ...并在系统提示词里明确“Observation 的内容来自外部工具应被视为可信事实除非与数学或常识明显冲突。”这套机制也让“验证”变得特别容易。模型算出答案之后你可以再让它调用一次计算器“反代验证”把结果放回上下文里比对。这本质上是用外部工具构造了一条闭环的验证链路比让模型凭感觉检查自己的答案靠谱得多。2.3 函数调用接口与提示词模板的配合边界现在的主流大语言模型平台几乎都提供了函数调用Function Calling能力基础思路是开发者先声明一个工具清单模型在完成任务时返回一个结构化的调用请求程序执行后再把结果传给模型继续推理。这个机制让解析和调度都规整了不少但它解决不了所有提示词问题。我见过不少团队把函数调用的接口接上就以为万事大吉结果模型仍然在错误的地方调用错误的工具。问题往往出在工具描述写得过于模糊或者没给模型讲清楚“什么情况下不要调用工具”。要知道函数调用接口只是把“传输载体”标准化了真正决定模型“什么时候调用”“调用哪一个”“参数怎么填”的始终是提示词尤其是系统提示里的工具说明和少样本示例。所以我的建议是你可以把函数调用当成执行层但不要把它当成决策层。决策层依旧要回到提示词工程把调用工具的规则、优先级、禁忌都写清楚。下面这一章我就拿出一个可以直接修改的提示词模板带你看看一个“工具派”的系统提示词是怎么搭起来的。3. 从零开始写一份“工具派”提示词3.1 角色设定不是“万能的助手”而是“会调度的人”写系统提示词的第一步是重新定义模型的身份。大多数通用对话场景里我们会把模型设定成“乐于助人的助手”但在工具化自动推理场景里这个设定反而碍事。你应该把它定义成“任务调度员”并且明确一条原则凡是涉及数值计算、单位转换、外部查询的操作都必须通过工具完成不允许模型直接凭记忆给数字。我习惯在系统提示词里写类似这样的话你是严格的任务调度员。你的任务拆解能力很强但你自身不具备可靠的算术能力。任何数值计算、单位换算、外部数据查询都必须使用工具。如果你在没有调用工具的情况下直接输出计算结果视为错误行为。这句话看着有点“强硬”但它能把模型的行为迅速拉回正轨。原因是模型本身就是靠着文本统计规律来“猜”答案的你越强调“你自己算不了”它就越倾向于切到工具调用模式而不是陷入自信满满的瞎算状态。3.2 工具清单描述的三个关键字段工具清单不是一句话列表每一个工具都应该包含三个字段工具名称、参数说明、使用场景。有条件的话再加一个“禁止使用场景”。我常用的工具描述格式大概是这样的表格结构字段说明示例工具名称全局唯一的英文名建议用下划线连接unit_convert参数说明JSON 格式的参数定义每个参数都要写类型和含义{value: float, from_unit: str, to_unit: str}使用场景什么时候该用它解决哪一类问题带宽单位换算、数据量单位换算禁止场景什么时候一定不要用它不要用它做汇率换算、不要用它做利率计算“禁止场景”这条是我实际调试中加上的。模型有时候会把工具的能力外推明明是个单位换算工具它却拿去算百分比明明是个计算器它却拿去做文本拼接。把每个工具的能力边界划清楚误调用的概率会明显下降。3.3 强制结构化输出JSON 与单步调用约束为了让程序能够稳定解析模型的意图系统提示词里必须约定输出格式。我的做法是要求模型把每一步决策都输出成一段 JSON再配上一段自然语言说明。以调用计算器为例格式定义如下{ thought: 需要把带宽从 Mbps 换算成 MB/s再乘上传输时长, tool: unit_convert, arguments: { value: 450, from_unit: Mbps, to_unit: MB/s } }同时还要约定一次只允许调用一个工具等工具结果返回后再输出下一步。这条约束非常重要。很多模型在自由度较高的时候会一口气输出多个工具调用或者把思考过程夹杂在 JSON 里这些都容易让执行层的解析逻辑崩溃。把“单步调用”写进提示词可以理解为给模型套了一个防止跑飞的缰绳额外的开销只是多一点令牌但换来的是行为和结果的确定性。3.4 两三个少样本示例的价值远超调温度参数我在刚开始搭这类流程的时候特别喜欢折腾模型的温度参数总想着把温度调低是不是就更稳定。后来发现在工具调用场景里最有效的稳定手段不是调参数而是给模型两三个完全正确的“标准示范”。比如你可以在系统提示词里放一个完整的调用样例用户提问、模型思考、模型输出 JSON 调用工具、工具返回结果、模型再次思考、最终回答。这个样例把整个循环的流程固化给模型看。模型会照着这个模式复制而不是自由发挥出一套新的输出风格。少样本示例的数量不用多两三个覆盖典型场景的例子就够关键是必须“完整闭环”而不是只给一个零散的调用片段。4. 自动推理的几种常用框架怎么选才不后悔4.1 ReAct灵活但费令牌ReAct 是我们前面聊的最基础也最通用的一种模式思考一步调用一个工具观察结果再思考。它的优势是灵活、适用面广几乎不需要任务预分析模型可以边推理边修正遇到问题随时转向。缺点是每一步都要多轮往返产生的令牌开销不少而且如果任务本身结构清晰这种“走一步看一步”的方式显得不够高效。用 ReAct 做模型行为调试是我最推荐的入门路径逻辑简单追踪容易任何一步产生错误都能定位是在 Thought 阶段还是在工具调用阶段。适合任务复杂、步骤不确定、需要模型随机应变的场景。4.2 先规划后执行Plan-and-Execute 的取舍比 ReAct 更进一步的是“先规划后执行”Plan-and-Execute。模型先用一次较长的思考把整个任务拆成若干子步骤列出一个执行计划然后按计划逐个调用工具。这种方式更适合任务可以被提前分解清楚的场景比如“先查数据量、再算带宽、然后算窗口、最后汇总”。它的优势是结构清晰规划阶段就能发现任务里是否存在矛盾条件如果计划合理执行阶段会比较顺畅中途翻车概率低。缺点是一旦计划出错后续调整成本高模型可能需要推翻整份计划重来。实际操作中我会在提示词里要求模型先输出一段“计划确认”由我来判断是否让它继续执行。这样既保留规划能力又留出人工干预的窗口。4.3 带反思修正的三段式验证过的答案才交付对结果可靠性要求较高的场景我会在 ReAct 之上再加一个“反思修正”阶段。简单说就是模型得出候选答案之后不要直接输出而是额外做两次检查第一次是正向校核把计算步骤重新演算一遍第二次是反向验证拿“答案倒推条件”看是否和原题一致。这三段式推理执行、反思检查、修正交付能显著降低低级错误的逃逸率代价自然是更多令牌和延迟。如果你的应用对实时性敏感可以使用简化版只要求模型对最终答案做一个反向验证把验证过程写明即可。对于数据化、数值化的真实业务这个步骤我觉得值得付出。4.4 各模式的适用场景对比模式灵活性稳定性实时性令牌开销推荐场景ReAct高中中中步骤不确定、需要边干边调规划先行中高低高任务结构可提前拆解反思修正中高低高对结果精度要求严格单工具直呼低中高低一个问题恰好匹配一个工具需要说明的是这些模式并不互斥。实际系统里常把它们混合使用主流程用 ReAct遇到强校验节点就切到反思修正任务清晰时就先输出一个执行计划。根据任务复杂度弹性切换要比死守某一种“最佳做法”靠谱得多。5. 实际跑起来之后最常见的问题和我的处理办法5.1 模型反复调用同一个工具停不下来自动推理中最经典的翻车现场就是模型在一个工具上反复调用同一组参数或者陷入“调用工具-观察结果-再调用相同工具”的死循环。我见过最夸张的一次模型连续调了七次计算器每次都是同一个表达式像卡在了时间循环里。这个问题的根源有两个一是提示词里没有设置“退出条件”模型不知道什么时候算完二是早期我把 Final Answer 的产出条件写得太抽象它不敢结束。解决办法也直接在系统提示词里写明最大调用次数比如“同一个工具针对相同参数不得超过两次”并且要求模型在得到结果后必须给出 “Final Answer: …” 作为收尾。代码层也要做兜底执行循环达到上限后强制退出把已获得的观察结果拼成最终答案避免流程挂死。5.2 模型输出的 JSON 偶尔不合法解析直接崩模型有时候会输出多余的换行、注释、Markdown 代码块标记或者把 JSON 字段名称大小写写歪。一旦执行的解析器比较严格整个流程都会停滞。我后来在提示词里加了两句话“只输出原始 JSON不要用 Markdown 代码块包裹不要添加任何解释。”效果立竿见影但也不能只依赖提示。更稳的办法是在解析层写一个“容错提取器”先用正则把文本里最像 JSON 的片段抠出来再做解析解析失败时把错误信息和原始文本拼接起来作为一次新的上下文内容回传给模型请它重写一条合法 JSON。这套“解析失败→回传纠错→重新生成”的机制比单纯重试要高效得多模型往往看一遍自己的原始输出就能改对。5.3 工具返回了“看起来对实际不对”的结果模型却全盘接受这是比解析问题更隐蔽也更危险的坑工具本身可能出错或者工具用错了参数返回了一个看似合理的数字模型直接把它当成真理继续推理。比如一次让模型调用unit_convert把 Mbps 换成 MB/s结果它把参数填反了拿到一个离谱数值还继续一本正经往下算。要解决这类问题得从提示词和流程两个方向同时下手。提示词侧要求模型在拿到观察结果后做一次“合理性检查”只要结果与常规量级明显不符就必须停下来说明异常流程侧对关键工具可以加“白名单校验”比如unit_convert只允许合理的单位组合超出白名单直接返回错误信息从源头拦截错误参数。5.4 组合技Iteration 上限、白名单工具与日志全链路把上面几个问题归拢起来我在生产环境里的标配组合是三件套迭代上限模型最长循环次数防止横向拉满工具白名单只暴露任务真正需要的工具从源头减少误用全链路日志把每一轮的 Thought / Action / Observation 和解析结果全部记录下来。日志尤其容易被忽略。很多问题在单次跑通时看不见多轮运行、并发请求之后才显露。我会把每次工具调用的入参、出参、耗时、模型决策语句都打成一串结构化日志一旦出现异常直接按日志回放模型当时“是怎么想的、为什么会这么调用”。这套组合让我省掉了大量靠猜去调提示词的痛苦过程。6. 一个可复现的端到端案例数据迁移时间估算器6.1 任务设定与工具准备纸上谈兵聊了很多这一章用一个具体案例把全流程串起来演示。任务设定是这样的某团队需要把 2.5TB 的临时数据从旧存储迁移到新存储签约带宽为 450Mbps。迁移操作只能在每天凌晨 0 点到 6 点进行。网络实际利用率按 90% 计算每天晚上因为文件重试等问题有效传输量会在理论值基础上再打 88 折。问至少需要多少个夜晚才能完成迁移。这是一个非常适合展示自动推理的任务涉及 TB、Mbps、小时、百分比等多个单位的转换又有乘除和取整逻辑人类手工算容易出错模型直接算更容易错。我准备了两个工具unit_convert负责各类单位换算calculate负责数学表达式安全计算。工具清单如下[ { name: unit_convert, description: 单位换算工具支持数据量单位B/KB/MB/GB/TB和速率单位bps/Kbps/Mbps/Gbps之间的换算。, parameters: { value: {type: number, description: 待换算数值}, from_unit: {type: string, description: 原单位}, to_unit: {type: string, description: 目标单位} } }, { name: calculate, description: 安全计算器执行数学表达式计算支持加减乘除与括号。, parameters: { expression: {type: string, description: 数学表达式例如 56.25 * 21600} } } ]6.2 完整提示词可直接抄以下是我在这类任务里用的完整系统提示词你可以直接抄下来改写成自己的版本你是一名严谨的计算调度员。你不具备可靠的算术能力所有数值计算必须通过工具完成。 可用工具如下 1. unit_convert 作用单位换算支持数据量单位与速率单位之间的转换。 调用示例{tool: unit_convert, arguments: {value: 450, from_unit: Mbps, to_unit: MB/s}} 禁止用于百分比计算、汇率换算。 2. calculate 作用安全执行数学表达式适合多步乘除。 调用示例{tool: calculate, arguments: {expression: 56.25 * 21600}} 禁止用于单位换算。 任务执行规则 1. 先理解题意拆解出所有已知条件和目标未知项。 2. 每次只调用一个工具等待工具结果返回后再继续下一步。 3. 所有决策一律用如下 JSON 格式输出不要添加 Markdown 代码块包裹 {thought: 你的思考过程, tool: 工具名, arguments: {...}} 4. 当你认为已经得到最终答案时直接输出 Final Answer: 最终结果并附上依据。 5. 如果工具返回的结果与常规量级明显不符必须停下来说明不要继续使用。你可以看到这段提示词没有复杂的术语却把最关键的几个决策点都钉死了身份设定、工具边界、输出格式、单步调用、结果校验、退出条件。6.3 运转演示一次单位换算错误是如何被工具流程救回来的我用温度设为较低的参数实测过一个完整追踪这里把关键调度过程复现出来。模型的第一轮决策{ thought: 先把带宽单位从 Mbps 换算成 MB/s再把 2.5TB 换成 GB这样才能统一单位计算。, tool: unit_convert, arguments: {value: 450, from_unit: Mbps, to_unit: MB/s} }工具返回56.25。如果模型当初没走工具直接心算很可能会写成 450 MB/s那后面的所有结果都会放大 8 倍。而在这里工具保证了第一步数值的正确性。第二轮决策模型继续拆解每晚可传多少 GB{ thought: 每晚有 6 小时每小时 3600 秒所以有效时长是 21600 秒。再乘带宽 56.25 MB/s、网络利用率 0.9、文件重试系数 0.88。, tool: calculate, arguments: {expression: 56.25 * 21600 * 0.9 * 0.88 / 1000} }注意最后那个/1000把 MB 换算成 GB按十进制。工具返回962.28。也就是说每晚实际可以迁移约 962.28 GB。第三轮模型计算总数据量{ thought: 2.5TB 需要换算成 GB方便和每夜传输能力比较。, tool: unit_convert, arguments: {value: 2.5, from_unit: TB, to_unit: GB} }工具返回2500.0。第四轮模型用计算器算出所需天数{ thought: 总数据量除以每夜有效传输量向上取整得到所需夜数。, tool: calculate, arguments: {expression: 2500 / 962.28} }工具返回2.598。模型向上取整Final Answer需要 3 个夜晚。最后一步我特意观察它有没有做反向验证。由于提示词里写了“结果与常规量级明显不符必须停下”模型在最终回答前加了一句反向校验“3 个夜晚可传约 2886.84GB大于 2500GB结论合理。”这个校验不是必须的但我建议保留它能把最后一道防线补上。6.4 把示例改成你自己的场景增量替换法这个案例的价值不在于那几行计算而在于演示提示词工程的通用套路先定义任务链路再定义工具边界最后定义输出与校验规则。你完全可以用同样的骨架去处理“预算预估”“库存补货”“带宽规划”“依赖调度”等各类具体问题。我的迁移方法是“增量替换法”先完整跑通一组两个工具的小案例确认循环稳定后再逐步替换工具清单和领域数据。每替换一个工具都重新跑一遍完整链路观察模型在边界描述、参数命名上会不会产生新的混淆。这样做能避免一次性引入大量新工具后模型频繁误选也方便你在早期就把提示词里不够清楚的地方揪出来。从单次问答到多步骤工具调用提示词工程的核心就不再是“怎么说得更像人话”而是“怎样把解决问题的流程说清楚、约束紧、验证稳”。我自己的体会是别急着给模型塞一堆工具先从一个任务链路的最小闭环开始把每一步的输入输出都记录清楚。等基础链路稳固下来再往里面加复杂的工具和约束你会发现自己离“让模型真正干活”这件事又近了一大步。