深入探讨 Anthropic、OpenAI、Perplexity 和 LangChain 实际构建的内容。涵盖编排循环、工具、记忆、上下文管理，以及将无状态 LLM 转变为强大 Agent 所需的一切。

你已经构建了一个聊天机器人。也许你已经用几个工具搭建了一个 ReAct 循环。它在演示中运行良好。然后你尝试构建一个生产级系统，问题就接踵而至：模型忘记了三步前做了什么，工具调用无声地失败，上下文窗口被垃圾信息填满。

问题不在于你的模型。而在于模型周围的一切。

LangChain 证明了这一点：他们只改变了围绕 LLM 的基础设施（相同的模型、相同的权重），就从 TerminalBench 2.0 的前 30 名之外跃升至第 5 名。另一个独立研究项目通过让 LLM 自行优化基础设施，达到了 76.4% 的通过率，超越了人工设计的系统。

这个基础设施现在有了一个名字：Agent 框架。

什么是 Agent 框架？#

这个术语在 2026 年初被正式确立，但概念早已存在。框架是包裹 LLM 的完整软件基础设施：编排循环、工具、记忆、上下文管理、状态持久化、错误处理和护栏。Anthropic 的 Claude Code 文档简洁地指出：SDK 是“驱动 Claude Code 的 Agent 框架”。OpenAI 的 Codex 团队也使用了相同的框架，明确将“Agent”和“框架”这两个术语等同起来，指代使 LLM 有用的非模型基础设施。

我非常喜欢 LangChain 的 Vivek Trivedy 提出的经典公式：“如果你不是模型，你就是框架。”

这里有一个容易让人困惑的区别。“Agent”是涌现的行为：用户与之交互的、目标导向、使用工具、自我修正的实体。框架是产生这种行为的机制。当有人说“我构建了一个 Agent”时，他们的意思是他们构建了一个框架，并将其指向一个模型。

Beren Millidge 在他 2023 年的文章《Scaffolded LLMs as Natural Language Computers.》中精确地阐述了这一类比。原始的 LLM 就像一个没有 RAM、没有磁盘、没有 I/O 的 CPU。上下文窗口充当 RAM（快速但有限）。外部数据库充当磁盘存储（容量大但速度慢）。工具集成充当设备驱动程序。框架就是操作系统。正如 Millidge 所写：“我们重新发明了冯·诺依曼架构”，因为它是任何计算系统的自然抽象。

三个工程层次#

围绕模型有三个同心圆式的工程层次：

提示工程 精心设计模型接收的指令。
上下文工程 管理模型看到什么以及何时看到。
框架工程 包含以上两者，外加整个应用程序基础设施：工具编排、状态持久化、错误恢复、验证循环、安全执行和生命周期管理。

框架不是提示的包装器。它是使自主 Agent 行为成为可能的完整系统。

生产级框架的 12 个组件#

综合 Anthropic、OpenAI、LangChain 以及更广泛的实践者社区，一个生产级 Agent 框架包含十二个不同的组件。让我们逐一了解。

1. 编排循环#

这是核心。它实现了思考-行动-观察（TAO）循环，也称为 ReAct 循环。循环运行：组装提示、调用 LLM、解析输出、执行任何工具调用、将结果反馈、重复直到完成。

从机制上讲，它通常只是一个 while 循环。复杂性在于循环管理的一切，而不是循环本身。Anthropic 将其运行时描述为一个“哑循环”，所有智能都存在于模型中。框架只管理轮次。

2. 工具#

工具是 Agent 的双手。它们被定义为模式（名称、描述、参数类型），注入到 LLM 的上下文中，以便模型知道可用什么。工具层处理注册、模式验证、参数提取、沙箱执行、结果捕获，以及将结果格式化为 LLM 可读的观察结果。

Claude Code 提供六大类工具：文件操作、搜索、执行、网络访问、代码智能和子 Agent 生成。OpenAI 的 Agents SDK 支持函数工具（通过 @function_tool）、托管工具（WebSearch、CodeInterpreter、FileSearch）和 MCP 服务器工具。

3. 记忆#

记忆在多个时间尺度上运作。短期记忆是单个会话内的对话历史。长期记忆跨会话持久化：Anthropic 使用 CLAUDE.md 项目文件和自动生成的 MEMORY.md 文件；LangGraph 使用按命名空间组织的 JSON 存储；OpenAI 支持由 SQLite 或 Redis 支持的会话。

Claude Code 实现了一个三层层次结构：轻量级索引（每个条目约 150 个字符，始终加载）、按需拉取的详细主题文件，以及仅通过搜索访问的原始记录。一个关键的设计原则：Agent 将其自身的记忆视为“提示”，并在行动前根据实际状态进行验证。

4. 上下文管理#

这是许多 Agent 无声失败的地方。核心问题是上下文腐烂：当关键内容落在中间窗口位置时，模型性能下降 30% 以上（Chroma 研究，得到斯坦福大学“迷失在中间”发现的证实）。即使拥有百万级 token 的窗口，随着上下文增长，指令遵循能力也会下降。

生产策略包括：

压缩：在接近限制时总结对话历史（Claude Code 保留架构决策和未解决的错误，同时丢弃冗余的工具输出）
观察屏蔽：JetBrains 的 Junie 隐藏旧的工具输出，同时保持工具调用可见
即时检索：维护轻量级标识符并动态加载数据（Claude Code 使用 grep、glob、head、tail，而不是加载完整文件）
子 Agent 委派：每个子 Agent 进行广泛探索，但仅返回 1,000 到 2,000 个 token 的压缩摘要

Anthropic 的上下文工程指南阐述了目标：找到尽可能小的、高信号 token 集合，以最大化期望结果的可能性。

5. 提示构建#

这组装了模型在每个步骤实际看到的内容。它是分层的：系统提示、工具定义、记忆文件、对话历史和当前用户消息。

OpenAI 的 Codex 使用严格的优先级堆栈：服务器控制的系统消息（最高优先级）、工具定义、开发者指令、用户指令（级联的 AGENTS.md 文件，32 KiB 限制），然后是对话历史。

6. 输出解析#

现代框架依赖原生工具调用，模型返回结构化的 tool_calls 对象，而不是需要解析的自由文本。框架检查：是否有工具调用？执行它们并循环。没有工具调用？那就是最终答案。

对于结构化输出，OpenAI 和 LangChain 都支持通过 Pydantic 模型进行模式约束的响应。像 RetryWithErrorOutputParser（它将原始提示、失败的完成和解析错误反馈给模型）这样的传统方法仍可用于边缘情况。

7. 状态管理#

LangGraph 将状态建模为通过图节点流动的类型化字典，并使用归约器合并更新。检查点发生在超级步骤边界，使得中断后恢复和时间旅行调试成为可能。OpenAI 提供了四种互斥策略：应用内存、SDK 会话、服务器端 Conversations API，或轻量级的 previous_response_id 链式调用。Claude Code 则采用了不同的方法：将 git 提交作为检查点，将进度文件作为结构化的暂存区。

8. 错误处理#

这一点至关重要：一个 10 步流程，即使每一步的成功率高达 99%，其端到端的成功率也仅有约 90.4%。错误会迅速累积。

LangGraph 区分了四种错误类型：瞬时错误（带退避重试）、LLM 可恢复错误（将错误作为 ToolMessage 返回，以便模型调整）、用户可修复错误（中断等待人工输入）和意外错误（向上冒泡以便调试）。Anthropic 在工具处理程序内捕获失败，并将其作为错误结果返回，以保持循环运行。Stripe 的生产环境将重试次数限制为两次。

9. 护栏与安全#

OpenAI 的 SDK 实现了三个层级：输入护栏（在第一个智能体上运行）、输出护栏（在最终输出上运行）和工具护栏（在每个工具调用上运行）。一个“绊网”机制会在触发时立即停止智能体。

Anthropic 在架构上将权限执行与模型推理分离。模型决定尝试什么；工具系统决定允许什么。Claude Code 独立地控制了大约 40 个离散的工具能力，分为三个阶段：项目加载时的信任建立、每次工具调用前的权限检查，以及高风险操作的显式用户确认。

10. 验证循环#

这是区分玩具演示和生产级智能体的关键。Anthropic 推荐三种方法：基于规则的反馈（测试、linter、类型检查器）、视觉反馈（通过 Playwright 为 UI 任务截取屏幕截图）和 LLM 作为评判者（一个独立的子智能体评估输出）。

Claude Code 的创建者 Boris Cherny 指出，让模型能够验证其工作成果，可以将质量提升 2 到 3 倍。

11. 子智能体编排#

Claude Code 支持三种执行模型：Fork（父上下文的字节级副本）、Teammate（独立的终端面板，通过基于文件的邮箱通信）和 Worktree（拥有自己的 git worktree，每个智能体有独立的分支）。OpenAI 的 SDK 支持将智能体作为工具（专家处理有边界的子任务）和交接（专家完全接管控制）。LangGraph 将子智能体实现为嵌套的状态图。

循环在行动：逐步演练#

现在你已经了解了各个组件，让我们追踪它们在一个周期中如何协同工作。

步骤 1（提示组装）：执行环境构建完整的输入：系统提示 + 工具模式 + 内存文件 + 对话历史 + 当前用户消息。重要的上下文被放置在提示的开头和结尾（“迷失在中间”的发现）。

步骤 2（LLM 推理）：组装好的提示被发送到模型 API。模型生成输出令牌：文本、工具调用请求，或两者兼有。

步骤 3（输出分类）：如果模型生成了文本且没有工具调用，则循环结束。如果请求了工具调用，则继续执行。如果请求了交接，则更新当前智能体并重新开始。

步骤 4（工具执行）：对于每个工具调用，执行环境验证参数、检查权限、在沙盒环境中执行并捕获结果。只读操作可以并发运行；修改操作则串行执行。

步骤 5（结果打包）：工具结果被格式化为 LLM 可读的消息。错误被捕获并作为错误结果返回，以便模型能够自我纠正。

步骤 6（上下文更新）：结果被追加到对话历史中。如果接近上下文窗口限制，执行环境会触发压缩。

步骤 7（循环）：返回步骤 1。重复直到终止。

终止条件是分层的：模型生成一个没有工具调用的响应、超过最大轮次限制、令牌预算耗尽、护栏绊网触发、用户中断，或者返回安全拒绝。一个简单的问题可能需要 1 到 2 轮。一个复杂的重构任务可能会在多个轮次中链式调用数十个工具。

对于跨越多个上下文窗口的长时间运行任务，Anthropic 开发了一种两阶段的“Ralph 循环”模式：一个初始化智能体设置环境（初始化脚本、进度文件、功能列表、初始 git 提交），然后一个编码智能体在随后的每个会话中读取 git 日志和进度文件来定位自身，选择优先级最高的未完成功能，进行处理，提交，并编写摘要。文件系统提供了跨上下文窗口的连续性。

真实框架如何实现该模式#

Anthropic 的 Claude Agent SDK 通过一个单一的 query() 函数暴露执行环境，该函数创建智能体循环并返回一个流式传输消息的异步迭代器。运行时是一个“哑循环”。所有智能都存在于模型中。Claude Code 使用“收集-行动-验证”循环：收集上下文（搜索文件、阅读代码）、采取行动（编辑文件、运行命令）、验证结果（运行测试、检查输出）、重复。

OpenAI 的 Agents SDK 通过 Runner 类实现执行环境，具有三种模式：异步、同步和流式。该 SDK 是“代码优先”的：工作流逻辑用原生 Python 表达，而不是图 DSL。Codex 执行环境通过三层架构扩展了这一点：Codex Core（智能体代码 + 运行时）、App Server（双向 JSON-RPC API）和客户端界面（CLI、VS Code、Web 应用）。所有界面共享同一个执行环境，这就是为什么“Codex 模型在 Codex 界面上的感觉比在通用聊天窗口中更好”。

LangGraph 将执行环境建模为显式的状态图。两个节点（llm_call 和 tool_node）通过一个条件边连接：如果存在工具调用，则路由到 tool_node；如果不存在，则路由到 END。LangGraph 从 LangChain 的 AgentExecutor 演变而来，后者在 v0.2 中被弃用，因为它难以扩展且缺乏多智能体支持。LangChain 的 Deep Agents 明确使用了“智能体执行环境”这个术语：内置工具、规划（write_todos 工具）、用于上下文管理的文件系统、子智能体生成和持久化内存。

CrewAI 实现了一种基于角色的多智能体架构：Agent（围绕 LLM 的执行环境，由角色、目标、背景故事和工具定义）、Task（工作单元）和 Crew（智能体集合）。CrewAI 的 Flows 层增加了一个“在关键处具有智能的确定性骨架”，在 Crews 处理自主协作的同时管理路由和验证。

AutoGen（正在演变为 Microsoft Agent Framework）开创了对话驱动的编排。其三层架构（Core、AgentChat、Extensions）支持五种编排模式：顺序、并发（扇出/扇入）、群聊、交接和磁体式（一个管理智能体维护一个动态任务账本，协调专家）。

脚手架隐喻#

脚手架隐喻并非装饰性的，而是精准的。建筑脚手架是临时性基础设施，让工人能够建造原本无法触及的结构。它本身不进行建造工作，但没有它，工人就无法到达上层。

关键洞察：建筑完工后脚手架会被拆除。随着模型改进，工具链的复杂性应该降低。Manus 在六个月内重建了五次，每次重写都移除了复杂性。复杂的工具定义变成了通用的 shell 执行。"管理代理"变成了简单的结构化交接。

这指向了共同进化原则：模型现在是在特定工具链参与下进行后训练的。Claude Code 的模型学会了使用它训练时所用的特定工具链。由于这种紧密耦合，更改工具实现可能会降低性能。

工具链设计的"未来验证测试"：如果随着模型能力增强，性能提升而无需增加工具链复杂性，那么设计就是合理的。

定义每个工具链的七个决策#

每个工具链架构师都面临七个选择：

单代理 vs. 多代理。Anthropic 和 OpenAI 都表示：首先最大化单代理能力。多代理系统会增加开销（路由需要额外的 LLM 调用，交接时上下文丢失）。只有当工具过载超过约 10 个重叠工具或存在明确分离的任务域时，才考虑拆分。
ReAct vs. 规划-执行。ReAct 在每一步都交错进行推理和行动（灵活但每步成本更高）。规划-执行将规划与执行分离。LLMCompiler 报告相比顺序 ReAct 有 3.6 倍的速度提升。
上下文窗口管理策略。五种生产级方法：基于时间的清除、对话摘要、观察屏蔽、结构化笔记和子代理委派。ACON 研究表明，通过优先保留推理轨迹而非原始工具输出，可实现 26% 到 54% 的 token 减少，同时保持 95% 以上的准确率。
验证循环设计。计算验证（测试、linter）提供确定性的真实依据。推理验证（LLM 作为评判者）能捕捉语义问题但会增加延迟。Martin Fowler 的 Thoughtworks 团队将其框架化为"指南"（前馈，行动前引导）与"传感器"（反馈，行动后观察）。
权限与安全架构。宽松型（快速但有风险，自动批准大多数操作）与严格型（安全但慢，每个操作都需要批准）。选择取决于部署环境。
工具范围策略。更多工具往往意味着更差性能。Vercel 从 v0 中移除了 80% 的工具，结果反而更好。Claude Code 通过惰性加载实现了 95% 的上下文缩减。原则：只暴露当前步骤所需的最小工具集。
工具链厚度。多少逻辑放在工具链中，多少留给模型。Anthropic 押注薄工具链和模型改进。基于图的框架押注显式控制。随着新模型版本内化规划能力，Anthropic 定期从 Claude Code 的工具链中删除规划步骤。

工具链即产品#

使用相同模型的两个产品，仅因工具链设计不同，性能可能天差地别。TerminalBench 的证据很明确：仅更改工具链就让代理的排名移动了 20 多位。

工具链不是一个已解决的问题或商品化层。它是硬核工程所在：将上下文作为稀缺资源管理，设计在故障累积前捕获它们的验证循环，构建提供连续性而不产生幻觉的记忆系统，以及做出关于构建多少脚手架与留给模型多少的架构决策。

随着模型改进，该领域正朝着更薄的工具链发展。但工具链本身不会消失。即使是最强大的模型也需要某些东西来管理其上下文窗口、执行其工具调用、持久化其状态并验证其工作。

下次你的代理失败时，不要责怪模型。看看工具链。

以上就是全部内容！

如果你喜欢阅读本文：

找到我 →@akshay_pachaar ✔️

每天，我都会分享关于 AI、机器学习和 vibe 编码最佳实践的教程和见解。

Agent Cookbook

Agent 框架的解剖结构