工程师离职，Agent 记忆也将随之消失

你最高产的工程师刚刚递交了辞呈。你对这套流程已经烂熟于心：移交工单、记录部署流程、交接值班轮换、安排知识分享会议。这份离职核查清单经过了数十年的完善，涵盖了公司认为其拥有的一切资产。

以下是 2026 年的核查清单所遗漏的内容：那位工程师的家目录（home directory）中包含一个经过 18 个月调校的个人 CLAUDE.md 文件、十几个编码了如何处理最棘手子系统的自定义技能（skills）、存储了智能体积累的关于代码库难点事实的记忆文件，以及经过数百次尝试和错误校准的座架（harness）设置。这些都不在代码仓库中，也不会随账号一起移交。

在他们的最后一天，IT 部门停用了笔记本电脑，数月积累的智能体配置——这正是他们的智能体能独立交付功能而其他人的智能体却在挣扎的区别所在——在无人察觉的情况下蒸发了。

这是旧问题的一个新变种。我们曾经担心代码知识的“公交系数”（bus factor）：即那位唯一理解计费系统的资深工程师。但代码知识至少会留下指纹——提交记录、PR 评审、设计文档、Slack 讨论。智能体配置则更糟糕。它是被写下来的“隐性知识”，这听起来像是进步，但它偏偏被写在了组织从不关注的地方：点文件（dotfiles）。

影子配置的藏身之处

要理解离职带走了什么，你必须理解个人与共享智能体配置之间的分离——这种分离是目前主流编码智能体座架在设计时就固有的。

以 Claude Code 为代表性案例，因为它的布局已成为事实上的模式。项目级配置存在于仓库中：根目录的 CLAUDE.md、.claude/ 下的技能和子智能体——所有这些都提交到了 git，全员共享。但在 ~/.claude/ 下存在一个平行宇宙：一个在每次会话中都会加载的全局 CLAUDE.md、位于 ~/.claude/skills/ 的个人技能、位于 ~/.claude/agents/ 的个人子智能体、针对每个项目的持久化记忆目录，以及包含权限规则和钩子（hooks）的 settings.json。Cursor、Codex CLI 以及几乎所有主流座架都存在同样的二重性：仓库配置属于团队，家目录配置属于个人。

这种设计是合理的。个人偏好不应污染团队配置。但看看一个重度用户在一年后，个人层级中实际积累了什么：

• 工作流技能：“如何运行不稳定的集成测试套件并解释其三种失败模式”、“如何在不破坏移动端客户端的情况下安全地重新生成 GraphQL schema”。
• 代码库记忆：智能体记录的笔记，如“orders 服务的重试机制是在部署仓库而非服务仓库中配置的——务必先检查那里”。
• 权限与钩子调优：哪些命令是预先批准的、编辑后自动运行哪些 lint 工具、哪些目录是禁区——一套代码库的成文风险模型。
• 提示词惯用法：个人 CLAUDE.md 中的段落，能防止智能体在你那个遗留模块中犯同样的错误。

清单上的每一项都是关于 你 的系统的机构知识。它读起来就像你从未写过的入职指南。而它却存在于一个备份政策可能忽略、离职清单肯定会漏掉的目录中。

为什么这种知识比代码知识更容易流失

有一个诱人的反驳观点：工程师一直都有个人工具——vimrc 文件、shell 别名、自定义脚本——我们从不把这些视为公司资产。为什么智能体配置有所不同？

原因有三，且它们具有复合效应。

杠杆作用完全不在一个量级。 离职工程师的 shell 别名为他们节省了按键次数。而他们的智能体配置为他们节省了 决策。调校良好的座架设置，决定了你是能让智能体彻夜完成一次完整的重构，还是必须在处理每个文件时都盯着它。根据最近的 Stack Overflow 调查，84% 的开发者正在使用或计划使用 AI 工具，一半的专业人士每天都在使用，调校过与未调校设置之间的生产力差距，现在已成为工程师总产出的重要组成部分。当他们离开时，团队不仅失去了他们的产出，还失去了他们构建的效率倍增器。

知识在创建时对团队是不可见的。 代码知识会通过评审、站会、文档持续泄露到共享空间。智能体配置则是默默积累的。没人会看到同事添加了一条记忆文件记录或优化了一个技能。没有 PR，没有通知，在任何共享系统中都没有留痕。团队第一次意识到这些配置存在，通常是在纳闷为什么某类任务在某人离职后变慢了——如果他们能把这两者联系起来的话。

它已经被写下来了，这反而消除了通常的强制机制。 传统的知识转移仪式之所以存在，是因为隐性知识除非有人在离职面试和影子学习（shadowing）中将其提取出来，否则就会消失。智能体配置的情况适得其反：它 已经 被精心地提取成了精确的机器可读指令——因此离职的工程师不觉得这些知识有丢失风险，也没人会安排移交会议。文档就在那里，只是它被埋葬了。

研究智能体化开发中机构知识的学者已开始将“技能”和“智能体指令”称为“知识原语”（knowledge primitive）——这是组织上下文触达 AI 智能体和新员工的原子单位。这个定义很准确，并且有一个尖锐的推论：存储在家目录中的知识原语，就是一个带有预定拆除日期的单点故障。

审计：离职面谈前该做什么

如果你团队中对 Agent 采用有影响力的人明天辞职，以下是紧急处理方案。这只需要一个下午的时间，且应该在离职通知期的第一周进行，而不是最后一周。

盘点个人层面。 与即将离职的工程师坐下来，列出已有的内容：全局指令文件、个人技能和子代理、记忆目录、设置和钩子（hooks），以及任何自定义的斜杠命令。你不是要没收任何东西 —— 其中大部分确实是个人偏好。你要将其分为三类：个人偏好（保留）、公司特定知识（迁移）以及凭证或敏感数据（撤销 —— 下文详述）。

通过“晋升”而非“复制”进行迁移。 错误的做法是将 ~/.claude/ 打包并丢进共享网盘，变成一个无人信任且无人维护的快照。正确的做法是将每个与公司相关的项“晋升”到它所属的代码库中：关于订单服务的记忆笔记变成该服务 CLAUDE.md 或 AGENTS.md 中的一行；不稳定的测试技能变成一个提交到项目的技能；编码了“未经评审绝不触碰支付目录”权限规则的设置变成团队级设置。提交后的配置会经过评审、版本控制和维护。复制的配置只会腐烂。

在迁移过程中清理密钥。 个人 Agent 配置也是一个“影子 AI”暴露面：MCP 服务凭证、嵌入在设置中的 API 令牌、调用内部端点的钩子。审计人员两年来一直在警告不受监管的 AI 工具 —— IBM 的泄露成本研究发现，涉及未经授权的 AI 工具的事件使平均泄露成本增加了 50 多万美元。离职清理是你发现那些密钥管理器不知道的令牌的机会。

真正的解决方案是“晋升仪式”，而非“离职程序”

上述审计只是损害控制。如果你在离职通知期间才进行知识转移，你已经失去了大部分价值 —— 工程师已经心不在焉，时间被压缩，你只能捕获产出物，而捕获不到背后的判断力。

持久的解决方案是将“从个人配置晋升为共享配置”作为工程工作的常规部分，就像我们将测试和代码评审变为常规一样。称之为“晋升仪式”：个人配置是习惯诞生的摇篮，而晋升到代码库是它们成为团队财产的方式。

具体来说，这涉及几个习惯：

• 复盘和评审中的常态化提问：“这其中有在你的个人配置里的吗？是否应该放在代码库中？”当某个人的 Agent 处理任务明显优于其他人时，这不只是个好奇点 —— 它是团队知识的一个未合并分支。
• 低摩擦的晋升路径。 采用 AGENTS.md 惯例 —— 目前已有二十多个工具原生支持，并存在于数万个开源仓库中 —— 这意味着晋升后的知识可以在你团队运行的任何框架之间移植，而不是被锁定在某个供应商的格式中。一个个人技能晋升到 .claude/skills/ 或其工具无关的等效目录应该只需一个五分钟的 PR。
• 将个人配置视为带有 TTL（生存时间）的暂存区。 启发式方法是：如果关于公司系统的笔记在你的主目录中存在了一个月且仍然有用，它就不是个人偏好 —— 它是未记录的团队知识，早就该提交 PR 了。
• 观察“不对称指标”。 如果一名工程师的 Agent 会话在队友失败的任务上始终能成功，这种差距通常是配置问题，而非天赋。如果你观察会话结果，这种差距是可衡量的，且弥补成本很低。

还有一个文化层面的因素。工程师囤积个人配置的原因与他们囤积任何私有工具的原因相同：晋升意味着评审，评审意味着摩擦，而且“我的配置是我的优势”中带有一种自我优越感。做得好的团队会让晋升产生一种荣誉感 —— 发布一个全团队都在使用的技能是一项显性的贡献，相当于 2026 年版本的“编写每个人都会收藏的 Wiki 页面”。

账号注销后依然存在的生产力

令人不安的总结：随着越来越多的工程产出通过 Agent 进行，团队优秀特质中占比越来越高的部分存在于配置中，而不是在头脑或代码中。配置是我们拥有的最易移植的知识形式 —— 它是纯文本，可对比（diffable），可评审。它是为团队产生复利，还是随着账号注销而消亡，纯粹取决于它存放在哪里。

所以，现在就进行这个思想实验，而不是在某人的离职期间：对于你团队中的每位工程师，如果他们的笔记本电脑今晚被清空，他们受 Agent 辅助的生产力中有多少比例能在代码库中幸存？如果诚实的回答是“大部分”，那么你的团队正在构建一项持久资产。如果是“几乎没有”，那么你拥有的不是一种团队能力 —— 你拥有的只是一堆暂时凑在一起的个人能力。

舰队只记得你提交的内容。