OceanBase MiniMax Code 多模数据治理与上下文管理实践
MiniMax Code 以开发任务串联多模态材料治理、证据检索与上下文接续，分享OceanBase seekdb和PowerContext如何组织截图、代码、日志，保留来源、验证结果与工作状态。
一张截图里，底部导航挡住了结算按钮；一段日志里，请求还在报错。开发者把截图、日志和代码仓库一起交给 Coding Agent。
材料虽然齐了，但线索却还没有连起来。Agent 开始排查后，还会读文档、改代码、跑测试，产生更多判断和验证结果。
任务越往前走，越需要分清：哪些是可靠依据，哪些仍是猜测，下一轮又该从哪里继续。
9 月 12 日，在外滩大会「OceanBase 面向生产级 Agent 专场」上，MiniMax 的冯雯老师带来《MiniMax Code 多模数据治理与上下文管理》分享。她以开发任务为线索，介绍了从材料治理、证据检索，到上下文管理和跨会话接续的探索。
MiniMax Codex 的这条链路，把 seekdb 和 PowerContext 放到了 Agent 的具体工作中：前者帮助组织、检索不同形式的线索，后者让值得保留的项目知识和未完成的工作状态能够延续。
图 1｜从截图、日志和代码出发，一次开发任务需要经历执行、验证与多轮修正。
01 多模态治理：先把材料变成能核对的证据
分享从移动端结算页面的问题展开。对开发者来说，截图、仓库和日志属于同一项任务；对 Agent 来说，它们之间的对应关系仍需要被建立。
截图中出问题的区域，要能对应到页面和组件；代码片段要能定位到仓库、路径和提交；日志则需要说明发生时间、触发条件，以及相关的工具调用。
多模态数据治理的关键，是让检索命中的内容能够回到具体现场。
一个重要做法，是把原始材料和用于检索的解析结果分开管理：
- 截图可以生成文字识别结果、布局描述和图像向量，同时保留原图与问题区域坐标。
- 代码可以按片段参与检索，同时保留仓库、文件路径和具体提交。
- 日志可以提取错误码和关键信息，同时保留原始记录、时间与调用关联。
原件保存现场，解析结果帮助查找。以后解析器升级，可以重新生成摘要或向量，并记录新的解析版本，不必让一次解析结果成为唯一依据。
图 2｜从采集、解析到治理与索引，各阶段保留关联，才能从检索结果回到原始证据。
版本变化也要沿着这条链路处理。新截图出现后，需要明确它与旧版本的关系；材料被删除或失效时，相关全文、向量和缓存也应按相应规则更新，避免后续检索继续使用已经失效的内容。
团队场景还要加上一道边界：先确定当前用户能够访问哪些资源，再在授权范围内检索。引用解决的是“去哪里核对”，材料是否正确、是否适用于当前任务，仍要继续判断。
02 用 OceanBase seekdb，把精确线索和语义线索查到一起
材料有了来源，下一步是让 Agent 找得到。
在结算页面的例子里，错误码、接口名、函数名适合按关键词查找；“按钮被底部导航遮挡”这样的描述，则更适合用语义检索寻找相关页面、组件和历史问题。
这两类检索还需要共同满足项目、版本和访问权限等条件。只找到“看起来相关”的内容，可能把 Agent 带到另一个项目，或者一段已经失效的实现上。
分享将 OceanBase seekdb 作为这类本地多模态治理方案的统一检索候选底座。seekdb 支持关系、JSON、全文和向量等数据，可以在同一数据库中组织结构化条件与混合检索。详见：seekdb 官方文档[1]。
具体到这次排查，可以按三个层次组织查询：
- 限定范围：只在当前项目、允许访问且符合版本条件的材料中查找。
- 组合线索：用全文检索查错误码和接口说明，用向量检索找语义相关的页面与组件。
- 返回依据：结果附带原图区域、日志位置、代码路径和版本，便于继续核对。
图 3｜结构化条件限定候选范围，全文与向量检索分别承接精确线索和语义线索。
这里要区分数据库与解析服务的职责。在这类方案中，图片、音视频的解析和向量生成由相应模型或服务完成，seekdb 承接解析结果的存储与检索；材料之间的关联、版本和访问规则，也需要在应用中明确建模。
检索效果最终要回到任务上验证：错误码能否找到对应接口？页面描述能否找到相关组件？返回的证据是否属于当前可用版本？
命中之后，Agent 才能进一步判断：哪些材料足以支持修改，哪里还需要补充取证。
03 上下文管理：把窗口留给当前这一轮
能查到材料，不代表每一轮都要把它们全部带上。
一份完整日志可能很长，但当前只需要其中的错误片段；一条历史决策可能有参考价值，却不能覆盖今天的新要求。上下文管理需要决定，什么此刻应该出现，什么应该保留在外部、按需回读。
分享将上下文信息分为四类：
图 4｜四类信息各有不同的更新和退出规则，共同服务于当前任务。
这个划分的重点是生命周期。任务前进，进度和阻塞就要更新；证据进入上下文，要带着版本和引用；稳定约定可以长期保留，但过期后也要能够修订或退出。
这些原则也体现在分享介绍的 MiniMax Code 产品控制中：桌面端提供会话记忆使用与生成的管理，以及不同内容的窗口占用反馈；CLI 通过动态输出预算、工具结果裁剪和压缩恢复，为长任务留出空间。
具体做法并不难理解：长日志和完整报告留在文件里，上下文保留必要摘要与回读路径；重复或过时的输出及时清理；阶段性摘要则留下目标、决定、已验证进展、阻塞和下一步。
压缩释放了窗口，还得保住下一步行动的依据。
比如已经定位按钮遮挡，却还没查明请求错误，摘要就应该分别记录这两种状态。两个症状同时出现，不足以说明它们来自同一个原因；恢复时，也需要重新核对代码、日志和工具现场。
多 Agent 协作同样如此。分享中的 Agent Team 由 Leader 管理目标和进度，Worker 在各自上下文中执行，Verifier 独立检查交付结果。通过文件、摘要和路径传递成果，协调者按需展开细节，避免每个角色都背负整段调试历史。
工作有没有完成，最后仍要看验证结果，不能只看执行者的总结。
04 会话之外，还要留下什么？
检索、裁剪和压缩，帮助 Agent 在当前会话中推进任务。但开发工作经常会停下来：今天只查到一半，明天换个会话继续；一个 Agent 完成实现，另一位开发者接着验证。
此时，下一位需要两类信息。
一类是后续仍然有效的项目知识，例如技术决策、兼容性要求和团队约定。另一类是这项工作当前停在哪里：做过哪些修改、验证到了哪一步、还剩什么疑点。
分享也介绍了利用 PowerContext 保持工作连续性的思路：把可追溯的项目知识与交接状态留在 Harness 和会话之外，为后续工作提供可核对的起点。
图 5｜分享中的 PowerContext 方案，围绕证据、项目记忆与交接状态支持工作接续。
PowerContext 的 MiniMax Code 插件将这两类需求落实为两个入口：Memory 保存值得复用的项目知识，Handoff 组织尚未完成的工作。
这个插件由 Skill 和原生 MCP 配置组成：Skill 提供使用指引，MCP 连接 PowerContext Server 执行操作。它按请求保存内容，不会自动采集每一段对话。详见：MiniMax Code 插件说明[2]。
05 Memory：留下结论，也留下为什么
开发者理解一段实现时，往往还需要知道它背后的原因。为什么采用这个方案？当时有哪些限制？相关约束现在是否仍然有效？
接入 PowerContext 后，可以直接在 MiniMax Code 中提出请求：
查找我们之前关于数据库迁移的决策，并列出来源。
检索结果中的来源引用，可以帮助开发者核对决策背景，再结合当前代码作出判断。
当一条新的项目约束得到确认，也可以明确要求保存：
记住：这个项目需要兼容 Python 3.11，后续实现都要考虑这一点。
保存什么，由用户选择。适合留下的内容包括已确认的决策、稳定的约束，以及经过验证、值得复用的经验。项目发生变化时，也可以要求修正记忆，或将不再适用的信息退役。
这样，后续任务就有了可查询的项目背景，而这些背景仍然需要与当前工作区和有效指令一起使用。
06 Handoff：让下一次工作有一个清楚的起点
继续沿用结算页面的例子。假设这一轮已经确认按钮遮挡与布局有关，完成了部分修改，但不同屏幕尺寸下的表现还没验证，请求错误也仍待定位。
此时只留一句“结算页问题已处理”，会把下一位带偏。交接至少要分清四件事：
- 已确认：按钮遮挡的表现，以及对应截图和代码位置。
- 已完成：实际修改了什么，执行过哪些检查，结果如何。
- 未解决：哪些屏幕尺寸尚未验证，请求错误还有什么线索。
- 下一步：先核对当前代码，再完成布局验证并继续排查请求错误。
图 6｜交接保留目标、进展、风险与证据；接手后结合当前工作区重新核对，再继续执行。
可以先让 MiniMax Code 整理临时交接：
使用 PowerContext 准备当前工作的交接，包含进展、关键证据、待完成的检查和下一步。先给我查看，暂不提交。
准备好的内容可以检查和补充。确认需要供后续会话恢复时，再明确提交：
将这份交接提交为持久检查点，并返回对应版本。
下一次进入项目，就可以提出：
恢复这个项目最近一次已提交的交接，先核对当前工作区，再继续剩余事项。
准备交接与持久保存是两个步骤。插件说明明确区分了临时交接和已提交检查点；需要在后续会话中取回，就要确认提交成功。详见：Handoff 使用说明[3]。
接手者拿到的是可检查的工作状态：已有结论附带依据，待验证的问题仍然开放，下一步也有方向。任务完成后，其中适合长期复用的结论，还可以由用户明确要求保存为 Memory。
07 在 MiniMax Code 中开始使用 PowerContext
MiniMax Code 的多模态任务实践、seekdb 的证据检索，以及 PowerContext 的项目记忆与工作交接，分别处理这条链路上的不同问题：材料怎样查，窗口怎样用，工作怎样继续。
在分享的最后，冯雯老师给了一些务实的落地建议：先选择一个同时具有多模态输入和跨会话需求的真实任务，观察证据是否准确、任务是否完成、恢复时是否减少了重复调查，再据此调整方案。最终，数据治理和上下文管理的价值，都要体现在工作能否更可靠地持续推进。
图 7｜多模态数据治理和上下文工程的收益，需要在真实任务中检验。
PowerContext 现已支持原生的 MiniMax Code 插件并上架官方市场，通过 Skill 与 MCP 配置接入。Skill 提供项目记忆和工作交接的使用指引，MCP 连接 PowerContext 服务，执行相关操作。
注：需要先安装并运行 PowerContext 服务，安装和配置说明见 PowerContext - 安装和运行文档[4]。
图 8｜目前 PowerContext 插件已经上架 MiniMax 插件市场
我们推荐在日常工作中采用下面的工作流：
- 开工前查找：取回与当前任务有关的项目决策和约束，核对来源。
- 确认后保存：留下值得长期复用的结论，检查写入是否成功。
- 暂停前交接：整理进展与证据，显式提交需要保留的检查点。
- 恢复时核对：结合当前工作区确认状态，再继续未完成的事项。
图 9｜使用 @ 选中 PowerContext 之后，即可使用
显式保存、读取 Memory 和整理 Handoff，不要求额外配置 PowerContext 的生成模型；向量搜索和模型生成内容则依赖 Server 中配置的模型服务。MiniMax Code 自身的账号或模型配置与这些服务分开管理。
回到开头的结算页面，下一次恢复任务时，Agent 应该知道：布局改到了哪里，哪些尺寸还没测，请求错误还缺什么证据。
他仍要读代码、跑测试、核对现场，但不用再把已经确认的事情调查一遍。让每一轮工作留下一个可靠的下一步，才是这些机制共同要解决的问题。
参考资料
[1]
seekdb 官方文档: https://github.com/oceanbase/seekdb-doc
[2]
MiniMax Code 插件说明: https://github.com/oceanbase/powercontext/tree/master/integrations/minimax/plugins/powercontext
[3]
Handoff 使用说明: https://github.com/oceanbase/powercontext/blob/master/integrations/minimax/plugins/powercontext/README.md[#pick\-up-where-the-work-left-off](https://github.com/oceanbase/powercontext/blob/master/integrations/minimax/plugins/powercontext/README.md#pick\-up-where-the-work-left-off)
[4]
PowerContext - 安装和运行文档: https://powercontext.oceanbase.io/zh/docs/get-started/install-and-run/
最后，欢迎大家关注 OceanBase 社区公众号 “老纪的技术唠嗑局”。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~
往期内容推荐
了解更多
添加社区小助手，加入微信交流群~