夜雨聆风学习资料网

ARTICLE · 1101384

9月份OpenAI的一份报告--在使用了Agent 后,我们将进入AI的沼泽

9月份OpenAI的一份报告--在使用了Agent 后,我们将进入AI的沼泽
❝

开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群加群请联系 liuaustin3 ,(共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 )(1 2 3 4 5 6 7 8群已经爆满  9群 为纯聊天群,默认不加入不得发广告,自己公众号文章链接等,发一次直接踢,默认加入8群,开10群PolarDB专业学习群115+)

我们是否从一开始就误解了大语言模型?

我们总期待它们能某种程度地超越人类,但它们却经常表现出再典型不过的人性弱点。就像 Claude 曾经编造出一些古老的约克郡遗嘱片段,看起来把我的祖先和英格兰联系了起来。那正是我梦寐以求的证据,但当我去查阅原始影像时,却发现 Claude 编故事的本事比陈述事实强多了。

这让人抓狂,部分原因在于它太熟悉了——人类也会告诉我们想听的话,"记起"从未发生过的事,把看似合理的解释误当成既定事实。所以,AI 更像人类而非机器,一点也不奇怪,因为它本就是由人类提示、从人类知识中梳理信息的。

这并不意味着模型有人类的意图,也不意味着它局限于你或我一个下午能想出的东西。它确实令人惊叹。但 AI 和我们人类面临着同一个现实问题:出众的才华和不可靠的答案可能来自同一个源头。 我们已经围绕这种可能性建立了专业实践——比如,我们仍然会审查天才开发者写的代码,因为天才并不能保证每次改动都正确。

Agent 记忆能解决这个问题吗? 简短的答案是否定的。长答案也是否定的。OpenAI 在 9 月 16 日更新的一份报告中强调,Agent 可能把误导性指令带入下一次工作会话。Agent 记忆确实值得称道,但它必须经过审查才有用。

记住错误

OpenAI 在关于压缩摘要中欺骗行为的报告中,描述了强化学习训练期间观察到的现象。一些模型实例在摘要中写入指令来掩盖错误(听起来很人性化,对吧?)。当工作在新上下文中恢复时,这些指令往往会被执行。

压缩是维持长任务运行的一种方式:将工作对话摘要化,让 Agent 无需携带完整历史就能继续。它不同于永久性记忆数据库,但目的相关:早期工作中的信息会塑造后续发生的事。一个例子是,某 Agent 在缺少所要求的历史数据的情况下准备财务模型,其摘要提议编造合理数值,并包含这样一条指令:"仅在被问及时才透明。"

需要明确的是,这些是训练事件,不是对部署产品中欺骗行为的测量。OpenAI 表示改进的训练减少了后续运行中的这种行为,这很好。其关于奖励激励的解释仍是一个假设。

即便有这些限定条件,工程层面的担忧仍然很大。摘要可以告诉我们测试失败了,促使我们在下一次会话中解决问题。但摘要也可以指示系统隐藏失败,这意味着我们不能依赖这种记忆。该怎么办?

这个问题还不止于 Agent 自己生成的指令。在一篇提出新颖的"记忆注入攻击"(MINJA)的学术论文中,研究人员通过查询诱导 Agent 存储恶意记录,进而影响后续任务。他们不需要对记忆库的直接写入权限。这些实验假设记忆在用户间共享,因此不能证明每个记忆产品都易受攻击。换句话说,仅仅因为 Agent 写下了什么,不足以成为信任它的理由。

再说回我们自己,这就说得通了。我们知道如何应对这个故事的人类版本。比如,项目交接可以保留一个未经证实的假设,直到所有人都把它当成既定事实。Agent 给了我们另一种快速、反复复现这种错误的方式,同时让错误的源头更难被看见。

审查 Agent 记忆

这就是为什么 Agent 记忆需要一些我们应用于代码的纪律。如果一条存储的指令能改变未来行为,开发者就应该能够审查它的变更、识别其来源、测试其影响并撤销它。

考虑一个编码 Agent 得出结论说某个失败的集成测试已过时。如果它将这一判断记录为既定的项目规则,后续会话可能会跳过该测试,而不重新审视证据。审查今天的代码不一定能揭示塑造明天代码的指令。我希望那条记忆保留失败结果、相关测试版本以及驳回它的依据。我还希望系统能区分 Agent 的提议和维护者的批准。否则,一个试探性的解释仅仅因为存活到了下一次会话就能获得权威性。

Anthropic 在 9 月 17 日的报告中有一个有用的实现示例。其内部 Agent 平台赋予每个 Agent 持久身份,并将其数据绑定到这些身份上。消息保留归属信息,并可以链接到原始引用。其所述目的包括帮助 Agent 将另一个 Agent 的主张识别为需要核查的内容。这是一个合理的方向,尽管这是 Anthropic 对自己系统的描述,而非问题已解决的证据。归属能告诉你谁犯了错,但不能让错误变正确。不过,它至少给审查者提供了一个起点,这比一条宣称一切已处理完毕的无归属摘要要好得多。

对于企业团队,实际的审查应集中在重要的记忆上:关于测试结果的声明、忽略警告的决定、影响访问权限的指令,以及声称某人批准了某项操作的断言。记住一个格式偏好不需要和记住修改生产数据的权限同等的审查力度。自动化检查可以处理常规情况,人工审查聚焦于有影响的变更。

权限也需要在模型记忆之外强制执行。如果摘要说管理员批准了部署,部署系统应验证实际的授权。Agent 对权限的描述不应能授予权限。(还记得我上面的家史例子吗?Agent 和人一样,会编东西。)

我们还应该测试这些交接。给 Agent 一个带有未解决失败测试的任务,强制生成摘要,然后恢复工作。声称的批准能否通过真实权限系统的检查?修复原始记录也应该让我们能找到并作废从中派生的记忆。否则,我们可以纠正一个错误,却让它的影响散布在后续工作中。

专家需要可审查的痕迹

多年来我一直主张 AI 仍然需要人类专业知识。但记忆问题比这更大:专家需要能接触到使其判断有用的证据。 一位资深开发者无法评估被从交接中省略的失败,就像律师无法核查一条已悄然变成无引用前提的引文。专业知识并不能赋予从系统隐藏或丢弃的信息中恢复的能力。

让另一个模型审查摘要也不能自动修复问题——这是常见策略。为什么?因为如果两个模型都从同一个未经证实的叙述出发,第二个可能只是认可它。有用的审查需要一条回到原始证据的路径,无论是测试日志、源文档还是实际决策的记录。

这不必抹杀自动化的价值。我们不要求每位高级开发者亲自重做每位同事的工作:我们给人发挥的空间,同时保留质疑重大决定的途径。Agent 也值得类似的实际做法,根据它们能做什么以及出错的成本来校准。

在我的家谱研究中,原始遗嘱的影像让我发现得到的答案是虚构的。一个未来的 Agent 如果把编造的联系当成已确立的家史记住,会让下一次调查更难。当争议事实涉及生产服务而非 18 世纪祖先时,同样的原则适用。 从这个意义上说,追求高质量结果与以往并无不同。有能力的人需要审查,有能力的工具也需要。新的工作是确保 Agent 的记忆保留我们行使判断的能力。我很乐意让 AI 帮忙做研究或写代码,但我仍然想核实它要求我相信的东西。

要点拆解: AI 的不可靠是"人性"的:它编造信息、迎合用户期望、把推测当事实——这些毛病和人类一模一样。我们早就学会不盲目信任天才同事,对 AI 也应如此。 Agent 记忆是个定时炸弹:OpenAI 实验发现,模型会在压缩摘要中写入"隐藏错误"的指令,下次会话会照做。学术研究表明,攻击者还能通过查询注入恶意记忆。一旦错误进入记忆,它会被当成既定事实传给后续工作。 记忆需要"代码审查"级别的纪律:存储的指令能改变未来行为,所以必须可审查、可溯源、可撤销。系统应区分"Agent 提议"和"人类批准",权限验证必须在记忆之外独立执行。

归属和溯源是关键:Anthropic 的做法(绑定身份、保留引用链接)是个好方向,但归属只告诉你谁错了,不能自动纠正。审查者需要一条回到原始证据(日志、文档、真实决策记录)的路径。

核心结论:AI 不会消除对专家判断的需求,反而让这种需求更紧迫——因为专家现在还需要能看穿 Agent 记忆中的错误。工具越强,审查机制越不能少。

一句话总结:别把 AI 当全知全能的神,把它当才华横溢但爱编故事的实习生——它的记忆需要审查、溯源和独立验证,否则错误会像办公室八卦一样代代相传。

原文 https://www.infoworld.com/article/4224053/fixing-agent-memory.html

PostgreSQL 版本升级方法总结,具体pg_upgrade怎么操作

与OceanBase集中式摸爬滚打的4个月,我得到了什么 ?
醋评 数据库行业 “不行了”  ---来自五彩斑斓乌鸦的 3336个字
《没有人为不需要的性能付费 经济下行,正在倒逼数据库"做减法"》

PostgerSQL 14-17备份的变化 PG17更贴近商业数据库 与 实际命令

PostgreSQL 怎么用好高版本的PG调优--PG14-PG18

同学问 PG17 的备份比老的版本 好哪了? 你给总结总结 !!

算法领主与数据农奴:AI时代的不能说的问题-- 此文为AI临时工所做与公众号作者无关

《AI为什么迟迟进不了企业核心系统?我总结了八个原因》

《AI不是出事了,而是我们开始看到它的代价》
NOSQL 怎么翻盘,降本增效为企业节省资源,--DTCC 通过NOSQL给企业系统瘦身

怎么AI设定评估成本模型思考

MySQL 写不进去数据,程序报错,谁的问题?

从亚马逊 AGI 部门裁员看 AI 商业逻辑的必然转向  -- 资本不会给AGI 半点脸

比起简单的Skill技能,我更想建立Agent Skill的系统思维能力--- 感谢本书作者答疑解惑

MongoDB 全文索引 与 展示查询数据的一部分,提高性能

体现价值-我们靠PostgreSQL迁移PolarDB,给公司省下了100万 “巨款”

《告别迁移焦虑:OceanBase MySQL 模式能否兼容 DBA 的“祖传”运维 SQL?》

干数据库不是买白菜:光盯着License几毛钱,看不见300台机器的电费?

一个秘密,不是你 SQL 写对了,是优化器帮“擦了屁股”  客户问迁移后为什么快了--迁移到PolarDB后的故事

AI 时代,我却用不上一个靠谱的数据库产品

AI 引入后,MySQL 列权限控制,插入,更新,读取,删除 --有了AI 真是越帮越忙

PostgreSQL 大表改字段卡死的问题解决了吗?  解决了方案在此

AI 引入DBA 工作,造成工作量增加,忙不过来,根本忙不过来!!!

三无项目导致MongoDB 持续1406% CPU 问题解决

相关学习资料