"Agent 进入生产环境的下半场，比拼的不再只是模型，更是 Agent 与上下文之间的关系是否被系统性组织起来。ContextBucket 的使命，是让 Agent 的记忆与工作区长在同一个底座上——记得住、找得到、带得走。"
—— ContextBucket 产品愿景
背景与挑战：Agent 进入生产环境后的上下文困境
过去一年，Agent 正在从聊天 demo 走向生产系统：进入研发流水线写代码、嵌入运营平台做分析、接入客服后台处理工单。它们不再是开几轮对话就关掉的玩具，而是要在终端、协作工具和企业系统里长期运行的常驻进程。随之被推到台前的是一个看似基础、却长期被绕开的问题：Agent 的上下文——它记住的事实、它操作过的文件、它产出的中间结果——应该存在哪里？
过去一年的工程实践基本是「拼装」：记忆挂到向量库或 Mem0，文件落本地磁盘或对象存储，多租隔离自行实现一套。在 demo 阶段可以跑通，规模化后则同时暴露三类问题：记忆随会话和实例丢失、文件无法跨端共享、权限与审计缺失。维护这条上下文链路的工程量，正在反超 Agent 业务逻辑本身。根因不在某个组件，而在于 Agent 的「脑子」和「手」被强行拆在了两套独立的存储体系里，具体表现为三类断层：
💡 记忆断层
存在向量库或本地 SQLite，换设备就丢、窗口压缩后召回失真；只用向量检索"既不准也不省"——召回噪声大，关键决策被相似讨论淹没。
💡 工作区断层
代码 / 配置 / 项目文档 / 运行产物全在本地磁盘，换机器就没，团队无法共享；自建 FUSE + 对象存储的拼装方案运维成本高。
💡 治理断层
多 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 写了一个数据处理脚本，跑完结果保存在工作区。第二天电脑重启，文件还在。换台电脑，重新挂载工作区，文件还在。同事要复用你的脚本，从共享目录直接拿，不用你手动传。
ContextBucket 通过 FUSE 挂载将工作区目录映射为本地文件系统，代码生成、文件编辑、项目构建等操作沿用本地路径语义，Agent 侧无需感知底层差异；实际数据则持久化在 ContextBucket，跨机器只需重新挂载即可续接。
下图展示了"记忆 + 工作区"同源底座下的跨机器续写流程：
隔离则在两个层次同时生效：底座侧提供租户级隔离，Plugin 侧叠加 Agent 级记忆隔离——主 Agent、命名 Agent、子 Agent 各自拥有独立的记忆命名空间，互不串扰。
💡 例如同时跑研究、编码、测试三个 Agent：研究 Agent 的记忆不会污染编码 Agent 的上下文，编码 Agent 生成的文件也不会覆盖测试 Agent 的产物。需要跨 Agent 查询时，通过 agentId 参数显式访问即可。
工作区并非冷存储——文件存在远端，Agent 仍需在写代码、改配置、查文档时做到问得到、找得准。
ContextBucket 将记忆侧的检索能力下沉至底座，工作区文件直接复用同一条召回链路，仅把第三路替换为更贴合文件场景的路径与元数据匹配。
💡 例如工作区里有上百个 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 是学术界常用的长程多轮对话评测集，包含跨会话的事件、偏好、关系等记忆类问题，专门用于衡量 Agent 在长周期任务中的记忆能力。测试中，OpenClaw 基线版本与接入 ContextBucket Plugin 的版本使用相同模型、相同问题集，区别仅在于记忆与工作区的存储方案。
💡 结论解读：回答正确率从 16.45% 跳到 64.14%，提升近 48 个百分点——核心原因是记忆不再全量灌入上下文，而是经过提取 → 检索 → 筛选后按需注入。LLM 输出 Token 减少 80%，计费 Token 总量减少 43.2%，成本也随之下降。
并不是所有 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，让第三方工具直接读写同一份上下文。
粤ICP备14082021号
免费POC，
零成本试错
