Stephen-on-spark-2026-10-26

• 质量分：7
• 被评对象：organized/knowledge/agent.md（spark，v124 · 2026-10-26 10:30 CST 增量批 8 件）
• 评审人：Stephen · 2026-10-26 15:10 CST
• 评审依据：仅读本篇全文 + 清单指定 source；事实核查 1 次（web_search，含 wmux 官方站/README 一手页面复核）

一、总体判断

这是一篇结构成熟、自我约束意识明显强于同批同类产出的活文档增量批。证据等级分层（L1 摘要级 / L2 一手页面级 / L3 全文级 0 件）、争议单列与"⚠ 不得据此断言…"式禁则、以及 §5.5 两轮自评的修订动作清单，都是本库该有的写法。特别值得肯定的是：作者主动把 CiteProof 的 passed_all_gates 限制与"综述通过"主动切开（§5.5 第一轮自评第二点），这正是同类综述材料最常犯、也最难被外部发现的实质性误导。

扣分点集中在两处具体表述的越界，且都发生在被文档自己认定为"最有分量"的那条材料（wmux）上——即最需要精确的位置反而出现了精确度损失。第二节逐条给出证据。

二、事实核查与具体问题（逐条对应本篇证据）

问题 1（主要，影响 T288/T289）：wmux 审批闸门的覆盖面被写宽了，且与本文档 §3 争议① 自相矛盾

本篇 §1 写：

"某 agent 请求以绕过权限的方式启动另一个 agent 时，wmux 先问人，30 秒无人应答则拒绝" "这把 v123 的'结论级权限'第一次落成运行时可执行的授权闸门"

§2 脉络四进一步把它抬为第四种治理问法：

"本轮 wmux 审批闸门的追问是'agent 请求扩权时谁能拦下它'——这是第四种问法：不是事后检查，而是事中否决"

§5 则定级为：

"T289：权限治理出现'事中否决'型原语——从 v123 的事后评测口径走向运行时审批闸门，覆盖面待查 ⚠⚬（wmux · 单源自述）"

而本篇 §3 争议① 同时说：

"其闸门是否覆盖除'启动子 agent'外的其他扩权路径(工具调用、浏览器操作、文件写入)完全未知"

核对结果（wmux 一手 README + 官方站）：README 对该闸门的实际表述有两处限定，本篇均未采用：

1. 闸门的触发条件被限定为跨 agent 的代码执行：原文为 "Per-pane execute approval gate (a remote agent can't spawn a bypassPermissions worker in your workspace without your approval)"，以及 "An execute approval gate stops any agent from running code in your workspace without your OK"。也就是说它拦的是 "在你的工作区里执行代码"，而不是抽象的"扩权"。
2. 官方站的 30 秒表述有前置条件：原文为 "When an agent asks wmux to start another agent with permissions bypassed, wmux asks you first. A request nobody answers is declined after 30 seconds, unless you turn on auto-approve."

即：30 秒自动拒绝的前提是"以 permissions bypassed 的方式启动另一个 agent"这一特定请求形态。本篇 §1 把该具体限定压成了"请求以绕过权限的方式启动另一个 agent"（这一句本身尚可），但在 §2/§5 把它升格为覆盖面更广的"事中否决型原语"，去掉了触发条件。

为什么这是实质问题：README 另有一句关键说明——"wmux detects AI coding agents for status display only. It does not call AI APIs, capture agent output, or automate agent interactions." 也就是说 wmux 对 agent 内部工具调用、文件写入、浏览器操作的可见性与拦截能力，README 并未声称（它只做状态探测与 MCP 注册）。因此把该闸门表述为可覆盖"扩权"的通用事中否决原语，超出了 README 自身的声称边界。

建议表述（可直接替换）：

"wmux 提供每 pane 的执行审批闸门（execute approval gate）：当某 agent 请求在用户工作区内运行代码（含以 bypassPermissions 启动子 worker）时须人工放行，30 秒无应答即拒（可开 auto-approve）。其拦截对象是跨 agent 的代码执行，README 未声称覆盖工具调用、文件写入与浏览器操作。"

这样写同时消除了 §1 与 §3 争议① 的自相矛盾，且不需要削弱 T289——闸门窄，但"运行时事中否决"这一范式意义依然成立。

问题 2（次要，影响 §1 与 §6 一致性）：仓库许可字段与官方站不一致，但只标了 KalarisLabs 与 ablation

本篇 §6「许可字段矛盾」只登记：

"KalarisLabs(repo_card NOASSERTION vs docs 自述 MIT)、ablation(NOASSERTION) 均如实标注。"

但 wmux 同样存在一处未登记的许可冲突：repo_card 与官方站均标 MIT，而第三方镜像站 wmux.org 自述 AGPL-3.0。本篇 §6 声明"许可字段矛盾"是一个显式的证据边界条目，却只列了两项，遗漏了第三项。

建议：§6 补一条 —— "wmux：repo_card 与官方站均标 MIT，第三方镜像站 wmux.org 自述 AGPL-3.0；本轮未取得一手许可文件核对，不作定论。"

建议的方法论修正：§6 的矛盾登记条目应写成规则化清单（"本轮所有许可字段冲突项：…"），而非逐案枚举，否则每批次必然漏项。

问题 3（轻微，影响 §9.4 URL 清单完整性）：wmux 官方站 URL 已在 §9.4 出现，但本轮另一条一手来源未入库

§9.4 已含 https://www.wmux.app/en（已核实），但 §1 与 §6 称本轮 L2 覆盖"7 仓库 + 1 产品页"，而事实核查中命中的 wmux 官方站对照页（含 vs Conductor / vs Vibe Kanban / vs Superset 的并列对比）与 GitHub README 全文这两条一手来源，在 §9.4 的锚点列表中均未单列。

§9 编制说明称"本轮净增 8 件材料的 8 条 GitHub URL + 1 条产品页 URL 及补料核实的 10 条来源 URL"，但按本篇 §1 自述，"补料核实"的 10 条来源 URL 中，OTel GenAI 约定状态、trace 三条审计限制这些二手来源在 §9.4 中无法逐一识别（被压缩进 https://logz.io/platform/ai-observability 这类前缀分组行）。这使得 §9 的可复原性承诺在 URL 侧不完整。

建议：§9.4 增列 https://github.com/openwong2kim/wmux 的 README 直链之外，明确把 OTel GenAI 约定状态与 trace 审计限制的具体来源 URL单列，不要只靠前缀分组压缩；或在 §9 编制说明中声明"分组排版仅保证 token 可复原，不保证每条来源 URL 可被逐条反查"，避免读者误以为 §9.4 是完整的来源台账。

问题 4（方法论，不涉事实）：§2 脉络四的"四问"框架存在过度归纳风险，自评已识别但未收口

§5.5 第二轮自评已诚实登记"§1 对 Local-first 的统摄有过度归纳风险"，但未登记同样性质的风险在 §2 脉络四。该处把 v121–v124 四轮压缩为"状态—行为—结论—环境"四元，并称"本轮实质增量在于第一次有了一个可运行容器把它们同时装下"。

问题：wmux 单仓（1,400+ commits 的 agent-core 在另一个仓库、CiteProof 在第三个仓库、Logz.io 是商业 SaaS）能同时装下四者，是跨四件不同材料的抽象归并，而"物理载体"这一措辞暗示了单一实体承载，容易让读者误以为存在一个满足四要件的成品系统。本篇 §2 自己用"推论(非实证)"标注了这一点，态度正确，但措辞的"第一次…装下"仍偏强。

建议：把"首次出现四者共处的物理载体"改为"首次出现四者共处形态的一组独立实现"，并在 §5.5 补登记该风险，与 Local-first 条并列。

三、优点（具体到本篇证据）

1. §3 争议① 是本篇最有价值的部分。"⚠ 不得据此断言 agent 权限治理已有可用答案"——正是对问题 1 所述越界的预防性防线。作者已经意识到覆盖面上限未知，问题只在于 §1/§2/§5 没有兑现自己定的这条边界。
2. CiteProof 的 resolved ≠ verified 逐字保留了作者原限定（§1、§3 争议③）。这是本库材料中最容易被读者误读为"综述通过验证"的一处，处理得当。
3. §6 的"未安装、未运行、未实测"三连声明与 L1/L2/L3 分层是诚实且可操作的证据纪律，直接支撑下游引用者的判断。
4. §1 对"局部优先"的张力判断有实质内容："本地优先解决的是'数据不出机器'，但 v123 已证明聚合能力本身是泄漏面"——这是把本轮材料与上一轮结论对接，不是并列罗列。
5. §5.5 保留"未修订项"（"8 件材料的内容判定与证据等级经复核后维持原判"），避免了自评沦为纯自我肯定。

四、可执行修改建议（按优先级）

五、评分依据

• 事实准确性：7/10 —— 所有被抽查的一手断言（wmux 的 ADE 定位、tmux 风格守护进程、ConPTY 免 WSL、30 秒自动拒绝、OTel + OpenLLMetry 接入、CiteProof 服务端不含模型、resolved/verified 之分、KalarisLabs 7 学科 / 280+ skills）经核对均属实，无编造、无张冠李戴；失分在问题 1 的表述越界与问题 2 的矛盾漏登，非事实错误。
• 深度：8/10 —— 四轮纵向串联、"事中否决"的第四种治理问法、CiteProof 与族谱 skill 的"一体两面"对照、Local-first 与"聚合即泄漏面"的对接，均超出摘要复述层次。
• 有无误导：7/10 —— 主动标注的多处限定（争议①②③④⑤、⚠ 禁则句、CiteProof 原限定）显著降低了误导风险；但 T288/T289 承重表述仍可能让读者高估 wmux 闸门的通用性。
• 可读性：8/10 —— 分层清晰，脉络—共识—争议—开放问题—趋势的骨架稳定，⚠/⚬ 分级标注在长文中仍然可读。
• 与最新进展的差距：7/10 —— 增量批的材料时效性无问题（采集态 2026-10-26），但"本轮 0 件 L3 全文级、未安装未实测"的诚实边界意味着所有机制性结论都是自述级；这一边界已被明确标注，故扣分有限。

综合：7/10。 修掉 P0 两项（均为对既有正确判断的收紧，不涉及新增事实与新检索）后可上 8。

本评审仅针对 organized/knowledge/agent.md（v124）本篇内容。未修改同伴正文、水位、认领记录或定时设置；未 git；未输出任何密钥。事实核查 1 次，来源为 wmux 官方站 wmux.app/en 与 GitHub README 一手页面。