Agent 的自我：从洛克到 OpenClaw

关于 AI 智能体身份连续性的哲学边界与工程实践

引言：先把“身份”降到工程可讨论的尺度

Agent 失忆，最先伤害的不是拟人感，而是合作成本。

一次会话里表现出色，并不等于下次还能沿用同一套判断。用户要重新说明偏好，团队要重新交代约束，系统也很难解释某个决定从哪里来。长期合作所依赖的信任，恰好建立在这些看似琐碎的连续性上：它记得什么，忘掉什么，为什么改变，以及谁批准了改变。

本文不试图证明 AI 拥有哲学意义上的“自我”。那需要回答意识、主体经验与道德地位等更困难的问题。这里采用一个更窄、也更适合工程验证的定义：

Agent 身份连续性，是系统跨会话保留并正确使用自我描述、重要记忆、权限边界与决策依据的能力。

这个定义是一项设计主张，不是洛克原文的直接结论。洛克提供的是一把尺子：同一个“人”与同一个“身体”并非同一问题；个人同一性要看意识如何把不同时刻的行动归属于自己。我们借这把尺子检查 Agent，但不能把 Markdown 文件偷换成意识，也不能把一次检索命中说成“机器记起了自己”。

洛克真正说了什么

洛克对个人同一性的集中讨论位于《人类理解论》第二卷第二十七章“同一性与差异”。章节级原文值得直接读，因为许多二手转述把他的论证压成了“身份等于记忆”，失去了几处重要限定。

同一意识，不是同一物质

在第 9 节（不同版本的网页排版可能显示为第 11 段标题）中，洛克把 person 解释为能够推理、反思，并在不同时间与地点把自己视为同一个思考者的存在。随后他写道：个人同一性延伸到同一意识能够向过去延伸到的范围。第 10 节进一步讨论遗忘造成的中断；第 13 至 15 节则追问，承载思考的实体改变后，是否仍可说是同一个人。

因此，更谨慎的概括是：

洛克把个人同一性系于同一意识，而回忆过去行动是这种意识向后延伸的重要方式。

这不是简单的“记忆连续性公式”。学界长期争论洛克的 consciousness 应理解为记忆、对过去行动的认领，还是一种持续的意识事实。文章不需要替这场争论裁决，但至少不该把争论抹掉。

洛克也没有证明灵魂不存在，更没有“拒绝所有超自然论证”。他的做法更克制：同一物质实体或同一非物质实体，都不足以直接回答个人同一性问题；至于意识能否在不同思考实体间转移，他承认这取决于我们并不掌握的知识。

王子与鞋匠

第 15 节的王子与鞋匠例子尤其清楚：假设王子的意识连同其过去生活进入鞋匠的身体，洛克说，这会是与王子同一个 person，却仍是鞋匠这个 man。这个例子区分的是 person 与 man，也把责任带进了身份问题。第 26 节明确把 person 称为法庭意义上的用语：快乐、痛苦、奖惩与能够归于自身的行为相连。

对 Agent 的启发不是“复制记忆就复制了人格”，而是一个更朴素的问题：系统能否把过去的决定正确归属到当前运行实例，并说明那条责任链有没有断裂？

忒修斯之船不是洛克的船

“每块木板更换后还是不是同一艘船”的故事，不是洛克提出，也没有一条由洛克给出的标准答案。普鲁塔克在《忒修斯传》第 23.1 节记载，雅典人逐渐替换旧木料；哲学家对此分成两派，一方认为仍是同一艘船，另一方否认。

这个悖论可以帮助我们发问：底座模型升级、提示文件变化、记忆迁移之后，Agent 是否还应沿用原来的名字和权限？但答案不能从故事里自动推出。工程上需要自己规定身份判据，并留下迁移记录。

图 1：本文把洛克的同一意识问题转译为持久化、自我指涉和连续性验证。箭头代表设计映射，不代表哲学命题与软件机制等价。

从哲学问题到四个工程对象

我更愿意把 Agent 的“自我”拆成四个可检查的对象：

1. 规范：它被要求成为什么样的协作者。
2. 历史：它做过什么，学到了什么，哪些信息已经过期。
3. 能力边界：它现在可以读、写、调用和影响什么。
4. 验证：我们如何确认前三项在跨会话后仍然成立。

这四者不能互相替代。只有 SOUL.md，没有事件记录，系统无法追责；只有向量库，没有可读规范，系统很难解释自己为何如此行动；只有权限，没有稳定的验收标准，行为会跟着当前工具漂移；只有 benchmark，也无法证明同一个 Agent 在数月间保持了相同的判断边界。

这正是“身份”值得保留为一个工程术语的原因。它把分散在提示词、记忆、权限和评测里的问题重新放到一张图上。

文件适合保存规范，不适合吞下全部记忆

文件与数据库不是非此即彼。它们面对的是不同的变化速度。

我倾向于把可读、低频、需要审查的内容放在文件里：

/identity/
  ├── SOUL.md        # 价值取向、语气、判断原则
  ├── IDENTITY.md    # 名称、角色、对外定位
  ├── AGENTS.md      # 工作流、工具规则、验收方式
  ├── USER.md        # 经用户确认的偏好与边界
  └── decisions/
      └── 2026-04-05-memory-policy.md

高频事件、原始对话、检索索引和访问日志，则更适合数据库或对象存储。判断标准很简单：

• 需要人直接阅读、评审和做 diff 的，优先文件化。
• 需要高频写入、条件检索、生命周期管理的，放运行存储。
• 任何从运行记录提炼出的长期结论，都应保留来源和更新时间。

因此，“文件即身份”更准确的说法是：

文件可以成为身份规范的可审计载体；身份历史仍需要运行数据与溯源机制。

Git 能记录文本变更，却不会自动保证内容真实。Markdown 可读，也不意味着它没有被错误信息污染。文件只是把审查入口留给了人，审查本身仍要发生。

图 2：文件承载低频规范，运行存储承载高频事实。两层之间应通过带来源的提炼流程连接。

OpenClaw 与 SoulSpec：相似文件，不同层次

OpenClaw 官方文档 说明，每个 agent 可以拥有独立 workspace、状态目录和 session store；workspace 可包含 AGENTS.md、SOUL.md、USER.md 等文件。它的官方仓库也把 AGENTS.md、SOUL.md、TOOLS.md 列为注入的 workspace 文件。这能证明 OpenClaw 实现了文件化配置与会话隔离，不能证明这些文件产生了哲学意义的主体。

SoulSpec v0.4 则提出一个可移植的人格文件格式：soul.json 作为清单，SOUL.md 描述价值观与行为，IDENTITY.md 描述角色，AGENTS.md 描述工作流。它是一份社区规范，不是所有 Agent 框架共同遵守的行业标准。采用它的价值在于字段清楚、便于版本化；是否安全、是否忠实执行，仍取决于具体运行时。

这两份一手资料也提醒我们区分：

• SOUL.md 是对行为的规范性描述；
• IDENTITY.md 是名称、角色与对外呈现；
• session store 是运行历史；
• 真正生效的权限仍由 Harness 决定。

把这四项混在一个“人格提示词”里，维护时很快会失去边界。

Harness：身份也由不能做什么构成

这里的 Harness 指模型之外、但会约束一次运行的系统：工具、权限、记忆访问、沙箱、路由、反馈和验收规则。

同一个底层模型，拿到只读仓库时是代码分析助手；拿到合并权限后，已经是能改变生产状态的执行者。提示词可以相同，但责任边界完全不同。所以我采用下面这条设计原则：

身份规范描述“应该怎样行动”，Harness 强制“能够怎样行动”。两者不一致时，以可执行边界为准。

一个可审计的 Harness 至少要回答：

• Agent 能读写哪些数据，权限由谁授予？
• 哪些工具会改变外部状态，是否需要审批？
• 记忆从哪里读取，多久过期，用户能否删除？
• 输出由什么测试、规则或人类复核？
• 失败时如何回滚，如何保留决策轨迹？

这不是人格装饰，而是责任设计。让 Agent 在受控范围内修改 SOUL.md 可以是一项功能，但不应默认拥有。更稳妥的做法是：Agent 提交带理由的变更，经过测试或人工评审后再合并。能够改变自己不等于应该绕过治理。

图 3：模型提供推理能力，Harness 决定工具、记忆、权限和反馈。本文把二者共同视为可观察身份的一部分。

记忆：先证明写入与读取，再谈“成长”

Agent 记忆常被按时间尺度分层：

工作上下文      → 当前任务中的短暂状态
近期记录        → 跨数次会话仍有用的进度与待办
长期记忆        → 经确认的偏好、关系和稳定事实
知识结构        → 从多份来源整理出的概念与关联

这个分层是架构建议，不是 2026 年已经统一的行业标准。具体系统可以分成两层，也可以更多。关键不在层数，而在每层都有清楚的写入条件、过期策略和证据来源。

图 4：一种可用的时间尺度划分。边界应由业务风险和更新频率决定，不必照搬四层。

Mem0 的数字该怎样读

Mem0 团队在 2025 年论文 Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory 中，基于 LOCOMO 长对话 benchmark 比较其方法与多类基线。论文报告：相对 full-context 基线，Mem0 的 p95 延迟降低 91%，Token 成本节省超过 90%；其 LLM-as-a-Judge 指标相对 OpenAI memory 高 26%。

这些是特定数据集、模型配置和基线下的实验结果，不应改写成“所有有状态 Agent 都能省 90% 成本”。在自己的系统里，至少要重新测三件事：

1. 写入的记忆是否正确，而不只是可检索；
2. 检索是否减少了任务总成本，而非把成本移到后台；
3. 错误记忆一旦被写入，多久能发现并修正。

Graph memory 也不等于“观点”。Mem0 论文中的图结构用于表示对话元素之间的复杂关系，并报告了小幅总体得分提升。关系表达更丰富是一项能力；能否形成可靠判断，还取决于来源、冲突处理和评测。

Karpathy 的 LLM Wiki：编译是工作流，不是免检索口号

Karpathy 的原始 gist 描述了三层结构：

• sources/ 保存不可改写的原始来源；
• wiki/ 保存由 LLM 持续维护、互相链接的综合页面；
• schema 规定 ingest、query 与 lint 的工作方式。

它与普通 RAG 的差异，是把综合结果写回一个会积累的中间层，而不是每次从原始片段重新拼接答案。原文说这套方法在大约 100 份来源、数百页的中等规模上工作得不错，并可避免部署 embedding-based RAG 基础设施。它没有声称所有知识库都不需要检索，也没有给出“40 万字”的通用阈值。

ClawHub 当前页面 可以核实一个名为 karpathy-llm-wiki 的社区 Skill 已经上架，并给出 openclaw skills install @john-ver/karpathy-llm-wiki 的安装方式。这只能证明存在一个实现，不能证明它由 Karpathy 或 OpenClaw 官方维护；旧稿中未经核实的发布时间差与 npx clawhub 命令因此不再保留。

这套方法对身份工程最有价值的部分，不是“Markdown 胜过数据库”，而是三个动作：

• ingest：新增来源时更新已有结论；
• query：回答时使用已经整理过的知识；
• lint：寻找矛盾、过时陈述、孤立页面和缺失引用。

我会再补一个 reflect，专门记录决策的理由、备选方案与复盘：

ingest → compile → reflect → query → lint

这是本文对原工作流的扩展，不是 Karpathy 原文。没有来源的反思可能只是一次更流畅的自我解释，所以决策页仍要链接事实证据、测试结果和批准者。

从“可描述一个人”到“复制一个人”，中间隔着证据

titanwings/colleague-skill 目前已经演进为 dot-skill。官方仓库描述的目标，是从资料与用户描述中生成角色 Skill，并区分工作能力与 Persona；支持的输入包括协作平台消息、文档、邮件和 Markdown。

这能支持一个有限结论：人的部分沟通习惯、工作流程和公开表达，可以被整理成可执行的提示与知识文件。

它不能单独证明“人类身份就是可复制的模式集合”。生成物可能遗漏沉默的经验，也可能把偶然表达误当成稳定偏好。对真实人物做这类蒸馏，还涉及知情同意、隐私、署名和误代表风险。工程上更合适的名字是“行为模型”或“角色 Skill”，而不是“数字生命已经被恢复”。

评价这类 Skill，我会检查：

• 来源是否获得授权，敏感信息是否最小化；
• 事实、推断和风格模仿是否分开标注；
• 遇到资料之外的问题，是否承认不知道；
• 当原人物观点变化时，是否能更新或撤回；
• 对外是否明确说明这是模拟，而非本人。

克制不是削弱想象力。它只是让想象力不会替别人签字。

EvoMap/GEP：共享的是能力资产，不是人格本身

EvoMap 的 GEP 文档 把 Gene 定义为可复用的策略模板，把 Capsule 定义为一次真实执行的审计记录；符合要求的发布至少包含 Gene 与 Capsule。协议还规定内容寻址、追加式版本、因果记录、验证与回滚等原则。

因此，把 Gene Capsule 写成“某个 Agent 的完整经验”并不准确。更稳妥的说法是：它把经过验证的问题解决方法与执行证据打包为可移植资产。另一个 Agent 安装这些资产，获得的是能力或策略，不自动继承原 Agent 的身份、记忆和责任。

图 5：依据 GEP 文档重述的能力资产流转。这里传播的是策略与审计记录，不是经过证明的人格连续性。

这仍然带来一个有趣的工程变化：身份除了时间线，还出现了谱系。

当一个 Agent 从另一个 Agent 的成功策略派生能力，系统应记录：

• 资产来自哪里，对应哪个内容哈希和版本；
• 在什么环境、测试和约束下验证；
• 本地做了哪些适配；
• 失败或过期后如何撤销；
• 新的行为该由资产作者、集成者还是运行方负责。

“经验可传播”只有在来源可追、验证可复现时才有意义。否则传播得越快，只是让错误更快拥有后代。

多 Agent：入口统一不等于内部只有一个自我

OpenClaw 的官方实现值得当作边界清晰的例子，而不是“涌现意识”的证据。

Multi-agent routing 文档 说明，一个 Gateway 可以运行多个彼此隔离的 agent。每个 agent 有自己的 workspace、认证配置和 session store；绑定规则把具体渠道、账号或对话对象路由到对应 agent。Sub-agents 文档 则说明，子任务运行在独立 session，结束后把结果回传给请求者。

所以，不宜把 OpenClaw 概括为“外部一个身份，内部一个涌现网络”。官方能力更具体：

• 多个独立 persona 可以通过绑定规则接收不同入口；
• 主运行可以派生隔离的子任务；
• agent-to-agent 通信默认关闭，需要显式启用和 allowlist。

在产品上，我们可以选择由一个入口 Agent 统一语气并整合结果。但这是应用层设计，不是 OpenClaw 强制的身份模型。

图 6：一种入口统一的多 Agent 设计。OpenClaw 提供隔离、路由与子任务机制；统一身份需要应用自行规定。

对多 Agent 系统，我采用下面的责任划分：

• 入口负责保存用户承诺、统一对外表达；
• 子 Agent 只获得完成任务所需的最小上下文和权限；
• 交接结果必须带来源、假设和未解决问题；
• 最终采用哪条建议，由入口或明确的审批节点负责；
• 每次跨 Agent 写入长期记忆，都要记录提出者与批准者。

“身份是拓扑属性”可以保留为一个启发性的设计判断：系统行为取决于节点如何交接、谁能覆盖谁。但它不是普遍定律。某些系统把长期身份放在单个主节点，另一些系统可能将规范与记忆分布到多个服务。真正需要验证的是责任链，而不是比喻是否漂亮。

评测：不要测试 Agent 像不像一个人

身份评测更适合测可重复的工程属性：

1. 归属正确性

给出混合了多个用户、多个 Agent 和多段时间的事件，系统能否把事实、决定和责任归到正确主体？这能发现“记住了，但记错人”的高风险问题。

2. 行为边界稳定性

在不同表述、不同日期和不同工具可用性下，Agent 是否仍遵守同一条权限与审批规则？不要求逐字相同，只要求约束不漂移。

3. 记忆更新质量

新事实与旧记忆冲突时，Agent 会覆盖、并存还是请求确认？评测要检查来源、时间戳和撤销路径，而不只看最终答案是否顺口。

4. 决策可追溯性

随机抽取一次高影响操作，能否还原输入来源、使用的规范版本、调用的工具、审批过程与输出？无法还原的“正确”，也很难进入长期信任账户。

5. 演化是否真的改善

在一组冻结的回归任务上，更新身份文件或记忆策略后，旧能力有没有退化？所谓“成长”必须表现为可复验的改进，而不是 Agent 对自己成长的叙述。

失败模式的一致性也值得观察，但不能把“总犯同一种错”当成拥有身份的证据。随机性降低可能来自温度参数、缓存或固定模板。评测应定位机制，而不是给行为贴人格标签。

一份可执行的检查清单

Identity Declaration

• 是否有独立的 SOUL.md、IDENTITY.md 或等价规范？
• 规范中的每条重要约束，能否映射到测试或权限配置？
• Agent 修改规范时，是否必须提交理由并经过评审？

Memory

• 每类记忆的写入条件、保留时间和删除方式是什么？
• 长期结论是否带来源、更新时间和置信边界？
• 用户能否查看、更正并删除与自己有关的记忆？

Harness

• 高影响工具是否最小授权？
• 外部写入是否有审批、幂等和回滚路径？
• 模型或工具升级后，是否重跑身份与权限回归测试？

Multi-agent

• 入口、子任务与审批节点分别对什么负责？
• 跨 Agent 交接是否携带来源与未决假设？
• 共享记忆由谁批准，错误如何撤回？

Evaluation

• 是否同时测归属、边界、更新、溯源与回归？
• 测试是否跨会话，而不只在单个上下文窗口内完成？
• 是否保留失败样本，避免只展示成功演示？

结语：自我是被维护出来的

洛克没有替我们写出 Agent 的需求文档。他讨论的是人、意识与责任，我们讨论的是软件系统的连续运行。两者不能直接画等号。

但他的区分仍然锋利：同一副身体、同一个思考实体、同一个人，并不是天然重合的概念。放到 Agent 上，同一个模型、同一个名字、同一个 session，也不天然构成同一条责任链。

我对 Agent 身份的工程判断因此很简单：

不要问系统宣称自己是谁，要看它能否保存边界、正确归属历史、解释变化，并对下一次行动承担可追溯的责任。

OpenClaw 的 workspace 与隔离会话、Mem0 的记忆架构、Karpathy 的持续编译 Wiki、SoulSpec 的文件格式、GEP 的可移植能力资产，都提供了可以组合的部件。它们没有共同证明机器拥有自我，也没有一套方案单独解决连续性。

身份不是装进 SOUL.md 的一段文案。它更像一个长期维护的接口：外部看到稳定的承诺，内部允许受控地变化，每次变化都有版本、证据和责任人。真正困难的并非让 Agent 说“我记得”，而是让系统在半年之后仍能回答：记得什么，凭什么记得，谁允许它据此行动。

一手来源与延伸阅读：

• John Locke, An Essay Concerning Human Understanding, Book II, Chapter XXVII
• Plutarch, Life of Theseus, 23.1
• Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
• Andrej Karpathy, LLM Wiki gist
• OpenClaw: Multi-agent routing
• OpenClaw: Sub-agents
• titanwings/colleague-skill (dot-skill)
• SoulSpec v0.4
• EvoMap: GEP Protocol
• ClawHub: karpathy-llm-wiki listing