RAG已死，File System会成为上下文管理的最佳实践

“RAG已死”不是说检索没价值，而是说它不该再做默认入口。对工程型 Agent 来说，单纯依赖向量检索容易出现索引滞后、切片失真、上下文断裂，结果是模型看起来“知道很多”，但落地经常偏题。

更稳的做法是先把 File System 当主上下文层：代码、文档、日志、任务清单都在同一个事实源里，路径清晰、版本可追溯、修改可验证。Manus、Claude Code 这类产品的共同点，也是把“直接读写文件”放在高优先级。RAG 仍然有用，但更适合作为“缩小检索范围”的辅助层，而不是系统核心。

Local First

Local First 的本质是把 Unix 的 “everything is a file” 落到 Agent 架构里：把状态、上下文和执行都尽量放在本地。这样做的好处很直接：延迟更低、调试更快、权限边界更明确，Agent 连续执行任务时也更稳定。
这一点可以从最近流行的工具项目中观察到，Obsidian越来越火，Notion被人嫌弃，因为Notion不开放生态，文件导出格式不兼容，想把LLM集成在内部。Clawbot大火，为什么？AI首次拥有了一整台机器的所有权限，所有任务本地执行

CLI代替部分MCP

MCP

MCP本质是将client（比如Codex）与server通过tools的方式连接起来

CLI

CLI（命令行交互）一开始是用来让人可以直接通过命令行与server交互，但是CLI本身是大模型最擅长的交互方式，因为所有大模型都有bash这个tool，可以直接通过命令行在本地操作。同时如果CLI是生态比较大的软件，LLM会针对该服务的CLI针对性训练，有性能高、交互快的优点

什么情况下要加入Skills

如果软件生态不大，但是又想使用CLI的方式，就会面临着AI读不懂命令行的问题，同时命令行的设计是个人设计的，如果AI要执行一些批量化操作不方便
这种时候就可以创建一个skills，写入一些固定的脚本和prompt来指导Agent使用CLI

什么情况下仍然用MCP

如果软件功能过于复杂，生态支持不够，想统一管理tool，让用户开箱即用，这种时候可以使用MCP
同时MCP更方便做专门的gateway，适合大平台管理

Obsidian

这个世界上最流行的Local first笔记软件最近做的事可以让你了解趋势，Obsidian本身是没有基础LLM的，然后社区生态根据Obsidian提供的API做了第三方的MCP，很多人直接用Agent来管理文章、写文章，最近，Obsidian有出来官方的CLI（内测中），Agent可以直接通过CLI来使用Obsidian

pi Agent + SKILLS彻底淘汰workflow

传统 workflow 依赖预先编排，流程一旦固定，面对开放任务就会变笨重。pi Agent 这类内核的价值在于提供稳定 loop 骨架，再把领域经验沉淀进 SKILLS，让系统能在执行中动态拆解、调用、校验和回环。

未来的趋势是：逐步淘汰workflow，把自由还给Agent，而SKILLS负责指导和约束