工具调用机制

一、为什么 Agent 需要工具调用

在制造场景中，用户的问题往往并不是“生成一段回答”就能解决，而是需要落到明确的业务能力上，例如：

• 查询产量
• 分析 OEE
• 识别瓶颈工位
• 统计故障分布
• 查看质量趋势

这些问题不能只依赖语言模型自由生成答案，而需要调用对应工具获取结构化结果。产线军师的 Agent 正是通过工具调用机制，把自然语言问题连接到专业分析能力、语义约束和结果解释链路上。

二、产线军师所说的“工具”是什么

这里的工具，不只是一个技术接口，而是面向业务语义封装过的能力单元，例如：

• 产量、产能、OEE、质量、故障、节拍等分析能力
• 主数据查询与对象映射能力
• 时间解析、维度补全、范围确认等辅助能力
• 知识检索、案例关联、规则增强等补充能力

因此，工具调用的重点不在“能不能调用接口”，而在“能不能把问题稳定地转成正确的业务动作”。

三、调用过程的基本流程

更完整地看，Agent 通常会经历以下步骤：

1. 识别问题中的对象、指标、时间和目标
2. 判断问题适合由哪个工具或哪组工具处理
3. 若参数不完整，则先发起澄清
4. 执行工具并获取结构化结果
5. 必要时补充知识或案例证据
6. 将结果组织为结论、图表、解释和建议

四、工具设计的核心原则

为了让 Agent 可以稳定工作，工具本身通常需要满足以下原则：

原则	说明
职责清晰	每个工具解决的问题边界应明确，不承担无限泛化职责
输入稳定	参数命名、含义和范围应清晰，避免同义混用
输出结构化	返回结果应可被进一步解释、组合和展示
语义优先	参数尽量围绕业务对象、时间和维度，而不是底层表结构
边界可控	工具应运行在预设权限和能力范围内
执行可观测	调用了什么能力、返回了什么类型结果，应可追踪和校验

五、为什么产线军师不鼓励“模型直写底层查询”

在制造场景中，如果直接把底层查询能力暴露给模型，通常会带来三类风险：

• 指标和维度口径不稳定
• 对象与时间参数更容易被误解
• 查询能力与执行边界难以按部署模式约束

因此，产线军师更强调通过业务语义能力完成调用，而不是让模型自由拼装底层实现。

六、工具调用的核心特点

1. 面向业务语义

产线军师调用的是业务语义工具，而不是把问题直接转成任意底层操作。这有助于保持指标口径稳定，也更适合制造业客户对结果一致性的要求。

2. 面向场景选择

同样是“产量”，不同上下文可能需要不同口径。Agent 会根据对象、时间、粒度和问题意图，选择更合适的工具路径。

3. 支持多步组合

复杂问题通常不是一次调用完成，而是多个步骤串联，例如：

1. 先看趋势
2. 再看分布
3. 再做对比
4. 最后生成解释

4. 支持先澄清再执行

如果对象、口径或时间范围不完整，Agent 会先补齐上下文，再进入执行链路，而不是直接给出不可靠结果。

七、为什么系统有时会调用多个工具

一个看似简单的问题，背后可能需要多种能力协同。例如：

1. 先解析“上个夜班”这样的时间表达
2. 再定位用户说的产线、工序或设备对象
3. 再调用产量或质量分析工具获取结果
4. 最后结合知识内容补充解释和建议

这类组合式调用，是 Agent 区别于单轮问答系统的重要特征。

八、工具调用与分析剧本的关系

工具调用和分析剧本相关，但不相同：

组件	关注点
工具调用机制	当前问题如何选择、组合和执行能力
分析剧本（Playbook）	在固定场景下，如何按更确定的顺序稳定执行这些能力

可以把两者理解为：

• 工具调用机制更像“执行引擎”
• Playbook 更像“标准化执行路径”

当问题具有明显的标准流程特征时，产线军师更适合让 Agent 命中对应 Playbook，而不是每次从零决定调用顺序。

九、工具调用解决了什么问题

问题	工具调用带来的变化
语言模型容易“会说不会算”	结果来自明确的业务能力
同一个问题可能有多种口径	通过场景规则选择合适能力
复杂分析链路对用户不透明	用户只提问，系统自动完成编排
底层数据结构复杂	由语义化工具屏蔽底层实现细节

十、与普通问答系统的差异

普通问答系统更偏向“给出一段回答”；产线军师的工具调用机制更强调：

• 先计算，再表达
• 先分析，再解释
• 先得到结构化结果，再组织可读输出
• 先在能力边界内执行，再生成自然语言

这也是产线军师能够在制造场景中提供更稳定结果的关键原因之一。