架构
运行时与 MCP 架构
MindMux 通过运行时层和 MCP 工具层，把模型执行与项目知识分开。
运行时抽象
运行时抽象让不同执行后端可以驱动同一个产品界面。对话会话和任务都依赖这层抽象。
它的主要目标是：
- 运行时可移植性
- 不同后端上的共享产品行为
- 更清晰的产品逻辑与供应商特定执行之间的边界
当前支持的运行时
当前产品方向是让多个运行时共同作用于同一个知识模型。当前文档覆盖的可用运行时包括：
- Claude Code
- Codex
真正重要的架构点不是品牌列表，而是项目大脑不属于其中任何一个运行时。
MCP 作为知识边界
MindMux 通过 MCP 工具暴露结构化项目能力，而不是只依赖原始 prompt 上下文。
重要的工具家族包括：
- 项目大脑读写工具
- 根文档工具
- 技能工具
- 任务工具
- 配置工具
典型请求路径
对话作用域和任务作用域
工具界面是被刻意限域的。有些工具对主对话 agent 开放，但不会直接开放给代理任务执行，尤其是那些涉及路径解析、编排权限或项目级写入的能力。
例如更偏向对话作用域的行为有：
- 项目级编排
- 用户交互卡片
- 大范围知识写入
而更适合任务作用域的行为包括：
- 聚焦的读访问
- 受约束的审查或执行流程
独立 MCP server 进程
代码库使用的是一个独立 MCP server 边界，而不是把所有能力都封装进同一个单体运行时循环。这样能更严格地控制工具暴露范围，也让知识接口保持清晰。
外部连接器和桥接
MindMux 本身也是一个 MCP client。这意味着产品既能：
- 把自己的能力暴露给运行时
- 把外部 MCP servers 当作连接器来消费
当某个运行时不能直接消费某种传输形态时，架构里还会通过一层桥接来把连接器规范化成可用形式。
为什么这很重要
这套架构让 MindMux 拥有一份稳定的知识契约。运行时可以变化，但项目大脑及其操作方式仍然保持可读和结构化。