Prompt、RAG、MCP、Workflow、Agent、Skill 经常同时出现在一张 AI 架构图里，也经常被当成从简单到高级的升级路线。

这种理解会直接影响技术选型：Context 缺文件，却先建 RAG；只有一个内部 API，也加一层 MCP；路径可以写成状态机，仍然让 Agent 动态规划；项目长期规则和任务方法则全部塞进一个 Skill。

本文不比较具体框架，也不提供某个产品的实现教程。目标是建立一套可用于架构评审的职责模型：每个概念解决什么问题，处在什么运行环节，边界在哪里，以及引入它之前应该验证什么。

从一次模型调用建立基线

最小运行链路可以表示为：

本次调用实际提供的信息（Context）
            ↓
       Model Inference
            ↓
          Output

模型在运行时使用两类信息：训练后已经编码在参数中的知识与能力，以及本次调用实际提供的内容。后者称为 Context，即模型本轮能够看到的全部信息。

Prompt 属于 Context，但 Context 还可能包含 System / Developer Instructions、历史消息、文件、检索结果、已加载 Skill、Tool Schema 和 Tool Result。Context Window 只是本次推理可容纳的信息容量，不等于长期记忆。

这一基线把 Prompt Engineering 与 Context Engineering 拆开：

职责	工程对象	主要问题
Prompt Engineering	当前任务的表达与验证	目标、输入、约束、示例、输出和成功标准是否明确
Context Engineering	本轮全部有效信息的组装	选什么、何时加入、怎样排序，以及如何处理冲突、噪声、容量、成本和过期

二者最终都可能以 Token 形式进入模型，但失败位置不同。任务契约含糊时应改 Prompt；关键文件缺失、旧规则混入或检索结果失真时应改 Context Pipeline。用更长 Prompt 掩盖 Context 组装错误，会让问题更难定位。

外部知识：先区分来源，再决定是否需要 RAG

模型参数不是实时知识库。当前网页、企业文档、业务数据和用户最新状态，都可能不存在于参数中或已经过期。

运行时补充外部知识有几条不同路径：

路径	适用问题	关键验证
直接资料	当前任务需要的资料明确且数量可控	文件是否完整、版本是否正确
Web Search / Browser	公开网页和当前信息	来源、时间、页面内容与查询是否匹配
RAG	大量受控知识源中只需取回相关部分	检索召回、排序、权限、引用范围和新鲜度
Memory	跨轮次或跨任务的偏好、事实与状态	写入条件、取回条件、过期、冲突和隐私

RAG 的核心链路是：

Query
  ↓
Retrieve from controlled sources
  ↓
Select / Rank / Authorize
  ↓
Add evidence to Context
  ↓
Generate

Embedding 和向量数据库是常见实现，但不是 RAG 的定义。全文搜索、SQL、知识图谱或业务 API 都可以承担检索环节。RAG 的关键在于“需要时取回相关证据”，而不是是否使用向量。

Search、RAG 和 Memory 都不会自动修改模型参数。Post-training 与 Fine-tuning 才会通过继续训练改变参数中的稳定知识、能力或行为，因此不适合保存新闻、价格、版本等频繁变化的事实。

引入 RAG 前，至少先回答：缺失资料是否已经明确？如果只缺一份已知文件，直接提供通常具有更短链路、更清楚来源和更低调试成本。

外部动作：Tool、Function Calling 与 MCP 分别在哪一层

模型可以生成调用意图，但不会因为输出“查询订单”就自动执行数据库操作。动作发生需要宿主侧的可执行契约。

Application provides tool schema
              ↓
Model selects tool + generates arguments
              ↓
Host validates arguments, permission and policy
              ↓
Runtime executes Script / API / browser action
              ↓
Host returns Tool Result to subsequent Context

其中：

• Script / API 是能力实现或系统接口。
• Tool 是 AI 应用暴露给模型选择和请求调用的具体能力。
• Function Calling / Tool Calling 是模型结构化表达工具名与参数的机制。
• Host 或独立 Runtime 负责校验、授权、执行和回传，模型本身不天然拥有这些权限。

当多个 AI Host 需要连接多个外部系统时，会出现重复发现、描述、传输与授权适配。MCP 用 Host、Client、Server 的协议关系标准化这种连接。MCP Server 可以暴露 Tools、Resources 和 Prompts。

因此，MCP 是连接协议，不是 Tool 的同义词，也不是 Agent Runtime。一个 Server 只提供数据库查询仍然完全成立；它不需要持有最终目标或决定任务路径。

选型时可以使用一个简单门槛：单一应用、少量内部能力且接口稳定时，原生 Tool 集成通常足够；多个 Host、多个服务与重复适配已经形成实际成本时，再评估 MCP 的标准化收益。

运行控制：Workflow 与 Agent 的分界是控制权

Tool 解决“可以执行什么”，没有解决“多步任务下一步由谁决定”。

Workflow 由代码、规则或状态机预先定义步骤、顺序和分支。某一步调用 LLM，并不会让整体自动变成 Agent：

Receive input
  ↓ fixed route
Classify with LLM
  ↓ fixed branch
Query data
  ↓ fixed route
Render and save

只要路径控制权仍在预设代码中，它就是带 LLM 的 Workflow。

Agent 在一次运行中持有目标、Context 与状态，根据每次观察动态选择下一步，并判断完成或退出：

Goal + State
    ↓
Model decides next action
    ↓
Tool call or output
    ↓
Observation updates State
    └── continue / finish / request human input

核心判断如下：

场景	更合适的控制方式
步骤和分支可以提前穷举	Workflow / 状态机
LLM 只完成固定流程中的一个节点	带 LLM 的 Workflow
必须根据未预料的中间结果持续改路径	Agent
组织模型、Tool、Workflow、Agent 和共享状态	Orchestration

Agent 不是默认升级。它用更高的不可预测性、评测成本与治理要求，换取对模糊输入和开放分支的适应能力。确定性部分继续交给普通程序和 Workflow，通常更易测试、审计和恢复。

Orchestration 关注整个运行系统如何路由、并行、交接、重试、暂停和恢复。Orchestrator 可以是固定代码、Workflow Engine、Manager Agent 或混合实现。只有它自己持有目标并由模型动态决策时，才同时具有 Agent 属性。

Multi-Agent 进一步要求存在多个相对独立的运行主体，各自拥有角色、Context 或子目标，并发生委派、Handoff 或汇总。多个 Prompt、多个函数和多个并行步骤都不足以单独证明多 Agent。

方法复用：Skill 不是更长的 Prompt

Agent 能够选择下一步，不代表它已经掌握代码审查、文档整理或故障排查的成熟方法。

最初可以把完整方法写进当前 Prompt；当同类任务反复出现，适用条件、流程、参考资料、脚本、异常处理和验收标准就需要作为一个单元维护。Skill 的职责是组织这种可发现、按需加载的工作方法。

Skill 被加载后，其中的文字和必要资料仍会进入 Context。因此，它没有创造新的模型基础能力。它与 Prompt 的边界在系统生命周期和加载方式：

内容	生命周期与职责
Prompt	当前任务的目标、输入与要求
Prompt Template	可重复填写的一段输入模板
Skill	一类任务的可发现方法及配套资源
AGENTS.md / Project Instructions	项目或目录范围内持续生效的规则
Plugin	Skill、MCP 与其他集成能力的组合、安装和分发

复杂 Skill 也不会自动成为 Agent。只要最终目标、当前状态和生命周期仍由宿主 Agent 持有，Skill 就是被加载的方法。

治理要与外部动作同时进入设计

当系统从生成文字扩展到修改文件、发送消息、操作数据库和调用付费服务，治理要求必须进入架构：

• Permission / Authorization：是否有权读取数据或执行动作。
• Sandbox：代码和命令在哪个隔离边界运行。
• Guardrail：输入、输出与工具调用前后的规则校验。
• Human in the Loop：高风险、歧义与异常如何交给人确认或接管。
• Eval：怎样用样本与标准判断任务是否真正完成。
• Trace / Observability：怎样记录模型、工具、耗时、错误与状态。
• Checkpoint：长任务怎样暂停、恢复与避免重复动作。

这些能力可以与 Skill、MCP 和 Agent Runtime 协作，但不能被一段“请安全执行”的指令替代。

用五个问题完成架构初筛

面对一个新需求或新名词，可以按以下顺序缩小方案：

1. 要改变模型参数，还是只影响本次运行？
2. 当前缺的是指令、知识、方法、动作，还是路径控制权？
3. 这项内容服务一次任务、一类任务，还是长期项目？
4. 下一步可以由固定代码决定，还是必须由模型结合结果动态判断？
5. 它是实际能力，还是连接、编排、治理或分发职责？

这五问不会替代框架评测、容量规划和安全设计，但能提前排除类别错误。一个可评审的 AI 架构不取决于名词数量，而取决于每项职责是否具有明确输入、输出、控制权、权限边界、失败路径和验证方式。

先定位任务缺口，再承担与它对应的复杂度。Prompt、RAG、MCP、Agent 和 Skill 可以共同工作，但从来不是一组互相晋级的替代方案。