Agent 驾驭系统剖析
多数构建 AI 代理的工程师将 80% 的时间花在思考使用哪种模型上，20% 的时间花在其他所有事情上。这个比例应该反过来。模型在这一点上几乎是可以互换的——决定你的代理是否能在生产环境中实际工作的是“线束（harness）”。
这个等式很简单：**代理 = 模型 + 线束。**如果你不是模型，你就是线束。而几乎所有真正的工程工作都存在于线束中。
线束是围绕模型的所有代码、配置和执行逻辑的总和。它处理状态、工具、内存、执行、上下文窗口、错误恢复以及模型无法独立完成的所有其他事情。模型是无状态的文本转换器。线束才是将它们变成代理的关键。
模型无法独立完成的事情
要理解线束为何重要，请从模型根本无法做到的事情开始：
- 在调用之间保持状态
- 执行任意代码
- 访问训练截止日期之后的信息
- 管理自己的上下文窗口
- 决定何时完成
这些并非等待下一次模型发布即可解决的临时限制。它们是架构上的事实。即使是能力显著增强的模型，也需要处理文件系统访问、工具调度、持久化和生命周期管理的线束。线束不是之后可以废弃的脚手架——它是系统的一个永久层。
这就是为什么 2025 年被越来越多地视为代理证明其可行性的一年，而 2026 年则是工程团队弄清楚如何让它们 可靠地 工作的一年。这种可靠性差距几乎完全存在于线束中。
六个核心组件
生产级别的代理线束有六个功能领域。缺少其中任何一个，你的代理都会以特定且可预测的方式失败。
1. 文件系统和存储
文件系统是线束实现持久性的主要机制。没有它，每次代理运行都将从头开始。有了它，代理可以：
- 跨会话和上下文窗口重置持久化状态
- 将大型工件从上下文窗口中卸载（写入磁盘，通过路径引用）
- 与其他代理协调——文件系统是多代理团队的协作界面
- 通过结构化文件实现记忆，这些文件会被注入未来的提示中
那些跳过持久化存储的团队，最终会在用户抱怨他们的代理“忘记”了正在做什么时，在压力下重新构建它。从一开始就将其构建进去。
2. 代码执行和 Bash 工具
通用代码执行是你赋予代理的最高杠杆能力之一。当代理能够运行代码时，它们就会从局限于预配置工具转变为能够即时设计解决方案。
拥有 bash 工具的代理可以：
- 编写并运行自己的诊断脚本
- 转换未明确编程处理的数据格式
- 通过运行断言来验证自己的输出
- 按需安装依赖
实际的好处是巨大的。实际的缺点是，你给了代理一把上膛的武器。这引出了我们的下一个组件。
3. 沙盒和执行环境
沙盒化是生产代理部署中最难解决的问题。大多数团队都低估了它。
幼稚的方法是在宿主机上运行代理代码。这在代理运行不该运行的 rm -rf 命令，或向你不想它访问的服务发出网络调用，或安装与你的生产环境冲突的软件包之前，都工作得很好。
一个合适的沙盒提供：
- 隔离：文件系统和网络访问范围限定在代理实际需要的内容
- 预装依赖：代理不应该在每次运行时都需要引导其环境
- 日志和可观察性：代理采取的每一个行动都应该是可检查的
- 验证循环：沙盒应包含测试运行器和 linter，以便代理可以检查自己的工作
关键的见解是，沙盒化并非为了约束代理 ——而是为了给代理提供一个安全的自主操作界面。一个设计良好的沙盒中的代理可以更具侵略性和能力，而不是更少，因为错误的爆炸半径得到了控制。
专门用于此目的的、可在几毫秒内启动的生产级沙盒现已存在。如果你正在生产基础设施上直接运行代理代码，那么你有一个尚未发现的沙盒问题。
4. 记忆和知识系统
代理线束中存在两个截然不同的记忆问题：
长期记忆——代理应在不同会话之间保留的内容。这通过文件、数据库或向量存储来实现，线束在每次运行开始时将其注入上下文。代理不会“原生”地记忆事物；线束为其加载记忆。
实时知识——代理需要知道的、在其训练日期之后的信息。这通过网络搜索工具、MCP（模型上下文协议）集成和检索系统来实现。没有这些，你的代理将根据几个月或几年前的世界快照进行操作。
两者都至关重要。一个拥有长期记忆但没有实时知识的代理，将拥有出色的回忆能力但信息过时。一个拥有实时知识但没有长期记忆的代理，将敏锐但健忘。大多数早期的代理实现完全放弃长期记忆，然后疑惑为什么用户感觉每次会话都是从头开始。
5. 上下文管理
上下文窗口是有限的资源。天真的实现会把它们填满，然后崩溃。优秀的辅助框架（harness）将上下文视为 一流的工程关注点。
主要策略有：
压缩（Compaction）：当上下文窗口填满时，总结之前的对话，然后用这个总结开启一个新的上下文。模型获得一个干净的窗口，同时关键信息得以保留。
工具输出卸载（Tool output offloading）：工具的输出——特别是像文件读取或 API 响应这样的大型输出——可以写入磁盘，而不是插入到上下文。代理获得文件的引用，而不是完整内容，它可以在需要时读取文件。
渐进式披露（Progressive disclosure）：不要将所有可用的工具加载到每个提示中。只加载与当前任务相关的工具。过多的工具加载会增加噪音，从而降低模型性能。当你只需要 5 个工具却加载 50 个时，反而会显著损害输出质量。
上下文预算跟踪（Context budget tracking）：建立对已消耗上下文量的意识，并在达到限制之前（而不是之后）触发压缩或卸载。
正确处理此问题的团队将上下文视为预算——而不是一个直到溢出才停止填充的垃圾桶。
6. 长周期执行模式
单次任务基本已经解决。前沿是需要跨越多个上下文窗口、数百个步骤的任务。
这里的可靠性计算是严酷的。如果多步骤管道中的每一步成功率为 95%，那么一个 20 步任务的端到端成功率仅为 36%。在 50 步时，端到端成功率降至 8% 以下。将单步可靠性从 95% 提高到 99%，20 步任务的成功率将达到 82%——在不改变任务结构的情况下，实现了 2 倍的提升。
这使得每一步的错误恢复和重试逻辑成为承重基 础设施，而不是事后才考虑的事情。
一个值得明确命名的模式是：循环重注入模式（loop reinject pattern）。当一个长期运行的任务需要比任何单个窗口都能容纳的更多上下文时，辅助框架会在每个新上下文窗口的开始处，重新注入原始任务提示，并带上代理基于文件系统的状态跟踪器。代理始终知道它从何处开始以及当前处于何处。上下文是短暂的；文件系统是真相的来源。
这种模式使无限长度的任务变得可行。它还使得辅助框架的状态管理设计成为任务可能性的决定性约束。
IMPACT 框架
一个确保你的辅助框架涵盖所有方面的有用心智模型是 IMPACT 框架：
- 意图（Intent）：代理如何理解并在长期任务中保持其目标？
- 记忆（Memory）：代理记住什么，以及如何记住？
- 规划（Planning）：代理如何分解任务并安排行动顺序？
- 权限（Authority）：代理拥有哪些权限，以及如何执行这些权限？
- 控制流（Control Flow）：代理如何循环、分支和处理错误？
- 工具（Tools）：代理可以在现实世界中采取哪些行动？
任何无法对这六个问题给出明确答案的辅助框架都存在缺陷，这些缺陷将在生产中表现为故障。
可靠性乘数
以下是为什么辅助框架工程被低估的原因：模型质量在实践中具有对数回报，但辅助框架质量具有复合效应。
模型原始能力提高 10% 可能只会让你的基准测试提升 5%。在 20 步工作流中，每一步可靠性提高 10% 可以使你的端到端成功率翻倍。
那些在交付脆弱辅助框架的同时，却只专注于模型选择的团队，正在优化错误的变量。可靠性是在辅助框架中建立或丧失的。
多代理架构进一步放大了这一点。当协调器将任务委托给专业的子代理时，每个子代理都有独立的上下文窗口，专注于特定任务，整个系统就能处理任何单个代理都无法应对的问题。但这种架构只有在每个代理的辅助框架都稳固的情况下才有效——一个不稳定的子代理辅助框架会将故障沿着链条向上蔓延。
从行为反向工程
设计辅助框架的正确方法是，从你想要的行为开始，反向推导出你需要的组件。
如果你需要一个能够处理跨越数天任务的代理，你需要长期记忆和循环重注入模式。如果你需要一个能够安全修改代码库的代理，你需要一个带有测试运行器的沙盒。如果你需要一个能够保持最新状态的代理，你需要实时知识工具。如果你需要多个代理协作，你需要一个共享文件系统作为协调层。
不要凭空增加基础设施。但在交付之前，请务必将你预期的用例映射到这六个核心组件，并诚实地面对你所接受的差距。
展望未来
随着模型的改进，一些辅助框架的功能将迁移到模型本身中。未来的模型可能会原生处理更长的上下文，从而减少对激进压缩的需求。更好的指令遵循能力可能会降低单个步骤的失败率。
但辅助框架的核心功能——沙盒执行、持久状态、实时知识、显式内存管理——在可预见的未来仍将是工程关注点。模型处理推理；辅助框架处理所有使推理在现实世界中有用的事情。
那些及早弄清楚这一点的工程师正在构建他们的同行将在 2026 年试图复制的系统。辅助框架就是护城河。
