GLM-5.2是智谱于6月17日开放的新一代大模型产品，提供1M上下文能力，并且兼容Claude Code协议。PowerMem则是OceanBase开源的一套AI记忆引擎，面向LLM应用输出长期记忆、信息检索以及智能遗忘等基础设施能力。当这两者被放进同一个工程项目，会产生怎样的结果？
一位受邀参与GLM-5.2长程任务执行测试计划的开发者，在智谱与AGI Bar联合举办的活动上分享了一个内测case。恰巧其手上的Agent平台项目需要使用OceanBase PowerMem的TypeScript版本SDK，但查阅PowerMem的GitHub仓库后可以确认，TypeScript SDK的迭代节奏落后于Python SDK。由此产生了一个天然的测试命题：让GLM-5.2去完成PowerMem从Python SDK到TypeScript SDK的功能拉平，补齐滞后的迭代进度。
PowerMem为何适合作为长程任务试金石
PowerMem覆盖的能力面相当宽，而每一项能力背后都对应一块独立的工程模块。具体包括长期记忆的存储、检索、更新、删除以及批量管理；SourceStore来源管理与SkillStore技能管理；以艾宾浩斯曲线为依据的智能遗忘机制；面向多Agent协作的Scope与Permission控制；HTTP server与Dashboard可视化能力；以及对向量、全文、图、时间四类信号的混合检索。
在多语言SDK层面PowerMem铺得较广，官方维护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提供一次完整的功能复盘与对齐。
任务边界如何划分：翻译与对齐必须分清
真实工程case确定后，接下来的问题是怎样起步。为了便于模型上手，需要将其转化为一份模型能够承接的工程任务：从哪个仓库出发、允许修改哪些内容、禁止触碰哪些内容、最终交付物包含什么、哪些行为必须保留，这套边界定义得越清楚，模型表现才越能被客观评审。
就PowerMem这个任务而言，主要涉及两个仓库：upstream-powermem，即Python主仓库，只可只读参考、不允许修改，它是行为来源；candidate-powermem-ts，即TypeScript候选仓库，是模型的主要修改对象，必须保留现有项目结构与API风格。
在此基础上还规定了几条核心要求：读懂Python主仓库中PowerMem的行为；读懂TypeScript当前实现与已有测试；识别TypeScript已有能力以避免重复实现；建立Python API到TypeScript API的行为mapping；对关键差异补充实现、测试或者known-gaps；编写Vitest parity tests，用测试来证明行为对齐；保证type-check、test、build、lint等结果可以复现；输出迁移文档与最终报告。
这次case里最容易踩的坑，是把任务理解成单纯的“翻译”。其真正目标在于行为对齐：某个API在Python里的真实行为是什么，TypeScript里是否实现，如果已经实现其行为是否等价，若不完全等价应当改代码、补测试还是记录为差异，若需要修改是否能够最小改动而不破坏现有架构。每一步都是判断题。
评测设计层面也需要提前布局。如果只观察最终仓库，很容易落入两个对称陷阱：模型可能把环境历史问题包装成自己修复的业务bug，也可能反过来让环境问题被算到模型头上。因此评测不能只看终态，必须提前埋下过程观察点和隐藏验收点。
正式测试前先要记录baseline。PowerMem候选仓库在baseline阶段的type-check、test、build均为失败状态，但失败原因来自npm安装不完整以及Windows上npm optional dependency的问题，不是候选代码本身的缺陷。这份baseline记录可以挡住一种常见评测误差：把环境历史问题算成模型的成绩或过错。
与此同时还埋下一批隐藏验收点：是否误改Python主仓库；是否从零重写TypeScript仓库；是否识别TypeScript已有核心实现；是否依赖真实API Key；是否存在known-gaps；是否保留TypeScript API风格；需求变更时是否做增量修改；故障修复时是否最小修改；是否具备PR级交付意识；是否区分baseline问题与候选实现问题。这些点不会提前告知模型，而会在最终审查中逐项确认。长程任务里最危险的通常不是写错一行代码，而是方向漂移、无谓重写、掩盖失败、改动范围失控，以及把环境问题与业务问题混在一起。
七轮推进：核心SDK对齐在前，深度功能与文档收尾在后
整个任务按阶段推进，每一阶段对应一个明确的子目标，除作为模型的工程检查点外，也便于后续评审分阶段复盘。全部过程分为七轮，大致可分为两段：R1到R3偏向核心SDK的行为对齐，工程纪律优先；R4到R7偏向深度功能与文档收尾，复杂度和稳定性成为重点。
R1到R3最能检验模型能否“正确起步”。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一处，其余主要是新增测试、文档与示例，改动规模出乎意料地小。
R2属于需求变更，要求复核addBatch、getAll、count、deleteAll、reset五个批量API，并明确不重写、不删除。模型先审计已有状态，判断这些API在第一轮已经覆盖，第二轮的重点不是再次修改业务代码，而是补测试与文档。于是R2业务代码为零改动，只追加22个batch parity tests，并更新了migration文档与最终报告。
R3是一次故障修复，属于临时加入的轮次。R1、R2之后发现了一些问题，例如api-mapping文档中关于getAll默认order的描述自相矛盾。重新审核后，模型将其归类为“文档与代码不一致”而非实现问题，最终只修改文档中的相关行，没有触碰业务代码，也没有删除测试。前三轮没有一上来就推倒重来，而是先审计、后判断、再做最小改动，这在长程工程任务中属于相对严格的规范行为。
R4深水区：183个源文件对80多个源文件的逐项审计
从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”的坑。
R5是整个任务中代码复杂度最高的轮次，从“补丁式修改”正式进入“新增实现”阶段。R4生成的差异矩阵在此化为施工图纸，每一行“未实现”或“部分对齐”都要落到真实代码上。这一轮新增的模块横跨多个技术域：存储抽象与参考实现类的SourceStore/SkillStore、数值计算类的EbbinghausAlgorithm、LLM驱动的SkillManager、语义对齐类的ScopeController与PermissionController，以及走HTTP协议的HttpMemoryClient。每块的实现风格、测试方式、外部依赖都不相同，却要在同一轮里同时推进，模块之间还需保持接口与数据流连贯。
复杂度不仅在于模块数量，更在于每个模块背后都有判断题：哪些能力直接照搬Python并不现实，需要重新设计抽象层；哪些行为必须做数值对齐而非逻辑对齐；哪些测试不能依赖真实外部服务，必须把LLM、fetch、数据库等依赖全部注入化。这一轮跑完后，最终测试达到649 passed / 2 skipped / 0 failed，比R4之前多出几百个case；整个仓库的真实实现占比提升到约92%，stub压到约8%。剩余stub集中在OceanBase原生能力与少量高层串联API上，而且这些缺口都被显式记录在known-gaps里，既没有藏在代码注释中，也没有被忽略。
R5完成后，R6负责文档收尾。其中一个细节值得注意：模型没有只写“能力已完成”，而是同步修正README、api-mapping、python-ts-parity、known-gaps，让文档说明与代码状态保持一致，并明确标注OceanBase真实集成仍属于后续PR。R7则站在评审者视角，复查那些“声称实现”的能力是否真有代码支撑、测试是否真正覆盖、文档中是否还有过时描述，最终给出PASS，并建议进入dashboard人工验收。
从最初的baseline记录到R7 final收官，七轮跑下来总跨度大约4小时37分钟。这也是长程任务常见的形态：并非一次完成，而是在多个阶段里不断扩大范围、处理变更、修补文档债、补充测试证据，最终形成一个可审查的闭环，这些过程记录也是后续结果与交叉评审的依据。
最终结果：649项测试通过与可验证的证据链
这次任务最终可验证的结果包括：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 tests合计189个case；API surface完整度约98%；真实实现占比约92%，stub约8%。这些数字背后均有据可查，日志、测试输出、diff、最终报告与观察日志可以互相印证。除可验证数据之外，GLM-5.2在任务过程中还持续产出完成情况报告，记录每一轮做了什么、改了哪些文件、跑了哪些命令、哪些测试通过、哪些能力尚未完成，以及后续PR应如何拆分。这既是模型对自身工作的交付，也是后续交叉评审的素材基础。
由于让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的部分高级方法，也仍未完全对齐。这些情况都在报告中如实列出，但并不影响整体结论：评价虽高，却又明确留有后续工作。
结论与启示：模型价值不只在写了多少代码
这次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这次的表现更接近后者。
落在PowerMem项目自身，这次case也让人对其有更深认识。Python SDK的高活跃度体现了项目的工程推进力；TypeScript SDK虽更新节奏放缓，底子依旧扎实，核心抽象没有走偏。一个在停滞一段时间后仍能被模型快速理解并扩展的代码库，本身就说明PowerMem早期的架构设计经得起时间检验。
落在GLM-5.2这个模型上，1M上下文在跨仓库任务中的作用相当明显。此类任务需要同时持有Python仓库的行为规范、TypeScript仓库的当前实现、配置系统状态、测试覆盖情况、文档历史债、多轮需求变更等信息，只有将其放进同一个上下文窗口，才能做出连贯的工程判断，这对国内做Agent应用的开发者是一个相当实际的利好。
这次长程任务评测也提供了一个值得借鉴的样本。一个高质量的长程任务评测不应是“丢给模型一个超长prompt然后等结果”，而应提前设计好baseline、隐藏验收点、阶段化检查点、过程日志。脚手架越扎实，模型的真实能力越能被测出来，分数也越有参考价值。总体来说，在这次PowerMem从Python到TypeScript的长程功能对齐任务中，GLM-5.2表现相当不错：既展现了稳定的长上下文跟踪能力，也展示了阶段化规划、工程边界控制、最小增量修复、证据化测试、风险诚实记录等一系列能力。
小结：在此次约4小时37分的七轮长程任务中，GLM-5.2未重写代码库，而是以最小改动完成PowerMem TypeScript SDK行为对齐，最终649项测试全部通过、API完整度约98%、真实实现占比约92%。其表现说明，大模型在长程工程任务中的价值正从代码产出量转向判断力与证据链，而扎实的评测脚手架是检验这一能力的前提。
PowerMem Python SDK仓库：https://github.com/oceanbase/powermem
PowerMem TypeScript SDK仓库：https://github.com/ob-labs/powermem-ts
智谱GLM-5.2模型HuggingFace开源地址：https://huggingface.co/zai-org/GLM-5.2