企业把订单、会员与知识库接给 AI，常以为工具越多，代理就越能帮忙。但用户问“这笔订单能不能退”，AI 可能选到取消订单，而不是查询退货资格。问题不一定出在模型不够强，而是工具名称太像、用途不清楚，或一次提供了太多选项。
近期信号：工具也需要被搜索
2026 年 8 月 25 日发表于 arXiv 的 SCOUT 预印本，描述 PayPal 环境中通过搜索挑选相关工具、再提供给代理的做法。这是作者报告的特定实现，并非通用效果保证。Firebase 在 8 月 11 日也分享了技能激活与端到端评估方法。两者提醒我们：除了接通系统，还要确认代理能找到并正确使用能力。以下是米亚科技的实施建议。
先把工具写成业务看得懂的服务
每个工具都应有清楚的用途、适用场景、不适用场景、必要输入、输出与负责人。例如“查询退货资格”只返回规则与订单状态；“创建退货申请”会产生新工单；“执行退款”则会改变资金流。三者不能只用相似名称区分。也要标明是否写入数据、是否需要审批，以及失败时代表未执行还是结果未知。
按任务挑选，再加载细节
可以把工具目录想成图书馆索引：先用需求找到少量候选，再读取完整操作规范。MCP 是连接工具的一种方式，工具发现则是另一层设计，并不会因为接上 MCP 就自动完成。工具数量不多时，清楚分组可能已足够；扩大后再考虑结合关键词与语义搜索。候选过少会漏掉正确工具，过多又增加判断负担，应以真实任务调整。
找得到，不代表可以执行
目录应先按用户、部门与数据范围过滤可见工具；实际调用时，后端仍须重新检查身份与权限。搜索排名不是授权，工具说明也不能替代审批。目录记录应经过审核，保留版本与停用状态，避免过期接口或不可信的描述混入。涉及写入时，还要确认参数与审批对象一致。
用退货流程做一个小型验收
以下是假设场景，并非客户实绩。客服要求“帮我看能不能退”，系统应查询资格并说明依据，不应直接退款；要求“创建申请”才可进入申请流程；没有退款权限的人，即使知道工具名称也不能执行。测试还应包含同名客户、缺少订单号、工具停用、搜索没有结果，以及用户中途改变意图。信息不足时应询问或交接，不能猜一个工具继续。
衡量完成工作，不只看省下多少 Token
先以现有集成建立基准，再比较选对工具比例、任务完成率、错误写入次数、延迟与人工修正时间。工具发现本身也需要成本与时间，缩短提示不一定让整段流程更快。每次改名、更换版本或新增工具，都应重新运行代表性案例，保留选了哪个工具、依据哪版目录与后端是否允许的记录。
米亚科技的建议
先挑一条客服或申请流程，整理少量常用工具与容易混淆的需求，再把网站、APP、现有 API、权限与后台记录接起来。企业 AI 集成的价值，会逐步从“能连多少系统”转向“能否在正确场景下，安全而稳定地完成工作”。工具目录就是让这件事可管理、可验收的起点。
References: SCOUT — arXiv preprint, 2026-08-25; Firebase — Eval-driven development, 2026-08-11