智能体调用工具：把边界画在哪里

智能体与普通问答的区别在于它会执行动作：查订单、改状态、发消息。能力变强的同时，错误的后果也从「说错一句话」变成了「做错一件事」，而后者往往不可撤销。

工具定义要具体

给模型的工具描述应当写清楚：这个工具做什么、每个参数是什么含义与取值范围、什么情况下不该用它。描述含糊时模型会在不合适的场景调用它，或者把参数填错。

一个实用的原则是：工具粒度不要太大。「处理订单」这种包含多种动作的工具，不如拆成「查询订单」「取消订单」「修改收货地址」几个单一职责的工具 —— 粒度细了，权限才好分，出错范围也小。

参数不能直接信

模型生成的参数要经过与处理用户输入同等强度的校验：类型、范围、格式、以及业务合法性。不能因为参数来自模型就跳过校验 —— 模型会把用户输入里的内容带进参数，这条路径等同于用户可控。

读写分离，写操作收紧

• 只读工具可以放开让模型自由调用，错了重来即可；
• 写操作需要额外条件：要么人工确认，要么限定在很窄的范围内（例如只能修改自己创建的、只能在某状态下执行）；
• 涉及资金、对外通知、不可逆变更的，不要做成工具交给模型调用，改为由模型生成建议、人执行；
• 每个写操作都要有幂等键，模型重试或链路重放时不会执行两次。

失败要能被模型理解

工具返回错误时，错误信息要写成模型能据以决策的内容：是参数不对需要重填、是条件不满足需要换方案、还是系统故障应当放弃并转人工。只返回一个错误码，模型通常会盲目重试。

同时要在系统侧限制单次会话内的工具调用次数，避免模型陷入反复重试的循环 —— 这既消耗成本，也会让用户等待很久却没有结果。

全链路都要留痕

记录模型决定调用哪个工具、传了什么参数、返回了什么、以及最终呈现给用户什么。出问题时这条链是唯一能还原现场的东西。只记录最终回答，等于放弃了排查能力。相关设计见AI 智能体解决方案与平台与系统开发。