Agent工具治理实践：从Function Calling到运行时治理

核心内容

1. Function Calling的演变

在Function Calling出现前，开发者通过提示词约定模型输出JSON来触发函数调用，但模型输出不稳定（夹带自然语言、格式错误等）。2023年6月，OpenAI引入Function Calling（参数 functions/function_call），模型返回结构化字段，应用层无需再费力解析JSON。2023年11月，OpenAI将接口演进为更通用的 tools/tool_choice，支持多工具并行调用（tool_calls数组）。其他厂商（如Claude、DeepSeek）也陆续支持类似机制，但协议和字段名称不统一。

Function Calling仅保证“格式稳定”，并未解决“语义稳定”（选对工具和参数）和“执行稳定”（超时、权限、业务状态等）问题。

2. Agent的工具调用过程

Agent运行时是一个由模型驱动的循环（Agent Loop）：应用层将用户消息、系统提示词、历史上下文和工具列表发给模型；模型判断是否调用工具；若返回工具调用请求，应用层执行对应工具并将结果追加到上下文；再次请求模型，直到模型不再返回调用请求。

实际业务场景（如修改订单地址）涉及多条链路：需要先查询订单、检查订单状态、确认权限，然后才能调用修改地址工具。Agent没有固定执行路径，每一步由模型动态决策，带来不可控风险：选错工具、参数不合法、执行失败、上下文爆炸、循环调用等。

3. Agent工具治理的四大维度

3.1 工具入口治理

• 工具定义要清晰：说明工具做什么、何时用、何时不用、参数来源和约束。模糊定义（如“查询信息”）需避免。
• 单次暴露给模型的工具不要过多：模型在10个工具中选择远优于100个。常用做法：按业务域动态加载、先检索Top‑K再调用、Agent拆分。
• 为模型增加工具选择规则（在系统提示词中写明）。
• 参数必须做运行时校验：检查必填字段、类型、枚举值、业务约束。校验失败返回结构化错误（含error_type、message、retryable、suggested_action），让模型判断下一步。

3.2 工具执行治理

不同错误类型需不同策略：

• 参数错误（invalid_arguments）：不重试，返回错误给模型修正。
• 超时/临时不可用（timeout）：设置短间隔重试，限制最大次数，失败后交给模型。
• 权限错误（permission_denied）：禁止自动重试和提权，通知模型无权限，必要时要求用户授权。
• 业务规则违规（business_rule_violation）：详细返回失败原因，让模型向用户解释。
• 高风险动作失败（扣款、退款、删数据等）：必须做审计日志、幂等控制、自动失败后转人工处理，并推状态给用户。

3.3 上下文与收敛治理

• 设置循环停止条件：最大推理轮数、最大工具调用次数、单任务最长执行时间、单任务最大调用成本。达到阈值时主动终止并向用户说明。
• 控制工具结果进入上下文：限制结果长度、做摘要压缩、只保留相关片段。避免上下文溢出。
• 工具结果结构化：所有工具返回统一格式。失败时包含错误类型、消息、是否可重试、下一步建议；成功时包含业务状态、可用操作。便于模型稳定决策。
• 识别重复调用：若模型连续多次调用同一工具且参数相同，应直接复用已有结果或提示模型停止。

3.4 安全与授权治理

• 工具安全分类：
  • 低风险（查询订单、搜索等）：可直接执行。
  • 中风险（生成草稿等）：可执行但记录日志。
  • 高风险（发送邮件、提交订单等）：执行前必须用户确认。
  • 不可逆风险（删除数据、退款等）：需审批或双重确认。
• 高风险工具手动确认：执行前要求用户确认，防止误触发。