AI Agent 函数调用实战：避免冗余工具调用

2.1 初始设计（朴素方案）

我的初始架构是这样的：

User Input → LLM → Function Call → Backend API → LLM → Response

让模型决定调用哪个函数

只要建议执行就始终执行该函数

在实践中，这导致了几个问题：

模型即使对"你好"这样的简单消息也会触发函数调用

冗余的 API 调用增加了后端负载

对何时应该执行工具缺乏清晰控制

不必要的延迟导致用户体验不佳

此时，我意识到：

让 LLM 完全无约束地控制执行会导致系统效率低下。

转折点在于理解这一点：

AI Agent 不应该只是"调用工具"——它应该决定何时不调用它们。

受控的执行逻辑

更好的 LLM 与后端之间的编排

不再盲目执行工具调用，我重新设计了系统：

→ LLM (intent + decision)
→ Orchestration Layer
→ (Conditional) Backend Tool Execution
→ LLM Final Response

4.2 基于决策的工具调用

我引入了以下逻辑：

简单输入 → 直接响应（不调用工具）

信息查询 → 通过 API 获取数据

复杂操作 → 执行前进行多步骤推理

4.3 延迟执行（重要）

Agent 不立即调用工具，而是：

识别缺失信息

提出后续问题

仅在所有参数都可用时才执行函数

这显著减少了不必要的调用。

在后端（ASP.NET Core），我将 API 设计为可调用工具：

每个函数都暴露了结构化的输入/输出模式，以便 LLM 能够安全地与它们交互。

6. Prompt 与编排策略

为改进行为，我优化了：

系统 prompt（清晰的工具使用规则）

函数描述（明确的意图）

上下文处理（多轮对话）

改进意图识别

减少错误的工具选择

保持一致的响应

7. 评估与测试

由于没有大规模的生产流量，我使用以下方式评估系统：

模拟用户输入（各种意图场景）

多轮对话测试

边界情况（不完整或模糊的查询）

减少了不必要的工具调用

提高了响应一致性

更好地处理复杂请求

每个设计都有权衡：

更高效的 API 使用

更好的用户体验

对系统行为有更清晰的控制

增加了系统复杂性

需要精心设计 prompt 和流程

比简单的聊天机器人系统更难调试

这个项目改变了我对 AI 系统的思考方式：

LLM 应该是控制器，而不是执行器

后端系统应该是工具，而不仅仅是 API

好的 AI 系统需要编排，而不仅仅是 prompt

构建 AI Agent 不仅仅是调用 API。

而是设计一个系统，使：

决策受控制

执行高效

行为可预测

如果你在构建 AI 驱动的应用，少关注"模型能做什么"，多关注你的系统如何控制它。

11. 未来改进

添加对话记忆（持久上下文）

集成向量搜索以获得更好的推荐

引入性能指标（延迟、工具调用率）

优化系统以适应现实世界扩展

这个项目推动我超越仅仅使用 LLM——它帮助我像工程师一样围绕 LLM 设计系统。

而这才是真正价值的来源。