上一篇我们讲到，RAG 解决的是“模型依据什么回答”。

它让模型不再只依赖参数里的通用知识，而是可以在当前任务中拿到企业文档、制度规范和业务资料。

但知道还不够。

一个真正进入业务的 AI，不只是要能读资料，还要能查数据库、调用接口、操作文件、运行命令、创建任务、发送通知。

也就是说，问题从“模型如何获得知识”变成了“模型如何调用外部世界”？

这里就会出现三个经常被混在一起的概念：

Function Call、MCP、CLI。

1. 很多人会问：

Function Call 和 MCP 是不是一回事？

有了 MCP，还要不要 API？

CLI 算不算工具调用？

AI 编程助手为什么经常需要命令行？

这篇文章要讲清楚它们之间的关系。

一句话先说结论：

Function Call 解决“模型如何发起调用”；MCP 解决“工具如何标准化接入”；CLI 解决“如何在系统层执行命令”。

它们不是替代关系，而是工具层的不同分工。

一、模型会说“我已经完成”，不代表系统真的完成了

很多 AI 应用最容易出现的错觉是：

模型说它做了，就以为它真的做了。

比如用户说：

帮我创建一个明天下午三点的项目会议。

如果模型只是回复：

已经为你创建会议。

这并不代表会议真的存在。

除非它调用了日历系统，传入了时间、参会人、会议主题，并且日历系统返回创建成功。

否则，“已创建”只是语言生成。

大模型原生能力是理解和生成，并不会天然拥有外部系统的执行权。OpenAI 的 Function Calling 文档也把这件事讲得很清楚：模型可以和外部系统交互，但外部能力由应用提供，工具通常通过结构化 schema 定义，模型生成调用参数，真正执行仍发生在你的应用系统里。

所以，从“会说”到“会做”，中间必须有一道工程边界：

模型负责判断要调用什么

系统负责校验和执行

工具负责产生真实结果

这一点非常关键。

如果不区分“模型生成动作描述”和“系统真实执行动作”，AI 应用很容易变成一个会编造执行结果的聊天机器人。

二、Function Call：把自然语言意图变成结构化调用

Function Call 的本质，是让模型把用户的自然语言目标，转换成机器可以执行的结构化请求。

比如用户说：

帮我查一下客户 A 最近一次退款进度。

模型不应该直接编一个答案。

它应该判断：这个问题需要查询退款系统。

于是生成类似这样的调用意图：

{"tool": "query_refund_status","arguments": {"customer_name": "客户A"}}

注意，这里有三个动作：

第一，模型判断需要使用哪个工具。

第二，模型生成这个工具所需的参数。

第三，外部系统接到请求后执行真实查询。

Function Call 只完成前两步。

真正访问数据库、调用接口、返回结果，是应用程序或工具服务完成的。

所以：

Function Call 不是让模型自己执行代码，而是让模型用结构化方式表达“我要调用什么”。

这也是它和普通文本生成最大的区别。

普通文本生成输出的是一句话；

Function Call 输出的是一个可执行请求。

这使得模型可以从“回答系统”，变成“调度系统”。

但也带来一个新问题：

• 模型生成的参数可能错；

• 工具选择可能错；

• 用户可能没有权限；

• 工具执行可能失败；

返回结果可能需要二次解释。

因此，一个真正可用的 Function Call 系统，不能只靠模型判断，还必须有：

• 参数校验；

• 权限检查；

• 错误处理；

• 执行日志；

• 结果回传；

必要时人工确认。

模型可以提出动作，但系统必须负责动作的边界。

三、MCP：解决工具如何标准化接入

如果工具只有几个，Function Call 加一些 API 封装就够了。

但真实企业环境里，AI 应用要连接的东西会越来越多：

• 数据库；

• 文件系统；

• Git 仓库；

• CRM；

• 工单系统；

• 浏览器；

• 搜索服务；

• 内部 API；

• 本地脚本；

• 命令行工具。

如果每个 AI 客户端都要单独适配每个工具，复杂度会迅速失控。

这时，MCP 的意义就出现了。

MCP，也就是 Model Context Protocol，官方定义是一个用于连接 AI 应用与外部系统的开放标准。它可以让 AI 应用连接数据源、工具和工作流，官方文档也用“AI 应用的 USB-C 接口”来类比它的作用。

可以这样理解：

API 是某个业务系统本来就有的接口；

MCP 是把这些接口、资源和工具，用一种更统一的方式暴露给 AI 应用。

MCP Server 可以向 AI 客户端暴露几类能力：Tools 用于执行动作，Resources 用于提供文件、数据库结构等上下文，Prompts 用于提供结构化任务模板；MCP 官方文档也明确把这些作为 Server 侧概念来组织。

所以，MCP 不是另一个 Function Call。

它解决的是更底层的接入问题：

工具怎么被发现；

工具能力怎么描述；

资源怎么提供给模型；

多个 AI 客户端如何复用同一套工具服务；

工具和数据如何以统一协议接入。

一句话：

Function Call 解决“怎么调用”；MCP 解决“工具怎么被接进来”。

两者经常一起工作。

模型通过 Function Call 表达调用意图；

MCP 负责把这个调用路由到标准化接入的工具服务；

工具执行后，再把结果返回给模型。

四、CLI：AI 操作系统和开发环境的关键入口

API 和 MCP 更偏“服务接口”。

CLI 则更偏“系统执行入口”。

CLI，全称 Command Line Interface，也就是命令行界面。

对于程序员来说，CLI 太常见了：

npm testgit statuspython main.pypytestdocker buildkubectl get pods

这些命令本来是人敲给操作系统或开发工具的。

但在 AI 编程、自动化运维、数据处理场景里，CLI 会变成非常重要的工具入口。

为什么？

因为很多真实工作不是调一个 API 就能完成的。

比如一个 Coding Agent 修复 bug，它可能需要：

• 读取代码文件；

• 查看 Git diff；

• 运行测试；

• 根据报错修改代码；

• 再次运行测试；

• 最后生成修复说明。

这里的很多动作，都天然发生在命令行里。

所以，CLI 是 AI 从“理解代码”走向“参与开发工作流”的关键接口。

但 CLI 也最危险。

因为命令行可以做很多事情：

• 删除文件；

• 修改配置；

• 启动服务；

• 访问环境变量；

• 连接生产集群；

• 执行脚本。

如果让模型直接生成任意 shell 命令并执行，风险非常高。

更成熟的做法不是暴露一个“万能 shell”，而是把 CLI 包装成受控工具。

例如：不要给模型 run_any_command；

而是提供 run_tests、check_git_status、format_code、build_project 这类限定工具。

这样模型仍然可以使用命令行能力，但它调用的是被封装、被限制、可校验的 CLI 能力。

所以：

CLI 是执行入口，不是权限边界。权限边界必须由工具封装和运行环境来提供。

五、Function Call、MCP、CLI 到底是什么关系？

这三个概念最容易混淆，因为它们都和“工具”有关。

但它们处在不同层。

概念 解决的问题 更像什么

• Function Call 模型如何发起一次工具调用 调用动作

• MCP 工具和数据如何标准化接入 AI 应用 连接协议

• CLI 如何在操作系统或开发环境里执行命令 执行入口

• API 业务系统暴露能力的接口 服务接口

• Agent 谁根据目标持续选择和使用工具 执行者

可以用一个例子串起来。

用户说：

帮我检查这个项目的测试是否通过。

系统运行过程可能是：

第一步，模型理解任务，判断需要运行测试。

第二步，模型通过 Function Call 生成调用请求：

{"tool": "run_project_tests","arguments": {"project_path": "./app"}}

第三步，这个工具可能由 MCP Server 暴露给 AI 客户端。

第四步，MCP Server 内部执行受控 CLI：

npm test

第五步，CLI 返回 stdout、stderr、exit code。

第六步，结果回到模型，模型判断测试是否通过，并决定是否继续修复。

这一整条链路里：

Function Call 是模型发起调用的方式；

MCP 是工具接入和通信的标准层；

CLI 是底层真正执行命令的入口。

所以三者不是谁替代谁，而是上下游关系。

六、企业实践中，工具层要怎么设计？

工具层的设计质量，会直接决定 Agent 的行动质量。

很多团队做工具调用时，会犯一个错误：

先把所有 API、脚本、命令都暴露给模型，然后希望模型自己选对。

这很危险。

模型不是工具管理员。

它需要清晰、有限、可验证的工具集。

工具颗粒度要合适

工具太粗，模型无法精确控制。

例如：

manage_customer

这个工具太模糊。

到底是查询客户、更新客户、删除客户，还是创建任务？

工具太碎，又会增加选择难度。

更好的方式是围绕业务动作设计：

• query_customer_profile

• query_customer_refund_status

• create_customer_followup_task

2. 查询和修改要分开

只读工具和写入工具一定要分层。

查询客户状态和取消订单，不应该放在同一个工具里。

因为它们风险完全不同。

只读工具可以更自动化；

写入工具需要权限、确认和审计。

CLI 不要裸奔

不要把任意命令执行权直接交给模型。

更好的方式是白名单化：

• 允许运行测试；

• 允许查看 Git 状态；

• 允许执行格式化；

• 允许读取指定目录日志；

• 禁止删除文件；

• 禁止访问生产密钥；

• 禁止执行未知脚本。

对于 CLI 工具，还要设置：

• 工作目录；

• 超时时间；

• 最大输出长度；

• 环境变量隔离；

• 敏感信息脱敏；

• 沙箱执行环境。

工具返回结果要适合模型理解

工具返回一大段原始日志，模型未必能抓住重点。

可以让工具返回结构化结果：

{"success": false,"exit_code": 1,"summary": "3 个测试失败","failed_cases": ["test_user_login","test_payment_callback"],"raw_log_ref": "log_123"}

这样模型更容易继续判断下一步。

高风险动作必须有人类确认

涉及这些动作时，不建议完全自动执行：

• 付款；

• 退款；

• 删除数据；

• 发送外部邮件；

• 发布生产环境；

• 回滚核心服务；

• 修改权限配置。

成熟系统应该设计 Human-in-the-loop。

模型可以准备方案，但关键动作要由人确认。

七、这一篇的核心判断

Function Call、MCP、CLI 共同解决的是 AI 应用的工具层问题，但它们不是一个层级的东西。

Function Call 让模型从自然语言走向结构化调用；

MCP 让外部工具和数据以标准方式接入 AI 应用；

CLI 让 AI 可以在操作系统、开发环境和工程流程中执行真实命令。

如果说 RAG 给模型提供“依据”，那么工具调用给模型提供“行动能力”。

但行动能力本身并不等于可靠执行。

真正重要的不是让模型能调用更多工具，而是：

让模型在正确边界内，调用正确工具，执行可验证动作，并把结果带回任务循环。

到这里，AI 已经有了知识，也有了工具。

但它仍然可能每次都临场发挥。

下一篇我们继续讨论：

AI 应用架构地图 06｜Skill：如何把经验封装成可复用的 AI 能力