Agent 如何在一万多个金融工具里找对接口？
Agent 如何在一万多个金融工具里找对接口？
客户问了一句：“刚果金禁止铜钴精矿出口，对相关公司有什么影响？”Agent 的回答很快：“站内没有匹配到相关事件。”可数据库里明明躺着 50 条相关记录，其中点评类 38 条、研报类 7 条、新闻类 3 条。
数据不是没有，是“检索”这一步把它拦在了门外。这也是金融 Agent 最容易被低估的一道坎：工具接入解决的是“有没有”，工具检索解决的才是“找不找得到”。
01 工具多到一定程度，“找对接口”就成了新问题
金融 Agent 的背后从来不是一个接口，而是一张接口网络：行情、公告、研报、事件、财务、估值……成百上千个工具，上万条接口，每个接口有自己的参数、字段和覆盖范围。
用户不会说接口名。他说“股息”，接口描述里写的是“分红、派息”；他说“刚果金”，数据标题写的是“刚果（金）”；他说“出口禁令”，事件摘要写的是“禁止铜钴精矿出口”。
所以 Agent 的第一道坎不是调用，而是翻译：把一句自然语言，翻译成“该查哪个工具、用什么关键词、填什么参数”。这一层一旦出错，后面全是连锁反应——搜不到，就没有证据；没有证据，模型就只能靠脑补。
02 案例一：一句“搜不到”，其实是三个错误叠加
客户在系统里重测一个老话题，两轮检索都返回 0 条，系统还自动补了一句“站内事件无匹配，已走升级流程”。
但数据是有的。排查时先试了搜“刚果”，5 条结果立刻出现；再试客户的原话“刚果金禁止铜钴精矿出口”，0 条。同一个库，同一个话题，差别只在查询词。
拆开看，至少三个错误叠在一起：模型把事件类型默认填成了“新闻”，等于把最相关的 38 条点评直接过滤掉；查询词没有切分，整句话被当成一个必须精确命中的词；0 结果时也没有任何放宽或降级逻辑，直接判定“没有”。
这里的教训很具体：检索失败很少是“模型不懂”，而是查询构造环节把好问题变成了坏查询——该拆的词没拆，该放宽的类型没放宽，失败时还不知道为什么失败。
03 案例二：AI 懂“股息”，接口却叫“分红”
另一个坑藏在召回层，比查询构造更隐蔽。
某次检索评测里，用户问“股息”，正确的分红接口在向量召回里其实排第二，说明语义理解没问题；但全文检索里，接口描述只写了“分红、派息”，没有“股息”，排名直接掉到 21 名。两种召回结果做融合排序后，正确接口反而被低分拖了下去。
这不能怪 embedding——语义相似能救回一部分，但金融术语的精确匹配、不同数据源的命名习惯，仍然要靠别名治理。长期解法也不是往接口描述里硬塞关键词，那样会污染语料、越塞越乱；而是要建立一套中英文别名表，统一索引语料，再重建索引，让“股息 = 分红 = 派息”成为系统里的事实，而不是模型每次都要碰运气的常识。
04 为什么这不能靠提示词解决
一个很自然的想法是：给模型写清楚——“搜索用核心词，别用整句；找不到就换词再试”。
但这等于把正确性押在模型的临场发挥上：同一个问题，换一个模型、换一次参数，结果可能就不一样。检索不是创意写作，它需要稳定、可验证、可回退。
所以检索的正确性应该从“模型纪律”下沉为“系统契约”：别名放工具层，参数约束放接口层，0 结果兜底放检索层。这也是我们上一篇文章的延续——Prompt 里的“必须”不是程序里的“必须”，检索层也一样。
05 QVeris 的做法：把“找接口”变成一条可验证的检索链
在 QVeris，我们把“找接口”拆成一条检索链，每一环都可验证：
- 工具层：每个工具维护中英文别名和能力标签，检索前先完成一次“人话 → 接口语义”的翻译。
- 召回层：全文与向量双路召回再融合，同时治理语料，避免描述缺陷拖累融合结果。
- 参数层：自然语言到参数扩写与纠错，接口缺什么、填错什么，在调用前就暴露出来。
- 结果层：0 结果不直接说“没有”，而是先放宽类型、拆词降级重试；确实没有，就明确告诉用户“没找到，原因是什么”。
这条链的价值在于：每一步失败都有迹可循，每一步都可以回退。模型不需要“记住”一万个接口，只需要学会使用一条可靠的检索链。
06 结尾：工具多不是问题，检索层才是新瓶颈
用户不会背接口名，也不会填参数。他只会说“刚果金”和“股息”。
Agent 的价值，不是记住一万个接口，而是把一句人话翻译成正确的调用，并且在找不到的时候，诚实地告诉你为什么找不到。
工具接入解决的是“有没有”，工具检索解决的才是“找不找得到”。前者让 Agent 变强，后者决定 Agent 可不可信。
