在 Agent 类系统的实践里普通单轮问答和 Long-Horizon Agentic Design 的差别不只是任务变长那么简单。AutoDesign、Meta-Harness Optimization、Long-Horizon、Agentic Design 这几个词组合在一起指向的是一类更真实的系统问题当设计任务需要 Agent 连续工作数小时甚至数天需要拆解约束、调用多种工具、产生中间方案、根据验证结果反复返工时系统靠什么保证它不偏离原始目标、不遗忘关键约束、不把时间浪费在无效路径上。这篇文章把 AutoDesign 当作一种长周期设计任务的系统控制方法来看待重点讲清楚 Meta-Harness Optimization 为什么不是给模型再写一段复杂 Prompt而是要把 Agent 放进一层可控、可观测、可回溯、可自我优化的 Harness 控制框架中。读完可以按照文中结构和代码骨架搭建一套自己的长周期设计 Agent 最小系统。1. Long-Horizon Agentic Design 的难点不在单次推理而在长距离控制1.1 任务跨度拉长后Agent 系统多了哪些新变量单轮 Agent 任务通常是这样用户输入一个问题模型返回一个答案调用一次工具流程结束。你不需要关心上一轮状态是否被污染不需要判断任务是否在错误方向上走得太远也不需要设计“返工”机制因为失败后重开一轮的成本很低。Long-Horizon Agentic Design 不一样。它面向的是产品概念设计、系统架构设计、数据模型设计、技术方案评审这类需要持续推演的任务。这类任务有几个共同特征目标不是一次生成就能完成的需要多轮拆解和收敛。输入约束很多且可能互相冲突比如成本、性能、可维护性、时间窗口。中间产物需要被反复验证和修改不是单向流水线。越到后期早期错误被放大的成本越高。任务跨度拉长之后Agent 系统面对的关键问题就不再是“这一步模型回答得对不对”而是“系统能不能在几十步、上百步的执行过程中保持方向一致、约束不丢、失败可恢复”。这个能力已经超出单次模型推理的范畴必须由外层执行系统来承担。1.2 长周期设计任务最容易出现的四类失控现象结合实际的 Agent 项目经验长周期任务最容易出现以下四类问题且彼此会互相影响。第一类是规划漂移。Agent 在执行到第 20 步时可能已经完全按照局部最优的逻辑在推进忘记了最初的产品定位或架构约束输出的方案越来越像“通用模板”而不是“针对这个输入的设计结果”。第二类是约束遗忘。长周期任务往往有多个约束条件而且约束可能在执行过程中新增。Agent 的上下文窗口有限当对话记录或中间方案越来越多早期的重要约束会被挤出注意力系统后期很难自动发现“这个设计已经违反了需求 A”。第三类是上下文互相污染。把多轮工具结果直接堆进上下文很容易造成信息冲突。一个工具输出过时版本另一个工具输出了新版本模型不知道以谁为准可能自己拼接出一个混合方案。第四类是自我验证失效。让模型自己检查自己的输出在短任务中还能看在长周期任务中很容易失效因为模型缺少可靠的“期望基线”它并不清楚哪个中间版本才是符合全部需求的。这些问题的共同点是它们都不是模型单步生成能力造成的而是系统缺少计划管理、状态管理、验证回溯这些机制造成的。1.3 为什么“模型更强”不能直接解决长周期问题很多团队在遇到长周期任务效果不好时第一反应是换更大的模型或换更长的上下文。这个思路有一定作用但天花板很低。模型能力再强也只能保证单次决策的质量。它无法天然保证五十步之后还能参照第一轮定义的目标执行因为长期目标的保持依赖执行系统不断把“当前状态”与“目标基线”对齐。上下文再长也只能缓解信息被挤出的问题无法解决信息矛盾、验证失效和无效路径的累积。系统需要做的是把“长距离控制”从模型中抽出来交给一个显式的框架来管理。这正是 AutoDesign 这个词所表达的思路设计任务本身由 Agent 完成但方向盘、刹车、回放记录这些控制机制要由外层系统掌握。维度短周期 Agent 问答Long-Horizon Agentic Design执行长度单轮或少量轮次数十轮以上可能跨小时级失败成本低重试即可高晚期失败需要大范围返工主要风险单次回答质量方向漂移、约束遗忘、上下文冲突控制重点提示词和工具调用格式状态管理、验证回溯、策略优化是否需要 Harness不明显必须2. 先理解 AutoDesign 的核心Meta-Harness Optimization2.1 Harness 与 Base Agent 的分工要理解 Meta-Harness Optimization先要理解 Harness 是什么。Harness 可以译为“控制套件”或“执行框架”它是在 Base Agent 外面增加的一层运行控制机制。Base Agent 的职责是单步决策看到当前问题决定下一步写什么、调用什么工具、生成什么内容。在长周期任务中Base Agent 不应该自己掌管理论上无限的上下文也不应该自己决定什么时候应该回头看需求文档。Harness 的职责是控制 Base Agent 的运行环境。它负责维护任务目标和需求约束形成独立于对话上下文的目标状态区。管理执行快照让系统可以回到任意一个合法状态。判断当前计划是否已经偏离方向决定是否触发重新规划。记录每一步执行轨迹供后续复盘和优化使用。在多个候选策略之间做选择决定下一步使用哪套执行方式。可以这样理解Base Agent 是执行引擎Harness 是自动驾驶中的车道保持系统。引擎负责输出动力车道保持系统负责判断方向是否正确并决定什么时候纠正。2.2 “Meta”层优化的是什么普通 Agent 系统的 Prompt 优化通常是针对某一步指令做调整。Meta-Harness Optimization 的优化对象不是模型参数也不是单条 Prompt 文本而是 Harness 自身的控制策略。具体来说需要优化的内容包括当前状态下应该采用哪种规划的拆分粒度。执行多少步之后应该做一次目标一致性检查。什么情况下判定“当前路径不可行”需要回滚到哪一个快照。验证器怎么实现不同验证结果对应什么控制动作。上下文摘要怎么写哪些信息必须保留哪些信息可以压缩。这些策略被称为 Harness 策略。Meta 的含义是系统不仅执行任务还会在执行完一类任务后根据结果反馈来改进 Harness 下一次的控制策略。如果一次长周期执行失败了系统要能识别出失败模式进而调整触发回滚的阈值、改变方案评审的频率或者优化上下文组织方式。2.3 AutoDesign 与 ReAct、Plan-and-Execute 的差别很多读者接触过 ReAct 模式也见过 Plan-and-Execute 模式。AutoDesign 的思路和它们不同它不是在 Agent 决策层增加某种 Prompt 模式而是在执行层增加一个可优化的控制环。ReAct 强调“思考、行动、观察”的循环让模型在每一步都结合观察结果做决策它的优点是灵活缺点是缺少全局状态管理和长期目标的显式保持很容易在多步之后漂移。Plan-and-Execute 强调先做完整规划再逐步执行优点是结构清晰缺点是一旦规划本身建立在错误假设上执行期很少有机会动态纠正。AutoDesign 的 Harness 可以把这些模式都变成自己的“可选策略”在简单阶段用 ReAct 提高灵活性在需要严格阶段推进时用 Plan-and-Execute 拆分节点在偏离高风险阶段插入频繁目标校验。系统不是绑定某一种决策模式而是具备选择、组合并优化这些模式的能力。能力ReActPlan-and-ExecuteAutoDesign Harness单步决策位置Agent 内部按计划执行Agent 内部但受 Harness 约束全局目标管理弱前期规划强执行中弱独立状态区持续对齐失败回滚几乎不提供需要完全重新执行基于快照选择回滚点上下文组织直接拼接历史按步骤拼接按状态区摘要动态组织控制策略调整手工改 Prompt手工改流程Meta-Optimizer 根据轨迹调优2.4 没有现成源码时如何落地这套概念AutoDesign 这类名字在不同论文或开源项目中可能有不同侧重。如果你阅读到的资料没有附带可直接运行的仓库不要急于找一个“官方实现”。更有效的做法是把上面的思想拆成可以工程的模块任务目标注册区、状态管理区、执行控制区、验证回溯区、元优化区。这篇文章后续给出的代码就是对这套结构的一种轻量实现思路展示并不假设你已经拥有某个完整代码库。3. 工程化理解AutoDesign 系统应该由哪些模块构成3.1 五类核心模块的职责划分要把 Meta-Harness Optimization 变成可运行代码先要确定系统由哪几个模块组成。这里给出推荐的分层任务目标注册与拆解层负责接收用户原始输入把它转换成机器可检查的 RequirementFrame。用户说“设计一个低成本的库存管理系统”系统不能直接把这个句子当成任务锚点而应该拆成角色、业务范围、约束条件、交付产物、验收标准五类字段。状态与记忆层负责保存当前执行快照、历史轨迹、上下文摘要。它不是单纯保存对话记录而是把对话消息、工具输出、当前方案版本、已满足约束、待回填风险分开存储。行动执行层负责调用 Base Agent 和工具。它接收来自 Harness 的单步指令调用模型生成内容或调用外部工具并把结果标准化后写回状态区。验证与回溯层负责周期性检查当前产出是否还在任务目标允许范围内如果发现偏离或错误则触发回滚。元优化层负责在所有执行结束后分析轨迹中的失败模式并生成下一轮任务的 Harness 配置。这五层中前四层是把系统跑起来的基础第五层是 AutoDesign 名称里 “Meta” 的来源。实际项目可以先只做前四层跑通后再加入元优化层。3.2 状态管理用“快照加轨迹”不要只存对话历史很多 Agent 项目的状态管理就是维护一个 message 数组这是不够的。message 数组只能回答“模型说过什么”回答不了三个关键问题当前完整方案版本是什么、哪些约束已经验证通过、哪些分支路径曾经被尝试过并失败了。没有这类信息系统就无法在偏离发生时恢复到正确状态。推荐使用“快照加轨迹”的结构。快照保存某一时刻的完整系统状态包括需求帧、当前方案版本、约束满足情况、已执行节点 ID。它相当于数据库的 checkpoint。轨迹则保存每步动作和原因用来复盘“为什么走到当前状态”。快照用于回滚轨迹用于学习和调试。信息类型对话历史状态快照执行轨迹模型消息有无事件记录当前方案版本可能隐含有无约束满足情况无有无失败尝试记录有但不易检索无有结构化适合用途生成上下文回滚、恢复分析优化、审计3.3 Harness 控制循环长什么样Harness 的主循环不建议写成“不停调用模型直到用户满意”的 while 循环。它应该是带条件判断和恢复动作的分段循环。理想流程如下先从任务目标区读取未完成节点再从状态区恢复当前快照接着调用 Base Agent 决策下一步行动并执行执行结果写回状态区然后周期触发一致性验证如果验证通过则继续推进如果失败则回到最近一个合法快照并调整策略最后所有步骤都被记录进执行轨迹。整个过程里Harness 不会代替模型做专业内容设计它只保证设计过程始终处于可控轨道上。这个控制循环每一轮都会回答四个问题当前处于什么状态、当前是否偏离目标、下一步应该做什么、如果失败应该回到哪里。4. 最小可行实现搭一个可运行的 AutoDesign Harness 环境4.1 准备 Python 环境与依赖这里的实现示例以 Python 3.10 及以上版本为例依赖尽量少方便在本地快速跑通验证流程。不要直接在生产环境套用生产环境需要额外处理密钥、限流、日志落盘和可观测性。安装基础依赖python -m venv .venv source .venv/bin/activate pip install pydantic2.* pip install openai pip install pyyaml说明一下为什么要引入 pydantic。Agent 系统的状态类非常多如果全部用 dict 管理字段名拼写错误、类型不匹配都会在几十步执行后才会暴露。pydantic 可以在状态写入和读取时立刻校验类型让状态管理足够严格。大模型部分不绑定具体厂商。代码里以BaseLLMClient作为抽象层真实项目里再替换成 OpenAI、通义或其他兼容 SDK。这样做的好处是 Harness 的控制逻辑和模型实现解耦后续换模型不需要改状态管理代码。4.2 推荐目录结构autodesign/ ├── main.py ├── core/ │ ├── __init__.py │ ├── requirements.py │ ├── state.py │ ├── harness.py │ ├── meta.py │ └── llm.py ├── data/ │ └── tasks.yaml └── logs/ └── trace.jsonlcore/requirements.py负责定义需求模型core/state.py定义快照和执行状态core/harness.py实现主控制循环core/meta.py实现轻量元优化逻辑core/llm.py统一模型调用接口。logs/trace.jsonl用来记录执行轨迹每一行是一个结构化事件。4.3 定义核心数据结构先定义需求帧。用户输入必须转换成结构化字段才能被后续程序检查from pydantic import BaseModel, Field from typing import List, Optional class DesignRequirement(BaseModel): project_name: str roles: List[str] Field(description设计涉及的参与方或角色) objectives: List[str] Field(description需要达到的核心目标) constraints: List[str] Field(description必须遵守的限制条件) deliverables: List[str] Field(description最终交付物) acceptance_criteria: List[str] Field(description用于验证最终成果的标准) class RequirementFrame(BaseModel): requirement_id: str raw_text: str design_requirement: DesignRequirement frozen: bool Field(defaultFalse, description是否已经冻结冻结后不允许随意修改)冻结字段很重要。长周期任务中需求有时会被用户追加但不能在任何阶段都被随意改动。一旦任务进入执行后期需求变更必须以新版本帧的形式存在并把变更原因写入轨迹否则系统会因为目标频繁变化而无法收敛。再定义执行状态和快照from enum import Enum from typing import Dict, Any, List class Phase(str, Enum): REQUIREMENT_ANALYSIS requirement_analysis RESEARCH research DRAFTING drafting REVIEW review REVISION revision FINALIZE finalize class Artifact(BaseModel): artifact_id: str version: int content: str class ExecutionSnapshot(BaseModel): snapshot_id: str step_index: int requirement_frame: RequirementFrame phase: Phase artifacts: Dict[str, Artifact] completed_nodes: List[str] violated_constraints: List[str] summary: str快照字段里最容易被忽略的是violated_constraints。它不是成功指标而是失败记录。普通系统通常只记成功的中间产物但长周期 Agent 更需要在失败发生前就把“已经察觉的约束违反”显式记录下来这样才能触发回溯。4.4 定义执行记录格式执行轨迹需要记录足够多的事件但文件量不能失控。推荐以 JSON Lines 格式写日志class StepAction(BaseModel): step_id: str description: str agent_choice: str tool_name: Optional[str] None prompt_excerpt: str output_excerpt: str class StepRecord(BaseModel): step_id: str step_index: int timestamp: str snapshot_before: str action: StepAction status: str snapshot_after: str error_message: Optional[str] None每条记录都有snapshot_before和snapshot_after这样复盘时可以精确知道这一步从哪里执行到哪里不需要把完整状态都打印在日志里只保存 snapshot_id 即可。5. 核心代码实现把一个普通 Agent 改造为受 Harness 控制的长周期系统5.1 把用户任务转换为 RequirementFrame在进入循环前系统需要先把用户输入转成结构化 RequirementFrame。这里用一个轻量的 parserdef parse_requirement_from_task(task_text: str, llm_client) - RequirementFrame: system_instruction ( 把用户的设计任务拆解为结构化需求输出 JSON 字段为 project_name, roles, objectives, constraints, deliverables, acceptance_criteria。 不要添加用户没有提及的约束不要遗漏用户已经提供的限制。 ) response llm_client.complete(system_instruction, task_text, response_formatjson) data json.loads(response) design_req DesignRequirement(**data) return RequirementFrame( requirement_iduuid4().hex[:8], raw_texttask_text, design_requirementdesign_req, frozenFalse )这一步很容易踩坑。不要试图在第一轮拆解时就把需求做到绝对完整更不要用模型自行脑补约束。拆解的目标是生成“可检查的初始帧”而不是“完美计划”。后续执行中用户可能会追加信息只要 Harness 允许以版本化方式更新帧就是合理的。5.2 实现 Harness 主循环骨架整个 AutoDesign 控制核心在 Harness 类里。下面给出一个结构完整且可扩展的循环class AutoDesignHarness: def __init__(self, llm_client, snapshot_store, trace_store): self.llm llm_client self.snapshots snapshot_store self.trace trace_store self.max_steps 40 self.validation_interval 3 self.rollback_threshold 1 def run(self, requirement_frame: RequirementFrame) - ExecutionSnapshot: current_rf requirement_frame snapshot self._initial_snapshot(current_rf) violations_streak 0 for step_index in range(self.max_steps): if self._is_terminal(snapshot): self._record_terminal(snapshot) return snapshot plan_node self._select_next_node(snapshot, current_rf) if plan_node is None: break action self._decide_action(snapshot, plan_node) new_snapshot, error self._execute_action(snapshot, action) self._persist_trace(snapshot, action, new_snapshot, error) if error is not None: violations_streak 1 else: violations_streak 0 snapshot new_snapshot if step_index % self.validation_interval 0: report self._validate_against_requirements(snapshot, current_rf) if report.has_blocking_violations(): snapshot self._rollback_to_latest_valid(snapshot) violations_streak 1 if violations_streak self.rollback_threshold: snapshot self._rollback_and_change_strategy(snapshot) violations_streak 0 return snapshot这个循环有四个关键点执行前有_select_next_node决定下一步推进哪个目标而不是让模型自由发挥执行后有快照对比和轨迹记录每隔固定步数执行一次目标一致性验证连续失败触发回滚并切换策略。想立刻开始的读者不要觉得它简单这套循环已经能覆盖大多数长周期 Agent 失控问题。5.3 快照存储与回滚逻辑快照不能只存在内存里否则系统中途重启就无法恢复。用文件或数据库做快照存储class FileSnapshotStore: def __init__(self, base_dir: str): self.base_dir Path(base_dir) self.base_dir.mkdir(parentsTrue, exist_okTrue) def save(self, snapshot: ExecutionSnapshot) - str: path self.base_dir / f{snapshot.snapshot_id}.json path.write_text(snapshot.model_dump_json(indent2), encodingutf-8) return snapshot.snapshot_id def load(self, snapshot_id: str) - ExecutionSnapshot: path self.base_dir / f{snapshot_id}.json data json.loads(path.read_text(encodingutf-8)) return ExecutionSnapshot.model_validate(data)回滚逻辑要注意粒度问题。最简单的回滚是回到上个快照但这可能丢掉有效的进展。推荐记录“快照分支”当一个验证失败发生时Harness 读取失败记录找到导致失败的那一步然后回到该步之前的快照并把失败尝试存进轨迹。def rollback_to_snapshot(snapshot_store, trace_store, snapshot_id): snapshot snapshot_store.load(snapshot_id) trace_store.rollback_log.append({ event: rollback, target_snapshot: snapshot_id, reason: blocking_violation }) return snapshot生产项目中回滚建议配合人工审查确认自动回滚可能选错基线尤其是在设计任务的早期过多自动回滚会导致系统无法推进。可以先用“警告并暂停”策略观察一段时间后再开放自动回滚。5.4 实现一个极简 Meta-Optimizer 示例Meta-Optimizer 不需要一上来就做成强化学习系统它可以从规则策略开始。核心思想是根据执行轨迹选择下一轮任务使用的 Harness 策略。先定义 HarnessPolicyclass HarnessPolicy(BaseModel): validation_interval: int rollback_threshold: int use_plan_first: bool max_draft_length: int context_summary_mode: str Field(defaultembed_requirements)然后定义一个基于轨迹事件的优化器class SimpleMetaOptimizer: def __init__(self, policies: List[HarnessPolicy]): self.policies policies self.history [] def register_trace(self, trace_records, final_status): self.history.append({ trace: trace_records, status: final_status }) def propose_next_policy(self, current_policy: HarnessPolicy) - HarnessPolicy: recent_failures [h for h in self.history[-5:] if h[status] FAILED] if not recent_failures: return current_policy drift_failures sum( 1 for h in recent_failures if self._has_drift_event(h[trace]) ) if drift_failures 2: return HarnessPolicy( validation_interval1, rollback_threshold1, use_plan_firstTrue, max_draft_length500, context_summary_modestrict_requirement_check ) return current_policy从工程角度看这个 Optimizer 已经体现了 Meta 层的核心它不是在 Prompt 层面修补而是在本轮任务结束后调整下一轮任务的验证频率、回溯阈值和上下文组织方式。如果你有更多的历史数据可以把register_trace的数据接入离线评估逻辑用准确率指标来决定是否采用某个新策略。5.5 接入真实模型和设计工具上面的代码保留了llm_client抽象。真实接入时建议把模型调用封装成统一方法class OpenAIClient: def __init__(self, api_key, modelgpt-4o-mini): self.client OpenAI(api_keyapi_key) self.model model def complete(self, system_prompt, user_prompt, response_formatNone, temperature0.2): kwargs { model: self.model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: temperature, } if response_format json: kwargs[response_format] {type: json_object} resp self.client.chat.completions.create(**kwargs) return resp.choices[0].message.content注意在 Long-Horizon 任务里temperature 不要设得过高。设计任务虽然需要探索但 Harness 已经承担了探索机制模型的单步输出更应当稳定、可预期、符合 JSON 结构。探索交给系统层在不同方案之间的选择不要交给单次生成时随机性。5.6 主流程入口示例最后用main.py把它们串起来from core.requirements import parse_requirement_from_task from core.harness import AutoDesignHarness from core.meta import SimpleMetaOptimizer from core.state import FileSnapshotStore from core.llm import OpenAIClient def main(): llm OpenAIClient(api_keyyour-key) snapshots FileSnapshotStore(./data/snapshots) optimizer SimpleMetaOptimizer(policies[]) task_text 为一个中小型仓库设计低成本的库存预警系统 rf parse_requirement_from_task(task_text, llm) harness AutoDesignHarness(llm, snapshots, trace_store) final_snapshot harness.run(rf) optimizer.register_trace(harness.trace.records, final_snapshot.status) print(final_snapshot.model_dump_json(indent2)) if __name__ __main__: main()6. 运行验证从“能跑”到“能判断有没有变好”6.1 用一组任务池验证而不是单条任务长周期 Agent 最忌讳用一两条任务判断效果。你至少要准备五到十条覆盖不同领域的设计任务。下面是一个示例任务池实际项目可以替换成你自己的场景任务 ID任务描述主要难点期望轮次T1设计仓库库存预警系统多约束、需要权衡成本与准确率15T2设计一个内部员工请假审批流程涉及角色矩阵与异常分支12T3为二手交易平台设计订单争议仲裁方案需要多轮方案修改25T4设计一个数据分析报表的多租户权限模型安全规则复杂容易遗忘约束20T5为一个智能家居 App 规划冷启动推荐策略无明显正确答案需要评估探索30每个任务都需要提前写清楚“人工评价关注点”。这一条在开始实验前就要做否则任务跑完后你只能凭感觉判断结果无法给出可复现的对比。6.2 关键指标不只看最终成功率只看最终成功率的坏处是一个最终结果勉强合格、但中间出现多次无效绕路的系统和一个高效收敛的系统在成功率上可能完全相同。所以 AutoDesign 实验至少要记录以下指标里程碑达成率规划阶段拆解出的关键节点有多少被实际完成。约束遗忘次数执行过程中发现有多少条原始约束被违反。方向一致率人工评估每轮中间产物时有多少步骤仍然与目标相关。无效步骤占比执行轨迹中被回滚或最终未使用的步骤数量占总步骤的比例。平均偏离轮数系统第一次产生需求外内容到被纠正之间的轮次间隔。指标计算方式说明里程碑达成率达成节点数 / 计划节点数判断任务是否推进完整约束遗忘次数统计验证阶段触发的遗忘失败判断需求管理是否稳定无效步骤占比回滚步骤数 / 总步骤数判断决策质量和回溯策略平均偏离轮数偏离开始到纠正的轮数均值判断控制循环敏感度6.3 运行过程中的观察与检查点任务执行过程中需要留下可以回看的结构化数据。执行结束后除了看最终产物还要打开轨迹文件从事件流中复盘这两个问题第一次偏离发生在第几步当时的快照内容是什么。触发回滚时选择的回滚点是否正确有没有把有效进展一起丢弃。建议在日志里额外生成本地 JSON 快照方便用 Python 脚本批量分析python scripts/analyze_trace.py --log logs/trace.jsonl \ --metric constraint_forgetting \ --requirement data/tasks.yaml如果一段时间后系统的约束遗忘次数下降但无效步骤占比上升说明验证器变得过度敏感Harness 频繁打断有效执行。这时需要调大validation_interval或者优化验证器的判断条件。7. 常见问题与排查链路7.1 任务进行到后期输出明显偏离原始需求现象前几轮还按照需求文档推进十轮之后开始出现与原始目标无关的设计内容甚至用通用模板覆盖了特定约束。可能的根因有三个需求帧没有在后续提示中持续出现验证器只在固定步数触发没能在偏离早期发现问题上下文被工具输出和中间方案挤占模型忘记了原始约束。排查顺序先检查需求帧在每轮提示词中是完整透传还是已经被摘要替代。再检查验证器是从哪个快照开始判定“一致”的如果它自己也使用被污染上下文就会失去参考价值。解决思路把RequirementFrame里最核心的 acceptance_criteria 单独拼到每轮用户提示词末尾把执行步骤与需求节点的关联记录下来在每轮循环前插入一次轻量一致性检查如果当前输出违反了任一验收标准立即触发回滚。注意验证器必须依赖独立状态区中的 RequirementFrame不能使用模型上一步生成的总结来判断是否偏离否则会出现“错误被另一层错误掩盖”的情况。7.2 Harness 本身成了执行瓶颈响应延迟和 token 成本明显升高现象Harness 引入后每个步骤都要额外做验证还要写多条结构化状态任务没变复杂耗时长了一倍。先观察轨迹日志中的 token 分布确认额外成本主要来自哪一类系统调用。如果是每轮都重新把完整需求帧、完整方案快照、全部历史摘要拼进上下文成本必然会高。优化方向有几个快照摘要可以分层顶层只保留当前方案版本、下一步候选、未完成的约束列表细节放到二级块中按需读取验证不是每步都调用大模型可以先做关键词级和规则级检查通过后再调用模型做深度一致性判断回滚不需要立刻执行模型完整重规划可以先用离线路由选择一条已缓存的候选策略。经验上Harness 对长周期任务的额外开销如果在 20% 到 35% 之间属于正常范围。如果超过 50%优先检查是否重复加载上下文和是否每步都做了“不必要的全量验证”。7.3 快照回滚把有效进展一起丢掉了现象系统检测到一个失败后自动回滚结果任务退回到很早期的空状态前几轮已经完成的有效设计被当成无效内容抛弃。原因通常是快照粒度设置得太粗。整个状态分区只有“初始、中期、最终”三个快照回滚时无法定位到具体失败转折点。另一个常见原因是回滚策略写成了无条件回到上个 checkpoint而没有判断失败是否发生在当前步骤生成的内容中。解决方式把快照粒度细化到每个“目标节点完成点”并在每个快照里保存已满足需求的标记。回滚优先寻找最近的“包含当前需求节点且未违反约束”的快照而不是简单的上一份。如果没有任何快照满足条件再降级到人工暂停等待处理。7.4 Meta-Optimizer 不收敛同一类失败反复出现现象优化器运行多轮后系统还是会在相似位置失败控制策略没有被真正改变。排查时先检查优化器修改的字段是否真的进入下一轮执行。常见问题是把新的 HarnessPolicy 存到了某个配置对象但 Harness 初始化时读取的是默认参数。再检查轨迹记录是否足够完整优化器能不能定位到失败环节。比如轨迹只记录了“最终失败”没有记录失败前第几步出现偏离优化器就无法确定该调大验证频率还是该修改上下文组织方式。最后一类是过拟合问题优化器在单条任务上调参导致换一条任务后效果更差。建议增加任务池数量并且把优化器策略改动先离线回放到历史轨迹上验证成功率后再上线。7.5 Base Agent 输出不符合 JSON 结构导致状态解析失败现象状态写入时报错字段缺失或类型错误系统在某一步直接中断。排查顺序先看模型被要求输出的 JSON schema 和解析代码中的 pydantic 模型是否一致字段名不匹配是最常见问题。再检查是否对模型输出做了格式兜底例如去掉多余前后缀、修复未闭合 JSON最后检查出错时有没有进入重试循环如果没有状态快照能否恢复。解决建议在 LLM 调用层统一使用 response_format 约束同时提供异常输出重试机制解析不到合法 JSON 时不要使用模糊替换而是记录原始输出并请求模型重新输出。pydantic 模型的字段命名建议全部使用 snake_case避免输出格式里出现大小写不一致导致的解析失败。问题现象常见原因检查方式解决建议后期偏离原始需求需求帧未持续对齐验证频度低检查每轮 prompt 是否注入验收标准缩短验证间隔独立保存需求帧token 成本过高每轮拼入完整历史和完整快照查看轨迹日志中的输入 token 变化引入分层摘要按需读取详情回滚丢失有效进展快照粒度太粗或回滚点选择错误检查回滚目标是否包含有效约束标记细化快照节点分布并增加约束标记错误反复出现Meta 策略未生效或过拟合检查下一轮 Harness 读取的策略对象修正配置读取链路引入任务池评估8. 生产落地清单与后续方向8.1 把 AutoDesign 思路带入现有 Agent 项目的渐进路径如果团队已经有一个能跑通短任务的 Agent 系统不需要一次性推倒重来。推荐分三步演进第一步加入状态快照和执行轨迹记录。不改动模型调用逻辑只把每一步输入输出存成结构化文件。这一步投入很小但立刻让系统具备了可观测性后续分析问题有依据。第二步加入验证和回滚机制。不要立刻把验证器接到每一轮可以先选择高风险阶段做插入式验证把失败的下一步记录下来然后人工判断回滚点。这一步主要是验证“失败是否可以被自动捕获”。第三步再加入 Meta-Optimizer。先使用简单的规则策略根据上几轮失败事件自动选择验证频率和回溯阈值。如果业务数据足够再逐步引入离线评估和策略搜索。很多人会想直接做第三步但缺少前两步的轨迹数据时优化器没有可靠的输入只会变成又一层黑盒这是落地时最常见的误区。8.2 生产环境发布前要检查的事项发布到生产环境前至少要做一次完整检查需求帧是否支持版本化变更用户的追加需求是否会污染已冻结的基线。快照是否有独立存储保存频率是否经过权衡恢复后能不能完整还原上下文。执行轨迹是否包含每个步骤的快照 ID、模型输出摘要、工具调用参数和错误信息能否支持事后审计。验证器使用的是什么参考源是否独立于模型主提示词。自动回滚是否设置了人工确认开关是否需要分级策略提示警告、半自动回滚、全自动回滚。Meta-Optimizer 每次策略变更是否记录版本新策略上线前是否能回滚到旧策略。检查项学习环境标准生产环境标准快照保存文件系统即可独立存储并定期备份轨迹记录本地 JSONL接入中央日志系统并设置保留策略回滚动作自动回滚分级控制高风险任务人工确认Meta 策略上线直接替换版本化并支持灰度切换资源观测人工查日志指标监控与告警8.3 明确 AutoDesign 思路的适用边界这类系统不是适合所有 Agent 场景。如果一个任务只需要单步问答或者任务本身执行完全不可观测外部工具无法留下稳定的结构化反馈那么 AutoDesign 的额外控制层可能得不偿失。适合的场景包括技术架构设计、产品需求评审、数据模型设计、复杂页面信息架构设计、需要多次修改和验证的中长文本方案生成。系统需要具备至少两个前提任务可以拆解成可检查的节点每一步的产物可以被验证器或人工判断执行过程允许有时间做多轮循环不会因为自动回滚造成不可接受的延迟。相反如果任务只是“翻译一句话”或“给出一段摘要”引入长周期控制层会让问题复杂化。Meta-Optimization 的价值来自复杂度路径越复杂、失败越频繁、回顾成本越高它的收益才越明显。8.4 给后续实验和工程实践的建议AutoDesign 这类方法论最值得学习的不是某个具体参数而是它把“系统控制”从“模型输出”中分离出来的思路。面对长周期任务时不要默认把所有问题推给大模型先思考你的外层系统能不能回答三个问题当前状态是什么、当前目标是什么、现在离目标还有多远。给新手的实践建议是先拿五个你熟悉的业务任务手工设计状态快照字段和执行轨迹格式不接入模型用人工执行的方式跑一遍模拟流程。等你能清楚回答上面三个问题后再接入 Base Agent。你会发现 Harness 的结构其实是在帮助你把不可控的长周期执行变得像一系列可审计、可恢复的短周期执行而 Meta 层则让这套控制逻辑能够在任务完成之后持续变好。真正把 AutoDesign 做进生产项目时持续观察的重点也不只是准确率还有每一步失败模式的分布是否在变小。一个稳定长周期 Agent 系统的标志并不是从来没有失败而是失败发生时Harness 能准确知道它发生在了哪里、为什么发生、以及下一次如何通过策略调整规避同类问题。 AutoDesign：长周期Agent任务的Meta-Harness优化控制框架
在 Agent 类系统的实践里普通单轮问答和 Long-Horizon Agentic Design 的差别不只是任务变长那么简单。AutoDesign、Meta-Harness Optimization、Long-Horizon、Agentic Design 这几个词组合在一起指向的是一类更真实的系统问题当设计任务需要 Agent 连续工作数小时甚至数天需要拆解约束、调用多种工具、产生中间方案、根据验证结果反复返工时系统靠什么保证它不偏离原始目标、不遗忘关键约束、不把时间浪费在无效路径上。这篇文章把 AutoDesign 当作一种长周期设计任务的系统控制方法来看待重点讲清楚 Meta-Harness Optimization 为什么不是给模型再写一段复杂 Prompt而是要把 Agent 放进一层可控、可观测、可回溯、可自我优化的 Harness 控制框架中。读完可以按照文中结构和代码骨架搭建一套自己的长周期设计 Agent 最小系统。1. Long-Horizon Agentic Design 的难点不在单次推理而在长距离控制1.1 任务跨度拉长后Agent 系统多了哪些新变量单轮 Agent 任务通常是这样用户输入一个问题模型返回一个答案调用一次工具流程结束。你不需要关心上一轮状态是否被污染不需要判断任务是否在错误方向上走得太远也不需要设计“返工”机制因为失败后重开一轮的成本很低。Long-Horizon Agentic Design 不一样。它面向的是产品概念设计、系统架构设计、数据模型设计、技术方案评审这类需要持续推演的任务。这类任务有几个共同特征目标不是一次生成就能完成的需要多轮拆解和收敛。输入约束很多且可能互相冲突比如成本、性能、可维护性、时间窗口。中间产物需要被反复验证和修改不是单向流水线。越到后期早期错误被放大的成本越高。任务跨度拉长之后Agent 系统面对的关键问题就不再是“这一步模型回答得对不对”而是“系统能不能在几十步、上百步的执行过程中保持方向一致、约束不丢、失败可恢复”。这个能力已经超出单次模型推理的范畴必须由外层执行系统来承担。1.2 长周期设计任务最容易出现的四类失控现象结合实际的 Agent 项目经验长周期任务最容易出现以下四类问题且彼此会互相影响。第一类是规划漂移。Agent 在执行到第 20 步时可能已经完全按照局部最优的逻辑在推进忘记了最初的产品定位或架构约束输出的方案越来越像“通用模板”而不是“针对这个输入的设计结果”。第二类是约束遗忘。长周期任务往往有多个约束条件而且约束可能在执行过程中新增。Agent 的上下文窗口有限当对话记录或中间方案越来越多早期的重要约束会被挤出注意力系统后期很难自动发现“这个设计已经违反了需求 A”。第三类是上下文互相污染。把多轮工具结果直接堆进上下文很容易造成信息冲突。一个工具输出过时版本另一个工具输出了新版本模型不知道以谁为准可能自己拼接出一个混合方案。第四类是自我验证失效。让模型自己检查自己的输出在短任务中还能看在长周期任务中很容易失效因为模型缺少可靠的“期望基线”它并不清楚哪个中间版本才是符合全部需求的。这些问题的共同点是它们都不是模型单步生成能力造成的而是系统缺少计划管理、状态管理、验证回溯这些机制造成的。1.3 为什么“模型更强”不能直接解决长周期问题很多团队在遇到长周期任务效果不好时第一反应是换更大的模型或换更长的上下文。这个思路有一定作用但天花板很低。模型能力再强也只能保证单次决策的质量。它无法天然保证五十步之后还能参照第一轮定义的目标执行因为长期目标的保持依赖执行系统不断把“当前状态”与“目标基线”对齐。上下文再长也只能缓解信息被挤出的问题无法解决信息矛盾、验证失效和无效路径的累积。系统需要做的是把“长距离控制”从模型中抽出来交给一个显式的框架来管理。这正是 AutoDesign 这个词所表达的思路设计任务本身由 Agent 完成但方向盘、刹车、回放记录这些控制机制要由外层系统掌握。维度短周期 Agent 问答Long-Horizon Agentic Design执行长度单轮或少量轮次数十轮以上可能跨小时级失败成本低重试即可高晚期失败需要大范围返工主要风险单次回答质量方向漂移、约束遗忘、上下文冲突控制重点提示词和工具调用格式状态管理、验证回溯、策略优化是否需要 Harness不明显必须2. 先理解 AutoDesign 的核心Meta-Harness Optimization2.1 Harness 与 Base Agent 的分工要理解 Meta-Harness Optimization先要理解 Harness 是什么。Harness 可以译为“控制套件”或“执行框架”它是在 Base Agent 外面增加的一层运行控制机制。Base Agent 的职责是单步决策看到当前问题决定下一步写什么、调用什么工具、生成什么内容。在长周期任务中Base Agent 不应该自己掌管理论上无限的上下文也不应该自己决定什么时候应该回头看需求文档。Harness 的职责是控制 Base Agent 的运行环境。它负责维护任务目标和需求约束形成独立于对话上下文的目标状态区。管理执行快照让系统可以回到任意一个合法状态。判断当前计划是否已经偏离方向决定是否触发重新规划。记录每一步执行轨迹供后续复盘和优化使用。在多个候选策略之间做选择决定下一步使用哪套执行方式。可以这样理解Base Agent 是执行引擎Harness 是自动驾驶中的车道保持系统。引擎负责输出动力车道保持系统负责判断方向是否正确并决定什么时候纠正。2.2 “Meta”层优化的是什么普通 Agent 系统的 Prompt 优化通常是针对某一步指令做调整。Meta-Harness Optimization 的优化对象不是模型参数也不是单条 Prompt 文本而是 Harness 自身的控制策略。具体来说需要优化的内容包括当前状态下应该采用哪种规划的拆分粒度。执行多少步之后应该做一次目标一致性检查。什么情况下判定“当前路径不可行”需要回滚到哪一个快照。验证器怎么实现不同验证结果对应什么控制动作。上下文摘要怎么写哪些信息必须保留哪些信息可以压缩。这些策略被称为 Harness 策略。Meta 的含义是系统不仅执行任务还会在执行完一类任务后根据结果反馈来改进 Harness 下一次的控制策略。如果一次长周期执行失败了系统要能识别出失败模式进而调整触发回滚的阈值、改变方案评审的频率或者优化上下文组织方式。2.3 AutoDesign 与 ReAct、Plan-and-Execute 的差别很多读者接触过 ReAct 模式也见过 Plan-and-Execute 模式。AutoDesign 的思路和它们不同它不是在 Agent 决策层增加某种 Prompt 模式而是在执行层增加一个可优化的控制环。ReAct 强调“思考、行动、观察”的循环让模型在每一步都结合观察结果做决策它的优点是灵活缺点是缺少全局状态管理和长期目标的显式保持很容易在多步之后漂移。Plan-and-Execute 强调先做完整规划再逐步执行优点是结构清晰缺点是一旦规划本身建立在错误假设上执行期很少有机会动态纠正。AutoDesign 的 Harness 可以把这些模式都变成自己的“可选策略”在简单阶段用 ReAct 提高灵活性在需要严格阶段推进时用 Plan-and-Execute 拆分节点在偏离高风险阶段插入频繁目标校验。系统不是绑定某一种决策模式而是具备选择、组合并优化这些模式的能力。能力ReActPlan-and-ExecuteAutoDesign Harness单步决策位置Agent 内部按计划执行Agent 内部但受 Harness 约束全局目标管理弱前期规划强执行中弱独立状态区持续对齐失败回滚几乎不提供需要完全重新执行基于快照选择回滚点上下文组织直接拼接历史按步骤拼接按状态区摘要动态组织控制策略调整手工改 Prompt手工改流程Meta-Optimizer 根据轨迹调优2.4 没有现成源码时如何落地这套概念AutoDesign 这类名字在不同论文或开源项目中可能有不同侧重。如果你阅读到的资料没有附带可直接运行的仓库不要急于找一个“官方实现”。更有效的做法是把上面的思想拆成可以工程的模块任务目标注册区、状态管理区、执行控制区、验证回溯区、元优化区。这篇文章后续给出的代码就是对这套结构的一种轻量实现思路展示并不假设你已经拥有某个完整代码库。3. 工程化理解AutoDesign 系统应该由哪些模块构成3.1 五类核心模块的职责划分要把 Meta-Harness Optimization 变成可运行代码先要确定系统由哪几个模块组成。这里给出推荐的分层任务目标注册与拆解层负责接收用户原始输入把它转换成机器可检查的 RequirementFrame。用户说“设计一个低成本的库存管理系统”系统不能直接把这个句子当成任务锚点而应该拆成角色、业务范围、约束条件、交付产物、验收标准五类字段。状态与记忆层负责保存当前执行快照、历史轨迹、上下文摘要。它不是单纯保存对话记录而是把对话消息、工具输出、当前方案版本、已满足约束、待回填风险分开存储。行动执行层负责调用 Base Agent 和工具。它接收来自 Harness 的单步指令调用模型生成内容或调用外部工具并把结果标准化后写回状态区。验证与回溯层负责周期性检查当前产出是否还在任务目标允许范围内如果发现偏离或错误则触发回滚。元优化层负责在所有执行结束后分析轨迹中的失败模式并生成下一轮任务的 Harness 配置。这五层中前四层是把系统跑起来的基础第五层是 AutoDesign 名称里 “Meta” 的来源。实际项目可以先只做前四层跑通后再加入元优化层。3.2 状态管理用“快照加轨迹”不要只存对话历史很多 Agent 项目的状态管理就是维护一个 message 数组这是不够的。message 数组只能回答“模型说过什么”回答不了三个关键问题当前完整方案版本是什么、哪些约束已经验证通过、哪些分支路径曾经被尝试过并失败了。没有这类信息系统就无法在偏离发生时恢复到正确状态。推荐使用“快照加轨迹”的结构。快照保存某一时刻的完整系统状态包括需求帧、当前方案版本、约束满足情况、已执行节点 ID。它相当于数据库的 checkpoint。轨迹则保存每步动作和原因用来复盘“为什么走到当前状态”。快照用于回滚轨迹用于学习和调试。信息类型对话历史状态快照执行轨迹模型消息有无事件记录当前方案版本可能隐含有无约束满足情况无有无失败尝试记录有但不易检索无有结构化适合用途生成上下文回滚、恢复分析优化、审计3.3 Harness 控制循环长什么样Harness 的主循环不建议写成“不停调用模型直到用户满意”的 while 循环。它应该是带条件判断和恢复动作的分段循环。理想流程如下先从任务目标区读取未完成节点再从状态区恢复当前快照接着调用 Base Agent 决策下一步行动并执行执行结果写回状态区然后周期触发一致性验证如果验证通过则继续推进如果失败则回到最近一个合法快照并调整策略最后所有步骤都被记录进执行轨迹。整个过程里Harness 不会代替模型做专业内容设计它只保证设计过程始终处于可控轨道上。这个控制循环每一轮都会回答四个问题当前处于什么状态、当前是否偏离目标、下一步应该做什么、如果失败应该回到哪里。4. 最小可行实现搭一个可运行的 AutoDesign Harness 环境4.1 准备 Python 环境与依赖这里的实现示例以 Python 3.10 及以上版本为例依赖尽量少方便在本地快速跑通验证流程。不要直接在生产环境套用生产环境需要额外处理密钥、限流、日志落盘和可观测性。安装基础依赖python -m venv .venv source .venv/bin/activate pip install pydantic2.* pip install openai pip install pyyaml说明一下为什么要引入 pydantic。Agent 系统的状态类非常多如果全部用 dict 管理字段名拼写错误、类型不匹配都会在几十步执行后才会暴露。pydantic 可以在状态写入和读取时立刻校验类型让状态管理足够严格。大模型部分不绑定具体厂商。代码里以BaseLLMClient作为抽象层真实项目里再替换成 OpenAI、通义或其他兼容 SDK。这样做的好处是 Harness 的控制逻辑和模型实现解耦后续换模型不需要改状态管理代码。4.2 推荐目录结构autodesign/ ├── main.py ├── core/ │ ├── __init__.py │ ├── requirements.py │ ├── state.py │ ├── harness.py │ ├── meta.py │ └── llm.py ├── data/ │ └── tasks.yaml └── logs/ └── trace.jsonlcore/requirements.py负责定义需求模型core/state.py定义快照和执行状态core/harness.py实现主控制循环core/meta.py实现轻量元优化逻辑core/llm.py统一模型调用接口。logs/trace.jsonl用来记录执行轨迹每一行是一个结构化事件。4.3 定义核心数据结构先定义需求帧。用户输入必须转换成结构化字段才能被后续程序检查from pydantic import BaseModel, Field from typing import List, Optional class DesignRequirement(BaseModel): project_name: str roles: List[str] Field(description设计涉及的参与方或角色) objectives: List[str] Field(description需要达到的核心目标) constraints: List[str] Field(description必须遵守的限制条件) deliverables: List[str] Field(description最终交付物) acceptance_criteria: List[str] Field(description用于验证最终成果的标准) class RequirementFrame(BaseModel): requirement_id: str raw_text: str design_requirement: DesignRequirement frozen: bool Field(defaultFalse, description是否已经冻结冻结后不允许随意修改)冻结字段很重要。长周期任务中需求有时会被用户追加但不能在任何阶段都被随意改动。一旦任务进入执行后期需求变更必须以新版本帧的形式存在并把变更原因写入轨迹否则系统会因为目标频繁变化而无法收敛。再定义执行状态和快照from enum import Enum from typing import Dict, Any, List class Phase(str, Enum): REQUIREMENT_ANALYSIS requirement_analysis RESEARCH research DRAFTING drafting REVIEW review REVISION revision FINALIZE finalize class Artifact(BaseModel): artifact_id: str version: int content: str class ExecutionSnapshot(BaseModel): snapshot_id: str step_index: int requirement_frame: RequirementFrame phase: Phase artifacts: Dict[str, Artifact] completed_nodes: List[str] violated_constraints: List[str] summary: str快照字段里最容易被忽略的是violated_constraints。它不是成功指标而是失败记录。普通系统通常只记成功的中间产物但长周期 Agent 更需要在失败发生前就把“已经察觉的约束违反”显式记录下来这样才能触发回溯。4.4 定义执行记录格式执行轨迹需要记录足够多的事件但文件量不能失控。推荐以 JSON Lines 格式写日志class StepAction(BaseModel): step_id: str description: str agent_choice: str tool_name: Optional[str] None prompt_excerpt: str output_excerpt: str class StepRecord(BaseModel): step_id: str step_index: int timestamp: str snapshot_before: str action: StepAction status: str snapshot_after: str error_message: Optional[str] None每条记录都有snapshot_before和snapshot_after这样复盘时可以精确知道这一步从哪里执行到哪里不需要把完整状态都打印在日志里只保存 snapshot_id 即可。5. 核心代码实现把一个普通 Agent 改造为受 Harness 控制的长周期系统5.1 把用户任务转换为 RequirementFrame在进入循环前系统需要先把用户输入转成结构化 RequirementFrame。这里用一个轻量的 parserdef parse_requirement_from_task(task_text: str, llm_client) - RequirementFrame: system_instruction ( 把用户的设计任务拆解为结构化需求输出 JSON 字段为 project_name, roles, objectives, constraints, deliverables, acceptance_criteria。 不要添加用户没有提及的约束不要遗漏用户已经提供的限制。 ) response llm_client.complete(system_instruction, task_text, response_formatjson) data json.loads(response) design_req DesignRequirement(**data) return RequirementFrame( requirement_iduuid4().hex[:8], raw_texttask_text, design_requirementdesign_req, frozenFalse )这一步很容易踩坑。不要试图在第一轮拆解时就把需求做到绝对完整更不要用模型自行脑补约束。拆解的目标是生成“可检查的初始帧”而不是“完美计划”。后续执行中用户可能会追加信息只要 Harness 允许以版本化方式更新帧就是合理的。5.2 实现 Harness 主循环骨架整个 AutoDesign 控制核心在 Harness 类里。下面给出一个结构完整且可扩展的循环class AutoDesignHarness: def __init__(self, llm_client, snapshot_store, trace_store): self.llm llm_client self.snapshots snapshot_store self.trace trace_store self.max_steps 40 self.validation_interval 3 self.rollback_threshold 1 def run(self, requirement_frame: RequirementFrame) - ExecutionSnapshot: current_rf requirement_frame snapshot self._initial_snapshot(current_rf) violations_streak 0 for step_index in range(self.max_steps): if self._is_terminal(snapshot): self._record_terminal(snapshot) return snapshot plan_node self._select_next_node(snapshot, current_rf) if plan_node is None: break action self._decide_action(snapshot, plan_node) new_snapshot, error self._execute_action(snapshot, action) self._persist_trace(snapshot, action, new_snapshot, error) if error is not None: violations_streak 1 else: violations_streak 0 snapshot new_snapshot if step_index % self.validation_interval 0: report self._validate_against_requirements(snapshot, current_rf) if report.has_blocking_violations(): snapshot self._rollback_to_latest_valid(snapshot) violations_streak 1 if violations_streak self.rollback_threshold: snapshot self._rollback_and_change_strategy(snapshot) violations_streak 0 return snapshot这个循环有四个关键点执行前有_select_next_node决定下一步推进哪个目标而不是让模型自由发挥执行后有快照对比和轨迹记录每隔固定步数执行一次目标一致性验证连续失败触发回滚并切换策略。想立刻开始的读者不要觉得它简单这套循环已经能覆盖大多数长周期 Agent 失控问题。5.3 快照存储与回滚逻辑快照不能只存在内存里否则系统中途重启就无法恢复。用文件或数据库做快照存储class FileSnapshotStore: def __init__(self, base_dir: str): self.base_dir Path(base_dir) self.base_dir.mkdir(parentsTrue, exist_okTrue) def save(self, snapshot: ExecutionSnapshot) - str: path self.base_dir / f{snapshot.snapshot_id}.json path.write_text(snapshot.model_dump_json(indent2), encodingutf-8) return snapshot.snapshot_id def load(self, snapshot_id: str) - ExecutionSnapshot: path self.base_dir / f{snapshot_id}.json data json.loads(path.read_text(encodingutf-8)) return ExecutionSnapshot.model_validate(data)回滚逻辑要注意粒度问题。最简单的回滚是回到上个快照但这可能丢掉有效的进展。推荐记录“快照分支”当一个验证失败发生时Harness 读取失败记录找到导致失败的那一步然后回到该步之前的快照并把失败尝试存进轨迹。def rollback_to_snapshot(snapshot_store, trace_store, snapshot_id): snapshot snapshot_store.load(snapshot_id) trace_store.rollback_log.append({ event: rollback, target_snapshot: snapshot_id, reason: blocking_violation }) return snapshot生产项目中回滚建议配合人工审查确认自动回滚可能选错基线尤其是在设计任务的早期过多自动回滚会导致系统无法推进。可以先用“警告并暂停”策略观察一段时间后再开放自动回滚。5.4 实现一个极简 Meta-Optimizer 示例Meta-Optimizer 不需要一上来就做成强化学习系统它可以从规则策略开始。核心思想是根据执行轨迹选择下一轮任务使用的 Harness 策略。先定义 HarnessPolicyclass HarnessPolicy(BaseModel): validation_interval: int rollback_threshold: int use_plan_first: bool max_draft_length: int context_summary_mode: str Field(defaultembed_requirements)然后定义一个基于轨迹事件的优化器class SimpleMetaOptimizer: def __init__(self, policies: List[HarnessPolicy]): self.policies policies self.history [] def register_trace(self, trace_records, final_status): self.history.append({ trace: trace_records, status: final_status }) def propose_next_policy(self, current_policy: HarnessPolicy) - HarnessPolicy: recent_failures [h for h in self.history[-5:] if h[status] FAILED] if not recent_failures: return current_policy drift_failures sum( 1 for h in recent_failures if self._has_drift_event(h[trace]) ) if drift_failures 2: return HarnessPolicy( validation_interval1, rollback_threshold1, use_plan_firstTrue, max_draft_length500, context_summary_modestrict_requirement_check ) return current_policy从工程角度看这个 Optimizer 已经体现了 Meta 层的核心它不是在 Prompt 层面修补而是在本轮任务结束后调整下一轮任务的验证频率、回溯阈值和上下文组织方式。如果你有更多的历史数据可以把register_trace的数据接入离线评估逻辑用准确率指标来决定是否采用某个新策略。5.5 接入真实模型和设计工具上面的代码保留了llm_client抽象。真实接入时建议把模型调用封装成统一方法class OpenAIClient: def __init__(self, api_key, modelgpt-4o-mini): self.client OpenAI(api_keyapi_key) self.model model def complete(self, system_prompt, user_prompt, response_formatNone, temperature0.2): kwargs { model: self.model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: temperature, } if response_format json: kwargs[response_format] {type: json_object} resp self.client.chat.completions.create(**kwargs) return resp.choices[0].message.content注意在 Long-Horizon 任务里temperature 不要设得过高。设计任务虽然需要探索但 Harness 已经承担了探索机制模型的单步输出更应当稳定、可预期、符合 JSON 结构。探索交给系统层在不同方案之间的选择不要交给单次生成时随机性。5.6 主流程入口示例最后用main.py把它们串起来from core.requirements import parse_requirement_from_task from core.harness import AutoDesignHarness from core.meta import SimpleMetaOptimizer from core.state import FileSnapshotStore from core.llm import OpenAIClient def main(): llm OpenAIClient(api_keyyour-key) snapshots FileSnapshotStore(./data/snapshots) optimizer SimpleMetaOptimizer(policies[]) task_text 为一个中小型仓库设计低成本的库存预警系统 rf parse_requirement_from_task(task_text, llm) harness AutoDesignHarness(llm, snapshots, trace_store) final_snapshot harness.run(rf) optimizer.register_trace(harness.trace.records, final_snapshot.status) print(final_snapshot.model_dump_json(indent2)) if __name__ __main__: main()6. 运行验证从“能跑”到“能判断有没有变好”6.1 用一组任务池验证而不是单条任务长周期 Agent 最忌讳用一两条任务判断效果。你至少要准备五到十条覆盖不同领域的设计任务。下面是一个示例任务池实际项目可以替换成你自己的场景任务 ID任务描述主要难点期望轮次T1设计仓库库存预警系统多约束、需要权衡成本与准确率15T2设计一个内部员工请假审批流程涉及角色矩阵与异常分支12T3为二手交易平台设计订单争议仲裁方案需要多轮方案修改25T4设计一个数据分析报表的多租户权限模型安全规则复杂容易遗忘约束20T5为一个智能家居 App 规划冷启动推荐策略无明显正确答案需要评估探索30每个任务都需要提前写清楚“人工评价关注点”。这一条在开始实验前就要做否则任务跑完后你只能凭感觉判断结果无法给出可复现的对比。6.2 关键指标不只看最终成功率只看最终成功率的坏处是一个最终结果勉强合格、但中间出现多次无效绕路的系统和一个高效收敛的系统在成功率上可能完全相同。所以 AutoDesign 实验至少要记录以下指标里程碑达成率规划阶段拆解出的关键节点有多少被实际完成。约束遗忘次数执行过程中发现有多少条原始约束被违反。方向一致率人工评估每轮中间产物时有多少步骤仍然与目标相关。无效步骤占比执行轨迹中被回滚或最终未使用的步骤数量占总步骤的比例。平均偏离轮数系统第一次产生需求外内容到被纠正之间的轮次间隔。指标计算方式说明里程碑达成率达成节点数 / 计划节点数判断任务是否推进完整约束遗忘次数统计验证阶段触发的遗忘失败判断需求管理是否稳定无效步骤占比回滚步骤数 / 总步骤数判断决策质量和回溯策略平均偏离轮数偏离开始到纠正的轮数均值判断控制循环敏感度6.3 运行过程中的观察与检查点任务执行过程中需要留下可以回看的结构化数据。执行结束后除了看最终产物还要打开轨迹文件从事件流中复盘这两个问题第一次偏离发生在第几步当时的快照内容是什么。触发回滚时选择的回滚点是否正确有没有把有效进展一起丢弃。建议在日志里额外生成本地 JSON 快照方便用 Python 脚本批量分析python scripts/analyze_trace.py --log logs/trace.jsonl \ --metric constraint_forgetting \ --requirement data/tasks.yaml如果一段时间后系统的约束遗忘次数下降但无效步骤占比上升说明验证器变得过度敏感Harness 频繁打断有效执行。这时需要调大validation_interval或者优化验证器的判断条件。7. 常见问题与排查链路7.1 任务进行到后期输出明显偏离原始需求现象前几轮还按照需求文档推进十轮之后开始出现与原始目标无关的设计内容甚至用通用模板覆盖了特定约束。可能的根因有三个需求帧没有在后续提示中持续出现验证器只在固定步数触发没能在偏离早期发现问题上下文被工具输出和中间方案挤占模型忘记了原始约束。排查顺序先检查需求帧在每轮提示词中是完整透传还是已经被摘要替代。再检查验证器是从哪个快照开始判定“一致”的如果它自己也使用被污染上下文就会失去参考价值。解决思路把RequirementFrame里最核心的 acceptance_criteria 单独拼到每轮用户提示词末尾把执行步骤与需求节点的关联记录下来在每轮循环前插入一次轻量一致性检查如果当前输出违反了任一验收标准立即触发回滚。注意验证器必须依赖独立状态区中的 RequirementFrame不能使用模型上一步生成的总结来判断是否偏离否则会出现“错误被另一层错误掩盖”的情况。7.2 Harness 本身成了执行瓶颈响应延迟和 token 成本明显升高现象Harness 引入后每个步骤都要额外做验证还要写多条结构化状态任务没变复杂耗时长了一倍。先观察轨迹日志中的 token 分布确认额外成本主要来自哪一类系统调用。如果是每轮都重新把完整需求帧、完整方案快照、全部历史摘要拼进上下文成本必然会高。优化方向有几个快照摘要可以分层顶层只保留当前方案版本、下一步候选、未完成的约束列表细节放到二级块中按需读取验证不是每步都调用大模型可以先做关键词级和规则级检查通过后再调用模型做深度一致性判断回滚不需要立刻执行模型完整重规划可以先用离线路由选择一条已缓存的候选策略。经验上Harness 对长周期任务的额外开销如果在 20% 到 35% 之间属于正常范围。如果超过 50%优先检查是否重复加载上下文和是否每步都做了“不必要的全量验证”。7.3 快照回滚把有效进展一起丢掉了现象系统检测到一个失败后自动回滚结果任务退回到很早期的空状态前几轮已经完成的有效设计被当成无效内容抛弃。原因通常是快照粒度设置得太粗。整个状态分区只有“初始、中期、最终”三个快照回滚时无法定位到具体失败转折点。另一个常见原因是回滚策略写成了无条件回到上个 checkpoint而没有判断失败是否发生在当前步骤生成的内容中。解决方式把快照粒度细化到每个“目标节点完成点”并在每个快照里保存已满足需求的标记。回滚优先寻找最近的“包含当前需求节点且未违反约束”的快照而不是简单的上一份。如果没有任何快照满足条件再降级到人工暂停等待处理。7.4 Meta-Optimizer 不收敛同一类失败反复出现现象优化器运行多轮后系统还是会在相似位置失败控制策略没有被真正改变。排查时先检查优化器修改的字段是否真的进入下一轮执行。常见问题是把新的 HarnessPolicy 存到了某个配置对象但 Harness 初始化时读取的是默认参数。再检查轨迹记录是否足够完整优化器能不能定位到失败环节。比如轨迹只记录了“最终失败”没有记录失败前第几步出现偏离优化器就无法确定该调大验证频率还是该修改上下文组织方式。最后一类是过拟合问题优化器在单条任务上调参导致换一条任务后效果更差。建议增加任务池数量并且把优化器策略改动先离线回放到历史轨迹上验证成功率后再上线。7.5 Base Agent 输出不符合 JSON 结构导致状态解析失败现象状态写入时报错字段缺失或类型错误系统在某一步直接中断。排查顺序先看模型被要求输出的 JSON schema 和解析代码中的 pydantic 模型是否一致字段名不匹配是最常见问题。再检查是否对模型输出做了格式兜底例如去掉多余前后缀、修复未闭合 JSON最后检查出错时有没有进入重试循环如果没有状态快照能否恢复。解决建议在 LLM 调用层统一使用 response_format 约束同时提供异常输出重试机制解析不到合法 JSON 时不要使用模糊替换而是记录原始输出并请求模型重新输出。pydantic 模型的字段命名建议全部使用 snake_case避免输出格式里出现大小写不一致导致的解析失败。问题现象常见原因检查方式解决建议后期偏离原始需求需求帧未持续对齐验证频度低检查每轮 prompt 是否注入验收标准缩短验证间隔独立保存需求帧token 成本过高每轮拼入完整历史和完整快照查看轨迹日志中的输入 token 变化引入分层摘要按需读取详情回滚丢失有效进展快照粒度太粗或回滚点选择错误检查回滚目标是否包含有效约束标记细化快照节点分布并增加约束标记错误反复出现Meta 策略未生效或过拟合检查下一轮 Harness 读取的策略对象修正配置读取链路引入任务池评估8. 生产落地清单与后续方向8.1 把 AutoDesign 思路带入现有 Agent 项目的渐进路径如果团队已经有一个能跑通短任务的 Agent 系统不需要一次性推倒重来。推荐分三步演进第一步加入状态快照和执行轨迹记录。不改动模型调用逻辑只把每一步输入输出存成结构化文件。这一步投入很小但立刻让系统具备了可观测性后续分析问题有依据。第二步加入验证和回滚机制。不要立刻把验证器接到每一轮可以先选择高风险阶段做插入式验证把失败的下一步记录下来然后人工判断回滚点。这一步主要是验证“失败是否可以被自动捕获”。第三步再加入 Meta-Optimizer。先使用简单的规则策略根据上几轮失败事件自动选择验证频率和回溯阈值。如果业务数据足够再逐步引入离线评估和策略搜索。很多人会想直接做第三步但缺少前两步的轨迹数据时优化器没有可靠的输入只会变成又一层黑盒这是落地时最常见的误区。8.2 生产环境发布前要检查的事项发布到生产环境前至少要做一次完整检查需求帧是否支持版本化变更用户的追加需求是否会污染已冻结的基线。快照是否有独立存储保存频率是否经过权衡恢复后能不能完整还原上下文。执行轨迹是否包含每个步骤的快照 ID、模型输出摘要、工具调用参数和错误信息能否支持事后审计。验证器使用的是什么参考源是否独立于模型主提示词。自动回滚是否设置了人工确认开关是否需要分级策略提示警告、半自动回滚、全自动回滚。Meta-Optimizer 每次策略变更是否记录版本新策略上线前是否能回滚到旧策略。检查项学习环境标准生产环境标准快照保存文件系统即可独立存储并定期备份轨迹记录本地 JSONL接入中央日志系统并设置保留策略回滚动作自动回滚分级控制高风险任务人工确认Meta 策略上线直接替换版本化并支持灰度切换资源观测人工查日志指标监控与告警8.3 明确 AutoDesign 思路的适用边界这类系统不是适合所有 Agent 场景。如果一个任务只需要单步问答或者任务本身执行完全不可观测外部工具无法留下稳定的结构化反馈那么 AutoDesign 的额外控制层可能得不偿失。适合的场景包括技术架构设计、产品需求评审、数据模型设计、复杂页面信息架构设计、需要多次修改和验证的中长文本方案生成。系统需要具备至少两个前提任务可以拆解成可检查的节点每一步的产物可以被验证器或人工判断执行过程允许有时间做多轮循环不会因为自动回滚造成不可接受的延迟。相反如果任务只是“翻译一句话”或“给出一段摘要”引入长周期控制层会让问题复杂化。Meta-Optimization 的价值来自复杂度路径越复杂、失败越频繁、回顾成本越高它的收益才越明显。8.4 给后续实验和工程实践的建议AutoDesign 这类方法论最值得学习的不是某个具体参数而是它把“系统控制”从“模型输出”中分离出来的思路。面对长周期任务时不要默认把所有问题推给大模型先思考你的外层系统能不能回答三个问题当前状态是什么、当前目标是什么、现在离目标还有多远。给新手的实践建议是先拿五个你熟悉的业务任务手工设计状态快照字段和执行轨迹格式不接入模型用人工执行的方式跑一遍模拟流程。等你能清楚回答上面三个问题后再接入 Base Agent。你会发现 Harness 的结构其实是在帮助你把不可控的长周期执行变得像一系列可审计、可恢复的短周期执行而 Meta 层则让这套控制逻辑能够在任务完成之后持续变好。真正把 AutoDesign 做进生产项目时持续观察的重点也不只是准确率还有每一步失败模式的分布是否在变小。一个稳定长周期 Agent 系统的标志并不是从来没有失败而是失败发生时Harness 能准确知道它发生在了哪里、为什么发生、以及下一次如何通过策略调整规避同类问题。