Topic-Memory:PowerContext 怎样把多次输入整理成主题知识

发布于 2026年10月13日

来年 花也将继续盛开，春日将不厌其烦地反复到来

Topic Memory：PowerContext 怎样把多次输入整理成主题知识

项目里的知识通常来自多次讨论：今天确定一个约定，明天补充限制，后天又根据实际结果修改方案。 PowerContext 的 Topic Memory（主题记忆） 会围绕一个长期主题，把相关证据整理成有标题、摘要和详情的材料，并通过版本保留变化。

本文用“订单 CSV 导入器”贯穿讲解。文中的金额规则和生成结果都是教学示例。

1. 从三次讨论到一份主题材料

假设项目里先后出现三次讨论：

1. 金额统一以整数分存储。
2. 发现浮点转换可能造成精度误差，决定使用 Decimal。
3. 超过两位小数的输入应被拒绝，错误信息包含 CSV 原始行号。

后来接手项目的人问：“金额处理方案是什么？为什么这样设计？输入有哪些限制？” 将这些内容组织成一份“金额存储与校验”主题，就能一起说明规则、原因和细节。

Topic Memory 的正文有三个主要字段：

这种结构支持按需阅读：先找到主题，再看摘要，确实相关时才读取详情。

2. Memory 与 Topic Memory 怎样分工？

你也可以把金额规则保存为几条 Memory Entry，例如“金额以整数分存储”和“输入转换使用 Decimal”。 每条知识可以独立引用、修订或停用。

Topic Memory 以一份主题材料组织相关信息，适合一起阅读背景、决定和细节。

两者可以同时存在。保存一条 Memory 不会因此自动生成 Topic Memory；自动主题整理有自己的 Source 处理流程。

3. 什么时候会开始整理？

假设你刚讨论完“整数分存储”“Decimal 转换”和“小数位校验”，这些输入已经保存为 Source。 此时原始材料已经入库，但可能还没有整理成 Topic Memory。你可以等待定时处理，也可以主动请求处理。

方式一：等待后台定时整理

开启自动处理后，后台按配置的间隔接纳有新 Source 的 Scope，安排整理工作。例如，间隔设为 60 秒，就可以等待下一次调度。任务可能需要排队、调用模型，因此 60 秒是调度间隔，不保证在这段时间内完成。

自动处理默认关闭，需要配置生成模型、后台处理能力和自动处理间隔。

方式二：主动请求整理（flush）

如果你希望刚才的讨论尽快安排处理，可以调用 flush。它相当于发出一句请求：

请安排整理这个 Scope 中尚未处理的 Source。

请求只需指定 Scope：

POST /v1/topic-memory/flush
Content-Type: application/json

{"scope_id":"你的 Scope ID"}

flush 返回 ：

• accepted 表示请求已接受，后台将安排处理；
• 返回 idle 表示截至请求时，Source 已处理到最新位置。

系统会根据处理进度找到尚未处理的材料，你不需要逐条挑选 Source。这适合刚输入完一组重要材料、想观察整理结果，或关闭自动调度后手动触发处理的情况。生成模型和后台处理能力仍需准备好。

两种方式的区别在于谁发起请求：定时调度发起，或调用方主动发起。后面的整理流程相同。

两者都不保证有新主题生成，实际结果可通过搜索主题或查看修订历史确认。

4. 一批 Source 怎样变成 Topic Memory？

后台开始工作后，先确定本批读取哪些输入，再由程序和模型配合完成主题整理。我们用同一批 Source，沿着“选取输入 → 过滤 → 识别线索 → 检索 → 生成 → 提交”走一遍。

假设当前 Scope 有 25 条 Source，前 10 条已经处理过。系统用 Cursor（游标） 记住“处理到第 10 条”，像读书时的书签，下一批从第 11 条开始。

如果数量和模型上下文预算允许，就读取第 11～20 条。这段连续范围叫 Window（窗口）。当前数量配置默认上限是 10 条；材料较长时，系统会缩小范围，把后面的 Source 留给下一批。 选定窗口后，进入下面五步：

第一步：程序过滤，准备可用证据

程序先检查这 10 条 Source 的内部用途。假设第 14 条带有 lineage_only（仅用于追溯）标记，就将它排除，其余 9 条进入生成流程。这个判断在调用模型之前完成。

标记由服务端设置。例如，通过通用 Artifact 接口直接创建或替换制品时，系统会保存一份 Source，记录写入内容并绑定目标版本。这份记录用于追溯，因此不会再次作为普通输入参与主题提炼。第 14 条仍保存在系统中，只是不进入模型输入。

第二步：模型理解证据，识别主题线索

程序给可用证据分配临时编号，再将任务说明和证据一起交给模型。输入可以简化理解为：

任务：识别值得长期保留的主题线索，并注明使用的证据编号。

e1：金额以整数分存储。
e2：发现浮点转换存在精度误差。
e3：决定改用 Decimal。
e5：部署采用容器。
……其余可用证据

e1 等是示意编号，程序保留它们与真实 Source 的对应关系。第 14 条已被过滤，所以没有它对应的 e4。

模型可能返回两条 Probe（主题查询线索）：

• “金额转换与精度”，依据是 e1、e2、e3；
• “容器部署”，依据是 e5。

每条线索包含查询内容、可选关键词和证据编号，供下一步检索使用。此时还没有最终主题正文。

第三步：程序按线索检索已有主题

程序用这些线索在当前 Scope 中检索 Topic Memory，选取相关候选并读取其精确版本。假设金额线索找到了“金额处理”第 1 版，部署线索没有找到合适候选。

检索结果给模型提供了已有知识的背景。接下来，程序把本批新证据和选中的已有主题内容一起交给模型，由模型判断如何组织成主题。

第四步：模型提出新主题或修订内容

结合这些材料，模型可以提出：

• 修订已有的“金额处理”主题，补充精度问题和 Decimal 方案，引用 e1、e2、e3。
• 新建“容器部署”主题，引用 e5。

如果某条 Source 没有提供值得整理的新信息，模型可以不将它用于任何主题。例如，“好的，收到”可能不会进入主题，具体要结合上下文判断。原始 Source 仍然保留。

每份提案都包含完整的标题、摘要、详情和证据编号；修订提案还要指明采用哪个已有主题作为更新目标。这些内容仍在处理过程中，提交后才成为正式可检索的 Topic Memory。

材料能放进预算、更新目标也明确时，可以整体生成；材料过多或目标无法明确对应时，系统会拆分工作、必要时形成临时摘要，再协调结果。因此，10 条是本批读取范围，整个流程可能包含多次模型调用。

第五步：程序校验并提交，推进处理进度

程序把临时证据编号映射回真实 Source 引用，检查内容结构、引用范围和更新目标，并确认目标版本与处理进度没有被其他工作抢先改变。

校验通过后，主题写入、检索索引和 Cursor 推进在同一次事务中完成。在这个例子里，金额主题产生第 2 版，部署主题产生第 1 版，Cursor 从 10 推进到 20，下一批从第 21 条继续。第 14 条虽然没有交给模型，也已经按用途规则处理过，因此不会卡住进度。

如果提交失败，这些变化一起回滚；如果成功处理后没有值得发布的主题，也可以只推进进度。自动 Topic Memory 通过校验后直接发布，无需进入人工审核收件箱。结构和引用检查保证提交规则，内容是否准确、是否适用仍需要结合证据判断。

已有完整标题、摘要和详情时，也可以通过通用 Artifact API 直接创建或整体替换主题，无需模型生成。

5. 怎样读取：先搜索，再展开精确版本

同一主题更新时，artifact_id 不变，revision 增加，head 指向最新版本。每一版都保存完整正文，旧版本仍可精确读取；新版本还保留本次 Source 依据和采用的旧主题版本引用，便于追溯。

当你搜索“金额精度”时，系统检索当前 Scope 中的主题 head，返回标题、摘要、可能的匹配片段和精确 Artifact 引用。 标题、摘要和详情分块都可以参与检索；逐步展开控制的是返回给读者的内容量。

看过摘要后，如果需要详情，就把结果中的精确引用传给读取接口：

例如，搜索返回 topic-memory / topic_01 @ 2。随后后台发布第 3 版，你仍应使用 @ 2 来展开刚才摘要对应的详情。 如果想了解最新情况，可以重新搜索或读取当前 head。

Topic Memory 也可以参与 PreparedContext。一次请求会按组装配置和预算选择主题材料，提供有界的标题、摘要和可选片段； 需要完整内容时，再按精确引用读取。组装上下文不会新增 Topic Memory Revision。

6. 把完整过程连起来

在金额处理这个例子里，多次讨论先被采集为 Source；自动调度或显式请求启动处理；系统按 Cursor 分批读取证据，识别主题线索、检索已有材料，生成并提交合适的主题内容。后续请求先搜索摘要，再根据需要展开精确版本。

当业务规则继续变化，主题可以产生新的 Revision，过去的引用仍保留当时的内容。使用时还要结合当前指令和项目现状，判断历史材料是否适用。

参考

• Topic Memory 使用说明：配置、处理请求、搜索与读取。
• Topic Memory 设计 RFC：窗口、主题识别、分层生成和证据关联。
• 通用 API 补充设计：直接创建、替换和通用读取。
• 生成流程实现：主题线索、历史检索、生成与提交。
• Scope 处理实现：处理目标与窗口推进。