【学习笔记】OceanBase × MiniMax × 行业伙伴

9 月 12 日，由 OceanBase 和 MiniMax 联合主办的“面向生产级 Agent seekdb × PowerContext 技术专场”在上海外滩大会收官。

专场聚焦 AI 编程、长文本与智能体三条技术主线，汇聚来自 OceanBase、MiniMax、Nowledge Mem、EverMind 的近十位技术专家，围绕上下文工程的四大核心议题展开深度分享，并正式发布 PowerContext 1.0。

左右滑动查看更多

作为一家 AI 数据平台公司与 AI 公司的跨界联合，专场分享内容覆盖上下文架构演进、多模态数据治理、Agent 工程化实践与跨 Harness 标准化四大方向，为开发者社区提供可复用的工程方法论。

欢迎大家关注 OceanBase 社区公众号 “老纪的技术唠嗑局”。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~

作为 OceanBase 开源负责人，封仲淹长期深耕分布式数据库与 AI 基础设施的交叉领域。

本次分享，他以“生产级 Agent 上下文的本质是数据系统”为核心论点，完整披露 PowerContext 从 Memory 走向 Context Runtime 的三代技术演进路径。

OceanBase 开源负责人封仲淹

封仲淹引用 Gartner 报告指出，未来三年内 AI 将渗透软件行业的 80% 以上，远超报告中所预测的 40%。

在此背景下，Agent 上下文工程面临三类典型痛点：

上下文孵化：当窗口达到百万级 Token 时，注意力易被分散到无关信息；同时 Token 消耗随对话轮次线性增长，成本急剧上升；上下文冲突频发，需对编排与权重做精准控制。

多 Agent 协同：当设计用 Claude Code、编码用 MiniMax、Review 用 Codex 时，三类 Agent 如何实现上下文传递成为关键挑战。

上下文丰富性：故障诊断场景需同时纳入日志、代码（sourcing）、工单系统、RAG 历史、设计文档、CI/CD、测试系统等多源数据源。

封仲淹将 PowerContext 的演进划分为 Memory、Power Memory 和第三代（上下文协同）三个时代。

Memory 时代聚焦记忆的存储与查询，本质是基础设施；Power Memory 时代实现记忆的自动化定制，并提供共享与私有两种模式；第三代（上下文协同）：从 Agent Memory 升级为 Agent Context，更关注复杂任务场景下多种上下文的协同管理。

PowerContext 采用分层架构，自顶向下依次为：

应用层：覆盖 MiniMax Code、Claude Code、LangChain 等 Agent 产品；

适配层（Adapter）：通过 SDK 包或 middleware（如 LangChain 用 middleware 接入）插入到各 Agent；

PowerContext Server：支持 MCP、Local、Server 三种接入模式；

Context Runtime + 数据底座：底层数据可选用 OceanBase、SQL Server、SQLite、PostgreSQL 等。

Source 层覆盖对话、文档、代码、人员经验、知识库、工单系统、第三方博客、设计文档等多元数据。

其中，制品层提供原子记忆、聚合记忆、主题记忆、个人/团队分享记忆等形态。整套框架嵌入 trigger 机制，当代码从 0.2 发布到 1.0 时，trigger 驱动 Source 根据 policy 重新生成制品，经人工与智能化双重复核后形成可导出版本或失败记录。

目前，PowerContext 支持多版本管理，从默认版本出发，按补充边界生成新版本，最终合并形成更新版本，并支持回滚到老版本。该机制对 Agent 的可观测与可评估至关重要，便于不同策略与 Prompt 的 A/B 对比。

现场，封仲淹公布了 PowerContext 在 SWE Benchmark 上的测试数据：

GPT 单独解答完成率约 60%
加上 Codex 后提升至 82%
叠加 PowerContext 后达到 86%

PowerContext 在上下文编排与权重分配上的优化（包括解决 Codex 上下文 compact 时丢失 solution 的问题），是任务完成度提升的关键。

OceanBase seekdb 1.4 内核优化

内存压缩：稳态内存消耗从 600MB 降至 160MB（优化幅度 73%）

进程升级：数据库内核从独立数组进程升级为共享后台进程，支持多 Agent 通过共享机制相互共享 Context

Fork Table：提供沙箱与快照能力，可基于同一基线拉出多个分支进行 Prompt 对比测试，保留原始数据的同时让 Agent 安全试错

应用场景扩展

内存压缩与进程升级使 OceanBase seekdb 1.4 在嵌入式场景具备落地条件。

稳态内存由 600MB 降至 160MB，使数据库可直接运行在个人 PC、手机 APP 等资源受限终端；进程模型的演进则使多 Agent 能够在端侧共享同一个 Context Runtime，无须额外启动独立的数据库实例。

在此基础上，OceanBase seekdb 1.4 可覆盖以下端侧场景：

具身智能：终端本地运行的 Agent 集群，需共享 Context Runtime 但受限于单设备算力

机器人本体：机器人本体的状态、感知与决策日志需要持久化与多 Agent 共享，进程隔离不再适用

个人 PC：本地的 Coding Agent、办公 Agent 需要长时间运行的后台 Context 服务

手机 APP：受限于内存与电量的端侧 Agent，需极低资源开销的嵌入式数据库

Fork Table 提供的沙箱与快照能力进一步支撑端侧场景下的安全试错与版本回溯，使 Agent 能够在不污染主数据的前提下进行 Prompt 对比与策略验证。

现场开发者们合影

MiniMax 架构师负责人冯雯在本次演讲中，系统阐述了在多模态数据规模爆炸背景下，如何构建可工程化的上下文数据管线，并介绍了 MiniMax Code 在多模工作台与记忆管理上的最新进展。

MiniMax 架构师负责人冯雯

冯雯首先介绍了 MiniMax Code 的近期进展：

多模工作台：新增无限画布，支持用户对截图或视频中需要迭代的部分进行标注，更高效地加载上下文；

记忆管理：长期记忆与短期记忆支持可下载与调整，用户可主动管理；

长任务可持续性：结合上下文压缩与 PowerContext 等开源工具，灵活调整窗口预算，支持跨对话、跨 Agent 的交付包设计。

冯雯提出，上下文治理需贯穿数据全生命周期：

入库：保留原件、版本与权限，针对截图、会议记录、代码、日志、检索结果等不同模态设计差异化的检索投影与定位信息

解析：覆盖 OCR、ASR、视觉理解等不同解析方式，涉及分块与混合检索；需建立原件与解析内容的 Mapping 关系

治理：处理重复内容、敏感字段、权限边界等问题，关联检索结果与权限判定

检索阶段的四个关键考量

身份与授权：识别用户身份后，判断其是否有权限获取对应信息

版本与演进：单轮 Coding 任务难以一次到位，需在多轮迭代中管理版本与演进

保留与删除：在跨对话、跨 Agent 的删除场景下保持信息一致性

解析质量：解析工具的准确率直接影响整体检索质量

多路检索与数据底座

冯雯建议在多路检索场景下使用 OceanBase 作为统一入口：OceanBase 既能存储原始数据，也支持文本与向量，并内置解析器。

在对比 MiniMax Code、Claude Code、Codex、DeepSeek Harness 的多模接入方式后，主流方案仍以文件系统与披露方式为主。

冯雯将生产级 Agent 的上下文抽象为四个核心组成部分：

常驻约束：用户的当前有效指令（最高优先级），含目标、权限边界、长期使用习惯

任务状态：Agent 在持续迭代中的当前任务状态、已解决问题、验证结果、阻塞点、下一步行动

检索信息：来自多模态数据治理的检索结果，是上下文准确率的核心保障

长期记忆：用户偏好、过往项目经验、个人 spec 等 skill 类资产

冯雯给出工程化的上下文预算公式：可用输入预算 = 整体窗口容量 - 输出预留 - 安全余量

当预算不足时，需对上下文做摘要或压缩，区分「仅保留片段」与「必须全文保留」的差异化策略。

压缩的三大原则

长输出文件化：完整日志与输出转为文件存储，仅在检索到相关内容时调用工具结果定期清理：清理重复内容与被历史版本覆盖的过期数据结构化摘要：对最终结果做结构化摘要，便于后续检索

Agent Team 实践

在 MiniMax 内部的 Agent Team 实践中：Leader 只关注各任务的状态与执行结果是否满足要求；Worker 在自身上下文内独立执行，不感知其他 Worker 的细节；Verify 基于 Worker 的结果进行验证，反馈不合格项。

各角色的上下文按职责分工隔离。冯雯表示，MiniMax 已接入 PowerContext，推荐开发者在自身任务流程中接入 PowerContext 进行上下文管理。

PowerContext contributor 秋梵专注于开发者工具链与 Agent 框架的设计与实现。

本次分享聚焦“如何让 Agent 越用越聪明”这一核心命题，通过一个像素游戏的可视化演示，完整呈现 Source → Experience → Skill 的三段式进化路径。

PowerContext contributor 秋梵

秋梵构建了一个像素世界的小游戏：让 Agent 在地图上搭桥过河、连接电线、点亮营地灯。完成第一步后，新开多个地图与新 Agent，验证前序经验与技能是否可被沉淀与复用。

PowerContext 在此过程中承担 Source 沉淀、Experience 提炼与 Skill 跨场景调用的关键角色。

Source 保留 Agent 的实际动作、方式与结果，作为可追溯的证据链；Experience 基于 Source 自动整理任务经验，生成「待审核」的经验候选；经验需经人工审批后转为正式可用资产；基于正式经验生成「待审核」的技能候选，经审批后转为正式 Skill 供其他 Agent 调用。

PowerContext 支持 Skill 修订。当新 Agent 在新场景下使用 Skill 后，会留下使用记录作为新 Source。用户提出修订要求后，PowerContext 根据最新 Source 重新生成修订候选，同样需经审批后方可升级为新版本（如 R1 → R2）。整个修订链路完整可溯源。

除 Experience 与 Skill 外，PowerContext 还提供 memory、handoff、scope 等能力，通过 scope 进行项目范围的分类管理。秋梵强调，Agent 与 Skill 的所有生成内容均需经过人工审批方可成为可信资产。

针对开发者入门，秋梵给出三步实操路径：

第一步：安装 PowerContext CLI
第二步：启动 PowerContext Server
第三步：通过 setup 将当前使用的 Agent 与 PowerContext 进行配置

注：具体操作可参考 PowerContext 官网教程

秋梵在分享最后宣布 PowerContext 1.0 正式发布，并介绍了官网、GitHub 与他和社区共建的 Apocalypse 101 实践教程网站，欢迎开发者反馈与共建。

注：PowerContext GitHub：

https://github.com/oceanbase/powercontext

本场圆桌由 OceanBase PowerContext Maintainer 尚卓燃主持，邀请 Nowledge Mem CTO 王维真珍、盛大 EverMind 开源生态负责人艾略特、OceanBase PowerContext Maintainer 傅榕锋三位嘉宾同台，围绕上下文工程的核心议题展开深度对谈。

话题一：最关键的产品特性

上下文工程的核心能力可归纳为三个层次 —— 记忆体的自动生成与可审计、跨实体的共享记忆、从 Memory 升级到 Context 的完整 story 视角。

三类产品分别对应「记忆的生产」「记忆的分发」「上下文的协同」三个工程层级。

其中，记忆体的自动生成，基于用户 Session 与日常文档自动生成经验、memory 与决策，每个决策关联原始证据形成可审计能力；

跨实体的共享记忆以自信化、主动性、多模态为支柱，实现跨 Agent、跨 Session、跨 Device、跨 Harness 的同步分发；

完整 story 视角：从 Power Memory 升级到 PowerContext，更积极地介入 Context 工作，关注 Context 的组成而非仅记忆的工程方式

话题二：如何管理自己的上下文

上下文管理的工程化手段可分为三类 —— 工具接入、项目级约定、跨 Harness 共享索引。三者协同覆盖「Engine 集成」「项目规范」「跨 Harness 互通」三个维度：

工具接入：通过插件或中间件将上下文基础设施接入到 Claude Code、Codex 等 Engine；提供 MCP、Local、Server 等多种模式；

项目级约定：以 CLAUDE.md 或 agent.md 等文件保存项目与团队约定，作为 Engine 启动时的注入内容（因索引非全文，需在启动时直接加载）；

跨 Harness 索引：在 MiniMax 应用商城等渠道上架产品，主动在任务执行前读取相关记忆，建立跨 Harness 的统一索引层

话题三：如何排除干扰信息

上下文干扰信息的处理需结合内容分层与场景化组装 —— 一方面按维度对内容进行分区存储，另一方面根据场景拼装对应的上下文子集：

内容分区存储：按「项目规范 vs 过程决策 vs 用户偏好」等维度对记忆内容进行分区，例如 working memory（每日高频内容）、情景记忆（时间、地点、事件、关联人）、preference（用户偏好）、agents memory（cases + skills）；

多维矩阵索引：在分区之上叠加 project ID、app ID、team ID 等维度，形成矩阵化的索引结构，以覆盖 95% 的常见场景；

场景化拼装：不同场景需组装不同的上下文子集 —— 客服场景需要知识库与用户画像；Coding 场景更关注项目规范与设计目标

话题四：自进化与验证

自进化机制需在三个层面建立闭环 —— 输入源扩展、跨 Engine 验证、主动服务能力。

当前自进化的泛化性仍是工程难点，Skill 上线普遍依赖人工审批作为安全阀：

输入源扩展：覆盖 Session、会议记录、文档、聊天记录等更多数据源，使 Agent 更全面地了解用户状态；

跨 Engine 验证：将 Skill/Experience 共享给其他 Engine，根据执行结果收集正反馈与负反馈，无反馈则压制该 Skill；生产阶段进一步加入沙箱回放验证（trace + skill）；
主动服务能力：基于记忆积累形成预判能力（例如根据简短指令推断用户意图），是 Agent 真正实现主动服务的核心

话题五：失败经验的价值与多 Agent 协同

失败经验与成功经验同等重要，多 Agent 协同需遵循「最小共享原则」以避免串通：

失败经验的内化：失败经验直接内化为新经验，下次遇到相同问题即可直接规避；同时需警惕污染问题 —— 若失败仅为偶然，可通过其他 Engine 的协同进化或人工在后台订正；

失败经验的检索：用户可在感知层主动查询「上次失败学到了什么」，算法层将其融入下一次的主动性策略，也可单独划分分区专门存储失败经验；

最小共享原则：多 Agent 共享完整上下文时会出现「合起伙来骗人」现象 —— 即便 1 个开发 + 3 个 Reviewer 的配置也能在 1-2 轮内快速达成错误共识。解决方案是只共享关键部分：设计阶段共享「目标 + 当前提案」；开发与 Review 阶段共享「目标 + 确认的设计方案」，且不让 Review 直接访问 spec 文件。调整后收敛轮次从 1-2 轮延长到 7-8 轮甚至 20+ 轮；

Engine 性格互补：不同 Engine 性格迥异 —— Claude Code 偏献媚（常说「you are absolutely right」）、Codex 偏过度认真（长任务耗时长）、Grok 4 偏反驳（常 diss 用户）。可在记忆同步时选择性开关，并结合多 Engine 交叉验证（Cross Verify），在效率与准确率间取得平衡。

话题六：Data Infra 选型考量

Data Infra 选型需兼顾跨平台能力与 AI Native 特性，Memory Layer 已不足以支撑多 Harness 时代：

跨平台能力：嵌入式、Local First、用户友好等部署形态需数据库跨平台支撑；过去 flag 数据库 + 图数据库 + 向量/全文 DB 的多库组合方案维护代价过高（资源消耗 + 一致性管理），需收敛到具备跨平台能力的单一底座；

AI Native 能力：AI Native DB 的虚拟化、Bench、本地查询云端等能力是面向 Agent 场景的关键演进方向

从 Memory Layer 到 OS 的演进：随着 DeepSeek Harness 等多 Harness 时代到来，Memory Layer 已不足够。EverOS 的演进路径是包容所有数据库并提供自有跑分机制，让开源贡献者可嵌入自己偏好的数据库

话题七：多 Harness 时代的能力留存

多 Harness 时代的能力留存需建立集中化的共享层，并保留用户对关键决策的介入权：

集中化共享层：无论使用多少家 Harness，最终都需要一个集中化的共享 Memory 层，从采购与成本角度都能达到最优；

用户决策介入：需要人类决策的关键点必须暴露给用户。例如 Agent 读取大量 Session 后发现某事件存在 A 与 B 两种冲突方案，应将冲突直接呈现给用户，由用户决策或补充信息；

隐私与信任基础：监管机制与端到端 Encryption 是跨 Harness 共享方案获得用户信任的基础

话题八：跨 Harness 的共享记忆方案

跨 Harness 的共享记忆应采用「共享机器」架构，避免数据冗余与一致性维护成本：