智能体编排的图执行引擎：Onyx VM如何用计算图驯服非确定性
内容提要
Onyx VM将Agent编排转化为有向无环图执行模型，通过状态节点、类型化边约束和条件分支控制非确定性。它引入静态控制流图、并行扇出和显式错误恢复路径，提升可观测性与可组合性，使Agent系统更可预测、可恢复。
延伸解读
从文本流到类型化数据流：图约束如何降低不确定性
Onyx VM将Agent间的文本流动升级为类型化数据流，通过状态节点和zod模式约束写入数据。这相当于在图的边上施加类型签名，使数据形状在编译期可推理。相比ReAct循环中无约束的文本边，这种设计将非确定性从数据层面剥离，让开发者能在图层面验证数据一致性，而非依赖运行时调试。
静态控制流图：可预测性与动态工作流的取舍
Onyx选择静态控制流图，使执行图形状在运行前可知，便于预估并行度和预算。这与Claude的动态工作流形成对比：后者由Agent动态生成编排脚本，图结构运行时才确定。静态图牺牲了灵活性，但换来了可推理的保证，适合对稳定性和成本敏感的生产环境。
错误即路径：显式恢复子图的设计哲学
Onyx将异常视为图执行中的分支事件，通过try-catch连接到恢复子图，使错误成为正常状态转换而非终止信号。例如，实验节点崩溃后，程序构造特殊结果对象并继续循环。这种设计让系统在故障时保持连贯性，并支持嵌套重试子图，如切换模型重试，提升了整体鲁棒性。
拓扑约束与可观测性：图工程的双重红利
图拓扑天然限制了Agent的动作空间，每个节点只负责明确定义的子任务，父图负责任务分解，从而将非确定性搜索空间裁剪到可控范围。同时，节点执行有明确起止，数据流动显式化，运行时能记录完整执行迹，使调试从黑箱日志变为图上路径追溯，显著提升可观测性。
Q&A
Onyx VM是什么？它如何解决Agent编排中的非确定性问题？
Onyx VM是Random Labs推出的虚拟机，它将Agent协调转化为有向无环图（DAG）执行模型。通过引入状态节点、类型化边约束和条件分支，它把Agent的非确定性行为限制在节点内部，而节点之间的路由逻辑由确定性代码控制，从而提升系统的可预测性、可观测性和可恢复性。
Onyx VM中的状态节点是什么？它如何实现类型化存储？
状态节点是Onyx VM中的一等公民，是持久化、可命名、带类型签名的存储单元。它使用zod模式定义形状（如z.object({ risk: z.enum(["low", "high"]), why: z.string() })），所有指向该节点的写入边都必须符合此模式，运行时会在写入时强制校验，从而在图的边上施加类型约束，将文本流动图升级为类型化数据流图。
Onyx VM的静态控制流图与Claude的动态工作流有何区别？
Onyx VM采用静态控制流图，程序本身就是控制流图，执行图形状在运行前可知，Agent只能影响节点内部输出，不能改变图结构。而Claude的动态工作流是动态生成执行图，Agent自己写编排脚本，图结构在运行时才确定。静态图提供了可推理的保证，如预判最大并行度、预估预算上限、设计错误恢复路径。
Onyx VM如何实现并行扇出和扇入汇聚？请举例说明。
Onyx VM通过spawn原语创建并行执行子图，多个spawn节点同时运行形成扇出结构，它们可共享状态节点协调，父节点用await等待所有子节点完成形成扇入汇聚。例如Deep Codebase Research程序创建N个Reader节点并行读取代码库不同部分，写入共享状态节点，Evaluator节点在所有Reader完成后启动，综合数据判断研究深度，若不够深则再启动新一轮Reader，形成迭代式扇出-汇聚模式。
Onyx VM如何处理Agent节点执行中的错误？
Onyx VM将异常视为图执行中的分支事件，可用try-catch捕获异常节点并连接到恢复子图。例如在autoresearch程序中，实验节点抛出异常时，程序捕获后构造特殊结果对象（status设为"crash"，valBpb设为null），数据流入记录节点写入状态节点，程序继续执行下一次循环迭代，将错误转化为正常状态转换路径。还可实现重试模式，在catch块中连接到使用不同模型的Agent节点重试。
Onyx VM的图拓扑如何限制Agent的动作空间并提升可观测性？
Onyx VM的图拓扑天然限制了Agent的动作空间，Agent只能在节点内部操作，不能跳出图结构修改控制流，从而将非确定性搜索空间裁剪到可控子空间。同时，每个节点执行有明确的开始和结束时间点，数据流动是显式的状态读写操作，运行时能记录完整执行迹（节点操作、token消耗、输出结果），使调试变成图上路径追溯，提升可观测性。
