从 Python 到 TypeScript，用 GLM-5.2

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