2.1 local 命令的懒加载#

/compact 的注册对象只包含元数据和动态导入入口：

1
const compact = {
2
  type: 'local',
3
  name: 'compact',
4
  description:
5
    'Clear conversation history but keep a summary in context. Optional: /compact [instructions for summarization]',
6
  isEnabled: () => !isEnvTruthy(process.env.DISABLE_COMPACT),
7
  supportsNonInteractive: true,
8
  argumentHint: '<optional custom summarization instructions>',
9
  load: () => import('./compact.js'),
10
} satisfies Command

启动时先加载这份注册信息。用户真正执行 /compact 后，load() 才导入压缩模块。DISABLE_COMPACT 控制手动命令是否可用，自动压缩还要经过自己的配置和 feature flag 判断。

2.2 call() 先确定要压缩的消息#

src/commands/compact/compact.ts 的 call() 可以概括成下面的路径：

1
/compact args
2
  -> getMessagesAfterCompactBoundary(messages)
3
  -> 没有自定义指令时，尝试 session-memory compaction
4
  -> reactive-only 模式走 reactiveCompactOnPromptTooLong
5
  -> microcompactMessages(messages)
6
  -> compactConversation(messagesForCompact, customInstructions)
7
  -> 返回 { type: "compact", compactionResult }

getMessagesAfterCompactBoundary() 只取最近一个压缩边界之后的消息。没有可压缩消息时，命令直接返回错误。

microcompactMessages() 会先处理工具结果。启用 cached microcompact 且模型支持时，代码扫描可压缩的 tool_result，按消息分组记录，再通过 cache edit 删除旧结果。消息对象可以保持不变，删除动作延迟到 API 层执行。

2.3 压缩提示词只负责生成交接摘要#

compactConversation() 先估算 preCompactTokenCount，执行 executePreCompactHooks()，再把 Hook 返回的指令和用户在 /compact 后输入的指令合并。用户指令排在前面。

getCompactPrompt() 对模型输出有明确约束：只输出文本，不调用工具，并用 <analysis> 和 <summary> 区分内部草稿与最终摘要。摘要要保留用户目标、文件名、函数签名、代码修改、错误修复和安全约束：

1
<analysis>
2
  为交接摘要整理当前任务状态
3
</analysis>
4
<summary>
5
  用户目标
6
  关键文件和函数
7
  已完成的修改与错误修复
8
  未完成步骤
9
  需要继续遵守的约束
10
</summary>

formatCompactSummary() 会移除 <analysis> 草稿，只把 <summary> 写回会话。摘要请求复用主会话的工具 Schema 时，模型一旦发起工具调用，这次请求就不会得到可用的摘要文本。

2.4 生成摘要后如何安装回会话#

streamCompactSummary() 优先调用 runForkedAgent()，复用主会话的系统提示词、工具和缓存前缀。失败或开关关闭时，代码改用 queryModelWithStreaming()，并做几项输入清理：

• 图片和文档替换成 [image]、[document] 标记。
• 移除压缩后会重新注入的 Skill attachment。
• 禁用 thinking，只保留文本摘要。
• 只允许读取类工具，并拒绝工具调用。

历史过长时，摘要请求本身也可能超出上下文窗口。代码按 API round 丢弃最早的一组消息后重试；仍然失败时返回 Conversation too long to summarize，提示用户使用 /clear。

摘要生成后，代码保存 readFileState，清理读取缓存，并构造恢复附件。这些附件可以包含最近读取的少量文件、仍在运行的 Agent、计划文件、plan mode 指令、已经调用过的 Skill，以及工具、Agent、MCP 指令的 delta。复刻实现对单文件、单 Skill、总附件 token 数和恢复文件数量都设有限制。

createCompactBoundaryMessage() 会生成一个 system / compact_boundary 消息，记录触发方式、压缩前 token 数和最后一条旧消息的 UUID。新历史按下面的顺序组装：

1
boundaryMarker
2
summaryMessages
3
messagesToKeep
4
attachments
5
hookResults

QueryEngine 和 SDK 层识别这个边界。原始 transcript 仍然存在，当前 API 看到的是摘要、保留的近期消息和恢复附件。

手动压缩、自动压缩和 Reactive Compact 都调用 compactConversation()，触发入口不同：

官方 SDK 类型把 session.compact() 的 trigger 暴露为 plugin，并允许 Hook veto。cached microcompact、reactive 模式和具体阈值属于版本实现细节。

3.1 prompt 命令返回一段文本#

Anthropic 的 2.1.63 CHANGELOG 将 /simplify 列为 bundled slash command。在复刻实现中，它注册成一个 prompt 命令：

1
export function registerSimplifySkill(): void {
2
  registerBundledSkill({
3
    name: 'simplify',
4
    description:
5
      'Review changed code for reuse, quality, and efficiency, then fix any issues found.',
6
    userInvocable: true,
7
    async getPromptForCommand(args) {
8
      let prompt = SIMPLIFY_PROMPT
9
      if (args) prompt += `\n\n## Additional Focus\n\n${args}`
10
      return [{ type: 'text', text: prompt }]
11
    },
12
  })
13
}

getPromptForCommand() 返回的是 ContentBlockParam[]。命令本身没有执行审查，也没有独立的 AST 分析器；主 Agent 收到这段文本后，才按照提示词调用 git、Agent、Edit 和 Write 等工具。

提示词的实际拼接方式如下：

1
SIMPLIFY_PROMPT
2

3
## Additional Focus
4

5
用户在 /simplify 后提供的参数

没有附加参数时，模型只收到 SIMPLIFY_PROMPT。有参数时，参数被追加到 ## Additional Focus 下，用来限定性能、API 兼容性或目录范围。

SIMPLIFY_PROMPT 的主体围绕三个阶段展开。下面保留阶段和审查项，省略了源码中的工具名与补充说明：

1
# Simplify: Code Review and Cleanup
2

3
审查所有变更文件，处理代码复用、质量和效率问题。
4

5
## Phase 1: Identify Changes
6

7
运行 git diff。存在暂存内容时运行 git diff HEAD。
8
没有 diff 时，审查用户点名或本轮修改过的文件。
9

10
## Phase 2: Launch Three Review Agents in Parallel
11

12
并行启动三个审查 Agent：
13
- Code Reuse Review
14
- Code Quality Review
15
- Efficiency Review
16

17
把完整 diff 交给每个 Agent，并等待三份结果。
18

19
## Phase 3: Fix Issues
20

21
合并审查结果，跳过误报，修复确认后的问题，并报告跳过的建议。

3.2 主 Agent 如何执行审查#

SIMPLIFY_PROMPT 要求主 Agent 先确定变更集合：工作树有暂存内容时使用 git diff HEAD，否则使用 git diff；工作树没有变化时，审查用户提到或本轮编辑过的文件。

确定 diff 后，主 Agent 在同一条模型响应中并发调用三个 Agent：

三个调用返回后，主 Agent 合并发现，选择需要处理的问题并修改代码。误报可以跳过，但需要在最终摘要中说明。整个过程使用普通的权限、工作树和工具调用协议。

这里的提示词决定审查顺序和关注点，代码修改仍由主 Agent 的工具调用完成。是否采纳某条建议，取决于模型对 diff、仓库搜索结果和误报的判断。

4.1 local-jsx 命令处理目标操作#

/goal 的注册对象使用 local-jsx：

1
const goal = {
2
  type: 'local-jsx',
3
  name: 'goal',
4
  description: 'Set or view a persistent goal that drives auto-continuation across turns',
5
  argumentHint: '[<objective> | status | clear | pause | resume | complete]',
6
  bridgeSafe: false,
7
  load: () => import('./goal.js'),
8
} satisfies Command

goal.tsx 把输入转换成状态操作：

命令完成回调可以设置 shouldQuery: true，也可以插入隐藏的 metaMessages。设置新目标时，源码会插入 <goal-objective-updated> 元消息，UI 显示截断后的摘要。

4.2 GoalState 保存跨轮次数据#

状态机位于复刻实现的 src/services/goal/goalState.ts，按 session ID 存在 Map<string, GoalState> 中：

1
type GoalState = {
2
  objective: string
3
  status: 'active' | 'paused' | 'blocked' | 'budget_limited'
4
    | 'usage_limited' | 'max_turns' | 'complete'
5
  tokenBudget: number | null
6
  tokensUsed: number
7
  startTime: number
8
  pausedAt: number | null
9
  accumulatedActiveMs: number
10
  blockedAttempts: number
11
  lastBlockReason: string | null
12
  turnsExecuted: number
13
}

状态更新有几条规则：

• pause 会把当前 active 时间累加到 accumulatedActiveMs，恢复时重新设置 startTime。
• cost tracker 收到 API usage 后更新 token 计数，达到 tokenBudget 就进入 budget_limited。
• 相同原因的 blocked 报告连续三次后才进入 blocked，原因变化会重置计数。
• 自动续跑最多执行 MAX_GOAL_TURNS = 150 轮，达到上限后进入 max_turns，需要 /goal continue 才能继续。

goalStorage.ts 每次状态变化都会向当前会话的 JSONL transcript 写入 goal checkpoint。/goal clear 追加 goal-cleared tombstone，恢复会话时，读取器按 session ID 取最后一个状态。

4.3 GoalTool 报告完成和阻塞#

模型通过 GoalTool.ts 读取目标或报告状态，输入 schema 是：

1
z.strictObject({
2
  action: z.enum(['get', 'update']).optional(),
3
  status: z.enum(['complete', 'blocked']).optional(),
4
  reason: z.string().optional(),
5
})

get 返回当前快照。update 只能把目标标记为 complete 或 blocked。完成时工具记录 token、有效耗时和续跑轮数，再调用 completeGoal()；阻塞时调用 recordBlockedAttempt()。目标状态由应用代码保存，模型只能通过这个 schema 约束的工具修改它。

4.4 两层提示词把目标带入下一轮#

Goal 有两类模型上下文。

第一类是每轮都可以看到的目标摘要。它把状态、耗时、token、预算和轮数放进 XML：

1
<active-goal status="active" elapsed="4m 12s" tokens="18400" budget="50000" turns="3">
2
为 monorepo 添加可回滚的数据库迁移并补齐测试
3
</active-goal>

第二类是 idle hook 注入的 continuation meta message。buildContinuationPrompt() 要求模型保持原始目标范围，完成前逐项寻找测试、文件内容或命令结果等证据；遇到阻塞时继续尝试，只有相同原因连续三轮才标记 blocked；完成或确认阻塞后，通过 GoalTool 更新状态。

续跑提示词的主要内容如下：

1
<goal-steering type="continuation">
2
  当前目标：{objective}
3
  已用 token：{tokensUsed}
4
  token 预算：{tokenBudget}
5

6
  保持目标范围。
7
  完成前执行 Completion Audit，寻找可验证证据。
8
  对相同阻塞原因进行连续计数。
9
  完成或确认阻塞后调用 GoalTool 更新状态。
10
</goal-steering>

目标文本会经过 escape_xml_text，防止 <、> 和 & 破坏 XML 结构。

4.5 idle hook 决定是否自动发起下一轮#

useGoalContinuation() 在 isLoading 从 true 变成 false 时检查续跑条件：

1
一轮查询结束
2
  -> 检查用户队列、活动 JSX、plan mode 和 abort 状态
3
  -> 读取 GoalState
4
  -> budget_limited: 注入一次收尾提示
5
  -> active 且未到 MAX_GOAL_TURNS: turnsExecuted += 1
6
  -> enqueue(<goal-steering type="continuation">...</goal-steering>)
7
  -> 下一轮正常 query

队列里有 /goal pause 或普通用户消息时，Hook 会跳过本次自动续跑。目标进入 complete、blocked、max_turns 或资源受限状态后，也不会继续创建实质性工作。