无人监督的上限涨了 288 倍，而模型没换

速览

以下内容全部出自 Notion 自己的公告与帮助中心，日期为 2026 年 10 月 19 日。撰稿时不存在任何对其中任一项的独立测量。

关于这次发布的报道称它是这套 harness 的第六代。这个细节比那个小时数更要紧：一个模型周围的脚手架被重建六次，才换来无人监督时长 288 倍的变化，而这六次重建里没有一次是你能从模型供应商那里买到的东西。

为什么旧上限是 5 分钟

5 分钟的上限不是对模型耐力的陈述。它是"回合在一个请求内部执行"的签名——HTTP 请求、serverless 调用、websocket 会话——在那里，平台自身的超时就是硬性终点，而一旦进程消失，这份工作无处可去。模型根本不知道、也不在乎过去了 5 分钟。这个约束完全属于那个握着循环的东西，这正是智能体 harness一直在讲的那件事：脚手架拥有权重所没有的属性。

Notion 描述用来取代它的东西是标准答案，而"标准"本身就是优点。每个会话跑在一个专属服务上。任务进队列。一个工作循环一次走一步，并把进度写到比工作者活得更久的地方，于是重启意味着继续而不是重来。这就是持久状态与可恢复性，与LangGraph 加 Temporal里讲的那些持久执行引擎同形——一个各步骤可对日志重放的工作流。

值得照抄的不是架构，那早已被充分理解。值得照抄的是这个认识：无人监督的上限从一开始就不是一个能力问题，所以移动它的工程就是普通的分布式系统工程，带着一笔众所周知的代价——一旦步骤会重放，智能体能执行的每一个副作用都必须幂等，否则一次恢复会把一封邮件变成两封。幂等与重试就是持久性寄来的账单，而它在你上线工作循环的那天就到期，不是在第一次重放发生的那天。

三个机制，三张不同的账单

这次发布点名了全部三个，而把它们合在一起读，比单读其中任何一个都更有信息量。持久性给你一次能扛住基础设施的运行，向你收取幂等性。上下文处理给你一次能装进窗口的运行，向你收取保真度。监督给你一次没人盯着的运行，向你收取"那个替你盯着的东西"的错误率。24 小时这个数字是三者的乘积，而一个只上线了第一项的团队，得到的是一个持久的智能体——它会在大约第三小时悄悄退化成胡言乱语。

上下文那张账单最常被低估，因为它的失效不是一个报错。"压缩会话"与"搁置大体积工具返回结果"是上下文压缩与塑形工具返回结果里的两根杠杆，而两者的工作方式都是故意丢掉信息。一次运行进行到第二十小时，智能体并不是在对"发生过什么"推理；它是在对"发生过什么的摘要的摘要"推理，而它需要的那个具体细节——第二小时那条确切的错误串、那一行没对上的记录——恰恰是压缩器会当成噪声丢掉的那类东西。遗忘与取代讲的就是把这件事做成刻意的，而不是做成 token 预算的副作用。

于是得到一个没人公布的测量——包括本文也没有：不是"智能体能不能跑 24 小时"，而是"它在第 20 小时的答案是否好过它在第 2 小时的答案"。一次压缩激进的长时运行可能比一次短运行更差，而知道答案的唯一办法，是在你自己的工作上对同一个任务在两个时长上分别打分。Notion 在那个时长主张旁边没有公布任何客户层面的任务质量数据或典型额度消耗数据——这对这类公告而言是常态，也正是为什么那个时长数字应被读作运行时的一项能力，而不是对结果的一个承诺。

你能卖的时域，不是你能跑的上限

一个上限说的是这次运行不会被杀掉。它完全没说这次运行是否成功，而这两者之间的落差，正是大多数人对长时域智能体失望的所在。任务时域是把它们分开的那个单位：智能体以某个明示成功率自主完成的工作长度。那套文献里的头条数字是 50% 时域——一次抛硬币——而你真正会拿去部署的可靠性，大约 80%，长度要短上约五倍。

所以一个会把任务维持 24 小时的产品，告诉了你分母，没告诉你分子。这个算术一如既往地不留情：长到需要一天的任务，是一个有数百步的任务，而数百步即便每步 99% 可靠，整体也只是抛硬币。持久性修不了这件事；它只保证失败到来时，那是智能体的失败而不是平台的失败。这是真实的改进——一次丢失的运行什么都不告诉你，而一次"跑完了但是错的"运行至少可以诊断——但它与头条暗示的那个改进，不是同一个改进。

实践上的读法：把厂商的时长上限当成一个被移除的约束，而不是一个被新增的能力。然后去测你自己任务上你自己的 80% 时域，因为那才是你能向客户承诺的数字，而它在 10 月 19 日并没有变。

没人在看，于是必须有别的东西在看

一次 24 小时的无人监督运行，打破了所有审批界面所假设的那个监督模型：有个人就在附近。Notion 的答案是"Review for me"：一个独立模型检查智能体的动作，并把它标记为可能不安全的那些送出去让人审批。这与 Claude Code 的 auto 权限模式是同一个动作——那里由一个分类器审查每一次动作——也与微软在同一天宣布的"随风险评估上升而收紧智能体可做之事"的那组控制措施是同一个动作。

这种趋同不是巧合——一旦运行的时长超过了启动它的那个人的注意力跨度，你就被逼到这里。它也确实优于一个会话级全局开关，因为分类器能做出单个设置做不到的"逐动作判断"。渐进式自主推导了这个缺口为什么存在，以及梯级究竟该住在哪里。

但要把买到的东西说准。一个审核模型把一项显式的策略决定换成了一个带假阴性率的预测，而从那一刻起，审核者的漏判率就是你的安全余量。这要求任何检测器都要接受的那套待遇——在你自己的动作分布上测出混淆矩阵；按"错批一笔付款"与"错拦一次文件改名"之间的不对称去选阈值；并随动作构成变化监控漂移。按风险打分的权限讲运维版本，而修复智能体的副作用讲的是那次长跑里审核者漏掉的那一部分。

计费表在同一次发布里也换了

时长公告与一个新的计费单位同时抵达，而这组配对并非偶然：一个能在单个任务上花掉 24 小时的产品，需要一个不依赖任何人盯着的支出天花板。Business 与 Enterprise 席位现在每月带 1,500 个 Standard 额度，用于由 Notion 路由器挑选模型的工作；另有 500 个 Select 额度，用于用户自己指定模型或运行自定义智能体的工作。额度按月重置、不结转，也不能在成员之间共享或转移。既有客户在 11 月 2 日切换。

没有公布的是换算率。额度与 token、额度与任务之间的换算在任何地方都没出现，而决定哪个模型服务你这次任务——因而决定它烧掉多少额度——的那个路由器，是厂商的。这个组合意味着供货方同时定下了你账单的两个因子。该公司对路由器的说法是：在 20 多个常见用例上它与 Opus 5.5 和 Astra 打平，而平均成本低约 90%；它自己的帮助中心把这个数字写成"比 Opus 5.5 低 87%"。两者都是厂商测试，而同一项节省的两次第一方表述之间那三个百分点的落差，大致就是外部人士能把这件事还原到多精确的合理估计。

可用的应对是：用你自己的流量测"每完成一次任务消耗多少额度"，并保留这条序列——这正是按额度计费的智能体产品的全部论点。有一个结构性后果值得在这里点名，因为它咬的恰恰是这次发布所启用的那种工作负载：在不共享池、不结转的前提下，一位重度用户的一次 24 小时运行，只从那一个席位的配额里扣。请按每个席位自己的峰值配额，而不是按团队平均值，否则你最重度的用户会在月末最后一周撞墙，而其他所有人的余额原地过期。

该抄什么，该跳过什么

还有一件该跳过的事：不要伸手去加更多智能体。当一个任务长到一次运行装不下时，本能反应是把它拆给好几个，而协调税通常超过收益——子智能体与本站的多智能体材料都落在同一个结论上。对"时长"这个问题，一个持久的单循环才是更便宜的修法，而这也正是 Notion 伸手去拿的那个修法。

延伸阅读

本站：

• 任务时域——为什么 50% 的数字是抛硬币，而 80% 的那个要短上五倍。
• 持久状态与可恢复性——这次上限变化所建立在的那个范式。
• 幂等与重试——持久性寄给你的账单。
• 上下文压缩——压缩一条长会话线究竟丢掉了什么。
• 按额度计费的智能体产品——怎么测一张你没拿到单位的账单。
• 渐进式自主——当会话旋钮表达不出来时，梯级该归谁。
• 长寿命会话与部署——在一次比部署活得更久的运行之下发代码。

一手来源：

• Notion——《Agents, rebuilt to do more for less》（2026 年 10 月 19 日）
• Notion 发布说明，2026 年 10 月 19 日
• Notion 帮助中心——管理你的 AI 额度
• Notion 帮助中心——Auto 模型路由