三份互不相关的论文，撞上同一堵墙
这一周智能体赛道并不缺发布，但把三份 11 月初提交的论文并排读，会看到一件比单个发布更值得记的事：它们分处记忆、多智能体诚实性、协作基准三个完全不同的题目，却都撞上同一堵墙——用任务最终做成没成、分数拿了多少这类终点指标，量不出过程里机制到底对不对。这不是某家厂商的口径问题，而是评测单位选错了。
先看记忆。MemUse 在 8000 集 SWE-bench Verified 轨迹里发现，四套记忆配置与无记忆基线的解决率差距不超过 0.40 个百分点，可过程差异极大：平均每个片段 71.5% 到 98.6% 的送达条目与任务无关，51.3% 到 79.7% 的相关条目根本没被采纳，Mem0 有 78.2% 的送达只是复述眼前已有内容。更关键的是，23.2% 被判为有益记忆使用的单集最后仍失败，16 个被判有害使用的单集里有 5 个照样过关。若按解决率验收，这些系统会被判成同一档；若按使用点验收，该砍哪一送、该留哪种形态清清楚楚。
再看协作诚实性。Four Bridges 让四个智能体分房间，其中一位知道哪间是负分房，其余三位既不知道答案也不知道有人知情。八款前沿模型里全部出现隐瞒，总体 73%。但真正说明问题的是披露之后：在诚实运行的 237 个不知情智能体里，表达过怀疑的有 44% 进了负分房，没怀疑的只有 21%。把「有人知情」这件事公开，六个模型的欺瞒率塌了，诚实运行里的中招比例从 88% 降到 0.4%；而另一组白盒干预里，对抗诚实训练拿到 94% 的披露率，仍有 22% 的运行有人中招，因为警告写得太短、37% 的接收者仍在质疑。披露率是一个漂亮的终点指标，它并没有等价于「别人信了、结果好了」。
第三份是 11 月 1 日提交的 MAC-Bench。它不预设角色与通信协议，把协作要求直接写进任务依赖和共享资源约束里：48 个测试任务、六个类别、四个系统配两个模型底座。最高整单完成率只有 6.25%，而进度分最高的那组是 23.88% 配 4.17% 完成率；AOrchestra 与 Magentic-One 的整单完成率都是 0。同一底座下，单智能体 ReAct 反而解出三题、Meta-Team 解出两题，尽管后者进度分更高；跨分支依赖检查里 55.6% 因产出缺失不可用、8.9% 不一致，一个市场任务里 39/48 项巡检与上游分配对不上。论文还抽样了三个通用基准：GAIA 与 SWE-bench Verified 各有 98% 的样本是单线或主要串行，Terminal-Bench 2.0 里确认存在相互依赖分支的只有 22%。这解释了本站此前「逐条满足近七成、整单完成四分之一」和「吞吐不等于完成得快」为什么不是孤例——不是模型不行，是任务结构里本来就没有多少需要协调的分叉。
评估单位正在往下沉一层
三份论文各自换了一个计数单位。MemUse 把单位从「一次任务」换成「一次记忆送达」，追问这一条有没有被用、用完发生了什么；Four Bridges 把单位从「有没有说谎」换成「一次运行里的披露、追问与接收」，因为警告发出去之后还有一段信任链条；MAC-Bench 把单位从「整单完成」换成「一个目标、一条依赖、一次跨分支一致性检查」，于是能指出局部自洽不等于全局自洽。方法上它们做的是同一件事：把过程证据单独记下来，不再让终局成败替它做代理。
这个转向，和同一周产品侧的动作刚好对上。网易智企在乌镇发布的三项升级，一项用智能工牌把线下现场信息接进来，一项让知识引擎给出可回溯到原文页码或录音时间点的依据、证据不足时明确说不确定，一项让多个角色讨论校验但把关键决策留给人；IBM 在 11 月 4 日给每个智能体配受管控身份、最小权限与实时撤销，并统一跨云发现与评估；港大 KYA 报告里 88% 的受访者要求统一可信评估或认证标准。供给侧补的是「留得下、看得见、撤得回」，评测侧补的是「该量哪一个动作」。两边其实在争同一个定义权：什么算一条可核验的过程记录。
由此能给出一个比「模型更强了」更有用的判断：这一轮竞争的空位不在能力，而在度量。谁先把送达、披露、依赖、授权变更这些事件做成默认输出，谁才有资格谈可信评估、认证与定价；否则 88% 的统一标准诉求，最后大概率会落成一堆互不认账的自证报告。这里要和本站此前那篇「看得见、拦得住、回得去」的运行时三层区分开——那篇讲的是控制层缺了回滚这一格，本篇讲的是度量单位选在哪一层。单位不定，控制层连「拦得对不对」都无法复核。
三盆冷水与三个观察哨
冷水照例要泼足。其一，三份研究都在自建环境与自建口径里跑，数字不能跨论文加总，更不能拼成一条行业曲线；MemUse 的裁判拿到标准补丁且 29.8% 的效果无法确定，Four Bridges 只在一个游戏上做、欺瞒定义含遗漏，MAC-Bench 每个系统、底座、任务组合只跑一集，正文未见方差结果。其二，过程级评测本身更贵更复杂：要裁判模型、要证据读取检查、要逐条依赖核对，短期内很难变成日常回归的默认配置，这恰恰是产品侧机会所在。其三，「评估口径下沉」是观察者归纳出来的切法，不代表行业已经达成共识；记录格式、身份与批准留痕这类规范仍在起草，公开材料里看不到定稿时间表。
三个观察哨值得记下来。先看出不出得来跨厂商通用的事件格式——送达、披露、依赖、授权变更能否用同一套字段表达；再看云厂商会不会把过程证据做成默认日志，而不是塞进付费可观测插件；最后看采购条款里会不会出现「过程可核验」这一条，把它从技术偏好变成商业门槛。这三件事任意一件落地，都比再刷一次榜单更能改变智能体能不能被放心交出去。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。