Agent 会话状态设计：上下文不是越长越聪明

Agent 应用很容易把会话历史越塞越长：用户说过的话、工具返回、模型思考、错误重试、检索结果，全都往上下文里堆。短期看，模型似乎更“记得住”；长期看，成本升高、噪声增多、关键约束反而被淹没。上下文不是越长越聪明，状态设计才是 Agent 稳定性的基础。

Agent 会话状态要把任务目标、短期上下文、长期记忆和工具状态分开。

一、深度引言与场景痛点

flowchart TD
A[Conversation] –> B[Task State]
A –> C[Short Context]
A –> D[Memory]
A –> E[Tool State]

任务状态记录当前要完成什么、进度到哪里、下一步是什么。短期上下文记录本轮对话需要的信息。长期记忆记录用户偏好和稳定事实。工具状态记录外部操作结果、文件路径、任务 ID 等。不同状态生命周期不同，不能混在一段聊天历史里。

如果所有东西都塞进 prompt，模型需要自己判断什么重要。工程系统应该先替它整理好状态，让模型处理真正需要推理的部分。

二、底层机制与原理深度剖析

{
"goal": "generate_report",
"phase": "collecting_data",
"completed_steps": ["read_metrics"],
"pending_steps": ["write_summary"]
}

结构化任务状态比自然语言总结更稳定。模型可以根据状态继续执行，系统也能判断是否卡住、是否重复、是否已经完成。尤其是多步骤 Agent，状态机比聊天记录可靠。

状态结构不必复杂，但字段要清楚。目标、阶段、已完成步骤、待处理步骤、阻塞原因、外部资源 ID，这些足以支撑大多数工作流。

三、生产级代码实现

compress:
keep_constraints
keep_decisions
drop_failed_attempt_details

长会话必须压缩。压缩不是简单摘要，而是保留约束、决策、用户确认和当前状态，丢弃无效尝试和重复解释。失败细节可以写进日志，不一定继续喂给模型。

压缩结果要可审计。系统应该知道摘要来自哪些消息，必要时能回看原文。否则摘要错了，后面所有回答都会跟着跑偏。

四、边界分析与架构权衡

tool_state:
file_id: "f_1024"
job_id: "job_889"
status: "running"

工具调用产生的状态要由系统保存。文件 ID、任务 ID、外部订单号、检索结果版本，都不应该只存在模型上下文里。模型可以引用它们，但系统要负责真实状态。

这样做也方便恢复。页面刷新、模型重试、服务重启后，Agent 仍然能从系统状态继续，而不是让用户重新描述一遍。

会话状态还要有过期策略。临时工具结果可以几小时后清理，长期偏好需要用户确认，任务状态完成后要归档。没有过期策略，状态库会越来越大，模型也可能把旧任务误认为当前任务。

多轮对话中，还要区分“用户刚刚改变了目标”和“用户只是补充条件”。目标变化时应重置部分计划，补充条件时只更新约束。这个判断可以由模型辅助，但系统状态机要记录变化原因，方便后续复盘。

状态模型还需要版本化。上线初期只有 phase 和 steps，后续可能加入预算、权限、引用证据和人工确认字段。如果没有 state_version，旧会话恢复时就会出现字段缺失、语义变化和错误迁移。比较稳的做法是给状态定义迁移函数，并在恢复会话前完成结构升级。迁移失败时宁可让用户确认关键约束，也不要把旧状态硬塞给新的 Agent 流程。

五、总结

Agent 会话状态设计要区分任务状态、短期上下文、长期记忆和工具状态。上下文要压缩，任务要结构化，工具状态要由系统保存。

Agent 聪明不靠记住所有话，而靠在正确时间拿到正确状态。

Agent 会话状态设计：上下文不是越长越聪明