Agent 的 thinking 阶段如何判断该调用工具还是直接回复，如何设计决策信号和安全约束？｜高频面试题解析

60 秒回答模板

我会把 thinking 阶段理解成内部决策策略，而不是把原始思维链直接暴露给用户。它的核心输出应该是结构化动作：直接回复、调用某个工具、继续追问澄清，或者拒绝。判断是否调用工具主要看几个信号。第一，回答是否需要外部事实、实时数据、私有上下文、数据库状态或精确计算；如果模型记忆不可靠，就应该走工具。第二，用户意图是否足够明确，参数是否齐全；缺参数时不应编造工具参数，而应追问。第三，工具是否能提供更高置信度或可验证结果，比如搜索、查库、执行代码、创建工单。第四，工具调用是否有副作用和权限风险；读操作和写操作要分级，写操作、付费操作、删除操作需要确认和审计。实现上可以让 LLM 输出受约束的 action schema，再由规则层校验工具名、参数、权限、置信度阈值和循环次数。工具返回后还要把结果回填给模型生成最终回答，并处理失败、超时和低置信度。评估时看工具调用准确率、漏调率、误调率、参数正确率、任务成功率、延迟成本和安全违规率，而不是只看回答像不像。

考点 动作结构化

难度 真实面经题

回答目标 让候选人能把 Agent 工具决策讲成一个受约束的运行时策略，覆盖直接答、工具调用、澄清、拒绝、安全校验、结果回填和可量化评估。

深入解析

thinking 输出应是可执行决策

工程上不要依赖不可控的长篇自由文本思考，而应让模型或策略层输出结构化动作，例如 direct_answer、tool_call、ask_clarification、refuse。每个动作带理由摘要、置信度、需要的工具、参数和是否有副作用，方便后续系统校验和审计。

直接回复适合高置信静态问题

如果用户问的是模型已掌握的通用知识、无需实时状态、无需私有数据、无需精确执行，并且风险较低，可以直接回复。直接回复也要遵守边界：不能假装查过系统，不能编造当前状态，不能把不确定事实说成确定结论。

调用工具适合需要外部事实的任务

当问题依赖实时信息、用户私有上下文、数据库记录、文件内容、订单状态、代码运行结果、精确计算或外部系统动作时，应优先调用工具。工具的价值是把不可验证的语言猜测变成可追溯事实或真实操作。

参数完整性决定是否追问

很多错误工具调用来自参数不全但模型硬猜。例如用户说帮我查一下，没有给对象、时间范围或权限上下文，系统应该追问；如果部分参数可从上下文安全推断，也要标记来源。参数缺失、歧义和冲突需要在工具前处理。

安全约束应独立于模型判断

不能只相信模型说这个工具安全。系统层需要校验工具白名单、用户权限、参数范围、敏感数据访问、读写类型、幂等性、副作用级别和确认策略。删除、支付、发消息、改权限等高风险工具必须有人类确认或更强认证。

置信度和成本要进入决策

工具调用并非越多越好。策略应考虑模型对直接答案的置信度、工具可用性、调用成本、延迟、失败概率和用户体验。低成本读工具可以降低幻觉，高成本或慢工具应在确有必要时调用，或先给用户说明需要查询。

工具结果要回填并校验

调用工具后，模型需要基于工具结果回答，而不是继续按先验编造。系统可以把工具结果、状态码、错误信息和证据摘要回填给模型，并要求引用结果中的关键字段。若工具失败，要区分可重试、参数错误、权限不足和外部系统不可用。

循环控制防止失控

Agent 可能陷入反复思考和调用工具的循环。需要设置最大工具调用次数、最大思考轮数、超时、去重、错误熔断和结束条件。若多次工具结果不足，应转为澄清或说明无法完成，而不是继续调用相同工具。

评估看决策而不只看答案

应单独评估 action 选择准确率、该调未调、误调工具、参数正确率、权限拦截率、工具失败恢复、最终任务成功率、延迟和成本。这样才能知道问题出在 thinking 决策、工具执行、结果回填，还是最终回答生成。

易错点

把 thinking 阶段等同于展示完整思维链，忽略工程上需要的是结构化动作和可审计决策。
认为工具调用越多越可靠，没有考虑延迟、成本、误调率和用户体验。
需要实时或私有数据时直接凭模型记忆回答，导致编造当前状态。
参数不全时让模型猜用户、时间范围、文件名或业务对象，而不是追问澄清。
只靠 prompt 约束安全，没有系统层权限、白名单、副作用和确认校验。
工具返回错误后仍生成看似成功的最终答案，没有区分失败类型和恢复策略。
没有限制工具调用轮数，导致循环调用、重复查询或超时。
评估只看最终回答是否流畅，不单独统计工具选择、参数正确率和安全拦截率。

面试官追问

如何防止 Agent 为了显得专业而过度调用工具？

给每类任务定义工具必要性规则和成本阈值，评估误调率和延迟成本；对低风险静态知识允许直接答，对实时、私有、精确和可执行任务才要求工具。还可以在 action schema 中要求说明工具带来的新增事实。

模型生成了不存在的工具名怎么办？

系统层必须用工具注册表校验工具名和参数 schema。不存在的工具不能执行，应返回可用工具列表或让模型重新选择，并把 hallucinated tool call 计入评估指标。

工具参数缺失但模型很有把握，应该执行吗？

不应该。置信度不能替代参数完整性。系统应检查必填字段、类型、权限和歧义；缺关键参数时追问用户，能安全默认的参数也要明确默认来源。

有副作用的工具如何处理？

先分级读写风险。读操作可在权限内直接执行；写操作、发消息、支付、删除、改权限等需要确认、幂等键、审计日志和回滚或补偿机制，高风险还要二次认证。

工具调用失败后 Agent 应该怎么恢复？

根据失败类型处理：超时可重试或降级，参数错误应修正或追问，权限不足应说明权限问题，外部系统不可用应告知无法完成。不能把失败结果包装成成功回答。

如何评估该调用工具却没调用的情况？

构造需要实时数据、私有上下文、精确计算和外部执行的测试集，人工标注期望 action，统计漏调率，并检查最终答案是否出现编造状态或未经验证的事实。