Agent 的“状态工程”到底在解决什么?
上下文窗口保存的是一次推理要读取的内容,不能自动成为项目的权威状态。代码是否已经修改、测试是否刚刚失败、部署是否获得批准,都要以外部环境为准。Agent 每次行动前都要重新读取当前工作树、测试状态和审批记录。
所谓 State Engineering,如果这个名称最终成立,应该解决一个具体问题:怎样从事件记录和真实环境中重建此刻有效的状态,再把当前决策需要的部分交给模型。它不是给聊天摘要换一个名字。
能完成更长任务,不等于能稳定交付
如果近年的趋势延续,模型可完成的任务长度还会增长。METR 对 2019 至 2025 年模型的研究估计,软件任务的 50% 成功率时间跨度大约每 207 天翻一倍。2026 年更新页面仍在追踪同一指标。不过,原论文还报告:80% 成功率对应的时间跨度约短五倍,模型在结构较乱、验收不清的任务上表现更差。这个历史趋势不能直接外推成未来定律,却指出了一个会长期存在的分化:模型能够偶尔完成更长任务,不等于它已经能稳定交付同样长的任务。
下一阶段不能只靠扩大上下文窗口。完整事件记录需要保存在窗口外。每次推理前,系统从当前工作树、最新测试结果和已经确认的决定中选择与下一步有关的事实,组成一份状态视图。
状态视图不是聊天摘要
聊天摘要压缩“过去发生过什么”;状态视图描述“哪些事实此刻仍然有效,以及当前决策需要知道什么”。例如,Agent 判断一个补丁能否交付时,需要看到当前 commit、验收条件、最近一次测试结果和尚未解决的阻塞项;早期搜索日志通常只需保留证据位置。同一份事件记录用于排查报错和准备部署时,会产生不同的状态视图。
状态视图可以用知识图谱实现,但两者不在同一层。知识图谱保存实体及其关系;状态视图则是针对某个时间点和决策目标生成的查询结果。状态视图也可以来自 Git、数据库或测试系统,最后以 JSON 或一段短文本交给模型。
| 对象 | 它回答的问题 | 常见形态 |
|---|---|---|
| 事件日志 | 发生过什么 | 按时间追加的消息、工具调用和状态变更 |
| 知识图谱 | 哪些实体存在关系 | 实体、边和属性 |
| 当前状态 | 现在什么为真 | 工作树、数据库记录、权限和最新测试结果 |
| 状态视图 | 下一项决策需要知道哪些当前事实 | 从当前状态投影出的临时输入 |
图谱、文件和多 Agent 只是不同实现
一项图记忆预印本把 Agent 轨迹抽象成状态机中的决策路径,并报告这种表示在其任务上的收益。这说明图可以承载一部分状态和经验,不说明所有状态都应该进入图。当前进程是否存活、某次测试刚刚失败、一次部署是否已经获得批准,通常直接从对应系统读取更可靠。把所有信息图谱化,也会重新引入同步和过期问题。
把长期记录移到窗口外,来自一个直接约束:有限窗口无法同时承担永久记录和当前决策,而且压缩是有损的。Anthropic 公开的 Managed Agents 架构把 session 日志与 Claude 的上下文窗口分开,说明这种实现已经存在;公开材料没有证明该架构优于所有替代方案。
文件系统很可能承担代码存储之外的角色,成为 Agent 的长期状态接口。2026 年预印本《Coding Agents are Effective Long-Context Processors》让 coding agent 使用文件和终端处理超大语料,在多项 benchmark 上平均超过既有最好结果 17.3%,处理的语料规模最高达到三万亿 token。这个结果尚未经过正式同行评审,任务也不等于软件开发;实验仍然提示了一条清楚的路线:让 Agent 通过文件索引、程序和查询按需处理信息,可能比把所有内容直接塞入注意力窗口更有效。
无论长期状态保存在图谱还是文件中,记录都需要更明确的结构。未来的进度文件不会只是一段摘要,而会区分已验证事实、当前假设和待执行决定。每条记录需要来源,过期状态需要失效机制,写入长期记忆前还要经过 evaluator。ACL 2026 的记忆实验已经说明无条件积累经验会降低表现;下一步的研究重点应从“能否记住”转向“什么有资格被记住”。
多个 Agent 共享状态时,重点也可能从增加并行数量转向划清状态边界。一个子代理可以自由搜索数万 token,只把证据和结论写回共享 workspace,主代理不必看到全部过程。AiScientist 的 2026 年预印本把这种设计称为 File-as-Bus:控制层只保留阶段摘要,代码和实验记录留在持久工作区。去掉 File-as-Bus 后,PaperBench 平均下降 6.41 分,MLE-Bench Lite 的 Any Medal 指标下降 31.82 个百分点。这仍是一套特定研究工程系统的结果,不能证明多 Agent 普遍更好;实验能够证明的范围是,多个角色在这套系统中需要围绕同一份可检查状态协作,不能只靠层层转述。
可靠性需要独立预算
验证层可能比生成层获得更多系统预算。现在的 benchmark 常用一次通过率衡量能力,生产系统更关心同一任务重复运行是否稳定,输入轻微变化时是否仍能工作,失败后能否预测影响并回退。ICML 2026 的 Agent 可靠性研究用十二项指标检查十四种 Agent,发现近期能力增益只带来了较小的可靠性改善。包含故障识别、状态恢复和适时放弃的轨迹可能更有训练价值;现有评测尚不能证明厂商会采用这条路线。
验证层负责检查行动后的状态,用户消息则会在行动前改变状态。未来的交互可能不再是一条无类型的聊天流,而会分成不同作用域的控制信号:补充约束修改当前规格,旁支问题进入 side channel,目标变化触发新计划,高风险动作停在批准门槛前。Codex 已有 Steer、Queue、Side 和 Goal 等不同入口,这只能证明某个产品已经采用分流接口。预测本身来自消息语义不同:修改需求和询问背景会造成不同的状态变化,把它们都无类型地追加到同一历史,系统就只能依靠模型临时猜测作用域。
新名称必须对应可测的工程增益
新词通常出现在瓶颈转移以后。Prompt engineering 流行时,稀缺能力是让模型按要求输出。模型的基础能力提高后,失败更多来自它看到了什么、系统保存了什么,以及一次行动是否越过权限。工程团队需要为这些问题划预算,投资叙事便会把一个实现部件扩成独立品类。
2026 至 2029 年的趋势判断关注这些工程问题会不会进入采购和组织分工,不预测某个确定拼法必然流行。有些名称已经出现在论文或小型产品中,仍不能当成成熟品类。
| 预测术语(英文) | 包装前的工程问题 | 不被术语骗的检验 | 预测 |
|---|---|---|---|
| State Engineering | 从事件和环境中重建此刻有效的状态 | 固定模型与任务后,它是否降低状态冲突和恢复错误 | 2026—2027,高 |
| Context Compiler | 按下一项决策生成最小状态视图 | 它是否比简单检索或长 prompt 减少无关 token,同时保持必要事实 | 2026—2027,高 |
| MemoryOps | 管理记忆的来源、过期、冲突、权限和删除 | 能否撤销过期记忆,并测量错误记忆造成的下游损失 | 2026—2028,高 |
| Harness Debt | 为旧模型编写的补偿规则已经没有收益 | 新旧模型与简繁 harness 的四组消融能否证明规则仍有正边际价值 | 2026—2027,中高 |
| Reasoning Router | 按任务难度分配模型、规划频率和验证预算 | 是否在相同质量下稳定降低成本,或在相同成本下提高成功率 | 2026—2028,高 |
| Agent Control Plane | 管理会话状态、工具权限、并发、检查点和恢复 | 中断后能否恢复,重复执行是否幂等,越权动作是否在执行前被阻止 | 2027—2028,高 |
| Verifiable Autonomy | 让外部动作带有来源、授权依据和执行证据 | 每个副作用能否追溯到用户目标与环境证据;证据不足时系统是否拒绝执行 | 2027—2029,中高 |
| Autonomy Budget | 根据动作影响和可逆性决定 Agent 可以自行做到哪一步 | 是否存在明确的风险函数和升级门槛,而不是给某个模型统一贴“可自治”标签 | 2027—2029,中 |
| Intent Compiler | 把模糊目标转成约束、授权边界和可执行验收条件 | 能否发现冲突约束,目标修改后又能否更新受影响的测试及权限 | 2027—2029,中 |
| Agent SLO | 衡量重复运行的可靠性、人工介入和失败恢复 | 是否公布结果分布与严重失败,而不是只报告一次成功率 | 2027—2029,中高 |
这些预测背后已经出现可测的研究对象。长期记忆安全综述把写入、存储、检索和遗忘视为同一治理周期。动态规划研究发现规划频率与表现并非单调关系,规划过多也可能降低长程任务表现;BEST-Route则同时选择模型和采样次数,以优化成本与质量。Agent provenance 综述开始连接证据、工具调用、记忆和最终行动。另一项尚待独立复现的预印本实验尝试在工具执行前检查动作是否得到可追溯证据支持。这些工作不能证明上表中的商业名称一定流行,只说明对应瓶颈已经存在。
最值得警惕的是名词把实现范围偷偷扩大。一个产品生成较短的 prompt,就可以自称 Context Compiler;保存聊天记录,也可以自称 Memory Fabric;在工具调用前再问一次模型,便可能被包装成 Trust Layer。新词只有在固定任务、模型和预算的对照实验中产生可重复增益,才对应新的工程能力。
从词汇演化看,主线可能是 prompt engineering 决定“怎样说”,context engineering 决定“看见什么”,state engineering 决定“此刻什么为真”,随后 governance engineering 决定“允许改变什么”。其中大部分底层问题早已存在于数据库、分布式系统和安全工程。Agent 带来的新变量,是一个概率性决策器进入了真实控制回路。资本会不断给外围约束换名字,这个变量不会因为命名而消失。
最后,能力提升会把瓶颈推向任务定义。编译、测试和数值指标明确的工作会更快获得长任务能力,因为环境能及时判定进展。产品取舍、跨团队协调和业务后果没有同样便宜的 evaluator,进步会慢一些。METR 也明确提醒,它的任务大多自包含、规格清楚,并不能代表日常工作中依赖隐性知识的任务。未来人类在 Agent 系统里的主要作用,可能从逐步告诉模型怎么写代码,转向定义契约、处理无法自动评分的冲突,并决定哪些结果可以进入权威状态。
State Engineering 有没有独立价值,最后仍要回到同一项检验:固定模型、任务和预算以后,状态工程是否减少了状态冲突,让中断后的恢复更可靠,并阻止过期信息继续影响行动。做不到这些,名称只是 Context Engineering 的重新包装。只有这些指标确实改善,State Engineering 才算解决了一个独立问题:概率性决策器进入真实系统以后,怎样知道此刻什么仍然为真。
相关文章
- CLI Agent 的长任务为什么越做越不可靠:CLI Agent 在长任务中失控,不是模型参数逐步变差,而是当前上下文偏离了项目的可验证状态。缩短未验证跨度,比单纯扩大窗口更重要。
- 中文“AI 味”是怎样被训练出来的?:为什么多种模型会反复写出相似的中文?本文从训练数据和偏好选择追溯原因,也说明标注外包、跨模型蒸馏的公开证据到哪里为止。
- Skill 到底有没有用?一次没有提升的编程基准实验:公开 Skill benchmark 的结论并不一致。本文对照 SkillsBench、SWE-Skills-Bench 和困难编程任务实测,说明没有提升时应怎样解释结果。