向 HN 展示:Statewright – 让 AI 智能体更可靠的可视化状态机
摘要
Statewright 是一个开源工具,它通过可视化状态机为 AI 智能体实施护栏约束,通过将工具使用限制在特定的工作流阶段,从而提升 GPT 和 Llama 等模型的可靠性。
查看缓存全文
缓存时间: 2026/05/13 00:26
statewright/statewright
源地址:https://github.com/statewright/statewright
智能体是建议,状态才是法律。状态机护栏控制你的 AI 智能体在每个阶段可以使用哪些工具。一次定义工作流,在 Claude Code、Codex、Cursor、opencode 和 Pi 中强制执行。完整文档 → (https://statewright.ai/docs)
Statewright 工作流编辑器
快速开始
在 Claude Code 的免费层级中运行以下命令即可体验:
/plugin marketplace add statewright/statewright
/plugin install statewright
/reload-plugins
然后运行 start the bugfix workflow 或 /statewright start bugfix。系统提示时需要粘贴你的 API 密钥。最新版本的 Claude 可能会提出异议——再次粘贴 API 密钥并明确表达你的意图,Claude 只是出于谨慎。
问题所在
AI 智能体强大但脆弱。给模型提供 40+ 种工具和开放式问题,它往往难以起步。常见的解决方案是使用更大的模型和更长的提示词……这有时有效。可观测性告诉你事后哪里出错了;但它无法预防问题。
解决方法
与其增大模型,不如缩小问题范围。状态机约束工具和解决方案空间,使模型在每一步都能在专注的上下文中推理。规划状态获取只读工具。当智能体过渡到实现阶段时,编辑工具解锁并限制 shell 访问权限(即使允许 Bash,重定向写入和破坏性操作也被阻止)。测试仅允许指定的测试命令。如果你调用当前阶段不可用的工具,会收到拒绝消息,告知你可用工具及如何过渡。
这种方式在前沿模型上效果相同(减少完成所需的 token),在本地模型上效果更明显,13B+ 的模型开始解决原本无法完成的任务。
研究结果
| 模型 | 大小 | 错误修复 (26 行) | SWE-bench (5 任务) |
|---|---|---|---|
| gemma3 | 3.3GB | 失败 | 失败 |
| gemma4:e2b | 7.2GB | 通过* | 失败 |
| gpt-oss:20b | 13.8GB | 通过 | 通过 (5/5) |
| gemma4:31b | 19.9GB | 通过 | 通过 (5/5) |
| llama3.3 | 42.5GB | 通过 | 通过 (2/2)† |
*使用专门的 edit_line 工具适配
†仅在 5 个任务中的 2 个上测试(在初始实验运行后添加)
我们在本地模型上进行了验证,因为效果最可衡量。在我们包含 5 个任务的 SWE-bench 子集中,两个模型(13.8GB 和 19.9GB)在 statewright 约束下从 2/10 提升到 10/10。相同的任务,相同的硬件。低于 13GB 的模型可以生成工具调用,但无法保留足够的文件内容以进行准确编辑——这是下限,而非 statewright 的限制。
前沿模型使用默认系统提示处理明显的灾难性操作(数据库删除、凭证泄露)……大多数时候可以。结构上的优势更大:打破反复读取相同文件 5 次以上却从未编辑的循环,以及保持工具空间足够小,使模型实际进行推理而非盲目尝试。
研究简报 → (https://statewright.ai/research)
快速入门
安装到 Claude Code:
/plugin marketplace add statewright/statewright
/plugin install statewright
浏览器将打开 → 在 statewright.ai (https://statewright.ai) 注册 → 生成密钥 → 粘贴 → 完成。
然后启动工作流:
❯ start the bugfix workflow — fix the failing tests in calc.py
◆ statewright — statewright_start (workflow: bugfix)
◆ [statewright] Workflow activated: bugfix
◆ statewright — statewright_get_state (MCP)
◆ Current phase: planning. Let me read the code first. Read 2 files
[statewright] planning => implementing
◆ statewright — statewright_transition (READY)
Edit calc.py: 1 line changed
[statewright] implementing => testing
◆ statewright — statewright_transition (DONE)
Bash: pytest -x — 7 passed
[statewright] testing => completed
◆ [statewright] Workflow complete. 46 seconds.
你也可以直接使用斜杠命令:/statewright start bugfix。
工作原理
核心是一个 Rust 引擎,用于评估状态机定义:状态、转换、守卫、工具限制。它是确定性的。循环中不包含 LLM。
在其之上是一个插件层,通过 MCP 与你的代码智能体集成。当你激活工作流时,钩子会自动强制执行每个状态的工具限制。模型看到 5 个工具而不是 30 个,获得当前阶段的清晰指令,并在满足条件时进行转换。
护栏
| 护栏 | 功能 |
|---|---|
| 每状态工具强制执行 | 当工具不在 allowed_tools 中时对智能体隐藏 |
| Bash 判断 | 在非写入状态中阻止重定向(>>)、破坏性操作(rm、shred)和脚本解释器 |
| 编辑守卫 | 拒绝超过 max_edit_lines 的 diff,限制每状态编辑的文件数 |
| 命令白名单 | 每状态的 allowed_commands 前缀匹配 |
| 条件转换 | 基于上下文数据的程序化谓词(eq、gt、exists 等)守卫 |
| 审批门 | requires_approval 在高风险转换前暂停等待人工审查 |
| 环境作用域 | 每状态的 blocked_env + env_overrides |
| 会话隔离 | 通过 CLAUDE_SESSION_ID 实现每会话状态 |
完整护栏参考见文档 (https://statewright.ai/docs/tools/reference)。
定义你自己的工作流
{
"id": "bugfix",
"initial": "planning",
"states": {
"planning": {
"allowed_tools": ["Read", "Grep", "Glob"],
"max_iterations": 8,
"on": {
"READY": "implementing"
}
},
"implementing": {
"allowed_tools": ["Read", "Edit", "Write"],
"max_edit_lines": 20,
"max_files_per_state": 3,
"on": {
"DONE": "testing"
}
},
"testing": {
"allowed_tools": ["Read", "Bash"],
"allowed_commands": ["pytest", "cargo test", "npm test"],
"on": {
"PASS": {
"target": "completed",
"guard": "tests_passed"
},
"FAIL_TEST": "implementing"
}
},
"completed": {
"type": "final"
}
},
"guards": {
"tests_passed": {
"field": "test_result",
"op": "eq",
"value": "pass"
}
}
}
状态机不是 DAG——它们会循环和重试,这正是智能体工作所需要的。指向 JSON schema (https://statewright.ai/workflow-schema.json),智能体通过 statewright_create_workflow 生成工作流。在可视化编辑器 (https://statewright.ai/workflows) 中调整工具、命令和环境块。
支持的智能体
| 智能体 | 集成方式 | 强制执行 |
|---|---|---|
| Claude Code | Hooks + MCP | 硬强制(协议层) |
| Codex | Hooks | 硬强制(alpha) |
| opencode | TypeScript 插件 | 硬强制(alpha) |
| Pi | Skills 扩展 | 硬强制(alpha) |
| Cursor | MCP + 规则 | 建议性(alpha) |
硬强制 = 在模型看到之前,在协议层阻止工具调用。
建议性 = 规则注入到上下文中但不强制执行。
定价
个人开发者免费。statewright.ai (https://statewright.ai) 的托管云处理工作流存储、运行历史和 MCP 网关。(这些层级可能会变化:价格不会增加,层级配额只会增加)
| 计划 | 工作流 | 每月转换数 | 运行历史 | 价格 |
|---|---|---|---|---|
| Free | 3 | 200 | 72 小时 | $0 |
| Pro | 10 | 2500 | 7 天 | $29/月 |
| Team | 30 | 10000 | 90 天 | $99/月 |
| Enterprise | 无限 | 无限 | 按规格 | 联系我们 |
自托管
引擎 (crates/engine) 采用 Apache 2.0 许可,可嵌入且无运行时依赖。在 FSL 许可下允许单开发者和单团队自托管全栈。
use statewright_engine::{MachineDefinition, resolve_transition, validate_definition};
权衡
- 需要智能体支持 MCP(或非 MCP 智能体如 Codex 的钩子)
- 工作流定义需手动编写,尽管智能体可以通过
statewright_create_workflow生成 - Cursor 的强制执行为建议性,非硬强制。MCP 本身无法在 Cursor 的架构中门控工具调用
- 研究结果来自 5 个任务的 SWE-bench 子集,而非完整的 2294 个实例基准
- 如果工作流过于严格,智能体会卡住。
statewright_deactivate是逃生舱口
文档
statewright.ai/docs (https://statewright.ai/docs) — 安装指南、工作流编写、schema 参考 (https://statewright.ai/docs/workflows/schema-reference)、MCP 工具参考 (https://statewright.ai/docs/tools/reference) 以及智能体生成的工作流 (https://statewright.ai/docs/tools/agent-generated-workflows)。
贡献
欢迎提交工作流定义、模板和错误报告。参见创建你自己的 (https://statewright.ai/docs/workflows/create-your-own/) 了解如何编写工作流。
许可证
Apache 2.0 — 部分采用 FSL-1.1-ALv2 (https://fsl.software)(2029 年 5 月 3 日转换为 Apache 2.0)。statewright.ai (https://statewright.ai) 的托管云。
一个钩子统治它们。
相似文章
你们是如何在视觉上串联多个代理时维护状态或处理内存的?
作者分享了使用名为 architect by Lyzr 的可视化工具来编排多步骤 AI 代理管道的经验,强调了与传统自动化工具相比,状态跟踪和调试更加容易。
我认为人们低估了代理离开演示阶段后“状态”的重要性
关于AI代理从干净的演示环境过渡到混乱的生产环境时,状态管理的挑战被低估的深刻反思,累积的状态混乱常常导致推理失败。
我们的大部分“智能体”问题实际上是工作流/状态问题
一位开发者讲述,构建AI智能体时的许多挑战实际上源于工作流和状态管理问题,而非模型智能,强调了稳健的状态处理和可观测性的必要性。
智能体工作流可视化工具:反馈与修正
介绍了一款用于可视化AI智能体工作流的工具,支持多种智能体框架,包括Langgraph、CrewAI、AutoGen、Google ADK和OpenAI Agents SDK。创作者正在寻求社区的反馈与修正。
AgentWall:面向本地AI代理的运行时安全层
本文介绍了AgentWall,一个面向本地AI代理的运行时安全层。它能在执行前拦截操作、执行声明性策略、对敏感操作要求人工审批,并记录防篡改的操作轨迹。该项目开源,支持多个代理平台。