万字长文丨Claude Code 源码泄漏技术复盘:第一梯队 AI 公司如何打造 Harness Engineering
本次泄漏事件,表面上是一份 Claude Code 发布包,实质上却让外界第一次较完整地看到了顶级 AI Coding Agent 的工程骨架。从 cli.js.map 可恢复的大量源码来看,Claude Code 的核心并不是“会写代码的聊天机器人”,而是一套典型的 Harness Engineering 系统:它把大模型装进一个有工具注册表、权限系统、沙箱策略、计划模式、任务清单、子 Agent 协作、会话记忆、MCP/插件接入和灰度开关的可控执行框架里。结论很明确:第一梯队 AI 公司竞争的重点,已经不只是模型能力,而是如何把模型封装进一个能够稳定执行、可验证交付、可灰度运营、可持续扩展的 Harness Engineering。
大多数人看 AI Coding 产品时,注意力会自然落在模型回答得准不准、代码写得快不快、会不会自动改文件。但从工程视角看,这些只是表层表现。真正决定产品上限的,往往是下面几个问题:
-
模型如何安全地接触真实文件系统和终端
-
模型如何被约束在可解释、可审计的工具调用路径里
-
模型如何管理长任务、拆分任务、做验证、保留状态
-
产品如何把实验功能、内部能力和正式功能放进同一套 runtime
-
团队如何把 AI 能力做成平台,而不只是某个 prompt 技巧
这正是 Harness Engineering 的问题域。
如果用更通俗的话说,Harness Engineering 不是研究“模型会不会做事”,而是研究“怎样让模型在真实系统里、按可控方式、持续稳定地做事”。 这份 Claude Code 包,恰好提供了一个观察窗口。
本次分析主要基于以下文件:
-
package/package.json
-
package/cli.js
-
package/cli.js.map
其中,最关键的是 cli.js.map。它不是压缩包,而是一个 source map 文件,内部包含:
-
sources:原始源码路径
-
sourcesContent:原始源码正文
基于这份 map,内嵌源码已完整恢复到本地目录:
-
recovered-src
共恢复出约 1900 个 src/** 文件片段,用于本文中的代码核查与引用。
参考文献部分优先采用大厂官方资料,尤其是 Harness Engineering 相关文档与博客。因此,“概念框架”和“行业背景”优先锚定在:
-
Anthropic 官方博客 / 文档
-
OpenAI 官方文档
-
Google / Cloud 官方博客或文档
本文坚持两个原则:
-
代码事实优先:任何关于 Claude Code 的细节判断,优先由源码支持
-
推论有限:源码没写清的地方,不做过度猜测
也就是说,本文会区分:
-
源码事实:代码里直接能看到的模块、状态、注释、功能开关
-
工程推论:基于源码结构得出的合理解释,但不会把推论说成事实
在传统软件工程里,大家更熟悉“框架”“平台”“运行时”“编排系统”这些词。 到了 Agent 时代,Harness Engineering 可以理解为这些能力在 AI 系统中的重新组合。
它通常包括几个核心问题:
-
如何把模型能力绑定到工具能力
-
如何定义执行边界,而不是仅靠 prompt 自觉
-
如何让任务可以被拆分、追踪、验证和恢复
-
如何把长期记忆、外部系统和多 Agent 协作纳入统一执行平面
-
如何通过 feature flag、权限模式、实验开关来运营整个系统
而且,“harness”并不是为分析方便临时拼接出来的词。Anthropic 官方的 Claude Code SDK 文档明确把 SDK 描述为建立在“the agent harness that powers Claude Code”之上。这一点非常重要,因为它意味着从官方表述看,Claude Code 本身就被 Anthropic 理解为一个 agent harness。
从 Anthropic、OpenAI 等官方资料看,这个方向的关键词高度一致:
-
tool use
-
handoff / agents
-
tracing / observability
-
memory / long-running sessions
-
safety boundaries
-
evaluation harness
因此,把 Claude Code 解释为一个 Harness Engineering 案例,比把它解释为一个“强一点的 CLI 助手”要准确得多。

图 1:Harness Engineering 的重点不是模型本身,而是模型与执行环境之间的那一层系统设计
recovered-src/src/tools.ts 是最值得先看的文件之一。里面的 getAllBaseTools() 基本就是 Claude Code 执行平面的目录表:
exportfunction getAllBaseTools(): Tools {return [ AgentTool, TaskOutputTool, BashTool, ...(hasEmbeddedSearchTools() ? [] : [GlobTool, GrepTool]), ExitPlanModeV2Tool, FileReadTool, FileEditTool, FileWriteTool, NotebookEditTool, WebFetchTool, TodoWriteTool, WebSearchTool, TaskStopTool, AskUserQuestionTool, SkillTool, EnterPlanModeTool, ...(process.env.USER_TYPE === 'ant' ? [ConfigTool] : []), ...(process.env.USER_TYPE === 'ant' ? [TungstenTool] : []),
单看这一段,已经足够得出一个基础判断:
-
Claude Code 的核心不是消息窗口
-
它是一个以工具调用为中心的Agent运行时
这些工具覆盖了多个层面:
-
文件系统操作
-
终端与 PowerShell 执行
-
Web 获取与搜索
-
计划与任务清单
-
用户问答
-
技能系统
-
子Agent能力
这意味着 Claude Code 不是“让模型输出文本”,而是“让模型驱动一个被定义好的行动集合”。
同一文件里,大量工具并不是永久启用,而是跟随特性开关:
const SleepTool = feature('PROACTIVE') || feature('KAIROS') ? require('./tools/SleepTool/SleepTool.js').SleepTool : nullconst cronTools = feature('AGENT_TRIGGERS') ? [ require('./tools/ScheduleCronTool/CronCreateTool.js').CronCreateTool, require('./tools/ScheduleCronTool/CronDeleteTool.js').CronDeleteTool, require('./tools/ScheduleCronTool/CronListTool.js').CronListTool, ] : []const RemoteTriggerTool = feature('AGENT_TRIGGERS_REMOTE') ? require('./tools/RemoteTriggerTool/RemoteTriggerTool.js').RemoteTriggerTool : null
这里至少透露出三层工程信号:
-
有正式功能与实验功能并存的机制
-
有面向不同用户群、不同环境做差异化启停的能力
-
Claude Code 背后存在完整的线上配置与灰度系统
这已经不是一个“打包好的桌面小工具”的组织方式,而是成熟平台软件的组织方式。
如果说 tools.ts 展示了动作集合,那么 recovered-src/src/commands.ts 展示的就是入口集合。
文件里除了传统命令,还出现了大量能指向未来产品形态的入口:
import teleport from './commands/teleport/index.js'import chrome from './commands/chrome/index.js'import stickers from './commands/stickers/index.js'import advisor from './commands/advisor.js'import mobile from './commands/mobile/index.js'
还有按特性启用的命令:
const voiceCommand = feature('VOICE_MODE') ? require('./commands/voice/index.js').default : nullconst webCmd = feature('CCR_REMOTE_SETUP') ? ( require('./commands/remote-setup/index.js') as typeof import('./commands/remote-setup/index.js') ).default : nullconst buddy = feature('BUDDY') ? ( require('./commands/buddy/index.js') as typeof import('./commands/buddy/index.js') ).default : null
从工程角度看,这说明 Claude Code 不是单一使用场景产品,而是一个正在向多宿主环境扩张的 Agent 平台。命令层很像一层路由系统,把不同入口需求映射到统一 runtime。
工程推论可以概括为一句话:Claude Code 的 CLI,只是它当前最清晰的壳;并不意味着它的能力边界只在 CLI。
很多 AI 产品会说自己“支持 planning”。但大多数时候,这只是 prompt 层的行为。 Claude Code 不一样,它把规划做成了 runtime 的显式状态。
recovered-src/src/commands/plan/plan.tsx 中,可以看到:
if (currentMode !== 'plan') { handlePlanModeTransition(currentMode, 'plan'); setAppState(prev => ({ ...prev, toolPermissionContext: applyPermissionUpdate(prepareContextForPlanMode(prev.toolPermissionContext), {type: 'setMode', mode: 'plan', destination: 'session' }) })); const description = args.trim();if (description && description !== 'open') { onDone('Enabled plan mode', { shouldQuery: true }); } else { onDone('Enabled plan mode'); }return null;}
这段代码至少说明三件事:
-
plan 是一个显式 mode
-
mode 会驱动 toolPermissionContext 变化
-
计划流程会影响后续 query 行为
这和“模型先想一想再答”是两个层次的事情。 前者是系统状态机,后者只是语言习惯。
recovered-src/src/tools/TodoWriteTool/TodoWriteTool.ts 中,Todo 并不是 UI 装饰,而是执行主线的组成部分:
export const TodoWriteTool = buildTool({ name: TODO_WRITE_TOOL_NAME, searchHint: 'manage the session task checklist', ... async call({ todos }, context) { const appState = context.getAppState() const todoKey = context.agentId ?? getSessionId() const oldTodos = appState.todos[todoKey] ?? [] const allDone = todos.every(_ => _.status === 'completed') const newTodos = allDone ? [] : todos
这说明 Claude Code 把任务清单做成了 session state 的一部分,而不是单纯的前端展示。
同文件中最值得注意的一段,是对 verification 的提醒:
if ( feature('VERIFICATION_AGENT') && getFeatureValue_CACHED_MAY_BE_STALE('tengu_hive_evidence', false) && !context.agentId && allDone && todos.length >= 3 && !todos.some(t => /verif/i.test(t.content))) { verificationNudgeNeeded = true}
并且结果信息中还会追加明确提示:
const nudge = verificationNudgeNeeded ? \n\nNOTE: You just closed out 3+ tasks and none of them was a verification step. Before writing your final summary, spawn the verification agent... : ''
这说明 Claude Code 的工程哲学不是“做完就汇报”,而是“做完之前需要 verification”。 从 harness 角度看,这是一种非常关键的差异:系统开始主动约束交付质量,而不是只提升生成速度。

图 2:计划模式、Todo 列表与验证Agent共同组成 Claude Code 的任务控制骨架
如果只看“能改文件、能跑终端”,Claude Code 当然很强。但更值得研究的是:它如何在允许模型动手的同时,把风险压回系统边界内。
recovered-src/src/tools/BashTool/shouldUseSandbox.ts 中,有一句非常关键的注释:
// NOTE: excludedCommands is a user-facing convenience feature, not a security boundary.// It is not a security bug to be able to bypass excludedCommands — the sandbox permission// system (which prompts users) is the actual security control.
这两行注释的含义极重:
-
excludedCommands 只是交互便利层
-
真正的安全控制在 sandbox permission system
这是一种成熟安全工程常见的分层思维:不要把“用户感觉像安全”的东西,当成真正的安全边界。
recovered-src/src/utils/permissions/permissionSetup.ts 对 Bash 权限规则做了明确风险识别:
exportfunction isDangerousBashPermission( toolName: string, ruleContent: string | undefined,): boolean {if (toolName !== BASH_TOOL_NAME) {returnfalse }if (ruleContent === undefined || ruleContent === '') {returntrue }
后续还会继续匹配:
if (content === ${lowerPattern}:*) {returntrue}if (content === ${lowerPattern}*) {returntrue}if (content.startsWith(${lowerPattern} -) && content.endsWith('*')) {returntrue}
这说明系统不是简单地限制“危险命令名单”,而是在识别解释器前缀、通配规则和脚本执行入口。
PowerShell 版本更能看出这种意识:
const patterns: readonly string[] = [ ...CROSS_PLATFORM_CODE_EXEC,'pwsh','powershell','cmd','wsl','iex','invoke-expression','icm','invoke-command','start-process', ...'add-type','new-object',]
换句话说,Claude Code 关心的不是“是否运行了某个危险命令”,而是“是否打开了任意代码执行通道”。这才是 Agent 安全里最难、也最关键的部分。
同一文件还出现了动态配置读取:
const disabledCommands = getFeatureValue_CACHED_MAY_BE_STALE<{ commands: string[] substrings: string[]}>('tengu_sandbox_disabled_commands', { commands: [], substrings: [] })
这说明安全策略不是纯本地静态逻辑,而是可以通过远端配置影响行为。这类设计只有在产品已经进入大规模运营阶段时才会成为必需。
工程推论是:Anthropic 已经把安全策略当成一个持续运营系统,而不是一次性实现。
很多产品会宣传“多 agent”,但源码里真正能看出深度的并不多。Claude Code 这一份包,算是证据相当充足的。
recovered-src/src/tools/AgentTool/builtInAgents.ts 中,可以直接看到内建 Agent 定义来源:
import { CLAUDE_CODE_GUIDE_AGENT } from './built-in/claudeCodeGuideAgent.js'import { EXPLORE_AGENT } from './built-in/exploreAgent.js'import { GENERAL_PURPOSE_AGENT } from './built-in/generalPurposeAgent.js'import { PLAN_AGENT } from './built-in/planAgent.js'import { STATUSLINE_SETUP_AGENT } from './built-in/statuslineSetup.js'import { VERIFICATION_AGENT } from './built-in/verificationAgent.js'
组合逻辑也很直白:
const agents: AgentDefinition[] = [ GENERAL_PURPOSE_AGENT, STATUSLINE_SETUP_AGENT,]if (areExplorePlanAgentsEnabled()) { agents.push(EXPLORE_AGENT, PLAN_AGENT)}if ( feature('VERIFICATION_AGENT') && getFeatureValue_CACHED_MAY_BE_STALE('tengu_hive_evidence', false)) { agents.push(VERIFICATION_AGENT)}
这说明 Claude Code 不是只有一个“大总管 Agent”,而是已经形成了相对清晰的角色分工:
-
通用执行
-
探索
-
规划
-
验证
-
辅助设置
recovered-src/src/tools/shared/spawnMultiAgent.ts 中,文件开头就写明:
/**Shared spawn module for teammate creation.Extracted from TeammateTool to allow reuse by AgentTool.*/
继续往下,会看到非常重的组织化命名:
import { SWARM_SESSION_NAME, TEAM_LEAD_NAME, TEAMMATE_COMMAND_ENV_VAR, TMUX_COMMAND,} from '../../utils/swarm/constants.js'
以及生成结果结构:
exporttype SpawnOutput = { teammate_id: string agent_id: string agent_type?: string model?: string name: string color?: string tmux_session_name: string tmux_window_name: string tmux_pane_id: string team_name?: string is_splitpane?: boolean plan_mode_required?: boolean}
这些命名串在一起,足够支持一个强判断:
-
Claude Code 内部确实有“团队协作式 Agent”抽象
-
它支持 teammate、team lead、swarm 这类概念
-
终端编排层甚至考虑了 tmux
这背后真正的工程意义是:Anthropic 已经不满足于让一个模型实例调用工具,而是在构建一个能够拆分劳动力、组织多个执行单元的系统。
这正是 Harness Engineering 进入下一阶段的标志。

图 3:Claude Code 暴露出的不仅是 sub-agent,而是具备 team/swarm 语义的组织层设计
recovered-src/src/services/SessionMemory/sessionMemory.ts 中,记忆提取逻辑非常清晰:
exportfunction shouldExtractMemory(messages: Message[]): boolean { const currentTokenCount = tokenCountWithEstimation(messages)if (!isSessionMemoryInitialized()) {if (!hasMetInitializationThreshold(currentTokenCount)) {returnfalse } markSessionMemoryInitialized() }
继续往下:
const shouldExtract = (hasMetTokenThreshold && hasMetToolCallThreshold) || (hasMetTokenThreshold && !hasToolCallsInLastTurn)
它综合考虑了:
-
token 阈值
-
工具调用次数
-
当前回合是否适合做抽取
这说明 Claude Code 对记忆的处理是“何时抽取、何时压缩、何时持久化”的工程问题,而不是“把历史都拼接进去”的简单问题。
同文件还可以看到文件创建时的权限设置:
await fs.mkdir(sessionMemoryDir, { mode: 0o700 })...await writeFile(memoryPath, '', { encoding: 'utf-8', mode: 0o600, flag: 'wx',})
这说明连 session memory 都不是草率写入,而是按受控数据来处理的。这与 Anthropic 文档里对安全、隐私与企业可用性的强调是一致的。
recovered-src/src/services/mcp/config.ts 中,可以看到对 MCP 配置的完整管理逻辑。比如企业托管路径:
exportfunction getEnterpriseMcpFilePath(): string {return join(getManagedFilePath(), 'managed-mcp.json')}
写入 .mcp.json 时,还采用了原子写入逻辑:
const tempPath = ${mcpJsonPath}.tmp.${process.pid}.${Date.now()}const handle = await open(tempPath, 'w', existingMode ?? 0o644)...await handle.datasync()...await rename(tempPath, mcpJsonPath)
这种写法很像成熟基础设施软件,而不像临时功能。
同文件中还有一个很有代表性的函数:
exportfunction getMcpServerSignature(config: McpServerConfig): string | null { const cmd = getServerCommandArray(config)if (cmd) {return stdio:${jsonStringify(cmd)} } const url = getServerUrl(config)if (url) {return url:${unwrapCcrProxyUrl(url)} }return null}
这说明 Claude Code 在意的是:
-
两个名字不同的 server,是否其实指向同一个底层连接
-
插件配置与手工配置是否实际上重复
这是一种平台级 dedup 思维,不是简单 UI 配置页会有的思路。
工程推论是:Claude Code 正在把自己打造为一个“Agent OS风格”的执行宿主,MCP 和插件是扩展边界。
先看命令入口,在 recovered-src/src/commands.ts:
const buddy = feature('BUDDY') ? ( require('./commands/buddy/index.js') as typeof import('./commands/buddy/index.js') ).default : null
再看全局状态,在 recovered-src/src/state/AppStateStore.ts:
companionReaction?: string// Timestamp of last /buddy pet — CompanionSprite renders hearts while recentcompanionPetAt?: number
再看渲染层,在 recovered-src/src/buddy/CompanionSprite.tsx:
const PET_BURST_MS = 2500; // how long hearts float after /buddy petconst PET_HEARTS = [ ${H}${H} , ${H}${H}${H} , ${H}${H}${H} , ${H}${H}${H} , '· · · '];以及:const petAt = useAppState(s => s.companionPetAt);...const petting = petAge * TICK_MS < PET_BURST_MS;
基于这些代码,可以稳妥地下结论:
-
Claude Code 存在一个受 BUDDY feature gate 控制的 companion/buddy 系统
-
其中至少包含 /buddy pet 一类交互
-
该交互会驱动 UI 状态更新,并触发爱心动画反馈
但仍不能进一步断言:
-
完整玩法是什么
-
会不会正式公开
-
它在商业产品中的定位是什么
源码能支持的边界,就到这里。

图 4:基于 Buddy 代码线索单独复现的 pet 功能 demo
recovered-src/src/commands/stickers/stickers.ts 中:
export async function call(): Promise<LocalCommandResult> { const url = 'https://www.stickermule.com/claudecode' const success = await openBrowser(url)
这说明 Claude Code 的终端体验里,已经开始混入品牌化和轻娱乐化组件。 它不是核心能力,但它是产品成熟度的一个信号:团队开始经营用户关系,而不是只经营能力。
recovered-src/src/commands/review.ts 中:
const ultrareview: Command = {type: 'local-jsx', name: 'ultrareview', description: ~10–20 min · Finds and verifies bugs in your branch. Runs in Claude Code on the web. See ${CCR_TERMS_URL}, isEnabled: () => isUltrareviewEnabled(), load: () => import('./review/ultrareviewCommand.js'),}
这说明至少存在一种“本地入口触发、Web 侧执行或配合执行”的工作流。 这进一步支持前文判断:Claude Code 的真实边界并不等于“一个本地 CLI”。

图 5:Buddy、Stickers、Ultrareview 等线索共同说明 Claude Code 内部存在分层开放的产品能力池
把前面的代码事实收束起来,Claude Code 至少给出了一幅非常清晰的行业图景。
在 Claude Code 这份包里,最重的部分不是聊天,也不是提示词,而是:
-
工具调用系统
-
权限模式
-
沙箱控制
-
状态管理
-
子 Agent 与组织协作
-
记忆与任务持久化
-
MCP/插件生态
-
Feature flag 与灰度实验
这说明第一梯队 AI 公司真正建设的是一个“模型执行底座”。
为什么 Anthropic、OpenAI、Google 都越来越强调 tools、agents、tracing、evals、handoffs?因为单纯“生成文本”已经不够了。
真正能进入生产环境的系统,必须满足:
-
可控
-
可观测
-
可恢复
-
可扩展
-
可验证
-
可运营
Claude Code 的源码恰好把这些要求都映射到了具体模块上。
这个说法可能听起来有点重,但从这份包看,它并不夸张。Claude Code 已经在做下面这些事情:
-
定义工具
-
控制权限
-
管理进程与终端
-
跟踪任务
-
维护状态
-
调度子Agent
-
接入外部系统
-
用配置系统控制行为
这已经非常接近一个面向 Agent 的应用运行平台。
这次事件最值得复盘的,不是“Claude Code 里面有什么小技巧”,而是顶级 AI 公司到底在怎样做工程。
从源码能得到的核心结论有四点:
Claude Code 的真正核心是工具化执行 runtime,而不是聊天界面
安全边界主要由权限系统、规则匹配、沙箱与模式状态共同实现,而不是靠 prompt 自律
任务规划、验证、子 Agent 协作和记忆提取已经被工程化为系统能力
MCP、插件、远程能力、Buddy 等 feature-gated 模块说明 Claude Code 正在向平台化 Agent 系统演化
因此,如果要用一句话概括 Claude Code 在这份源码里暴露出来的本质,那就是:
Anthropic 做的不是一个“更会写代码的助手”,而是一套让模型可以在真实世界里受控执行的 Harness Engineering 系统。
参考资料
A. 官方博客 / 官方文档
【1】:AI正在“接管”软件工程,但系统正在慢慢失控:http://mp.weixin.qq.com/s/OHlQE3FerJRnHJ2KNjEGEw
【2】:https://docs.anthropic.com/en/docs/claude-code/
【3】:https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
【4】:https://platform.openai.com/docs/docs-mcp
【5】:https://cloud.google.com/blog/topics/developers-practitioners/a-methodical-approach-to-agent-evaluation
【6】:https://mitchellh.com/writing/my-ai-adoption-journey
【7】:工程技术:在智能体优先的世界中利用 Codex:https://openai.com/zh-Hans-CN/index/harness-engineering/
B. 外部讨论线索
【1】:YukerX, X/Twitter: https://x.com/yukerx/status/2038959908968919297
【2】:agintender, X/Twitter: https://x.com/agintender/status/2038921508999901274
C. 本地源码证据
【1】:package/package.json
【2】:package/cli.js.map
【3】:tools.ts
【4】:commands.ts
【5】:plan.tsx
【6】:TodoWriteTool.ts
【7】:permissionSetup.ts
【8】:shouldUseSandbox.ts
【9】:builtInAgents.ts
【10】:spawnMultiAgent.ts
【11】:sessionMemory.ts
【12】:config.ts
【13】:AppStateStore.ts
【14】:CompanionSprite.tsx
【15】:stickers.ts
【16】:review.ts
撰稿:菠萝吹雪
编辑:空格
审核:Joy
玉衡实验室是华清未央旗下开展前瞻科技研发的实验室,我们秉持“独到、精准、深刻”的内容理念,致力于为决策者、创新者和思想者提供具有穿透力的观点与洞见,在众声喧哗中辨别真正价值。

夜雨聆风