Skip to main content
English: Architecture overview 这是面向开发者的架构入口。Monad 守护进程持有 Agent 团队运行时，客户端与执行引擎通过公开协议接入。Monad Agent Runtime 是随附的第一方执行路径。 这一页回答三个问题：
  1. 系统由哪些部分组成？ 查看下面的分层图
  2. 随附 Agent 如何执行一轮？ 查看请求时序图
  3. 接下来读什么？ 选择一个内部机制分类
面向用户的功能文档在 ../usage/；仓库工程规范在 ../engineering/。

​
1. 分层图

Monad 的所有设计都服从一条规则：守护进程持有状态，客户端只负责渲染与操控。 由此推出三条必须先内化的结论：
  • 没有权威客户端。 关掉浏览器不会中断一轮生成；CLI、Telegram 消息、编辑器可以驱动同一个会话。
  • Workplace Experience 是 Web UI 的功能，不是运行时的一层。 它活在 apps/web 里，只负责 重绘项目页面；CLI、TUI、编辑器和通道都不经过它。任何需要在所有客户端都可用的能力，必须放在 守护进程侧（工具、命令、hooks、protocol），不能放进 experience。
  • 跨进程边界的一切都要解析，不能信任：HTTP、WebSocket、磁盘、MCP、atom pack、模型输出 一视同仁。见运行时安全模型。

​
2. 第一方 Agent 如何执行请求

这段时序描述随附的第一方执行引擎。外部运行时使用各自的适配器与观察协议。 这张图编码了三条不变量：
  • 先落库，再发布。 状态先提交存储，事件后发出。重连的客户端不会看到一个取不到状态的事件。
  • 两条平面，永不合并。 低频生命周期走控制 WebSocket，token 增量走 per-message SSE。细节见 infra/realtime-channels.md。
  • 审批门 fail-closed。 高风险工具在没有可用审批门时被拒绝，而不是放行。细节见 agent-runtime/tools.md。

​
3. 进程怎么起来

启动是一张按拓扑排序的生命周期图，不是一坨 main()。热重载刻意保守：尾部去抖、单飞、提交成功 才接受。完整模块表见 infra/daemon-architecture.md。

​
4. 状态存在哪

路径布局由 @monad/environment 统一定义，包括 Linux 上的 XDG 拆分。详细边界见运行时架构。

​
5. 怎么扩展

扩展遵循「先声明、后注册」：清单声明能力种类，宿主展示给用户审计，运行时强制执行。 内置工具不是 atom kind。它们随守护进程发布，安全防护保持第一方。见 infra/atoms.md、../usage/skills.md、 infra/hooks.md。

​
6. 约束层

每一层都假设上一层已经失效。完整威胁模型见运行时安全模型，各平台落地现状见沙箱后端。

​
继续阅读

各分类的完整文档清单见英文版 README.md，或直接进入 infra/、agent-team-runtime/、 agent-runtime/。