每日AI新鲜事·10月15日晚间版：Agent标准与记忆层

今天AI圈又有不少新动静,而且我发现一个规律,最近大家聊的东西越来越往底层走了. 今天咱们主要聊这么几件. 一是多agent改同一文件,二是AnyPS5开源项目,三是Discovery Phase对比ChatGPT,四是PhotoCraft图片编辑器,五是agent互操作标准,六是上下文检索小技巧,七是Search Console的MCP服务器,八是Meta的记忆层. 嗯,这几条确实都挺有代表性的. 那咱们就按顺序来,先快速过一遍新闻,后半段重点聊聊标准和记忆这两块. 第一条,刚在dev.to上看到一篇文章,讲的是两个编程agent同时改同一个文件的问题. 作者的思路挺妙的,直接用Git自带的rerere功能,让系统把冲突只解决一次,以后自动复用. 这个角度很实际. 你想,现在多agent协作是常态,两个人同时改一个文件,合并冲突简直是噩梦. rerere就是reuse recorded resolution,之前记录过的解法,下次直接套用. 把Git的老功能翻出来治新问题,有点意思. 那这是不是意味着,多agent协作的基础设施,其实不用重新造轮子,老的版本控制工具就够用? 有一部分是. 但你再想想,agent之间的冲突不只是文本层面的,还有意图层面的,这个Git可管不了. 第二条,有个叫AnyPS5的开源项目,在dev.to上被人试用了. 做的事情是把PS5的可执行文件自动移植到Linux和Windows上,现在已经有三万七千多star了. 三万七千多star,这增长速度确实吓人. 不过我第一反应是,这里面法律风险不小吧. 对,我也想说这个. 开源是开源,但PS5的可执行文件本身就涉及索尼的版权,移植工具本身合法,用的人就不好说了. 所以这个项目火归火,真正能落地的场景其实挺窄的. 更多是技术演示性质. 第三条,有个对比挺有意思,叫Discovery Phase AI和ChatGPT的诚实对比. 作者说ChatGPT适合起草需求文档的某个片段,但整个发现阶段有十个环节,跨好几周,ChatGPT就管不住了. 这个观察很准. 通用模型是单点能力强,但流程一长,状态一多,它就散了. 专门做发现阶段的工具,核心优势不是模型更强,而是它把整个流程的状态给管住了. 所以你是说,垂直工具赢在流程管理,不是赢在模型能力? 对,至少在这个场景下是这样. 模型能力大家都能调API,但流程编排是各家自己的功夫. 第四条,又是个开源项目,叫photocraft,一个从零写的图片编辑器. star数更夸张,六万一千多. 完全开源,免费使用. 六万多star的图片编辑器,这个体量已经不小了. 不过我好奇的是,它跟AI怎么结合. 素材里没细说AI部分,但我觉得放在今天这个语境下,图片编辑器的想象空间肯定不只是手动调参数了. 对,如果它能接上图像生成或者智能修图的agent,那价值就完全不一样了. 第五条,这个我觉得是今天最有分量的一条. 有篇文章说,agent互操作标准在2026年变成了真正的基础设施层. 也就是说,不同厂商的agent之间怎么通信、怎么协作,已经有一套公认的标准了. 这个判断我认同. 你回头看,去年大家还在各搞各的协议,今年开始收敛了. 好了新闻就先聊到这儿,接下来我们深入聊聊两个话题,一个是上下文检索,一个是Meta的记忆层. 先聊上下文检索. 有篇文章标题就很吸引人,叫用八十行代码实现Anthropic的分块前缀技巧. 核心思路是在每个文本块前面加一段上下文说明,让检索的时候能更准地匹配到相关内容. 这个技巧的关键在于,它没有改模型,也没有改检索算法,只是在数据预处理阶段做了一个很小的改动. 但效果提升很明显. 因为原来一个文本块脱离了上下文,语义是模糊的,加上前缀之后,它的语义就锚定了. 那这个前缀是谁来生成的?人工写还是模型生成? 模型生成. 用一个小模型,把整个文档的摘要塞到每个块前面. 成本不高,但检索准确率能上一个台阶. 所以这算是RAG领域的一个微创新?不是说革命性的,但很实用. 对,而且八十行代码就能跑,门槛极低. 这种技巧最容易被社区接受,因为它立刻能用. 不过我有个疑问,如果文档本身就很长,每个块都加前缀,会不会把上下文窗口撑爆? 好问题. 所以前缀不能太长,一般就一两句话. 你是在检索阶段用,不是全塞给模型. 检索的时候用前缀来匹配,匹配到了之后,返回的还是原始块. 这样既提高了召回,又不增加推理成本. 明白了,就是检索用的索引和实际喂给模型的内容是分开的. 对,这个设计很聪明. 总结一下就是,分块前缀是个低成本高回报的RAG优化手段,核心在于用模型生成的上下文来增强检索索引. 接下来聊第二个深度话题,Google Search Console API的静默失败问题. 有个开发者说,你按国家代码us去查点击数据,返回零行,不报错,不警告,就是什么都没有. 这个太典型了. 静默失败是API设计里最坑人的模式,你根本不知道自己错了. 而且不止一种情况会这样,无效的正则、不符合RE2规范的正则,全都返回空,没有任何提示. 所以这个开发者就自己写了一个MCP服务器,在请求发出去之前先做校验. 本地运行,只读,开源. 如果参数有问题,它直接告诉你,而不是让Google悄悄返回空. 这个思路我觉得可以推广. 现在MCP服务器越来越多,但很多都是在做转发,真正做校验和增强的还不多. 对,这其实是一个产品思路. 不是去替代原始API,而是在前面加一层,把体验做好. 而且它是本地的,只读的,安全性和隐私性都没问题. 这种轻量级MCP工具应该会越来越多. 所以MCP生态现在是在往两个方向走,一个是连接更多服务,一个是在连接之上做体验优化. 对,后者可能才是真正拉开差距的地方. 总结一下就是,MCP服务器的价值不只是转发请求,更在于在请求前后做校验和增强,把静默失败变成明确反馈. 最后一个话题,Meta的Muse Wonder加了一个记忆层. 10月12号发布的,有一个百万token的上下文窗口,还配了十三页的模型卡. 百万token的上下文窗口现在不算稀奇了,但它的Active Memory功能是重点. 这个功能能把用户在乎的细节从一次对话带到下一次,然后在需要的时候把相关部分调出来. 这不就是长期记忆吗?之前很多产品都在做,但效果一直不太好. 对,长期记忆的难点不在于存,在于取. 什么时候该想起来什么,这个判断很难. Meta把它做进模型层,而不是外挂一个向量数据库,这个选择本身就值得关注. 那这是不是意味着,记忆能力以后会成为模型的基础能力,而不是应用层的附加功能? 我觉得是趋势. 你想想,如果一个agent记不住你上次说过什么,它怎么可能是真正的agent? 有道理. 但我也想到一个问题,记忆越强,隐私问题就越大. 用户说过的话,模型一直记着,这个边界在哪? 这个确实是接下来要面对的. 技术上能做到,不代表产品上就应该这么做. 不过从竞争角度看,Meta这一步是在补短板. 之前大家在agent能力上卷,现在开始卷记忆了. 所以总结一下就是,Active Memory把记忆从应用层拉到了模型层,这可能会重新定义agent的长期交互体验,但隐私边界还需要行业一起摸索. 对,而且我补充一句,记忆层加上agent互操作标准,这两件事加起来,其实指向同一个方向,就是agent正在从工具变成基础设施. 这个总结到位. 今天聊下来,我感觉整个行业确实在往底层走,标准、记忆、互操作,都是在打地基. 好了,今天就聊到这儿,明天见.