自愈智能体只是一个你忘了构建的循环 [博客]
摘要
一篇关于自愈智能体简单模式的博客文章:使用生命周期钩子读写经验教训,并用护栏防止错误信念固化。
你的智能体运行了一个 Supabase 查询,得到 200 OK 和一个空数组,于是断定这一行不存在。其实它是存在的——只是被 RLS 过滤掉了。十分钟白白浪费了。下一次会话:同样的查询,同样错误的结论,同样的十分钟。你不是在为一次错误买单,而是在为它交房租。我把修复方法写了下来,它无聊得令人安心。没有微调,没有 embeddings 流水线。在你的智能体已经触发的生命周期钩子上有三个动词:在 SessionStart 时读取相关经验教训;Fail 时——工具调用出错,匹配的先前经验教训会在重试前被注入;在 Stop 时写一段简短的回顾。我真正花时间的地方不是写这些,而是给这些书写加上护栏。一个存储自己结论并回读的循环,也可能说服自己相信某个错误的东西,并永远捍卫它。那不是学习,那是带有数据库的迷信。所以:经验教训只是建议性的,绝不能自动禁用某个关卡;晋升需要重复出现(seen_count >= 3);所有内容大约 90 天后过期;矛盾会浮出水面,而不是被默默覆盖;隐私预检会丢弃任何携带秘密的内容。对于边界情况我也很坦诚——匹配器是字面子串匹配,而不是语义匹配,所以它不会把两条用不同措辞描述同一件事的经验教训联系起来。这是刻意的权衡:确定性、零依赖、无推理开销。很好奇其他人是如何处理这个根深蒂固的问题的——如果你的智能体自己写经验教训,什么能阻止它学到错误的东西?
相似文章
构建自修复智能体循环(39分钟阅读)
本文介绍了一种使用OpenAI的Codex构建自修复智能体循环的方法,智能体通过结构化反馈循环迭代地审查、修复和验证输出,并提供了一个修复过时API文档的实例。
生产环境中无人警示的"自愈"智能体的阴暗面
在AI生产智能体中,无约束的自愈错误循环会在模型将硬性业务规则违规视为暂时性故障时,悄无声息地损坏数据,导致逻辑债务积累,而传统监控难以发现。文章主张采用严格的电路断路器,强制语义性错误显式失败。
使用MCP和可观测性构建自愈代理
一个自愈代理的演示,它利用可观测性(Monocle)和MCP来调试和修复一个损坏的应用程序,通过检查遥测数据和运行测试,将可观测性视为代理循环的一部分。
智能体循环很棒,直到它们从你最糟糕的代码中学习
本文讨论了AI编码智能体循环如何在不经意间从现有代码库中学习并传播已弃用的代码模式,导致技术债务,尽管表面看起来很成功。
构建智能体让我明白,模型很少是问题所在。你有哪些来之不易的教训?
一位开发者分享了构建AI智能体的来之不易的教训:优先关注工具设计而非模型选择,使用小循环而非大型提示,记录智能体上下文,尽早添加防护措施,以及创建小型评估来捕捉错误。