Agent 状态管理：上下文不是随手塞进 Prompt

一、Agent 失控很多时候不是模型问题

AI Agent 做复杂任务时，最容易被忽略的是状态管理。很多实现把历史对话、工具结果、用户偏好、任务进度全部塞进 Prompt，觉得上下文越完整越安全。实际生产里，这会让输入膨胀、成本飙升、关键信息被稀释，还会把过期状态继续带到下一轮决策里。

Agent 不是一个更长的聊天框，而是一个会读取状态、执行动作、更新状态的系统。状态如果没有结构，模型就会在旧信息、新信息和推测之间来回跳。任务越长，越容易出现重复执行、漏掉约束、误用旧结果的问题。

二、状态要分层，而不是全部混在一起

一个可维护的 Agent 状态通常至少分成四层：任务目标、执行计划、工具结果和运行记忆。

flowchart TD
  A[用户目标] --> B[任务状态]
  B --> C[计划步骤]
  C --> D[工具调用结果]
  D --> E[短期运行记忆]
  E --> F[下一步决策]
  F --> C

任务目标是稳定约束，不应该频繁改写；计划步骤是可变结构，可以暂停、重试和跳过；工具结果要保留来源、时间和可信度；运行记忆只保留当前决策需要的信息。把这些混成一段自然语言，会让后续维护非常痛苦。

三、状态结构要能被程序校验

下面是一个简化状态结构。重点不是字段多，而是每个字段都有明确用途。

type AgentState = {
  goal: string;
  currentStep: string;
  completedSteps: string[];
  toolResults: Array<{
    tool: string;
    ok: boolean;
    summary: string;
    createdAt: string;
  }>;
  constraints: string[];
};

function canContinue(state: AgentState) {
  return state.goal.length > 0 && state.currentStep.length > 0;
}

结构化状态可以做校验、压缩、审计和回放。自然语言状态只能靠模型自己理解，一旦任务失败，很难判断是模型推理错了，还是状态传错了。

四、上下文压缩要保留决策依据

Agent 跑得久了，状态一定要压缩。压缩不是简单摘要，而是把对后续决策有用的信息留下。比如工具返回的完整日志可以归档，进入 Prompt 的只需要错误类型、影响范围和下一步建议。

还要标记状态的新旧。一个工具结果两小时前有效，不代表现在仍然有效。缓存数据、外部接口返回、环境状态都要带上时间戳。没有时间概念的 Agent，很容易用旧结果做新决策。

失败状态也不能丢。重试过几次、失败原因是什么、是否已经人工介入，这些信息会影响下一步策略。如果每次失败都像第一次失败，Agent 会在同一个坑里循环。

最后，状态更新要有原子性。工具调用成功后再写入结果，失败时写入失败状态，不要出现“动作执行了但状态没记录”的中间态。否则回放和补偿都会变得不可信。

状态还要区分事实和推断。工具返回的数据、用户明确给出的限制，属于事实；模型根据上下文猜出的下一步，属于推断。事实可以长期保留，推断要带置信度和失效条件。很多 Agent 事故不是没有信息，而是把推断当成事实继续传播。

多 Agent 协作时，状态边界更重要。每个 Agent 只应该读自己需要的状态片段，写入时也要经过统一协调层。否则多个执行者同时修改计划，很容易出现步骤重复、结果覆盖和责任不清。

五、总结

Agent 状态管理的核心是把上下文从一段 Prompt 变成可校验、可压缩、可审计的运行数据。目标、计划、工具结果和运行记忆要分层保存。上下文不是越多越好，能支持下一步正确决策才是重点。