企业知识库问答真正进入生产环境后，难点通常不在“能不能检索到文档”，而在于能否回答这些问题：请求被路由到了哪个知识库？检索用了什么过滤条件？最终答案引用了哪些来源？一次失败发生在 Agent、检索、模型还是基础设施？系统上线后，答案质量又如何持续评估？
这套方案围绕 Amazon Bedrock Managed Knowledge Base 与 Amazon Bedrock AgentCore 构建一个企业级 agentic retrieval 系统。Agent 负责理解问题、选择知识库并组织答案，系统同时提供引用信息、分层可观测性，以及按需和持续评估能力。所有组件通过一条 AWS CloudFormation 部署链交付，适合需要重复部署、审计和环境隔离的团队。
从单一检索升级为智能路由
传统 RAG 往往只有一条固定链路：接收问题、查询一个知识库、把结果交给模型生成答案。当企业知识分散在员工手册、产品文档、合同、工单和运维记录中时，单一知识库会带来两个问题：检索范围过大，或者不同类型文档之间缺少清晰边界。
Agentic retrieval 把“选择检索路径”交给 Agent。一个问题可能被路由到 HR 知识库、产品知识库或运维知识库；复杂问题也可以拆解后访问多个知识库，再合并结果。路由过程至少需要明确以下约束：
- 每个知识库有清晰的用途、描述和访问边界。
- Agent 必须知道何时只查询一个知识库，何时需要跨库查询。
- 返回答案必须携带可追溯的引用，而不是只输出一段看似合理的文本。
- 无法找到证据时，应明确返回“不确定”或要求补充信息。
这里的核心不是让 Agent 自由发挥，而是把路由决策变成可观察、可评估的执行步骤。每次调用都应记录问题、路由目标、检索结果摘要、模型响应和引用信息，同时避免把敏感原文无控制地写入日志。
七层可观测性如何落地
来源方案强调七层可观测性。实际落地时，可以把它拆成从请求入口到质量评估的完整链路：
- 请求层：记录请求 ID、租户、调用方、区域和时间。
- Agent 决策层：记录 Agent 选择的知识库、工具调用、重试和终止原因。
- 检索层：记录查询文本、过滤条件、召回数量、相关性分数或排序结果摘要。
- 模型层：记录模型调用耗时、输入输出 token、错误类型和延迟分布。
- 引用层：记录答案中的引用是否来自实际检索结果，以及引用覆盖了哪些关键结论。
- 基础设施层：观察 Lambda、AgentCore、CloudFormation、权限和依赖服务的健康状态。
- 评估层：记录事实性、相关性、引用完整性、拒答质量和端到端延迟等指标。
这七层不等于“所有数据都写进一张日志表”。生产系统应区分指标、日志和追踪：延迟与错误率适合指标；路由决策和引用映射适合结构化日志；一次用户请求跨越多个服务时，使用统一 trace ID 连接调用链。原始文档内容和用户输入可能包含个人信息或商业机密，必须通过脱敏、访问控制、保留周期和加密策略限制暴露面。
CloudFormation 让部署链可重复
知识库、数据源、Agent、权限、监控和评估资源通常分属不同生命周期。将它们拆成嵌套堆栈或串联堆栈，可以让每个阶段拥有清晰的输入输出：
基础设施堆栈
-> IAM 与加密配置
-> Knowledge Base 与 Data Source
-> AgentCore 运行时与路由配置
-> 观测、告警与评估资源
下面是一个可以改造成实际项目入口的 CloudFormation 根模板。示例中的子模板路径、资源参数和 AgentCore 资源类型需要替换成团队实际维护的模板；根模板本身展示的是部署顺序和参数传递方式。
AWSTemplateFormatVersion: '2010-09-09'
Description: Enterprise agentic retrieval deployment chain
Parameters:
Environment:
Type: String
AllowedValues: [dev, staging, prod]
DataBucketName:
Type: String
KmsKeyArn:
Type: String
ModelId:
Type: String
Default: anthropic.claude-3-5-sonnet-20240620-v1:0
Resources:
Foundation:
Type: AWS::CloudFormation::Stack
Properties:
TemplateURL: https://example-bucket.s3.amazonaws.com/templates/foundation.yaml
Parameters:
Environment: !Ref Environment
KmsKeyArn: !Ref KmsKeyArn
KnowledgeBases:
Type: AWS::CloudFormation::Stack
DependsOn: Foundation
Properties:
TemplateURL: https://example-bucket.s3.amazonaws.com/templates/knowledge-bases.yaml
Parameters:
Environment: !Ref Environment
DataBucketName: !Ref DataBucketName
KmsKeyArn: !Ref KmsKeyArn
AgentRuntime:
Type: AWS::CloudFormation::Stack
DependsOn: KnowledgeBases
Properties:
TemplateURL: https://example-bucket.s3.amazonaws.com/templates/agent-runtime.yaml
Parameters:
Environment: !Ref Environment
ModelId: !Ref ModelId
KnowledgeBaseIds: !GetAtt KnowledgeBases.Outputs.KnowledgeBaseIds
Observability:
Type: AWS::CloudFormation::Stack
DependsOn: AgentRuntime
Properties:
TemplateURL: https://example-bucket.s3.amazonaws.com/templates/observability.yaml
Parameters:
Environment: !Ref Environment
AgentEndpoint: !GetAtt AgentRuntime.Outputs.AgentEndpoint
Outputs:
AgentEndpoint:
Value: !GetAtt AgentRuntime.Outputs.AgentEndpoint
KnowledgeBaseIds:
Value: !GetAtt KnowledgeBases.Outputs.KnowledgeBaseIds
部署前，先将子模板上传到版本化的 S3 前缀，并确保 CloudFormation 执行角色拥有创建相关 Bedrock、IAM、日志和评估资源的权限。部署命令可以这样执行：
aws cloudformation deploy \
--template-file root.yaml \
--stack-name enterprise-agentic-retrieval-dev \
--parameter-overrides \
Environment=dev \
DataBucketName=company-kb-dev \
KmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/REPLACE_ME \
ModelId=anthropic.claude-3-5-sonnet-20240620-v1:0 \
--capabilities CAPABILITY_NAMED_IAM \
--region us-east-1
实际模板中应把资源的输出显式传递给下一层，避免通过命名约定或人工复制 ID。生产环境还应固定模板版本、启用变更集，并将数据源同步和索引构建纳入可追踪的发布流程。
让答案带着证据返回
Agent 的系统提示词可以明确路由和引用协议。下面是一段可作为起点的提示词示例，具体工具名称和输入格式需要根据 AgentCore 的运行时契约调整：
你是企业知识助手。
路由规则：
- HR、假期、福利和员工政策问题只查询 HR_KB。
- 产品配置、API 和功能问题只查询 PRODUCT_KB。
- 事故、告警、部署和故障排查问题只查询 OPS_KB。
- 如果一个问题跨越多个领域，先拆分问题，再按需查询多个知识库。
回答规则：
- 只使用检索结果中的事实，不要补写没有证据的细节。
- 每个关键结论后附引用，引用必须指向实际返回的文档和片段。
- 没有足够证据时，明确说明无法确认，并列出需要补充的信息。
- 不要输出检索结果中的访问令牌、个人信息或内部凭据。
可以用一个最小的 Python 客户端验证端到端响应。这里假设运行时提供一个 HTTPS Agent endpoint，并返回 answer、citations 和 trace_id 字段；字段名若不同，应按实际 API 契约修改。
import os
import requests
endpoint = os.environ["AGENT_ENDPOINT"]
token = os.environ["AGENT_TOKEN"]
question = "生产环境 API 返回 5xx 时，应该查看哪些指标？"
response = requests.post(
endpoint,
headers={
"Authorization": f"Bearer {token}",
"Content-Type": "application/json",
},
json={"input": question, "tenant_id": "demo"},
timeout=60,
)
response.raise_for_status()
result = response.json()
print("trace:", result.get("trace_id"))
print("answer:", result.get("answer"))
for citation in result.get("citations", []):
print("-", citation.get("title"), citation.get("location"))
验证时不要只检查 HTTP 200。至少应测试错误路由、跨库问题、无结果问题、权限隔离、引用缺失和模型超时。对相同测试集运行多次，还要观察路由是否稳定、引用是否变化过大，以及答案质量是否随着知识库更新而退化。
按需评估与持续评估
按需评估适合发布前和重大配置变更后执行：固定一组带参考答案和参考来源的问题，比较不同路由提示词、切分策略、嵌入模型或生成模型的结果。持续评估则适合在系统运行期间采样真实请求，监控质量趋势和异常变化。
建议把评估结果至少分成四类：
- 检索质量：相关文档是否被召回，噪声文档是否过多。
- 生成质量：答案是否完整、准确、符合问题范围。
- 引用质量：引用是否存在、是否支持对应结论、是否覆盖关键事实。
- 运行质量：端到端延迟、失败率、成本和重试次数。
持续评估不应把用户反馈简单等同于事实标签。可以组合人工抽检、规则检查、模型评审和业务指标，并保留评估数据集版本。这样才能区分“检索没有找到证据”和“模型找到了证据但生成错误”这两类完全不同的问题。
上线前检查清单
- 每个知识库都有明确的领域描述、数据所有者和访问策略。
- CloudFormation 堆栈之间通过 Outputs 传递资源 ID，部署可以重复执行。
- Agent 路由、工具调用、检索和模型调用拥有统一 trace ID。
- 日志经过脱敏，原始文档和用户输入受到最小权限与保留策略保护。
- 答案引用可回溯到真实文档位置，而不是由模型自由生成。
- 同时准备发布前的按需评估和上线后的持续评估。
- 为无证据、跨租户访问、依赖超时和权限拒绝设计明确的失败行为。
Managed Knowledge Base 降低了知识检索基础设施的维护负担，AgentCore 则为路由和执行提供了更灵活的编排空间。真正决定企业方案能否长期运行的，是资源可重复部署、决策可解释、答案可引用、质量可量化。把这些能力从演示阶段就纳入 CloudFormation 和观测体系，后续扩展知识库和模型时，系统才不会重新变成一条难以排查的黑盒链路。