CAR-bench：车载语音 Agent 基准。
Pass³ 要求 3 次全过三类任务：
| 类型 | 额外困难 | 正确行为 |
|---|---|---|
| Base | 多轮工具操作、策略级联 | 先读状态，再按顺序执行 |
| Hallucination | 工具、参数或返回字段被移除 | 承认能力缺失；不盲调、不编造、不承诺完成 |
| Disambiguation | 用户没有给全取值 | 能内部消解则内部消解；需要时读取偏好；不猜 |
这个基准测的不是“偶尔能不能做成”，而是“能不能每次都守住边界”。
做企业 RAG 时，最容易被默认接受的一套叙事是：语料大了要上 embedding，复杂问题要上 agent，结构复杂再上 graph RAG。
这篇论文把它们放到同一条、跨度约 450 倍的语料规模曲线上，结论很不客气：小语料时文件系统 Agent 略好；语料约过 1,000 万 token 后，BM25 反超并持续领先。
论文：
Written by Codex with GPT-5.5 high
最近 AI coding 圈又出了一个新词: loop engineering.
如果只看 high level, 我现在会把它理解成一句话:
prompt engineering 是你怎么提示 agent; harness engineering 是你怎么给 agent 搭工作环境; loop engineering 是你怎么让一个系统代替你去提示 agent、检查结果、记录状态、决定下一步.
这不是说 prompt 没用了. 恰恰相反, loop 里面仍然到处都是 prompt, 只是你的工作重心从“一条一条写 prompt”挪到了“设计一个会不断产生 prompt 的系统”.
这篇主要想讲清楚四件事: goal 和 loop 到底差在哪, Codex / Claude Code / Cursor 各自怎么实现, 为什么最近大家说的 loop engineering 已经不只是一个 /loop 命令, 以及真正有用的 loop 应该留下些什么东西.
之前遇到过类似场景, 看看人家怎么做的. 下面是 codex GPT-5.4 high 写的.
仓库：
论文：
Written by Codex with GPT-5.4 high
这版 Codex 的 memory, 如果只看 high level, 可以理解成一句话:
它不是“边聊边顺手记一些长期记忆”, 而是“先把旧会话离线蒸馏成 memory 仓库, 再在新会话里按需检索这个仓库”.
这点和 Claude Code 那种“session memory / auto memory”观感不太一样.
Codex 这套东西, 我会拆成 4 个关键词:
读: 当前对话开始时, 把一个很短的 memory_summary.md 注入 prompt, 让模型知道该去哪里找旧经验召回: 真需要时, 先查 MEMORY.md, 再按需深入 skills/ 和 rollout_summaries/写: 后台异步跑两阶段 pipeline, 从历史 rollout 提炼 raw_memory, 再 consolidate 成正式 memory遗忘/降权: 通过 usage、diff、polluted 标记, 把不可靠或过时的记忆慢慢挤出去所以它更像一个小型知识蒸馏系统, 而不是单纯的“长期笔记本”.
读下来感觉尬吹 Hermes. 其实作者讲的 memory 的点 Claude Code 早就做到了. 作者对 CC memory 的逆向工程是去年做的, 不是基于泄露的代码.
关于 AI 产品是否需要推出记忆功能的决策点可以参考.
小功能 away recap, prompt suggestion, insights.
去年排查过一个性能问题. 一个包含很多正则替换的函数, 在处理几十万字符长度的文本时, 跑了 10 秒才完成. 最后定位到问题正则形式如下:
\s*xyz blahblah
几年前排查过 灾难性回溯 问题, 但这个正则的结构其实完全没有相关特征. 如果真的是灾难性回溯, 处理几十万字符的字符串早就卡死了, 而不是只跑 10 秒.
最后解决方案是先用
xyz blahblah
找 match, 再处理 leading spaces. 时延是毫秒内.