AI Agent 不是缺 Prompt，而是缺一套刹车系统

Thu, 14 May 2026 10:00:00 +0800

用 Claude Code、Codex、Cursor 久了，你大概率见过这种场面。

你只是想让它修一个小 bug。它先把项目翻了半天，打开几个不相干的文件，然后突然开始改架构。你说“先别动代码，先分析”，它答应得很快，下一秒还是调用了编辑工具。你让它跑测试，它挑了一个最顺手的命令，跑完以后告诉你“看起来没问题”。

这时候，我们通常会怪 Prompt。

于是规则一条条加上去：先读文件再计划，不要擅自扩大范围，每次只改一个问题，必须跑测试，不要使用危险命令。CLAUDE.md 越写越长，system prompt 越来越像公司制度手册。

可很多 Agent 失控，并不是因为它没读过流程，而是因为它手里一直有权限。

人类经理写再多“请规范操作”，也挡不住一个有生产权限的人半夜直接删库。AI Agent 也差不多。危险工具一直摆在它面前，你就只能祈祷它每次都记得别碰。

Statewright 这个项目有意思的地方就在这里。它不再试图发明一套更神的 Prompt，而是换了个更工程化的办法：别只劝 Agent 守规矩，让它在错误阶段根本看不到那些工具。

这个变化看起来不大，但味道完全变了。它把 AI Agent 从“靠自觉”往“有边界的系统”推了一步。

Statewright 到底是什么？

Statewright 是一个给 AI 编程代理用的状态机护栏系统。它最近出现在 Hacker News 的 Show HN 讨论里，项目也开源在 GitHub 上。

它做的事不复杂：把一次 Agent 任务拆成几个状态，比如 planning、implementing、testing、completed。不同状态下，Agent 能看到的工具不一样。

planning 阶段只能读文件、搜代码、整理方案，不能编辑，也不能随便跑脚本。implementing 阶段可以改代码，但可以限制改哪些文件、改多少行、能用哪些命令。testing 阶段只允许跑白名单里的测试命令，不能借着“验证”再顺手改点别的。

Statewright 的 README 里有一句话很狠：Agents are suggestions, states are laws.

Prompt 是建议，状态才是法律。

普通 rules、CLAUDE.md、项目说明，本质上是在告诉模型“你应该这么做”。Statewright 则把一部分要求搬到执行层：当前状态不允许的工具，Agent 就调用不了。

底层是一个 Rust 状态机引擎，负责处理状态、转移、guard 条件、工具限制、命令白名单和人工审批节点。它不靠另一个 LLM 来判断“这一步合不合规”，而是用确定性的规则跑。

这点我觉得很关键。用一个可能幻觉的模型，去监管另一个可能幻觉的模型，听起来就不太踏实。

为什么更好的 Prompt 不够？

过去两年，AI 工具的主旋律一直是“写更好的 Prompt”。这当然有用，尤其在模型能力还弱、工具调用还简单的时候。

但 AI 编程代理现在做的事已经变了。它不只是回答问题，而是在真实项目里读文件、改代码、跑命令、调 MCP、处理 Git 状态，有时还要跨多个系统操作。

这已经不是聊天问题，而是权限问题。

Prompt 可以告诉 Agent：没有计划时不要编辑文件。但只要编辑工具仍然可见，它就有机会误用。Prompt 可以告诉 Agent：不要运行危险命令。但只要 Bash 没有限制，它就可能为了省事使用重定向、批量替换，或者跑一个你没预料到的脚本。

这不一定是模型“不听话”。很多时候，它确实在努力完成目标，只是它对风险、范围和副作用的判断，和人类不一样。

你让它“修复构建失败”，它可能觉得升级依赖是合理路径；你让它“优化代码”，它可能顺手重构半个模块；你让它“验证一下”，它可能跑了一个不相关的测试，然后把成功结果当成证据。

问题不只是“怎样让 Agent 更聪明”，而是“怎样让 Agent 即使很聪明，也不能随便越界”。

Statewright 切的就是这个口子。

从贴纸条，到门禁卡

现在很多 AI 产品都会讲 guardrails，但不少 guardrail 仍然是 Prompt guardrail：在系统提示里写清楚哪些事不能做，哪些流程要遵守，哪些内容要拒绝。

这种护栏有用，但它依赖模型配合。

Statewright 更像 protocol-level guardrail。它不是让模型记住“当前不要编辑”，而是在 planning 状态下不给编辑工具。它不是让模型承诺“只运行 npm test”，而是在 testing 状态下只允许白名单命令。

这两者的差别，就像“贴一张禁止入内的纸条”和“门禁卡刷不开”。

Agent 能调的工具越多，这个差别越大。靠提示词管理几十个工具，迟早会变脆。

一个成熟的 Agent 工作流，绕不开三个问题：它现在处于什么阶段；这个阶段能做什么；满足什么条件才能进入下一阶段。

Prompt 可以描述这三个问题，状态机可以执行这三个问题。

拿 bugfix 举例。先进入 inspect 状态，只允许读相关文件和搜索错误；再进入 plan 状态，产出修改方案并等待确认；之后进入 implement 状态，只允许编辑已声明的文件；最后进入 verify 状态，只允许运行指定测试命令。中间想绕路，状态机直接拒绝。

这不是为了把 AI 绑住，而是为了把问题空间变小。

Statewright 网站上有一句说法也很直接：Instead of making the model bigger, make the problem smaller.

我挺喜欢这句话。与其期待模型在 40 个工具、几十个文件和一个模糊目标里永远做对，不如让它每一步只面对当下该处理的小问题。

Claude Code 为什么适合这种思路？

Statewright 目前对 Claude Code 的支持是 Hooks + MCP，而且属于硬限制。Codex、opencode、Pi 等也在不同程度接入。Cursor 目前更偏 advisory，也就是规则建议，还不能真正拦截工具调用。

这背后有个趋势：AI 编程工具的差异，正在从“哪个模型更强”，转到“哪个运行时更可控”。

Claude Code 这类 CLI-native 工具天然适合做协议层治理。它有清晰的工具调用边界，有 hooks，有 MCP，有本地文件和命令执行过程，也更容易在工具调用前后加拦截器。

Cursor 这种 IDE 产品体验更顺滑，但很多约束更像编辑器规则和上下文注入。普通用户可能已经够用。可如果团队需要强流程、强审计、强权限控制，那种“建议式约束”就会显得软。

这不是谁先进谁落后的问题，而是产品形态不同。

Agent 只是帮你补几行代码时，软规则够了。Agent 开始改项目、跑脚本、处理发布、调用外部服务时，软规则就不够了。

企业不会满足于一句“我们已经提示 AI 不要乱来”。企业真正想要的是：它在那个状态下就是不能乱来。

本地模型更需要这种轨道

Statewright 还有个容易被忽略的价值：它不只服务最强的云端模型，也可能对本地模型更有帮助。

很多人讨论本地模型时，习惯看跑分：SWE-bench 多少，Terminal-Bench 多少，代码能力接近谁。但真实使用里，本地模型的短板往往不是完全不会写代码，而是在复杂流程里更容易分心、漏步骤、误用工具。

状态机能缓解这件事。

模型不需要同时记住“现在处于什么阶段、哪些工具能用、下一步该做什么、哪些风险不能碰”。它只需要在当前轨道里完成局部任务。

这有点像新手司机上路。你当然可以教育他遵守交通规则，但如果路边有护栏、弯道有限速、危险路段有隔离带，事故率会低很多。

对本地小模型来说，护栏不是束缚，更像能力放大器。

我猜后面会出现一种混合架构：强模型负责制定计划和处理复杂判断，小模型在状态机约束下执行明确步骤。Statewright 这类工具，就是给这种架构铺轨道。

Agent 工作流会变得像 CI/CD 吗？

Statewright 现在未必已经是终局产品，但它指向的方向很清楚：AI Agent 工作流会开始像软件工程本身一样，被配置、被验证、被审计。

早期写代码，大家手动构建、手动测试、手动部署。后来有了 CI/CD，流程被写成 pipeline：什么时候构建，什么时候测试，什么时候发布，失败怎么回滚，谁有审批权。

今天的 AI Agent 还很像“手动部署时代”。我们把一堆规则写进 prompt，然后盯着它干活。它做对了，我们夸模型聪明；它做错了，我们再补一条规则。

长期看，这肯定不够。

以后的 Agent 工作流可能会更像 pipeline：需求澄清、代码搜索、方案确认、实现、测试、review、发布，每一步都有状态、权限、输入输出和转移条件。

到那时，团队的核心资产不只是代码库，还包括一套可复用的 Agent 工作流定义。新人可以按这套流程工作，AI Agent 也可以按这套流程工作。流程不再藏在资深工程师脑子里，也不再散落在几千字 Prompt 里，而是变成可执行的状态机。

这对 AI 编程很要命。

因为很多真实工程问题，并不是“会不会写某段代码”，而是“能不能稳定地按正确顺序做事”。

它当然也不是万能药

状态机也有成本。

你要定义状态、工具、命令、转移条件，还要维护这些规则。个人项目里可能有点重，快速探索时也可能嫌束手束脚。

它也不能替代代码 review。状态机能限制 Agent 什么时候做什么，但不能保证它写出的代码一定优雅、正确、符合业务语义。

流程本身也可能设计坏。如果设计得太死，Agent 会卡住；设计得太松，又回到了原来的问题。

所以这类工具更适合高风险、高重复、可流程化的任务，比如修 bug、跑测试、批量重构、发布前检查、安全审查、依赖升级。探索性研究、产品构思、写作脑暴，未必一上来就需要状态机。

但这不影响它的重要性。

AI Agent 真正进入生产环境后，最先要解决的不是“如何让它更自由”，而是“如何让它可控”。

真正的变化：从相信模型，到设计系统

AI 圈很容易陷入模型崇拜：模型更大，问题就少；推理更强，流程就稳；上下文更长，协作就顺。

现实没这么省事。

软件工程从来不是靠“聪明人自由发挥”维持质量的。我们靠类型系统、测试、CI、代码审查、权限管理、发布流程、监控告警，把人的能力装进一套系统里。

AI Agent 大概率也会走同一条路。

Prompt 仍然重要，但它会从唯一的控制手段，退回到系统的一部分。真正可靠的 Agent，不会只靠一段写得漂亮的提示词，而会靠上下文、工具、权限、状态、测试和审计共同组成的运行环境。

Statewright 让我看到的，就是这个方向。

AI Agent 的下一步，不只是更会写代码，而是更像一个受控的软件系统。

所以，“别再只写 Prompt 了”不是说 Prompt 没用。

而是说，如果你的 Agent 已经开始读项目、改代码、跑命令、调工具，那它需要的不只是更温柔、更详细的嘱咐。

它需要一套刹车系统。

Statewright on 奇诺分享 | 重在分享