SmartAgency · 代表作
AI Native
多 Agent 开放系统
与现有产品的区别
| 竞品系列 | 核心问题 |
|---|---|
| Claw 系 OpenClaw / Hermes |
为了实现自进化，引入太多黑盒逻辑，Token 消耗大；多 Agent 是后打的补丁，架构支持不利；单机部署，团队不能共用。 |
| Claude Code 系 | 单机产品，云端部署时有较多不便，无法团队共用；多 Agent 是在原来 SubAgent 上打的补丁，导致 AgentTeam 只能实现中心化管理方案；代码中较多 HardCode 为模型兜底，短期能提升效果，长期看是技术负债。 |
| Managed Agents 系 | 太复杂，复杂到几乎无法搭建团队级多 Agent 产品；架构层没想清楚，做了太多不必要设计 |
MultiAgent 是必然的技术趋势，为此我们需要一套自底向上、围绕全新技术范式建设的 AgentOS。
好的 Agent 应用必然是由人定义出来的——在以 Transformer 为「心」的技术前提下，AI 自进化路线无法成行。
我们的实现方案
四层架构，自底向上，每一层都为多 Agent 协同而设计。
LAYER A
通信层
message-station · 多 Agent 协同的基础设施
- 在 message 里扩展 source、target 字段，明确通信的双方，实现 U2A、A2U、A2A 甚至 U2U 全覆盖。
- 全异步双向通信代替 SSE 协议，能够完整支持 ABCA 与 ABCBA 通信模式。
同样的 A→B→C 流程，SSE 必须逐级返回，全异步通信允许 C 直接回 A
LAYER B
定义层
prompt + tools + model = Agent 的全部
- agent.json 中提供 prompts、tools、model 三个基本定义。
- skill 与 memory 均通过 prompts 中配置 md 文件，结合渐进式披露实现。
- 一个 Agent 不是 skill 的单纯堆砌，而应该是对业务流程，知识与服务的系统化组织。
好的 Agent 是 Define 出来的，不是 HardCode 出来的。
LAYER C
ReAct 层
ReAct Loop 与运行环境解耦 · 无状态 · 可集群化
- ReAct Loop 与运行环境解耦，通过 Sandbox 提供 Bash 与 Filesystem，ReAct 层变成无状态，可以支持集群化部署，以承载大规模用户高并发请求。
- 对接毫秒级启动的弹性 Sandbox，用完即销毁，极大提高 Agent 场景下的资源利用率。
- 提供原生的 mail 能力，结合 message-station 的双向通信。由此多 Agent 的设计与实现变成上层的"Agent 管理学"问题。
ReAct 跑在服务器上，Bash 与 Filesystem 在弹性 Sandbox 中执行
LAYER D
环境层
共享云存储 · 动态挂载 · Everything is File
- 使用基于 Posix 协议的共享存储作为 Sandbox 里的 Filesystem，通过动态挂载的方式决定每个 Agent 能看到的内容以及读写权限。
- 挂载方案、agent.json、skill、memory——在 Agent 的世界里，一切皆为文件。
- 在 SmartAgency 中初始化一个 Agent——盘古，它能够读写整块云盘，于是它能创造 Agent，也能修改 Agent，一生二，二生三，三生万物。
盘古的领地是 L 型（左列 + 底部 RW 条）· 其余 Agent 通过动态挂载获得可见范围
所以整套系统都是 AI Native。