当智能体需要回答企业内部问题时，真正困难的往往不是生成答案，而是找到可信、最新、属于当前组织的数据。Cloudflare AI Search 的定位很直接：把它指向自己的文件和网站，就能创建面向这些数据的搜索能力，让智能体拥有一个针对专属知识库的搜索引擎。
从“拼装搜索链路”到直接接入数据
传统做法通常需要自行组合数据抓取、文本切分、向量化、索引、检索和结果拼接等组件。每一层都可能带来额外的配置和运维成本，智能体开发者还要处理数据更新、权限边界以及搜索结果格式等问题。
AI Search 的核心价值，是减少这些 Cloudflare 基础能力之间的胶水代码。开发者可以把注意力放在三个问题上：
- 哪些文件和网站内容应该被搜索；
- 智能体在什么场景下调用搜索；
- 搜索结果如何参与最终回答。
这并不意味着搜索可以完全脱离数据治理。数据源的范围、更新频率、访问权限和内容质量，仍然决定了智能体回答的可靠程度。
搜索结果是智能体的工作材料
将 AI Search 接入智能体时，建议把搜索当作一个明确的工具调用，而不是让模型凭空“回忆”企业知识。一个基本流程可以是：
- 用户提出问题；
- 智能体判断是否需要查询专属数据；
- 调用 AI Search 获取相关片段；
- 将搜索结果作为上下文交给模型；
- 生成回答，并尽量保留来源信息。
这种设计有两个实际好处。其一，模型可以根据实时索引内容回答问题，而不是依赖训练数据。其二，搜索和生成职责分离，出现错误时更容易定位：是没有找到正确文档，还是模型误读了检索结果。
实践中应当限制上下文大小，并要求模型区分“搜索结果明确说明的内容”和“无法从数据中确认的内容”。对于政策、合同、操作手册等高风险资料，还应在回答中展示文档名称、更新时间或内部引用标识。
一个可改造的调用示例
下面的示例假设你的部署提供一个兼容 JSON 的搜索接口。接口路径和字段名需要按照实际 AI Search 集成方式调整；示例重点是展示如何把搜索封装成智能体工具。运行前设置 AI_SEARCH_ENDPOINT 和 AI_SEARCH_TOKEN。
import json
import os
import sys
from urllib.request import Request, urlopen
from urllib.error import HTTPError, URLError
def search_private_data(query: str, limit: int = 5) -> list[dict]:
endpoint = os.environ["AI_SEARCH_ENDPOINT"]
token = os.environ["AI_SEARCH_TOKEN"]
payload = json.dumps({"query": query, "limit": limit}).encode("utf-8")
request = Request(
endpoint,
data=payload,
method="POST",
headers={
"Authorization": f"Bearer {token}",
"Content-Type": "application/json",
},
)
try:
with urlopen(request, timeout=15) as response:
data = json.load(response)
except (HTTPError, URLError) as exc:
raise RuntimeError(f"search request failed: {exc}") from exc
# 按实际响应结构修改这里，例如 data["results"]。
return data.get("results", [])
if __name__ == "__main__":
question = " ".join(sys.argv[1:]).strip()
if not question:
raise SystemExit("usage: python search.py 'your question'")
for item in search_private_data(question):
title = item.get("title", "untitled")
text = item.get("text", "")
print(f"[{title}]\n{text}\n")
可以这样运行：
export AI_SEARCH_ENDPOINT="https://your-search-endpoint.example/search"
export AI_SEARCH_TOKEN="replace-with-your-token"
python search.py "如何申请远程办公？"
如果接入的是支持工具调用的模型，可以把 search_private_data 的参数描述为 query 和 limit，并在系统提示词中规定：只有搜索结果足够支持结论时才回答；没有相关结果时明确说明无法确认。这样能减少模型把通用常识误包装成公司内部规定。
数据范围和成本需要一起评估
AI Search 降低了搜索基础设施的搭建门槛，但采用前仍要做几项检查：
- 数据边界：只接入确实允许被智能体检索的文件和网站，避免把草稿、个人资料或受限内容混入公共搜索范围。
- 更新策略：确认内容发生变化后多久能反映到搜索结果。对频繁更新的数据，过期索引会直接影响回答。
- 权限模型：搜索结果不能突破原始数据的访问权限。需要为不同用户或不同智能体设计清晰的授权边界。
- 结果质量：用真实问题集测试召回效果，尤其关注同义词、缩写、产品名和中英文混合查询。
- 价格模型：Cloudflare 正在预览新的定价模型。上线前应使用预计的数据规模、查询量和调用模式估算成本，并关注预览阶段条款可能发生变化。
适合怎样开始
比较稳妥的路径是选择一个边界明确的场景，例如内部文档问答、产品帮助中心或团队运维手册。先接入少量高质量数据，记录搜索命中率、无结果比例、回答引用准确性和单次查询成本，再决定是否扩大数据范围。
采用清单可以压缩为四项：
- 确定允许搜索的数据源；
- 为智能体定义清晰的搜索工具契约；
- 用真实问题验证结果质量和权限行为；
- 根据预览定价和实际查询量评估长期成本。
AI Search 的意义不只是“多了一个搜索接口”，而是让专属数据更容易成为智能体可以调用的基础能力。真正的工程收益，取决于数据治理、工具边界和评测体系是否同步建立。