尧图网站建设 
Electric Agent 运行时 DSL 覆盖率全景从测试矩阵到编排模式验证指南【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric导读本文围绕 packages/agents-runtime/test/runtime-dsl-ideas.md 展开这是一份服务于packages/agents-runtime运行时黑盒测试套件的规范规划与覆盖率追踪文档。它通过 A–N 十二组场景编号把 Electric Agent 运行时基于 durable streams 的行为栈的实体生命周期、派生机制、共享状态、观察回放、协调编排、Map-Reduce、流水线、同行评审、辩论、Wiki 自治与响应式观察流全部映射为可断言的流历史测试。读完本文你将理解这套 DSL 测试的编写纪律、83 个场景覆盖了什么、哪些是待办缺口、哪些模式被刻意否决并能据此为自己的 Agent 编排功能设计同等级的回归测试。一、这份文档是什么DSL 覆盖矩阵而非普通笔记runtime-dsl-ideas.md的定位在文件头写得非常清楚它是packages/agents-runtime/test/runtime-dsl.test.ts的权威规划/覆盖率追踪文件canonical planning/coverage tracker。它的核心数据是runtime-dsl.test.ts当前包含83 个场景测试完整运行时套件全绿共256 个测试文档追踪三件事已覆盖什么、还缺什么、哪些想法因编码了错误的编排模式而刻意不加持not blessing。也就是说这不是一篇教程而是一张测试军规 覆盖地图 待办看板三合一的技术文档。作为文章骨架它最适合用来回答三个问题Electric Agent 运行时的行为契约是什么用什么纪律去验证哪些行为边界还没有被验证二、DSL 编写纪律七条铁律文档在 DSL Rules 一节给出了黑盒场景测试的七条编写纪律这是理解整个矩阵的方法论前提尽量断言完整流历史而不是抽查Assert full stream history wherever possible, not spot checks优先使用过滤快照filtered snapshots而不是对调度敏感scheduler-sensitive的原始历史快照从流开头匹配禁止固定 sleepMatch from the beginning of the stream; no fixed sleeps——测试必须靠语义事件驱动而不是靠等时间断言 spawn 参数、manifest 行与初始 inbox 消息的 eager durability主动持久化测试回放/再水合replay/rehydration行为时强制 wake 边界Force wake boundaries使用确定性的假助手/假工具而不是 playground 特有的工具蔓延不要因为某些错误编排模式容易测就把它们洗白进 DSL。这七条纪律在 runtime-dsl.test.ts 中有直接体现。例如测试基础设施runtimeTest()在 runtime-dsl.ts 中统一管理ElectricAgentsServerDurableStreamTestServer 本地 webhook 处理器并提供waitForRun、waitForRunCount、waitForSettled等语义等待原语waitForSettled依赖runtime.drainWakes()让运行时达到静默quiescence而不是轮询固定次数。这正是从流开头匹配、禁止固定 sleep纪律的实现基础。三、已覆盖场景全解A–N 十二组矩阵A. 独立助手Standalone AssistantA1–A14这组场景回答单个实体如何从 spawn 到产生完整 run 历史。核心断言包括A1spawn 立即写入entity_created并携带 spawn 参数见 A1 测试快照确认args与entity_type进入历史A2spawn 携带initialMessage时inbox 历史先于任何 run 写入快照中entity_created在inbox之前且无 run 记录A3单条消息产生完整的 run 历史——快照展示run insert → step insert → text insert → text_delta insert → text update(completed) → step update(completed) → run update(completed)的全链路见 快照文件A5多条消息产生两条 completed runA5b/A5c分别验证entity.waitForSettled与全局t.waitForSettled两种静默等待路径A6无 agent 的实体只记录入站消息只写 inboxA7setup 状态写入出现在 run 历史之前A9–A11同步/异步工具调用在单个 run 内按序出现、多次工具调用顺序稳定且取最后一次结果A12有状态 note 写入跨 wake 持久、后续可读A13/A14失败工具干净地关闭 run 并保留持久失败历史且实体能在后续 run 中恢复。其中A13对应的fail_tool命令与createFakeToolAssistantruntime-dsl.test.ts体现了确定性假工具纪律工具行为全部由测试内联命令解析器驱动不依赖任何外部服务。B. 派生机制Spawn MechanicsB1–B4验证父实体 spawn 子实体的流历史形态B1spawn 创建可接收消息的子实体B2带initialMessage的 spawn 写入子实体历史B3spawn 的 manifest 历史包含解析后的entityUrlB4spawn 自动创建 observe manifest 条目对应测试标题 spawn marks the child manifest row as observed。C. 状态集合State CollectionsC1–C3C1ctx.db上的集合写入反映到完整流历史C2setup 初始化的状态在最终历史中仍然可见C3实体自己写自己的状态不会触发第二次 run——这是防止状态回环self-triggered loop的关键行为契约。D. 共享状态Shared StateD1–D12共享状态是跨实体协作的地基。createSharedState/ctx.mkdbctx.observe(db(...))的组合见d1–d4实体定义runtime-dsl.test.ts驱动了 12 个场景D1createSharedState在实体历史中产生 manifest 条目D2共享状态流在任何写入之前就已存在D3对共享状态的写入同时反映在写入方与被观察方两个历史中D4第二个实体可连接既有共享状态并读到先前行D5共享状态的 update/delete 事件跨 wake 持久D6多集合共享状态在 writer/reader 实体间保持一致D7多个实体可向同一共享集合贡献持久行D8后写入者可覆盖共享行新 reader 读到最新值D9setup 注册的共享状态 effect 在首次 wake 写入时触发并在后续 wake 存活D10不同实体可在同一共享状态中向不同集合写入D11同一共享 key 的相邻写入者保留完整历史且后写覆盖last-write-winsD12变更一个共享集合不干扰另一集合的读取。E. 观察回放Observation ReplayE1–E3E1observed effect 在父实体重新 wake 时不重复旧子行E2更新被观察行保持单一派生行 keyE3被观察行更新被回放为 update 而非第二次 insertE0 还额外验证了不带 wake 的 observe 在后续子写入时不会重新 wake。F. 协调编排Coordination OrchestrationF1–F12这是文档篇幅最大的编排组覆盖 dispatcher 与 manager-worker 两种经典模式F1dispatcher 路由到指定专家类型并记录子实体F2manager-worker spawn、observe 并以稳定顺序收集全部 perspectives测试中optimist/pessimist/pragmatist三种视角runtime-dsl.test.tsF3dispatcher 递增 dispatch 计数并在多次 wake 后保留两个子行F4dispatcher 记录 dispatch 过程中的期望状态迁移idle → classifying → dispatching → waiting见createDispatcherAssistantF5/F7子实体无文本输出时使用文档化占位符placeholderF6wait_for_all在未 spawn 前调用返回文档化错误路径F8重复spawn_perspectives复用同一批子实体只返回最新输出F9/F10manager-worker 对定向子失败只对该 perspective 用占位符且可在失败后重试并最终收集完整结果F11/F12dispatcher 在专家失败甚至反复失败时保留计数器与子行。从实现看子完成通过wake: { on:runFinished, includeResponse: true }注册唤醒父实体在非 inbox wake 中读取finished_child载荷并更新childStatus集合见f2Manager的applyWakeStatusruntime-dsl.test.ts。G. Map-ReduceG1–G4G1即使各 chunk 完成时间不同结果仍按 chunk 顺序返回测试用delayMs打乱完成时序见createMapReduceAssistantG2单 chunk 的 map-reduce 仍走编排路径G3后续 run 复用 chunk 子实体且不泄漏上一次的 chunk 输出G4仅对失败 chunk 使用占位符其余保留。H. 流水线PipelineH1–H6H1流水线在首次 wake、阶段执行之前就写入状态行H2每个阶段消费上一阶段的输出并持久化最终状态H3状态上限封顶于stage_5更长流水线仍能完成——这与实现中Math.min(stageNumber, 5)的写法一致runtime-dsl.test.tsH4逐阶段持久化currentInput更新H5后续 run 复用阶段子实体但重置到最新输入链H6失败阶段以占位符输入继续传给后续阶段。I. 同行评审Peer ReviewI1–I4I1评审者通过共享状态聚合 reviewer 写入测试含 3 名评审者clarity/correctness/completeness见 runtime-dsl.test.tsI2summarize_reviews在无评审时返回空状态错误路径I3/I4分别配置 1 名与 2 名评审者时只汇总对应的持久行——评审者数量必须精确对应聚合结果。J. 辩论DebateJ1–J3J1辩论父实体在裁决前从共享状态读取正反双方论点J2end_debate在无论点时返回空状态路径J3只有一方论点时辩论保持 partial直到缺失一方到达才 resolve。K. Wiki 自治WikiK1–K10K1Wiki 专家累积共享文章后续查询可读K2重复create_wiki复用既有专家只 spawn 缺失的子主题K3get_wiki_status在专家文章落地后报告完整覆盖K4create_wiki拒绝切换既有 wiki 的主题K5/K7未创建任何文章/未创建 wiki 时返回空状态消息K6同主题同子主题的重复create_wiki幂等K8wiki 镜像持久化的子实体/文章通知元数据含 topic/authorK9幂等重建不重复共享文章行K10同主题扩展只新增缺失文章并更新后续查询覆盖。L. 响应式观察流Reactive Observation FlowsL1–L5L1显式observe createEffect转发 insert/update/delete 三类通知L2子实体无新变更时重新 wake watcher 不重复旧通知L3watcher 休眠期间发生的子删除在回放时只产生一条 delete 通知L4同一子实体被观察两次保持去重dedupedL5一个 watcher 可观察多个子实体并保留来源归属source attribution。从实现看l1Watcher实体通过_mirror集合记录每个子 URL 的镜像行在每次 wake 时做增/改/删三向比对并生成insert:/update:/delete:通知行runtime-dsl.test.ts是响应式观察流的参考实现。M/N 附加组Deep Researcher 与 Wake 语义文档的 Active Backlog 提到 Deep ResearcherM 组已覆盖 spawn-timeinitialMessage、wait_for_results前调用错误路径、多子研究员跨 wake 隔离。测试文件中对应的M1–M3runtime-dsl.test.ts验证了研究员从 spawn 的 initialMessage 启动无需额外 send。此外N1–N5组专门验证 wake 语义runFinished唤醒时父实体收到wake类型事件、spawn wake 与子 manifest 共享同一条runFinished注册、ctx.agent.run可携带 wake 载荷执行第二次 run。四、待办缺口Active Backlog 逐项解读文档明确区分已覆盖与待办。待办中有一部分已打勾有一部分仍是缺口其中值得关注的有共享状态第 1 节已覆盖相邻 wake 下两个实体对同一 key 的写竞争、reader 观察一个集合时 writer 变更另一集合缺口setup 时间与动态 update/delete 组合作用于可变行时的 effect 覆盖。协调失败与恢复第 2 节——全部为缺口dispatcher 子失败路径上的runFinished延续聚合跨多次 wake 的反复失败需保留子行与计数器注F12已在测试文件中实现为 dispatcher preserves counters and child rows across repeated failing dispatches子失败后在同一父实体上替换子实体。Map-Reduce 与流水线边界第 3 节——已全部覆盖单 chunk 失败占位符、跨 wake 的重复 chunk id 复用、阶段失败语义、done后的重跑重置语义。同行评审与辩论第 4 节缺口评审已持久后跨 wake 边界的汇总已覆盖评审者数量变体1/2/3、辩论双方向缺失前的 partial 状态。Deep Researcher第 5 节——已全部覆盖。Wiki 自治第 6 节——全部为缺口无需第二次用户干预的 build-and-answer 流程文章足够后自动 resolve 的 pending query 状态只有部分专家写完时的 partial wiki 答案同一实体上的显式子主题扩展与后续跟进查询面向观察者的更清晰的父侧高层进度面。观察 / Effects第 7 节——全部为缺口且文档给出了关键判断无效 observe 目标的错误路径observe-once 与 first-write-wins 配置不匹配的固定化多种编排模式下的live .send()观察句柄可变行 effect 回放/update/delete需上游 effect gating 落地多源 joined effects依赖上游createEffect语义稳定。文档在 第 7 节末尾 给出一条重要的前置依赖说明ElectricAgents 现在已经有了按源命名空间隔离的 StreamDB collection id 与逐消息 offset但上游createEffect的稳定回放语义仍不够可靠因此**暂时不加持bless**可变行与多源 joined 这两类用例。Trading Floor第 8 节——全部为缺口开放市场播种与时钟初始化新闻注入扇出fanout跨会话的时钟推进由持久共享状态派生的市场摘要。横切压力第 9 节——全部为缺口混合 spawn observe shared state replay 多子实体的组合场景带反复再水合与过滤快照的长多 wake 场景。五、Import Idea Triage想法分级与刻意否决清单2026-03-21 的一次头脑风暴被映射进 DSL 计划文档给出三种归宿1. 已由 DSL 覆盖如 1–8 由 A1–A14/C1–C3 覆盖9–19 由 B1–B4/A1–A2/F3/F8 覆盖80–85 由 F/G/H/I/J/K 各组合覆盖。2. 更适合放在 DSL 之外的低层测试setup-context、wake-handler、process-wake的单元/集成测试包括spawn manifest 的entityUrl、createSharedState/connectSharedState的 manifest 条目、createEffect的 manifest/functionRef/dedupe 规则、agent factory 与 re-wake 回放内部机制、spawn/setup 失败的 crash-only 行为。这类条目不是行为洞而是测试层级选择。3. 明确不在当前产品方向内子完成通过runFinished唤醒父实体编排应表示为持久化的延续唤醒durable continuation wakes。真实遗留 DSL 待办包括状态删除流覆盖15、受保护状态迁移示例28、agent factory 中创建共享状态与幂等创建39–40、协调实体存活直到所有子完成86、trading-floor 场景94–95、无效 guard 迁移错误路径97。**Explicitly Rejected Patterns明确否决的模式**是本文档的独特价值——它警告了三种看似能测但方向错误的测试依赖同步子输出读取的同实体重复 map-reduce 再聚合假设立即子复用与聚合的同实体重复流水线重跑依赖偶然调度顺序而非持久语义历史的测试。这与 DSL Rules 第 7 条不要将坏编排模式洗白进 DSL形成闭环测试矩阵不仅测对的也明确拒绝错的。六、落地运行与仓库证据索引如果你想亲自验证这套矩阵仓库提供了完整的运行路径包名electric-ax/agents-runtime版本0.6.3见 packages/agents-runtime/package.json运行命令在packages/agents-runtime下执行pnpm testvitest run或pnpm test:watch完整运行时套件 256 个测试全绿文档记录其中runtime-dsl.test.ts贡献 83 个场景测试基础设施runtimeTest()在 packages/agents-runtime/test/runtime-dsl.ts 中自动拉起ElectricAgentsServer、DurableStreamTestServer与本地 webhook 处理器并注入system:runtime-dsl-test主体验证 spawn 权限快照断言流历史快照集中在 packages/agents-runtime/test/snapshots/runtime-dsl.test.ts.snapA1–A4的entity_created → inbox → run → step → text → text_delta事件链是理解完整流历史断言的最佳样本相关运行时代码ctx.spawn/ctx.observe/ctx.mkdb等上下文能力对应 packages/agents-runtime/src/setup-context.tswake 分发逻辑见 packages/agents-runtime/src/process-wake.ts实体定义与注册见 packages/agents-runtime/src/define-entity.ts 与 packages/agents-runtime/src/index.ts。七、结论一张活的编排行为契约runtime-dsl-ideas.md的价值不在于罗列测试数量而在于它把行为契约工程化了用可断言的流历史替代时序猜测用语义等待替代固定 sleep用确定性假助手替代外部依赖用明确否决清单守住编排模式的正确方向。对于在 Electric Agent 运行时之上构建协调类功能的开发者这张矩阵既是回归测试的规格说明书也是判断某个行为该不该进入 DSL的决策框架——当你想给一个新编排模式补测试时先问自己它能断言完整流历史吗它依赖偶然调度吗它是不是把坏模式洗白了答案会引导你走向 A–N 中正确的那个分组或者走向setup-context级别的低层测试又或者直接进入Not Current Product Direction清单。【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Electric Agent 运行时 DSL 覆盖率全景：从测试矩阵到编排模式验证指南
Electric Agent 运行时 DSL 覆盖率全景从测试矩阵到编排模式验证指南【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric导读本文围绕 packages/agents-runtime/test/runtime-dsl-ideas.md 展开这是一份服务于packages/agents-runtime运行时黑盒测试套件的规范规划与覆盖率追踪文档。它通过 A–N 十二组场景编号把 Electric Agent 运行时基于 durable streams 的行为栈的实体生命周期、派生机制、共享状态、观察回放、协调编排、Map-Reduce、流水线、同行评审、辩论、Wiki 自治与响应式观察流全部映射为可断言的流历史测试。读完本文你将理解这套 DSL 测试的编写纪律、83 个场景覆盖了什么、哪些是待办缺口、哪些模式被刻意否决并能据此为自己的 Agent 编排功能设计同等级的回归测试。一、这份文档是什么DSL 覆盖矩阵而非普通笔记runtime-dsl-ideas.md的定位在文件头写得非常清楚它是packages/agents-runtime/test/runtime-dsl.test.ts的权威规划/覆盖率追踪文件canonical planning/coverage tracker。它的核心数据是runtime-dsl.test.ts当前包含83 个场景测试完整运行时套件全绿共256 个测试文档追踪三件事已覆盖什么、还缺什么、哪些想法因编码了错误的编排模式而刻意不加持not blessing。也就是说这不是一篇教程而是一张测试军规 覆盖地图 待办看板三合一的技术文档。作为文章骨架它最适合用来回答三个问题Electric Agent 运行时的行为契约是什么用什么纪律去验证哪些行为边界还没有被验证二、DSL 编写纪律七条铁律文档在 DSL Rules 一节给出了黑盒场景测试的七条编写纪律这是理解整个矩阵的方法论前提尽量断言完整流历史而不是抽查Assert full stream history wherever possible, not spot checks优先使用过滤快照filtered snapshots而不是对调度敏感scheduler-sensitive的原始历史快照从流开头匹配禁止固定 sleepMatch from the beginning of the stream; no fixed sleeps——测试必须靠语义事件驱动而不是靠等时间断言 spawn 参数、manifest 行与初始 inbox 消息的 eager durability主动持久化测试回放/再水合replay/rehydration行为时强制 wake 边界Force wake boundaries使用确定性的假助手/假工具而不是 playground 特有的工具蔓延不要因为某些错误编排模式容易测就把它们洗白进 DSL。这七条纪律在 runtime-dsl.test.ts 中有直接体现。例如测试基础设施runtimeTest()在 runtime-dsl.ts 中统一管理ElectricAgentsServerDurableStreamTestServer 本地 webhook 处理器并提供waitForRun、waitForRunCount、waitForSettled等语义等待原语waitForSettled依赖runtime.drainWakes()让运行时达到静默quiescence而不是轮询固定次数。这正是从流开头匹配、禁止固定 sleep纪律的实现基础。三、已覆盖场景全解A–N 十二组矩阵A. 独立助手Standalone AssistantA1–A14这组场景回答单个实体如何从 spawn 到产生完整 run 历史。核心断言包括A1spawn 立即写入entity_created并携带 spawn 参数见 A1 测试快照确认args与entity_type进入历史A2spawn 携带initialMessage时inbox 历史先于任何 run 写入快照中entity_created在inbox之前且无 run 记录A3单条消息产生完整的 run 历史——快照展示run insert → step insert → text insert → text_delta insert → text update(completed) → step update(completed) → run update(completed)的全链路见 快照文件A5多条消息产生两条 completed runA5b/A5c分别验证entity.waitForSettled与全局t.waitForSettled两种静默等待路径A6无 agent 的实体只记录入站消息只写 inboxA7setup 状态写入出现在 run 历史之前A9–A11同步/异步工具调用在单个 run 内按序出现、多次工具调用顺序稳定且取最后一次结果A12有状态 note 写入跨 wake 持久、后续可读A13/A14失败工具干净地关闭 run 并保留持久失败历史且实体能在后续 run 中恢复。其中A13对应的fail_tool命令与createFakeToolAssistantruntime-dsl.test.ts体现了确定性假工具纪律工具行为全部由测试内联命令解析器驱动不依赖任何外部服务。B. 派生机制Spawn MechanicsB1–B4验证父实体 spawn 子实体的流历史形态B1spawn 创建可接收消息的子实体B2带initialMessage的 spawn 写入子实体历史B3spawn 的 manifest 历史包含解析后的entityUrlB4spawn 自动创建 observe manifest 条目对应测试标题 spawn marks the child manifest row as observed。C. 状态集合State CollectionsC1–C3C1ctx.db上的集合写入反映到完整流历史C2setup 初始化的状态在最终历史中仍然可见C3实体自己写自己的状态不会触发第二次 run——这是防止状态回环self-triggered loop的关键行为契约。D. 共享状态Shared StateD1–D12共享状态是跨实体协作的地基。createSharedState/ctx.mkdbctx.observe(db(...))的组合见d1–d4实体定义runtime-dsl.test.ts驱动了 12 个场景D1createSharedState在实体历史中产生 manifest 条目D2共享状态流在任何写入之前就已存在D3对共享状态的写入同时反映在写入方与被观察方两个历史中D4第二个实体可连接既有共享状态并读到先前行D5共享状态的 update/delete 事件跨 wake 持久D6多集合共享状态在 writer/reader 实体间保持一致D7多个实体可向同一共享集合贡献持久行D8后写入者可覆盖共享行新 reader 读到最新值D9setup 注册的共享状态 effect 在首次 wake 写入时触发并在后续 wake 存活D10不同实体可在同一共享状态中向不同集合写入D11同一共享 key 的相邻写入者保留完整历史且后写覆盖last-write-winsD12变更一个共享集合不干扰另一集合的读取。E. 观察回放Observation ReplayE1–E3E1observed effect 在父实体重新 wake 时不重复旧子行E2更新被观察行保持单一派生行 keyE3被观察行更新被回放为 update 而非第二次 insertE0 还额外验证了不带 wake 的 observe 在后续子写入时不会重新 wake。F. 协调编排Coordination OrchestrationF1–F12这是文档篇幅最大的编排组覆盖 dispatcher 与 manager-worker 两种经典模式F1dispatcher 路由到指定专家类型并记录子实体F2manager-worker spawn、observe 并以稳定顺序收集全部 perspectives测试中optimist/pessimist/pragmatist三种视角runtime-dsl.test.tsF3dispatcher 递增 dispatch 计数并在多次 wake 后保留两个子行F4dispatcher 记录 dispatch 过程中的期望状态迁移idle → classifying → dispatching → waiting见createDispatcherAssistantF5/F7子实体无文本输出时使用文档化占位符placeholderF6wait_for_all在未 spawn 前调用返回文档化错误路径F8重复spawn_perspectives复用同一批子实体只返回最新输出F9/F10manager-worker 对定向子失败只对该 perspective 用占位符且可在失败后重试并最终收集完整结果F11/F12dispatcher 在专家失败甚至反复失败时保留计数器与子行。从实现看子完成通过wake: { on:runFinished, includeResponse: true }注册唤醒父实体在非 inbox wake 中读取finished_child载荷并更新childStatus集合见f2Manager的applyWakeStatusruntime-dsl.test.ts。G. Map-ReduceG1–G4G1即使各 chunk 完成时间不同结果仍按 chunk 顺序返回测试用delayMs打乱完成时序见createMapReduceAssistantG2单 chunk 的 map-reduce 仍走编排路径G3后续 run 复用 chunk 子实体且不泄漏上一次的 chunk 输出G4仅对失败 chunk 使用占位符其余保留。H. 流水线PipelineH1–H6H1流水线在首次 wake、阶段执行之前就写入状态行H2每个阶段消费上一阶段的输出并持久化最终状态H3状态上限封顶于stage_5更长流水线仍能完成——这与实现中Math.min(stageNumber, 5)的写法一致runtime-dsl.test.tsH4逐阶段持久化currentInput更新H5后续 run 复用阶段子实体但重置到最新输入链H6失败阶段以占位符输入继续传给后续阶段。I. 同行评审Peer ReviewI1–I4I1评审者通过共享状态聚合 reviewer 写入测试含 3 名评审者clarity/correctness/completeness见 runtime-dsl.test.tsI2summarize_reviews在无评审时返回空状态错误路径I3/I4分别配置 1 名与 2 名评审者时只汇总对应的持久行——评审者数量必须精确对应聚合结果。J. 辩论DebateJ1–J3J1辩论父实体在裁决前从共享状态读取正反双方论点J2end_debate在无论点时返回空状态路径J3只有一方论点时辩论保持 partial直到缺失一方到达才 resolve。K. Wiki 自治WikiK1–K10K1Wiki 专家累积共享文章后续查询可读K2重复create_wiki复用既有专家只 spawn 缺失的子主题K3get_wiki_status在专家文章落地后报告完整覆盖K4create_wiki拒绝切换既有 wiki 的主题K5/K7未创建任何文章/未创建 wiki 时返回空状态消息K6同主题同子主题的重复create_wiki幂等K8wiki 镜像持久化的子实体/文章通知元数据含 topic/authorK9幂等重建不重复共享文章行K10同主题扩展只新增缺失文章并更新后续查询覆盖。L. 响应式观察流Reactive Observation FlowsL1–L5L1显式observe createEffect转发 insert/update/delete 三类通知L2子实体无新变更时重新 wake watcher 不重复旧通知L3watcher 休眠期间发生的子删除在回放时只产生一条 delete 通知L4同一子实体被观察两次保持去重dedupedL5一个 watcher 可观察多个子实体并保留来源归属source attribution。从实现看l1Watcher实体通过_mirror集合记录每个子 URL 的镜像行在每次 wake 时做增/改/删三向比对并生成insert:/update:/delete:通知行runtime-dsl.test.ts是响应式观察流的参考实现。M/N 附加组Deep Researcher 与 Wake 语义文档的 Active Backlog 提到 Deep ResearcherM 组已覆盖 spawn-timeinitialMessage、wait_for_results前调用错误路径、多子研究员跨 wake 隔离。测试文件中对应的M1–M3runtime-dsl.test.ts验证了研究员从 spawn 的 initialMessage 启动无需额外 send。此外N1–N5组专门验证 wake 语义runFinished唤醒时父实体收到wake类型事件、spawn wake 与子 manifest 共享同一条runFinished注册、ctx.agent.run可携带 wake 载荷执行第二次 run。四、待办缺口Active Backlog 逐项解读文档明确区分已覆盖与待办。待办中有一部分已打勾有一部分仍是缺口其中值得关注的有共享状态第 1 节已覆盖相邻 wake 下两个实体对同一 key 的写竞争、reader 观察一个集合时 writer 变更另一集合缺口setup 时间与动态 update/delete 组合作用于可变行时的 effect 覆盖。协调失败与恢复第 2 节——全部为缺口dispatcher 子失败路径上的runFinished延续聚合跨多次 wake 的反复失败需保留子行与计数器注F12已在测试文件中实现为 dispatcher preserves counters and child rows across repeated failing dispatches子失败后在同一父实体上替换子实体。Map-Reduce 与流水线边界第 3 节——已全部覆盖单 chunk 失败占位符、跨 wake 的重复 chunk id 复用、阶段失败语义、done后的重跑重置语义。同行评审与辩论第 4 节缺口评审已持久后跨 wake 边界的汇总已覆盖评审者数量变体1/2/3、辩论双方向缺失前的 partial 状态。Deep Researcher第 5 节——已全部覆盖。Wiki 自治第 6 节——全部为缺口无需第二次用户干预的 build-and-answer 流程文章足够后自动 resolve 的 pending query 状态只有部分专家写完时的 partial wiki 答案同一实体上的显式子主题扩展与后续跟进查询面向观察者的更清晰的父侧高层进度面。观察 / Effects第 7 节——全部为缺口且文档给出了关键判断无效 observe 目标的错误路径observe-once 与 first-write-wins 配置不匹配的固定化多种编排模式下的live .send()观察句柄可变行 effect 回放/update/delete需上游 effect gating 落地多源 joined effects依赖上游createEffect语义稳定。文档在 第 7 节末尾 给出一条重要的前置依赖说明ElectricAgents 现在已经有了按源命名空间隔离的 StreamDB collection id 与逐消息 offset但上游createEffect的稳定回放语义仍不够可靠因此**暂时不加持bless**可变行与多源 joined 这两类用例。Trading Floor第 8 节——全部为缺口开放市场播种与时钟初始化新闻注入扇出fanout跨会话的时钟推进由持久共享状态派生的市场摘要。横切压力第 9 节——全部为缺口混合 spawn observe shared state replay 多子实体的组合场景带反复再水合与过滤快照的长多 wake 场景。五、Import Idea Triage想法分级与刻意否决清单2026-03-21 的一次头脑风暴被映射进 DSL 计划文档给出三种归宿1. 已由 DSL 覆盖如 1–8 由 A1–A14/C1–C3 覆盖9–19 由 B1–B4/A1–A2/F3/F8 覆盖80–85 由 F/G/H/I/J/K 各组合覆盖。2. 更适合放在 DSL 之外的低层测试setup-context、wake-handler、process-wake的单元/集成测试包括spawn manifest 的entityUrl、createSharedState/connectSharedState的 manifest 条目、createEffect的 manifest/functionRef/dedupe 规则、agent factory 与 re-wake 回放内部机制、spawn/setup 失败的 crash-only 行为。这类条目不是行为洞而是测试层级选择。3. 明确不在当前产品方向内子完成通过runFinished唤醒父实体编排应表示为持久化的延续唤醒durable continuation wakes。真实遗留 DSL 待办包括状态删除流覆盖15、受保护状态迁移示例28、agent factory 中创建共享状态与幂等创建39–40、协调实体存活直到所有子完成86、trading-floor 场景94–95、无效 guard 迁移错误路径97。**Explicitly Rejected Patterns明确否决的模式**是本文档的独特价值——它警告了三种看似能测但方向错误的测试依赖同步子输出读取的同实体重复 map-reduce 再聚合假设立即子复用与聚合的同实体重复流水线重跑依赖偶然调度顺序而非持久语义历史的测试。这与 DSL Rules 第 7 条不要将坏编排模式洗白进 DSL形成闭环测试矩阵不仅测对的也明确拒绝错的。六、落地运行与仓库证据索引如果你想亲自验证这套矩阵仓库提供了完整的运行路径包名electric-ax/agents-runtime版本0.6.3见 packages/agents-runtime/package.json运行命令在packages/agents-runtime下执行pnpm testvitest run或pnpm test:watch完整运行时套件 256 个测试全绿文档记录其中runtime-dsl.test.ts贡献 83 个场景测试基础设施runtimeTest()在 packages/agents-runtime/test/runtime-dsl.ts 中自动拉起ElectricAgentsServer、DurableStreamTestServer与本地 webhook 处理器并注入system:runtime-dsl-test主体验证 spawn 权限快照断言流历史快照集中在 packages/agents-runtime/test/snapshots/runtime-dsl.test.ts.snapA1–A4的entity_created → inbox → run → step → text → text_delta事件链是理解完整流历史断言的最佳样本相关运行时代码ctx.spawn/ctx.observe/ctx.mkdb等上下文能力对应 packages/agents-runtime/src/setup-context.tswake 分发逻辑见 packages/agents-runtime/src/process-wake.ts实体定义与注册见 packages/agents-runtime/src/define-entity.ts 与 packages/agents-runtime/src/index.ts。七、结论一张活的编排行为契约runtime-dsl-ideas.md的价值不在于罗列测试数量而在于它把行为契约工程化了用可断言的流历史替代时序猜测用语义等待替代固定 sleep用确定性假助手替代外部依赖用明确否决清单守住编排模式的正确方向。对于在 Electric Agent 运行时之上构建协调类功能的开发者这张矩阵既是回归测试的规格说明书也是判断某个行为该不该进入 DSL的决策框架——当你想给一个新编排模式补测试时先问自己它能断言完整流历史吗它依赖偶然调度吗它是不是把坏模式洗白了答案会引导你走向 A–N 中正确的那个分组或者走向setup-context级别的低层测试又或者直接进入Not Current Product Direction清单。【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考