★ 后续：《指责模型无法修复工作流程》：论文现已发布为预印本。真正的收获：可组合域、验证棘轮与工具命名。

一个月前，我发布了一篇论文的非常粗略的初稿。那个粗略版本没有保留下来：它被它描述的过程本身拆解并重建，最终的结果现在是一份带有 DOI 的正式预印本：https://doi.org/10.5281/zenodo.21139628。简而言之：核心主张得到了验证。工件（规范、计划、可执行图）及其周围的验证门控在实际工作中得到了验证。智能体产生工作，门控捕获缺陷，只有证据真实存在时里程碑才会关闭，而不是模型宣称完成时。说实话，构建这个系统的过程中，头条结果并不是我得到的最有价值的东西。我真正想传递的是我在实现过程中学到的三件事。 第一是可组合域。在我的设置中，一个“域”是一组指令、技能和工具访问权限，你将其交给智能体用于一类任务。我最初构建的几个域都是一次性的。当我重新设计它们使其可组合（干净地叠加，不彼此假设）后，它们开始在我未计划的地方发挥作用。为一个工作流编写的域直接原封不动地应用到另外两个工作流中，同样的模式现在正支撑着一个完全不同的应用构建。下次我会优先考虑为组合性而非单一用途进行设计。 第二是棘轮，这需要一个具体例子。一个智能体曾经交付了一个负载测试，断言记录数大于或等于零。永远绿色，捕获不到任何东西，而且在审查中看起来完全正常。所以现在的循环是这样的：在代码存在之前编写验收标准，编码智能体从不编写测试，一个新的会话根据那些标准验证代码，然后另一个会话从中推导出回归测试，最后一步故意破坏代码以确认每个测试确实能够失败。通过这样测试的测试就会被冻结，后续工作将基于它运行，并且不能静默地撤销它。标准只能单向移动。这消灭了整整一类“看起来完成，实际未完成”的问题。 第三更简单也更令人惊讶：工具命名的重要性远超预期。智能体根据工具的名称进行路由，而名称会带上模型训练的先验知识。解决问题的诀窍从来不是聪明：借用模型已经知道的工具名称，完全镜像内置参数词汇（将参数名从 `code` 改成 `content` 就消除了一整类反复调整），并且永远不要让熟悉的名称对工具的功能撒谎。关键是：强大的模型会吸收糟糕的接口并隐藏问题，所以要用能完成工作的最弱模型来测试你的工具表面。 以上所有内容都作为一个开源参考实现运行：编排器、验证周期、可组合域。先说清楚，这不是又一个 180 行的智能体循环。这是一个经过反复打磨直到有用而不是可发布为止的设计的第三代，最近才赢得日常使用地位。它也通过了自用测试，因为系统自身的开发都通过自己的门控运行，它捕获过的最深的 bug 就在它自己身上。在点击之前提醒你：它是 Common Lisp。https://gitlab.com/naive-x/experimental/cl-naive-full-stack-agentic-system 预印本在这里，如果你想要正式版本：https://doi.org/10.5281/zenodo.21139628。欢迎提问。还有一个值得向任何由智能体编写的套件提出的问题：上一次测试因捕获错误代码而失败是什么时候？我之前无法回答我自己的这个问题，而这就是一切的起点。