Agent 与 Skill 设计范式的本质区别：记忆是分界线

在 AI Agent 概念满天飞的时代，Skill 和 Agent 之间的边界反而变得越来越模糊——以至于很多产品在做设计决策时，其实是在凭直觉选择，而不是靠原则。最近在一个技术群里和几位朋友深入聊了这个话题，过程中我的初始判断被推翻了一次，最终才形成一个我自己更信服的框架。这篇文章是我对这个问题的完整思考。

01 行业主流怎么定义 Skill 和 Tool

在讨论 Agent 之前，先看看行业里已经形成的共识。主流 AI 厂商（Anthropic、OpenAI、Google）对 Skill/Tool 的定义其实已经悄悄收敛了：

Tool = 可执行函数，有输入输出，在世界里产生副作用。是 Agent 的手。

Skill = 封装的专业知识，影响 Agent 怎么思考问题。不直接执行代码，提供 context、指令、领域知识、行为模式。是 Agent 的训练。

Arcade.dev 的这个框架是我觉得最清晰的——它把 Tool 和 Skill 的差异落实到了 Intelligence 应该放在哪里这个问题上。

02 我之前框架的问题

一开始我是这样想的：Skill 适用于"单一、明确、有边界的任务"，Agent 适用于"目标导向、流程不确定、需要判断和纠错的复杂任务"。

这个框架对不对呢？能跑，但太粗糙了。它的核心问题是：用"复杂度"和"是否需要判断"来区分 Agent 和 Skill。这个标准站不住足，因为 Skill 内部同样可以写复杂的判断逻辑。

Skill 不仅仅是"简单能力"的打包。一个 Skill 可以很复杂，内部可以有分支、有多步逻辑、有复杂的判断策略——但对调用方来说，它仍然是一个原子能力包：我调你，你给我结果，不管你内部怎么实现的。所以复杂度不是分界线。

03 真正的分界线：记忆的持有者

在讨论过程中，一位朋友提出了一个我最初忽略、后来被证明是关键的维度：Agent 与 Skill 的本质差别之一，是记忆能力。

Skill 的设计默认是无状态的。每次调用是独立的——传入参数，产出结果，结束。不保留"上一次"的信息。同一个 Skill 连续调用两次，第二次不记得第一次做了什么。

如果 Skill 内部偷偷维护了状态，它就变得难以预测、难以测试、难以在不同 Agent 之间共享。Skill 的价值在于可移植和可组合。

Agent 天然是有状态的。它的执行不是孤立的一次调用，而是一个会话。前面说了什么、做了什么、用户纠正了什么——这些构成 Agent 的"工作记忆"，影响它后续的判断。

即使 Agent 的记忆也是"运行时提供"的（context window 或外部 memory store），Agent 仍然负责管理和使用这份状态。Skill 完全不参与这个过程。

04 ClawHub 的印证

ClawHub 上有大量独立的记忆类 Skill：elite-longterm-memory、agent-memory、cognitive-state-tracker 等等。这说明市场已经验证了一件事：记忆是可以被 Skill 封装的能力。但这并不意味着 Skill 本身拥有记忆。

一个 memory-management-skill 可以负责压缩记忆内容、负责检索、负责写入——但它自己每次调用都是访问外部状态。它不持有任何持久信息。这就像是：Skill 是"操作文件的逻辑"，Agent 是"持有文件的那个人"。

05 Hermes Agent vs Claude 的对照

把这个问题放到具体系统里看会更清晰。Hermes Agent（Nous Research，2026 年 2 月开源）实现了三层内存架构：短时上下文（context window）、持久化对话（SQLite + FTS5 全文本搜索）、程序性记忆（MEMORY.md / USER.md）。

Hermes 的设计理念是：记忆是基础设施，Agent 必须适应它。字符上限硬性约束（MEMORY 2200 chars，USER 1375 chars），强迫 Agent 主动整理记忆内容。Claude 的记忆方案则更接近 Skill 化的思路：memory tool 让 Agent 自己调用进行跨对话的存储和检索。

两条路都能跑：Hermes 偏强制，适合需要长期记忆、多人共用、注重审计的场景；Claude 偏灵活，适合愿意自己管理记忆、追求简洁的场景。但无论哪条路，记忆的持有者始终是 Agent——而不是 Skill。

06 一个更清晰的设计原则

经过这轮讨论，我认为区分 Agent 和 Skill 的核心维度是：谁持有状态，谁就能在 session 之间保持连续性。Agent = 状态持有者 + 能力执行者（可以加载 Skill）。Skill = 能力的静态描述包（无状态，或状态由外部注入）。

这个原则带来的设计推论是：当你希望系统能跨 session 保持连贯性 → 需要 Agent。当你希望能力被复用、迁移、组合 → 需要 Skill。当你需要一个能记住上下文、又能调用多种能力的工作单元 → Agent + 按需加载的 Skill。

07 写在最后

这篇文章起源于一个看似简单的问题："旅行规划该用 Agent 还是 Skill？"

答案当然是"看场景"——但这个答案太廉价了。真正的问题是什么情况下必须用 Agent，什么情况下 Skill 就够了。

我的最终判断是：记忆是分界线，但不是唯一的分界线。Agent 的本质是"持续运转的状态体"，Skill 的本质是"即插即用的能力包"。在做一个产品设计时，先问自己一个问题：这个模块需要跨 session 保持状态吗？如果需要，它本质上是一个 Agent 设计；如果不需要，Skill 可能就够了。

这不是一个非此即彼的选择——而是一个关于状态应该放在哪一层的设计问题。