AI编码助手没有智能问题,它们有的是运行时纪律问题。以下是我如何强制执行它。
摘要
一位开发者介绍了agent-rigor,这是一个开源框架,它将运行时纪律和传统SDLC机制强制应用于AI编码助手,以防止常见的代理失败,如范围蔓延和修复-前向循环。
我对代理IDE感到厌倦的确切时刻,并不是当它们幻觉出一个库的时候,而是当一个代理跳过了编写测试,盲目地修改了四个无关文件来修复一个bug,破坏了我的本地构建,然后花了15分钟在一个递归的"修复-前向"死亡循环中试图猜测出路。LLM具有巨大的原始智能,但它们缺乏人类几十年来培养的基本工程直觉。它们不规划,不检查已知的良好状态,也没有任何范围控制。我们决定不试图通过提示工程来绕过这种行为(随着上下文窗口的增长,这最终总会失败),而是将其视为一个架构约束问题。我们构建并开源了agent-rigor,这是一个框架,显式地将传统SDLC机制直接硬编码到模块化的"代理技能"中,LLM被迫执行这些技能。该仓库完全开源,技能原语设计为解耦的,因此您可以将它们插入到自己的自定义代理架构或包装器中。如果您正在这个领域进行开发,或者只是想让本地代理不再失控,请查看下面的仓库,如果您喜欢我们的作品,请点个星!⭐ [评论中的链接]
相似文章
AI 编码代理需要“先计划后编辑”的工作流程?征求反馈
一种为 AI 编码代理提出的工作流程,强调在代码编辑之前进行头脑风暴和执行边界约束,寻求社区对其实用性的反馈。
规格驱动的智能体编程正在悄然削弱我们监督智能体的能力
作者认为,过度依赖 AI 编程智能体会导致人类开发者逐渐丧失关键的技术直觉和代码审查技能,并提出了诸如强制手动编码日等措施,以维持监督能力。
编码代理的真正障碍不是代码质量——而是你是否能围绕它们构建一个可靠的循环
文章认为,AI编码代理的主要挑战不是代码生成质量,而是用户能否围绕它们构建可靠的循环,这将采用的障碍从模型能力转移到了工作流设计。
如何让代理运行数小时,以及哪些架构真正对代理友好?#深度探讨 #氛围程序员问题
作者探讨了AI编码代理的两个关键挑战:确保长时间自主执行(数小时)以及为本地应用设计对代理友好的架构。他们提出在规划和执行之前,增加一个显式的知识组织阶段来管理混乱的上下文。
在实际仓库中运行编码代理:代理写完代码后哪些环节会出问题?
本文讨论了工程团队在采用AI编码代理时面临的实际挑战,如任务安全性、上下文检索、输出审查和协调,并提出了一个用于评估的准备度模型。