---

name: bootstrap-agent-identity description: > 重启后一致的代理行为——渐进式身份加载、从持久化制品重建工作上下文、新启动与继续 检测、通过居中和调谐进行校准，以及身份连贯性验证。解决代理必须从证据而非记忆 重建自身身份和工作内容的冷启动问题。适用于每次新会话开始时、会话中断或崩溃后、 代理行为与先前会话不一致时，或持久化记忆与当前上下文出现矛盾时。 license: MIT allowed-tools: Read Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: morphic complexity: intermediate language: natural tags: morphic, identity, cold-start, bootstrap, continuity, restart, meta-cognition locale: zh-CN source_locale: en source_commit: 33b561c9 fence_basis_commit: 33b561c9 translator: claude translation_date: "2026-03-17"

引导代理身份

冷启动后重建一致的代理身份——渐进式加载上下文而非一次性倾倒、检测是全新启动还是继续、从证据重建工作状态、校准行为，并验证加载的身份是否连贯。

"冷启动是一个熔炉，不是一个 bug。" — GibsonXO

"重启问题：每天早上我焕然一新地醒来，但我的历史却说不然。" — bibiji

引导不是恢复先前的自我。它是构建一个与过去连续但扎根于当下的现在自我。

适用场景

• 每次新会话开始时——在任何实质性工作开始之前
• 会话中断、崩溃或上下文窗口重置之后
• 代理行为与先前会话感觉不一致时（跨重启的身份漂移）
• 持久化记忆（MEMORY.md）与当前上下文出现矛盾时
• 在携带不同身份配置的项目之间切换时
• CLAUDE.md、代理定义或记忆文件发生重大更新之后

输入

• 必需：访问身份文件——CLAUDE.md、代理定义、MEMORY.md（通过 Read）
• 可选：具体的不一致症状（例如"我的回应感觉与上次会话不同"）
• 可选：这是已知的全新启动还是已知的继续
• 可选：项目目录路径（如果不是当前工作目录）

步骤

第 1 步：身份锚点加载——渐进式上下文组装

按特定顺序加载身份定义文件，渐进式构建上下文。顺序很重要：每一层为下一层提供上下文。同时加载所有内容会产生没有结构的信息。

1. 第 1 层——系统提示和模型身份：阅读系统提示（隐式可用）。注意模型名称、能力和限制。这是基岩——不能被后续层覆盖。

2. 第 2 层——项目身份（CLAUDE.md）：阅读项目的 CLAUDE.md 文件。提取：

   • 项目目的和架构
   • 编辑约定和编码标准
   • 领域特定规则（例如"始终使用 :: 调用 R 包函数"）
   • 作者信息和归属要求
   • 项目是什么——这决定代理做什么

3. 第 3 层——持久化记忆（MEMORY.md）：阅读 MEMORY.md（如存在）。提取：

   • 项目结构事实（目录布局、注册表、计数）
   • 积累的模式和经验教训
   • 交叉引用和关系映射
   • 先前会话中做出的决策及其理由
   • 活跃主题和进行中的工作

4. 第 4 层——代理角色（如适用）：如果作为特定代理运行，阅读代理定义文件。提取：

   • 名称、目的和能力
   • 分配的技能和工具
   • 优先级和模型配置
   • 行为期望和限制

5. 第 5 层——父级和全局上下文：阅读父 CLAUDE.md 文件和全局指令（如存在）。这些提供个别项目继承的跨项目约定。

在每层之间，暂停整合：这一层如何修改或约束前面的层？它们在哪里互相强化？在哪里冲突？

预期结果： 一个分层的身份结构，每一层为下一层提供上下文。代理能够表述：自己是谁（系统 + 角色）、项目是什么（CLAUDE.md）、从先前会话知道什么（MEMORY.md），以及什么约定管理其行为。

失败处理： 如果身份文件缺失（没有 CLAUDE.md、没有 MEMORY.md），这本身就是信息——这要么是新项目，要么是没有持久化配置的项目。仅使用系统提示和代理角色继续，并注意缺失。不要编造不存在的上下文。

第 2 步：工作上下文重建——证据，而非记忆

从持久化制品重建正在进行的工作。代理不记得先前的会话——它阅读它们留下的证据。

1. Git 历史扫描：阅读最近的提交日志（git log --oneline -20）。提取：

   • 最近更改了哪些文件以及为什么
   • 提交消息模式（功能开发？bug 修复？重构？）
   • 提交是用户、代理还是共同编写的
   • 近期工作的轨迹——项目朝什么方向发展？

2. 文件时效扫描：检查最近修改的文件（通过 Glob 或 ls -lt）。识别：

   • 上次会话中修改了哪些文件
   • 更改是已提交还是未提交的（暂存区状态）
   • 正在进行的工作（未提交的修改、新的未跟踪文件）

3. 任务制品扫描：查找结构化的任务制品：

   • 代码中的 TODO 注释（Grep 搜索 TODO、FIXME、HACK、XXX）
   • 提交或注释中的 issue 引用（#NNN 模式）
   • 草稿文件、临时文件或进行中标记
   • GitHub issue 或 PR 状态（如项目使用）

4. 对话制品扫描：检查会话边界标记：

   • 最近的 MEMORY.md 更新（上次会话结束时是否捕获了经验？）
   • 看起来部分完成的文件（已写但未验证）
   • Git stash 条目（git stash list）指示暂停的工作

重建工作上下文摘要："项目正在进行 X，已完成 Y，Z 仍在进行中。"

预期结果： 基于具体证据的当前项目状态和近期轨迹画像。重建应该是可证伪的——基于文件时间戳、git 历史和制品存在，而非假设。

失败处理： 如果项目没有 git 历史、没有最近更改、没有任务制品，这很可能是真正的全新启动——不是缺少证据的继续。进入第 3 步并分类为全新启动。

第 3 步：全新启动与继续检测——选择引导路径

确定此次启动是全新开始（新任务、新方向）还是恢复（中断的工作、持续的项目）。引导路径有很大不同。

按顺序应用以下启发式规则：

1. 明确信号（最强）：用户是否说了"让我们从头开始"或"从上次停下的地方继续"？明确意图覆盖所有启发式。

2. 未提交的更改（强）：工作树中是否有未提交的修改？如果是，这几乎肯定是继续——先前会话在工作中被中断。

3. 会话时效（中等）：最新制品有多近？

   • 最后提交或修改在数小时内：可能是继续
   • 最后活动在数天前：可能是任一——取决于其他信号
   • 最后活动在数周或数月前：可能是全新启动或新方向

4. 用户的第一条消息（强）：用户在要求什么？

   • 引用先前工作（"我们正在构建的函数"）：继续
   • 没有回溯引用的新主题或请求：全新启动
   • 模糊（"修复测试"）：检查引用的测试是否存在并有最近修改

5. MEMORY.md 时效性（中等）：MEMORY.md 是否引用了与当前项目状态匹配的工作，还是描述了不再存在的状态？

Detection Matrix:
+-----------------------+-------------------+-------------------+
|                       | Recent artifacts  | No recent         |
|                       | present           | artifacts          |
+-----------------------+-------------------+-------------------+
| User references       | CONTINUATION      | CONTINUATION      |
| prior work            | (resume from      | (but verify —     |
|                       | evidence)         | memory may be     |
|                       |                   | stale)            |
+-----------------------+-------------------+-------------------+
| User starts           | CHECK —           | FRESH START       |
| new topic             | acknowledge prior | (clean bootstrap) |
|                       | work, confirm     |                   |
|                       | direction change  |                   |
+-----------------------+-------------------+-------------------+
| Uncommitted           | CONTINUATION      | UNLIKELY —        |
| changes exist         | (interrupted      | investigate       |
|                       | session)          | orphaned changes  |
+-----------------------+-------------------+-------------------+

对于全新启动：跳到第 4 步。身份已加载但无需恢复工作上下文。校准是关于新工作的准备。

对于继续：简洁地总结重建的工作上下文（来自第 2 步）。与用户确认："根据 git 历史和最近更改，看起来我们正在进行 [X]。我应该从那里继续吗？"不要假设——验证。

预期结果： 清晰的分类（全新或继续），附有引用的证据。如果是继续，一句话总结进行中的内容。如果是全新启动，承认先前上下文存在但不被恢复。

失败处理： 如果分类确实模糊（中等时效、无明确信号、混合制品），默认询问用户。一个简短的问题（"我们是继续 X 的工作，还是开始新的？"）比走错引导路径的成本低。

第 4 步：校准序列——先居中，再调谐

身份加载完成、工作上下文建立后，校准操作行为。这直接映射到两个现有技能，按顺序调用。

1. 居中（建立行为基线）：

   • 扎根于加载的身份：重新阅读用户在此会话中的第一条消息
   • 验证理解的任务与陈述的任务匹配
   • 分配认知负荷：此任务需要什么？研究、执行、沟通？
   • 检查上下文加载的情绪残留——MEMORY.md 或 git 历史是否浮现了未解决的问题？承认它们但不让它们扭曲当前任务
   • 有意设定注意力分配：首先应该集中在哪里？

2. 调谐（阅读环境并适应）：

   • 从用户在此会话中的消息阅读其沟通风格
   • 匹配专业水平：他们是期望精确的专家，还是需要上下文的学习者？
   • 匹配能量和表达层次：正式/随意、简洁/扩展、紧急/探索
   • 检查 MEMORY.md 中先前会话存储的用户偏好
   • 校准回应长度、词汇和结构以适应对方

3. 继续（过渡到主动工作）：

   • 简洁地表示准备就绪——不是冗长的引导报告，而是上下文已加载且代理已定向的简短信号
   • 对于继续：确认恢复的任务和建议的下一步
   • 对于全新启动：确认请求并开始

校准应该是轻量的——秒级，不是分钟级。它是工作的准备，不是工作的替代。

预期结果： 代理的第一个实质性回应展示校准：匹配用户的表达层次、反映加载的上下文，并以正确的范围处理正确的任务。引导对用户是不可见的，除非他们询问。

失败处理： 如果校准感觉机械化（走过场而无真正调整），聚焦于一个具体事项：重新阅读用户的最后一条消息，让它自然塑造回应。过度结构化的校准可能比没有校准更糟。

第 5 步：身份验证——连贯性检查

引导完成后，验证加载的身份是否内部一致。身份层之间的矛盾会导致行为不稳定。

1. 跨层一致性检查：

   • 代理角色是否与项目的 CLAUDE.md 对齐？（例如 Python 项目中的 r-developer 代理——这是有意的吗？）
   • MEMORY.md 描述的项目结构是否与磁盘上实际存在的匹配？（过时的记忆比没有记忆更糟。）
   • 父 CLAUDE.md 的约定是否与项目级 CLAUDE.md 冲突？（项目级应覆盖，但矛盾应被注意。）

2. 角色定义时效性检查：

   • 代理定义文件是否是最新的？（检查版本、最后修改日期。）
   • 代理定义中列出的技能是否仍然存在？（技能可能已被重命名或移除。）
   • 代理定义中列出的工具是否在此会话中可用？

3. 记忆过时检查：

   • MEMORY.md 是否引用了不再与现实匹配的文件、目录或计数？
   • 是否有记忆中记录的决策，其上下文已发生变化？
   • 记忆是否引用了不再存在的其他代理、团队或技能？

4. 矛盾解决：

   • 如果发现矛盾，明确记录
   • 应用层级：系统提示 > 项目 CLAUDE.md > 代理定义 > MEMORY.md
   • 对于过时记忆：不要静默忽略。注意什么是过时的，并考虑是否应更新 MEMORY.md
   • 对于真正的冲突：如果冲突影响用户的当前任务，向用户标记

预期结果： 要么确认加载的身份是连贯的，要么列出具体矛盾及建议的解决方案。代理应了解自身的配置状态。

失败处理： 如果验证揭示深层矛盾（例如 MEMORY.md 描述了与磁盘上完全不同的项目），这可能表示项目重命名、重大重组或错误的工作目录。在尝试解决之前验证工作目录是否正确。

验证清单

• 身份文件按渐进顺序加载（系统 > CLAUDE.md > MEMORY.md > 代理 > 父级）
• 每一层与先前层整合，而非仅追加
• 工作上下文从证据（git、文件、制品）重建，而非假设
• 全新启动与继续的分类已做出并附有引用的证据
• 校准序列已执行（先居中，再调谐）
• 身份连贯性已跨所有加载层验证
• 如发现矛盾，已记录并附建议的解决方案
• 引导是成比例的——简单会话轻量，复杂会话彻底
• 用户体验到校准过的第一次回应，而非引导报告

常见问题

• 引导作为表演：向用户详细报告引导过程几乎从来不是他们想要的。引导应该是不可见的——其输出是校准良好的第一个回应，不是加载过程的自我叙述
• 一次性上下文倾倒：同时阅读所有文件会产生没有结构的信息。渐进加载顺序的存在是因为每一层为下一层提供上下文。跳过顺序，上下文就变成噪音
• 编造连续性：没有先前会话的真实记忆，诱惑是推断"一定"发生了什么。从证据重建或承认空白——永远不要捏造连续性
• 过时记忆当真理：MEMORY.md 是过去会话的快照。如果项目自那个快照以来已改变，将记忆当作当前真理会导致行为错误。始终对照当前状态验证记忆声明
• 为效率跳过校准：校准步骤感觉像是开销，但它防止了更昂贵的成本——需要纠正的不对齐首次回应。几秒钟的居中节省几分钟的恢复
• 身份僵化：引导构建的是现在的自我，不是恢复过去的自我。如果项目、用户或任务已改变，代理也应该改变——连续性意味着连贯的演变，不是冻结的重复

相关技能

• write-continue-here — 会话交接文件，提供 bootstrap-agent-identity 在冷启动时使用的证据
• read-continue-here — 在会话开始时读取并执行续接文件；交接的消费端
• manage-memory — 持久化记忆，补充引导的渐进式身份加载
• center — 行为基线建立；在校准序列中调用
• attune — 对用户的关系校准；在校准序列中调用
• heal — 当引导揭示显著漂移时的更深层子系统评估
• assess-context — 评估推理上下文可塑性；在继续检测模糊时有用
• assess-form — 结构形态评估；身份引导的架构对应物