外部能力通过 API、CLI 或 MCP 接入 Agent 时如何选择？

核心回答

选择依据是已有能力、调用方和运行环境。API 适合自有服务直接集成，便于控制请求、认证和错误；已有成熟命令行能力且环境可控时，可以封装 CLI；多个兼容宿主需要统一发现和调用能力时，MCP 更有复用价值。

这几种方式可以组合：MCP Server 内部调用业务 API 或执行已有 CLI，Agent 再通过工具调用使用它。Function Calling 负责让模型给出结构化调用意图，Skill 可以补充任务方法。协议名称不决定权限、可靠性或性能，具体执行端仍要处理这些问题。

在同一需求下比较

以“查询订单并导出对账数据”为例：

条件	倾向选择	需要承担的工作
订单系统已有稳定接口，自有后端使用	直接接 API，再包装工具	参数与响应适配、身份传递、超时和错误映射
已有可输出结构化结果的对账命令	封装 CLI	版本安装、进程管理、退出码、输出解析与路径限制
多个支持 MCP 的宿主共用对账能力	提供 MCP 接入层	工具发现与调用契约、客户端兼容、身份与服务运维

有 API 不等于要把所有底层接口直接给模型。可以提供面向任务的工具，例如“按日期导出对账数据”，由执行层完成分页、字段筛选与结果存储。工具说明应让模型知道适用场景、参数和限制。

CLI 怎样包装才可靠

优先传递独立参数列表，避免拼接含用户内容的 shell 字符串。固定允许执行的命令和工作目录，设置超时，捕获退出码及 stdout、stderr，让业务输出与诊断日志有清晰分工。

命令返回零退出码后，还要检查预期结果或输出文件；非零退出码需要映射成模型能理解的错误。执行超时不能自动说明远端业务操作没发生，例如命令可能已经提交了导出任务，只是没等到响应，应先查询任务状态。

CLI 完全可以处理认证。凭证可以由受控配置、系统凭证库或执行端环境注入，模型只需要业务参数；同时要避免密钥出现在命令输出、日志和工具结果中。

MCP 增加了什么，没增加什么

MCP 统一工具描述、发现和调用消息，减少各宿主分别定义接入协议的成本。仍需核对协议版本、客户端支持、传输方式和返回呈现；不能把“支持 MCP”理解为所有特性都兼容。

本地 stdio 服务和远程 HTTP 服务是部署选择，不能简单等同于“CLI 只能本地、MCP 只能远程”。远程受保护服务可按 MCP 的授权规范处理访问；本地服务通常从环境或受控执行上下文取得凭证。业务服务还需要核对调用者能访问哪些订单。

是否采用 MCP，最终看标准接入收益是否超过新增协议和运维成本。只有一个可控客户端、工具数量很少时，直接集成可能更省事。

追问

MCP 一定比 CLI 更慢吗？

不能只凭名称判断。进程启动、网络、依赖加载和业务处理都可能占主要耗时；MCP 可以包装常驻服务，也可能每次启动一个命令。需要在同一任务下测量。

CLI 能否不让模型感知密钥？

可以，由执行端取得凭证后调用服务，工具参数不暴露密钥字段，结果和日志也应脱敏。MCP 同样需要这种执行端设计。

已有 CLI 之后还要不要重写 MCP 业务逻辑？

通常可以复用：服务端校验协议参数，调用原命令，再把退出状态和业务结果转换为协议结果；只在命令接口不适合复用或服务化时再考虑重构。

对应教程

参考资料