乐于分享
好东西不私藏

万字长文丨Claude Code 源码泄漏技术复盘:第一梯队 AI 公司如何打造 Harness Engineering

万字长文丨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 包,恰好提供了一个观察窗口。

二、研究方法与证据边界
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 执行平面的目录表:

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 不是“让模型输出文本”,而是“让模型驱动一个被定义好的行动集合”。

02
大量能力被 feature gate 包裹,说明这是平台级产品

同一文件里,大量工具并不是永久启用,而是跟随特性开关:

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 背后存在完整的线上配置与灰度系统

这已经不是一个“打包好的桌面小工具”的组织方式,而是成熟平台软件的组织方式。

五、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。

六、计划模式、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 权限规则做了明确风险识别:

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 安全里最难、也最关键的部分。

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'

以及生成结果结构:

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 语义的组织层设计

九、会话记忆与长程执行:Claude Code 在做的是状态化 Agent,而不是一次性问答

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 对记忆的处理是“何时抽取、何时压缩、何时持久化”的工程问题,而不是“把历史都拼接进去”的简单问题。

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 配置的完整管理逻辑。比如企业托管路径:

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)

这种写法很像成熟基础设施软件,而不像临时功能。

02
去重逻辑按“底层连接签名”做,而不是按名字做

同文件中还有一个很有代表性的函数:

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 和插件是扩展边界。

十一、彩蛋与未公开能力:哪些能确认,哪些不能
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 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

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乐趣~