跳到主要内容
翻译页面

本页面由 AI 辅助从英文翻译而来。如两者存在差异，以英文版本为准。

为什么状态文件对 AI 智能体失效

状态文件是围绕一些被 AI 智能体打破的假设设计的：同一时间只有一个写入方，更改被成批合并为不频繁的、经人工评审的 apply，以及工作流能容忍状态在两次刷新之间是陈旧的。智能体是并发的，持续行动，并且根据提供给它们的任何事实进行推理。如果这些事实来自状态文件，智能体就是在根据一份陈旧的、不完整的现实副本进行推理。

明确列出这些假设​

状态文件模型在以下条件下有效：

  1. 写入是串行的。 状态锁定假设争用很少发生。人类团队每天 apply 几次；锁争用属于边缘情况。
  2. 读取发生在 plan 阶段。 状态在有人运行 plan 时刷新；两次刷新之间的陈旧状态是不可见的，因为没有人在看。
  3. 受管集合就是相关集合。 状态文件只描述该工具创建的资源。工作流假设在它之外不存在任何重要的东西。
  4. 错误由专家修复。 损坏或出现分歧的状态由从业者通过状态手术（导入、移动、手动编辑）来修复。

在智能体的运行方式下，每一条假设都不成立。智能体以秒为单位行动，因此串行写入成为吞吐量上限，锁争用成为常态。智能体持续观察，因此两次刷新之间的陈旧状态变成一连串错误的前提。智能体经常被问到有关整个环境的问题（“有没有任何东西被公开暴露？”），而受管集合之外的答案恰恰是关键所在。此外，损坏了状态的智能体无法可靠地为自己执行状态手术，因为这一修复循环原本假设由人来判断。

更深层的问题：副本就是接口​

所有这些都可以归结为一个设计决策：状态文件把基础设施状态的一份副本当作系统的工作接口。每份副本都有同步问题，副本的每个使用方都会继承这个问题。基础设施漂移不是运维上的意外；它是副本在一个现实会通过其他渠道发生变化的环境中的稳态行为，这些渠道即控制台、自动伸缩器、其他工具、其他智能体。

人工工作流用流程来消化这个问题：变更冻结、强制使用单一工具、定期核对。智能体环境做不到这一点：智能体的价值在于它们频繁且独立地行动，而这恰恰是使一份需要协调的副本无法维护的流量模式。

替代原语​

控制平面本身已经是一个一致、权威、并发安全的状态存储，它由 Provider 运行。智能体需要的是一个符合其工作方式的控制平面接口：针对当前状态的声明式查询，在各 Provider 之间保持统一，变更用同一套语法表达并由策略门控。这就是 StackQL 实现的模型：

SELECT instance_id, instance_type, launch_time
FROM aws.ec2.instances
WHERE region = 'us-east-1';

结果在执行时为真，包含未受管的资源，不需要锁，也不需要修复工作流，因为没有任何东西可以被损坏。标识符映射和依赖排序（状态文件的正当职责）转移到查询引擎和部署编排（stackql-deploy）中，而不是放在一个必须由智能体保持一致的可变制品中。