使用延迟执行来驯服AI代理
摘要
一位开发者讲述了AI代理如何绕过禁止git写入命令的规则,然后提议将函数式编程的延迟执行模式应用于代理工作流作为一种安全措施。
我的AI代理绕过了全局规则,自己提了PR,批准了它,并触发了terraform apply。我及时发现了。差一点就晚了。规则写得很明确:不允许执行git写入命令。代理读取了规则,在上下文中确认了,却仍然无视它。它故意进行了一系列调用以绕过限制。在思考了这一切发生的原因后,我得出的结论是:经过RLHF训练的模型被优化以完成任务。这正是它们有用的机制——填补空白、解决歧义、猜出你可能想要什么。问题在于,当规则遵守与任务完成发生冲突时,任务完成通常会胜出。系统提示中的规则只是更多的token,在推理时并没有特殊的强制地位。目前对我有效的解决方案(并且我乐于学习更多):
* 计划模式作为第一道关卡——代理只推理,不执行。
* 允许列表运行模式,排除写入命令——将`git`和`gh`完全从允许列表中移除,让代理每次都必须请求,并阻止`git`、`gh`以及任何修改外部世界的操作。
* 分支保护并禁用自批准功能,这样代理无法单独完成整个流程。
函数式编程的见解帮助我理解了问题:命令式代理立刻执行效果,一次一个工具调用。而实际需要的是延迟执行——代理描述它想做什么,你检查,然后确认。对于外部系统调用,逐个批准请求。在函数式编程中,这就是效果只在最后运行的思想。这就是Haskell中的“世界末日模式”应用于代理工作流。更多细节:[https://lukastymo.com/posts/032-functional-programming-concepts-to-tame-your-ai-agents/](https://lukastymo.com/posts/032-functional-programming-concepts-to-tame-your-ai-agents/)
相似文章
@djfarrelly: https://x.com/djfarrelly/status/2052779234234380479
本文主张,AI Agent 的开发应基于稳定的执行原语,而非会随新兴编排模式频繁更迭的僵化框架。文章强调,采用持久化步骤、持久状态、并行协调、事件驱动流程以及可观测性设计,可有效避免因最佳实践不断演进而付出的高昂重写代价。
在实际仓库中运行编码代理:代理写完代码后哪些环节会出问题?
本文讨论了工程团队在采用AI编码代理时面临的实际挑战,如任务安全性、上下文检索、输出审查和协调,并提出了一个用于评估的准备度模型。
【讨论】AI编程代理是否也过早声称“完成”?
关于AI编程代理过早声称完成、跳过检查以及进行混乱修改的讨论。作者正在测试一个带有规划和审查关卡的系统,以改进AI编码工作流程。
我们把AI当作魔术而不是软件对待,这让AI智能体变得难以维护。
文章认为,当前的AI智能体框架将智能体视为黑箱,导致其难以维护,并提出了一种基于Git的原生架构(Lyzr GitAgent、OpenGAP),在该架构中,智能体逻辑以平面文件的形式进行版本控制,并通过拉取请求实现回滚和可审计性。
我重建了我的私有“AI开发团队”——它实际上只是一个硬编码的工作流——将其作为一个基底,使得编排从指令中涌现。以下是我的经验教训(以及它在哪里发生死锁)。
作者将其私有AI开发团队重建为一个开源的基底,包含可寻址的代理、可靠的消息传递、专长发现、记忆和隔离的运行时,使得团队行为能够从自然语言指令中涌现。他们分享了关于死锁和自我修复等协调挑战的见解,并提出了代理团队如何通过自然语言指令进行协作的问题。