agent-harness-">Agent Harness 与裸模型：从“会说话的大脑”到“能干活的系统”

当一个训练好的大语言模型被剥离掉所有外围代码，它本质上是一个纯函数：输入一段文本，输出下一段文本。它不记得上一次对话，碰不到文件系统，无法执行命令，视野被上下文窗口框死，长任务中还会跑偏、遗忘、累积错误。然而开发者在实际使用编码助手类产品时，体验到的却是另一番景象：它能记住项目约定、自主读代码改文件跑测试、连续执行数十步操作。这中间的差距，正是 Agent Harness 所填补的工程空间。

本文对比的对象是裸模型调用（Model-Only）与Agent Harness（模型加工程脚手架）两类方案。前者指直接通过推理接口调用模型、由调用方自行承担全部外围逻辑；后者指包裹在模型之外、驱动其反复运行并与真实世界交互的整套子系统。需要强调的是，二者并非互斥替代关系，而是同一能力链条上的不同抽象层级。

一、对比背景：为什么需要区分这两者

“harness”一词本意是挽具——套在有力气但不受控的牲口身上，把力气导向有用方向。软件工程中的“test harness”（测试夹具）沿用了同一意象：一圈脚手架代码，负责喂输入、驱动被测系统、收集输出。Agent Harness 是同一思路在 LLM 场景的延伸。

核心命题可以压缩为一句话：模型决定能力上限，harness 决定这个上限有多少能真正兑现到具体任务上。 这也是为什么同一个模型套用不同 harness，实际表现可能差出一倍。用工程师熟悉的比喻：模型像 CPU，harness 像操作系统——负责调度、内存管理、设备 I/O、进程间通信。CPU 再强，没有 OS 也跑不起应用；Agent 这个“应用”，跑在 harness 这个“OS”上。

二、对象定义

裸模型调用：调用方构造 prompt，发起一次推理请求，获得文本输出后自行解析、自行决定下一步。所有状态管理、工具调用、错误处理、循环控制都由业务代码承担。模型本身无状态、无工具、无记忆。

Agent Harness：包裹在模型外部的完整工程层，典型包含六个子系统——指令层（角色与规则）、工具层（读写执行与外部协议接入）、记忆层（短期与长期）、上下文管理层（装载、压缩、检索、预算）、控制层（权限、重试、终止、安全）、编排层（子 Agent 并行与上下文隔离）。六层共同服务于中央的 Agent Loop：观察→思考→行动→再观察。

三、相同点分析

两者目标一致：把模型的语言能力转化为任务产出。二者都依赖同一模型权重，能力天花板相同；都需要处理输入构造与输出解析；都面临上下文窗口有限这一硬约束；在简单单轮任务（如文本改写、单次问答、格式转换）上，裸模型调用已足够，harness 的增益有限。换言之，差异不在“能不能做”，而在“能做多长、多稳、多深”。

四、核心差异分析

架构边界。裸模型调用是“请求-响应”式短链路，系统边界清晰但责任外移；harness 是“循环-状态机”式长链路，把状态、工具、权限收拢到统一层。前者接入快，后者可观测性与可控性更强。

功能覆盖。裸模型无法自主读写文件、执行命令、发起外部请求；harness 通过工具层将这些能力标准化暴露，并通过控制层约束其边界（如命令白名单、写入审批、超时终止）。

上下文与记忆。裸模型每次调用从零开始，长任务必然遗忘；harness 通过记忆层持久化关键约定，通过上下文管理层做装载、压缩、检索与预算分配，把“窗口有限”转化为“可管理的工程问题”。

错误恢复。裸模型一次输出错误即需调用方全量重来；harness 内置重试、回退、终止策略，可在循环内局部纠偏，降低长任务的累积误差。

安全与合规。裸模型方案下权限控制完全依赖调用方代码；harness 将身份认证、权限分级、操作审计、数据隔离集中到控制层，便于统一策略与审计追溯。

运维与成本。裸模型调用运维面小但重复建设多，每个业务都要自造轮子；harness 前期建设与调优成本高，但边际复用性强，多任务场景下人力成本摊薄。资源成本两者都随调用量增长，harness 因多轮循环通常 token 消耗更高，需通过预算控制与压缩策略平衡。

五、对比表格

维度	裸模型调用	Agent Harness
架构形态	单次请求-响应	循环状态机 + 六层子系统
工具能力	无，需调用方外挂	标准化工具层，统一约束
记忆与上下文	无状态，窗口硬约束	持久化记忆 + 压缩检索预算
错误处理	调用方全量重试	循环内重试、回退、终止
安全控制	分散在业务代码	集中权限、审计、隔离
接入成本	低	中高，需建设与调优
适用任务长度	短、单轮	长、多步、需交互
复用性	每个业务重复建设	跨任务复用

六、典型场景选择

单轮文本处理、轻量分类抽取、离线批处理中的独立短任务，裸模型调用更经济直接。需要多步操作、跨文件修改、外部系统交互、长周期任务追踪的场景——如代码库级重构、自动化运维流程、多源信息汇总——完整 harness 的收益显著。介于两者之间，可采用“轻量封装”：仅实现循环控制与工具调用，暂不建设记忆与编排层，随任务复杂度渐进演进。

七、选型建议与迁移注意事项

选型应基于任务长度、工具依赖度、错误容忍度与团队运维能力四个条件判断，而非绝对优劣。若任务普遍为单轮且输出可直接消费，优先裸模型调用；若任务需要连续决策且失败代价高，harness 的集中控制与审计能力更关键。

从裸模型迁移到 harness 需注意：接口层从单次调用改为循环驱动，业务代码需适配状态传递；工具接入需定义权限边界与超时策略，避免越权操作；上下文预算与压缩策略需按任务实测调优，防止关键信息被压缩丢失；多轮循环带来的 token 成本上升需纳入容量规划；日志与审计粒度需同步升级，确保循环内每步可追溯。反向从重 harness 裁剪为轻封装时，需评估记忆与编排能力移除后对长任务稳定性的影响。

八、总结

裸模型与 harness 的差异，本质是“能力上限”与“能力兑现率”的差异。模型是大脑，harness 是身体；前者决定能想什么，后者决定能做成什么。理解六层子系统各自解决的问题，比记住某个具体实现更重要——因为无论技术栈如何演进，把无状态纯函数导向有用工作的工程逻辑始终成立。选型的核心问题不是“哪个更好”，而是“我的任务需要多长的循环、多强的约束、多高的复用”。