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 产品的一套框架。

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

1. 完成能力；
2. 控制能力；
3. 验证能力；
4. 恢复能力；
5. 积累能力。

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

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

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

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

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

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

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

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

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

还要定义：

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

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

一个只负责修改代码；

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

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

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

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

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

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

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

Grok Bot 也要求用户把发送、发布、购买、删除和生产环境变更放在明确审批之后，并建议从只读任务和待审核草稿开始。

这背后是一条更合理的放权路径：

1. 先让 Agent 读取和整理；
2. 结果稳定后，让它生成待审核草稿；
3. 用户建立信心后，允许它执行范围清晰的动作；
4. 低风险、经过反复验证的流程，再进入有限自动化；

完全无人值守，只适合成功标准与风险边界都已经成熟的任务。

Agent 的自主权不应该一次性交出，而应该由一次次可验证的结果逐渐换取。

Grok Bot 的共享电脑架构，还体现了产品包装与权限结构之间的距离。

官方发布页把 Bot 描述为长期存在的 AI 同事；更具体的官方文档则说明，一名用户创建的所有 Bot 实际共享一台持久化云电脑。

文件、浏览器登录状态和命令行凭证可以在 Bot 之间使用。官方明确提醒，不应把不同 Bot 当成彼此隔离的安全边界。

从界面上看，用户创建了多个职责不同的 AI 同事。

从底层权限看，它们仍然共用同一个用户级工作环境。

这不意味着 Grok Bot 一定会发生越权事故。

它说明的是：

AI 同事的角色包装，已经走在独立身份与权限隔离能力之前。

企业中的市场、财务和研究人员，不会天然拥有同一套账号、文件和系统权限。

Agent 产品真正进入组织以后，也需要逐渐建立以身份、职责和任务为单位的权限边界，而不只是为不同 Bot 设置名称、头像和人设。

3）验证能力：自动化还要降低验收成本

如果 Agent 用十分钟完成一项工作，用户却要花四十分钟检查每个步骤，这项自动化没有真正节省时间。

如果用户缺乏相关专业能力，根本无法判断结果是否正确，那么 Agent 做得越快，潜在风险反而越大。

因此，Agent 产品需要同时降低两种成本：

• 执行成本；
• 验证成本。

产品不只要展示自己“做了很多事”，还要帮助用户快速回答：

• 任务完成了吗；
• 结果为什么可信；
• 还有什么没有完成；
• 哪里需要人工处理。

对 Coding Agent 来说，验证材料可以是代码差异、测试结果和构建状态。

对研究 Agent 来说，可以是来源、冲突证据和仍不确定的结论。

对业务 Agent 来说，可以是操作前后的参数、动作记录、跳过对象和异常项。

透明度也不等于把几百条工具调用日志全部扔给用户。

信息过多，会重新制造检查负担。

好的产品需要从完整执行轨迹中，提取真正影响用户判断的证据。

一个产品只是展示 Agent 很忙。

另一个产品则帮助用户完成验收。

这就是产品差异。

4）恢复能力：可托付不等于永远不出错

Agent 越多地进入真实系统，错误越难被完全避免。

• 模型可能误解目标；
• 工具可能返回异常；
• 网页结构可能改变；
• 外部系统可能在执行中断开；
• 任务也可能只完成一半。

成熟产品不能只设计“怎样让 Agent 执行”，还要设计“执行错了怎么办”。

Claude Code 已经提供 Checkpoint，允许用户恢复由文件编辑工具记录的修改。

但官方文档同时说明，Bash 命令产生的文件变更不会被 Checkpoint 追踪，部分 Sub-agent 和外部修改也不一定能在当前会话中恢复。Checkpoint 不能替代 Git 等正式版本控制工具。

Grok Bot 的官方文档也明确指出，审批只能阻止尚未执行的动作，不能自动反转已经完成的工作。

这说明：

阻止错误和恢复错误，是两套不同的产品能力。

可逆的本地修改，可以依靠快照和版本控制降低风险；

可以补偿的外部动作，需要保留完整记录和撤销路径；

转账、发布、删除和权限变更等不可逆操作，则应优先采用预览、草稿、最小范围执行和明确审批。

一个真正可托付的 Agent，不必永远不犯错。

但它必须保证错误发生后，局面仍然处于可理解、可限制和可恢复的范围内。

5）积累能力：长期价值来自工作方法，而不只是聊天记录

一次任务成功，只能证明 Agent 在当前条件下完成过一次工作。

长期价值来自成功过程能否被保存、复用和改善。

Claude Code 可以通过 CLAUDE.md、Auto Memory、Skills 和 Hooks，沉淀项目规则、用户纠正和重复流程。

Grok Bot 的 Skill 也不只保存步骤，还可以记录决策规则、结果格式、安全边界、验证方式和审批条件。

用户长期积累的资产可能包括：

• 项目规范；
• 业务规则；
• 工具连接；
• 权限边界；
• 输出格式；
• 历史纠错；
• 经过验证的执行流程；
• 团队协作方式。

这些内容会逐渐减少用户每次重新解释任务的成本。

产品使用得越久，Agent 越清楚：

• 哪些规则必须遵守；
• 哪些结果可以直接交付；
• 哪些动作必须获得授权；
• 哪些错误过去已经发生过。
• 但积累也会产生新的问题。
• 旧记忆可能过时；
• 规则可能互相冲突；

错误流程一旦被保存，会被稳定复现；外部系统变化后，原自动化也可能失效。

所以，积累能力不只意味着“能保存”，还包括：

• 用户能否查看；
• 能否修改和删除；
• 能否判断适用范围；
• 能否发现信息已经过期；
• 能否在环境变化后重新验证。

Claude Code 官方文档现在明确说明，其 Skills 遵循可以跨多个 AI 工具使用的 Agent Skills 开放标准。

这件事很有意思。

如果工作流沉淀是 Agent 产品的重要资产，一种本能策略是把所有内容锁在自家平台里，让用户无法迁移。

但更健康的产品壁垒，未必来自“用户走不了”。

更理想的状态是：

即使用户能够带走自己的规则和工作流，他仍然认为原产品执行得更可靠。

任务托付能力是一套短板系统

完成、控制、验证、恢复和积累，不是五个互相独立的加分项。

任何明显短板，都可能中断用户托付。

完成能力很强，却经常越权，用户不敢用；

权限很严格，却每一步都要确认，效率无法提升；

结果总体正确，却没有验证材料，用户仍然要重新检查；

自动化可以运行，却无法恢复高风险错误，企业无法部署；

产品每次表现都不错，但用户要反复解释相同规则，长期价值无法沉淀。

代码决定 Agent 能不能动起来，任务托付系统决定用户敢不敢让它持续干下去。

这才是产品复制最难的一层。

06 商业复制：能运行，不等于能成为一门生意

即使后来者做出了可靠 Agent，也没有完成最后一层复制。

商业产品还要解决另一组问题：

• 用户从哪里来；
• 怎样注册、配置和付费；
• 推理与执行成本由谁承担；
• 企业怎样管理账号和权限；
• 事故发生后由谁负责；
• 产品怎样持续更新模型与工具；
• 团队如何提供部署、支持和服务。

这些能力很少出现在源码泄露的讨论中，却决定一款 Agent 能不能真正进入日常工作。

企业购买的不只是“更聪明”

个人用户可以容忍很多隐藏工作：

• 自己配置工具；
• 手动检查输出；
• 失败后重新执行；
• 自行承担权限风险。
• 企业无法依赖每名员工独立判断。

组织需要知道：

• 哪些员工可以使用；
• 员工离职后怎样回收权限；
• Agent 可以连接哪些系统；
• 哪些工具和命令被禁止；
• 数据存在哪里；
• 费用由谁承担；
• 管理员能否查看使用情况；
• 发生异常时能否审计。

Claude Code 的企业部署已经包括 SSO、域名管理、角色权限、合规 API 和组织级受管策略。

Grok Bot 也在建立团队身份、MCP 策略、共享规则、费用查看和云电脑管理能力。

但截至 2026 年 8 月 25 日查看到的官方文档，其企业访问仍在逐步推出，Bot 行为审计视图仍标注为即将推出，也尚未提供 Grok Bot 专属支出上限。

这不是简单说明谁更成熟。

它说明，从一个令人惊艳的 Early Beta 走向企业可治理产品，需要补齐大量发布页上不显眼的能力。

Agent 从个人工具进入企业，不是增加一个团队套餐。

它要进入组织原本由员工、主管、安全、财务和法务共同管理的责任体系。

用户和分发不会随着代码一起转移

根据 Anthropic 于 2026 年 2 月 12 日披露的公司口径，Claude Code 当时的年化收入运行率已经超过 25 亿美元，周活跃用户数较年初翻倍，企业使用贡献了超过一半的 Claude Code 收入。

这些数据不等于经过独立审计的市场份额，但至少说明 Claude Code 已经形成了显著的个人和企业使用规模。

这套规模背后包含：

• 用户认知；
• 工作流习惯；
• 企业合同；
• 采购评估；
• 账号计费；
• 客户支持；
• 生产任务；
• 持续反馈。

竞争者即使拥有相同代码，也需要重新证明：

• 产品是否可靠；
• 企业数据是否安全；
• 团队能否长期维护；
• 发生事故后是否有人负责；

今天建立的流程明年是否仍能工作。

Agent 还要解决自己的单位经济

Agent 的成本结构也比普通软件复杂。

每次任务可能持续消耗：

• 模型推理；
• 浏览器环境；
• 云电脑；
• 存储与网络；
• 外部工具；
• 并行 Agent。

任务越长、模型越强、并发越多，成本越可能迅速增加。

因此，商业化不是产品完成后再加一个付款页面。

定价和成本会反过来影响产品：

• 哪些步骤值得使用更强模型；
• 什么时候应该使用更便宜的模型；
• 失败后自动重试多少次；
• 后台 Routine 如何防止资源失控；
• 用户按席位、用量还是任务结果付费；
• 企业怎样设置预算和停止条件。

一个任务即使技术上可以完成，如果执行成本超过用户愿意支付的价值，也很难成为长期产品。

商业系统会形成产品反馈循环

商业规模真正有价值的地方，不只在收入。

• 更多真实用户会带来更多任务；
• 更多任务暴露更多失败方式；
• 失败案例被转化成评测；
• 评测帮助团队发现回退；
• 结果更稳定后，用户愿意交出更重要的任务；

更重要的任务又继续提出新的权限和治理要求。

Anthropic 对 Agent 评测的总结显示，Claude Code 最初依靠员工和外部用户反馈快速迭代，后来逐步建立针对简洁度、文件编辑和过度设计等行为的评测，再结合生产监控、A/B 测试和用户研究持续改进。

规模不会自动成为护城河。

只有当团队能把生产失败转化成评测和产品改进时，规模才会形成复利。

源码记录一个版本已经做出的选择，商业反馈决定团队下一版能够学到什么。

07 难复制，不等于无法超越

写到这里，还需要避免三种过度结论。

第一，代码仍然重要

源码包含工程实现、异常处理、安全策略、功能路线和大量产品选择。

公开代码会降低竞争者的理解成本，也可能提前暴露产品方向。

所以，本文并不是在说：AI 时代代码没有价值。

更准确的结论是：代码依然是护城河的一部分，但单纯依靠别人看不见代码，已经不足以构成完整护城河。

第二，模型仍然决定能力上限

一个产品可以拥有优秀的权限系统、工作流和企业后台。

如果底层模型经常误解任务、无法规划复杂步骤，用户仍然不会托付重要工作。

更合理的关系是：模型决定 Agent 的能力上限，产品系统决定这些能力能否被稳定、可控地转化成用户结果。

拿到 Claude Code 的客户端代码，不等于获得 Claude 模型本身。

重建 Grok Bot 的运行层，也不等于复制官方的模型组合、服务路由和持续训练能力。

第三，所有产品能力最终都可能被追平

评测、权限、Skills、Routines 和企业后台，都不是无法模仿的秘密。

竞争者可以逐项开发。

真正难复制的，是这些能力经过长期使用后形成的组合：

• 团队处理过哪些真实任务；
• 见过哪些失败；
• 怎样把失败转化成评测；
• 怎样根据风险调整权限；
• 用户沉淀了哪些工作方式；
• 企业部署又提出了什么要求。

后来者仍然可能追上，甚至超越。

更强的模型、更低的成本、更开放的生态和更快的组织学习，都会改变竞争结果。

“难复制”并不意味着成熟产品永远不会失败。

它只意味着：一次源码获取或一次功能复刻，无法让后来者直接继承原产品已经积累的全部能力。

08 这对 AI 产品经理意味着什么

两起事件表面发生在源码、打包和客户端运行层。

但对产品经理来说，真正需要回答的是：

当代码和功能越来越容易被研究，产品资源应该投向哪里？

1. 把发布资产纳入产品验收

用户最终能够获得的所有内容，都属于产品交付的一部分。

除了检查功能、页面、埋点和服务稳定性，团队还需要明确：

• 正式包中是否包含 Source Map 和调试资产；
• 内部日志是否暴露不必要的信息；
• 未发布功能是否进入客户端；
• Feature Flag 能否被外部发现或触发；
• 内部 Prompt 和工具定义是否被不必要地交付；
• 事故发生后如何回滚和说明影响。

PM 不需要亲自检查每一个构建文件。

• PM 要确保团队已经定义：
• 什么属于允许对外交付的产品资产；
• 什么内容一旦暴露会影响产品路线和客户信任；
• 谁负责在发布前确认这个边界。

2. 用任务链路代替竞品名词对齐

面对竞品功能，团队不应该只问：对方有，我们什么时候做？

更有价值的问题是：

• 用户为什么发起任务；
• 在哪一步无法继续；
• 需要读取什么信息；
• 会调用哪些工具；
• 哪些动作会产生外部后果；
• 怎样验证结果；
• 失败后怎样恢复；
• 成功流程怎样被复用。

竞品上线 Routine，不代表自己的产品也应该立刻增加定时任务。

团队首先要确认：

• 当前任务在有人监督时是否已经稳定；
• 重复执行会不会造成数据污染；
• 用户需要全自动，还是定时生成待审核结果；
• 失败是否能够被发现和停止。

3. 让产品经理参与定义 Agent 评测

Agent 评测不能只是模型团队提供的一个总分。

产品经理掌握的是：

• 用户真正要完成什么；
• 哪些错误最不可接受；
• 什么结果可以直接使用；
• 哪些权限边界不能突破；
• 哪类体验问题会影响留存与付费。

这些内容应该被转化成可以重复运行的任务和成功标准。

一个更有效的闭环是：

• 生产失败出现；
• 团队还原任务和环境；
• PM 定义完成标准与不可接受行为；
• 研发将问题加入评测；
• 新版本上线前重复验证；
• 新的失败继续进入评测。

真正有价值的不是拥有最多用户数据，而是团队能否把真实使用转化成下一轮产品改进。

4. 同时设计权限与恢复

权限设计不能只统计弹出了多少审批框。

产品需要根据风险进行分层：

• 低风险、可逆、范围明确的操作，可以在沙箱或快照保护下减少打扰；
• 中风险操作，可以进行有限范围授权；
• 高风险、不可逆或涉及外部主体的动作，需要展示目标、参数和后果；
• 删除、发布、转账和权限变更等操作，还需要补偿或恢复方案。

权限解决“能不能做”，恢复解决“做错了怎么办”，两者缺一不可。

5. 衡量用户是否真正开始托付任务

消息数、会话数和使用时长，无法完整描述 Agent 产品的价值。

用户每天发送很多消息，可能是因为 Agent 不断出错，需要反复纠正。

另一个用户消息很少，可能是因为 Routine 已经稳定完成了大量工作。

Agent 产品更应该关注：

• 端到端任务成功率；
• 用户人工接管率；
• 结果直接采用率；
• 用户验证结果所需时间；
• 错误恢复成功率；
• 重复任务复用率。

这些指标共同回答的是：

用户是在尝试产品，还是已经开始把真实工作交给产品？

结尾：源码能复制昨天的骨架，难复制的是明天的学习速度

Claude Code 和 Grok Bot 被拆开后，我们看到了许多过去隐藏在产品背后的结构：

• 模型怎样连接工具；
• 上下文怎样组织；
• 任务怎样调度；
• 权限在哪个环节生效；
• 记忆怎样保存；
• 客户端如何连接执行环境。

这些内容具有真实价值。

它们会降低后来者理解产品的成本，也会缩短部分功能的追赶时间。

源码泄露从来不只是一次令人尴尬的工程失误。

它会暴露实现、路线，以及团队已经验证过的产品假设。

但两起事件也让另一件事变得更清楚：一款 AI Agent 的完整价值，并不全部存在于代码仓库里。

• 代码里没有原产品全部的真实任务；
• 没有用户因为什么错误放弃使用；
• 没有企业为什么拒绝部署；
• 没有什么结果必须人工复核；
• 没有团队如何把一次失败变成评测；

也没有用户已经写入产品的规则、流程和工作习惯。

Claude Code 的源码，可以让后来者更快理解一款生产级 Coding Agent。

Grok Bot 的重建，可以让外部团队重新组合模型、运行层和执行环境。

它们解决的是：怎样更快看懂一个已有产品。

它们没有自动回答：怎样让用户持续把真实工作交给这个产品。

任务托付能力也不是一句抽象的信任口号。

它来自五件具体的事同时成立：

1. 任务能够完成；
2. 权限不会失控；
3. 结果容易验证；
4. 错误可以恢复；
5. 工作方法能够沉淀。

再往外一层，它还需要企业治理、成本控制、产品分发和持续服务，才能成为一项真正运转的业务。

代码、模型和功能都重要。

但它们越来越像进入竞争的必要条件，而不是单独决定胜负的充分条件。

对产品经理来说，真正需要建立的，也不是一个竞争对手暂时没有的按钮。

而是一套能够持续吸收真实任务、发现失败、更新评测、调整权限并改善结果的产品系统。

源码记录的是一个版本已经做出的选择。

真正拉开长期差距的，是团队能否比别人更快知道：

用户下一次为什么不愿意托付；

产品在哪一步失去了控制；

什么结果才真正算完成；

以及怎样把今天的失败，变成明天不会重复发生的问题。

AI Agent 最深的护城河，不是永远让竞争者看不见它怎样工作，而是即使代码、功能和结构已经被看见，用户仍然更愿意把下一项工作交给它。

参考资料

1. Axios：Claude Code 大规模内部源码暴露事件及 Anthropic 回应。
2. SpaceXAI：Grok Bot 官方发布说明。
3. Grok Bot 官方文档：审批、安全、隐私与共享电脑边界。
4. Grok Bot 官方文档：团队与企业部署、模型、审计和费用控制。
5. Grok Bot 官方文档：Skills 与 Routines 的设计和测试原则。
6. Anthropic：Agent 评测方法与 Claude Code 的评测演进。
7. Anthropic：Claude Code Auto Mode 与 93% 权限请求批准率。
8. Anthropic：Claude Code 企业部署与治理能力。
9. Anthropic：Claude Code 的记忆、Checkpoint 与 Skills 文档。
10. Grok Bot 0.18.0 重建项目的性质、边界和扩展说明。