TencentCloud/TencentDB-Agent-Memory

OpenClaw Version | OpenClaw 版本 此 issue 基于 feat/server_team 分支源码提出，与 OpenClaw 版本无关。 Plugin Version | 插件版本 TencentDB-Agent-Memory / feat/server_team 分支（MemoryCore + MemoryPanel） Operating System | 操作系统 macOS 15 (Darwin 25.6.0) System Specification | 系统配置 MacBook AIR M1 Describe the bug | 问题描述 移除团队成员或删除用户后，该用户名下的 Agent 会成为孤儿 Agent：owner_user_id 悬空，且 Agent 删除是严格 owner-only，任何角色（包括 system_admin / team admin）都无法删除它。 会导致以下问题： Panel 的 Agents 列表不做权限过滤，孤儿 Agent 对全团队可见，owner 标签无法解析； 其名下 skill 同样卡死（skill/delete 同样要求 caller 是 agent owner）； 前端 canManageAsset 对 team admin 返回 true 并渲染删除按钮，但点击后始终 403 —— UI 与内核授权不一致； 无任何 GC / ownership transfer 机制，唯一逃生通

OpenClaw Version | OpenClaw 版本 none Plugin Version | 插件版本 agentmemory/memory-hub:latest (2026-08-25 or newer) Operating System | 操作系统 macOS Sonoma (Darwin 25.5.0) / Docker Desktop System Specification | 系统配置 M4 Ultra, 48GB Describe the bug | 问题描述 When ingesting a large batch of documents (700 markdown files) into a TencentDB wiki, the ingestion pipeline completes successfully, but the wiki asset metadata is never committed to the database. The asset exists on disk but is unretrievable via the API. To Reproduce | 复现步骤 Create wiki via API: curl -X POST http://localhost:8424/v3/wiki/create \ -H "Content-Type: application/json" \ -H "x-tdai-service-id: default" \ -d '{ "service_id": "default", "team_id": "test-team-123", "name": "Test Wiki" }' Response: {"data":{"wiki_id":"wiki-abc123"}} Upload files in batches (10 files per batch, as per API limit): curl -X POST http://localhost:8424/v3/wiki/raw/write -H "Content-Ty

Environment TencentDB Agent Memory: current feat/server_team MemoryPanel with a MemoryCore deployment where SkillCore is not enabled Operating system: Linux (container deployment) Root cause POST /api/v1/agent/delete-cascade always calls /v3/skill/list before archiving an Agent. When SkillCore is not configured, MemoryCore returns the explicit capability-absence envelope code=404, message="Skill module not enabled". MemoryPanel forwards that response and never reaches /v3/meta/agent/archive, even for an Agent with no Skills. Reproduction Run MemoryPanel against a MemoryCore instance without SkillCore enabled. Create an Agent owned by the caller and do not attach any Skills. Call POST /api/v1/agent/delete-cascade with that Agent ID. Observe 404 Skill module not enabled; the Agent remains active. Directly calling the retained /api/v1/meta/agent/archive escape hatch succeeds, which confirms the failure is in the cascade control route. Expected behavior The cascade route should treat o

Bug Description meta_assets.usage_count 与 meta_assets.last_used_at 两个字段是死字段：无论 skill 被读取多少次，计数恒为 0、时间恒为空。实测全量 513 个资产全部为 0。面板若展示该列会恒定显示 0（误导运维/审计）。 Steps to Reproduce 通过 /v3/skill/get 连续读取同一 skill 2 次（HTTP 200） 查询 metadata.db → meta_assets.usage_count 观察到 usage_count 仍为 0，last_used_at 为空（本环境 513/513 全部如此） Root Cause 线索 在 standalone 网关路径上，skill 读取（/v3/skill/get 等）未调用 onSkillAccessed 钩子去更新 meta_assets 的 usage 字段，源码注释中已隐含承认该路径缺这一落库动作。对比：vectors.db 的 memory_audit 表在 L2/L3 记忆每次 update/delete 都会落审计行、机制完整——唯独 skill 读取审计缺失。 Expected Behavior skill 被成功读取时，应更新对应 meta_assets 行的 usage_count(+1) 与 last_used_at(当前时间)，使

OpenClaw Version | OpenClaw 版本 N/A(本机未使用 OpenClaw,直接通过 memory-proxy 部署) Plugin Version | 插件版本 memory-proxy agentmemory/memory-proxy:latest(2026-08-21 拉取) Operating System | 操作系统 Windows 11(部署端:Windows + Docker Desktop;客户端:CodeBuddy CN Windows 版) System Specification | 系统配置 No response Describe the bug | 问题描述 更新了最新的版本后，通过 CodeBuddy 自定义模型接入 memory-proxy(/codebuddy/default/v1/chat/completions)时,session-init 的 ask_followup_question 表单无法渲染。CodeBuddy 客户端报错: Error calling tool: Tool call arguments for ask_followup_question were invalid: invalid argument type for questions, expected array, received string 排查发现 MemoryProxy/src/session/codebuddy/form.ts 的 buildFollowupQuestionArgs() 将选项列表做了一层 JSON.stringify: function buildFollowupQuestionArgs(data: FormData): { title: string; questions: string } { ... return { title, questi