Yifeng "Evan" Wang

聊一聊 Agent 的存算分离架构设计👇 一个有灵魂，有记忆的 Agent，一次任务的生命周期包括以下步骤 1. 用户输入 query（text + files） 2. Agent 读取提示词文件（soul.md，identify.md，user.md 等） 3. Agent 读取可用的工具和技能（tools，skills 等） 4. Agent 读取记忆（memory.md，memory_search 查询） 5. Agent 构建上下文（prompt + tools + memory + query） 6. Agent 进入 Loop（LLM 调用 → 工具调用 → 观测 → 再推理） 7. Agent 交付结果（Artifacts） 什么需要存：提示词文件，工具和技能，对话记录，交付产物 什么需要算：上下文拼接，LLM 调用，工具调用 简单表示这个过程 fn(query, agent runtime) = artifacts 我们可以把 agent 运行方式简单分为三类 1. 本地裸机运行 2. 本地带沙盒（sandbox）运行 3. 云端多副本运行 --- 1. 本地裸机运行，是 OpenClaw 之类 Agent 的常见模式。Agent 提示词文件、skills，对话记录（sessions）全部存在本地磁盘，Agent 执行任务时，会在固定 workspace 目录下运行，用户上传的文件、Agent 产出的文件全部落在同一个 workspace，Agent Loop 完全依赖本地文件构建上下文和执行工具调用，存跟算是一体的。 这种模式好处是足够简单，避免了额外的文件挂载开销，弊端在于安全性，比如 Agent Loop 执行了一个 exec(rm -rf /) 工具调用，很容易对宿主机产生破坏 2. 本地带沙盒运行，是 Codex 之类的 Agent 的常见模式。主要解决两个问题。一是防止 Agent 越权操作，提高安全性；二是解决宿主机的依赖缺失导致工具调用异常的问题。 Agent Loop 执行工具调用时，涉及到敏感操作或者有外部依赖时，把宿主机的 workspace 目录挂载到 sandbox，在 sandbox 执行工具调用，输出产物自动同步到宿主机的 workspace 目录 这种模式下的存算分离，只在工具调用环节引入 sandbox 来动态计算，存储主要靠宿主机的文件系统 3. 云端多副本运行，是 Manus 之类的工具型 Agent 的常见模式。主要特点是多租户，多任务，长时间运行 像 genspark claw，kimi claw，max claw 之类的托管版小龙虾，本质上是在云端多副本运行的助理型 Agent，每个用户有独立的提示词文件，动态安装的 skills，需要长期记忆 这类 claw 托管服务，最简单的实现方式是搭建一套 k8s 集群，在每个 pod 部署一套 Agent 框架（OpenClaw，harmes 等），通过 pvc 挂载云硬盘，实现对用户资料的持久化存储。通过负载均衡策略把每个用户的请求路由到固定的 pod，在同一个 pod 做 Agent Loop，存算是一体的，每个 Agent 有独立的运行空间。这种方案隔离性很好，不好的地方在于 pod 需要常驻，运行成本很高，难以规模化 --- 云端 Agent 需要规模化（scalable），必然要结合 serverless 架构做存算分离。计算层依赖 k8s 集群的调度机制动态扩缩容，水平扩展 Agent 网关的并发处理能力 存储层结合 Agent 的运行生命周期，不同阶段的产物用不同的存储方案，主要分为四种 1. 热状态。Agent Loop 的 step，plan，游标等状态，用 kv（redis）来存，高性能，低延迟，用于异常重启后的断点恢复 2. 对话和任务记录。在任务完成后用关系型数据库（postgres）来存 3. 长期记忆。基于对话/任务记录做摘要，提取成记忆，用向量数据库（pgvector，milvus）来存 4. 工作产物。包括用户上传的文件，Agent 输出的文件，系统内置的 tools，动态创建的 skills 等，用对象存储（s3，oss）来存 --- 以 FastClaw 为例，演示基于存算分离架构的云端 Agent 的运行过程👇 1. 一套 k8s 集群，日常 2 个 pod，部署 fastclaw gateway，接收用户请求 2. 负载均衡把用户请求路由到其中一个 pod，Agent 开始计算逻辑： 2.1 从 db 读取提示词文件（soul，identity，user） 2.2 初始化 pod 内一个临时目录作为 workspace 2.3 初始化 sandbox，挂载 workspace 2.4 从对象存储下载用户资料和系统 skills 到 workspace 2.5 调用 memory_search 工具，从向量数据库查询记忆 2.6 拼接上下文，调用 llm，解析工具 2.7 在 sandbox 执行工具调用，读写 workspace 内的文件 2.8 把 Agent Loop 过程中的状态设置为 checkpoint，保存到 kv 2.9 Agent 输出结果给用户 3. 通过惰性检查，把不活跃的 sandbox 关闭，关闭前把 sandbox 内 workspace 的文件上传到对象存储 以上的存算分离架构，计算层依赖 pod + sandbox，pod 水平扩容支持并发调用，sandbox 承接少量的工具调用，使用 e2b 作为 sandbox 可以做到秒级启动，构建 sandbox 池可以提高并发容错；存储层依赖 kv + db + vector db + oss 的组合使用，瓶颈在于 io 延迟 这套架构最大的挑战在于分布式多副本场景下的数据一致性，需要合理使用锁机制和负载均衡策略。 理解了这套架构，再去看 Manus，Claude managed agents 的实现，就很好理解了。 篇幅有限，不能详述细节，欢迎留言讨论。🤗

我挺认同Kun Chen的看法的，他这次的判断抓住了核心，而且说得挺准。 事情是这样的：Anthropic本来打算从今天开始，把用Claude Pro或Max订阅去跑Agent SDK、claude -p这种程序化调用、GitHub Actions，还有第三方agent工具的额度单独拆出来，改成独立的计费，用完就得按API价格另外付钱。这对很多开发者来说简直是晴天霹雳，尤其是那些把Claude当主力跑自动化工作流的人。 结果就在今天，他们突然发邮件说这个改动先暂停了，什么都不变，订阅额度依然能继续被这些工具正常消耗。Kun Chen自己做的那个“/no-mistakes”工具，也就能继续顺畅地用下去。他兴奋地说这是个好信号，我觉得没错。 为什么说这是积极变化呢？因为这说明Anthropic在认真听开发者的反馈，没有一意孤行地只保护自己家的交互式产品。他们原本可能想把Claude打造成一个“超级应用”，不愿意让重度用户和第三方工具把服务器资源薅得太狠。但现在暂停这个计划，其实等于默认让订阅继续补贴更广阔的生态，让大家能更自由地基于Claude做创新。这对整个开发者社区是实打实的利好，也显示他们正在从“封闭应用”往“开放基础设施”的方向调整。 当然，他最后也说“still have more to do to gain back my trust”，这点我也很赞同。 Anthropic这次快速掉头是好事，但之前政策反复确实伤过不少人的信任。以后能不能说到做到、给开发者稳定的预期，才是最关键的。 总之，这件事对正在用Claude做agent开发的同学来说，是个可以松口气的好消息。短期内继续放心投入是相对安全的，值得继续观察他们下一步怎么平衡容量和生态。

我觉得国人很大的一个问题是，缺乏生活追求，当然也许他们的生活追求在我理解之外。我身边有些朋友，明明财务自由，还在追寻一份工作，我说的不是那种有自己的事业不放手，或者和朋友们一起搞点理想的事业，这种我能理解。我说的是，继续去找份职场工作，哪怕只是一种生活惯性。有一个朋友连续创业成功企业卖出套现n个亿，然后找了一份国企工作上班去了，护照上缴的那种，我就一直理解不了他图什么，我说你是看中人家前台了还是秘书了，总要有个目标吧，人家说真没有，就是没有工作不踏实。 还有一个大学宿舍同学，之前在不同互联网巨头做技术中层，资历老，年头久，虽然管理级别不高，但股票套现身价比我高不少，孩子也上大学了，没啥可操心的了吧。然后跟我吐槽说最近下课了，50岁不好找工作，我说你跟我一起出去浪不好么，为啥还要找工作，就觉得在家不踏实。 身边好像不少这种，资产相当不错，人特别宅，没啥爱好，赚了钱就是养家，有精力就鸡娃，孩子也都上大学了（有的都毕业有工作了），不知道干嘛，不上班就难受，上班也不知道图啥。 然后有这种人没事还说羡慕我的生活，我说你羡慕个球啊，你要是真喜欢到处浪不就是一念之间的事情。

史称 419 day