let graph = FlowGraph::new()
let _ = graph.add_task(TaskNode::new("collect_papers", "Collect papers"))
let _ = graph.add_task(TaskNode::new("write_report", "Write report"))
let _ = graph.add_dependency(TaskId::new("collect_papers"), TaskId::new("write_report"))
guard graph.plan() is Ok(plan) else { fail("invalid graph") }
常用查询:
let _ = graph.update_status(TaskId::new("collect_papers"), Succeeded)
let _ = graph.predecessors(TaskId::new("write_report"))
let _ = graph.successors(TaskId::new("collect_papers"))
let _ = graph.ready_tasks([TaskId::new("collect_papers")])
当前状态
moon check 通过。
moon test 通过,当前覆盖 DAG 构建、重复任务、缺失依赖、循环检测、拓扑排序、并行批次、状态更新、ready 任务、trace 查询和导出。
moon run cmd/demo 可以直接运行,并展示 Markdown 与 JSON 两种结果。
MoonFlowGraph
我在维护科研自动化插件时,经常遇到一个不太显眼、但很影响复现的问题:任务清单写在计划里,依赖关系藏在代码里,运行结果又散落在日志和临时文件中。流程短的时候还能靠记忆串起来;一旦同时包含文献检索、数据准备、baseline、指标比较和报告撰写,就很难回答三个简单的问题:下一步能做什么,哪些步骤可以并行,这次运行到底留下了哪些证据。
MoonFlowGraph 是我对这个问题的一次小范围拆解。它用 MoonBit 提供任务图、DAG 校验、执行批次和 provenance trace,只负责把流程和证据说清楚,不替调用者执行模型或命令。
它适合解决什么
核心能力
before -> after的执行约束。它刻意不做什么
MoonFlowGraph 不是完整 Agent runtime。当前版本刻意不做这些事情:
这些能力更适合由上层 runtime 负责。MoonFlowGraph 保持在“描述计划、检查依赖、记录证据”这一层,因而可以单独测试,也容易嵌入现有工具。
快速运行
需要本机已安装 MoonBit 工具链,并确保
moon在PATH中。也可以运行仓库内脚本:
一个具体例子
仓库里的 demo 模拟一次从文献和数据准备走向实验报告的流程:
第一批
collect_papers和prepare_dataset可以并行;第二批extract_claims和run_baseline可以并行;之后汇合到compare_metrics,最后进入write_report。trace 不只写“任务完成”,还会记录检索范围、数据快照、baseline 配置和比较依据。demo 最终输出:
完整 API 和错误行为见 docs/API.md。
API 示例
常用查询:
当前状态
moon check通过。moon test通过,当前覆盖 DAG 构建、重复任务、缺失依赖、循环检测、拓扑排序、并行批次、状态更新、ready 任务、trace 查询和导出。moon run cmd/demo可以直接运行,并展示 Markdown 与 JSON 两种结果。项目链接
开发说明
项目为原创 MoonBit 实现,参考的是通用的 DAG、workflow 和 provenance 思路,不直接移植某个上游项目。开发过程中使用了 AI 辅助代码实现、测试和文档整理;选题、功能取舍、验收与提交由项目作者负责。
许可证
Apache-2.0。详见 LICENSE。