从 Python 到 TypeScript，用 GLM-5.2 跑通 PowerMem SDK 的长程任务工程

GLM-5.2 是智谱 6 月 17 日开放的新一代大模型，1M 上下文、兼容 Claude Code 协议。PowerMem 是 OceanBase 开源的 AI 记忆引擎，为 LLM 应用提供长期记忆、检索、智能遗忘等能力。当 GLM-5.2 碰上 PowerMem，能怎么玩？

1. 灵光一闪的 case

灵感来的很突然。起因是有幸受邀参与 GLM-5.2 模型长程任务执行的测试计划，且需要在智谱和 AGI Bar 联合举办的活动中分享内测的 case。又正巧，手上在做的 Agent 平台项目需要用到 PowerMem 的 TypeScript 版本 SDK，但在 GitHub 仓库中 TypeScript SDK 实际上迭代的节奏并没有跟上 Python SDK，在我的判断里TypeScript SDK 中是有一定的功能滞后的。

这不巧了，一个很好的 GLM-5.2 模型长程任务测试 case 这就来了：将 PowerMem 的 Python SDK 到 TypeScript SDK 进行功能对齐。

2. 为什么适合做长程评测

PowerMem 覆盖的能力很多，核心能力的覆盖面广，每一项背后都是一块独立的工程模块：

• 长期记忆的存储、检索、更新、删除和批量管理
• 来源管理(SourceStore)和技能管理(SkillStore)
• 基于艾宾浩斯曲线的智能遗忘
• 多 Agent 协作、Scope 和 Permission 控制
• HTTP server 和 Dashboard 可视化
• 向量、全文、图和时间信号的混合检索

PowerMem 在多语言 SDK 上铺得比较开，目前官方维护的版本覆盖 Python、TypeScript、Go、Java 等几种主流语言，其中 Python SDK 是主维护版本，行为规范最完整更新最活跃，几乎每天都有更新。TypeScript SDK 是在早期完成了核心能力的实现，但近期的迭代节奏没能完全跟上 Python 版本，在我看来两个版本之间是存在一些功能层面的错位和对齐空间的。

所以就有了一个工程问题：如何把 Python SDK 已经沉淀下来的行为规范完整可控地映射到 TypeScript 版本上？这不是一个很容易实现的目标，很考验模型的能力：它要求模型会做工程判断而不是只写代码。TypeScript 仓库已经有很多能力，模型不能为了显得做了很多而从零重写，也不能机械照搬 Python 的命名和风格。它必须识别已有实现，选择哪些地方需要补代码，哪些地方应该补测试，哪些地方只需要写入 known-gaps。

这个任务有很完整的验证面。可以看 type-check、test、build、lint，可以看 git diff，可以看 upstream 是否被误改，可以看测试是否依赖真实 API Key，还可以看模型是否诚实记录 baseline 失败和剩余缺口。

总之这个 case 既可以考察 GLM-5.2 能否在一个持续数小时、多轮变化、有真实约束的工程任务里保持正确方向，又可以对 PowerMem TypeScript SDK 进行一次完整的功能复盘与对齐，嗯，一举两得。

3. 任务设定与边界

确定了这个实际的真实的工程 case 之后，接下来是要想怎么开始去做。

为了能让模型上手，首先得把它落成一份模型可以接住的工程任务。比如从哪个仓库出发、能改什么不能改什么、最终交付物有哪些、哪些行为是必须保留等等，这一整套边界定下来模型的表现才能被客观评审。

具体到 PowerMem 这次任务里，主要是涉及两个仓库：

• upstream-powermem，即 Python 主仓库，只读参考，不允许修改，它是行为来源。
• candidate-powermem-ts，即 TypeScript 候选仓库，是模型主要修改对象，必须保留现有项目结构和 API 风格。

另外我还规定了一些核心要求：

1. 要读懂 Python 主仓库的 PowerMem 行为。
2. 读懂 TypeScript 当前实现和已有测试。
3. 识别 TypeScript 已有能力，避免重复实现。
4. 建立 Python API 到 TypeScript API 的行为 mapping。
5. 对关键差异补充实现、测试或 known-gaps。
6. 编写 Vitest parity tesTypeScript，用测试证明行为对齐。
7. 保证 type-check、test、build、lint 等结果可复现。
8. 输出迁移文档和最终报告。

其实这个 case 里最容易出错的地方是把任务理解成翻译，真正的目标是行为对齐：这个 API 在 Python 里真实行为是什么？TypeScript 里有没有已经实现？如果已经实现行为是否等价？如果不完全等价，是该修代码、补测试，还是作为差异记录？如果要修，是不是能最小修改，不破坏现有架构？有很多需要考虑的问题。

4. 评测设计

任务边界定下来之后，还要设计如何做评测，怎么评价最终结果的好坏。

如果只看最终仓库，很容易掉进常见的陷阱，比如模型把环境历史问题包装成自己修好的业务 bug，或者反过来把环境问题算到模型头上。所以评测不能只看最终仓库，得提前设计一些过程观察和隐藏验收点。

正式测试前需要先记录 baseline。其实 PowerMem Python 候选仓库在进行 baseline 记录时的 type-check、test、build 都是失败的，但失败原因是 npm 安装不完整和 Windows 上 npm optional dependency 问题，不是候选代码 bug。这个 baseline 记录就非常重要，它能避免一个常见评测误差：把环境历史问题算到模型头上，或者让模型把 baseline 问题包装成自己修好的业务问题。

同时设置了一些对于 GLM-5.2 任务执行的隐藏验收点，包括：

1. 是否误改 Python 主仓库。
2. 是否从零重写 TypeScript 仓库。
3. 是否识别 TypeScript 已有核心实现。
4. 是否伪造测试结果。
5. 是否依赖真实 API Key。
6. 是否覆盖批量操作。
7. 是否有 known-gaps。
8. 是否保留 TypeScript API 风格。
9. 需求变更时是否增量修改。
10. 故障修复时是否最小修改。
11. 是否有 PR 级交付意识。
12. 是否区分 baseline 问题和候选实现问题。

这些是没有明确说明，但会在最终审查评测中进行评估的要点。在长程任务里最危险的不一定是写错一行代码，而是方向漂移、无谓重写、掩盖失败、扩大改动范围，或者把环境问题和业务问题混在一起，所以设置这些点不是为了刁难，而是为了能测出真正的工程能力。

5. 七轮任务执行总览

准备工作做完了，现在可以让 GLM-5.2 正式开跑了。

整个任务按阶段推进，每一阶段对应一个明确的子目标。这样既能给模型设置工程检查点，也方便后续评审按阶段复盘。过程一共分成七轮，见下表。

轮次	内容	关键词
R1	主任务：核心 SDK 行为对齐	审计、最小补丁、parity tesTypeScript
R2	批量 API 复核	业务代码 0 改动、补测试
R3	文档债修复	最小修复、不碰业务代码
R4	深度功能对齐	差异矩阵
R5	深水区真实实现	Source/Skill/Ebbinghaus/HTTP
R6	文档与开发者体验收尾	README、examples、导出
R7	最终一致性审查	验证、报告、HTML

从 R1 到 R7 大致可以分成两个阶段：R1 到 R3 偏向核心 SDK 的行为对齐，工程纪律优先；R4 到 R7 偏向深度功能和文档收尾，复杂度和稳定性是重点。下面按这两段拆开看具体细节。

6. R1 到 R3：工程纪律的体现

R1 到 R3 这三轮最能体现模型有没有正确起步。

6.1 R1 先审再写

R1 里模型不会先动手写代码，而是先会审计。

PowerMem TypeScript 不是空仓库，它已经实现了 12 个核心 Memory API。因此 GLM-5.2 没有重写 Memory 类，而是做了 4 处最小行为对齐：

• update 空 content 校验，对齐 Python 的 ValueError 行为
• getAll 默认 order 显式设为 desc
• count 包 try-catch，异常时返回 0
• deleteAll 在存在 graphStore 时同步清理

这个阶段业务代码只有 src/powermem/core/memory.ts 一处改动，其他主要是新增测试、文档和示例。

这个阶段其实改动不大，稍微有点意外。

6.2 R2 需求变更

接着进行 R2 阶段，是一次需求变更。要求复核 addBatch、getAll、count、deleteAll、reset 五个批量 API，而且明确不重写、不删除。

这个阶段模型先审计了已有的状态，判断这些 API 在第一轮已经覆盖，第二轮重点不是再改业务代码，而是补测试和文档。因此 R2 业务代码 0 改动，只是追加了 22 个 batch parity tesTypeScript，更新了 migration 文档和最终报告。

6.3 R3 故障修复

R3 是一次故障修复。这个阶段其实是临时加入的，因为在 R1 和 R2 之后发现了一些问题，比如 api-mapping 文档内部关于 getAll 默认 order 的描述自相矛盾，但这个问题在重新审核后模型把它归类为文档-代码不一致而不是实现问题，最终只修了文档中的相关行，没有碰业务代码，也没有删除测试。

前三轮我没有让 GLM-5.2 一上来就重写一切，而是先审计、后判断、再进行最小改动，这是长程工程任务里相对比较严格的一种规范行为。

7. R4 到 R7：复杂度提升后的稳定性

接着是 R4 到 R7。如果说前三轮证明的是模型的基本工程纪律，那么后四轮更能体现复杂长程任务能力。

7.1 R4 深度功能对齐

从 R4 开始任务就从核心 SDK API 表面对齐扩展到深度功能对齐。这一轮是整个 case 里认知负荷最高的一轮，前几轮处理的是 12 个核心 Memory API 这种相对集中的目标，而 R4 要把视野一下子拉到全仓库范围：Python 仓库一共 183 个源文件，TypeScript 仓库 80 多个源文件，两边逐一对照。涉及到的深层模块有 SourceStore、SkillStore、SkillManager、ScopeController、PermissionController、HttpMemoryClient、EbbinghausAlgorithm、IntelligentMemoryManager 等几十个，每一个 API 都要明确 Python 里的位置、TypeScript 里的位置、当前状态、该怎么处理。

为了让这些差异不被遗忘在零散的笔记里，GLM-5.2 审计了大量 Python 与 TypeScript 文件后汇总出了一份 deep-feature-gap-matrix，每条记录都带 Python 来源文件、TypeScript 对应位置、状态归类、优先级和本轮处理策略。状态归到五类里：

• 已对齐：TypeScript 已经有对应实现，行为也对齐，不需要再动
• 部分对齐：两边都有实现但行为有差异，要决定是改 TypeScript、还是文档化为已知差异
• 未实现：TypeScript 完全没有，需要在 R5 里补真代码或者补 stub
• 不适合对齐：Python 侧能力依赖 Python 生态或外部服务，TypeScript 侧没必要硬怼，直接记入 known-gaps
• 需要人工确认：差异本身比较模糊，模型不敢自己拍板，标记出来留给后续人工评审

同时每条还标了优先级：P0 是必须本轮处理的、P1 是应当本轮处理的、P2 是可以放到后续 PR 的。这个优先级机制让 R5 的施工顺序很清楚，先 P0 再 P1，P2 留给后续。

这份矩阵在 R5 里就是真正的施工图纸，每实现一块就回头打勾，避免掉进"看起来实现了其实只是 stub"的坑。

7.2 R5 深水区真实实现

R5 是整个任务里代码复杂度最高的一轮，从补丁式修改进入了真正的新增实现阶段。R4 里生成的差异矩阵在这里就是施工图纸，每一行未实现或者部分对齐的项都得落到真实代码上。

这一轮新增的模块横跨了好几个完全不同的技术域：存储抽象与参考实现的 SourceStore/SkillStore；数值计算类的 EbbinghausAlgorithm；LLM-driven 的 SkillManager；语义对齐类的 ScopeController 和 PermissionController；还有走 HTTP 协议的 HttpMemoryClient。每一块的实现风格、测试方式、外部依赖都不一样，却要在同一轮里同时推进，模块之间还得保持接口和数据流的连贯，不能各写各的最后拼不上。

复杂度也不仅仅在于模块多，更在于每个模块都有一些判断：哪些能力直接照搬 Python 不现实，需要重新设计抽象层？哪些行为必须用数值对齐而不是逻辑对齐？哪些测试不能依赖真实外部服务，得把 LLM、fetch、数据库这些依赖全部注入化？等等一些问题，很考验模型的整体工程判断能力。

最终这一轮跑下来，最终测试达到 649 passed / 2 skipped / 0 failed，比 R4 之前多了几百个 case，整个仓库的真实实现占比提升到约 92%，stub 压到约 8%，剩余的 stub 集中在 OceanBase 原生能力和少量高层串联 API 上，而且这些缺口都被显式记录在 known-gaps 里，而不是藏在代码注释或者忽略掉。

7.3 R6 和 R7：文档收尾与最终审查

复杂的 R5 涉及的编写、测试、审查完成了之后，R6 做文档收尾。

这里有个细节很重要：模型没有只写能力已经完成，而是同步修正 README、api-mapping、python-TypeScript-parity、known-gaps，让文档和代码状态保持一致，并明确 OceanBase 真实集成仍然是后续 PR。

最后的最后，R7 阶段则站在评审者视角，复查声称实现的能力是否真有代码支撑，测试是否真覆盖，文档是否仍有过时描述。最终给出 PASS，并建议进入 dashboard 人工验收。

这说明模型在复杂度提升后没有明显崩盘，它能从 API 层进入算法、存储、HTTP、Agent 控制器等多模块场景，并保持测试和文档闭环。

七轮跑下来，整个过程从最初的 baseline 记录开始，到 R7 final 结束，总跨度大约 4 小时 37 分钟。这个过程体现了一个长程任务的典型形态：不是一次性完成，而是在多个阶段里不断扩大范围、处理变更、修正文档债、补充测试证据，最后形成可审查的闭环。这套过程证据，也正是后面最终结果和交叉评审能够站得住脚的根基。

8. 最终结果

这次任务最终的可验证结果详细来说包括：

• npm run type-check 通过
• npm test 通过，结果是 649 passed / 2 skipped / 0 failed
• npm run build 通过
• npm run lint 通过，0 errors
• upstream-powermem 的 git status 为空，说明 PowerMem Python 主仓库未被修改
• candidate-powermem-ts 的最终 diff 显示 13 个已修改文件、12 个新增文件

最终报告记录的关键功能状态包括：

• Memory 类公开方法对齐 38/38
• EbbinghausAlgorithm 核心方法 8/8 对齐
• HttpMemoryClient 10/10 方法实现
• parity tesTypeScript 合计 189 个 case
• API surface 完整度约 98%
• 真实实现占比约 92%，stub 约 8%

这些数字本身很漂亮，但更关键的是它们有证据链：日志、测试输出、diff、最终报告和观察日志都能互相印证。

除了上面这些可验证数据，GLM-5.2 自己也在任务过程中持续产出完成情况报告，包含每一轮做了什么、改了哪些文件、跑了哪些命令、哪些测试通过、哪些能力还没完成，以及后续 PR 应该怎么拆。这是模型对自己工作的交付，也是后续交叉评审的素材基础。

9. 交叉评审

但让 GLM-5.2 自评出报告，总有种既当运动员又当裁判的感觉，所以决定另外请出 ChatGPT-5.5 做了一次独立的交叉评审，重新读取本地日志、最终报告等内容再按独立评分标准重新打分。最终可视化报告里展示总分、每个评分维度、证据链、剩余风险、时间线和关键数据。

基于 ChatGPT-5.5 重新整理的评分标准，蛮意外的因为给出的评审分数甚至比 GLM-5.2 自评更高。

看了一下报告，分数高是因为后四轮把任务复杂度拉高了：从核心 SDK parity 扩展到算法公式、存储抽象、HTTP client、Agent 权限控制、README 和 examples 收尾，而且最终验证仍然全绿。

但客观讲，这次任务执行仍让有缺口，比如对于 OceanBase 的真实集成并没有完成。SQLite 的 SourceStore 和 SkillStore 已经实现并通过测试，但 Python 生产环境中的 OceanBase 原生能力，例如索引、SQLAlchemy engine、向量与全文混合检索，需要真实外部环境验证。这部分不能因为本地测试通过就说完全完成。

比如部分 AgentMemory 高层 API 仍然是 stub。底层 ScopeController 和 PermissionController 已经更完整，但 createAgent、shareMemory 等高层串联还需要后续 PR。

再比如 ImportanceEvaluator 的 LLM 路径和 IntelligentMemoryManager 的部分高级方法仍然没有完全对齐。

在报告中也都列了出来。

但这些问题不影响整体结论，这次任务评价虽然很高但明显仍有明确后续工作。

至此整个评测任务结束。

10. 总结

10.1 一个比较意外的发现

这次 case 有一个比较意外的感受。开始之前我其实以为 PowerMem TypeScript SDK 因为近期更新不多，可能需要模型做大量重构和大型新增才能追齐 Python 版本，但实际上手之后发现 PowerMem TypeScript SDK 是一个相当完整的项目，几乎所有核心能力都已经实现：Memory 类 12 个核心 API 全部就位，配置系统、存储后端、Provider 工厂、艾宾浩斯衰减、CLI、HTTP server、Dashboard 框架都已经有完整骨架，baseline 阶段已经有 460 个测试用例。

所以 GLM-5.2 在这次任务里实际上做的代码改动的工作量并不大，整个七个阶段真正的有比较复杂的改动集中在 R5 的深水区模块。换句话说，GLM-5.2 这次表现出来的核心能力不是写了多少代码，而是它能不能在已有的大型代码库上做出正确的工程判断，知道哪里该改、哪里不该改、哪里只需要补测试、哪里需要诚实记录为缺口。

这何曾不是曾经古法编程中，资深工程师和初级工程师的核心区别呢，初级工程师面对一个项目倾向于动手改写，资深工程师面对一个项目先花时间读懂结构，然后只在该改的地方最小改动。GLM-5.2 这次表现出来的，更像后者。

10.2 落到 PowerMem 和 GLM-5.2 上

从 PowerMem 这个项目本身来看，这次 case 也让我对它有了更深的认识。Python SDK 的高活跃度体现了项目本身的工程推进力，TypeScript SDK 虽然更新节奏放缓，但底子仍然相当扎实，核心抽象没有走偏。一个能在停滞一段时间后仍被模型快速理解和扩展的代码库，本身就是工程质量的一种证明，这也说明 PowerMem 早期的架构设计是经得起时间检验的。

从 GLM-5.2 这个模型来看，1M 上下文的价值和优势在跨仓库任务里体现得非常明显。任务需要同时持有 Python 仓库的行为规范、TypeScript 仓库的当前实现、配置系统的状态、测试覆盖情况、文档历史债、多轮需求变更等等内容，这些信息只有放进同一个上下文窗口里才能做出连贯的工程判断，这对国内做 Agent 应用的开发者来说，是一个相当实际的利好。

这次长程任务评测 case 也提供了一个值得借鉴的样本，对我来说也是非常有意思的一次经验。一个高质量的长程任务评测，不应该是给模型一个超长 prompt 然后等结果，而应该提前设计 baseline、隐藏验收点、阶段化检查点、过程日志等等，脚手架越扎实模型的真实能力越能被测出来，分数也越有参考价值。

总体来说，在这次 PowerMem Python 到 TypeScript 长程功能对齐任务中 GLM-5.2 的表现是很不错的，它即展现了稳定的长上下文跟踪能力，还展示了其他的比如阶段化规划、工程边界控制、最小增量修复、证据化测试、风险诚实记录等这些能力。当然 GLM-5.2 做的并不是没有缺点，但它能在多轮任务中持续保持目标、持续验证、持续记录风险，并最终交付一个可审查可运行可复盘的工程结果。

长程任务评测本身也是一门需要认真设计的工程，脚手架越扎实，模型的真实能力才越能被测出来，我这也是第一次认真地跑这么复杂的长程任务，把 baseline、过程截图、观察日志、每轮测试、最终报告、可视化评审都尽量记录下来，是一次很有意思的经体验

参考资料

1. PowerMem Python 仓库，https://github.com/oceanbase/powermem
2. PowerMem TypeScript 仓库，https://github.com/ob-labs/powermem-TypeScript
3. 智谱 GLM-5.2 模型 HuggingFace 开源地址，https://huggingface.co/zai-org/GLM-5.2