Prompt、RAG、上下文与 MCP

前置阅读：核心概念卡（先把这 4 个名词当"用过的东西"再读这页）。 预期收获：读完你能画出一个 RAG 系统的标准流程，并说出 5 个常见失败模式。

这份文档整理 Agent 周边的 AI 原生基础设施。

如果你还不清楚一次请求里有哪些字段，先读 Token、上下文与一次请求结构。

Prompt 工程

Prompt 工程应当被当作工程纪律，而不是一次性文案技巧。

核心原则

推荐结构

角色：
任务：
上下文：
输入：
约束：
可用工具：
输出格式：
质量标准：
失败处理：

PromptOps

重要提示词要像代码一样管理：

• 使用 Jinja2 或类似模板系统。
• 放入版本控制。
• 配套测试输入和黄金样例。
• 自动检查输出结构。
• 跟踪回归。
• 上线前评审。
• 指标下降时可回滚。

当提示词成为运营依赖时，PromptOps 尤其重要，例如 PRD 生成、客服分流、销售分析、数据解释、合规审查。

RAG

RAG 是检索增强生成，用于在生成时为模型接入外部知识。

它解决的问题：

• 业务知识持续变化。
• 私有文档不能进入训练集。
• 最新政策或内部流程需要实时访问。
• 产品知识库太大，无法全部放入上下文。
• 模型需要基于来源回答，而不是凭记忆猜测。

标准流程

文档 -> 切片 -> 向量化 -> 向量库/索引
用户问题 -> 查询改写 -> 召回 -> 精排 -> 上下文拼装 -> 生成 -> 引用/评估

关键组件

RAG 层级

常见问题

• Chunk 切片策略不合理。
• 用户问题不完整，需要 Query 改写。
• 单一检索方式不稳定。
• 缺少 Rerank，召回噪音太大。
• 多文档上下文互相矛盾。
• 上下文过长、过旧或过噪。
• 没有引用和来源。
• 没有评测集。

上下文工程

上下文工程就是决定模型应该看到什么、以什么顺序看到、哪些内容不能覆盖系统规则。

上下文类型

设计规则

• 相关性比长度更重要。
• 保留来源。
• 明确处理冲突。
• 工具输出要结构化。
• 长历史要压缩成任务状态摘要。
• 指令和证据要分开。
• 检索文本不能覆盖系统规则和安全约束。

MCP

MCP 的价值是让工具和上下文接入更标准化。

工具调用生命周期

无论是否使用 MCP，工具调用都要按一个可审计的生命周期设计：

声明工具 -> 模型选择工具 -> 生成参数 -> 参数校验 -> 执行工具 -> 返回结果 -> 结果压缩/结构化 -> 继续推理或停止

工具调用失败时，不要把一大段错误直接塞回上下文。更好的方式是返回结构化错误：

{
  "ok": false,
  "error_type": "permission_error",
  "message": "用户无权读取该知识库",
  "retryable": false,
  "suggested_next_step": "request_permission_or_handoff"
}

MCP 风格的工具应包含：

• 工具名称。
• 语义描述。
• 输入结构。
• 输出结构。
• 认证方式。
• 权限边界。
• 错误模型。
• 审计和轨迹信息。

为什么 MCP 重要

没有协议边界时，每个 Agent 集成都容易变成一次性胶水代码。有协议化工具后，Agent 可以：

• 发现工具。
• 理解工具语义。
• 稳定调用工具。
• 替换实现。
• 保留审计链路。
• 接入多个系统而不重写 Agent。

设计模型：Prompt -> Context -> Tool -> Agent

可以按这个层次设计：

1. Prompt 定义行为和输出契约。
2. Context 提供事实、历史和约束。
3. Tool 提供外部动作能力。
4. Agent 循环决定何时推理、检索、调用工具和停止。
5. Runtime 管理执行、轨迹、成本和安全。

准备度检查

• Prompt 模板已存在并版本化。
• 输出结构可校验。
• RAG 具备切片、元数据、检索、精排和来源。
• 上下文拼装能处理冲突和长度限制。
• 工具有权限和审计。
• Agent 有停止条件和兜底策略。
• 评测覆盖正常路径、边界路径和对抗路径。

读完自测

• [ ] 画出 RAG 标准流程（文档进 + 用户问题进 + 中间 6 步 + 最终输出）。
• [ ] 列出 5 个 RAG 常见失败模式以及对应的修法。
• [ ] 解释为什么"上下文越长越好"是错的。
• [ ] 给一个具体场景（如"客服基于产品手册答疑"），你能说出该用 L1 关键词检索、L2 向量、还是 L3 混合检索。
• [ ] 用一段话解释 MCP 解决了什么过去要重复写的胶水代码。

下一站