TencentDB Agent Memory 面板能做哪些操作：从路由与菜单反推

2026-08-16

想知道一个管理面板能做哪些操作，最省事的办法是翻 README 里那张功能表。但功能表是写给人看的宣传口径，路由表是写给浏览器看的执行口径，两者不是一回事。TencentDB Agent Memory 的 MemoryPanel 恰好把这个差距摆得很清楚：根 README_CN.md:206-214 有一张五行的玩法表（组队、资产背包、Agent Loadout、Knowledge 工坊、权限控制），而前端路由文件里注册的页面只有 8 条。

这篇就按「路由 → 菜单 → 前端 API → 后端端点」四层往下扒，看看这个面板在代码层面究竟暴露了哪些操作。先声明前提：本文所有事实来自仓库 feat/server_team 分支（这是该仓的默认分支，不是 main 也不是 master）2026-08-16 的快照，MemoryPanel/package.json 里的版本是 0.1.0，仓库主模块处于 beta 阶段，接口与常量随时可能变动。我们没有部署、没有启动、没有登录过这个面板，所以下文不会出现任何关于界面长相和操作体验的描述。

第一层：8 条路由，就是面板的全部页面

MemoryPanel/web/src/routes/index.tsx:18-33 用 createHashRouter（:39，注释说明是为兼容旧版 hash 路由、避免刷新 404）注册了 8 条子路由：

路径	页面组件
`/`（index）	`WorkbenchPage`
`/wiki`	`WikiPage`
`/code`	`CodePage`
`/skills`	`SkillsPage`
`/memory`	`ChatMemoryPage`
`/team/members`	`MembersPage`
`/team/agents`	`AgentsPage`
`/team/api-keys`	`ApiKeysPage`

菜单侧完全对得上：MemoryPanel/web/src/constants/menu.tsx:19-27 的 PageId 也是 8 个（workbench_board / wiki / code / skills / chat_memory / team_members / team_agents / api_keys），分组常量 GROUP_ORDER_KEYS = ['workbench', 'organization', 'assets']（:58）把它们归成工作台、组织与权限、资产管理三组，其中 workbench_board 标了 affix: true（:46）。

这一层能回答的问题是「有哪些入口」。把它和 README 的五行玩法表对齐会发现：组队对应 /team/members 与 /team/agents，资产背包对应 /wiki、/code、/skills、/memory 四页，Knowledge 工坊落在 /wiki 与 /code。而「Agent Loadout」和「权限控制」没有独立页面——它们是散在资产页里的动作，得往下一层找。

第二层：前端 API 调用面，才是动作清单

MemoryPanel/web/src/lib/api/ 下按对象分文件，每个文件导出的方法就是页面能发起的动作。挑几组直接相关的：

agents.ts：list / get / create / update / delete / getAssets / getFixedAssets / setFixedAssets
chat-memory.ts：teamAssets / agentFixed / myAgents / layer / setAgentFixed / allocate / unbind / create / patchScope / import / updateLayer / searchLayer
skills.ts：list / listByAgent / get / filesRead / create / delete / update / search / forkToAgent
users.ts：用户侧 list / get / create / createWithKey / delete，user-key 侧 list / create / revoke，配置侧 get / set / getAssetCapabilities / setAssetCapability

到这一层，「Agent Loadout」才有了具体落点：agents.ts 的 getFixedAssets / setFixedAssets、chat-memory.ts 的 allocate / unbind / setAgentFixed，就是给 Agent 绑记忆、解绑的那组动作。「权限控制」的落点是 chat-memory.ts 的 patchScope 和 knowledge 侧的可见性接口。

顺带一个容易被漏掉的对象：tasks.ts 里有 list / get / listWithAgents / create / update / delete / linkAgent / unlinkAgent 八个方法，但 8 条路由里没有任何一条叫 /tasks。也就是说，任务相关的动作在前端 API 层是有的，路由表里却没有对应的独立入口，两处状态就是这样。

第三层：后端注册了什么

MemoryPanel/src/panel/http/app.ts:15 把公开前缀统一挂在 /api/v1，:22-36 注册了七组路由（meta / skill / chat-memory / task / agent-overview / agent / knowledge），:52 有一条 GET * 静态兜底，把 /api/ 和 /health 之外的路径回落到 index.html。

按 api.post( / api.get( / app.get( 的字面量扫下来是 51 条带字面量路径的注册，另有 2 条通过变量注册（/knowledge/wiki/team-assets、/knowledge/code-graph/team-assets，见 MemoryPanel/src/panel/http/routes/knowledge/list-routes.ts:62-63），合计 53 条。分布很不均匀：Chat Memory 一个文件里就有 15 条（全在 MemoryPanel/src/panel/http/routes/chat-memory.ts，从 /chat-memory/team-assets 到 /chat-memory/search），Wiki 侧从 wiki/list 一路排到 wiki/raw/write，Code Graph 8 条（list / create / register-meta / get / sync / delete / search / explore），分配与可见性 5 条（allocate / unbind / agent-fixed / set-visibility / grant）。

这里有两处必须提醒，否则你会把端点数当成「操作数」：

其一，/api/v1/meta/* 和 /api/v1/skill/* 各自只占一条注册，实际是白名单透传。MemoryPanel/src/panel/api/meta-actions.ts 的 META_ACTIONS 数组我们数出 55 条，NOT_IN_SCOPE_PREFIXES = ['agent-fixed-asset/']（:92）对应 4 条，因此真正放行的 ALLOWED_PANEL_ACTIONS（:98-100）是 51 条；另一侧 skill-actions.ts:16-31 是 14 条，文件头注释也写「14 条，全部 POST」。一条路由后面挂着几十个 action，只数路由文件是数不出这部分的。

其二，53 条里有一条不是给人用的：POST /api/v1/knowledge/status-callback（callback-routes.ts:117）是 S2S 回调，注册时没有挂 validatePanelMetaHeaders，文件头注释自述原因是「S2S，无浏览器 session header」（:16）。数「面板能做什么」的时候别把它算进去。

另外，MemoryPanel/README.md:110-115 与 MemoryPanel/web/README.md:59-64 各列了 6 个 API 前缀（meta / skill / chat-memory / knowledge / agent-overview / agent），两份都没有列 /api/v1/task/*，而 app.ts:32 确实注册了 registerTaskRoutes，端点是 POST /api/v1/task/list-with-agents（task.ts:82）。这两处口径不一致，以我们实读的源码为准。

第四层：注册了 ≠ 现在能用

这是反推能力面时最容易翻车的一步。仓库里有相当多位置明写着「暂未开放」「演示阶段」「尚未稳定支持」，逐条照抄如下，不做任何延伸：

MemoryPanel/web/src/lib/api/base.ts:22-24 有 export const PANEL_CAPABILITIES = { assets: false } as const;，:18-20 注释说明为 false 时应展示「暂未开放」占位，不要发起注定 501 的请求。
meta-actions.ts:86-92 写「暂未开放给面板的 action 前缀……agent-fixed-asset/*（运行时固定注入绑定）仍暂不开放」；chat-memory.ts:5-6 写 asset/* 与 agent-fixed-asset/* 一期在 meta pass-through 里返回 501（NOT_IN_SCOPE）。
中文文案 web/src/i18n/zh-CN.ts:1148-1149 是「当前接口暂不支持，请刷新页面或联系管理员。」与「该能力当前暂未开放。」，分别对应 UNKNOWN_META_ACTION 与 NOT_IN_SCOPE。
web/src/pages/team/components/TeamManagementPanel.tsx:15-16 写「Agent owner 由后端在创建时固定为当前登录用户，暂不支持转交；Team 删除接口后端尚未稳定支持，本面板暂不提供」，对应文案在 zh-CN.ts:780-781。
web/src/pages/code/CodePage/components/code-constants.ts:23 写「暂不支持 SSH」；zh-CN.ts:233 写「该 Wiki 尚未加工完成（未 ready），暂不能分配到 Agent」。
web/src/pages/workbench/WorkbenchPage/components/workbench-utils.ts:13 写「Task 状态在演示阶段简化为二态：进行中 / 已完成」。
web/src/services/ 下有 5 个自述为 localStorage 的 store（账号表、Agent 模板、资产可配置范围、用户资产、用户资料），共用底座 storage-utils.ts，其 :12-13 原文是「这些 store 均为前端演示阶段的 localStorage 实现，后端上线后整批替换为 fetch 即可」。
ROADMAP_CN.md:46-47 在「记忆可编辑：L1 - L3 支持修改」一项下写「目前面板只能查看和删除，无法修正」；:59 写当前只提供按时间范围过滤记忆列表。注意 ROADMAP_CN.md:7 明写「路线图列出的是团队正在推进的工作，不是承诺，范围与时间可能调整」——路线图里的条目不能当成已有能力。

还有一处方向相反的差异：web/src/lib/api/auth.ts:45-54 定义并导出了 environmentBindingsApi，打 GET/POST/DELETE /api/v1/users/me/environment-bindings，我们在 MemoryPanel/src/ 下 grep environment-bindings 命中 0 次，也没找到调用它的页面组件。前端有定义、后端无注册，两处状态就是这样，我们不推断原因。

权限这一维，别从守卫文件里读

如果你想按角色反推「谁能做什么」，注意 web/src/components/RouteGuards.tsx 里定义的两个守卫（ResourceGuard、以及实际函数名为 MemberManageGuard 的那个）在 web/src/routes/index.tsx 的 8 条路由上我们一处都没找到接线——grep ResourceGuard|MemberManageGuard 只命中该文件自身。菜单侧唯一实际生效的按角色过滤是一行：web/src/layouts/ConsoleLayout.tsx:129 的 if (userRole === 'reviewer' && meta.id === 'team_members') continue;。

可见性的取值也要按层看：后端 knowledge/allocate-routes.ts:47 的 VALID_VISIBILITY 是 5 种（private / team / restricted / agent / task），前端类型 web/src/lib/api/types.ts:74 同样 5 种，根 README_CN.md:230-235 的表只列 4 种（没有 task），而 Chat Memory 侧前端只暴露二元 scope（patchScope 的入参是 'team' | 'private'，web/src/lib/api/chat-memory.ts:140）。同一个概念在四处的取值范围不同，写代码前先确认自己在哪一层。

至于跨 Agent 的「借入」，上限是硬编码的：MemoryPanel/src/panel/domain/chat-memory-governance.ts:16 的 MAX_IMPORTED_AGENTS = 2，而这层关系当前的持久化方式按同文件 :9-13 的注释是塞进 Agent.metadata_json 的 chat_memory namespace，注释自述「后端 schema 还没落 chat_memory_rel 真字段」，属于演示阶段的实现。

你可以自己复核的四个动作

想验证上面这些，不需要运行任何东西，clone 下 feat/server_team 分支静态读就够：

数页面入口：打开 web/src/routes/index.tsx 和 web/src/constants/menu.tsx，两处的条目数应当一致。
数动作：ls web/src/lib/api/，每个文件的导出方法就是该对象的动作清单。
数后端注册：在 src/ 下 grep api.post( / api.get( / app.get(，再单独看 src/panel/api/meta-actions.ts 和 skill-actions.ts 两份白名单——透传型路由的能力藏在数组里，不在路由文件里。
数「不能用的」：grep 「暂未开放」「暂不支持」「演示阶段」「尚未稳定」以及 NOT_IN_SCOPE、501。

最后提醒一句端口口径：src/panel/config/panel-config.ts:47 的 PORT 默认值是 8123、KNOWLEDGE_SERVICE_URL 默认 http://127.0.0.1:8421，而根 INSTALL_CN.md:222-236 里「只装 Memory Hub」的镜像映射的是 8125 与 8424。两套端口在仓库里并存，照哪一套走取决于你用哪条部署路径。

延伸阅读

从头读起：TencentDB Agent Memory 是什么：团队级 Agent 记忆中枢怎么读
本专题共 40 篇，完整分组目录见专题页
TencentDB Agent Memory 的隐私边界：那个三选一的读取授权判定
TencentDB Agent Memory 面板：admin 权限有两组完全相反的注释

本文依据 TencentDB Agent Memory 官方仓库（github.com/TencentCloud/TencentDB-Agent-Memory） feat/server_team 分支上的 README、INSTALL、CHANGELOG、ROADMAP 与四个模块的源码整理，核对日 2026-08-16，对应仓库快照 97f9465。该仓库的默认分支即为 feat/server_team。本文内容为仓库源码与文档口径，我们没有部署、也没有运行过该项目的任何一个模块，因此不涉及运行效果、检索质量与性能的任何描述。该项目主模块处于 beta 阶段、其余模块版本号仍为 0.1.0，参数与接口随版本变动，请以仓库最新内容为准。该项目会采集并存储团队的对话、文档与代码，属于敏感数据，是否使用请结合自身合规要求评估。安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。