简介：同一个大模型，直接调用与套上Harness变成Agent，实际能兑现的能力可能相差一倍。本文从系统形态、状态记忆、工具触达、上下文管理、安全控制、编排与成本等维度，系统对比“裸模型直调”与“基于Harness的Agent”两类方案，并给出典型场景选型建议与迁移注意事项，帮助开发者判断何时单次调用已够用、何时必须搭建Agent循环。
大模型能力普及之后，几乎所有团队都会在某个时刻遇到同一个选择题：需求来了，是直接调用模型接口、把结果拼进业务流程，还是投入工程资源，把模型包成一个能持续干活的Agent？
这道题选错的代价不小。把简单的单轮任务套上复杂的Agent循环，会平白付出多倍的token成本和更长的延迟，还要维护一堆脚手架代码；反过来，把多步骤的工程任务塞进单次调用里，模型会跑偏、遗忘、无法触达真实系统，最终只能靠人工把流程切成碎片再拼接。要做出正确判断，需要理解两者之间真正拉开差距的那一层——Agent Harness（Agent“挽具/脚手架”）。
业内有一个流传很广的判断：“模型决定了能力的上限，harness决定了这个上限有多少能真正兑现到你的任务上。”同一个模型，套不同的harness，实际表现可能差出一倍。这也是本文做这组对比的意义：不是比较两个模型谁更强，而是比较“模型裸奔”与“模型+Harness”两种应用形态的差异与边界。
一个训练好的大语言模型，剥离所有外壳之后，本质是一个纯函数：输入一段文本（context），输出下一段文本，仅此而已。它有三个与生俱来的限制：
裸模型直调方案，就是直接围绕这个纯函数构建应用：单次或批量调用模型推理服务，加上提示词工程与结果解析，不引入额外的运行时循环。在百度智能云等大模型平台上，这类形态通常对应最基础的模型调用服务。
“harness”一词本意是马的挽具——套在一头有力气但不受控的牲口身上，把它的力气导向有用的方向。软件工程里早有”test harness”（测试夹具）：一圈脚手架代码，负责喂输入、驱动被测系统运行、收集输出。Agent harness沿用了完全相同的意象：它是包裹在LLM外面、驱动它反复运行并与真实世界交互的那一整套工程脚手架。
一个完整的harness通常包含六个子系统，环绕着中央的模型：
方案B就是“模型+Harness”的整体：模型仍然只负责文本进文本出，但Harness把这条纯函数变成了一个循环——观察→思考→行动→再观察——直到任务完成。
一句话概括两者的关系：模型是大脑，harness是身体；模型像CPU，harness像操作系统。CPU再强，没有操作系统也跑不起任何应用；Agent这个“应用”，正是跑在harness这个”OS”上的。
在展开差异之前，先明确两类方案共享的基础，这决定了“换方案”时哪些资产可以继承：
方案A的生命周期是一次请求级别的：请求进来，文本出去，结束。方案B则是一个循环：模型在每一轮观察环境反馈、思考下一步、执行动作，循环几十步完成长任务。用示意代码表达差异：
# 方案A：裸模型直调result = llm(prompt) # 一次调用，生命周期即结束# 方案B：Agent循环（Harness驱动）context = load_instructions() + load_memory()while not done and steps < MAX_STEPS:observation = collect_feedback() # 观察：工具结果、环境反馈thought = llm(context, observation) # 思考：模型仍是纯函数action = execute(thought) # 行动：读写文件/执行命令/调用接口context = manage(context, observation) # 压缩、检索、预算控制
这个形态差异是其余所有差异的根源：因为要循环，所以需要状态；因为要行动，所以需要工具与权限；因为循环会很长，所以需要上下文管理和终止条件。
裸模型没有任何记忆，跨轮次的信息全靠调用方自己拼接进上下文。Agent方案里，Harness承担两类记忆：短期记忆维持当前任务会话中的中间结果与执行轨迹；长期记忆把项目约定、历史决策等持久化到记忆文件中，在下次任务开始时装载。“能连续干上几十步”不是模型变强了，而是Harness替它记住了该记住的东西。
裸模型碰不到任何东西：不能读文件、不能执行命令、不能发请求，全部作用域就是输入输出文本。Agent通过工具层获得真实世界的操作能力——文件读写、命令执行、通过标准化协议接入的外部服务。这也意味着风险等级完全不同：方案A出错最多是输出内容不对，方案B出错可能是真实地改坏了文件、执行了危险命令。
裸模型的视野被固定窗口框死，超出即不可见，长任务必然丢信息。Harness的上下文管理层把窗口当作需要主动经营的预算：按需装载相关材料、对历史轨迹做压缩、通过检索把远处的信息拉进窗口、对不同内容分配token预算。长任务不跑偏的很大一部分功夫，花在这里。
裸调用的安全边界清晰：内容审核、输出过滤即可。Agent因为能执行真实动作，必须有一整层控制机制：敏感操作前的人工审批、工具调用的权限分级、失败后的重试策略、任务级和步数级的终止条件。缺少这一层，Agent的能力越强，事故半径越大。
裸模型是单点执行。成熟的Harness支持把大任务拆给多个子Agent并行处理，每个子Agent拥有隔离的上下文，互不污染，再由主Agent汇总。这让系统可以处理远超单个上下文窗口的工程规模。
方案A的成本可预估：每请求一次调用、一次token消耗，延迟通常在秒级。方案B是循环执行，token消耗随步数放大（每步都携带完整上下文），端到端延迟以分钟计，还需要日志、追踪、监控等运维投入。这是很多团队低估Agent运行成本的地方。
单次调用输出方差相对小，结果好评估。Agent长链条执行中，每一步的小偏差会累积放大，出现跑偏、遗忘、重复劳动等失败模式，需要检查点、自我校验和终止条件来兜底。
| 对比维度 | 方案A：裸模型直调 | 方案B：Agent（模型+Harness） |
|---|---|---|
| 系统形态 | 单次请求-响应的纯函数 | 观察→思考→行动的持续循环 |
| 状态与记忆 | 无状态，每次从零开始 | 短期会话记忆+跨会话长期记忆 |
| 外部触达 | 无法读写文件、执行命令、发请求 | 通过工具层操作真实系统 |
| 上下文管理 | 固定窗口，超出即不可见 | 装载、压缩、检索、预算四类手段 |
| 控制与安全 | 风险限于输出内容 | 需要权限、重试、终止、安全护栏 |
| 编排能力 | 单点执行 | 子Agent并行、分工、上下文隔离 |
| 延迟与成本 | 单次调用，成本低、延迟短 | 多轮调用，token与时间成本放大 |
| 结果确定性 | 输出方差小，易评估 | 误差可能累积，需检查点与终止条件 |
| 工程复杂度 | 低，接入快 | 高，需要完整脚手架与持续运维 |
| 适用任务 | 单轮、封闭、无环境反馈的任务 | 多步、开放、需与真实系统交互的任务 |
这些场景的共同特征是：任务一轮内可完成、不需要环境反馈、不产生真实副作用。此时引入Agent循环，通常只会增加成本与不稳定因素。
共同特征是：任务无法在单轮内完成、执行结果依赖真实环境反馈、需要状态延续。
从方案A迁移到方案B，不是“换个接口”，而是引入一个新的运行时，需要提前评估：
回到开头那句话：模型是大脑，harness是身体。裸模型直调与Agent方案的全部差距，不在于模型本身，而在于是否为这个“大脑”配上了负责记忆、触达、视野经营、控制与编排的“身体”。
选型逻辑可以浓缩为三句话：任务单轮可完成、无环境反馈、无副作用，用裸模型，把工程精力花在提示词与流程拼接上；任务多步、开放、需要操作真实系统，用Agent，把工程精力花在Harness的六个子系统上；介于两者之间、流程可枚举的，用工作流编排做过渡。而在Agent路线内部，同一模型下Harness质量的差异可能带来一倍的实际表现差距——这意味着选择Agent之后，真正的竞争力不在模型，而在那圈脚手架的打磨深度。