智能体与工具调用实践
【摘要】 智能体（Agent）与工具调用（Function Calling / Tool Use）的核心，是让大模型从“只会说话”变成“能调用真实系统”。模型本身不直接执行工具，而是根据用户输入和可用工具列表，输出结构化调用指令；应用层执行工具后，再把结果回传给模型，由模型整合成最终回答。核心流程一次典型的工具调用闭环通常是：用户输入：用户提出需求，例如“查一下北京天气”。模型决策：模型结合系统提示词...
智能体（Agent）与工具调用（Function Calling / Tool Use）的核心，是让大模型从“只会说话”变成“能调用真实系统”。模型本身不直接执行工具，而是根据用户输入和可用工具列表，输出结构化调用指令；应用层执行工具后，再把结果回传给模型，由模型整合成最终回答。
核心流程
一次典型的工具调用闭环通常是：
- 用户输入：用户提出需求，例如“查一下北京天气”。
- 模型决策：模型结合系统提示词和工具定义，判断是否需要调用工具。
- 输出结构化指令：模型返回
tool_calls，包含工具名和参数。 - 应用执行工具：后端解析参数，调用真实 API、数据库或本地函数。
- 结果回传：把执行结果以
role=tool的消息追加到对话上下文。 - 模型生成回答：模型根据工具结果生成最终自然语言回复。
工具定义要点
工具定义建议使用 JSON Schema，重点写清：
- 工具名称：采用动宾结构，例如
get_weather、query_order。 - 功能描述：说明适用场景、输入含义和返回内容。
- 参数类型：明确
string、number、enum、是否必填。 - 返回约束：说明返回值结构和错误码含义。
- 权限边界：读操作和写操作要区分，写操作需要额外确认。
工具数量不宜一次性全部注入。超过几十个时，模型选择准确率可能下降，可以按场景动态加载子集。
常见架构模式
工程上常采用 ReAct 模式：模型先思考是否需要调用工具，再执行动作，最后观察结果并继续决策。
更完整的落地架构通常分为：
| 层级 | 职责 | 实践建议 |
|---|
| 层级 | 职责 | 实践建议 |
|---|---|---|
| 决策层 | 判断是否调用工具、如何拆解任务 | 使用 ReAct、Plan-and-Execute |
| 路由层 | 选择具体工具 | 动态加载工具子集 |
| 执行层 | 调用 API/数据库/脚本 | 增加超时、重试、降级 |
| 安全层 | 权限控制、审计、沙箱 | 写操作必须校验和留痕 |
生产环境常见坑
- 描述太模糊：工具 description 写得笼统，模型容易不调用或调用错工具。
- 参数未校验：模型可能漏传、错传参数，后端必须二次校验。
- tool_call_id 不匹配：回传结果时必须携带正确的调用 ID，否则上下文会断裂。
- 工具返回非字符串：很多 SDK 要求工具结果以字符串形式回传。
- 写操作无兜底：下单、删除、转账类操作需要审批、确认或回滚机制。
- 全量工具注入：工具过多会增加成本、延迟和误调用风险。
实践建议
- 先从 少量高频工具 开始，不要一开始堆太多。
- 用 装饰器或注册表 管理工具，避免 if/else 硬编码。
- 对每个工具设置 超时、重试、降级策略。
- 对高风险工具增加 人工确认、权限校验、审计日志。
- 把工具调用日志、参数、返回值、错误码都记录下来，方便排查 Badcase。
- 如果工具调用不稳定，可以先优化提示词和工具描述，再考虑微调模型。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）