feat(external-context): Out-of-the-box Mem0 provider with built-in protocol IDs #12596

Activity

1. yiliang114

   added

   type/feature-requestNew feature or enhancement requestNew feature or enhancement request

   scope/memoryMemory and context managementMemory and context management

   on Sep 24, 2026
2. doudouOUC commented on Sep 24, 2026

   

   doudouOUC

   on Sep 24, 2026

   Collaborator

   More actions

   Independent source verification against main — all three structural claims and the PolarDB top_k regression confirmed.

   1. The top_k-vs-limit regression in the shipped PolarDB preset — CONFIRMED

   This is the highest-value flag in the issue, so verifying it end-to-end:

   • At commit 5702f63 (the 2026-08-25 live PolarDB verification you cite), the adapter was the old Mem0OssAdapter, and its search() body sent the literal key limit (providers.ts @ 5702f63, the POST /v2/memories/search call):

     const body = { query: input.query, limit: input.limit, filters: { user_id: ... } };

   • The mem0-presets.ts file (which introduces the limitField: 'top_k' | 'limit' abstraction) did not exist yet at 5702f63 — contents/integrations/external-context/src/mem0-presets.ts?ref=5702f63 returns 404. It was introduced later, and the aliyun-polardb-mysql-2026-08 preset ships with limitField: 'top_k' (mem0-presets.ts:103-109).
   • Mem0CompatibleAdapter.search() (providers.ts:205-212) now builds the body from [this.preset.search.limitField]: Math.min(input.limit, MAX_PROVIDER_ITEMS) — so the PolarDB preset currently sends { ... "top_k": 5 } where the verified-good run sent { ... "limit": 5 }.
   • MAX_PROVIDER_ITEMS = 5 (providers.ts:46) is the only cap. If PolarDB silently ignores an unknown top_k, the 5-result cap simply stops being applied — exactly as you describe.

   So the regression is real: the field was renamed from limit → top_k for the PolarDB family without a recorded live run against the preset version. The design doc (docs/design/direct-external-context-mem0-presets.md:148) lists Limit: top_k for the PolarDB preset as a stated contract, but the only documented live evidence (5702f63) used limit. This needs a live Hologres/PolarDB check before mem0-v2 (which would inherit the same top_k default, per your direction-1 table) becomes the default.

   One additional nuance: Hologres was observed at /v2/memories/search/ with a trailing slash (#10634) while the PolarDB preset path is /v2/memories/search without the trailing slash (mem0-presets.ts:106). buildUrl (providers.ts:262-267) uses new URL(this.origin) + url.pathname = basePath + path verbatim — it does not normalize the trailing slash. Whether /v2/memories/search vs /v2/memories/search/ matters depends on the server (many Mem0 services redirect one to the other, some 404). Worth including in the live verification.

   2. Two implementations, neither installable — CONFIRMED

   • integrations/external-context/package.json has "private": true (line 5) — confirmed, this package is not npm-publishable as-is.
   • integrations/external-context-mem0/package.json has no private field (defaults to publishable) but also has no prepublishOnly/publish config and no provenance/signing step — consistent with "the bootstrap publish never happened," so @qwen-code/external-context-mem0 is not on npm.
   • Both are @qwen-code/* scoped, version 0.24.4, so a consolidated publishable package is a real convergence target, not a rename.

   3. Safety boundary + protocol-ID design — sound against source

   • The model-facing MCP surface stays context_search({ query }) (+ context_remember({ content })); endpoint/credential/scope are not in the tool schema — confirmed by applyMem0Scope (providers.ts:304-320) mapping userId/agentId/appId into user_id/agent_id/app_id strictly from config.scope, never from the request. The model cannot steer these.
   • No request templates / JSONPath / protocol probing in the search path — search() builds a fixed body shape from the preset, postJson, parse. No fallback across presets. Confirmed.
   • The immutable-protocol-ID design (MEM0_PRESET_IDS in types.ts:50-55, keyed by id not version) matches your direction-1 proposal — adding a mem0-v4 is additive, existing IDs unchanged. The current aliyun-polardb-mysql-2026-08/mem0-platform-v3/mem0-oss-rest-2026-08 → alias mapping is consistent with keeping them as aliases of mem0-v2/mem0-v3/mem0-oss-2026-08.
   • Auto recall opt-in/off-by-default: createMemoryWriter (providers.ts:24-33) returns the writer only when the preset has a write block AND config write.enabled/autoRecall is set — consistent with "writes only when explicitly enabled."

   Recommendation

   Before merging the mem0-v2 default:

   1. Live-verify the top_k field against a PolarDB and a Hologres Mem0 instance — if top_k is ignored, change aliyun-polardb-mysql-2026-08 and the new mem0-v2 preset's limitField to 'limit'. The verified-good evidence (5702f63) used limit; top_k has no recorded live run for the PolarDB family.
   2. Verify the trailing-slash /v2/memories/search vs /v2/memories/search/ on the same instances.
   3. Consolidation is straightforward from here — the preset abstraction (mem0-presets.ts) already carries the cross-flavor differences, so merging the dialect-file package into the preset package is mostly wiring + the npm bootstrap publish.

   The direction (protocol-not-vendor, immutable IDs, out-of-the-box, unchanged safety boundary) is well-aligned with the current source structure. The top_k regression is the one concrete blocker.