假设你让 AI 给客户准备一份报价。
它很快写出一封漂亮的邮件，但产品价格是旧的，交期是猜的，折扣也没按公司的规定来。你把资料和要求重新解释了一遍，它终于改对。第二天换个同事，又得解释一遍。
这里至少有两个问题：AI 能不能拿到当前资料，以及它知不知道公司要求怎么做事。
MCP 和 Skill，分别能帮助解决这两类问题。老板可以先记住：MCP 让 AI 应用按一套通用协议接入外部能力；Skill 把一类工作的做法整理成 AI 可以读取、复用的任务包。
两者经常一起用，也可以分开用。公司不用为了“跟上技术”同时装齐。
MCP：让 AI 应用接上外面的系统
MCP 的全称是 Model Context Protocol，中文通常译作“模型上下文协议”。它约定 AI 应用与外部服务如何交换上下文、发现和调用能力。官方架构说明
举个例子，公司库存放在 ERP 里。工程师可以做一个 MCP 服务，对外提供“按产品编号查询可用库存”的工具。支持 MCP 的 AI 应用接入后，就有机会调用这个工具，拿到系统里的结果。
这中间真正查 ERP 的，仍然是服务背后的程序和接口。MCP 提供共同的接入约定，不会自动替你打通所有企业软件。
大家说“装一个 MCP”，通常省略了后半句：配置一个 MCP 服务，或者连接一个现成服务。MCP 本身是协议。
它能提供的也不只有工具，还包括资源和提示模板。读者先理解“接入外部能力”就够了，不需要背协议细节。
如果原系统没有可用接口，也没有现成接入方式，工程师还要解决取数问题。不能在方案里写上 MCP，就把这部分工作算作完成了。
Skill：把工作做法放进一个可复用的包
这里说的 Skill，是 Agent Skills 这类技能包，不是所有产品里名字叫“技能”的按钮。
按开放规范，一个 Skill 的基本形式是文件夹，里面有一份 SKILL.md，写明名称、适用场景和操作说明；也可以带参考资料、模板、脚本。支持它的 Agent 通常先识别简短描述，在相关任务中再加载详细内容。Agent Skills 规范
还是报价这件事。一个“销售报价准备”Skill 可以写清楚：
- 先确认产品型号、数量、收货地区和客户要求的交期。
- 价格以有效报价表为准，注明来源和日期。
- 缺少折扣授权时，把申请列给负责人，不自行批准。
- 按公司模板输出报价草稿；信息不全就标出来，暂不发送。
员工不用每次从头解释这些要求。业务负责人调整了报价流程，也有一份明确的位置可以修改。
但 Skill 不会把知识训练进模型，也不保证每次执行都一样。它影响 Agent 做事的方式，结果依然要检查。涉及精确计算的步骤，可以交给脚本；涉及系统权限的限制，要在系统里执行。
把“不得擅自打折”写在 Skill 里，是工作要求。让未经审批的折扣无法提交，是程序和权限设计的责任。
知识库又放在哪里？
这几个词很容易搅在一起。我会按下面这张表拆开：
| 组成 | 回答的问题 | 报价场景里的例子 |
|---|---|---|
| 知识库 | 有哪些资料可查？ | 产品说明、售后政策、历史方案 |
| MCP 服务 | AI 应用能通过什么能力访问系统？ | 查询库存、检索产品资料、创建报价草稿 |
| Skill | 这类工作按什么步骤和标准做？ | 必须补齐哪些字段、用哪份模板、何时请示 |
| Agent 应用 | 谁组织这些步骤并调用工具？ | 读取任务、调用查询、生成草稿的工作台 |
企业知识库可以通过 MCP 提供检索能力。Skill 可以告诉 Agent，报价前先检索哪类资料。资料仍然存在知识库里，实时库存仍然由业务系统管理。
因此，别把每天变化的库存和价格复制进 Skill。那里适合写“去哪里查、以什么为准、查不到怎么办”。
“MCP 管连接、Skill 管做法”是便于入门的概括，边界并非绝对：MCP 也能提供提示模板，Skill 里的脚本也能直接调用接口。实际选用时，要看哪种方式更容易维护。
什么时候用，什么时候先别用？
偶尔改一封邮件，把要求说清楚，直接对话就行。
每周都做同一种工作，每次都要强调格式、判断规则、例外情况，就值得考虑 Skill。比如周报整理、方案审阅、询盘回复草稿。先把已经跑通的做法整理下来，比下载几十个技能更有帮助。
频繁复制系统里的数据给 AI，信息又容易过期，可以考虑 MCP 接入。特别是多个支持 MCP 的 AI 应用要复用同一项企业能力时，共同的接口约定可能减少重复适配，但仍需逐一验证兼容性。
公司已经有好用的 API、CLI 或原生连接器，也可以继续用。一个内部脚本只服务一个任务，未必需要再包一层 MCP。
至于金额计算、库存扣减这类规则明确的处理，仍适合由程序确定执行。AI 可以帮助理解需求、补问字段、整理说明，不必让模型临场决定每一步。
企业可以这样开始：先做一份报价草稿
下面是一个建议试点，沿用开头的虚构场景，不代表已取得的项目效果。
第一步，找销售负责人拿出几份可以用于测试的报价资料。写明哪些字段必填，谁能决定折扣，遇到缺货怎么处理。先用模拟数据，准备几条正常需求，再放进型号不明、过期价格、库存不足等异常情况。
让 AI 用这些资料做一次报价草稿。业务负责人逐项修正，把反复需要提醒的做法整理成 Skill。此时完全可以先用本地文件，不急着连接 ERP。
等这个流程有价值了，再观察哪里还在人工搬运。如果销售每天都要查库存、导价格，就由工程师评估接口，优先接入必要的只读查询。需要跨 AI 应用复用时，再考虑通过 MCP 提供。
一个可执行的试点任务可以这样写：
根据客户需求准备报价草稿。先检查型号、数量、地区和交期是否完整；缺失时列出待确认项。查询有效价格和库存，注明数据来源及查询时间。遇到多个同名产品先请求确认。没有授权的折扣只列为申请，不计入正式报价。按模板生成草稿和未解决问题，交销售负责人审核，暂不发送给客户。
这里有两个交付物：一份公司认可的工作做法，以及一组经过验证的系统能力。前者可以放进 Skill，后者可以通过 MCP 或现有接口供 Agent 调用。
审核通过后是否写回 CRM、是否发送邮件，是下一阶段的范围。新增这些动作时，要另外验证授权、重复提交和失败处理。
怎么判断用起来有没有效果？
还是拿报价来说。过去准备一份报价要多久，用上以后，连同检查和修改又花了多久？如果生成快了，核对却更费劲，这个流程就还需要调整。
除了时间，也看看员工还在反复纠正什么。每次都忘记填写交期，就回头检查 Skill 有没有写清要求；价格总是过期，就检查资料来源和查询方式。问题出在哪一层，就改哪一层。
先留几份做对的样例，再加上型号不明、价格失效这样的异常情况。以后改了 Skill、换了模型或接入方式，用它们重新试一次。正常需求能完成，拿不准的地方能明确提出来，才值得继续交给它做。
还有一个很实际的检查：换个同事，能不能照着同一套做法完成？如果只有最初配置的人会用，就把缺少的说明补上。等团队能稳定复用这一项工作，再考虑增加新任务。
老板可以先问团队：哪件工作每次都要重新交代？哪份资料每天都要复制来复制去？前一个问题适合从 Skill 入手，后一个值得评估系统接入。把这件工作做顺，再决定是否扩大。