夜雨聆风星漫宇航｜AI名词百科 · 第24篇
员工在企业助手里问：“帮我查一下上周提交的报销，现在审批到哪一步了？”
要回答这个问题，光知道公司的报销制度还不够。AI 还需要查看这笔申请当前的真实状态。它可能在等待直属主管审批，也可能已经进入财务审核。
这些信息通常保存在 OA（Office Automation，办公自动化系统，用于处理请假、报销、采购和审批等办公流程的软件）里，而不是写在一份固定文档中。
那么，AI 是怎样从一句自然语言问题，变成“查询这笔报销申请”的？关键能力就是 Tool Calling。
Tool Calling（工具调用，也常称为 Function Calling，函数调用）可以理解为：模型根据用户的问题，从软件提供的可用工具中选择合适的一项，并生成这项工具需要的参数请求。随后是否真正执行、能查询哪些数据、结果怎样使用，都由外部程序按照权限和业务规则决定。
这里最容易被误解的一点是：模型并不是自己打开 OA、登录系统或点击按钮。它先提出“需要调用什么工具、需要哪些参数”，软件再决定是否执行。
先看结论
1. Tool Calling 让模型把用户意图转换成标准化的工具请求，例如“查询报销状态”以及对应的申请编号、时间范围等参数。
2. 模型只能从软件预先提供的工具中选择，不能凭空拥有查询、修改或付款权限。
3. 程序接到工具请求后，仍要完成身份识别、权限判断、参数校验和必要的人工确认，再决定是否真正执行。
4. Tool Calling 让 AI 能够参与查询和流程协作，但不等于 AI 获得自主决策权，更不等于它可以绕过企业制度。
一、会回答问题，不等于能完成一项操作
如果员工问“报销审批一般需要多久？”，AI 可以根据制度文件解释流程和时限。但如果员工问“我的报销现在到哪一步了？”，答案不在制度里，而在实时变化的业务记录中。
这两类问题看起来很像，实际需要的能力不同。前者需要查规则，后者需要查状态。
如果企业助手只会生成文字，它最多回答：“请登录 OA 系统查看审批进度。”而有了 Tool Calling，模型可以把用户的意图转成一项结构明确的请求，例如查询报销审批状态，并带上当前登录员工、提交时间范围和报销申请编号等参数。
系统拿到这份请求后，才会去查询实际数据。所以，Tool Calling 解决的不是“让模型更会说”，而是让模型能够提出可被程序执行或查询的下一步请求。
知识库问答和工具调用的区别
二、工具不是模型自己拥有的能力
为了让模型知道“有哪些事可以请求软件去做”，开发者需要先把工具说明提供给模型。一项工具通常会写清三件事。
工具能做什么
例如：查询报销审批状态、查询剩余年假、创建请假申请草稿，或者查询订单物流信息。工具名称和说明划定了模型可以提出哪些请求。模型不能自己发明一个“直接修改客户合同”的能力。
调用它需要什么信息
不同工具需要不同参数。“查询报销状态”可能需要申请编号或时间范围。“创建请假申请草稿”则可能需要开始日期、结束日期和请假类型。参数写得越清楚，模型越不容易把“下周三请一天假”理解错日期或漏掉关键信息。
谁可以使用，什么时候需要确认
工具的说明不等于授权。普通员工可以查询自己的报销进度，却不应该查询其他人的报销明细。创建请假草稿的风险较低，真正提交请假申请则可能需要用户再次确认。工具描述告诉模型“可以提出什么请求”，权限规则决定系统“是否允许执行”。
工具说明、参数和权限：模型能提出请求的边界
三、一次 Tool Calling，通常怎样发生？
仍以“查询我的报销审批进度”为例，一个简化流程通常有五步。
1. 软件提供可用工具
企业助手告诉模型：当前可以使用“查询报销审批状态”这个工具，并说明它需要哪些参数。
2. 模型判断是否需要工具
模型阅读用户问题后发现，用户问的是实时状态，不是制度规则。因此，它会尝试提出查询请求，而不是只生成一段泛泛说明。
3. 模型生成工具请求和参数
模型会选择“查询报销审批状态”，并从对话和当前登录状态中整理必要参数。如果申请编号不够明确，系统也可以要求用户补充信息，而不是让模型猜测。
4. 程序校验后执行
外部程序核对当前用户身份、工具权限和参数格式。通过后，它才向 OA 发起查询。涉及提交、删除、付款等不可逆或高风险操作时，程序还应要求用户确认。
5. 结果回到模型，再回到用户
工具返回审批节点、处理时间等结果。模型据此组织成易懂回答，例如：“你的报销申请目前在财务审核阶段，等待财务专员处理。”
这里的关键关系是：模型负责理解意图和生成请求，程序负责执行和控制权限，业务系统负责提供真实结果。
从用户提问到查询结果：Tool Calling 的五步流程
四、为什么权限和人工确认不能省？
查询一笔自己的报销进度，风险相对较低。但工具不只可以查询，也可能创建、修改或提交信息。
例如，员工说：“帮我提交明天的请假申请。”模型可以整理日期、请假类型和备注，并提出“创建请假申请”的请求。
但在真正提交前，系统至少需要再确认几件事：当前员工是否有剩余假期，日期是否符合公司规则，请假类型是否正确，这项操作会不会立即触发审批流程，以及用户是否确认提交内容。
因为一旦提交，可能影响考勤、排班和审批记录。更高风险的场景，例如修改收款账户、对外发送邮件、批准采购或发起付款，不能只因为模型“认为应该这样做”就自动执行。
企业系统需要把确认、权限分级、操作日志和异常处理放在工具执行链路中。Tool Calling 让模型可以提出动作建议，但不能把最终控制权交给模型。
低风险查询与高风险操作：为什么需要人工确认
五、Tool Calling 在企业 AI 地图中的位置
把企业 AI 的几层能力放在一起，位置会更清楚。AI 知识库帮助模型参考制度、手册和流程等稳定资料。业务系统保存审批进度、库存、订单等实时状态。
Tool Calling 让模型把用户意图转换为工具名称和参数请求。外部程序负责执行工具、验证权限和返回结果。
在这条链路里，Tool Calling 是模型和外部系统之间的“请求表达层”。它不替代业务系统，也不替代权限管理。它让模型能够把“我想查什么”“我建议做什么”转换成软件可以理解的请求格式。这也是企业 AI 从单纯回答问题，走向参与实际工作流程的重要一步。
结尾总结
回到员工的提问：“帮我查一下上周提交的报销，现在审批到哪一步了？”模型首先识别到，这不是制度解释，而是需要实时查询。它随后提出调用“查询报销审批状态”工具的请求。程序确认当前用户有权限后，查询 OA 系统，再把真实结果交回模型组织成回答。
记住一句话：Tool Calling 让模型提出工具请求，程序决定是否执行，业务系统提供真实结果。
当工具涉及提交、修改、付款或对外发送时，权限校验和人工确认不是附加步骤，而是这项能力能够安全进入企业流程的前提。
注：文章插图均由 AI 辅助生成。
星漫宇航
概念学清，项目做实，前沿看懂。复盘迭代，持续精进。