智能体编排的图执行引擎：Onyx VM如何用计算图驯服非确定性
内容提要
Onyx VM通过计算图将Agent编排从文本流升级为类型化数据流，引入状态节点、静态控制流和并行扇出，显式建模错误路径，限制Agent动作空间，提升可观测性与可恢复性，实现确定性、可组合的Agent系统。
延伸解读
从文本流到类型化数据流：图结构如何约束非确定性
传统Agent编排中，节点间的文本流缺乏类型约束，导致输出不可预测。Onyx VM通过引入状态节点和zod模式校验，将边升级为类型化数据流，使数据形状在编译期可推理。这种设计限制了Agent的动作空间，让每个节点只负责明确子任务，从而将非确定性搜索裁剪到可控范围，提升系统整体可预测性。
静态控制流图：可预判的执行形状与预算控制
Onyx将控制流外化为静态图结构，run、spawn、if-else等原语构成确定性的路由逻辑，Agent仅影响节点内部输出。这使得执行图形状在运行前可知，开发者能预判最大并行度、预估预算上限，并设计错误恢复路径。相比动态生成执行图的方案，静态图提供了更强的可推理性和工程保障。
错误路径显式建模：从终止信号到正常状态转换
在Onyx图中，异常被视为分支事件而非终止信号。通过try-catch捕获异常节点并连接恢复子图，程序可将错误转换为状态节点中的特殊结果，继续执行后续迭代。这种设计让图在节点故障时保持连贯性，并支持重试子图嵌套，实现带退避策略的恢复路径，显著提升系统鲁棒性。
并行扇出与迭代式探针：提升探索效率的图模式
Onyx的spawn原语支持并行子图，形成扇出-汇聚结构。以Deep Codebase Research为例，多个Reader节点并行读取代码库，Evaluator节点汇聚结果并决定是否启动新一轮迭代。这种动态深度探针图将串行探索变为并行，吞吐量提升N倍，同时根据已收集信息调整策略，适用于搜索空间巨大的场景。
Q&A
Onyx VM是什么？它如何解决Agent编排中的非确定性问题？
Onyx VM是Random Labs推出的虚拟机，它将Agent协调转化为有向无环图（DAG）执行模型。通过持久化状态节点、类型化边约束和条件分支，它限制了Agent的动作空间，将非确定性裁剪到可控子空间，从而提升系统的确定性、可观测性和可恢复性。
Onyx VM中的状态节点是什么？它如何实现类型化存储？
状态节点是Onyx图中的一等公民，是持久化、可命名、带类型签名的存储单元。它使用zod模式定义形状（如z.object({ risk: z.enum(["low", "high"]), why: z.string() })），所有写入边必须符合该模式，运行时强制校验，从而将图升级为类型化数据流图。
Onyx VM如何实现静态控制流？与动态工作流相比有何优势？
Onyx程序本身就是控制流图，使用run、spawn、if-else、while、Promise.all等原语构建执行节点和分支结构。执行图形状在运行前可知，Agent只能影响节点内部输出，不能改变图结构。相比动态工作流（如Claude），静态图提供可推理的保证，如预判并行度、预算上限和错误恢复路径。
Onyx VM如何支持并行执行？请举例说明扇出-汇聚模式。
Onyx通过spawn原语创建并行子图，多个spawn节点同时运行形成扇出，父节点用await等待所有子节点完成形成扇入汇聚。例如Deep Codebase Research程序创建N个Reader节点并行读取代码库，写入共享状态节点，Evaluator节点汇聚后判断是否继续迭代，形成动态深度的探针图。
Onyx VM如何显式建模错误路径？请举例说明。
Onyx将异常视为图执行中的分支事件，通过try-catch捕获异常节点并连接到恢复子图。例如autoresearch程序中，实验节点抛出异常时，程序捕获后构造status为"crash"的结果对象，写入状态节点，继续循环，而不是中断整个图。还可实现重试模式，如切换到不同模型重试。
Onyx VM如何提升可观测性？
Onyx运行时记录完整执行迹，包括每个节点的开始/结束时间、操作、token消耗和输出结果。节点间数据流动是显式状态读写，因此调试可追溯图上路径，而非黑箱日志。
