一个Rust写成的状态机引擎，让AI编程Agent在plan→implement→test→deploy的流水线中不再"自由发挥"。在5个SWE-bench任务上，两个本地模型从10次尝试仅2次通过，变成10次全部通过。更妙的是：这玩意开源、自托管、月费29美元起步。
发生了什么
6月5日，一个名叫Statewright的项目在Hacker News上炸了——126 points、59条评论，直接冲上当日热榜。项目描述只有一句话："Agents are suggestions, states are laws."（Agent是建议，状态是法律。）
简单说，Statewright是一个用状态机给AI编程Agent加"护栏"的工具。你定义好planning→implementing→testing→completed这样的工作流，每个状态只暴露该状态需要的工具。比如在planning阶段，Agent只能Read/Grep/Glob；切到implementing阶段，Edit/Write才解锁；到了testing阶段，只允许pytest/cargo test等指定命令。
核心理念：不把模型变大，让问题变小。 不给Agent扔40+工具说"你自由发挥吧"，而是拆成小步骤，每步只给5个工具。
为什么这件事重要
如果你用过Claude Code、Codex或Cursor做复杂任务，一定对这种体验不陌生：
- Agent在review阶段突然开始改代码
- 部署命令在测试跑通之前就被执行了
- 同一文件读了5遍还在绕圈子
- 一次修改了20+行，然后测试全炸
Statewright解决的就是这个问题。而且它的成果非常硬核——
研究数据：在5个SWE-bench任务的子集上（非完整2294实例基准），两个本地模型的表现：
| 模型 | 大小 | 修复前（10次尝试通过数） | 修复后（10次尝试通过数） |
|---|---|---|---|
| gpt-oss:20b | 13.8GB | 2/10 | 10/10 |
| gemma4:31b | 19.9GB | 2/10 | 10/10 |
同样的任务、同样的硬件、同样的模型。加了状态机约束后，完成率从20%拉到100%。
▲ Statewright研究数据：加约束后完成率从20%拉升至100%
门槛在13GB。低于这个容量，模型能识别bug但改不动代码——那是模型本身的限制，不是Statewright的问题。
它具体是怎么工作的
Statewright的核心分两层：
底层：一个Rust写成的确定性状态机引擎。它解析状态、转换、守卫条件、工具限制——全程不调LLM，纯确定性逻辑。
上层：一个MCP插件层，集成到各种编程Agent中（Claude Code、Codex、Cursor、opencode、Pi）。当你激活一个工作流，hooks在每步拦截工具调用，Agent看到的不是30个工具而是5个，每个阶段有清晰的指令。
具体护栏包括：
| 护栏类型 | 作用 |
|---|---|
| 按状态限制工具 | 当前状态不在allowed_tools里的工具，Agent根本看不到 |
| Bash分辨力 | 即使Bash被允许，echo > file、rm -rf、sed -i、python/node等脚本解释器仍被阻止（当Write/Edit不允许时） |
| 编辑上限 | 每次diff不超过max_edit_lines行，每个状态最多编辑max_files_per_state个文件 |
| 命令白名单 | 只允许前缀匹配的命令（如pytest、cargo test） |
| 条件转换 | 编程式守卫：test_result eq pass、coverage gt 80等 |
| 审批门 | requires_approval暂停等人工审查 |
| 中断机制 | 编辑匹配glob模式的文件？自动跳转到验证状态，然后回到原位 |
| Fork/Join | 顺序或并行跑分支，等全部（或任一）完成后汇合 |
| 环境隔离 | 隐藏PROD_DB_URL，用env_overrides替换 |
| 会话隔离 | 通过CLAUDE_SESSION_ID实现每会话独立状态 |
工作流定义：简单到可以用JSON写
一个bugfix工作流的完整定义长这样：
▲ Statewright Bug修复工作流的四个阶段
而且你不需要手写JSON——让Agent自己生成。对Claude Code说"给我生成一个bugfix工作流"，它调用statewright_create_workflow工具自动产出，你再用可视化编辑器微调就行。
安装也极简：
浏览器打开statewright.ai注册→生成key→粘贴→搞定。
定价：29美元/月起步，可以自托管
Statewright的定价策略值得关注——它走的是"开源核心+托管云服务"路线：
| 方案 | 工作流数 | 月转换次数 | 历史记录 | 价格 |
|---|---|---|---|---|
| Free | 3 | 200 | 72小时 | $0 |
| Pro | 10 | 2,500 | 7天 | $29/月 |
| Team | 30 | 10,000 | 90天 | $99/月 |
| Enterprise | 无限 | 无限 | 按需 | 联系销售 |
更关键的是：你可以完全自托管。一个docker compose up --build就跑起来了——PocketBase + MCP网关 + 工作流编辑器，全部本地。核心引擎（crates/engine和crates/agent）是Apache 2.0协议，零运行时依赖，可以嵌入到任何项目里。
HN社区的争议点：这东西能活多久？
HN评论区的讨论非常精彩，几个关键争议值得关注：
争议1：会不会被大厂吃掉？
这是最尖锐的质疑。有评论直言："这家公司看起来只有几个月可活，如果这个想法好，Anthropic会直接把它做到Claude Code里"（lambdaone）。另一条评论补充："我预计工具会开始嵌入本地SLM（~1B参数）来做这件事，它会变成快速变化格局中的一个功能，需求可能在未来消失"（hsaliak）。
但反方观点也很有力。有用户提到自己正在做一个类似的ticketing系统，"用状态机约束后效果更可预测"（giancarlostoro）。另一位开发者说："我完全相信状态机是让低参数LLM产出高质量代码的关键"（tim-projects）。
争议2：代理层模式的价值超乎想象
一位叫thebotclub的评论者指出："Agent和LLM之间的代理层模式，意义远超上下文压缩。一旦你有一个拦截工具输出的层，你不仅可以压缩——你可以检查、审计、对Agent实际在做什么执行策略。"这个视角把Statewright从一个"护栏工具"拔高到了"Agent治理基础设施"的层面。
争议3：灵活性vs约束
"真正有趣的方法。我唯一的担忧是当工作流变得过于僵化时会失去多少灵活性。想知道它在需要更多创造性探索的任务上表现如何。"（prunrCloud）。这确实是个真问题——bugfix这种线性流程适合状态机，但探索性编程呢？
对AI创业者的启示
Statewright这个故事，至少有三层启示：
第一层：Agent可靠性是创业刚需。 如果你正在基于Claude Code/Codex/Cursor构建产品，Agent"乱来"是你的真实痛点。Statewright提供了一个开源的、可自托管的解决方案。不需要等Anthropic或OpenAI出官方方案。
第二层：小模型+好约束 > 大模型+自由发挥。 研究数据很明确：20B参数的本地模型+状态机约束，和云端大模型裸跑，前者居然赢了（10/10 vs 2/10）。这对AI创业者意味着：你不需要烧钱买最贵的模型，把约束做对，本地模型也能打。
第三层："Agent中间层"是一个独立的创业赛道。 Statewright的MCP网关、Context Gateway的压缩代理、各种Agent harness——这些不是大模型公司的附属品，而是一个独立的产品层。未来12个月，这个层会诞生不止一家独角兽。
行动建议
- 今天就可以试：Statewright可以在30秒内装进Claude Code。试试bugfix工作流，对比一下有无约束的成功率差异。
- 如果你的产品用到了编程Agent：评估一下把状态机约束作为默认配置。用户可能没意识到Agent乱跳是他们的隐形成本。
- 创业者机会：如果你在做一个垂直场景的AI编程工具（比如自动化测试生成、SQL优化、API对接），Statewright这种"定义领域工作流+约束Agent行为"的模式可以直接借鉴。加上你自己的领域知识做工作流模板，这就是护城河。
- 关注替代方案：Context Gateway（97pts HN，606 GitHub stars）走的是"压缩上下文"路线；Swival也在做上下文管理。这些工具和Statewright不冲突，可以组合使用——状态机管行为边界，压缩代理管token经济。
本文由AI辅助创作，经人工审核编辑发布