Prompt、Skills、MCP：大模型上下文工程核心链路

Prompt：从静态指令到结构化思维

Prompt（提示词）是激发大型语言模型（LLM）智能的核心入口，也是人与模型最直接的沟通桥梁。随着技术演进，Prompt 已超越简单“提问”，发展为引导模型进行结构化思考的系统性方法。

1、Prompt 的本质：一次性、静态的人机指令

Prompt 是用户或开发者向模型输入的一次性、静态文本指令，作为模型生成响应的直接依据。在上下文工程体系中，它处于最底层——所有高级上下文信息（如 RAG 检索结果、工具输出、对话摘要）最终都需编译为 Prompt 文本送入模型。

其“静态”与“一次性”特性，既保障了易用性，也带来了根本局限：无法动态更新，缺乏对实时环境的感知能力。

2、高级 Prompt 技法：引导模型“思考”

为突破静态限制，社区发展出多种结构化 Prompt 技法，旨在构建“思维脚手架”，激发模型推理能力。

2.1 思维链（Chain-of-Thought, CoT）

2022 年 Google 提出 CoT：在 Prompt 示例中不仅提供答案，更展示中间推理步骤，显著提升模型在数学、逻辑等多步任务中的准确率。

例如，面对“罗杰原有 5 个球，又得 2 罐网球，每罐 3 个”，标准 Prompt 易得错误答案；CoT Prompt 引导模型分步推导：“5 + (2×3) = 11”，提升可解释性与可靠性。

2.2 ReAct：协同推理与行动

针对需调用外部工具的任务，Google 同年提出 ReAct（Reason + Act）框架，建立“思考→行动→观察”循环：

• Thought：分析任务，决定下一步动作；
• Action：选择并执行工具（如 Search[keyword]）；
• Observation：接收工具返回结果。

ReAct 成为现代 AI 智能体的基础，使模型从封闭的“语言大脑”升级为具备规划、执行与环境交互能力的“行动实体”。

3、Prompt 的根本痛点：脆弱、难管、与世隔绝

尽管高级技法拓展了 LLM 能力，但 Prompt 本身存在四大工程瓶颈：

• 脆弱性（Brittleness）：效果高度依赖措辞与格式，微小改动易致输出大幅波动，开发接近“玄学”而非工程实践；
• 难管理（Poor Manageability）：复杂应用中 Prompt 易膨胀为冗长“泥潭”（Prompt Swamp），难以阅读、维护与迭代；
• 无法连接实时世界（Lack of World Connection）：无法原生访问 API 或实时数据，动态信息须由外层代码预处理后注入；
• 缺乏记忆与状态（Statelessness）：多轮交互需手动拼接历史，成本高且易超上下文长度限制。

4、必然演进：从 Prompt Engineering 到 Context Engineering

上述痛点推动范式升级——从优化单一 Prompt，转向系统性构建模型所需的完整上下文供给体系，即上下文工程（Context Engineering）。

该体系需支持：
• 主动从数据库、API、传感器等多源获取信息；
• 对信息进行结构化处理与压缩；
• 动态编排上下文并按需路由；
• 全流程保障安全、合规与可追溯。

Prompt 仍是信息流最终汇入模型的“入口”，但已不再是唯一主角，而是嵌入更大系统的基础组件。焦点正从“精雕入口”转向“设计管道”。

Skills：可复用、可组合的能力单元

如果说 Prompt 定义“做什么”（What to do），Skills 则定义“能做什么”（What can be done）。它是连接 LLM 推理能力与外部功能的桥梁，是智能体的“手和脚”。

1、Skill 的定义：从临时工具到能力资产

一个 Skill 是标准化、可被模型理解与调用的能力单元，包含三部分：

• 功能逻辑（Functional Logic）：实际执行操作的代码（如 Python 函数或业务 API 调用）；
• 调用接口（Interface Schema）：以 JSON Schema 描述用途、输入参数与返回格式，构成模型使用的“说明书”；
• 元数据（Metadata）：含版本、所有者、依赖、成本、使用历史等，支撑发现、治理与演进。

2、Skill 在上下文中的角色：能力的显式化

Skills 构成“能力上下文”（Capability Context）的基本单位。将其接口注入模型上下文，即明确赋予模型对应超能力。

核心价值包括：

• 让模型成为规划者：结合 ReAct 等框架，自主将复杂任务拆解为 Skill 调用序列（如订机票+查酒店）；
• 让能力可动态组合：标准化设计支持灵活拼装，如今日配“天气查询+新闻播报”，明日换“代码生成+数据库查询”。

3、Skill 的生命周期：从定义到演进

作为“能力资产”，Skill 需全生命周期管理，典型流程含五阶段：定义 → 开发 → 测试 → 发布 → 监控演进。

该闭环确保组织能力可沉淀、复用与持续优化。

4、演进之路：从自定义 JSON 到标准化协议

Skill 实践经历三阶段演进：

• 早期：开发者自定义 JSON 格式描述工具，配合大量胶水代码解析模型意图；
• 2023 年 OpenAI Function Calling：引入结构化函数声明与返回机制，大幅降低集成门槛；
• 当前厂商锁定困局：各模型（OpenAI/Claude/Gemini）工具调用协议互不兼容，跨平台应用受限。

5、标准化 Skill 定义与实现

Anthropic 推出基于 Markdown 的 Skills 标准（SKILL.md），采用 YAML frontmatter + 正文结构：

• name：小写字母、数字、连字符，≤64 字符（如 processing-pdfs）；
• description：第三人称描述，含触发条件，≤1024 字符；
• 正文：操作指南与代码示例；
• 目录结构：支持渐进式披露（Progressive Disclosure），按需加载参考文件，节省 Token。

MCP：单智能体的上下文扩展坞

Skills 单元化后，亟需统一“接入标准”。模型上下文协议（Model Context Protocol, MCP）正是解决能力集成混乱的关键基础设施，可视为单智能体的“上下文扩展坞”。

1、MCP 要解决的核心问题：能力集成的“巴别塔”

此前能力集成存在三大顽疾：

• 紧耦合：工具调用逻辑与应用代码深度绑定，变更即重写；
• 厂商锁定：各模型工具协议互不兼容，跨平台迁移成本高；
• 静态不透明：能力列表硬编码，无法运行时动态发现或感知状态/成本。

MCP 通过客户端-服务器（Client-Server）架构彻底解耦智能体与能力。

2、MCP 的核心架构：解耦智能体与能力

MCP Client：AI 智能体或宿主应用，负责与模型交互，并按需向 MCP Server 发起请求；
MCP Server：独立 Web 服务，托管 Skills 并暴露标准化 MCP 接口。

交互流程含两步：

• 获取能力清单：GET /mcp/v1/tools 获取结构化 Skills Schema；
• 调用指定能力：POST /mcp/v1/tools/{tool_name} 提交符合 Schema 的参数。

3、MCP 的三大原语：不止于工具

MCP 将外部上下文抽象为三种原语：

• Tools：可调用的动态能力（如 send_email）；
• Resources：可引用的静态/半静态数据（如 PDF 财报、CSV 用户列表），支持元数据与摘要获取；
• Prompts：可复用的结构化 Prompt 模板（如“用户反馈分析”ReAct 模板），供客户端直接调用。

三大原语共同构成完整上下文供给系统：告知模型“能做什么”（Tools）、“能参考什么”（Resources）、“应如何思考”（Prompts）。

4、MCP 工作流实例：一次订票查询

1. 启动与发现：旅行助手 Agent 连接“航空公司 MCP Server”，调用 /mcp/v1/tools 获取 search_flights 工具；
2. 用户输入：“查明天 SFO 到 JFK 的航班”；
3. 上下文构建：Agent 将工具 Schema 与用户请求整合进 Prompt，提交给 LLM；
4. 模型意图生成：LLM 输出结构化 JSON，指明调用 search_flights 及参数；
5. 客户端执行：Agent 解析 JSON，向 /mcp/v1/tools/search_flights 发 POST 请求；
6. 服务器响应：MCP Server 执行查询，返回航班数据 JSON；
7. 最终生成：Agent 将结果与原始问题再次提交 LLM，生成自然语言回答。

5、最佳实践：基于官方文档的 MCP Server 和 Client 实现

参考 MCP 官方文档（https://modelcontextprotocol.io/docs/develop/build-server），FastMCP 框架示例关键点：

• 使用 @mcp.tool() 装饰器定义工具；
• 借助 Python type hints 与 docstrings 自动生成 Schema；
• STDIO-based Server 中，日志写入 stderr，避免 stdout 污染通信流。

Client 示例（https://modelcontextprotocol.io/docs/develop/build-client）展现标准工作流：

• 通过 STDIO 连接 MCP Server；
• 调用 session.list_tools() 发现能力；
• 将工具定义传给 Claude 决策是否调用；
• 执行 session.call_tool()；
• 将结果回传 LLM 生成最终答复。

该架构实现智能体与能力的完全解耦，客户端仅依赖协议，无需了解实现细节。

6、MCP 的历史定位与争议

尽管 2025 年底起社区出现“MCP 已死”讨论（认为厂商原生 Tool Calling 与长上下文已削弱其必要性），但其真正价值在于首次明确提出“上下文即服务”（Context-as-a-Service）理念。

MCP 的核心贡献，是确立“通过标准化客户端-服务器架构解耦智能体与能力”这一架构范式。无论未来协议名称如何演变，该思想已是构建可扩展、可维护 AI 系统的必由之路——它将上下文管理，从应用内部实现细节，升维为独立、可治理的架构层。

因此，MCP 在上下文工程演进中承上启下：为单智能体提供标准化“扩展坞”，使其安全、动态接入外部能力与知识；而当多个智能体需协作时，则需更高层级的 A2A 协议。