Open ETF Agent v0.7 details durable control-event handoffs
A report examines how Open ETF Agent v0.7 separates reliable delivery of control events from confirmation that their intended business effects occurred. It describes the public SQLite implementation’s Claim/Fence leases, receipt reconciliation with the original Owner, unknown outcomes, cancellation, and restart recovery. The public slice covers a narrower path for a single Run and does not include the original system’s multi-Owner control-event bus. The report also cautions that not every target, production deployment, or cross-process failure has received unified end-to-end validation.
The report says that checking the original Owner’s receipt before retrying can prevent duplicate effects, while keeping admission decisions with the Owner’s identity, authorization, resource, and business-state checks.
后台研究正在进行，用户点了 Stop。另一台 Worker 随后接手，看到数据库里还有一条待处理命令。它能否直接再执行一次停止？如果上一个 Worker 已经让原任务停下，只是在写回投递 ACK 前掉线，这次重试应该做什么？
这是 ETF Agent 逐渐遇到的真正难题：一条命令被可靠送达，和它要求的业务效果真实发生，是两件事。 如果把“投递成功”当成“任务成功”，会漏掉真正的效果；如果把“没收到 ACK”当成“没执行”，又可能重复停止、重复唤醒，甚至重派受保护的动作。
持久控制通道的工作不是管理整个 Agent，而是把持久控制事件作为一条有身份、顺序、领取资格和交付回执的窄通道。实际终止 Run、接纳 Correction、建立 Task 或恢复 Child 的权力，仍由它们各自的原 Owner 持有。
本文先解释原系统持久控制通道的完整交接设计，再用 Open ETF Agent 的公开实现对照其中一条更窄的路径：同一个 Run 的 SQLite 领取、取消和重启恢复。公开切片已经能独立运行，但没有搬出原系统的多 Owner 控制事件总线；两者的能力范围会分别说明。
#Open ETF Agent#ETF Agent#ControlEventRepository#ControlEventService