AutoDesign：自动搜索 Harness，让长周期 Agent 告别手工编排

最近几个月接触 Agent 项目的开发者大多会经历一种“从震撼到心累”的心理曲线第一天觉得 LLM 什么都能干第二天开始想要不要给 Agent 加记忆第三天已经搞不清是该调整 System Prompt、多让模型反思几次还是换一套规划策略。尤其是面对需要连续执行几十步甚至上百步的长周期任务Agent 经常在开头表现正常越往后越离谱目标丢失、重复劳动、工具调用混乱、最终输出看起来“正确但没什么用”。这些问题的共性不在单次模型调用而在 Agent 的外围编排层我们怎么给模型规划路径、怎么约束工具调用、遇到错误要不要重试、多久反思一次、什么时候停止。较新的研究和讨论正在把这一层视为核心优化对象。AutoDesign 这个方向通常会被拆成三个关键词来理解——Long-Horizon Agentic Design 是问题域Harness 是干预对象Meta-Harness Optimization 是优化方法。把它翻译成工程语言就是不再手搓 Agent 的“骨架与缰绳”而是设计一套自动机制让机器在任务实例上搜索出更优的“编排策略”。这篇文章不会去虚拟某个具体测试结论而是把 AutoDesign 背后的技术判断拆开讲透Harness 到底是什么、Long-Horizon 为什么难以手动设计、Meta 层优化跟普通 Prompt 优化有什么区别并给出一个可以参考的最小代码实验框架。适合正在做 Agent 应用、被多步任务稳定性和流程调参折磨的读者收藏。1. 先理解“Harness”Agent 外那层不起眼的脚手架单论模型本身今天的 LLM 并不缺“理解能力”缺的是在开放任务中稳定执行的能力。一个最简单的 Agent Demo通常只需要 Prompt LLM 一个工具函数看起来足够惊艳。可一旦进入生产环境你迟早会在模型外面包上这些逻辑规定最多执行多少轮、限制哪些工具可用、工具出错时重试几次、每几轮让模型做一次自我检查、最终输出必须符合某个 Schema。这一整圈代码就是 Agent 的 Harness。Harness 这个词直译是“挽具”像马匹身上的缰绳和背带作用是让蛮力能被方向化地使用。在 Agent 系统里它也是模型与真实执行环境之间的控制层。你不直接控制模型每一步想什么但可以通过 Harness 设定搜索路径、边界条件和终止信号。过去很多团队把 Harness 当成“工程胶水”不值得单独设计。但你越是做长任务越会发现真正决定 Agent 好坏的不是模型参数而是这层胶水写得好不好。它包含的其实是一组控制策略任务怎么切分、上下文怎么组织、什么时候让模型停下、用到什么程度才算完成。如果我们说“大模型是发动机”那么 Harness 就是传动系统、制动系统和仪表盘的合集。顺着这个思路就能理解 AutoDesign 的切入点既然 Harness 对结果影响这么大而手写 Harness 又极度依赖个人经验能不能用算法来自动寻找一个好的 Harness这个反问就是 Meta-Harness Optimization 的核心动机。2. Long-Horizon Agentic Design 为什么让人头疼Long-Horizon 不是一个形容词而是指任务具备明确的“长期跨度”特征目标无法一次完成需要多步推理、多次工具调用或阶段性反馈才能收敛。常见的代表任务包括数据分析报告、技术方案生成、跨网页资料整合、代码仓库修复、长流程自动化操作等。这类任务难做的原因可以概括成三点。第一是误差会累积。单步大模型的回答可能有 90% 以上的准确率但如果任务需要连续调用 20 次模型90% 的准确率经过多步乘法后会衰减到很低的水平。而且错误不是独立的前一步偏了一点后一步很可能在错误方向上越走越远。这正是 Long-Horizon 和 Short-Horizon 最本质的区别。第二是反馈非常稀疏。短任务里模型生成完答案后马上能判断好坏长时间任务里模型往往走完了五六步才发现方向错了这时已经消耗了大量 Token也可能留下了无法回滚的副作用。更麻烦的是很多真实任务根本没有标准答案你很难写清楚什么情况算“成功”。第三是组合复杂度高。Agent 长任务通常需要规划、调用工具、阅读结果、再次规划还可能涉及多个 Agent 协作。任何一环的 Harness 设计不合理都会在后续环节被放大。你很难通过肉眼观察一次执行过程定位到底是模型的判断问题、工具的返回问题还是编排流程本身的问题。手写 Harness 之所以容易失败是因为这些决策彼此耦合反思频率过高可能打断执行节奏计划步数太多可能让模型陷入过度规划重试次数太少又会让偶发错误直接中断任务。AutoDesign 真正要优化的是这样一组离散的、结构性的、非线性的决策组合而不是某一句话怎么写。3. Meta-Harness Optimization把“编排设计”本身变成一个可优化问题先说清楚两个词避免概念混淆。“Harness”是我们要搜索的对象它是 Agent 外部结构与控制参数的集合体。它不是一个文本文件而是包含规划器配置、循环边界、反思规则、验证方法、终止条件等结构化描述的系统组件。“Meta-Harness Optimization”的重点是 Meta。它不是让 LLM 在某一步直接输出“更好的答案”而是在更高一层运行一个优化算法通过多次执行、评分、筛选、变异迭代出更好的 Harness。这个过程与神经网络训练中的“元学习”思想相似单次任务内部是 Agent 在解决问题外层是优化器在解决“如何设计一个能解决问题的 Agent”。用一个简化公式表达这个过程H* argmax_H E_{task ~ D}[ Score( execute(task, H) ) ]其中 H 是可选的 Harness 配置D 是代表真实需求的评测任务集合Score 是对单次执行结果的质量评估。优化器要做的是搜索 H 的配置空间使得在所有任务上综合得分最高。看到这里你可能会问为什么不直接让 LLM 来改 Prompt这不是已经很流行了吗这里有一个容易被忽略的差异。Prompt 优化通常只改变文本层面的指令而 Harness 优化会改变 Agent 的“结构”加不加规划步骤、执行到哪一步触发反思、允许多少次重试、采用哪种评分标准。Prompt 优化很难自动增加一个“工具结果校验流程”但 Harness 搜索可以。从题目的组合来看AutoDesign 这类方向想表达的关键判断是设计 Agent 不能停留在“把一段 Prompt 调好”而应该把 Harness 视为一个与模型同样重要的可优化对象。这也意味着Agent 工程师的竞争力会逐步从“会写提示词”转移到“会定义 Harness 搜索空间”和“会设计评价机制”上。4. 一个可拆解的 AutoDesign 参考架构在没有看到特定实现细节的情况下从工程实现角度来理解 AutoDesign我们可以把一套 Harness 自动优化系统拆成四个关键模块。这四个模块不一定要求用某种特定框架但思路对任何 Agent 项目都有借鉴价值。4.1 任务实例层这一层要准备一定数量的代表性任务实例构成搜索评测的基础集。任务不能太少否则优化器会过拟合。Long-Horizon 任务对数据集的要求更高一个任务内部要有长期执行路径最好同时覆盖多种失败模式。这一层的产物是一批带评测指标的任务描述比如“从 30 个网页中提取某产品近半年的价格变化并生成趋势总结”。4.2 Harness 表达层要让算法搜索 Harness先得把 Harness 翻译成可计算的结构。工程上最自然的方式是用数据类或 YAML 描述一组配置项计划拆解步数、最大迭代次数、重试上限、反思触发频率、输出校验 Schema、终止条件。每一种配置组合都是一个候选点搜索算法在候选点之间移动。4.3 执行与反馈收集层给定一个 Harness 候选系统需要真实执行若干条任务实例并把执行轨迹记录下来。这里最关键的是“过程反馈”而不只关心最终答案。比如模型有没有频繁跳回上一步、工具调用失败后能不能恢复、规划的步骤和实际执行顺序是否一致。没有这些过程信息优化器很难判断该往哪个方向调整 Harness。4.4 元优化器层元优化器根据执行反馈生成下一批 Harness 候选。实际工程里可以用进化算法、贝叶斯优化或者简单的随机搜索起步。每次迭代评估当前候选保留表现好的 Harness对它们做小幅度变异生成新的候选继续评估直到达到预算上限。这套架构的关键在于闭环执行、打分、反馈、调整。没有闭环的手工调参本质上是靠人在执行这套循环只是速度更慢、样本更少。5. 从手工 Harness 到自动搜索的代码示例接下来用一个教学原型展示从“手工 Harness”到“Meta-Harness 搜索”的代码实现思路。这个例子不能直接搬到生产环境但能帮助你理解搜索空间的定义方式。5.1 首先把 Harness 定义成一个数据类# 文件路径agent_harness.py from dataclasses import dataclass, field from typing import List dataclass class AgentHarness: # 任务目标描述 task: str # 规划时拆成几个子任务 planner_steps: int 4 # Agent 最多执行多少轮 max_iterations: int 10 # 工具调用失败后的重试次数 retry_on_tool_error: int 2 # 每执行多少轮做一次反思 reflection_every: int 3 # 允许使用的工具白名单 allowed_tools: List[str] field( default_factorylambda: [search, read_page, summarize] ) # 到达多少置信分数时可以提前终止 stop_threshold: float 0.9 def build_meta_prompt(self) - str: return ( f当前任务目标{self.task}\n f建议先拆分为 {self.planner_steps} 个子任务去执行。\n f你可以使用工具{, .join(self.allowed_tools)}。\n f如果连续执行 {self.reflection_every} 轮还没进展请暂停并反思当前方案。\n f当你认为任务已达到可信完成状态且置信度超过 {self.stop_threshold} 时可以提前结束。 )这里的关键点是把经验参数显式化。retry_on_tool_error、reflection_every、planner_steps 这些值原来散落在不同代码分支里现在被集中收拢成了一个对象。后续所有自动搜索都基于这个对象展开。5.2 然后写一个最简的元优化循环以下代码展示进化式 Meta-Harness 搜索的骨架。它不一定是最优算法但逻辑足够清晰。# 文件路径meta_search.py import random from agent_harness import AgentHarness def evaluate_harness(harness: AgentHarness, tasks: list) - float: 对单个 Harness 在多个任务上求平均分。 正式项目中这里会调用真实 Agent 执行器并汇总最终结果分。 total_score 0.0 for task in tasks: # 示意真实场景中需要替换成 Agent 执行逻辑 total_score run_agent_with_harness(task, harness) return total_score / len(tasks) def mutate(harness: AgentHarness) - AgentHarness: 对 Harness 配置做一次小范围随机变异。 new_harness AgentHarness( taskharness.task, planner_stepsharness.planner_steps random.choice([-1, 0, 1]), max_iterationsharness.max_iterations random.choice([-2, 0, 2]), retry_on_tool_errorharness.retry_on_tool_error random.choice([-1, 0, 1]), reflection_everymax(1, harness.reflection_every random.choice([-1, 0, 1])), stop_thresholdmax(0.1, min(1.0, harness.stop_threshold random.uniform(-0.1, 0.1))), ) return new_harness def meta_harness_search( tasks: list, population_size: int 6, generations: int 10 ) - AgentHarness: # 随机初始化一批候选 population [ AgentHarness( planner_stepsrandom.randint(2, 6), max_iterationsrandom.randint(6, 16), retry_on_tool_errorrandom.randint(0, 3), reflection_everyrandom.randint(1, 5), ) for _ in range(population_size) ] for gen in range(generations): scores [evaluate_harness(h, tasks) for h in population] ranked sorted( zip(population, scores), keylambda x: x[1], reverseTrue ) # 保留前一半作为精英 elites [h for h, _ in ranked[: population_size // 2]] best_score ranked[0][1] print(fgeneration{gen 1}, best_score{best_score:.3f}) # 精英保留剩余候选由变异生成 new_population list(elites) while len(new_population) population_size: parent random.choice(elites) new_population.append(mutate(parent)) population new_population best_harness max(population, keylambda h: evaluate_harness(h, tasks)) return best_harness这段代码的精髓只有两件事得分高的 Harness 进入下一轮其余 Harness 通过变异探索附近的新配置。假如一组配置里 reflection_every2 效果更好变异机制会大概率让下一轮候选集中在这个值附近。真实实现中evaluate_harness 执行的是真正的 Agent 跑批成本会很高因此通常会加入全局 Token 预算和提前终止条件避免优化过程无限烧钱。5.3 用 YAML 管理 Harness 搜索空间为了让配置不散落在代码里更推荐把 Harness 搜索空间写成 YAML 文件。# 文件路径search_space.yaml optimizer: population_size: 8 generations: 20 eval_tasks_per_generation: 10 search_space: planner_steps: [2, 4, 6, 8, 12] max_iterations: [5, 10, 20, 30] retry_on_tool_error: [0, 1, 2, 3] reflection_every: [1, 2, 3, 5] stop_threshold: [0.7, 0.8, 0.9, 0.95] # 注这里给出的是“配置结构”具体数值需要根据实际任务和预算调整这比把参数硬编码在 Python 里更适合多人协作和实验记录。每次搜索出一组最佳 Harness直接把对应的 YAML 片段保存下来相当于给 Agent 编排策略做了版本管理。回滚、对比、灰度都可以围绕这套结构展开。5.4 为什么要控制搜索成本必须提醒一点Meta-Harness 搜索不是免费的。每一代都要跑多轮完整 Agent 任务而一个长任务本身可能就要消耗数万 Token。如果 population_size 是 8、generations 是 20最坏情况下要评估 160 次任务成本非常惊人。所以实践中有几个降本手段先在短任务子集上做一轮快速筛选用过程指标替代昂贵的人类评估对明显很差的 Harness 提前中断不跑完整任务搜索得出最优配置后再在完整任务集上做一次验证。6. 效果验证思路与实验口径这类自动化优化的项目最容易翻车的地方不是“搜不到好结果”而是“不知道怎么判断结果是否真的好”。我建议在动手前就定好三层验证口径。第一层是单任务执行质量。怎么定义单次任务成功可以设计成规则指标加模型判断的结合体。如果是数据分析类任务可以检查最终输出是否包含指定字段如果是网页信息整合任务可以由一个独立的评审模型按维度打分。第二层是跨任务泛化能力。把任务集切分成搜索集和留出集。Meta-Harness 算法只能在搜索集上迭代最终选出的 Harness 必须放到留出集上跑一遍。如果搜索集分数高而留出集分数低说明系统过拟合了任务集而不是学会了更好的编排策略。第三层是人工抽样复核。算法优化出的 Harness 可能正好在某个分数定义上钻了空子。建议每次选优后抽出 3 到 5 条完整执行轨迹人工检查中间过程是否合理。这一步可以挽回大量隐藏问题。在你自己写代码验证时可以把上文 meta_search.py 中调用 LLM 的部分换成 mock 执行器先把流程跑通再接入真实 Agent。系统打印的最核心变量是每一代 best_score 的变化曲线。如果多轮迭代后分数始终没有抬升问题通常不在优化算法而在 Harness 的搜索空间表达或评分函数设计上。7. 常见问题与排查思路问题现象可能原因排查方式解决方案搜索多代后仍不如手写 Harness搜索空间表达不足关键参数没有纳入检查最佳 Harness 与手工配置差异增加更多 Harness 维度例如反思触发条件、输出校验策略搜索集分数高留出集分数低对任务集过拟合对比训练和验证集差异增加任务多样性减少同一任务重复评估LLM 评审分数不稳定评分模型随机性或 Prompt 模糊固定评审 Prompt用多次采样取均值引入规则指标双模型交叉评审单代评估成本过高每代评估任务太多或未做早停查看 Token 使用统计缩短最大迭代次数增加低分提前终止优化后的 Harness 出现指令攻击式输出Agent 把优化搜索到的格式当成了越权依据人工抽查轨迹增加安全过滤器禁止执行高风险工具遵守最小权限原则真实项目里排在前面并且最容易反复出现的是“评分函数有噪声”。噪声大的评分会让优化器把随机波动当成有效信号最终得出一些看似分数高、实际不稳定的 Harness。因此建议第一版系统不要追求复杂的加权评分先用干净、稳定、可复现的指标把闭环跑通。8. 边界、安全与工程化建议在考虑引入 AutoDesign 思路之前先明确它的适用边界。它适合任务目标足够明确、评测方式相对清晰、Agent 的执行结果可以被标准化量化的场景。典型的例子包括代码生成、信息检索整合、特定格式文档产出、数据库查询生成等。反之如果任务本身非常模糊连一个有经验的人都无法判断结果好坏那么再强的元优化也无法帮你突破评价缺失的瓶颈。安全方面也需要比普通 Agent 项目更谨慎。自动搜索会不断尝试不同编排策略这意味着某些 Harness 可能会诱导模型使用原本不在计划内的高风险工具调用。因此工具白名单必须在 Harness 外层硬性约束不能只靠模型自觉。Agent 的每一步执行都应当留下日志方便回溯是哪一次变异、哪一个 Harness 导致了异常行为。工程化方面最推荐的是把 Harness 当作“一等公民”来管理。团队里不要只在会议里讨论“我们的 agent 不太聪明”而要把“当前 Harness 是什么版本、上一次调整了什么”“调参前后指标变化是多少”这些信息固化下来。只有当你能够稳定地比较两个 Harness 版本时Meta-Harness 优化才有意义。进入生产环境时新搜索出的 Harness 应该先做小流量灰度保留回滚能力而不是直接替换所有线上场景。9. 给 Agent 工程师的几个落地建议不要等一个“全自动 Agent 设计器”成熟之后再行动。现在就可以做三件事。先把你手头 Agent 的 Harness 参数显式化。即使不做自动搜索把规划步数、迭代上限、反思频率等配置从代码里抽出来也已经能大幅提升调试效率。再搭一个最少 5 到 10 条任务的最小评测集。没有评测集任何调参都只是玄学有了评测集你至少能知道一次修改到底变好了还是变坏了。最后从小规模随机搜索开始。先随机生成 20 组 Harness跑分、排序、分析结果这个动作能帮你快速找到几个容易忽略的配置盲区。AutoDesign 这类研究真正值得关注的并不是某个具体算法有多强而是它把 Agent 开发中“靠手感、靠经验、靠运气”的那部分工作慢慢变成了“可计算、可搜索、可复现”的工程问题。长任务 Agent 的稳定性一定不会只靠模型进步来解决外围编排层自动化程度会越来越高。早一点把 Harness 和评测体系建起来你就能早一点把精力放在真正需要人类判断的地方。