AI产品经理技术基础:怎么区分FC、MCP、Skills、Execution、API和CLI?

设计AI的工具调用，需要说清：模型怎样提出请求，应用怎样接入能力，操作由谁执行，以及步骤和方法怎样组织。

Function Calling、MCP、API、CLI、Code Execution和Skills分别参与这些工作。分清它们的职责和连接关系，才能判断怎样选择、怎样组合。

一、先看一条调用路线：每项技术放在哪？

以发邮件为例：模型用Function Calling给出收件人、主题和正文；助手程序检查参数和权限，通过邮箱API发送，再读取返回状态。Function Calling负责传达请求，API负责操作邮箱。

下面的图在这条基础路线上，加上MCP、代码运行和Skills，看看它们各自改变什么。

发信能力也可以做成一套MCP服务，支持MCP且获授权的内外部应用都能接入，减少逐个应用定制对接的成本。

如果20份附件要“按邮箱去重、统计各部门人数、导出CSV”，现成工具又不支持这套处理，可以让模型编写Python代码，交给Code Execution环境运行，取得统计结果和文件。已有程序能完成的固定处理，直接复用就够了。

Skills可以给助手补充一类任务的专业知识和做事流程。比如数据分析Skill，既说明指标怎么算，也规定查什么数据、怎样校验、按什么模板出报告，还可以附带处理脚本。

二、沿着这条路线，怎么选、怎么组合？

沿着上面的调用路线，选择可以分成四件事：

如何选择合适的技术方案，是构建工具调研的核心，下面我们会把每个环节的方案选择进行对比说明：

1. 动作怎么交给程序：FC还是自己约定格式？

模型要知道工具的用途、输入要求和结果含义。使用原生Function Calling时，按模型接口提供说明，模型用专用调用消息提交名称和参数，程序执行后返回对应结果。

也可以约定模型输出JSON或动作文本，由应用自己解析执行。

原生FC省下从头设计调用消息和结果关联的工作；代价是按模型接口适配，真正执行和校验仍由应用负责。

自行约定能沿用成熟流程、适配特殊动作表达；代价是解析、错误反馈和结果关联规则都要自己维护。

接口规则满足任务，就优先原生FC；已有成熟解析流程或特殊格式需求，再考虑自行约定。

2. 工具怎么接进来：自己对接，还是用MCP？

直接接入，应用调用已有代码、SDK或软件API；MCP接入，应用通过Client按统一规则发现和调用Server提供的能力。FC处理模型的请求表达，MCP处理应用与能力服务的连接，可以一起使用。

直接接入能沿用现有代码，少一套协议适配与服务配置；软件接口和授权方式变化时，对接仍要自己维护。

MCP能复用现成服务，给不同兼容应用统一接法，减少重复集成；代价是协议兼容、授权和服务维护。

现有实现够用，就直接接；已有合适的MCP服务，或需要统一向不同应用提供能力时，再考虑MCP。

3. 现成软件怎么用：API还是CLI？

API让程序按软件接口调用操作，CLI让程序运行命令。两者都能放在应用或MCP服务内部。

CLI对编程和运维Agent的吸引力，在于一个通用Shell入口可以组合Git、文件、测试等现成工具，不用为每条命令单独定义工具。开放给Agent的动作空间可以更大，代价是运行和控制更复杂。

API在操作、参数和返回约定清楚时，便于校验、授权和记录；代价是按接口对接，跟进接口变化，未开放的操作仍需另找实现。

CLI能复用命令行工具生态，通过Shell灵活组合操作；代价是管理依赖、工作目录、输出和允许执行的范围。命令退出成功也不等于任务完成。

业务动作明确、接口约定清楚，优先API；需要组合多个本地工具且已有成熟命令，考虑受控Shell加CLI。比较的是实际开放能力，不能只按API或CLI的名字排强弱。

4. 多步任务怎样组织，何时用代码执行？

先区分谁安排步骤、代码在哪里运行。程序化调用负责循环和分支，Code Execution负责实际运行；代码可以来自已有程序，也可以由模型生成。

模型逐步判断能根据新内容调整路线，适合不确定任务；如果每步都读结果再推理，会增加往返、上下文占用和过程波动。

程序组织能批量、循环、筛选，步骤和中间数据更容易控制；前提是规则明确，代码、依赖和错误处理需要维护。Code Execution能运行临时生成的代码，但不保证代码或结果正确。

明确的重复步骤交程序，确实需要理解和判断的环节交模型；现成工具不覆盖临时处理需求时，再让模型写代码并提供可用执行环境。FC可以提交运行请求，代码再按环境权限使用API、CLI或MCP。

5. 专业知识和任务流程，怎样交给助手？

Skills把一类任务的专业知识、流程、工具用法、模板与可选脚本封装起来。除了按需加载，更重要的是专业经验能被维护、共享，并配合工具完成任务。

少量固定要求留在提示词；一类专业任务的知识、流程与资源需要整体维护和复用时，采用Skills。

上下文压力也要按来源处理：工具说明多，筛选或按需发现；专业资料多，按需加载；结果数据大，先用程序处理。

三、从关系图走向具体机制

分清这些职责，产品经理就能把“接几个工具”拆成具体的设计问题：现有能力怎样接入，哪些处理交给程序，哪些专业知识和流程需要提供给模型，新增组件又要付出什么维护成本。

接下来的四篇，会把这张关系图里的关键机制讲透：

• 第15篇，工具适配与调用
  ：怎样让模型理解现有API或CLI？工具说明、参数和返回结果该如何设计？
• 第16篇，MCP
  ：工具怎样被发现和调用？接入现成服务与自己提供服务，分别要做什么？
• 第17篇，代码执行与程序化调用
  ：模型生成的代码怎样运行、检查结果，并组织多次工具操作？
• 第18篇，Skills
  ：专业知识和流程怎样封装、共享与按需加载，又怎样配合工具完成任务？