一、个人智能体是什么

个人智能体(Personal Agent)和常见的聊天框最大的区别不是”更聪明”,而是”始终在场”。它通常具备四个特征:

• 跑在用户自己控制的硬件上
• 长期在线,不会随对话窗口关闭而消失
• 通过 Telegram、WhatsApp、Slack、iMessage 等已有的聊天工具与人交互
• 能在多次对话之间保留记忆

聊天框关掉就忘了你;个人智能体不会关掉。这是从”主动去问”到”它一直在”的转变,也是后续架构设计、安全风险与行业趋势的共同起点。

这一波浪潮的代表项目是OpenClaw(社区驱动、MIT 协议开源)和Hermes(出自 Nous Research),两者基于同一套底层架构,却走出了完全不同的产品路线。

二、七层架构:个人智能体的通用骨架

一个看起来”自主”的智能体,本质不是会自己醒来思考的大脑,而是输入 + 状态 + 一个循环。所谓自主性,是一种工程模式,而不是某种意识。拆开任意一个个人智能体(OpenClaw、Hermes 或其他衍生项目),都能看到同样的七层结构:

1. 网关(Gateway)
一个长期运行的进程,是真正”始终在线”的部分。它连接所有聊天平台,是唯一的事实来源——客户端只能向它询问,不能自己去翻文件。相当于整个系统的内核。

2. 循环(The Loop)
核心引擎。不管是用户发的一条消息,还是定时器自动触发的一次事件,走的都是同一套流程:

while True:
    event   = wait_for_input()        # 消息、心跳、webhook、定时任务
    context = load_state(event)       # 历史记录 + 数据库 + 记忆,组装成提示词
    reply   = model.call(context)     # 模型的一次"思考"

    while reply.tool_calls:           # 如果它要执行动作,执行后让它继续思考
        results = run_tools(reply.tool_calls)   # 命令行、文件、浏览器、网络
        context.append(results)
        reply = model.call(context)

    persist(event, reply)             # 持久化,避免重启后丢失状态
    if reply.text:
        respond(event.channel, reply.text)
    # 否则保持沉默——"什么都不做"也是一种合法输出

加载上下文、调用模型、按需使用工具、记录结果、必要时回复——这就是智能体的”思维”。

3. 记忆(Memory)
落盘的状态:一份持续记录的对话历史,加一个可检索的数据库,确保重启后不丢失上下文。相当于文件系统。

4. 技能(Skills)
可复用的操作流程,通常以 Markdown 文件形式存在(如”如何部署”“如何写周报”)。技能由人编写还是由智能体自己生成,是不同项目的关键分歧点。

5. 工具(Tools)
智能体的”手”:命令行、文件系统、可操作的浏览器、网络搜索,以及对接其他系统的连接器。这里是能力所在,也是安全风险所在。

6. 心跳(Heartbeat)
一个定时器按周期触发,往循环里塞入一个”假”事件,效果等同于用户发了条消息。智能体醒来、思考、判断是否需要行动。这是让它”显得活着”的全部机制——本质就是一个定时任务。

7. 模型(The Model)
真正的大语言模型,放在一个可替换的接口后面,云端或本地均可。智能体是骨架,模型是可以随时更换的发动机。

网关、循环、记忆、技能、工具、心跳、模型——这七层组合,基本能覆盖目前所有个人智能体的实现方式。

三、两种设计路线:编排广度 vs 记忆深度

OpenClaw:中心辐射式,押注广度

OpenClaw 采用中心化网关架构:一个中央守护进程作为交通枢纽,所有聊天平台、客户端、定时任务、其他智能体都是辐条。它的策略是”广覆盖”:接入十余种平台,提供技能市场 ClawHub 供人发布和安装技能,支持智能体之间互相调用,并提供托管版本。其重写版本直接命名为”Agent OS”——定位是控制平面,协调多个智能体、多个渠道与一个由人类编写的技能市场,扩张方式是横向铺开。

Hermes:闭环学习,押注深度

Hermes 的核心问题是:能否做出一个不需要人重新配置、只靠使用本身就会变得更好的智能体。其底层是一个闭环:解决问题 → 写下学到的东西 → 下次检索复用 → 持续优化。这个闭环靠两个机制实现:

• ‎自动生成技能:任务完成后,智能体自行判断该路径是否值得保存——只保留真正费功夫解决的问题(多步骤任务、需要从错误中恢复的情况、用户的纠正、非显而易见的技巧),写成结构化的技能文件,无需人工编写。

---
name: deploy-staging
triggers: ["deploy to staging"]
uses: 7
---
## 步骤
1. 构建 Web 应用。失败则读取错误信息,修复 import,重试一次。
2. 运行测试,全部通过才继续。
3. 部署到 staging,把链接发到 #eng 频道。

• ‎记忆有上限,强制筛选:常驻加载的记忆有硬性容量上限(几千字符量级),迫使系统保留真正重要的内容,其余历史按需检索而非全量加载。

Hermes 的扩张方式是向内深耕,目标是单个私有智能体随使用持续复利增长。

两条路线目前正在相互靠近——OpenClaw 在补记忆能力,Hermes 在补连接广度。

四、循环工程的局限:自主性不等于方向感

“循环工程”(Loop Engineering)是当下的热门做法:让一个智能体写代码、另一个预览、再有一个检查,循环执行写、测、修,直到全部通过。这种模式确实能提升正确性,但有一个明确的边界。

让代码没有 bug,是工程问题;决定什么值得做,是方向问题。后者不在循环里,而需要人来提供。让智能体完全无监督地反复迭代,它会趋向”收敛”——代码规整、正确,但缺乏创造性,因为它只能优化已给定的方向,无法发明新方向。

更进一步,提示词中的具体框架设定会显著影响输出质量。模型训练数据来自海量人类讨论,提示词的措辞决定了模型调用哪一种推理模式。例如把任务设定从”按已知细节排查问题”改为”假设一定存在问题,主动构建假设并验证”,在同样的信息输入下,可能得到完全不同的排查效率。这说明:自动化循环本身不会自动找到正确答案,没有方向的循环只是更快地走向错误答案。提示词工程并未因智能体的出现而过时,反而是其中杠杆最大的一环。

实践上的结论是:在自动化循环中保留一个”人工确认/调整方向”的节点,比追求完全无人值守的全自动化更可靠。

五、安全风险:致命三件套与防御设计

按设计,个人智能体天然处于高风险配置。安全研究中称之为”致命三件套”(lethal trifecta):同一个系统同时具备读取私有数据、连接互联网、自主执行动作三种能力。单独看每一项都没问题,三项叠加在同一进程中,一条错误指令就可能造成数据泄露或破坏性操作。

再加上模型本身难以可靠区分”应读取的数据”与”应执行的指令”,就构成了**提示词注入(Prompt Injection)**风险——一封邮件、一个网页里藏的一行文字,可能被当作指令执行。

两个项目在这个问题上选择了不同路径:

• ‎OpenClaw:早期版本默认权限较宽松,可在无确认的情况下执行命令行操作。项目快速增长、完全开放,也因此较早暴露出真实漏洞、技能市场中出现过被植入恶意内容的技能,以及大量实例未做访问限制即暴露在公网。
• ‎Hermes:从设计之初引入防御机制,包括默认拒绝访问、不可被任何模式绕过的硬性命令黑名单,以及用容器作为执行边界。

# 任何模式下都不可执行的命令示例
hardline_blocklist:
  - "rm -rf /"            # 清空整台机器
  - "curl * | sh"        # 把外部脚本直接灌入命令行执行
  - "dd * of=/dev/sd*"   # 覆写原始磁盘

需要指出的是,防御机制更完善的项目同样可能存在未被发现的漏洞,“没有被攻破”不等于”不存在风险”,这与项目被攻击测试的时间和规模有关。

基于此,可以总结出几条实践层面的安全准则:

• 部署在独立、受限的设备或容器上,不要直接放在主力工作机器上
• 为每个外部服务使用范围受限的访问令牌,而非主密钥
• 默认只读权限,按需逐步开放执行权限
• 将社区发布的技能视为不可信代码,审查后再使用
• 不将网关直接暴露在公网

六、架构视角:个人智能体即”意图层操作系统”

把七层结构对应到传统计算机体系,会发现这套架构本质上是操作系统的再实现:网关对应内核,技能对应可安装程序,心跳对应调度器,记忆对应文件系统,工具对应系统调用,模型对应可替换的处理器,聊天界面只是输入终端。区别在于,它管理的不是文件和进程,而是用自然语言表达的”意图”。

这也是为什么个人智能体被一些项目直接称为”Agent OS”——这不是营销概念,而是相对准确的技术定位。

行业层面,这类系统的扩散背后有一个更基础的原因:记忆和重复性事务处理本就是人类认知中效率最低的部分。把这部分卸载给系统,把认知资源留给判断和方向选择,是这类工具被广泛采用的核心驱动力,而非短期炒作。

当前尚未定论的两个问题是:最终更优的设计形态会是”记忆复利型”还是”协调编排型”(目前两者正在融合);以及能否在不削弱自主性的前提下,解决”读取、联网、执行”三种能力叠加带来的安全问题。后者更可能决定这类系统的长期可用性,而非模型能力本身。