当前上下文
这不是新的路线，而是把第一份 DeerFlow 判断和上一份 proof-chain 报告收成可执行实验。
What The Best Minds Would Say
| Mind | Paraphrase | Action Here |
|---|---|---|
| David Allen | 先把同一类输入收成唯一 clarify loop，再去谈系统扩张。 | 只选一个 benchmark task，不并行跑 3 个 PoC。 |
| Charity Majors | 没有可观测指标的对照，不算 benchmark。 | 先冻结输入、输出、评分、人工干预记录。 |
| Peter Drucker | 真正缺的是可运行对照，而不是更多可能性。 | 先补 contract，再决定是否继续 DeerFlow 接线。 |
要点 1：一次只冻住一个 benchmark
先不要同时跑调研、Feishu 入口和技能互操作。那会把“有没有对照”重新冲散。
Decision
选 `PoC 1 · 深度调研报告`，其余两条先不跑。
- 现成输入资产最多，OpenClaw 侧已经有统一内容对象。
- 最容易做到 DeerFlow 和 OpenClaw 吃同一题、交同一类输出。
- 最能直接检验“sidecar runtime 到底值不值得继续养”。
要点 2：同一输入包先冻结，不允许临场改题
没有同一输入包，后面的质量差、稳定性差、维护成本差都无法比较。
Chosen Input Pack
这次 benchmark 的唯一输入包，先固定为
topics/openclaw-info-intake-system-closure/content-current-latest.json
对应的 1 个真实主题簇，必要时再附带该 topic 已公开的 supporting report。
- 先选 1 个真实 topic cluster，不从 hiring 页面文案倒推题目。
- 输入包一旦选定，OpenClaw 和 DeerFlow 都只能吃这一包。
- 运行过程中不得额外补充只属于一边的上下文。
要点 3：输出格式和评分表必须先写死
没有统一输出 contract，就会重新退回“感觉哪边更顺手”。
Frozen Output Contract
- 输出必须是一份带 sources 的调研/归纳报告。
- 报告必须包含结论、证据链、下一步动作。
- 每轮都要附一张同结构 scorecard。
6 个评分维度：报告质量、证据链完整度、运行稳定性、链路复杂度、人工干预成本、长期维护成本。
要点 4：先跑 OpenClaw baseline，再跑 DeerFlow sidecar
没有 baseline，就连 DeerFlow 是改进、持平还是退步都说不清。
Execution Order
- 第一轮先用 OpenClaw 跑出 baseline，完整记录输入、输出、耗时和人工干预点。
- 第二轮 DeerFlow 必须吃同一包输入、交同类输出，不能换题补题。
- 最后只收一张 scorecard，不急着公开发布 A/B 报告。
要点 5：当前成功标准不是“跑通 DeerFlow”，而是冻结阻塞点
如果本地还没有 DeerFlow runtime 痕迹，那这次真正该交付的是一张可执行 contract，而不是伪造运行记录。
Main Blocker
本地没有发现 DeerFlow repo、脚本、依赖声明或 run log。
- 第一阻塞：没有 DeerFlow 第一条可执行命令。
- 第二阻塞：还没从 content_current 里选定唯一 topic 作为输入包。
- 第三阻塞：还没把 scorecard 字段收成一次性可复用模板。
现成资产
这次 benchmark 不是从零开始，它只是在等一个更硬的执行入口。
| Asset | Why It Matters |
|---|---|
| DeerFlow fit | 已经明确 DeerFlow 更适合作 sidecar runtime，而不是替主链。 |
| proof-chain next step | 已经把 benchmark、clarify、hiring proof 这 3 条缺口说清楚。 |
| OpenClaw intake closure | 提供统一内容对象，是最自然的 benchmark 输入包来源。 |
| clarify plan | 说明 OpenClaw 一侧已经有真实中间层方向，不需要从零搭对照面。 |
评分维度
如果只剩几分钟，先看这张雷达：它定义了这次 benchmark 真正比较什么。
Field Definitions
- quality：结论是否清楚、结构是否稳、能否直接二次使用。
- sources：证据链是否完整、输入到结论是否可追溯。
- stability：长任务是否容易卡住、中断或跑偏。
- complexity：从拿到输入到拿到结果一共需要几步。
- human cost：中途需要你接几次手、补几次判断。
- maintenance：为了保留这条能力，后续要照顾多少额外系统负担。
最小 Runbook
这一步先只冻结流程，不伪造 DeerFlow 命令。没有 runtime，就明确写成 blocker。
Execution Contract
1. 从 content-current-latest.json 选 1 个真实 topic cluster 2. 把 benchmark prompt 固定成同一句 3. OpenClaw 先跑 baseline，记录输入 / 输出 / 耗时 / 干预点 4. DeerFlow 再吃同一输入包，交同类报告 5. 用同一张 scorecard 评分 6. 若 DeerFlow runtime 不存在，本轮停在 blocker 明示，不补写假结果
下一步
按这张 contract，后面就不该再讨论“要不要 benchmark”，而只讨论“输入包和 DeerFlow 第一条命令是什么”。
Next 1
从 content_current 里挑 1 个唯一 topic cluster
这一步决定 benchmark 不再发散，也决定 OpenClaw baseline 的真实题目是什么。
Next 2
补 DeerFlow 第一条可执行命令
当前本地没有发现任何 DeerFlow runtime 痕迹，这是进入实测前唯一必须先补的入口。
Next 3
再决定要不要把结果接进 hiring proof bundle
benchmark 结果出来后，才值得把它接进 hiring/portfolio 的证据入口，而不是现在就空挂链接。
Sources
只列当前这一页直接依赖的现成证据，不发明不存在的 DeerFlow run log。