工具调用
一、为什么 Agent 需要工具调用
在制造场景中，用户的问题往往并不是“生成一段回答”就能解决，而是需要落到明确的业务能力上，例如：
- 查询产量
- 分析 OEE
- 识别瓶颈工位
- 统计故障分布
- 查看质量趋势
这些问题不能只依赖语言模型自由生成答案，而需要调用对应工具获取结构化结果。产线军师的 Agent 正是通过工具调用机制，把自然语言问题连接到专业分析能力、语义约束和结果解释链路上。
二、产线军师所说的“工具”是什么
这里的工具，不只是一个 技术接口，而是面向业务语义封装过的能力单元，例如：
- 产量、产能、OEE、质量、故障、节拍等分析能力
- 主数据查询与对象映射能力
- 时间解析、维度补全、范围确认等辅助能力
- 知识检索、案例关联、规则增强等补充能力
因此，工具调用的重点不在“能不能调用接口”，而在“能不能把问题稳定地转成正确的业务动作”。
三、调用过程的基本流程
更完整地看，Agent 通常会经历以下步骤：
- 识别问题中的对象、指标、时间和目标
- 判断问题适合由哪个工具或哪组工具处理
- 若参数不完整，则先发起澄清
- 执行工具并获取结构化结果
- 必要时补充知识或案例证据
- 将结果组织为结论、图表、解释和建议
四、工具设计的核心原则
为了让 Agent 可以稳定工作，工具本身通常需要满足以下原则：
| 原则 | 说明 |
|---|---|
| 职责清晰 | 每个工具解决的问题边界应明确，不承担无限泛化职责 |
| 输入稳定 | 参数命名、含义和范围应清晰，避免同义混用 |
| 输出结构化 | 返回结果应可被进一步解释、组合和展示 |
| 语义优先 | 参数尽量围绕业务对象、时间和维度，而不是底层表结构 |
| 边界可控 | 工具应运行在预设权限和能力范围内 |
| 执行可观测 | 调用了什么能力、返回了什么类型结果，应可追踪和校验 |
五、为什么产线军师不鼓励“模型直写底层查询”
在制造场景中，如果直接把底层查询能力暴露给模型，通常会带来三类风险：
- 指标和维度口径不稳定
- 对象与时间参数更容易被误解
- 查询能力与执行边界难以按部署模式约束
因此，产线军师更强调通过业务语义能力完成调用，而不是让模型自由拼装底层实现。
六、工具调用的核心特点
1. 面向业务语义
产线军师调用的是业务语义工具，而不是把问题直接转成任意底层操作。这有助于保持指标口径稳定，也更适合制造业客户对结果一致性的要求。
2. 面向场景选择
同样是“产量”，不同上下文可能需要不同口径。Agent 会根据对象、时间、粒度和问题意图，选择更合适的工具路径。
3. 支持多步组合
复杂问题通常不是一次调用完成，而是多个步骤串联，例如：
- 先看趋势
- 再看分布
- 再做对比
- 最后生成解释
4. 支持先澄清再执行
如果对象、口径或时间范围不完整，Agent 会先补齐上下文，再进入执行链路，而不是直接给出不可靠结果。
七、为什么系统有时会调用多个工具
一个看似简单的问题，背后可能需要多种能力协同。例如：
- 先解析“上个夜班”这样的时间表达
- 再定位用户说的产线、工序或设备对象
- 再调用产量或质量分析工具获取结果
- 最后结合知识内容补充解释和建议
这类组合式调用，是 Agent 区别于单轮问答系统的重要特征。
八、工具调用与分析剧本的关系
工具调用和分析剧本相关，但不相同：
| 组件 | 关注点 |
|---|---|
| 工具调用机制 | 当前问题如何选择、组合和执行能力 |
| 分析剧本（Playbook） | 在固定场景下，如何按更确定的顺序稳定执行这些能力 |
可以把两者理解为：
- 工具调用机制更像“执行引擎”
- Playbook 更像“标准化执行路径”
当问题具有明显的标准流程特征时，产线军师更适合让 Agent 命中对应 Playbook，而不是每次从零决定调用顺序。
九、工具调用解决了什么问题
| 问题 | 工具调用带来的变化 |
|---|---|
| 语言模型容易“会说不会算” | 结果来自明确的业务能力 |
| 同一个问题可能有多种口径 | 通过场景规则选择合适能力 |
| 复杂分析链路对用户不透明 | 用户只提问，系统自动完成编排 |
| 底层数据结构复杂 | 由语义化工具屏蔽底层实现细节 |
十、与普通问答系统的差异
普通问答系统更偏向“给出一段回答”；产线军师的工具调用机制更强调：
- 先计算，再表达
- 先分析，再解释
- 先得到结构化结果，再组织可读输出
- 先在能力边界内执行，再生成自然语言
这也是产线军师能够在制造场景中提供更稳定结果的关键原因之一。