职责要先分家，再谈实现
# 职责要先分家，再谈实现
结论
你反复遇到的是同一个形状：两个本质上不同的东西被当成一个在讨论 —— 于是同步、缓存、编排、选型全都在错误的前提下叠加。 判断是：先问「这两件事各自的职责边界在哪」，把分家显式写下来，再谈怎么实现。 分家的依据是职责，不是相似度 —— 长得像、名字像、恰好由同一套基础设施承载，都不构成「该合成一件」。
四处证据
| 场合 | 被混为一谈的两件事 | 分家之后的规则 |
|---|---|---|
| 产品能力 vs AI Agent | 确定性、短时、单步（文章总结 / 打标） | 拆成两个运行体：packages/ai 降级为模型适配与通用原语，编排/状态/工具独立成 agent-server |
| 首次导入与增量更新要用不同规则 | 订阅时的历史导入 vs 固定时间更新新文章 | 两条独立任务：首次导入单独跑，cron 只管「有多少新文章读多少」，不能共用一条固定条数规则 |
| 离线存储的三个等级 | 「有网时少一次往返」vs「断网可增删改」 | 三个等级分别实现与验收，不塞进同一个 Issue |
| 多Agent协作控制面 | 「现在谁在做什么」vs「可复用的知识」 | 分文件分层：status 管现在、registry 管复用、lesson 管教训；把「当前状态」写进「长期知识」会让下一层失真 |
综合判断
-
分家的依据是职责，不是相似度。 四处被混在一起的两件事，都是「恰好长在同一套东西上」： 同一份
packages/ai、同一条 cron、同一套 IndexedDB、同一个协作目录。承载相同 ≠ 职责相同。 -
没分家的症状统一是「互相污染 / 各说各话」，而且不报错。 缓存的语义被离线编辑污染、cron 的规则被首次导入污染、可复用知识被当前进度污染 —— 每一个都表现为「说不清 / 越改越乱」，没有一条报错信息指向「你少分了一次家」。
-
可迁移的动作：当出现「这块到底算谁的」时，先写一句 「A 负责…，B 负责…」，确认两者没有重叠、也没有缺口，再动手实现。 分家的产物是一句可写在文档里的话，不是一个更复杂的架构。
为什么这是 synthesis
单看每一页，都是某个系统里的一次边界调整（AI 架构、抓取策略、缓存档位、协作目录）。 并排之后才看得出它们共享同一个动作：先把混在一起的两件事按职责分开，再谈实现。 这个动作独立于任何系统，可以直接带走。
相关
- 分层要落到运行时才有效 —— 分完家还要有人执行边界，否则等于没分
- 契约只承载结构，个性留给扩展层 —— 层与层之间怎么切界
- 真源要按维度显式指定 —— 同一份数据也要按维度分家
- 可复用物与不可复用物分开 —— 按寿命分家；本条按职责分家
- 按实际规模选型而不是按方案先进性 —— 同源：先量清这一侧，再谈方案
- 观测平台不能当运行状态真相源 —— 同形的另一处实例：数据库决定 Agent 在做什么，观测平台解释它为什么这样做
- 多Agent协作控制面 / 离线存储的三个等级 / 首次导入与增量更新要用不同规则