如何构建生产级AI Agent：MCP、CLI和Skills，为任务选择合适工具

连接性并非单一问题

2024年我们构建了演示。2025年我们构建了编码Agent。2026年我们将把通用知识工作者投入生产，这一转变暴露了演示中隐藏的问题：将代理连接到真实世界并非一个能用单一解决方案解决的单一问题。

模型上下文协议（MCP）据报道已超过1.1亿月下载量，增长速度超过React，并且确实非常出色。但如果有人告诉你MCP、命令行或计算机使用是满足你所有连接需求的唯一答案，那他们就错了。最好的生产代理不会选边站。它们会同时使用整个连接栈：Skills、MCP和CLI，每个都用于其真正擅长的任务。

以下是判断给定任务属于哪个层级的方法，附带代码和一个可以应用于每个集成的决策框架。

三个层级，定义明确

理解这个堆栈最快的方式是每层一句话。MCP为模型提供正式的服务契约。CLI为模型提供直接的操作杠杆。Skills为模型提供可复用的标准操作规程，位于两者之上。 它们并非竞争者，而是不同层级。

MCP是通用适配器。 与其为每对代理-工具组合编写一次性的连接器，MCP允许服务发布一个标准化的契约，供多个代理消费。代理询问服务器有哪些工具，获取名称、描述和输入模式，并通过结构化协议调用它们。这正是你对于需要OAuth、细粒度权限和审计追踪的远程SaaS系统以及永远不应看到堆栈跟踪的非技术用户所需要的。它现在得到了所有主要实验室的支持，并隶属于一个中立基金会，已有数千个服务器可用。

CLI是直接的操作杠杆。 许多工具已经拥有经过实战测试的命令行界面，并且语言模型已经在数百万个git、docker和kubectl的示例上进行了训练。该模型已经知道如何驱动它们。CLI在本地运行，因此没有远程服务器超时的问题，Token成本要低得多，并且命令通过管道组合的方式如同Unix五十年来所做的那样。对于注重速度、成本和组合性的开发者工作流来说，这是正确的选择。

Skills是配方卡片。 一个Skill是一个markdown文件（SKILL.md），在后台静默存在，几乎不消耗任何资源，直到代理识别出匹配的任务。然后它加载完整的配方：使用哪个工具、哪些标志、如何处理错误以及“完成”是什么样的。Skills并不取代MCP或CLI。它们位于两者之上，使它们保持一致且可重复，将每一步路由到最适合的传输方式。

Skills的实际应用

Skill是你一次性编码工作流的地方，这样代理就不会即兴发挥。注意同一个配方如何将某些步骤路由到CLI，将另一步骤路由到MCP服务器。

---
name: deploy-release
description: 切分并发布带标签的版本。当要求发布、部署或标记版本时使用。
---

## 部署发布
1. 通过CLI运行测试：`npm test`。如果失败，停止并报告。
2. 通过CLI升级版本：`npm version {level}`（patch | minor | major）。
3. 推送标签：`git push --follow-tags`。
4. 通过Notion MCP服务器在Notion中创建发布说明（工具：create_page），标题为“版本 {version}”。
5. 当标签推送成功且Notion页面存在时，任务完成。

Skill是标准操作规程。CLI和MCP是执行工具。这种分离使得代理行为可重复，而不是每次运行都像是一场新的赌博。

同一能力，两种传输方式

以下是一目了然的选择。决定因素在于工具在哪里运行以及谁需要使用它。

## CLI：直接杠杆。工具在本地运行，模型已经知道它。
run("gh issue list --repo acme/api --state open")

## MCP：正式契约。工具是需要认证和模式的远程SaaS。
tools = mcp_client.list_tools()                       # 发现存在哪些工具
mcp_client.call("salesforce.create_lead", {"name": "Acme", "stage": "new"})

CLI版本更便宜、更快，但它之所以有效，是因为GitHub有本地CLI，并且运行者有凭证。MCP版本在Token和设置方面成本更高，但对于一个永远不会阅读终端的销售总监来说，这是唯一合理的选项，因为他们需要访问要求OAuth和权限范围的服务。

一个你真正可以使用的决策框架

大多数团队犯的错误是为整个系统选择一种传输方式。更好的实践是针对每个集成做出决定，使用四个问题：

1. 工具在哪里运行？ 本地且可脚本化指向CLI。远程SaaS指向MCP。
2. 用户是谁？ 开发者可以处理CLI输出。业务用户需要MCP结构化、友好的界面。
3. 认证是什么样的？ 如果需要OAuth、限定范围的权限和审计追踪，那是MCP的主场。本地凭证和shell是CLI的主场。
4. 这个工作流是否重复？ 如果是，将其封装到Skill中，这样步骤和质量标准就固定了，无论每一步使用哪种传输方式。

还有第五点，它悄无声息地超越了协议之争：工具界面的设计质量决定了你的代理工作得是否好，而不是你选择了哪种传输方式。一个描述糟糕的工具在MCP和CLI上都会失败。大多数团队选择一种传输方式后就停止了。不要停在那里。

安全考虑

每一层都打开了不同的漏洞，所以你的威胁模型必须跟踪架构。

• MCP转储模式并增加远程表面。 连接一个大型服务器在代理做任何有用的事情之前，可能会将数万个Token推入上下文，而远程服务器是攻击者可以触及的。将每个服务器限制为你所需的最小工具集，并将其OAuth权限视为生产凭据，而不是设置便利。
• CLI执行真实命令。 给代理一个shell意味着给它执行破坏性操作的能力。将其限制在允许的命令列表中，永远不要将不受信任的文本直接插入命令行，并要求对任何删除、部署或消费的操作进行人工批准。
• 单一开发者安全模型无法扩展。 在你的笔记本电脑上安全的shell在多租户、合规性高的部署中可能是危险的。生产环境需要沙箱、每租户隔离以及本地设置从未操心的日志记录。
• Skills可以编码不安全的指令，工具输出可能携带攻击。 Skill是模型会遵循的文本，所以要像审查代码一样审查它。并且将工具返回的任何内容，尤其是来自网络或邮件的，视为可能试图劫持下一步的不受信任输入。

结论

生产级代理不是通过押注获胜协议来构建的。它们是通过将每个任务匹配到适合的层来构建的：CLI用于本地、Token成本低、可组合的开发者工作；MCP用于远程、需要认证、面向用户的服务；而Skills则叠加在两者之上，将一次性的聪明运行转变为具有明确完成定义的可重复程序。

别再问哪个工具最好。开始问每个连接支持什么样的工作，让你的代理像优秀工程师使用整个工具箱一样使用整个堆栈。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～