AI 工作流的原生化模式：插件化 vs 服务化，两条相反方向消灭同一摩擦
问题：同一摩擦，两种痛法
知识工作流中断的主因往往不是功能缺失，而是工具切换成本与手工上下文传递：
- KnowFlow 作者用四个 Codex Skills（clipping-update / daily-learning / study-outline / study-quiz）跑通了学习流程，但”每处理一篇文章都要离开 Obsidian 去 Codex 里重新描述文件”——学习变成一串需要记住的命令。
- Linkly AI 的出发点是研究者的”四道墙”：文献检索不记得下载过什么、阅读筛选只能 Ctrl+F、笔记散落三处、写综述引用要手动翻原文确认。
两者的共同病灶：人要负责告诉 AI”当前处理的是谁”，并手动搬运上下文。
两条方向相反的解法
| 维度 | KnowFlow：插件化（能力搬进数据的环境） | Linkly AI：服务化（数据暴露给任意能力） |
|---|---|---|
| 移动的是什么 | AI 工作流能力（清洗/摘要/图谱/测验）搬进 Obsidian 侧边栏 | 本地文献库经 [[wiki/entities/MCP |
| 宿主 | 单一宿主（Obsidian），深度绑定 | 宿主无关，任何 MCP 客户端即插即用 |
| 上下文获取 | 侧边栏跟随当前笔记切换四种模式，“打开文章即进入下一步工作” | search/outline/read 三工具，AI 自主决定搜什么、读什么、读多少 |
| 适用规模 | 单篇深度学习闭环 | 大规模语料库（1000+ 篇）检索消费 |
| 代价 | 离开 Obsidian 能力不可携带；0.1.0 闭源待开源 | 依赖客户端的 MCP 支持与 Agent 的检索规划质量 |
共同规律
- 文件/数据本身就是上下文：KnowFlow 用”打开状态”代替手工传文件名（“文件本身就是上下文”）；Linkly AI 用 Outline Index”名片”让 AI 先看结构再决定读什么——两者都在消灭”手工描述当前对象”这一步。这与上下文工程的微观实践一致（用环境状态代替显式传递）。
- AI 做判断，确定性层做执行：KnowFlow 的格式整理流水线里 AI 只返回 keep / wrap-code / heading 等结构化决定，规则做确定性修复，配三层写入保护；Linkly AI 的引用必须是本地文件原话（反幻觉）。两者都不让 LLM 自由发挥数值/文本的确定性部分。
- 产物落回开放格式：KnowFlow 学习产物落 Markdown/frontmatter（弃用无锁定）；Linkly AI 不搬家、不改文件——本地优先是两者的公共底座。
判断：何时选哪条路
- 高频单对象深加工（每篇文章都要走完整流程）→ 插件化：上下文切换成本被摊薄到零。
- 低频大规模检索消费（偶尔问一次千篇语料）→ 服务化：不值得为语料库定制宿主，MCP 一次接入处处可用。
- 两条路线不互斥：KnowFlow 式的宿主插件完全可以反过来调用 Linkly AI 式的 MCP 文献库——“侧边栏管精读，MCP 管检索”可能是知识工作流的终态组合。
边界与存疑
？ 两案例均为产品自述：KnowFlow 0.1.0 闭源（承诺 1.0.0 开源）、未在大型 Vault 验证；Linkly AI 源文为产品推广文，配置时间等数字无第三方基准。“工具切换成本是流程中断主因”这一归因目前只有作者侧证据，需要更多案例累积验证。