KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
08. 完成一个可恢复的知识驱动诊断 Agent — keel 龙骨
结课项目场景：用户提交支付服务故障。Agent 需要读取当前知识库、查询只读监控工具、等待外部部署状态、在必要时 compaction，并给出带引用的结论。worker 随时可能重启，旧事件可能重复投递。
结课项目场景：用户提交支付服务故障。Agent 需要读取当前知识库、查询只读监控工具、等待外部部署状态、在必要时 compaction，并给出带引用的结论。worker 随时可能重启，旧事件可能重复投递。
实施阶段
阶段一：持久运行
run.started和step.requested写入 SQLite event store；- reducer 能在没有内存缓存时恢复状态；
- 每个运行都有
run_id、trace_id和 schema version。
阶段二：唤醒与执行
- timer、人工 signal、task completion 都转换成 WakeupRequest；
- claim 使用 lease，重复 delivery 不重复完成；
- 外部 action 使用 Real-world Execution 的 fingerprint 和 receipt。
阶段三：知识和上下文
- 文档 chunk 带 tenant、ACL、version 和 source URI；
- 先过滤权限，再混合检索和 rerank；
- Context Builder 使用前面课程的 token budget/compaction；
- 回答只能引用本次检索到且 quote 可验证的 chunk。
阶段四：门禁与回归
- 固定 20 条故障问题、相关 chunk 和期望引用；
- 对比 full history、JIT retrieval、JIT+compaction；
- 统计 Recall@k、citation precision、token、延迟、重复唤醒和恢复时间；
- 任一 ACL leakage、伪造 citation 或重复副作用直接阻止发布。
完成标准
一次运行结束后，你能从事件和报告回答：
它在什么时候等待？谁唤醒了它？
哪个 worker 获得了 lease？重复投递如何被拒绝？
模型看到了哪些 chunk，哪些因为 ACL/预算被丢弃？
每个结论的 citation 是否来自当前版本的证据？
worker 重启后从哪里恢复？
质量提升是否抵消了 token、延迟和额外组件？
如果只能展示一个漂亮回答而不能回答这些问题，项目仍停留在 demo 层。