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

> 状态文件假设只有一个缓慢的、由人协调的写入方；AI 智能体是并发、快速且持续运行的，这违背了状态文件模型所依赖的每一条假设，替代它的原语是对控制平面的实时查询。

Source: https://stackql.io/zh-hans/ai/concepts/why-state-files-break-down-for-ai-agents

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

## 明确列出这些假设

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

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

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

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

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

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

## 替代原语

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

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

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

## 相关概念

- [什么是基础设施漂移？](/ai/canonical-definitions/what-is-infrastructure-drift)：漂移是副本的一种属性
- [什么是智能体基础设施？](/ai/canonical-definitions/what-is-agentic-infrastructure)：智能体提出的要求
- [StackQL vs Terraform](/ai/comparisons/stackql-vs-terraform)：两种模型的并列比较
- [什么是可查询基础设施？](/ai/canonical-definitions/what-is-queryable-infrastructure)：实时查询的运作模式
- [如何将 StackQL 与 AI 智能体配合使用](/ai/how-tos/use-stackql-with-ai-agents)：实际设置