AI 应用真正落地后，难点往往不在于调用模型，而在于让模型可靠地找到企业自己的文档、产品资料、工单和多媒体内容。Cloudflare AI Search 试图把这部分能力做成内置的搜索与检索服务：应用和 AI Agent 不必从零搭建索引、检索和数据连接，就可以围绕自定义数据构建搜索体验。
这项能力的价值不只是“给聊天机器人接一个搜索框”，而是把搜索变成 Agent 工作流中的基础工具，并与 Cloudflare 生态中的其他工具协同使用。
从通用问答转向“搜索自己的数据”
通用大模型知道很多公开知识，却不了解某个团队最新的内部规范、客户合同、产品版本说明或故障记录。直接让模型回答这些问题，容易出现两类风险：
- 模型没有看到相关资料，只能猜测或给出过时答案；
- 模型看到了大量上下文，但没有稳定的检索策略，回答成本和延迟都随之上升。
AI Search 的定位，是为自定义数据提供一个现成的搜索和检索层。应用可以把用户问题转换为搜索请求，再将相关结果交给模型生成答案。这样，模型负责理解和表达，搜索服务负责从业务数据中找到候选内容。
一个典型链路可以这样设计：
用户问题
↓
AI Agent 判断是否需要检索
↓
Cloudflare AI Search 查询自定义数据
↓
返回相关文本、元数据或多模态结果
↓
模型基于检索结果生成答案
这里的关键边界是：搜索结果应该成为答案的依据，而不是把搜索服务当成另一个“会自动解决所有问题”的模型。生产系统仍然需要处理权限、数据新鲜度、结果数量和引用展示等问题。
Agent 集成带来的变化
传统搜索通常由用户主动操作：输入关键词、浏览结果、打开文档。Agent 场景则不同，Agent 需要在完成任务的过程中自主判断：
- 当前问题是否需要访问企业数据；
- 应该使用哪一种搜索条件；
- 搜索结果是否足够支持下一步动作；
- 是否需要继续搜索，或者向用户澄清问题。
因此，面向 Agent 的搜索接口最好被包装成一个清晰的工具，而不是暴露复杂的底层实现。可以把工具描述成“搜索产品文档和内部知识库”，并明确输入字段、返回字段和使用边界。
下面是一个可改造的 Python 示例。它使用一个通用 HTTP 搜索接口作为适配层；SEARCH_URL、认证头和请求字段需要根据实际 Cloudflare 账户配置及产品文档替换。示例的重点是 Agent 工具边界和结果整理方式，而不是假设某个固定 API 路径。
运行前安装依赖：
python -m pip install requests
保存为 agent_search.py：
import os
from typing import Any
import requests
SEARCH_URL = os.environ.get("SEARCH_URL", "https://example.invalid/search")
API_TOKEN = os.environ.get("CLOUDFLARE_API_TOKEN", "replace-me")
def search_custom_data(query: str, limit: int = 5) -> list[dict[str, Any]]:
"""给 AI Agent 调用的最小搜索工具。请按实际 API 调整 payload。"""
if not query.strip():
return []
response = requests.post(
SEARCH_URL,
headers={
"Authorization": f"Bearer {API_TOKEN}",
"Content-Type": "application/json",
},
json={
"query": query,
"limit": max(1, min(limit, 10)),
},
timeout=10,
)
response.raise_for_status()
data = response.json()
# 统一成 Agent 容易消费的结构，避免把底层响应直接暴露给模型。
results = []
for item in data.get("results", []):
results.append({
"title": item.get("title", ""),
"text": item.get("text", ""),
"url": item.get("url", ""),
"score": item.get("score"),
})
return results
if __name__ == "__main__":
question = input("搜索问题：")
for result in search_custom_data(question):
print(f"[{result['title']}] {result['url']}")
print(result["text"][:500])
print("-")
这个适配层有几个实际好处：输入长度和结果数量可以限制，响应格式可以固定，底层服务变化时不必修改 Agent 的工具定义。接入模型时，还可以要求模型只根据返回的 text 和元数据回答，并在答案中保留 url 作为引用。
多模态搜索不只是文本检索
Cloudflare AI Search 还强调多模态搜索能力。对于产品目录、图片资产、扫描文档、视频资料或包含图表的知识库，单纯把内容转成纯文本可能会丢失重要信息。
可以这样规划数据层：
| 数据类型 | 可检索内容 | 适合的应用 |
|---|---|---|
| 文档 | 标题、正文、标签、版本号 | 内部问答、技术支持 |
| 图片 | 图片语义、说明、关联产品 | 素材查找、商品搜索 |
| 扫描件 | OCR 文本与页面元数据 | 合同和历史档案查询 |
| 视频 | 字幕、章节、时间戳 | 培训内容和故障复盘 |
多模态能力并不意味着所有数据都应该混在一个索引里。实践中仍然需要考虑数据权限、租户隔离和结果排序。例如，客服 Agent 可以搜索产品手册，但不应因为“相关度更高”而返回另一个客户的合同附件。
建议在进入搜索层之前，为每条数据附加稳定的元数据：
{
"tenant_id": "customer-123",
"document_type": "product-manual",
"product_version": "2025.1",
"visibility": "support-team",
"source_url": "https://internal.example/manuals/widget",
"updated_at": "2025-02-01T10:30:00Z"
}
搜索请求应结合当前用户或 Agent 的身份生成过滤条件。不要只依赖提示词告诉模型“不要泄露数据”；权限过滤必须在数据访问层执行。
与 Cloudflare 工具组合时要关注边界
AI Search 的另一个吸引力，是可以与 Cloudflare 的其他开发和边缘能力放在同一套架构中使用。这样做有助于减少组件数量，但并不等于所有问题都会自动解决。
可以把职责拆成几层：
- 数据接入层：同步文档、网页、图片或业务记录，并处理更新与删除。
- 搜索层：对自定义数据提供关键词、语义或多模态检索。
- Agent 层：决定何时搜索、如何组合结果，以及是否需要调用其他工具。
- 安全层：执行身份验证、租户隔离、字段过滤和审计。
- 回答层：生成带引用的答案，并在证据不足时明确说明。
这种拆分能避免把“搜索能力”和“业务决策”混为一谈。搜索返回相关内容，Agent 决定下一步动作，业务 API 执行真正的写操作。比如，Agent 可以搜索退款政策，但是否创建退款工单，仍然应该调用有权限控制的业务服务，而不是让模型直接推断。
落地前的检查清单
如果要把 Cloudflare AI Search 引入现有 Agent，可以从一个只读场景开始，例如“搜索产品文档并给出引用”。上线前至少检查以下项目：
- 搜索数据是否覆盖了真实用户问题，而不是只有演示文档；
- 文档更新、删除和版本切换是否能及时反映；
- 每个结果是否包含可追踪的来源和更新时间；
- 租户、团队和文档级权限是否在搜索层或前置服务中执行；
- Agent 是否有最大搜索次数、超时和结果数量限制；
- 没有可靠结果时，系统是否会明确说“不足以判断”；
- 多模态结果是否能被模型正确理解，并在回答中说明来源；
- 是否记录查询、命中结果和最终回答，便于排查错误。
Cloudflare AI Search 的核心意义，在于降低自定义数据搜索和 Agent 集成的起步成本。它最适合那些已经拥有业务数据、又不希望为检索基础设施维护大量独立组件的团队。但搜索质量、权限治理和答案可信度仍然是应用方的责任。把它当成 Agent 的可靠数据入口，而不是自动完成知识管理的黑盒，通常会得到更稳妥的结果。