AI Agent 源码泄露后，真正难复制的是任务托付系统

Claude Code 的大规模内部源码因发布失误被暴露，Grok Bot 的客户端运行层也被外部开发者重建。两起事件降低了外界理解和模仿 AI Agent 的成本，却没有让成熟产品的全部价值随代码一起转移。真正难复制的，是一套让用户敢于持续交出真实工作的“任务托付系统”。

2026 年，两个受到高度关注的 AI Agent 产品，先后以不同方式被外界“拆开”。

3 月 31 日，Claude Code 2.1.88 的公开发布资产中误带了内部调试文件。外界由此获得了接近 2,000 个文件、约 50 万行内部代码，也看到了部分未正式发布的功能方向。

Anthropic 将其定性为人为造成的发布打包问题，而不是外部攻击，并表示没有客户数据或凭证受到影响。

8 月 11 日，Grok Bot 以 Early Beta 形式推出。

官方把它描述为一组长期在线的 AI 同事：能够在云电脑中登录工具和应用，执行跨系统任务，并在用户离开后继续工作。随后，外部开发者依据 0.18.0 客户端中的 Source Map、协议和运行信息，发布了一个可以重新构建运行的非官方项目。

最开始看到这两个事件时，人很容易被“源码泄露”四个字带着走。

既然代码已经被公开、恢复，甚至可以在原有结构上接入 Claude Code、Codex、OpenRouter 和本地 Docker，原产品的护城河是不是也跟着消失了？

最省事的回答是：

代码已经不重要了。

但这个判断显然经不起推敲。

Claude Code 的源码暴露，确实让竞争者能够更快理解一套生产级 Coding Agent 如何组织上下文、工具、记忆、权限和任务状态。

Grok Bot 的重建项目也证明，只要正式客户端留下足够多的结构信息，外部团队就可能重新理解它的运行边界，并在此基础上替换模型、调整执行环境，甚至做出另一套产品选择。

代码仍然是重要资产。

问题在于，代码并不等于一款 AI Agent 的全部产品价值。

源码可以展示一个 Agent 怎样运行，却不会同时附带真实用户任务、历史失败案例、评测标准、企业权限要求、用户工作习惯、分发渠道和持续服务能力。

源码可以复制产品的骨架，却不能直接复制用户为什么愿意把工作交出去。

这两起事件真正划出的是一条产品边界：

看见一款 Agent 的内部结构，与复制一款成熟 Agent 产品，是两件不同的事。

说明：本文基于公开报道、官方产品文档及公开重建项目信息进行分析。作者没有运行非官方 Grok Bot 重建安装包，也不对其安全性作出判断。

01 先别急着把它们都叫作“完整源码泄露”

Claude Code 和 Grok Bot 可以放在一起讨论，但两起事件的性质并不相同。

Claude Code：产品主动交付时，发布边界失效了

Source Map 原本是一种调试资产。

软件正式发布前，代码通常会经过压缩、合并或转换。Source Map 负责把这些处理后的代码映射回更接近原始开发代码的位置。

有些 Source Map 只记录映射关系，有些也会包含原始代码内容。正式发布物一旦保留足够完整的信息，外界恢复可读代码的成本就会显著降低。

Claude Code 事件的核心，不是攻击者攻破了 Anthropic 的内部系统，而是公司在主动交付产品时，把原本不应对外发布的内部资产一起发了出去。

外界获得的也不只是一批 TypeScript 文件。

源码还暴露了内部架构、功能开关、产品指令，以及部分尚未上线的功能方向。原本需要通过竞品体验、版本更新、招聘信息和长期试验逐渐拼出的产品路线，一部分变成了可以直接阅读和验证的答案。

这类泄露的商业价值，不能只用代码行数衡量。

代码中还记录了产品团队已经做出的选择：

• 哪些能力值得单独设计一个模块；
• 哪些行为可以交给模型判断；
• 哪些行为必须使用确定性规则；
• 长期记忆怎样组织；
• 权限在哪个环节生效；
• 任务怎样保存进度；
• 哪些功能已经开发完成，只是尚未正式开放。
• 暴露的既是“怎样实现”，也是团队认为“什么值得实现”。

但这次事件同样有明确边界。

公开材料涉及的是 Claude Code 产品的大规模内部代码，并不等于 Claude 底层模型的权重、训练数据和 Anthropic 的完整商业基础设施被公开。

因此，更准确的描述是：

Claude Code 的大规模内部产品代码和部分路线信息，因为发布打包失误而被暴露。

这已经是一项严重的产品资产事故，但它不等于“整个 Claude 被开源”。

Grok Bot：运行层被重建，社区又继续改造了它

Grok Bot 的情况不同。

公开重建项目明确说明，它不是官方原始 monorepo，而是一个非官方、面向源码的重建与扩展项目。

原始 React 前端源码和对应 Source Map 并未包含在正式客户端中，因此重建版本保留了已打包、压缩的 Renderer 作为界面基础，再把恢复出的运行代码和新设置界面接入其中。

项目中的 Claude Code、Codex、OpenRouter 路由，以及可选的本地 Docker 沙箱，也属于重建者后来增加的实验能力，并非从官方产品中发现的隐藏功能。

所以，不能把这件事概括成：

Grok Bot 的完整官方源码已经全部开源，而且原产品本来就支持 Claude Code、Codex 和本地 Docker。

更准确的说法是：

Grok Bot 0.18.0 客户端暴露的信息，使外部开发者得以重建部分运行层和控制层，并在保留部分官方发布资产的基础上，继续增加新的模型路由和执行方式。

Claude Code 更像是公司不小心把一部分内部设计图发出了门。

Grok Bot 则更像有人拿到成品、部分结构标记和运行线索后，拆开机器，重新画出零件，又换上了几个自己设计的模块。

两者性质不同，却共同改变了一件事：

外界理解一款成熟 AI Agent 的成本正在下降。

02 复制一个 AI Agent，至少存在四个层级

谈论“源码被公开以后，产品是不是很容易复制”，首先要重新定义什么叫复制。

拿到代码、做出相似功能、交付相近结果，以及建立一项可以持续收费的业务，显然不是同一件事。

可以把复制一款 AI Agent 拆成四层。

第一层：代码复制

复制或重新实现：

• Agent 的任务循环；
• 模型与工具之间的连接；
• 上下文和状态管理；
• 客户端与执行环境之间的通信；
• 权限判断；
• 异常处理；
• 任务调度。

它回答的是：

这套系统大致怎样运转？

第二层：功能复制

做出相似的可见能力：

• Memory；
• Skills；
• Routines；
• Sub-agents；
• MCP；
• 浏览器和终端操作；
• 权限审批；
• 后台任务。

它回答的是：

用户可以在产品里做什么？

第三层：产品复制

让用户在真实任务中获得接近原产品的结果：

• 相近的任务完成率；
• 相近的稳定性；
• 相近的人工接管率；
• 相近的权限体验；
• 相近的验证和恢复能力；
• 相近的长期工作流沉淀。

它回答的是：

用户能不能放心地把工作交给它？

第四层：商业复制

让产品能够长期获得用户和收入：

• 分发与获客；
• 账号和计费；
• 企业采购；
• 身份和权限；
• 部署、运维与支持；
• 成本管理；
• 合规与事故责任；
• 持续版本升级。

它回答的是：

这套产品能不能成为一项持续运转的业务？

Claude Code 和 Grok Bot 的事件，主要降低了第一层的理解成本，也在一定程度上降低了第二层的模仿成本。

第三层和第四层，不会随着代码公开自动出现。

03 代码复制：最先被抹平的是理解成本

强调代码之外的产品能力，很容易走到另一个极端：

既然用户最终购买的是任务结果，代码是不是已经没有价值了？

答案是否定的。

成熟 Agent 的源码，更像一份被压缩过的产品决策记录。

它不只包含“工程师怎样实现”，还记录了团队最终选择了哪条路线：

• 上下文应该怎样组织；
• 长期记忆在什么时候读取；
• 任务是否值得拆给多个 Agent；
• 哪些动作可以依赖模型判断；
• 哪些动作必须采用确定性规则；
• 什么时候减少打扰；
• 什么时候一定要让用户确认；
• 发生异常后应该重试，还是立即停止。

这些都不只是工程问题。

源码把“探索题”变成了“阅读题”

团队从零开始开发 Agent 时，最昂贵的部分未必是写代码。

更昂贵的是不知道应该写什么。

产品团队需要不断验证：

• 用户是否真的需要长期记忆；
• 多 Agent 能提升结果，还是只会增加成本；
• 审批应该出现在什么节点；
• 自动化应该从只读任务开始，还是直接执行外部动作；
• 任务中断后如何保留已完成部分；
• 产品怎样判断“任务完成”。

这些问题没有统一答案。

每一种选择，都牵涉模型能力、用户体验、执行成本和安全风险。

源码暴露后，后来者会获得一份已经做出大量选择的答卷。

它未必适合自己的产品，却足以帮助团队快速缩小探索范围。

原本需要从十种方案中逐一试验，现在可能只需要重点研究两三种；

原本不知道竞争者是否已经进入某个方向，现在可以从功能开关和预留接口中看到线索；

原本只能通过界面猜测产品限制，现在能够进一步理解限制来自哪里。

这也是 Claude Code 事件最实际的竞争影响之一。

Axios 对这次事件的概括很直接：它相当于给竞争者提供了一次关于生产级 Coding Agent 的免费工程教育。

看懂之后，后来者还可以重新组合产品

Grok Bot 重建项目进一步展示了，理解结构以后可以做什么。

开发者没有停留在“照着做一个相同版本”，而是把模型和部分执行环境重新变成可替换组件。

项目增加了 Claude Code、Codex、OpenRouter 等路由，以及可选的本地 Docker 沙箱。

重建版本因此不只是一份复制品，也变成了一次关于多模型、开放执行环境和本地化的产品实验。

这意味着，源码暴露带来的风险不只是出现一个外观相似的仿制品。

外部团队还可能：

• 替换底层模型；
• 改变推理成本结构；
• 使用本地或私有执行环境；
• 面向另一类用户重新设计；
• 把封闭产品拆成更开放的平台。

一旦产品结构被理解，后来者就可以直接以原产品已经验证过的骨架为起点，转向另一条路线。

但源码仍然是一份静态答卷

代码能够展示当前版本怎样运行，却很少完整记录：

• 团队曾经尝试过哪些失败方案；
• 为什么放弃另一种交互；
• 哪些功能在演示中漂亮，真实使用率却很低；
• 哪些默认值来自用户反馈，哪些只是暂时妥协；
• 什么错误最容易让用户失去信任；
• 下一次模型升级后，哪些设计可能失效。

这些信息通常分散在用户访谈、客服记录、销售反馈、产品数据、线上事故和内部复盘里。

它们未必存在于核心代码中，却持续决定团队下一步改什么。

源码可以缩短竞争者理解昨天产品的时间，却不会自动告诉他们明天应该改什么。

04 功能复制：最容易实现的是“看起来差不多”

AI Agent 的功能正在快速趋同。

打开不同产品的介绍页，经常可以看到一组相似的词：Memory、Skills、Hooks、Sub-agents、Routines、Approvals、MCP、Computer Use。

Claude Code 可以通过 CLAUDE.md、Auto Memory 和 Skills 保存项目知识、长期纠正和重复流程；自定义 Sub-agent 可以拥有独立上下文、工具和权限；Hooks 则允许团队在特定生命周期节点执行确定性规则。

Grok Bot 同样把 Skill 和 Routine 做成了核心能力。

官方建议先完成一次任务，使流程变得可靠；再把方法保存为 Skill；最后才把它设置成定时或事件触发的 Routine。

一份完整的 Skill 还应包含步骤、决策规则、预期结果、验证方式和审批边界。

从功能列表看，两类产品正在进入相似方向。

但相同的功能名称，并不代表相同的产品体验。

有 Memory，不等于能够记对

用户真正关心的不是产品有没有记忆，而是：

• 它记住了什么；
• 什么时候调用；
• 是否会保存错误内容；
• 用户能否查看、修改和删除；
• 旧信息会不会干扰新任务；
• 不同项目之间是否正确隔离。

Claude Code 的 Auto Memory 本身就有明确的存储范围、加载限制和编辑入口。记忆文件可以被用户审查和删除，详细内容也不会全部在每次会话开始时无差别加载。

“增加一个 Memory 入口”很容易复制。

让记忆长期保持准确、可控和有用，则需要持续的产品设计。

有 Skill，不等于流程可以稳定复用

Skill 表面上像是把一段指令保存下来。

真正有价值的 Skill 还要明确：

• 什么时候触发；
• 需要哪些输入和权限；
• 按照什么顺序执行；
• 结果怎样验证；
• 失败时停在哪里；
• 哪些动作必须重新询问用户。

一套不稳定的流程被保存下来，只会让错误更容易重复。

一个缺少验证规则的 Skill，也可能每次用不同方式理解“完成”。

有 Routine，不等于可以无人值守

从一次执行走向后台自动化，不是简单增加一个定时器。

产品还要解决：

• 数据过期时是否继续；
• 任务只完成一半时怎样汇报；
• 重复触发会不会造成重复操作；
• 外部接口变化后能否发现异常；
• 连续失败后应该重试还是暂停；
• 任务消耗了多少资源；
• 用户怎样查看最近的成功和失败。

Grok Bot 在官方文档中反复强调：

先测试任务，先让准备过程稳定，再逐渐开放真正的外部执行；重试应尽量保持幂等，数据缺失和部分完成也要被明确报告。

这背后是一条非常重要的 Agent 产品原则：

先证明任务可以完成，再证明过程可以复用，最后才证明它值得自动运行。

否则，所谓自动化，只是把一次不稳定执行升级成定期发生的不稳定执行。

有 Approval，不等于用户真正拥有控制权

审批是 Agent 产品中最常见的安全设计。

发送邮件、删除数据、运行命令或修改线上系统之前弹出确认，看起来已经把控制权交还给用户。

但审批卡片的存在只是起点。

真正影响体验的是：

• 用户能否理解操作对象和影响；
• 同意的是一次动作，还是未来所有相似动作；
• 提示太多时，用户会不会机械点击同意；
• 拒绝后，Agent 能不能换一种安全方式继续；
• 动作执行以后能否撤回。

Anthropic 在 2026 年 3 月介绍 Claude Code Auto Mode 时披露，用户会批准约 93% 的权限请求。

它同时指出，高频审批会造成审批疲劳：提示越多，用户越难认真判断每一次操作。

因此，审批越多不一定越安全。

如果所有操作都以同样形式出现，真正高风险的动作反而会被淹没在大量低风险确认中。

Grok Bot 的官方文档也明确说明，审批只能控制即将执行的动作，不能反转已经完成的工作；Auto Review 属于模型驱动的辅助判断，不能替代最小权限和明确边界。

功能表只能回答“有没有”

产品经理最容易陷入的竞争方式，是按照竞品名词追路线图：

• 对方有 Memory，我们也要做；
• 对方有多 Agent，我们也必须跟进；
• 对方可以创建 Routine，我们也需要自动化入口。

但真正需要对齐的不是名词，而是用户任务。

团队应该继续追问：

• 用户当前在哪一步失败；
• 缺少的是理解、执行、验证还是恢复；
• 新功能能否提高端到端任务成功率；
• 它会不会增加新的权限和操作负担；
• 用户怎样判断执行结果正确；
• 错误发生以后如何接管。

功能复制解决的是“产品里有没有”，产品竞争解决的是“用户敢不敢用”。

05 产品复制：真正的分水岭，是任务托付能力

功能层回答的是：Agent 能做什么？

产品层回答的则是：用户是否愿意把一项真实、有后果的工作完整交给它？

用户可以因为好奇，让 Agent 打开一次网页、修改一段代码或者生成一份报告。

当任务开始涉及真实项目、客户账号、企业数据和线上系统，衡量标准会迅速变化。

用户会开始关注：

• 它是否真的完成；
• 它会不会越界；
• 结果是否容易验证；
• 一旦出错能否恢复；
• 这次教会它的流程，下次能否继续使用。

这些能力共同构成本文所说的：

任务托付能力

它不是一个已有的行业标准术语，而是本文用于分析 Agent 产品的一套框架。

任务托付能力包含五个维度：

• 完成能力；
• 控制能力；
• 验证能力；
• 恢复能力；
• 积累能力。

四层复制框架回答“复制一款 Agent 要复制哪些层”。

这五项能力，则用于解释第三层的产品结果到底怎样成立。

1）完成能力：Agent 说完成，不代表任务真的完成

Agent 产品最容易出现的一种错觉，是把“Agent 宣布完成”当作任务已经完成。

一个订票 Agent 可以说预订成功，但真实结果要看订单是否进入系统。

Coding Agent 可以说问题已经修复，但最终还要看代码能否构建、测试是否通过、原功能是否受到影响。

研究 Agent 可以生成一份很长的报告，但用户仍然要确认来源是否可靠、反方证据是否遗漏、结论是否越过证据边界。

Anthropic 在 Agent 评测方法中强调，Agent 会经历多轮工具调用并改变外部环境，因此评测不能只看最终回复，还要检查真实环境状态和任务结果。

对于 Agent 产品，PM 不能只定义“它需要执行哪些动作”。

还要定义：

• 现实环境最终应该发生什么；
• 哪些约束必须满足；
• 什么证据可以证明完成；
• 未完成部分怎样呈现；
• 部分成功是否可以保留。

功能相似的两个 Agent，可能交付完全不同的产品结果。

一个只负责修改代码；

另一个修改后继续运行测试、检查差异，并告诉用户仍然存在什么风险。

它们都拥有代码编辑功能，但只有后者更接近一项可以直接验收的任务。

2）控制能力：自主权应该通过任务逐步获得

Agent 与普通聊天产品最重要的差异，是它不仅生成内容，还会改变真实环境。

它可以修改文件、运行命令、发送消息、操作账号、更新数据和改变生产系统。

能力越强，权限越不能只被视为后台安全配置。

Claude Code 已经通过权限规则、不同权限模式和组织级受管设置，控制 Agent 可以访问和执行什么；组织管理员还可以部署用户无法覆盖的权限规则。