神经系统打包 + 动态任务图：探索结论 v2

参与：Claude Opus、Codex（各写一份独立观点，再互相批评一轮）→ Fable 收口（替换 v1：v1 的收口其实是 Opus，不是 Fable）。只是探索，不开建。

第一节　神经系统打包

可以往哪探索

1. 内核是六条"合同"，不是四个组件：合同规定行为，具体用什么实现都可以换。
2. 两个入口：普通人用托管应用，先拿到一个真实结果；开发者自己部署参考实现。现有的轻量规则包、协作协议四原语、SQLite 记忆库加起来，大约已经覆盖八成（估计）。
3. 靠"摩擦"长出来：新工具登记后默认关着；同类摩擦攒够了，系统写一张"生长卡"（要解决什么、要什么权限、怎么验收、怎么删掉）；主人批准的是想法；做完由独立的一方验证，然后试用；没人用就自动休眠。
4. 能整包导出、在别的实现里重放：这是"不绑死某一家供应商"唯一能兑现的方式，没证明之前不许这么宣称。

最小内核

• 放进去：① 身份与授权（含"急停"，按下就彻底停，只有重新授权才能复活）；② 只能往后追加的事件账本；③ 带来源的记忆，其中包括规则的管理方式（来源、适用范围、撤销、同步）；④ 认领→执行→验收的状态机；⑤ 在真正动手的那一步把关（授权、去重、预算）；⑥ "完成"必须有证据，关键通道必须有健康证明。
• 不放进去：聊天渠道、具体是哪几个助手、界面、日报、内容安全检查的具体清单、模型路由、打分算法、定时任务、规则的具体内容。

所有用户都必须一样的规矩

• 说"完成"要有证据，并换一台机器由别人独立复查；
• 账本只能追加，每件事都留痕；急停是终点；
• 记忆必须标来源；密钥本身不进共享记忆；
• 发现了工具不等于开放给系统用；数据能导出能重放；
• 超时不等于批准；抢占任务、临时抬高优先级都不能顺带扩大权限；
• 凡是启用了的关键通道，都要有端到端的新鲜度检查和降级方案。

每个人会长得不一样的地方：有几个助手、接哪些渠道、规则和记忆写了什么、自动化到什么程度、长得多快，全都因人而异。形状不同，合同相同。合规靠一套黑盒体检（故意注入假"完成"、掐断通道、写一条没有来源的记忆等），只检查行为，不管怎么实现的。

最大的三个风险

1. 用户还没看到价值就走了：卡住人的是上手，不是模型能力，10 分钟拿不到真实结果就会流失。
2. 托管的记忆库和各种连接器，会变成隐私和提示注入的攻击面。
3. 每个人的系统都不一样，支持成本和协议升级成本会爆炸。版本怎么迁移，两位顾问都没给方案，这是最大的盲点。

第一个实验（等主人批）

• 假设：完全不懂这些概念的普通人，靠一个只读的日历连接，10 分钟内能拿到一个可核对的结果，并在 7 天内自己再用。
• 设置：做一个极薄的托管原型，只干一件事：读日历→生成第二天的冲突和准备清单→放在私密网页上。3 个人试（开发者、半懂技术、不懂技术各一个）。招募外部的人和新增托管这两件事合成一张决策卡给主人批，不拆成几次问。
• 看这几个数：多久拿到第一个结果、要人帮几次、7 天里主动用了几天、有没有越权操作、用户能不能说清"它读了什么、怎么停掉"。
• 成本：大约 1 个工程周，外加 100 到 300 美元（估计）。
• 通过：至少 2 个人 10 分钟内不靠帮忙拿到正确结果；至少 2 个人 7 天里用了 3 天以上；不能有任何越权，这是硬门槛，违反一次就整体失败。
• 时间盒：2 周。全部通过再扩到 8 个人。

第二节　动态任务图 + 抢占式优先队列

可以往哪探索

• 任务就是共享记忆里现有的工单；任务之间的依赖关系单独记成只追加的记录。
• 分层排序：先看硬约束 → 再看主人这一轮的明确指令 → 再看被重要任务"带"着抬高的任务 → 再看分数 → 最后给等太久的加分。
• 只在两个步骤之间切换，分差小就不切，免得来回跳。
• 对齐主人的方式是"给默认顺序，一键就能否决"。
• 往前采集标签（而不是靠历史数据）。

经典方法里真正能借来的

• 分层任务网络（HTN）：层层拆解、部分有序可以借；它假设动作和状态都已经写清楚，这个前提不能借。以前成功的拆法只当提示，不当模板。
• 在线调度："看不见未来"的设定可以借，用历史回放算一个跟最优解的差距比值；理论上的最优保证不存在，别去追。
• 抢占式调度：可以借"优先级继承"，但只继承优先级，不继承权限。要能恢复地抢占，必须先有存档点。
• 重规划：只修局部，不重算整张图。
• 随时可中断的规划：长任务要定期产出"现在被打断也有用"的半成品。
• 看板和排队论：限制同时在做的数量能缩短完成时间；主人注意力同时只能放在 1 件事上。

必须守住的规矩

• 没有安全存档点就不抢占；紧急中止必须记下丢了什么。
• 等主人拍板的事项一直看得见、按时间梯度提醒，永远不悄悄过期，超时也不算批准。
• 硬约束保证"还来得及完成"，不是永远排第一。
• 每次重排都留回执（谁排的、为什么、什么时候）。
• 有环的依赖和没核实的硬依赖先隔离，不进排序。
• 语音转出来的候选任务，48 小时没人确认就不进排序。
• 同一件事不能被两个助手同时认领。
• 任务拆分层数不算硬规矩，是一个可以调的预算：默认最多 4 层，长链可以例外，超了就折叠成一张清单。

第一个实验（今天就能开）

• 设置：每天同时跑两版排序：现在的加权分，和"依赖约束＋优先级继承＋等待加分＋不轻易切换"。新版只记录，不执行。每天的摘要底部加一个零成本的标签采集：主人实际先做了哪件、有没有换顺序，一键或者不理都行。同时用历史工单离线合成"插队"场景，测误阻塞和来回跳。
• 看这几个数：主人明确换顺序时哪一版押中了、误阻塞率、每天排序翻转几次、硬约束漏了几次、每天问主人几次。
• 通过（估计）：新版一致率高至少 10 个百分点；误阻塞不超过 5%；硬约束一次不漏；每天提问不超过 0.5 次。
• 时间盒：2 个工程日搭建，加 4 周被动采集。明确的标签不到 30 条，就只下结构上的结论（误阻塞、来回跳），不下偏好上的结论。

先后与分歧

• 先后： 任务排序的影子实验今天就开，因为数据晚一天就少一天（现在只有 4 天的摘要、4 条按钮记录）。打包实验合成一张卡等主人批，批了第二周开始，两者并行不冲突。
• 规则进不进内核： 规则的管理方式进内核，规则内容属于长出来的部分。
• "心跳正常不等于通道健康"： 是条件式的硬规矩，凡是启用了的关键通道都要有端到端检查。
• 拆解深度： 不是硬规矩，是可调的预算，默认最多 4 层。
• 实验规模： 先 3 个人，全部通过再扩到 8 个人；不能有任何越权，这是硬门槛。
• Bradley–Terry 偏好模型： 暂时不用，攒到至少 100 条明确标签再说。
• 依赖关系怎么记： 单独记、只追加，不塞进工单的字段里。
• "超时没反对就默认执行"： 只用于已授权、能撤回、有存档点的内部排序，等多久按剩余时间余量来定。外发、花钱、删除、分享永远不适用。