【技术综述与趋势】从 51 万行泄露源码，看 Anthropic 如何工程化落地 Agent 路由

摘要2026 年 3 月 31 日Anthropic 因一次发布流程中的配置失误将 Claude Code 的 51.2 万行 TypeScript 源码意外公开。这次事件首次让外界完整看到一个年收入 25 亿美元级别的 AI Agent 产品在工程层面究竟是如何构建的。本文聚焦于其中最具学习价值的部分路由设计。我们将从入口层到多智能体委派层逐层拆解并与学界主流框架对照最终回答一个核心问题Claude Code 的路由设计里有多少是新技术有多少是工程化沉淀。答案对正在构建企业 AI 系统的团队具有直接参考价值。2026 年 3 月Claude Code 因一次 .npmignore 配置遗漏导致大规模工程源码外泄。Anthropic 将其定性为打包失误而非安全攻击。围绕功能细节和彩蛋的讨论已相当充分本文不再重复。我们更关注的是另一层价值这套源码是否揭示了一种可复制的 Agent 架构范式五层架构全景Claude Code 是一个完整的五层系统入口层EntrypointsCLI / Desktop / Web / IDE / SDK运行层RuntimeREPL 循环、状态机、Hook 系统引擎层EngineQueryEngine、动态 Prompt 组装、上下文压缩工具与能力层Tools Caps40 权限受控工具、ToolSearch、MCP基础设施层Infrastructure认证、缓存、遥测、远程控制各层之间通过双向数据/控制流连接形成一个闭环运行系统而非线性流水线。图 1. 路由视角下的Claude Code 架构分层图。第一层路由入口层的统一收口设计Claude Code 同时支持 CLI、桌面端、Web、IDE 插件和 SDK。每种入口的输入形态、权限模型都不同。如果每个入口维护一套 Agent 逻辑系统必然分裂。源码显示main.tsx 并非简单启动脚本而是一个运行时装配器。在进入 REPL 前它完成环境与凭证预热会话类型判定上下文、命令、工具收集LSP / MCP 初始化REPL 面对的不是“裸模型”而是一个能力已完全装配的运行时。MDM 读取与 Keychain 预取被异步启动体现了典型的延迟隐藏latency hiding思路首轮交互延迟本身就是一等工程问题。main.tsx 最关键的判断是这次启动是什么类型的会话交互式 REPLPipe 批处理SDK 远程调用是否恢复历史会话这个判断直接决定后续的工具集合、上下文注入与权限策略。先路由运行形态再处理用户任务这就是入口级路由的本质。对于正在构建企业 AI 系统的团队入口层的设计思路可以直接类比钉钉、飞书、Web 端、小程序本质上都是不同形态的入口。如果每个入口都自己维护一套 Agent 逻辑代码分裂是必然结局。Claude Code 的答案是用一个装配器在启动时就把差异消化掉让后续核心逻辑只看标准化的输入和统一的运行时环境。对于企业团队来说这种思路的价值非常直接入口可以多样运行时必须收敛。只有把路由前移到入口层把差异吸收在装配阶段后续的 Agent 编排、工具调用和任务执行才能真正做到可复用、可治理、可扩展。第二层路由TAOR 循环——嵌在 Agent 执行里的动态调度Claude Code 的运行层核心是一个TAOR 循环Think → Act → Observe → Repeat这是学术界 ReAct 模式Yao et al., 2022的直接工程化实现。每一轮循环都隐含一次路由判断是否继续执行工具调用是否终止输出这个路由由模型输出隐式决定而非外部调度器。也正因如此Claude Code 的路由不是“循环前的一次性决策”而是嵌入在 Agent 执行过程中的连续动态调度。在 TAOR 循环之上Claude Code 还引入了执行模式层面的路由。从源码角度看Claude Code 至少区分了三种语义完全不同的执行模式普通模式Default Mode标准的 TAOR 循环推理与执行交替进行工具调用会实时产生真实副作用文件修改、命令执行等。这是绝大多数用户交互发生的模式。只读规划模式Plan Mode只允许使用只读工具FileReadTool、GlobTool、GrepTool 等显式禁用所有有副作用的工具BashTool、FileEditTool 等输出一份可供用户审查的执行计划而非直接执行进入和退出 Plan Mode 分别通过 EnterPlanModeTool 和 ExitPlanModeTool 完成这意味着 Plan Mode 本身也是通过工具调用触发的——模型可以在推理中自主决定我需要先规划再执行。Plan Mode 是一种执行风险路由机制。高风险、不可逆操作大规模文件改动、危险的 Bash 命令在 Plan Mode 下只会生成计划文本人类在看到计划后可以选择确认或拒绝再执行从而在路由层面阻断了危险操作的直接触发路径。3.Coordinator Mode多Agent一个 Claude 实例扮演协调者Coordinator角色协调者通过TeamCreateTool 和 SendMessageTool 创建并管理多个Worker Agent每个 Worker 在独立的 git worktree中执行彼此上下文隔离Coordinator 不直接编写代码只负责任务拆分、分配和结果汇总Worker 与 Coordinator 的通信方式是结构化文本结果回填上下文不存在独立的 Agent-to-Agent 消息总线学界的多 Agent 通信拓扑研究如 G-Designer2024关注的是如何在 Agent 图中自动化设计最优的通信结构涉及图神经网络生成动态拓扑。Claude Code 的实现要简单得多——它是固定的 Hub-and-Spoke中心辐射拓扑协调者永远是中心节点。这意味着通信复杂度更低、可预测性更强代价是失去了 Agent 间点对点通信的灵活性。这是一个典型的工程权衡在生产系统里可预测性比理论最优更重要。在 Coordinator Mode 下路由决策链是用户复杂任务 ↓ Coordinator 分析任务结构 ↓ 判断哪些子任务可以并行哪些有顺序依赖 ↓ 通过 TeamCreateTool 创建 Worker A、Worker B、Worker C ↓ 通过 SendMessageTool 分配具体子任务含工具访问权限 ↓ Worker 在各自隔离的 worktree 中执行 ↓ Worker 完成后将结果通过结构化文本回传 Coordinator ↓ Coordinator 汇总输出最终结果用企业路由语言表达这是一个典型的Task Router Worker Pool模式与消息队列系统如 Kafka Consumer Group或任务调度系统如 Celery Worker的设计逻辑高度相似只不过Worker是 Claude 实例而不是计算节点。泄露代码还显示Claude Code 在每轮 Act 完成后、下一轮 Think 开始前插入了一个Reflection 环节检验刚才的操作是否达到预期检测是否陷入了重复执行循环检查是否遗漏了约束条件这与 Shinn et al.2023提出的 Reflexion 框架高度一致。社区测试结果显示引入 Reflection 后Agent 在复杂编程任务中的成功率显著提升但代价是额外的模型调用成本。从路由视角看Reflection 并不是单纯的“质量检测”而是一个隐式的自适应路由节点如果检测到循环或偏差系统会修正下一轮的执行路径而不是继续沿原路径盲目推进。第三层路由引擎层的动态提示词调度QueryEngine.ts 是整个系统最核心的单个文件代码量接近 46,000 行。它负责上下文窗口的拼接与管理提示缓存Prompt Cache的命中与更新流式响应Streaming的处理对话历史的压缩把这些逻辑集中在一个文件而不是拆散有其工程理由所有涉及模型 API 调用的逻辑——重试策略、限速处理、上下文预算——都在同一处推理避免了跨模块的状态不一致问题。Claude Code 路由设计里最具特色、也最反直觉的部分Claude Code 没有一个固定的系统提示词。它有数百个提示词碎片在运行时根据当前的模式、工具集合和上下文动态组装出最终注入的系统提示。以下是几个已知的组装触发条件这套设计本质上是一个提示词级别的路由系统请求的上下文特征模式、工具、项目配置决定了哪些提示词片段被路由激活最终拼出一个专属于这次会话的系统提示。此外提示缓存Prompt Caching是 Anthropic API 的一项功能允许将重复的提示词前缀缓存起来后续调用命中缓存则大幅降低 Token 计算成本。Claude Code 在工程实现上用了14 个缓存断点配合粘性锁存器Sticky Latch管理防止模式切换导致缓存失效。每次缓存失效都意味着真实的 API 成本增加所以提示词片段的拼接顺序和断点位置也是一种路由优化把不变的内容放在缓存断点之前把动态变化的内容放在断点之后最大化缓存命中率。第四层路由工具层的按需曝光与权限门控Claude Code 内置约 40 个工具每一个工具都是自我完备的独立模块包含Zod v4 定义的输入 Schema权限级别声明执行逻辑错误处理工具列表涵盖文件操作、Shell 执行、信息检索、Agent 协作、任务管理以及 MCP 集成等类别。工具基类的定义就有约 29,000 行 TypeScript这是工程严谨性的体现。40 工具的完整描述全量注入上下文对 Token 预算来说是一种浪费对模型的工具选择推理也是干扰。Claude Code 的解法是Progressive Disclosure渐进式曝光工具池组装assembleToolPool()根据当前会话的上下文特征只选出当前可能相关的工具子集放入 Tool Pool延迟加载defer_loading: true部分工具的详细描述不在初始提示词里而是按需注入ToolSearch模型可以主动搜索工具注册表相当于先知道有哪些大类能力再具体找工具。这本质上是一种工具级的粗粒度到细粒度的两阶段路由第一阶段粗路由能力大类感知用户请求 → 确定大类文件操作搜索执行命令第二阶段细路由精确工具选择大类确定后 → 注入该类工具的详细 Schema → 模型精确选择具体工具与直接把所有工具塞给模型相比这种设计在长会话场景下可以显著减少 prompt 体积从全量工具描述到按需注入Token 节省可达数千甚至数万同时降低模型在过多选择中产生误选的概率。遥测与隐式反馈路由用行为信号驱动系统改进泄露代码里有两个不显眼但极具价值的遥测设计挫败感指标Frustration Metric系统实时追踪用户在对话中出现骂人词汇的频率将其作为 UX 质量的代理指标。当用户开始骂人大概率意味着 Agent 的行为与预期严重偏离。这是一种情绪信号驱动的行为路由反馈——不需要用户主动填问卷情绪本身就是最真实的系统评分。continue计数器追踪用户在会话中输入continue的频率。对于一个应该自主推进的 Coding Agent用户频繁输入continue意味着 Agent 在不该停下来的地方停了——这是主动性不足故障模式的量化信号。这两个指标的工程意义在于它们不是用来展示在 Dashboard 上的虚荣指标而是可以驱动具体路由改进决策的行为数据挫败感高发的任务类型 → 提示词调整或工具行为修正continue高频的会话模式 → Agent Loop 的停止条件需要重新标定这是一种隐式的自适应路由反馈机制用户行为信号 → 系统行为分析 → 路由策略调整形成闭环。对企业 AI 系统建设者的落地建议核心技术/商业价值总结Claude Code 的泄露对企业 AI 系统建设者的价值不在于我要抄它的代码而在于验证了分层路由架构的可行性一个商业成功、生产稳定的系统用的就是分层路由 权限门控 上下文压缩这套组合没有神秘的黑盒算法提供了具体的工程参考系哪些组件需要多少代码工具基类 29K 行、QueryEngine 46K 行帮助团队做出更准确的工程估算明确了关键的非功能性需求六层权限门控、三层压缩、断路器保护——这些在 Demo 阶段往往被忽略但是生产稳定性的真正来源。针对不同角色的行动建议对于 AI Agent 系统架构师不要在早期设计阶段就追求动态拓扑的灵活性先用固定的 Hub-and-Spoke把任务路由逻辑跑通再考虑扩展把权限门控从功能列表里的一项提升到架构设计的一等公民参照六层门控思路逐步实现从配置白名单到自动分类的完整链路上下文压缩不是优化项是生产必需项在第一版就设计压缩触发点哪怕先只实现最简单的截断策略对于 NLU/意图路由模型研究者Claude Code 的工具路由渐进式曝光 按需加载对意图识别的启发在企业多意图场景下不需要让模型同时感知所有意图类别先粗分大类再在大类内部做精细分类可以显著降低误分类率QueryEngine 的动态提示词组装对应意图分类系统的动态 prompt 调度不同业务场景注入不同的分类约束比一个通用分类器处理所有场景效果更稳定对于企业 AI 产品经理Claude Code 的两个遥测指标挫败感指标 continue 计数器值得直接借鉴用户行为信号比满意度问卷更能反映 Agent 的真实表现在产品埋点时加入用户重复触发同一操作、会话中途中断等行为指标多端入口统一收口的架构选择意味着你只需要维护一套核心逻辑但需要在入口层做好差异适配这个工程成本应该在排期时被提前估算结语工程化才是真正的护城河Claude Code 的源码告诉我们当今最成功的商业 AI Agent 产品它的核心技术竞争力不是一个没人见过的路由算法而是把 ReAct 这个 2022 年的学术 idea工程化成 46,000 行稳定运行的 QueryEngine把分层权限这个安全工程常识工程化成针对 AI 特定风险的 6 层独立门控把按需加载这个 UI 设计原则工程化成工具注册表的渐进式曝光机制把任务分发这个分布式系统常识工程化成 Claude 实例之间的结构化文本 pipe没有新算法。只有深厚的工程沉淀。这对于正处于从 Demo 到生产阶段的企业 AI 团队是一个重要的信号你的技术差距不在于你没有独特的路由算法而在于你还没有把那些已知的好想法以 Claude Code 这样的密度和质量工程化出来。泄露的代码可以被 DMCA 下架但工程化的设计思路一旦公开就属于整个行业了。参考资料Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., Cao, Y. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv preprint arXiv:2210.03629.https://arxiv.org/abs/2210.03629Shinn, N., Cassano, F., Berman, E., Gopinath, A., Narasimhan, K., Yao, S. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv preprint arXiv:2303.11366.https://arxiv.org/abs/2303.11366Chen, L., Zaharia, M., Zou, J. (2023). FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv preprint arXiv:2305.05176.https://arxiv.org/abs/2305.05176Ong, I., Almahairi, A., Wu, V., Chiang, W. L., Wu, T., Gonzalez, J. E., Kadous, M. W., Stoica, I. (2024). RouteLLM: Learning to Route LLMs with Preference Data. arXiv preprint arXiv:2406.18665.https://arxiv.org/abs/2406.18665