完全离线的本地多节点 Agent 栈
开源生产采用 · 第三方项目
这套离线 Agent 栈是第三方开源项目，由 Mark Galyan（GitHub 用户名 apollo-mg）独立开发维护，基于 open-multi-agent 构建。整套系统断网运行，推理全部落在自有硬件的本地量化模型上，OMA 在其中充当编排核心。
场景
open-multi-agent 的 README 把 Mark Galyan 列为自框架第一个月起的贡献者。他公开的仓库 Project Apollo 自述为气隙（air-gapped）、本地优先的多节点 Swarm 架构。
按他的 README 与运维手册，系统分两层：协调节点规划并分解任务，工作节点认领执行；中间是 WAL 模式的 SQLite 消息总线，节点以独占事务原子认领，任务自带硬件约束（最小上下文长度、量化位宽），按各节点上报的显存与状态路由。当前稳定运行的是双节点：16GB 显存工作站做协调，32GB 显存双卡无头服务器做执行。
痛点都写在他公开的 issue 和 PR 里：显存是硬边界，无人值守的长循环很快撑爆上下文；高度量化的模型在多轮工具调用里容易吐坏 JSON、掉进重复循环。
方案
| 角色 | 任务 DAG | 工具 | 模型 | 部署形态 |
|---|---|---|---|---|
| 协调节点（Architect） | 目标 → 任务分解与依赖调度；跨轮次靠上下文压缩把历史压回可承受的体量 | OMA 的 coordinator 与 context compaction；委派任务经消息总线下发、等 SSE 回调，设 30 分钟安全超时 | 本地量化模型，经 OpenAI 兼容端点接入 | 工作站上从仓库内 vendored 的 open-multi-agent 引擎目录启动（npx tsx examples/apollo_cli.ts 或 apollo_server.ts） |
| 工作节点（Worker daemon） | 从 SQLite 队列认领任务并本地执行；卡在执行中超过 15 分钟由后台线程回收重排 | 本机 shell 与系统管理能力经 MCP 暴露，带分级权限门 | 节点本地小模型（其 README 说日志与抽取类任务用 8B–14B 量级即可） | deploy/Dockerfile.worker 构建时先拷 engines/open-multi-agent-upstream/package*.json 并 npm ci，再装 Python 守护进程 |
| 常驻后台循环（他称 Daydream Daemon、codebase_investigator） | 无人值守的长多轮循环，自动复查日志与代码库 | 上下文压缩策略是这条循环能活下来的前提 | 同为本地量化模型 | 本地常驻，全栈离线运行 |
OMA 的位置从仓库结构直接可见：engines/ 下有两个指向 open-multi-agent 的引擎目录，git 记录的是提交指针，其中一个正是 OMA 2026-04-01 的首个发布提交；deploy/Dockerfile.worker 构建工作节点镜像时先装该目录的 Node 依赖；启动脚本与运维手册里拉起编排层的命令也在该目录下。
他提交并已合并进 open-multi-agent 的三个 PR，都是本地离线场景逼出来的。
#161（2026-04-23 合并）：上下文压缩只在第二轮之后才评估，压缩后的历史又没回传给调用方，调用方继续持有未压缩历史。改动落在 src/agent/agent.ts、src/agent/runner.ts 与上下文策略测试，去掉首轮门槛并避免丢轮次。对应他先提的 issue #152。
#163（2026-04-25 合并）：把 topP、topK、minP、frequencyPenalty、presencePenalty、extraBody 透出到 AgentConfig 与 RunTeamOptions，并接进 OpenAI / Anthropic 适配器。他给的理由：云端默认采样够用，消费级硬件上跑高度量化 MoE 模型缺了这些参数，多轮工具调用里容易掉进重复幻觉循环。
#269（2026-06-02 合并）：量化模型偶尔往工具参数里塞 Python 三引号或未转义引号，JSON.parse 失败后只返回空对象，模型据此空转。该 PR 在 OpenAI 补全解析处加正则兜底；按评审意见去掉硬编码的工具名，并补了独立测试文件。
结果
他本人与公开记录写下的事实：
open-multi-agent 的 README 在「Built with OMA」一节列出 Mark Galyan：他 "runs OMA fully offline on local quantized models"，用 coordinator 与上下文压缩在紧张显存下维持自主 Agent 循环，自框架第一个月起就是贡献者。
三个 PR（#161、#163、#269）已合并进主仓，改动分布在 Agent 运行器、LLM 适配器与测试文件；另有两个 PR 由他自己关闭，其中一个他说明根因在自己的本地推理服务器。
他在公开 issue #152 的回复里说明用途：把 OMA 当作本地优先系统的核心编排器，在本地复刻 Coordinator → Worker 模式。
他公开仓库的致谢把 open-multi-agent（MIT）列为核心 TypeScript DAG 编排与基础 agent 循环的来源，引擎目录、工作节点 Dockerfile 与启动脚本可逐条对上。
可核实
与元定义的关系
本页素材全部来自第三方开源项目的公开仓库、PR 与 issue，元定义是它所依赖的 open-multi-agent 框架的作者，他的修复经公开 PR 合并进框架。
如果你的约束也是数据留在内网、模型跑在自有 GPU、还要多个 Agent 分工协作，元定义提供私有化部署与内网模型接入，对应的服务是 多智能体系统集成 →
相关服务
最后更新
想知道类似的流程在你这边怎么落地?