Agent 存算分离架构

这组图想讲清楚一件事：

一个 Agent 想规模化运行，不能把“长期保存的数据”和“临时发生的计算”绑死在同一个地方。

01｜Agent 存算分离

Agent 的“存”和“算”其实是两件事。

“存”是灵魂、记忆、文件、产物。

“算”是上下文拼接、LLM 调用、工具调用和中间推理。

存要长期可靠，算可以临时拉起。

02｜一次任务怎么跑

一次 Agent 任务，不是简单问一次 LLM。

它通常会经历：

query -> prompt -> tools -> memory -> loop -> artifacts

也就是先拿到用户输入，再读取提示词、工具和记忆，然后进入循环推理，最后交付产物。

03｜什么需要存

需要存的是那些不能随便丢的东西：

• 提示词
• 工具技能
• 对话记录
• 长期记忆
• 交付产物

这些东西像 Agent 的档案柜。

它们决定了 Agent 是谁、会什么、记得什么、交付过什么。

04｜什么需要算

需要算的是任务执行时临时发生的动作：

• 拼上下文
• 调 LLM
• 调工具
• 观察结果
• 再推理

这些动作很重要，但不一定要永久占用一台机器。

算力应该像临时工作台：任务来了就启动，用完就释放。

05｜本地裸机：简单但危险

本地裸机运行最简单。

提示词、记忆、文件、工具调用和产物都在同一个 workspace 里。

好处是快，文件不用来回同步。

坏处也明显：如果 Agent 执行危险命令，可能直接伤到宿主机。

06｜本地沙盒：把危险关进盒子

沙盒模式会把敏感工具调用隔离出去。

宿主机保存文件和 workspace。

sandbox 负责执行命令、跑工具、处理外部依赖。

这样即使工具调用出问题，也不容易直接污染宿主机。

07｜云端：临时 workspace + 外部存储

云端 Agent 要服务很多用户，不能让每个用户都常驻一个 pod。

更合理的方式是：

任务来了 -> 拉起临时 workspace
读取 KV / DB / 记忆库 / OSS
执行 Agent Loop
上传状态和产物
用完释放

这里的关键是：计算资源临时化，数据资源持久化。

08｜真正难点：多副本一致性

云端规模化以后，真正难的不是“跑起来”。

难的是多个副本同时工作时，数据不能乱。

所以需要：

• 锁
• checkpoint
• 幂等写入
• 任务状态机
• workspace 快照

目标只有一个：不串数据，能恢复，成本还压得住。

一句话总结

Agent 存算分离的本质是：

让 Agent 的灵魂、记忆和产物长期存在，让 Agent 的计算过程按需发生。

这样它才能同时做到：

• 记得住
• 跑得动
• 可恢复
• 不串数据
• 可规模化