project-orchestrator
Rust 编写、以 Neo4j 知识图谱为共享记忆的多 AI Agent 编排引擎，支持本地 candle 神经网络路由
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
Rust 编写、以 Neo4j 知识图谱为共享记忆的多 AI Agent 编排引擎，支持本地 candle 神经网络路由
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下这个画面：你同时调度 Claude Code、Cursor、Copilot 等多个 AI 编程工具，让它们并行开发一个后端系统。结果呢？Agent A 建了一张用户表，Agent B 不知道；Agent C 重构了接口，Agent D 还在用旧签名。最后代码合并，冲突一片。这不是工具的问题，而是缺乏共享上下文——就像一个没有白板的团队，每个人脑子里只装着自己的任务。
Project Orchestrator 正是为了解决这个问题而生：它用 Rust 编写了一个多智能体编排引擎，以 Neo4j 知识图谱 为核心记忆中枢，以 Meilisearch 为语义搜索引擎，以 Tree-sitter 为代码结构解析器，让多个 AI Agent 在同一张"项目地图"上协同工作。
这个项目来自 this-rs 组织（命名暗示"All-Things Rust"），选择了 Rust 而非 Python 作为 AI Agent 框架的主力语言。背后的逻辑很清晰：
candle（LocalAI 团队出品的 Rust ML 框架）本地运行神经网络路由模型，不依赖外部推理 API这代表了一个有趣的趋势：AI 基础设施 Rust 化。以往 ML 领域 Python 一统天下，但随着 LLM 本地部署需求增长，Rust 在推理效率、包体积和运维成本上的优势开始显现。
每个 Agent 执行任务时产生的中间产物——代码片段、设计决策、API 变更——都会写入 Neo4j 图数据库。以节点和关系的形式存储，比如：
(Plan:plan_id) -[:HAS_TASK]-> (Task:task_id) -[:PRODUCES]-> (Artifact:file_change)
(Task:task_id) -[:BLOCKED_BY]-> (Task:other_task_id)
这样，任意 Agent 在行动前都能查询"谁改过这个文件"、"这个任务依赖哪些前置完成"。彻底解决开头提到的"信息孤岛"问题。
Meilisearch 为项目提供毫秒级全文和语义搜索能力。Agent 可以用自然语言提问，比如"哪个任务负责实现支付模块"，系统直接返回相关上下文片段。
Tree-sitter 解析源代码生成 AST（抽象语法树），为 Agent 提供精确的代码结构理解能力。配合 tree-sitter-dart 和 tree-sitter-hcl（自定义解析器），不仅能读懂代码"是什么"，还能理解"在哪里改"。
项目内置了 neural-routing 子系统，包含 4 个 ML 模型：
| 模型 | 用途 |
|---|---|
| Decision Transformer | 序列决策，强化学习路线 |
| R-GCN + GraphSAGE | 图神经网络，学习代码关系图 |
| Nearest Neighbor | 最近邻路由，稳定兜底 |
| CQL Policy Network | 离线强化学习策略 |
这套"神经网络路由"的目的是让系统在多个可用 Agent / 执行路径中自动选择最优方案。
NATS 提供了低延迟发布/订阅消息通道，各组件通过它解耦通信，支持 Jetstream 流式处理事件日志。这比传统 RPC 更适合多 Agent 异步协作场景。
项目采用 Rust Workspace 结构，主 Crate 负责核心 API（Axum Web 服务器），子 crate 分层：
src/
├── api/ # HTTP API（任务拉取、状态更新）
├── auth/ # 认证（ed25519-dalek 签名）
├── chat/ # Agent 聊天上下文管理
├── embeddings/ # 向量化嵌入
├── graph/ # Neo4j 图操作
├── episodes/ # 任务执行记录
├── events/ # 事件流
├── analytics/ # 分析统计
└── bin/ # CLI 入口
桌面客户端在 desktop/src-tauri/（Tauri 框架），实现了跨平台 GUI。
推荐路径：Docker Compose 一键部署
项目提供了完整的 docker-compose.yml，内置 Neo4j + Meilisearch + NATS 三个依赖服务，加上主服务共 4 个容器。启动命令简洁：
cp .env.example .env # 编辑填入配置
docker-compose up -d
然后访问 http://localhost:8080 使用 Web UI，或通过 CLI 和 MCP 工具直接接入。
硬件要求：最低 4GB RAM（Neo4j 建议分配 2-4GB Heap），多容器并发建议 8GB+。无 GPU 可跑 CPU 模式——得益于 candle 的纯 CPU 实现。
1. 许可证混乱
根目录同时存在 LICENSE-MIT、LICENSE-EE 和 LICENSE（无后缀，NOASSERTION），实际 license 字段返回 NOASSERTION。核心 ML 模块（neural-routing-*）标注了 MIT AND BUSL-1.1 双许可。License 不清晰会给商业使用带来法务风险。
2. 成熟度存疑 项目 stars 仅 124，crates 数量少（tree-sitter-dart 和 tree-sitter-hcl 是最简单的自定义解析器），神经网络路由模块尚处于实验阶段（"permanent fallback"说明 NN 路由还不可靠）。
3. Neo4j 的运维负担 Neo4j 是重量级依赖（2-4GB 内存 + Java 运行时），单机轻量使用场景下略显奢侈，增加了部署复杂度。
Project Orchestrator 处于 AI Agent 基础设施的一个细分赛道——多 Agent 协调中间件。这个赛道的核心挑战不是"如何做一个更好的 AI"，而是"如何让多个 AI 高效协作"。类比微服务架构中的 Service Mesh，Project Orchestrator 试图成为 AI 编程 Agent 的"数据平面"。
类似定位的项目还有 LangGraph、AutoGen、CrewAI，但它们的共同问题是：用 Python 写的，在生产环境中缺乏 Rust 级别的稳定性和性能。从这个角度看，this-rs 的赌注有一定道理——当企业开始大规模部署 AI Agent 时，运维团队会更青睐可预测的资源消耗和更小的容器镜像。
Stars 增长曲线：目前 124 星，属于早期项目，但架构设计完整度高，具备长期潜力。关注者主要是对 Rust + AI 交叉领域感兴趣的开发者。
报告生成时间：2026-08-01 | 数据来源：GitHub API + 项目源码分析