1. Plan Mode 的设计目标

在 Agent 的日常使用中，一个常见的痛点是：Agent 急于动手，却在执行到一半时发现方向错了。模型在看到用户指令后，本能地想要「做点什么」——调用工具、创建文件、修改代码——但这些动作往往是盲目的。缺少事前的整体规划，会导致大量的无效工作、不必要的返工，甚至破坏已有的正确代码。

Plan Mode 正是为解决这一问题而设计的。它的核心理念是将「先想再做」的工作流形式化：​让 Agent 先制定一个完整的执行计划，呈现给用户审阅，在获得批准后再开始真正执行​。这种设计在几个层面带来了价值：

• ​减少盲目行动​：Agent 在动手之前必须回答「我要做什么、分几步做、每步的预期是什么」，这迫使模型进行更深层的任务分析。
• ​用户参与决策​：用户可以在计划阶段提出修改意见，纠正 Agent 的错误理解，调整执行策略，避免了事后返工的挫败感。
• ​风险预先识别​:计划中明确标注了各步骤的依赖关系和潜在风险，用户可以在高风险操作执行前进行干预。
• ​执行可追溯​:有了计划作为参照，Agent 的每一步执行都有明确的目标锚点，偏离计划的行为更容易被发现和纠正。

Plan Mode 本质上是一种​人类在环（Human-in-the-Loop）的决策架构​——它承认模型的规划能力并不完美，因此将最终决策权保留在用户手中。

2. Plan Mode 的工作流程

Plan Mode 的进入和退出由两个特殊的工具调用来控制：enter_plan_mode 和 exit_plan_mode。它们不是普通的业务工具，而是框架层面的控制原语，直接影响 TurnFlow 的行为模式。

2.1 进入 Plan Mode

当用户发出一条复杂度较高的指令（如「重构整个认证模块」或「在项目中集成 OAuth2.0 支持」）时，Agent 可以有多种方式进入 Plan Mode：

• ​用户显式触发​：用户在指令中明确要求「先制定一个计划」。
• ​模型主动进入​：模型判断当前任务足够复杂，需要事先规划，主动调用 enter_plan_mode。
• ​系统策略触发​：某些配置下，超过一定复杂度阈值的任务会自动进入 Plan Mode。

进入 Plan Mode 后，当前 turn 的性质发生变化：Agent 不再执行实际的修改操作，而是专注于分析、拆解、评估。模型会：

1. 读取相关代码和配置，理解当前状态
2. 识别任务的核心目标和约束条件
3. 将任务分解为有序的执行步骤
4. 分析步骤之间的依赖关系和并行可能性
5. 评估每步的风险和所需的验证方式
6. 生成结构化的计划文档

2.2 用户审阅阶段

计划生成后，系统将其呈现给用户。这是一个关键的决策点，用户有几种选择：

操作	效果
批准（Approve）	计划被接受，Agent 开始按步骤执行
修改（Modify）	用户调整某一步骤的内容、顺序或删除不必要的步骤，修改后的计划继续执行
拒绝（Reject）	计划被整体驳回，用户可能重新描述需求，Agent 重新规划
请求澄清	用户对计划中的某部分有疑问，要求 Agent 进一步解释后再做决定

2.3 退出 Plan Mode 并开始执行

一旦用户批准计划，Agent 调用 exit_plan_mode，将计划中的第一步作为当前 turn 的执行目标。后续的每个 turn 会推进计划中的一个步骤，直到所有步骤完成。在执行过程中，如果遇到需要调整计划的情况（如某步骤的预期结果与实际不符），Agent 可以重新进入 Plan Mode 进行修正。

1.用户发起复杂任务

Agent 评估复杂度，决定进入 Plan Mode

2.Agent 分析并生成计划

读取上下文、拆解步骤、评估风险、生成结构化计划

3.用户审阅计划

批准、修改或拒绝计划

4.Agent 按计划逐步执行

每完成一个步骤，检查验证点，推进到下一步

3. 计划的数据结构

Plan 不是一个简单的文本列表，而是一个结构化的数据对象，包含了足够的元信息来支持自动化执行和状态跟踪。

3.1 计划的核心组成

每个计划包含以下核心字段：

• ​**目标（Goal）**​：用一句话描述计划要达成的最终结果，作为整个执行过程的北极星。
• ​**步骤列表（Steps）**​：有序的执行步骤，每个步骤包含：
  • description：步骤的详细描述
  • expected_outcome：预期产出和验收标准
  • verification：如何验证此步骤已正确完成
• ​**依赖关系（Dependencies）**​：步骤之间的依赖图，标明哪些步骤可以并行执行，哪些步骤必须串行等待前序步骤完成。
• ​**验证点（Verification Points）**​：在关键步骤后设置的检查点，用于确认执行方向正确。如果验证失败，Agent 应暂停并请求用户决策。

3.2 步骤状态跟踪

每个步骤在执行过程中会经历状态流转：

状态	含义
pending	尚未开始，等待前序步骤完成
in_progress	当前正在执行中
completed	已完成并通过验证
skipped	用户或 Agent 决定跳过此步骤（如因条件变化不再需要）
failed	执行失败，需要重新规划或人工介入

3.3 计划的持久化

计划一旦创建，就会被持久化到 session 的上下文中。这意味着：

• ​跨 turn 可用​：每一步执行时都能访问完整的计划，确保执行不偏离轨道。
• ​session 恢复​：如果 session 因故中断（网络问题、超时等），重启后可以恢复到上次执行的步骤。
• ​审计可追溯​：完整的计划和执行记录可以用于后续的复盘分析。

// 计划的简化数据结构
interface Plan {
  id: string;
  goal: string;
  steps: PlanStep[];
  currentStepIndex: number;
  status: 'draft' | 'approved' | 'executing' | 'completed' | 'aborted';
  createdAt: Date;
  updatedAt: Date;
}

interface PlanStep {
  index: number;
  description: string;
  expectedOutcome: string;
  verification: string;
  status: StepStatus;
  dependsOn: number[];        // 依赖的前序步骤索引
  startedAt?: Date;
  completedAt?: Date;
}

4. Plan Mode 与其他模式的交互

4.1 与 TurnFlow 的关系

Plan Mode 从根本上改变了 TurnFlow 的行为。在正常模式下，每个 turn 是一个「接收用户指令 → 执行 → 返回结果」的循环；而在 Plan Mode 下，turn 的行为被修改为「推进计划中的一个步骤」。TurnFlow 会跟踪当前步骤的索引，在每个 turn 开始时注入当前步骤的上下文，在 turn 结束时更新步骤状态并判断是否需要继续执行下一个步骤。

Plan Mode 实际上是在 TurnFlow 之上叠加了一个​步骤调度层​——TurnFlow 仍然管理单轮对话的生命周期，但「下一步做什么」的决策权从用户转移到了计划。

4.2 与 PermissionManager 的关系

计划审阅可以看作 PermissionManager 的一种扩展形式。在常规权限控制中，每个工具调用都可能触发权限检查；而 Plan Mode 将权限检查提前到了计划层面——用户批准计划意味着对计划中所有步骤的「预授权」。这减少了执行过程中的权限确认中断，同时也要求计划本身对高风险操作有明确的标注。

如果计划中的某个步骤在执行时触发了新的权限边界（如访问了计划中未提及的敏感文件），PermissionManager 仍然会介入，确保「预授权」的范围不会超出用户的预期。

4.3 与 Goal Mode 的关系

Plan Mode 和 Goal Mode 是互补的两种自主执行模式。Plan Mode 侧重于事前规划 + 逐步执行，需要用户在规划阶段参与决策；而 Goal Mode 则追求设定目标后的全自动推进。实践中，Plan 可以为 Goal 提供执行蓝图：

• 用户在 Plan Mode 中审阅并批准计划后，可以将整个计划作为一个 Goal 来执行
• Goal Driver 参考计划中的步骤顺序和验证点，自动推进执行
• 当 Goal 执行中遇到需要重新规划的情况时，可以回到 Plan Mode 修正计划后继续

5. Goal Mode 的设计哲学

如果说 Plan Mode 的核心是「让用户在动手前审阅」，那么 Goal Mode 则是走向了另一个方向：​在明确约束下，让 Agent 自主完成多轮任务​。Goal Mode 的设计基于一个关键洞察——对于许多开发任务来说，逐轮交互的效率太低。用户可能希望「把这个功能完整实现」然后离开，让 Agent 在无人干预的情况下持续推进，等到任务完成后再回来检查结果。

但 Goal Mode 绝不是「放养」。它的设计哲学包含三条铁律：

• ​有明确的完成标准​：每个 Goal 都有清晰的可验证目标，Agent 不能无限循环。
• ​有严格的停止条件​：预算耗尽、遇到阻塞、发生错误时，Goal 必须停下来。
• ​有可恢复的状态​：停止不是失败——用户可以检查进展、解除阻塞、恢复执行。

Goal Mode 的设计哲学可以概括为：​信任但要验证​。给 Agent 足够的自主空间去推进任务，但用预算、护栏和状态机确保它不会失控。

6. Goal 状态机

Goal 的生命周期由一个四状态的状态机驱动。理解这个状态机是理解 Goal Mode 全部行为的关键。

                ┌──────────┐
创建 Goal ────→ │  active  │ ←─── 用户恢复
                └────┬─────┘
                     │
      ┌──────────────┼──────────────┐
      ↓              ↓              ↓
 ┌─────────┐   ┌──────────┐   ┌──────────┐
 │  paused │   │ blocked  │   │ complete │ (瞬时，随后清除)
 └─────────┘   └──────────┘   └──────────┘
      ↑              ↑
      └────── 用户恢复 ──────┘

active ←→ paused   (用户暂停 / 运行时错误 / 用户恢复)
active ←→ blocked  (业务阻塞 / 预算耗尽 / 用户恢复)
active  → complete (目标完成，瞬时状态，立即清除)

6.1 active（活跃）

active 是 Goal 的「工作状态」。在此状态下，Goal Driver 会在每个 turn 结束自动追加 continuation prompt，触发下一个 turn 的执行。模型在这个连续的执行流中自动推进任务，无需用户逐轮确认。

active 状态的核心行为包括：

• 每个 turn 被当作 Goal 整体任务的一个执行切片
• 模型在每个 turn 中需要判断「目标是否已完成」或「是否遇到阻塞」
• 如果既未完成也未阻塞，模型应推进一个合理的执行切片

6.2 paused（暂停）

paused 表示 Goal 处于暂停状态，其成因可以分为两类：

• ​用户主动暂停​：用户需要检查当前进展、修改执行策略，或者只是暂时不想让 Agent 继续运行。
• ​系统自动暂停​：遇到运行时错误（如 API rate limit、网络连接断开）时，系统会自动将 Goal 设为 paused，避免在错误状态下继续执行造成更多问题。

paused 状态下的 Goal 不会被清除——所有执行进度、中间结果和上下文都被保留。用户可以在解决问题后恢复执行。

6.3 blocked（阻塞）

blocked 是比 paused 更严重的停止状态，表示 Goal 遇到了自身无法解决的障碍：

• ​业务阻塞​：prompt hook 阻止了某个操作、模型判断当前无法继续（如缺少必要信息）、权限被拒绝等。
• ​预算耗尽​：turn budget、token budget 或 wall-clock budget 中任意一项达到 100%，Goal 会被 hard stop 并标记为 blocked。

paused 和 blocked 的本质区别在于：paused 通常是外部环境问题（可自动恢复），而 blocked 是业务或资源限制问题（需要人为介入）。

blocked 状态的 Goal 需要显式的用户操作才能恢复——系统不会自动重试。这是为了防止 Agent 在无法前进的情况下反复尝试，浪费资源。

6.4 complete（完成）

complete 是一个​瞬时状态​。当模型判断目标已达成时，Goal 进入 complete 状态，系统会：

1. 记录完成信息（完成时间、最终结果摘要）
2. 通知用户目标已完成
3. 立即清除 Goal（从 active goal 中移除）

complete 状态不持久化——它只是一个过渡信号，防止已完成的目标继续占用系统资源或误导后续交互。

7. Goal 的创建与生命周期

7.1 创建 Goal

Goal 的创建有两种触发方式：

• ​用户发起​：用户在对话中明确要求「把这个任务作为 Goal 执行」，系统通过特定的工具或指令创建 Goal。
• ​模型发起​：在执行 Plan 或其他复杂任务的过程中，模型可能判断当前任务适合以 Goal 模式自动推进，向用户建议创建 Goal。

创建时需要进行严格验证：

• ​目标不能为空​：空目标没有任何意义，直接拒绝。
• ​目标不能过长​：过长的目标描述会超出上下文注入的合理范围，也会导致模型难以聚焦。
• ​不能覆盖已有 goal​：如果当前已存在一个 active、paused 或 blocked 状态的 goal，默认情况下不允许创建新 goal。用户必须显式确认（如先完成或放弃当前 goal，再创建新 goal）。这是一种保护机制，防止用户无意中丢弃正在执行的任务。

7.2 替换 Goal

如果用户明确要求替换当前 Goal（例如「放弃当前任务，改为做 X」），系统会：

1. 将当前 Goal 标记为 paused（保留进度以备将来恢复）
2. 创建新 Goal 并设为 active
3. 通知用户旧 Goal 已被暂停

7.3 持久化和恢复

Goal 的状态和进度信息被持久化到 session 存储中。当 session 因用户关闭客户端、网络断开等原因重启时：

• ​active goal 自动降级为 paused​：这是一个关键的安全设计。在 session 重启后，Agent 对之前的执行状态可能有部分信息缺失（如上下文压缩），盲目继续执行 active goal 可能导致不一致的行为。将 active 降级为 paused 要求用户在恢复前确认：是否继续执行？从哪里继续？
• ​paused 和 blocked goal 保持原状态​：这些状态本身就意味着需要用户干预，重启应该保持。

// session 重启时的 Goal 状态恢复逻辑
function restoreGoalOnSessionStart(savedGoal: Goal): Goal {
  if (savedGoal.status === 'active') {
    // 关键安全设计：active → paused
    savedGoal.status = 'paused';
    savedGoal.pauseReason = 'session_restart';
  }
  // paused 和 blocked 保持原状态
  return savedGoal;
}

8. Goal Driver 工作机制

Goal Driver 是 Goal Mode 的核心执行引擎。它的职责看似简单，但其设计直接影响 Agent 的执行效率和用户体验：​将 active goal 推进成连续的普通 turn，直到 goal 不再是 active 状态​。

8.1 Goal Driver 的执行循环

Goal Driver 的工作是一个标准的检查-执行-再检查循环：

// Goal Driver 的简化实现
async function goalDriverLoop(goal: Goal): Promise<void> {
  while (true) {
    // 1. 检查预算
    const budgetStatus = checkBudget(goal);
    if (budgetStatus.exhausted) {
      goal.status = 'blocked';
      goal.blockedReason = `budget_exhausted: ${budgetStatus.reason}`;
      break;
    }
    if (budgetStatus.nearLimit) {
      injectBudgetWarning(budgetStatus);
    }

    // 2. 检查 goal 状态——如果不是 active 就停止
    if (goal.status !== 'active') break;

    // 3. 执行一个 turn
    const turnResult = await executeTurn({
      goal: goal,
      continuationPrompt: buildContinuationPrompt(goal)
    });

    // 4. 分析 turn 结果，更新状态
    if (turnResult.error) {
      goal.status = 'paused';
      goal.pauseReason = turnResult.error.message;
      break;
    }

    // 5. 模型返回的状态判断
    goal.status = turnResult.goalStatus;

    // 6. 继续循环（如果仍然是 active）
  }
}

8.2 Continuation Prompt

continuation prompt 是 Goal Driver 自动追加给模型的消息，它不会替换用户指令，而是在模型的已有上下文中附加一个引导性提示。continuation prompt 的设计非常精妙，它不直接告诉模型要做什么，而是引导模型自我评估当前状态并决定下一步：

continuation prompt 的核心不是命令，而是​让我审视​——它要求模型在每个 turn 回答三个问题：目标达成了吗？遇到障碍了吗？如果没有，下一步该推进什么？

一个典型的 continuation prompt 包含以下元素：

• ​目标重述​：提醒模型当前 Goal 是什么，确保模型不会在连续的 turn 中遗忘或偏离目标。
• ​进度概览​：简要说明已完成的工作，帮助模型理解当前处于任务的哪个阶段。
• ​自审提示​：要求模型判断目标是否已完成、是否遇到了需要暂停的阻塞。
• ​推进指引​：提示模型在没有阻塞的情况下，应该继续推进一个合理的执行切片（不要试图一次完成所有，也不要做得太少）。

8.3 Driver 的停止条件

Goal Driver 在以下情况停止循环：

停止条件	结果状态	说明
模型返回 complete	complete → 清除	目标已达成
模型返回 blocked	blocked	模型判断无法继续
运行时错误	paused	网络/API 错误等
预算耗尽	blocked	turn/token/time budget 达到上限
用户手动暂停	paused	用户主动介入

9. 预算系统

预算系统是 Goal Mode 的安全网——它确保 Agent 的自主执行不会无限期地持续下去，消耗大量资源。预算系统提供了三种维度的限制，用户可以按需组合使用。

9.1 三种预算类型

预算类型	计量单位	适用场景
Turn Budget	对话轮数	限制 Agent 的交互次数，防止无限循环
Token Budget	累计 token 消耗	控制 API 调用成本，适合对费用敏感的场景
Wall-Clock Budget	实际经过的时间	确保任务在合理时间内完成，适合有 deadline 的场景

9.2 默认行为与用户设置

默认情况下​没有任何预算限制​。预算系统完全由用户选择启用——如果你不设置预算，Agent 将一直运行直到目标完成或遇到阻塞。

这是一种「默认信任」的设计：相信大多数用户不会滥用（或能判断哪些任务需要预算约束），同时不强制设置默认值来限制绝大多数正常任务的执行。但对于长时间运行的任务，系统建议用户至少设置一项预算作为安全网。

9.3 两级阈值机制

每种预算都有两级阈值来控制 Agent 的行为：

• ​**75% 阈值（警告级）**​：当预算消耗达到 75% 时，系统向模型注入预算警告提示。这要求模型：
  • 检查当前进度，判断目标是否能在剩余预算内完成
  • 如果判断无法完成，开始收敛——不再启动新的工作，专注于收尾已有工作
  • 如果判断可以完成，继续正常执行但更注意效率
• ​**100% 阈值（硬停止）**​：预算完全耗尽时，Goal 被标记为 blocked，Driver 停止执行。这是一种硬性保护，确保资源消耗不会超出用户设定的上限。

// 预算检查的简化实现
function checkBudget(goal: Goal): BudgetStatus {
  const turnUsed = goal.turnsExecuted / goal.budget.maxTurns;
  const tokenUsed = goal.tokensConsumed / goal.budget.maxTokens;
  const timeUsed = Date.now() - goal.startTime.getTime();
  const timeRatio = timeUsed / goal.budget.maxDurationMs;

  // 找到消耗比例最高的那个预算维度
  const maxRatio = Math.max(turnUsed, tokenUsed, timeRatio);

  if (maxRatio >= 1.0) {
    return { exhausted: true, nearLimit: true, reason: 'budget_depleted' };
  }

  if (maxRatio >= 0.75) {
    return { exhausted: false, nearLimit: true,
      warning: `预算已消耗 ${Math.round(maxRatio * 100)}%，请收敛当前工作` };
  }

  return { exhausted: false, nearLimit: false };
}

10. 错误与故障处理

Goal Mode 的自主执行特性使得错误处理变得尤为重要——因为没有人在旁边实时监控，错误如果处理不当，可能导致 Agent 在错误状态下反复尝试，造成更大的问题。

10.1 运行时错误 → paused

运行时错误是指在 Goal 执行过程中出现的、与业务逻辑无关的技术故障。这类错误通常具有「可自动恢复」的特性，但系统选择不自动重试，而是降级为 paused——原因有两点：

• 连续重试可能加剧问题（如 rate limit 场景下持续重试只会延长限流时间）
• 暂停让用户有机会了解发生了什么、评估影响、决定是否继续

常见的运行时错误包括：

错误类型	处理方式
API Rate Limit (429)	paused，用户等待后手动恢复
网络连接超时/断开	paused，连接恢复后用户恢复
Token 超限（非预算）	paused，触发上下文压缩后恢复
模型返回非预期格式	paused，提示用户检查后恢复

10.2 业务阻塞 → blocked

业务阻塞与运行时错误不同——它不是技术故障，而是执行逻辑上的障碍，代表 Agent 在当前条件下确实无法继续推进。对于这类阻塞，简单的重试不会产生不同结果，因此系统将其标记为 blocked 而非 paused：

• ​prompt hook 阻止​：用户配置的 hook 拦截了某个操作，Agent 无法继续。
• ​模型判断无法继续​：模型在 continuation prompt 的自我审视中判断目标在当前条件下无法达成（如缺少必要文件、权限不足、前置条件不满足）。
• ​权限拒绝​：某工具调用被 PermissionManager 拒绝，且这不是可重试的操作。

10.3 恢复机制

无论是 paused 还是 blocked，Goal 的恢复都需要​显式的用户操作​。这不是为了增加用户负担，而是为了确保：

• 用户了解 Agent 为何停止
• 用户可以评估当前状态是否安全、合理
• 用户有机会在恢复前调整策略或解除阻塞原因

恢复操作会将 Goal 状态从 paused/blocked 切换回 active，Goal Driver 随之重新启动。

// 错误处理的分类逻辑
function handleTurnError(error: TurnError, goal: Goal): void {
  if (isRuntimeError(error)) {
    // 运行时错误：降级为 paused，用户可恢复
    goal.status = 'paused';
    goal.pauseReason = error.message;
    goal.pauseType = 'runtime_error';
  } else if (isBusinessBlock(error)) {
    // 业务阻塞：标记为 blocked，需要用户介入
    goal.status = 'blocked';
    goal.blockedReason = error.message;
    goal.blockedType = 'business_block';
  }
  // 通知 Goal Driver 停止循环
}

11. Goal 的上下文注入

上下文注入是 Goal Mode 的关键实现细节——它决定了模型在每个 turn 中能感知到多少 Goal 相关的信息，从而影响模型的决策质量。Goal 的上下文注入根据 Goal 的状态不同而有差异。

11.1 Active Goal 的上下文注入

当 Goal 处于 active 状态时，系统会向模型的上下文注入「全量」Goal 信息：

• ​完整的目标描述​：模型的每一个 turn 都能重新审视目标，避免在多轮执行中逐渐偏离方向。
• ​进度概览​：已完成的工作摘要、当前所处的阶段、还剩余的工作量估算。
• ​自审提示​：明确要求模型在执行每一步后评估「目标是否已完成」、「是否遇到阻塞」、「是否需要调整策略」。
• ​预算状态​：如果用户设置了预算，当前消耗比例和剩余预算也会被注入，帮助模型做出收敛决策。

Active Goal 的上下文注入是一种​强化锚定​——在多轮自主执行中，模型容易逐渐偏离原始目标（即所谓的「上下文漂移」），而持续注入完整目标可以有效对抗这种漂移。

11.2 Paused/Blocked Goal 的轻量注入

当 Goal 处于 paused 或 blocked 状态时，注入策略切换到轻量模式。这是因为在这两种状态下，Goal Driver 不会自动推进任务，因此不需要全量注入来引导模型决策：

• ​目标提醒​：简要说明有一个暂停/阻塞中的 Goal，提醒用户和模型它依然存在。
• ​状态说明​：告知为什么 Goal 被暂停或阻塞（如「因 API rate limit 暂停」或「预算耗尽，标记为阻塞」）。
• ​操作指引​：提示用户可以如何恢复（如「输入 continue 恢复执行」或「通过 budget 命令调整预算上限」）。

这种差异化注入策略的动机是实用主义的：在 paused/blocked 状态下注入全量 Goal 信息只会浪费上下文空间，而轻量提醒足够让用户了解状态并做出决策。

11.3 上下文注入与 Compaction 的协调

当 session 上下文接近窗口上限时，Compaction 机制会被触发以压缩历史消息。Goal 信息在 Compaction 中有特殊处理：

• Goal 的核心信息（目标、进度摘要）被保留在压缩后的摘要中，不会被丢弃。
• 预算信息和自审提示作为压缩后的「系统注解」继续注入。
• 详细的历史执行记录可以被压缩，但关键阶段的输出会被保留。

总结

Plan Mode 和 Goal Mode 代表了 agent-core 在结构化自主执行方面的两种策略。Plan Mode 侧重于事前规划与人类审阅，通过 enter_plan_mode / exit_plan_mode 控制原语和结构化的计划数据，将复杂任务的执行置于用户的监督之下。Goal Mode 则走向预算约束下的自动推进，通过四状态状态机、Goal Driver 循环和三级预算系统，让 Agent 在安全网的保护下自主完成多轮任务。

两者的关系不是对立，而是互补：Plan 可以为 Goal 提供蓝图，Goal 可以为 Plan 提供高效的执行引擎。在 agent-core 的设计中，这两种模式的交互通过 TurnFlow 的 step scheduling 和 Goal Driver 的 auto-continuation 实现无缝衔接。

理解这些机制的关键在于：​它们不是为了取代用户，而是为了让用户在合适的时机进行合适的干预​——Plan Mode 让干预发生在执行之前，Goal Mode 让干预发生在预算耗尽或遇到阻塞之后。这种「适时干预」的设计，是 kimi-code Agent 在自主性和可控性之间取得平衡的核心。