Agent Harness（智能体运行外壳）

Harness 一词借自软件工程中的 test harness：指把被测组件装进去、在受控条件下跑起来的夹具。这个类比之所以成立，是因为智能体运行层解决的问题结构相同——它既不产生智能，也不产生业务逻辑，而是提供「让某样东西可靠地跑起来」的环境。

推动这个术语成形的现实原因是分工的错位。一次模型调用是无状态的：输入文本、输出文本。而一个智能体是有状态的：它在循环里反复调用模型、累积上下文、可能在第 14 步失败、并且持续消耗预算。团队在把演示推向生产时发现，模型只占工程量的少数，真正反复重建的是它外面的那套机器——按轮次装配上下文、撮合工具调用、从失败中恢复、施加额度限制、记录发生过什么。这套机器被一个项目一个项目地重写，于是需要一个名字。据 Hugging Face 的 Agent 术语梳理以及 Snowflake、Databricks、Stacklok 等厂商的公开说明，agent harness 已在 2025-2026 年被广泛采用，并派生出 harness engineering（外壳工程）这一专业化方向。

一个简化的表达是：Agent = 模型 + Harness。模型提供智能，Harness 提供组织愿意把真实动作交给这份智能所需的全部条件。

把生产级 Harness 拆开，责任大体落在六处：

执行循环。这是骨架。它把「发给模型、执行模型选择动作、把结果回填上下文」串成循环，直到任务完成或触达停止条件。这一模式即 ReAct 提出的推理-行动交替循环（见 arXiv:2210.03629），此后所有复杂机制——重试、子智能体、规划——都可以视为这一循环的展开形式。

工具执行。Harness 向模型暴露工具清单，校验模型发出的调用参数，真正执行它，并把结构化结果回填。工具描述是否清晰、是否难以误用，直接影响模型表现。

上下文与记忆管理。每一轮决定什么进入有限的上下文窗口，什么被摘要、压缩或丢弃，什么需要从外部检索回来。这是 context engineering（上下文工程）落地的位置。

状态持久化。跨轮次、跨会话保存事实、文件与进度。缺了这一层，一次超时或重启就会让长任务从零开始，或者留下一个半完成且无记录的状态。

权限与护栏。在执行之前判定：这个工具能不能调、这份数据能不能读、这笔开销是否在预算内、以谁的身份行动。审批提示属于这一层。

错误恢复与轨迹记录。超时、重试、检查点、回滚，以及把每一步动作、工具调用与决策记录下来，使「这个智能体做了什么、为什么」有据可查。

这几个词在行业里长期混用，区分它们的可行方式是看各自作用的对象。

Scaffold（脚手架）作用于模型：系统提示、工具定义、输出格式、上下文组织方式——即模型工作时所依据的材料。Snowflake 在其技术说明中引用 Hugging Face 的划分指出，scaffolding 是模型工作的依据，而 harness 是调用模型、处理工具调用、并决定何时停止的执行层。脚手架带有临时性：随着模型自身能力提升，它应当变小。

Harness（运行外壳）作用于系统：它是脚手架加上循环、工具执行、记忆、护栏与可观测性之后的完整运行时。

Framework（框架）作用于开发者：它提供搭建 Harness 的积木——模型接口、工具抽象、记忆组件、编排模式。用框架不等于拥有 Harness，不使用框架也不妨碍写出 Harness；据 Stacklok 的层级划分，框架回答「我该怎么写这个智能体」，Harness 回答「这个智能体怎么才能安全、可重复地运行」。

Orchestration（编排）作用范围更窄：它只负责协调下一步——调哪个工具、起哪个子智能体、走哪条分支、何时停止。编排是 Harness 的一个子集，但 Harness 还要为每一步提供安全、持久与可观测的支撑。部分厂商的划分中另有一层 gateway（网关），负责模型与工具之间的流量审查与准入控制。

Harness 不是可以忽略的管道，它直接决定智能体在真实任务上的可用程度。差异主要来自四类操作条件。

工具空间的大小与清晰度。工具越多、定义越模糊，模型选错的概率越高。据 Snowflake 在 Harness 说明中引述 Vercel 的内部实践，其文本转 SQL 智能体在移除约 80% 的工具并简化架构后，报告的成功率从 80% 提升到 100%，同时步骤数、Token 消耗与响应时间都下降。这条经验的指向是：可靠性往往来自更简单、更一致的动作接口，而不是更多选项。

上下文策略。同一模型在不同压缩与检索策略下，长任务表现会出现明显分化，这也是基准分数难以跨实现比较的原因之一。

状态管理与恢复路径。有检查点的智能体可以从已知点继续；没有检查点的智能体只能从对话历史里重新推断进度。

权限边界与控制点。在执行前施加约束，比事后审计更有效。

把 Harness 当作可对照的变量，已经成为研究的做法。2026 年 9 月一项被行业广泛讨论的 Harness 价值分解研究（见 arXiv:2609.20474）把规划环节拆成固定与随机两档做对照，报告固定规划带来约 7.17 个百分点的增益，并指出验证器组件能以每回合不到一美分的成本拦截约 61% 的无效轨迹——这类结论的意义在于，它把「外壳贡献了多少」变成了可测量的量。

Harness 缺失时，故障模式高度一致：花费失控（智能体卡在同一个工具调用上整夜循环，团队从账单上才得知）、状态丢失（20 步任务在第 14 步失败后要么归零要么半途而废）、权限过大（智能体继承部署者的全部凭据，改动生产数据时与人类操作无法区分）、无法审计（安全评审问「它能做什么、做过什么」时只能翻应用日志）、行为不可复现（上下文膨胀后模型丢失指令，行为漂移，且无人能还原它当时看到了什么）。

这些都不是模型问题，而是外壳问题。工程上的对策也随之成形：为工具与数据划定显式边界，把审批与额度写入外壳而非提示词，用检查点承载长任务，把每轮上下文与每步轨迹落盘，并把评测挂到外壳上——因为换外壳就等于换系统，模型卡上的分数不能替外壳背书。需要提醒的是，Harness 层的强化并不自动带来安全：外壳同时是权限的集中点，一旦外壳自身可被智能体改写，隔离效果会连同护栏一起失效，这属于沙箱逃逸一类问题的讨论范畴。

Harness 与模型的耦合正在加深：前沿实验室倾向于把模型与其专用外壳一起训练和发布，把模型迁入陌生外壳往往会掉性能。这一趋势会带来三个后果——harness engineering 作为岗位与学科继续专业化；外壳能力（检查点、权限描述、轨迹格式）逐步标准化，可观测性语义约定与权限清单可能成为下一批协议层议题；以及评测口径的变化，模型卡分数与系统级分数会被更明确地区分开来。目前官方与行业尚未披露统一的 Harness 能力描述规范，后续将持续跟进迭代动态。