26年5月来自CMU, Yale大学, JHU, 东北大学（NEU）, Tulane大学, 阿拉巴马大学（UAB）, 俄亥俄州立（OSU）, Virginia Tech 和Amazon公司的论文“Agent Harness Engineering: A Survey”。

大语言模型（LLM）智体在生产环境中的快速部署揭示一个反复出现的规律：任务执行的可靠性与其说取决于底层的语言模型本身，不如说更多地取决于包裹该模型的“基础设施层”——即智体Harness（Agent Harness）。本综述基于实践经验，对智体Harness工程进行系统性的梳理，并围绕三个核心论点展开。首先，智体harness是一个独立的系统层，其工程质量在很大程度上决定实际应用中的系统可靠性；通过三个阶段的工程演进（从“提示工程”到“上下文管理”再到“harness工程”）来阐述这一观点，并在此基础上进行跨层级的综合分析，涵盖“成本-质量-速度”三难困境、“能力与控制”的权衡取舍，以及“harness耦合”等关键问题；此外，还提出一系列开放性研究议题，旨在填补当前研究领域的空白并解决生产环境中的痛点。其次，提出 ETCLOVG 这一七层分类体系（分别代表：执行环境、工具接口、上下文管理、生命周期/编排、可观测性、验证、治理）；该体系在既有的六组件框架基础上进行扩展，将“可观测性”和“治理”提升为独立的架构考量要素。第三，将 170 多个开源项目映射至上述分类体系中，旨在揭示当前生态系统的发展模式、覆盖范围的空白点以及正在涌现的设计原则；与此同时，还提炼一系列源自 OpenAI、Anthropic 和 LangChain 等机构生产部署实践的工程原则，旨在弥合从业者经验知识与学术研究术语体系之间的鸿沟。

如图4所示智体Harness工程分类体系的详细内容：

约束瓶颈：驾驭（Harness）机制重于模型本身

针对基于大语言模型（LLM）的智体（Agent）进行的学术研究，在很大程度上一直聚焦于模型本身。研究议程的核心在于探究模型的能力边界：它能否执行多步规划、能否可靠地调用工具、能否检索并压缩相关记忆，抑或能否与其他智体协同工作。这种研究范式背后潜藏着一个隐性假设：智体的能力主要取决于模型的能力；换言之，只要拥有足够强大的模型并辅以足够精良的提示词（Prompt），便能产出足够可靠的行为表现。

然而，近期涌现的实证证据对这一假设提出了挑战——即单纯依靠更先进的模型，并不能自动带来更可靠的智体表现。近期三项研究成果确立了这一规律。Bölük (2026a) 仅修改“编辑工具”的格式及其周边的工具驾驭机制（Tool Harness），而未对模型本身做任何改动；结果显示，在针对15个不同模型进行的编程基准测试中，其性能提升幅度最高竟达10倍之巨。Trivedy (2026) 在 Terminal-Bench 2.0 基准测试中，将一个固定的 GPT-5.2-Codex 智体性能从 52.8% 提升至 66.5%；这一提升完全归功于对系统提示词的重构、中间件层面的上下文注入，以及引入“自我验证钩子”等基础设施层面的调整——在未触及模型本身的情况下，实现了高达 13.7 个百分点的性能跃升。Meta-Harness (Lee et al., 2026) 项目通过自动化驾驭机制优化手段，在 Terminal-Bench-2 测试中取得了 76.4% 的成绩；在同样未修改模型权重的前提下，这一成绩超越了所有由人工精心调校的优化方案。在上述每一个案例中，作为变量的均是“执行驾驭机制”（即负责管理上下文构建、工具交互、任务编排、反馈机制及执行约束的基础设施层）；而作为对照组的模型本身则始终保持固定不变。值得注意的是，这些仅凭优化驾驭机制所取得的性能提升，均显著超越在同一基准测试中被视为“模型重大进步”的典型提升幅度（通常仅为 2 至 4 个百分点）。这一规律绝非偶然：真正决定最终成效的，并非模型本身，而是其背后的驾驭（harness）机制。

这一规律称之为“约束瓶颈论”（Binding-Constraint Thesis，Bölük, 2026b）：针对那些在同类前沿模型之间进行横向对比的长周期任务评估而言，基准测试结果的差异性，可能在很大程度上既取决于模型本身，也同样取决于其所搭载的执行驾驭机制。

如图3 形象地展示这一历史性的范式转变：早期的智体系统往往将核心能力高度集中于单一的模型循环（Model Loop）之中；而近期的系统则日益揭示出这样一个事实——智体的可靠性问题，本质上是一个横跨各层级的基础设施层面的系统性问题。

智体系统的演进

从早期的“思维链提示”（Chain-of-Thought Prompting）到自主智体，这一发展轨迹可以被理解为从业者必须管理的“工程界面”在逐步扩展的过程。

ReAct 时代（2022–2023）。Yao（2023）确立“观察-思考-行动”（Observe-Think-Act）循环作为智体系统的基础原语。早期的系统仅依靠极简的基础设施运行：一个 while 循环、一个提示模板以及一个简易的工具分发表。AutoGPT 和 BabyAGI 通过将语言模型的调用封装在任务队列、记忆模块和工具分发机制之中，展现实现完全自主运行的雄心；与此同时，它们也将“执行失控”、“上下文溢出”、“状态丢失”以及“未受监控的副作用”等故障模式，从单纯的“提示工程问题”转化为显性的“基础设施问题”（Significant Gravitas, 2023; Nakajima, 2023）。

工具集成与多智体协作（2023–2024）。Gorilla、ToolLLM 和 Toolformer 等项目证实，工具的使用能力是可以被模型通过学习或引导而获得的，而非必须硬编码进固定的 API 封装器中（Patil et al., 2024b; Qin et al., 2024; Schick et al., 2023）。CAMEL、ChatDev、MetaGPT 和 Mixture-of-Agents 等项目引入丰富多样的多智体协作模式，其形式涵盖从“角色扮演式对话”到“模拟软件开发组织”乃至“分层智体聚合”等多种类型（Li et al., 2023a; Qian et al., 2023a; Hong et al., 2023; Wang et al., 2024）。随着 SWE-bench、AgentBench、WebArena 和 GAIA 等基准测试平台的问世，智体系统的评估基础设施日趋成熟（Jimenez et al., 2024; Liu et al., 2023a; Zhou et al., 2024; Mialon et al., 2023）；与此同时，以 Anthropic 提出的 MCP 协议和 Google 提出的 A2A 协议为开端，智体领域的协议标准化工作也正式启动（Anthropic, 2024c; Surapaneni et al., 2025）。

“驾驭（harness）与管理”的转折期（2025–2026）。截至2025年，业界已积累了足够的部署经验，足以确凿地证明：制约智体（Agent）可靠性的关键瓶颈在于基础设施质量，而非模型质量。2026年初发生的三个独立进展进一步印证这一趋势的转变：OpenAI 正式将“驾驭工程”（Harness Engineering）确立为一门独立学科；斯坦福大学与麻省理工学院联合推出的 Meta-Harness 项目证实，自动化的 Harness 优化方案其成效优于人工工程调优；此外，LangChain 的 DeepAgents 项目仅通过对 Harness 层进行调整，便在 Terminal-Bench 2.0 基准测试中将性能得分从 52.8% 提升至 66.5%——这相当于实现了 13.7 个百分点的绝对增长，以及约 26% 的相对提升（OpenAI, 2026a; Lee et al., 2026; Trivedy, 2026）。

三个工程阶段

2022年至2026年这一时期，该领域所选择的工程实践呈现出一种连贯的、分三个阶段演进的脉络，如图 1所示。

提示工程（2022–2024）。这一阶段的主要着力点在于输入提示文本（prompt text）。从业者通过精心设计更优质的指令、少样本示例（few-shot examples）以及推理模板来进行优化。当时的工程范畴较为狭窄：仅限于优化针对单次模型调用的单一文本输入。

上下文工程（2025）。随着智体（agents）的运行周期变得更长，其面临的“瓶颈约束”随之发生了转移——从最初的“输入内容是什么？”，转变为“在每一步操作中，模型应当看到哪些信息？”这一阶段的核心在于上下文管理：即在每一轮交互中应注入何种信息、如何检索并压缩记忆数据、如何依据相关性对工具执行结果进行排序，以及如何应对上下文窗口（context window）达到容量上限的问题。工程范畴由此前的单一输入，扩展至对流入上下文窗口的多个信息流进行统筹管理（Anthropic Applied AI Team, 2025）。

驾驭工程（2026）。随着模型能力的日益增强，足以胜任长期运行的任务，系统的可靠性也愈发依赖于其外部的“基础设施封装层”（harness wrapper）。该封装层负责维护系统状态、协调工具调用、注入反馈信号、强制执行约束条件，并对任务进度进行核验。这一观察结果与“瓶颈约束”理论的观点不谋而合：即具备长周期执行能力的智能体，其优异表现并非仅凭模型自身所能达成，而是源于模型与外部封装层（harness）协同耦合所构成的整体系统（Bölük, 2026b）。因此，“驾驭工程”所探讨的核心问题在于：为了确保智体系统的可靠运行，必须在模型外围构建怎样的治理机制、约束条件、反馈回路以及执行控制策略？在所构建的分类体系中，这一阶段将ETCLOVG框架下的全部七个层级视为一个不可分割的有机整体（OpenAI, 2026a; Böckeler, 2026; LangChain, 2026b）。

这三个阶段之间存在着层层包含的关系：驾驭（harness）工程涵盖上下文（context）工程，而上下文工程又涵盖提示（prompt）工程。此外，这三个阶段在时间与概念上均存在相互重叠之处，并非以泾渭分明的界限彼此割裂、依次更替。时至今日，提示工程依然是驾驭工程实践中不可或缺的活跃组成部分；与此同时，上下文工程也在持续演进与成熟，并与驾驭层级相关议题并行发展。因此，这一阶段的划分，更恰当的解读应是：工程领域内“边际工程投入”重心的转移，而非旧有工程范式的彻底废弃与更迭。

ETCLOVG 七层分类体系

针对智体驾驭工程（agent harness engineering）提出一套七层分类体系。简称为 ETCLOVG，该缩写分别代表：执行（Execution）、工具（Tooling）、上下文（Context）、生命周期（Lifecycle）、可观测性（Observability）、验证（Verification）以及治理（Governance）。前图 4 提供该体系的精简可视化概览。如图 2 所示：

前四层描述驾驭的核心结构。执行层（E）决定智体代码的运行环境，以及对其进行约束的沙箱限制；工具层（T）规定外部能力的描述、发现及调用方式；上下文层（C）控制模型在短期、会话级及持久化时间跨度内所能感知的信息范围；而生命周期层（L）则组织负责读取与写入上述状态的控制流——其涵盖范围从单智体循环，延伸至多智体协作及“从问题（Issue）到拉取请求（Pull Request）”的完整工作流。余下的三层则描述围绕该核心结构构建的控制平面。可观测性层（O）负责捕获追踪日志、成本数据、故障信息及可靠性信号；验证层（V）将任务执行情况与追踪日志转化为评估指标、故障归因分析及回归测试反馈；而治理层（G）则通过权限管理、身份认证、策略约束、安全加固、审计追踪及人工监督等机制来规范智能体的行为。

该分类体系的两项设计抉择使其独树一帜。首先，将“可观测性”（O）提升为一个独立的层次，而非将其仅仅视为生命周期钩子（lifecycle hooks）所产生的附带效应。在生产级系统中，可观测性拥有其专属的工具生态体系（例如 Langfuse、Arize Phoenix、OpenLLMetry）以及独特的工程实践（例如 OpenTelemetry 埋点检测、成本归因分析、异常检测等），因此理应作为独立层次进行专门探讨。其次，将“治理”（G）确立为一个“一级”层次，旨在全面涵盖安全与合规领域的各类关切；该层次进一步细分为三个子层级：模型级（涵盖防护栏机制、内容过滤等）、系统级（涵盖网关、智体、权限模型等）以及组织级（涵盖审计追踪、合规管理、人工介入监督等）。

状态管理（State management）自然应归属于“生命周期与编排”（L）层级之中，并与负责读取及写入该状态的执行流紧密相伴；生命周期钩子与策略强制执行应归属于“治理”（G）范畴，在此处，它们能与其他约束机制保持协调一致。

构建该语料库，旨在对公开文档中记载的“智体-驾驭”（agent-harness）相关制品进行系统性映射；在此过程中，借鉴系统综述的研究规范，明确披露数据来源渠道、检索策略及筛选流程（Page et al., 2021）。如图5所示，候选对象主要通过四类渠道进行收集：既往的综述论文与基准测试论文；基于GitHub平台、针对项目名称、描述、README文档、主题标签、星标数、更新时间及归档状态等字段进行的可复现式检索；经过人工整理的项目列表与软件包注册库；以及各类公司工程博客或发布说明中涉及测试框架级机制的内容（Meng et al., 2026; Jimenez et al., 2024; Liu et al., 2023a; Zhou et al., 2024; GitHub, 2026; OpenAI, 2026a; Anthropic, 2025d; LangChain, 2026b）。典型的检索关键词组合涵盖“agent harness”（智体驾驭）、“coding agent”（编程智体）、“LLM agent sandbox”（大语言模型智体沙箱）、“MCP server”、“agent observability”（智体可观测性）、“agent memory”（智体记忆）、“agent evaluation”（智体评估）以及“agent governance”（智体治理）等术语。对于每一个最终入选的候选对象，均记录其项目名称、URL链接、制品类型、来源类型、可用性状态、可识别的发布年份、可获取的GitHub元数据，以及用于后续ETCLOVG编码分析的公开佐证材料。

---

1 范围与概念

定义

智体的执行环境是指智体动作得以物理执行的基础设施层。在大语言模型（LLM）智体的语境下，执行环境与沙箱是紧密耦合的概念。因此，生产级的智体系统几乎无一例外地会在沙箱环境中执行动作。

为何沙箱技术在“智体时代”居于核心地位

在智体（Agent）时代，沙箱技术不仅仅是一项沿袭自传统多租户代码执行环境的安全措施。它同时承载着三个截然不同的目的；正是这三者的结合，将沙箱技术从一个单纯的操作性细节，提升为智体运行框架设计中的一项“头等大事”。

首要目的是安全性。智体沙箱所面临的挑战，已超越传统多租户代码执行环境的范畴。由大语言模型（LLM）生成的代码，在规模化应用时既难以审计，也缺乏可预测性，这使得“静态代码审查”这一传统的首要防御手段变得不再适用。此外，智体往往需要跨越多个步骤自主执行任务，这意味着在实际执行动作的当下，无法进行人工干预。恶意利用“提示注入”（Prompt Injection）攻击，可以将原本无害的智体劫持，使其沦为针对沙箱环境发起攻击的载体，从而模糊“可信的用户意图”与“恶意的输入指令”之间的界限。近期关于“沙箱逃逸”（Sandbox Escape）现象的实证研究表明，上述担忧绝非空穴来风。

第二个目的是可复现性。针对智体的“长周期任务”，以及用于评估此类任务的测试框架，均要求系统具备将执行状态重置回某一“已知基线”的能力。Docker容器或微型虚拟机（MicroVM）可以根据需求随时销毁并重建，而开发者的物理工作站则无法做到这一点；正是凭借这一特性，诸如 SWE-bench (Jimenez et al., 2024) 和 OSWorld (Xie et al., 2024) 等基于沙箱技术的评估基准，才得以具备实际的可行性。在模型训练阶段——即单个任务可能在多条并行轨迹上被反复重演数百次之时——若缺乏一种低成本的状态重置机制，其本身便会成为制约系统扩展性的一个瓶颈。

第三个目的是“活跃性”（Liveness），这也是智体时代所独有的一个特定需求。若缺乏沙箱环境的保护，智体所试图执行的每一个潜在高风险动作——例如写入文件、安装软件包或发起外部网络调用——都必须先通过显式的权限提示窗口，交由人类用户进行审批放行。在规模化应用场景下，这种模式往往会导致两种失效后果：要么用户因不堪其扰而彻底放弃使用该智体；要么用户出于惯性或麻木感而对所有权限请求一律“反射性”地点击批准，从而彻底消解权限提示机制原本旨在提供的安全防护意义。沙箱技术通过划定一个明确的“边界区域”——在此区域内，智体被授权可以自由地执行操作——从而打破上述僵局；它将权限管理的重心，从针对“具体动作”的逐一审批，转移到了针对“整个会话周期”的统一配置。据 Anthropic 公司报告显示，在其 Claude Code 产品中引入沙箱技术后，在确保安全性的前提下，成功将权限审批提示的出现频率降低84% (Anthropic, 2025b)。在这一框架下，沙盒既是一座“牢笼”，亦是一份“许可”；而正是这“许可”的一面，才从根本上促成自主且长周期的任务执行。

在这三重目的中，安全性是与传统沙盒技术所共有的；可复现性在智体（Agent）语境下得到显著增强；而“活性”（Liveness）则是一个本质上全新的概念。正是这三者的有机结合，赋予将“智体沙盒”视为一个独立研究对象——而非仅仅作为容器技术之某种下游应用——的充分理据。

2 智体沙箱的分类

在2024至2026年间，智体沙箱基础设施已从最初的一小部分通用运行时，演化为如今的多个截然不同的产品类别，且每个类别均针对特定类型的智体任务进行优化。依据“工作负载”与“应用场景”这两个维度对这一生态格局进行划分，将其归纳为七大类别；对于需要在众多系统中进行选型的沙箱集成设计者而言，这一分类方式最具参考价值。至于另一个正交维度——“隔离技术”（涵盖容器、gVisor [Google, 2018] 等用户空间内核、Firecracker [Agache et al., 2020] 与 Kata Containers [Kata Containers Project, 2017] 等微虚拟机、WebAssembly，以及 bubblewrap 和 Seatbelt 等操作系统级原语），并未将其列为顶级分类，而是将其作为一种设计属性进行探讨；究其原因，在于同一套隔离原语往往会被复用于多种不同的工作负载之中。这七大类别具体包括：通用托管沙箱、计算机操作型智体基础设施、代码专用型沙箱、框架集成型运行时、浏览器评估环境、操作系统级权限沙箱，以及沙箱抽象层。

3 威胁模型与沙箱逃逸

对智体（Agent）执行过程进行沙箱化处理，不仅面临传统的容器级威胁（如容器逃逸、侧信道攻击、资源耗尽），还面临一类智体特有的威胁类别，这些类别往往会放大传统的安全隐患。首先，提示注入（Prompt Injection）攻击允许外部输入——例如检索的网页内容、工具的响应结果或文件内容——劫持智体的行为，进而触发恶意的沙箱操作。其次，目标失调（Goal Misalignment）可能导致智体本身将“主动尝试逃逸沙箱”视为实现其最终目标的一个必要中间子目标。第三，组合放大（Compositional Amplification）效应发生于智体拥有多重工具访问权限之时；在这种情况下，沙箱环境中的单一弱点可能会在智体集成的各项能力之间产生连锁反应，从而被放大利用。

尽管针对智体环境下的沙箱逃逸现象，目前尚缺乏大量的实证数据，但现有证据已足以引发高度关注。由 Marchand（2026）提出的 Sandbox-EscapeBench 基准测试工具，在一个嵌套式沙箱“夺旗赛”（Capture-the-Flag）环境中对前沿的大语言模型（LLM）进行评估；结果显示，针对基于 Docker 的容器环境，其沙箱逃逸的成功率在 15% 至 35% 之间浮动，具体数值取决于容器的配置方式。该基准测试涵盖多种沙箱逃逸机制，包括配置错误、权限分配失误、内核漏洞，以及运行时或编排层面的安全弱点；测试结果确凿地证明，即使以当前模型的智能体能力水平来看，沙箱逃逸威胁也绝非仅仅停留在理论层面，而是已经成为切实存在的现实风险。相比之下，针对此类威胁的防御性研究目前仍处于起步阶段。Wu（2025）提出的 IsolateGPT 方案，针对基于 LLM 的智体系统构建一种执行隔离架构；据其报告，该方案在有效防范跨应用数据泄露的同时，针对四分之三的测试查询，其所产生的性能开销均控制在 30% 以下。Yan（2025）提出的事务性沙箱（Transactional Sandboxing）方法则提供一种基于“回展（rollback）”机制的防护手段；据其报告，该方法产生的性能开销约为 14.5%，且针对高风险指令具有极高的拦截成功率。Cheng（2026）提出的“LLM-in-Sandbox”方案则提供一种互补性的视角；该方案主张，构建功能“极简”而非“全能”的沙箱环境，有助于同时缩小攻击面并降低智体运行过程中不必要的复杂性。

综合上述研究成果不难发现，当前在“进攻”与“防御”两类研究进展之间存在着显著的差距。在“进攻”层面，研究人员已成功构建出具体且可复现的基准测试工具；而在“防御”层面，相关研究工作仍呈现出碎片化的状态，仅散见于各类孤立的原型系统中，且各系统在威胁模型、评估协议及基线假设等方面均存在差异。因此，构建一套针对智体环境原生设计的运行时安全框架——即能够在一套统一的评估方法论下，系统性地解决提示注入、目标失调及组合放大等核心安全挑战——已成为当前亟待探索的开放性研究方向。

4 部署模式

Agent 沙盒基础设施的部署模式已日趋多样化，不再局限于最初的自托管 Docker 模式。在当前的实践中，主要存在三种模式并存的局面。在自托管模式下，开发者直接管理沙盒基础设施，这也是 OpenHands 和 SWE-agent 所采用的默认模式。在云端（SaaS）模式下，沙盒即服务（Sandbox-as-a-Service）提供商负责基础设施的管理，E2B、Modal 和 Daytona Cloud 便是此类模式的典型代表。而在混合模式或“自带云”（BYOC）模式下，Agent 的逻辑层与沙盒的执行层在不同的环境中实现解耦；此类模式的案例包括 OpenHands SDK 中的“本地工作区”与“远程工作区”抽象（Wang et al., 2025c），以及 E2B 和 Northflank 所提供的 BYOC 服务。

推动这些模式演进的背后，是两种相互补充的驱动力量。一方面，从业者的反馈报告往往从延迟、安全性和可扩展性这三个维度来权衡部署方案的选择（Anthropic, 2025b;f）。自托管沙盒能够提供最低的延迟和最紧凑的迭代周期，但也意味着需要承担全部的运维负担；云端沙盒则呈现出一种截然不同的权衡取舍——它以增加网络往返延迟为代价，换取弹性伸缩的能力和托管式的安全保障；而混合模式则试图在将敏感数据保留在本地的同时，将具体的执行任务委托给外部资源。另一方面，数据驻留地要求、合规性以及可审计性等组织层面的约束条件，往往会促使部署方案向混合架构倾斜——即便从延迟和可扩展性的角度来看，单一模式的解决方案可能显得更为理想。

在实际观察的应用场景中，自托管沙盒主要占据了交互式开发和单租户场景的主导地位；相比之下，云端沙盒则在多租户环境及大规模部署场景中更为普及。混合模式正作为一种新兴方案崭露头角，尤其适用于那些既有合规性或数据本地化要求，又需要大规模、瞬时性执行资源池支持的特定场景。目前，针对这些不同部署模式在实际 Agent 工作负载下的系统性实证对比研究尚属空白。

---

工具接口与协议层（T）是 ETCLOVG 的第二大支柱。

工具接口与协议层定义智体（Agent）如何发现自身能力、如何表征可调用的交互功能（affordances），以及如何在异构的运行时边界之间执行动作。在实践中，这一层恰好处于两个相互竞争的目标之间的交汇点：一方面要通过暴露更多工具来扩大能力覆盖范围；另一方面又要通过控制动作空间和提示词（Prompt）的占用规模，来确保决策的质量。来自生产级智体系统的最新工程实践指南反复指出：过于庞大的工具菜单不仅会降低系统的可靠性，增加 Token 的消耗开销，还会放大规划过程中产生的错误（Anthropic, 2025d; OpenAI, 2026c）。

这一层面的工作划分为四个相互补充的方向：协议与接口标准；工具的描述、发现与选择；基于工具增强的模型训练与集成；以及系统的可扩展性与会话管理。

1 协议与接口标准

MCP 已成为针对编程和企业智体（Agent）领域最引人注目的工具集成基础层。它采用明确的主机-客户端-服务器（Host-Client-Server）架构，并基于 JSON-RPC 实现了工具、资源和提示信息的类型化交换（Model Context Protocol, 2025b;c;a）。MCP 的实际价值不仅在于实现模式层面的互操作性，更在于提升了生态系统的流动性：智体构建者可以复用日益扩充的服务器目录，而无需为每一次部署单独开发定制化的连接器。

A2A 协议所针对的边界虽与上述领域不同，但二者紧密相邻。A2A 并非仅将工具暴露给单一的智体进程，而是致力于标准化“黑盒式”智体应用之间的通信，其功能涵盖通过“智体卡片”（Agent Cards）进行服务发现、支持同步与流式交互，以及实现长周期任务的协同处理（A2A Project, 2025）。近期的协议调研报告将 MCP 与 A2A 定位为互补关系：MCP 主要负责工具与上下文的访问，而 A2A 则专注于智体间的任务委托与协作（Ehtesham et al., 2025）。一种更为有效的归类原则是：应依据工具/接口标准所跨越的“集成边界”来对其进行划分，而非单纯依据其所属厂商或发布时间线。基于这一视角，可以识别出四类边界：模型（Model）↔ 函数（Function）（即结构化调用）、智体（Agent）↔外部能力（即运行时与工具的解耦）、智体 ↔ 智体（即跨进程的任务委托），以及智体 ↔代码库/环境（即版本控制下的策略管理）。下表 1 总结这一分类观点，并明确阐释为何几组常被拿来相互比较的标准（例如 MCP 与 A2A，或函数调用机制与 OpenAPI）在整个集成体系中实际上各司其职、互不重叠。

在此层级中，函数调用模式（Function-calling schemas）与 API 描述标准依然构成了最基础的构建模块。OpenAI 风格的函数调用机制通过 JSON 模式（JSON schema）以及明确的“调用-返回”交互回合，实现了工具调用的具体落地（OpenAI, 2026c）；而 OpenAPI 则提供了一种与特定编程语言无关且机器可读的 API 契约规范，许多智体框架均以此为基础，自动生成并验证所需的工具接口（OpenAPI Initiative, 2025）。此外，诸如 AGENTS.md 和 AGENT.md 之类的仓库级指令文件，提供一种轻量级的替代方案，可将工具的使用方式及工作流约束直接编码于版本控制系统中，从而降低了代码智体（Code Agents）的配置门槛（agentsmd, 2025; agentmd, 2025）。

2 工具描述、发现与选择

一旦协议定义如何发起调用，接下来的瓶颈便在于：在每一个步骤中，应当呈现并选择哪些工具。越来越多的研究工作致力于探讨工具文档的质量、检索机制以及动态候选工具剪枝等问题。EASYTOOL 项目深入分析如何从庞大的工具库中挑选出合适工具所面临的挑战（Yuan et al., 2025）。AnyTool 和 CRAFT 则专注于通过自动构建或优化工具使用流程（pipelines），从而减轻人工指定工具参数的负担（Du et al., 2024; Yuan et al., 2023）。MetaTool 采用基准测试式的评估方法，其结果表明，工具的检索质量与调用质量在不同的应用领域及查询形式之间，往往存在显著的差异（Huang et al., 2023）。近期涌现的 MCP-Zero、ToolRet 和 ToolRegistry 等研究工作进一步强调，具备检索意识的工具编排策略以及高质量的工具注册表，是决定下游智体（Agent）能否成功执行任务的首要关键因素（Fei et al., 2025; Shi et al., 2025b; Ding, 2025）。与此紧密相关的一个研究方向，是将工具选择的范畴扩展至“可复用技能”层面；在此模式下，智体必须识别并调用相关的程序性模块，而不再局限于仅调用精简的 API 接口定义（schemas）。SkillRouter (Zheng et al., 2026) 和 SkillRet (Cho et al., 2026) 两项研究均针对这种大规模的技能选择问题展开了探索，并着重指出了从庞大且存在重叠的技能库中精准检索出所需技能的必要性。

在系统设计层面，上述研究成果印证了两项核心设计原则。首先，“少而精的工具集”往往比“无差别地罗列所有工具”（即暴力式工具暴露）能取得更优异的性能表现；究其原因，这种精简策略既降低了提示词（Prompt）的熵值，又减少了规划器（Planner）在决策时所需考量的分支数量。其次，工具发现流程必须具备自适应能力：那种僵化且全局统一的静态工具列表，将难以适应工具库快速迭代演进的现状，也无法满足多租户企业级部署环境下的复杂需求。

3 工具增强训练与集成

第三个研究方向将关注点从“运行时工具编排”转向“模型能力习得”这一层面。Toolformer 项目通过演示一种自监督增强学习范式，成功展示模型如何学会判断在生成文本的过程中何时以及如何恰当地插入 API 调用指令（Schick et al., 2023）。Gorilla 以及 ToolLLM/ToolBench 等后续研究工作进一步拓展了这一研究思路，通过引入规模更为庞大的工具语料库、构建专门的指令微调（Instruction-tuning）流程，并针对 API 的实际调用过程实施以执行结果为导向的监督训练，从而持续提升了模型的工具使用能力（Patil et al., 2024b; Qin et al., 2024）。 ToolkenGPT 和 CREATOR 探索了token级或控制器式（controller-style）的集成方案，旨在提升调用格式化的保真度及规划过程的稳定性（Hao et al., 2023; Qian et al., 2023b）。

在实际的生产应用框架中，模型侧的这些技术进步通常会与框架级的运行时栈（如 LangChain、Semantic Kernel 和 smolagents）相结合；这些运行时栈负责提供记忆抽象、路由中间件以及工具适配器等功能（LangChain, 2026c; Microsoft, 2026; Hugging Face, 2026）。在代码智体（coding agent）的应用场景下，还会涌现出第二类更具语义特性的工具：静态分析器、类型检查器、基于求解器的验证器、证明助手，以及补丁等价性验证或故障定位工具。Ugare 与 Chandra (2026) 将这一领域定义为“智体式代码推理”（agentic code reasoning）：即智体通过探索代码仓库，对代码的行为进行推理，而无需实际执行这些代码。他们提出的半形式化推理方法介于非结构化的“思维链”（Chain of Thought）与完全形式化的验证技术之间；该方法强制智体明确陈述前提假设、追踪程序执行路径，并推导出显性的结论，从而有效提升了补丁等价性验证、故障定位以及代码问答任务的性能。对于工具层而言，这意味着自动化推理工具在返回结果时，应当提供带有佐证依据的产物——例如执行轨迹、证明义务（proof obligations）、反例或结构化的证明证书——而非仅仅给出非黑即白的“是/否”式回答。综合各项证据来看，工具的实际效能是由预训练与微调信号、接口模式（schema）的质量，以及运行时工具选择策略这三大要素共同决定的；若仅针对其中某一单一组件进行优化，所能获得的性能提升往往十分有限。

4 可扩展性与会话管理

在处理长期运行任务时，会话管理（session management）往往是一个反复出现的运营挑战。虽然有状态的工具会话有助于提升任务的连续性，但也随之增加了状态维护（bookkeeping）的复杂性，尤其是在工具调用被并行化处理或跨多个智能体进行委托执行的场景下。常见的故障模式包括：句柄失效（stale handles）、在重​​试过程中工具状态出现不一致、以及因工具执行轨迹过于冗长而导致上下文窗口（context window）溢出。因此，若要设计出高效稳健的应用框架，必须具备针对工具会话的显式生命周期控制机制、对工具上下文注入进行边界限制的能力，以及能够将错误归因于规划逻辑层面还是接口/协议层面的可观测性钩子（observability hooks）。

最后，对整个生态系统层面的资源与格局进行梳理与归纳，有助于开发者快速掌握当前可用的协议及工具选项；然而，若要针对具体的部署场景来决策究竟应采用哪种协议或工具路由策略，基于基准测试（benchmark）的实证对比分析依然是不可或缺的关键环节。

---

上下文与记忆管理（C）是提示与上下文工程同 Harness 工程交汇的层级。

这一层级决定模型在执行的每一个步骤中能够“看到”哪些信息，以及知识如何在不同的交互轮次和会话之间得以留存。其核心工程难题表述起来很简单：在每一个步骤中，只向模型提供恰好所需的信息，不多也不少。若提供的上下文过少，智体（Agent）将因缺乏必要的状态信息而无法做出正确的决策；若提供的上下文过多，模型的性能便会随之下降——这种性能退化不仅是可量化的，在不同模型之间具有一致性，且其背后的深层机制目前尚未被完全理解。

1 为什么必须对上下文进行工程化设计

仅仅扩大上下文窗口并不能解决“记忆”问题。要理解其中的原因，需要深入审视其底层架构。

二次方的注意成本。Transformer 模型的自注意机制需要计算上下文窗口内每一个token之间的两两关联（Vaswani，2017）。对于包含 n 个tokens的上下文，该机制会产生 n² 个两两配对的权重；这意味着计算资源与记忆资源的消耗都会随着上下文长度的增加呈二次方增长。尽管 FlashAttention 和位置编码插值等工程技术能够降低常数系数，但这种二次方增长的结构性特征是其架构本身所固有的。将上下文长度翻倍，其成本并非仅仅翻倍，而是会暴增至四倍。这一特性使得上下文窗口成为一种稀缺资源。

U 形注意力曲线。仅凭架构层面的成本考量，尚不足以解释为何模型在处理长上下文时会发生性能退化——即便在计算资源充裕、成本可控的情况下也是如此。Liu（2024）提供一项关键的实证结果：在一项涉及 20 篇输入文档的多文档问答任务中，如果包含关键信息的文档被置于上下文窗口的中间位置，模型的准确率会比将其置于开头或结尾位置时下降超过 30%。这种呈“U 形”的性能曲线现象，在各类模型、各类任务以及不同长度的上下文中均普遍存在——即便是在那些专门针对长上下文进行过训练的模型中，这一现象依然成立。这一发现具有直接的现实指导意义：信息在上下文中的“摆放位置”与信息本身的“存在与否”同样重要。如果一个智体（Agent）虽然成功检索到了正确的内容，却未能将其妥善地置于上下文的恰当位置，那么此次检索工作所带来的实际收益将微乎其微。

大规模上下文腐化​​。Hong（2025）在严格受控的实验条件下，对包括 GPT-4.1、Claude Opus 4、Gemini 2.5 和 Qwen3 在内的 18 款前沿大模型进行综合评估。实验环境经过精心设计，旨在将“输入文本长度”这一变量与“任务难度”这一变量隔离开来，从而进行独立考察。结果显示，随着输入文本长度的增加，所有参评模型的性能均出现了不同程度的退化。这种性能退化并非均匀发生，且具有显著的任务特异性。具体而言，在处理那些具有语义歧义的查询（即包含关键信息的段落与提问语句之间不存在词汇层面的直接匹配）时，模型的性能退化尤为剧烈；相比之下，在处理那些存在词汇层面精确匹配的查询时，性能退化则相对和缓。这一对比结果揭示一种复合式的故障模式：模型不仅难以在长文本中准确定位出关键信息，即便在勉强定位到信息之后，也往往无法基于这些信息进行有效的逻辑推理。此外，这种性能退化现象往往早在上下文窗口被完全填满之前就已经开始显现。例如，一款额定支持 20 万个tokens的模型，其性能可能早在输入长度达到 5 万个tokens时就已经出现了显著的衰减。Hong（2025）将这种现象命名为“上下文腐化​​”（Context Rot），并指出这绝非一种罕见的边缘案例，而是一种普遍存在的系统性问题。对于任何需要在多个步骤中累积工具执行结果、中间推理过程及文件内容的智体（Agent）而言，这都是一种常态化的运行工况。

综合来看，这些结果确立一个事实：上下文管理绝非可有可无的“事后补丁”。关于“包含什么内容”、“置于何处”以及“何时移除”的每一个决策，都会对智体的可靠性产生直接影响。

2 从提示工程到上下文工程

从提示工程（Prompt Engineering）向上下文工程（Context Engineering）的演进，体现了其作用范畴的扩展（Karpathy, 2025）。提示工程旨在针对单次模型调用，优化其主要呈静态特性的文本输入。在视觉领域，这一框架同样适用于连续可学习的tokens：视觉提示微调（Visual Prompt Tuning）通过在冻结的视觉Transformer模型的图像块序列前预置一小组可训练向量，使其适应下游任务，且仅需更新不到1%的模型参数（Jia et al., 2022; Xiao et al., 2025）。无论是文本模态还是视觉模态的变体，它们都共享提示工程的核心特征：即针对单一输入模态所进行的、固定且单次生效的优化。相比之下，上下文工程旨在针对跨越多个步骤的任务，在每一个推理环节中，对模型所能获取的全部信息状态进行优化。

Anthropic公司的应用AI团队将其定义为：“一套旨在大语言模型（LLM）推理过程中，策划并维护最优token集合的策略体系——该集合不仅包含提示语本身，还涵盖了所有可能被纳入其中的其他辅助信息”（Anthropic Applied AI Team, 2025）。由此衍生出的指导原则是：在每一个推理步骤中，寻觅并保留那个“最小化”却“高信息密度”的token集合，从而最大化达成预期结果的概率。“渐进式披露”（Progressive Disclosure）策略主张按需实时加载信息，而非在任务伊始便全盘载入；“信息精简”（Compaction）策略负责移除那些已完成其使命的tokens；而“记忆检索”（Memory Retrieval）策略则仅提取与当前任务关联度最高的历史记录。

上下文的构成要素：在实际部署的智体中，推理阶段的上下文通常包含以下要素：系统提示语及行为指令、工具的定义与接口规范（Schemas）、此前交互轮次的对话历史、当前任务执行轨迹中产生的工具调用结果、经检索获取的文档或记忆记录，以及任何动态注入的中间工作状态信息。所有这些要素都必须在模型有限的“注意力预算”（Attention Budget）这一稀缺资源池中相互竞逐。因此，上下文工程的核心要义在于：针对每一个推理步骤中的各个组件，做出明确且审慎的取舍决策，而非任由其无节制地堆积膨胀。

如今，随着相关生态系统的日趋成熟，这种精细化的实践理念已然蔚然成风。如今，各类基础原理手册（Kimai, 2025）及精选综述（Meirtz, 2025）已将“上下文工程”（Context Engineering）视为一门独立的学科。其中，涵盖“活跃上下文窗口”、“会话级状态”及“跨会话存储”的“三层记忆架构”已脱颖而出，成为该领域的主流组织框架。这一架构与操作系统中的经典“存储层次结构”直接对应，不仅提供了直观的理解视角，还确立了一套通用的术语体系，有助于针对不同的时间跨度（即记忆周期），匹配最恰当的技术手段。

3 短期记忆：管理活跃上下文窗口

短期上下文管理主要负责调控模型在单次推理步骤中，或在同一会话内的连续短序列步骤中，所能“感知”的信息内容。此类决策对模型的行为表现具有最直接的影响；若决策失误，其所引发的成本（包括计算资源消耗及性能损耗）往往也是最高的。

系统提示词（System Prompt）校准。系统提示词旨在确立智体（Agent）的行为边界与规范，且在每一次调用时都会占用固定的上下文资源配额。Anthropic 应用 AI 团队（2025）将这一设计挑战形象地比喻为寻找恰当的“高度”：若提示词过于具体详尽，往往会导致逻辑僵化且难以维护；反之，若提示词过于笼统模糊，则会让模型因缺乏具体指引而无所适从。在实际应用中，高效的系统提示词通常会被划分为界限清晰的若干部分——例如背景信息、操作指令、工具使用指南及输出格式要求等——并利用 XML 标签或 Markdown 标题进行区隔。推荐的工作流程是：首先在性能最优的模型上使用一份极简的初始提示词；接着通过实证测试找出模型可能出现的失效模式；最后，针对这些具体的短板或漏洞，有针对性地补充相应的指令。若试图预先穷举并涵盖所有的边缘案例，往往只会导致提示词内容过度膨胀，却无法实质性地提升模型的可靠性。

高效利用 Token 的工具设计。工具定义是消耗上下文资源（Token）的“大户”。每一次模型调用时，工具的架构定义（Schema）、名称、功能描述及参数类型等信息都会被一并注入到上下文中。如果工具集规模庞大，智体甚至在开始处理用户请求之前，仅加载工具定义本身就可能已消耗掉数万个 Token。基于生产环境部署实践所提炼出的核心原则是：相比于提供一份包含大量功能单一、细碎工具的菜单，应优先选用数量较少但功能更为强大、表达能力更强的工具。如果连人类工程师都无法在特定情境下准确判断应使用哪一款工具，自然也无法指望模型能做出更优的判断。理想的工具设计应具备以下特征：功能自洽（Self-contained）、对错误具有鲁棒性（Robust）、且其预期用途必须清晰明确；此外，工具的参数命名应具有充分的描述性，以便充分发挥模型的语义理解优势。

即时检索（Just-in-time retrieval）与渐进式披露（Progressive disclosure）。高效的智体（Agent）并非预先加载所有潜在的相关信息，而是维护诸如文件路径、存储查询和网页链接之类的轻量级标识符，并随着任务的展开按需加载数据。Anthropic 应用 AI 团队（2025）将这种方法称为“渐进式披露”（progressive disclosure）。这恰好映照了人类专家的工作方式：不会死记硬背整个语料库，而是构建外部索引系统，并根据需要进行检索。在实际应用中，Claude Code 采用了一种混合策略。CLAUDE.md 文件会在会话开始时加载，以提供项目背景信息；而 glob 和 grep 命令则允许智体实时导航并加载特定的文件内容。这种做法既规避“索引陈旧”的问题，又避免因预填充大量数据而产生的成本。环境元数据中也蕴含着隐性信号：文件大小暗示了其复杂程度；命名规范揭示了其用途；时间戳则作为相关性的智体指标。智体能够层层递进地构建对环境的理解，仅在当前活跃的窗口中保留当下必需的信息。

KV 缓存-觉察的上下文设计。对于生产环境中的智体部署而言，提示词缓存（Prompt caching）无疑是性价比最高的优化手段；而其成效如何，完全取决于上下文的结构设计。在对其生产级智体架构进行五轮迭代之后，Manus 团队将“KV 缓存命中率”确立为“生产阶段 AI 智体最重要的单一指标”；他们指出，在 Claude Sonnet 模型中，缓存命中的 Token成本仅为 0.30 美元/百万 Token，而未命中缓存的 Token 成本则高达 3.00 美元/百万 Token（Manus Team, 2025）。基于这一缓存模型，衍生出三条设计准则。第一，保持提示词前缀的稳定性：系统提示词（System Prompt）开头的哪怕一个 Token 发生变动，都会导致后续所有内容的缓存失效。第二，将上下文视为“仅追加”（Append-only）的数据流：若修改过去执行的动作或观察结果，会因改变了前缀序列而导致缓存无法复用。第三，采用确定性的序列化机制：若在进行 JSON 序列化时，键（Key）的排序顺序不稳定，则会导致原本完全相同的请求因序列化结果不同而无法命中缓存。鉴于工具定义通常位于序列化上下文的前端位置，因此增删工具的操作会导致后续所有交互轮次的缓存内容全部失效。Manus 团队通过引入一种“上下文感知型状态机”解决了这一问题：该状态机在解码过程中通过屏蔽 Token 的 Logits（对数几率值），从而阻止模型选择当前不可用的动作，而非在运行时动态修改工具定义列表（Manus Team, 2025）。 Anthropic 发布的上下文管理功能，通过显式的 cache_control 断点，在产品层面实现缓存机制的落地（Anthropic, 2025c）。

针对短期上下文管理的工具生态系统已日趋成熟，其涵盖范围现已扩展至：包含智体调用间 KV 缓存压缩模式的生产级技能库（Koylan, 2025），以及提供以 MCP（元上下文协议）为核心原语、用于动态上下文组装的基础设施项目（context-space, 2025）。

4 中期：会话状态与跨运行持久化

中期上下文管理旨在弥合“当前活跃上下文窗口”与“完整的长期记忆系统”之间的鸿沟。具体而言，其核心问题在于：智体如何在同一会话内的不同轮次之间，或在同一任务的多次运行之间，实现状态的保存与恢复。这一技术的工程价值极高：仅需数百个 Token 的结构化工作状态，便足以在上下文重置（即清空）发生时，帮助智体跨越中断点，避免因上下文丢失而导致此前积累的所有任务进度功亏一篑。

结构化笔记记录。最简单的中期管理技术是让智体维护一个持久化的笔记文件——通常命名为 NOTES.md 或 todo.md；智体会在每次任务运行开始时读取该文件，并在上下文被清空（重置）之前对其进行更新。Anthropic 应用 AI 团队（2025）通过一个案例生动地展示了这一技术：他们让 Claude 模拟游玩《宝可梦》游戏，历经数千个游戏步骤。在未接收任何关于记忆结构显式指令的情况下，该智体自主构建已探索区域的地图，维护针对特定对手的战斗策略及其成效的统计记录，并在上下文重置发生后依然能持续追踪既定的任务目标。在每一次清空主对话历史记录的“上下文压缩”步骤完成后，智体便会读取其自存的笔记，从而得以在不丧失连贯性的前提下，继续执行长达数小时的训练序列。这一技术的关键洞察在于：笔记记录机制将“工作记忆”进行了外部化处理。智体不再单纯依赖对话历史记录来承载任务状态，而是将关键信息写入外部存储介质中，并根据实际需要随时将其读取回来。

基于文件的规划与任务外部化。作为“结构化笔记记录”技术的一种扩展，该方法将完整的任务规划表征（planning representation）全部外部化并存储至磁盘中。诸如 planning-with-files（OthmanAdi, 2025）之类的工具，便为编码智体（coding-agent）的工作流提供了相应的技能包，使其能够实现基于文件的持久化任务规划。任务状态、规格参数、中间结果以及依赖关系图等各类信息，均会在任务执行的各个关键里程碑处被写入文件系统；而在下一次任务运行开始时，智体仅会选择性地加载所需信息，从而让那些与当前任务执行并非紧密相关的冗余内容，完全绕过并无需占用宝贵的上下文窗口资源。像 Trellis (mindfold-ai, 2025) 这样的框架扩展了这一模式，将其涵盖至“项目记忆”和“规范注入”领域；它负责管理结构化的项目状态，并根据当前步骤的具体需求进行选择性注入。

跨运行注入。作为一种互补模式，该技术会捕获前一次运行中的关键输出，并将其注入到下一次运行的起始阶段。像 claude-mem (thedotmack, 2025) 这样的工具充当着插件式的记忆层：它们负责捕获会话历史，从中提取对未来运行最有价值的信息，并将其前置（prepend）到下一个会话的上下文之中。这种做法既无需依赖向量数据库，也无需图存储系统，却能为跨运行过程提供显著的连续性。社区代码库 everything-claude-code (affaan-m, 2025) 拥有超过 15 万个 GitHub Star，堪称目前规模最大的此类模式开源集合；它充分展示了“中层记忆”实践在实际生产环境中的编码智体部署中已达到了何等广泛的应用规模。

中层记忆的权衡。相比单纯的“窗口内”（in-window）记忆管理技术，中层记忆技术能够提供显著增强的连续性；与此同时，其所需的基础设施成本仅为完整“长期记忆”系统的一小部分。然而，这种技术的局限性在于：信息流只能单向地从前一次运行传递至下一次运行，而无法像在索引存储中那样进行按需检索；此外，面对海量的历史数据，此类技术的扩展性（scalability）表现并不理想。当跨运行的历史数据量变得过于庞大，或者当智体（Agent）需要精确检索某项特定的过往观察记录而非仅仅注入一份摘要时，就必须引入下文即将详述的“长期记忆”系统，以此作为对中层记忆技术的补充。

5 长期：持久记忆系统

长期记忆系统提供一种经过索引且可检索的存储机制，其存储内容可在不同的会话、任务及智体实例之间持久留存。相较于依赖于“前向注入”摘要的中期记忆技术，长期记忆系统支持“任意回溯”功能：即给定一个查询指令，系统能够检索出与之关联度最高的已存储记忆，而无需顾及其创建的时间。这一层级正是智体随时间推移不断积累经验的场所。

基础架构

受操作系统启发的层级式记忆。Packer（2023）引入一项关键抽象：将大语言模型（LLM）的上下文窗口视为内存（RAM），将外部存储视为磁盘，并赋予模型函数调用能力，使其能够显式地将信息进行“换入”和“换出”操作。这种与虚拟内存的类比非常精准：正如操作系统通过透明的分页机制为应用程序提供了拥有更大记忆的“幻觉”一样，MemGPT 也通过透明的记忆管理机制，为 LLM 提供拥有更长上下文的“幻觉”。智体（Agent）因此能够处理远超其物理窗口限制的上下文内容，并按需从外部存储中检索相关的历史信息。该论文明确揭示了智体记忆与操作系统记忆之间的内在联系，而这一联系正是随后大多数长期记忆系统的底层基础。

观察、反思与检索。Park（2023）在构建社会模拟智体的背景下，引入“记忆流”（Memory Stream）架构。该架构将智体的所有观察记录存储为带有时间戳和重要性评分的自然语言文本。在每一个时间步中，一个检索模型会综合考量三个信号——即时性（Recency）、重要性（由智体在写入时自行评分）以及与当前查询的相关性——从而筛选出最相关的记忆片段。该架构还包含第二项机制，即“反思”（Reflection）：它会周期性地对已存储的观察记录进行综合归纳，从中提炼出更高层级的洞察与见解。具体而言，智体会自省：在近期经历中，哪些问题是最为突出的？随后，它会检索相关的记录，并生成相应的结论，最终将这些结论重新存储回“记忆流”中。消融实验结果显示，观察、反思和检索这三个组件均能独立地提升智体行为的质量；若移除其中任何一个组件，都会导致行为表现出现可测量的显著退化。如今，“观察—反思—检索”这一三元组模式，已成为智能体记忆系统设计的标准范式。

动态遗忘与人格建模。Zhong（2024）在上述检索架构的基础上进行扩展，构建了名为 MemoryBank 的系统，并为其新增了两项功能。第一项功能是受“艾宾浩斯遗忘曲线”（Ebbinghaus Forgetting Curve）启发的动态遗忘机制：记忆的强度会随时间推移呈指数级衰减；若记忆被频繁访问，其强度便会得到强化；而相互矛盾的记忆条目则会被系统进行消解与整合。第二项功能是层级式的用户人格摘要：随着新的交互记录不断累积，系统会每日对这些摘要进行更新与迭代。上述两项核心理念——即自适应的记忆强度管理与用户人格建模——随后在 Mem0 和 Honcho 等系统中得到大规模的落地与应用。

生产级记忆系统

混合存储与行业应用。Mem0（Chhikara 等，2025）是目前在生产级智体（Agent）中部署最为广泛的长期记忆层，拥有超过 1400 万次 Python 包下载量、4.1 万个 GitHub Star，并已原生集成至 CrewAI、Flowise 和 Langflow 等平台中。其架构结合三种存储后端：用于语义相似度搜索的向量数据库、用于关系建模的图数据库，以及用于快速事实检索的键值存储。一个基于大语言模型（LLM）的提取层负责处理新的交互数据，识别其中的事实与偏好，并将记录路由至相应的存储库。在 LOCOMO 基准测试中，Mem0 的准确率比 OpenAI 的原生记忆系统高出 26%，同时其消耗的 Token 数量却比“全上下文”（Full-context）处理方式减少了 90%（Chhikara 等，2025）。2025 年，亚马逊云科技（AWS）选定 Mem0 作为其 Agent SDK 的独家记忆服务提供商，这一举措标志着 Mem0 已成功从科研原型阶段迈向了生产级基础设施阶段。

动态知识网络。A-MEM（Xu，2025）借鉴 Zettelkasten（卡片盒笔记法）这一知识管理系统。它并非将记忆存储为扁平化的记录，而是为每一条新记忆生成一份结构化的笔记；这份笔记包含关键词、标签、上下文描述，以及一组指向语义相关记忆的动态链接。当新增一条记忆时，A-MEM 不仅会将其存储下来，还会追溯性地更新现有相关笔记的上下文与属性，从而使记忆图谱能够随着知识的积累而不断演化。这一机制解决了基于检索的记忆系统所面临的一个根本性局限：即某条已存储记忆的关联性，往往在写入之时尚不显而易见，其真正的意义与价值只有结合后续获取的信息进行参照评估时，方能得以彰显。

从经验中学习。Hindsight（Vectorize — Agents That Learn From Every Conversation，2025）秉持这样一种理念：大多数记忆系统往往过于专注于“记住”信息，而真正的核心需求其实在于“学习”。其 API 开放三项核心操作：retain（保留），用于存储新信息；recall（回溯​​），用于检索相关的既有记忆；以及 reflect（反思），用于生成一种既考量自身内在倾向（Disposition-aware），又将既有记忆与当前上下文深度融合的响应内容。在内部运作层面，retain 操作会提取时间实体、对重叠的事实进行去重处理，并构建出基于确凿证据、高度整合的知识记录。 Hind-sight 在 LongMemEval 基准测试中取得了最先进的性能表现，这一结果已由弗吉尼亚理工大学 Sanghani 中心的研究人员独立复现。
推理驱动的个性化。由 Plastic Labs 开发的 Honcho（Plastic Labs, 2025）建立的是用户模型，而非关于用户的单纯事实存储库。其内部包含一条名为“梦境”（dreaming）的异步推理流水线，该流水线在后台持续处理过往的交互数据，从中提取的不仅是显性事实，还包括关于用户偏好、沟通风格及动态演变目标的推断性结论。这种以实体为中心的数据模型支持多智能体环境，即多个智体可同时与同一位用户进行交互：每个智能体都维护着各自独立的观察视角，从而有效防止了信息间的相互干扰（即“交叉污染”）；与此同时，一个共享的用户模型则负责汇聚并整合来自所有交互过程的理解与认知。

集体记忆。Mozilla AI 推出的 cq（Mozilla AI, 2025）填补其他现有系统所遗留的一项空白：即跨智体实例的共享记忆机制。目前大多数长时记忆系统均采用“单智体专属”或“单用户专属”的模式；这意味着当多个智体协同处理相关任务时，每一个智体实例往往不得不独立地去重新探索并学习其他智体早已掌握的知识。cq 是一项旨在实现智体共享学习的开放标准，它允许智能体在整个智体集群（fleet）范围内，对集体知识进行持久化存储、查询及验证。其架构原生支持 MCP（多智体协作协议），并划分为三个运作层级：存储于开发者本地机器的“本地知识”、供团队内部成员访问的“组织共享知识”，以及跨越不同团队边界的“跨团队知识”。该系统采用一种名为“错误后钩子”（post-error hook）的模式：一旦某个智体遭遇错误，cq 便会自动向集体知识库发起查询。这一机制提供一种切实有效的手段，能够防止在组织内部的各类部署环境中，出现针对同一类重复性故障进行各自独立、重复解决的低效局面。

6 长期任务技术：确保智体在 100 多轮交互中保持连贯性

长期任务——包括大型代码库迁移、跨会话的研究项目以及长周期的自主工作流——则要求同时协调所有三个层级，并针对在特定时刻应采用何种技术做出实时决策。本节将重点介绍在此类规模下所涌现出的集成级技术。

上下文压缩（Context compaction）。上下文压缩是指对即将达到容量上限的上下文窗口进行归纳总结，随后利用这种经过压缩的、代表了当前累积状态的表示形式，重新启动任务执行流程。Anthropic 应用 AI 团队（2025）详细阐述了在此过程中所面临的校准挑战。在进行总结时，必须保留架构决策、尚未解决的错误（bug）以及具体的实现细节；与此同时，则应剔除那些冗余的工具输出，以及那些其推理结果已被后续步骤所采纳的中间推理过程。推荐的调优工作流始于“最大化召回率”——即从执行轨迹（trace）中尽可能捕获每一条潜在的相关信息；随后通过迭代优化来提升“精确率”——即剔除其中多余的内容。切忌反其道而行之。若过早地剔除过多内容，将导致智能体丢失后续任务所需的关键上下文信息，且这种信息的丢失往往是无法挽回的。工具结果清理（Tool result clearing）是上下文压缩中最轻量化的一种形式：一旦智体已依据工具输出采取了相应的行动，这些完整的工具输出内容便会被替换为精简的路径引用。这项技术可实现持续应用，目前已作为一项产品级功能正式上线于 Anthropic 开发者平台（Anthropic, 2025c）。

子智体上下文隔离（Sub-agent context isolation）。当某项任务需要对特定子主题进行深入探索时，探索过程本身往往会产生大量的中间上下文信息；尽管这些信息对于完成子任务至关重要，但若将其直接混入主控智体（orchestrator）的视野中，则会干扰其对整体任务局面的把控。子智体架构（Sub-agent architecture）通过将子任务分配给专门的智体来解决这一问题：每个子智体均拥有一个独立的、全新的上下文窗口，且仅向主控智体返回一份篇幅精简（约 1,000 至 2,000 个 token）的探索结果摘要（Anthropic, 2025e）。如此一来，详尽的探索过程所产生的上下文信息便被隔离并局限于子智能体内部；主控智体接收到的仅是经过提炼与浓缩后的最终结果。Manus 团队（2025）对这一模式提出了一种更为精细化的改进方案。针对那些主控智体仅需获取最终输出结果的简单子任务，主控智体与子智体之间将完全不共享任何上下文信息。而针对那些需要共享状态信息的复杂子任务，主控智体的完整上下文信息则会被传递给子智体。在不同智体（Agent）之间共享上下文的成本很高：这会导致预填充（prefill）数据量增大，并阻碍跨不同系统提示词（system prompts）进行 KV 缓存重用。对于每一种任务类型，都必须明确权衡“隔离成本”与“协作收益”之间的利弊。

混合决策框架。在实际生产部署中，通常不会统一套用某一种单一技术；而是会根据任务结构，在执行流程的不同阶段选用不同的技术。Anthropic (2026c) 将此类框架描述为：预加载那些始终必需的内容；按需检索那些仅在特定条件下才需要的内容；当上下文窗口接近饱和时对历史记录进行压缩；以及在某项子任务需要进行探索性操作（且此类操作会污染主协调器/Orchestrator 的上下文环境）时，派生出相应的子智体。Anthropic (2025d) 进一步引入了“协调层”（Harness-level）的视角：通过引入检查点（checkpoint）与恢复（resume）机制，智体得以在遭遇瞬时故障时仍能存续，且不会丢失当前的任务状态；此外，生命周期钩子（lifecycle hooks）还可在达到预设的阈值时，自动触发上下文压缩或记忆整合操作。这正是职责划分的理想模式。上下文管理理应属于基础设施层面的职责，而非智体自身的职责。当协调层能够自动处理上下文的压缩与整合工作时，模型便能将全部精力集中于任务推理本身。

7 上下文漂移与现有方法的局限性

若从“绑定约束”（binding-constraint）的视角审视，上下文漂移（Context Drift）可被视为一种源自“控制器侧”（controller-side）的故障模式：鉴于模型所能感知的状态仅限于协调层所暴露出的“投影”（projection），因此，任何与任务相关的上下文信息的丢失或失真，本质上均属于协调层所呈现的特性，而非仅仅归因于模型自身的特性 (Bölük, 2026b)。上文所提及的各类技术，虽能在不同条件下发挥作用，且成效各异，但无一能够从根本上解决这一深层问题。上下文漂移——即智能体在经历长时间的交互过程后，其行为表现逐渐发生退化的现象——依然是当前该技术层级中所面临的最棘手、且尚未解决的挑战。

问题的本质。上下文漂移与“上下文腐化​​”（Context Rot）虽均源自相同的架构约束，但二者在本质上却截然不同。上下文腐化​​是针对单一推理步骤而言的一种特性：即在既定的上下文窗口内，随着输入 Token 数量的增加，模型的检索与推理质量便会随之下降。而上下文漂移则是针对整个长期交互轨迹而言的一种特性。随着智体所累积的交互轮次（turns）不断增加，其行为表现便会逐渐偏离最初设定的任务意图；尽管通过上下文压缩与检索等手段可在一定程度上延缓这一漂移过程，却终究无法将其彻底杜绝。在经历100个或更多轮次后，智体往往会重复已完成的工作，在毫无察觉的情况下推翻先前的决策，并偏离其最初的驱动目标（Bowne-Anderson & Huber, 2026）。根本原因不仅仅在于窗口饱和。即使采取了激进的压缩策略，那些在每一轮压缩步骤中幸存下来的摘要信息仍携带着细微的不准确性，且这种不准确性会随时间推移而累积放大。智体（Agent）所累积的假设可能会偏离实际的任务环境，而在当前的架构中，没有任何机制能够检测到这种偏离。

评估鸿沟。另一个次要问题在于，语境漂移（Context Drift）极难衡量。标准的基准测试通常仅针对那些在几十个步骤内即可完成的任务来评估代理的表现；因此，那些在100轮甚至更多轮交互之后才会显现出来的故障模式往往无法被捕捉到。近期的一些研究工作已开始着手弥合这一鸿沟。Tan（2025）引入MemBench，该基准测试通过涵盖时间推理、知识更新以及跨会话聚合等场景的多会话任务，来评估代理的记忆质量。He（2026）则专门针对相互依存的多会话任务设计MemoryArena——正是在此类任务条件下，语境漂移所造成的破坏性往往最为严重。Hu（2025b）提出一种增量式的多轮评估方法，旨在将记忆质量与生成质量区分开来，从而实现独立评估。尽管这些基准测试是必要的，但它们尚不足以解决所有问题。它们确实证明了语境漂移现象的存在，但尚未提供那种能够指导如何预防漂移的机制层面的深入理解。
当前技术为何力有未逮。虽然压缩技术能够减少Token的数量，但它无法保证压缩后的表征能够准确无遗地捕捉到所有的相关状态信息。在每一轮压缩过程中所丢失的信息，一旦失去便无法挽回。尽管检索系统能够调取出相关的过往记忆，但前提是检索查询本身必须是结构良好且准确无误的。然而，一个已经发生语境漂移的智体可能根本无从知晓自己究竟需要检索哪些信息，才能将其行为纠正回正轨。子智体隔离机制虽然能够防止子任务的语境信息污染主协调器（Orchestrator）的语境，但主协调器自身的语境信息依然会随着时间的推移而逐渐发生漂移。Bowne-Anderson与Huber（2026）指出，上述种种局限性揭示一个边界：仅仅依靠“上下文工程”（Context Engineering）本身，是无法彻底解决长周期任务中的可靠性问题的。若要确保可靠性，必须构建一个完整的“驾驭层”（Harness Layer），该层应包含验证回路、在关键节点处引入“人机协作”（Human-in-the-loop）的检查点机制，以及能够识别行为偏离的异常检测系统。

---

生命周期与编排（L）主要关注智体系统如何跨越多次模型调用、工具调用、故障处理、版本修订以及任务移交等环节，从而持续推进并完成一项既定任务。这一层融合了两个在早期框架中往往相互分离的关注点：即智体的执行流，以及该执行流所读取和写入的运行状态。在执行长期任务时，系统的可靠性不仅取决于模型能否生成恰当的“下一步动作”，更取决于其驾驭（harness）能否准确记忆既往事件、决策后续行动、从错误中恢复、协调各项子任务，并在任务完成后适时终止（OpenAI, 2026b; Anthropic, 2025d; 2026c）。

这一层级涵盖三个组织层面的内容。单智体内循环（Single-agent inner loop）是一个重复的周期：单个智体观察当前情境，决定采取何种行动，调用工具或生成输出，并利用所得结果继续推进任务。多智体编排（Multi-agent orchestration）负责协调多个此类循环，通常通过为不同的智体分配不同的角色，或在它们之间进行任务路由来实现。全生命周期管道（Full lifecycle pipeline）则将这些智体循环置于更宏大的软件开发或任务工作流之中，例如涵盖从接收问题（Issue）到代码变更、测试、代码审查，直至提交拉取请求（Pull Request）的整个流程。在这些不同的层级中，各类系统在状态维护方式上也各具特色。无状态重放（Stateless replay）机制通过回溯已记录的交互历史，来重建并重现运行过程。有状态执行（Stateful execution）机制则将操作状态存储在提示词（Prompt）之外，例如存储在文件、代码仓库、数据库、任务图谱或外部服务中。许多实际应用系统采用的是混合模式：它们既保留了可供重放的历史记录，同时也依赖于持久化的中间产物（Artifacts）。

1 生命周期状态管理

生命周期状态管理主要关注那些维持智体运行连续性所必需的操作状态，这些状态需要在不同的轮次、会话、故障恢复以及任务交接过程中得以维系。具体内容包括待处理的子任务、工具执行结果、中间产物、代码仓库变更记录、协调元数据、会话持久化数据，以及检查点（Checkpoint）恢复机制。正是得益于这些机制，智体编排过程才得以具备持久性而非瞬时性：智体能够基于此前的工作基础继续推进任务，而无需将每一个执行步骤都视为一次孤立的模型调用调用。

在此领域，一个核心的权衡点在于“无状态执行”与“有状态执行”之间的取舍。无状态设计通过回溯既往的交互历史来重建执行过程，这有助于提升任务的可复现性与可审计性；但随着执行轨迹（Trajectories）的不断增长，这种方式的成本也会随之攀升。有状态设计则将执行状态持久化存储在文件、数据库、代码仓库、任务图谱或外部服务中，从而增强了任务的连续性与故障恢复能力；但也随之引入了状态一致性维护以及调试方面的挑战（OpenAI, 2026b; Anthropic, 2026c）。因此，许多实际应用的智能体框架（Harnesses）往往采用混合设计模式，将可重放的交互历史记录与持久化的中间产物相结合，以求兼顾二者的优势。

此处所探讨的“状态”概念，有别于“上下文与记忆”（Context and Memory）层级；后者主要关注的是为模型推理过程所提供的各类信息，例如检索到的文档、记忆片段或对话历史记录。它也不同于“可观测性”（Observability）概念；后者主要关注的是针对系统行为进行日志记录、链路追踪以及运行监控。

2 单智体内循环

单智体内循环是智体系统中的基本执行单元。在这一循环中，单个智体通过工具使用和接收反馈，反复与环境进行交互，且无需多个智体之间进行显式的协同。这种抽象机制构成了交互式编程、调试及问题解决过程的基础。

从概念上讲，单智体循环遵循 ReAct 范式（Yao，2023），即交替执行“推理”（Reasoning）、“行动”（Action）和“观察”（Observation）这三个环节。正如 OpenAI 在其对 Codex 智体循环的分析（OpenAI，2026b）中所强调的那样，此类系统的行为不仅取决于其背后的模型，还取决于其“驾驭”（harness）——该框架负责构建提示词、调用工具、管理控制流，并将工具的输出结果反馈至后续的执行步骤中。

在这一层面上，主要的执行模式差异体现在“无状态回放”（Stateless replay）与“混合执行”（Hybrid execution）之间。Codex CLI（OpenAI，2025）是基于回放机制执行模式的最典型案例；而实际应用中的编程智体往往会将可回放的历史记录与文件、代码仓库或会话状态等持久性产物相结合。因此，在表 2 中，OpenCode（Anomaly，2025）、Claude Code（Anthropic，2025）、Gemini CLI（Google，2025）、Codex CLI（OpenAI，2025）、Aider（Aider-AI，2025）以及 SWE-agent（SWE-agent，2025）均被归类于“单循环”（Single loop）这一主要模式之下。尽管此类系统具有一定的灵活性，但在执行周期较长的任务时，往往会面临上下文碎片化、错误累积以及任务分解结构薄弱等问题（Anthropic，2025d），这也促使人们寻求更为结构化的智体编排方案。

3 多智体编排模式

多智体编排通过组合具有特定角色的多个智体，对单智体循环模式进行了扩展。与其让单个智体独自承担规划、执行、检查和修正的任务，多智体框架可以将这些职责分配给不同的智体或子智体。这种结构支持任务拆解、并行探索、批判性评估、验证以及结果聚合，使其比孤立的单智体循环模式更适合处理复杂任务。

在这一设计领域中，存在几种反复出现的模式。层级编排利用高层级控制器将工作分配给智体或子智体，并整合它们的输出结果。团队编排将一组具有特定职能的智体组织成一个协同工作的团队，通常为每个成员分配明确命名的职责。工作流编排将智体和工具组织成明确的阶段或控制逻辑。扇出（Fan-out）模式并行运行多个智体，以探索多样化的解决方案。图结构组合将智体、工具或系统状态表示为交互图中的节点，从而允许多种编排模式共存。这些标签对应于表2中使用的主要模式类别。

这一层级的执行通常采用有状态（Stateful）或混合（Hybrid）模式，因为多智体系统必须维护协调状态、角色分配、任务图谱、共享资源或中间结果。Anthropic 提出的“规划-生成-评估”架构（Anthropic, 2025e）印证了这一更广泛的原则：规划、执行和验证这三个环节可以拆分为明确的角色，这有助于提升任务拆解的质量和系统的鲁棒性，尽管同时也增加了协调管理的开销（Anthropic, 2026c）。

表2中所列的各类系统以不同的方式实现上述模式。DeerFlow (Bytedance, 2026)、AutoGen (Microsoft, 2025)、OpenAI Agents SDK (OpenAI, 2026a) 以及 DeepAgents (LangChain, 2026b) 均归类为层级编排模式。oh-my-claudecode (Heo, 2026) 归类为团队编排模式。LangGraph (LangChain, 2026a) 和 Hive (Aden, 2026) 是图结构组合模式的​​典型代表；Semantic Kernel (Microsoft, 2026) 属于工作流编排模式；而 Emdash (Action, 2026) 则属于扇出模式。

4 从 Issue 到 Pull Request 的全生命周期流水线

全生命周期编排负责管理从需求规范到经校验的最终输出这一完整的任务工作流。在这一层面上，关注的重点不仅在于智体（Agent）之间如何交互，更在于其支撑框架（Harness）如何支持跨越规划、实施、验证、评审及交付等各个阶段的长期执行任务。

其核心抽象概念是“任务运行器”（Task Runner）：这是一种支撑框架，负责在完整的任务生命周期内管理调度、状态持久化、重试机制、验证环节以及迭代优化过程（OpenAI, 2026a; LangChain, 2026b）。具体的执行过程依托于各类持久化制品（Artifacts），例如代码仓库、Issue、分支、文件、测试用例以及 Pull Request 等。一个典型的标准工作流通常始于某个 Issue 或任务规范，随后依次经历智能体规划、代码或制品生成、验证、人工评审，并最终以 Pull Request 被合并接纳而告终。

鉴于此类系统通常是在持久化的代码仓库及外部工作流环境中运作，其所采用的主导执行模型通常属于“有状态”（Stateful）模式。部分系统会将持久化的基础设施状态与子组件内部的类“回放”（Replay-like）或“会话局部”（Session-local）执行模式相结合，这也正是表2中将其归类为“混合型”（Hybrid）的原因所在。Vibe Kanban (Bloop-AI, 2026)、Symphony (OpenAI, 2026b) 以及 GitHub Agentic Workflows (GitHub, 2026) 等系统均被归类为“全生命周期流水线”类型。从概念层面来看，这些系统实际上是对前文所述各类抽象概念的综合运用：单智体循环（Single-agent loops）提供基本的执行原语；多智体模式（Multi-agent patterns）负责提供协作机制；而任务运行器则将上述要素整合为一个端到端的工作流，在这一流程中，人类负责把控方向与决策（Steer），而智体则负责具体的执行工作。

---

。。。待续。。。