@BharukaShraddha: 90% 的 AI 工程师将这些概念混为一谈，但它们并不相同。这正是许多 AI 智能体变得…

X AI KOLs Timeline 新闻
ai-agents concepts skills subagents mcp hooks engineering

摘要

一条 Twitter 线程澄清了 Skills（技能）、Subagents（子智能体）、MCP（模型上下文协议）和 Hooks（钩子）在 AI 智能体设计中的不同角色，指出混淆这些概念会导致系统效率低下且成本高昂。

90% 的 AI 工程师将这些概念混为一谈。 但它们并不相同。 而这正是许多 AI 智能体变得缓慢、昂贵且难以调试的原因。 这四个概念是： • Skills（技能） • Subagents（子智能体） • MCP（模型上下文协议） • Hooks（钩子） 每个解决的都是完全不同的问题。 以下是最简单的理解方式： **SKILLS** = 智能体所 **知道** 的 需要可复用的专业知识？ 一个编码标准。 一种文件格式。 一个工作流。 使用技能。 仅在需要时加载。 并非每个任务都值得永久占用上下文。 **SUBAGENTS** = 智能体 **思考** 的地方 需要深入研究？ 并行分析？ 杂乱的探索？ 使用子智能体。 为任务分配独立的工作空间。 保持主对话的整洁。 **MCP** = 智能体能够 **触及** 的内容 需要访问： • API • 数据库 • SaaS 工具 • 内部系统 使用 MCP。 如果智能体必须与外部交互，MCP 通常是答案。 **HOOKS** = 智能体必须 **遵守** 的规则 需要： • 验证 • 安全检查 • 格式化规则 • 日志记录 使用钩子。 不要指望模型记住规则。 强制执行。 思维模型： Skills → 知识 Subagents → 思考 MCP → 访问 Hooks → 规则 大多数人构建 AI 系统时这样思考： “MCP 能解决这个问题吗？” 更好的问题是： “这个问题真的需要 MCP 吗？” 大胆假设： 大量 MCP 服务器本应只是技能。 人们创建集成时，他们所需要的仅仅是可复用的知识。 结果呢？ 更高的延迟。 更多的身份验证难题。 更多的维护工作。 更好的 AI 系统并非通过添加更多组件来构建。 而是通过知道 **不** 该添加哪一个组件。 你在决定使用技能还是 MCP 时的规则是什么？
查看原文
查看缓存全文

缓存时间: 2026/06/08 15:26

90% 的 AI 工程师都在混用这四个概念。

但它们其实并不相同。

而这正是导致许多 AI 智能体变得缓慢、昂贵且难以调试的根本原因。

这四个概念是：

• 技能 (Skills) • 子智能体 (Subagents) • MCP • 钩子 (Hooks)

每一个解决的问题都完全不同。

下面是最简单的理解方式：

技能 (Skills) = 智能体所知道的内容

需要可复用的专业知识？

一个编码规范。 一种文件格式。 一个工作流程。

使用技能。

仅在需要时加载它。

并不是每个任务都值得占用永久上下文。

子智能体 (Subagents) = 智能体思考的场所

需要深度调研？ 并行分析？ 杂乱无章的探索？

使用子智能体。

给任务分配独立的运行空间。

保持主对话的整洁。

MCP = 智能体能够触及的内容

需要访问：

• API • 数据库 • SaaS 工具 • 内部系统

使用 MCP。

如果智能体必须与自身以外的东西交互，MCP 通常是答案。

钩子 (Hooks) = 智能体必须遵守的规则

需要：

• 验证 • 安全检查 • 格式规范 • 日志记录

使用钩子。

不要依赖模型去记住。

强制执行。

思维模型：

技能 → 知识

子智能体 → 思考

MCP → 访问

钩子 → 规则

大多数人构建 AI 系统时是这样想的：

“MCP 能解决吗？”

更好的问题是：

“这个问题真的需要 MCP 吗？”

一个激进的观点：

有很大一部分 MCP 服务器本应该是技能。

人们在需要复用知识的时候，却创建了集成。

结果呢？

更高的延迟。 更多的认证麻烦。 更多的维护工作。

更好的 AI 系统不是靠增加更多组件搭建出来的。

而是靠知道哪些组件不应该加进来的。

你在决定使用技能还是 MCP 时，有什么原则？

相似文章