先说结论“让大模型自己设计自己的运行框架”这件事已经有了明确的研究方向。AutoDesign: Meta-Harness Optimization for Long-Horizon Agentic Design这个题目如果只看名字很容易被当成又一个花哨的 agent 框架但它真正想解决的问题恰好是目前做智能体应用最头疼的部分——你花了很多时间调 prompt、调工具调用格式、调多轮循环结果换一个任务场景就全部作废。AutoDesign 的思路是把这个过程本身交给一个上层系统去优化不再由人类手写 agent 的行为规则而是让系统自动搜索、评估并改进“用来承载 agent 运行”的那套外层控制结构术语叫 Harness。目标场景是 Long-Horizon也就是执行时间长、步骤多、依赖多个工具、中间状态容易出错的任务。这篇文章不会只做概念搬运我会尽量把它拆成可以用于工程预研的技术点包括 Meta-Harness Optimization 要解决什么问题、Long-Horizon Agentic Design 的难点在哪里、如果你想在自己项目里做一个小型验证应该从哪些模块入手以及在批量运行、资源占用、效果度量和问题排查上要注意什么。1. AutoDesign 核心能力速览在动手拆解之前先给一张定位表。AutoDesign 不是传统意义上“装好就能跑”的单一开源工具它更像一个研究范式一套让智能体自动设计和优化自身运行框架的方法论。当前公开可复现资料有限因此下表里部分结论是基于论文标题与研究范式作出的合理推导不是某个官方仓库写死的规格。能力项说明项目定位面向长视野任务的智能体设计自动化研究关键词包含 AutoDesign、Meta-Harness Optimization、Long-Horizon Agentic Design核心思想把 agent 的外层控制结构当作可优化对象通过元层优化让系统自动生成、评估和改进 Harness目标场景长时间跨度、多步骤、多工具协作的复杂任务如自动化设计流程、研究报告生成、多阶段代码工程等主要模块Harness 定义、任务分解、执行循环、结果评估、元优化回路是否可直接下载当前公开材料不完整建议先把原型实验做通再判断是否需要依赖具体实现依赖基础底层通常需要一个可调用的大语言模型推理服务无论是云端接口还是本地推理服务均可显存需求不确定取决于底层模型如果按纯接口调用方式验证本机无需大显存API 化能力可通过通用 HTTP API 接入任务调度队列属于工程集成层面可自行搭建批量任务支持需要自行设计任务队列、结果记录和失败重试机制适合读者研究 agent 自动化设计的算法工程师、做复杂工作流平台的开发人员、关注 Agent 新范式的技术负责人很多人看到这里会问它跟 AutoGPT、AutoGen 这些有什么本质区别区别在于优化的对象。AutoGPT 这类框架把“固定的循环控制”视为前提大模型只负责填任务分析和动作参数。而 AutoDesign 关注的不是某个任务里的具体动作而是“承载这个动作序列的外层框架”本身能不能被优化。也就是说设计对象从任务内容上移到了框架结构层面。2. 技术拆解Meta-Harness Optimization 解决什么问题要把这个概念读懂先得把 Harness 这个词从抽象里拉出来。在智能体应用里Harness 可以理解为“让大模型能在一个环境里稳定完成任务的整套外层系统”它不是模型本身而是模型运行所依赖的结构。常见内容包括System Prompt 与行为约束工具调用的输入输出格式多轮循环的跳出条件记忆写入和上下文截断策略错误回退与重试规则中间结果的校验逻辑。传统做法里这些结构都是工程师手工设计的。你写一个 ReAct 循环规定好“观察”和“思考”的格式再写十几个 if-else 处理各种异常这套东西就是一个典型的 Harness。问题是它对人的经验依赖极高Prompt 稍微写得不够细模型就会反复调用同一个工具上下文过长导致早期信息被截断某个工具返回了不符合预期的 JSON整个循环就卡住。AutoDesign 的核心观点很直接既然 Harness 决定了 agent 的表现为什么不把 Harness 本身当成一个搜索对象让元层智能体去自动优化它这就是 Meta-Harness Optimization 的含义。它包含两层第一层是目标层负责执行具体的长视野任务比如根据用户输入自动完成一个界面的多轮设计。这一层的模型需要按某个 Harness 运行。第二层是元层负责观察目标层执行过程分析哪些步骤超时、哪些工具调用出错、哪些信息没有被利用然后修改 Harness 定义。修改内容可以是 Prompt 措辞、工具调用说明、循环退出条件甚至是整体执行流程的调整。如果把这两层映射到实际的 agent 系统开发中元层优化器本质上也是一个 LLM 程序但它处理的对象不是用户业务问题而是“当前这套执行框架为什么效率不高”的工程问题。它看到的是执行日志、工具调用记录、中断原因和评估分数输出的是新的 Harness 配置。这个过程可以迭代多轮直到在代表性验收任务上达到指定效果。从范式上看AutoDesign 与“Code Generation 自动写代码”的思路类似。自动写代码是用模型生成程序代码来解决一个功能问题AutoDesign 是用模型生成智能体系统运行所需的框架配置来解决“智能体自动化程度不足”的问题。差别在于程序代码可以比较方便地编译运行验证而 Harness 的效果必须在多次长任务执行中观测评估成本要高得多。这一点会直接决定后面做原型验证的设计策略。3. 适用场景与使用边界3.1 适合什么场景从 Long-Horizon Agentic Design 的定位看它最适合的场景具备三个共同特征任务必须可以被重复执行。如果每个任务只跑一次优化出来的 Harness 没有复用价值。AutoDesign 类方案要求同一类任务有足够的样本量元层才能在结果中归纳规律。任务结果必须可以被自动评估。系统只有知道“这次执行是好是坏”优化才有一个相对明确的梯度方向。评估方式可以是规则校验、结果匹配、用户反馈也可以是另一个模型打分。任务的时间跨度足够长。如果任务三步之内就能完成手工写 Prompt 可能更省成本。AutoDesign 的优势在长流程中才明显因为步骤变多之后每步微小错误都会被放大人工定位问题的时间成本急剧上升。3.2 不适合什么场景如果任务本身不具备可重复性或者用户输入每次差异极大又没有可靠的自动评估器那么直接把 AutoDesign 方案引入生产环境风险很高。元层优化会持续产生额外的推理调用和 token 消耗但如果无法判断哪版 Harness 更好整个优化只是在浪费时间与成本。3.3 使用边界与合规红线AutoDesign 这类“元优化”能力一旦与真实工具系统打通存在被滥用的可能。如果一个 Harness 被自动优化出“尝试绕过权限限制、访问未授权文件、对第三方系统执行越权操作”的行为元层优化器本身可能因为评估器设计不完善而无法及时发现。因此落地时必须做到所有工具调用必须保留完整审计日志关键操作必须经过人工授权或独立安全策略校验设计实验只使用测试环境和模拟数据涉及人脸、声音、隐私数据或版权素材时必须先确认授权真实项目上线前要把异常行为规则加入评估维度而不是只考核任务成功率。任何自动优化框架都不应该被用来生成绕过平台限制、规避安全机制或窃取数据的内容。工程人员需要在评测环节加入安全约束校验确保优化出来的 Harness 不会越界。4. 原型环境准备与前置条件虽然公开材料没有给出 AutoDesign 的一键安装包和官方代码仓库但我们仍然可以基于范式搭建一个最小可运行的实验原型。环境准备的核心不是某个特定库而是把“模型推理调用”和“任务执行日志”这两个基础能力准备好。4.1 基础环境清单建议使用独立 Python 环境避免与已有项目依赖互相污染。以下是一个通用检查清单操作系统Linux 或 macOS 优先Windows 也可以但路径处理要留意Python3.10 或 3.11 均可依赖管理venv 或 conda底层模型选择支持 OpenAI 兼容接口的推理服务。本地可使用 Ollama、vLLM 等也可以使用云上的模型 API请求库requests或openaiPython SDK日志与排障建议直接使用标准库logging不要着急引重量级框架。4.2 推荐目录结构原型阶段不建议把所有代码塞进一个文件建议按职责分开autodesign_proto/ ├── config/ │ └── model.yaml ├── harness/ │ ├── base.py │ ├── parser.py │ └── prompt_templates.py ├── agents/ │ ├── executor.py │ └── meta_optimizer.py ├── evaluator/ │ ├── rules.py │ └── score.py ├── data/ │ └── tasks.jsonl ├── logs/ │ └── run.log └── main.pyconfig 目录保存模型接入参数harness 目录保存 Harness 的解析逻辑和 Prompt 模板agents 目录实现执行器和元优化器evaluator 目录负责给单次执行打分。这样划分的好处是元层优化器修改的只是 Harness 配置而不是代码逻辑代码结构可以保持稳定。4.3 模型接口通用配置下面的 YAML 配置是一个通用模板具体 model、base_url、api_key 需要按你实际的推理服务填写。# config/model.yaml default_model: base_url: http://127.0.0.1:8080/v1 api_key: EMPTY model_name: your-local-model temperature: 0.2 max_tokens: 2048使用本地推理服务时base_url 指向本地端口即可使用云端 API 时base_url 填写服务商提供地址api_key 使用自己的密钥。这个原型不限制模型规格但需要注意长视野任务对长文本能力要求比较高如果模型上下文窗口很短需要在 Harness 中设计持久化记忆截断策略。5. 原型关键模块设计AutoDesign 的最小原型至少要包含四类模块Harness 定义器、执行器、评估器、元优化器。下面按“先让目标层跑起来再套上元层优化”的顺序设计。5.1 Harness 定义可被解析的配置结构Harness 不能是一段人眼才能理解的自然语言它需要被代码解析并控制执行流程。最简单的形式是一个 JSON 或 YAML 配置描述系统行为。这里给一个示意结构{ harness_id: harness_v1, system_instruction: 你是一个设计任务执行助手。请严格按照步骤完成设计每一步都必须调用相应工具并给出中间说明。, max_steps: 12, tool_call_format: { type: json, force_comment: true }, retry_policy: { max_retry: 2, retry_interval_seconds: 3 }, context_policy: { max_history_chars: 6000, truncation: keep_recent }, stop_conditions: [ task_complete, max_steps_reached, user_cancelled ] }这个结构可以由元层优化器生成也可以由人工写初始版本。关键点是代码必须标准化地读取它而不能把配置含义硬编码在执行逻辑里。5.2 执行器让 Harness 约束真正生效执行器的职责是加载 Harness 配置并控制目标层模型按此运行。下面给出一段原型示意代码它演示了如何把配置中的 system_instruction、max_steps 和 stop_conditions 转换成实际控制逻辑。实际项目中需要按你自己的模型 SDK 和工具调用方式调整。import json import time import logging from typing import Optional logger logging.getLogger(__name__) class HarnessExecutor: def __init__(self, harness_config: dict, model_client): self.config harness_config self.model model_client def execute_task(self, task: str): instruction self.config.get(system_instruction, ) max_steps int(self.config.get(max_steps, 8)) history [] for step in range(1, max_steps 1): messages self._build_messages(instruction, task, history) response self.model.chat(messagesmessages, temperature0.2) logger.info(step%s response%s, step, response) # 解析动作可能是工具调用也可能是最终答案 action self._parse_action(response) history.append({step: step, action: action}) if action.get(type) final_answer: return {success: True, answer: action.get(content), steps: step} if action.get(type) tool_call: result self._execute_tool(action.get(name), action.get(arguments)) history.append({tool_result: result}) return {success: False, answer: None, steps: max_steps}这段代码不是完整可运行版本它展示了 Harness 的核心控制点在第几步结束、历史消息如何裁剪、工具调用结果要不要继续喂回模型、达到最大步数时如何终止。一个 Harness 好不好正是由这些控制点上的策略决定的。5.3 评估器优化回路的驱动器若没有评估器元层优化就没有反馈信号。评估器需要针对具体任务类型设计。原型阶段建议使用多层指标完成率任务是否在最大步骤内完成结果质量分是否符合验收规则或者由打分模型输出 1 到 10 的分数资源效率实际调用次数、总 token 消耗、平均单步耗时稳定性同一任务多次运行时结果的离散程度。代码里可以这样组织class MetricAggregator: def __init__(self): self.records [] def add_run(self, run_result: dict): self.records.append({ success: run_result.get(success), quality: run_result.get(quality, 0), steps: run_result.get(steps, 0), total_tokens: run_result.get(total_tokens, 0), cost: run_result.get(cost, 0.0) }) def aggregate(self) - dict: if not self.records: return {} n len(self.records) success_rate sum(1 for r in self.records if r[success]) / n avg_quality sum(r[quality] for r in self.records) / n avg_tokens sum(r[total_tokens] for r in self.records) / n return { success_rate: round(success_rate, 4), avg_quality: round(avg_quality, 4), avg_tokens: int(avg_tokens), run_count: n }在 AutoDesign 中评估器不只是用来给单次任务打分它还要对比不同 Harness 版本在同一批验收任务上的表现。这里最容易踩的坑是为了节省成本而减少测试任务数量。样本太少会导致某个 Harness 出现假阳性结果元层优化器可能会过度拟合噪声。5.4 元优化器自动修改 Harness元优化器可以理解为另一个面向 Harness 的“写作模型”。它需要拿到三类信息当前 Harness 配置一批任务的多轮执行日志摘要聚合后的评估结果。然后输出一版新的 Harness 配置。典型的调用方式示意如下instruction 你是智能体系统优化器。当前 Harness 在验收任务上的成功率为{success_rate} 平均质量分为{quality}平均 token 消耗为{tokens}。 请根据以下执行日志中的问题模式输出优化后的 Harness。 注意优化目标是提高成功率与稳定性不要无意义增加工具调用步数。 .format(success_ratesr, qualityq, tokenst) new_config meta_model.chat( messages[ {role: system, content: 你只能输出合法 JSON 格式的 Harness 配置。}, {role: user, content: instruction \n旧配置 json.dumps(old_config, ensure_asciiFalse)} ] )这里有几个工程细节需要特别说明元层模型必须被限制为输出严格 JSON否则后续解析会不断失败每次优化只应该针对一个明确的失败模式不要期望一次把所有问题改完拿到新 Harness 后下一步不是直接推广而是用小规模任务样本做回归验证。如果优化回路陷入不收敛通常的原因是描述不够具体。比如“提升质量分”这种目标太泛元层模型不知道往哪个方向改。比较好的做法是把日志摘要里的具体失败例放到上下文里比如“在第 7 步出现了重复调用 search_tool 三次且查询条件完全相同”这样的描述能显著提升优化方向的准确性。6. Long-Horizon Agentic Design 功能测试与效果验证原型搭好后需要有标准化的测试流程。AutoDesign 目标场景是 Long-Horizon所以不能只用简单问答来验证而应设计包含中间步骤的验收任务。6.1 验收任务样例下面以“多阶段设计任务”为样例设计三种难度递增的任务。你可以根据自己的业务场景替换任务 A给定一个产品关键词生成 10 条候选 slogans。这个任务步骤不多主要是测温能力。任务 B给定一个页面主题先采集素材再生成结构方案最后输出完整设计说明。这个任务跨多个工具需要多轮信息组织。任务 C给定一个全流程需求需要拆解成子任务清单逐个执行并汇总成文档且中间允许自动纠错。这更接近 Long-Horizon。每个任务最好准备 10 到 30 个不同输入。任务太少无法判断 Harness 稳定性和元优化的真实收益。6.2 对比实验设计一次完整的 AutoDesign 实验建议跑三条线基线 A固定人工设计的初始 Harness不做任何元优化重复多轮记录指标。基线 B修改部分 Prompt 但仍然手工配置比如只加一段“如果调用工具失败请重新描述目标”记录指标。实验线 C使用元优化器迭代改进 Harness通常是多轮优化每轮用小样本验证后再在测试集上评估。判断 AutoDesign 是否有价值的直接指标是实验线 C 在验收集上的成功率是否显著高于基线 A且 token 开销是否在可接受范围内。如果成功率上升但 token 消耗翻了几倍对生产环境不一定划算。6.3 检查执行日志的要点实验过程中不要只看最终分数要定期人工抽查目标层执行日志。主要排查对象包括工具调用是否与当前阶段目标一致是否存在无效的重复调用历史信息是否出现截断后的自我矛盾模型是否因为 Context 太长而丢失早期任务约束。如果日志里出现“模型反复尝试调用一个并不存在的工具”“在第 3 步就开始重复使用第 1 步的结论”这些问题单靠评估分数不容易发现需要日志联动分析。6.4 判断优化是否成功的标准成功率在验收任务集上成功率持续上升而不是单次波动中断率因为“步数耗尽”或“解析失败”而中断的任务占比降低稳定收益元优化后的 Harness 在没有继续优化时也能在相似任务上保持效果而不是过拟合到训练样本可解释性新的 Harness 修改点能够解释为“减少了盲目重试”或“补充了输出格式约束”而不是随机改动。7. 自动化接入与批量任务框架AutoDesign 从实验走向生产必须解决批量任务和自动化接入问题。简单说你需要把实验流程封装成可调度的任务服务让外部系统可以提交多份需求并带上一份 Harness 配置或“使用默认配置进行优化”的标记。一个通用流程如下接收 Job 请求保存任务参数到队列Worker 拉取任务选择 Harness 版本目标层执行并将完整日志写入文件或数据库评估器计算指标写入结果记录如果是元层优化任务还需触发配置迭代流程。下面是批量提交任务的 Python 调用示意实际接口路径和任务结构需要按你的平台调整。import requests import json job_list [ {task_id: job_001, content: 设计一个登录页面的视觉布局方案, harness_id: harness_v3}, {task_id: job_002, content: 为一款在线协作工具设计设置面板结构, harness_id: harness_v3}, ] for job in job_list: resp requests.post( http://127.0.0.1:8000/submit, jsonjob, timeout30 ) print(job[task_id], resp.status_code, resp.text)批量任务的难点往往不在接口本身而在失败重试和日志关联。建议在 task_id 之外增加全局 request_id所有内部日志都带这个 ID否则一旦某个任务中间卡住排查顺序会非常痛苦。失败重试策略也要谨慎。对于 LLM 类任务直接盲目重试可能浪费大量 token。建议区分错误类型接口超时可重试模型返回格式非法可以重试但重试用例要带上纠错说明任务执行超过最大步数通常重试也没有意义应该记录失败原因后通过元层分析修复逻辑。元层优化还有一个更高阶的玩法不针对单个任务优化 Harness而是维护一个 Harness 版本库每次任务在开始时先跑一个小型“能力预检”根据任务难度选择不同 Harness 配置。这与 AutoDesign 的核心目标结合可以演变成一套更自动化的路由机制。当然这属于工程扩展方向实际落地要以你的任务分布和成本结构为前提。8. 资源占用与性能观察AutoDesign 的资源消耗与普通 Agent 应用相比是倍增的因为它在完成目标层任务之外还多了一层元层评估与优化调用。需要重点观察三个方向。8.1 推理 Token 消耗Long-Horizon 任务本身会导致长上下文。每个步骤都要把前面的历史信息重新发送给模型随着步骤增加Token 消耗呈近似线性增长。如果再加一层元层优化每个优化周期还需要带上日志摘要日志越长 Token 越大。建议在日志入库时对文本做截断或摘要不要让元层优化器读取全部原始日志。# 示例截断超长日志的逻辑片段 def truncate_log_text(log_text: str, max_chars: int 3000): if len(log_text) max_chars: return log_text head log_text[: max_chars // 2] tail log_text[-max_chars // 2:] return head \n...[middle truncated]...\n tail8.2 上下文窗口与显存关系如果你使用本地模型上下文窗口长度直接决定显存占用。模型上下文越长KV Cache 占用的显存越高尤其是在长视野任务持续多轮对话时需要注意。同一个模型处理短查询和处理 10 轮以上长任务日志所需显存可能有明显差异。具体数字不能一概而论需要按实际模型、量化精度和并发数测试。以是否接入本地模型的判断为准如果完全走云端模型 API本机主要资源瓶颈在任务队列、日志存储和处理进程本身CPU 内存 8G 以上基本够用如果走本地推理显存大小才是决定上限的因素。8.3 性能取舍建议在做 AutoDesign 实验时不要一开始就在全量验收集上做元优化。正确做法是先抽 5 到 8 个代表任务作为快速反馈集元层每修改一轮 Harness就在快速反馈集上跑一次。确认指标没有退化之后再扩大到全量验证集。这样可以大幅降低优化成本也让迭代频率更快。如果目标层模型出现反复输出非法 JSON 的情况可以考虑增强解析器的容错能力而不是让元层模型重新生成一版 Harness。解析器容错和处理异常生成结果是执行器层面的事元层模型更适合处理策略问题。9. 常见问题与排查方法从工程预研角度AutoDesign 类系统最容易遇到下面几类问题。排查时不建议只盯代码报错要从“最终分数降到阈值外”往回追原因。问题现象可能原因排查方式解决方案优化循环不收敛评估指标波动太大、验收任务量太少、元层上下文里缺少具体失败样例检查多轮评估分数的标准差与日志摘要固定验收集增加样本量优化目标从泛化描述改为具体失败模式成功率上升但 token 消耗暴涨模型在无关步骤上消耗上下文或 Harness 增加了无效的中间检查点分析每步调用类型与 token 消耗分布在 Harness 中增加“完成预期后立即输出最终结果”的跳出条件长任务出现早期任务约束丢失上下文过长导致截断或模型注意力集中在最近几轮回放执行日志查看关键约束是否还存在于历史消息中使用持久化 Memory按阶段摘要早期信息并重新注入元层输出不是合法 JSON元层 Prompt 约束不足或输出被截断打印原始模型响应增强结构化输出约束或使用 JSON Mode 接口重试风暴失败后直接重试全部任务导致接口压力增大查看日志中的 token 消耗与调用频次区分可重试错误与不可重试错误必要时引入退避策略结果分数偏离人工判断评估器指标设计不合理例如只关注完成不关注质量抽取失败样本人工对比在评估器中加入规则校验或模型质量评分需要特别提醒的是AutoDesign 里一旦元层优化器生成的 Harness 明显偏离预期不要急着“把模型换大一号”。更大的模型固然可能生成更复杂的配置但也会带来更高的延迟与成本。更稳妥的做法是记录当前 Harness 中哪一条约束导致了问题直接修改对应配置项然后观察下一次执行是否改善。这种“定向修策略”的方式比无脑全量重跑高效得多。10. 最佳实践与使用建议AutoDesign 这套范式如果要用到真实系统建议按下面的工程节奏推进不要直接上线完全自治的“Agent 设计 Agent”产品。第一阶段做好任务样本库。把你的真实任务整理成可重复执行、可自动评估的数据集。这是 AutoDesign 能否跑通的前提。如果这一步没有做好后面所有优化都会变成盲人摸象。第二阶段先选择一个基线 Harness。最简单的方式是手工写一个固定流程的 ReAct 或 Plan-and-Execute 循环跑通一段端到端任务并记录日志。这个阶段的目标不是效果多好而是让日志、错误分类、评估指标和任务 ID 串联起来。第三阶段实现元层优化闭环。在基线上增加日志摘要模块、指标聚合模块和 Harness 生成模块。优化时保持“每轮只修一个关键问题”的原则宁可多跑几轮也不要让单轮改动过大否则无法定位是哪项改动提升了效果。第四阶段加入安全边界和人工抽检。对 Harness 自动生成工具的调用权限进行限制不建议直接授权元层模型新增或删除任何工具它的职责应该局限于调整执行策略。每次元层输出新配置后至少要跑一轮安全校验检查是否存在绕过权限、访问非法资源、修改受保护文件的描述。第五阶段逐步扩大自动权限。只有经过充分验证、并在多人复核过的 Harness 版本才可以在受限范围内自动使用。涉及高风险操作例如发送消息、修改数据库、发布内容必须在系统中保留不可跳过的授权步骤。从合规角度再三重复一点凡是涉及真实用户数据、受版权保护内容、人脸或声音信息、跨系统操作、第三方账号的自动化流程都必须事先确认授权与合规边界。AutoDesign 的理念是让系统更聪明地完成任务而不是让系统突破使用边界。评估器里必须加入安全合规维度确保模型“能做好一件事”和“只做合法范围内的事”这两个目标不冲突。11. 总结AutoDesign 思路是否值得跟进AutoDesign 这个方向给 agent 工程带来的最大启发不是“以后不用人写 Prompt 了”而是把静态的 Prompt 工程升级成了动态的系统优化问题。它把目标层的执行框架看成可以被搜索和迭代的对象把工程师从“手调几十条规则”的重复劳动里解放出来同时也把问题转移到了“如何构建可靠评估器”和“如何控制优化成本”上。如果你想在自己项目里验证这套思路最先应该做的不是写一个完整的元优化器而是先回答一个问题你手头的任务集是否可以自动评估如果答案是肯定的AutoDesign 就具备了落地的土壤如果答案是否定的优先补评估能力远比搭一个精美的 Harness 搜索框架更有价值。最容易踩的坑是低估日志分析和评估集的作用。很多团队会花大量时间设计元层 Prompt却忽视了日志里最有价值的信息哪一步重复调用、哪一步上下文溢出、哪一步输出格式不合法。把这些失败模式结构化再交给元层模型去修改 Harness效果会好很多。AutoDesign 真正可以持续扩展的方向包括多任务场景下的 Harness 路由、基于历史优化的成本控制、评估器的自动生成与校准、以及把 Harness 版本化后接入 CI/CD 流程。如果你正在做 Agent 平台或者复杂工作流引擎建议先把这套“配置可解析、执行可记录、效果可评估、上层可迭代”的工程基础打牢。后续就算不沿用 AutoDesign 的全部设计这套思路也能显著降低智能体系统的维护成本。