Posts

Claude Code 架构解析：从源码看现代 AI Agent 的四大核心设计 Claude Code 是 Anthropic 于 2025 年 2 月发布的 AI 编程 Agent，内部代号 Tengu（天狗）。从第一个 v0.2 beta 到泄露时的 v2.1.88，Claude Code 在一年多的时间里经历了快速迭代，陆续引入了后台 Agent 支持、auto 权限模式、MCP 服务器集成、Agent Teams 多 Agent 协作等功能。与 LangChain、Google ADK 等以"框架"自居的项目不同，Claude Code 本身是一个面向终端用户的产品，它不提供 SDK 让开发者构建自己的 Agent，而是直接作为一个可以在终端中运行的编程伙伴存在。这个定位差异决定了它的架构设计面临着一组完全不同的约束：不需要考虑可扩展性和可组合性这些框架层面的抽象问题，但必须在安全性、上下文管理、流式交互和错误恢复等工程维度上做到生产级可靠。 2026 年 3 月底，Claude Code 的完整 TypeScript 源码因一次 npm 发布配置失误而被公开。安全研究者 Chaofan Shou 发现 Anthropic 在向 npm 发布 v2.1.88 版本时，遗留了构建产物中的 .map 文件（Source Map），该文件指向了 Cloudflare R2 存储桶上一份未经混淆的源码压缩包。多个 GitHub 镜像仓库迅速备份了代码，Anthropic 虽然在数小时内推送了更新并删除旧版本，但源码已无法收回。 这份意外泄露的代码库包含近 2000 个文件、超过 50 万行 TypeScript 代码，涵盖了完整的 Agent 循环、40 余种工具实现、权限管线、上下文压缩策略，以及 44 个内部 feature flag 背后的未发布功能。它为我们提供了一个从源码级别审视工业级 AI Agent 内部设计的罕见机会。Anthropic 在 Claude Code 上贯彻的核心设计哲学是 “Less scaffolding, more model”，即尽可能信任模型的推理能力，将系统复杂度从编排层转移到模型自身。这意味着没有 DAG、没有分类器、没有 RAG 系统，整个架构的核心是一个朴素的推理-行动循环。 ...

LangChain 与 LangGraph 架构解析：从链式调用到图驱动的 Agent 编排 LangChain 是当前 LLM 应用开发领域中使用最广泛的开源框架之一，而 LangGraph 则是 LangChain 团队在 Agent 编排层面的第二次架构尝试——一个受 Google Pregel 和 Apache Beam 启发的、基于有向图的状态化工作流引擎。两者的关系并不是简单的替代，而是分层互补：LangChain 提供模型抽象、工具封装和高层 Agent 接口，LangGraph 则负责底层的执行编排、状态持久化和人在回路控制。理解这两个项目的架构设计，本质上是理解"如何用软件工程的方式构建可靠的 LLM 应用"这个问题在 2024-2026 年间的演进路径。 从宏观上看，LangChain 生态的整体分层结构如下： ┌─────────────────────────────────────────────────────────────────┐ │ Application Layer │ │ create_agent / Custom Graph / Deep Agents │ ├─────────────────────────────────────────────────────────────────┤ │ LangChain (High-Level) │ │ Agent Abstraction │ Middleware │ Structured Output │ │ (create_agent, │ (wrap_model │ (with_structured │ │ tool loop) │ _call) │ _output) │ ├────────────────────────┴─────────────┴──────────────────────────┤ │ LangGraph (Low-Level Orchestration) │ │ StateGraph │ Functional API │ Checkpointer │ Command │ │ (nodes, │ (entrypoint, │ (persistence, │ (control │ │ edges, │ task) │ threads, │ flow + │ │ state) │ │ time-travel) │ updates) │ ├─────────────────────────────────────────────────────────────────┤ │ LangChain Core │ │ Runnable Protocol │ Chat Models │ Messages │ Tools │ │ (invoke/stream/ │ (BaseChatModel│ (Human/AI/│ (BaseTool,│ │ batch/transform) │ + providers)│ Tool/Sys)│ @tool) │ ├─────────────────────────────────────────────────────────────────┤ │ Integrations │ │ OpenAI / Anthropic / Google / ... / MCP / Vector Stores │ └─────────────────────────────────────────────────────────────────┘ 自底向上，Integrations 层对接各家模型供应商和外部工具；LangChain Core 定义了 Runnable 协议和核心数据类型；LangGraph 在 Core 之上构建了图执行引擎和持久化基础设施；LangChain 的高层 Agent 抽象则是面向开发者的最终接口。这种分层在项目结构上体现为独立的 Python 包——langchain-core、langgraph、langchain 分别发布和版本管理，通过依赖关系松散耦合。 ...

Google ADK 架构解析：如何用软件工程思维构建 AI Agent 系统 Agent Development Kit（ADK）是 Google 在 2025 年开源的一个 AI Agent 开发框架，目前在 GitHub 上有超过 18000 个 star，支持 Python、TypeScript、Go 和 Java 四种语言的实现。ADK 的设计目标很明确：让 Agent 开发回归软件工程的范式，而不是停留在 prompt engineering 的阶段。这意味着它需要提供清晰的抽象层级、可组合的模块、确定性的执行流程、以及工业级的状态管理能力。 当前 AI Agent 领域的框架呈现出一种两极分化的态势：一端是 LangChain 这样高度灵活但过于松散的链式调用框架，另一端是各家云厂商封闭的托管服务。ADK 试图在这两者之间找到一个平衡点——既保持代码优先（code-first）的灵活性，又提供足够的结构化约束来支撑复杂的多 Agent 系统。这个定位是否站得住脚，需要从架构层面逐一拆解。 在进入细节之前，先从宏观上理解 ADK 的整体分层结构： ┌─────────────────────────────────────────────────────────────────┐ │ Application Layer │ │ adk web / adk run / adk api_server │ ├─────────────────────────────────────────────────────────────────┤ │ Runner (Event Loop) │ │ yield/pause/resume cycle ── Event processing │ ├───────────────┬───────────────┬─────────────────────────────────┤ │ Agent Layer │ Tool Layer │ Flow Layer │ │ BaseAgent │ BaseTool │ BaseLlmFlow │ │ ├ LlmAgent │ ├ FunctionTool│ ├ SingleFlow │ │ ├ Sequential │ ├ AgentTool │ └ AutoFlow │ │ ├ Parallel │ ├ MCPTool │ (LLM request/response │ │ ├ Loop │ └ ... │ + tool execution loop) │ │ └ Custom │ │ │ ├───────────────┴───────────────┴─────────────────────────────────┤ │ Model Abstraction │ │ BaseLlm ── LLMRegistry ── Gemini / OpenAI / ... │ ├─────────────────────────────────────────────────────────────────┤ │ Services Layer │ │ SessionService │ ArtifactService │ MemoryService │ │ (state + history) (binary blobs) (cross-session search) │ ├─────────────────────────────────────────────────────────────────┤ │ Infrastructure │ │ InMemory / Database / GCS / Vertex AI Agent Engine │ └─────────────────────────────────────────────────────────────────┘ 自底向上，Infrastructure 层提供可插拔的存储后端；Services 层管理状态、产物和记忆的持久化；Model 层抽象了不同 LLM 供应商的差异；Agent/Tool/Flow 三层构成了核心的执行逻辑；Runner 层驱动整个事件循环；Application 层则提供了面向开发者和终端用户的接口。 ...

Redis 持久化机制: RDB 和 AOF Redis 持久化 为什么需要持久化? Redis 是基于内存的数据库, 服务一旦宕机, 内存中的数据将全部丢失. 通常来说可以通过数据库来恢复这些数据, 但这会给数据库带来非常大的读压力, 并且这个过程会非常缓慢, 并导致程序响应慢, 因此 Redis 提供了把内存数据持久化到硬盘, 并通过备份文件来恢复数据的功能, 即持久化机制. 持久化的方式 目前 Redis Documentation 上对持久化的支持有以下几种方案: RDB (Redis Database): 将某个时间点上的数据生成快照 (snapshot) 并保存到硬盘上 AOF (Append Only File): 将每个接收到的写操作记录到硬盘上, 这些操作可以在 Redis 重启时被重放, 并用于重新构建 Redis 数据库 RDB + AOF: AOF 和 RDB 的混合模式 RDB RDB 指对整个数据集在特定时间点生成快照 (point-to-time snapshot), 可用于Redis的数据备份, 转移和恢复. 它是 Redis 默认使用的持久化方案. 工作原理 RDB 利用操作系统提供的写时复制 (Copy-on-Write) 机制来进行持久化, 即当主进程 P fork 出子进程时 Q 时, Q 和 P 共享同一块内存空间, 当 P 准备对某块内存进行写操作时, P 会将这块内存页进行复制, 并在新的副本上对数据进行修改, 而 Q 仍然读取原先的内存页. 这样既能够保证 Redis 实例继续服务外部流量, 又能够以最小的成本完成数据的持久化. 但正因如此, 持久化过程中的写操作是不会被记录的. ...

Disaster Recovery Architecture on AWS [TOC] The downtime of software systems could have a significant impact on business, customer satisfaction, reputation, or income of the company. Thus maintaining the availability and durability must be the most crucial part of a software system. Disaster recovery (DR) helps engineers prepare for disaster events. This post summaries the architecture for DR on AWS. DR objectives There are two key objectives: Recovery time objective (RTO): The maximum time range between service collapse and service restoration. It represents how quickly the service could be restarted. ...