Claude Code 源码泄露之后,终端 Agent 到底该怎么用

大家好，我是苍一，一个干了13年的后端开发，正在探索AI编程，从产品到开发的全生命周期最佳实践，如果您感兴趣，欢迎关注👇，看我如何自我革命。

3 月底 Claude Code 的 npm 包带出了 source map，CLI 源码被完整读了出来。这件事在 Hacker News 上炸到了 1800 多分，讨论量也冲到了 900 条以上。

但我写这篇不是来聊八卦的。

源码里真正有意思的东西，是它暴露了 Anthropic 对终端 Agent 的底层设计思路：反蒸馏机制、内部痕迹隐藏、权限和上下文的精细管理。这些信号拼在一起，其实回答了一个很多人还没想明白的问题——终端 Agent 的能力边界到底在哪。

过去半年大家一直在争 Claude Code 好不好用、能不能替代 Cursor。但更实际的问题其实是另一条：

什么活该交出去，什么活得自己兜着。

这条线没划清楚，Agent 不但提不了效，还会把返工量放大。

泄露为什么值得关注

3 月 31 日的事。Claude Code 的 npm 包里混进了 source map，外部开发者直接把完整的 CLI 源码扒了个干净。

讨论热度说明这不是圈内人的谈资，而是大量开发者都在认真看。源码里被翻出来的东西也确实值得看：

• 有 fake tools 之类的反蒸馏手段

• 有 undercover mode，避免在外部仓库留下 Anthropic 的内部痕迹

• 对权限、上下文管理、会话压缩、客户端校验都做了不少处理

这些设计细节背后的逻辑很一致：Anthropic 自己在用终端 Agent 的过程中，已经踩过足够多的坑，才会在架构层面加上这些保护。

所以这次泄露给我的最大启发不是技术层面的，而是认知层面的——终端 Agent 的价值不在于无所不能，而在于被放在边界清晰的位置上。

说得再直白一点：很多人不是高估了 Agent 的能力，而是低估了任务描述模糊带来的代价。把一个半成品的指令丢出去，收回来的往往是一个需要全部推翻重来的结果。这一来一回浪费的时间，远比省下的那几分钟多得多。

我现在只在这三类任务上用终端 Agent

1️⃣ 第一类：边界清楚、能客观验收的实现任务

Anthropic 官方的 best practices 里有一条很关键：给 Agent 一个可验证的成功标准，这是投入产出比最高的动作。他们推荐的流程也不是上来就写代码，而是先探索，再规划，最后才动手。

这说明什么？说明 Agent 最擅长处理的任务需要满足几个前提：

• issue 已经把需求描述到位了

• 改哪些文件、不改哪些文件是明确的

• 有测试用例、截图或者输出结果可以对照

• 完成标准用一句话就能概括

这类任务交给 Agent 之后，省下来的时间不是敲键盘那几分钟。真正省下来的是你在不同上下文之间来回切换的精力损耗。

2️⃣ 第二类：重复出现、可以标准化的流程性工作

GitHub 今年 2 月把 Claude 和 Codex 的 coding agents 放进了 public preview，入口开得非常全：GitHub 网页端、移动端、VS Code、issue、PR、Agents tab 都能直接发起任务。

这个信号很明确——行业共识已经从”拿 Agent 当聊天伙伴”转向了”把 Agent 嵌进工作流”。

适合这类场景的活包括：

• 根据 issue 起草初版修复方案

• 跟进 PR review 的评论意见

• 把文档、配置、测试一次性补齐

• 脚手架搭建和批量改造

人当然也能干。但这类活太碎了，碎片化到一定程度之后，真正消耗你的不是技术难度，而是不断切换注意力带来的疲劳。

3️⃣ 第三类：需要先探索一轮、再由人拍板的任务

Claude Code 官方文档专门花了一节讲 subagents。核心思路是：把探索和执行拆到不同的上下文里，避免主会话被无关信息污染。

这个模式其实跟真实的团队协作很像。你先让 Agent 做一轮粗活：

• 扫一遍代码库，搞清楚现状

• 列出可能的改动点

• 写一个初步的执行计划

• 跑出一个最小可运行版本

• 把潜在风险先暴露出来

然后你再决定要不要沿着这条路继续走。

我现在的习惯是把 Agent 当成第一轮推进者，而不是最终执行者。让它先把路趟出来，人来做关键决策。

这三类任务，我反而不会交给 Agent

4️⃣ 需求本身还没定清楚的活

如果连你自己都没法把目标、边界、排除项说明白，Agent 只会把这种模糊放大。它会非常卖力地干活，但方向一旦偏了，越卖力越灾难。

5️⃣ 涉及生产环境和高风险操作的活

线上变更、账号权限、资金操作、对外执行——这类任务我都不会让终端 Agent 单独闭环。Agent 能力越强，越要清楚哪些环节必须由人亲自接管。

6️⃣ 需要视觉判断和业务直觉的活

复杂的 UI 微调、产品方向的取舍、老板一句话背后真正想要的东西——这些本质上不是编码问题，是判断题。判断没到位就把活交出去，结果大概率是做完再推翻。

上手之前，先过这四个问题

7️⃣ 目标能不能一句话讲明白

说不清就先别给 Agent。

“把这个登录报错修掉，跑通现有测试”——这是任务。

“你顺手把整个登录体验优化一下”——这是许愿。

8️⃣ 验收标准是不是客观的

“看起来差不多”不算标准。能写进自动化流程才算：

• 测试全过

• 页面截图和设计稿对齐

• lint 和 build 没报错

• 接口返回值符合预期

Anthropic 的 best practices 反复强调 verification，原因很简单：没有验证的话，Agent 很容易生成一种”看起来对但实际不对”的结果。这种错误最恶心，因为第一眼觉得没问题，回头才发现根本没解决真正的问题。

9️⃣ 出错之后代价有多大

如果这一步搞砸了会导致线上事故、数据泄露、资金损失——那就别让 Agent 直接执行。

我现在的分级很简单：

• 低风险：让 Agent 多跑几轮

• 中风险：Agent 出方案，人确认后再执行

• 高风险：只让 Agent 做前期准备，执行权留在人手里

🔟 做歪了谁来收场

这一条很多人会忽略。

如果任务搞砸了最终还是你自己回来擦屁股，那就要提前想清楚：交给 Agent 到底是在减少工作量，还是仅仅把工作量延后了。

以前的流程是人从头包到尾：读代码、改代码、跑测试、回滚、补文档。现在更合理的分工是：

人把边界定清楚，Agent 负责读、试、列方案、跑第一轮实现和验证，人只接 review、决策和最终的 merge。

表面上看是”让 AI 多干一点”。但本质不是。本质是把你最稀缺的注意力从低价值的推进动作里抽出来，放到方向判断上。

这也是为什么我现在拿到一个任务，第一反应不再是”Agent 能不能做”，而是”值不值得让 Agent 先跑一轮”。换一个问法，返工量会立刻降下来。

最后说两句

Claude Code 这次泄露，真正有价值的不是源码本身，而是它从设计层面印证了一个判断：

终端 Agent 天生适合处理边界清晰、可验证、可回滚的任务。它不适合替你做那些需要判断力的决定。

如果你想今天就开始用，最稳的分工就三步：

人定边界。Agent 跑第一轮。人做最终判断。

这不是把人踢出流程。是把人从低价值的执行动作里解放出来，去做真正需要人的事。