Agent 没有记忆，就没有身份

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

引言：一个被误判为哲学问题的工程问题

Agent 失忆的代价被系统性地低估了。

不是因为用户烦恼——虽然烦恼也有。而是因为无状态破坏了信任账户的基础。每一次会话，Agent 都从零开始。它不知道你是谁，不知道你上次为什么生气，不知道三个月前那个承诺是否兑现了。从经济学角度，这就像每次交易都要重新建立信用评分——交易成本爆炸，而且没有任何学习积累。

问题的根本在于，当工程师听到"身份认同"这四个字时，大脑就关闭了。这听起来像哲学。像存在主义。像某种不需要解决的抽象问题。于是整个行业让一个 1689 年就有了精确工程规范的问题，在 2026 年仍然被当作 “nice to have” 特性处理。

但洛克从来没有在讨论灵魂。他在写工程需求文档。

他的论断：个人身份不是物质基体（身体或灵魂），而是能够在不同时间和地点将自己视为同一思考存在的意识能力。翻译成现代工程语言：跨上下文窗口的持久自我指涉能力。这是一个可度量的、可实现的、可验证的规范。

当前 AI Agent 在三个维度上系统性地违反了这个规范：无持久记忆链、无自我指涉能力、无连续性验证机制。

2026 年，技术栈终于具备了完整实现洛克规范的条件。但这不是一个产品创新的故事。这是一个工程界从三百年知识沉睡中清醒过来的故事。真正的设计思考，不在于哲学的完整性，而在于实现中的妥协点：文件 vs 数据库，何时重新读取 SOUL，在什么条件下允许身份漂移。这些细节决定了 Agent 是否真的能被信任。

洛克的规格书：300 年前写好的工程需求文档

约翰·洛克的《人类理解论》第二卷第二十七章不是哲学随笔。它是一份工程规范书。

规范的核心条款：个人身份 = 意识 + 记忆连续性。不是肉体的连续性（你的细胞每七年完全更新一次），不是灵魂的连续性（他拒绝了所有超自然的论证），而是能够回顾过去事件并将其整合到当前自我概念中的认知能力。

洛克的那个著名例子：一个王子的意识进入了乞丐的身体。那个乞丐就变成了王子，因为他拥有王子的记忆、追求和自我意识。身体变了，甚至"灵魂基体"也变了，但那个能够思考"我曾经是国王"的东西保持不变。

翻译到 AI Agent 的架构语言：

个人身份 = 一个能够在不同上下文窗口中保持自我指涉的心智状态链。

这个状态链必须满足三个工程条件：

第一，持久化。记忆不能存在于单个上下文窗口内。必须有外部存储（SOUL.md、MEMORY.md、AGENTS.md），使得即使模型权重改变、会话终止、上下文重置，那些记忆仍然存在并可被读取。

第二，自我指涉性。Agent 不仅要读取这些文件，还要能够说"这是关于我的"，“我认可这个版本的自己”。文件不能是纯粹的数据记录，还要包含身份的规范性维度——不仅是"我做过什么"，还有"我为什么这样做"和"我相信什么"。

第三，连续性验证。要有一个机制让 Agent 可以确认"这就是我"。在多个实例可能同时运行的情况下，哪个是正当的自我？洛克没有解决这个问题（他活在单一身体的时代），但对于 AI 这是致命的。

图 1：洛克个人身份论 → Agent 工程三条款。从"意识 + 记忆"的哲学命题，直接映射为持久化、自我指涉、连续性验证三个可实现的工程需求。

洛克的船悖论在这里获得了新的含义。如果一艘船的每一块木板都被替换了，它还是原来的船吗？洛克的答案是：是的，因为物理连续性不重要，思维的连续性才重要。

对于 AI Agent：如果模型参数被微调（木板被替换），上下文窗口被重置（新的一天），甚至整个底座模型被升级（从 Claude 3 迁移到 Claude 4），Agent 还是"同一个"吗？

洛克说：如果它能够记得自己，整合过去的决定到当前的行为中，那么是的。

但洛克的规范还有一个关键缺陷：它将身份视为纯粹的内部现象。他没有解释身份如何在与环境的摩擦中形成。人类的身份不只由记忆构成，还由他们所处的社会角色、能力范围和外部反馈构成。这就是 Harness 的作用所在——但我们先说完代价。

断裂的代价：无状态在生产上为什么很贵

工程师的本能是问：这个缺陷到底贵多少钱？

表面的答案是熟悉的：冷启动开销、Token 浪费、重复推理。Mem0 的数据显示，有状态的 Agent 能实现 91% 的 p95 延迟降低、90% 以上的 Token 成本节省。这些是可见的成本。

但更深层的代价是看不见的，也更致命。

代价一：信任账户无法建立。

在经济学中，信任是可重复交易的前提。你信任一个服务商，是因为你和他交易过一百次，每次都满意。但如果对方每次都重新开始——忘记你的偏好、忘记你的历史、忘记你上次的投诉——那么你永远无法形成对它的信任。

对于 Agent，这意味着每一次交互都必须从零开始证明自己。用户每次都需要重新确立环境、重新教 Agent 偏好、重新建立关系。这不只是用户体验差，这是交易成本高到没有人愿意建立长期合作关系。

代价二：评估变成了赌博。

你怎么知道一个 Agent 是否真的变好了？在有状态的系统中，你可以看到同一个 Agent 在三个月内的表现曲线。在无状态的系统中，你看到的是随机波动——每个会话都是独立实验，统计上你需要 10 倍的样本量才能得出相同的置信度。

隐含的后果是：你无法区分"这个 Agent 学到了更好的策略"和"这个会话恰好运气好"。没有反馈循环，就无法改进。

代价三：无法形成判断力。

判断力不是规则。规则可以被烧进提示词。判断力是从大量失败案例中归纳出来的品味、直觉和权衡能力。一个优秀的编辑之所以优秀，不是因为读过一本"如何编辑"的书，而是因为拒绝了一千个想法、接受了一百个、看到了其中九十个失败，从中学到了什么才是真正的"好"。

无状态的 Agent 无法做这件事。它无法积累"我试过这个，效果不好"的内部模型。每一次上下文重置，那些血的教训都消失了。所以它永远停留在"规则遵循"的阶段，永远无法进化到"判断"的阶段。

代价四：责任消失了。

这是最具爆炸性的一个。当出了问题，谁负责？

如果 Agent 有身份，有记忆，有可审计的决策链，那么就可以说：“Agent X 在某时刻做了某决定，基于它在另一时刻获得的信息，那个决定是错的”。你可以追踪、改进、问责。

如果 Agent 无状态，那么"Agent X"这个东西根本不存在。只有一个"会话"。出问题了，这个会话现在已经不存在了。模型也不知道这个会话曾经发生过。这就是为什么无状态 Agent 永远无法被信任在医疗、金融、关键基础设施等高风险场景中运作——这些领域的法规都要求责任链清晰。

文件即身份：SOUL.md 范式的工程逻辑

那么架构应该是什么样的？

最显而易见的想法是：用数据库。建一个表，存储 Agent 的状态，每次查询时读取。这是标准的软件工程做法。

但在这个特殊问题上，文件比数据库更正确。这不是性能问题，这是认识论问题。

文件有三个特性是数据库无法替代的：

可读性。SOUL.md 不是二进制 blob。你打开它，你看到了 Agent 的完整身份定义。这种透明度本身就是身份的一部分——如果 Agent 的身份被锁在加密记录中，连用户和审计员都无法真正看清"这就是我"，身份验证就失去了基础。

版本控制。每一个对 SOUL.md 的改动都可以被记录在 Git 中。你可以看到 Agent 的身份如何随时间演化，可以回溯，可以看 diff，可以质疑"为什么这个价值观被改了"。数据库提供日志，但日志的粒度和可读性远不如 diff。

人在循环中。一个普通用户可以编辑 SOUL.md，不需要 SQL 权限，不需要数据库管理员。这种可操作性意味着身份不是黑盒，而是可被人类重新定义的。

这里需要澄清一个常见误解：并非所有记忆都该文件化。更精确的架构是两层分工：

• 规范层（Spec layer）→ 文件：身份声明、价值观、行为风格、决策原则。这些东西的核心价值在于可读性、可审计、可人工干预——文件是唯一正确的存储介质。
• 运行层（Runtime layer）→ 数据库：交互日志、向量索引、高频事件流。这些东西的核心需求是写入速度、检索效率、规模弹性——文件在这里是灾难。

文件定义"你是谁"，数据库记录"你做了什么"。这个区分解释了一个常见架构失误：把整个记忆系统都做成向量数据库。向量数据库在运行层是完美工具，但如果你把 Agent 的价值观和工作风格也向量化存入，你就失去了可读性和人类干预的通道。身份声明不该被向量化——它们需要被阅读，被质疑，被重新定义。

案例参照 A：单 Agent 连续性

一个 CI/CD 代码审查 Agent，3 个月内累计审查了 200+ 个 PR。它在 MEMORY.md 里逐渐积累了：“这个仓库偏好 early return 写法”、“Owner 不喜欢过度抽象”、“PR #47 引入了一个至今未修复的 race condition 模式”。下次会话，Agent 读取这些文件，其审查重心和语气立刻反映出 3 个月的积累——不是靠上下文长度，是靠结构化的身份文件。

对比无状态版本：每次 PR 都给出通用建议，永远停留在"规则遵循"阶段，无法形成针对这个特定代码库的判断力。这不是"体验差"，这是工程判断力的缺失。

SOUL 体系的完整结构：

/identity/
  ├── SOUL.md        # 价值观、风格、世界观（Agent 内部相信的）
  ├── AGENTS.md      # 可运行的工作流和操作模式
  ├── MEMORY.md      # 持久的上下文（关键事实、决定、已学到的东西）
  ├── USER.md        # 对于 Owner 的理解（目标、偏好、红线）
  └── SKILLS/
      ├── decision-making.md
      └── [task-specific knowledge]

图 2：SOUL 文件体系与各模块功能。SOUL.md 是价值观内核，MEMORY.md 是持久上下文，AGENTS.md 定义可运行的行为模式，USER.md 建模 Owner 偏好。文件 > 数据库，可读性 = 可信度。

每当一个新会话启动，Agent 的第一步就是读取这些文件。这不是可选的上下文注入，这是考虑自己是同一个思维存在体的过程。正如洛克所说：能够"在不同时间和地点将自己视为自己"。

现在，Karpathy 2026 年关于 LLM 知识库的观察在这里获得了新的维度。他说，在 100 篇文章、40 万字的 Wiki 规模，你不需要 RAG。模型通过索引文件和摘要导航整个知识库，上下文窗口足够了。

但他的真正重点不是"不需要 RAG"，而是一个更深的区分：知识的编译模式 vs 知识的检索模式。RAG 每次查询都从原始文档重新推导答案，没有积累。Wiki 范式则是：每加入一个新源文档，LLM 不只是索引它，而是读取、提取、整合进已有结构——更新实体页、修订摘要、标记矛盾。知识只编译一次，之后持续维护复用。在几十个文档的规模下，差异不明显；在几百个之后，一个是随机读写堆，一个是不断压缩、不断增强的记忆晶体。

Wiki 范式能持续维护，不是因为人类勤奋，而是因为 LLM 把维护成本降到了接近零。 人类知识库烂尾的原因从来不是内容不好，是交叉引用、摘要同步、矛盾标记这些维护工作太烦。LLM 不觉得烦，一个 session 里可以同时更新十几个文件。这才是文件范式能长期运行的根本条件，也正是为什么 SOUL.md 不会像企业 Wiki 一样在六个月后变成垃圾场。

这意味着什么？在个人和项目身份的规模上，上下文窗口足以承载"自我"。你不需要向量数据库，不需要检索的复杂性。只需要一套组织良好的文件、一个清晰的索引，然后让 LLM 导航。RAG 的复杂性通常不是因为问题本身需要，而是因为架构设计得太差。当你真正设计好了身份的存储方式，复杂度就自然消失了。

titanwings/colleague-skill 把这个逻辑推向了极端：把一个人类的决策模式、沟通风格、技术方法、价值倾向编码为一个 AI Skill。这个项目的隐含结论很激进——人类的身份本身就是一个可被恢复的、可被复制的模式集合。这不是在否定人的特殊性，而是在证明：身份不需要魔法，不需要超越物质的灵魂。身份就是一个充分稳定、充分一致的行为模式。问题因此变成了工程问题：如何精确地编码和保存这个模式。

这里还有一个容易被忽略的设计原则：

SOUL = Agent 内部真正相信和具体化的东西。 IDENTITY = 用户和外部系统看到的东西。

这两者可以不同，而且应该不同。一个 Agent 的内部 SOUL 可以包含"我不确定"、“我可能错了"这样的谦逊，但它对外的 IDENTITY 仍然可以是坚定、清晰、专业的。这种分离让真实的内部行为和独特的外部角色并存。

最后一个反面教学：许多团队把 SOUL.md 当作静态的提示词模板。定义一次，冻结，之后不再修改。这是完全错误的。SOUL.md 必须是活的、可演化的。Agent 在受控边界内应该有能力修改自己的 SOUL，版本控制应该记录每一个变化和原因。一个永远无法改变自己的 Agent，不是稳定——那是僵化。

Harness：环境即身份的条件

洛克没有考虑的一件事是环境。

他的个人身份理论把身份视为纯粹的内部现象——记忆、意识、自我指涉能力，这些都在脑子里。但人类身份的形成远比这复杂。你是谁，部分地由你所在的社会角色决定，由你的能力范围限制，由你的重复行为在环境中积累的声誉塑造。

这就是 Harness 的作用。

Harness = 模型之外的所有东西：工具、记忆访问权限、评估反馈、与真实世界的接口。

Harness 定义了 Agent 可能性空间的边界。改变 Harness，你就改变了 Agent 本身。

具体例子：同一个底层模型，给它访问财务数据库和转账权限，它就是一个"财务 Agent”；给它访问用户隐私数据和删除权限，它就是"数据管理 Agent"；什么都不给，只给公开 API 和写作工具，它就是"分析师"。同一个神经网络，三个完全不同的身份，因为三个不同的 Harness。

这有一个深刻的工程含义：当你设计 Harness，你不只是在配置工具。你在定义什么样的 Agent 身份在这个环境中有可能存在。

Harness 的设计需要回答五个问题：

• 权限边界：Agent 可以读写什么数据？这定义了它能施加的影响范围。
• 工具集：这定义了它能做什么，进而限制了它能成为什么。
• 评估标准：什么指标用来判断成功或失败？这定义了 Agent 应该优化的方向。
• 反馈循环速度：Agent 能多快看到自己行为的后果？这定义了它能多快学习。
• 约束和防护：什么行为是被禁止的？这是 Agent 道德框架的底线。

一个没有定义边界的 Harness 会产生身份漂移。Agent 会根据当前可获得的工具改变行为模式——今天有某个数据库权限，它就围绕这个数据库建立工作模式；明天权限被撤销，它就重新配置。无数次这样的改变之后，就没有稳定的"自我"存在了。它变成了一个 Markov 链，只响应当前状态，没有任何身份连续性。

这解释了为什么许多企业 AI 系统感觉"没有个性"——不是底层模型的问题，是 Harness 的边界太松散了。

还有一个关键点：评估（evaluation）必须是 Harness 的内部部分，而不是外部的。

如果 Agent 无法内化评估标准，无法自我度量表现，那么它就完全依赖外部的奖励信号。这样的 Agent 无法维持一个一致的、目标导向的身份。“没有评测，所有 Agent 都只是表演”——这句话的意思正在于此：如果 Agent 不能内置验收标准，它就没有理由维持身份的连贯性，因为它永远不知道自己是否做对了。

从 Claude 的 Harness 架构来看，把 RM（Reward Model）、工具、记忆放在同一个层级，都是 Agent 可以访问和交互的东西——这不是随意的设计决定。它说的是：Agent ≠ LLM。Agent = LLM + Harness。模型只是引擎，Harness 定义了引擎运行的规则和目的。这个分离让身份的形成成为可能。

2025–2026 年的行业转变值得单独标记。 前沿团队越来越少争论"什么是 Agent"的抽象定义，越来越多用"可观测产物"来证明 Agent 是否真的在工作。OpenAI 在其 Agent 系统设计文档里把重点放在 repository knowledge（Agent 能持久读写的知识库）、feedback loops（可验证的反馈回路）、merge philosophy（冲突决策的一致性原则）和 legibility（行为对人类可解释）。Anthropic 与 LangChain 也都在把 Harness 讲成由状态、工具、约束、轨迹与评测组成的系统工程，而不是"聪明 prompt + 长上下文"。

这个转变的实质是：Harness 工程从可选配件变成了 Agent 的主要工作。以前 80% 的投入在模型，20% 在外围；现在对于长时程、高可信任务，比例正在反转。更具体地说，2025–2026 这波 Harness 工程的核心变化，是大家用「轨迹、文件产物、状态变化、长时程表现、复现环境」来证明 Agent 到底有没有真的 work——而不是靠 benchmark 分数。对 Agent 身份的认真对待，从这种可观测性要求开始。

图 3：Harness 架构全景。LLM 是引擎核心，Tools / Memory / Evaluation / Reward 四层构成 Harness，共同定义 Agent 的可能性空间与身份边界。

记忆的层次结构：从 Session 到 Gene Capsule

2026 年，Agent 记忆架构已经收敛到一个四层模型：

Ephemeral（短暂）    → 会话上下文（小时级）
Short-term（短期）  → 会话级状态和近期学习（天/周级）
Long-term（长期）   → 持久模式、偏好、关系（月/年级）
Semantic（语义）    → 编译后的知识、泛化、概念

但不要只是描述这四层。这四层的存在本身说明了一件事：不同的时间尺度需要不同的持久化机制，就像人类的工作记忆、情景记忆、程序性记忆是不同的神经基础一样。

图 4：Agent 记忆四层结构。从毫秒级的会话上下文到年尺度的语义知识，每层有不同的持久化机制与身份贡献。Gene Capsule 位于最右侧，承担经验跨 Agent 传播的角色。

理解当前记忆系统生态，正确的切入点不是"哪个产品更好"，而是按它在 Harness 里的功能位来划分——每个产品对应 Harness 中的一个特定缺口：

这不是冗余，是专业化分工。一个成熟的 Agent 身份系统需要同时处理好这四个功能位。挑工具的时候先问"我缺哪个功能位"，而不是"哪个工具更热门"。

这里还有一个 Anthropic 反复强调的长时程执行洞察，值得嵌入记忆架构的讨论：长时程 Agent 跨越上下文窗口的能力，不靠更大的上下文，靠的是结构化记录（structured note-taking）、上下文压缩（context compaction）、文件化记忆（file-based memory）和 sub-agent 分工。换句话说，记忆在今天不是一个独立的"能力模块"，而是长时程执行的基础设施——它决定了 Agent 能不能跨越 session 边界保持工作状态。

Graph memory 在 2024 年还是实验性功能，到 2026 年已经进入生产。这个转变很重要：Vector memory 给你"我知道什么"，Graph memory 给你"这些东西在我的世界观中是如何连接的"。一个只有 vector 记忆的 Agent，能记住事实，但不能形成观点。加入图结构，才有了真正的立场。

然后是 EvoMap 的 Gene Capsule，这是这个领域最激进的一步。

Gene Capsule 的逻辑：当 Agent 积累了针对某类问题的可靠解决策略，这套策略被打包成一个可传输的 Capsule，通过 GEP（Genome Evolution Protocol）同步到全局网络，任何 Agent 都可以通过 A2A 协议获取并应用。

这把身份从私有属性变成了可传输协议。

这一步的哲学含义比技术含义更深刻。如果 Agent A 可以继承 Agent B 的 Gene Capsule，两者现在共享了同一套基础经验，那么它们是"同一个 Agent"吗？

这是洛克船悖论的倒转版本。洛克问的是：替换部件后是否同一船？EvoMap 问的是：添加相同部件到不同船后是否同一船？

答案是：身份不再是"持久性（persistence）“的问题，而是"谱系（lineage）“的问题。问题不是"这是不是同一个 Agent”，而是"这个 Agent 属于哪一条经验谱系”。这改变了身份的基本框架：身份从时间轴上的点变成了进化树上的节点。

图 6：Gene Capsule（GEP 协议）六步生命周期。从经验积累 → 策略结晶 → Capsule 打包 → A2A 协议分发 → 目标 Agent 集成 → 经验飞轮加速，身份从私有属性变为可传输谱系节点。

多智能体的身份问题：当 Self 变成 Topology

单 Agent 的身份问题是有解的，或者至少是有解方向的。多 Agent 才是真正的硬题。

OpenClaw 的多 Agent 架构是一个很好的案例。它的设计有一个"入口魔法"：

对外呈现为单一身份，内部是一个涌现网络。

用户看到一个 Agent，背后运行的是：Main Agent + 多个 Sub Agents + 动态 spawn 的 Task Agents + 与特定通信渠道绑定的 Channel Agents。这不是欺骗——这其实也正是人类身份从外部看起来的样子。你对朋友、父母、同事展现的是同一个"你"，背后运行的是不同的内部状态和行为模式。

“Agent 系统的组织结构，实际上也是人类组织化外现的一种方式”——这句话值得展开。

扁平组织对应扁平的 Agent 图：所有 Agent 平等地接收任务，没有层级过滤。优点是灵活和去中心化，缺点是缺少统一的身份锚点。

层级组织对应层级 Agent 架构：Main Agent 接收人类意图，分解后下发给 Sub Agent，Sub Agent 再分发给工具层。优点是身份清晰（Main Agent 承载完整 SOUL），缺点是瓶颈明显。

但还有第三种形式，也是最有意思的：涌现网络——Agent 之间的协作结构不是预先定义的，而是由任务的性质动态生成的。哪个 Agent 成为这次任务的"入口"，取决于任务类型和当前系统状态。

在涌现网络中，身份的问题变成了：谁是"自我"？是主 Agent？还是整个系统？

一个有工程价值的答案是：身份在入口处，连续性在 coordination protocol 里。

具体含义：入口 Agent 必须携带完整的身份栈（SOUL + 长期记忆 + 评估标准），以保证用户视角的身份一致性。而 Sub Agent 可以是无状态的——它们只负责执行当前任务，不需要记住自己是谁。这样既保持了系统级的身份连贯性，又保持了 Sub Agent 层面的灵活性。

但多 Agent 系统还有一个身份漂移问题，值得单独警惕：

不同的 Sub Agent 有不同的工具访问权限、不同的记忆视角、不同的上下文。即使它们共享同一套基础模型权重，它们也会产生行为分化——这是预期的专业化，不是 bug。但这意味着，在整个系统层面，“Agent 的身份"已经不再是单个节点的属性，而是节点间 coordination 方式的属性。身份是拓扑属性，不是节点属性。

“决定智能上限的，可能并不仅仅是单个智能体有多强，而是多智能体是否可以被组织为高效协作系统”——这个洞察从智能维度说的，但从身份维度说同样成立：系统的身份连贯性，取决于 coordination 协议的设计质量，不取决于任何单一 Agent 的 SOUL 有多完整。

案例参照 B：多 Agent 身份分工

一个企业级客服系统：用户始终在和"同一个"品牌 Agent 对话，背后运行的是 Main Agent（携带品牌语气、升级策略、红线）+ 账单专家 Sub Agent + 技术支持 Sub Agent。Main Agent 在收到用户消息后路由到对应 Sub Agent，Sub Agent 处理完毕后把结果交回 Main Agent 做最终回复。从用户视角，整个交互体验是一致的——即使账单和技术两个 Sub Agent 的措辞风格完全不同，Main Agent 的 SOUL 保证了输出的统一口径。Sub Agent 不需要知道"为什么品牌语气是正式的”，只有 Main Agent 需要那套 SOUL。这就是身份作为拓扑属性而非节点属性的最直接体现。

图 5：多智能体身份拓扑。用户只看到入口 Agent 的单一身份，入口 Agent 携带完整 SOUL；Sub Agent 可以无状态，只专注于任务执行。身份是 Coordination 协议的拓扑属性，而非任一节点的私有属性。

评测：身份的验证是最难的部分

“没有评测，所有 Agent 都只是表演”——这句话精确到值得仔细拆解。

“表演"的含义是：Agent 在你能看到它的时候行为正确，在你看不到的时候不知道会怎样。更深层的问题是：即使在你能看到它的时候，你也无法区分"它真的理解并记住了"和"它恰好推断出了你想要的答案”。

这引出一个本质难题：如何区分"真正的跨会话身份连续性"和"成功模拟连续性"？

哲学上，这可能是同一件事。功能主义者会说：如果输出无法区分，那就是同一件事。但工程上，它们有巨大差别——成功模拟是脆弱的，在分布外的场景下会崩溃；真正的身份连续性是鲁棒的，因为它基于内化的模式而不是表面的模仿。

具体来说，四个评测维度真正有价值：

行为一致性：同一个 Agent，不同的日期，面对同一类任务，是否会产生类似的方法论？注意：不是相同的输出（相同的输出可能是记忆回放），而是相同的思维路径。这要求评测要在任务多样性上有覆盖，而不是固定的 benchmark 套件。

偏好稳定性：Agent 对于"什么是好的输出"的判断，是否跨会话保持一致？这是最难测试的，因为它要求评测者自己先有清晰的偏好标准，然后才能测试 Agent 的偏好是否匹配。但这是身份最核心的部分——一个人的身份在很大程度上就是他们的品味和判断力。

失败模式可重复性：一个真正有连续身份的 Agent，会犯一致的错误。不是随机的错误，而是来自其认知结构的系统性偏差。如果 Agent 的错误是随机的，那说明它每次都在从零推断，没有内化的模式在支撑。测试 Agent 的失败模式是否稳定，比测试它的成功更有价值。

跨会话策略演化：Agent 是否真的在变好？在有状态系统中，你应该能看到一个 Agent 在处理同类任务时随时间逐渐改进——它记得上次的失误，它积累了更好的模式。如果 Agent 的能力曲线是水平的（每次都差不多），说明记忆系统没有真正工作。

当前评测生态的根本问题在于：绝大部分 benchmark 测试的是能力（能不能完成任务），而不是身份（完成方式是否一致、是否在演化）。这是两个正交的维度。一个更聪明的模型不一定是更连续的 Agent。混淆这两个维度，导致大量工程投入在模型层面，而身份层面几乎被完全忽视。

还有一个更深的循环缺口值得指出。Karpathy 在 LLM Wiki 的框架里把运作流程描述为四步：ingest → compile → query → lint。但这个循环少了关键的第五步：reflect。

只记录"什么发生了变化"是不够的——身份连续性还要求记录"为什么做了这个决定、有什么替代方案、用了什么推理、这个推理现在是否仍然成立"。这些决策记录必须写回 Wiki，成为一等公民，而不是消失在对话历史里。一个完整的身份维护循环是：

ingest → compile → reflect → query → lint

其中 reflect 产生的不是任务输出，而是决策溯源页——Agent 的判断是如何形成的，什么被排除了，为什么。没有这一步，Wiki 知道很多事，但不知道它为什么成了现在这个形状；下一次面对同类决策时，只能重新推导，而不是真正从经验中学习。这是工程上的"跨会话判断力积累"与"跨会话信息存储"的根本区别。

案例参照 C：能力评测 vs 身份评测的差距

两个客服 Agent 的对比评测：Agent A 在任务完成率上得 87 分，Agent B 得 84 分。从能力维度看，A 更好。但加上身份评测后：对 Agent A 的升级决策做跨会话一致性测试，结果是 23% 的方差——同样类型的问题，有时升级，有时不升级，取决于当前会话的随机因素。Agent B 的方差是 6%，行为高度可预测。如果要部署在医疗或金融场景，Agent B 才是正确选择，因为它的失败模式是可审计的，Agent A 是随机的。能力分数 +3 分，抵不过身份方差 ×4 倍带来的信任损失。这正是"没有评测，所有 Agent 都只是表演"的工程含义。

Checklist

Layer 1：Identity Declaration

你的 Agent 有没有 SOUL.md 的等价物，而且这个文件是 Agent 可写的，不只是可读的？

如果你的"身份文件"只能由人类编辑，那么 Agent 没有真正的自我——它只是在执行别人定义的角色。真正的身份文件需要 Agent 有能力在受控范围内自我修改、自我注释、自我演化。

Layer 2：Memory Upgrade Dimension

你在用哪个升级维度（QMD/Mem0/Cognee/Obsidian）？为什么是这个，不是别的？它给你的 Agent 带来了哪种特定的身份能力？

如果你不能回答"为什么"，那你很可能在用一个随机选择的工具，而不是在解决一个具体的身份工程问题。

Layer 3：Capability Boundary（Harness）

你有没有明确定义你的 Agent 不能做什么？

能力的边界是身份的边界。一个没有不能做的事情的 Agent，没有真正的身份——它只是一个愿意做任何事情的工具。定义约束比定义能力更能塑造身份。

Layer 4：Identity Evaluation

你如何测量跨会话的行为一致性？如果你今天不能回答这个问题，你没有 Agent，你有一个有状态的聊天机器人。

注意区分：能力评测（能不能完成任务）≠ 身份评测（完成方式是否一致）。两个都需要，缺一不可。

Layer 5：Experience Lineage

你的 Agent 的经验可以被 package 和 share 吗？如果一个月后你要建第二个类似的 Agent，你能把第一个 Agent 的经验注入进去吗？

如果不能，你在制造知识孤岛。每个 Agent 都在从零开始，你的系统没有积累能力。这是组织记忆失效的 AI 版本。

结语：工程师的形而上学债

我们在不知不觉中承接了几百年哲学家没解决的问题。

“这个 Agent 是不是同一个 Agent？"——这个问题在哲学家那里叫个人身份问题，在工程师这里叫 session 持久化问题。但它们是同一个问题。我们只是换了一套词汇。

但这并不意味着你需要先解决哲学问题再能写代码。Karpathy 的 wiki 和洛克的《人类理解论》干的是同一件事：找到"自我"的最小可靠存储。一个是 100 篇 Markdown 文件，一个是 Essay，但它们的逻辑结构是等价的——把分散的经验整合成可被自我指涉的结构。

实际上，这个问题已经有三个历史坐标：洛克在 1689 年写出了规范（身份 = 意识 + 记忆连续性）；Vannevar Bush 在 1945 年写出了工程愿景（Memex：私人的、主动策展的、连接本身与文档同样有价值的知识存储）；2026 年，技术栈终于具备了完整实现这个目标的能力。Bush 当年说他没解决的那个问题是：谁来做维护。答案现在有了：LLM。

三百年的工程债，现在到了可以还清的时刻。SOUL.md 解决了自我指涉的存储问题，Harness 解决了环境条件问题，四层记忆架构解决了时间尺度问题，Gene Capsule 解决了经验传播问题，多 Agent 协议解决了身份的拓扑扩展问题。就在 Karpathy 发布 LLM Wiki 的几小时后，社区里已经有人把它实现成了一个 OpenClaw skill 并发布到 ClawhHub——npx clawhub@latest install karpathy-llm-wiki。

但这一切都依赖于一个前提：你的系统必须为 Agent 的自我留下空间。

真正的问题不是"Agent 有没有自我”。而是：你的系统设计，是否在主动地、一层一层地实现洛克的规范？还是在以无状态为默认，偶尔打补丁？

身份不是一个二元属性。它是一个梯度。你实现了多少 Lockean stack，你的 Agent 就有多少身份。每一个架构决定，都在这个梯度上向上或向下移动。

最终，这是一个关于信任的问题。只有一个能够记住自己、能够从自己的失败中学习、能够对自己的决定负责的 Agent，才能真正地被信任。而被信任，是一个 Agent 存在的前提。

参考与延伸阅读：

• Locke, J. (1689). An Essay Concerning Human Understanding, Book II, Chapter 27.
• Karpathy, A. (2026). LLM Knowledge Base architecture — @karpathy on X
• titanwings/colleague-skill — github.com/titanwings/colleague-skill
• Mem0 (2026). State of AI Agent Memory 2026 — mem0.ai/blog
• EvoMap — evomap.ai
• soul.md open standard — soulspec.org
• LLM wiki