专家是角色滤镜，不是记忆分片：兼谈多设备同步的盲区

《WorkBuddy 七层实操笔记》系列第 8 篇 · 作者：当月光落下 · 首发于腾讯云开发者社区。 全系列基于一台真实机器的逐条实测，记录哪些机制符合直觉、哪些相反，以及每条结论是在踩过什么坑之后才成立的。 系列目录：

1. 七层能力模型：把 AI 助手从「能用」拆到「会搭」
2. 信息该放哪：七个存放位置与一条晋升阶梯
3. 技能装了却不被调用：触发机制与四十条清单上限
4. 让 AI 够得着外部数据：连接器、MCP 与一次自建实践
5. 资料库不是网盘（上）：七种节点、三层 block 与 database
6. 资料库不是网盘（下）：page 发布、检索与 doc 修订流
7. 到点自己干活：自动化的三条执行链与五条军规
8. 专家是角色滤镜，不是记忆分片：兼谈多设备同步的盲区 ← 本篇
9. 四十一条实测踩坑清单：每条都标了根因和正解
10. 按收益排序的上手路径，与五份可直接复制的模板

L6 专家与工作拆分：角色滤镜，不是记忆分片

误解（本节最重要的一条）

「工作内容太多，记忆会膨胀。建几个专家，把它们拆开就好了。」

真相

专家隔离的是「角色」，不是「记忆」。 而且正好相反——建 N 个专家 = N 份同样的画像副本，反而多几份。

实测：专家记忆文件里装的是什么

打开某个专家的记忆文件，内容是：
# User Memory Profile
> Last updated: 2026-09-21T06:00:20+08:00
> Version: 78

## Memory Block
**工作背景** 用户是……
**个人背景** ……
**当前关注** ……

三段结论

1. 它是「用户画像」，不是「专家的领域知识」。 与会话启动时注入的云端档案同源，跟专业领域毫无关系。
2. 平台自动维护，人改不动（版本号每天自动刷新）。没法靠「往专家记忆里写东西」来沉淀知识。
3. 建 N 个专家 = N 份同样的画像副本。 实测某专家那份 26.7 KB。不但不缓解膨胀，反而多几份。

那专家真正承载领域知识的是什么

是包内的人设文件（角色 / 能力 / 工作流 / 输出规范）和随包的技能、参考资料——那是文件，不是记忆。

推论：想隔离的东西该放哪

本机实测到的机制事实

一条已更正的误判（值得记住的过程）

曾记录某个专家是「空壳」——其实是完整包（含五大核心能力、输出纪律要求）。

当时只看了「自定义专家」目录下的残留，没找到它在市场插件区的真身。

⇒ 与第 4 篇那条教训同源：判断「有没有 / 空不空」之前，搜索路径必须穷尽。

四条路的对比与定案

定案：以 C + D 为主，专家只在「强输出纪律」时建

依据：实际工作是零散穿插的（一个下午可能既改数据又写代码又推进度），而专家机制要求「一次启用一个」——与真实节奏冲突。

而且真正吃掉记忆的不是「谁在做」，而是「知识写进了记忆文件」。

专家 ≠ Agent：包装 vs 实体

市场清单里的数字

官方专家中心缓存文件里实测：专家总数约 447 个，其中 Agent 型约 393 个、Team 型约 54 个。

每个条目的核心三字段是包名 + 角色名 + 人设文件路径；另有包装字段（显示名 / 头像 / 职业 / 快捷提示词 / 默认开场语 / 标签）。

拆开一个 Agent 型专家

expertType  : agent
agentName   : <角色名>
agents      : ["./agents/<角色名>.md"]    ← 人设本体
skills      : [若干技能]                    ← 能力
displayName / profession / avatar / quickPrompts   ← 包装

一句话

Agent 型专家 = 1 份人设提示词 + N 个技能 + 一层商品包装。

三层对照

反向也要说清

agent ≠ 专家。 专家是「能在专家中心里被选中、有头像有名字、可安装可分发」的那部分 agent；会话里临时拉起的、以及主智能体本身，都是 agent 但不是专家。

Team 型的内部结构（实测）

某团队型专家的成员数组：一个 lead（首席角色）+ 若干 member（各领域专家），每人一份独立的人设文件。

⇒ 一个 team 包 = N 份独立人设 + 一套分工约定，成员各是各的 agent。

选专家的粒度是「会话」，不是「工作空间」

实测：会话记录与专家历史记录对比后确认——专家的绑定粒度是「会话」，不是「工作空间目录」。会话天然挂在某个工作目录下，所以效果上约等于「每个工作空间各自选」，但严格说是「每个会话各自选」。

官方那几百个专家 / 几十个专家团是什么

一句话

别人替你写好的「人设 + 工作流 + 技能」预制件，打包成插件供一键装载。不是额外的系统能力。

• 你装它，得到的是：一段人设提示词 + 若干技能 + 若干脚本参考资料。这些东西你自己写技能也能得到。
• 专家的价值在「已调好的组合 + 现成的输出纪律」，不在「多一种能力」。
• 专家团 vs 运行时组队：团 = 固定分工 + 固定流程（预置重、可复用）；组队 = 现场派活（零预置、任务结束即散）。二者底层都是「多个 agent 并行」，区别只在分工是不是写死的。

外壳到底有没有用

外壳卖的三件事

外壳做不到的事（这才是关键）

• 不提升模型能力：装了某个领域的专家，模型还是那个模型。
• 不隔离记忆：专家记忆是用户画像副本（8.1 已证）。
• 不保证质量：质量全靠包里那两段——人设文件里的纪律要求 + 技能里的检查清单。这两样你用技能一样能写。

外壳唯一不可替代的一点

技能是「触发才加载」，人设是「一直在」。 把「依据先行、注条款号」写进技能，只在触发那个技能时生效；写进人设，整个会话都生效。

⇒ 但这一点已被项目级记忆替代：进项目必载、全程生效，同样能承载「这个空间里始终要遵守的纪律」，还不占画像副本。

质量与消耗：靠什么，不靠什么

判断

只靠工作空间区分，保证不了质量。但「工作空间 + 技能 + 已收敛的记忆」三层叠加，能保证到相当高的程度——前提是质量必须变成硬约束，而不是临场发挥。

工作空间只管一件事：知识边界

工作变多后，质量下滑的三个真实根因

1. 上下文串味：一个会话混多件事，结论互相污染。工作空间挡不住，只能靠「一件事一个会话」的习惯（机制补不了）。
2. 约束稀释：记忆文件越长，关键红线越容易被忽略 → 靠定期体检脚本。
3. 没有硬检查清单的领域，全靠临场 ← 最大的洞

一句话判据

质量保证程度 ≈ 技能覆盖率。与套不套外壳无关。

已写进技能的领域：约束是硬的，每次必执行 → 能保证。 没写进技能的领域：只能临场发挥，工作一多就会飘 → 不能保证。

三件该做的事（按 ROI）

1. 清点「每次都要交代」的要求，没进技能的补进去——这才是真正降低无效消耗的动作（省掉重复交代 + 重复摸索）。
2. 每份技能结尾加「交付前自检清单」（3–7 条），跑完自己核一遍。
3. 会话纪律：一件事一个会话，串味就新开——这条机制补不了，靠习惯。

实测的一个典型缺口

盘点发现：某几个「产出交付物」的技能里，关于交付规矩的关键词命中数为 0——也就是说导出到哪、什么格式、要不要生成预览文件、出图前要不要先征得同意，每次都得口头说一遍。

修法不是在这几个技能里各贴一份，而是新建一个小技能「交付检查清单」，一处定义、多处调用——在各处复制会变成「改一处漏三处」的配置漂移。

定案：三层拆分各管什么

生效范围要精确

工作空间解决的是「横向」问题：多类型任务互不串味。 它不解决「纵向」问题：同一件事第 20 次做，还做得一样好。

后者归技能，不归专家也不归外壳。所以准确说法不是「工作空间已经足够」，而是：

工作空间（横向隔离）+ 用户级技能（纵向复用）+ 会话纪律（不串味）= 当前够用。少任何一层都有洞。

三个升级触发条件（满足任一才动，否则维持现状）

已知会漏的三种场景（现行方案的边界）

1. 同一工作空间内多类型任务 —— 空间粒度挡不住 → 靠技能触发区分。
2. 同一件事跨两个空间飘 → 围栏失效，需收敛到单一归属。
3. 用户级记忆塞了本该在项目里的约束 → 污染所有工作空间（分层错位的代价）。

一句话记住

隔离靠目录，复用靠技能，质量靠 checklist。专家和外壳只在「给别人用」那一刻才值钱。

L7 多设备同步：主干、边界与盲区

三套同步机制，别混为一谈

同步什么、不同步什么

判断原则：换设备还要不要、体积大不大、是不是本机独有。

两条写在规则里的教训

教训一：通配路径的层级

写忽略规则时，必须用前导斜杠限定根目录。写成不带斜杠的形式会匹配任意层级，把项目记忆镜像一起忽略掉。

实测中还踩过一个变体：规则里有拼写错误，导致它从未生效——这才是「本该被忽略的文件被纳入了版本库」的根本原因。

教训二：规则只对「此后新增」生效（本机踩过三次）

已进入版本库的旧文件不受新规则影响。 定规则时必须同时做一次全库存量清理 + 用「列出被跟踪文件」的命令核对，否则规则只对一半数据成立。

实测的第三次表现：约定「镜像只搬 MEMORY.md」，但某个项目的历史日志因为是老 tracked 文件，新规则管不着，53.8 KB 一直在同步。

为什么体检没发现：镜像一致性校验只比对 MEMORY.md，日志根本不在比对范围内。 ⇒ 只有「列出被跟踪文件」这一步能检出这类问题。

与 L3 的交叉：连接器不进同步意味着什么

连起来看

连接器凭据是绑定本机的、加密存本地、且不进同步仓库。

⇒ 换设备后，连接器必须重新授权。 你在办公电脑绑过的服务，到家庭电脑上不会自己出现。

而连接器状态同时又是「可重新绑定」的——不进仓库是安全考虑（凭据不外流），代价是换设备要重来一次。

一个必须点出的盲区

盲区：新建的目录可能不在同步范围内

实测发现：自建的 MCP 服务器目录、新建的技能目录都还是「未跟踪」状态，相关配置文件的改动也未提交。

⇒ 换台设备，配置文件同步过去之后指向的服务器代码不存在，连接器直接失效。

修法：把这些目录纳入版本库（凭据与密钥文件继续排除）。

教训：新建的东西不会自动进入同步范围。 每次新建目录 / 技能 / 脚本后，都要确认它有没有被跟踪。

移动端的现状与定位

为什么建议移动端只做「查看 + 勾选」

与 L4 那条判据一致：资料库是被访问层，不是生产层。

另外还有一个实际原因：移动端写入容易和 PC 端冲突（同一份数据两处改，容易出现覆盖）。

移动端要拿到「每日焦点」的三条通路

本节可带走的判据

1. 三套同步机制各管一摊，别混。
2. 规则只对新增生效——每次改规则都要同时清存量并核对已跟踪清单。
3. 凭据既不上云也不同步，只在本机加密躺着；换设备重新授权。
4. 新建的目录不会自动进同步范围——这是最容易漏的盲区。
5. 移动端只做「查看 + 勾选」，不做内容生产。

文中所有「实测」「xx KB」「xx 个」这类数量，均来自某一台真实机器的快照，请当作方法示范而非通用阈值；真正通用的是判据与因果关系。

原创声明

本文系「当月光落下」原创，首发于腾讯云开发者社区。内容来自作者在实际使用中的逐条实测整理， 所有结论均有本机实机验证或真实接口调用支撑；文中出现的数量均为特定环境下的实测快照， 仅作方法示范，不作为通用阈值。

如需转载，请注明作者「当月光落下」及首发出处，未经许可不得用于商业用途。