Tu Naichao c86071442c
fix(memory): truncate mem0 context injection on entry boundaries (#4600)
* fix(memory): truncate mem0 context injection on entry boundaries

Mem0Manager.get_context built the injection block and then hard-cut it
at max_injection_chars, which could sever the last memory mid-line and
leave a dangling partial entry in the agent prompt.

Accumulate whole entries against the remaining budget instead: a
memory that does not fit is skipped (a shorter later one may still
fit). When not even the first memory fits, fall back to the previous
hard-truncation behavior for that single entry rather than injecting
nothing.

Tests: entry-boundary truncation, skip-oversized-keep-later, and the
oversized-first-entry fallback.

* fix(memory): keep entry-boundary guarantee when no mem0 memory fits

Follow-up to PR #4600 review: remove the hard-truncation fallback that

could inject a partial memory when max_injection_chars is smaller than

every recalled entry. Instead return empty context and log a warning that

surfaced the undersized budget.
2026-07-31 22:16:56 +08:00
..

mem0 memory backend

Uses mem0 (Platform hosted API, or any API-compatible self-hosted server) as DeerFlow's memory store. Fully stateless in-process: dedup, fact extraction, and storage are server-side, so it is safe for multi-worker Gateway deployments.

Configuration

memory:
  enabled: true
  injection_enabled: true
  manager_class: mem0
  mode: middleware            # or "tool"
  backend_config:
    api_key_env: MEM0_API_KEY          # key read from env, never in config.yaml
    base_url: https://api.mem0.ai      # or your self-hosted mem0 server
    allow_insecure_http: false         # true only for trusted local HTTP dev
    top_k: 8
    score_threshold: 0.1
    max_injection_chars: 12000
    timeout_seconds: 10
    startup_policy: fail_fast          # fail_fast | tolerate
    failure_policy:
      read: fail_open                  # fail_open | fail_closed
      write: log_and_drop              # log_and_drop | raise

Set the key in the environment: export MEM0_API_KEY=...

base_url must use HTTPS because every request carries the API key. For a trusted local-development server that only exposes HTTP, opt in explicitly with allow_insecure_http: true; do not use that setting across an untrusted network.

Identity mapping

DeerFlow mem0
user_id user_id
agent_name agent_id
thread_id run_id

Limitations

  • mode: middleware recall is query-less (the get_context contract carries no query): the bucket's most recent top_k memories are injected. For query-aware semantic recall use mode: tool.
  • mode: tool retains the passive per-turn write middleware for this backend, because mem0 extracts and deduplicates facts from conversations through add(). The agent still gains query-aware memory_search, while new conversations continue accumulating memory even though fact CRUD is not available.
  • Fact CRUD, import_memory, and Settings-page memory editing are not implemented (gateway returns 501). DeerMem remains the default backend.
  • No migration of existing DeerMem data.
  • log_and_drop write policy is at-most-once: a failed write is dropped.
  • memory_add/memory_update/memory_delete are backed by fact CRUD, which this backend does not implement; they return a clear unsupported-operation error. Conversation writes still happen through the retained middleware.

Async execution and failure behavior

The mem0 HTTP client is synchronous for compatibility with the MemoryManager contract. DeerFlow offloads it at every async boundary: the async middleware uses the manager's a* methods, and Gateway memory routes run sync management calls in worker threads. A slow mem0 request therefore does not block unrelated ASGI handlers or SSE heartbeats.

failure_policy.read: fail_open logs a recall failure and continues without new memory context. fail_closed propagates the backend error through prompt construction and aborts the run instead of silently degrading.