向 HN 展示:Statewright – 让 AI 智能体更可靠的可视化状态机

Hacker News Top 工具

摘要

Statewright 是一个开源工具,它通过可视化状态机为 AI 智能体实施护栏约束,通过将工具使用限制在特定的工作流阶段,从而提升 GPT 和 Llama 等模型的可靠性。

当前的代理式问题解决(Agentic problem solving)非常脆弱。我对它着迷,但它带来的问题和解决的一样多。 我是 Ben Cochran,拥有 20 多年的全栈工程、DevOps、高性能计算和机器学习的实战经验,曾在 NVIDIA、AMD 以及其他多家组织任职,最近担任杰出工程师。 要让代理可靠地工作,你需要大量的参数规模或巨大的上下文窗口来保持解决方案空间的可行性。大多数人都在用更大的模型和更长的提示词来暴力破解可靠性。 如果我不增大模型规模,而是缩小问题规模呢? 我采取了不同的方法:使用较小的模型——在 13-20B 参数范围内的模型,并让它们解决真实的 SWE-bench 问题。我通过形式化状态机限制了工具和解空间。状态机中的每个状态定义了模型可以访问哪些工具、可以进行多少次迭代以及哪些转换是有效的。规划状态拥有只读工具。实现状态拥有编辑工具(作用域限制以防止大规模编辑)和友好的 bash 写操作工具。测试状态拥有 bash,但仅用于测试命令。模型在物理上无法跳过步骤或在错误的时间使用错误的工具。这是通过协议而非提示词来强制执行的。 结果比我预期的更有希望。在多个模型家族中,无论新旧(qwen-coder、gpt-oss、gemma4),在超过 13B 参数的拐点之上,改进都是一致的。低于这个参数规模,模型可以导航状态机,但无法保留足够的上下文来生成准确的编辑。更多关于研究的部分:<a href="https://statewright.ai/research" rel="nofollow">https://statewright.ai/research</a> 令人惊讶的是,这也带来了前沿模型的改进。Haiku 和 Sonnet 开始超常发挥,Opus 更可靠地解决问题,且使用的 token 更少,陷入“死亡螺旋”的情况也减少了。微调对我来说并没有带来这种功能性的改进。似乎得到的启示是:上下文窗口的利用率比原始上下文大小更重要——在每个步骤中,紧密作用域的工作上下文比赋予模型对所有内容无限权限的模型表现更好。通过确定性代码来约束非幂等的 LLM 是一种目前无人讨论的模式。 因此,我构建了 Statewright。它的核心是一个 Rust 引擎,用于评估状态机定义:状态、转换、守卫和工具限制。它的编排不使用 LLM,只是强制执行状态机。在其之上是一个插件层,通过 MCP 与 Claude Code(即将支持 Codex、Cursor 等)集成。当你激活一个工作流时,钩子会自动执行每个状态的护栏。模型会看到 5 个可用工具而不是几十个,获得当前阶段的清晰指令,并在满足条件时进行转换。重要的是,它会在模型尝试超出范围、不正确或陷入困境后需要尝试其他操作时告知模型。 你可以通过 MCP 使用你的代理为你构建一个状态机,以解决当前上下文中的问题。statewright.ai 上的可视化编辑器允许你在图形视图中调整这些工作流……你可以清楚地看到失败路径、重试循环和审批门。状态机不是有向无环图(DAG);它们循环和重试,这正是代理工作真正需要的。 Statewright 目前已经上线并提供免费层级,你可以通过在 Claude Code 中运行以下命令来尝试: /plugin marketplace add statewright/statewright /plugin install statewright /plugin reload-plugins 然后“启动 bugfix 工作流”或 /statewright start bugfix。你需要在提示时粘贴你的 API 密钥。最新版本的 Claude 可能会抱怨——再次粘贴 API 密钥并告诉它你确实要这样做,Claude 只是在这里表现得过于谨慎。 欢迎就工作流编辑器、插件体验提供反馈,并告诉我你首先想构建什么样的工作流。代理是建议,状态是法律。
查看原文
查看缓存全文

缓存时间: 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 任务)
gemma33.3GB失败失败
gemma4:e2b7.2GB通过*失败
gpt-oss:20b13.8GB通过通过 (5/5)
gemma4:31b19.9GB通过通过 (5/5)
llama3.342.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 判断在非写入状态中阻止重定向(>>)、破坏性操作(rmshred)和脚本解释器
编辑守卫拒绝超过 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 CodeHooks + MCP硬强制(协议层)
CodexHooks硬强制(alpha)
opencodeTypeScript 插件硬强制(alpha)
PiSkills 扩展硬强制(alpha)
CursorMCP + 规则建议性(alpha)

硬强制 = 在模型看到之前,在协议层阻止工具调用。
建议性 = 规则注入到上下文中但不强制执行。

定价

个人开发者免费。statewright.ai (https://statewright.ai) 的托管云处理工作流存储、运行历史和 MCP 网关。(这些层级可能会变化:价格不会增加,层级配额只会增加)

计划工作流每月转换数运行历史价格
Free320072 小时$0
Pro1025007 天$29/月
Team301000090 天$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) 的托管云。

一个钩子统治它们。

相似文章

智能体工作流可视化工具:反馈与修正

Reddit r/AI_Agents

介绍了一款用于可视化AI智能体工作流的工具,支持多种智能体框架,包括Langgraph、CrewAI、AutoGen、Google ADK和OpenAI Agents SDK。创作者正在寻求社区的反馈与修正。

AgentWall:面向本地AI代理的运行时安全层

arXiv cs.AI

本文介绍了AgentWall,一个面向本地AI代理的运行时安全层。它能在执行前拦截操作、执行声明性策略、对敏感操作要求人工审批,并记录防篡改的操作轨迹。该项目开源,支持多个代理平台。