责怪模型无法修复你的工作流——关于AI智能体结构性约束的白皮书
摘要
一份白皮书,识别了AI智能体工作流中的24种失效模式,并提出了一种包含三层约束、任务图和验证的结构性约束架构,以及一个基于Common Lisp的参考实现。
我一直在做一些别人可能会感兴趣的东西。目前还处于大量开发阶段,我边学边做。大多数AI智能体设置将模型视为更好的自动补全工具——粘贴提示词,获取输出,希望它是正确的。这对小任务有效。但当你想让智能体跨会话持续工作时,它就会崩溃:它们浏览规格说明,在完成60%时就宣布胜利,在噪音上消耗上下文,默默地解决歧义而不将其暴露出来,并且标记清单项为已完成但实际上并未完成。这些失败是可预测且可命名的——所以我给它们命了名。这是一份关于全栈智能体系统的白皮书和实施指南——从规划到在结构性约束下提升的整个过程。它记录了数月多智能体操作中出现的24种失效模式,并针对每种模式描述了实际预防它的方法:有些通过智能体无法跳过的机械门控,有些通过程序性技能,有些通过人工监督。该指南涵盖了如何构建规格说明、计划和验证,以使智能体工作以证据为导向而非以感觉为导向,如何将MCP能力表面用作结构性杠杆,以及这些失效模式如何适用于你使用的任何模型或供应商。白皮书还包括一个相关工作部分,将其置于新兴行业共识的背景下——CodeRabbit、Anthropic、Spotify、Cloudflare、OpenAI、Karpathy、Thoughtworks以及学术研究都独立得出了部分相同的结论。这里的不同之处在于集成的堆栈:一个映射到预防机制的失效分类法,一个三层约束架构,以及一个包含编排器、任务图、步骤验证、对抗性审查和模型分层的具体参考实现。白皮书:[https://gitlab.com/naive-x/naive-artifact-coding/-/blob/main/white-paper.md](https://gitlab.com/naive-x/naive-artifact-coding/-/blob/main/white-paper.md) 参考实现:[https://gitlab.com/naive-x/naive-artifact-coding/-/blob/main/docs/reference-implementation-guide.md](https://gitlab.com/naive-x/naive-artifact-coding/-/blob/main/docs/reference-implementation-guide.md) 实施指南:[https://gitlab.com/naive-x/naive-artifact-coding/-/blob/main/implementation-guide.md](https://gitlab.com/naive-x/naive-artifact-coding/-/blob/main/implementation-guide.md) 该方法是语言无关的。参考实现使用Common Lisp,但架构(编排器、监督器、MCP服务器、任务图、事件发射)并不假设任何特定的语言或领域。还有配套的规范用于适配企业工作流。
相似文章
你的代理失败不是因为模型,而是因为没人构建一个停止按钮
文章认为,AI代理在生产中的主要失败点并非模型本身,而是缺乏基础设施,如停止按钮、账单监控以及工具调用的可追溯性。
AI代理的失败方式鲜有人论及。以下是我亲眼所见。
文章强调了AI代理工作流程中实际的系统级失败,例如上下文泄漏和幻觉细节,认为这些通常是基础设施问题而非模型缺陷。
AI 智能体开始暴露出大多数工作流程原本就已支离破碎的事实
文章认为,AI 智能体揭示了企业工作流程实际上是多么缺乏结构和混乱不堪,暗示成功的自动化更多取决于整洁的系统和完善文档,而非先进的模型。
我们的大部分“智能体”问题实际上是工作流/状态问题
一位开发者讲述,构建AI智能体时的许多挑战实际上源于工作流和状态管理问题,而非模型智能,强调了稳健的状态处理和可观测性的必要性。
★ 后续:《指责模型无法修复工作流程》:论文现已发布为预印本。真正的收获:可组合域、验证棘轮与工具命名。
作者宣布了一份关于构建具备可组合域、验证棘轮及精细工具命名的智能体系统的预印本,分享了实践教训和一个开源的 Common Lisp 实现。