文章总结： 本文通过分析ClaudeCode源码泄漏事件，揭示其核心为HarnessEngineering系统而非单纯AI聊天机器人。关键发现包括工具注册表、权限系统、沙箱策略、计划模式等框架设计，表明顶级AI公司竞争重点已转向将模型封装进可控执行环境。可操作建议包括关注工具绑定、执行边界定义及灰度运营等工程实践。 综合评分： 85 文章分类： 漏洞分析,AI安全,安全建设,解决方案,技术标准
万字长文丨Claude Code 源码泄漏技术复盘：第一梯队 AI 公司如何打造 Harness Engineering
玉衡实验室 玉衡实验室
山海之关
2026年4月1日 18:27 北京
摘要
本次泄漏事件，表面上是一份 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 包，恰好提供了一个观察窗口。
二、研究方法与证据边界
01
一手证据：当前目录中的打包产物与 Source Map
本次分析主要基于以下文件：
-
package/package.json
-
package/cli.js
-
package/cli.js.map
其中，最关键的是 cli.js.map。它不是压缩包，而是一个 source map 文件，内部包含：
- sources：原始源码路径
- sourcesContent：原始源码正文
基于这份 map，内嵌源码已完整恢复到本地目录：
- recovered-src
共恢复出约 1900 个 src/** 文件片段，用于本文中的代码核查与引用。
02
二手证据：官方博客、官方文档、官方账号可验证资料
参考文献部分优先采用大厂官方资料，尤其是 Harness Engineering 相关文档与博客。因此，“概念框架”和“行业背景”优先锚定在：
- Anthropic 官方博客 / 文档
- OpenAI 官方文档
- Google / Cloud 官方博客或文档
#
03
分析边界
本文坚持两个原则：
- 代码事实优先：任何关于 Claude Code 的细节判断，优先由源码支持
- 推论有限：源码没写清的地方，不做过度猜测
也就是说，本文会区分：
- 源码事实：代码里直接能看到的模块、状态、注释、功能开关
- 工程推论：基于源码结构得出的合理解释，但不会把推论说成事实
三、什么是 Harness Engineering，为什么它适合解释 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 的重点不是模型本身，而是模型与执行环境之间的那一层系统设计
四、从源码看 Claude Code 的真实形态：它首先是一个工具执行框架
01
工具注册表说明了一切
recovered-src/src/tools.ts 是最值得先看的文件之一。里面的 getAllBaseTools() 基本就是 Claude Code 执行平面的目录表：
export function 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 不是“让模型输出文本”，而是“让模型驱动一个被定义好的行动集合”。
02
大量能力被 feature gate 包裹，说明这是平台级产品
同一文件里，大量工具并不是永久启用，而是跟随特性开关：
const SleepTool =
feature('PROACTIVE') || feature('KAIROS')
? require('./tools/SleepTool/SleepTool.js').SleepTool
: null
const 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 背后存在完整的线上配置与灰度系统
这已经不是一个“打包好的桌面小工具”的组织方式，而是成熟平台软件的组织方式。
五、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
: null
const webCmd = feature('CCR_REMOTE_SETUP')
? (
require('./commands/remote-setup/index.js') as typeof import('./commands/remote-setup/index.js')
).default
: null
const 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。
六、计划模式、Todo、验证 Agent：这不是“会规划”，而是“把规划做成系统状态”
很多 AI 产品会说自己“支持 planning”。但大多数时候，这只是 prompt 层的行为。 Claude Code 不一样，它把规划做成了 runtime 的显式状态。
01
Plan Mode 是一个真模式，而不是口头承诺
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 行为
这和“模型先想一想再答”是两个层次的事情。 前者是系统状态机，后者只是语言习惯。
02
Todo 是执行骨架的一部分
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 的一部分，而不是单纯的前端展示。
03
验证不是“可选美德”，而是被编码进工作流的要求
同文件中最值得注意的一段，是对 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 真正的硬核部分
如果只看“能改文件、能跑终端”，Claude Code 当然很强。但更值得研究的是：它如何在允许模型动手的同时，把风险压回系统边界内。
01
源码明确区分“用户便利功能”和“真正安全边界”
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
这是一种成熟安全工程常见的分层思维：不要把“用户感觉像安全”的东西，当成真正的安全边界。
02
Claude Code 防的不是某个命令，而是“任意代码执行入口”
recovered-src/src/utils/permissions/permissionSetup.ts 对 Bash 权限规则做了明确风险识别：
export function 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 安全里最难、也最关键的部分。
03
安全策略带有明显的线上运营特征
同一文件还出现了动态配置读取：
const disabledCommands = getFeatureValue_CACHED_MAY_BE_STALE<{
commands: string[]
substrings: string[]
}>('tengu_sandbox_disabled_commands', { commands: [], substrings: [] })
这说明安全策略不是纯本地静态逻辑，而是可以通过远端配置影响行为。这类设计只有在产品已经进入大规模运营阶段时才会成为必需。
工程推论是：Anthropic 已经把安全策略当成一个持续运营系统，而不是一次性实现。
八、多 Agent 与协同：Claude Code 在构建“AI 劳动力组织层”
很多产品会宣传“多 agent”，但源码里真正能看出深度的并不多。Claude Code 这一份包，算是证据相当充足的。
01
内建 Agent 角色是明确存在的
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”，而是已经形成了相对清晰的角色分工：
- 通用执行
- 探索
- 规划
- 验证
- 辅助设置
#
02
“Teammate / Swarm / Team Lead” 不是比喻，而是真实工程对象
#
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'
以及生成结果结构：
export type 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 语义的组织层设计
九、会话记忆与长程执行：Claude Code 在做的是状态化 Agent，而不是一次性问答
recovered-src/src/services/SessionMemory/sessionMemory.ts 中，记忆提取逻辑非常清晰：
export function shouldExtractMemory(messages: Message[]): boolean {
const currentTokenCount = tokenCountWithEstimation(messages)
if (!isSessionMemoryInitialized()) {
if (!hasMetInitializationThreshold(currentTokenCount)) {
return false
}
markSessionMemoryInitialized()
}
继续往下：
const shouldExtract =
(hasMetTokenThreshold && hasMetToolCallThreshold) ||
(hasMetTokenThreshold && !hasToolCallsInLastTurn)
它综合考虑了：
- token 阈值
- 工具调用次数
- 当前回合是否适合做抽取
这说明 Claude Code 对记忆的处理是“何时抽取、何时压缩、何时持久化”的工程问题，而不是“把历史都拼接进去”的简单问题。
02
本地记忆文件被当成受控资源处理
同文件还可以看到文件创建时的权限设置：
await fs.mkdir(sessionMemoryDir, { mode: 0o700 })
...
await writeFile(memoryPath, '', {
encoding: 'utf-8',
mode: 0o600,
flag: 'wx',
})
这说明连 session memory 都不是草率写入，而是按受控数据来处理的。这与 Anthropic 文档里对安全、隐私与企业可用性的强调是一致的。
#
十、MCP、插件与生态接入：Claude Code 明显在往 Agent 平台演化
01
MCP 不是附加功能，而是核心平台接口
recovered-src/src/services/mcp/config.ts 中，可以看到对 MCP 配置的完整管理逻辑。比如企业托管路径：
export function 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)
这种写法很像成熟基础设施软件，而不像临时功能。
02
去重逻辑按“底层连接签名”做，而不是按名字做
同文件中还有一个很有代表性的函数：
export function 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 和插件是扩展边界。
#
十一、彩蛋与未公开能力：哪些能确认，哪些不能
01
Buddy / Companion 是最扎实的隐藏功能线索
先看命令入口，在 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 recent
companionPetAt?: number
再看渲染层，在 recovered-src/src/buddy/CompanionSprite.tsx：
const PET_BURST_MS = 2500; // how long hearts float after /buddy pet
const 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
02
Stickers 是一个轻量但真实的品牌彩蛋
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 的终端体验里，已经开始混入品牌化和轻娱乐化组件。 它不是核心能力，但它是产品成熟度的一个信号：团队开始经营用户关系，而不是只经营能力。
03
“Web 上运行的代码审查”也是值得关注的信号
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 的真正启示：第一梯队 AI 公司在造什么
#
把前面的代码事实收束起来，Claude Code 至少给出了一幅非常清晰的行业图景。
01
领先产品的竞争重心已经从“模型输出”转向“系统执行”
在 Claude Code 这份包里，最重的部分不是聊天，也不是提示词，而是：
- 工具调用系统
- 权限模式
- 沙箱控制
- 状态管理
- 子 Agent 与组织协作
- 记忆与任务持久化
- MCP/插件生态
- Feature flag 与灰度实验
这说明第一梯队 AI 公司真正建设的是一个“模型执行底座”。
02
Harness Engineering 正在成为 AI 原生软件的新基础设施层
为什么 Anthropic、OpenAI、Google 都越来越强调 tools、agents、tracing、evals、handoffs？因为单纯“生成文本”已经不够了。
真正能进入生产环境的系统，必须满足：
- 可控
- 可观测
- 可恢复
- 可扩展
- 可验证
- 可运营
Claude Code 的源码恰好把这些要求都映射到了具体模块上。
03
所谓“AI 软件工程”，本质上越来越像“把模型放进操作系统”
这个说法可能听起来有点重，但从这份包看，它并不夸张。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
关于我们
玉衡实验室是华清未央旗下开展前瞻科技研发的实验室，我们秉持“独到、精准、深刻”的内容理念，致力于为决策者、创新者和思想者提供具有穿透力的观点与洞见，在众声喧哗中辨别真正价值。
玉衡实验室
关注我们，一同探索AI乐趣~
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：山海之关 玉衡实验室 玉衡实验室《万字长文丨Claude Code 源码泄漏技术复盘：第一梯队 AI 公司如何打造 Harness Engineering》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论