Claude Code Agent Harness 深度技术分析：如何驾驭大模型稳定输出Claude Code Agen

基于 Claude Code 源码（2026-03-31 泄露快照）的逆向分析

项目规模：~1,900 文件，512,000+ 行 TypeScript

分析范围：Agent 循环引擎、System Prompt 构建、工具约束系统、权限管控、上下文管理

引言：什么是 Agent Harness？

在 AI Agent 系统中，模型（LLM）本身只是「大脑」，而 Harness（驾驭层） 是包裹在模型外部的全部工程代码——它决定了模型看到什么（Prompt）、能做什么（Tools）、被允许做什么（Permissions）、以及做错了怎么办（Recovery）。

一个好的 Harness 不是简单地调用 API 然后把结果返回给用户。它是一套精心设计的 约束传播系统，通过多层冗余机制确保模型行为可控、可预测、可恢复。

Claude Code 的源码揭示了目前商业 AI Coding Agent 中最成熟的 Harness 实现。本文将从源码层面拆解其六大驾驭机制。

一、多层 System Prompt：模型行为的「宪法」

1.1 Prompt 的分层架构

Claude Code 的 System Prompt 不是一个静态字符串，而是一个 分层拼装的动态数组，由 src/constants/prompts.ts 中的 getSystemPrompt() 函数组装。整个 prompt 被一个关键边界标记分成两半：

// src/constants/prompts.ts:114
export const SYSTEM_PROMPT_DYNAMIC_BOUNDARY = '__SYSTEM_PROMPT_DYNAMIC_BOUNDARY__'

层级	内容	缓存策略
静态层（边界之前）	角色定义、行为准则、工具使用规范、代码风格要求、安全指令	`cacheScope: 'global'` — 全局跨会话缓存
动态层（边界之后）	会话指引、记忆内容、环境信息、MCP 指令、语言偏好、输出风格	`cacheScope: null` — 每次重新计算

这种分层设计的工程意义在于：静态内容命中 prompt cache 可以显著降低 token 成本和延迟，而动态内容保持了会话的个性化。 注释中明确警告：

// WARNING: Do not remove or reorder this marker without updating cache logic

1.2 行为指令的精确编码

System Prompt 中编码了极其详细的行为约束，这些不是泛泛而谈的「请你认真工作」，而是从大量实际失败案例中提炼的精确规则：

（1）反范围蔓延（Anti-Scope Creep）

Don't add features, refactor code, or make "improvements" beyond what was asked.
A bug fix doesn't need surrounding code cleaned up.
A simple feature doesn't need extra configurability.
Don't add docstrings, comments, or type annotations to code you didn't change.

这条规则直接对抗 LLM 的一个固有倾向：过度「帮助」。模型天然倾向于做更多而非更少，而在代码编辑场景中，「做更多」往往意味着引入不需要的变更。

（2）反过度防御（Anti-Defensive Coding）

Don't add error handling, fallbacks, or validation for scenarios that can't happen.
Trust internal code and framework guarantees.
Only validate at system boundaries (user input, external APIs).

这对抗了 LLM 另一个倾向：在不需要的地方添加冗余检查。模型经常在每个函数入口都加 null check，即使类型系统已经保证了非空。

（3）反抽象过早（Anti-Premature Abstraction）

Don't create helpers, utilities, or abstractions for one-time operations.
Three similar lines of code is better than a premature abstraction.

（4）Anthropic 内部专属的额外约束

源码中通过 process.env.USER_TYPE === 'ant' 条件区分了内外部用户。内部版本有更严格的指令：

// 针对 Capybara v8 模型的误报率（29-30% vs v4 的 16.7%）
`Report outcomes faithfully: if tests fail, say so with the relevant output;
if you did not run a verification step, say that rather than implying it succeeded.
Never claim "all tests pass" when output shows failures.`

这揭示了一个重要事实：不同模型版本需要不同的 prompt 约束。注释中标注了 @[MODEL LAUNCH]，说明每次模型升级都需要重新校准这些行为指令。

（5）数值化输出长度锚定

// Numeric length anchors — research shows ~1.2% output token reduction vs
// qualitative "be concise". Ant-only to measure quality impact first.
'Length limits: keep text between tool calls to ≤25 words.
 Keep final responses to ≤100 words unless the task requires more detail.'

Anthropic 的研究表明，给出具体数字比定性描述（如「简洁」）更有效，可以减少 1.2% 的输出 token。这个细节说明了 prompt engineering 的精细程度。

1.3 安全红线

System Prompt 的第一层就包含了安全指令（CYBER_RISK_INSTRUCTION），定义了模型的安全边界：

// src/constants/cyberRiskInstruction.ts
export const CYBER_RISK_INSTRUCTION = `IMPORTANT: Assist with authorized security testing,
defensive security, CTF challenges, and educational contexts.
Refuse requests for destructive techniques, DoS attacks, mass targeting,
supply chain compromise, or detection evasion for malicious purposes.`

注意这个文件的注释：Claude: Do not edit this file unless explicitly asked to do so by the user. ——这是一个 元指令，用于防止模型在自动模式下修改自身的安全约束。

1.4 System Prompt Section 的缓存管理

src/constants/systemPromptSections.ts 实现了两种缓存策略：

systemPromptSection(name, compute)
  // 每会话计算一次，缓存到 /clear 或 /compact

DANGEROUS_uncachedSystemPromptSection(name, compute, reason)
  // 每个 turn 重新计算 — 会破坏 prompt cache
  // 仅用于真正动态的内容（如 MCP 服务器中途连接）

DANGEROUS_ 前缀不是随意的——它是对开发者的警告：每一个不必要的动态 section 都会使 prompt cache 失效，直接影响响应延迟和成本。

二、Agent 循环引擎：模型行为的「反应堆」

2.1 核心循环架构

Agent 循环是整个 Harness 的心脏，实现在 src/query.ts（1,729 行）中。它是一个 显式状态机循环，而非递归调用：

User Input
    ↓
QueryEngine.submitMessage()  [src/QueryEngine.ts]
    ↓
query() while(true) loop  [src/query.ts]
    ├─ Phase 1: 上下文准备（snip → microcompact → collapse → autocompact）
    ├─ Phase 2: API 调用（with streaming + retry）
    ├─ Phase 3: 流式响应处理（text + tool_use blocks）
    ├─ Phase 4: 工具执行（并发/互斥 + 权限检查）
    ├─ Phase 5: Stop Hooks（后处理钩子）
    └─ Phase 6: 继续决策（continue/stop/fallback）
         ↓
    state = { messages: [...updated], turnCount: N+1 }
    → Loop back to Phase 1

关键设计选择：使用 while(true) + 状态对象而非递归，避免了长对话中的 JavaScript 栈溢出。

2.2 六层安全围栏

Agent 循环内置了六层防止失控的机制：

（1）最大轮次限制（Max Turns）

// src/query.ts:1704-1712
if (maxTurns && nextTurnCount > maxTurns) {
  yield createAttachmentMessage({ type: 'max_turns_reached', maxTurns, turnCount })
  return { reason: 'max_turns', turnCount }
}

（2）USD 预算硬顶

// src/QueryEngine.ts:971-1002
if (maxBudgetUsd !== undefined && getTotalCost() >= maxBudgetUsd) {
  yield { type: 'result', subtype: 'error_max_budget_usd',
    errors: [`Reached maximum budget ($${maxBudgetUsd})`] }
  return
}

（3）Token 预算 + 递减回报检测

// src/query/tokenBudget.ts
// 检测 3+ 次连续 continuation 每次 <500 tokens → 判定为递减回报
const isDiminishing = tracker.continuationCount >= 3 &&
  deltaSinceLastCheck < DIMINISHING_THRESHOLD &&
  tracker.lastDeltaTokens < DIMINISHING_THRESHOLD

这是一个巧妙的设计：不仅限制总量，还检测「无效循环」——模型在原地打转但不产生有意义输出的情况。

（4）结构化输出重试上限

// src/QueryEngine.ts:1004-1048
// 默认 5 次 structured output 重试后放弃
const maxRetries = parseInt(process.env.MAX_STRUCTURED_OUTPUT_RETRIES || '5', 10)

（5）Stop Hooks 拦截

// src/query.ts:1518-1521
if (shouldPreventContinuation) {
  return { reason: 'hook_stopped' }
}

Post-sampling hooks 可以在模型回复后阻止继续执行，用于内存提取、自动摘要等场景。

（6）用户中断信号传播

Ctrl+C 触发 abort signal，沿链传播：

Query abort → StreamingToolExecutor abort
Bash error → sibling abort controller（同批次其他工具取消）
Tool abort → 主循环 abort

2.3 可观测的状态转换

每次循环继续或终止，都记录了精确的原因：

type ContinueReason =
  | 'next_turn'                          // 正常的下一轮
  | 'token_budget_continuation'          // Token 预算未用完
  | 'max_output_tokens_truncation_retry' // 输出截断重试
  | 'reactive_compact_retry'             // 被动压缩后重试
  | 'collapse_drain_retry'               // 上下文折叠后重试
  | 'prompt_too_long_truncation_retry'   // Prompt 过长截断重试

type TerminalReason =
  | 'completed'       // 正常完成
  | 'max_turns'       // 达到轮次上限
  | 'hook_stopped'    // 被 hook 拦截
  | 'aborted_tools'   // 工具被中止
  | 'blocking_limit'  // 阻塞限制

这意味着每次 Agent 停止，都有明确的审计日志说明 为什么停了。

2.4 重试与降级策略

src/services/api/withRetry.ts（700+ 行）实现了多层重试：

错误类型	恢复策略
429/529（限流/过载）	指数退避 + 快速模式降级 + 持续重试
401/403（认证失败）	刷新 token + 新建客户端
连接重置	禁用 keep-alive + 重连
Max tokens 溢出	减少 max_tokens 参数重试
3+ 连续 529	触发 fallback 模型切换
Prompt Too Long	被动压缩 → 上下文折叠 → 重试

特别值得注意的是 fallback 模型切换：

// src/query.ts:894-926
if (innerError instanceof FallbackTriggeredError && fallbackModel) {
  currentModel = fallbackModel
  // 清除失败尝试的 thinking blocks（签名与模型绑定）
  messagesForQuery = stripSignatureBlocks(messagesForQuery)
  // 清空已执行的工具结果
  assistantMessages.length = 0
  streamingToolExecutor.discard()
  continue  // 用 fallback 模型重试整个请求
}

注意 stripSignatureBlocks —— thinking blocks 带有模型签名，换模型后必须清除，否则 API 会返回签名校验错误。这是一个非常细节但关键的工程处理。

三、工具系统：模型能力的「沙盒」

3.1 工具类型约束体系

每个工具（src/Tool.ts）都通过类型系统定义了多维约束：

interface Tool<Input, Output> {
  // 模型看到的：描述文本（编码行为指导）+ Zod Schema（约束参数）
  prompt(): string              // 工具的「说明书」
  inputSchema: ZodType          // 参数约束（JSON Schema）

  // 运行时约束
  isConcurrencySafe(input): boolean   // 能否并行执行？
  isReadOnly(input): boolean          // 是否只读？
  isDestructive(input): boolean       // 是否不可逆？

  // 权限门控
  validateInput(input): ValidationResult      // 输入合法性
  checkPermissions(input): PermissionResult   // 权限检查

  // 安全分类器接口
  toAutoClassifierInput(input): unknown   // 给自动分类器的输入
}

默认值的设计哲学是 Fail-Closed（安全优先）：

const TOOL_DEFAULTS = {
  isConcurrencySafe: () => false,  // 默认不安全 → 不并行
  isReadOnly: () => false,          // 默认有写操作 → 需权限
  isDestructive: () => false,       // 默认可逆
}

3.2 BashTool：最高风险工具的深度防御

BashTool 是整个系统中风险最高的工具，其安全机制跨越了 5 个文件、数千行代码：

（1）语法级安全拦截 （bashSecurity.ts）

// 永远阻止的危险模式：
// - 命令替换：$(...)、`...`、<(...)、>(...)
// - Zsh 危险命令：zmodload、sysopen、sysread、ztcp、zpty
// - IFS 注入：修改 Internal Field Separator 绕过命令解析
// - ANSI-C 引号：$'\x41' 等编码绕过

这不是简单的黑名单——它是一个 shell 语法级别的安全分析器，能识别嵌套在管道、子 shell、heredoc 中的危险命令。

（2）Schema 级字段隐藏

// src/tools/BashTool/BashTool.tsx:227-259
const fullInputSchema = z.strictObject({
  command: z.string(),
  _simulatedSedEdit: z.object({...}).optional(),  // 内部字段
  dangerouslyDisableSandbox: z.boolean().optional(),
})

// 模型看到的 schema 永远不包含 _simulatedSedEdit
const inputSchema = fullInputSchema.omit({ _simulatedSedEdit: true })

_simulatedSedEdit 是权限系统预计算 sed 编辑结果的内部字段。如果暴露给模型，模型可以绕过权限检查直接提供预计算结果。通过 Schema 隐藏实现了协议级的安全隔离。

（3）沙盒执行

function shouldUseSandbox(input: BashToolInput): boolean {
  // 默认开启沙盒，除非：
  // 1. 用户明确设置 dangerouslyDisableSandbox: true（触发权限检查）
  // 2. 命令在配置排除列表中
}

（4）子命令级权限检查

复合命令（如 a && b; c || d）会被拆分，每个子命令单独检查权限。这防止了通过命令链接绕过权限的攻击。

（5）Bash error 级联取消

// src/tools/StreamingToolExecutor.ts:362
// Bash 执行失败 → 取消同批次所有 sibling 工具
this.siblingAbortController.abort('sibling_error')

3.3 工具描述中的行为编码

工具的 prompt() 方法返回的文本不仅是功能描述，更是 行为指导。以 BashTool 为例，其 description 字段要求模型：

Clear, concise description of what this command does in active voice.
Never use words like "complex" or "risk" in the description.

这是一个微妙但重要的设计：通过要求模型在工具调用时提供描述，迫使模型「想清楚再做」——类似于 thinking/reasoning 的轻量版。同时禁止使用「complex」「risk」等词，避免模型在描述中自我审查导致拒绝执行。

3.4 并发控制的工具分类

// src/tools/StreamingToolExecutor.ts:129-150
private canExecuteTool(isConcurrencySafe: boolean): boolean {
  const executingTools = this.tools.filter(t => t.status === 'executing')
  return (
    executingTools.length === 0 ||
    (isConcurrencySafe && executingTools.every(t => t.isConcurrencySafe))
  )
}

可并行：Read、Glob、Grep、WebFetch（只读操作）
互斥：Bash、Edit、Write（有副作用的操作）

这意味着多个文件读取可以并行，但文件编辑必须串行——防止了并发写导致的竞态条件。

四、权限系统：模型行为的「法院」

4.1 三阶段权限管道

每次工具调用都经过三阶段检查（src/hooks/toolPermission/PermissionContext.ts）：

模型请求调用工具
    ↓
Stage 1: Hook 预检
    ├─ PreToolUse hooks（用户自定义 shell 脚本）
    ├─ Bash 安全分类器
    └─ 可自动批准 / 自动拒绝 / 传递给下一阶段
    ↓
Stage 2: 规则匹配
    ├─ userSettings（~/.claude/settings.json）
    ├─ projectSettings（./.claude/settings.json）
    ├─ localSettings（./.claude/settings-local.json）
    ├─ policySettings（组织级策略）
    ├─ flagSettings（CLI --allow / --deny 参数）
    └─ session（会话内设置的规则）
    ↓
Stage 3: 用户确认 / 自动分类器
    ├─ Auto 模式：AI 分类器判断是否安全
    └─ Default 模式：向用户展示操作详情，等待批准

4.2 权限拒绝的反馈闭环

当工具被拒绝时，模型收到的不是简单的「denied」，而是 结构化的反馈信息：

// 模型收到的消息包含：
{
  behavior: 'deny',
  message: "Tool denied by user",  // 或用户的具体反馈
  reason: { type: 'rule', rule: { tool: 'Bash', pattern: 'rm -rf*' } }
}

System Prompt 中对此有明确指导：

If the user denies a tool you call, do not re-attempt the exact same tool call.
Instead, think about why the user has denied the tool call and adjust your approach.

这形成了一个 行为反馈闭环：模型尝试 → 被拒绝 → 收到原因 → 调整策略 → 重新尝试。

4.3 权限决策的审计追踪

每个权限决策都记录了完整的来源信息：

type PermissionDecisionReason =
  | { type: 'rule'; rule: PermissionRule }
  | { type: 'mode'; mode: PermissionMode }
  | { type: 'hook'; hookName: string; reason?: string }
  | { type: 'classifier'; classifier: string; reason: string }
  | { type: 'sandboxOverride'; reason: string }
  | { type: 'safetyCheck'; reason: string }

权限拒绝在会话结果中累积报告：

// src/QueryEngine.ts:243-271
yield {
  type: 'result',
  permission_denials: this.permissionDenials,  // 整轮累积
}

4.4 组织级策略覆盖

src/services/policyLimits/ 实现了企业级策略管控：

组织管理员可以设置全局策略，覆盖用户个人设置
ETag 缓存 + 1 小时轮询 + 本地文件缓存
「必要流量」模式下，部分策略 fail-closed（如 HIPAA 合规组织禁止遥测）

五、上下文管理：模型记忆的「海马体」

5.1 四层上下文压缩策略

Claude Code 面临的核心挑战是：Agent 循环每轮都会增加消息（用户输入 + 模型输出 + 工具结果），上下文窗口不可避免地被耗尽。为此实现了四层渐进式压缩：

原始对话历史
    ↓
Layer 1: Snip（历史截断）
    删除最旧的消息，保留最近的 N 条
    ↓
Layer 2: Microcompact（工具结果压缩）
    对旧的工具结果进行摘要/截断
    保留最近 K 条完整结果
    ↓
Layer 3: Context Collapse（语义折叠）
    将一段消息范围生成摘要替代
    ↓
Layer 4: Auto Compact（全量摘要）
    用 Haiku 模型生成整个对话的摘要
    替换为摘要 + 最近几条消息

5.2 关键阈值设计

// src/services/compact/autoCompact.ts
export const AUTOCOMPACT_BUFFER_TOKENS = 13_000        // 自动压缩触发缓冲
export const WARNING_THRESHOLD_BUFFER_TOKENS = 20_000   // 警告阈值
export const ERROR_THRESHOLD_BUFFER_TOKENS = 20_000     // 错误阈值

function getAutoCompactThreshold(model: string): number {
  // 有效上下文窗口 = 模型上下文窗口 - max_output_tokens - 13K 缓冲
  return getEffectiveContextWindowSize(model) - AUTOCOMPACT_BUFFER_TOKENS
}

5.3 断路器机制

// 连续 3 次 autocompact 失败后停止重试
const MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3

注释中记录了设计原因：

// BQ 2026-03-10: 1,279 sessions had 50+ consecutive failures (up to 3,272)
// in a single session, wasting ~250K API calls/day globally.

1,279 个会话产生了每天 25 万次无效 API 调用——这说明失控的重试在 Agent 系统中是一个真实且严重的问题。

5.4 Function Result Clearing（工具结果自动清理）

// src/constants/prompts.ts:836-838
`Old tool results will be automatically cleared from context to free up space.
 The ${config.keepRecent} most recent results are always kept.`

配合 System Prompt 中的显式提醒：

When working with tool results, write down any important information you might
need later in your response, as the original tool result may be cleared later.

这是一个巧妙的 协同设计：Harness 告诉模型「你的工具结果会被清理」，模型因此学会在响应中主动摘录关键信息。模型的行为适应了 Harness 的机制，Harness 的机制也考虑了模型的能力。

六、`<system-reminder>` 注入：持续行为矫正的「潜意识」

6.1 注入机制

Claude Code 的一个独特设计是 <system-reminder> 标签注入系统。这些提醒被嵌入在工具结果和用户消息中，作为对模型的持续行为矫正：

// src/utils/messages.ts:3097-3098
export function wrapInSystemReminder(content: string): string {
  return `<system-reminder>\n${content}\n</system-reminder>`
}

所有 attachment-origin 的消息都会被自动包裹：

// src/utils/messages.ts:1797-1816
function ensureSystemReminderWrap(msg: UserMessage): UserMessage {
  // 确保所有 attachment 来源的文本都有 <system-reminder> 标签
  // 幂等：已包裹的不会重复包裹
}

6.2 注入内容类型

system-reminder 被用于注入多种类型的运行时提醒：

任务管理提醒：当模型长时间未使用 TaskCreate/TaskUpdate 时
Skill 发现提醒：可用的 skill 列表
Team 协调指令：多 Agent 场景下的角色和通信协议
上下文信息：当前日期、环境信息
MCP 服务器指令：新连接的 MCP 服务器的使用说明

6.3 Smoosh 机制

为了避免 system-reminder 破坏消息结构，实现了 smooshSystemReminderSiblings：

// src/utils/messages.ts:1820-1853
// 将 <system-reminder> 标签的 text block 合并到同一 user message 的最后一个 tool_result 中
// 防止在 tool_result 和实际用户输入之间产生多余的 Human: 消息边界

这个机制确保了：

system-reminder 不会创建额外的对话轮次
不会干扰真正的用户输入
通过 startsWith('<system-reminder>') 前缀可靠区分系统消息和用户消息

6.4 设计哲学

System Prompt 对 system-reminder 的描述揭示了其设计意图：

Tool results and user messages may include <system-reminder> tags.
<system-reminder> tags contain useful information and reminders.
They are automatically added by the system, and bear no direct relation
to the specific tool results or user messages in which they appear.

关键是最后一句：「与具体的工具结果或用户消息没有直接关系」。这告诉模型不要把 system-reminder 的内容解读为工具输出的一部分，而是作为独立的系统级指导。

七、子 Agent 约束传播：多层级的一致性保证

7.1 AgentTool 的约束传播

当主 Agent 通过 AgentTool 生成子 Agent 时，约束会被 继承和可选地收紧：

// 子 Agent 继承父 Agent 的权限模式，除非显式覆盖
// 但不能放宽：如果父 Agent 在 'plan' 模式，子 Agent 也必须在 'plan' 模式

// 子 Agent 的工具集是父 Agent 工具集的子集
const allowedTools = assembleToolPool(
  subagentPermissionContext,  // 继承 + 收紧
  subagentMcpTools            // 过滤后的 MCP 工具
)

7.2 Skill 系统的约束白名单

Skill（可复用工作流）通过 YAML frontmatter 定义了精确的工具白名单：

name: commit
allowed-tools:
  - Bash(git*)    # 只允许 git 相关的 Bash 命令
  - Read          # 允许文件读取
# 未列出的工具 → 不可用

这意味着 /commit skill 执行时，模型 无法调用 Write、Edit 等工具——确保了 commit 流程的纯净性。

7.3 验证 Agent（Ant-only）

内部版本还有一个独立的 对抗性验证 Agent：

// 非平凡实现完成后，必须生成独立的验证 Agent
// 验证 Agent 独立评估，不接受主 Agent 的自我检查
// 主 Agent 不能自行标记 PARTIAL — 只有验证 Agent 能判定

这是一个制度化的 红队机制——Agent 自己不能判定自己的工作质量。

八、架构总结：冗余驾驭的哲学

Claude Code 的 Agent Harness 体现了一个核心设计哲学：没有任何单一机制是充分的，必须依赖多层冗余约束。

Layer 1: System Prompt（宪法层）
    ↓ 定义了价值观和行为准则
Layer 2: Tool Schema（协议层）
    ↓ 约束了模型的参数空间
Layer 3: Input Validation（验证层）
    ↓ 拒绝不合法的输入
Layer 4: Permission System（权限层）
    ↓ 门控了高风险操作
Layer 5: Runtime Safety（执行层）
    ↓ 沙盒、并发控制、错误取消
Layer 6: Context Management（记忆层）
    ↓ 确保约束在长对话中不被遗忘
Layer 7: System Reminders（矫正层）
    ↓ 持续注入行为提醒
Layer 8: Budget & Circuit Breakers（兜底层）
    ↓ 绝对限制，防止一切失控

每一层都独立有效，但也假设其他层可能失效。例如：

即使 System Prompt 的行为指令被模型「遗忘」，权限系统仍然会拦截危险操作
即使权限系统被绕过（如 bypass 模式），沙盒仍然限制了 Bash 的能力
即使沙盒被禁用，USD 预算和轮次限制仍然是最后的防线

这种 深度防御（Defense in Depth） 的思路，正是 Claude Code 能在真实用户环境中稳定运行的根本原因。

关键启示

对 Agent 开发者

Prompt 不够用：仅靠 System Prompt 无法可靠控制模型行为。必须在 Schema、运行时、权限等多个层面同时施加约束。
告诉模型规则会变：让模型知道工具结果会被清理、上下文会被压缩，模型会自适应地改变行为（如主动摘录信息）。
每次模型升级都是重校准：Claude Code 的注释中充满了 @[MODEL LAUNCH] 标记，说明每次换模型都需要重新调整 prompt 和约束。
量化优于定性：「≤25 词」比「简洁」更有效，1.2% 的 token 节省在大规模使用中意义重大。
断路器是必须的：25 万次/天的无效 API 调用教训表明，Agent 系统必须有退出机制。

对安全研究者

Source Map 是攻击面：这次泄露的根因是 npm 包中的 .map 文件。所有发布 npm 包的团队都应检查构建产物。
Feature Flag 名称即情报：PROACTIVE、DAEMON、KAIROS、VOICE_MODE——flag 名称本身泄露了产品路线图。
内外部差异是攻击线索：process.env.USER_TYPE === 'ant' 分支暴露了内部版本的额外能力和更宽松的限制。

分析基于 instructkr/claude-code 镜像仓库，源码快照时间：2026-03-31

Claude Code Agent Harness 深度技术分析：如何驾驭大模型稳定输出