开源贡献日报 · 2026-09-09

9 月 10 日补记：我参与的三个讨论，以及一路想下来的问题

昨天整理这份日报时，我把几个架构提案放进了“值得参与”的列表。今天我挑出其中三个，读完原帖和评论，又和 AI 来回讨论了一轮，把自己的看法整理成英文，逐条确认后发了出去。

这三个问题刚好连在一起：浏览器操作以后，怎么知道它处理到了哪一步；Agent 需要问人时，其他工作能不能继续；再往前走，如果是子 Agent 需要问人，主 Agent 又该怎么监督整个团队。我把思考补在这里。以下是 9 月 10 日的参与记录，后面的日报统计仍保留 9 月 9 日原有的截止时间。

Browser Use #5137：页面没变，不能倒推出浏览器没处理

原提案希望给浏览器动作增加结构化证据，记录操作前后的 URL、文本和元素数量变化，让 Agent 分清操作失败、没有变化、导航等结果，减少反复点击。讨论中有人把过程拆成 dispatch、settlement、delta 和 recovery；也有人分享了预渲染页面的例子：回复框早就在 DOM 里，点击只是展开它，节点数量当然不会增加。四阶段建议、预渲染场景反馈

我看到这里，第一反应是：浏览器和 JS 框架的交互习惯，本来就主要围绕人来设计。人看到按钮、转圈和结果，会自己判断；Agent 却需要更明确地知道，这次操作到底有没有被处理、处理到了哪里。

所以我不太认同用应用结果的变化去定义 settlement。浏览器处理了输入，应用可能没有对应的 listener；listener 可能执行后直接返回；也可能已经发出请求，只是结果还没回来。这几种情况，页面都可能没有变化。

沿着这个问题去查 CDP 后，我修正了一个最初过强的判断：浏览器并不是完全没有处理反馈。Chromium 内部有输入事件 ACK，但现有 CDP 并没有给调用者一份完整的、能关联单次操作的处理回执。成功响应也没有把内部 ACK 的处理来源和状态完整交出来，不能直接等同于“应用处理完了”。Chromium 输入处理源码

我的建议是把这些层次分别记录：协议是否成功返回、DOM 事件是否送达、同步 listener 是否处理完、后续异步活动是什么，以及目标或页面最终发生了什么变化。尤其要保留“不知道”：listener 返回，不代表它启动的 Promise、网络请求、定时器和框架更新都结束了。

我觉得 Runtime.addBinding 很值得利用。它可以让页面或注入的观测代码通过 Runtime.bindingCalled 主动上报结构化信息，再尽可能关联到动作 ID。它本身只是通道，开始、结束和关联关系还要由观测代码定义。Event Timing 可以补充部分事件的处理时间，但有上报阈值，缺少记录也不能直接判为没处理。

我最后写进评论的重点是：处理过程的证据和结果变化的证据，应该独立保留。 页面变化仍然有价值，但不能代替对执行过程的观测。

参与记录：我发布的英文评论。这是一份分层设计建议，还没有变成我提交的实现。

OpenCode #6330：等一个人的回答，不必让整个会话都停下来

这个提案最初想解决跨客户端的人机交互问题：插件发出表单、选择或确认请求，TUI、桌面端和 Web 分别显示界面，再把回答送回执行流程。评论后来扩展到了自定义组件和插件通信。有人主张先拆开 HITL 与自定义 UI，也有人建议先打通服务端插件到客户端插件的事件通道。

我的理解是，一个等待人工输入的问题，最后暴露出了通信和调度的边界。模型需要这次 HITL 的答案，不代表其他任务也必须停下来。对于支持异步交互的模型和运行时，可以先发出请求，继续做不依赖答案的工作，等真正需要时再取结果。顺序执行的运行时也可以使用同一套协议，只是立即等待。

我提出可以借鉴浏览器的事件机制：模型或工具发起 emit(...)，内置处理器或插件监听请求。第三方如果想定制 UI，可以在初始化时注册自己的处理器，替换某些类型的默认呈现。

讨论后，我把“禁用原生事件”改成了“替换默认处理器”。事件还要存在，其他观察者也可能需要知道请求的状态。这里可以借鉴 DOM 的区分：preventDefault() 是取消默认行为，stopPropagation() 是停止传播。跨进程实现还要提前选定处理器，避免第三方接管时，原生弹窗已经打开。DOM 事件标准

类型设计上，我给的是一个推导思路：从最终需要保存的数据出发，而不是先列出所有 UI 控件。确认可以返回 boolean，普通单选返回一个选项 ID，多选返回数组，排序也可以用数组，但必须保留顺序约束；文本返回字符串，组合表单可以返回带类型的对象。它们只是例子，我不想提前把所有交互限制在几个枚举里。

这个角度也有边界：数据形状相同，不代表语义相同。多选和排序都能存成数组，默认客户端却不能丢掉排序要求。布局和组件偏好可以交给 metadata，影响答案正确性的约束仍要进入协议，或者声明为必须支持的扩展能力。

我还提出了 emitOnce、emitRace、emitTimeout、emitMaxTry 这样的扩展。进一步讨论后，我更倾向于把它们看成同一个请求生命周期上的策略：一个请求最多接受一个最终答案，多个合法回答者中取首个有效结果，超时明确结束，投递重试沿用同一个请求 ID。重新投递与重新问用户，是两回事。

普通事件总线还不够。Node 的 EventEmitter 同步调用监听器，并不等待监听器的异步结果。这里需要自己补上请求身份、响应关联、校验、取消和过期状态。我想保留的是事件驱动的扩展方式，同时把等待和恢复做成有明确状态的协议。

参与记录：我发布的英文评论。

OpenCode #12711：主 Agent 要监督团队，但不能靠沉默猜成员是不是卡住了

Agent Teams 提案把一个 lead 和多个 teammate 组织成团队。成员有独立 session，可以并行工作、直接发消息、共享任务。它用 synthetic user message 把消息送入对方会话，空闲成员收到消息后可以被唤醒。评论里已有稳定身份、关联 ID 和 ACK 的建议。

顺着上一个讨论，我马上想到：如果要问人的不是主 Agent，而是 subagent，这套 HITL 怎么传上来，又怎么把答案准确送回去？

我觉得 synthetic user message 本身没有问题，它可以继续承担把协作信息送入模型上下文的作用。但主 Agent 同时也在承担某种守护职责：子 Agent 可能假死，也可能只是很久不输出。如果看不到运行状态，主 Agent 根本不知道应该等、追问，还是中断。

所以我建议在消息外面增加运行时能理解的信息：原始 agent、session、task、请求 ID、等待原因，以及谁可以回答。HITL 经主 Agent 转交时，要保留原请求身份。普通技术问题可以由主 Agent 在权限内处理，明确要求人来授权的请求仍然要交给人；回答回到原请求，恢复依赖它的工作，其他成员继续推进。

监督也需要拆开职责。运行时负责采集执行阶段、当前工具、耗时、最后活动时间和阻塞原因；主 Agent 根据这些信息决定下一步。等待模型、执行长工具、等待用户、等待依赖，以及疑似失去响应，不能都只显示为 active。心跳能说明运行组件还活着，却不能证明任务有进展；没有文本输出也不能证明假死。

在这之上，我希望通信协议增加优先级和中断能力。但高优先级不等于立即打断：普通进度可以排队，约束变更可以在下一次工具调用前介入，HITL 应尽快呈现给用户，用户取消则需要直接到达运行时，不必等模型下一轮读到消息。

中断也需要回执：已请求、已接收、正在停止、已停止，或者无法中止、结果仍不确定。发送了取消消息，不能就显示成任务已经停止；停止推理，也不会撤销已经发生的外部操作。MCP 的取消和进度协议可以作为参考，但团队监督还需要更完整的状态定义。

我在发布的英文评论里，也表达了愿意承担一部分开发工作。具体从消息结构、HITL 路由，还是执行状态与中断支持开始，我希望和维护者一起确定一个范围明确的切入点。目前这是参与意愿，还不是已经获批或完成的开发任务。

三个讨论走下来，我越来越在意同一件事：系统能不能明确告诉我，一次请求现在由谁负责，正在等什么，已经完成到哪一步。浏览器操作、人工回答、队友消息和取消请求都需要这种边界。后续如果有机会动手，我会先选一个小范围，把这些状态真正跑通。

记录可验证的修复进展，也记录仍有空间参与的架构与规范讨论。

数据截止：2026-09-09T21:47:31+08:00（Asia/Singapore）。以下是当日截至该时间的记录。

1 今天的候选 issues

覆盖说明：PR 统计覆盖 13 个关注仓库中我的今日更新 PR 与全部开放 PR，分页已取全（21:38 核查）。候选来自今天的调查、提案和交付记录。部分仓库的采集受限，列表不代表所有待修问题。

2 今天提交的 PR

• fix(install): handle missing Windows settings device IDs safely (affaan-m/ECC#3044) — 开放；提交于 17:24:22
  • 关联 issue：issue
• fix(pi): preserve OpenCode session headers (CherryHQ/cherry-studio#20267) — 已合并；提交于 14:28:26
  • 关联 issue：issue
• fix(ai-core): repair restored tool result names (CherryHQ/cherry-studio#20281) — 开放；提交于 18:33:31
  • 关联 issue：issue
• fix(auth): wait for owner transition before login initialization (makecindy/cindy#4173) — 已合并；提交于 15:59:28
  • 关联 issue：issue
• test(pi): wait for follow-up command observation (makecindy/cindy#4185) — 开放；提交于 17:32:41
  • 关联 issue：issue

3 PR 合并、挂起与关闭

统计截止：2026-09-09T21:47:31+08:00（Asia/Singapore）。今日按该时区的 2026-09-09 计算；挂起为截止时全部本人开放 PR，包含此前提交的 PR。合并与关闭互斥，关闭仅统计未合并关闭。 覆盖：完整；PR 统计覆盖 13 个关注仓库中我的今日更新 PR 与全部开放 PR，分页已取全（21:38 核查）。候选来自今天的调查、提案和交付记录。部分仓库的采集受限，列表不代表所有待修问题。

• 今日提交：5。
• 今日新提且截止时仍开放：3。
• 今日合并：2。
• 截止时挂起：3。
• 今日关闭（未合并）：0。

挂起明细：

• fix(install): handle missing Windows settings device IDs safely (affaan-m/ECC#3044) — 待维护者 review；最近已核查自动检查通过
• fix(ai-core): repair restored tool result names (CherryHQ/cherry-studio#20281) — 待维护者 review；最近已核查 CI 通过
• test(pi): wait for follow-up command observation (makecindy/cindy#4185) — Windows CI 失败，等待维护者重跑/反馈；作者无重跑权限，见现有跟进记录

今日合并明细：

• fix(pi): preserve OpenCode session headers (CherryHQ/cherry-studio#20267)
• fix(auth): wait for owner transition before login initialization (makecindy/cindy#4173)

4 值得参与的架构、规范与工程讨论

讨论覆盖：不完整；从 13 个仓库的当日 issue/PR 材料筛选，5 个入选讨论均已核查原帖与关键评论（21:39 核查）。9 个仓库的最新增量受到 GitHub 请求频率限制，尚未穷尽全部 Discussions。

• Browser Use：怎样证明一次浏览器动作确实推进了任务？（browser-use/browser-use）
  • 类别：工程实践 / 可观测性契约
  • 开放问题：动作何时算结束：DOM稳定、事件结束还是有界观察窗口？；预渲染SPA节点数不变时，如何区分真实变化、无效动作与观测失败？
  • 主要立场：提案倾向先在ActionResult.metadata加入紧凑证据结构。；讨论建议分开派发、结束、变化和恢复；也有人指出元素数量不足以判断SPA动作成败。
  • 为什么值得关注：它会直接影响自动恢复、重试和调试；错误的无效动作判定可能让系统反复执行已成功的操作。
  • 参与切入点：先提供一组可复现页面夹具和判定矩阵：既有节点变化、真实no-op、观测失败、导航、延迟更新、遮挡；据此建议原始观察与推断结果分层。
  • 证据：原帖及关键反馈 1；原帖及关键反馈 2；原帖及关键反馈 3；原帖及关键反馈 4
  • 信息截止：2026-09-09T21:39:53+08:00
• OpenCode：插件跨客户端 UI 交互的最小协议（anomalyco/opencode）
  • 类别：架构 / 插件协议
  • 开放问题：先做有类型的人机请求/响应、通用插件事件通道，还是完整组件注册系统？；取消、重连、多客户端响应归属与背压该由哪层负责？
  • 主要立场：原提案希望复用权限交互形式，以声明式UI intent覆盖表单、确认和进度。；协作者要求先明确UI插件架构；后续讨论提出将typed HITL与自定义组件分开，或先提供有命名空间的最小事件通道。
  • 为什么值得关注：这决定插件、服务端、TUI/Desktop/Web之间的长期接口；合适的边界能减少各插件自建HTTP sidecar。
  • 参与切入点：写两层协议短案：事件传输定义correlation、响应所有权、取消、重连、背压；再叠加typed HITL。附一个TUI/服务端插件原型与组件注册仍不可替代的场景对照。
  • 证据：原帖及关键反馈 1；原帖及关键反馈 2；原帖及关键反馈 3；原帖及关键反馈 4；原帖及关键反馈 5
  • 信息截止：2026-09-09T21:39:53+08:00
• OpenCode：Agent Teams 的身份、消息与恢复契约（anomalyco/opencode）
  • 类别：架构 / 多任务运行时
  • 开放问题：扁平团队应成为独立概念，还是扩展现有任务树？；成员稳定身份、消息确认、并发认领、重启恢复与每成员MCP权限如何定义？
  • 主要立场：提案希望引入具名团队、持久状态、共享任务与TUI集成。；讨论补充了每成员凭据隔离、稳定内部ID、消息correlation/ack等要求；不同原型尚未解决统一契约。
  • 为什么值得关注：团队能力把任务归属、消息投递、并发与权限变成核心产品行为，先定义异常路径能减少实现后的返工。
  • 参与切入点：基于我们现有多任务监控/跟进经验，提供异常场景规范与小型验证工具：重名成员、发送/确认竞态、交付中重启、并发claim、成员退出、越权MCP调用。
  • 证据：原帖及关键反馈 1；原帖及关键反馈 2；原帖及关键反馈 3；原帖及关键反馈 4
  • 信息截止：2026-09-09T21:39:53+08:00
• Maka：图范围信号与通用成员通信的边界（apache/maka）
  • 类别：架构 / 协调协议
  • 开放问题：信号是否只能唤醒root supervisor，由Agent Graph继续独占调度？；信号、任务所有权/settlement记录和mailbox消息如何区分；排序、去重、重放保证是什么？
  • 主要立场：提案寻求可审计、可恢复的graph-scoped signal。；已有技术意见主张v1只唤醒supervisor，暂不引入直接唤醒成员或通用mailbox；维护者对最终契约尚无定论。
  • 为什么值得关注：一个发消息接口很容易意外成为第二套调度器，破坏原有任务准入、所有权和恢复语义。
  • 参与切入点：提出小型v1状态机与事件契约，附重复投递、过期成员身份、supervisor重启、signal与任务完成竞争的轨迹例子；明确v1不做哪些功能。
  • 证据：原帖及关键反馈 1；原帖及关键反馈 2
  • 信息截止：2026-09-09T21:39:53+08:00
• Maka：Runtime Event 的语义标注应放在哪里？（apache/maka）
  • 类别：规范 / 来源与可信度模型
  • 开放问题：语义标注放event envelope、内容metadata，还是独立关联事件？；自报confidence与工具/审核背书怎样区分；词汇表、版本兼容、脱敏及重放怎样约定？
  • 主要立场：原提案希望增加可选、向后兼容的语义命名空间，并把它与权限/路由决策分离。；已有实现认领，但尚无维护者对字段位置、词汇表或可信度模型的公开定论，仍可参与规范评审。
  • 为什么值得关注：可机器读取的来源信息有助于评估和重放，但可信度标签若混入权威事件模型，会带来信任边界与长期兼容成本。
  • 参与切入点：写三种存储位置的方案对照，补自报/工具/审核背书的信任矩阵；用小型round-trip原型验证未知字段、schema升级、脱敏和存储开销。
  • 证据：原帖及关键反馈 1；原帖及关键反馈 2
  • 信息截止：2026-09-09T21:39:53+08:00