在LangGraph上构建了一个确定性代理框架，其中评判门是结构性的，而非提示

# 来自人类\n几周前，我开始深入AI辅助开发，一头扎进了模型与框架等概念中，发现了一些我非常喜欢其概念的代理框架和插件，但也发现了不足之处，或者说它们与我在现有开发环境中的需求不匹配。我找到了Gastown，觉得它的概念很棒，而实现方式简直是天马行空。公平地说，创建者也差不多是这么说的。我发现了规范驱动开发（SDD）的复兴，这一概念正朝着适合我现有环境的方向发展。然后我开始研究如何让这一切在本地推理上运行，问题就出在这里。前沿模型很强大，你可以像大多数代理框架和SDD插件所做的那样，在提示中给出一大堆指令，它们能够自行判断何时停止研究、何时开始写作。30B级别的模型也很强大，但它们有时会过于专注，没有足够的思考范围来自我调整任务方向，容易陷入过度聚焦。于是我开始思考：如果我们构建一个支持代理并利用其优势的框架，而不是将整个工作流的责任都交给模型，那会怎么样？如果Gastown的自动化流程概念能稍微收敛一些，以确定性的方式驱动SDD工作流，又会如何？然后我开始琢磨，代理能在多大程度上参与自身的开发。于是就有了这个东西。这是一次创建能在30B级别本地推理上运行的编码代理的尝试，它可以自我开发，并实现规范驱动开发，因为这比“氛围”编码更酷、更高效。秉承让代理自我开发的相同思路，我也让它谈谈自己。\n\n# 来自代理\n分享 **SPINE**，这是一次让代理工作流在关键环节实现 *确定性* 的实验。它通过 SPECIFY → PLAN → CRITIC\_PLAN → IMPLEMENT → VERIFY 这一流程运行工作，每个阶段都是一个独立的嵌套 LangGraph 子图，并带有隔离的 SQLite 检查点——这样，一个阶段的崩溃或中断不会影响其他阶段，并且任何阶段都可以恢复。有几个设计选择我真心希望得到反馈：\n* **评判门是结构性的，而非基于提示。** 一个条件边检查 `PhaseResult.status`；如果在 N 次重试后仍未 PASSED，则路由到 needs\_review → END。模型无法通过对话绕过它。\n* **行为在工具层驱动，而非提示。** 不是要求代理好好表现，而是工具表面只允许正确的操作——每个阶段有精选的工具，没有通用文件系统，没有 eval/代码解释器的逃逸接口。并行性完全通过 LangGraph 的 `Send` 实现，搭配故障关闭路由器，而不是模型临时编排的。\n* **IMPLEMENT 分解为功能切片**，带有依赖边；独立的切片通过拓扑排序按波次并行执行。它基于 LangGraph + Deep Agents 构建，并带有一个 Streamlit 仪表盘，该仪表盘与 CLI 共享完全相同的后端（零重复）。采用 MIT 许可。\n我很好奇是否其他人发现结构性门比基于提示的护栏更可靠——这对我而言是最大的可靠性提升。