企业里做 AI Agent,最头疼的不是模型本身,而是"知识从哪来"。内部文档散落在 SharePoint、SQL Server、Cosmos DB;外部数据要从网页、API、第三方库拉取。每次新建一个 Agent,都要重新搭一套检索管线——索引、向量化、权限同步、缓存……重复劳动堆成山,答案质量还参差不齐。
Microsoft Foundry IQ 要解决的就是这件事:把企业内外数据统一收进一个安全、可扩展的知识层,Agent 只管提问,检索和知识管理交给平台,而且是 serverless 模式——不用自己运维向量库或检索服务。
知识层为什么是 Agent 的命门
Agent 的回答质量,上限由模型决定,下限由知识决定。一个没有稳定知识来源的 Agent,要么答非所问,要么编造事实。现实中常见的做法是:
- 手动给每个 Agent 挂一个 Azure AI Search 索引,写索引逻辑、管分片、调排名;
- 用 OneLake 做数据湖,但检索层还得自己搭;
- 外部数据靠爬虫或 API 定时拉取,时效性和权限控制全靠手工。
这套拼图每加一块数据源,运维成本就翻一层。Foundry IQ 的思路是:知识层本身变成平台能力,Agent 开发者只声明"我要哪些数据",不操心"数据怎么变成可检索的知识"。
Foundry IQ 的核心能力
根据微软的发布信息,Foundry IQ 提供三个关键能力:
统一知识接入——企业内部数据(数据库、文档库、文件存储)和外部数据(网页、公开 API、第三方知识库)通过同一套接口接入,Agent 不需要区分数据来源,检索时自动路由到正确的知识切片。
Serverless 检索——不需要预建向量索引、不需要管检索服务的扩缩容。平台按请求量自动调度,开发者只按使用量付费。这对快速迭代 Agent 的团队来说,省掉了大量基础设施工作。
安全与合规内置——知识层继承企业已有的权限模型。不同 Agent、不同用户只能检索到自己有权限访问的数据切片,不会因为"统一知识层"而泄露跨部门信息。
实践:用 Azure AI Foundry SDK 接入 Foundry IQ
以下示例展示如何在 Python 中创建一个 Agent,并将其连接到 Foundry IQ 知识层。代码基于 Azure AI Foundry 的 Python SDK(azure-ai-projects),假设你已经有了 Azure 订阅和 Foundry 项目。
注:Foundry IQ 是新发布的能力,具体 API 参数可能随版本迭代调整,以下为典型用法,运行前请对照最新 SDK 文档确认参数名。
# 安装依赖
# pip install azure-ai-projects azure-identity
import os
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
# 1. 用环境变量或硬编码填入你的 Foundry 项目连接字符串
project_connection_string = os.environ.get(
"AZURE_AI_PROJECT_CONNECTION_STRING",
"eastus.api.azureml.ms;my-subscription-id;my-resource-group;my-project-name"
)
credential = DefaultAzureCredential()
client = AIProjectClient.from_connection_string(
credential=credential,
connection_string=project_connection_string,
)
# 2. 创建 Agent,挂载 Foundry IQ 知识检索工具
agent = client.agents.create(
model="gpt-4o",
name="knowledge-agent",
instructions="你是一个企业知识助手。回答问题时,优先从检索到的知识片段中提取事实,不要编造。",
tools=[
{
"type": "foundry_iq_retrieval", # Foundry IQ 检索工具类型
"foundry_iq_retrieval": {
"data_sources": [
# 内部数据源:Azure SQL 中的产品手册
{
"type": "azure_sql",
"connection_name": "my-sql-connection", # 在 Foundry 中预先注册的连接
"table": "product_manuals",
},
# 内部数据源:SharePoint 文档库
{
"type": "sharepoint",
"connection_name": "my-sharepoint-connection",
"site": "https://contoso.sharepoint.com/sites/engineering",
},
# 外部数据源:公开网页知识
{
"type": "web",
"urls": [
"https://learn.microsoft.com/en-us/azure/",
],
},
],
},
}
],
)
print(f"Agent created, id: {agent.id}")
# 3. 发起对话,Agent 会自动调用 Foundry IQ 检索
thread = client.agents.create_thread()
client.agents.create_message(
thread_id=thread.id,
role="user",
content="Contoso X200 设备的保修政策是什么?",
)
run = client.agents.create_and_process_run(
thread_id=thread.id,
agent_id=agent.id,
)
# 4. 读取 Agent 回答
messages = client.agents.list_messages(thread_id=thread.id)
for msg in messages.data:
if msg.role == "assistant":
print("Agent 回答:", msg.content[-1].text.value)
运行前需要准备:
- 在 Azure AI Foundry 项目中注册数据连接(SQL、SharePoint 等),连接名对应代码中的
connection_name。 - 确保运行环境的 Azure 身份有权限访问 Foundry 项目和对应数据源。
foundry_iq_retrieval工具类型名以最新 SDK 文档为准,发布初期可能使用不同的标识符。
知识层不是银弹:边界与取舍
统一知识层解决了"数据散、检索难"的问题,但有几个现实边界需要正视:
时效性窗口——serverless 检索依赖平台侧的数据刷新节奏。如果你的数据源是高频变更的交易库,知识层中的切片可能有分钟级延迟。对实时性要求极高的场景(如风控、交易执行),仍需要 Agent 直接调用原始 API,而非走知识层检索。
权限粒度——Foundry IQ 继承企业权限模型,但权限粒度取决于源系统。SharePoint 的文档级权限可以透传,SQL 的行级安全如果没在源端配置,知识层也无法凭空加一道行级过滤。权限必须在数据源侧先做好,知识层只是透传而非补全。
成本模型——serverless 按检索请求量计费,对低频查询的 Agent 很划算;但如果 Agent 在高并发场景下频繁检索(比如每秒数百次知识调用),费用可能超过自建向量索引的固定成本。建议在上线前用典型负载做一次成本估算。
上线检查清单
把 Foundry IQ 纳入 Agent 架构前,走一遍这几项:
- 数据源清单:列出 Agent 需要的所有知识来源,标注内部/外部、权限模型、更新频率。
- 连接注册:在 Foundry 项目中逐个注册数据连接,验证连通性和权限透传。
- 时效性需求:标注哪些查询允许分钟级延迟、哪些必须实时。实时需求的数据源不走知识层,走直连 API。
- 成本预估:根据预期 QPS 和平均检索次数,用 Azure 定价页估算月度检索费用,与自建方案对比。
- 回答质量基线:上线前用 50-100 条典型问题做检索质量评测,对比"有知识层"和"无知识层"的回答准确率。
Foundry IQ 的价值不在替代模型,而在让 Agent 的知识获取从"手工作坊"变成"平台流水线"。对于正在 Azure AI Foundry 上构建多 Agent 系统的团队,这是目前最直接的知识层方案——先从小规模试点开始,验证权限透传和检索质量,再逐步扩大数据源覆盖。