最近 🦞 的热度明显下来了，Hermes 也过了最热的那几天。
经过这段爆火，我一直在思考复盘一个更底层的问题：个人 Agent 系统如果要长期工作，架构应该怎么设计。
热度最高的时候，大家问的大多是：怎么安装、怎么接入、哪个 SKILL 或是模型更强。
但连续用两个月以后，我发现更重要的问题不是「哪个 Agent 更聪明」，而是它能不能被养成一个长期工作的系统。
跑起来是一回事。养起来是另一回事。
解决安装、模型、入口、第一条消息很容易。但是接下来的 memory 怎么治理，skills 怎么维护，cron 怎么管理，sub-agent 输出怎么验证，工具权限怎么收，失败后人怎么接管。
当龙虾🦞和 Hermes 的后台主要接的都是 GPT-5.5 之后，差异就不能简单归因于"模型更聪明"。
真正拉开差距的，是模型外面的控制面：状态怎么管理，能力怎么路由，权限怎么收，失败怎么验证。
更好的 Agentic AI 架构，不只是让 Agent 会调用工具，而是让它知道：什么时候该用工具，什么时候该找流程，什么时候该验证环境，什么时候该停下来问人。
第一层：tool selection 不是工具列表问题
这两个月最明显的差别，是 Hermes 对 tool 和 skill 的选择更主动，也更稳定。
这里不是说模型本身更聪明，而是系统把「先找流程，再用工具」做得更明确。
比如写对外文章，它不是直接开写，而是先找内容生产 workflow，加载 writing style，再跑 content-lint，先约束账号、平台、风格和发布门槛。
改线上项目，它会先走维护 SOP：看 git status 和 relevant diff，改完跑 syntax check、diff check，再做线上验证。
一个很简单但是典型的例子，是我遇到的 Resend 客服邮件正文转发为空。
表面看，这是「邮箱里有没有收到正文」的问题。
如果 Agent 只会找 Gmail 工具，它大概率会卡在第一层：读邮箱、查转发、看收件箱。
但真正的问题不在 Gmail，而在 inbound webhook。
Resend 的 email.received payload 里主要是 metadata 和 email_id，完整正文需要再通过 receiving API 拉取。
所以排查路径必须拆层：
- Gmail / Workspace 是收信与发送层
- Resend dashboard 是 inbound / outbound 事件层
- webhook payload 是系统接口层
- SDK version 是运行时能力层
- smoke test 和 live URL 是部署验证层
这件事说明，tool selection 背后真正重要的是 capability routing。
任务进来后，Agent 要先判断这是什么类型的问题：邮箱读取、webhook 架构、credential state、SDK 版本，还是线上部署。
这里的 routing 不只是选 tool，也包括选 skill。
Skill description 本质上不是说明书，而是 routing trigger。
它决定 Agent 什么时候加载这套能力。
写得太宽，会误触。写得太窄，会漏触。和别的 skill 边界不清，会互相污染。
所以 skill 多不一定更强。每个 skill 都是一笔 context tax：写得越松，后面所有任务都在替它付费。
有选择机制，tool 和 skill 才能变成可复用能力。没有选择机制，能力越多，系统越乱。
一次任务做完只是自动化。下一次同类任务自动少踩一个坑，才开始有复利。
第二层：OpenClaw 解决的是入口和真实工作流
OpenClaw 当时最有价值的地方，是把 Agent 放进真实工作流。
个人 Agent 如果只存在于网页聊天框里，很难成为工作系统。真实任务通常来自 Telegram 消息、浏览器链接、webhook、本地脚本报错、定时任务，而不是用户主动打开一个 AI 页面。
OpenClaw 抓住的是 interface 和 routing 这两层：
- Agent 怎么被消息触发
- 怎么调用本地脚本
- 怎么接外部系统
- 怎么把结果回到用户正在看的地方
这里要说清楚：这不是说 OpenClaw 没有 memory。
恰恰相反，我之前在 OpenClaw 下已经搭了大量记忆架构。
比如三层记忆：
- L1：核心 memory，每次会话都加载
- L2：每日日志，只加载最近窗口
- L3：历史归档，通过语义搜索按需召回
还有自动过期和回收机制：P0 永不过期，P1 / P2 按 90 天、30 天归档，避免长期 memory 变成垃圾堆。
所以更准确的说法不是"OpenClaw 管入口，Hermes 才有记忆"。
而是 OpenClaw 让我先把 Agent 接进真实工作流，并围绕它手工搭出 memory / automation / gateway 体系。
Agent 必须先出现在任务发生的地方。否则后面能力再强，用户仍然要复制上下文、切窗口、手动执行下一步。那不是工作流，只是旁边开着的 assistant tab。
第三层：Hermes 把长期能力做得更细
迁到 Hermes 后，问题换了一层。
不是 OpenClaw 没有 memory，也不是 Hermes 换了一个更聪明的模型。
在我看来，Hermes 更明显的改进有两点：自主记忆更新，以及更细的 skill 能力。
它把 Agent 接活以后怎么保持可维护这件事，拆成了更明确的模块：skills、memory、session continuity、cron jobs、toolsets、provider abstraction、observability。
memory 不再只是我在系统外围搭的一套分层文件，而是 Agent 可以在任务中主动判断：哪些事实值得保存，哪些旧记忆需要替换，哪些临时进度不该进长期记忆。
skills 也不只是"有一份 SOP"，而是变成更细的 capability package。
其中 skills 最关键。我现在更倾向于把 skill 理解成 context architecture，而不是 prompt 模板。
成熟的 skill 也不只是一个 SKILL.md：
SKILL.md是入口，负责触发条件和核心判断scripts/放确定性逻辑，避免 Agent 每次重造轮子references/放重文档，只在需要时加载assets/放模板、schema、输出格式config放首次配置和环境差异
这就是 progressive loading：不是把所有上下文一次塞进模型，而是按任务需要一层层展开。
好 skill 也不是把流程写满。模型本来就知道的部分要删掉，只留下它容易错、必须稳定，或者体现个人判断的部分。
没有 skills，Agent 每次都靠上下文临场发挥。同一个问题换个 session，可能又重新踩一遍。
memory 也不能简单理解成「什么都记住」。记忆如果只是存东西，它只是文件柜。真正有用的 Agent memory，应该像神经系统：知道什么相关、什么变了、什么时候该提醒人。
长期 memory 只适合放稳定事实，比如用户偏好、账号规则、系统环境、项目约定。流程应该进 skill。临时进度应该留在 session。
如果边界不清，memory 会变成垃圾堆，而且会污染后续任务。
cron 也是类似问题。普通 cron 是到点跑命令；agent-native cron 更像到点启动一个带任务说明、工具限制、上下文来源和交付目标的小 Agent。
长期任务如果没有日志、没有失败处理、没有上下文边界，自动化只是稳定地重复错误。
Hermes 给我的启发是：Agent 接入工作流之后，还需要一套机制，把能力变成可复用、可限制、可观察、可替换的系统组件。
这也是为什么我最近看到 Anthropic 的 Managed Agents，会很有共鸣。
它表面上是在云端托管 Agent，省掉 sandbox、tool execution、state management、schedule 这些基础设施。
但更重要的是，它把 Agent 拆成了几个更稳定的接口：brain、hands、session。
brain 负责推理和调用工具，hands 负责执行，session 负责记录发生过什么。哪一层失败，都不应该把整个任务状态一起带走。
这和个人 Agent 的方向其实是一致的。
一个真正能长期用的个人 Agent，不应该是"一个模型 + 一堆工具"。它应该有清楚的 session，有可维护的 memory，有按任务收窄的 toolsets，有能被复用的 skills，有定时触发，有失败记录，也有权限边界。
所以我现在更愿意把个人 Agent 看成一个 managed runtime，而不是一个更聪明的聊天窗口。
第四层：迁移暴露的是隐性耦合
迁移最有价值的地方，是它把以前混在一起的问题拆开了。
一个功能能跑，不代表架构清楚。迁移后必须重新判断：这是入口问题、工具问题、credential 问题、memory 问题、skill 问题、cron 问题，还是权限和可观察性问题。
Google Workspace 是典型例子。memory 里可以写「已经配置过」，但真实创建 Google Doc 时 token 可能已经 expired or revoked。
这不是写作问题，也不是模型问题，而是 runtime state 和 long-term memory 之间不一致。
长期 Agent 不能只相信 memory，执行前必须验证当前环境。
skills 也会腐烂。路径会变，工具参数会变，账号规则会变。旧 skill 如果不更新，就会从经验复用变成事故复用。
维护 skill 也不是越写越长。真正值钱的是 gotchas。Agent 在哪里翻过车，就把那个坑写回去。
但改 description 要非常谨慎。因为 description 决定 routing，一改可能影响其它 skill。
这也是为什么成熟系统需要 eval：它要测 skill 该加载时有没有加载，不该加载时有没有误触，相邻任务有没有混淆，换模型后行为有没有漂移。
sub-agent 也是类似。能 spawn 多个 agent 不难，难的是验证输出。
子 agent 可能说任务完成了，但文件不存在、API 没跑通、路径用户访问不到。没有主 agent 的验证、日志和 guard，多 agent 只是把错误并行化。
这些不是 demo 里最显眼的部分，但决定系统能不能长期用。
个人 Agent 的七层 runtime
我现在会把个人 Agent 拆成一个 runtime 看：
它不是一条简单的聊天链路，而是一组工程层叠在一起：
- interface 不是入口列表，而是任务从哪里进来。Telegram、CLI、Web、IDE、email、browser 都属于这一层。
- routing 不是把消息转给模型，而是判断它应该进入哪个 session、profile、topic、skill 或 agent。
- tool execution 不是"能调用多少工具"，而是当前任务只给它哪些 hands。读文件、写文件、发邮件、发帖、删文件、改配置，不应该是同一个风险级别。
- capability 不是 prompt，而是 skills / workflows / runbooks：重复任务应该写成可维护流程，并配好 routing trigger、gotchas 和 eval。
- memory 不是什么都记住，而是保存稳定事实，不保存临时过程；保存偏好和约定，不保存一堆过期状态。
- task lifecycle 也不是普通 cron。cron、background process、watcher、event trigger、sub-agent 都要有创建、暂停、更新、追踪、失败恢复。
- observability / control 是最后一层：人要能知道 Agent 做了什么、用了什么上下文、哪里失败、什么时候能接管。
不是 chatbot，是 runtime。
用这套 runtime 看，OpenClaw 更强的是把前半段接进真实工作流：interface、routing、tool execution，以及围绕真实任务外接 automation。
Hermes 更强的是把后半段做得更细：自主 memory update、skills、task lifecycle、observability、provider abstraction。
这不是排座次，而是说明一个长期可用的 Agent 系统，前后两端都要有。
前端要进入真实工作流。后端要管理长期能力。中间要有权限、验证、日志和失败恢复。
Agent OS 不是概念包装，而是工程约束
我现在更愿意把个人 Agent OS 理解成一组工程约束。
它不需要真的像 macOS 或 Linux，但它必须处理类似问题：入口、权限、进程、调度、日志、配置、错误恢复、用户接管。
几个判断标准会变得很实际：
- capability 能不能模块化
- skill routing 会不会误触、漏触
- memory、skill、session 边界清不清楚
- 长期任务有没有 lifecycle
- 工具权限能不能收窄
- 模型和 provider 能不能替换
- 失败后能不能追溯
- 人能不能随时接管
这些听起来不如 demo 吸引人，但它们决定 Agent 能不能从「能跑」变成「能用」。
以前我看 Agent 项目，会先看它能调用哪些工具。现在我会先看它怎么管理复杂性。
OpenClaw 给我的启发是：Agent 必须进入真实工作流，否则只是聊天窗口。我在 OpenClaw 上已经搭过三层记忆和记忆回收，所以这不是"有没有 memory"的差别。
Hermes 给我的启发是：memory update 和 skill routing 如果变成 Agent 的内建动作，长期系统会更容易维护。
这两件事合在一起，才是我这段时间对更好 Agentic AI 架构的理解。
不是更大的模型。不是更多的工具。也不是更热的项目。
而是一套能把入口、工具、记忆、流程、权限、调度、失败处理放在一起管理的系统。