Real Examples zh

真实案例

案例 1：依赖审计（你的第一张图）

编写工作流-zh 里那个 spec——两个节点一条边。任何仓库上跑：

/dag-flow 跑 dependency-audit 工作流

dag.open 里你会看到：

1. inventory 几秒内走完 queued → running → completed；输出是一份清单列表。
2. report 在 inventory 完成后准入，prompt 里的 {{inventory}} 拿到值，返回被标记的依赖和升级顺序。
3. 工作流完成，父智能体被唤醒，带着报告。

这是最小的诚实图：边之所以存在，是因为报告真的消费了清单。

案例 2：一次深度修复，来自真实运行

用户报告恢复会话后无响应：消息发出去了、没反应、重启后发现消息其实到了。整个调查跑成一个工作流。转录节选：

reproduce-defect   红色测试：时间戳回绕边界上的 id 排序
deep-impact-audit  全库每处字典序 id 比较，逐点分类
repair-defect      裸毫秒生成器 + 基于 time.created 的比较
verify-repair      突变证明：回退修复 → 测试变红；恢复 → 变绿
review-repair      REJECT——一个加固提交缺可证伪探针
（补上 H1 探针，scratch 工作区回退后它变红）
review（重跑）      ACCEPT

转录里值得注意的：

• **那个 REJECT 是对的。**审查发现一个提交回退后测试套件仍然全绿——不会失败的屏障也保护不了任何东西。修复环补了缺失的探针重跑。这是系统在工作，不是系统出故障。
• **修订视图派上了用场。**被拒的那一轮和它的重试不会堆在最终的图上；工作流在实际通过的那个版本上报 completed。
• verify 节点跑了突变证明：在 scratch 工作区回退修复、看回归测试失败、字节级恢复、再看它通过。证据，不是保证。

案例 3：报告走文件

一个综合节点这样收尾：

把最终报告写到 /path/to/repo/.opencode/workflow-reports/fix-report.md
然后只回复这个绝对路径。

运行时捕获 {content_ref, size, sha256, summary}；workflow(action="result") 返回指针和短摘要。父智能体需要细节时自己去读文件。转录保持小巧，捕获时记录的哈希证明文件事后没被改过。

更多在哪

内置工作流库（workflow(action="list")）带参考拓扑——设计深挖、并行交付、深度审查、轻量变更审查——每个都是可读、可抄、可改的 spec。