3 State Engineering：用结构化状态保存 Agent 进度

查看大图

Goal 解决“要去哪里”，State 解决“现在走到哪里”。如果没有 State，Agent 每一步都要从历史里猜进度；如果 State 太乱，Agent 会把噪音当成事实。

State Engineering 的核心不是把所有历史都保存下来，而是把任务当前需要的事实、决策、产物、阻塞和下一步保存成结构化状态。它像项目管理里的看板，也像程序里的运行时对象。

很多 Agent 失败，是因为它只有聊天记录，没有状态。聊天记录里确实有信息，但信息散在几十轮里，优先级也不清楚。State 的价值，就是把“有用的当前截面”提炼出来。

1. State 不是 Transcript

查看大图

Transcript 是完整过程，State 是当前摘要。完整过程适合审计，当前摘要适合继续执行。一个 Harness 可以保存完整日志，但喂给模型时，通常只需要短状态。

比如调研一个模型时，State 不需要保存每个网页的完整内容，只需要保存：已读哪些来源、确认了哪些事实、还有哪些问题没确认、下一步要查什么。

2. 一个实用 State Schema

最小状态可以这样设计：topic 表示当前主题，finished 表示已完成步骤，todo 表示待办，decisions 表示已经做出的选择，artifacts 表示已经生成的文件或链接，blockers 表示阻塞，next_action 表示下一步。

如果任务涉及工具调用，还可以加 observations_summary，专门保存工具返回结果的摘要。注意是摘要，不是完整输出。完整输出留在日志里，摘要进入 State。

3. 状态更新要发生在观察之后

查看大图

一个常见错误是 Planner 刚列完计划，就把所有步骤都当作“将会完成”。更稳的做法是：执行一步，拿到观察结果，再更新 State。完成就进入 finished，没完成就保留在 todo 或 blockers。

状态要反映事实，而不是愿望。这样下一轮模型看到 State 时，才不会误以为任务已经推进。

4. State 要控制体积

查看大图

State 太短会丢信息，太长又会重新变成噪音上下文。我的经验是，State 应该能在 30 秒内被人读完，并且能回答三个问题：现在目标是什么，已完成什么，下一步是什么。

长期有价值的信息不要一直堆在 State 里，可以沉淀到 Memory。临时工具输出不要一直堆在 State 里，可以留在日志或 artifact。

5. 本节练习

查看大图

把下面这份结构复制到你的任务里，先手动维护三轮：

{
  "goal": "写一篇 Harness Engineering 教程",
  "finished": ["确定主题"],
  "todo": ["写大纲", "补图", "复核"],
  "decisions": ["用中文教程风格"],
  "artifacts": [],
  "blockers": [],
  "next_action": "写第一版大纲"
}

下一节我们把 State 接到 Planner 和 Executor 上，让 Agent 不只是记住进度，还能按进度一步一步做事。

查看大图