Neo.mjs：一个把自己当产品维护的 AI 工程团队，以及它的多线程运行时

它解决的问题：会话式 AI 的遗忘与无审查

大多数 AI 编程助手是无状态的。每次对话从头开始，模型不记得上次的决策，也没有跨会话的评审。Neo.mjs 的定位是反过来的：它把自己描述为一个常驻的工程机构，而不是一个聊天面板。文档用了一个词，"possession"，指 AI 通过 Neural Link 接口直接操作运行中的应用，而不只是读代码。它想解决的是单一模型自审查的盲区。多个模型，Claude、Gemini、GPT，共享记忆与图结构，互相读对方的推理。这对那些代码库庞大、历史决策分散在 issue 和 PR 里的团队有吸引力。它不适合个人开发者或一次性脚本项目。你需要的是一套持续演进的系统，而不是一个偶尔调用的工具。

两个半球：Brain 与 Body 的分工

仓库结构把系统切成两半。Body 是当前这个仓库，neomjs/neo，一个多线程应用引擎。它包含 App Worker、VDom Worker、Data Worker、Canvas Worker 和 SharedWorker，全部基于原生 ES 模块，零构建。Brain 在另一个仓库，neomjs/neo-agent-brain，是 Agent OS。它管 Memory Core、Knowledge Base、Native Edge Graph、A2A 协调、GitHub 工作流自动化和 DreamService。文档强调 Brain 是差异化所在。Body 是运行时，Brain 是住在里面的智能。两者通过 Neural Link 连接。这个拆分意味着你要部署的不只是一个 npm 包，而是两个仓库的配合。文档没有给出两者之间的通信协议细节，只提到 A2A 协调。如果你想深入，需要去 Brain 仓库的 learn 目录找文档。

MX 循环与 DreamService：自我进化的具体机制

Neo.mjs 的进化机制叫 MX 循环，Model Experience。流程是：内部摩擦变成 ticket，ticket 变成 PR，PR 变成技能和记忆，下一个 agent 从更好的起点开始。DreamService 在这个循环里负责把嘈杂的战术会话蒸馏成 Native Edge Graph 中的 Golden Path 拓扑。文档给了一个公式：priority = semanticScore × 2 + stru，后半部分被截断了。但至少能看出优先级不是简单计数，而是语义分与结构分的加权。这意味着系统不是靠 PR 数量成长，而是靠图拓扑的数学性质。文档说这是"gated-RSI by design"，即受控的递归自我改进。创始人架构师保留最终合并权。这既是治理选择，也是安全阀。它避免了完全自主的 AI 修改生产代码的失控风险，但也意味着你信任一个特定的人类。

Neural Link：AI 如何"居住"在应用里

文档描述 Neural Link 是一种 possession 接口。AI 不只是读代码，它检查语义运行时状态，实时修改 UI 和数据。这比常见的代码生成更进一步。普通 AI 工具生成 diff，你手动合并。Neural Link 让 AI 直接操作运行中的应用。这意味着它能验证自己的修改是否生效，而不只是靠静态分析。文档说它能"turn conversational UIs from chat panels into agents collaborating inside the application"。这听起来像是把聊天界面变成 agent 的操作台。但文档没有给出这个接口的 API 或安全边界。对于生产环境，这是一个关键缺口。你需要在采用前确认它如何防止 AI 破坏数据。Body 的 worker 结构可能提供隔离，但文档没明说。

部署与运行：从仓库到你的代码库

v13 把 Agent OS 变成多租户云部署。你可以指向自己的仓库，而不是 fork。文档说 onboarding 一个代码库是配置项，不是 fork。部署组件包括 Knowledge Base 和 Memory Core 的 MCP 服务器、Native Edge Graph、云安全的 Orchestrator、模型提供方和 OIDC 网关。状态存储是 SQLite Native Edge Graph 加向量库。这意味着备份就是快照数据库，可以移到另一台机器或 Time Capsule。文档提供了几个学习资源的链接，包括 Day-0 云部署教程和租户摄入模型。但当前仓库的 README 没有给出具体的安装命令或配置文件示例。你需要去 Brain 仓库的 learn 目录找。这是采用的一个实际障碍：入口不在你正在看的这个仓库。

限制与失败模式：它可能不是你的工具

第一，它依赖第三方模型。文档明确说 swarm 由 Claude、Gemini、GPT 组成。如果你的组织不允许外部 API 调用，或对数据主权有要求，这直接排除。第二，它要求你接受"AI 维护代码库"这个前提。不是所有团队都愿意让 AI 直接改 UI 和运行时状态。Neural Link 的实时修改能力在没有明确回滚机制的情况下是危险的。第三，文档提到"Clean Room Ethics"和"organism self-defense"，但没有细节。这意味着安全模型未完全公开。第四，多租户隔离只说"per-tenant identity and visibility isolation"，没有说明租户间数据泄露的防护机制。如果你的代码库包含敏感密钥或未公开算法，这些未回答的问题就是硬伤。

替代方案：无状态 copilot 与自托管 agent 框架

最直接的替代是 GitHub Copilot 或类似的无状态工具。它们不做跨会话记忆，不维护图结构，也不自我进化。优点是简单，缺点正是 Neo.mjs 想解决的遗忘问题。另一类替代是自托管的 agent 框架，比如 LangChain 或 AutoGPT。它们允许你控制模型和记忆，但通常没有内置的 GitHub 工作流自动化，也没有 DreamService 这样的蒸馏机制。Neo.mjs 的差异化在于它把工程生命周期整个包进来：issue 管理、PR 评审、技能沉淀。如果你只想让 AI 写代码片段，用 Copilot 更轻。如果你想构建一个长期维护代码库的机构，Neo.mjs 的图结构记忆是独特卖点。但你必须接受它的治理和部署方式。

维护成本与许可证

许可证是 MIT，这对商业使用友好，没有 copyleft 义务。但维护成本不低。你需要维护两个仓库的同步，因为 Brain 和 Body 分开演进。文档说"every git clone is a complete, runnable backup"，这缓解了备份焦虑，但也意味着你的部署体积包括整个运行时。升级路径是明确的：最近三个版本是 v13.1.0、v13.0.0、v12.1.0，发布间隔约三个月。v13 引入了多租户，这是一个重大变化。如果你从 v12 升级，需要检查 Brain 仓库的迁移文档。文档没有提到数据库 schema 变更的兼容性，也没有提到模型 API 成本。这些是隐藏成本。你需要在采用前估算每月 API 调用量。

编辑结论

如果你的团队维护多个长期代码库，且愿意把工程决策交给一个跨模型 swarm，并接受 SQLite 与向量库作为唯一记忆介质，Neo.mjs 的 v13 多租户部署值得一试。但若你只想要一个能生成代码的助手，或对第三方模型持保留态度，它过重。开始前先验证三件事：其一，你的代码库能否被 OIDC 网关安全暴露给 Orchestrator；其二，你是否接受 founder-architect 保留最终合并权的治理结构；其三，你是否愿意把 GraphRAG 的 Golden Path 拓扑当作团队知识的事实来源。文档明确说 onboarding 是配置项而非 fork，但没说迁移现有 issue 或 wiki 的路径，这需要你自己确认。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes