gent harness（执行编排层）正在成为提升长周期代理性能的核心驱动力。行业测试表明，在模型保持不变的前提下，仅通过编排层的改进即可带来显著的性能增益：LangChain 在 Terminal-Bench 基准上通过 harness 调整提升了 13.7 分；Vercel 在裁减 80% 工具的同时实现了更高的可靠性，并将延迟降低至原来的三分之一。这些案例中的性能差异来源于编排层，而非模型本身。
编排层快速迭代的背后，是代理任务范式的转变。团队正在将代理推向更长时间跨度、更多步骤的工作场景，并发现第一代架构在长任务中会快速退化。典型的单系统提示词模式——通常包含两万余 token 的条件指令，以及前置注入的 20 至 40 个工具 schema——无法在长任务中维持有效性。将指令迁移为按需渐进加载的技能模块，使系统提示词减少 45% 以上，在处理需要独立多源研究和结果回写的复杂表单任务时，表现出了明显的架构优势。
一种常见的认知是：编排层的演进源于模型能力的提升。但这并非唯一的驱动力。更根本的原因在于，代理被赋予了更多的工作量，而更多的工作意味着更多的上下文。每一次额外的工具调用、技能执行、搜索结果和运行输出，都会累加到上下文窗口中。随着流经代理的工作量和工作种类不断增加，上下文管理已成为核心的工程问题。从本质上看，harness 就是一个分布式的上下文管理系统。
这一判断指向了一个更深层的工程趋势：当代理从单次问答工具演变为长时间运行的工作系统时，架构设计的重心必须从"如何让模型更聪明地调用工具"转向"如何在有限的上下文窗口中高效组织计算"。上下文窗口的物理限制不会因模型能力提升而消失，因此编排层必须在上下文之外寻找状态存储和逻辑执行的载体。
本文将系统讨论编排层设计的四个关键变化：
-
• 沙箱中的程序化工具调用（PTC），将工作流逻辑移入沙箱代码执行，用变量和文件而非提示词保存中间状态
-
• 子代理将单一代理循环拆分为隔离的执行上下文，每个子代理拥有独立的上下文窗口
-
• 压缩策略保留关键对话状态，将原始中间输出转移至文件系统
-
• 技能的搜索优先发现机制，将工具和技能的发现与 schema 加载解耦，仅在执行时获取完整定义
代码作为主要执行原语
随着代理任务的复杂度提升，代码正在成为代理的主要执行原语。当工作涉及结果集迭代、条件分支、数据过滤与连接、证据排序、批量操作和独立步骤并行时，代码比一连串对话式工具调用更自然地表达这些逻辑。在传统的对话式调用模式中，模型需要在每一轮对话中从聊天记录中重新推导执行计划，而代码可以直接表达循环、分支和并行结构。
程序化工具调用（Programmatic Tool Calling, PTC）将这一工作流逻辑移入沙箱执行环境。工具被暴露为 Python 可调用函数，模型编写一段小程序，在单次执行中完成数据检索、过滤、分支、循环、磁盘写入和动作执行，而非分散在数十轮对话中。20 次工具调用可以在一次沙箱运行中完成，编排器仅接收汇总结果和结构化元数据，中间数据保留在 Python 变量和文件中。
PTC 嵌入合适的编排层后，可以在四个维度获得收益：
延迟方面，独立操作可以在单次代码运行中批量执行和并行化，而非在 LLM 往返调用之间串行等待。可靠性方面，循环、过滤、连接和条件分支在代码中比在脆弱的对话链中更为稳健，模型不再需要在每一步从对话历史中重建执行计划，同时堆栈跟踪使错误恢复变得更加直接。一致性方面，脚本可以保存为技能模块，使常见任务能够复现相同的工具调用序列。上下文效率方面，仅有汇总结果或最终输出返回编排器，每个中间产物不再占用上下文窗口，这使得大规模分析、批量操作以及需要分页、存储、计算和回溯状态的长任务变得可行。
这一设计选择的本质，是将代理从"对话式决策系统"重新定义为"具有程序作用域和文件系统的执行引擎"。当代理拥有了在上下文窗口之外操作状态的能力时，长任务的可行性边界被显著扩展。同时，代码作为执行原语也带来了新的工程问题：沙箱的安全性、代码生成的正确性验证、以及如何在模型生成的代码与预定义技能之间做合理的职责划分，这些都将成为编排层设计中需要持续面对的挑战。
子代理作为上下文隔离边界
子代理并非代理架构中的新概念，但程序化工具调用（PTC）显著扩展了其执行规模与可靠性。编排代理能够通过生成代码，以程序化方式启动多个并行子代理，将原本受限于手动调度的操作转化为可自动编排的工作流。
当编排代理需要对大量独立对象施加同等深度的分析时，子代理模式的价值尤为突出。例如研究数百个客户画像或分析数千条支持工单，每个子代理在独立的上下文窗口和 token 预算内执行任务，互不干扰。编排代理则通过提示词模板或程序化任务定义，向所有子代理分发统一的工作规范。
这种隔离机制带来两个直接收益。其一，每个子代理可以将全部注意力集中于自身任务的上下文，分析深度不受其他无关信息稀释。其二，系统得以横向扩展可重复的推理过程，而不会使单一上下文窗口承载过载。该设计思路与递归语言模型（Recursive Language Models）的核心思想一致：高层智能体负责工作分解，将边界清晰的任务委托给底层工作单元执行。
在多代理协作流程中，任务的生命周期呈现为编排分发、子代理独立并行执行、结果回传、编排聚合四个阶段。各层级代理可以共享知识图谱、技能索引、沙箱环境和模型枢纽等公共资源，但在执行层面保持上下文隔离。这种架构将工作负载从单点集中式处理转变为分布式并行处理，同时通过隔离边界确保每个推理单元的输入输出可控、可追溯。
从上下文管理的角度审视，子代理本质上是一种主动的上下文分区策略。与其在单一窗口内通过摘要或截断被动地应对上下文膨胀，系统通过创建隔离的工作单元，将问题域拆分为多个可独立维护的上下文片段。每个片段的规模被约束在可控范围内，推理质量因此得到保障。当工作规模进一步扩大时，子代理自身还可以继续向下委派，形成多层级的递归分解结构。
压缩策略：保存工作状态的上下文裁剪
子代理机制解决了横向上的上下文隔离问题，但并未处理单个代理内部上下文随对话轮次不断累积的困境。实际运行中约有 5% 的查询会触及上下文窗口上限。为此，需要引入压缩策略来保留对任务继续执行具有关键负载作用的对话状态：用户原始意图、已做出的决策、验证失败的方法路径、计划的后续步骤，以及近期高信号的工具输出。其余信息则被摘要化或直接移出上下文窗口、写入文件系统。最终目标是生成一个经过压缩但语义完整的任务状态表示，使代理能够在多轮交互后无缝接续工作。
这一机制在技术实现上分为两个层面。
对话压缩处理的是早期交互轮次的原始对话流。多轮问答的完整记录被精简为结构化摘要：用户最初提出了什么请求、代理尝试了哪些路径、哪些方案生效、哪些未能达成预期、下一步准备如何推进。通过剥离冗余的试探性对话，保留决策骨架，代理能够在有限的上下文窗口内维持对任务全貌的认知。
工具输出压缩针对的是体积庞大的工具返回结果。当某个工具调用产生大量输出时，完整内容被写入沙箱文件系统，上下文中仅保留精简摘要及对应的文件路径引用。代理需要查阅原始数据时，可通过路径重新读取文件。这种方式将上下文窗口从存储功能中解放出来，使其专注于维持推理链的连贯性。
压缩机制与子代理机制在架构上形成互补。子代理通过隔离上下文减少编排器接触到的无关细节，将中间工作状态封闭在独立的执行空间内；压缩机制则处理编排器自身历史中残留的内容，在时间维度上维持任务的连贯性。一个从空间维度裁剪上下文，一个从时间维度裁剪上下文。两者共同作用，使代理系统能够在长周期、多步骤的复杂任务中保持状态一致性，而不受固定大小上下文窗口的刚性约束。
这种时空二维的上下文管理策略揭示了一个更深层的设计取向：上下文窗口不应被视为工作记忆的容器，而应被视为推理焦点的窗口。真正的工作状态可以通过外部存储持久化，上下文窗口的价值在于维持当前推理步骤所需的精确信息集。
搜索优先的技能发现机制
技能（skill）正在成为封装可复用经验的开放标准。其核心优势在于渐进式披露——代理预先仅加载技能的名称和描述，只有当任务实际需要时，才会获取完整的技能内容。
然而在大规模场景下，仅靠渐进式披露仍然不够。当代理面对数百个工具或技能时，即便每个条目只有一行描述，累积起来也会形成大量噪声，代理必须在其中筛选出与当前请求相关的能力。大多数能力在特定请求中都是无关的，这种浏览成本不容忽视。为此，引入了覆盖全部技能的索引机制，仅将相关的技能加载到上下文中。
技能发现采用三阶段流程。第一阶段是搜索索引：模型识别到需要某种能力后，主动查询索引。这种搜索不仅依赖语义匹配，还利用图谱信号（如创建者、使用频率等）进行排序，从而在多人创建相似技能的场景下，仍能准确定位到最合适的选项。
第二阶段是短列表与轻量描述：索引返回一小批候选技能，包含名称、描述和执行提示。这是模型首次接触到这些能力的具体信息，它可以从这个精准筛选后的列表中选择适合当前任务的技能。
第三阶段在执行时加载完整 schema：只有当模型决定执行某个具体技能时，该技能的完整定义或 skill.md 文件才会进入上下文。
通过这种机制，代理无需为浏览全部能力面支付上下文开销。描述信息仅出现在模型主动搜索过的能力上，完整 schema 仅出现在即将执行的那一个技能上。每一层细节都在代理真正需要的时刻才被披露。代理的决策质量也随之提升——它面对的是一个精准筛选的短列表，而非数百条待扫描的条目，这使得 harness 能够扩展到更大的能力面。
结语
从整体架构来看，harness 正在通过更加分布式的策略来扩展和管理上下文。程序化工具调用处理复杂的执行逻辑，子代理隔离各自的上下文，压缩机制在保留任务状态的同时卸载上下文负担，技能发现则确保代理始终聚焦于当前任务。这四层机制相互独立又彼此补充，共同构成了一个可扩展的上下文管理框架。
harness 本身不会停止演进。每一代新的 AI 工作模式都会暴露出上一代方案的局限，而 harness 的设计也随之迭代。随着代理任务复杂度的提升和所需上下文规模的扩大，上下文管理的核心问题将从"如何装入更多信息"转向"如何在恰当的时机披露恰当的信息"。搜索优先的发现机制代表了这一方向上的一个重要实践——将上下文视为按需分配的资源，而非一次性加载的静态载体。