GLM-5.2 这次碰到的不是一道问答题，而是一类真实工程任务：把 PowerMem 从 Python SDK 到 TypeScript SDK 的功能差距补齐。这个 case 有意思的地方在于，它天然带着长程任务的几个硬指标：要读旧实现、识别缺口、迁移接口语义、补测试，还要控制迭代节奏不失控。
长程任务难在“持续保持上下文”
SDK 功能拉平不是简单翻译语言。Python SDK 里已经存在的能力，往往包含三层信息：
- 对外 API 的命名、参数、返回结构
- 内部请求拼装、错误处理、重试、分页等行为
- 测试用例里隐含的兼容性约束
让模型处理这类任务，真正考验的是它能不能在多文件、多轮修改里保持目标不漂移。比如 Python 端有 memory.create()、memory.search()、memory.delete()，TypeScript 端可能只实现了前两个；模型需要发现缺口，而不是只在当前打开的文件里补几行代码。
这也是 GLM-5.2 长程任务测试的价值所在：它不是看模型能不能写一个漂亮函数，而是看它能不能像工程师一样把一个滞后的 SDK 版本追上来。
功能拉平应该按“契约”推进
做跨语言 SDK 对齐时，最稳的方式不是从实现开始，而是先把契约列出来。可以把 Python SDK 当作事实来源，整理一张能力矩阵：
| 能力 | Python SDK | TypeScript SDK | 状态 |
|---|---|---|---|
| 创建记忆 | 已有 | 已有 | 对齐参数和返回值 |
| 搜索记忆 | 已有 | 部分已有 | 检查分页、过滤条件 |
| 删除记忆 | 已有 | 缺失 | 需要补实现和测试 |
| 错误处理 | 已有 | 不完整 | 对齐异常语义 |
这个矩阵能防止长程任务变成“边写边猜”。对 LLM 来说，它也是一个外部工作记忆：每完成一项就更新状态，避免在后半程遗忘前面的判断。
可以这样实践：让 Agent 先生成差距报告
下面是一个可改造的提示词模板，适合用于代码代理或具备仓库访问能力的 LLM。把仓库路径、SDK 目录按你的项目替换即可。
你是一个负责 SDK 兼容性的资深工程师。请比较 Python SDK 与 TypeScript SDK 的公开能力，并输出差距报告。
仓库结构假设：
- Python SDK: packages/python/powermem
- TypeScript SDK: packages/typescript/src
- Python 测试: packages/python/tests
- TypeScript 测试: packages/typescript/test
任务：
1. 列出 Python SDK 暴露的公开类、函数、方法。
2. 找出 TypeScript SDK 缺失或行为不一致的 API。
3. 对每个差距给出：文件位置、期望行为、建议实现、需要补充的测试。
4. 不要直接修改代码，先输出 Markdown 格式的差距报告。
输出格式：
- Summary
- API Parity Matrix
- Missing APIs
- Behavior Differences
- Proposed Implementation Order
- Test Plan
如果模型直接进入编码，很容易补到一半才发现类型设计不对。先生成差距报告，可以把任务拆成可审查的小块，也方便人类工程师把关。
可以这样实践：用测试锁住 TypeScript SDK 语义
假设 Python SDK 已经支持创建、搜索、删除记忆，而 TypeScript SDK 正在补齐。可以先写一个最小的 TypeScript 测试骨架，让 Agent 按测试补实现。
下面示例使用 vitest，接口名称是演示用的。运行前需要把 PowerMemClient 的导入路径、服务地址和 token 改成你项目里的真实值。
npm install -D vitest typescript tsx
npx vitest run
// test/memory.parity.test.ts
import { describe, expect, it } from "vitest";
import { PowerMemClient } from "../src/index";
const client = new PowerMemClient({
baseUrl: process.env.POWERMEM_BASE_URL ?? "http://localhost:8080",
apiKey: process.env.POWERMEM_API_KEY ?? "test-token",
});
describe("PowerMem TypeScript SDK parity", () => {
it("creates, searches, and deletes a memory", async () => {
const created = await client.memory.create({
userId: "user-sdk-parity",
content: "GLM-5.2 is being tested with a long-horizon SDK parity task.",
metadata: { source: "parity-test" },
});
expect(created.id).toBeTruthy();
expect(created.content).toContain("GLM-5.2");
const results = await client.memory.search({
userId: "user-sdk-parity",
query: "long-horizon SDK parity",
limit: 5,
});
expect(results.items.length).toBeGreaterThan(0);
expect(results.items[0]).toHaveProperty("id");
await client.memory.delete(created.id);
const afterDelete = await client.memory.search({
userId: "user-sdk-parity",
query: "long-horizon SDK parity",
limit: 5,
});
expect(afterDelete.items.some((item) => item.id === created.id)).toBe(false);
});
});
这个测试不追求覆盖所有边界，但它有两个价值：一是把“功能拉平”变成可执行标准；二是让模型每次改动后都能得到明确反馈，而不是靠自然语言判断是否完成。
对长程 Agent 任务的工程约束
让 GLM-5.2 这类模型承担长程工程任务时，建议把控制点放在三个位置：
- 入口要清楚：给它明确目录、目标 SDK、参考 SDK 和验收标准。
- 中途要收敛：要求先输出差距报告，再分批修改，不要一次性吞完整仓库。
- 结果要可验证：每个补齐项都要有测试、类型检查或最小运行命令。
也要看到边界。LLM 可能会把 Python 的动态语义机械搬到 TypeScript，导致类型设计别扭；也可能补了 happy path，却漏掉错误码、超时、分页和兼容性行为。长程能力强，不等于可以跳过 code review。
落地检查清单
如果你也想用 SDK 拉平来测试或使用长程模型，可以按这个顺序推进：
- 固定一个权威来源，例如 Python SDK。
- 生成 API parity matrix，并人工确认。
- 先补公开类型和接口签名，再补内部请求逻辑。
- 每个 API 至少配一个 TypeScript 测试。
- 对齐错误处理、分页、重试和序列化细节。
- 跑
npm test、npm run typecheck，必要时再做端到端验证。
PowerMem 这个任务之所以适合作为 GLM-5.2 的长程测试，不是因为它看起来复杂，而是因为它足够真实：目标明确、上下文分散、验收可执行。能把这种任务稳定做完，才说明模型开始接近工程团队真正需要的那类能力。