1. 从餐厅后厨到AI架构:Agent、Skill与MCP的本质解析
最近半年,AI领域最火的概念莫过于"Agent"。但当我真正开始研究各大公司的AI产品时,发现几乎每个厂商都在用不同的术语描述相似的概念——Agent、Skill、MCP、工作流、多模型路由...这些名词堆在一起,反而让人更加困惑。
作为一个有十年架构经验的开发者,我决定用最直接的方式搞清楚这些概念——拆解市面上最成熟的四个AI产品(Claude Code、OpenClaw、飞书CLI和Figma AI)的架构。经过两周的深入分析,我终于理清了这些概念之间的关系,以及它们在实际产品中的应用方式。
1.1 基础概念的三明治模型
理解这三个概念最简单的方式,是用餐厅后厨的运作来类比:
- Agent(主厨):负责理解客户需求并做出决策。就像主厨需要判断"随便来点好吃的"到底该上什么菜,AI Agent需要解析用户模糊的意图并规划执行路径。
- Skill(菜谱):标准化的执行流程。就像"红烧肉:焯水→炒糖色→加料→炖40分钟"这样的标准操作流程,Skill将业务逻辑封装成可复用的模块。
- MCP(厨房设备):实际执行所需的工具和资源。就像烤箱、炒锅这些设备,MCP让AI能够连接和操作外部系统和数据。
这三者的关系构成了AI系统的核心架构:Agent决定"做什么",Skill决定"怎么做",MCP决定"用什么工具做"。
1.2 为什么传统Chatbot正在被淘汰
传统Chatbot与Agent的核心区别可以用一个表格清晰展示:
| 能力维度 | Chatbot | Agent |
|---|---|---|
| 工具调用 | ❌ 只能对话 | ✅ 能查数据库、操作文档、调用API |
| 多步执行 | ❌ 一问一答 | ✅ 自主规划步骤并按顺序执行 |
| 决策能力 | ❌ 你问什么答什么 | ✅ 自主判断该调用什么能力 |
举个例子:当你问ChatGPT"帮我查一下上个月德国市场的销量"时,它只能回答"抱歉我没有你的数据"。而一个配置完善的Agent会:
- 理解查询意图
- 自动调用销量数据库接口(MCP)
- 获取数据后按模板整理(Skill)
- 返回可直接使用的分析结果
这种从"能聊天"到"能干活"的转变,正是Skill和MCP带来的质变。
2. Claude Code深度拆解:一个成熟Agent产品的架构设计
作为日常使用最频繁的AI编程助手,Claude Code展现了当前最完整的Agent架构实现。通过逆向工程其行为模式,我发现它的系统设计远比表面看到的复杂。
2.1 指令分层系统:CLAUDE.md的三级管控
Claude Code最精妙的设计之一是它的指令分层系统。不同于简单的全局设置,它支持三级指令文件:
- 全局级(~/.claude/CLAUDE.md):适用于所有项目的通用规则
- 项目级(项目根目录/CLAUDE.md):当前项目特定规则
- 目录级(子目录/CLAUDE.md):模块级精细控制
这种分层设计遵循"越近优先级越高"的原则。例如,全局设置可能要求"所有代码注释用英文",但某个项目的CLAUDE.md可以覆盖为"本项目使用中文注释"。
架构启示:优秀的Agent系统需要支持规则的分层覆盖,既要保证全局一致性,又要允许场景化定制。
2.2 Skill与Prompt的本质区别
Claude Code中的Skill不是简单的Prompt模板,而是完整业务流程的封装。以代码审查Skill(/review)为例,它包含:
- 审查维度定义(安全、性能、可维护性)
- 通过/需修改/拒绝的判断标准
- 调用的测试工具和检查项
- 结构化报告的输出格式
与普通Prompt的关键差异:
| 特性 | Prompt | Skill |
|---|---|---|
| 本质 | 文字指令 | 业务流程 |
| 复杂度 | 单次对话 | 多步骤+工具调用 |
| 复用性 | 每次重输 | 封装后一键调用 |
| 输出稳定性 | 随机性强 | 按流程标准化 |
在实际使用中,我将常用的"文章改写"流程封装成Skill后,效率提升了3倍以上——从每次重复说明要求,变为直接调用标准化流程。
2.3 MCP:AI与真实世界的连接器
MCP(Model Context Protocol)是Anthropic推出的工具调用协议,其核心价值在于:
- 双向数据流:不仅能让AI读取数据,还能操作系统
- 安全沙箱:所有工具调用都在受控环境中执行
- 统一接口:不同工具采用相同的调用规范
通过MCP,我的工作流实现了:
- 自动从Notion提取需求文档
- 根据文档内容生成代码框架
- 将成品代码写回Notion指定页面
这种闭环操作彻底改变了AI只能"动口不动手"的局限。
2.4 Hooks:不可或缺的安全网
Claude Code的Hooks机制常被忽视,却极为重要。它允许在关键操作前后插入自动化检查:
bash复制# 示例:代码提交前自动检查
pre-commit:
- run: lint-check # 代码风格检查
- run: unit-test # 单元测试
- confirm: "确定要提交吗?" # 人工确认
这种设计解决了AI应用的致命问题——如何保证自动化操作的可靠性。我的实践表明,合理配置Hooks可以减少80%的意外错误。
2.5 多模型路由:成本与效果的平衡术
Claude Code支持在Opus(最强)、Sonnet(均衡)、Haiku(轻量)三个模型间动态切换。关键在于:
- 不是手动选择:系统根据任务复杂度自动路由
- 成本差异显著:Opus价格可能是Haiku的10倍
- 效果权衡:简单任务用轻量模型足矣
这种设计给我的启示是:AI产品应该按需分配计算资源,而非一味追求最强模型。在实际项目中,通过精细化的模型路由,我的API成本降低了65%,而用户体验几乎不受影响。
3. OpenClaw架构解析:轻量级Agent框架设计
与Claude Code这样的成熟产品不同,OpenClaw定位为一个可自部署的Agent框架。我在68元/年的阿里云VPS上成功部署了一套,接入了飞书和浏览器自动化能力。
3.1 统一消息网关设计
OpenClaw最亮眼的设计是它的消息入口抽象层。无论请求来自飞书、还是其他平台,都会被统一转换为标准格式:
code复制消息流转路径:
飞书群聊 → 消息网关 → 统一格式 → Agent处理 → 结果返回
↗
私聊
这种设计完美解决了企业场景的痛点——不同部门可能使用不同的沟通工具,但Agent能力只需开发一次。在我的实践中,同一套日报生成Skill可以同时服务飞书和上的用户。
3.2 Skill与MCP的协作模式
OpenClaw清晰区分了两种能力:
-
Skill:业务流程封装
- 示例:会议纪要生成、数据报表制作
- 特点:可复用、可组合
-
MCP:系统连接协议
- 示例:飞书API连接器、数据库驱动
- 特点:标准化、安全性
一个典型的工作流示例如下:
mermaid复制graph TD
A[用户请求"生成销售报表"] --> B(销售报表Skill)
B --> C{调用哪些MCP}
C --> D[CRM系统MCP]
C --> E[数据库MCP]
D --> F[获取客户数据]
E --> G[获取交易记录]
F --> H[生成报表]
G --> H
H --> I[返回结果]
3.3 与Claude Code的对比分析
从架构师角度看,这两个产品代表了两种不同的技术路线:
| 维度 | OpenClaw | Claude Code |
|---|---|---|
| 定位 | Agent框架 | 开箱即用产品 |
| 灵活性 | 极高 | 中等 |
| 部署复杂度 | 需要运维 | 一键安装 |
| 适用场景 | 深度定制 | 快速应用 |
在我的技术选型中,两者形成了完美互补:OpenClaw用于构建企业内部定制化Agent,Claude Code用于个人效率提升。
4. 飞书CLI的Agent-First设计哲学
飞书推出的lark-cli工具在GitHub上6天斩获5000星,其设计理念颠覆了传统CLI工具的思路。
4.1 工具设计的范式转变
lark-cli最革命性的特点是:它首先是为AI Agent设计的,其次才是为人设计的。安装时会自动检测系统中的AI工具(如Claude Code、Cursor等),并将19个预置Skill注入这些工具。
这意味着:
- 用户无需记忆命令语法
- AI Agent可以直接调用飞书能力
- 人机交互变得更加自然
例如,只需对Claude Code说"帮我查今天的会议",AI就会自动:
- 解析时间范围(今天)
- 调用飞书日历API(MCP)
- 格式化返回结果
4.2 Agent-Friendly的API设计要点
lark-cli的API设计充分考虑了AI调用的特点:
-
结构化输入输出:
json复制// 查询会议API响应示例 { "meetings": [ { "title": "产品评审会", "time": "14:00-15:00", "participants": ["张三", "李四"] } ] } -
Dry-run模式:
bash复制lark-cli send-message --dry-run --content "测试消息" # 返回执行预览而不实际发送 -
自动化权限管理:
- 安装时自动申请合理权限
- 每个Skill有独立权限沙箱
-
安全评分机制:
- 每个API调用都有风险评估
- 危险操作需要额外确认
4.3 对开发者的启示
通过分析lark-cli,我总结了现代工具开发的四个原则:
- 假设主要用户是AI:接口设计优先考虑Agent调用
- 结构化优于自然语言:明确的Schema比自由文本更可靠
- 支持试探性执行:Dry-run模式必不可少
- 权限精细化管控:按最小权限原则设计
在实际项目中应用这些原则后,我开发的内部工具AI适配成本降低了70%。
5. Figma AI Agent:从辅助到执行的跨越
Figma最新推出的AI Agents on Canvas功能,代表了AI集成的新高度——从提供建议到直接执行。
5.1 新旧模式对比
| 维度 | 旧模式 | 新模式 |
|---|---|---|
| 输出形式 | 建议图片 | 可编辑图层 |
| 设计系统感知 | 无 | 读取组件库 |
| 操作权限 | 只读 | 读写 |
这种转变的核心在于MCP协议的深度集成——AI不再生成静态图片,而是直接操作Figma的图层系统。
5.2 Skill质量决定输出质量
Figma AI的表现高度依赖Skill的定义质量。一个优秀的Design Skill应该包含:
markdown复制# 设计规范
## 色彩系统
- 主色: #3B82F6
- 辅助色: #EC4899, #10B981
## 间距规则
- 基础单位: 8px
- 卡片内边距: 16px
- 元素间距: 8px倍数
## 组件规范
- 按钮圆角: 4px
- 卡片阴影: 0 1px 3px rgba(0,0,0,0.1)
在实践中,定义完善的Skill可以使设计输出的一致性提升60%以上。
5.3 双向集成的价值
Figma AI展示了MCP的高级应用场景:
-
读取模式:
- 分析现有设计系统
- 提取品牌规范
-
写入模式:
- 创建符合规范的新设计
- 自动调整间距和布局
这种双向集成让AI从"设计助手"变成了"设计协作者",在我的工作流中节省了约40%的重复性操作时间。
6. 通用Agent架构模型
分析这四个产品后,我提炼出了一个通用的6层Agent架构模型:
6.1 架构分层详解
-
指令层:
- 全局规范
- 场景规则
- 单次指令
- 特点:分层覆盖,越近越优先
-
Agent层:
- 角色定义
- 能力边界
- 决策逻辑
- 特点:场景化 specialization
-
Skill层:
- 业务流程封装
- 标准化模块
- 可复用组件
- 特点:一次开发,多处调用
-
MCP层:
- 工具连接器
- 数据适配器
- 协议转换
- 特点:统一接口,安全管控
-
模型层:
- 多模型路由
- 负载均衡
- 成本优化
- 特点:合适而非最强
-
守护层:
- 自动化检查
- 质量评分
- 人工确认
- 特点:安全网设计
6.2 各产品侧重点对比
| 产品 | 突出层级 | 设计亮点 |
|---|---|---|
| Claude Code | 指令层+守护层 | 三级指令系统,自动化Hooks |
| OpenClaw | MCP层+模型层 | 统一消息网关,多模型支持 |
| 飞书CLI | Skill层+MCP层 | Agent-first API设计 |
| Figma AI | Skill层 | 设计系统深度集成 |
7. 实战:构建个人Agent工作流
基于这些研究,我设计了一套个人效率Agent系统,以下是关键实现步骤:
7.1 技术选型
mermaid复制graph LR
A[消息入口] --> B(飞书)
A --> C()
A --> D[Web]
B --> E[OpenClaw核心]
C --> E
D --> E
E --> F[技能库]
F --> G[会议纪要生成]
F --> H[日报自动编写]
F --> I[代码审查]
E --> J[MCP连接器]
J --> K[Notion]
J --> L[GitHub]
J --> M[Google日历]
7.2 核心Skill示例:自动会议纪要
python复制# meeting_summary_skill.py
def execute(meeting_id):
# 通过MCP获取会议录音
audio = mcp.feishu.get_meeting_audio(meeting_id)
# 语音转文本
transcript = mcp.speech_to_text(audio)
# 提取关键信息
summary = llm.generate(
prompt=f"请从以下会议记录中提取关键决策和待办事项:\n{transcript}",
template="meeting_summary"
)
# 通过MCP写入Notion
mcp.notion.create_page(
database_id=MEETING_DB,
properties={
"title": f"{date.today()} 会议纪要",
"summary": summary
}
)
return summary
7.3 性能优化技巧
-
模型路由策略:
- 简单任务使用轻量模型
- 复杂分析使用大模型
- 实时交互平衡延迟和成本
-
缓存设计:
python复制@cache(ttl=3600) def get_project_status(project_id): return mcp.jira.query_issues(f"project={project_id}") -
异步处理:
python复制async def handle_message(msg): if msg.type == "meeting_summary": asyncio.create_task(generate_summary(msg.id)) return "会议纪要生成中,稍后将发送到Notion"
8. 避坑指南与经验总结
在实施过程中,我积累了一些宝贵经验:
8.1 常见问题排查
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| Agent拒绝执行有效请求 | 权限配置过严 | 检查MCP权限范围 |
| 输出结果不一致 | Skill定义模糊 | 细化执行步骤和标准 |
| 工具调用失败 | MCP连接问题 | 验证API可用性和配额 |
| 响应速度慢 | 模型选择不当 | 调整路由策略 |
8.2 性能优化指标
- 工具调用成功率:应保持在99%以上
- 平均响应时间:简单任务<3s,复杂任务<30s
- 模型成本分布:大模型占比不超过20%
- Skill复用率:优秀系统应达到60%+
8.3 安全最佳实践
- 最小权限原则:每个Skill只授予必要权限
- 输入验证:所有外部输入必须经过清洗
- 操作确认:高风险操作必须二次确认
- 审计日志:完整记录所有决策过程
9. 未来演进方向
基于当前实践,我认为Agent技术将向以下方向发展:
- 自适应Skill组合:Agent能自主组合简单Skill解决复杂问题
- 跨Agent协作:多个Agent通过标准协议协同工作
- 自我优化:根据使用数据自动调整Skill和路由策略
- 可视化编排:低代码方式设计和调试工作流
这些趋势将共同推动AI从"工具"进化为"同事",彻底改变人机协作的方式。