8.3 工具执行与结果处理

8.3.1 工具执行流程

spinner

8.3.2 参数验证

在执行前验证参数的有效性:

def validate_params(tool_name, params, schema):
    # 检查必需参数
    for required in schema.get("required", []):
        if required not in params:
            raise ValueError(f"缺少必需参数: {required}")
    
    # 检查参数类型
    for key, value in params.items():
        expected_type = schema["properties"][key]["type"]
        if not isinstance(value, TYPE_MAP[expected_type]):
            raise TypeError(f"参数 {key} 类型错误")
    
    # 检查枚举值
    for key, value in params.items():
        if "enum" in schema["properties"][key]:
            if value not in schema["properties"][key]["enum"]:
                raise ValueError(f"参数 {key} 值无效")

8.3.3 执行策略

同步执行

简单场景,等待执行完成:

异步执行

IO 密集型或耗时操作:

超时控制

防止工具执行无限等待:

8.3.4 结果格式化

将工具结果格式化为模型易理解的形式:

简洁输出

包含上下文

8.3.5 错误处理

工具执行可能失败,需要优雅处理:

错误类型分类

错误类型
处理方式
反馈给模型

参数错误

不执行

说明具体问题

执行失败

记录日志

返回错误信息

超时

终止执行

建议稍后重试

权限不足

拒绝执行

说明权限要求

错误信息模板

8.3.6 结果注入上下文

工具结果需要正确注入对话上下文:

8.3.7 结果压缩

工具返回大量数据时可能需要压缩:

8.3.8 多轮工具调用

复杂任务可能需要多轮工具调用:

spinner

每轮结果都成为上下文的一部分,影响后续决策。

8.3.9 安全考虑

工具执行涉及安全风险:

  1. 输入验证:防止注入攻击

  2. 权限控制:验证操作权限

  3. 操作审计:记录敏感操作

  4. 确认机制:危险操作需人工确认

8.3.10 高级工具执行技术

随着智能体需要使用的工具数量增长,传统的工具调用方式面临挑战。以下介绍两项高级技术:

Tool Search Tool(工具搜索工具)

问题:当连接多个 MCP 服务器时,工具定义可能消耗大量 Token:

  • GitHub(35 工具):约 26K Token

  • Slack(11 工具):约 21K Token

  • 总计 50+ 工具可能消耗 55K+ Token

解决方案:不预加载所有工具,而是按需发现。

效果

  • Token 使用从 77K 降至 8.7K(节省约 85%)

  • 工具选择准确率显著提升

Programmatic Tool Calling(编程式工具调用)

问题:传统工具调用有两个瓶颈:

  1. 中间结果污染上下文(分析 10MB 日志文件,全部进入上下文)

  2. 每次调用需要一次推理,开销大

解决方案:让模型通过代码编排工具,而非逐个 API 调用。

效果

  • 上下文只接收最终结果(1KB),而非原始数据(200KB)

  • Token 消耗降低约 37%

  • 消除多次推理开销

使用指南

技术
适用场景

Tool Search Tool

工具定义 >10K Token、10+ 工具

Programmatic Tool Calling

处理大数据集只需摘要、3+ 步依赖工具调用

8.3.11 工程实战:端到端数据分析助手

以下展示一个完整的数据分析助手工作流,包含规划、执行、结果处理和上下文更新。

场景:用户上传 CSV 文件并要求:"分析上季度的销售趋势,并画图展示。"

流程图

spinner

关键代码实现逻辑

8.3.12 核心指标与评估

在生产环境中,需要关注以下指标来衡量工具执行系统的健康度:

指标
目标值
说明

执行成功率

> 95%

工具调用无异常(Crash/Timeout)的比例

参数准确率

> 90%

模型生成的参数符合 Schema 定义且逻辑正确

平均延迟

< 800ms

工具本身的执行耗时(不含 LLM 推理)

幻觉率

< 1%

调用了不存在的工具或虚构了参数

Token 效率

压缩比 > 50%

原始工具结果 vs 注入上下文的结果大小

优化建议

  • 对于高频且低延迟要求的工具(如查天气),使用本地逻辑而非 LLM 规划。

  • 对于易错的复杂参数(如 SQL),在 System Prompt 中提供 Few-Shot 示例。

Last updated