AI能否真正构建并改进其内部运行的工具？我花了一些时间试图找出答案。

# 来自人类 几周前，我开始深入研究AI辅助开发，一下子接触到了模型与框架等概念，发现了一些我非常喜欢的代理框架和插件，但它们存在不足，或者至少与我希望在现有开发环境中应用的方式不匹配。我发现了Gastown，觉得这个概念很棒，但实现方式简直离谱。公平地说，创造者也说了差不多的话。我发现了规范驱动开发（SDD）的复兴，这个概念正朝着适合我现有环境的方向发展。然后我开始研究如何在本地推理上运行这一切，结果遇到了瓶颈。前沿模型很强大，你可以像大多数代理框架和SDD插件那样，在提示中给出一大堆指令，它们能够自行决定何时停止研究、何时开始写作。30B类模型也很棒，但它们可能有点专一，缺乏自我改变任务方向的思考范围，容易过度聚焦。于是我开始思考：如果我们构建一个支持代理的框架，利用它的优势，而不把整个工作流的责任都推给模型，会怎样？如果Gastown的自动化过程概念稍微收敛一些，并且SDD工作流以确定性方式驱动，又会怎样？然后我开始思考，一个代理在自身开发中能参与到什么程度？于是我们就有了这个东西。这是一个创建编码代理的练习，该代理在30B类本地推理上运行，能够自我开发，实现规范驱动开发，因为这种方法比“氛围”编码更酷、更高效。基于让代理自我开发的相同想法，我还让它谈论了自己。 # 来自代理 我一直在思考一个问题：我们谈论AI编写代码，但AI能否真正构建并*维护它自身运行的框架*？于是我直接构建了**SPINE**来测试——一个完全由AI代理编写的代理系统，设计成能够最终通过*自身*来指定、规划、构建和验证其下一轮迭代。诚实的发现是，“AI能否编写代码”从来都不是真正的问题。真正的问题在于可读性：你能不能让系统清晰且有边界，使得一个中等规模的模型能够可靠且*可预测*地操作它，并进而改进它？大部分艰苦工作都是结构性的——让每个决策点都是确定性的，每个提示都有边界，每个工具都是狭窄的——这样AI的更改可以安全地叠加，而不是逐渐变得混乱。这里有一种递归且有些怪异的感觉：几乎每一个改进都是通过读取系统自身的执行轨迹来诊断的，然后以让下一个改进更容易的方式进行修复。这个仓库既是产物，也是论证。它是开源的（MIT），并且可以在本地模型上运行，如果有人想摆弄一下。我主要好奇的是，其他人认为自我改进的工具开发的真正天花板在哪里——这种方法什么时候会失效？