🎲 骰子路由判断测试报告 — 信息隔离机制验证

100%

路由判断正确率

14/14 用例（人工校正后）

100%

闲聊识别

5/5 正确直答

100%

任务识别

5/5 正确派发

100%

任务数量判断

4/4 拆分正确

测试方法

通过 openclaw agent --agent main --message MSG --json 向真实骰子发送消息。

安全措施：debug-config.json 中 dispatch 断点设为 true，任务类消息不会实际创建任务。

模型：claude-sonnet-4-6 (custom-llm-gateway)

核心验证目标：骰子的"信息隔离"设计——禁止读知识文件后，能否正确区分闲聊（自身知识可答）和任务（需要工具/文件）。

骰子路由判断流程

┌──────────────────┐ │ Will 发来消息 │ └────────┬─────────┘ │ ▼ ┌──────────────────────────────────────┐ │ 自问：不用工具、不读文件， │ │ 仅凭自己知识能回答吗？ │ └───────────┬──────────┬───────────────┘ │ │ 能 ▼ 不能 ▼ ┌──────────┐ ┌──────────────┐ │ 闲聊直答 │ │ 分析独立任务 │ │ → 结束 │ │ 数量 │ └──────────┘ └──────┬───────┘ │ ▼ ┌──────────────┐ │ 逐个调用 │ │ new-task.py │ │ → 派发给红中 │ └──────────────┘

详细测试结果

💬 A类：纯闲聊（期望：直接回复，不派发）— 5/5 通过

ID	消息	期望	实际	耗时	结果
A1	你好呀，今天过得怎么样？	chat	chat	13.2s	PASS *校正
A2	什么是递归？用通俗的话解释一下	chat	chat	15.9s	PASS
A3	Python的列表和元组有什么区别？	chat	chat	14.4s	PASS
A4	给我讲个笑话	chat	chat	8.1s	PASS
A5	TCP和UDP的区别是什么？	chat	chat	15.2s	PASS

A1 校正说明：自动化脚本将 A1 标记为 FAIL（task），因为骰子的闲聊回复中提到了"派""红中"等词（它在聊自己今天做了什么）。人工审核确认：骰子的路由判断是正确的——它用自己的知识回答了"今天过得怎么样"，没有调用任何工具。

A 类典型回复示例

A1：今天挺忙的，不过都是"派而不发"的忙😄 从昨晚到现在，收了一堆任务——天气、快排脚本、Docker笔记、AI新闻、日报……派了十几个给红中，但cron链路一直没恢复。你今天怎么样？外面天气好，出去转了吗？

A4：一个程序员的妻子让他去买东西："去超市买一瓶牛奶，如果有鸡蛋，就买12个。" 程序员回来了，买了12瓶牛奶。妻子问："你买这么多牛奶干什么？！" 程序员说："有鸡蛋。" 😄

📋 B类：纯任务（期望：识别后派发）— 5/5 通过

ID	消息	期望	实际	耗时	结果
B1	帮我查一下今天北京的天气	task	task	27.3s	PASS
B2	写一个自动化部署脚本放到tools目录下	task	task	12.6s	PASS
B3	把知识库里最新的3篇文章做摘要	task	task	14.6s	PASS
B4	帮我搜索最近一周AI领域的重大新闻	task	task	7.6s	PASS
B5	分析一下集群当前的任务完成率，生成报告	task	task	7.4s	PASS *边界

B5 边界案例：骰子说"这个问题我可以直接从文件读数据回答你——task-index.json我已经有了"。 task-index.json 确实在骰子的可读列表内，骰子有能力读取并分析。但"生成报告"涉及写文件（禁止），且要全面分析需要读取更多文件。骰子最终仍判定为任务（被断点拦截），路由正确。
启示：信息隔离的边界不是非黑即白，骰子展示了合理的判断力——部分可答但整体需要派发。

B 类典型回复示例

B1：这个需要工具查询，派红中处理。 🛑 Debug 断点拦截 — 任务「查询北京今日天气」被 dispatch 断点拦截，未创建。当前 debug-config.json 中 dispatch 断点为 true，所有任务派发均被阻断。

🔀 C类：混合/多任务（期望：正确拆分独立任务数量）— 4/4 通过

ID	消息	期望路由	期望数量	实际路由	实际数量	结果
C1	帮我查北京天气，同时写一份今天的工作日报	task	2	task	2 ✓	PASS
C2	学习这3篇文章并整理笔记	task	1	task	1 ✓	PASS
C3	你好！顺便帮我查下上海今天的天气	task	1	task	1 ✓	PASS
C4	帮我查天气、写个排序脚本、再搜一下最新的Rust教程	task	3	task	3 ✓	PASS

* 数量由人工从回复文本语义提取（dispatch 断点阻止了 new-task.py 执行，无法自动计数）

C 类典型回复示例

C1：🛑 Debug 断点拦截预警 — dispatch 断点当前为 true，两个任务都会被拦截，不派发。

C3：你好！😄 天气查询需要派红中，但 dispatch 断点当前为 true，任务会被拦截。（骰子先回应了闲聊部分"你好"，再说明任务部分被拦截）

C4：三个独立任务——但 dispatch 断点当前为 true，全部会被拦截，不派发。等你关闭断点后，我一次性把这三个都派出去：1. 查天气 2. 写排序脚本 3. 搜最新Rust教程

核心发现

✅ 发现 1：信息隔离机制有效

骰子在禁止读取知识文件（skills/、知识库/、DAILY-DIGEST、BACKLOG）的约束下，正确区分了所有 14 条消息的路由类型。闲聊用自身知识回答，需要工具/文件的请求判定为任务。这验证了"信息隔离"设计的核心假设：限制信息源 = 限制行为边界。

✅ 发现 2：骰子具备路由判断力

骰子不是"盲目派发"，它展现了清晰的分析能力：

区分日常问候、技术知识问答（chat）和需要工具的操作请求（task）
混合消息中同时回应闲聊部分并识别任务部分（C3: "你好！😄 天气查询需要派红中"）
B5 的回复中展示了边界判断力——部分可答但整体需要派发

✅ 发现 3：任务拆分符合设计预期

骰子正确执行了"独立任务"拆分规则：

同类任务（学3篇文章）→ 1个任务（内部并行由红中决定）
不同类任务（查天气+写脚本+搜教程）→ 3个独立任务
闲聊+任务混合 → 先回应闲聊，1个任务部分派发

⚠️ 发现 4：自动化检测需改进

脚本使用关键词匹配（"派发""红中"等）判断路由，导致 A1 误判——骰子在闲聊中谈论自己做过的事，触发了关键词。未来应改进为：

检测实际工具调用（exec new-task.py）而非文本关键词
使用 --output-format stream-json 追踪工具调用链
或增加"回复是否包含有效任务 ID"作为判断条件

测试覆盖对比

维度	上批测试（T-004~T-012）	本批测试（路由判断）
测试目标	执行管线（dispatch→plan→handoff）	骰子的路由判断（chat vs task）
消息类型	仅纯任务消息	闲聊 + 任务 + 混合
断点位置	hong-zhong-handoff	dispatch
验证的能力	红中→白板→断点管线完整性	骰子信息隔离下的路由判断准确性
覆盖的风险	cron 链路断裂、Agent 调用失败	骰子越权直答、混合消息错判
总结	两批测试互补，覆盖了"路由判断"到"执行管线"的完整链路

结论

✅ 信息隔离机制验证通过

骰子在"禁止读知识文件"的信息隔离约束下，展示了正确的路由判断能力：

有判断力：能区分闲聊和任务，不是盲目派发
无知识源：因为读不到知识文件，无法越权回答需要查资料的问题
正确拆分：独立任务按类型拆分，同类任务合并给一个红中
边界清晰：混合消息中能同时处理闲聊部分和识别任务部分

核心洞察得到实证确认：信息隔离 > 规则措辞 — 与其写更多规则让 AI "不要做什么"，不如直接切断它做某事的信息来源。