Claude Code Harness 第21章：Effort、Fast Mode 与 Thinking

在 AI 编助手的进化历程中，一个关键的挑战是如何在推理深度、响应速度和资源消耗之间找到最佳平衡点。Claude Code 创新性地引入了三层推理控制系统：Effort（推理努力等级）、Fast Mode（加速模式）和 Thinking（思维配置）。本章将深入剖析这一精密的协同工作机制，揭示它们如何共同决定每一次 API 调用的推理行为。

为什么需要分层的推理控制

模型的推理深度并非"越深越好"。更深的思考意味着更高的延迟、更多的 token 消耗和更低的吞吐量。对于"把变量名从 foo 改成 bar"这样的简单任务，让 Opus 4.6 进行 10 秒的深度推理是巨大的资源浪费；而对于"重构整个认证模块的错误处理系统"，快速浅层响应则会产出低质量的代码。

Claude Code 通过三个独立但协作的机制来精细控制推理深度：Effort（推理努力等级）、Fast Mode（加速模式）和 Thinking（思维链配置）。它们各自拥有不同的配置来源、优先级规则和模型兼容性要求，在运行时协同工作，为用户提供最佳的推理体验。

flowchart TB
    subgraph "用户请求"
        A[用户输入] --> B{任务类型?}
        B -->|简单| C[低Effort快速响应]
        B -->|复杂| D[高Effort深度推理]
    end
    
    subgraph "推理控制系统"
        E[Effort等级] --> F{Fast Mode可用?}
        F -->|是| G[路由到Opus 4.6]
        F -->|否| H[使用当前模型]
        G --> I[自适应Thinking]
        H --> J[模型配置Thinking]
        E --> K[Thinking配置]
    end
    
    subgraph "结果输出"
        I --> L[高质量深度推理]
        J --> M[平衡速度与质量]
    end
    
    C --> M
    D --> L

21.1 Effort：推理努力等级

Effort 是 Claude API 的原生参数，控制模型在生成响应前投入多少"思考时间"。Claude Code 在此基础上构建了一套多层优先级链，让用户能够精确控制推理深度。

四个努力等级

系统定义了四个精细化的努力等级：

// utils/effort.ts
export const EFFORT_LEVELS = [
  'low',      // 快速、直接的实现，最小开销
  'medium',   // 平衡的方式，标准实现和测试
  'high',     // 全面的实现，包含广泛测试和文档
  'max',      // 最深推理能力，仅限Opus 4.6
] as const satisfies readonly EffortLevel[]

每个等级都有其明确的适用场景和资源消耗特征：

等级	响应特征	适用场景	资源消耗
`low`	极快响应，最小推理	简单重命名、格式调整	⭐☆☆☆
`medium`	平衡速度与质量	日常编码、重构任务	⭐⭐☆☆
`high`	深度分析，全面测试	架构设计、bug修复	⭐⭐⭐☆
`max`	最强推理，完全优化	复杂算法、系统设计	⭐⭐⭐⭐

max 等级的模型限制在 modelSupportsMaxEffort() 中硬编码：只有 opus-4-6 和内部模型支持。当其他模型尝试使用 max 时会被自动降级为 high。

三层优先级链

Effort 的实际值由一个精心设计的三层优先级链决定，确保配置的一致性和可预测性：

export function resolveAppliedEffort(
  model: string,
  appStateEffortValue: EffortValue | undefined,
): EffortValue | undefined {
  const envOverride = getEffortEnvOverride()
  if (envOverride === null) {
    return undefined  // 环境变量设为 'unset'/'auto'：不发送 effort 参数
  }
  const resolved =
    envOverride ?? appStateEffortValue ?? getDefaultEffortForModel(model)
  if (resolved === 'max' && !modelSupportsMaxEffort(model)) {
    return 'high'
  }
  return resolved
}

优先级从高到低：

环境变量 CLAUDE_CODE_EFFORT_LEVEL（最高优先级）
应用状态 AppState.effortValue（通过 /effort 命令或 UI 设置）
模型默认值（根据模型类型和订阅状态决定）

flowchart TD
    A["环境变量 CLAUDE_CODE_EFFORT_LEVEL\n(最高优先级)"] --> B{已设置?}
    B -->|"'unset'/'auto'"| C["不发送 effort 参数"]
    B -->|"有效值(low/medium/high/max)"| D["使用环境变量值"]
    B -->|未设置| E["AppState.effortValue"]
    E --> F{已设置?}
    F -->|是| G["使用AppState值"]
    F -->|否| H["getDefaultEffortForModel()"]
    H --> I["模型默认策略"]
    I --> J{"值为max且\n模型不支持?"}
    G --> J
    J -->|是| K["降级为high"]
    J -->|否| L["保持原值"]
    K --> M["发送到API"]
    L --> M

模型默认值的差异化策略

getDefaultEffortForModel() 函数展示了精细的默认值策略，根据模型类型和订阅状态提供不同的默认值：

if (model.toLowerCase().includes('opus-4-6')) {
  if (isProSubscriber()) {
    return 'medium'  // Opus 4.6 Pro用户默认medium
  }
  if (
    getOpusDefaultEffortConfig().enabled &&
    (isMaxSubscriber() || isTeamSubscriber())
  ) {
    return 'medium'  // 高级订阅用户默认medium
  }
}
// 其他模型返回undefined，使用API默认的high

这里有一个关键的决策：Opus 4.6 的 Pro 订阅者默认 medium（而非 high）。这是经过 A/B 测试的决策，通过 GrowthBook 的 tengu_grey_step2 控制。源码注释带有明确警告：

重要提醒：不要在没有通知模型负责人和研究团队的情况下更改默认努力等级。默认努力是一个敏感设置，会 greatly 影响模型质量和性能。

当 Ultrathink 特性启用时，所有支持 effort 的模型默认也降为 medium，因为 Ultrathink 会在用户输入包含关键词时将 effort 动态提升到 high——medium 成为可被动态提升的基线。

数值型 Effort：内部实验机制

除了四个字符串等级，内部用户还可以使用数值型 effort，提供更精细的控制：

export function convertEffortValueToLevel(value: EffortValue): EffortLevel {
  if (typeof value === 'string') {
    return isEffortLevel(value) ? value : 'high'
  }
  if (process.env.USER_TYPE === 'ant' && typeof value === 'number') {
    // 数值映射：0-50=low, 51-85=medium, 86-100=high, 100+=max
    if (value <= 50) return 'low'
    if (value <= 85) return 'medium'
    if (value <= 100) return 'high'
    return 'max'
  }
  return 'high'
}

数值型 effort 不可持久化到设置文件，它只存在于会话运行时。这是一个实验机制，设计上不应意外泄漏到用户的 settings.json 中，确保普通用户不会接触到这些不稳定的功能。

Effort 持久化的边界设计

toPersistableEffort() 函数揭示了系统的一个微妙设计：max 等级对外部用户也不持久化，只在当前会话有效。

export function toPersistableEffort(value: EffortValue): EffortLevel | undefined {
  if (typeof value === 'number') {
    return undefined  // 数值型effort不持久化
  }
  if (value === 'max') {
    return undefined  // max等级不持久化
  }
  return value
}

这意味着用户通过 /effort max 设置的 max 等级在下次启动时会恢复为模型默认值——这是有意为之的设计，避免用户忘记关闭 max 而长期消耗过多资源。

21.2 Fast Mode：Opus 4.6 加速模式

Fast Mode（内部代号 "Penguin Mode"）是一种让 Sonnet 级模型使用 Opus 4.6 作为"加速器"的创新模式。当用户的主模型不是 Opus 时，特定请求可以被智能路由到 Opus 4.6 以获得更高质量的响应。

可用性检查链

Fast Mode 的可用性经过层层检查，确保只有在最合适的条件下才启用：

export function isFastModeEnabled(): boolean {
  return !isEnvTruthy(process.env.CLAUDE_CODE_DISABLE_FAST_MODE)
}

顶层开关之后，getFastModeUnavailableReason() 检查以下条件：

Statsig 远程关闭（tengu_penguins_off）：最高优先级的远程开关
非原生二进制：可选检查，通过 GrowthBook 控制
SDK 模式：默认在 Agent SDK 中不可用，除非显式 opt-in
非一方提供商：Bedrock/Vertex/Foundry 不支持
组织级禁用：API 返回的组织状态

模型绑定设计

Fast Mode 硬绑定到 Opus 4.6，确保加速质量的一致性：

export const FAST_MODE_MODEL_DISPLAY = 'Opus 4.6'

export function getFastModeModel(): string {
  return 'opus' + (isOpus1mMergeEnabled() ? '[1m]' : '')
}

isFastModeSupportedByModel() 也只对 Opus 4.6 返回 true。这意味着如果用户已经在使用 Opus 4.6 作为主模型，Fast Mode 就是它本身——避免不必要的自我路由。

冷却状态机

Fast Mode 的运行时状态是一个精巧的状态机，管理其可用性：

export type FastModeRuntimeState =
  | { status: 'active' }
  | { status: 'cooldown'; resetAt: number; reason: CooldownReason }

stateDiagram-v2
    [*] --> Active: 启动Fast Mode
    Active --> Cooldown: triggerFastModeCooldown()
    Cooldown --> Active: Date.now() >= resetAt
    Active --> Disabled: 组织状态关闭
    Cooldown --> Disabled: 永久禁用原因
    Disabled --> [*]
    
    state Cooldown {
        [*] --> RateLimit: API 429
        RateLimit --> [*]
        [*] --> Overloaded: 服务过载
        Overloaded --> [*]
    }

冷却触发时，系统记录冷却结束时间戳和原因，发送分析事件，并通过信号通知 UI：

export function triggerFastModeCooldown(
  resetTimestamp: number,
  reason: CooldownReason,
): void {
  runtimeState = { status: 'cooldown', resetAt: resetTimestamp, reason }
  hasLoggedCooldownExpiry = false
  logEvent('tengu_fast_mode_fallback_triggered', {
    cooldown_duration_ms: cooldownDurationMs,
    cooldown_reason: reason,
  })
  cooldownTriggered.emit(resetTimestamp, reason)
}

冷却过期的检测是惰性的——不使用定时器，而是在每次调用 getFastModeRuntimeState() 时检查。这避免了不必要的定时器资源消耗，冷却到期的 cooldownExpired 信号只在下次查询状态时才触发。

组织级状态预取

组织是否允许 Fast Mode 通过 API 预取确定。prefetchFastModeStatus() 函数在启动时调用 /api/claude_code_penguin_mode 端点，结果缓存在内存中。

预取有节流保护（30 秒最小间隔）和防抖机制（同一时刻只允许一个 inflight 请求）。当网络请求失败时，内部用户默认允许（不阻塞内部开发），外部用户则回退到磁盘缓存的 penguinModeOrgEnabled 值。

三态输出设计

getFastModeState() 函数将所有状态压缩为三个用户可见的状态：

export function getFastModeState(
  model: ModelSetting,
  fastModeUserEnabled: boolean | undefined,
): 'off' | 'cooldown' | 'on' {
  const enabled =
    isFastModeEnabled() &&
    isFastModeAvailable() &&
    !!fastModeUserEnabled &&
    isFastModeSupportedByModel(model)
  if (enabled && isFastModeCooldown()) {
    return 'cooldown'
  }
  if (enabled) {
    return 'on'
  }
  return 'off'
}

这个三态在 UI 中映射为不同的视觉反馈：

on：显示加速图标，表示当前正在使用 Opus 4.6
cooldown：显示临时降级提示，告知用户加速器暂时不可用
off：不显示加速图标，使用正常模型流程

21.3 Thinking 配置：思维控制系统

Thinking（思维链/extended thinking）控制模型是否以及如何输出推理过程。这是另一个关键的质量控制机制，与 Effort 协同工作。

三种思维模式

系统定义了三种思维模式，适应不同的使用场景：

export type ThinkingConfig =
  | { type: 'adaptive' }        // 模型自行决定是否思考和思考多少
  | { type: 'enabled'; budgetTokens: number }  // 固定token预算的思维链
  | { type: 'disabled' }        // 不输出思维链

模式	API 表现	适用场景	兼容性
`adaptive`	模型自主控制思考深度	大多数对话场景	Opus 4.6、Sonnet 4.6
`enabled`	固定token预算的思维链	需要精确控制预算时	Claude 4 全系列
`disabled`	禁用思维链输出	API验证、工具Schema	所有模型

模型兼容性分层

三个独立的能力检测函数处理不同级别的 Thinking 支持，形成清晰的决策链：

modelSupportsThinking()：检测模型是否支持思维链

if (provider === 'foundry' || provider === 'firstParty') {
  return !canonical.includes('claude-3-')  // 所有 Claude 4+ 支持
}
return canonical.includes('sonnet-4') || canonical.includes('opus-4')

一方和 Foundry 提供商：Claude 3 以外的所有模型都支持。三方提供商（Bedrock/Vertex）：只有 Sonnet 4+ 和 Opus 4+ 支持。

modelSupportsAdaptiveThinking()：检测模型是否支持 adaptive 模式

if (canonical.includes('opus-4-6') || canonical.includes('sonnet-4-6')) {
  return true
}

只有 4.6 版本的模型明确支持 adaptive。对于未知模型字符串，一方和 Foundry 默认为 true，三方默认为 false。

shouldEnableThinkingByDefault()：决定 Thinking 是否默认启用

export function shouldEnableThinkingByDefault(): boolean {
  if (process.env.MAX_THINKING_TOKENS) {
    return parseInt(process.env.MAX_THINKING_TOKENS, 10) > 0
  }
  const { settings } = getSettingsWithErrors()
  if (settings.alwaysThinkingEnabled === false) {
    return false
  }
  return true
}

优先级：MAX_THINKING_TOKENS 环境变量 > settings 中的 alwaysThinkingEnabled > 默认启用。

三模式对比分析

┌─────────────────────────────────────────────────────────────────────┐
│                    Thinking 三模式对比                               │
├──────────────┬────────────────┬────────────────────┬─────────────────┤
│              │ adaptive       │ enabled            │ disabled        │
├──────────────┼────────────────┼────────────────────┼─────────────────┤
│ 思考预算     │ 模型自行决定   │ 固定 budgetTokens  │ 不思考          │
│ API 参数     │ {type:'adaptive│ {type:'enabled',   │ 不传 thinking   │
│              │  '}            │  budget_tokens:N}  │ 参数            │
│ 支持模型     │ Opus/Sonnet 4.6│ Claude 4 全系列    │ 所有模型        │
│ 默认状态     │ 4.6模型首选    │ 旧4系列回退        │ 显式禁用时      │
│ 与Effort交互 │ Effort控制深度 │ budget控制上限    │ 无关            │
│ 适用场景     │ 大多数对话     │ 需要精确控制预算   │ API验证、       │
│              │                │                    │ 工具Schema等    │
└──────────────┴────────────────┴────────────────────┴─────────────────┘

API层的实际应用

在 services/api/claude.ts 中，ThinkingConfig 被转换为实际的 API 参数：

if (hasThinking && modelSupportsThinking(options.model)) {
  if (!isEnvTruthy(process.env.CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING)
      && modelSupportsAdaptiveThinking(options.model)) {
    thinking = { type: 'adaptive' }  // 优先使用adaptive
  } else {
    let thinkingBudget = getMaxThinkingTokensForModel(options.model)
    if (thinkingConfig.type === 'enabled' && thinkingConfig.budgetTokens !== undefined) {
      thinkingBudget = thinkingConfig.budgetTokens  // 用户指定预算覆盖默认值
    }
    thinking = { type: 'enabled', budget_tokens: thinkingBudget }
  }
}

决策逻辑清晰：优先 adaptive → 不支持 adaptive 时用固定预算 → 用户指定预算覆盖默认值。环境变量 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING 是最后的逃生出口，允许强制回退到固定预算模式。

21.4 Ultrathink：关键词触发的 Effort 提升

Ultrathink 是 Claude Code 中一个巧妙的交互设计：当用户在消息中包含 ultrathink 关键词时，自动将 Effort 从 medium 提升到 high，实现零摩擦的深度推理升级。

双重门控机制

Ultrathink 通过双重门控确保安全可控：

export function isUltrathinkEnabled(): boolean {
  if (!feature('ULTRATHINK')) {
    return false  // 构建时Feature Flag控制
  }
  return getFeatureValue_CACHED_MAY_BE_STALE('tengu_turtle_carbon', true)
}

构建时 Feature Flag（ULTRATHINK）控制代码是否包含在构建产物中，GrowthBook 运行时 Flag（tengu_turtle_carbon）控制是否对当前用户启用。

关键词检测算法

export function hasUltrathinkKeyword(text: string): boolean {
  return /\bultrathink\b/i.test(text)  // 词边界匹配，大小写不敏感
}

检测使用词边界匹配（\b），确保匹配完整的单词而非部分匹配。findThinkingTriggerPositions() 函数进一步返回每个匹配的位置信息，供 UI 高亮显示。

注意源码中的一个细节：每次调用都创建一个新的正则表达式字面量而不是复用共享实例，因为 String.prototype.matchAll 会从源正则的 lastIndex 复制状态。如果与 hasUltrathinkKeyword 的 .test() 共享实例，lastIndex 会在两次调用间泄漏，导致匹配结果不准确。

附件注入机制

Ultrathink 的 Effort 提升通过附件系统实现：

function getUltrathinkEffortAttachment(input: string | null): Attachment[] {
  if (!isUltrathinkEnabled() || !input || !hasUltrathinkKeyword(input)) {
    return []
  }
  logEvent('tengu_ultrathink', {})  // 记录激活事件
  return [{ type: 'ultrathink_effort', level: 'high' }]
}

这个附件被转换为系统提醒消息注入对话中：

case 'ultrathink_effort': {
  return wrapMessagesInSystemReminder([
    createUserMessage({
      content: `The user has requested reasoning effort level: ${attachment.level}. Apply this to the current turn.`,
      isMeta: true,
    }),
  ])
}

Ultrathink 不直接修改 resolveAppliedEffort() 的输出——它通过消息系统告知模型"用户请求了更高的推理努力"，让模型在 adaptive thinking 模式下自行调整。这是一个纯提示词级别的干预，不改变 API 参数。

彩虹UI反馈

Ultrathink 激活时，UI 以彩虹色显示关键词，提供即时的视觉反馈：

const RAINBOW_COLORS: Array = [
  'rainbow_red',
  'rainbow_orange',
  'rainbow_yellow',
  'rainbow_green',
  'rainbow_blue',
  'rainbow_indigo',
  'rainbow_violet',
]

const getRainbowColor = (index: number) => {
  return RAINBOW_COLORS[index % RAINBOW_COLORS.length]
}

getRainbowColor() 函数根据字符索引循环分配颜色，还有一组 shimmer 变体用于闪烁效果。这种视觉反馈让用户明确知道 Ultrathink 已被识别和激活。

与默认 Effort 的完美协同

Ultrathink 的设计与 Opus 4.6 的默认 medium effort 形成完美配合：

默认 effort 为 medium：快速响应大多数请求，保持高吞吐量
用户输入 ultrathink：在需要深度推理时主动触发
附件系统注入：通过系统消息提升 effort 等级
模型自适应调整：在 adaptive thinking 模式下增加推理深度

这种设计的优雅之处在于：用户获得了一个语义化的控制接口——不需要理解 effort 参数的技术细节，只需要在"需要更深入思考"时在消息中写上 ultrathink。

21.5 三大机制的协同工作

Effort、Fast Mode 和 Thinking 不是孤立工作的，它们在 API 调用链路上的交互形成一个多层控制面板：

graph TD
    A[用户输入] --> B{包含 "ultrathink"?}
    B -->|是| C[注入ultrathink_effort附件]
    B -->|否| D[正常流程]
    
    C --> E[resolveAppliedEffort
模型+应用状态值]
    D --> E
    
    E --> F{Fast Mode状态?}
    F -->|on| G[路由到Opus 4.6]
    F -->|cooldown| H[使用原始模型]
    F -->|off| H
    
    G --> I[Thinking配置检查]
    H --> I
    
    I --> J{模型支持adaptive?}
    J -->|是| K[adaptive thinking]
    J -->|否| L{支持thinking?}
    L -->|是| M[enabled thinking]
    L -->|否| N[disabled]
    
    K --> O[API调用
messages.create]
    M --> O
    N --> O
    
    O --> P[最终响应
高质量推理]

关键的交互点：

Effort + Thinking：当 Effort 为 medium 且 Thinking 为 adaptive 时，模型可能选择较少的推理。当 Ultrathink 将 Effort 提升到 high 时，adaptive thinking 也会相应增加推理深度。
Fast Mode + Effort：Fast Mode 改变的是模型（路由到 Opus 4.6），而 Effort 改变的是同一模型的推理深度。两者正交，可以独立配置。
Fast Mode + Thinking：当 Fast Mode 将请求路由到 Opus 4.6 时，该模型支持 adaptive thinking，所以 Thinking 配置自动升级到最优模式。

21.6 设计洞察与哲学

"中等"作为默认值的哲学

Opus 4.6 对 Pro 用户默认 medium effort，而非直觉上的 high，反映了一个深刻的权衡哲学：大多数编程交互不需要最深的推理，而降低默认 effort 可以显著提升吞吐量和降低延迟。

Ultrathink 机制则提供了一个零摩擦的升级路径——用户不需要离开对话流去调整设置，只需在句子中加一个词。这种设计体现了"默认保守，按需提升"的原则。

惰性状态检查的模式

Fast Mode 冷却的过期检测不使用定时器，而是在每次查询状态时惰性计算。这种模式在 Claude Code 中多次出现：

export function getFastModeRuntimeState(): FastModeRuntimeState {
  const currentState = runtimeState
  if (currentState.status === 'cooldown') {
    if (Date.now() >= currentState.resetAt) {
      runtimeState = { status: 'active' }
      cooldownExpired.emit()
    }
  }
  return runtimeState
}

这种模式避免了定时器的资源开销和竞态条件，代价是状态转换的时间精度取决于查询频率。对于 UI 驱动的系统，这个代价几乎为零。

能力检测的三层结构

modelSupportsThinking → modelSupportsAdaptiveThinking → shouldEnableThinkingByDefault 形成了从"能否使用"到"应否启用"的决策链。每一层都考虑了不同的因素：

模型能力：是否支持思维链
提供商差异：一方 vs 三方的模型可用性
用户偏好：设置中的 alwaysThinkingEnabled

每一层都带有明确的"不要在不通知负责人的情况下修改"的警告注释。这种多层防护反映了推理配置对模型质量的敏感性。

持久化的谨慎边界

系统在持久化方面采取了谨慎的态度：

max effort 不对外部用户持久化
数值型 effort 不持久化
Fast Mode 的 per-session opt-in 选项

这些设计选择都遵循同一原则：高开销的配置不应跨会话泄漏。用户在一次会话中开启 max 是有意识的选择；但如果这个选择被静默地带入下一次会话，它可能成为一个被遗忘的资源消耗。

实践指南：用户能做什么

1. 使用 `/effort` 命令精确控制

/effort low      # 简单任务：重命名、格式调整
/effort medium   # 日常任务：编码、重构（默认）
/effort high     # 复杂任务：架构设计、bug修复
/effort max      # 极限任务：复杂算法（仅Opus 4.6）

2. 利用 `ultrathink` 关键词

在消息中加入 ultrathink 关键词，临时提升推理深度：

请帮我分析这个性能瓶颈，ultrathink 我需要详细的优化建议

3. 通过环境变量固定策略

# 团队统一策略
export CLAUDE_CODE_EFFORT_LEVEL=high

# 完全不发送effort参数，使用服务端默认
export CLAUDE_CODE_EFFORT_LEVEL=unset

4. 理解 Fast Mode 的冷却机制

当 Fast Mode 因速率限制进入冷却时：

系统自动回退到原始模型
冷却是临时的（通常几分钟）
到期后自动恢复，无需手动干预

5. 注意 Thinking 模式匹配

Opus 4.6/Sonnet 4.6：支持 adaptive 思维模式
旧版 Claude 4：使用固定预算模式
强制禁用 adaptive：CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=true

6. `max` effort 的会话边界

max effort 不会跨会话保留——这是有意设计。每次新会话都会恢复为模型默认值，避免长期资源浪费。

版本演化：v2.1.91 的变化

v2.1.91 引入了重要的代理成本控制机制：

// 新增环境变量
CLAUDE_CODE_AGENT_COST_STEER

// 新增事件信号
tengu_forked_agent_default_turns_exceeded

这表明系统在多代理场景下对成本进行了更精细的控制。不仅可以限制单个代理的 thinking 预算，还可以在整体层面引导代理的资源消耗，实现更智能的成本管理。

总结

Claude Code 的 Effort、Fast Mode 和 Thinking 三大机制构成了一个精密的推理控制系统。它们通过分层优先级、智能路由和自适应配置，在保证代码质量的同时优化了性能和资源消耗。

这种设计的核心思想是：让系统默认做正确的事，同时给用户足够的控制权。通过 medium 的默认值保证效率，通过 Ultrathink 提供便捷的升级路径，通过 Fast Mode 智能路由质量资源，最终实现了性能与质量的完美平衡。

本章内容基于 Claude Code 官方源码分析，揭示了其推理控制系统的设计哲学和实现细节。通过理解这些机制，用户可以更好地利用 Claude Code 的强大功能，在 AI 辅助编程中获得最佳体验。

Claude Code Harness 第21章：Effort、Fast Mode 与 Thinking

Claude Code Harness 第21章：Effort、Fast Mode 与 Thinking

为什么需要分层的推理控制

21.1 Effort：推理努力等级

四个努力等级

三层优先级链

模型默认值的差异化策略

数值型 Effort：内部实验机制

Effort 持久化的边界设计

21.2 Fast Mode：Opus 4.6 加速模式

可用性检查链

模型绑定设计

冷却状态机

组织级状态预取

三态输出设计

21.3 Thinking 配置：思维控制系统

三种思维模式

模型兼容性分层

三模式对比分析

API层的实际应用

21.4 Ultrathink：关键词触发的 Effort 提升

双重门控机制

关键词检测算法

附件注入机制

彩虹UI反馈

与默认 Effort 的完美协同

21.5 三大机制的协同工作

21.6 设计洞察与哲学

"中等"作为默认值的哲学

惰性状态检查的模式

能力检测的三层结构

持久化的谨慎边界

实践指南：用户能做什么

1. 使用 /effort 命令精确控制

2. 利用 ultrathink 关键词

3. 通过环境变量固定策略

4. 理解 Fast Mode 的冷却机制

5. 注意 Thinking 模式匹配

6. max effort 的会话边界

版本演化：v2.1.91 的变化

总结

1. 使用 `/effort` 命令精确控制

2. 利用 `ultrathink` 关键词

6. `max` effort 的会话边界