四组件拓扑与职责边界

文档摘要

四组件拓扑与职责边界本节摘要:四类资产需要四个组件来协同——记忆核心服务(管记忆的存与取)、知识服务(管 Wiki 与 CodeGraph 的构建)、记忆中枢(管人的治理与展示)、代理层(管让 Agent 零改造接入)。本节画出这四个组件的拓扑,逐个讲清它的端口、职责,以及同样重要的「它不做的事」——划清边界,避免把功能张冠李戴。理解了这张拓扑图,后续十一章里的每个细节你都能找到归属。一、四组件拓扑总览四个组件按「接入面 / 治理面 / 数据面」三层划分,能最快建立全局感: 一句话理解:Agent 从接入面进,数据面负责存与建,治理面负责人管。三个面各司其职,缺一不可。

四组件拓扑与职责边界

本节摘要:四类资产需要四个组件来协同——记忆核心服务(管记忆的存与取)、知识服务(管 Wiki 与 CodeGraph 的构建)、记忆中枢(管人的治理与展示)、代理层(管让 Agent 零改造接入)。本节画出这四个组件的拓扑,逐个讲清它的端口、职责,以及同样重要的「它不做的事」——划清边界,避免把功能张冠李戴。理解了这张拓扑图,后续十一章里的每个细节你都能找到归属。

一、四组件拓扑总览

四个组件按「接入面 / 治理面 / 数据面」三层划分,能最快建立全局感:


┌─────────────── 接入面(让 Agent 进来) ───────────────┐
│  代理层(8096)        官方 SDK(Python/TypeScript)    │
│  透明代理,改 baseURL   代码级集成,写四步              │
└──────────┬──────────────────────┬────────────────────┘
           │                      │
┌──────────▼──── 数据面(存与建)──▼────────────────────┐
│  记忆核心服务(8420)        知识服务(8421/8424)       │
│  L0-L3 存取 + 抽取           Wiki + CodeGraph 引擎     │
│  HTTP Gateway                                          │
└──────────▲──────────────────────▲────────────────────┘
           │                      │
┌──────────┴─── 治理面(人操作) ──┴────────────────────┐
│              记忆中枢 / 控制台(8125)                  │
│              团队/角色/资产/Loadout/工坊                │
└──────────────────────────────────────────────────────┘

一句话理解:Agent 从接入面进,数据面负责存与建,治理面负责人管。三个面各司其职,缺一不可。

二、逐组件:职责与「不做的事」

记忆核心服务(memory-core,8420)

这是整套系统的地基,负责记忆的存与取。

它做的事	它不做的事
L0-L3 四层记忆的存储与召回	构建 Wiki / CodeGraph(那是知识服务)
异步抽取 Pipeline(对话提炼成记忆)	面向人的可视化治理(那是控制台)
HTTP Gateway(对内对外的记忆 API)	直接接收 Agent 流量(那是代理层/SDK)
元数据管理(用户/团队/Agent/资产)

知识服务(memory-knowledge,8421/8424)

负责把文档和代码变成可查询的知识地图。

它做的事	它不做的事
Wiki ingest(文档→结构化页面+链接图谱)	存 Chat Memory(那是核心服务)
CodeGraph 索引(代码→符号/调用/影响)	直接面向 Agent 注入(经核心服务或代理层)
Auto-Sync(源变化时增量更新)	提炼 Skill(那是核心服务的抽取)

记忆中枢 / 控制台(memory-hub / panel,8125)

这是「人」操作整套系统的入口。

它做的事	它不做的事
团队与角色管理(System Admin/Team Admin/Member)	存记忆数据(它只展示与操作,数据在核心服务)
资产审核、分享、收回	自动决定召回内容(那是召回引擎)
Agent Loadout 装配	构建 Wiki/CodeGraph(它在工坊里「发起」,实际构建在知识服务)
Knowledge 工坊(发起构建、看状态)

代理层(memory-proxy,8096)

让成熟 Coding Agent 零改造拥有记忆的接入组件。

它做的事	它不做的事
拦截 Agent 请求,做八步处理	自己存长期记忆(它有本地存储抽象,但主记忆在核心服务)
召回注入(inject/toolize)	自己决定资产治理(权限规则来自核心服务)
对话回写(extract→喂给抽取)	替代 SDK(它是「不想改代码」时的接入方式)
限流 / 计费 / 可观测上报

⚠️ 注意:最常见的误解是把「控制台」当成「记忆数据的家」。控制台是操作台,不是数据库——它展示和操作的数据,真正存在核心服务里。这一点理解错了,会误以为「关掉控制台记忆就没了」,其实不会。

三、组件间的数据流向

四个组件不是孤岛,它们之间有清晰的数据流。以「Agent 问一个问题」为例:


Agent 发问
   │
   ▼
代理层(接入面):拦截请求
   │  ① 向核心服务召回记忆
   │  ② 向知识服务查 Wiki/CodeGraph(若 toolize)
   ▼
注入记忆后转发 LLM
   │
   ▼
代理层:收到 LLM 答复
   │  ③ 把对话回写给核心服务(extract)
   ▼
返回 Agent

(治理面:人通过控制台,随时管理核心服务与知识服务里的资产)

注意「召回」与「查知识」都是代理层主动发起的——它既问核心服务要 Chat Memory/Skill,也可能问知识服务要 Wiki/CodeGraph 片段。这条数据流的细节在第 8 章八步管道里逐段展开。

四、为什么是四个而不是一个

一个常见疑问:为什么不把四个组件合成一个大服务?答案在「关注点分离」与「独立演进」:

分离的关注点	由谁承担	为何不合并
记忆的存取与抽取	核心服务	抽取是 CPU/LLM 密集型,要独立扩展
知识的构建	知识服务	Wiki/CodeGraph 构建是重任务,不能拖慢记忆存取
人的治理	控制台	前端与治理逻辑变化快,要独立部署
Agent 接入	代理层	接入策略与限流计费是横切关注点,要可独立替换

💡 技巧:当你后续读到某个功能,先问「这是哪个组件的职责」。比如「召回」是核心服务,「构建 Wiki」是知识服务,「装配 Loadout」是控制台操作(数据落在核心服务),「改 baseURL 接入」是代理层。归对组件,理解就顺了。

本节要点回顾

三层划分:接入面(代理层/SDK)、数据面(核心服务/知识服务)、治理面(控制台),Agent 从接入面进、数据面存建、治理面人管。
核心服务:记忆地基,L0-L3 存取 + 抽取 + Gateway;不构建知识、不面向人。
知识服务:Wiki/CodeGraph 引擎;不存 Chat Memory、不直接注入 Agent。
控制台是操作台不是数据库:它展示操作,数据在核心服务;关掉它记忆仍在。
代理层:零改造接入 + 八步处理;不替代 SDK,不自己存长期记忆。
分离的好处:四组件各管一个关注点,可独立扩展与演进——这是工程上的关注点分离。

拓扑已建立,下一节我们跟踪一次完整的请求,看这四个组件在一次「记忆召回」里如何接力。