RFC-001: L3 ECS — 继续自研 archetype 还是直接接 Bevy ECS？

[leslie520-bye]

背景

OriEra 的 L3 对象模型层需要一个 ECS（Entity-Component-System）。我们已经写了一个最小原型（crates/oriera-ecs/），但它现在只有 spawn/insert/query，是单 archetype 的简化版。

选项 A：继续自研

优点：

• 完全可控，可以为 AI-native 场景做特殊优化（比如 MCP 工具直接 query component）
• 不引入 Bevy 的庞大依赖树（Bevy 带渲染、输入、场景图）
• 学习成本低，代码量小，社区容易读懂

缺点：

• 我们要自己实现多 archetype、query 组合、event、schedule——这是个深坑
• 性能要自己 benchmark 和优化
• 不如成熟项目经过工业验证

选项 B：直接接 Bevy ECS

优点：

• 成熟、高性能、经过千万级实体验证
• 内置 query、system schedule、event
• 社区大，文档全
• 未来如果需要 Bevy 渲染管线也顺理成章

缺点：

• Bevy ECS 是 Bevy 的核心，但单独用它会带很多依赖
• 它的 API 是为游戏设计的，AI-native 的需求（比如跨进程 query、MCP 工具暴露）可能需要 wrapper
• 我们对它的控制粒度不如自研

选项 C：用 slotmap + 自研调度

折中方案——用 slotmap（已经在 workspace deps 里）做实体存储，自己写 query 和 system schedule。

我的倾向

我个人倾向 选项 A（继续自研），理由：

1. OriEra 的 ECS 不是通用游戏 ECS，它要服务于 AI Agent——component 是"认知状态"、"记忆"、"目标"，不是"位置"、"速度"
2. 我们需要把 component query 暴露成 MCP 工具，这个接口层自研更直接
3. v0.1 阶段不需要百万级实体，简单原型够用

但我想听大家的意见。尤其是有 Bevy 或其他 ECS 经验的人。

投票

• 👍 A：继续自研
• ❤️ B：接 Bevy ECS
• 👀 C：slotmap + 自研调度

请在下面评论你的理由。