如果你用过 Claude Code、Codex CLI 或 Cursor 这类编程 Agent，大概率见过一种很烦人的失败模式：它明明已经读完文件，却又回头读一遍；明明应该先写测试，却开始大面积重构；明明只是修一个 20 行 bug，却顺手动了 6 个模块。最后 token 花了，diff 也出来了，但你不敢合并。
我越来越觉得，这不是“模型不够聪明”一个问题。
更准确地说，是我们把 Agent 放进了一个没有交通规则的城市：Read、Grep、Edit、Bash、Web、MCP 工具全都摊在它面前，然后指望一段系统提示词告诉它“请谨慎驾驶”。提示词当然有用，但它不是刹车，也不是红绿灯。
这也是 Statewright 最近在 HN 上引起我注意的原因。它的口号很硬：Agents are suggestions, states are laws. 用人话翻译：不要只靠模型“自觉”，把工作流拆成确定状态，在每个状态里只开放它该用的工具。
状态机不是新概念，但放在 Agent 上刚好戳中痛点
Statewright 做的事情并不神秘。它让你定义一个工作流，例如 planning → implementing → testing → completed。在 planning 状态里，Agent 只能读文件、搜索代码；进入 implementing 以后才允许 Edit/Write；到 testing 状态，Bash 可以用，但只能跑 pytest、cargo test、npm test 这类白名单命令。
项目 README 里的示例很直观：planning 只给 Read/Grep/Glob，implementing 允许 Read/Edit/Write 且限制 max_edit_lines、max_files_per_state，testing 才给 Bash，并且通过 guard 判断测试是否通过。官方的 workflow schema 也把这些字段明确写成结构化配置，而不是自然语言建议。
这点很关键。
自然语言提示词的问题是，它最终还是要被模型“理解”和“遵守”。状态机的问题是，工具调用在执行层被拦住。模型想在 planning 阶段写文件？调用会被拒绝。模型想在测试阶段跑一个不在白名单里的 shell 命令？也会被拒绝。技术描述听起来有点抽象，人话就是：把“你最好不要这样做”改成“你做不到”。
Statewright 的实现也不是纯概念。仓库主体是 Rust、Python、Shell 和 TypeScript，GitHub API 显示最近提交在 2026-05-14，仓库约 279 stars；目录里有 crates、plugins、templates 等实际代码。它通过 MCP/插件层接入 Claude Code、Codex、Cursor、opencode 等编码工具，核心 Rust engine 负责评估状态、转移、guard 和工具限制。换句话说，它不是又一个“Agent 最佳实践文档”，而是试图把最佳实践编译成运行时约束。
为什么这比“写更长的 system prompt”更像工程方案
我以前也习惯用长提示词管 Agent：先分析，不要急着改；每次只改小 diff；先跑测试；不要删除用户文件；遇到不确定先询问。问题是，提示词越长，越像团队的 Confluence 规范——看起来很完整，真出事时不一定拦得住。
Statewright 的优势是把约束分层了。
第一层是工具可见性。Agent 在某个状态下看到的工具变少，决策空间也变小。对大模型来说，这减少了乱试；对本地小模型来说，意义更大，因为它们本来就不擅长在 30 个工具里稳定选择。Statewright README 声称，在一个 5 题 SWE-bench 子集上，13.8GB 和 19.9GB 的本地模型在加入约束后从 2/10 提升到 10/10。这个结果当然不能等同于完整 SWE-bench——项目自己也注明只是 5 个任务的小样本——但方向是可信的：小模型最怕开放式任务，状态机把开放题改成了分步题。
第二层是命令与编辑限制。allowed_commands、max_edit_lines、max_files_per_state 这些字段看起来朴素，却是生产环境里最需要的东西。比如你可以允许 Agent 在 testing 阶段跑 pytest，但不允许它执行任意 curl | bash；允许它修 20 行，但不允许它顺手重写半个服务。很多 Agent 安全讨论会停留在“防 prompt injection”，但工程事故更多时候来自越权修改、过大 diff、错误 shell 命令和状态漂移。
第三层是显式转移。Agent 必须从 planning 转到 implementing，再到 testing。它不是在一个无限上下文里“凭感觉继续”，而是在被迫回答：现在是什么阶段？我为什么可以进入下一阶段？guard 是否满足？这会打断一种常见死循环：模型不断 reread 文件，却迟迟不编辑，或者测试失败后盲目继续改。
说白了，Statewright 不是让 Agent 更聪明，而是让任务环境更笨、更窄、更可控。很多时候，这反而是可靠性的来源。
但我不会把它直接神化成“Agent 可靠性终局”
它也有明显代价。
最直接的是工作流设计成本。你必须知道一个任务应该拆成哪些状态，每个状态开放哪些工具，哪些命令能跑，什么时候需要人工审批。如果工作流太松，护栏没意义；太紧，Agent 会卡在状态里。Statewright README 也提到，限制过强时需要 statewright_deactivate 作为逃生门。
第二个问题是，它更适合“流程明确”的任务，而不是探索性任务。修 bug、补测试、生成迁移脚本、执行 release checklist，这些都适合状态机；但如果你让 Agent 研究一个完全陌生的代码库、做架构探索、评估多种方案，过早限制工具可能会让它变笨。我的判断是：Statewright 应该放在从“探索”进入“执行”之后，而不是替代所有自由推理。
第三个问题是生态绑定。它现在对 Claude Code 的 quickstart 最成熟，也在文档里提到 Codex、Cursor、opencode 等集成方向。但不同工具的 hook 能力并不一致：有的能拦截 tool call，有的只能在 shell 层做包装，有的对 MCP 支持还不稳定。也就是说，Statewright 的思路可以迁移，但落地体验会高度依赖你用的 Agent harness。
还有一个小但真实的风险：状态机配置本身会变成新的复杂度来源。以前你 debug prompt，现在你还要 debug workflow。比如某个 guard 写错了，Agent 永远进不了 testing；某个命令白名单漏了参数，测试跑不起来；某个编辑行数限制太小，导致模型反复拆 patch。工程上没有免费的午餐，只是把不确定性从模型输出转移到了可审查的配置里。
我个人愿意接受这个转移。因为配置至少能 diff、review、版本化；模型的“自觉”不能。
它和 OpenClaw、AgentArmor 其实在解决同一个底层问题
Hypho Blog 之前写过 OpenClaw 的离散状态机架构：长时间运行的 AI 工作流，不能只靠一次 prompt 维持状态，必须把任务进度、失败恢复和执行阶段落到外部状态上。Statewright 更聚焦在编码 Agent，但哲学很像：LLM 负责生成建议，状态系统负责维持边界。
另一个相关方向是 AgentArmor 的多层安全框架。AgentArmor 更像安全防线清单：身份、权限、监控、隔离、审计；Statewright 则更像一套具体执行器：在每个状态拦工具、拦命令、拦大 diff。前者告诉你 Agent 系统应该有哪些安全层，后者把其中一部分变成了开发工作流里的硬约束。
这两个思路合在一起，才比较接近生产环境需要的样子：既要有宏观安全模型，也要有执行时的确定性控制。
我会怎么用它
如果是个人项目，我不会一上来就给所有任务套复杂状态机。那会把开发体验搞得很重。我会从三个高风险场景开始：
第一，自动修 bug。流程固定为 read-only 诊断、最小 diff 修复、指定测试、失败回滚或二次修改。这里状态机非常合适，因为“先读后改再测”本来就是人类工程师也该遵守的流程。
第二，依赖升级和迁移。比如升级框架、改数据库 schema、批量替换 API。Agent 很容易在这类任务里越改越大，所以 max_files_per_state、审批门和命令白名单很有价值。
第三，CI 失败自动修复。CI 环境最怕 Agent 执行任意命令，也最适合白名单：只允许读取日志、改特定目录、跑指定测试。状态机能把“自动修 CI”从危险实验变成可控流水线。
如果是团队项目，我会把 workflow 配置当成代码审查对象。谁能改状态机？哪些状态允许 Bash？哪些命令进入白名单？哪些 transition 需要人工审批？这些问题应该进入 repo，而不是藏在某个人的 Claude Code 配置里。
结论：Agent 可靠性不会只靠更强模型解决
我对 Statewright 的判断是：它不是所有 Agent 问题的答案，但它抓住了一个正确方向——把 Agent 从“会聊天的工具使用者”改造成“在流程约束下工作的执行者”。
这件事对未来一年会越来越重要。模型能力继续变强，Agent 能调用的工具也会越来越多；工具越多，自由度越高，事故半径也越大。继续往 prompt 里加“请小心”不够了。我们需要可执行、可审计、可版本化的边界。
状态机听起来老派，甚至有点不性感。但工程里很多可靠系统，最后靠的就是这些不性感的东西：有限状态、白名单、审批门、最小权限、失败回路。
Agent 也是系统。既然是系统，就别只给它写鸡汤，给它装刹车。