---
title: 'Agent 的自我：从洛克到 OpenClaw'
date: 2026-04-05T20:00:00+08:00
draft: false
showtoc: true
tocopen: true
type: posts
author: ["Xinwei Xiong", "Me"]
keywords: ["AI Agent", "身份连续性", "记忆架构", "SOUL.md", "Harness", "OpenClaw", "EvoMap", "多智能体", "洛克", "个人身份"]
tags:
  - AI
  - Open Source
  - Monthly Notes
categories:
  - AI & Technology
cover:
  image: /images/agent-identity/01-locke-spec.svg
  alt: "Locke Identity Spec — Agent Identity Engineering Stack"
description: >
  AI Agent 的失忆不是功能缺陷，是信任账户的根本缺失。本文从洛克 1689 年的身份理论出发，逐层拆解 2026 年 Agent 身份连续性的完整工程栈：文件即身份（SOUL.md 范式）、Harness 作为环境条件、记忆的四层结构与 Gene Capsule 协议、多智能体拓扑中的自我定位，以及评测作为身份验证的终极难题。
  适合正在构建或设计 AI Agent 系统的从业者，以及对 AI 自主性边界有深度思考需求的研究者。
tldr:
  - "身份不是物质特征而是跨上下文窗口的持久自我指涉能力，当前AI Agent无持久记忆、无连续性验证，三百年前洛克已给出工程规范。"
  - "文件系统比数据库更适合身份存储，SOUL.md体系提供可读性、版本控制、人工干预的透明度，使Agent能够记住自己、学会判断力、承担责任。"
  - "Agent身份由文件层(价值观)、Harness层(权限边界)、记忆层(四重结构)、多Agent拓扑(协议设计)和评测层(行为一致性)五维共同构成，缺失任一维度则身份坍塌。"
---

# 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 这是致命的。

![洛克身份规范三条工程条款](/images/agent-identity/01-locke-spec.svg)
*图 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]
```

![SOUL 文件体系结构](/images/agent-identity/02-soul-files.svg)
*图 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 身份的认真对待，从这种可观测性要求开始。**

![Harness 架构：Agent = LLM + Harness](/images/agent-identity/03-harness-arch.svg)
*图 3：Harness 架构全景。LLM 是引擎核心，Tools / Memory / Evaluation / Reward 四层构成 Harness，共同定义 Agent 的可能性空间与身份边界。*

---

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

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

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

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

![记忆四层架构](/images/agent-identity/04-memory-layers.svg)
*图 4：Agent 记忆四层结构。从毫秒级的会话上下文到年尺度的语义知识，每层有不同的持久化机制与身份贡献。Gene Capsule 位于最右侧，承担经验跨 Agent 传播的角色。*

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

| 功能位 | 在 Harness 里解决什么 | 代表实现 | 对身份的贡献 |
|--------|----------------------|----------|--------------|
| **Read path 优化** | 从记忆库精确检索相关上下文 | QMD（BM25 + vector + reranking） | 更精确地"回忆自己" |
| **Write path 自动化** | 将会话产物自动结构化写入记忆 | Mem0 | 更流畅地"积累自己" |
| **Memory 表示层** | 以图结构暴露记忆间语义关系 | Cognee | 更结构化地"理解自己" |
| **人类治理层** | 让人类可见、可编辑、可干预 | Obsidian + 文件系统 | 让人类参与"定义自己" |

这不是冗余，是专业化分工。一个成熟的 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 属于哪一条经验谱系"。这改变了身份的基本框架：身份从时间轴上的点变成了进化树上的节点。

![Gene Capsule 生命周期](/images/agent-identity/06-gene-capsule.svg)
*图 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。这就是身份作为拓扑属性而非节点属性的最直接体现。

---

![多智能体身份拓扑](/images/agent-identity/05-multi-agent-topology.svg)
*图 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](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)*
