把智能体嵌进产品，只解决了“用户在哪里提问”的问题，并没有解决“智能体依据什么回答”。来源材料提到，一个部署类产品在 Web 应用中上线智能体，并分析了 1,192 次对话。这个场景揭示了一个关键工程事实：当问题涉及产品配置、部署状态和版本差异时，模型的通用知识远远不够，智能体需要在回答前检索产品自己的知识库。
文档不是附件，而是回答链路的一部分
用户不会总按文档标题提问。他们更可能输入：
- “为什么这次部署没有生效？”
- “预览环境能不能覆盖生产变量？”
- “升级后原来的配置还兼容吗？”
这些问题往往同时包含产品概念、当前环境和隐含操作目标。仅靠大模型参数中的知识，容易出现三类问题：
- 信息过期：模型记住的是旧版本行为，产品文档已经更新。
- 术语错位：同一个词在不同产品里可能指向完全不同的资源。
- 无依据推断：当上下文不足时，模型仍可能生成听起来合理的答案。
因此，知识库检索不应只是一个可选工具。对于产品支持型智能体，它更适合作为回答流程中的固定步骤：识别问题、检索文档、筛选证据、生成回答，并在证据不足时明确追问或拒答。
搜索质量决定智能体的答案上限
接入文档并不等于问题已经解决。智能体能否给出可靠答案，取决于检索结果是否覆盖了用户真正需要的内容。
文档系统需要特别处理几类信号：
- 产品实体：项目、部署、环境变量、构建缓存等名称应具有较高权重。
- 版本与时间：带有版本号、发布日期或废弃标记的页面需要保留元数据。
- 任务意图：“配置”“排错”“迁移”通常应命中不同类型的文档。
- 访问范围：公开文档、团队内部手册和用户私有配置不能混在同一权限域里。
切分文档时也要避免两个极端。块太大，会把无关内容一起塞进上下文；块太小，则会丢失前置条件和警告。可以把一个完整操作步骤作为基本切分单元，并为每个块附上标题、版本、更新时间和来源路径。
可以这样实践：搭一个最小文档检索服务
下面是一个只使用 Python 标准库的可运行示例。它不是生产级向量检索，而是用于验证“先找证据、再组织回答”的工作流。运行前，把 DOCUMENTS 替换成自己的文档片段。
from http.server import BaseHTTPRequestHandler, HTTPServer
import json
import re
DOCUMENTS = [
{
"title": "Environment variables",
"path": "/docs/environment-variables",
"text": "Environment variables are scoped by environment. Redeploy after changing build-time variables.",
},
{
"title": "Deployment troubleshooting",
"path": "/docs/deployment-troubleshooting",
"text": "Check build logs, deployment status, and the selected environment before retrying a failed deployment.",
},
{
"title": "Build cache",
"path": "/docs/build-cache",
"text": "Clear the build cache when stale dependencies remain after a configuration change.",
},
]
def tokens(text):
return set(re.findall(r"[a-z0-9_-]+", text.lower()))
def search(query, limit=3):
query_tokens = tokens(query)
ranked = []
for doc in DOCUMENTS:
title_tokens = tokens(doc["title"])
body_tokens = tokens(doc["text"])
score = 3 * len(query_tokens & title_tokens) + len(query_tokens & body_tokens)
if score > 0:
ranked.append((score, doc))
ranked.sort(key=lambda item: item[0], reverse=True)
return [doc for _, doc in ranked[:limit]]
class Handler(BaseHTTPRequestHandler):
def do_POST(self):
if self.path != "/search":
self.send_error(404)
return
length = int(self.headers.get("Content-Length", "0"))
payload = json.loads(self.rfile.read(length))
results = search(payload.get("query", ""))
body = json.dumps({"results": results}).encode()
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
HTTPServer(("127.0.0.1", 8080), Handler).serve_forever()
保存为 docs_search.py 后运行：
python docs_search.py
再从另一个终端查询：
curl -s http://127.0.0.1:8080/search \
-H 'Content-Type: application/json' \
-d '{"query":"deployment environment failed"}'
检索结果可以放进模型提示词，但必须明确证据边界：
You are a product support agent.
Answer only from the DOCUMENTATION section.
If the documentation is insufficient, say what information is missing.
Do not invent product behavior, commands, or configuration fields.
Cite the document title and path used in the answer.
USER QUESTION:
{{question}}
DOCUMENTATION:
{{retrieved_documents}}
生产环境可以把示例中的词项匹配替换为混合检索：关键词搜索负责精确命中配置项和错误码，向量搜索负责匹配自然语言意图，再用重排模型筛选最终片段。
从“能回答”推进到“可验证”
上线时不应只观察回答是否流畅。更有价值的指标包括检索命中率、引用正确率、无证据回答率、追问率，以及用户是否在回答后完成目标操作。
还要记录检索查询、候选文档、最终引用和文档版本，但应清理访问令牌、环境变量值以及其他敏感数据。对于私有知识库，检索层必须先执行权限过滤，不能依赖模型在生成阶段隐藏越权内容。
一个稳妥的采用顺序是：
- 先选择高频、文档相对稳定的产品问题。
- 建立包含问题、期望文档和可接受答案的评测集。
- 强制回答附带引用，并允许智能体在证据不足时追问。
- 分析失败案例究竟来自检索、文档质量还是生成过程。
- 再逐步接入用户账户状态和可执行工具。
文档访问不会自动让智能体变得可靠，但它把答案从模型记忆拉回到可更新、可审计的产品事实。对部署支持这类高上下文场景，这通常是从聊天演示走向可用系统的必要一步。