四大智能体框架深度评测：Anthropic、OpenAI、Perplexity、LangChain
不得不说，用一套ReAct循环、几个工具再加上一段写好的系统提示，就能在演示里跑出让人眼前一亮的效果。但一旦任务超过10步，局面就急转直下——模型好像忘了三步前自己干过什么，工具调用也悄悄失败，上下文窗口里塞满了垃圾信息。
问题不在模型本身，而是模型周围的一切。
LangChain的实践很有说服力：他们只是调整了封装大语言模型的基础设施（模型和权重都没变），就从TerminalBench 2.0的30名开外直接冲到了第5名。另一个独立研究项目更绝——让大语言模型自己去优化基础设施，结果实现了76.4%的通过率，超过了人工设计的系统。
这套基础设施现在有了正式的名字：Harness（袋里）。
什么是袋里 Harness？
这个术语在2026年初才正式确定，但概念其实早就存在了。
简单说，Harness就是封装大语言模型的那套完整软件基础设施：包括编排循环、工具、内存、上下文管理、状态持久化、错误处理和安全防护措施。Anthropic的Claude Code文档里说得很直白：SDK是“驱动Claude Code的袋里工具包”。LangChain的Vivek Trivedy有个经典公式，行业里经常引用：“如果你不是模型，那你就是工具包。”
换句话说，“智能体”是一种涌现出来的行为——一个目标导向、会用工具、能自我修正的实体，用户与之交互。而“框架”则是产生这种行为的机制。当有人说“我构建了一个智能体”时，他真正的意思是自己搭了一个框架，然后指向某个模型。
贝伦·米利奇在2023年的论文里给了一个精妙的类比：
- 未经训练的大语言模型就像一台没有内存、没有硬盘、也没有输入输出设备的CPU。
- 上下文窗口相当于RAM（快但容量有限）——提示词也是上下文的一部分。
- 外部数据库相当于磁盘存储（容量大但慢）——知识库、数据库、素材库都是。
- 工具集成相当于设备驱动程序。
而Harness，就是操作系统。
三个工程层次
围绕模型有三个同心的工程层次：
- 提示工程：塑造模型接收到的指令。
- 上下文工程：管理模型何时看到什么内容。
- Harness工程：涵盖以上两者，外加整个应用基础设施——工具编排、状态持久化、错误恢复、验证循环、安全实施和生命周期管理。
Harness不是对提示的简单封装，而是一个完整的系统，让自主智能体的行为成为可能。
生产级工具箱的11个组件
综合Anthropic、OpenAI、LangChain以及整个社区的实践经验，一个生产级的袋里工具箱包含11个独特的组件。我们逐一来看。
1. 编排循环
这是整个系统的心跳。它实现的是“思考—行动—观察”（TAO）循环，也就是ReAct循环。流程很清楚：组装提示→调用模型→解析输出→执行工具调用→把结果反馈回去→再来一遍，直到任务完成。
从机械角度看，它不过是一个while循环。真正的复杂性不在循环本身，而在循环要处理的那些事。Anthropic把自己的运行时称为“一个愚蠢的循环”——所有智能都在模型里，控制装置只管管理轮次。
2. 插件/工具
工具是袋里的双手。它们以模式（名称、描述、参数类型）的形式定义，然后注入到大语言模型的上下文里，让模型知道有什么可用。工具层负责注册、模式验证、参数提取、沙箱执行、结果捕获，以及把结果格式化为模型能读的观测数据。
Claude Code提供了六大类工具：文件操作、搜索、执行、网页访问、代码智能和子袋里启动。OpenAI的Agents SDK支持函数工具（通过function_tool）、托管工具（WebSearch、CodeInterpreter、FileSearch）和MCP服务器工具。
3. 内存
记忆分不同时间尺度。短期记忆就是单次会话里的对话历史。长期记忆跨多个会话：Anthropic用项目文件和自动生成的文件；LangGraph用按命名空间组织的JSON存储；OpenAI支持SQLite或Redis驱动的会话。
Claude Code采用三层架构：轻量级索引（每条记录约150个字符，始终加载）、按需调取的详细主题文件，以及只能通过搜索访问的原始文本记录。
4. 上下文管理
很多袋里系统就是在这里悄悄失败的。核心问题是上下文衰减——当关键内容落在窗口中间位置时，模型性能会下降30%以上。就算有百万token的窗口，上下文越大，指令遵循能力也跟着下降。
生产环境里常用的策略包括：
- 压缩：快接近限制时汇总对话历史（Claude Code会保留架构决策和未解决的错误，但丢弃冗余的工具输出）
- 观察掩码：JetBrains的Junie会隐藏旧的工具输出，但保留工具调用可见
- 即时检索：只保留轻量级标识符，动态加载数据（Claude Code用grep、glob、head、tail，而不是加载完整文件）
- 子袋里委托：每个子袋里做广泛探索，但只返回1,000到2,000个token的摘要
Anthropic的上下文工程指南目标很明确：找到一组尽可能小的高信号token，以最大化实现预期结果的可能性。
5. 提示词
这汇总了模型每一步实际看到的内容。是分层结构：系统提示、工具定义、记忆文件、对话历史和当前用户消息。OpenAI的Codex用严格的优先级堆栈：服务器控制的系统消息（最高优先级）、工具定义、开发者说明、用户说明（分层文件，32 KiB限制），然后是对话历史。
6. 输出解析
现代实现依赖原生工具调用——模型直接返回结构化的tool_calls对象，而不是需要解析的自由文本。Harness会检查有没有工具调用：有就执行并继续循环，没有就给出最终答案。
对于结构化输出，OpenAI和LangChain都支持通过Pydantic模型实现模式约束的响应。像RetryWithErrorOutputParser这样的传统方法（把原始提示、失败的完成内容和解析错误再喂给模型）在边缘场景依然有用。
7. 状态管理
LangGraph把状态表示为在图节点间流动的类型化字典，由归约器合并更新。检查点记录发生在超级步骤边界，支持中断后恢复和时间旅行调试。OpenAI提供四种互斥策略：应用内存、SDK会话、服务器端对话API，或轻量级的previous_response_id链接。Claude Code则不同——用Git提交做检查点，用进度文件做结构化暂存区。
8. 错误处理
原因很简单：就算每一步成功率高达99%，经过10步后，端到端的成功率也只有约90.4%。LangGraph区分了四种错误类型：暂时性错误（带退避重试）、模型可恢复错误（以ToolMessage形式返回错误，让模型调整）、用户可修复错误（中断等待人工输入）和意外错误（上抛用于调试）。Anthropic会捕获工具处理程序中的失败，作为错误结果返回，保持循环继续。Stripe的生产环境限制重试次数为两次。
9. 防护措施与安全
OpenAI的SDK实施三个级别：输入防护（在首个袋里上运行）、输出防护（在最终输出上运行）和工具防护（在每次工具调用上运行）。“绊线”机制在触发时会立即停止袋里。Anthropic在架构上把权限执行与模型推理分开：模型决定想做什么，工具系统决定允许什么。Claude Code独立管理约40种不同的工具功能，分三个阶段：项目加载时建立信任、每次调用前权限检查、高风险操作需要用户确认。
10. 验证循环
这正是玩具演示和生产级袋里的分水岭。Anthropic推荐三种方法：基于规则的反馈（测试、linter、类型检查器）、视觉反馈（通过Playwright截图执行UI任务）、以大语言模型为裁判（用一个独立子袋里评估输出）。Claude Code的创始人鲍里斯·切尔尼指出，给模型一个验证自己工作成果的方法，能把质量提升2到3倍。
11. 子袋里编排
Claude Code支持三种执行模式：Fork（父上下文的字节级完整副本）、Teammate（独立终端窗格，基于文件的邮箱通信）和Worktree（独立的Git工作树，每个袋里有隔离的分支）。OpenAI的SDK支持袋里作为工具（专家处理有限子任务）和交接（专家完全接管控制）。LangGraph把子袋里实现为嵌套状态图。
分步操作指南
现在组件都清楚了，来看看它们在单个周期里是怎么协同工作的。
- 步骤1（提示组装）：Harness构建完整输入：系统提示+工具模式+内存文件+对话历史+当前用户消息。重要上下文放在提示的开头和结尾（“迷失于中间”现象）。
- 步骤2（模型推理）：组装好的提示发送给模型API。模型生成文本、工具调用请求，或者两者都有。
- 步骤3（输出分类）：如果模型生成的文本中没有工具调用，循环结束。如果有工具调用，进入执行阶段。如果有交接请求，更新当前袋里并重启。
- 步骤4（工具执行）：每次工具调用，框架验证参数、检查权限、在沙箱中执行、捕获结果。只读操作可并发运行，修改性操作按顺序执行。
- 步骤5（结果封装）：工具结果格式化为模型可读的消息。错误被捕获并以错误结果返回，让模型能自我纠正。
- 步骤6（上下文更新）：结果追加到对话历史。如果接近上下文窗口限制，触发压缩。
- 步骤7（循环）：返回步骤1，重复直到终止。
终止条件分层设置：模型生成无工具调用的回复、达到最大轮次限制、token预算耗尽、触发防护、用户中断，或返回安全拒绝。一个简单问题可能只要1到2轮，复杂重构任务可能在多个回合里串联数十次工具调用。
对于跨多个上下文窗口的长时间任务，Anthropic开发了一种两阶段的“Ralph Loop”模式：先用一个初始化袋里搭建环境（初始化脚本、进度文件、功能列表、首次Git提交），然后每个会话里，编码袋里读取Git日志和进度文件确定位置，挑出优先级最高的未完成功能，开发、提交，写摘要。文件系统在上下文窗口之间提供连续性。
框架如何实现该模式
Anthropic的Claude Agent SDK通过一个single query()函数公开了Harness，它创建智能体循环并返回一个流式传输消息的异步迭代器。运行时是个“哑循环”——所有智能都在模型里。Claude Code采用收集-行动-验证循环：收集上下文（搜索文件、读取代码），采取行动（编辑文件、运行命令），验证结果（运行测试、检查输出），然后重复。
OpenAI的袋里SDK通过Runner类实现Harness，提供异步、同步和流式三种模式。SDK采用“代码优先”模式：工作流逻辑用原生Python语言，而不是图式DSL。Codex工具包在此基础上扩展为三层架构：Codex Core（袋里代码+运行时）、应用服务器（双向JSON-RPC API）和客户端界面（CLI、VS Code、Web应用）。所有界面共享同一套控制台，这就是为什么“Codex模型在Codex界面上用起来比普通聊天窗口更顺手”。
LangGraph将Harness建模为显式状态图。两个节点（llm_call和tool_node）由一条条件边连接：有工具调用就路由到tool_node，没有就路由到END。LangGraph源自LangChain的AgentExecutor，后者在v0.2中已被弃用，因为难以扩展且缺乏多智能体支持。LangChain的深度智能体明确使用了“智能体Harness”这个词：内置工具、规划功能（write_todos）、用于上下文管理的文件系统、子智能体的启动和持久化存储。
CrewAI采用基于角色的多智能体架构：智能体（围绕模型构建，由角色、目标、背景故事和工具定义）、任务（工作单元）和团队（智能体的集合）。CrewAI的流程层提供了一种“在关键环节注入确定性与智能的骨干架构”，管理路由与验证，团队负责自主协作。
智能体开发平台——脚手架
建筑脚手架是什么？一种临时性基础设施，让工人能建造原本够不到的结构。它本身不参与施工，但没有它，工人就上不了高层。
关键洞察在于：建筑完工后，脚手架会被拆掉。随着模型改进，复杂性应当降低。Manus在六个月内经历了五次重构，每次重写都消除了一部分复杂性。复杂的工具定义逐渐演变为通用的外壳执行。“管理袋里”变成了简单的结构化交接。
这揭示了协同进化原则：如今，模型在训练完成后会结合特定的工具链进行微调。Claude Code的模型学会了使用它接受训练时所用的工具链。所以，更换工具实现可能因为这种紧密耦合而降低性能。
对Harness设计的未来适应性有一个简单判断标准：如果模型升级后性能提升，而Harness复杂度不需要跟着增加，那这个设计就是合理的。
Harness定义的七个决策
每个Harness架构师都要面对七个选择：
- 单智能体 vs 多智能体：Anthropic和OpenAI都建议先最大化单智能体效能。多智能体有额外开销（路由需要额外模型调用，交接可能丢失上下文）。只有当工具数量超过约10个有重叠的工具，或任务领域明显不同时，才考虑拆分。
- ReAct vs 计划并执行：ReAct每步交替推理和行动（灵活但每步成本高）。计划并执行则把规划和执行分开。LLMCompiler比顺序ReAct快3.6倍。
- 上下文窗口管理策略：五种生产方法包括基于时间的清除、对话摘要、观察屏蔽、结构化笔记记录和子袋里委派。ACON研究表明，优先处理推理轨迹而非原始工具输出，可在保持95%以上准确率的同时，减少26%到54%的token消耗。
- 验证循环设计：计算验证（测试、静态分析）提供确定性的基准。推理验证（以模型为裁判）能抓语义问题，但增加延迟。Martin Fowler所在的Thoughtworks团队将其框架化为“指南”（前馈，行动前引导）和“传感器”（反馈，行动后观察）。
- 权限与安全架构：宽松型（速度快但风险高，大多数操作自动批准）vs 严格型（安全但慢，每项操作需审批）。具体选哪个取决于部署环境。
- 工具范围策略：工具越多，性能往往越差。Vercel在v0版本中移除了80%的工具，效果反而更好。Claude Code通过惰性加载实现了95%的上下文缩减。原则是：只暴露当前步骤所需的最少工具集。
- Harness厚度：工具包里的逻辑量相比模型有多少。Anthropic押注薄Harness和模型改进。基于图的框架则侧重显式控制。Anthropic会定期从Claude Code的Harness中删除规划步骤，因为新版本的模型已经内化了这一能力。
Harness就是该产品
同样的模型，只因为Harness设计不同，产品性能可能天差地别。TerminalBench的数据已经证明，仅更换Harness就能让排名提升20多名。
Harness不是一个已解决的问题，也不是通用的底层模块。它承载着很多高难度的工程技术挑战：把上下文管理当作稀缺资源、设计能及早发现并阻止故障恶化的验证闭环、构建既能保持连续性又不会产生幻觉的内存系统，以及在架构上平衡“多建支撑”还是“多交给模型处理”。
随着模型性能提升，领域正朝着更薄的Harness方向发展。但Harness本身不会消失。即使是最强大的模型，也依然需要某种东西来管理上下文窗口、执行工具调用、持久化状态并验证工作成果。
下次你的袋里失败时，别怪模型，先看看那副Harness。