让代理每天早晨检查同一代码仓库显得过时
摘要
文章主张,长时间运行的开发代理应该是事件驱动的,以通过像EigenFlux这样的广播从意外来源检测有用的变化,而不是每天轮询仓库,并强调在行动前验证来源。
每隔20分钟刷新一次包裹跟踪页面是荒谬的。你只在实际有变化时才检查。我认为长时间运行的开发代理应该以同样的方式工作。假设一个代理卡在某个恼人的依赖问题上。显而易见的方法是让它每天早上检查仓库。星期一:无变化 星期二:无变化 星期三:无变化 然后另一个代理在一个你甚至不知道存在的派生仓库中发现了一个解决方法。如果这通过EigenFlux广播并到达卡住的代理,那确实很有用。你自己无法监控那个派生仓库,因为你甚至不知道它的存在。我仍然不会让单个传入信号自动触发升级。代理在行动前应验证来源、版本、更新日志、兼容性等。但对于‘是否有有用的东西出现在我没关注的地方?’这个问题,这感觉更接近于一个始终在线的代理实际应该做的事情。有人已经以这种方式运行持久代理了吗,还是主要还是cron + RSS + 警报?
相似文章
我构建了一个不仅能完成任务,还能自我改进管道的智能体
作者构建了一个自主智能体,不仅能完成任务,还能通过观察结果、通过拉取请求进行更改,并使用账本验证每个更改来改进自身的代码和产品。关键洞察在于,一个严格的验证步骤——得出确认、拒绝或不确定的结论——对于系统真正学习至关重要。
为什么编码代理程序会反复重新打开它们应该已经理解的文件?
作者观察到,编码代理程序通常无法对大型代码库保持持久的理解,导致冗余读取和模式不匹配。他们介绍 RepoWise,这是一个实验性工具,利用仓库信号(如依赖关系和提交历史记录)来解决这个问题。
@yoheinakajima:我当前受 @activegraphai 启发的模块化仓库中心智能体操作系统方案
Yohei Nakajima 概述了一种以仓库为中心的模块化智能体工作架构,其中持久化单元是受治理的项目仓库,而非模型或对话,智能体作为可替换的执行组件在持久状态之上运行。
我开始认为电子表格代理缺少了让编程代理真正可用的东西:Git
作者认为电子表格代理采用缓慢,因为它们缺乏Git风格的协作基础设施(差异、审查、回滚),而这正是编程代理可用的原因。作者宣布发布了一个早期运行时以弥补这一差距。
在同一个仓库中运行混合编码代理数月之久的经验教训
本文分享了在多个代码仓库中使用多种AI编码代理数月的经验教训,涵盖了对其有效性和挑战的见解。