分享从移动端结算页面的问题展开。

对开发者来说，截图、仓库和日志属于同一项任务；对 Agent 来说，它们之间的对应关系仍需要被建立。

截图中出问题的区域，要能对应到页面和组件；代码片段要能定位到仓库、路径和提交；日志则需要说明发生时间、触发条件，以及相关的工具调用。

多模态数据治理的关键，是让检索命中的内容能够回到具体现场。

一个重要做法，是把原始材料和用于检索的解析结果分开管理：

• 截图可以生成文字识别结果、布局描述和图像向量，同时保留原图与问题区域坐标。
• 代码可以按片段参与检索，同时保留仓库、文件路径和具体提交。
• 日志可以提取错误码和关键信息，同时保留原始记录、时间与调用关联。

原件保存现场，解析结果帮助查找。以后解析器升级，可以重新生成摘要或向量，并记录新的解析版本，不必让一次解析结果成为唯一依据。

从采集、解析到治理与索引，各阶段保留关联，才能从检索结果回到原始证据

版本变化也要沿着这条链路处理。新截图出现后，需要明确它与旧版本的关系；材料被删除或失效时，相关全文、向量和缓存也应按相应规则更新，避免后续检索继续使用已经失效的内容。

团队场景还要加上一道边界：先确定当前用户能够访问哪些资源，再在授权范围内检索。引用解决的是“去哪里核对”，材料是否正确、是否适用于当前任务，仍要继续判断。

材料有了来源，下一步是让 Agent 找得到。

在结算页面的例子里，错误码、接口名、函数名适合按关键词查找；“按钮被底部导航遮挡”这样的描述，则更适合用语义检索寻找相关页面、组件和历史问题。

这两类检索还需要共同满足项目、版本和访问权限等条件。只找到“看起来相关”的内容，可能把 Agent 带到另一个项目，或者一段已经失效的实现上。

分享将 OceanBase seekdb 作为这类本地多模态治理方案的统一检索候选底座。OceanBase seekdb 支持关系、JSON、全文和向量等数据，可以在同一数据库中组织结构化条件与混合检索。

注：OceanBase seekdb 官方文档：

https://github.com/oceanbase/seekdb-doc

具体到这次排查，可以按三个层次组织查询：

• 限定范围：只在当前项目、允许访问且符合版本条件的材料中查找。
• 组合线索：用全文检索查错误码和接口说明，用向量检索找语义相关的页面与组件。
• 返回依据：结果附带原图区域、日志位置、代码路径和版本，便于继续核对。

结构化条件限定候选范围，全文与向量检索分别承接精确线索和语义线索

这里要区分数据库与解析服务的职责。在这类方案中，图片、音视频的解析和向量生成由相应模型或服务完成，OceanBase seekdb 承接解析结果的存储与检索；材料之间的关联、版本和访问规则，也需要在应用中明确建模。

检索效果最终要回到任务上验证：错误码能否找到对应接口？页面描述能否找到相关组件？返回的证据是否属于当前可用版本？

命中之后，Agent 才能进一步判断：哪些材料足以支持修改，哪里还需要补充取证。

一份完整日志可能很长，但当前只需要其中的错误片段；一条历史决策可能有参考价值，却不能覆盖今天的新要求。上下文管理需要决定，什么此刻应该出现，什么应该保留在外部、按需回读。

分享将上下文信息分为四类：

四类信息各有不同的更新和退出规则，共同服务于当前任务

这个划分的重点是生命周期。任务前进，进度和阻塞就要更新；证据进入上下文，要带着版本和引用；稳定约定可以长期保留，但过期后也要能够修订或退出。

这些原则也体现在分享介绍的 MiniMax Code 产品控制中：桌面端提供会话记忆使用与生成的管理，以及不同内容的窗口占用反馈；CLI 通过动态输出预算、工具结果裁剪和压缩恢复，为长任务留出空间。

具体做法并不难理解：长日志和完整报告留在文件里，上下文保留必要摘要与回读路径；重复或过时的输出及时清理；阶段性摘要则留下目标、决定、已验证进展、阻塞和下一步。

压缩释放了窗口，还得保住下一步行动的依据。

比如已经定位按钮遮挡，却还没查明请求错误，摘要就应该分别记录这两种状态。两个症状同时出现，不足以说明它们来自同一个原因；恢复时，也需要重新核对代码、日志和工具现场。

多 Agent 协作同样如此。分享中的 Agent Team 由 Leader 管理目标和进度，Worker 在各自上下文中执行，Verifier 独立检查交付结果。通过文件、摘要和路径传递成果，协调者按需展开细节，避免每个角色都背负整段调试历史。

工作有没有完成，最后仍要看验证结果，不能只看执行者的总结。

检索、裁剪和压缩，帮助 Agent 在当前会话中推进任务。但开发工作经常会停下来：今天只查到一半，明天换个会话继续；一个 Agent 完成实现，另一位开发者接着验证。

此时，下一位需要两类信息。

• 一类是后续仍然有效的项目知识，例如技术决策、兼容性要求和团队约定；
• 另一类是这项工作当前停在哪里：做过哪些修改、验证到了哪一步、还剩什么疑点。

分享也介绍了利用 PowerContext 保持工作连续性的思路：把可追溯的项目知识与交接状态留在 Harness 和会话之外，为后续工作提供可核对的起点。

注：PowerContext GitHub ：

https://github.com/oceanbase/powercontext

分享中的 PowerContext 方案，围绕证据、项目记忆与交接状态支持工作接续

PowerContext 的 MiniMax Code 插件将这两类需求落实为两个入口：Memory 保存值得复用的项目知识，Handoff 组织尚未完成的工作。

这个插件由 Skill 和原生 MCP 配置组成：Skill 提供使用指引，MCP 连接 PowerContext Server 执行操作。它按请求保存内容，不会自动采集每一段对话。

注：MiniMax Code 插件说明：

https://github.com/oceanbase/powercontext/tree/master/integrations/minimax/plugins/powercontext

开发者理解一段实现时，往往还需要知道它背后的原因。为什么采用这个方案？当时有哪些限制？相关约束现在是否仍然有效？

接入 PowerContext 后，可以直接在 MiniMax Code 中提出请求：

查找我们之前关于数据库迁移的决策，并列出来源。

检索结果中的来源引用，可以帮助开发者核对决策背景，再结合当前代码作出判断。

当一条新的项目约束得到确认，也可以明确要求保存：

记住：这个项目需要兼容 Python 3.11，后续实现都要考虑这一点。

保存什么，由用户选择。适合留下的内容包括已确认的决策、稳定的约束，以及经过验证、值得复用的经验。项目发生变化时，也可以要求修正记忆，或将不再适用的信息退役。

这样，后续任务就有了可查询的项目背景，而这些背景仍然需要与当前工作区和有效指令一起使用。

继续沿用结算页面的例子。假设这一轮已经确认按钮遮挡与布局有关，完成了部分修改，但不同屏幕尺寸下的表现还没验证，请求错误也仍待定位。

此时只留一句“结算页问题已处理”，会把下一位带偏。交接至少要分清四件事：

• 已确认：按钮遮挡的表现，以及对应截图和代码位置。
• 已完成：实际修改了什么，执行过哪些检查，结果如何。
• 未解决：哪些屏幕尺寸尚未验证，请求错误还有什么线索。
• 下一步：先核对当前代码，再完成布局验证并继续排查请求错误。

交接保留目标、进展、风险与证据；接手后结合当前工作区重新核对，再继续执行

可以先让 MiniMax Code 整理临时交接：使用 PowerContext 准备当前工作的交接，包含进展、关键证据、待完成的检查和下一步。先给我查看，暂不提交。

准备好的内容可以检查和补充。确认需要供后续会话恢复时，再明确提交：将这份交接提交为持久检查点，并返回对应版本。

下一次进入项目，就可以提出：恢复这个项目最近一次已提交的交接，先核对当前工作区，再继续剩余事项。

准备交接与持久保存是两个步骤。插件说明明确区分了临时交接和已提交检查点；需要在后续会话中取回，就要确认提交成功。

注：Handoff 使用说明：

https://github.com/oceanbase/powercontext/blob/master/integrations/minimax/plugins/powercontext/README.md#pick-up-where-the-work-left-off）

接手者拿到的是可检查的工作状态：已有结论附带依据，待验证的问题仍然开放，下一步也有方向。任务完成后，其中适合长期复用的结论，还可以由用户明确要求保存为 Memory。

MiniMax Code 的多模态任务实践、OceanBase seekdb 的证据检索，以及 PowerContext 的项目记忆与工作交接，分别处理这条链路上的不同问题：材料怎样查，窗口怎样用，工作怎样继续。

在分享的最后，冯雯给了一些务实的落地建议：先选择一个同时具有多模态输入和跨会话需求的真实任务，观察证据是否准确、任务是否完成、恢复时是否减少了重复调查，再据此调整方案。最终，数据治理和上下文管理的价值，都要体现在工作能否更可靠地持续推进。

多模态数据治理和上下文工程的收益，需要在真实任务中检验

PowerContext 现已支持原生的 MiniMax Code 插件并上架官方市场，通过 Skill 与 MCP 配置接入。Skill 提供项目记忆和工作交接的使用指引，MCP 连接 PowerContext 服务，执行相关操作。

注：需要先安装并运行 PowerContext 服务，安装和配置说明见 PowerContext - 安装和运行文档

https://powercontext.oceanbase.io/zh/docs/get-started/install-and-run/

目前 PowerContext 插件已经上架 MiniMax 插件市场

我们推荐在日常工作中采用下面的工作流：

• 开工前查找：取回与当前任务有关的项目决策和约束，核对来源。
• 确认后保存：留下值得长期复用的结论，检查写入是否成功。
• 暂停前交接：整理进展与证据，显式提交需要保留的检查点。
• 恢复时核对：结合当前工作区确认状态，再继续未完成的事项。

使用*@*选中 PowerContext 之后，即可使用

显式保存、读取 Memory 和整理 Handoff，不要求额外配置 PowerContext 的生成模型；向量搜索和模型生成内容则依赖 Server 中配置的模型服务。MiniMax Code 自身的账号或模型配置与这些服务分开管理。

回到开头的结算页面，下一次恢复任务时，Agent 应该知道：布局改到了哪里，哪些尺寸还没测，请求错误还缺什么证据。他仍要读代码、跑测试、核对现场，但不用再把已经确认的事情调查一遍。

让每一轮工作留下一个可靠的下一步，才是这些机制共同要解决的问题。

立即试用 OceanBase 企业版，体验国产数据库能力180 天免费试用，零门槛开通