在 AI 超级智能体项目中，你实现了哪些工具调用功能？

标签：后端、编程导航

🏛 业务架构师

我实现的工具按用户高频痛点排序（这也是我的工具建设优先级方法论）：

联网搜索工具：知识库没有时效性信息（"今天的新闻""最新价格"）——AI 知识有截止日期，联网是补时效短板的标准配置，也是用户感知最强的能力；
PDF/文档生成工具：把 AI 的分析结论、行程规划导出为可分享的文件——交付物化：用户要的不只是对话，是能拿走用的东西（报告发给老板、行程发给同伴）；
地图/路线工具（MCP 接入）：行程规划落地到真实地理数据——"规划得再美，走不通就是废话"；
图片搜索工具（MCP 接入）：图文混排的回答，体验升级；
计算与数据查询工具：精确计算（模型心算不可靠）与业务数据查询。

优先级的业务判断框架：工具开发投入按三个维度打分——用户请求频率 × 不可替代性（模型自身做不到）× 失败的代价。搜索三项全高所以第一个做；"生成随机数"这种模型自己能做的，不值得做成工具。

治理经验：工具上线后看调用成功率与模型选择准确率——模型总选错工具（描述冲突）就改描述；总不选（描述太弱）就强化场景说明。工具集是运营出来的资产，季度复盘调用数据，淘汰没人用的、拆分频繁传错参的。

一句话：工具清单 = 产品的能力边界——我把它当功能路线图来经营，而不是技术演示的素材库。

🏗 系统架构师

我在智能体项目里落地的工具按功能分四类：

1. 信息获取类（读外部世界）：

联网搜索：接 Search API（Tavily/Bing/SerpAPI），实时信息问答（新闻、行情）——LLM 知识截止日期的补丁；
网页阅读：搜索结果的 URL 抓取正文，喂给模型做深度阅读总结；
图片搜索 MCP 服务：接入图片检索，回答"看看这是什么"类多模态需求。

2. 文档生产类：

PDF 生成：模型产出 Markdown 结构 → iText/OpenHTMLtoPDF 渲染成 PDF（报告导出场景）；结构化数据 → 模板填充；
文件处理：文档解析、格式转换。

3. 空间服务类：

地图 MCP：高德/百度地图 API 封装——路线规划、POI 搜索、距离计算，"从 A 到 B 多远"这类模型算不了的问题交给专业服务。

4. 系统内部类：

数据库查询工具（限定白名单 SQL/视图）、邮件发送、日程操作。

设计原则（架构视角）：

每个工具单一职责 + 描述精确（何时用/参数含义），工具说明书就是给模型的 API 文档；
读工具放开、写工具（发邮件/落库）加确认与权限；
统一异常返回格式（错误也是模型可理解的信息）；
工具注册进统一管理器（见工具管理题），新工具以 MCP 或 @Tool Bean 插拔接入。

观察到的规律：工具数量上去后，描述质量与工具粒度比工具本身更影响调用准确率——这是 Agent 工程里"提示词即接口设计"的体现。

💻 全栈开发专家

我实现了六类工具，按使用频率：

联网搜索：接博查/Tavily 搜索 API，模型知识截止日期后的问题（最新版本号、时事）自动触发。核心坑是结果截断——搜索返回几万字会撑爆上下文，只取 top3 摘要 + url。
PDF/文档生成：把模型生成的 markdown 渲染成 PDF（见单独一题），存对象存储返回下载链接。
图片搜索：接 Pexels/Bing Image API，回答"给我看看 xxx"时返回图片链接，前端渲染。
数据库查询（只读）：自然语言转 SQL 的受限版——只开放固定的几张宽表 + 白名单校验（SELECT only、LIMIT 强制），避免模型生成危险 SQL。
地图/路线：高德 API 封装，查地点、算通勤时间。
文件读取：解析用户上传的附件（CSV/Excel 摘要）供回答引用。

管理上的关键实践：

按场景注册子集：不是把所有工具一股脑给模型——工具越多选择准确率越低（实测 10+ 工具时误调率上升），按会话类型配 3~5 个最相关的；
统一返回结构：{success, data, message}，失败信息明确（模型能读懂错误并重试或告知用户）；
可观测：每次工具调用记录（哪个工具、参数、耗时、结果长度），排查"为什么调了这个工具"全靠它。