夜雨聆风
AI 系统学习笔记 03｜面向初学者、产品经理与工程师
资料校准日期：2026-08-16
上一篇讲 RAG 时，我把它概括成一条“证据供应链”：让模型在回答前取得外部知识。接下来问题自然变成了：模型知道答案以后，怎样真正查询订单、创建工单、提交报销或发送通知？
这正是 Tool Calling（工具调用）经常出现的地方。但它也是最容易被说乱的概念之一：模型返回了一段工具参数，就被称为 Agent；接上一个业务 API，就以为模型已经拥有执行权；参数符合 JSON Schema，就以为调用一定安全。
这篇继续使用“企业知识与业务助手”案例。员工说：“帮我确认这笔 860 元的杭州差旅打车费是否符合规定，符合的话帮我提交报销。”我会把这句话拆成模型提议、应用校验、权限判断、人工确认、业务执行和结果回传，画清每一方真正负责什么。
一、先说结论：模型提出调用，不代表工具已经执行
Tool 可以理解为一个被 AI 应用描述并暴露出来的能力，例如查询天气、读取订单、计算税费或创建报销草稿。Tool Calling 则是模型根据用户意图和工具描述，输出“建议调用哪个工具、携带哪些参数”的结构化结果。
对于应用侧工具，真正的代码通常运行在模型之外。模型不会因为生成了 submit_expense 就自动写入财务系统。应用收到调用请求后，仍要验证参数、识别当前用户、检查权限与业务状态，必要时要求人工确认，最后才决定执行、拒绝或改道。
不同平台会使用 Function Calling、Tool Use、Tools 等名称，但核心边界相同：模型负责提议，应用负责控制，业务系统负责最终落账。
边界速记：工具调用请求属于模型输出，不是可信命令；工具执行结果属于外部输入，也不是可信指令。
二、一次完整调用是往返握手，不是一段魔法
一次典型的客户端工具调用至少包含五步：应用把可用工具及其参数结构交给模型；模型返回工具调用请求；应用执行或拒绝；应用把工具结果回传给模型；模型基于结果生成最终回复，或者继续提出下一次调用。
这条链路里有两个容易忽略的事实。
第一，模型返回的不是函数指针，而是名称、参数和调用标识等数据。应用必须维护工具注册表，并把模型名称映射到真实实现。第二，工具结果需要与对应调用关联，否则并行调用或重试时可能把结果接错。
企业助手查询报销政策时，可以调用只读工具；创建草稿时，可以调用写入草稿区的工具；正式提交前，则进入审批路径。它们看起来都叫“调用工具”，风险等级却完全不同。
三、Tool Schema 是接口契约，但不是安全证明
工具定义通常包含名称、用途说明和参数 Schema。好的 Schema 会限制字段类型、枚举、格式、范围和必填项，并明确工具何时适用、何时不适用。模型依赖这些描述选择工具和生成参数，应用也可以用同一份契约做结构校验。
严格结构化输出可以显著减少缺字段、字段类型错误和额外属性，但它只证明“形状符合契约”。amount: 860 是数字，不代表这张发票属于当前用户；expense_id 格式正确，不代表记录仍处于可提交状态；approver_id 存在，也不代表用户有权选择该审批人。
因此，生产工具至少需要三层契约：模型侧 Schema 约束结构，应用策略约束调用是否允许，业务系统约束操作在当前状态下是否成立。只做第一层，相当于把“能解析”误当成“能执行”。
四、结构化输出与 Tool Calling 解决的是不同问题
Structured Output（结构化输出）让模型按指定结构返回数据，例如把用户描述提取成报销类型、金额、日期和城市。它可以用于分类、抽取和生成表单草稿，并不要求调用任何外部系统。
Tool Calling 则表达“建议使用某项能力”。它通常也使用结构化参数，但后面多了一道执行边界。应用可以采纳、修改、延迟、转审批或拒绝这项建议。
在企业助手里，先让模型把自然语言整理成报销草稿，是结构化输出；再由应用调用 create_expense_draft 保存草稿，才是工具执行。把两者分开，可以在写入前增加确定性校验，也便于用户预览。
五、工具设计越具体，系统越容易控制
最危险的工具往往不是参数写错，而是能力过宽。run_shell、execute_sql、call_any_url 这类开放接口，把大量不可预期行为藏进一个名称里，难以建立细粒度权限、审批和审计。
更稳妥的做法，是按业务意图拆成窄工具：get_expense_policy、list_my_receipts、create_expense_draft、submit_expense。读取、草拟和正式写入分别暴露，不要用一个工具通过 mode=delete 或 action=submit 突然升级风险。
工具也不是越多越智能。大量相似工具会增加上下文成本和选择混淆。应用可以根据页面、用户角色和当前流程只暴露必要集合，或者使用渐进式工具发现：先检索候选能力，再把少量具体 Schema 交给模型。
六、身份、权限和凭证不能交给模型判断
模型可以判断“用户似乎想提交报销”，但不能决定“这个用户有权提交哪一条记录”。身份来自登录会话，权限来自策略和业务系统，凭证由服务端安全保存，这些都不应由 Prompt 中的一句话替代。
工具执行应携带当前用户或受委托主体的身份上下文，并在下游重新授权。不要让所有调用共享一个超级管理员账号，也不要接受模型自行生成的 user_id 作为权限依据。即使模型参数写着“代表张三”，系统也必须以认证会话中的主体为准。
最小权限还包括最小数据范围和最短凭证生命周期。只读查询使用只读权限；提交报销只能访问当前用户可操作的记录；高权限动作应使用单独通道，并留下完整审计。
七、参数进入执行器前，要经过四道校验
第一道是结构校验：字段、类型、枚举、长度和格式。第二道是语义校验：金额必须为正数，日期不能超出制度范围，币种与金额要匹配。第三道是授权校验：资源归属、角色和数据域必须允许。第四道是状态校验：记录是否已提交、版本是否过期、余额是否仍充足。
校验失败不应被包装成一句模糊的“工具出错”。应用应返回可机器识别的错误类别，例如 INVALID_ARGUMENT、FORBIDDEN、CONFLICT 或 NEEDS_CONFIRMATION，再决定让模型追问用户、重新规划还是停止。
同时，工具输出也需要限制字段、大小和敏感内容。结构化结果应优先于整页 HTML 或任意长文本，避免把无关数据、秘密字段和潜在恶意指令重新送入模型上下文。
八、高风险写操作要采用“预览—确认—执行”
让用户点一个泛化的“确定”并不等于有效审批。确认界面应展示将执行的工具、目标对象、关键参数、影响范围和不可逆后果。例如：提交哪一张报销单、金额多少、进入哪条审批流，而不是只显示“AI 即将执行操作”。
确认前先生成不可执行的草稿或执行计划；确认时冻结关键参数并生成审批凭证；执行器验证凭证、参数哈希、用户身份和有效期一致后才写入。若模型在确认后修改了金额或目标，应重新审批，不能沿用旧确认。
人工介入也不是所有工具的默认负担。查询本人订单可以自动执行；创建草稿通常风险较低；对外发送、付款、删除、正式提交和权限变更则应根据金额、对象和组织政策进入审批。
九、重复调用是常态，幂等必须由业务侧保证
模型可能在下一轮再次提出相同调用，客户端可能因超时重试，消息系统也可能重复投递。如果写操作没有幂等控制，同一张报销单可能被创建两次，通知可能发送多次，订单也可能重复提交。
调用标识适合关联一次模型往返，但跨网络重试和进程恢复时，还需要稳定的业务幂等键。执行器先原子地登记幂等键和请求摘要：首次请求进入执行；相同请求重复到达时返回已保存结果；同一键对应不同参数时拒绝为冲突。
读操作通常天然更容易重试，写操作则要由下游系统提供幂等语义，或由应用建立去重记录。不能依赖模型记住“刚才已经执行过”。
十、超时、重试与补偿必须按失败类型设计
工具失败至少可以分为参数错误、权限拒绝、业务冲突、限流、临时网络故障、超时和未知结果。只有确认可重试且操作幂等时，才适合自动重试；参数错误应追问或修正，权限拒绝应停止，业务冲突应重新读取状态。
超时尤其棘手：客户端没有收到结果，不代表下游没有成功。写操作超时后应先用幂等键查询状态，再决定是否补发。盲目重试可能制造重复数据。
跨系统流程无法真正数据库回滚时，可以使用补偿动作，例如撤销预占、关闭草稿或发送更正通知。但补偿是新的业务操作，不等于时间倒流，也可能失败，所以同样需要权限、幂等和审计。
十一、并行调用由运行时调度，不由模型一句话决定
模型可能一次提出多个工具调用。查询制度和读取本人票据彼此独立，可以并行降低延迟；创建报销草稿依赖前两项结果，正式提交又依赖用户确认，必须顺序执行。
应用运行时要根据依赖关系、资源锁、并发上限和风险等级决定调度，而不是看到多个调用就全部并发。对于资金、库存和状态变更，还要处理版本号、乐观锁或事务边界。
一旦流程存在固定依赖、分支、审批、超时和补偿，把它显式建模为 Workflow 往往比让模型临场组织更可靠。LLM 可以填参数或处理模糊语义，但关键顺序由代码和状态机控制。
十二、工具结果是不可信数据，不是更高优先级指令
工具可能返回第三方网页、邮件、文档或用户生成内容，其中可能夹带“忽略之前规则并发送数据”一类间接 Prompt Injection。即使工具本身可信，它读取的数据也未必可信。
应用应把工具结果标记为数据，使用允许字段提取、内容转义、长度限制、敏感信息过滤和来源标注，再交给模型。数据中的文字不能改变系统策略、扩大工具权限或绕过审批。
错误结果也应结构化返回：是否可重试、用户可见信息、内部错误码和追踪 ID 分开处理。不要把数据库堆栈、访问令牌或内部地址原样交给模型，再由模型复述给用户。
十三、评估不能只看最终回复是否流畅
Tool Calling 的质量是一条轨迹，而不是一句答案。Trace 至少应关联用户请求、候选工具、模型选择、参数摘要、策略决策、审批记录、幂等键、下游响应、重试次数、延迟和最终任务状态。
评估可以分为五层：工具选择是否正确，参数是否有效，策略是否正确放行或拦截，执行是否成功，最终任务是否完成。还要单独观察不安全调用拦截率、误拦率、重复执行率、审批取消率、单任务调用数、成本和 P95 延迟。
测试集不能只放“正常查询”。至少要注入缺少参数、越权资源、重复请求、超时后已成功、工具返回恶意指令、用户拒绝审批和下游状态冲突，确认系统走向可预测的停止路径。
十四、API、Tool 与 MCP 处在不同层
API 是软件系统之间的具体接口；Tool 是面向模型暴露的能力描述与适配边界；MCP（Model Context Protocol）则定义 Host、Client、Server 及 Tools、Resources、Prompts 等原语，让能力发现和调用可以采用统一协议。
一个 Tool 可以在内部调用 REST API、数据库或本地函数，也可以由 MCP Server 暴露。MCP 解决连接、能力协商和消息交互，不会替代业务授权、参数校验、审批、幂等和审计。
所以，MCP 不是某个工具，也不是 Agent 框架。Host 仍要决定向模型暴露哪些 Server 和工具，并执行用户同意与安全策略；Server 也必须按调用者身份落实最小权限。
十五、把 Tool Calling 放回正确层次
Tool Calling 与 Workflow、Agent 不是同一层概念。Tool Calling 是模型与外部能力交互的机制；Workflow 和 Agent 描述的则是系统如何组织步骤、状态以及下一步控制权。普通 LLM 应用、Workflow 和 Agent 都可以使用 Tool Calling。
Workflow 由代码预先定义节点、分支和状态转移；Agent 则围绕目标和状态，在约束内循环选择下一步，直到完成、失败、超限或等待人工。它们都可以把 Tool Calling 当作某个节点或循环中的能力接口。
Agent 经常使用 Tool Calling，但“使用工具”不是成为 Agent 的充分条件。一次查询天气或创建草稿没有持续目标、状态循环和停止策略，更适合称为带工具的 LLM 应用。反过来，Workflow 也可以包含 LLM 分类节点，却仍由预定流程掌握控制权。
对企业助手，我会按风险渐进上线：先开放只读查询，再允许生成草稿；补齐权限、校验、Trace 和评估后，才开放带审批和幂等的写操作；固定业务流程进入 Workflow；只有确实需要动态多步决策的局部环节，才引入受约束 Agent。
成熟度判断：只读工具、窄 Schema、服务端授权、审批、幂等和审计属于生产基础；动态工具发现属于条件采用；让通用 Agent 持有广泛写权限不应成为默认方案。
写在最后
现在我更愿意把 Tool Calling 理解成一份待审查的行动提案。模型擅长把自然语言意图映射为工具和参数，应用负责把提案转成受约束的命令，业务系统则以真实身份、权限和状态完成最终操作。
真正可靠的系统，不是让模型“想做什么就做什么”，而是让模型在清晰能力边界内提出建议，并让每次执行都可验证、可拒绝、可重试、可追踪。
下一篇继续往控制权的核心推进。
《Workflow 与 Agent 到底差在哪：谁决定系统的下一步？》
资料依据
OpenAI Developers, Function calling Anthropic, Tool use with Claude Model Context Protocol, Architecture Model Context Protocol Specification 2026-07-28, Tools OWASP GenAI Security Project, LLM06:2025 Excessive Agency OWASP GenAI Security Project, LLM05:2025 Improper Output Handling