企业 Agent 真正落地时，难点通常不在于调用大模型，而在于如何让它稳定、准确并且可控地找到内部资料。Amazon Bedrock Managed Knowledge Base 将数据接入、向量化、索引和检索组织成托管流程，使团队可以把精力放在数据质量、检索策略和生产治理上。
这套能力可以从三个支柱理解：简化配置、更智能的检索，以及面向生产环境的准备工作。
托管知识库简化了哪些环节
一个典型的企业检索链路包含文档解析、文本切分、向量生成、向量存储、相似度搜索和结果组装。自行建设意味着团队需要维护多个组件，还要处理模型升级、索引同步和失败重试。
Bedrock 托管知识库把这些步骤收敛为几个主要对象：
- 知识库：定义嵌入模型、执行角色和向量存储。
- 数据源：指定需要同步的企业数据，例如 S3 中的文档。
- 摄取任务：读取、切分、向量化并写入索引。
- 检索接口：根据自然语言查询返回相关内容及来源信息。
这里的“简化”并不代表零配置。团队仍然需要选择嵌入模型、设计索引字段、配置 IAM 权限，并决定哪些数据能够进入知识库。
更智能的检索不只是增加结果数量
Agent 使用企业搜索时，目标不是找到最多的段落，而是找到足以支持下一步决策的证据。检索质量通常受四个因素影响：
- 文档边界：标题、章节和表格是否在摄取前得到合理保留。
- 文本切分：片段太小会丢失上下文，太大则会稀释语义相关性。
- 查询表达：Agent 应该把对话中的模糊需求改写成独立、明确的检索问题。
- 结果数量：返回太少可能漏掉关键依据，返回太多则会挤占模型上下文并引入噪声。
例如，用户问“高级版能不能用于欧洲团队”，Agent 不宜直接用整句话搜索。它可以拆成“高级版功能限制”“欧洲区域可用性”“企业数据驻留政策”等查询，再综合检索结果。
可以给 Agent 使用如下检索提示词：
你负责查询企业知识库。
根据用户问题生成 1 到 3 个可独立理解的检索查询：
- 保留产品名、地区、版本和时间范围；
- 将定价、权限、合规等不同意图拆开；
- 不要补充用户没有提供的事实。
回答时只使用检索结果中的证据。如果证据不足，明确指出缺少什么信息，并列出引用来源。
可以这样实践：用 Python 查询现有知识库
下面示例假设已经创建 Bedrock 知识库，并且当前 AWS 身份拥有调用检索接口的权限。运行前需要安装 boto3，然后把环境变量替换成自己的知识库 ID 和区域。
python -m pip install --upgrade boto3
export AWS_REGION=us-east-1
export BEDROCK_KB_ID=YOUR_KNOWLEDGE_BASE_ID
将以下内容保存为 retrieve.py 后运行。脚本会打印匹配文本、相关性分数和来源位置，可直接改造成 Agent 的检索工具。
import json
import os
import sys
import boto3
def retrieve(query: str, limit: int = 5) -> list[dict]:
client = boto3.client(
"bedrock-agent-runtime",
region_name=os.environ.get("AWS_REGION", "us-east-1"),
)
response = client.retrieve(
knowledgeBaseId=os.environ["BEDROCK_KB_ID"],
retrievalQuery={"text": query},
retrievalConfiguration={
"vectorSearchConfiguration": {
"numberOfResults": limit
}
},
)
return [
{
"text": item.get("content", {}).get("text", ""),
"score": item.get("score"),
"location": item.get("location", {}),
"metadata": item.get("metadata", {}),
}
for item in response.get("retrievalResults", [])
]
if __name__ == "__main__":
question = " ".join(sys.argv[1:]) or "公司的数据保留政策是什么？"
print(json.dumps(retrieve(question), ensure_ascii=False, indent=2))
执行查询：
python retrieve.py "欧洲客户数据可以保留多长时间？"
接入 Agent 时，不要只把文本片段传给模型。建议同时保留 score、location 和 metadata，这样才能生成引用、执行权限过滤，并在问题发生时追踪检索来源。
生产环境需要补上的控制面
托管服务减少了基础设施工作，但不会自动解决企业治理问题。上线前至少应检查以下事项：
- 最小权限：摄取角色只读取指定数据源，运行时角色只访问获准的知识库。
- 数据隔离：不要把不同租户或不同保密级别的数据混入一个无法过滤的索引。
- 同步策略：明确文档更新、删除和摄取失败后的处理流程。
- 检索评测：建立包含问题、期望来源和关键事实的测试集，持续比较召回率与答案正确性。
- 可观测性：记录查询、命中文档、延迟和空结果，但对日志中的个人信息及机密内容做脱敏。
- 失败边界：没有可靠证据时，Agent 应拒绝猜测，并将问题转交人工或其他系统。
检索评测尤其不能只看最终回答。应分别测量“正确文档是否被召回”和“模型是否正确使用了文档”。前者暴露索引与查询问题，后者暴露提示词和生成模型问题。
采用建议
适合的切入点是选择一个边界清晰、来源稳定且答案可以验证的场景，例如内部产品手册、支持流程或合规政策。先建立几十到几百条真实问题组成的评测集，再调整切分方式和结果数量。
Amazon Bedrock Managed Knowledge Base 能缩短企业搜索基础设施的建设周期，但搜索质量仍取决于文档治理、查询设计、权限模型和持续评测。把知识库视为 Agent 的受控证据层，而不是一个会自动理解所有企业数据的黑盒，才能更稳妥地进入生产环境。