企业官网建设流程全解析

你有没有遇到过这种场景：用户问“今晚某城市适合穿什么衣服”，模型一本正经地回答“建议穿短袖”，可它根本不知道当地的实时温度；用户说“帮我看看服务器日志里访问量最高的三个接口”，模型立刻给出一个看起来很专业的结论，但你心里清楚它根本没看过日志，纯粹在编。这不是模型不够聪明，而是因为它只有一张会说话的嘴，没有手，没有眼睛。

要让模型真正做到“干活”而不是“聊天”，就得给它装上自主工具使用能力，把“思考、行动、观察、再思考”串成一条智能推理链。这也是本次进阶指南（二）要解决的核心问题：如何打造具备自主工具使用能力的智能推理链。这篇内容适合已经会调大模型API、做过提示词工程，但还没系统接触过Agent和Function Calling的开发者。我会从底层逻辑讲到可落地的代码实现，再分享几个实测中翻车的典型场景，尽量说人话，把细节讲透。

1. 从“话痨”到“干活”：工具使用能力到底解决了什么问题

1.1 模型的三个先天缺陷，注定了它必须要靠工具

先纠正一个误区：很多人觉得大模型是“什么都知道的百科全书”，但你在真实项目里用久了就会发现，它有三个先天缺陷是模型本身无法靠参数规模弥补的。

第一是知识有截止日期。模型训练完成后，它的知识就冻结在那个时间点了。昨天新发布的产品、今天刚出的漏洞通告、明天某地的临时交通管制，它一概不知道。你说你可以把最新知识写进提示词塞给它，但当知识量超过上下文窗口、或者你需要每天自动更新时，提示词方案就不现实了。

第二是计算能力不可靠。你让它算一道浮点数乘法，它可能算对；让它算一个复杂的金融收益率，它大概率会把小数点点错位置。模型本质是在做概率化的文字接龙，不是在做精确计算。你强行让它心算，等于让一个中文系毕业生去做造价审计。

第三是没有环境感知能力。它不读文件就看不到日志，不查数据库就拿不到订单数据，不调用API就不知道某个服务现在是否健康。文本模型能做的只有“基于已有信息组织语言”，而这些“已有信息”如果不通过工具去获取，它就只能编。

这三点叠加，决定了如果你只把模型当文本生成器用，你的应用天花板会非常低。真正实用的做法是：让模型当大脑，让工具当手脚。

1.2 工具使用能力的本质，不是“会调API”而是“会做决策”

很多初学者会把工具使用能力理解成“在代码里写一个if else，调用一下天气API，把结果塞进提示词里”，但这不是Agent，这叫字符串拼接。

真正的自主工具使用能力，核心是一个决策循环。模型需要自己回答四个问题：

• 当前这个问题，我需要调用工具吗？还是凭已有知识直接回答？
• 如果需要工具，哪个工具最合适？
• 这个工具需要什么参数？参数值从哪里来？
• 工具返回的结果可靠吗？我要直接使用，还是需要再调用其他工具进行验证或补充？

这四个决策动作串联起来，才是所谓的“智能推理链”。模型不再被动等待你喂数据，而是像人一样，遇到需求时主动去查、去算、去验证，然后基于获取到的信息继续推理。

我打个比方。你让一个实习生去订一场会议的场地。他不会因为熟记了全城酒店的清单就觉得自己能搞定，他会打开地图查位置，打开日历确认时间，打开预算表确认价格区间，最后还要打开天气软件看看当天下不下雨。每一步都是一个小工具调用，而工具返回的结果会影响他的下一步决策。我们要构建的智能推理链，本质上就是把这个实习生的行为逻辑移植到模型身上。

1.3 从提示词工程到智能体，中间差的不是知识而是编排

我见过不少团队做项目时，路径是这样的：先写一个精细的提示词，让模型输出JSON格式的内容，然后在代码里解析JSON、调接口、拼结果。这个方案短期能用，但它属于“单向流水线”，模型没有主动权。一旦用户问题变复杂，比如“先查日志再分析再生成报告”，你的代码逻辑就会越来越臃肿，最后变成巨大的状态机，维护成本极高。

而具备自主工具使用能力的推理链，走的是另一条路：我把工具清单交给模型，剩下的路由逻辑交给模型自己判断。你不需要在代码里穷举“如果用户问天气就调天气接口，如果问新闻就调新闻接口”，模型会根据用户问题的语义动态选择。

当然，这条路也有它的问题：模型可能选错工具、可能参数填错、可能陷入死循环。所以我们需要一套机制去约束它、引导它、兜底它。接下来的内容，就是这套机制的具体拆解。

2. 推理链的三段式循环：思考、调用、观察

2.1 ReAct范式的落地理解：一个循环里到底发生了什么

要构建自主工具使用能力，目前工业界最成熟、最通用的范式是ReAct，也就是Reasoning和Acting的交替循环。在代码层面，它表现为三个阶段的不断重复：

第一个阶段是思考。模型接收到用户问题，以及之前所有工具调用的结果，输出一条推理轨迹，说明当前它理解了什么问题、下一步打算怎么办。在支持Function Calling的接口里，这个思考不一定以文字形式暴露出来，很多时候它直接表现为“模型返回了一个工具调用请求”。

第二个阶段是执行。系统拿到模型返回的工具调用请求，根据工具名称找到对应的函数，然后解析参数、真正去执行。这个动作发生在模型服务之外，由你自己的代码完成。这一点非常关键：模型不会真的自己去调API，它只会发出调用意图，剩下的脏活累活由你的执行器干。

第三个阶段是观察。工具执行完毕后，系统把执行结果（成功或失败、返回值或报错信息）以一条消息的形式回传给模型。模型看到结果后，进入下一轮思考：结果是否符合预期？还需要进一步处理吗？还是已经可以生成最终答案？

这个循环会持续进行，直到模型判断自己已经拿到足够信息、不再发起工具调用为止。用一个伪代码表达，就是：

while True: response = llm.chat( messages=messages, tools=TOOLS, tool_choice="auto" ) msg = response.message if msg.tool_calls: messages.append(msg) for call in msg.tool_calls: result = executor.execute(call.name, call.arguments) messages.append(role_tool_message(call.id, result)) else: return msg.content

理解ReAct的关键在于：**思考阶段的目标不是输出正确答案，而是输出下一步最合理的动作。**观察阶段的目标也不只是把结果存档，而是刷新模型对当前状态的认知。整个循环的推进动力，来自“信息不断积累”和“决策不断收敛”之间的交替。

2.2 一个贴近生活的类比：像人出差一样安排任务的节奏

ReAct这个词有点学术味，我用日常场景帮你拆开。假设你出差去一个陌生城市，收到一项任务：明天下午三点参加一个客户会议，但你还不知道会场在哪里、交通怎么走、要不要带电脑。

你会怎么行动？

你的第一反应不是“一次性解决所有问题”，而是先想：“我需要知道会场地址，那就打开地图查一下。”这是第一次思考+调用。地图返回结果后，你发现地址在郊区，于是你又想：“郊区打车不方便，我得看看有没有地铁直达。”这是第二次思考+调用。确认交通方案后，你又想：“既然地址偏远，路上耗时超过一小时，我得提前出门，那么下午一点之前必须吃完午饭。”这是第三次推理，但这次不再需要新工具，而是基于已有信息做出综合判断。

整个过程，“思考”和“工具调用”是交替出现的。你不会在地图App里同时把“订餐”“打车”“看天气”全部塞进一次操作，而是根据每次返回的信息调整下一步规划。推理链推崇的正是这种“走一步看一步”的节奏。它之所以优于一次性提示词，是因为它允许模型在信息不完全的情况下先迈出第一步，再根据反馈动态修正。

有些人会把“多工具调用”理解成“一口气调用所有工具”，实际上这反而容易出错。如果初始信息就是错的，后面所有并行调用都建立在错误前提上，结果自然一塌糊涂。动态交替调用，本质上是对不确定性的渐进式消化。

2.3 推理链的终止条件：什么时候停下来才是关键设计

循环不能无限跑，所以你必须给模型一个明确的“结束信号”。这个信号在接口层面通常表现为：模型返回了一条不包含工具调用的消息，并且内容直接面向用户。

很多团队写的Agent不稳定，问题恰恰出在终止条件上。模型可能始终觉得信息不足，于是一遍又一遍调用工具；也可能在拿到满意结果后，仍然多调用一次工具，纯粹因为系统提示词里写了“每一步都必须使用工具”，它就不敢停下来。

我给这类系统写提示词时，会用非常明确的语言约束：**只有当你认为当前信息已经足够回答用户问题时，才能直接输出最终答案，不要为了调用工具而调用工具。**同时，在代码层面也会设置最大循环步数，比如默认8步，超过就强行终止，把已采集到的信息原样返回给用户，并提示“推理未收敛”。

这一步既是体验兜底，也是成本控制。模型每多跑一轮，就多一次API调用的费用和时延，如果不在终止条件上做文章，你的Agent很可能会成为一个昂贵的“无限分析机”。

3. 实战演示：用Function Calling搭一个可自主调工具的智能推理链

3.1 整体架构与准备工作

理论聊完，我们来点实际的。我以“工程日志分析助手”为例，搭建一个能自主决定调用工具的智能推理链。这个场景很典型：用户的提问是开放式的，比如“帮我看看最近一小时有多少条错误日志”“哪个接口的平均耗时最高”“对比一下这两天服务可用性变化”，这些问题不是单次查询就能解决的，需要模型结合多个工具灵活组合。

整体架构分四个部分：

• 模型服务：选择支持Function Calling的模型接口，目前主流模型服务商都提供类似的工具调用协议。
• 工具注册表：把可用的工具以JSON Schema的形式声明给模型，相当于一份“工具使用说明书”。
• 执行器：负责真正运行工具函数，比如查询日志文件、执行聚合计算。
• 循环控制器：负责调度“模型→执行器→模型”的循环，管理上下文消息、判断终止条件。

我先定义两个非常简单的模拟工具，跑通流程。第一个是查询错误日志数量的工具，第二个是计算表达式结果的工具。后面我们会让模型自己判断用户问题该用哪个。

# tools.py import json import random def query_error_logs(hours: int) -> dict: """模拟从日志系统查询最近小时数内的错误日志数量""" # 真实场景中这里会读日志平台API，这里用随机数模拟 base = random.randint(20, 200) return { "hours": hours, "error_log_count": base, "sample_messages": [ "TimeoutError: connection to backend timed out", "ValueError: invalid request payload", ] } def eval_expression(expression: str) -> dict: """求值一个数学表达式，例如 '100 * 0.2 + 5'""" try: # 注意：生产环境不要直接用eval，应该用安全表达式解析库 result = eval(expression) except Exception as e: return {"success": False, "error": str(e)} return {"success": True, "result": result}

这两个工具足够简单，但它们能体现两种不同的调用意图：一个是“获取数据信息”，一个是“执行计算操作”。实际生产环境里的工具会比这复杂得多，但推理链的编排逻辑是一样的。

接着，我定义一个工具Schema列表。Schema就是给模型看的“说明书”，里面写清楚了工具叫什么、干什么用、需要什么参数、每个参数是什么类型。模型不会真的阅读你的代码，它只读这份Schema来理解工具能力。

# schemas.py TOOL_SCHEMAS = [ { "type": "function", "function": { "name": "query_error_logs", "description": "查询最近N个小时内系统中错误日志的数量和典型错误信息。当用户询问错误、异常、故障、日志分析时，必须使用该工具。", "parameters": { "type": "object", "properties": { "hours": { "type": "integer", "description": "需要查询的小时数，取值范围1-24，默认值1" } }, "required": ["hours"] } } }, { "type": "function", "function": { "name": "eval_expression", "description": "对数学表达式进行精确计算，支持加减乘除、百分号等。当用户需要精确数值计算、涉及算术运算时必须使用该工具。", "parameters": { "type": "object", "properties": { "expression": { "type": "string", "description": "数学表达式，例如 '120 * 0.05 - 3'" } }, "required": ["expression"] } } } ]

这里我要强调一个实操体会：工具描述写得越具体，模型选择工具的准确率越高。比如我在query_error_logs的描述里明确写了“当用户询问错误、异常、故障、日志分析时，必须使用该工具”，模型看到日志类提问时，绑定该工具的概率就会显著上升。相反，如果你只写“查询错误日志”，模型可能犹豫半天，甚至选择不调用工具直接瞎答。

3.2 循环控制器：把模型和工具串起来

接下来是核心部分——循环控制器的代码。这个代码做的事情其实很朴素：不断调用模型接口，检查返回结果里有没有工具调用请求，有就执行工具并把结果回传，没有就结束循环。

# agent.py import json from llm_service import chat_completion # 抽象模型服务接口 from tools import query_error_logs, eval_expression from schemas import TOOL_SCHEMAS TOOL_MAP = { "query_error_logs": query_error_logs, "eval_expression": eval_expression, } SYSTEM_PROMPT = """ 你是一个具备自主工具使用能力的工程日志分析助手。 你可以调用以下工具来完成用户请求： - 当需要了解错误日志信息时，调用query_error_logs。 - 当需要精确计算数值时，调用eval_expression。 你必须遵守以下规则： 1. 每一步先判断是否需要工具支持，如果需要，就发起工具调用。 2. 工具调用结果会以额外消息返回给你，你需要基于结果继续推理。 3. 当你已经拿到足够的信息、可以回答用户的问题时，直接输出最终答案。 4. 禁止编造工具结果，所有数据必须来自工具返回。 5. 不要为了调用工具而调用工具。 """ def run_agent(user_query: str, max_steps: int = 8): messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_query}, ] for step in range(max_steps): response = chat_completion(model="default-model", messages=messages, tools=TOOL_SCHEMAS, tool_choice="auto") assistant_msg = response.choices[0].message messages.append(assistant_msg) # 情况1：模型没有发起工具调用，认为可以直接回答 if not assistant_msg.tool_calls: return assistant_msg.content # 情况2：模型发起了工具调用，逐个执行 for tool_call in assistant_msg.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) print(f"[Step {step+1}] 模型调用工具: {fn_name}({fn_args})") if fn_name not in TOOL_MAP: result = {"error": f"未知工具: {fn_name}"} else: result = TOOL_MAP[fn_name](**fn_args) # 把工具执行结果返回给模型 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False), }) return "已达到最大推理步数，未能收敛到可靠答案。"

这里有几个细节值得展开说。

tool_call_id的对应关系非常关键。模型发起工具调用时，会生成一个唯一的调用ID。你把执行结果回传时，必须通过tool_call_id指出这份结果对应的是哪一次调用。如果这里对应错了，模型会把结果理解错乱，后续推理逻辑会全面崩盘。

工具执行失败也要返回，而不是直接抛异常。你仔细看我的代码，工具执行成功的结果返回给模型，失败的信息同样返回给模型。模型看到错误信息后，有能力修正自己的行为，比如换一个参数重试，或者换一个工具。如果你直接在Python层抛异常中断循环，模型就失去了自我纠错的机会。

参数解析前加json.loads还不够严谨。实际生产环境里，模型输出的参数偶尔会多一个换行、少一个引号，这是JSON解析的常见坑。我会包一层异常处理，解析失败时把原始参数和报错信息一起传给模型，让它自己看着办。别笑，这招在实测里真的能救回不少请求。

3.3 跑通一次完整推理链：模型如何自主选择工具

假设用户问的是：“过去两个小时系统有多少条错误日志？如果错误率超过百分之五，帮我把这个数值乘以三预估明天的量。”

这个请求包含两个动作逻辑：先查日志拿到错误数量，再执行一次百分比计算。让我演示一下推理链的推进过程：

第一轮：模型收到用户问题，判断“用户需要查询错误日志”，于是发起工具调用：

{ "name": "query_error_logs", "arguments": "{\"hours\": 2}" }

执行器调用query_error_logs(2)，假设返回：

{ "hours": 2, "error_log_count": 350, "sample_messages": ["..."] }

系统把这条结果作为tool role消息回传给模型。注意，此刻模型并不知道“350是否大于某个统计基数”，它还需要更多信息，所以它会继续推理。

第二轮：模型经历了“看日志 → 拿到错误数量350”的观察，下一步它需要判断错误率是否超过5%。但它现在缺少分母数据，也就是总请求量。如果我们的工具集里再添加一个“query_total_requests”工具，模型就会自动调用它去拿总请求量。这里为了简洁起见，我假设日志工具直接返回了error_rate字段：

{"hours": 2, "error_log_count": 350, "error_rate": 0.045}

第三轮：模型看到error_rate为0.045，小于5%，于是它认为不需要做“乘以三”的后续计算，直接生成答案：“过去两小时错误日志数量为350条，错误率4.5%，未超过5%，不需要调整预估。”整个流程结束。

这个例子的精彩之处在于，模型自主判断了“是否还要继续调用工具”——因为它发现不该执行乘法，于是直接输出答案。这是严格的if-else流水线很难实现的行为。

我实测下来，模型在这类多步任务中的工具调用成功率，很大程度上依赖于观测结果的格式是否友好。如果你把工具结果拼成一坨没有结构的纯文本，模型理解起来非常吃力；如果返回结构化JSON，并加上必要的字段解释，模型推理质量会明显提升。后面我会展开讲这点的踩坑经历。

4. 进阶设计：多工具协同时的任务编排与边界控制

4.1 串行、并行、分支：多工具交互的三种基础模式

当你的工具数量从2个增长到20个，单纯让模型“一步一步来”还不够，你必须考虑工具之间的交互模式。我总结下来，实际项目里无外乎三种：

串行依赖模式。上一个工具的输出，是下一个工具的输入参数。比如：先调用“query_service_list”拿到服务列表，再对每一行调用“check_service_status”检查健康状态。这种模式下，每一轮只能有一个工具调用，推理链条清晰，也最容易控制。

并行独立模式。一个请求需要多个互不依赖的数据。比如：用户问“把最近一小时错误日志数量和三小时前的做一个对比”，模型可能先调用一次query_error_logs(hours=1)，再调用一次query_error_logs(hours=3)。这两种调用互不依赖，可以在同一轮里同时发出。现在主流模型接口都支持在一次返回里携带多个tool_calls，这样能省好几轮往返时延。

条件分支模式。模型根据当前工具结果决定走哪条路径。比如：日志工具返回error_rate = 0.02，低于阈值，模型直接输出结论；如果返回error_rate = 0.08，模型决定调用告警工具发送通知。分支是推理链中最体现“智能”的地方，也是调试时最容易翻车的地方。

我在生产环境里更倾向于先求稳再求快：默认用串行模式，只有当工具之间确实没有数据依赖时才允许多工具并行。因为并行调用虽然省时间，但会让模型在“解析结果对应关系”上犯迷糊，尤其是多个工具返回相似结构的数据时，模型可能把A工具的结果当作B工具的输入，导致后续推理全部错位。

4.2 失控防护：步数上限、超时中断、成本预算一个都不能少

Agent失控是实操中一定会遇到的，表现形式有：模型反复调用同一个工具、模型在工具之间来回横跳、模型无限细化同一个问题迟迟不给结论。这些行为不仅烧钱，还会把用户体验拖入深渊。

我自己的实战策略是三层防护。

第一层，步数上限。前面代码里的max_steps=8就是这个作用。如果8轮之内还不能收敛，直接返回当前已采集的信息，并明确告诉用户“推理链路过长，结果仅供参考”。有些复杂任务确实需要更多步数，你可以根据业务场景调整，但一定要设置，无上限的Agent就是定时炸弹。

第二层，重复调用检测。我在控制器里维护一个hash表，记录“工具名+参数”的出现次数。如果同一个调用出现超过三次，我就中断这次调用，要求模型切换策略，或者直接生成最终答案。

第三层，单步超时与整体预算。每个工具函数执行时，用future包一层，设置10秒超时；整个Agent会话设置API预算上限，比如最多消耗N个token，超过就强制截断。这些措施在开发环境看起来多余，一上生产你就知道它们的价值了。我曾见过一个Agent在没人值守的情况下连续跑了四十多轮，月底账单出来时，整个团队都沉默了。

4.3 上下文膨胀：工具结果把主角挤到窒息

推理链有一个隐蔽的副作用：每一轮工具调用的结果都会追加进messages列表，导致上下文越滚越大。如果你做的是日志分析、文档审阅、数据库查询这类任务，工具结果动辄几KB甚至几十KB，模型很快就会被冗长的历史观测结果淹没，甚至超出上下文窗口。

我的解决思路是在回传前先做结果压缩。

如果工具返回的是大数据集，不让原始结果直接进入messages，而是先经过一个摘要步骤：提取统计指标、截断长列表、保留前几条抽样，然后只把摘要文本回传给模型。比如查询错误日志，原始数据可能有50000条，我只让工具返回error_log_count、error_rate和三个典型错误样本，这样模型拿到的信息密度反而更高，推理也更清晰。

另一种做法是动态摘要历史消息。当整个对话上下文超过某个阈值时，把早期的工具观测结果用模型重写为一段精简总结，替代原始的长消息。这种“记忆压缩”机制，是让长期运行的Agent保持稳定的重要手段。开发阶段你可能感受不到，但一旦你的Agent需要连续工作半小时以上，上下文膨胀一定会找上你。

5. 实测中的翻车现场与排查路径

5.1 工具幻觉：模型连调用都没发生，就开始编结果

先说一个我踩得最深、也最隐蔽的坑：工具幻觉。现象是，模型没有返回tool_calls请求，但它在最终回答里说“根据日志查询结果显示，错误量为350条”。你到处找这条350是从哪来的，最后发现完全没有调用记录。模型编造了工具结果，而且编得有理有据，让用户无法察觉。

这个问题在两类场景里特别高发：一是模型认为自己凭训练知识能推断答案时；二是工具描述不够强约束时。

排查路径：先看日志中模型是否产生过tool_calls请求，确认没有调用；再检查可行性，当模型忽略工具时，系统提示词规则第四条“禁止编造工具结果，所有数据必须来自工具返回”是否被模型突破。

我后来做了两个调整：一是在系统提示词里增加反面示例，比如写明“你上一轮没有调用query_error_logs，所以你不能声称知道错误日志数量”；二是从框架层面兜底——控制器解析模型最终回答时，如果发现回答中出现了疑似数据性表述，但上下文里没有对应工具调用记录，就强制触发一次“你可确认是否真的拿到数据？如果没有，请调用工具”的追问。这个兜底逻辑简单粗暴，但非常有效。

5.2 参数格式错误：一个JSON引号引发的大排查

第二个高频坑是参数格式错误。模型理解了该用什么工具，但传给执行器的参数类型不对。比如我的query_error_logs定义hours是integer，模型却传了{"hours": "2"}；再比如模型在arguments里多加了一个逗号，json.loads直接抛异常。

这类问题的第一诱因是Schema里字段描述不清晰。如果我写的是“需要查询的小时数”，模型可能自然输出字符串；如果我写成“hours，整数类型，必填，取值范围1-24，默认值1”，并且在系统提示词里补充“注意参数类型必须严格匹配，hours是整数，不是字符串”，错误率会显著下降。

第二道防线是执行器端的类型宽容处理。我在解析arguments后，会做一个“字段修正”：对声明为integer的字段，如果传入的是字符串且能转换，就自动转成int；对boolean字段，兼容"true"/"false"/true/false四种写法。这些修正不是让模型随便乱来，而是让你在模型偶尔抽风时不至于整个流程崩溃。

第三道防线，也是最容易被忽视的，是把解析失败的信息回传给模型，让它自己修复。当你发现json.loads失败，不要直接报错退出，而是把“参数解析失败：json.loads错误信息：xxxx”作为工具结果返回给模型。实测中，模型看到自己的错误后，大概率会重新生成一个规范的arguments，第二次就对了。给模型一次自我纠错的机会，比任何参数校验正则都有效。

5.3 循环不收敛：模型化身“复读机”的机制与破解

第三种翻车现场是循环不收敛。模型在同一轮调用query_error_logs多次，且传入参数完全相同。它不是想多拿信息，而是“卡住了”——要么上下文里缺少能推动决策的新知识，要么它自己被绕进去了。

排查后发现，最常见的触发点是：模型在一次工具调用拿到结果后，结果被原样回传，但模型并不清楚“接下来该干嘛”。系统提示词里如果没写清楚“观察结果后请判断是否已经足够”，模型就会迷茫。

我的破解思路是“阶梯式干预”。第一层，检测到完全相同的调用出现两次时，在下一轮系统消息里附加一句提醒：“你刚刚已经查询过相同条件的数据，请基于已有结果继续推理，不要重复调用。”第二层，如果第三次还重复，强行终止循环，返回当前结果并附带“本文Answer缓存”标记，让调用的上层来决定如何处理。第三层，从模型服务参数上做文章：适当调低temperature，减少模型的随机性漂移，让它在推理路径上更稳定。

5.4 模型绕过工具：懒不是模型的错，是你的约束太弱

最后一种情况是模型明明该用工具，却直接凭记忆回答。比如用户问“帮我算一下1500乘以12.7”，模型直接输出19050——它算对了，但它根本没有调用eval_expression。

为什么？因为模型认为“自己会算”。问题在于，你既然搭了推理链，就希望所有需要计算的场景都走工具，这样至少能保证计算可靠。模型绕过的本质是工具描述里的“触发条件”不够强。

我在描述里原本写的是“当需要精确数值计算时可以调用”，后来改成“当用户表达涉及任何形式的算术运算时，必须调用eval_expression，禁止自行心算”。一字之差，调用率提升非常明显。工具描述本质上是提示词的一部分，你要用明确的白名单式语言，而不是“可以”“允许”这类弱词。

另外，还有一种方案，是在系统提示词里指定“工具偏好规则”，列一个优先级表：“用户诉求优先级最高，其次是数据准确性和计算正确性。遇到计算层面问题，一律用工具；遇到需要实时或事实性知识问题，一律用工具。”这样即使模型对自己的心算很有信心，也会因为规则约束而选择调用工具。

写在最后的实操体会

这套智能推理链，我在不同场景下反复调过很多次，最深的感受是：它的核心瓶颈其实不在模型能力，而在于你给模型的“边界”是否清晰。工具清单是能力边界，描述是否明确是决策边界，终止条件是收敛边界，上下文压缩是记忆边界。把这四层边界设计好了，哪怕模型本身并不是最强的，推理链也能稳定跑出靠谱的结果；反过来，边界设计得一塌糊涂，再强的模型也会变成会胡说八道的重复调用机器。

最后分享一个很实用的小技巧：开发调试阶段，把所有工具调用和观测结果都打印到标准输出，你会亲眼看到模型的每一步思考轨迹。这些轨迹是最有价值的调试线索，比任何日志分析工具都好用。等你熟悉了模型的“思维习惯”，再逐步把打印关掉，你的Agent就真正可以上生产了。