Show HN：Statewright – 使人工智能代理可靠的视觉状态机
一句话看懂：前 NVIDIA/AMD 工程师 Ben Cochran 推出了 Statewright，一个用状态机而非大模型暴力求解来提升 AI 代理可靠性的工具。其核心思路是通过确定性的代码约束非确定性的 LLM，在 13-20B 参数的小模型上取得了超越大模型的 SWE-bench 任务成绩。
事件核心：发生了什么
创始人 Ben Cochran 在 Hacker News 上发布了 Statewright。他拥有 20 余年全栈、DevOps 和高性能计算经验，曾在 NVIDIA、AMD 担任杰出工程师。Statewright 的核心理念不同于当前主流依赖更大的参数规模（如 70B+）或更长的上下文窗口来保证 AI 代理可靠性，而是从反面入手：缩小问题空间。产品基于 Rust 引擎，将代码任务分解为规划、实施、测试等离散状态。每个状态限制模型只能访问特定的工具和指令，并且强制规定了迭代次数和状态转移规则——代理无法跳过步骤或在不该使用编辑工具时进行编辑。这种约束通过协议而非提示词强制实现。
基准测试显示，在 13-20B 参数级别（如 Qwen-Coder、GPT-oss、Gemma 4）的模型中，状态机方法带来了显著且一致的改进。出人意料的是，该方法对前沿模型（如 Claude Sonnet、Opus）也有提升，减少了“死亡螺旋”和分词浪费。Ben 强调，上下文窗口利用效率比原始上下文大小更重要。Statewright 目前已上线并提供免费层级，支持通过 MCP 插件与 Claude Code 集成。
为什么重要
当前 AI 代理社区的主流思路是“堆料”：更大的模型、更长的提示词来对抗不确定性。Statewright 提供了一个逆向但极有价值的思路——用确定性的代码（状态机）来约束非确定性的 LLM。这一模式打破了“只有大模型才能可靠”的假设，为中小模型在特定工程任务中的实用化开辟了道路。对行业而言，它意味着降低推理成本、提高部署效率的另一个可扩展方向：不是把模型做“大”，而是把问题做“小”。此外，它强调了上下文窗口的“利用率”而非“长度”才是关键，这可能会推动工具链和模型架构的重新设计。值得关注的是，Statewright 明确表示“状态是法律，建议是代理”，这种设计哲学与当前流行的提示工程范式有本质不同。
对用户/开发者/创作者的影响
对 AI 代理开发者：Statewright 提供了一种现成的方案来提升可靠性和减少失败，尤其适合需要稳定代码产出（如修 bug、代码审查、自动化测试）的场景。开发者可以在视觉编辑器中自定义工作流，清晰看到失败路径、重试循环和审批关卡，而非依赖不透明的 prompt 调优。对企业采购决策者：表明在特定任务上，采购 70B+ 参数的昂贵模型并非唯一选项。13-20B 的模型配合状态机约束可能以更低成本达到甚至超越大模型的效果。这有望改变企业对 AI 代理的 ROI 计算。对 AI 创作者/研究人员：Statewright 的发现（上下文窗口利用率 > 原始长度）值得关注，可能推动更细粒度的上下文管理研究。不过，目前产品主要面向工程任务（如 SWE-bench），暂时不适用于创意或开放域生成场景。
值得关注的后续
1. 生态扩展：Statewright 目前仅支持 Claude Code，但计划支持 Codex 和 Cursor。MCP 插件的接受度和开发者社区反馈将是验证其模式好坏的关键。2. 效果可重复性：目前公开信息显示，13B 参数以上模型效果显著，但 13B 以下模型导航状态机但无法保留足够上下文。这一“拐点”是否随模型代数变化值得追踪。3. 竞品反应：如果这一模式被大规模验证有效，主流 AI 代理平台（如 GitHub Copilot、Codela、Cursor）可能将状态机约束直接集成进它们的编排层，而非作为独立插件存在。
来源：hackernews
