深入探讨 Anthropic、OpenAI、Perplexity 和 LangChain 实际构建的内容。涵盖编排循环、工具、记忆、上下文管理以及将无状态大语言模型（LLM）转化为能力强大的智能体的所有要素。

你或许已经搭建了一个聊天机器人。也许你已经用几个工具配置了 ReAct 循环。它在演示中运行良好。但当你尝试构建生产级应用时，系统就开始崩溃：模型忘记了三个步骤之前的内容，工具调用静默失败，上下文窗口被垃圾信息填满。

问题不在于你的模型，而在于围绕模型的一切架构。

LangChain 证明了这一点——他们仅改变了封装其大语言模型的底层架构（使用相同的模型和权重），就在 TerminalBench 2.0 测试中从排名30名以外跃升至第5名。一个独立研究项目通过让 LLM 自主优化底层架构，达到了76.4%的通过率，超越了人工设计的系统。

这个架构现在有了个正式名称：智能体框架（agent harness）。

什么是智能体框架？

该术语于2026年初正式确立，但其概念早已存在。框架是指完整封装大语言模型的软件基础设施，包括：编排循环、工具、记忆、上下文管理、状态持久化、错误处理和安全护栏。Anthropic 的 Claude Code 文档将其简单描述为：SDK 就是"驱动 Claude Code 运行的智能体框架"。OpenAI 的 Codex 团队也采用相同表述，明确将"智能体"与"框架"视为同义词，指代使大语言模型变得实用的非模型层基础设施。

我特别喜欢 LangChain 的 Vivek Trivedy 提出的经典定义："如果你不是模型，那你就是框架。"

容易让人混淆的关键区别在于：所谓"智能体"是涌现出的行为——即用户交互的目标导向型、能使用工具并能自我修正的实体；而框架则是产生这种行为的机制。当有人说"我构建了一个智能体"时，实际上是指他构建了框架并将其指向某个模型。

Beren Millidge 在2023年的文章《脚手架式大语言模型作为自然语言计算机》中精确地类比了这一概念。原始的大语言模型就像一台没有内存（RAM）、没有磁盘存储、没有输入输出设备的 CPU。上下文窗口充当了 RAM（速度快但容量有限），外部数据库相当于磁盘存储（容量大但速度慢），工具集成则如同设备驱动程序。而框架就是操作系统。正如 Millidge 所写："我们重新发明了冯·诺依曼架构"，因为它为任何计算系统提供了自然的抽象。

三层工程架构

围绕模型有三层同心圆式的工程架构：

• 提示词工程（Prompt Engineering）：精心编写模型接收的指令
• 上下文工程（Context Engineering）：管理模型所见内容及其时机
• 框架工程（Harness Engineering）：涵盖前两者，外加整个应用基础设施：工具编排、状态持久化、错误恢复、验证循环、安全执行和生命周期管理

框架不是简单的提示词包装器，而是实现自主智能体行为所需的完整系统。

生产级框架的十二个组件

综合 Anthropic、OpenAI、LangChain 及更广泛的实践社区的经验，一个生产级的智能体框架包含十二个独特组件。让我们逐一了解：

1. 编排循环（The Orchestration Loop）

这是系统的核心心跳。它实现了"思考-行动-观察"（TAO）循环，也称为 ReAct 循环。循环流程为：组装提示词 → 调用 LLM → 解析输出 → 执行工具调用 → 反馈结果 → 重复直至完成。

从机械角度看，这通常只是一个 while 循环。真正的复杂性体现在循环管理的各个方面，而非循环本身。Anthropic 将其运行时描述为"愚蠢的循环"，其中所有智能都存在于模型内部，框架只需管理对话轮次。

2. 工具（Tools）

工具是智能体的双手。它们被定义为模式（名称、描述、参数类型），注入到 LLM 的上下文中，使模型知晓可用资源。工具层负责注册、模式验证、参数提取、沙箱执行、结果捕获，并将结果格式化为 LLM 可读取的观察值。

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

3. 记忆（Memory）

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

Claude Code 实现了三级层次结构：轻量级索引（每项约150字符，始终加载）、按需调用的详细主题文件，以及仅通过搜索访问的原始记录。关键设计原则是：智能体将其自身记忆视为"提示"，并在行动前与实际状态进行验证。

4. 上下文管理（Context Management）

许多智能体在这里静默失败。核心问题是上下文衰减：当关键内容滑入窗口中间位置时，模型性能会下降30%以上（Chroma 研究证实，与斯坦福大学"迷失在中间"的发现一致）。即使百万 token 级别的窗口也会随着上下文增长而出现指令遵循能力退化。

生产级策略包括：

• 压缩（Compaction）：接近限制时总结对话历史（Claude Code 保留架构决策和未解决问题，同时丢弃冗余工具输出）
• 观察遮蔽（Observation Masking）：JetBrains 的 Junie 隐藏旧工具输出，同时保持工具调用可见
• 即时检索（Just-in-time Retrieval）：维护轻量标识符并动态加载数据（Claude Code 使用 grep、glob、head、tail 而非加载完整文件）
• 子智能体委派（Sub-agent Delegation）：每个子智能体深度探索后仅返回1,000至2,000 token 的浓缩摘要

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

5. 提示词构建（Prompt Construction）

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

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

6. 输出解析（Output Parsing）

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

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

7. 状态管理（State Management）

LangGraph 将状态建模为流经图节点的类型化字典，并通过 reducer 合并更新。检查点设置在超步边界，支持中断后恢复和时间旅行调试。OpenAI 提供四种互斥策略：应用内存、SDK 会话、服务器端 Conversations API 或轻量级 previous_response_id 链式调用。Claude Code 采取不同方法：使用 git 提交作为检查点，进度文件作为结构化草稿本。

8. 错误处理（Error Handling）

这就是为什么重要：一个10步流程，若每步成功率为99%，整体成功率仍只有约90.4%。错误会迅速累积。

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

9. 护栏与安全（Guardrails and Safety）

OpenAI 的 SDK 实现三级护栏：输入护栏（首次运行）、输出护栏（最终输出）和工具护栏（每次工具调用）。"触发线"机制可在触发时立即停止智能体。

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

10. 验证循环（Verification Loops）

这是玩具演示与生产级智能体的分水岭。Anthropic 推荐三种方法：基于规则的反馈（测试、linter、类型检查器）、视觉反馈（通过 Playwright 截图进行 UI 任务）和 LLM-as-judge（独立子智能体评估输出）。

Claude Code 的创造者 Boris Cherny 指出，为模型提供验证工作的方式可将质量提升2至3倍。

11. 子智能体编排（Subagent Orchestration）

Claude Code 支持三种执行模型：Fork（父级上下文的字节级副本）、Teammate（带文件邮箱通信的独立终端窗格）和 Worktree（每个智能体拥有独立的 git worktree 分支）。OpenAI 的 SDK 支持智能体作为工具和移交（specialist 完全接管）。LangGraph 将子智能体实现为嵌套状态图。

循环运行示例：分步详解

现在您已了解各组件，让我们追踪单个循环中它们如何协同工作。

步骤1（提示词组装）： 框架构建完整输入：系统提示词 + 工具模式 + 记忆文件 + 对话历史 + 当前用户消息。重要上下文置于提示词开头和结尾（"迷失在中间"发现）。

步骤2（LLM 推理）： 组装后的提示词发送至模型 API。模型生成输出 token：文本、工具调用请求或两者兼有。

步骤3（输出分类）： 若模型输出纯文本且无工具调用，则循环结束。若请求了工具调用，则继续执行。若请求了移交，则更新当前智能体并重启。

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

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

步骤6（上下文更新）： 结果追加到对话历史。若接近上下文窗口限制，框架触发压缩。

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

终止条件是分层设置的：模型输出无工具调用的响应、超出最大轮次限制、token 预算耗尽、护栏触发线激活、用户中断或返回安全拒绝。简单提问可能只需1-2轮。复杂重构任务可能涉及数十次工具调用跨越多轮。

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

真实框架如何实现该模式

Anthropic 的 Claude Agent SDK 通过单个 query() 函数暴露框架，创建智能体循环并返回流式传输消息的异步迭代器。运行时是"愚蠢的循环"，所有智能都存在于模型内部。Claude Code 使用 Gather-Act-Verify 循环：收集上下文（搜索文件、读取代码）、采取行动（编辑文件、运行命令）、验证结果（运行测试、检查结果），重复此过程。

OpenAI 的 Agents SDK 通过 Runner 类实现框架，支持异步、同步和流式三种模式。SDK 是"代码优先"的：工作流逻辑用原生 Python 表达而非图形 DSL。Codex 框架扩展了三层架构：Codex Core（智能体代码+运行时）、App Server（双向 JSON-RPC API）和客户界面（CLI、VS Code、网页应用）。所有界面共享同一框架，这就是为什么"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）支持五种编排模式：顺序、并发（扇出/扇入）、群聊、移交和 magentic（管理器智能体维护动态任务账簿协调 specialists）。

脚手架隐喻

脚手架隐喻并非装饰性比喻，而是精确类比。建筑施工脚手架是临时基础设施，使工人能够建造原本无法触及的结构。它不执行施工，但没有它，工人无法到达上层楼层。

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

这引出了共演化原理：模型现在会通过特定框架进行后训练。Claude Code 的模型学会了使用与其训练配套的特定框架。改变工具实现可能会因紧密耦合而导致性能下降。

框架设计的"未来适应性测试"：如果更强模型的性能提升无需增加框架复杂度，则设计是合理的。

定义每个框架的七项决策

每个框架架构师都面临七个选择：

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

框架就是产品

使用完全相同模型的两个产品可能仅因框架设计差异而产生巨大性能差距。TerminalBench 的证据清晰明了：仅改变框架就将智能体提升了20多个排名位次。

框架不是已解决的问题或商品层。这里才是艰难的工程所在：管理稀缺的上下文资源、设计能在失败累积前捕获错误的验证循环、构建能提供连续性而不产生幻觉的记忆系统，以及做出关于构建多少脚手架而非留给模型的架构抉择。

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

下次你的智能体失败时，不要责怪模型。请审视框架。