工具调用与 Workflow

「产品经理的大模型基础」系列之六
上一篇：Embedding 与 RAG · 系列入口 · 下一篇：Agent 的基本原理

大模型本身主要负责理解和生成内容。即使它知道怎样查询天气、创建任务或计算退款金额，也不会仅凭一段文字就自动改变外部系统。

要让模型真正读取数据或执行动作，需要为它提供工具。要让多个模型调用、工具和程序检查稳定地连接起来，则需要 Workflow。

一、什么是工具调用

工具调用也常被称为 Tool Calling 或 Function Calling。

系统会向模型说明当前有哪些工具，每个工具做什么、需要哪些参数。模型根据用户意图，决定是否提出一个工具调用请求。

例如，一个查询订单工具可能被描述为：

{
  "name": "get_order",
  "description": "根据订单编号查询订单状态",
  "parameters": {
    "order_id": "string"
  }
}

当用户问“订单 A1024 发货了吗”，模型可以生成一个结构化请求：

{
  "name": "get_order",
  "arguments": {
    "order_id": "A1024"
  }
}

程序收到请求后，验证参数与权限，真正查询订单系统，再把结果返回模型。模型最后把系统结果解释给用户。

二、模型怎样选择工具和生成参数

模型并不是直接看见后端代码。每次调用时，它通常看到的是工具的名称、用途说明和参数 Schema，然后像生成其他内容一样，生成一个符合约定结构的工具请求。

这意味着工具定义本身也是上下文的一部分。以下设计会直接影响选择质量：

• 名称是否清楚：get_order_status 比 handle_order 更具体。
• 用途是否互斥：查询订单与取消订单不应使用含糊、重叠的说明。
• 参数是否有语义：说明 order_id 的格式、必填条件和允许范围。
• 工具数量是否克制：几十个相似工具同时出现，会增加选错概率，也占用上下文。
• 返回和错误是否明确：区分“订单不存在”“无权限”和“服务暂时不可用”。

参数生成同样是概率性的。模型可能把用户口中的日期理解错、遗漏必填字段，甚至编造一个不存在的 ID。因此，Schema 只能帮助约束结构，后端仍要验证类型、范围、资源是否存在以及当前用户是否有权操作。

大白话说，工具说明像给模型看的操作菜单：菜单写得含糊，模型就容易点错菜；但即使点单格式正确，厨房仍要核对库存、价格和权限。

三、模型提出调用，程序负责执行

这是工具调用中最重要的边界。

模型可以判断应该使用哪个工具，也可以从自然语言中提取参数。但模型生成的调用请求仍然是不可信输入，程序必须负责：

• 检查工具名称是否允许。
• 验证参数格式和取值范围。
• 判断当前用户是否有权限。
• 防止重复执行。
• 处理超时和错误。
• 记录真实执行结果。

例如，模型从用户话语中提取了退款金额，后端仍然应该根据订单和政策重新计算，而不能直接相信模型给出的数字。

四、只读工具和写入工具

工具的风险并不相同。

只读工具主要查询信息，例如搜索文档、查询订单、读取项目状态。写入工具会改变外部状态，例如创建任务、发送邮件、删除文件和发起付款。

可以按照风险采用不同策略：

权限不应只写在提示词中。模型即使被要求“不要执行危险操作”，也不能替代程序层的访问控制。

五、工具结果怎样返回给模型

工具执行后，系统通常会把结果作为新的上下文交给模型。例如：

{
  "order_id": "A1024",
  "status": "shipped",
  "carrier": "Example Express"
}

模型根据这个真实结果生成自然语言：

订单 A1024 已经发货，承运方为 Example Express。

模型不需要记住所有业务状态，只需要知道何时调用工具、怎样理解工具返回的数据，以及怎样向用户解释。

这种结构形成了清晰分工：业务系统保存事实，工具提供接口，模型负责自然语言交互。

六、什么是 Workflow

Workflow 是按照预先设计的步骤和分支，编排程序、模型、工具和人工节点的流程。

例如，把一段需求文字转换成任务，可以设计为：

读取需求
→ 提取标题、背景和验收条件
→ 判断需求类型
→ 根据类型选择任务模板
→ 生成任务草稿
→ 程序检查必填字段
→ 用户确认
→ 调用任务系统创建任务

其中，“理解需求”和“生成草稿”适合模型；“检查字段”适合程序；“创建任务”通过工具执行；“最终确认”由人完成。

Workflow 的价值，是把一次模型能力放进一个稳定的业务过程。

七、Workflow 中常见的流程结构

顺序执行

一个步骤完成后，再进入下一步。适合前后依赖明确的任务。

条件分支

根据分类或规则选择不同路径。例如投诉、退款和技术问题进入不同处理流程。

并行处理

多个相互独立的子任务同时执行。例如分别分析价格、体验和竞品反馈，最后合并结果。

重试与降级

某一步失败后有限重试；持续失败时改用简单方案、保存草稿或交给人工。

人工确认

在高风险或主观判断节点暂停，让用户确认参数或选择方案。

这些结构大多是普通软件工程中的成熟概念。大模型只是成为 Workflow 中的一种新节点。

八、为什么任务拆解在 Workflow 中很重要

如果让模型一次完成“读取需求、分类、生成任务并创建”，一旦结果错误，很难判断问题发生在哪里。

拆开后可以分别观察：

• 模型是否正确提取需求信息。
• 分类是否正确。
• 任务字段是否完整。
• 用户是否确认。
• 工具是否真正创建成功。

中间结果不仅便于排错，也允许不同步骤使用不同模型或确定性程序。简单分类可能使用成本较低的能力，复杂生成使用更强模型，字段校验则完全不需要模型。

九、Workflow 的状态与错误处理

多步流程需要知道自己运行到哪里，这就是状态。

状态可能包括：

• 原始需求。
• 已提取的字段。
• 分类结果。
• 生成的任务草稿。
• 用户是否确认。
• 工具调用结果。
• 当前步骤和错误信息。

如果创建任务时网络失败，系统不应重新从头分析需求，而应保留前面结果，从失败节点继续。若工具实际上已经执行成功但响应丢失，还要避免重复创建任务，这类能力称为幂等控制。

重试也要按错误类型设计：网络波动、超时和部分 5xx 错误适合在间隔递增的情况下有限重试；参数错误、权限不足和业务规则冲突，重复相同请求通常没有意义。对写入操作，可以使用幂等键（Idempotency Key）或业务唯一标识，避免“第一次已经成功，只是响应丢了”时又创建一份相同数据。

十、Workflow 与普通自动化的区别

Workflow 并不是大模型专属概念。传统审批、订单和数据处理系统早就在使用流程编排。

大模型带来的变化是：一些过去难以用规则表达的步骤，现在可以由模型处理，例如理解自然语言、归纳信息和生成文本。但流程中的状态、权限、重试、审计和恢复，依然属于传统软件工程问题。

因此，一个稳定的 AI Workflow 通常是“概率模型节点 + 确定性程序骨架”，而不是让模型自由处理一切。

十一、Workflow 与 Agent 的关系

Workflow 的路径主要由设计者预先定义。即使有分支，分支范围也比较明确。

Agent 则让模型在运行过程中根据中间结果决定下一步，路径更灵活，也更难预测。两者并没有高低之分：步骤固定的任务通常更适合 Workflow；只有当任务路径无法提前确定时，Agent 才可能带来额外价值。

本篇小结

这篇文章最重要的关系是：

工具让模型能够提出读取或改变外部系统的请求；工具定义影响模型怎样选择和填写参数；程序负责验证与真正执行；Workflow 再把模型、工具、规则、状态和人工节点组织成稳定流程。

下一篇将在 Workflow 基础上进入 Agent，重点理解状态、计划、记忆、循环和停止条件，以及 Agent 为什么不是“会调用工具的聊天机器人”这么简单。

上一篇：Embedding 与 RAG　下一篇：Agent 的基本原理