AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载导读本文围绕 ouroboros 仓库中 #956 Workflow IR规划契约与 #946 Projection 投影词汇观察读模型之间只读映射展开系统讲解WorkflowNode.node_id、WorkflowEdge.edge_id、WorkflowSpec.spec_id如何与StepRecord、VerdictRecord、RunRecord的标识符体系对齐以及 11 种工作流生命周期事件如何通过既有 EventStore 投影构建器体现为投影效果。读者读完将掌握这一映射契约的边界与权威来源、两套标识符词汇的逐项对应规则、8 条禁止动作anti-actions以及如何通过 一致性集成测试 验证并锁定该契约。契约定位映射参考而非新 Schemadocs/agentos/workflow-ir-projection-mapping.md是一份映射参考文档mapping reference不是 schema。它不引入新类型、新标志、新事件族或新持久化只把两侧已经存在的标识符与生命周期词汇按既有边界重新陈述清楚。它的价值在于下游 Wave 3 工作PR F 的 dispatch 接线、S4 StepSnapshot、conformance harness 扩展等可以直接依赖这份映射而不必每次都重新推导边界。这份契约锁定的权威来源是两个边界文档workflow-ir-v1.md规定 Workflow IR 拥有什么规划图、校验、生命周期事件以及它不得嵌入什么投影记录、dispatch、持久化。projection-v1-scope.md规定投影词汇拥有什么RunRecord/StageRecord/StepRecord/ArtifactRecord/VerdictRecord作为可重建读模型。其中workflow-ir-v1.md中的锁定边界段落被本契约视为权威表述默认边界 fixture 必须保持本地化与确定性它可以把校验过的WorkflowSpec与合成的EventStore行配对以证明源事件关联但不得给 IR 增加 dispatch、缓存、持久化或投影记录嵌入。与之配套的每个一致性测试都必须遵守这一规则规范化的 fixture 模式见 test_ir_projection_consistency.py。第一层理解IR 与投影各自拥有什么在进入标识符映射之前需要先明确两套词汇的职责分工。workflow-ir-v1.md用一张职责表固定了边界关注点归属方节点、边、owner、schema 引用、能力信封#956 Workflow IRRun/Stage/Step/Artifact/Verdict 读模型记录#946 投影词汇证据 schema 语义与 verifier 策略#830 / #978 evidence spineHITL WAIT/RESUME 权威#960插件权限与审计契约#939一句话概括#956 描述的是计划要运行什么planning#946 描述的是事件发出后实际发生了什么observed read model。IR 节点不得直接嵌入投影记录运行时或 fixture 代码可以发出生命周期/事件其源 ID 随后投影为记录但投影始终是被观察到的读模型不是规划契约本身。标识符映射两套词汇如何对齐Workflow IR 把工作规划成由WorkflowNode实例连接、WorkflowEdge实例连边的图投影则观察事件发出后被写入日志的工作。两侧共享标识符语义但不共享存储。WorkflowNode.node_id→ 投影 step / verdict 身份节点 owner / kind投影目标标识符如何对齐NodeOwner.AGENT、NodeOwner.PLUGIN、NodeOwner.HARNESS携带工具/LLM 工作StepRecord运行时调用方在配对的tool.call.started/tool.call.returned或llm.call.requested/llm.call.returned行上设置event.data[call_id] WorkflowNode.node_id。随后由 projection_builder.py 导出的模块级stable_step_id(source_key, family, call_id)助手基于节点 id 派生出确定性的StepRecord.step_id。IR 侧从不存储 step id它始终可以从日志行推导。NodeOwner.AGENT、NodeOwner.PLUGIN产出验收证据StepRecord.ac_id当节点是某项工作的验收标准锚点时event.data[ac_id]携带 IR 规划所用的同一标识符典型即WorkflowNode.node_id或元数据附加的 AC 标签。ProjectionBuilder._extract_ac_id将其提升到投影的StepRecord上不做发明。NodeOwner.VERIFIERVerdictRecordverifier 的harness.verdict.recorded/evaluation.verdict.recorded事件设置event.data[scope] ac与event.data[ac_id] WorkflowNode.node_id针对被裁决的 AC。_verdict_from_event将其投影为VerdictRecord.ac_id。Run 范围裁决scope run针对 run 而非节点。NodeOwner.HUMAN_GATEv1 不投影HITL WAIT/RESUME 权威归属 #960由projection-v1-scope.md显式推迟。映射有意让这些节点 id 悬空——投影目前没有对应的记录类型。NodeKind.TERMINALRunRecord结束到达终态节点对应终态WorkflowLifecycleEventType.RUN_COMPLETED/RUN_FAILED/RUN_CANCELLED事件由 run 范围VerdictRecordscope run投影。终态节点 id 本身不作为独立记录投影。源码佐证在 workflow_ir.py 中NodeOwner枚举定义为HARNESS/AGENT/PLUGIN/HUMAN_GATE/VERIFIERNodeKind定义为TASK/DECISION/FAN_OUT/FAN_IN/TERMINAL。而 projection.py 中StepRecord带ac_id字段、VerdictRecord带scope: Literal[run, ac]与ac_id字段且强制校验scopeac必须有ac_idscoperun不得携带ac_id——这与映射表对 verifier 节点与 run 裁决的处理完全对应。WorkflowEdge.edge_id→ 投影事件对关联WorkflowEdge在 v1 中不作为独立投影记录类型投影。它的可观测面是转换两侧的源事件对WorkflowLifecycleEventType.EDGE_TRAVERSED行携带edge_id与尝试序号作为日志事件存储而非投影行。前驱 step 的*.returned事件与后继 step 的*.started事件上的投影StepRecord.source_event_ids元组是该边已被遍历的读模型证据。需要边粒度读状态的消费者可以把日志生命周期事件上的edge_id字段与投影的source_event_idsjoin 起来无需投影新增EdgeRecord类型——v1 有意不增加。Run / stage 锚点WorkflowSpec.spec_id是生命周期workflow_id不是投影标识符投影以seed_id加执行/会话锚点来键控 run见_derive_projection_source_key。一次WorkflowSpec执行精确映射为一个RunRecord和至少一个StageRecord默认 kind 为StageKind.EXECUTE。更丰富的 stage 检测是projection-v1-scope.md明确推迟的增量后续工作。从源码看_derive_projection_source_keyprojection_builder.py的推导优先级是事件切片中恰好一个 execution 聚合 →execution:{id}恰好一个 session 聚合 →session:{id}否则对事件切片做稳定 digest →events:{digest}空切片回退seed:{seed_id}。_stable_run_id(source_key)生成run_{uuid5 hex[:12]}_stable_stage_id(run_id, kind)生成stage_{...}全部基于uuid5确定性派生——这正是投影记录可从日志重建的根基。生命周期事件 → 投影映射Workflow IR 的生命周期词汇是有界的WorkflowLifecycleEventType定义在 workflow_lifecycle.py。每种生命周期事件类型通过既有投影词汇可观测如下WorkflowLifecycleEventType投影效果关联方式workflow.run.created打开一个RunRecord。started_at锚定到最早的投影事件时间戳。RunRecord.metadata是消费者附加workflow_id来源标签的唯一位置v1 不扩展该记录。workflow.node.scheduled预留一个未来的StepRecord槽位。在日志中存在配对的tool.call.*/llm.call.*事件之前不发出任何StepRecord。StepRecord.source_event_ids将引用*.started与*.returned行scheduled 生命周期行不嵌入。workflow.node.started发出投影StepRecord的*.started一半。悬空 step 的ended_atNone直到匹配的 returned 事件到达。StepRecord.source_event_ids (started_event.id,)配对完成前。workflow.node.completed用 returned 事件配对StepRecord的ended_at与ok。StepRecord.source_event_ids (started_event.id, returned_event.id)。workflow.node.failed同completed但StepRecord.ok False。节点的reason_code留在生命周期事件上不复制进投影。StepRecord.source_event_ids。workflow.node.retried重新打开节点槽位。上一个StepRecord保留其step_id下一次尝试产生新的StepRecord键控同一node_id经call_id 新的attempt序号。每次尝试各自的StepRecord.source_event_ids。workflow.edge.traversed不作为记录投影。通过日志中的EDGE_TRAVERSED生命周期行可观测。前驱StepRecord的source_event_ids覆盖读模型证据。workflow.checkpoint.savedv1 不投影。Checkpoint 引用是后续投影切片中RunSnapshotRecord的材料本映射文档特意列出该行让未来 PR 知道它落在哪里。按projection-v1-scope.md推迟。workflow.run.completed关闭RunRecordended_at为终态生命周期行时间戳。若运行时也发出了 run 范围裁决事件RunRecord.verdict_id指向投影出的VerdictRecord。run 裁决的VerdictRecord.evidence_event_ids。workflow.run.failed同completed投影出的 run 范围裁决若有outcomeFAIL。VerdictRecord.evidence_event_ids。workflow.run.cancelled同completed投影出的 run 范围裁决若有outcomeCANCELLED。VerdictRecord.evidence_event_ids。源码佐证WorkflowLifecycleEventType在 workflow_lifecycle.py 中定义为上述 11 个成员WorkflowLifecycleEvent提供to_base_event()把生命周期行写入aggregate_typeworkflow_ir桶与运行时execution/session聚合区分开便于下游投影过滤而不扫描无关事件族。而 projection.py 中StepRecord的模型级校验强制必须有source_event_ids或legacy_inferredTrueVerdictRecord用evidence_event_ids引用裁决依据——这些字段正是映射表中关联方式列的实现载体。映射表不是穷尽的只锁交集映射表在两个方向上都不穷尽没有生命周期对应物的投影事件族例如harness.artifact.recorded只由projection-v1-scope.md治理没有投影对应物的生命周期事件workflow.checkpoint.saved、workflow.edge.traversed只由workflow-ir-v1.md治理。本契约只锁定交集。反动作这份契约明确不做的事映射文档显式声明不引入、不暗示以下 8 类变更不改 schemasrc/ouroboros/orchestrator/workflow_ir.py与src/ouroboros/harness/projection.py两个面都保持各自已发布的*_SCHEMA_VERSIONWORKFLOW_IR_SCHEMA_VERSION 1、PROJECTION_SCHEMA_VERSION 1。不加投影记录字段/标志一致性测试只能依赖legacy_inferred、source_event_ids、ac_id、metadata这些既有表面新标志workflow_node_id、edge_id等超出范围。不实时 dispatch用于证明本映射的 IR fixture 按锁定边界段落保持本地化与确定性——无parallel_executor调用、无 agent 派生、无插件命令执行。IR 内不嵌入投影记录WorkflowNode、WorkflowEdge只携带规划词汇不引用step_id、run_id、verdict_id。投影记录内不嵌入 IRStepRecord.metadata只有在日志事件本身携带时才可带workflow_node_id投影不发明、不回溯填充 IR 标识符。不写持久化契约通过既有 EventStore 投影构建器观察映射文档及其测试不得创建迁移、缓存或新表。不加新事件族WorkflowLifecycleEventType与投影事件族集合_TOOL_STARTED、_TOOL_RETURNED、_LLM_REQUESTED、_LLM_RETURNED、_ARTIFACT_RECORDED_TYPES、_VERDICT_RECORDED_TYPES在 v1 都是闭集扩充由各自的规范 issue 治理。不拥有 HITL / 插件 / 证据 schema 权威边界表把这些分别分配给了 #960、#939、#830/#978本文档对它们一律让位。验证一致性测试如何锁定映射映射由 test_ir_projection_consistency.py 执行验证。它构建一个小的、校验通过的WorkflowSpecfan-out terminal发出遵守上述规则的合成EventStore行并断言投影的标识符与 IR 规划标识符精确对齐。正例fan-out terminal fixturefixture 图刻意覆盖映射文档中的三类标识符角色plan_nodeharness fan-out自身不投影为记录但其生命周期事件锚定 runrun_tool_nodeagent 任务投影为StepRecordjudge_ac_nodeverifier 任务投影为带ac_id的VerdictRecorddone_nodeterminal关闭 run。构造并校验 spec 的代码节选自测试 fixturespec WorkflowSpec( spec_idwfspec_ir_proj_fixture, sourceSourceKind.SYNTHETIC, nodes(plan_node, run_tool_node, judge_ac_node, done_node), edgesedges, ) validation validate_workflow(spec) assert validation.ok, validation.errors随后发出按 IR 节点 id 键控的合成事件交给ProjectionBuilderevents [ _tool_started(call_idrun_tool_node, tool_nameBash, when_at(10)), _tool_returned(call_idrun_tool_node, tool_nameBash, when_at(11)), _verdict_event(ac_idjudge_ac_node, when_at(12)), ] builder ProjectionBuilder(seed_idseed_ir_proj, goalVerify IR ↔ projection mapping contract) result builder.add_events(events).build()测试断言的关键点投影恰好产生一个 run 与一个默认 stagestage.run_id result.run.run_id恰好一个StepRecord其step_id等于stable_step_id(execution:exec_ir_proj, tool, run_tool_node)——即WorkflowNode.node_id必须推导出确定性的StepRecord.step_idstep 保留 IR 节点 id 作为ac_idstep.ac_id run_tool_nodelegacy_inferred is Falsesource_event_ids (evt_run_tool_node_started, evt_run_tool_node_returned)恰好一个 verdictscope ac、ac_id judge_ac_node、outcome is VerdictOutcome.PASSspec.spec_id不得泄漏进投影身份空间spec.spec_id not in {run.run_id, stage.stage_id, step.step_id, verdict.verdict_id}最后用validate_workflow_lifecycle_conformance(spec, lifecycle)验证 IR 侧接受与投影事件镜像的生命周期历史证明边界双向成立。负例未知节点 id 不崩投影第二个测试锁定映射文档Verification一节描述的负路径行为当合成生命周期事件引用了 spec 中不存在的节点 id如ghost_node时投影仍然正常构建len(result.steps) 1因为投影构建器按设计是spec-agnostic的不新增任何标志来表示不匹配ghost_step.legacy_inferred is False失配由 IR 侧既有助手validate_workflow_lifecycle_conformance暴露其report.errors中包含unknown_node_id违规码该码定义在 workflow_lifecycle.py 的WorkflowConformanceIssue.code联合类型中。这个负例同时验证了反动作第 2、5 条投影侧不发明新标志、不回溯填充 IR 标识符失配的探测职责明确留在 IR 侧。如何运行验证仓库为只读验证只需运行既有测试无需修改任何文件python -m pytest tests/integration/test_ir_projection_consistency.py -v该测试是确定性的、离线的永不 dispatch 工作、不持久化状态、不访问网络符合锁定边界段落的全部要求。实践要点小结写事件时配对tool.call.*/llm.call.*事件时让data[call_id]等于 IR 规划的WorkflowNode.node_idAC 锚点节点让data[ac_id]携带同一标识符verifier 裁决让data[scope]ac、data[ac_id]指向被裁决节点——这样投影侧无需发明任何新词汇即可对齐。读投影时step 的可追溯性看source_event_ids不要期望 IR 节点 id 直接出现在投影记录的专用字段里ac_id与metadata是仅有的合法携带面。排查失配投影构建成功不代表规划一致用 IR 侧validate_workflow_lifecycle_conformance检查unknown_node_id/unknown_edge_id等违规码。理解边界IR 是规划契约投影是观察读模型EventStore 日志是唯一事实源任何把投影变成第二状态模型、把 IR 变成实时 dispatch 引擎的改动都超出了 v1 范围。更完整的背景可继续阅读 workflow-ir-v1.mdIR 的 v1 边界与非目标与 projection-v1-scope.md投影 v1 范围、已包含项与显式推迟项以及 projection_builder.py 中stable_step_id、_derive_projection_source_key、_verdict_from_event的实现细节。赞分享AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载相关推荐AgentOS Workflow IR v1Ouroboros 的规划与校验契约设计全解AgentOS Workflow IR v1Ouroboros 的规划与校验契约设计全解 本篇指南聚焦 OuroborosAgent OS中由 harneAI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具Ouroboros AgentOS Projection 后续工作全解从 946 基线到可交付的只读投影栈Ouroboros AgentOS Projection 后续工作全解从 946 基线到可交付的只读投影栈 导读 本文围绕 OuroborosAgent OAI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具React Suite 图标动画指南使用 spin 与 pulse 实现加载与旋转效果React Suite 图标动画指南使用 spin 与 pulse 实现加载与旋转效果 导读 在 React Suitersuite组件库中 rsuiAI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具上一篇Grounded-SAM-2图像分割实战从零开始构建AI视觉管道下一篇A-to-Z-Resources-for-Students开源项目代码性能优化技术选型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
