工具与技能与MCP：AI智能体的三层结构
工具用于展现操作功能，技能用于编码工作流程，而MCP则负责标准化外部连接。这样就能建立清晰的思维模型，从而在设计智能体架构时避免各层次相互混淆。
了解人工智能智能体的构成要素
智能体领域的格局正在不断变化。
早期的讨论主要集中在提示词设计、基础模型以及检索流程上。而当前的设计则要求智能体能够调用API、驱动工作流、查询数据存储、操作代码库，并与SaaS服务进行交互。
这些设计中主要有三个分类标签：
工具。技能。MCP。
相关的标签对应不同的功能职责。
清晰的边界使得架构更易于设计与讨论。
简单的思维模型
在深入细节之前，先通过一个简明的对比来了解：
| Concept | Primary purpose | Simple question |
| ---------- | ------------------------------------------------ | ----------------------------------------- |
| **Tools** | Give the agent capabilities/access | *What can the agent access or do?* |
| **Skills** | Give the agent instructions/workflows | *How should the agent perform a task?* |
| **MCP** | Standardize connections to external capabilities | *How can the agent connect to a service?* |
或者更简洁地表达为：
工具用于实现操作，技能决定执行策略，MCP则负责连接外部系统。
本文的其余部分将逐一解析这些层次结构。
- 什么是工具？
工具是智能体可以调用来修改或读取内容的操作界面。仅靠文本生成是不够的；当任务需要产生某种副作用时，模型就会选择相应的工具。
想象一个具备以下操作功能的编程助手：
readFile()
writeFile()
runTests()
searchCode()
runCommand()
模型可能会得出这样的结论：
我需要检查这个文件。
然后它会调用：
readFile("lib/features/login/login.dart")
该工具运行后将结果返回给模型。
工具可以连接内部系统
- 私有HTTP服务
- 数据存储系统
- 构建与发布流程
- 如Jira之类的工单管理系统
- 源代码控制服务器
- 可观测性工具集
- 部署与发布平台
- 知识库
示例：
getEmployeeDetails()
createJiraTicket()
triggerBuild()
checkDeploymentStatus()
queryCustomer()
关键所在
自研工具通常意味着由你负责集成工作。
你需要承担以下责任：
- 实现
- 身份验证
- 权限控制
- 安全性保障
- 错误处理
- 监控
- 维护
- 版本管理
这些工具功能强大，但也会带来持续的工程工作负担。
2. 什么是技能？
技能解决的是不同的问题。
技能指的是指导：它向操作人员展示具体的流程或工作步骤。
应将其视为可重复使用的操作手册，而非原始API。
假设某个技能的名称为：
releaseFlutterApp
它可能会包含如下步骤：
1. Check the current version.
2. Verify the changelog.
3. Run unit tests.
4. Run static analysis.
5. Build the release artifact.
6. Upload to the testing environment.
7. Verify the deployment.
8. Generate the release summary.
技能并不需要提供原始能力，它只是告诉智能体如何将现有的能力组合起来以实现目标。这种区分非常重要。
换言之：工具会说明可执行的操作，而技能则明确完成某项任务的最佳顺序。
3. 技能并非集成组件
很多混淆都源于此。
假设某个智能体已经拥有：
runCommand()
readFile()
writeFile()
searchCode()
这些条目都属于能力范畴。
现在再为其添加一个技能：
Flutter Release Workflow
该技能可能会指导智能体去：
read project configuration
↓
run tests
↓
run analyzer
↓
build application
↓
verify artifact
↓
prepare release
技能蕴含着任务协调的技巧，它们实际上就是操作指南的编码形式。
简而言之：
工具 = 可执行的内容
技能 = 执行顺序的规划
4. 什么是MCP？
第三层就是MCP（模型上下文协议）。
它规范了人工智能应用如何接入外部系统及能力服务器。
无需为每对产品单独开发适配器，MCP提供了一种通用协议来向客户端提供各种能力。
其简化后的结构如下：
AI Application
│
│ MCP
▼
MCP Server
/ | \
/ | \
▼ ▼ ▼
GitHub DB Jira
人工智能应用与MCP服务器通信，该服务器再从外部服务获取所需能力。
MCP服务器可能会暴露与以下内容相关的接口：
GitHub
PostgreSQL
Slack
Jira
Google Drive
Internal APIs
具体的接口范围取决于服务器本身。
- MCP的重要性
在没有通用协议的情况下，各团队往往需要为每款人工智能应用和每个SaaS接口单独开发适配器。
这种做法会导致：
AI Agent
│
├── Custom GitHub integration
├── Custom Jira integration
├── Custom Slack integration
├── Custom Database integration
└── Custom Internal API integration
服务越多，所需的定制化适配器就越多。
统一的协议则能提供标准的通信模式。
从概念上讲：
AI Client
│
MCP
│
┌─────────┴─────────┐
│ │
MCP Server MCP Server
│ │
GitHub Database
人工智能客户端与服务实现部分可以保持更为清晰的分离。
6. 工具、技能与MCP
这种并列对比在设计评审中依然很有用：
| | Tools | Skills | MCP |
| ------------------ | -------------------- | ------------------------ | ---------------------------------------- |
| Main purpose | Provide capabilities | Provide procedures | Standardize external connections |
| Focus | **Action** | **Instructions** | **Integration protocol** |
| Answers | "What can I do?" | "How should I do it?" | "How do I connect?" |
| Example | `run_tests()` | Flutter release workflow | GitHub MCP server |
| Usually created by | Developers | Developers/teams | Service/integration providers |
| Maintenance | You may own it | You own the instructions | Often handled by the MCP server/provider |
实际系统中的界限往往较为模糊，但这种思维模型在构建智能体时仍能提供帮助。
7. 一个实际案例：基于AI的Flutter开发
可以利用Flutter团队助手来构建该模型。
用户可能提出的需求是：
“为下一次质量检测版本准备应用程序。”
该智能体可能会提供多种工具：
read_file()
search_code()
run_flutter_test()
run_flutter_analyze()
build_android()
upload_to_firebase()
接着需要定义一个技能：
Flutter QA Release
该技能可以给出相应指令：
1. Check the current branch.
2. Read pubspec.yaml.
3. Determine the current version.
4. Run flutter analyze.
5. Run tests.
6. Build the QA APK.
7. Upload the APK.
8. Verify the upload.
9. Generate a release summary.
之后，MCP连接便可接入Git存储、工单系统、数据存储库，或是团队发布的任何MCP服务器。
最终形成的结构可能如下：
AI Agent
│
┌────────────┼────────────┐
│ │ │
Skills Tools MCP
│ │ │
▼ ▼ ▼
QA Release Flutter CLI External
Workflow Build/Test Services
这样的智能体就不再仅仅是问答机器人了。
它能够解析目标、遵循操作手册、使用本地工具以及连接外部系统。
正是这样的技术架构让智能代理驱动的产品开发真正落地。
8. 记住二者区别的另一种方法
想象一下为新工程师进行入职培训的场景。
工具是他们的设备
Laptop
Terminal
Git
Database
CI/CD
APIs
设备用于执行各种操作。
技能是他们的知识
How to release an app
How to debug a production issue
How to investigate a crash
How to review Flutter code
How to troubleshoot CI/CD
知识能够解释如何完成工作。
MCP是标准化的连接层
它是人工智能应用与提供MCP功能的外部系统之间保持一致的通信通道。
9. 为何这种区分对开发者很重要
将这三层混为一谈的开发者会无意中制造出复杂性。
更简洁的处理流程：
第一步——确定功能需求
提出问题：
“智能体需要具备哪些能力？”
这个问题的答案就是候选的工具。
步骤2 — 确定工作流程
请思考：
“智能体应如何完成这项任务？”
这个问题的答案就是候选的技能。
步骤3 — 识别外部系统
请思考：
“这是否需要访问外部服务？”
如果是，那么基于MCP的集成可能是个合适方案。
10. 更宏观的视角
常见的趋势是从：
Prompt
↓
LLM
↓
Response
转向更类似以下的布局：
┌───────────────┐
│ AI Agent │
└───────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
Skills Tools MCP
│ │ │
▼ ▼ ▼
Workflows Actions External
Services
总体而言，这些变化促使系统从生成文本转向执行结构化任务。
对于工程类组织而言，这才是有意义的变化。
最终结论
可以这样记住这三者：工具用于触发操作，技能负责定义操作流程，而MCP则规范外部系统如何接入。
它们彼此不能替代。
一个稳健的设计通常会将三者结合使用：技能描述操作流程，工具执行具体步骤，MCP则为第三方系统提供统一的连接桥梁。
随着产品不再局限于纯聊天功能，开始承担智能体工程任务，这些概念的价值也会不断提升。