夜雨聆风
从 OpenClaw 到 Manus:Agent 架构到底复杂在哪?
最近这段时间一直在忙一些出海相关的业务，注意力基本都放在「增长」和「内容系统」这两块。
现在研究点Agent的一线生产架构，灵感来源@idoubi老师。
Agent 从来不只是模型调用，而是一套系统工程
如果要描述一个有灵魂、有记忆的 Agent，它一次完整任务的生命周期，大概不是简单的“用户问一句，模型答一句”，而是可以拆成下面这一套流程：
- 用户输入 query，可能是纯文本，也可能带文件
- Agent 去读取自己的提示词文件，比如 soul.md、AGENTS.md、CLAUDE.md
- Agent 加载当前能用的工具和技能，比如 tools、skills
- Agent 读取记忆，比如 memory.md，或者通过 memory_search 查询历史信息
- Agent 把 prompt、tools、memory、query 这些东西拼成上下文
- Agent 进入循环：LLM 推理 → 调用工具 → 观察结果 → 继续推理
- 最后把结果交付出来，也就是 Artifacts
从这里其实能看出一个核心问题：Agent 系统里有些东西是要「存」的，有些东西是要「算」的。
需要存的东西包括：
提示词文件、工具和技能、对话记录、最终交付产物。
需要算的东西包括：
上下文拼接、LLM 调用、工具调用。
所以按照运行方式粗暴划分，Agent 大概可以分成三种形态：
- 本地裸机运行
- 本地加 sandbox 运行
- 云端多副本运行
1. 本地裸机运行
本地裸机运行，是 OpenClaw 这类 Agent 比较典型的模式。
这种模式下，Agent 的提示词文件、skills、sessions 对话记录，基本都直接放在本地磁盘。
Agent 真正执行任务的时候，会进入一个固定的 workspace 目录。
用户上传的文件也好，Agent 后面生成的文件也好，都会堆在这个 workspace 里面。
换句话说，Agent Loop 在运行过程中，不管是构建上下文，还是执行工具调用，本质上都是围绕本地文件系统展开的。
这种情况下，「存」和「算」几乎是绑死在一起的。
它的优点很明显：简单。
没有额外的文件挂载逻辑，也不需要引入复杂的调度系统。Agent 想读文件就读，想写文件就写，整个链路非常直接。
但它的问题也同样明显：安全性差。
因为 Agent 和宿主机之间没有强隔离。
举个极端一点的例子，如果 Agent Loop 里真的执行了类似 exec(rm -rf /) 这种工具调用，那它就有可能直接把宿主机干穿。
当然正常产品里未必会允许这种操作，但问题本质还是一样的：Agent 的执行边界太靠近宿主机了。
2. 本地加 sandbox 运行
第二种是本地带 sandbox 的模式，Codex 这类 Agent 就比较接近这种形态。
它引入 sandbox，主要是为了限制 Agent 的操作边界，避免它直接越权影响宿主机。
也就是说，Agent 需要执行一些敏感工具调用的时候，不是直接在本机环境里跑，而是把任务丢进 sandbox 里执行。
这里大佬还提到一个点，说 sandbox 可以解决“宿主机依赖缺失导致工具调用异常”的问题。
但我个人感觉，这里可能稍微有点混淆。
如果还是本地 Agent，本地 sandbox 不一定真能很好解决依赖缺失的问题。实际体验里也能感受到，很多时候该缺的依赖还是缺，该报错还是报错。
我理解他真正想表达的，可能是更云端化、容器化的 sandbox / environment。
也就是提前准备好一套标准化运行环境，让工具调用在一个更可控的容器里执行。这样确实可以减少因为用户本地环境乱七八糟导致的异常。
本地 sandbox 的运行方式，大概可以理解成这样：
Agent 仍然在宿主机上管理 workspace。
当 Agent Loop 需要执行工具调用时，就把宿主机上的 workspace 目录挂载到 sandbox 里。
工具在 sandbox 里执行，读写的也是这个挂载进去的 workspace。
执行完之后，产物又能同步回宿主机的 workspace 目录。
这里的「挂载」不是简单地复制一份文件。
更像是把同一个目录映射到了 sandbox 里面。
所以 Agent 在 sandbox 里改了文件，本地 workspace 里也能看到对应变化。
因此这种模式虽然比裸机安全一些，但严格来说，存算分离并不彻底。
它只是把“工具调用”这部分计算放进了 sandbox。
真正的存储，主要还是依赖宿主机自己的文件系统。
3. 云端多副本运行
第三种是云端多副本运行，这更像 Manus 这类工具型 Agent 的常见形态。
它面对的问题已经不只是“我本地怎么跑一个 Agent”，而是：
怎么让很多用户同时用？怎么让多个任务并行跑？怎么让 Agent 可以长时间运行？怎么保留用户的记忆、文件和技能？
像 genspark claw、kimi claw、max claw 这些托管版小龙虾，本质上就是云端多副本的助理型 Agent。
每个用户都有自己的提示词文件、动态安装的 skills，也会产生长期记忆和历史任务记录。
这类 claw 托管服务，最简单粗暴的实现方式，就是上一套 k8s 集群。
每个 pod 里部署一套 Agent 框架，比如 OpenClaw、hermes 之类。
用户资料则通过 PVC 挂载云硬盘来做持久化。
然后再通过负载均衡策略，把某个用户的请求固定打到某个 pod 上。
这样这个用户的 Agent Loop 就一直在同一个 pod 里完成。
这种方案有点像把“本地 Agent”搬到了云端。
每个 Agent 都有自己的运行空间，隔离性不错，逻辑也比较直观。
但缺点也很硬：成本高。
因为 pod 需要常驻。
如果每个用户、每个任务都要长期占着一个 pod，那用户量一大，成本会非常难看，也很难真正规模化。
所以云端 Agent 如果要做到 scalable，就不能再简单地把本地 Agent 搬到服务器上跑。
它一定要走向存算分离。
也就是：
计算层负责动态扩缩容，按需处理任务。存储层负责长期保存用户资料、记忆、任务记录和工作产物。
计算层通常会依赖 k8s 的调度能力，让 pod 可以根据请求量水平扩展，从而提高 Agent 网关的并发处理能力。
而存储层则要根据 Agent 的运行生命周期，把不同类型的数据拆开存。
大概可以分成四类。
1. 热状态
第一类是热状态。
比如 Agent Loop 里的 step、plan、游标、checkpoint 这些东西。
这些状态需要频繁读写，也需要足够低延迟。
所以适合放在 KV 里，比如 Redis。
它的作用主要是支撑异常恢复。
比如任务跑到一半挂了，Agent 可以根据这些状态继续恢复，而不是从头再来。
2. 对话和任务记录
第二类是对话记录和任务记录。
这类数据通常在任务完成后沉淀下来，结构也比较清晰。
所以比较适合放进关系型数据库，比如 Postgres。
它更像是系统里的“正式档案”。
3. 长期记忆
第三类是长期记忆。
长期记忆不是简单把所有聊天记录原样塞进去。
更合理的做法，是基于历史对话和任务记录做摘要，再从里面提取出对未来有用的信息，形成 memory。
这类内容通常需要语义检索，所以会放进向量数据库。
比如 pgvector、Milvus 这类东西。
4. 工作产物
第四类是工作产物。
包括用户上传的文件、Agent 生成的文件、系统内置 tools、动态创建出来的 skills 等。
这类东西本质上都是文件或对象。
所以更适合放在对象存储里，比如 S3、OSS。
作者在原文里还拿自己的 FastClaw 举了一个例子。
我们可以顺着这个例子看一下，基于存算分离架构的云端 Agent 是怎么跑起来的。
以 FastClaw 为例，整个流程大概是：
- 先有一套 k8s 集群，平时保留 2 个 pod，用来部署 fastclaw gateway，负责接收用户请求。
- 用户请求进来之后，负载均衡会把它路由到某一个 pod，Agent 开始执行计算逻辑。
2.1 从 DB 里读取提示词文件，比如 soul、identity、user2.2 在 pod 内部初始化一个临时 workspace2.3 启动 sandbox，并把 workspace 挂载进去2.4 从对象存储里把用户资料和系统 skills 下载到 workspace2.5 调用 memory_search，从向量数据库里检索长期记忆2.6 拼接上下文，调用 LLM，并解析模型给出的工具调用2.7 在 sandbox 里执行工具调用，读写 workspace 里的文件2.8 把 Agent Loop 中间产生的状态做成 checkpoint，保存到 KV2.9 最后把结果返回给用户
-
任务结束之后，系统会通过惰性检查，关闭那些不活跃的 sandbox。 在关闭之前，会先把 sandbox 里 workspace 的文件同步回对象存储。
所以这套架构可以拆成两层来看。
计算层是 pod + sandbox。
pod 负责承接请求和做水平扩容，用来提升并发能力。
sandbox 负责执行具体工具调用，把高风险操作隔离出去。
如果 sandbox 用的是 e2b 这类方案，启动速度可以做到秒级。
如果再提前维护一个 sandbox 池，还可以进一步提升并发稳定性和容错能力。
存储层则是 KV + DB + Vector DB + OSS 的组合。
KV 存热状态，DB 存任务和对话记录，Vector DB 存长期记忆，OSS 存文件和产物。
这样一拆，Agent 就不再依赖某一个固定 pod 或某一台机器。
计算资源可以按需启动，存储资源也能长期沉淀。
但这套方案也不是银弹。
它最大的瓶颈之一是 IO 延迟。
因为很多东西不再在本地磁盘里了，而是要在 DB、KV、向量数据库、对象存储之间来回读写。
同时，更大的挑战其实是分布式多副本场景下的数据一致性。
当多个 pod、多个 sandbox、多个任务同时操作同一批用户资料、记忆和工作产物时，怎么避免状态错乱、文件覆盖、记忆冲突，就是很关键的问题。
所以这里一定要设计好锁机制，也要谨慎处理负载均衡策略。
否则表面上看，Agent 确实跑起来了。
但一旦进入多用户、多任务、长时间运行的真实场景，各种隐藏问题就会冒出来。
我觉得这篇架构分享最有意思的地方，不是它讲了某个具体技术栈，而是它把 Agent 这件事从“模型调用”拉回到了“系统工程”。
一个真正可用的 Agent，不只是把 prompt 写好，然后接几个 tool 就完事了。
它背后其实要处理很多工程问题：
提示词放哪里？记忆怎么存？文件怎么同步？工具怎么执行？sandbox 怎么隔离？任务挂了怎么恢复？多个副本同时跑怎么保证数据一致？
本地 Agent 看起来简单，是因为它天然把存和算混在一起。
云端 Agent 看起来复杂，是因为它必须把存和算拆开，再用一套更工程化的方式重新组织起来。
这也是为什么很多 Agent Demo 看起来非常丝滑，但真要做成一个稳定的云端产品，复杂度会突然上一个台阶。