"Agent 进入生产环境的下半场，比拼的不再只是模型，更是 Agent 与上下文之间的关系是否被系统性组织起来。ContextBucket 的使命，是让 Agent 的记忆与工作区长在同一个底座上——记得住、找得到、带得走。"
—— ContextBucket 产品愿景
背景与挑战：Agent 进入生产环境后的上下文困境
过去一年，Agent 正在从聊天 demo 走向生产系统：进入研发流水线写代码、嵌入运营平台做分析、接入客服后台处理工单。它们不再是开几轮对话就关掉的玩具，而是要在终端、协作工具和企业系统里长期运行的常驻进程。随之被推到台前的是一个看似基础、却长期被绕开的问题：Agent 的上下文——它记住的事实、它操作过的文件、它产出的中间结果——应该存在哪里？
过去一年的工程实践基本是「拼装」：记忆挂到向量库或 Mem0，文件落本地磁盘或对象存储，多租隔离自行实现一套。在 demo 阶段可以跑通，规模化后则同时暴露三类问题：记忆随会话和实例丢失、文件无法跨端共享、权限与审计缺失。维护这条上下文链路的工程量，正在反超 Agent 业务逻辑本身。根因不在某个组件，而在于 Agent 的「脑子」和「手」被强行拆在了两套独立的存储体系里，具体表现为三类断层：
💡 记忆断层
存在向量库或本地 SQLite，换设备就丢、窗口压缩后召回失真；只用向量检索"既不准也不省"——召回噪声大，关键决策被相似讨论淹没。
💡 工作区断层
代码 / 配置 / 项目文档 / 运行产物全在本地磁盘，换机器就没，团队无法共享；自建 FUSE + 对象存储的拼装方案运维成本高。
💡 治理断层
多 Agent 跑同机互相串数据；多用户、多团队没有原生隔离；迁移、审计、配额全靠人肉拼装，开发者最后不是在做 Agent，而是在维护一条上下文管道。
换台电脑，本地的代码和配置就丢；
几个同事各跑各的 Agent，记忆和文件散落各处，复用从无谈起；
同时跑多个 Agent 时，记忆互串、文件互相覆盖更是家常便饭。
三类断层叠加，使 Agent 的记忆和工作区始终无法收敛到同一个底座——这正是 ContextBucket 试图回答的问题。
产品能力：一个底座，两种能力
ContextBucket 是火山引擎提供的托管服务，在同一套服务层内提供文件存储、记忆管理、混合检索、多租隔离与 Serverless 弹性。Agent 侧通过 ContextBucket Plugin 一键接入即可获得全部能力，无需分别对接向量库、对象存储与记忆中间件；每个 Agent 或用户对应一个 ContextSet(逻辑隔离单元)，记忆与工作区文件在同一 ContextSet 下共享凭证与端点。下方列出以 OpenClaw 为例 ContextBucket 替代的全部组件：
下图给出 ContextBucket 的整体架构，自上而下分为接入层、能力层与存储层：
记忆：记得准、找得到、带得走
记得准：智能提取，只记事实
OpenClaw 的对话流里夹杂着大量过程噪声——反复讨论、方案对比、代码试错、被否决的提案。若这些内容被等量沉淀进记忆库，污染不可避免，检索精度也会随之下降。
ContextBucket 在写入侧做一次过滤：仅自动识别并提取对话中的关键事实——需求决策、技术结论、用户偏好，过程性的方案讨论、被否决的提案、代码试错不再等量保存；「昨天」「上周」一类相对时间表达进行特殊处理，避免后续召回时产生歧义。
💡 举个例子：
你让 OpenClaw 帮你重构一个微服务，聊了整整两天——讨论了三种接口拆分方案，权衡后选了按领域拆分；评估了 gRPC 和 REST，最终决定核心链路用 gRPC；定了错误码规范；确认了灰度按流量比例滚动发布。
没有智能提取的话，所有对话内容都会被存成记忆，下次你问"灰度策略怎么定的"，检索出来的可能是讨论过程中的某段代码片段或某个被否决的方案。有了智能提取，存下来的只有最终结论。
找得到：多路检索，精准召回
存得准只是第一步，真正决定可用性的是召回精度。ContextBucket 采用向量 + BM25 双路检索 + Rerank 重排把决策结论排到前列；新会话首次交互时会额外触发一轮宽泛召回，避免关键上下文因提问模糊而被遗漏。
💡 例如你问 OpenClaw"上次决定核心链路用 gRPC 的依据是什么"。纯向量检索可能返回讨论 gRPC 时的多段对话，其中夹杂着性能担忧、学习成本质疑、对比示例代码——但真正的决策只有一段。混合检索把关键词、语义和排序合在一起看，让 Agent 拿到的是结论，而不是一堆沾边的过程。
带得走：服务端存储，易迁移，超大容量，低成本
记忆数据存储于 ContextBucket 服务端，而非 Agent 所在的本地磁盘。换机器、换环境，只要用同一个 user_id 接入，历史记忆即刻可用；容量也不再受本地窗口约束，按需检索、按需注入即可。在 Locomo 评测中，这一存储形态对应的端到端收益是 LLM 输出 Token 下降 80%、计费 Token 下降 43.2%。
举个常见场景：你在公司电脑上用 OpenClaw 做了一周项目调研，积累了大量技术决策和需求理解。周末想在家里的电脑上继续，过去要么手动复制记忆文件，要么从头再来；现在两台机器装上插件、共用同一个 user_id，记忆自动同步，回到家直接续上。
团队场景同理：成员各跑各的 Agent，但项目相关的技术决策、架构约定、编码规范共享同一份记忆，不必每次重复交代背景。
工作区：文件可持久化，工作流不断
文件远端持久化，不随本地环境丢失
只解决记忆还不够。OpenClaw 的工作环境里同时存在代码、配置、项目文档、运行产物——这些原本散落在本地磁盘，换台机器即丢失，团队协作也缺乏共享路径。
ContextBucket 在同一个 ContextSet 内同时支持 memory 与 workspace 两种场景——创建时声明 scenes： ['memory'， 'workspace']，记忆数据与工作区文件即可共享同一套凭证与端点，无需再分别对接记忆服务与文件存储。
工作区分为两个目录，兼顾协作与性能：
💡 你让 OpenClaw 写了一个数据处理脚本，跑完结果保存在工作区。第二天电脑重启，文件还在。换台电脑，重新挂载工作区，文件还在。同事要复用你的脚本，从共享目录直接拿，不用你手动传。
工作流跨 Agent 无缝迁移
ContextBucket 通过 FUSE 挂载将工作区目录映射为本地文件系统，代码生成、文件编辑、项目构建等操作沿用本地路径语义，Agent 侧无需感知底层差异；实际数据则持久化在 ContextBucket，跨机器只需重新挂载即可续接。
下图展示了"记忆 + 工作区"同源底座下的跨机器续写流程：
隔离则在两个层次同时生效：底座侧提供租户级隔离，Plugin 侧叠加 Agent 级记忆隔离——主 Agent、命名 Agent、子 Agent 各自拥有独立的记忆命名空间，互不串扰。
💡 例如同时跑研究、编码、测试三个 Agent：研究 Agent 的记忆不会污染编码 Agent 的上下文，编码 Agent 生成的文件也不会覆盖测试 Agent 的产物。需要跨 Agent 查询时，通过 agentId 参数显式访问即可。
工作区也能多路召回：语义 + 关键词 + 元数据
工作区并非冷存储——文件存在远端，Agent 仍需在写代码、改配置、查文档时做到问得到、找得准。
ContextBucket 将记忆侧的检索能力下沉至底座，工作区文件直接复用同一条召回链路，仅把第三路替换为更贴合文件场景的路径与元数据匹配。
💡 三路并行召回
向量检索：按语义找到功能相近的代码段、文档段
BM25 关键词：精准命中函数名、配置项、错误码
路径 / 元数据匹配：按目录、文件名、修改时间定位
💡 Rerank + 按需注入
三路结果合并后由 Rerank 统一重排
按 Token 预算只注入最相关的若干片段,而不是整个文件灌进上下文
大仓库、长文档也能稳定命中关键内容
💡 例如工作区里有上百个 yaml 配置和几十万行代码。你问"灰度发布的流量比例配置在哪"，纯路径匹配可能漏掉换过名字的文件，纯向量检索又会被一堆"看起来相关"的注释干扰。多路召回 + Rerank 让命中的就是那一行配置，而不是十个相似文件。
对外接口与记忆侧保持一致：工作区文件和记忆事实可以在同一次检索请求里联合返回，Agent 不必区分"该问记忆还是该问文件"。
接入形态：一键安装，一行配置接入
接入 ContextBucket 只需两步——一键安装与验证插件状态。向量库对接、FUSE 挂载、多租隔离均在 Plugin 安装期完成，Agent 侧无需任何额外改造。
执行以下命令完成安装：
curl -fsSL https：//context-bucket-cn-beijing.tos-cn-beijing.volces.com/context-bucket-bundle-latest.tar.gz \ | tar xz -C /tmp \ && bash /tmp/stage/install.sh \ --backend context \ --endpoint tos-control-cn-beijing.volces.com \ --access-key-id '' \ --access-key-secret '' \ --region cn-beijing \ --account-id '' \ --context-bucket-name 'context-bucket-poc' \ --context-set-name 'csn-poc' \ --secure false \ --force
把 、、 替换为火山引擎控制台获取的真实凭证；context-bucket-poc 与 csn-poc 可按实际项目命名。
安装完成后，执行以下命令验证插件是否正确注册：
openclaw plugins list
列表中能看到 ContextBucket 相关插件且状态正常，即视为安装成功。如果列表为空或状态异常，回看 install.sh 末尾输出，常见原因是 AK/SK 错误、网络不通、或 bucket 不在该 account 下。
性能验证：Locomo 长程对话评测
Locomo 是学术界常用的长程多轮对话评测集，包含跨会话的事件、偏好、关系等记忆类问题，专门用于衡量 Agent 在长周期任务中的记忆能力。测试中，OpenClaw 基线版本与接入 ContextBucket Plugin 的版本使用相同模型、相同问题集，区别仅在于记忆与工作区的存储方案。
💡 结论解读：回答正确率从 16.45% 跳到 64.14%，提升近 48 个百分点——核心原因是记忆不再全量灌入上下文，而是经过提取 → 检索 → 筛选后按需注入。LLM 输出 Token 减少 80%，计费 Token 总量减少 43.2%，成本也随之下降。
适用场景：哪些 Agent 真正需要它
并不是所有 Agent 都需要 ContextBucket。它最适合那些已经从单机 Demo 走向长期服务、多端协作、多租户运营的系统——这类 Agent 里，上下文不是一次性消耗品，而是必须被沉淀、复用和治理的核心资产。下面四种是最典型的形态：
💡 研发 Agent
代码、设计文档、依赖配置、CI 结果、排障记录长期共存于工作区；架构决策、Code Review 结论、踩坑经验沉淀为团队记忆。跨设备接续开发、跨成员复用经验是刚需。
💡 办公 / 流程 Agent
会议纪要、周报、项目背景、审批材料、历史决策需要跨会话延续。每次重新交代背景成本极高，稳定的长期上下文直接决定 Agent 能否真正接管流程。
💡 终端助手 / 私人 Agent
用户偏好、常用资料、历史任务和本地文件需要长期积累。手机、电脑、车机多端切换时，记忆和工作产物不能断层，否则"私人助理"就只是"一次性问答"。
💡 企业 Copilot 平台
多个 Agent、多个团队、多个租户共存时，权限隔离、配额治理、可审计性会比单 Agent 体验更早成为瓶颈。Context Bucket 的千万级原生隔离正是为这一阶段设计。
💡 这四类场景的共同特征是：上下文规模大、生命周期长、跨端跨人协作、需要审计与隔离。一旦 Agent 进入其中任一场景，记忆与工作区便不再是可选项，而是绕不开的底层依赖。
总结与展望
ContextBucket 以一个托管底座同时收敛了 Agent 的三类断层——记忆随会话消失、工作文件无法跨实例持久化、多 Agent 共用存储下的权限与审计混乱。在 OpenClaw 上的实测结果印证了这一收敛带来的端到端收益：
💡解决记忆断层
向量 + BM25 + Rerank 多路检索
服务端持久化，跨机器带得走
正确率 16.45% → 64.14%（↑ 47.69%）
💡 解决工作区断层
FUSE 挂载，接近本地文件系统体验
语义 + 关键词 + 元数据多路召回
工作流跨 Agent / 跨实例无缝迁移
💡 解决治理断层
ContextSet 千万级原生多租隔离
统一凭证与接入点，审计链路清晰
Serverless 零运维，5 分钟跑通
底座层的核心问题已经解决，接下来 ContextBucket 的演进将沿两个方向展开：
💡 更智能检索
引入图谱关联与时序感知，让 Agent 在跨会话、跨文件的大仓库中精准命中上下文；记忆侧与工作区侧检索能力对齐，一次提问同时捞回相关事实与相关文件。
💡 更开放生态
扩展 Plugin 生态，支持更多 Agent 框架（LangChain、Hermes等）一键接入；开放 ContextSet API，让第三方工具直接读写同一份上下文。
