机器人在修 PR，人类只剩签字

11 月 1 日，OpenClaw 的仓库更新了 500 条 PR，其中 270 条被合并或关闭；Hermes Agent 同样更新了 500 条，其中 371 条还挂在待合并队列里。两个项目当天都没有发布新版本——OpenClaw 的 v2026.10.10-beta.5 是 10 月 31 日发的，Hermes 最新仍是 v0.22.5。

也是在这一天，@roboclaw-bot 接力重开了两个长期停滞的社区 PR：原本的流末重复文本问题，由新 PR #189852 取代旧 PR；Slack 原生流过期之后进度冻结、最终答案重复送达的那条，由 #189837 取代。日报记录这件事时，专门点了这两个新编号，并注明 bot 重启 PR 时保留了原作者 commit credit。

它们修的事都很小：回复尾部多出一段字，最终答案送了两遍。

对照在另一边。OpenClaw 的 P0 问题 #160959，大型外部插件把 Gateway 事件循环阻塞数分钟，挂着 66 条评论，从 9 月底撑到 11 月初，依然没有 fix PR。同一份日报的 P0 段落里还列着另外三条：#166634 崩溃恢复后 SQLite 会话回收的 checkpoint 过期、agent 永久 UNAVAILABLE；#153426 记忆根文件被溯源闸门静默排除出 bootstrap 注入；#137177 内置 wecom 插件无法安装。

所以 11 月 1 日真正的问题不是机器能不能修 bug。它已经在修了，而且专挑人类最不愿意花时间的琐碎债下手。剩下的问题是：修完之后，谁来签字。

这一天跨三个来源的数据——两个开源智能体生态、七个 AI 编码 CLI 工具、一份 Hacker News 榜单——都在指向同一个位置：产能已经过剩，瓶颈搬到了判断环节。

这一天被自动化的四个动作

第一件是接力。停滞 PR 的处理方式本来只有两种：等原作者回来，或者关掉。roboclaw-bot 选了第三种，把旧 PR 的改动重做成新 PR，作者署名保留。

这个细节比它修了什么更重要。开源协作里，署名是唯一的回报，这算社区常识；但由此推出的结论是推断，不是观察：如果自动化在接管积压时顺手抢走 credit，长期看会抑制补丁供给，可这一天没有任何数据能回答「抑制多少」。所以保留 credit 更像是在维护一条供料管道，而不只是一次礼貌。

第二件是分诊。OpenClaw 的 issue 上挂着一整套机器打的标签：clawsweeper:needs-maintainer-review 表示需要维护者看一眼，no-new-fix-pr 表示已经确认没有新补丁，还有一类被标成 diamond lobster，意思是长期没人管但评级很高。当天近 400 条活跃 issue 中，绝大多数带着 no-new-fix-pr（这是日报的概括，不是逐条计数）。

这个标签本身就是一句结论：机器已经判定「这条没有新补丁可等」，把它从工作队列里挪开。分诊把四百条噪音压成一张短名单，可短名单仍然要人一条条看。digest 的原话是，维护者评审吞吐——尤其是 needs-maintainer-review 与 needs-product-decision 两个队列——已经成为项目当前最明显的瓶颈。

第三件是清理。这一天 Claude Code 以批量 stale 关闭为主，把大量 7-8 月的历史 bug 统一标记关闭，涉及内存泄漏、配额异常扣减、安全分类器误判；三个 3 月创建、集中在同一作者名下的 PR 也一并关闭。Codex 那边，copyberry[bot] 提交了四个 PR 之后关闭，涉及 TUI 跨后端会话切换、失败推理轨迹保留、Guardian 上下文弹性预算、CI 快照清理。OpenCode 把 2.0 时代积压的一批老 issue 集中关掉。

清理的收益立刻可见，代价也立刻可见。Claude Code 当天评论数最高的 issue #62107，讲的是 Windows 上定时任务跑完后 claude.exe 进程不退出、内存持续累积——它就是「已经 stale 关闭，但问题本质未解」的一个例子，10 条评论。这里要克制：个例只能说明这种情形存在，不能拿来推算整体比例。但「关闭不等于修复」这条界线，在批处理之后确实很容易被跨过去。

第四件是降本，而这一件是人做的：@vincentkoc 用 #189838、#189840、#189841、#189844 一串 PR 去重 fixture 构建，降低 CI 成本。CI 是整条流水线里最贵也最容易被忽视的一段。它和前三件共享同一套逻辑——把重复劳动改成一次规则变更，只不过这次动手的是人。

四个动作连起来看，「找问题、分队列、清积压、降成本」里前三段已经交给机器，第四段是一个人类用机器的思路在干活。研发流程里只剩最后一段没有自动化：判。

这不是说机器做得不好。恰恰相反，它比大多数人类维护者更勤快：不需要睡觉，不会因为被骂而离开项目，也不会在评审一条无聊的 bug 时心生厌烦。但它产出的是流量，不是决定。流量可以靠加机器无限放大，决定不能。

五百条 PR 与三百七十一条待合并

先把口径摊开，否则下面每个数字都会被读错——尤其是关闭率，它单独读没有意义，必须配关闭原因分布。

这三个比率都只描述当天，不是存量消化率。stale 机制会把「没修」记成「已关闭」，OpenClaw 与 Claude Code 都对历史条目做过批量 stale 处理；Issue 更新数包含既有条目被评论顶起来的部分，OpenClaw 的 496 条里有 395 条属于「新开或活跃」；PR 合关数包含 bot 批处理。还有一处必须点明：两个项目的「PR 更新」都恰好是 500，这个整齐数字很可能是我这边采集端的上限截断（这是推测，不是事实），所以那一行只能当规模量级看，不能当精确计数。另外，表里两个比率（20.4% 对 4.7%、0.85 对 2.88）是我按原始计数算出来的——日报只给计数，没给这两个百分比。如果 500 真是上限，那么「合计 1000 条 PR」「601 条待合并」这两个数也只能当下限看。下面所有解读都限定在「当天这一刀」里，不延伸成长期健康度。

即便如此，两种策略的差别已经很清楚。OpenClaw 用 270 条合关压住了队列，代价是四个 P0 仍未修复——就是上面列过的那四条。Hermes 只关了 14 条 issue，但 P0 是零，P1 里只有一条没有明确 fix，就是 #145022。

「待合并 ÷ 合并关闭」这一列可以读成：当天每关掉一条 PR，队列里还压着几条。0.85 意味着进出大致平衡，2.88 意味着当天放出去的只有压着的三分之一。

这两个数字放一起读才有意思：关闭率 20.4% 的项目留着四个 P0，关闭率 4.7% 的项目一个 P0 都没有。

一种可能的解释是，高关闭率里有相当一部分是「清理」而非「解决」——把不打算修的、复现不出的、过了时效的条目批量关掉，队列立刻变短，但风险并没有消失，只是从队列里搬到了静默状态。另一种解释是 Hermes 更年轻、规模更小，债务本来就没到爆发期。单日快照分不出这两种解释的权重。所以在拿到关闭原因分布之前，任何关闭率都只能当描述，不能当评价。

真正共同的病灶在长尾。Hermes 那 371 条待合并里，有 8 月就已经通过 CI 审查的功能 PR：#81403 让审批提示中的隐藏 Unicode 与 bidi 字符可见，这是 prompt injection 防线的一部分；#82826 给 cron 提示注入运行时间；#81434 提供 pre_llm_call 阻断钩子。三条都不是半成品，是「审过、没合」。

OpenClaw 这边，队列里还躺着 8 月开的 #127770，把 PDF 当作原生文档输入给 OpenAI 接口的开关。两边都有 8 月的东西在排队，这说明积压不是某个项目的偶然，而是这类项目的常态形状。

队列尾部的长度，直接等于用户踩坑后的等待时间。一个用户遇到 bug，他等的不是「这个项目一天能合多少」，而是「我这条什么时候被看见」。前者是产能，后者是带宽，两者之间没有换算公式。

还有一个更硬的约束：评审带宽是唯一不能靠加机器扩容的资源。加模型能提高补丁产量，加 CI 能提高验证速度，但「这个改动该不该进主干、进了出事谁负责」没有并行化方案。要么加人，要么降低标准，要么把一部分判断提前变成规则。

前两条路都走不通的时候，第三条就成了唯一方向。但在谈那条路之前，得先看清：哪些问题根本写不成一条能被验证的断言。

有一组对照能说明这件事值多少。Hermes 的 #147030 讲的是 cron 任务在高并发下撞 SQLite 竞态：实测峰值 12 并发时 busy handler 超时，直接把 worker 杀掉。当天就有 PR 提出序列化 ledger 写入，路径从复现到补丁极短。OpenCode 的 #60947 也一样，压缩摘要被输出上限截断后直接失败，修的是这条最常见的压缩失败根因。这两个都属于同一类：失败路径明确、断言可写、验证成本低。

反面是 #145022：多个 Kanban worker 并发时网关一卡，worker 就崩，界面显示 Kanban execution unknown，进行中的工作直接丢失，单次事故杀死 4 个 worker。它至今没有明确 fix PR，只有 #147022 这条「抑制终态卡片的过期失败唤醒」算部分相关。原因不难理解——这个问题的第一步不是写代码，是先定义「什么算完成」，而定义完成语义属于产品决策。

所以修复速度的差异，几乎完全由一件事决定：这个 bug 能不能被写成一条可验证的断言。能写成的，当天就有人修；写不成的，只能等人先想清楚它到底错在哪。

三类没人敢交给机器的签字

把「判」拆开看，会发现它不是单个动作，而是三种性质完全不同的动作：定语义——这个东西应该怎样；守边界——谁可以碰什么；护信任——用户还愿不愿意用下去。这个三分法是我为了分析方便临时划的，不是通用框架。11 月 1 日的仓库里，三种各有标本。

产品语义：闸门误伤之后要不要自动放行

OpenClaw #153426 的具体形状值得完整复述：MEMORY.md 与 USER.md 因为 provenance ratchet（溯源棘轮）被静默永久排除出 bootstrap 注入，没有诊断信息，也没有恢复路径。digest 把这一簇用户反馈概括成一句话——行为本身可以错，但不能不给解释。

为什么机器不能定这条：收紧溯源是对的，防止记忆被投毒；放宽也是对的，因为记忆是个人助手最核心的价值。两个方向都站得住，代价却不对称。收紧的代价是用户发现助手「忘」了他上周说过的话，而且不知道为什么；放宽的代价是某一天注入的长文档改写了助手的长期行为。前者是体验事故，后者是安全事故，两边都不能用「修复成功率」来衡量。

digest 对这条的标注是「需产品决策」。这四个字很轻，但它意味着一个 PR 再好也合不了——因为没有人能替产品回答「记忆该不该有溯源闸门、闸门误伤后要不要自动放行」。

Hermes 那边有同构的一条。#143767 讲的是 Desktop 恢复了一个压缩前就已结束的会话，之后每次切换模型都被拒 session_superseded，聊天窗口直接不可用。代码上可以强行允许切换，但那会破坏「一个会话只归属一个运行时」的语义；不允许，用户就卡在那里。修法取决于产品打算承诺什么，不取决于代码怎么写。

对比之下，#76493 是另一类标本：mcp.servers[].env 不接受 SecretRef 对象，用户被迫放弃密钥间接引用。这条只有 5 个赞，共识度高、schema 改动局部，落地下一个 minor 的可能性很高。同一批积压里，有的问题缺的是共识，有的问题缺的是权限；前者可以等，后者等不来。

安全边界：改一行就生效，改错就开门

这一类有三个标本，性质依次递进。

OpenClaw #173058：workspaceOnly 设成 true 不生效。agent 运行时仍以 OpenClaw 的状态根作为允许目录，文件工具可以越界读写。digest 的建议是优先处置，当前没有 fix PR。

Hermes #62336：终端环境快照（export -p）把含凭据的环境变量持久化到磁盘，包括密钥管理器注入的密钥。7 月提出，积压近 4 个月。

OpenClaw #189749：cron 自动化支持人类 owner 的管理与转移，XL 体量，标了 security-boundary，要求提供 proof 才能合。这一条的难点不在实现，在于「转移 owner」本身就是一次权限变更，任何自动化转移都可能变成提权路径。

还有一类更少被注意：同一天的日报里还挂着三个针对 Gemini CLI 的 CI Chained E2E 流程的安全探测 PR，#30066、#30064、#30065。作者自述这是 Google OSS VRP 报告的一部分，演示的是 fork 分支的代码可以在自托管 runner 上执行并读到环境变量。这不是普通 bug 报告，是一次公开的、按流程走的攻击演示。

仓库侧当天也有一条正面样本。#189850 让受限 operator 角色不再发出被禁止的请求——修的是权限边界本身，而不是提示文案。

为什么这一类不能交给机器：改动通常只有几行，几行就能生效，几行也能打开一扇门。机器可以写出这行代码，但「门开了之后谁承担」的答案在组织里，不在代码里。这也是为什么 #189749 要求 proof——proof 不是给代码看的，是给将来要担责的人看的。

信任：不崩溃、不泄漏、不越权，只是让人失望

第三条标本链最不起眼，却离用户最近。三条分别来自两个项目：

#143426（Hermes）：Linux 桌面以 6% 不透明度启动，而设置界面把透明度控件藏了起来，用户没有任何自救路径。21 条评论、13 个赞，当日已关闭。

#161976（OpenClaw）：WhatsApp 私聊回复在重启后持续送达失败，P1，需要安全评审。

#105758（Hermes）：生命周期守卫误杀良性的 Node.js CLI，9 月 3 日一次 scan-budget 提交引入的回归，两个月停在 needs-decision。

这三条的共同点是：它们不崩溃、不泄漏、不越权，只是让人失望。而失望在优先级排序里永远排在崩溃后面，所以它们会一直排队，排到用户不再报告为止。

但用户决定要不要继续用一个助手，靠的往往就是这类事：启动时屏幕是黑的、消息没送到却显示已读、一个正常命令被守卫拦下。这些体验没有事故等级，只有流失率。#143426 的 13 个赞不算高，可它是那种「用户在评论区说『设置在跟我作对』」的帖子——情绪浓度远比点赞数更能说明问题。

还有一类信任问题不在功能里，在账上。Claude Code #87419：Max 20x 用户反映周配额自 8 月 17 日重置之后消耗速度快了 1.7 到 5 倍，OAuth token 携带的 rateLimitTier 与用户实际购买的档位不一致，这条关联了 6 个历史 issue。Codex #55507 是 Business 用户频繁撞 429，配 #45619「周配额订阅续费后不重置」一起读，问题就从「额度不够」变成「额度账本说不清」。OpenCode 那边，#59387 这条免费层问题汇总帖积压到 167 条评论，是全社区最热的单个条目。

用户在这里的位置很微妙：他不在评审席上，也没有能力验证自己到底买了多少。当计量不透明，用户其实也在签一份他读不懂的合同——只不过他签字的方式是继续付费或者离开。这也是为什么「成本可观测性」正在从产品加分项变成选型硬指标：一个说不清账的工具，用起来每一步都在赌。

三个类别放在一起，自动化的边界就浮出来了：可验证的都能自动化，因为有测试、有复现、有配对实验；要担责的都不能，因为答案取决于安全、语义与信任，而这三样都不在代码里。

11 月 1 日的仓库里，恰好有一批 PR 演示了怎么把「担责」压缩到最小——不是靠更强的模型，是靠更好的证据。

让签字变快的，从来不是更快的评审

@steipete 这一天提交的一串 Control UI 性能 PR 值得逐条看，因为它们示范了一种语言。

#189762：Dashboard 冷启动改走早期 Gateway 交接。描述里附了 11/11 配对实验，hello 时间从 570ms 降到 468ms，中位数改善 96.88ms。

#189729：会话删除后不再反复失效侧边栏缓存。描述里写清了旧行为的量级——一次删除曾引发 25/5 次跨 tab 广播失效。

#189760：热重载时在首次挂载就接纳缓存聊天面板，消除 144px 的身份内容跳变。

#189843 与 #189821：大花名册场景下选择器与侧边栏只挂载可见行，把 CPU 占用压下来。

这四个 PR 的共同点是：把「我觉得这个更快」换成了「这是配对实验的中位数差」。评审的人不需要复现，只需要判断这点改善值不值得引入这点复杂度——判断对象从事实变成了取舍。

对照组是 #160959：66 条评论，0 个 fix PR。不是用户不努力。这个问题需要的是架构层的所有权模型——插件捕获必须离开事件循环——而不是一条补丁。当问题大到没有补丁形状，讨论就只能在情绪层循环：每个人都描述自己遇到的阻塞时长，但没有人能提交一个「把这几分钟消掉」的改动。

用户的表达也在同步升级。Copilot CLI 的 #5302 用 2,164 次真实 shell 调用的日志，统计出 Windows 上反复出现的无效 PowerShell 模式；OpenClaw 前一天还有一条 #143017 的记录，把一次缓存前缀重写换算成 2130 万 cache-write token 的生产侧账单——那不是设计出来的实验，是真实跑出来的写入量。当报告本身带上测量，「我觉得」就变成了「我测了」，评审才有落点。

这是 11 月 1 日最实用的一条经验：在一个产能过剩的生态里，注意力只对证据开放。

资本市场在做同一件事，只是用另一种语言。HN 榜单上紧挨着的三条热帖连起来读很有意思（其中第三条来自前一天）：OpenAI 的融资不到 300 亿美元目标的一半（181 分 / 185 评论）；Anthropic 的招股文件引发科技股抛售（49 分 / 75 评论）；前一天 Blackstone 判断它 IPO 之后可能拿不到投资级评级（269 分 / 216 评论）。

这三条摆在一起，我的读法是：模型产能已经不再稀缺，稀缺的是能被人相信的交付。资本在给「可信度」打折，而不是给「能力」加价——这是解读，不是数据，但技术侧的评审瓶颈与资本侧的估值压力确实在问同一个问题：供给端已经能造出远超需求的东西，需求端凭什么相信这一份。

必须说明这是类比，不是证据：融资热度与评审带宽之间没有已知的因果链，我也拿不出任何数据把两者接起来。它可以被证伪——如果接下来几天融资回暖、社区热度回升，这个类比就该被丢掉。

规范前移：把判断写成机器能读的东西

如果说评审是唯一的瓶颈，那解法只有三个方向：加人、降标准、把判断前移。前两条都有限，第三条在这一天有很多具体形状。

企业侧做得最直接。Claude Code v2.1.316 给网关加了团队共享预算：管理员可以通过 spend limits API 的 pooled_budget 为团队成员设一个共享的月度额度，叠加在各成员个人限额之上。同版本还加了 CLAUDE_CODE_DISABLE_ULTRATHINK，让团队能关掉那个关键词触发的深思考。Codex 的 Guardian 审查链路引入 ContextBudgeting::Elastic，取消固定分段请求上限，把「给审查留多少上下文」从硬编码变成可分配。Copilot CLI 则让 COPILOT_PROVIDER_GHES_HOST 直接接受企业实例的浏览器地址，把部署配置的门槛降下来。

这些改动的方向一致：把「谁批、批多少、批多久」从口头约定变成产品能力。预算不是财务报表上的数字，是一条准入规则——它在你写代码之前就替你做了决定，于是评审时不用再讨论「这个功能值不值这个钱」。

仓库侧做的是同一件事的另一种形态。sweeper 的标签体系把「这条该谁看」写成机器可执行的规则；#189850 让受限 operator 角色不再发出被禁止的请求，把权限判断从人的记忆搬进代码；#189856 让系统 agent 能读取用量与成本，把「钱花在哪」变成可查询的事实。这三件事都在减少「需要人记住的东西」，而需要记住的东西越少，需要签的字也越少。

还有一种更朴素的做法：把散落的抱怨收敛成一个总账。Hermes 的 #143547 就是这种条目——10 月 14 日统一网关合并之后暴露的认证、配置、压缩、连接问题，被收进一个清单，30 条评论，成为当前最关键的总账。同一天 #127647 也在做同样的事，把桌面端闲置 CPU、GPU、内存的零散反馈汇总成一个资源追踪器，34 条评论。这类 issue 本身不修任何东西，但它把「二十个小问题」变成「一个需要排期的主题」，评审的判断成本从二十次降到一次。

OpenCode 在 11 月 1 日提交的一批重构更能说明问题。它把 headers、fetch、timeout 统一到每次请求（#60970），修的是图片与决策请求静默忽略超时的老毛病；给 AIError 加上 status、code、isRetryable、retryAfterMs 四个字段（#60808），让上层重试逻辑不必靠猜；把非法 tool 输入的恢复路径打通（#60797），参数解析失败不再直接终止循环；给每个 HTTP 请求与会话轮次打独立 trace（#60974）。这四件事看着是重构，实际是在造一套「错误语义」——把「出了什么事」标准化成机器能分类、人不必逐条判断的枚举。

生态侧的信号更直白。11 月 1 日的 GitHub Trending 上，claude-mem 单日新增 1723 星，做的是跨会话持久上下文层；impeccable 新增 1339 星，做的是给编码 Agent 立设计规范、审查 AI slop；Orkas 新增 1118 星，用 Commander 拆解目标再调度 16 个专家 Agent；mattpocock/skills 新增 882 星、obra/superpowers 新增 663 星，做的是把工程方法论打包成技能目录。

需要说明口径：digest 里部分新项目的总星数未采到，显示为 0，上面只引用单日增量，不代表项目总规模。

这些项目分散在记忆、规范、编排、技能四个方向，但它们在做同一件事：把人的判断写成机器能读的规范，让机器先过一遍。impeccable 尤其典型——它不生成设计，它约束设计：给 Agent 一套设计词汇表，然后审它有没有写出 slop。这是把「审美判断」这种最像人类专利的东西，拆成了可执行的检查项。

我的判断是把签字拆成两半。规范能覆盖的部分——格式、性能阈值、权限白名单、设计词汇、预算上限、错误语义——交给机器先跑一遍；剩下真正要担责的部分，比如要不要放行一个已知风险的开关、要不要接受一次语义变更，留给人。前一半越大，后一半越小，评审带宽才会真的变宽。

这不是把责任外包给机器。这是把重复判断从人脑里搬走，让人只剩下真正需要判断的那部分。差别在于：搬走的部分出错可以回滚，留下的部分出错要有人负责。

规范前移也有它自己的代价，而且这个代价在 11 月 1 日的数据里能看见。规范会把连续判断压成二值判断，可现实里很多判断是三值的：可以、不可以、看情况。sweeper 的 no-new-fix-pr 标签就像一把很快的刀——它准确地把队列切短了，但它分不清「确认没人会修」和「暂时没人有空」，被切掉的条目不会自己申诉。impeccable 那类工具的风险类似：把审美压成检查表能有效拦住 slop，但过度规范会让产出趋同，所有人都交出同一份「正确但无趣」的设计。

所以前移的边界要留一条回退路径：任何被规则判死的条目，必须能被人一键翻案，而且翻案的成本要低于当初判死的成本。这条对自建系统同样适用——你写进 agent 的每一条硬规则，都要配一个「如果有人不同意，怎么改回来」的入口，否则规则会以比 bug 更慢的速度腐烂。

那些「没说」的失败，评审根本够不着

把 11 月 1 日的工具侧问题按性质归类，会得到一张很不舒服的表。

八条里有七条的共同点是「没说」，剩下一条是「没问」——OpenCode 的 DROP MEASUREMENT 压根没经过确认就执行了。两者都比「做错」更贵：因为评审、监控、回归测试全都建立在「事件会发生并留下痕迹」这个前提上。当一个动作在系统内部完成、外部看到的是正常输出，所有基于痕迹的机制会同时失效。

Claude Code 那条尤其典型。配置写着 false，行为却是 true，中间还夹了一次「为了安全」的 fallback。在授权的 IT 运维场景里，用户会以为自己受策略保护，实际上策略从未生效。这类问题不会崩溃，也很难被测试抓住——测试通常验行为，不验「行为是否与配置一致」——只能靠人偶然读到日志。

Gemini CLI 那三条的组合效果更值得警惕：配置被忽略（#22267）、阈值被丢弃（#30068）、轮次到顶仍报成功（#22323）。三件事叠起来，用户看到的是一份「按我的设置跑完并成功」的报告，实际跑的可能是另一套参数、在另一个位置被截断。对依赖子代理做自动化的流程来说，这等于把校验点全部挪到了看不见的地方。

Hermes 那两条属于同一族的极端形态。#146428 是永久静默卡死——不是慢，不是重试，是彻底不动且不报错；#131786 是结果被截断后仍然交付，用户拿到的是一段看起来完整的 JSON，只是尾部没了。两者都要求用户先怀疑「是不是根本没跑」，才可能去查。

平台差异是另一种「没说」。这一天多款工具集中暴露 Windows 问题：Claude Code #62107 是进程残留，Copilot CLI #5302 用 2164 次调用统计出反复生成的无效 PowerShell、#5304 是 WSL2 里 keep-alive 拦不住宿主休眠导致长任务被中断，Qwen Code #15276 是桌面更新时 node.exe 被捆绑运行时锁住，Codex #54989 则是设置里浏览器开关明明开着、browser-use 工具反复报「本地浏览器被禁用」，要完全重启才恢复。

用户在这些场景里拿到的不是报错，是「这个功能在你这儿就是用不了」，而且大多没有解释。平台语义——路径分隔符、shell 类型、电源管理、文件锁——属于环境假设，而环境假设恰恰是自动化最难自我验证的部分：机器在自己那套环境里跑通了，就会认为全世界都跑得通。把这些假设写成显式规则，又是一次只有人能做的判断。

基础设施层的静默失败更隐蔽。Qwen Code 的 #14724 是一条跑了近两周的追踪帖，105 条评论，讲的是 Main CI 上 Managed Agent gate 失败却不指明具体失败测试；#16003 更直白——CI Runner 磁盘耗尽，RocketMQ 拒绝写入，Java lane 建不出临时目录，但故障摘要里完全看不到磁盘问题，跨三天跨多个 Runner 池复发，诊断成本极高。当必过检查因为基础设施而变红，代码质量信号就被污染了，而污染源不会自己举手。

OpenClaw 的 #182369 是另一个形状：Gateway 的 RSS 每小时泄漏约 0.1 GiB，内部阈值监控却不触发。监控说没事，进程在长胖。这类「监控本身失效」的问题最麻烦，因为你用来发现问题的工具，正是出问题的那一层。

再往上一层看，安全问题也是「没说」的一种。OpenClaw #130209 的处理方式是反向的：脱敏把错误消息里的 key 也一起打码，于是模型无法自我纠错。这一条和 #153426 的诉求正好构成一条设计原则的两端——诊断信息要够用，但不能泄密。这个平衡点没有通用解，只能由人在具体场景里定。

这也是为什么「签字」不能全自动。HN 当天榜首是一篇把 ChatGPT 账户接管漏洞拆成完整数学推导的披露（293 分 / 142 评论），前一天更重的一条是 Claude Code 的 VS Code 扩展在 Cursor 市场被植入 SSH 后门（724 分 / 451 评论）。当「看不见的失败」发生在工具链上，代价会从返工变成泄露。签字的人，是在为那些看不见的部分担保。

写在最后

回到 11 月 1 日这一天的账：合计 399 条 PR 合并或关闭、601 条待合并、4 个 P0 未修——三个数都按日报口径，其中 PR 计数可能受采集上限影响，只能当下限看。人类这一天真正的工作不是写代码，是决定哪些改动可以进主干。

诚实边界放在这里：本文数字全部来自 2026 年 11 月 1 日的公开仓库活动汇总与当日 Hacker News 榜单，是单日快照；两个项目不能代表全部生态；关闭数除以更新数不等于存量消化率，stale 批处理会把「没修」变成「已关闭」；评论数与点赞数会随时间变化；我没有独立复现任何一条工具行为，也没有核验任何一条 issue 陈述的完整性——那是一手证词，不是判决。

如果你在自建 agent 系统，先把「每天能签多少个决定」算出来，再决定让机器人开多少 PR。评审预算和算力预算是两种预算，前者更贵，而且不能并行扩容。

如果你在做选型，看队列年龄，不看 star。OpenClaw 当天合关 270 条 PR，#160959 却从 9 月底挂到现在，这种落差比任何功能列表都更能说明你将来的处境。

如果你在给开源项目提 PR，把配对实验、复现路径、影响量级写进描述。那是唯一能通过人肉关卡的语言，也是自动化唯一帮不上忙的地方。

机器人不需要学会签字，它需要学会把证据摆到签字的人面前。而人需要接受的现实是：产能过剩之后，稀缺的是判断力，不是算力。