ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

为什么有了大模型,还需要 Skill、MCP、Agent 和 Workflow?

为什么有了大模型,还需要 Skill、MCP、Agent 和 Workflow?

大语言模型已经能够理解问题、编写代码、分析文档,甚至生成完整的解决方案。既然模型越来越聪明,为什么开发 AI 应用时,还需要 Skill、MCP、Agent 和 Workflow 这么多组件?

以企业智能客服为例。

客户提出退货申请后,AI 需要理解退货原因、查询订单、检查退货条件,并在符合规则时发起后续处理。如果遇到超出权限的请求,还必须停止操作或转交人工。

仅仅让模型生成一段看起来合理的回答,并不能保证这些事情真正完成。

AI 应用还需要解决任务知识如何复用、外部系统如何连接、复杂任务如何决策,以及关键操作如何受到约束等问题。

这正是 Skill、MCP、Agent 和 Workflow 发挥作用的地方。它们解决的是不同层面的问题,可以组合使用,而不是相互替代。

一、Prompt:告诉模型当前要做什么

Prompt(提示词)是提供给模型的指令和上下文,用于说明任务目标、限制条件和预期输出。

例如:

请分析客户的退货申请,查询相关订单,判断是否满足退货条件。如果信息不足,请继续询问;如果涉及特殊审批,不要直接执行退款。

这段 Prompt 说明了当前任务需要完成什么,以及哪些操作不能随意执行。

但 Prompt 不是执行能力本身。

即使模型准确理解了退货要求,如果应用没有提供订单查询工具,它也无法真正查询订单;如果没有接入退款系统,它也不能仅凭一段指令完成退款。

当一类任务反复出现时,还会产生另一个问题:每次都重新输入大量操作规范,不仅增加维护成本,也容易造成规则不一致。

因此,需要将可复用的任务知识与当前任务指令区分开来。

二、Skill:把可复用的任务知识组织起来

Skill 可以理解为一套可复用的任务知识与操作方法。

在常见的 Agent Skills 实现中,一个 Skill 通常包含SKILL.md说明文件,也可以包含参考资料、示例、模板或脚本等。不同平台的具体实现和加载机制可能有所不同。Agent Skills 规范

例如,企业可以建立一个退货处理 Skill,说明:

  • 需要收集哪些订单信息。
  • 如何检查退货申请是否满足业务条件。
  • 哪些特殊情况必须转交人工。
  • 执行退款前需要进行哪些检查。
  • 完成操作后需要核对什么结果。

这些知识可以在不同的退货任务中复用,而不必每次重新编写。

但是,Skill 不等于自动执行程序。

Skill 可以指导系统如何处理任务,也可能携带可执行脚本,但能否执行取决于运行环境是否支持相应能力。仅仅在 Skill 中写明“必须核对订单”,并不能保证订单已经被真实查询。

Skill 解决的是任务方法如何沉淀和复用的问题,不保证任务必然执行成功。

三、MCP:让 AI 应用标准化地连接外部能力

模型能够理解“查询订单”,不意味着它天然拥有访问企业订单系统的权限。

要完成真实操作,应用需要提供相应的工具,例如:

  • 查询订单。
  • 查询退货记录。
  • 检查退款资格。
  • 发起退款申请。
  • 查询退款处理状态。

MCP(Model Context Protocol,模型上下文协议)是一种开放协议,用于标准化 AI 应用与外部工具、数据等系统之间的交互。

MCP Server 可以向兼容的客户端提供不同能力:

  • Tools(工具):可调用的操作,例如查询订单或创建退款申请。
  • Resources(资源):可读取的数据或上下文。
  • Prompts(提示模板):可复用的提示模板。

相关能力的具体实现可以参考 MCP 官方 SDK 文档。

在退货场景中,订单系统可以通过 MCP Server 暴露一个订单查询工具。AI 应用发现该工具后,可以按照协议提供参数、发起调用并接收结果。

但 MCP 本身并不负责查询订单或执行退款。真正的业务操作仍由工具实现及其背后的系统完成。

例如,MCP 调用正常返回,只能说明这次协议交互得到了响应。订单是否存在、退款是否成功,仍然需要根据返回内容和实际业务状态判断。

因此,MCP 解决的是外部能力如何被发现、连接和调用的问题,而不是由谁决定下一步该做什么。

四、Agent:理解目标并根据结果决定下一步

Agent(智能体)是一种围绕目标组织模型、工具、上下文和执行机制的 AI 应用形态。

与只生成一段回答的模型调用相比,Agent 可以在执行过程中根据工具结果继续判断和行动。

例如,处理退货申请时,Agent 可能需要:

  1. 理解客户的退货诉求。
  2. 判断需要补充哪些信息。
  3. 调用订单查询工具。
  4. 根据订单状态和业务规则,分析下一步应当做什么。
  5. 在允许的范围内调用相应工具。
  6. 根据执行结果继续处理,或转交人工。

如果查询结果显示订单已经超过退货期限,Agent 可以解释原因;如果缺少订单编号,可以要求客户补充;如果涉及特殊审批,可以转交相应流程。

Agent 的价值在于处理自然语言理解、上下文判断和不确定情况,而不只是按照固定步骤机械运行。

但 Agent 不一定完全自主,也不保证每次判断正确。它能够采取什么行动,仍然受到工具权限、系统规则和运行机制的限制。

五、Workflow:明确任务步骤与执行约束

Workflow(工作流)用于组织任务的执行步骤、条件分支和状态流转。

退货处理通常需要遵循明确的业务顺序:

  1. 确认客户身份及操作权限。
  2. 查询订单。
  3. 检查退货条件。
  4. 根据规则决定是否需要审批。
  5. 满足执行条件后发起相应操作。
  6. 核对实际处理结果并返回状态。

可以将其表示为:

收到退货申请 ↓ 身份与权限检查 ├─ 不通过 → 拒绝操作或转交人工 └─ 通过 ↓ 查询订单 ↓ 检查退货条件 ├─ 不满足 → 说明原因 ├─ 需要审批 → 进入审批流程 └─ 满足条件 ↓ 发起退款申请 ↓ 查询实际处理结果 ↓ 返回真实状态

这里的关键不是流程图本身,而是每一步的执行条件都可以被明确表达和检查。

例如,退款申请必须在身份校验通过后才能发起;某类特殊退款必须经过审批;操作失败后只能按照规定的重试策略处理。

这些约束不应该仅仅写在 Prompt 或 Skill 中,而应当由工作流、业务程序、权限系统等实际落实。

Workflow 也不意味着每一步都只能使用固定代码。它可以在某些节点调用 Agent,让模型处理需要理解或分析的任务,再由流程控制后续步骤。

六、四个核心概念如何协作?

在同一个 AI 应用中,它们可以形成清晰的职责分工。

组成部分核心职责退货处理示例
Prompt描述当前任务分析退货申请并查询订单
Skill提供可复用的任务知识退货处理规范与检查要求
MCP标准化连接外部能力连接订单查询、退款申请工具
Agent理解目标并作出判断分析退货原因,决定下一步行动
Workflow组织步骤并约束执行控制权限检查、审批、重试和状态流转

一个典型的协作过程是:

客户提出需求 → Agent 理解目标 → 使用 Skill 提供的任务知识 → 通过工具或 MCP 获取外部能力 → Workflow 控制关键步骤 → 工具返回结果 → 系统验证业务状态 → 返回最终处理结果。

需要注意,这只是一个示例架构,并非所有 AI 应用都必须同时使用这些组件。具体设计取决于任务的复杂度、复用需求、外部连接需求和风险水平。

七、Agent 与 Workflow:为什么不能完全互相替代?

两者最容易混淆,因为它们都可能参与任务执行。

区别在于,Agent 更适合处理需要理解和判断的问题,而 Workflow 更适合明确任务执行路径与约束。

例如,客户描述退货原因时,表达方式可能非常多样,Agent 可以理解不同说法并提取关键信息。

但退款操作必须满足明确的业务条件。这些条件不能因为 Agent 认为客户的理由合理,就被随意绕过。

因此,比较合理的设计是:

  • 由 Agent 理解客户诉求、分析异常和提出建议。
  • 由 Workflow 组织处理步骤,并控制必须满足的条件。
  • 由业务系统执行身份校验、权限检查和实际退款操作。
  • 由结果验证机制确认操作是否真正完成。

OpenAI 的 Agents SDK 编排文档也介绍了由模型决定下一步与通过代码控制流程两类编排方式,并说明它们可以组合使用。

八、出现问题时,应该检查哪一层?

理解组件的区别,还有一个实际价值:能够更准确地定位问题。

故障现象优先检查
模型没有遵循退货处理规范Prompt、Skill 是否正确提供和加载
无法找到订单查询工具工具注册、MCP 连接及工具发现
模型错误理解客户的诉求输入信息、上下文和 Agent 判断逻辑
未经审批就执行退款Workflow、权限校验和业务规则约束
工具调用返回成功,但退款未完成工具实现、外部系统响应和业务状态验证
失败后无限重试工作流状态控制、重试上限和异常处理

这只是排查的起点,不能代替实际日志、调用记录和业务状态证据。

尤其需要注意两个边界。

第一,权限不能只靠提示词保证。

如果某个客户没有退款权限,系统必须在工具或后端业务服务中进行授权检查。不能只依赖模型记住“不要越权操作”。

第二,工具调用成功不等于业务操作成功。

接口可能正常返回,但返回内容表示业务失败;即使接口报告成功,也可能仍然需要查询实际业务状态进行核对。

可靠的系统必须明确什么才算成功,并通过可验证的结果确认任务完成。

总结

大模型提供了理解和生成能力,但将模型变成能够可靠处理业务任务的应用,还需要解决不同层面的问题。

Prompt 描述当前任务,Skill 沉淀可复用的任务知识,MCP 标准化外部连接,Agent 根据目标和执行反馈作出判断,Workflow 则组织任务流程并落实关键约束。

它们可以组合使用,但不能相互替代。

可靠的 AI 应用,不是把所有事情都交给模型自由发挥,而是让模型在适合的范围内进行判断,同时由系统明确执行边界、落实必要约束,并验证最终结果。

参考资料

  1. Agent Skills 规范:Skill 的文件组织与任务指引。
  2. MCP TypeScript SDK 官方文档:MCP 客户端、服务端、工具、资源与提示模板。
  3. OpenAI Agents SDK:Agent 编排:模型驱动的编排与代码控制的流程。
  4. OpenAI Agents SDK:Guardrails:输入、输出及工具调用的检查机制。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进