模型之外：编排层决定AI应用上限的三项改造

大语言模型正从单轮问答走向多步骤、多工具的复杂任务。任务变长以后，决定系统表现的因素越来越多地落在模型参数之外。一些研究团队提出”约束绑定假说”：在长周期的自主智能体任务中，系统效能主要由包裹在模型外部的控制框架（即Harness）决定。

这一判断正在改变团队的选型思路。过去团队比较的是模型本身，现在，编排层的设计已经成为AI应用架构的核心问题之一。

一、为什么编排层会决定上限

简单问答或单段代码生成中，模型的预训练知识和推理能力基本决定输出质量。任务变长后，情况就不同了。涉及多文件修改、持续状态交互和频繁工具调用时，模型容易出现三类问题：上下文遗忘、工具调用格式出错，以及对环境状态的理解与真实状态不一致。

Harness位于基础模型与运行环境之间，通常包含四部分：系统提示词策略、工具调用接口定义、上下文压缩与注入中间件，以及错误拦截与回滚机制。它不改变模型权重，但决定模型看到什么信息、能调用什么工具，以及出错后如何处理。

部分研究报告显示，只调整编辑工具的交互格式和周边Harness，不改动模型权重，任务通过率就有明显提升，有的报告给出的提升幅度可达数倍。不过，这些报告大多没有公开基准名称、测试环境和样本量，因此它们只能说明方向。读者若要引用具体数字，应先查阅原始报告的测试条件。

二、如何构建高可用Harness：三步落地实操指南

把Harness的潜力变成稳定的生产效果，可以从三个环节入手。

1. 把系统提示词做成状态机

静态提示词在长任务中容易让模型行为漂移。更稳妥的做法是把提示词拆成若干状态，每个状态对应一组行为约束。系统根据环境反馈切换状态，反馈信号包括测试通过率、编译器报错和任务所处阶段。每一步下发的指令都与当前情况匹配，模型就不必在一大段固定说明里自行判断该遵守哪条规则。

状态转移最好写成显式的配置表，而不是散落在代码分支里。下面是一个示例：

当前状态	触发事件	目标状态	下发的提示词模板
编码中	编译失败	修复中	“修复报错，不改动无关文件”
修复中	测试未通过	调试中	“只针对失败用例修改”
调试中	测试全部通过	收尾	“整理变更并生成摘要”
任意状态	连续三次工具调用失败	等待人工确认	“停止自动修改，等待人工判断”

显式的转移表便于测试和审查。团队可以逐条检查每个事件是否有明确去向，也能在出现异常行为时快速定位是哪条规则出了问题。表中”任意状态”那一行尤其重要。它保证无论模型处于哪个阶段，连续失败都会转交人工处理，不会无限重试。

1. 中间件上下文注入怎样做

长任务的历史记录会快速占满上下文窗口，关键指令随之被挤出。中间件在模型读取输入之前做一次清洗：保留文件差异、核心报错堆栈和未完成的子任务，剔除重复的探针式调用日志和已失效的中间结果。清洗后的信息用统一格式重新注入，信噪比会更高。

过滤规则可以写成如下配置：

{
  "keep": ["file_diff", "error_stack_top_20_lines", "pending_tasks"],
  "drop": ["probe_call_log", "duplicate_tool_output", "expired_state"],
  "max_tokens_per_block": 2000
}

规则需要结合具体任务调整。过滤过猛会丢掉关键线索，过松则无法控制上下文膨胀。建议先用一批真实任务的日志做回放，比较保留与丢弃的内容对结果的影响，再确定参数。

这套规则可以接入主流框架。在LangChain中，清洗逻辑可以封装成一个可运行的处理步骤，放在提示词模板和模型之间。以下为伪代码：

def clean_context(inputs):
    inputs["history"] = apply_filter(inputs["history"], KEEP, DROP)
    return inputs
chain = prompt | RunnableLambda(clean_context) | llm

回调机制更适合记录日志和监控，不适合修改输入。在LlamaIndex中，同类逻辑可以放在节点后处理器（postprocessor）里实现，伪代码如下：

class ContextCleaner(BaseNodePostprocessor):
    def _postprocess_nodes(self, nodes, query_bundle=None):
        return [n for n in nodes if keep_rule(n)]

如果项目没有使用框架，一个独立的预处理函数加上统一的消息格式，同样能达到目的。

1. 自验证拦截如何防止错误扩散

模型偶尔会产生幻觉或无效调用。自验证拦截在指令触及外部环境之前进行合法性检查，例如校验参数格式，确认命令在允许范围之内。一旦发现格式错误或潜在破坏性操作，Harness会拒绝执行，并要求模型重新生成。错误因此止步于拦截层，不会进入文件系统或代码仓库。

拦截规则一般分三层。第一层检查参数结构是否符合工具定义。第二层检查命令是否在白名单内。第三层针对删除、覆盖、对外发送等操作，要求人工确认。前两层适合自动化，第三层应当保留人工入口。拦截还需要设置最大重试次数，避免模型在被拒绝后陷入无效循环。

有一组终端环境测试显示，保持同一款先进商业模型不变，仅加入提示词重构、上下文注入和自验证拦截三项改造，任务通过率明显上升。公开材料没有披露模型版本、基准集名称和样本量，因此这组结果的可比性需要单独核实。

三、自动优化能走多远

手工调优高度依赖工程师经验。换一个模型或业务场景，往往要重新来过。业界因此开始探索”元编排”，让系统自动优化Harness本身。

基本思路是把任务成功率当作奖励信号，自动调整几类参数：系统提示词的措辞、工具返回结果的截断长度、验证拦截的阈值。经过多轮执行，系统会找到与当前模型更匹配的编排策略。

相关报告称，在不修改模型权重的前提下，自动优化后的整体成绩超过了人工调优的结果。但报告没有说明对比基线的测试条件，因此它更适合作为”自动优化有潜力”的参考，不宜当作固定的性能承诺。

这种思路把Harness视为一组可优化的”软参数”。迭代速度可能快于传统微调，前提是有稳定、可度量的成功率信号。没有可靠的评估指标，自动优化会朝错误的方向收敛。

除了任务通过率，还需要观测几个量化指标，判断优化是否真正有效：

• 单任务平均Token消耗：反映每个任务的费用。
• 单步平均延迟：反映拦截与清洗增加的响应时间。
• 单任务重试率：反映拦截规则和状态切换是否合理，重试过多通常说明规则过严或提示词有歧义。
• 拦截触发率：反映模型产生无效调用的频率，若持续升高，应检查模型或工具定义是否有变化。
• 人工介入率：反映自动流程离可用还有多远。

若单步延迟持续上升，而通过率没有变化，说明优化正在增加负担，应当回退到上一版本。团队在开始自动优化之前，应先建立固定的评测集，并记录每次改动的成本与结果。

四、Harness的代价与权衡

Harness也有成本。额外的验证、上下文清洗和状态切换都会增加延迟，多轮修正还会消耗更多Token。设计时，团队需要把这些成本和准确率提升放在一起衡量。

下面是三类改造的定性比较，可用于项目初期排序优先级：

改造手段	额外延迟	开发成本	对准确率的主要作用
提示词状态机	低	中（需梳理状态与约束）	减少长任务中模型行为的漂移
上下文清洗中间件	中（每轮都需过滤与格式化）	中到高（需定义保留与丢弃规则）	降低上下文噪声，保留关键线索
自验证拦截	低到中（每次调用前需校验）	中（需定义三层规则与白名单）	阻止破坏性指令落地，并收敛无效重试