Orkas 里早就有可持久的任务计划里程碑也早就在记录每次工具调用到底改变了什么的宿主侧事实。但这两半从没被接起来于是一步是否完成取决于模型说了什么。这篇讲 BEACON 怎么定位它的里程碑检测器、真要做该分哪三层以及一条论文里没有的判据。这是长程 Agent 设计手记系列的第二篇起因是我们精读了 BEACON 浙江大学arXiv:2605.06078 。第一篇 的结论是循环检测抓不到停滞因为重复是输入侧的信号而进展得看输出侧。但那个结论要能成立前提是有个东西可以拿来量进展。这一篇讲的就是那个东西。一句话版本完成与否由检查说了算不是由 Agent 自己说了算Orkas 在把一个里程碑判为完成之前会先验证没解决的会明确列出来而不是悄悄往下走。先把问题问对问题不是「怎么让 Agent 知道自己完成了一步」而是「怎么让系统知道它真的完成了一步而不是它说自己完成了」。就差这么一层可信度完全是两回事。我们其实已经有两半只是没接上翻自家实现的时候这点让我们有点意外。第一半。里程碑这个东西产品里早就有了。有个工具在维护一份可持久的任务计划一个长任务被拆成哪几步、每步是什么状态待办、进行中、已完成、受阻。它的设计意图就是给长任务提供稳定的进度锚点。但每一步是怎么变成「已完成」的模型自己声明的。第二半。每次工具调用结束宿主侧都会记下一批确定性事实文件的内容哈希有没有真的变、命令的退出码是多少、有没有超时。这批数据记在宿主侧从不进模型上下文所以模型伪造不了。缺口就在这儿。一边是「我完成了」一边是「某个文件的哈希从 A 变成了 B」这两条线索从来没被摆到一起过。缺的不是数据结构也不是观测数据就是中间那座桥。论文里最有用的一点不是那个公式BEACON 最出名的是双尺度 advantage但真正值得拿走的是它怎么定位检测器 Φ。Φ 不需要训练模型也不需要人工标注只读环境反馈里能观测到的状态变化。ALFWorld 里检测物体状态跃迁成功拿起、加热完成WebShop 里检测页面跳转ScienceWorld 直接消费环境本来就给的子目标信号。零额外模型、零额外采样开销。对比另外两条路过程奖励模型要昂贵标注、还有被刷分的风险蒙特卡洛估值则要在每个决策点多跑几次 rollout。省下的就是这块成本。而做 Agent 产品的人有个论文场景里没有的便宜条件工具调用本来就是结构化的成功失败有明确返回。论文得费劲从环境里抠信号我们的信号是现成的。真要做分三层第一层把确定性证据聚成一条流。不做任何语义判断只机械记录不可逆的可验证变化。文件内容哈希变了、命令退出码为零、外部接口调用返回成功、数据落库成功。这些现在就有只是散在各处从没被拢成「已达成事实」这么一条东西。第二层把两半接上。性价比最高的一步。模型声明某步完成时不再无条件采信而是去查这段时间里有没有第一层的证据。有证据就标成已验证完成没有就标成已声明完成。这不阻止模型声明任何东西只是把有据和无据分开。第三层按能力类型分别定义 Φ。作者自己也承认 Φ 需要领域知识、难以泛化所以别指望一套通用检测器。写代码类看测试退出码数据分析类看产出文件有没有生成发消息类看接口返回。这层得一个能力一个能力慢慢铺。我们自己加的一条判据看不可逆别看重要这条论文里没有。BEACON 的里程碑之所以管用本质是它标记了回不去的状态跃迁拿到钥匙之后世界就变了。所以判据应该是这个动作有没有产生不可逆的外部副作用而不是这一步重不重要。不可逆写文件、提交代码、发消息、调付费接口、数据落库。可逆读文件、搜索、抓网页、思考。这么定有两个好处。一是机械可判动作类型直接决定归属不需要任何语义理解也就不会有「模型觉得这步很重要」这种主观东西混进来。二是它跟恢复点本来就是一回事只有从不可逆的地方往后恢复才有意义可逆的动作重做一遍就完了。论文里有两个数一个能壮胆一个得当心壮胆的那个是降级实验。随机丢掉一半里程碑成绩还有 82.8比 72.8 的基线高 10 个点。降级是平滑的不是悬崖。对想落地的人来说这才是关键你不用等 Φ 设计得完美无缺才敢上覆盖一半就已经有得赚。当心的那个是切分对照。切分方式成绩相比基线 (72.8)随机切 5 段74.21.4真实里程碑91.417.2第一篇也引过这组数但放在这里含义更直接。如果你的里程碑是拍脑袋定的那它约等于随机切分白做。里程碑值钱值钱在它跟任务的真实结构对上了。哪些地方得打折论文自己在附录里把「自动里程碑发现」列成了待解决问题。三个 benchmark 的里程碑全是靠规则拿到的模式匹配环境响应、页面跳转、或者环境直接给信号。而浏览器操作、代码库改造、深度研究这类真正开放的场景压根没有这种现成的可验证跃迁。所以那套东西更像是在结构化环境里被验证过的范式不是能整个搬走的方案。Agent 产品能落地靠的是工具调用这个结构化边界不是靠论文给了现成答案。另一个坑是粒度。太稀就等于什么都没做太密则段级信号变成噪声。对应到产品就是任务拆解的粒度而这里反倒有个论文场景没有的便利计划里的每一步本来就是给用户看的粒度可以用「用户能不能看懂这一步」来锚不用纯靠算法调参。如果只做一件事做第二层。成本低因为第一层的数据本来就在第二层只是把它跟模型的声明对上。可独立验证因为「已验证」和「已声明」的比例本身就是个值得盯的指标。而且它是后面所有事的前提没有「已验证里程碑」这个概念第一篇的停滞检测、下一篇的压缩边界都无从谈起。它还有个很舒服的性质上线不改变任何行为。模型该怎么声明还怎么声明只是多了个标记。等数据攒够了再决定要不要对「声明了但没证据」的那些做拦截。下一篇聊上下文压缩为什么按 token 阈值切跟「什么该忘」基本没关系以及对本篇最自然的那个延伸的一处纠正——很多人会顺手认为里程碑一旦验证通过它前面的东西就能整段折叠掉。实践补充为报告任务分别定义来源收集、数字核对和最终文件可读的证据并明确发布前必须验证哪些内容。下一步阅读官网原文下载 OrkasOrkas 官方指南 · 最后核验2026-09-14