问题不在AI Agent——现有系统和API并非为AI设计

在企业环境中，AI Agent面临的最大挑战之一是如何与大量遗留API交互。这些API通常以工程师十多年前的命名习惯命名，名称如getProcInfo3，描述常常为空或仅写着“见文档”。这样的API对于大型语言模型（LLM）来说几乎不可读。MCP Bridge为解决这一问题推出了两个关键组件：混合搜索优化和AI增强（AI Enrichment）。

混合搜索机制

起初，团队尝试了纯向量搜索，将每个工具的名称和描述嵌入并存储在pgvector中。这在教科书式数据集上表现良好，但面对企业API时，相似嵌入但不同意图的工具（如get_customer、get_customer_full、get_customer_with_orders）会导致失败。随后尝试的全文搜索（Postgres FTS）在精确匹配上更好，但无法理解Agent意图与工具描述之间的词汇差异。最终采用的混合方法：首先由Postgres FTS进行第一轮筛选（采用BM25风格排名），然后由pgvector在第一轮候选结果及更广泛的语义池上进行第二轮搜索，最后由一个小型重新排序器将两个有序列表合并为一个分数。重新排序器还会考虑Agent的近期上下文——如果Agent正在处理客户数据，那么与客户相关的工具排名更高。

真正的难题：数据本身

然而，即使搜索机制设计精良，源数据的质量决定了最终效果。以getProcInfo3(custId, opt) → object为例，签名几乎没有信息量，而返回的JSON响应却包含了丰富的信号：custId、billingAddress、accountStatus、primaryContact、assignedManager。正是响应形状揭示了工具的实际功能——客户账户查询。

团队考虑过要求客户重命名API，但这在小范围内可行，对于拥有70个遗留服务的客户而言则不可能。因此，他们构建了AI增强（AI Enrichment）。

AI增强的工作原理

MCP Bridge可以被指向任何兼容OpenAI的聊天补全端点（内部使用Azure OpenAI，也支持Anthropic和本地Llama）。启用增强后，平台会为每个工具收集：名称、描述（常为空）、参数模式、响应类型定义（来自OpenAPI、WSDL或.proto），以及对于不透明API，通过探测或生产流量捕获的响应样本。然后发送一个结构化提示，要求模型生成更清晰的名称、1–2句描述工具用途，以及3–5个标签或别名。输出会经过验证（无幻觉参数，输入输出类型无语义漂移）。增强后的元数据与原始模式共同存储，工具调用仍使用原始名称和模式，只有发现层使用增强版本。

关键的信号是响应形状。仅凭名称和描述，模型无法区分getProcInfo3和getProcInfo4；一旦看到响应（或样本），功能就变得清晰。对于SOAP服务，WSDL通常提供响应类型；对于无文档API，MCP Bridge可以一次性探测或从追踪中提取。

重要的一点：增强是按服务选择性开启的，原始模式被保留，Agent永远不会看到重命名的参数。这样避免了与源API的无声偏离。

效果与工程细节

在一个真实客户（匿名）的SOAP服务上，原始getProcInfo3被增强为get_customer_account_details，描述为：“获取客户账户信息，包括账单地址、账户状态、主要联系人和指定客户经理。适用于支持、计费或销售前的账户状态验证。”并带有别名。

在该客户的服务上，Agent任务套件中的工具选择准确率从41%提升至89%。而REST服务因已有合理名称，提升幅度较小（71%到88%）。

工程方面：嵌入向量在增强描述变更时重新生成，但保留原始嵌入，检索时两者加权组合（原始×0.3 + 增强×0.7）效果最佳。重新排序器是一个小型交叉编码器，基于手工标注的数百个（意图、工具、标签）三元组训练。成本控制：每晚仅对变更的服务重新增强，200个操作的服务完整增强约花费30美分。管理UI展示命中率指标，帮助识别哪些工具被频繁发现，哪些被忽略，从而优先增强。

结语

MCP Bridge的下一步是响应后处理（Response Post-Processing），这将在未来发布。混合搜索和AI增强的代码已在docs.mcp-bridge.ai上提供。