Personal Agent：from Charon to OpenClaw

在 2025 年下半年的时候我开始做一个“数字分身” 的实验，我给它取名 Charon（卡戎）。它不是一个更会聊天的机器人，而是一个能在长期尺度上替我 记忆管理、上下文装配、工作流执行 的基于本地文件系统的智能体。

在我和 ChatGPT 的早期讨论里，Charon 的落地路径其实非常明确：

• 维护一个本地项目文件夹，把它当作长期记忆与知识资产的底座
• 让 Claude Code / Codex 这样的 coding agent 进入这个文件夹工作
• 目录结构围绕三件事组织：kb（读过的世界）/ skills（会做事的方式）/ memory（可训练的高信噪比自我）
• 用“inbox → review_queue → eval → merge”的流程，约束写入与演进
• 面对上下文限制，采用按需加载（渐进式披露），融合使用上下文卸载的五种机制（卸载、压缩、检索、隔离、缓存）

后来我部署使用了 Clawdbot（现 OpenClaw）：它在 skill、记忆机制、本地文件系统约束、agent loop 这些关键点上，几乎把我当初的设想以一种更工程化的方式验证了，除了gateway之外。它让我确认：这套思路不是空想，它可以被做成真实可运行的工程系统。

1. Charon 是什么：先把“个人系统”当作一个本地工程

我对 Charon 的定义（至少现阶段）更接近：

• 持久的工作伙伴：它要记得我在做什么、为什么这么做、下一步是什么。
• 以“项目文件夹”为中心：对话只是输入，产出必须进入文件系统，形成可审计、可复用资产。
• 能跑工作流：例如“采集 → 生成 prompts → 收集回答 → 分析 → 产出内容/修复建议”，要能闭环。

换句话说，我要的是一个“长期可迭代的工作系统”，不是一个“临时问答工具”。Charon 的一个关键洞见是：先别谈模型态，先把文件系统结构与写入规则定下来。在早期讨论里，我认为 Charon 文件夹最重要的就是三块：

• kb/：数据量最大，承载我读过的知识（AI/行业/个人方法论都可以用 collection 扩展）
• skills/：把高频 workflow agent 沉淀成可复用 skill（研究/学习/写作/代码审计…）
• memory/：高信噪比、结构一致、可训练的“我是谁”（写入需要 gate）

与之匹配的是一个非常“工程”的写入流程：

• inbox/：所有原始输入先落这里
• review_queue/：代理整理后的候选变更先放这里，等我确认
• eval/：用黄金样例做回归，防风格/目标漂移

以及一条必须长期坚持的纪律：随着系统变大，每次对话按需加载（渐进式披露），优先用索引与摘要装配上下文。

为了让这个愿景在工程上可执行，我的设想是把 Charon 设想成一个“可被 coding agent 直接进入工作的 repo”，大概的框架是这样（核心是 kb/skills/memory 三块，外加写入管道）：

Charon/
  AGENTS.md              # 给 coding agent 的总指令（Single Source of Truth）
  README.md
  inbox/                 # 原始输入先落地（链接/随手想法/转写/截图…）
  review_queue/          # 代理整理后的候选变更，等待我确认
  eval/                  # 回归测试/风格锚点/防漂移

  kb/                    # 读过的世界（体量最大）
    index.md
    templates/
    cards/

  skills/                # 会做事的方式（workflow agents 的沉淀载体）
    <skill_name>/
      skill.md
      examples/
      eval/

  memory/                # 可训练的“我”（高信噪比、结构一致、可审计）
    index.md
    identity/
    episodic/
    semantic/
    procedural/

  context/               # 上下文装配策略（按需加载/压缩/展开协议）
  docs/
  secrets/               # 明确禁止被代理默认 ingest 的敏感区

当时我并不确定这套结构是否“正确”，但我确定它解决的是同一个核心：把“记忆管理”从模型能力，变成可被工程约束与演进的文件资产。

2. OpenClaw 的 “工程化验证”

OpenClaw 有很多组件，当把它当作“个人系统的工程实现”去看时，最关键的是：

2.1 记忆不是“模型记住了”，而是“文件写下来了”

OpenClaw 的默认工作方式很像一个严谨的自我管理习惯：

• 每天的日志：memory/YYYY-MM-DD.md（原始流水账，记录发生了什么）
• 长期记忆：MEMORY.md（提炼后的稳定事实与重要上下文）

这件事看起来朴素，但它解决了个人系统里最难的一点：可持续性。

如果你把“记忆”寄托在模型上下文里，你会得到一个“当场很聪明、隔天全失忆”的伙伴；而把记忆外置到文件，你得到的是一个可以长期维护、可搜索、可版本化的知识资产。

更重要的是：这其实不是“记不记得”的问题，而是**上下文工程（context engineering）**的问题——你必须能在每次交互时，把最小且足够的身份/目标/证据装配进上下文里，而不是把“全部人生”一次性塞进去。

2.2 本地文件系统就是你的“事实数据库”

我越来越相信：个人系统最好的数据库不是某个 SaaS，而是你自己的硬盘。从 Manus、Claude Code、LangChain 等的最佳实践中已经反复印证了这一点。

• 项目文件夹里存的 markdown、json、脚本、报告，本质上就是可审计的事实
• 任何“自动化结论”，都应该能追溯到输入文件/证据

OpenClaw 的工作目录（workspace）和明确的读写边界，让“AI 产出”不再是漂浮的聊天内容，而是可进入工程流水线的资产。

2.3 Skill：把一次性的对话能力变成可复用模块

如果说 prompt 是“临时语言”，skill 就像“可复用工具”。比如我前段时间做 GEO 这类工作时，最怕的是每次都从零开始问模型、手动搬运结果。

Skill 的价值是：

• 把“如何做某件事”固化成脚本/规则/输出格式
• 把“证据包”与“结论”绑定（例如审计报告里带 DOM 路径、抓取片段、规则阈值）
• 让 Agent 具备稳定可预测的能力边界

这与 Charon 的设计理念如出一辙：数字分身的能力是靠一组可以复用且自我更新进化的 skills 逐步堆出来的。

3. 从 Charon 到 OpenClaw 的启发

把 Charon 的构想和 OpenClaw 的机制对齐，两者的共同点是都强调“长期、可迭代、以项目为中心”。它们本质都在做一件事：

把 AI 从“问答工具”变成“工作系统的参与者”。

这意味着：输出要进项目目录；过程要可追溯；结果要可复用。

两者的 memory 机制对比：差异不在“存在哪里”，而在“如何被装配进上下文”。 Charon 和 OpenClaw 在“记忆外置到文件系统”这点上高度一致，但它们在记忆的粒度、写入闸门、以及默认的上下文装配方式上，呈现出两个很有代表性的取舍。

Charon 更强调“可训练语料”与“记忆即数据集”。在最初设想里，我把 memory/ 明确定位为未来“模型态贾维斯”的训练源数据，所以它天然会追求：

• 结构一致：更像数据集，而不是随手日志
• 高信噪比：写入要 gate（inbox → review_queue → eval → merge）
• 分层明确：identity / episodic / semantic / procedural，避免“一锅粥”

它的风险也很典型，过早把系统当数据工程，会导致“忙于整理而不产出”（过度仪式化）。并且如果没有很强的检索与压缩机制，memory/ 增长会直接把上下文预算打爆。

OpenClaw 把记忆拆成“日记 + 长期摘要”，默认支持持续运转，更像一个可持续的个人工作习惯：

• memory/YYYY-MM-DD.md：允许记录“发生了什么”（raw、低门槛、持续性强）
• MEMORY.md：只保留“长期稳定事实与重要上下文”（被提炼后的高信噪比）

它的好处在于，写入门槛很低，所以更容易长期坚持；同时它天然鼓励“先记流水、再做蒸馏”的节奏：把生活/工作过程先沉淀为可追溯的日记，再在合适的时间抽取出稳定事实与关键脉络，写进长期记忆。代价是你必须把“整理”这件事制度化：如果缺少定期索引与提炼，日记会快速堆积成不可检索的噪声；而当 MEMORY.md 本身变长，它也会遇到同样的上下文预算问题——这时候就需要更明确的检索、压缩与分层策略。

上下文工程（Context Engineering）是真正的分水岭，两者的重中之重其实相同：记忆不是被“存”出来的，而是被“用”出来的。

可用的记忆系统，关键不在于“存了多少”，而在于每次交互时你能否把最小且足够的材料装配进上下文：有一个极小的常驻身份/边界/目标（always-on），再从 kb/memory 里按需检索少量相关条目（retrieval），把原文压成能工作的摘要（compression），先给结论、必要时再逐步展开证据（progressive disclosure），同时通过写入闸门防止未经确认的信息进入长期记忆（write gate）。当这套装配线跑通后你会发现，“记忆”本质上是一套可控的上下文供给系统；而“数字分身”也不只是更大的 memory，而是更好的检索、压缩、对齐与行动闭环。

4. 个人系统的终局不是工具，是“可持续的反馈回路”

更准确说：终局不是某个 App，而是一种能自我演化的 personal agent architecture，是否拥有一个可持续的反馈回路（一个能自我积累、也能自我纠偏的循环系统）。我对未来 personal agent 的想象，更像一套能长期运行的个人架构。

1）大模型能力会越来越像电力，但“上下文工程”仍然是真正的护城河。 当模型能力趋同后，决定一个 personal agent 是否好用的，不再是“回答有多聪明”，而是它能不能在正确的时刻拿到正确的上下文，并且不把错误写成事实。

2）RAG 不是终点，真正的难点是“检索-压缩-验证”一体化。 未来的个人系统会更像一个“证据驱动的工作系统”：

• 检索到的不是文本块，而是带来源、置信度、反例的“证据包”
• 压缩不是摘要，而是面向任务的“决策材料”（what matters / what’s missing）
• 验证会成为默认动作：对关键结论做最小代价的交叉检查

3）技能（skills）会变成个人系统的“能力经济”，而不是 prompt 工具箱。 你会逐渐发现：稳定可复用的能力边界，来自脚本、规则、评测与数据闭环，而不仅仅是高质量的提示词。 长期看，个人的 skill library 会像个人操作系统的 API。

4）形态上，personal agent 会从“聊天框”走向“多视图工作台”。 聊天是入口，但不是最有效的工作界面。更合理的形态可能是：

• 一边是对话与指令
• 一边是项目目录、证据包、diff、报告、待办
• 再加一个“记忆面板”：显示本次装配进上下文的记忆、为什么被选中、如何被更新

5）“模型态贾维斯”更像结果，而不是起点。 先用 agent 形态跑通长期闭环：写入闸门、回归评测、上下文装配线、技能沉淀。 当这些资产积累起来，再把你确认过的高质量输出蒸馏成训练数据，模型态才有意义——否则只是在训练一个更自信的幻觉器。

Charon 作为愿景依然重要——它定义了我想让“自我表达”最终长成什么样。这条路不是哲学讨论，而是可以被工程化执行的长期项目。

如果你也在做个人系统，我的建议仍然只有一句：

少一点“工具选择焦虑”，多一点“把产出写进文件”的工程习惯。