第 24 篇
工程技术
从任务经验到长期知识:如何控制晋升过程
结合实际开发项目,讨论从任务经验到长期知识:如何控制晋升过程,说明设计理由、关键源码、验证方法及适用边界。
本文目录 · 7 节
本文属于 Memory Center:AI 编程上下文与记忆系统工程实践,第 24 篇,位于“任务记忆与长期知识”模块。案例背景统一采用实际开发项目;复现步骤使用脱敏教学样例,不代表特定生产事故。
从实际问题出发
任务日志里可能包含临时判断、私有路径和工具载荷。把日志直接复制进长期 Wiki,会把短期噪声与敏感信息永久带入后续检索。晋升需要一次明确的提炼过程。
先预览可复用结论
把经验写成适用场景、做法、限制和来源,再检查是否具有跨任务价值。assistant_memory 的预览与确认区分,使用户能看到将写入什么。确认知识晋升与确认 Skill 发布是不同动作,不能互相替代。

图中展示的是本篇关注的职责和顺序。正常流程之外,还要结合下面的源码与实验检查失败分支;它不是对某次线上调用的运行时追踪。
来源与解释共同保留
有来源不代表来源自动真实,引用也不能为未经验证的结论背书。应说明哪些来自测试,哪些来自人工判断。提炼时删去项目身份和原始会话正文,保留能帮助未来判断的必要条件。
关键源码与阅读方法
源码基线为 Memory Center 6e90553(文档标注 5.0.0b24)。定位:memory_center/platform/assistant/tools.py,函数 assistant_memory,起始行 109。
以下为源码节选,省略后续分支;不能作为独立脚本执行。
def assistant_memory(
action: str,
title: str = "",
content: str = "",
source: str = "",
knowledge_type: str = "事实",
module: str = "system",
source_refs: list[str] | None = None,
source_path: str = "",
destination: str = "",
company: str = "",
category: str = "项目资料",
task_id: str = "",
confirm: bool = False,
) -> dict:
"""晋升稳定长期知识或显式归档文档;两类写入默认只预检,确认后才执行。
Args:
action: promote 或 archive
title/content/source/knowledge_type/module: promote 的长期知识字段
source_refs: promote 的 Memory Center task、receipt 或其他可追溯来源引用
task_id: promote 的可选 Memory Center 任务锚点;仅在存在可信任务绑定时传入
source_path: archive 的绝对源路径
destination 或 company/category: archive 的目标路由
confirm: 二次确认后才执行写入
"""
if action == "promote":
return core.promote(
root, title=title, content=content, source=source,
knowledge_type=knowledge_type, module=module,
source_refs=source_refs, confirm=confirm, task_id=task_id,
)
if action == "archive":
if not source_path.strip():
raise core.WikiError("action=archive 时 source_path 不能为空")
return core.archive(
阅读时先找输入由谁提供,再区分纯计算、读取和写入;遇到异常或提前返回,追问调用方会得到什么,以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现,跨模块行为应继续查看调用处和相应测试。
用一个小实验核对设计
建议在独立临时目录和隔离数据中操作,使用虚构的接口、文档与项目名称。
- 选一条已完成任务经验。
- 生成晋升预览。
- 核对适用边界与敏感字段。
- 确认后再检查记录。
**要核对的结果:**预览阶段不应让候选知识生效,确认后的内容应能追溯到明确来源。
可把观察记录为下表;没有执行的项写“未执行”,不能用设计预期冒充实测结果。
| 核对项 | 应保留的证据 |
|---|---|
| 使用条件 | 源码版本、配置、输入与项目范围 |
| 正常行为 | 实际返回、来源位置或状态变化 |
| 关键失败分支 | 错误码、可见结果与原状态是否保留 |
| 结论范围 | 已覆盖、未覆盖和需要进一步验证的条件 |
适用边界与继续阅读
本篇以静态源码与项目设计为依据,给出可执行的核对方法,未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化,应先核对当前合同,再把方法用于自己的实际开发项目。
理解这一节后,可以回到专题总导航,沿同一模块继续阅读;顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择,应连同本篇的代价与限制一起采用。