如果你们的 Agent 在短任务上表现得像“专家”一旦放到长周期设计任务里就开始失控那问题很可能不在模型本身而在模型外面的那层“Agent 运行框架”。过去一年很多团队把精力花在换更大的模型、写更长的提示词上却发现收益越来越低。真正值得关注的方向正在转向更高一层把 Agent 执行依赖的 harness 也当作可优化的对象。这就是 AutoDesign 所代表的思路Meta-Harness Optimization for Long-Horizon Agentic Design。它的核心判断是长时序 Agentic Design 任务的瓶颈不是单次推理质量不够而是“Agent 是怎么被组织、被控制、被反馈、被约束”的设计问题。模型是引擎harness 是底盘在需要跑几十步、不断试错、持续收敛的任务里底盘调教带来的收益往往比换引擎更明显。这篇文章会做三件事先解释 Agentic Design、Long-Horizon、Harness 这几个概念之间的关系再拆解 Meta-Harness Optimization 的方法结构和工程含义最后给出一套可在自己项目中实现的轻量级 AutoDesign 循环代码并说明如何评估、如何排错、如何落地。如果你正在做 Agent 应用或者被长任务 Agent 的成本和不稳定性折磨这篇文章值得读完。1. 长流程 Agentic Design难点到底在哪先看一个典型场景产品经理让 AI 设计一套 App 的交互原型和视觉方案。这个任务不是“生成一段文字”就结束而是包含需求拆解、竞品分析、信息架构设计、页面布局、文案输出、设计师反馈修改、多轮方案对比等多个阶段。每一个阶段都会产生中间产物前一步的错误可能被后一步放大。这种任务在 AI Agent 领域被称为 Long-Horizon Tasks。它的核心特征是目标明确但路径不确定中间需要很多步骤每步都可能出错错误会累积最终结果必须满足一定质量标准。很多第一次接触 Agent 开发的工程师会误以为Long-Horizon 任务难在“模型上下文不够长”。这种理解并不全面。上下文长度只是表面约束更本质的难点有三个。第一误差累积。单步模型的错误率假设是 5%一个 20 步任务的理论成功率只有约 36%。如果任务本身要求设计质量错误累积会远高于普通问答任务。第二设计类任务没有唯一标准答案。 Agent 很难判断自己“是否完成”需要外部校验、用户反馈或评估器介入。这个反馈循环如何设计直接决定任务质量。第三资源消耗失控。长任务会产生大量中间 token、多轮工具调用、多次反思。如果不对步骤粒度、重试次数、反思频率做约束一个看起来简单的设计任务可能在后台消耗几十万 token产出却无法收敛。所以当标题里同时出现 Long-Horizon 和 Agentic Design 时重点不是某个模型的单次输出而是整个 Agent 能否在长周期的“规划—执行—反馈—修改”循环里稳定工作。2. Agentic Design、Long-Horizon、Harness 概念拆解为了后续讨论清楚需要先把几个术语放在一张表里对比术语中文理解关键点Agentic Design由 Agent 自主完成的设计型任务设计意图、约束满足、多轮产物Long-Horizon需要多步执行的长周期任务路径不确定、状态多、错误累积HarnessAgent 的外部运行框架提示模板、工具、记忆、循环策略、评估协议Meta-Harness Optimization对运行框架本身做自动化优化优化对象不是模型而是组织模型的方式AutoDesign自动化的设计生成系统方向让设计过程可观察、可评估、可迭代可以先这么理解Agent 是一辆自动驾驶汽车模型是发动机Agentic Design 是“让它自己开车去设计一栋楼”的目标任务Long-Horizon 是这段路很长且路况复杂harness 则是方向盘、油门、刹车、导航和行车记录仪的组合系统。Meta-Harness Optimization就是去调整这套方向盘和导航策略而不是反复去换发动机。传统上构建 Agent 应用时大家更关注模型的选型、Prompt 怎么写、工具怎么配。这其实是“模型中心”的思维方式。而 AutoDesign 这类方法把观察视角上升到“系统中心”它关心的问题是给同一个模型接上不同的 harness任务成功率会差多少什么样的循环策略、反馈机制、终止条件能最大程度发挥模型的潜力这个视角的转变对工程团队非常重要。因为模型更新很快但 harness 层积累的流程经验和评估体系可以复用。长期来看优化 harness 比反复调整单条 Prompt 更有杠杆效应。3. Harness 的工程含义Agent 的“操作系统”在 Agent 工程实践中Harness 并不是一个生僻的研究术语它实际上已经存在于所有生产级 Agent 项目中。只是很多团队没有把它当成一个独立可配置的层来对待。一个完整的 Harness 通常包括以下组件组件作用长任务中常见问题系统提示与角色设定定义 Agent 身份、任务边界角色容易被后续上下文淹没规划模块把任务拆解为子步骤规划过粗或过细都影响效率工具与动作策略决定每一步调用什么工具工具选择错误率随步数上升记忆管理保存中间产物、历史决策信息遗忘导致重复设计自我反思循环定期检查输出是否合理反思太频繁浪费太少漏错评估与终止条件判断任务是否完成缺乏可量化退出标准在一个典型的手动 Agent 项目里工程师会把这些逻辑写成硬编码流程。例如先调用规划模型生成步骤再逐步骤调用工具最后检查结果。问题是这些参数和策略往往是一次性写死的。比如反思间隔是每 3 步一次重试上限是 2 次步骤拆分粒度为“尽量细”。这些数字没有经过系统搜索只是拍脑袋决定的。AutoDesign 类方法提出的问题是能不能把这些参数和策略组合放进一个搜索空间让系统根据历史任务表现自动找到更好的 harness这就是 Meta-Harness Optimization 的出发点。这里要特别注意“Meta”的含义。它不是让 Agent 去设计页面时自己调整框架参数而是在更高一层建立“Agent 任务跑完一批后根据结果调整下一批任务的运行框架”的外层循环。也就是说它优化的是“如何运行 Agent”而不是只优化“Agent 在单次任务里如何表现”。4. Meta-Harness Optimization 的核心机制把 Meta-Harness Optimization 落到方法层面需要拆成几个部分来理解。4.1 问题定义假设有一个 Agent 任务分布 T比如“给不同类型的电商页面做设计”。每个任务实例 t 都有输入需求、约束和人工或自动评估标准。再假设 Harness 配置空间 H里面包含 Agent 的执行流程结构、反思策略、提示模板版本、工具调用规则、终止条件等。Meta-Harness Optimization 的目标是在 H 中找到一组配置 h使得 Agent 在 T 上的期望效果最好同时满足成本约束。用工程语言表达h* argmax(h in H) AverageQuality(T, h) subject to AverageCost(T, h) Budget其中 AverageQuality 是通过评估器得到的质量分数AverageCost 是 token 消耗、调用次数或延迟。这个式子不是某个具体论文的公式而是理解这类方法通用的抽象。4.2 优化对象为什么是 Harness而不是 Prompt 或模型一个很自然的问题是为什么不直接做 Prompt 自动搜索或者用强化学习微调模型Prompt 自动搜索的问题在于维度太局部。它只能调整输入文本但无法改变 Agent 的整体执行节奏。同一个 Prompt在“每步反思”和“从不反思”两种流程下最终效果会差很多。如果只优化 Prompt无法找到流程层面的更优解。微调模型的成本更高而且每一轮新模型发布后都要重新调。更重要的是很多设计任务需要工具调用和多步反馈这些能力分布在外部环境不全是模型参数能解决的。Harness 层刚好处于中间位置改动成本比微调模型低影响范围比 Prompt 单点调整大且可以积累成团队的通用 Agent 工程资产。因此Meta-Harness Optimization 在工程上非常自然。4.3 搜索空间与评估反馈在设计实际系统时Harness 搜索空间通常包括反思间隔每 N 步反思一次还是任务完成后再反思规划粒度一次性生成全部步骤还是滚动生成下一步重试策略失败后重试几次是否更换提示模板上下文管理模式全量保留历史还是定期摘要压缩工具选择策略让模型自由选择还是根据阶段限制工具集终止条件达到多少分才终止还是达到最大步数强制终止。每一次评估都会返回质量分数和成本数据。Meta-Optimizer 根据多轮评估结果更新对配置空间的偏好。比较常见的方法有贝叶斯优化、进化搜索或者简单的随机搜索配合成本筛选。由于不同任务的评估成本差别很大实际项目中不会每次都用全量人工评估。通常的做法是先用轻量自动评估器筛掉明显不合适的配置再对保留的少量配置进行人工或高精度模型评估。这也是 AutoDesign 工程落地中很重要的一环。5. 实现一个轻量级 AutoDesign 循环理解了概念之后最重要的问题是代码层面怎么搭下面用一个不依赖具体模型厂商 API 的最小实现展示 AutoDesign 的四个组成部分。5.1 定义 Harness 配置结构# 文件路径harness_types.py Harness 配置的数据结构定义。 from dataclasses import dataclass, field from typing import Optional dataclass class HarnessConfig: 一个 Harness 配置代表 Agent 运行框架的一组可选参数。 # 规划相关 plan_mode: str rollout # all 表示一次生成所有步骤rollout 表示逐步生成 max_steps: int 20 # 反思相关 reflection_interval: int 3 # 每 N 步反思一次0 表示不反思 reflection_style: str structured # structured 或 freeform # 重试与终止 retry_limit: int 2 quality_threshold: float 0.8 # 自动评估分数达到该值可提前终止 # 上下文管理 compress_history: bool True # 是否定期压缩历史记录 compress_threshold: int 6000 # 超过多少字符触发压缩 # 工具策略 restricted_tools: bool True # 是否按阶段限制工具集 def describe(self) - str: return ( fplan{self.plan_mode}, max_steps{self.max_steps}, freflect_every{self.reflection_interval}, retry{self.retry_limit}, fthreshold{self.quality_threshold}, compress{self.compress_history} )这段代码把 Harness 的常见调节项抽象成配置字段。实际项目中还可以继续增加工具白名单、Prompt 模板版本号、反思模板名称等字段。5.2 实现一个可插拔的 Agent 执行器为了让 Harness 配置可以被实验需要把 Agent 的执行过程写成可配置函数。# 文件路径agent_runner.py 根据 Harness 配置执行一次长周期设计任务。 from typing import Any, Callable, Optional # 在实际项目中这个函数替换为模型服务 SDK 调用 llm_call: Optional[Callable[[str], str]] None def call_model(context: str) - str: 统一模型调用入口。生产环境替换为真实模型服务。 if llm_call is None: raise RuntimeError(请先注入 llm_call 函数例如接入 OpenAI / Claude / 国内大模型 SDK。) return llm_call(context) def run_agent_task(task_input: str, cfg: HarnessConfig) - dict: 执行一次 Agent 任务返回最终产物、日志和成本统计。 为了演示这里将模型推理简化为字符串拼接。集成真实模型时 请替换 call_model 中的实现并在上下文里注入规划结果、工具反馈和反思信息。 steps [] current_plan [] for step_idx in range(1, cfg.max_steps 1): # 规划模式all 模式只规划一次rollout 模式逐步追加步骤 if cfg.plan_mode all and step_idx 1: plan_prompt build_plan_prompt(task_input) current_plan call_model(plan_prompt).strip().splitlines() elif cfg.plan_mode rollout: plan_prompt ( f当前是第 {step_idx} 步。请根据任务继续生成下一步动作。\n f任务{task_input}\n已完成步骤{len(steps)} ) next_action call_model(plan_prompt).strip() current_plan.append(next_action) # 执行当前步骤 action current_plan[step_idx - 1] if step_idx - 1 len(current_plan) else design_draft action_prompt ( fStep {step_idx}正在执行动作{action}\n f历史步骤{steps} ) step_result call_model(action_prompt) steps.append({step: step_idx, action: action, result: step_result}) # 反思间隔到达指定步数后让模型对已有结果做质量检查 if cfg.reflection_interval and step_idx % cfg.reflection_interval 0: reflect_prompt ( f请反思当前设计方案的不足。第 {step_idx} 步已完成 {len(steps)} 步。 ) reflection call_model(reflect_prompt) update_prompt f根据反思意见修正方案{reflection} corrected call_model(update_prompt) steps.append({step: step_idx, type: reflection, result: corrected}) final_artifact steps[-1][result] if steps else return { artifact: final_artifact, steps: steps, step_count: len(steps), } def build_plan_prompt(task: str) - str: return f请把以下设计任务拆解为可执行步骤每行一个步骤\n{task}这里把 Agent 执行器写成了纯函数风格目的是让每次运行都只依赖 cfg 参数方便后续做多轮搜索。真正接入模型时call_model 内部要根据厂商 API 拼接消息、解析输出并记录 token 消耗。5.3 实现 Meta Harness Optimizer 外层循环核心优化器负责不断采样新的 Harness 配置执行一批任务计算目标分数更新历史。# 文件路径meta_optimizer.py Meta-Harness Optimization 的最小实现随机搜索 成本过滤。 import random from harness_types import HarnessConfig from agent_runner import run_agent_task def auto_evaluate(artifact: str) - float: 轻量自动评估器。真实项目中可以替换为模型裁判、 规则检查或人工评分。这里用伪随机分数演示流程。 return random.uniform(0.5, 1.0) def estimate_cost(execution_result: dict) - float: 根据步数估算成本真实场景换算为 token 消耗。 return execution_result[step_count] * 1.0 def sample_config() - HarnessConfig: 在 Harness 搜索空间里随机采样一组配置。 return HarnessConfig( plan_moderandom.choice([all, rollout]), max_stepsrandom.choice([10, 15, 20]), reflection_intervalrandom.choice([0, 2, 3, 5]), retry_limitrandom.choice([1, 2, 3]), quality_thresholdrandom.choice([0.7, 0.8, 0.9]), compress_historyrandom.choice([True, False]), restricted_toolsrandom.choice([True, False]), ) def evaluate_config(cfg: HarnessConfig, task_pool, max_cost: float) - dict: 在任务池上评估一组配置返回平均质量、总成本和可用性。 total_quality 0.0 total_cost 0.0 valid_task_count len(task_pool) for task in task_pool: result run_agent_task(task, cfg) total_quality auto_evaluate(result[artifact]) total_cost estimate_cost(result) avg_quality total_quality / valid_task_count if total_cost max_cost: return {cfg: cfg, quality: avg_quality, valid: False} return {cfg: cfg, quality: avg_quality, valid: True} def optimize_harness(task_pool, trials: int 20, max_cost: float 100.0): 运行若干轮 Harness 配置搜索返回最优配置。 best_score -1.0 best_cfg None for trial in range(1, trials 1): candidate sample_config() report evaluate_config(candidate, task_pool, max_cost) if not report[valid]: print(f[Trial {trial}] {candidate.describe()} - 成本超限跳过) continue print(f[Trial {trial}] {candidate.describe()} - 质量 {report[quality]:.3f}) if report[quality] best_score: best_score report[quality] best_cfg candidate return best_cfg, best_score if __name__ __main__: demo_tasks [设计一个生鲜电商首页, 设计一个企业官网的落地页] optimal_cfg, score optimize_harness(demo_tasks, trials20, max_cost120.0) print(\n最优 Harness 配置) print(optimal_cfg.describe()) print(f平均质量分数{score:.3f})这段代码看起来简单但已经包含了 AutoDesign 循环的所有要素配置采样、Agent 执行、质量评估、成本过滤、最优结果保留。真实系统中只需要把sample_config替换成更智能的搜索算法把auto_evaluate替换成更可靠的评估器就可以支撑一个生产级 Meta-Harness Optimization 服务。运行方式python meta_optimizer.py预期输出示例[Trial 1] planall, max_steps20, reflect_every3 ... - 质量 0.712 [Trial 2] planrollout, max_steps10, reflect_every0 ... - 质量 0.655 ... 最优 Harness 配置 planrollout, max_steps15, reflect_every2, ... 平均质量分数0.824由于示例中评估器是随机实现每次输出会不同。这里的关键不是具体分数而是证明外层优化循环可以自动比较不同 Harness 配置并给出一个“比随机配置更可能出色”的输出。6. 如何建立评估闭环判断 AutoDesign 是否改进AutoDesign 最怕没有可靠的评估信号。如果质量是拍脑袋给的那么无论优化算法多先进都只是在拟合噪声。所以工程落地的核心是把评估体系做好。建议分三层建立评估层次方法适用场景快速规则评估检查必要元素是否存在、格式是否完整每轮搜索初筛模型裁判用强模型对产物打分或对比批量迭代人工评审设计专家或用户对最终方案打分最终验收一个比较实用的做法是先用规则评估筛掉 80% 的低质量结果再用模型裁判对剩下的配置打分最后只对每个搜索阶段的前几名做人工评审。这样可以控制评估成本也不会因为自动评估器太薄弱而选出明显不可用的配置。在验证效果时需要设计可对比的指标。常见指标包括平均质量分任务完成度、设计合理性成功率达到指定阈值的任务占比平均步数任务收敛速度平均 token 成本单次任务资源消耗波动率同一配置在不同任务上的稳定性。如果没有对比基线AutoDesign 很容易变成“看起来很忙但不知道有没有变好”。最合适的基线是团队当前线上使用的固定 Harness 配置。每轮新配置候选都要与基线跑同一批任务做 A/B 对比。7. AutoDesign 落地中的常见问题问题现象可能原因排查方式解决方案搜索了很多配置质量提升不明显搜索空间不合理最优配置不在空间内检查是否漏掉反思频率、终止条件等维度增加 Harness 维度或聚合相似配置自动评估分数高人工评审却差评估器指标与真实目标错位对比模型裁判分数与人工分引入少量人工样本校准评估器优化后的配置在特定任务上过拟合任务池太窄评估任务代表性不足检查任务池是否覆盖不同难度和类型扩充任务池按难度分层抽样每轮评估成本过高候选配置太多、任务太多观察是否做了初筛先用规则评估初筛再用全量评估流程过于复杂难以解释结果没有记录每轮配置和分数日志查看是否只有最终结果没有过程为每次实验持久化完整配置和评估数据同一配置多次运行结果波动大Agent 本身随机性 模型温度设置固定随机种子多次重复取均值对关键评估任务运行多次取均值或中位数排查 AutoDesign 问题时最重要的原则是从数据入手。不要凭感觉判断“这个配置不行”要看它是哪一步失败的。如果失败发生在工具调用之后可能是工具返回格式问题如果失败发生在反思之后可能是反思 Prompt 和上下文管理策略不匹配。8. 工程实践建议与注意事项8.1 先把 Harness 参数化再做 AutoDesign很多团队连 Harness 的基本配置都没有抽离出来就直接想上 Meta-Optimization这会导致搜索无从下手。正确路径是先把当前 Agent 运行方式中的所有可变项抽取成配置字段并保证同一配置可以被重复执行。没有确定性执行能力优化就没有意义。8.2 成本控制必须放在优化目标里Meta-Harness Optimization 里最容易被忽略的是成本维度。如果只追求质量优化器会倾向选择 max_steps 很大、反思间隔很小的高耗配置。结果平均质量提升 5%成本却翻了三倍生产上无法接受。建议把成本约束写成硬条件超限配置直接跳过。8.3 小心评估器本身被“玩弄”使用强模型做裁判时如果裁判提示过于简单优化器可能会发现某些词句能让模型裁判给高分但实际设计方案并不好。可以每隔几轮插入一小批人工评审样本并对比模型裁判和人工评分的一致性。8.4 生产环境永远保留回滚能力如果把 AutoDesign 调到的最优配置直接上线风险很大。更稳妥的做法是把当前线上配置和新配置同时跑一段流量观察关键指标后再逐步切流。任何配置变更都应该有版本号、生效时间和回滚开关。8.5 不要忽略 Agent 执行失败的隐蔽原因Meta-Harness Optimization 常被误以为只是“调 Harness 参数”但很多提升其实来自修复了执行过程中的隐藏缺陷例如工具返回格式不兼容、上下文被截断、反思结果没有真正写回执行计划。这些修复不属于搜索空间却会影响整体效果。建议在优化前先做一轮 Agent 执行日志审计。9. 总结为什么应该关注 AutoDesign 方向回到开头的问题。长周期 Agentic Design 任务真正难的不是某一步生成而是整条链路上模型、工具、记忆、反思、评估之间的协作。AutoDesign 的贡献在于把目光从单次模型调用移到“如何组织模型工作”的 Harness 层并用 Meta-Harness Optimization 把 Harness 的调优过程自动化。如果读者正在开发 Agent最值得立刻做的事有三件。第一把当前 Agent 的执行参数表抽取出来先搞清楚有哪些可调项。第二为典型任务建立可重复执行的评估脚本。第三跑一轮简单的随机搜索对比当前固定配置与新配置的质量和成本差异。哪怕只做这三步也能对 AutoDesign 模式的价值有一个实感。Meta-Harness Optimization 未必会取代提示词工程或模型微调但它补上了当前 Agent 工程里最容易缺失的一环用系统化方式优化 Agent 运行框架。这个方向才刚刚开始后续值得继续关注它对设计类任务、工具使用类任务和复杂工作流的具体影响。