Function Calling 引擎解析：衡石 Data Agent 的工具调用技术机制

Article body

正文

6 分钟阅读

引言

AI Agent 的核心能力是什么？不是「会说」，而是「会做」。

一个只会说的大模型，是一个高级搜索引擎——你问它答，但它的回答不能改变任何系统状态。一个会做的 Agent，是一个数字员工——它不仅能分析问题，还能调用工具、执行操作、改变现实。

从「会说」到「会做」，关键技术桥梁就是 Function Calling（函数调用）。这是让大模型从「文本生成器」进化为「行动执行者」的核心机制。

衡石 Data Agent 内置了一套完整的 Function Calling 引擎，管理着从工具注册、意图匹配、参数生成、调用执行到结果解析的全流程。 本文将逐层拆解这套引擎的技术实现。

一、Function Calling 的基本原理

1.1 从 Prompt 到函数调用

Function Calling 的核心思路是：不让 LLM 直接输出自然语言回答，而是让它输出一个结构化的函数调用请求。

举个例子，用户问「上个月华东区的销售额是多少？」

不用 Function Calling 时，LLM 可能回答：「上个月华东区销售额约为 1250 万元。」——这个数字可能是幻觉。

用 Function Calling 时，LLM 输出的是一个结构化请求：

函数名：query_metric
参数：{ metric: “销售额”, time_range: “上个月”, region: “华东” }

系统拿到这个请求后，调用实际的查询函数，获得真实数据「12,563,400 元」，再让 LLM 基于真实数据组织语言回答。

关键转变：LLM 的角色从「答案生成者」变成了「工具选择者和参数生成者」。最终答案由工具执行结果决定，而非 LLM 的参数化知识。

1.2 Function Calling 的标准流程

完整的 Function Calling 流程分为五步：

步骤一：工具注册。系统预先注册所有可用的函数，每个函数包含名称、描述、参数 Schema（JSON Schema 格式）。

步骤二：意图匹配。用户问题进来后，LLM 根据函数描述判断应该调用哪个函数。函数描述的质量直接决定匹配准确率。

步骤三：参数生成。LLM 从用户问题中提取参数值，按 JSON Schema 格式组装。比如从「上个月」提取出日期范围，从「华东区」提取出区域过滤条件。

步骤四：函数执行。系统调用实际的函数实现，传入 LLM 生成的参数。函数执行在安全沙箱中进行。

步骤五：结果解析。函数返回结果后，LLM 基于结果生成自然语言回答。如果结果是结构化数据（表格、图表），LLM 组织描述性文本；如果结果是错误信息，LLM 做错误解释和重试建议。

二、衡石 Data Agent 的工具注册体系

2.1 工具 Schema 设计

衡石 Data Agent 的每个工具都有标准化的 Schema 定义，包含以下字段：

基础信息：

工具名称：全局唯一标识符
显示名称：面向用户的可读名称
描述文本：告诉 LLM 这个工具做什么、什么时候用。这是影响意图匹配准确率的最关键字段

参数定义：

参数名称、类型、是否必填
参数描述：告诉 LLM 这个参数代表什么、怎么从用户问题中提取
枚举值约束：某些参数只能取预定义的值（如图表类型只能是柱状图/折线图/饼图）
默认值：参数未提供时的兜底值

返回格式：

返回类型：数据表、标量值、图表配置、文件链接
返回 Schema：结构化返回的字段定义

2.2 工具分类与层级

衡石 Data Agent 的工具按功能域分为四大类，每类下有多条具体工具：

数据查询类：

query_dataset：按数据集和过滤条件查询明细数据
aggregate_metric：按指标和维度做聚合查询
compare_periods：做时间区间对比（同比/环比）
rank_entities：按指标对实体做排行

分析推理类：

detect_anomaly：检测时间序列中的异常点
find_correlation：发现两个指标之间的相关性
segment_analysis：按维度做分群分析
root_cause_analysis：对指标变动做归因分析

可视化类：

create_chart：生成单张图表
compose_dashboard：组合多张图表为仪表盘
apply_chart_style：应用图表样式模板

协作操作类：

export_report：导出分析报告（PDF/Excel/图片）
send_notification：推送分析结果到通知渠道
create_alert：创建数据告警规则

2.3 动态工具注册

并非所有工具都对所有用户可见。衡石支持动态工具注册——根据当前用户的角色、权限、所属租户，动态生成可用工具列表。

比如普通业务用户只能看到「查询」「可视化」「导出」类工具，管理员额外可见「创建告警」「管理订阅」类工具。这种动态裁剪不仅做安全控制，还减少了 LLM 的选择空间，提高了意图匹配准确率。

三、意图匹配与参数生成

3.1 多工具选择策略

用户的一句话可能需要调用多个工具。比如「帮我分析上个月销售额下降的原因，并生成一份报告」——这需要先做根因分析，再导出报告。

衡石 Data Agent 的多工具选择策略：

串行依赖检测：LLM 分析工具间的依赖关系。如果工具 B 的参数需要工具 A 的返回结果，则标记为串行依赖，先生成 A 的调用计划，等 A 返回后再生成 B 的调用。

并行独立检测：如果两个工具没有依赖关系（如「同时查华东和华北的销售额」），生成并行调用计划，同时发起两个函数调用，减少总等待时间。

条件分支检测：某些场景下，下一步操作依赖上一步结果。如「如果销售额下降超过 10%，触发告警」——LLM 生成条件判断逻辑，系统在执行时动态决定是否进入告警分支。

3.2 参数提取的精确性保障

参数提取是 Function Calling 中最容易出错的环节。常见问题：

时间表达歧义：「上个月」是自然月还是滚动 30 天？「最近一周」是含今天还是不含？衡石的方案是在参数 Schema 中嵌入时间解析规则，LLM 输出原始时间表达后，由专门的日期解析器做标准化转换。

实体名称模糊：「华东区」在不同企业可能指不同范围。衡石通过指标语义层的实体映射表，把用户口中的「华东区」映射为系统中的标准区域编码。

数值单位遗漏：用户说「销售额 1250」，是指 1250 元、1250 万、还是 1250 千？衡石在参数描述中标注默认单位，同时在结果返回时强制带单位，避免歧义。

3.3 参数校验与错误恢复

LLM 生成的参数不一定正确——可能类型错误、值越界、枚举不匹配。衡石的两层校验：

Schema 校验：参数提交到函数前，先过 JSON Schema 校验。类型不对、必填缺失、枚举值非法等问题在这一层拦截。

语义校验：Schema 校验通过后，进入业务语义校验。比如「查询 2025 年 13 月的数据」语法正确但语义错误（没有 13 月），「查询负数的销售额」数值合法但业务不合理。语义校验规则由各工具自行定义。

错误恢复：校验失败后，系统不直接报错给用户，而是把错误信息回传给 LLM，让 LLM 做修正重试。比如 LLM 生成了 region: "华东" 但系统中标准值是 region: "east_china"，系统返回错误「区域参数不合法，可选值为 east_china, south_china, …」，LLM 修正后重新提交。

四、函数执行引擎

4.1 执行沙箱

函数执行在隔离的沙箱环境中进行，确保安全：

SQL 注入防护：所有涉及 SQL 查询的函数，参数化传入而非字符串拼接。即使用户问题中包含恶意 SQL 片段，也不会被拼入查询语句。

资源限制：每个函数调用有 CPU 时间上限（30 秒）、内存上限（512MB）、返回行数上限（10000 行）。超限自动终止并返回友好错误信息。

网络隔离：协作操作类工具（如发通知）需要网络访问，执行时通过白名单代理出站，防止数据外泄到未授权地址。

4.2 异步执行与流式返回

某些工具执行时间较长（如大数据量查询、报告导出），同步等待会导致用户长时间无响应。衡石支持异步执行模式：

工具调用后立即返回任务 ID，用户看到「正在查询中…」的进度提示
后台异步执行，完成后通过 WebSocket 推送结果
对于特别长的任务（如全量导出），支持完成后通过通知渠道推送下载链接

4.3 结果缓存与复用

如果两个用户问了相同的问题，或者同一用户在短时间内重复问了类似问题，函数不需要重复执行：

缓存 Key = 函数名 + 参数哈希
缓存有效期按工具类型配置（查询类 5 分钟、分析类 30 分钟、导出类不缓存）
缓存命中时直接返回结果，跳过执行环节

五、从单工具到工具链：Agentic 工作流

5.1 工具链编排

单工具调用解决简单问题，复杂分析需要多工具协作。衡石 Data Agent 的工具链编排能力：

线性链：工具 A → 工具 B → 工具 C。前一个工具的输出作为后一个的输入。如：查询数据 → 检测异常 → 生成报告 → 发送通知。

分支链：工具 A 的结果决定走 B 还是 C。如：查询销售额 → 判断是否下降超过阈值 → 是则触发告警工具 / 否则记录正常状态。

循环链：工具 A 的结果决定是否再次调用 A。如：分页查询数据 → 判断是否还有下一页 → 是则查询下一页 / 否则合并所有结果。

5.2 动态重规划

工具链不是预先定义的固定流程，而是 Agent 在执行过程中动态规划的。当某个工具返回意外结果时，Agent 会重新评估后续步骤：

场景示例：Agent 计划查询「华南区」的销售数据，但查询结果返回空。Agent 分析原因——可能是「华南区」在系统中不存在，或者该区域确实没有数据。Agent 重新规划：先查询系统中的区域列表，发现标准名称是「华南片区」而非「华南区」，修正参数后重新查询。

这种动态重规划能力是 Agentic BI 区别于传统固定流程 BI 的核心——它能在执行过程中自适应，而非死板地按预设路径走。

六、效果与优化

6.1 工具选择准确率

衡石 Data Agent 在内部测试集上的工具选择准确率为 94.7%。错误案例分析显示，主要错误类型：

工具描述不够清晰：LLM 在两个功能相近的工具间犹豫。优化方向是细化工具描述，增加「使用场景」和「不适用场景」说明
多工具混淆：用户问题涉及多个工具，LLM 遗漏了其中一个。优化方向是在 Prompt 中增加「请检查是否有遗漏的工具调用」的自我审查环节
参数提取错误：时间表达和实体名称的提取错误。优化方向是增强参数描述和增加语义校验

6.2 端到端延迟优化

Function Calling 的端到端延迟由三部分组成：

LLM 推理（意图匹配 + 参数生成）：平均 1.2 秒
函数执行：平均 0.8 秒（查询类）/ 3-5 秒（分析类）
结果解析与回答生成：平均 0.6 秒

优化手段：

工具描述精简：减少 Prompt 中工具列表的 Token 数，降低 LLM 推理时间
并行执行：独立工具并行调用，总延迟取最长而非累加
结果缓存：高频问题命中缓存时跳过函数执行

七、总结

Function Calling 是 AI Agent 从「会说」到「会做」的核心技术。它的本质是把 LLM 的语言理解能力与确定性工具的精确执行能力结合起来——LLM 负责「理解意图、选择工具、生成参数」，工具负责「精确执行、返回事实」。

衡石 Data Agent 的 Function Calling 引擎，三个核心设计点：

动态工具注册：按用户角色和权限裁剪工具空间，提高匹配准确率
多工具编排：支持线性、分支、循环三种工具链模式，覆盖复杂分析场景
动态重规划：执行过程中根据实际结果自适应调整后续步骤

当一个 BI 系统的工具调用从「单次函数执行」进化为「自主工具链编排」，它就从「智能问答」跨入了「智能代理」的门槛。