Agent 编排层薄自建优先于重型框架

更新于 2026-06-25

**给本地优先的桌面 App 接 Agent，先自建一层很薄的编排层，不要直接引入 LangChain / LangGraph / AutoGen 这类重型框架 —— 当能力边界很明确（读笔记、读文件、写笔记）时，权限边界比「框架功能丰富」更重要。** 这里的「自建」不是自己训练模型，也不是从零写 LLM，而是自己定义工具、权限、上下文与错误处理。

薄自建层要自己定义什么

  • Agent 能调用哪些工具：list_notes、read_note、read_file、write_note
  • 工具怎么接 Tauri / vault / 文件系统
  • 写入前要不要用户确认
  • 上下文怎么塞：当前笔记、选中文件、搜索结果
  • 错误怎么显示：没权限、文件太大、笔记冲突、写入失败

优点是贴合「本地优先、文件是真相源、写笔记走现有 vault 契约、API key 运行时配置」，代码量可控，第一版不被框架抽象绑住。代价是高级能力要自己补：多步计划、任务队列、长程记忆、工具重试。

开源框架的适用面与代价

框架的价值在复杂任务流：例如「扫描整个知识库 → 找主题 → 生成报告 → 拆成多篇笔记 → 反复修订」，这时 agent graph、memory、workflow、multi-agent、观测调试确实省事。

代价是：多数框架默认服务端 / 云端思路，和 Tauri 桌面、本地文件权限、vault 原子写入、前端状态机不完全贴合；还会引入依赖、抽象层与调试成本。最危险的是写文件 / 写笔记这类能力被框架包装得太深后，权限边界会变模糊。

推荐路线：混合

  • 不接完整开源 Agent App，也不引入重型 agent framework
  • 复用现有 AI SDK / 模型的 tool calling 能力
  • 自己定义工具层、权限层、笔记读写层、UI 状态
  • 将来真要复杂工作流，再单独评估是否引入「流程图式编排」（如 LangGraph）

这样第一版能快，架构也不会死。

相关