AI搜索封装成API与MCP：面向Agent的工程拆解

近期，多个AI领域的头部机构相继推出了面向智能体的搜索能力，这一变化成为行业内的重要趋势。AI搜索的实现逻辑并不复杂，但为了适配不同场景的需求，需要在工程层面做大量优化。

AI搜索的基本原理

当用户提问类似“北京明天天气怎么样，出门要带伞吗？”时，AI不会直接给出答案，因为它无法主动获取实时信息。它的工作流程是：首先生成一个标准化的搜索请求，明确需要检索的内容和数量；外部程序识别这个请求后，执行搜索并返回结果；模型读取这些结果后，结合信息生成最终回答。

这个过程中，模型仅负责两件事：确定搜索的内容，以及如何使用返回的结果。但这也带来了问题：搜索结果的真实性由搜索引擎决定，模型无法判断内容是否可靠，可能混入营销号的过时信息或不实内容。这就是工程优化需要解决的核心问题。

面向智能体的搜索挑战

搜索的应用场景从面向用户转变为面向智能体后，情况发生了很大变化，主要面临四个核心挑战：

• 检索词由智能体生成，搜索需要适配智能体的表达习惯，而不是人类的提问方式；
• 智能体模型无法辨别信息真假，需要搜索端承担信息审核的责任；
• 模型的知识停留在训练结束的时间点，需要搜索补充最新信息；
• 智能体完成一个任务需要多轮搜索，每一轮都需要足够快的响应速度。

一、理解检索词

理解检索词的难点，过去就存在：比如用户问“苹果”，是指水果还是电子产品？问“北京的机场”，是大兴机场还是首都机场？如果意图理解错误，后续的搜索结果都会偏离需求。在智能体场景下，检索词由智能体拆分生成，其表达逻辑和人类不同，搜索需要反过来适配智能体的需求。

某主流AI服务提供商的解决方案是让搜索和智能体双向传递信号：搜索向智能体提供每条结果的权威等级、发布时间、排序满意度等信息，帮助智能体选择合适的引用内容；智能体向搜索反馈最终引用的内容、思考过程和答案的评分，用于优化搜索的排序模型。

这种双向交互的效果可以通过实际案例体现：某联合评测显示，接入优化后的搜索服务，单个任务的平均搜索次数从8次降至5次左右；一位内容产品开发者表示，过去智能体需要参考20个网页，现在仅需5个即可。

这些信号最终会输入到排序模型中，该模型由大模型训练而成：首先用海量检索词和网页标注产出监督信号，再用这些信号训练一个大尺寸的教师模型，学习复杂的排序偏好，之后蒸馏为小尺寸的学生模型上线，保证运行速度。训练样本来自线上数据，系统会将结果不满意的检索词交给智能体标注，实现按天迭代，替代了过去按月迭代的人工标注方式。

二、辨别信息真假

模型无法辨别信息真假，营销号和AI生成的内容都会被直接使用，因此需要在内容收录阶段就判断其可靠性。某主流AI服务提供商为每个网页设置三级质量评分，涵盖站点、账号和页面三个维度。收录时，通过大模型解析网页，判断作者身份、作者过往发布内容以及内容的出处。

针对AI生成的内容和专门为AI引用设计的内容，需要进行专项识别：单篇内容使用专门的识别模型，频繁发布AI内容的账号和网站则根据发布规律进行识别。同时，将优质信源优先排序，也是提升信息可靠性的关键。

部分内容无法被搜索到，比如设置了反爬的网站，出于版权保护的原因不收录；对于无法直接访问的内容，会通过第三方合作获取。

三、补充最新信息

模型的知识停留在训练结束的时间，而互联网内容不断更新，比如财报、赛事信息等，晚一小时就可能失效。时效性高的网站刷新频率更快，财经、股票类信息大约每小时更新一次。但股价、天气、航班等信息变化更快，网页发布后就可能过时。

为此，某主流AI服务提供商开发了一套插件系统，类似其他服务的实时数据接口，接入了13个垂直行业的157个头部信源，包括行情、航班、商品等数据。这些插件直接调用合作方的接口，获取数据后封装为结构化卡片，和网页结果一起返回。这些卡片的字段为中文，带有更新时间，模型可以直接使用。

四、降低延迟

智能体需要多轮搜索，每轮延迟都会影响用户体验，因此需要尽可能缩短响应时间。某主流AI服务提供商的最快版本单次搜索可在300毫秒内返回，升级前需要400到500毫秒，连续三轮搜索的总耗时不到一秒。

索引优化方面，将按词检索的倒排索引和按语义检索的向量索引合并为一张千亿规模的索引，召回率达到94%以上，平均检索耗时仅8毫秒。排序优化方面，采用了Gist Token技术：建索引时将每个网页压缩为100个向量令牌，存储在键值缓存中；查询时将这些令牌放在前面，只需计算检索词的令牌，大幅减少计算量。这种方式可以节省约30%的在线推理成本。推理框架方面，适配多种硬件，单位推理成本降低90%。

搜索作为应用程序编程接口

搜索服务做好后，需要提供给智能体使用，对外表现为一个应用程序编程接口。以某主流AI服务提供商的服务为例，用户可以在云平台上获取该接口，选择版本和计费方式。标准版按使用量后付费，每千次20元，单次仅需两分钱；也可以购买资源包。

免费额度为每月2000次，在特定时间段内，使用激活码可提升至每月6000次。获取接口密钥后，通过HTTPS POST方式调用，在请求头中携带密钥，请求体中放入检索词。返回的结果是模型需要的条目，包括原文摘录，最长约800字和2500字。答案由拿到这些条目的模型自行生成。

用户可以控制返回的结果数量，最多50条，还可以限定站点、时间范围、垂直领域，或者只获取插件卡片。不同版本的接口提供不同的功能，标准版包含动态摘要和插件卡片，极速版仅返回基础结果，旗舰版还会提供结果的权威度评分。

打包为模型上下文协议

接口有了之后，需要让模型知道如何使用这个工具，这一要求的实现方式经历了多次演变，目前主流的是模型上下文协议。用户可以在云平台的协议广场获取现成的服务，填入之前获取的密钥即可完成配置。

模型上下文协议的工作流程分为三步：第一步初始化，确认对方身份；第二步获取工具列表，得到使用说明；第三步调用工具，将参数传递给接口，再将返回的结果转换为文本。因此，模型上下文协议版本和应用程序编程接口版本返回的结果是相同的，只是多了一份给模型的使用说明。

多轮任务的情况更能体现搜索和智能体的分工：搜索是原子化的单次能力，每次仅处理一个问题；多轮规划则由智能体负责。比如查询某物理学家的任职大学和校长，需要多轮搜索，每一轮都需要准确快速的结果。

总结

用户看到的只是一句简单的回答，背后是模型和搜索的多次交互，搜索需要在几百毫秒内从海量网页中筛选出合适的结果。对于智能体任务，这种交互会重复多次。

选择面向智能体的搜索服务时，可以关注几个关键点：是否返回官方和权威来源的内容，实时数据是否有结构化卡片，单次响应速度是否足够快，是否可以限定范围。同时，当前的搜索服务价格已经大幅降低，个人也可以负担，相比过去的高价格，科技普惠已经实现。