大模型趋同后，Agent Harness 工程如何决定应用上限？

一、当模型不再是唯一变量

过去两年，围绕大模型能力的竞争主要集中在参数规模、训练数据与推理能力上。但随着头部模型在通用基准上的表现逐渐收敛，一个越来越明显的趋势是：模型本身正在趋同，而应用效果的分化越来越取决于模型之外的工程层。

在实际的智能体（Agent）系统中，模型只是决策核心之一。围绕模型构建的提示词模板、工具定义、工具返回结果的格式、执行循环的控制逻辑，共同构成了一个完整的运行环境。业界常把这一层统称为 Harness（驾驭层/工程外壳）。

一个容易被忽视的事实是：同一个模型，放在不同的 Harness 中，完成同一个任务的准确率、成本和延迟可能相差数倍。而同一套 Harness，换一个模型，成绩单也可能完全不同。这意味着，模型决定“可用能力”的上限，而 Harness 决定这些能力在连续执行中能发挥出多少。

二、长任务的三笔账：上下文、成本与延迟

一个复杂的智能体任务，可能连续执行数百轮工具调用与推理循环。每一次循环都会产生三类开销，我们称之为“三笔账”。

1. 上下文账：重点被淹没

随着轮次增加，对话历史、工具返回结果、中间推理不断累积。上下文窗口越来越长，真正关键的信息可能被大量无关结果稀释。模型在冗长上下文中定位关键约束的能力会下降，表现为“忘记目标”“重复提问”“忽略已有结论”。

2. 成本账：输入 token 持续膨胀

每一轮请求都要携带历史上下文。如果 Harness 不做裁剪、摘要或结构化压缩，输入 token 会随轮次线性甚至超线性增长，直接推高推理费用。长任务中，成本往往不是由单次调用决定，而是由循环结构决定。

3. 延迟账：用户等待被拉长

每一轮准备、序列化、网络往返、模型推理都需要时间。轮次越多，累计延迟越明显。对于交互式场景，延迟直接决定用户体验；对于批处理场景，延迟影响吞吐与资源占用。

请求结构同时影响质量、成本与延迟，这三者并非独立，而是相互牵制。Harness 的核心工作，就是在三者之间做动态权衡。

三、重复行为：长任务中最典型的浪费

长任务里最常见的低效模式，是模型反复读取已经读过的文件，或者再次提出已经被否决的方案。这类重复并不完全是模型能力问题，很多时候是 Harness 的信息组织方式导致的：

• 工具返回结果没有做去重与标记，模型无法判断“这个文件已经读过了”；
• 中间结论没有显式记录，模型在后续轮次中重新推导；
• 执行循环没有阶段划分，模型缺少“当前处于哪个阶段”的元信息。

Harness 能控制的信息返回方式、记录机制和循环结构，会显著影响重复的严重程度。例如，通过在工具返回中附加“已读标记”，或在循环中维护一个结构化的任务状态表，可以有效减少无效重复。但改善多少，必须通过实测来验证，不能仅凭直觉假设。

四、Harness 的架构要点：模型无关与逐模型验证

一个设计良好的 Harness，通常具备以下特征：

1. 模型无关的架构

Harness 不绑定单一模型。用户自带 API Key，也能使用同一套提示词、工具与循环结构。这种解耦让系统可以在不同模型之间迁移，而不必重写整个工程层。

2. 默认开关、提示词与工具描述需逐模型验证

“接入同一个 Harness”并不意味着每个模型自动获得相同收益。不同模型对提示词格式、工具描述风格、返回结构敏感度不同。默认开关、提示词模板、工具描述都需要针对具体模型逐个验证和微调。

3. 统一内核，多入口

无论通过桌面端、命令行还是 SDK 接入，运行的都是同一个内核。这保证了行为一致性，也意味着优化在一处生效，处处受益。

五、如何评估 Harness 的真实收益

在理解 Harness 的作用之后，再看评测数据才有意义。评估时需要注意几点：

1. 数据来源：厂商自测数据通常有特定条件，不能直接等同于你的项目收益。
2. 多次试验：每个任务跑多次 trial，观察方差，而不是只看单次最好成绩。
3. 例外情况：同一套工程思路，在不同模型上可能交出不同成绩单。例如在某些模型上更准更省，但延迟增加；在另一些模型上则相反。
4. 端到端指标：不仅看单步准确率，还要看任务完成率、总 token 消耗、总耗时和重复调用次数。

一个可参考的评估框架如下：

# 伪代码：Harness 评估的核心指标采集
metrics = {
    "task_success_rate": None,      # 任务最终完成率
    "total_input_tokens": None,     # 累计输入 token
    "total_output_tokens": None,    # 累计输出 token
    "total_latency_ms": None,       # 端到端延迟
    "redundant_tool_calls": None,   # 重复工具调用次数
    "context_utilization": None,    # 有效上下文占比
}
# 每个任务至少跑 3 次，取均值与方差
for trial in range(3):
    result = run_agent_task(task, harness, model)
    update_metrics(metrics, result)

六、工程实践建议

结合上述分析，可以给出几条可落地的实践建议：

• 上下文分层管理：将系统提示、任务目标、阶段状态、工具结果分层存放，按需注入，避免全量堆叠。
• 工具返回结构化：统一返回格式，附加状态标记与去重标识，减少模型重复读取。
• 循环阶段化：为执行循环定义明确阶段（探索、规划、执行、校验），每阶段有独立的上下文策略。
• 逐模型调优：更换模型时，重新验证提示词、工具描述与默认参数，不假设收益自动迁移。
• 持续实测：建立自己的评估集，覆盖长任务、多工具、异常分支等场景，用数据驱动优化。

七、结语

当大模型能力逐渐趋同，应用之间的差距将越来越多地体现在 Harness 工程上。模型决定可用能力，Harness 影响这些能力在连续执行中如何发挥。理解上下文、成本与延迟的三笔账，控制重复行为，做好逐模型验证，才能让智能体在真实业务中稳定落地。这不是一次性的调参工作，而是一套需要持续迭代的工程体系。