多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

Code designs Harness 还是 Model drives Harnesses?

Code designs Harness 还是 Model drives Harnesses? If youre not the Model, youre the Harness.这是 Langchain 提出过的观点强调了 Harness 在构建 Agent 过程中的重要性。从事过后端开发、设计过分布式系统的朋友肯对对胶水代码、中间件很熟悉展开本文正文前我们来结合两个熟悉的概念来进一步加深理解 Harness。胶水代码泛指把两个东西粘在一起的代码没有自己的业务含义纯粹是连接器。听上去不高级因为它暗示这层代码没有设计、是偶然产物。中间件分布式系统中的术语强调位于两端之间的一层服务通常指消息队列、RPC 框架、API 网关这类基础设施有明确的工程定义和产品形态。Harness在 Agent 时代他的定义既精准又抽象精准的是它特指围绕一个 LLM Agent 的运行时控制逻辑什么时候调用模型、调用几次、怎么校验输出、失败怎么重试、多步骤怎么编排等等是对 Agent 运行时策略的驾驭。抽象的是很难像中间件那样做出明确的工程定义和产品形态。虽然三者都属于工程范畴但是各自要解决的问题和解决范式是完全不同的。对于 Harness驾驭层通常没有被表示为干净、可研究的对象。将驾驭逻辑高度耦合在控制器代码里例如提示词、工具适配器、解析规则、校验脚本、产物路径、重试逻辑、上下文策略等。一个看似微小的驾驭层改动可能同时改变调用边界、工具中介、状态载体、校验门、停止语义。这让驾驭层难以检视、移植、对比和消融尽管驾驭模式本身往往才是系统中真正可复用的部分。听上去有些矛盾既难驾驭、又是可复用。但我想从事 Harness 工程设计的朋友能感受到 Harness 工程的特殊性。最近看到一篇技术论文《Natural-Language Agent Harnesses》受益良多。论文围绕“智能体驾驭层这种可复用的设计模式能否被表示为一个可执行的自然语言对象将模型周围偶然的胶水转变为科学的表示对象”的研究课题并给出了研究方法感兴趣的朋友可以阅读原文本文尝试做一个简单的解读。控制一次智能体运行的三种方式现代语言模型智能体已经成为多步执行系统。它们使用工具、保持状态、从失败中恢复、校验中间结果有时还会把工作委派给其他智能体。这些行为由一个外部驾驭层来组织而该驾驭层会对实测性能产生很大影响。在智能体脚手架、工作流生成、长上下文执行、多智能体编排、工具使用智能体等近期工作中也出现了类似的关切。图 1控制一次智能体运行的三种方式其谱系从“限制性驾驭”到“无外部驾驭”即自驾驭self-harnessing从左到右是外部控制越来越弱、模型自主性越来越强。其中代码驾驭层通过程序逻辑对模型施加硬性外部控制。自然语言智能体驾驭层NLAHs智能驾驭运行时IHR把驾驭策略移入可读的自然语言同时由一个共享运行时通过子智能体调用来执行该策略。自驾驭则是一种可能的未来设计由一个控制器模型直接驾驭其他模型而不需要任何外部驾驭层。论文主要围绕第二点展开研究把驾驭策略从代码中外置为可执行的自然语言对象NLAHNatural-Language Agent Harnesses自然语言智能体驾驭层可编辑的文档用自然语言描述运行级驾驭策略包括阶段、角色、状态规则、校验规则、恢复规则、停止条件等。IHRIntelligent Harness Runtime智能驾驭运行时一个共享的运行时把这些 NLAH 文档解释执行为智能体调用、交接、状态更新、校验门、产物契约等。其中自然语言承载策略代码与运行时承载精确机制诸如工具执行、解析、沙箱、日志等。论文的核心贡献是引入 NLAH作为智能体驾驭模式的显式自然语言表示它既区别于运行时策略也区别于确定性的代码钩子。引入 IHR一个共享的、在环in-loop的运行时把 NLAH 转化为可审计的智能体调用、交接、状态更新、校验门与产物契约。探索了智能体驾驭系统中自然语言与代码的边界朝着把自然语言的作用范围从局部指令大幅拓展到驾驭层级策略迈出第一步。在三类基准上提供了受控证据NLAH 能以相当的任务结果塑造智能体行为、暴露简洁的静态驾驭策略并支持模块级分析。NLAH 和 IHR 的四层架构图 2NLAHIHR 框架基础智能体一个最小化的 agent 循环LLM 唯一工具 终端。通过终端可以读写文件、运行命令、启动子 agent。本身不包含任何任务逻辑是一块“白板”。运行时策略一段固定的 NL 指令把基础智能体变成智能驾驭运行时 IHR。告诉它“你的角色是读取 NLAH 文档、按文档调度子 agent、管理 state 文件、做 call-graph recovery、执行 contract-first completion。”对所有任务通用不随具体任务改变。自然语言驾驭 NLAH 文档这就是论文的核心创新。一份可以阅读、编辑、做对照实验的自然语言文档描述任务阶段划分、角色与分工、状态流转、验收标准、失败恢复、停止条件。具备可替换换个 .md 文件就换了任务。脚本与适配器不需要 LLM 判断的硬逻辑实现 JSON schema 校验、diff 行数计算、格式转换、外部 API 调用封装。由 NLAH 文档中的规则触发IHR 进行调度执行。这个可以认为是构建 Harness 的新范式做个比喻基础智能体是马运行时策略是骑手自然语言驾驭文档是今天这趟行程的路线图可以换脚本与适配器是路上的信号灯和检查站确定性规则。如何评估新范式的效果有了核心架构后就要开始设计评估方法。RQ1驾驭实现NLAH 能否在保持任务性能的同时塑造可观测的智能体行为RQ1 对比同一驾驭思想的三种实现按驾驭层能多直接地控制执行排序代码驾驭层Code Harness所研究的智能体驾驭层家族的原始代码实现——控制器代码、工作流脚本、框架默认值、工具适配器。它提供最强、最确定的控制但其策略与实现细节交织在一起。提示词式 NLAHPrompted NLAH把相同的 NLAH 内容作为普通提示词/指令文本提供给 Codex CLI 智能体没有 IHR 的共享运行时章程与执行语义。它测试“当自然语言只是被动指令载体时”能获得多少控制。IHR 执行的 NLAHIHR-executed NLAH由 IHR 解释并执行的 NLAH带有针对子智能体生命周期、产物与状态处理、契约门、停止的显式运行时语义。它放弃了代码驾驭层的硬性确定性但为自然语言策略提供了一个能物化角色、交接、状态、校验边界的执行基质。在 SWE-bench Verified、Terminal-Bench 2.0、OSWorld 三类基准上IHR 执行的 NLAH 取得与代码驾驭层相当的成绩同时把静态可读策略大幅压缩如 Live-SWE 从 6.01 万 token 代码降到 2.9k token 的 NLAHMHTBA 从 1.05 万降到 0.8k。代价是当前原型运行时的 token/调用开销更高。RQ2驾驭机制实现RQ1 证明了自然语言能等效承载 harness 策略之后论文进一步追问一个更细的问题模型在执行 NLAH 时对文档里写的每一条机制究竟有多忠实为此他们把一份 NLAH 中的指令拆解标注为 8 类可观测的驾驭机制例如交付物契约、工具成功门控、阶段交接、停止条件等然后让 IHR 在三个基准任务上实际运行逐条比对“文档要求做的”与“模型实际做的”为每一类机制计算一个遵循率。研究结果是“有好有坏、差异显著”契约式、可即时验证的机制遵循度很高因为这类指令边界清晰、模型每一步都能自查而依赖跨阶段、跨子 agent 协调的机制遵循度明显偏低。这种“执行质量不均”的发现为 RQ3 的模块消融提供了动机。RQ3模块消融由于 NLAH 被刻意写成阶段与机制分离、模块边界清晰的结构每个功能模块都对应文档中一段可独立增删的文字这使得经典的消融实验第一次可以在策略层而非代码层开展。论文采用 leave-one-out 方式每次只关闭 NLAH 中的一个模块如 file-backed state 文件持久化状态、self-evolution 自我进化、multi-candidate search 多候选搜索、context compression 上下文压缩、markdown memory 等其余保持不变再测量相对完整 NLAH 的成功率变化。整个过程不改动任何底层代码只编辑文档因此能干净地把每个模块的贡献单独归因出来。消融揭示出模块价值高度分化且部分看似有用的设计实为负资产文件持久化状态是最稳的正贡献Δ 约 2.6 / 13.9说明让 agent 把中间状态外化到文件比依赖上下文记忆可靠得多自我进化模块带来最高绝对性能Live-SWE 78.8 / 52.8但代价是 token 消耗大幅上升而多候选搜索反而损害性能分散了模型注意力且昂贵上下文压缩在两个任务上都有害省了 token 却丢了关键信息markdown memory 则表现不稳定、收益依任务而定。总体结论是harness 模块“不是越多越好”有效的工程实践应优先保留可外化状态、审慎使用自我进化、并主动剔除多候选搜索与上下文压缩这类负收益模块。这也首次把“该保留哪些 harness 设计”变成了一个可用实验数据回答的问题。局限和风险论文也提到了这种范式的局限和风险。局限是自然语言的不精确性。NLAH 是可编辑的自然语言策略因此语义上重要的约束可能被欠定义、被不同模型不同解读、或被改写削弱。因此论文把精确机制保留在代码里并把执行出的行为当作必须通过实际运行来检验的东西避免仅从文本进行推断。风险是把驾驭模块外置可以降低开发成本、改善可比性、并鼓励复用稳健的工作流。然而可移植的驾驭逻辑与脚本也可能降低传播危险工作流的门槛。由于驾驭层中介了工具使用、产物处理与委派它们可能为提示注入、恶意工具嫁接或供应链污染引入新的攻击面。部署时应结合溯源追踪、审查、权限控制与沙箱隔离。
返回列表