企业官网建设流程全解析

在 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 完成，但方向盘、刹车、回放记录这些控制机制，要由外层系统掌握。

2. 先理解 AutoDesign 的核心：Meta-Harness Optimization

2.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 拆分节点，在偏离高风险阶段插入频繁目标校验。系统不是绑定某一种决策模式，而是具备选择、组合并优化这些模式的能力。

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 pydantic==2.* 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.jsonl

core/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(default=False, 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。这里用一个轻量的 parser：

def 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_format="json") data = json.loads(response) design_req = DesignRequirement(**data) return RequirementFrame( requirement_id=uuid4().hex[:8], raw_text=task_text, design_requirement=design_req, frozen=False )

这一步很容易踩坑。不要试图在第一轮拆解时就把需求做到绝对完整，更不要用模型自行脑补约束。拆解的目标是生成“可检查的初始帧”，而不是“完美计划”。后续执行中用户可能会追加信息，只要 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(parents=True, exist_ok=True) def save(self, snapshot: ExecutionSnapshot) -> str: path = self.base_dir / f"{snapshot.snapshot_id}.json" path.write_text(snapshot.model_dump_json(indent=2), encoding="utf-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(encoding="utf-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 策略。

先定义 HarnessPolicy：

class HarnessPolicy(BaseModel): validation_interval: int rollback_threshold: int use_plan_first: bool max_draft_length: int context_summary_mode: str = Field(default="embed_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_interval=1, rollback_threshold=1, use_plan_first=True, max_draft_length=500, context_summary_mode="strict_requirement_check" ) return current_policy

从工程角度看，这个 Optimizer 已经体现了 Meta 层的核心：它不是在 Prompt 层面修补，而是在本轮任务结束后调整下一轮任务的验证频率、回溯阈值和上下文组织方式。如果你有更多的历史数据，可以把register_trace的数据接入离线评估逻辑，用准确率指标来决定是否采用某个新策略。

5.5 接入真实模型和设计工具

上面的代码保留了llm_client抽象。真实接入时建议把模型调用封装成统一方法：

class OpenAIClient: def __init__(self, api_key, model="gpt-4o-mini"): self.client = OpenAI(api_key=api_key) self.model = model def complete(self, system_prompt, user_prompt, response_format=None, temperature=0.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_key="your-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(indent=2)) if __name__ == "__main__": main()

6. 运行验证：从“能跑”到“能判断有没有变好”

6.1 用一组任务池验证，而不是单条任务

长周期 Agent 最忌讳用一两条任务判断效果。你至少要准备五到十条覆盖不同领域的设计任务。下面是一个示例任务池，实际项目可以替换成你自己的场景：

每个任务都需要提前写清楚“人工评价关注点”。这一条在开始实验前就要做，否则任务跑完后你只能凭感觉判断结果，无法给出可复现的对比。

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，避免输出格式里出现大小写不一致导致的解析失败。

8. 生产落地清单与后续方向

8.1 把 AutoDesign 思路带入现有 Agent 项目的渐进路径

如果团队已经有一个能跑通短任务的 Agent 系统，不需要一次性推倒重来。推荐分三步演进：

第一步，加入状态快照和执行轨迹记录。不改动模型调用逻辑，只把每一步输入输出存成结构化文件。这一步投入很小，但立刻让系统具备了可观测性，后续分析问题有依据。

第二步，加入验证和回滚机制。不要立刻把验证器接到每一轮，可以先选择高风险阶段做插入式验证，把失败的下一步记录下来，然后人工判断回滚点。这一步主要是验证“失败是否可以被自动捕获”。

第三步，再加入 Meta-Optimizer。先使用简单的规则策略，根据上几轮失败事件自动选择验证频率和回溯阈值。如果业务数据足够，再逐步引入离线评估和策略搜索。

很多人会想直接做第三步，但缺少前两步的轨迹数据时，优化器没有可靠的输入，只会变成又一层黑盒，这是落地时最常见的误区。

8.2 生产环境发布前要检查的事项

发布到生产环境前，至少要做一次完整检查：

• 需求帧是否支持版本化变更，用户的追加需求是否会污染已冻结的基线。
• 快照是否有独立存储，保存频率是否经过权衡，恢复后能不能完整还原上下文。
• 执行轨迹是否包含每个步骤的快照 ID、模型输出摘要、工具调用参数和错误信息，能否支持事后审计。
• 验证器使用的是什么参考源，是否独立于模型主提示词。
• 自动回滚是否设置了人工确认开关，是否需要分级策略：提示警告、半自动回滚、全自动回滚。
• Meta-Optimizer 每次策略变更是否记录版本，新策略上线前是否能回滚到旧策略。

8.3 明确 AutoDesign 思路的适用边界

这类系统不是适合所有 Agent 场景。如果一个任务只需要单步问答，或者任务本身执行完全不可观测，外部工具无法留下稳定的结构化反馈，那么 AutoDesign 的额外控制层可能得不偿失。

适合的场景包括：技术架构设计、产品需求评审、数据模型设计、复杂页面信息架构设计、需要多次修改和验证的中长文本方案生成。系统需要具备至少两个前提：任务可以拆解成可检查的节点，每一步的产物可以被验证器或人工判断；执行过程允许有时间做多轮循环，不会因为自动回滚造成不可接受的延迟。

相反，如果任务只是“翻译一句话”或“给出一段摘要”，引入长周期控制层会让问题复杂化。Meta-Optimization 的价值来自复杂度：路径越复杂、失败越频繁、回顾成本越高，它的收益才越明显。

8.4 给后续实验和工程实践的建议

AutoDesign 这类方法论最值得学习的不是某个具体参数，而是它把“系统控制”从“模型输出”中分离出来的思路。面对长周期任务时，不要默认把所有问题推给大模型，先思考你的外层系统能不能回答三个问题：当前状态是什么、当前目标是什么、现在离目标还有多远。

给新手的实践建议是：先拿五个你熟悉的业务任务，手工设计状态快照字段和执行轨迹格式，不接入模型，用人工执行的方式跑一遍模拟流程。等你能清楚回答上面三个问题后，再接入 Base Agent。你会发现 Harness 的结构其实是在帮助你把不可控的长周期执行变得像一系列可审计、可恢复的短周期执行，而 Meta 层则让这套控制逻辑能够在任务完成之后持续变好。

真正把 AutoDesign 做进生产项目时，持续观察的重点也不只是准确率，还有每一步失败模式的分布是否在变小。一个稳定长周期 Agent 系统的标志并不是从来没有失败，而是失败发生时，Harness 能准确知道它发生在了哪里、为什么发生、以及下一次如何通过策略调整规避同类问题。