附录 G：MCP 与提示词工程的融合¶
G.1 MCP 时代的提示词工程范式转变¶
从 2024 年起，MCP（Model Context Protocol，模型上下文协议）正在改变我们设计和使用提示词的方式。MCP 官方定义它是连接 AI 应用与外部系统的开放标准，让应用可以接入数据源、工具和工作流（包括专门的提示模板）。
传统提示词工程 vs MCP 时代的上下文工程¶
传统方式（2023年及之前）:
手动拼接 → 静态提示词文本 → 发送给模型
问题：
- 信息通过字符串硬编码
- 难以动态更新和管理
- 每次都要重新拼接，低效且容易出错
- 无法实时注入新数据
MCP方式（2024年及之后）:
协议化注入 → 动态上下文源 → 标准化接口 → 发送给模型
优势：
- 通过协议标准化上下文的提供方式
- 支持实时、动态的信息注入
- 模型可以请求访问所需信息，宿主应用按权限和用户策略决定是否提供
- 清晰的权限和隔离机制
G.2 MCP 的三大核心原语与提示词工程¶
MCP 服务器提供多类能力。本附录聚焦与提示词工程关系最直接的三个能力：Resources、Tools 和 Prompts。
1. Resources（资源）- 数据的声明式描述¶
原语定义：Resources 是应用驱动的上下文来源，服务器暴露资源，客户端应用决定如何检索、筛选并提供给模型。
对提示词工程的影响：
传统方式：
MCP 方式：
{
"resources": [
{
"uri": "file:///customer_db",
"name": "Customer Database",
"description": "企业客户关系管理数据库"
},
{
"uri": "file:///product_catalog",
"name": "Product Catalog",
"description": "实时产品目录和库存信息"
}
]
}
提示词只需简洁地说：
你可以访问以下资源：
- Customer Database (file:///customer_db)
- Product Catalog (file:///product_catalog)
应用可按权限读取这些 URI 对应的资源，并把相关片段提供给模型。
优势：
- 在示例场景中，Token 消耗可减少约 50%+；实际收益取决于资源规模、缓存策略和检索命中率
- 资源描述在服务器端管理，易于更新
- 应用可以根据任务选择、检索或筛选相关资源
2. Tools（工具）- 可执行操作的标准化¶
原语定义：Tools 是模型可请求调用的、带 JSON Schema 输入约束的操作接口；宿主应用仍应负责权限、审批和审计。
对提示词工程的影响：
传统方式（ReAct）：
你可以使用以下工具：
1. send_email(recipient, subject, body)
2. query_database(sql)
3. update_record(table, id, data)
[冗长的使用说明和示例]
MCP 方式：
{
"tools": [
{
"name": "send_email",
"description": "发送电子邮件",
"inputSchema": {
"type": "object",
"properties": {
"recipient": {"type": "string", "description": "收件人邮箱"},
"subject": {"type": "string"},
"body": {"type": "string"}
},
"required": ["recipient", "subject", "body"]
}
}
]
}
提示词可以更简洁：
优势：
- 工具定义与提示词分离
- 模型自动理解工具的签名和约束
- 减少提示词中关于“如何使用工具”的冗余文本
3. Prompts（提示模板）- 可复用的提示词模板库¶
原语定义：Prompts 是服务器暴露的可复用、可参数化提示模板，通常由用户显式选择或通过应用界面触发。
对提示词工程的影响：
传统方式：
MCP 方式：
MCP服务器提供标准化的提示词模板：
{
"prompts": [
{
"name": "code_review",
"description": "代码审查提示模板",
"arguments": [
{"name": "language", "description": "编程语言"},
{"name": "focus", "description": "审查重点"}
]
},
{
"name": "document_summarization",
"description": "文档总结提示模板",
"arguments": [{"name": "style", "description": "摘要风格"}]
}
]
}
应用调用：
// 而不是手动构建提示词
const prompt = await mcp.getPrompt("code_review", {
language: "python",
focus: "security"
});
优势：
- 提示词成为可共享的资产
- 版本控制和最佳实践积累
- 跨组织、跨项目的一致性
G.3 MCP 改变的提示词设计原则¶
原则 1：从“包含所有信息”到“按需获取”¶
传统方式：
MCP 方式：
系统提示词 =
核心角色定义 +
对可用资源和工具的引用（简洁的声明）
当应用暴露资源时 → 应用检索并选择合适上下文，宿主按权限决定是否提供
当应用暴露工具时 → 模型可请求调用，宿主/用户按策略授权执行
当需要特定指导时 → 应用可检索特定的 Prompt 模板
→ 精简且高效的核心提示词
原则 2：从“静态管理”到“动态协商”¶
传统方式：
MCP 方式：
原则 3：从“模型中心”到“上下文中心”¶
提示词工程的演进：
阶段1：模型中心 (2020-2022)
"我需要写一个很好的提示词来指导模型"
重点：优化文本本身
阶段2：思维链 (2022-2023)
"通过结构化推理改进模型输出"
重点：提示词结构
阶段3：上下文中心 (2024+)
"如何设计最优的上下文环境让模型自主发现答案"
重点：上下文来源和动态组装
G.4 MCP 时代的最佳实践¶
实践 1：最小化系统提示词¶
示例：
# 旧方式（包含所有细节，超过5000 tokens）
你是一个专业的数据分析师...
你可以访问以下数据库...
数据库模式包括...
支持的查询类型有...
请遵循这些格式规范...
[等等冗长内容]
# MCP方式（核心提示词，仅500 tokens）
你是一个数据分析助手。
可用资源：
- 客户数据库 (db://customers)
- 销售数据库 (db://sales)
- 产品目录 (resource://products)
可用工具：
- query_database - 执行SQL查询
- generate_report - 生成分析报告
需要任何数据或执行特定操作时，使用上述资源和工具。
实践 2：利用 Prompts 模板库¶
组织中的提示词管理：
企业级MCP服务器上的提示词库：
prompts/
├─ business_analysis/
│ ├─ competitor_analysis.json
│ ├─ market_sizing.json
│ └─ trend_analysis.json
├─ technical/
│ ├─ code_review.json
│ ├─ architecture_review.json
│ └─ testing_strategy.json
└─ content/
├─ blog_post_outline.json
├─ social_media.json
└─ product_documentation.json
应用使用：
# 而不是在每个应用中重复提示词
class AnalysisAgent:
async def analyze_competitor(self, company_name):
# 从MCP服务器获取最新的提示模板
prompt_template = await mcp.getPrompt(
"competitor_analysis",
{"company": company_name}
)
result = await claude.process(prompt_template)
return result
实践 3：条件化的上下文注入¶
根据用户查询动态选择资源：
class SmartContextBuilder:
async def build_context(self, user_query):
context_parts = []
# 核心系统提示词（总是包含）
context_parts.append(self.base_system_prompt)
# 通过MCP动态发现相关资源
if "客户" in user_query or "订单" in user_query:
customer_resource = await mcp.getResource("db://customers")
context_parts.append(f"相关资源：{customer_resource}")
if "产品" in user_query:
product_resource = await mcp.getResource("resource://products")
context_parts.append(f"相关资源：{product_resource}")
# 根据查询复杂度选择合适的工具集合
if self.is_complex_query(user_query):
tools = await mcp.discoverTools(category="advanced")
else:
tools = await mcp.discoverTools(category="basic")
context_parts.append(f"可用工具：{tools}")
return "\n\n".join(context_parts)
实践 4：MCP 驱动的 Agent 设计¶
新的 Agent 架构：
用户输入
↓
[感知阶段]
├─ 通过MCP的Prompts获取"任务理解"模板
├─ 通过MCP的Resources发现相关数据源
└─ 通过MCP的Tools列表确定可用操作
↓
[规划阶段]
├─ 根据发现的资源制定计划
└─ 确定需要调用的工具序列
↓
[执行阶段]
├─ 调用MCP工具执行每个步骤
├─ 实时查询MCP资源获取所需数据
└─ 根据反馈调整计划
↓
[响应阶段]
└─ 通过MCP的Prompt模板格式化输出
G.5 MCP 与成本优化¶
Token 消耗的改善¶
传统提示词工程：
系统提示词: 2000 tokens
工具定义: 1500 tokens
示例: 1000 tokens
当前会话: 500 tokens
─────────────────
总计: 5000 tokens/请求
MCP方式：
系统提示词: 300 tokens
资源/工具引用: 100 tokens (仅名称和URI)
当前会话: 500 tokens
─────────────────
总计: 900 tokens/请求
示例节省: 82%（用于说明量级，不代表通用保证）
Prompt Caching 与 MCP 的协同¶
MCP + Prompt Caching的最佳实践：
1. 缓存基础系统提示词
- 这部分几乎不变
- 必须先达到目标模型的最小可缓存长度，否则标了 `cache_control` 也不会真正缓存
（Anthropic 当前为 Fable 5.1 / Mythos 5.1 / Fable 5 / Mythos 5 / Opus 5 512 tokens，Sonnet 5 / Opus 4.8 / Sonnet 4.6 1,024 tokens，
Haiku 4.5 4,096 tokens；不足长度时不报错，只是静默不缓存）
- 缓存命中率可较高（取决于系统提示词稳定性和服务商缓存策略，需以服务商缓存统计为准）
2. 动态注入资源和工具引用
- 通过MCP在缓存边界之外
- 每次查询可能不同
- 无需重新缓存
3. 结果：
- 缓存节省基础成本
- MCP动态适应每个查询
- 组合优化效果显著
G.6 企业级 MCP 部署示例¶
# 企业的MCP服务器配置示例
class EnterpriseMCPServer:
def __init__(self):
self.resources = []
self.tools = []
self.prompts = []
def setup_resources(self):
"""注册企业数据源"""
self.resources.extend([
{
"uri": "db://salesforce",
"name": "Sales Database",
"auth": "oauth2",
"read_only": False
},
{
"uri": "db://jira",
"name": "Project Management",
"auth": "api_key",
"read_only": True
},
{
"uri": "file://company_docs",
"name": "Company Knowledge Base",
"auth": "none",
"read_only": True
}
])
def setup_tools(self):
"""注册企业工具"""
self.tools.extend([
{
"name": "create_ticket",
"description": "在Jira中创建工作单",
"requires_auth": True,
"rate_limit": "100/hour"
},
{
"name": "update_sales_record",
"description": "更新Salesforce销售记录",
"requires_auth": True,
"rate_limit": "1000/hour"
}
])
def setup_prompts(self):
"""注册标准化提示模板库"""
self.prompts.extend([
{
"name": "sales_analysis",
"version": "2.1",
"maintained_by": "sales_team",
"last_updated": "2024-03-01"
},
{
"name": "technical_design_review",
"version": "1.5",
"maintained_by": "engineering_team",
"last_updated": "2024-02-28"
}
])
G.7 MCP 时代的安全性考量¶
权限管理不能只靠提示词¶
传统方式：
在提示词中说明权限 → 容易被注入攻击绕过
MCP方式：
权限由服务器端、宿主应用和用户审批共同强制执行
├─ 某个角色只能查询读权限的资源
├─ 某个工具需要额外的授权
├─ 敏感操作需要审计日志
└─ 提示词中不需要重复说明权限
→ 安全性由架构保证，而非提示词技巧
G.8 小结：MCP 带来的范式转变¶
维度 传统方式 MCP方式
────────────────────────────────────────────────
上下文来源 手动拼接文本 协议化声明
信息更新 需要重写提示词 服务器端更新
工具调用 详细的使用说明 标准化JSON
权限管理 在提示词中描述 服务器端/宿主/用户审批
可扩展性 每新增能力都修改提示词 自动发现
Token消耗 随拼接上下文增长 通常更低（示意，取决于资源粒度）
版本管理 困难 标准化
────────────────────────────────────────────────
核心转变：
从 "精心设计单一提示词"
到 "设计最优的上下文环境"
G.9 学习资源¶
- 官方 MCP 文档
- MCP 服务器概念：Tools / Resources / Prompts
- MCP Python SDK
- 社区驱动的 MCP 服务器集合
思考题¶
- 在你的当前项目中，如果采用 MCP 方式，提示词能减少多少 token？
- 你如何设计一个企业级 MCP 服务器来统一管理提示词模板？
- MCP 与 Prompt Caching 结合时，如何设计缓存边界以最大化成本节省？