微软WebIQ：为AI Agent提供可验证的实时网页接地

AI Agent 的能力边界正在快速扩展，但一个根本矛盾始终存在：Agent 只能基于它“知道”的信息进行推理，而它的知识往往停留在训练数据截止的那一刻。当市场价格变动、法规更新、新产品发布时，缺乏实时接地的 Agent 会给出一个语气笃定、格式工整、却已经过时的答案——最危险的是，这个答案听起来毫无破绽。

微软在近期的一场技术分享中系统介绍了 WebIQ，一套为 Agent 时代设计的 AI 原生接地（Grounding）API 套件。它要解决的问题很明确：让 Agent 的每一步推理都建立在新鲜、可引用、可验证的外部证据之上。

为什么 Agent 比聊天机器人更需要接地

未接地的模型面对“最新款 Surface 笔记本是哪款、有什么变化”这类问题时，通常会自信地报出一个旧型号，没有来源、没有日期、无从核查。对聊天机器人来说，这是一次尴尬的回答；对 Agent 来说，问题会被放大得多。

Agent 不回答单个问题，它运行的是多步循环：查一个事实、基于该事实做决策、执行下一步动作、完成任务。如果第一步拿到的是过时的版本号或价格，错误会沿着链条逐级传递，最终 Agent 仍然会汇报“任务完成”。分享中提到的一个旧价格或上个月刚变更的法规，足以让整条任务链悄然脱轨。

这正是 Agent 需要“新鲜、可引用、足够快”的接地的原因——它必须能嵌入循环的每一步，而不是偶尔调用一次。

接地（Grounding） 在 AI 领域指的是将模型的生成与推理锚定在外部可验证的信息源上，而非仅依赖参数中记忆的静态知识。常见做法包括检索增强生成（RAG）、工具调用、搜索 API 等。接地的核心价值在于降低幻觉、提升事实准确性，并让输出可追溯。对 Agent 而言，接地不仅是“补充知识”，更是决策链条的输入校验环节——每一步动作所依据的事实都必须来自当下可核查的外部证据，否则错误会沿多步循环被放大。

WebIQ 是什么：六个接地入口加一个统一调度层

WebIQ 是微软 IQ 家族的一员。其他 IQ 层负责引入组织内部知识，WebIQ 则是外部的真实世界知识层，建立在 Bing 近二十年的搜索与检索经验之上，面向全球规模运行。

它提供六种接地方式：通用网页搜索、最近几天的新闻、图片、视频、对已有 URL 的浏览解析，以及 Places 这一专业化知识域。据分享披露，WebIQ Places 覆盖 2.075 亿个真实世界实体，包含结构化信息、位置与商业详情，后续还会扩展更多垂直领域。

在这些能力之上是 Auto——WebIQ 的统一入口。开发者只需一次调用，WebIQ 自动编排合适的来源并组装带引用的证据。Auto 提供两种模式：Fast 模式做一次成本可控的检索，适合需要可预测延迟与成本的交互式 Agent；Advanced 模式会评估结果、改写查询、继续检索补充信息，面向需要多轮深挖的复杂研究问题。切换只需改一个字段。

接入方式有两条路径但能力一致：REST API 支持从 playground 直接复制 curl、Python、JavaScript、C#、Java、Go、Ruby 代码；托管 MCP Server 则可插入任何支持 MCP 的 Agent 框架。WebIQ 目前已面向所有 Azure 客户正式可用。

MCP（Model Context Protocol） 是一种开放协议，用于让 AI 应用以标准化方式连接外部工具与数据源。托管 MCP Server 意味着服务提供方已经封装好协议接口，Agent 框架只需按 MCP 规范接入即可调用 WebIQ 的接地能力，无需自行处理鉴权、请求格式与结果解析。这与直接调用 REST API 在能力上一致，区别在于集成成本与框架兼容性——对已支持 MCP 的 Agent 框架，接入几乎是即插即用。

性能数据：质量、延迟与 token 效率的三重取舍

微软公布的对比测试采用跨服务的匹配配置。接地满意度方面，WebIQ 为 79.05，次优方案为 75.7。延迟方面，P95 为 164 毫秒，比次优方案快近 2.5 倍。token 效率方面，在达到同等接地质量的前提下，比次优方案少用 50% 的 token。

这三个指标之间存在紧密关联，而非各自独立。延迟在 Agent 循环中会逐级累积：一次任务若调用五次接地，每节省一毫秒就被放大五倍。token 越少，单次调用成本越低，在生产规模下这一差异会迅速放大。

质量提升的一个重要机制是段落级检索（passage level retrieval）。将内容格式设为 passage 后，每条结果返回标题、来源 URL、与问题最相关的段落以及抓取时间。模型拿到的是聚焦的、可直接引用的上下文，而不是被整页内容淹没的上下文窗口。同一个页面换一个问题，返回的段落也随之改变。

段落级检索（Passage Level Retrieval） 与传统的整页检索相对：后者返回完整网页或大段文本，容易让上下文窗口被无关内容占满；前者先将页面切分为语义段落，再针对具体问题召回最相关的段落。这样做的好处是上下文更聚焦、token 消耗更低、引用更精确，模型也更容易判断证据是否充分。段落级检索本质上把“上下文工程”的一部分前移到了检索层完成。

Scopes：把 Agent 的接地范围收窄到可信来源

并非所有场景都需要开放整个网络。WebIQ Scopes 允许开发者和企业管理员按 URL、域名、站点和路径进行包含或排除：可以纳入团队信任的文档站点，也可以排除某个不希望被 Agent 引用的归档页面。API 与结果格式不变，改变的只是边界。

这套机制带来的价值有三层：策略可以在所有 Agent 之间一致地强制实施；证据来自选定来源，回答的相关性与可信度随之提升；在来源选择最敏感的场景中，控制权回到企业手中。

企业级信任：来源透明与发布者控制

WebIQ 在内容获取方式上遵循发布者控制，包括适用的 robots 指令、TXDX 指令以及微软认可的其他发布者信号。每一条结果都附带引用，用户能够核查信息来自哪里、追溯回原始网页。

演示环节展示了一个由 Azure OpenAI 模型驱动、接入 WebIQ 作为工具的 Agent，分析美国能源市场。Agent 不仅输出答案，还展示了完整的活动步骤与引用来源，每条结论都可点击回源验证。这一模式同样适用于金融研究、媒体趋势监测、法规监控和帮助台 Agent。

一个竞争情报 Agent 的例子更能说明问题：面对“我们的主要竞争对手发布了什么”这一问题，Agent 发起两次 WebIQ 调用（网页搜索与新闻搜索，内容格式均为 passage），拿到针对该问题最相关的段落而非整页内容，每条段落保留来源 URL，模型基于这些段落重写简报，每个论断都带引用。原本分析师需要花一天搜索、阅读、复制链接的工作，变成了 Agent 每天早上自动运行的流程。

P95 延迟 指在全部请求中，95% 的请求耗时不超过该数值，剩余 5% 可能更慢。相比平均值，P95 更能反映尾部体验，对 Agent 多步循环尤其重要——单次接地的慢请求会拖累整条任务链。Token 效率 则衡量达到同等输出质量所需的 token 数量；token 越少，单次调用成本越低、上下文窗口占用越小，在生产规模下成本差异会被调用次数迅速放大。

落地路径

上手路径是：在 Azure 门户部署 WebIQ 资源，随后跳转至 WebIQ 平台获取 API key 或绑定 Microsoft Entra ID，之后即可在 playground 或终端发起第一次调用。微软在 Microsoft Learn 上提供了快速入门文档，演示所用代码仓库也随分享一同放出。

分享给出的总结可以浓缩为一句话：更好的证据输入，带来更好的答案输出，并且快到足以在 Agent 的每一步上完成接地与引用。

常见问题

WebIQ 与普通搜索 API 的区别是什么？

普通搜索 API 返回的是链接列表，WebIQ 返回的是可直接送入模型上下文的段落级证据，附带标题、来源 URL 与抓取时间，并针对准确度、新鲜度和相关性做排序，而非单纯追求召回。

Fast 和 Advanced 模式该如何选择？

Fast 适合交互式路径，成本与延迟可预测；Advanced 适合需要多轮检索的复杂研究问题。实际使用中许多团队两者并用：交互路径走 Fast，深度分析走 Advanced。

企业如何限制 Agent 可访问的内容？

通过 Scopes 按 URL、域名、站点或路径设置包含与排除规则，同一套策略可跨所有 Agent 统一执行。