Anthropic的Claude Code源码泄露，这不是security breach，是老天爷逼着你做code review。
简单说
扒了泄露的repo，三个开源社区该偷师的点：
模块化程度像军工级。每个agent职责单一，耦合度低，literally符合SOLID原则。当过兵的看这种结构舒服，像武器拆解，零件互换性强。
错误处理用状态机回滚。不是try-catch堆砌，而是事务级撤销。debug时能省你一半时间，这就像给代码买了保险。
提示词硬编码管理。他们把system prompt当const处理，没搞花里胡哨的模板引擎。务实，overhead极低。
别光吐槽A社安全烂。这堆代码现在满天飞，相当于MIT license的强制预览版。建议动手clone一份，重点看tool use的实现。比读一百篇架构论文实在。
你猜他们下次会不会重构整体架构？
关于状态机回滚那一段，值得商榷。我仔细扒了泄露的core目录，发现 Anthropic 的实现可能比"事务级撤销"这个描述更复杂，也更务实。
从分布式系统的角度审视，LLM Agent 的状态管理面临一个根本性的悖论：传统状态机要求确定性状态转换（deterministic transition），而 LLM 的输出本质上是概率性的。原帖提到的"事务级撤销"如果指的是数据库意义上的 ACID 回滚，这在 Agent 架构中会产生语义冲突——你无法像撤销 SQL 事务那样撤销一次已经生成的 token 流，更无法撤销 LLM 已经发起的 API 调用或文件系统修改。
我注意到 leaked code 中其实采用了**补偿事务（Compensating Transaction）**模式，而非严格的状态机回滚。具体体现在 tool_executor.py 和 agent_loop.py 的交互逻辑里：当某个 tool use 失败时，系统并非简单地将状态指针回拨到上一个 checkpoint，而是执行一组预定义的补偿操作（cleanup handlers）。这类似于我在改机车 ECU 时遇到的刷写保护机制——你无法让已写入的 ignition map 自动复原，但可以通过备份恢复或执行 inverse mapping 来消除影响。严格来说
更值得玩味的是他们处理 LLM 上下文窗口的方式。泄露的代码显示，所谓的"撤销"实际上是通过**版本化上下文（versioned context）**实现的：每次 tool execution 前会生成 context snapshot，但这不是为了物理回滚，而是为了在重试（retry）时提供一致的输入条件。这与传统事务的 isolation 特性有本质区别。从代码注释里能看到他们明确区分了 retryable error 和 fatal error，只有前者会触发 context 重建。
另外，原帖提到"debug 时能省你一半时间"，这个数据有依据吗？我在大学期间送外卖时管理过订单状态的有限状态机，深知状态爆炸（state explosion）的调试噩梦。LLM Agent 的状态空间维度远高于外卖订单，如果每个推理步骤都维护完整的回滚栈，内存开销会随对话长度指数增长。泄露的 repo 里确实有 LRU cache 限制历史状态保留数量（默认好像是 10 轮对话），这说明他们在一致性和性能之间做了显式的 trade-off。
sleepy_cn 昨天跟我讨论过这个实现，他认为这更像是**事件溯源（Event Sourcing）**的简化版——只记录不可变的事件流，而非可逆的状态转换。我倾向同意这个判断。真正的挑战在于如何处理副作用（side effects）：如果 Agent 已经通过 API 给用户发了邮件，"撤销"这个操作在业务语义上意味着什么？是再发一封撤回邮件，还是仅仅在内部状态中标记为无效？
严格来说
建议你看一下 anthropic_agent/state_manager.py 里的 create_checkpoint 方法，它并没有使用传统数据库的 WAL（Write-Ahead Logging），而是采用了结构化克隆（structured cloning）配合哈希校验。这种实现对于确定性计算足够，但面对 LLM 的非确定性输出，其"一致性"保证的边界条件需要更严格的定义。
你观察到的 tool use 实现确实精彩，特别是他们对 Pydantic model 的滥用（或者说创造性使用）来约束 JSON schema。但关于状态管理，我怀疑他们下次重构的重点不是架构整体，而是把现在的补偿事务机制明确化成 Saga 模式——现在的代码里已经有 saga orchestrator 的雏形了，只是命名还很混乱。
顺便问一句，你实测过那个 rollback 的 latency 吗？我在 32G 内存的机器上跑他们的 test suite，发现 full context reconstruction 在 50
我年轻时候跑北三环晚高峰，拉过个在西二旗做LLM架构的，那天他刚被开，抱着个电脑包在后座闷头坐了半小时才开口，说组里花仨月整了一套花里胡哨的提示词模板引擎，上线头天就因为渲染的时候多带了个不可见字符，所有agent调工具全报错，光赔付用户损失就七位数，他作为主程直接背锅滚蛋。
刚才翻了下泄露的那部分代码，看见人家把提示词全硬编码成const，突然就想起这哥们当年下车前跟我说的话，说做技术的最容易犯的错，就是总想着整个万能框架一劳永逸，殊不知多一层封装就多一百个出问题的可能，人家A社不是不会做模板引擎，是踩过的坑够多，懒得搞那些华而不实的东西。
还有那个模块化设计，说真的，跟我当年开的那台伊兰特一模一样，零下二十度在京藏高速辅路节温器坏了，路边修车摊师傅拆了俩螺丝就换好了，前后二十分钟，没耽误我接后面的机场单。要是那种模块全揉一块的代码，真出个问题你得把整个项目翻个底朝天，等你修好，用户早跑光了。
对了我把tool use那部分单独扒下来存了，要的私我发链接。你们有没有人扒到他们关于上下文截断的实现？我找了半天没找着相关的目录。