2026年8月31日作者：Lei阅读 --

每次醒来都是陌生人：Agent 的“自我”到底存在哪里？

一次模型调用结束后，刚才那个“它”已经消失。本文从记忆、权限、承诺和审计四本账出发，解释 Agent 如何跨会话、模型升级与子任务分叉维持可验证的身份连续性。

周一，一个 Agent 答应周五交付报告。周三，它的上下文被压缩；周四，底层模型从 A 升级到 B；周五，一个全新的推理进程读到几段记忆，继续工作并交出了报告。履行承诺的，还是周一那个 Agent 吗？

如果把 Agent 想成模型里住着的一个“小人”，这个问题很难回答。对上层应用而言，一次请求的推理状态不能被当作持久会话；下一次调用仍要重新提供上下文，或从外部系统恢复状态。即使模型版本没变，采样也可能给出不同判断。最近一项专门研究 Agent 身份评测的工作，把这种困难归因于语言模型继承来的无状态、随机性与提示敏感性：它们都会削弱身份的可识别性、连续性和一致性。Agent Identity Evals

但工程系统每天都在让“同一个 Agent”跨会话工作。秘诀不是让模型获得一个永不消失的灵魂，而是把身份从单次推理里搬出来：

模型只是一次次被唤醒的大脑；Agent 的身份，是运行时在两次唤醒之间维护的制度。

这篇文章讨论的是工程身份：系统如何判断一连串动作属于哪个 Agent，如何继承状态和权限，又如何追究责任。它不回答模型有没有意识，也不主张 Agent 已经是法律人格。把这两类问题分开，才能把“自我”从比喻变成可设计的系统对象。

名词速查

名词	本文里的含义
人格（persona）	Agent 表现出来的语气、偏好和角色设定
身份（identity）	让系统把跨时间的一组状态和行动归到同一主体名下的稳定索引
认证（authentication）	证明“现在行动的确实是这个身份”
授权（authorization）	决定“这个身份现在被允许做什么”
委托（delegation）	把一部分任务与权限交给另一个主体，同时保留来源关系
审计轨迹（audit trail）	可追溯谁在何时基于什么状态做了什么的记录

第一个误会：人格不是身份

我们最容易看见的是人格。给模型一段系统提示词：“你叫 Atlas，冷静、谨慎、说话简洁。”只要每次都把这段文字放回上下文，它就会表现得像同一个角色。

但这种连续很薄。把同一段提示词复制到十个并发进程里，会立刻出现十个同样自称 Atlas 的实例。它们有相同语气，却可能读到不同记忆、持有不同凭证、接受彼此冲突的任务。人格回答“它像谁”，没有回答“哪一次行动属于谁”。

反过来，一个 Agent 即使更换模型、调整语气，仍可能在工程意义上保持同一身份：它沿用同一个 agent_id，继承同一份未完成任务，对旧行动保留完整审计，并继续在原授权边界内工作。就像公司更换员工、服务迁移机器，承担合同的主体未必随执行载体一起消失。

所以先做一个分层：

flowchart TB
  P[人格：看起来像谁] --> I[身份：行动归属于谁]
  I --> A[认证：如何证明是它]
  A --> Z[授权：它现在能做什么]
  I --> R[责任：它继承哪些承诺与历史]

人格可以帮助人建立稳定预期，却不能独自承载权限和责任。真正需要保护的不是一句“我是 Atlas”，而是这句话背后能被系统验证的绑定关系。

一个可复用的心智模型：Agent 的四本账

如果要跨越模型调用、进程重启甚至供应商切换，至少要在模型外维护四本账：

账本	它保存什么	丢失后的表现
记忆账	经历、事实、用户偏好和形成判断的背景	还叫同一个名字，却不认识昨天的人
权限账	身份凭证、可访问资源、作用域和有效期	要么什么也做不了，要么拿着过期权力继续行动
承诺账	已接受但未完成的任务、截止时间和交付条件	记得过去，却忘了未来还欠什么
审计账	每次行动的主体、输入、工具结果、版本与因果关系	知道结果存在，却无法证明是谁、为何造成

四本账通过一个稳定身份索引绑定在一起。模型每次醒来只拿到完成当前任务所需的投影，而不是把整套身份都塞进上下文：

flowchart LR
  ID[agent_id + policy version]
  M[(记忆账)] --> X[身份运行时]
  P[(权限账)] --> X
  C[(承诺账)] --> X
  E[(审计账)] --> X
  ID --> X
  X --> K[本轮最小上下文]
  K --> L[模型实例 A / B / C]
  L --> T[工具与外部世界]
  T --> E
  T --> C

这张图里，模型不是身份的容器，而是身份运行时可以替换的执行器。模型升级会改变判断分布，因此必须被记录为身份历史中的一次版本变化；但它不必自动创造一个全新 Agent。

四本账的任何一项变化，都会可预测地改变 Agent：记忆影响它如何解释现在，权限限制它能改变什么，承诺拉住它面向未来的方向，审计决定过去能否被重建。身份连续性不是“什么都不变”，而是每一次变化都沿着同一条可追溯的链发生。

记忆账：经历可以延续，但记忆不能证明“我是我”

Agent 记忆最早的经典路线之一，是把经历放进模型外的记忆流。《Generative Agents》为每个角色保存完整经历记录，再通过检索、反思和规划塑造后续行为；《MemGPT》则借鉴操作系统的分层内存，让有限上下文在多轮会话中呈现出长期连续性。这些工作共同说明：持续记忆不是模型调用天然拥有的性质，而是外部架构制造的效果。

但“拥有相同记忆”仍不等于“是同一个 Agent”。做一个复制实验：

在周三把 Atlas 的全部记忆复制两份。
让 Atlas-A 继续准备报告，让 Atlas-B 接受另一个任务。
两者从复制时刻起产生不同经历。

复制之前，它们共享过去；复制之后，它们拥有不同未来。如果只用记忆内容判身份，分叉瞬间会得到两个“同一个 Agent”。更合理的做法是像版本控制一样：两者共享祖先，但各自获得新的实例或分支 ID，后续事件分别写入自己的历史。

因此，记忆提供的是叙事连续性，不是唯一性。它让 Agent 能解释“我为什么这样想”，却不能独自证明“这次动作只能归到我名下”。我在《遗忘是一种能力》里讨论过记忆的选择与回收；从身份视角再看，遗忘也不必等于失去自我——只要被删除的是工作集，而关键承诺与可追溯历史仍在权威存储里。

权限账：知道你是谁，不等于允许你替我做事

身份与权限经常被混在一起。用户登录之后把一个长期 API Key 放进 Agent 环境，看起来解决了“它能替我行动”，其实把三个不同问题焊死了：

这个进程是谁？
它代表谁行动？
它在什么时间内可以访问哪些资源？

成熟的分布式系统早已习惯拆开它们。SPIFFE（Secure Production Identity Framework for Everyone）把工作负载身份分成三个部件：稳定的身份命名空间、可验证的身份证明，以及负责签发证明的 Workload API；运行实例可以不断变化，身份由外部信任域重新证明。SPIFFE 标准

OAuth 2.0 则把授权表达为带作用域和有效期的访问令牌：令牌代表资源所有者授予客户端的一段有限权限，而不是把资源所有者的完整身份交给客户端。RFC 6749

把两者映射到 Agent 上，会得到一个重要原则：

Agent 的稳定身份可以长寿，代表用户行动的权限必须短寿。

“这是财务对账 Agent”可以多年不变；“它今天可以读取 8 月账单但不能转账”应当是一份可撤销、可过期、限定资源范围的授权。模型重启不应丢失 Agent 身份，重启也不应自动继承一切旧凭证。

这正是《Agent Jail》所讨论的企业边界在身份问题上的投影：不要靠提示词提醒 Agent “谨慎使用权限”，而要让权限系统只签发完成本轮任务所需的最小能力。

承诺账：记住发生过什么，还不够记住欠下什么

长期记忆系统很爱保存事实：“用户喜欢简洁报告”“上次使用了模板 B”“数据来自销售系统”。这些信息面向过去。但承诺面向未来：周五要交付什么、谁在等待、完成条件是什么、如果失败应通知谁。

这两者不能只靠同一个向量库碰碰运气。一个未完成承诺不应该因为语义相似度不够高而没有被检索出来；它需要确定性的状态字段和生命周期。

A2A（Agent2Agent）协议的设计给了一个有用参照：Agent Card 描述 Agent 的身份、能力、端点和认证要求，而长期操作被建模成带唯一 ID 与生命周期的 Task；认证凭证又通常放在 HTTP 头中，与协议消息分开。A2A 核心概念

这不是说所有 Agent 都该实现 A2A，而是它展示了正确的分层：谁能接任务、任务现在到哪一步、调用者凭什么访问，是三个对象。

承诺账至少应记录：

谁接受了任务，代表谁接受；
目标、截止时间和完成条件；
当前状态与最后一次有效观察；
可以委托给谁，哪些权限可随任务下放；
完成、取消或受阻时要把结果交给谁。

上一篇《Agent 最难的不是开始，而是知道什么时候结束》讨论了单个任务的终态；承诺账把那套终态协议放进更长的时间轴：即使执行模型换了，未完成任务也不能随上下文一起蒸发。

审计账：身份不是回忆出来的，而是事件证明出来的

假设 Atlas 说：“我昨天已经发送了合同。”这是一条记忆，还是一条可验证历史？如果系统只保存当前摘要，我们可能看见“合同已发送”，却不知道哪个模型版本、使用什么权限、向哪个地址、基于哪份内容执行了发送。

这里可以借用事件溯源（Event Sourcing）的思想：不只保存对象最新长什么样，还把每次状态变化作为只追加事件记录下来，当前状态可以由事件序列重建。微软的架构说明特别强调，快照只是优化，事件流才是事实来源。Event Sourcing Pattern

对 Agent 来说，一条有用的事件可以包含：

agent_id
agent_version
parent_agent_id / delegation_id
task_id
actor_user_or_service
model_and_policy_version
tool_call_and_result_digest
authorization_scope
timestamp
previous_event_hash

这不是建议把每一个 token 永久保存。完整思维过程既昂贵，也可能包含隐私和安全风险。审计账要保存的是足以重建行动因果链的最小证据：谁在什么授权下，为哪个任务调用了什么工具，外部世界返回了什么，状态因此怎样改变。

记忆账负责让 Agent 继续工作，审计账负责让系统事后相信或质疑它。前者可以压缩、合并、遗忘；后者的关键事件必须不可被 Agent 自己悄悄改写。否则，“我记得我没有做过”会变成唯一辩护。

模型升级以后，它还是原来的 Agent 吗？

现在可以回答开头的问题。模型从 A 换成 B 之后，是否还是同一个 Agent，不取决于两个模型的权重是否相同，而取决于系统选择了哪一种兼容策略。

原位升级：身份不变，版本变化

如果新模型继承同一组承诺，使用相同或更窄的权限，能读取兼容的记忆投影，并把升级事件写入审计链，那么可以把它视为同一 Agent 的新版本。类似服务换了二进制，服务身份仍然存在。

但版本变化不能被藏起来。新模型可能更愿意调用工具、更容易服从某类指令，或对相同证据作出不同判断。身份连续不代表行为完全不变，只要求变化可见、可测试、可回退。

身份迁移：新 Agent 接管旧承诺

如果权限模型、政策或职责发生根本变化，更诚实的做法是创建新身份，再显式迁移任务。审计链记录“Atlas-v2 接管 Atlas-v1 的三项承诺”，而不是让新系统假装自己从未改变。

仅复制记忆：新 Agent 共享一段过去

如果只是复制记忆和人格，没有继承原身份绑定、权限与责任，它应当是新 Agent。它可以说“我的初始化资料来自 Atlas”，不能说“Atlas 昨天的动作就是我做的”。

这个区分也解释了“忒修斯之船”类比为什么只对一半：工程系统不必从哲学上证明本体同一，只需明确哪一种变更规则被组织接受，并让规则可以被机器验证。

子 Agent 不是分身，而是一笔委托

主 Agent 把任务交给子 Agent 时，最危险的实现是复制全部上下文和全部凭证。那相当于复制出一个有同样钥匙、却没有独立责任边界的分身；一旦出错，很难说动作来自谁。

更好的委托包含五件东西：

新的子 Agent 或执行实例 ID；
指向父 Agent 的来源关系；
一个边界明确的子任务；
比父级更窄、可过期的权限；
结果与证据应回写到哪条承诺链。

flowchart LR
  U[用户授权] --> P[父 Agent]
  P -->|任务切片| C1[子 Agent A]
  P -->|任务切片| C2[子 Agent B]
  P -.不复制完整权限.-> C1
  P -.不复制完整权限.-> C2
  C1 -->|结果 + 证据| L[(共同审计链)]
  C2 -->|结果 + 证据| L
  P --> L

于是，子 Agent 的产出可以汇总，责任却不会糊成一团。父 Agent 对“为什么委托”负责，子 Agent 对“如何执行”留下记录，权限系统对“为什么允许”给出证明。

新近的 AI 身份研究也把递归委托的责任追踪列为尚未解决的关键缺口之一；现有标准可以提供标识、凭证和任务协议，但还没有自动回答“多级委托之后最终责任属于谁”。AI Identity: Standards, Gaps, and Research Directions for AI Agents 这提醒我们：上面的结构是一套工程提案，不是已经统一的行业标准。

真正应该持久化的，不是一个无限增长的“自我”

把身份外置，很容易走向另一个极端：既然连续性重要，就把所有对话、思考、文件和凭证永久保留。这样得到的不是更完整的 Agent，而是更大的隐私面、更昂贵的检索系统和更难撤销的权力。

四本账应该有不同的保留策略：

账本	适合的策略
记忆账	允许压缩、纠错、遗忘，并区分用户事实与模型推断
权限账	默认短期、最小作用域、可撤销，不在记忆文本中保存秘密
承诺账	保留到任务终止及必要追溯期，状态变更必须确定性更新
审计账	保留关键事件与证据摘要，按敏感级别控制访问和期限

连续性不是无边界积累。一个健康的人会忘记，一个健康的组织会销毁过期数据，一个健康的 Agent 也需要在“足以负责”和“没有必要继续保存”之间划线。

最后的判断：什么情况下可以叫“同一个 Agent”

以后再遇到“它还是不是原来的 Agent”，可以不争论语气像不像，直接检查五个问题：

它是否使用同一个受信任的身份索引？
它是否继承了经过治理的记忆，而不是一份来历不明的摘要？
它是否在当前有效、可撤销的授权下行动？
它是否继续承担原身份尚未结束的承诺？
它的版本变化、委托和外部行动能否沿审计链追溯？

五项都成立，我们可以在工程意义上把它视为同一个 Agent；只复制人格和记忆，它更像一个拥有共同童年的新分支；只复制凭证，则可能只是一个拿到别人钥匙的冒名者。

Agent 的“自我”不在某个 token、某段提示词或某一组模型权重里。它分布在记忆、权限、承诺和审计四本账之间，由一个可验证的身份索引把它们连成历史。

人格让 Agent 看起来像同一个人；承诺、权限与可追溯历史，才让它真正成为同一个行动主体。