[feat] add Dify memory adapter

[bugkeep]

Motivation

Add a Dify platform adapter for TencentDB Agent Memory so Dify workflows can call the existing Gateway/Core memory pipeline instead of reimplementing memory behavior.

Related upstream issue: TencentCloud#235.

Changes

• Added dify-plugin-tdai-memory with Dify tool provider metadata and Python tool implementations for health, recall, capture, memory search, conversation search, and session end.
• Added a Gateway + mock Dify quickstart e2e script for capture, immediate read-back, and recall smoke testing.
• Documented tdai_conversation_search as the adapter's immediate L0 read path; tdai_recall remains the structured recall path.
• Added Dify workflow diagram, cross-platform comparison, adapter architecture notes, and package/install guide.
• Fixed provider icon packaging metadata to match Dify CLI package validation.
• Added a minimal GitHub Actions workflow for Dify plugin tests and manifest/package layout checks.

Validation

• python -m unittest discover -s dify-plugin-tdai-memory\tests (Ran 54 tests, OK)
• Dify CLI package validation: dify plugin package ./dify-plugin-tdai-memory
• Real quickstart e2e:

[1/5] Starting or reusing TencentDB Agent Memory Gateway at http://172.23.224.1:8424
Gateway already healthy
[2/5] Starting mock Dify plugin server at http://127.0.0.1:18420
[3/5] Capturing a completed Dify turn through tdai_capture
{"l0_recorded": 2, "ok": true, "scheduler_notified": true}
[4/5] Validating immediate L0 read-back through tdai_conversation_search
{"ok": true, "results": "Found 2 matching message(s): ... TDAI_DIFY_E2E_TOKEN_20260705091935-960 ...", "total": 2}
[5/5] Recalling memory through tdai_recall
{"context": "", "memory_count": 0, "ok": true}
Quickstart e2e succeeded: Gateway -> mock Dify server -> capture -> conversation_search (L0 read-back) -> recall

• Local Dify package/install against Dify 1.15.0 + plugin daemon 0.6.3-local:

plugin packaged successfully output_path=/tmp/tdai_memory_0.0.1.difypkg
package size: 19227 bytes
upload unique_identifier: tencentdb-agent-memory/tdai_memory:0.0.1@83c5476576a25586fc2223f0cd9cadf7331cfc3b52719b983039528a9ebab872
install task: status=success, message=installed

• Dify plugin runtime invocation path verified:

Dify API -> plugin_daemon -> tdai_memory Python plugin -> TencentDB Agent Memory Gateway

tdai_health: ok=true, status=ok, vectorStore=true
tdai_capture: ok=true, l0_recorded=2
tdai_conversation_search: ok=true, total=2, immediate L0 read-back token=TDAI_DIFY_E2E_TOKEN_20260704_SKYBLUE
tdai_recall: ok=true, memory_count=0 (structured recall path may still be empty immediately after capture)

Notes

For local unsigned package installation in Dify, FORCE_VERIFYING_SIGNATURE=false was used in the local plugin daemon. Production deployments should keep signature verification enabled unless the package is signed and trusted.

[bugkeep]

Superseded by upstream PR: TencentCloud#394

The branch name was changed to feat/dify-memory-adapter and the old codex/* branch PR was closed.

[bugkeep]

补一条更严格的 Dify read-back 验证（2026-07-05，本地 Dify + 真实 plugin invoke）：

• Gateway: http://host.docker.internal:8432
• Session: strict-recall-20260705-5
• Marker: TDAI_STRICT_RECALL_20260705_COBALT

tdai_capture           -> {l0_recorded: 2, ok: true, scheduler_notified: true}
tdai_conversation_search -> 找到 2 条带 marker 的原始对话
tdai_session_end       -> {flushed: true, ok: true}
tdai_memory_search     -> 找到 1 条 persona memory:
                          用户偏好使用 Go 语言开发后端服务，并通常部署在 Kubernetes 集群上。
tdai_recall            -> {memory_count: 1, ok: true, ...}

关键点是这次 tdai_recall.context 已经不是空串，也不是只带静态 guide，而是直接包含：

<relevant-memories>
以下是当前对话召回的相关记忆，不代表当前任务进程，仅作为参考：
- [persona|我和用户讨论如何记住他的技术偏好] 用户偏好使用 Go 语言开发后端服务，并通常部署在 Kubernetes 集群上。
</relevant-memories>

这条验证覆盖了真实 Dify 插件路径下的 L0 capture -> session_end flush -> L1 memory_search -> recall context read-back。

[bugkeep]

补充一组 L1 / L2 / L3 的真实实证（2026-07-05，本地 Dify + 真实 plugin invoke，Gateway http://host.docker.internal:8432，session=strict-recall-20260705-5）。

L1 evidence

Dify 工具链路：

tdai_capture             -> {"l0_recorded": 2, "ok": true, "scheduler_notified": true}
tdai_session_end         -> {"flushed": true, "ok": true}
tdai_memory_search       -> 命中 1 条 persona memory

SQLite 实际落库：

{
  "counts": { "l0": 2, "l1": 1 },
  "l1Rows": [
    {
      "type": "persona",
      "priority": 90,
      "scene_name": "我和用户讨论如何记住他的技术偏好",
      "content": "用户偏好使用 Go 语言开发后端服务，并通常部署在 Kubernetes 集群上。",
      "updated_time": "2026-07-05T04:33:31.647Z"
    }
  ]
}

Gateway log also shows:

[l1-extractor] Extraction complete: extracted=1, stored=1
[pipeline-factory] [l1] L1 complete: extracted=1, stored=1 (1 group(s))

L2 evidence

本次同一 session 生成了 scene block 和 scene index：

scene_blocks/Go后端开发-技术栈.md
.metadata/scene_index.json

Checkpoint / logs:

scenes_processed = 1
last_extraction_time = 2026-07-05T04:33:48.389Z

Gateway log:

[pipeline-factory] [L2] Incremental query returned 1 record(s)
[extractor] extract() completed: 1 memories processed
[pipeline-factory] [L2] Extraction complete: processed=1, latestCursor=2026-07-05T04:33:31.647Z

L3 evidence

本次同一 session 生成了 persona.md，checkpoint 也推进了 persona 状态：

last_persona_at = 2
last_persona_time = 2026-07-05T04:33:59.049Z
memories_since_last_persona = 0

Gateway log:

[trigger] Trigger P2 (cold start)
[pipeline-factory] [L3] Starting persona generation
[persona] Persona written (3403 chars)
[pipeline-factory] [L3] Persona generation succeeded

Dify-visible read path after L3

重新从 Dify 调 tdai_recall(query="Go Kubernetes")，返回摘要：

{
  "ok": true,
  "memory_count": 1,
  "strategy": "hybrid",
  "context_length": 2013,
  "has_relevant_memories": true,
  "has_user_persona": true
}

也就是说，这里不只是后台把 L2/L3 文件写出来了，tdai_recall 的实际返回已经把：

• L1: <relevant-memories>
• L3: <user-persona>

一起带回给 Dify / LLM 使用。