本地 AI 工具这两年有个挺明显的分叉：一边继续把聊天框做得更强，另一边开始把“项目现场”本身搬进 AI 工作台。OpenLoaf 属于后者。它不只是又包了一层多模型聊天，也不是把 Claude Code、Cursor、Notion、Miro 混在一起做个启动器；它真正想解决的是：AI 到底应该围着“对话”转，还是围着“项目”转。
答案很现实。真正干活时，人不是只在一个聊天窗口里工作。你要看文件、改文档、跑命令、查邮件、排日程、拆任务、画流程，还要在不同客户、不同仓库、不同知识库之间切换。AI 如果永远只记得当前会话，迟早会变成一个很会说话、但不懂现场的外包同学。
OpenLoaf 的思路，是把每个项目做成一个本地优先的独立工作区：一个项目一个窗口，一套文件、记忆、技能、终端、任务板和画布。主窗口里有 Secretary Agent 负责全局调度，项目窗口里有 Project Agent 负责项目上下文，复杂任务再拆给 Worker Agents。这个结构看起来有点“公司组织架构”，但对重度 AI 用户来说，反而比万能聊天框更接近真实工作。
先看它解决的不是“模型不够多”，而是“上下文没有家”
很多 All-in-one AI 工具都喜欢强调“支持很多模型”。OpenLoaf 也支持 OpenAI、Claude、Gemini、DeepSeek、Qwen、Grok，以及通过 Ollama 跑本地模型。但如果只看多模型，就把重点看小了。
多模型只是入口自由。真正值钱的是项目上下文有了稳定落点。
在 OpenLoaf 里，一个项目不是临时会话，而是一个自包含工作区：
- 项目有自己的文件树、文档、任务板、终端和画布；
- 项目有自己的 Project Agent，能读取项目相关上下文；
- 项目有自己的 memory 和 skills；
- 项目之间可以显式 link，共享记忆和技能；
- 全局 Secretary Agent 负责跨项目查询、邮件、日历和任务路由。
这就把 AI 从“每次问一次”变成“长期待在项目里”。区别很大。比如你有一个“编码规范”项目，里面沉淀团队的前端规范、提交约定、接口风格、设计系统说明。把它 link 到多个代码仓库项目后，项目 Agent 处理每个仓库时都能读到这份共享知识，而不是你每次复制粘贴一遍。
说白了，OpenLoaf 不是让 AI 记住所有东西，而是让上下文有边界、有归属、有复用路径。这个方向比单纯加大上下文窗口更稳。
三层 Agent：主助理、项目助理和临时工
OpenLoaf 的 Agent 架构可以拆成三层。
第一层是 Secretary Agent。它在主窗口里，像一个全局助理，适合处理日历、邮件、跨项目查询、近期活动梳理，以及把复杂任务路由到具体项目。
第二层是 Project Agent。每个项目窗口都有一个专属 Agent，它能围绕当前项目工作：读文件、看文档、管理任务、理解项目 memory、调用项目 skills，必要时经过批准运行终端命令。
第三层是 Worker Agents。它们是按需生成的专业子 Agent，适合承担探索、规划、编码、审查这类具体任务。复杂任务不必全压在一个对话里，而是可以拆给不同 worker 并行推进。
这个结构的意义，不是听起来“更智能”。它更像一种权限和上下文分层：
- Secretary 管全局，但不应该随便替每个项目做深修改；
- Project Agent 管项目现场，知道当前仓库、文档、任务状态；
- Worker Agent 管单次子任务，干完就交付结果；
- MCP、Skills、Memory 和终端工具都围绕项目边界加载。
这套分层对团队尤其重要。因为团队最怕的不是 AI 不会回答，而是 AI 在错误上下文里自信地改东西。把 Agent 分到项目、记忆、技能、工具权限这些边界里，至少能让错误更容易定位和收口。
最小上手：先跑 Web，再看桌面端
OpenLoaf 官方仓库是 pnpm monorepo，技术栈包括 Next.js 16、React 19、Tailwind CSS 4、Hono、tRPC、Prisma 7、SQLite 和 Electron 40。想本地体验，先确认 Node.js 和 pnpm 版本。
如果还没启用 pnpm，可以用 Corepack：
然后拉仓库、安装依赖、初始化数据库并启动开发环境：
默认 Web 入口是：
桌面端可以单独启动：
如果只是想先理解产品结构，Web 端已经够用；如果要体验多窗口项目工作台、系统日历、桌面集成等能力，再看 Electron 桌面端更合适。
Docker 方式也能跑开发环境，仓库里给了 docker-compose.yml，默认把宿主机 3100 映射到容器内 3001，并把 OpenLoaf 数据放到 /root/.openloaf 对应的数据卷里。适合临时试用，但桌面能力主要还是本机运行更自然。
访问：
第一个项目别贪大，先做一个“规范库”
OpenLoaf 很容易让人上来就想把所有工具都塞进去：文档、画布、邮箱、日历、代码仓库、MCP、Ollama，全开。但第一次试用，建议反过来，先做一个很小的“规范库”项目。
可以按这个顺序来：
- 创建一个项目，类型标成 docs 或 knowledge base；
- 写一份团队编码规范，比如分支命名、提交规范、接口返回结构、前端组件风格；
- 在项目里放一个 SKILL.md，把“审查代码时先看哪些问题”写成步骤；
- 再创建一个代码仓库项目；
- 把代码仓库项目 link 到规范库项目；
- 让 Project Agent 基于规范库检查一个小文件或一个小 PR。
这样能最快看出 OpenLoaf 的核心价值：项目之间不是互相复制资料，而是通过显式链接共享上下文。
一个最小的 Skill 可以这样写：
把这种技能放在全局 skills 或项目级 skills 目录后，Agent 可以按需加载。OpenLoaf README 里给出的约定是：全局技能放在 ~/.agents/skills/，项目技能放在 <projectPath>/.agents/skills/。
Memory 要写“稳定事实”，不要把聊天记录全倒进去
OpenLoaf 的 memory 分三层：用户级、项目级、链接项目级。路径大致是：
这套结构最好不要拿来做“垃圾桶式长期记忆”。什么都记，最后只会把 Agent 带偏。更靠谱的写法是只保存稳定事实：
- 项目采用什么架构；
- 哪些目录不能动；
- API 的兼容边界；
- 团队偏好的代码风格；
- 常用测试命令和验收口径；
- 客户项目里的固定术语和禁用说法。
不要把临时 TODO、一次性讨论、已经过期的错误判断、密钥、客户隐私数据写进去。记忆层越干净，Agent 越像靠谱同事；记忆层越脏，Agent 越像翻旧账的实习生。
比较实用的项目记忆可以写成这样：
注意，这类记忆是给 Agent 长期读的，不是给人看的流水账。越短越清楚。
MCP：别急着全接，先按项目开工具
OpenLoaf 支持 MCP server，可以通过 stdio、http、sse 连接外部工具。配置可以放在全局：
也可以放在项目级：
项目级配置更适合生产使用。原因很简单：不同项目需要的工具不一样。代码仓库项目可能需要 GitHub、文件系统、数据库只读查询；内容项目可能需要浏览器、笔记库、图片工具；客户项目可能只允许访问特定 API。
一个安全的原则是：能放项目级，就别全局乱开；能只读，就别直接给写权限；能人工确认，就别让 Agent 自动执行。
比如数据库 MCP，开发期可以先给只读账号；GitHub MCP 可以从只读 repo 权限开始；文件系统 MCP 限定在当前项目目录。等流程跑通，再逐步增加写操作。
这和 OpenLoaf 的项目边界是同一件事：工具不是越多越好，工具应该跟着项目上下文和权限走。
多模型：按任务选，而不是迷信一个默认模型
OpenLoaf 通过 Vercel AI SDK 接入多家模型，外加 Ollama 本地模型。对个人用户来说，最直接的好处是不用被某一个工具的模型选择绑死。
比较稳的搭配是：
- 日常问答、文档整理：便宜快的模型优先；
- 代码规划、复杂重构：强模型优先；
- 隐私材料、离线笔记：Ollama 本地模型优先；
- 长文档摘要：看上下文长度和成本；
- 自动化任务：看工具调用稳定性，不只看跑分。
这里有个容易忽略的点：本地优先不等于所有 AI 推理都本地。OpenLoaf 的数据可以存本地，但如果你使用云模型，prompt 和上下文仍会发往对应模型服务商。它更准确的价值是 BYOK 和直接调用：API 请求从你的设备发往模型提供商，不经过 OpenLoaf 第三方中转。
如果你处理的是客户资料、合同、代码安全问题，就别只看“数据存本地”四个字，还要看实际调用的是本地模型还是云模型。
什么时候该上服务器，什么时候就留在本机
OpenLoaf 的核心体验更偏本地桌面。但很多人试 AI 工具时，还是会准备一台隔离实验机：跑 Ollama、跑 MCP server、跑测试数据库、跑浏览器自动化，避免把主力电脑弄乱。
如果你最近正折腾 Agent 实验环境、MCP 工具箱或本地模型网关，可以把这类东西放到独立云服务器里，主机只负责桌面入口和少量本地数据。雨云这类云服务器方案适合做低成本试验机：跑模型周边服务、测试 MCP、部署轻量 Web 端和日志面板，坏了重装也不心疼。
但要分清边界：桌面数据、私人文件、邮件日历这类强个人信息，没必要随便上服务器；需要公网访问的服务，也别裸奔。至少要做端口限制、SSH key 登录、反向代理认证、备份和日志脱敏。
OpenLoaf 适合谁，不适合谁
它适合几类人。
第一类是独立开发者和小团队。你有多个仓库、多个客户项目、多个规范文档，已经厌烦了在 ChatGPT、Cursor、Notion、终端、任务板之间反复横跳。OpenLoaf 的项目窗口和链接记忆，正好能把这些现场收进一个地方。
第二类是内容创作者和研究型用户。你可以把参考资料、草稿、画布、任务拆解、生成图片和日程放在一个项目里，再用另一个项目做发布或交付。重点不是“AI 帮你写”，而是素材和工作流不再散。
第三类是隐私敏感用户。OpenLoaf 的本地存储、零遥测、BYOK、Ollama 支持，给了用户更多控制权。它不是让你完全脱离云模型，而是让你能按任务选择是否出网。
不太适合的也很明确。
如果你只想要一个最稳定的聊天应用，OpenLoaf 可能显得太重；如果你只做代码补全，专业 IDE 插件更直接；如果你需要成熟企业权限、团队协作审计、SaaS 管理后台，那现在还要谨慎评估。项目仍在活跃开发阶段，路线图里 full web browser access、i18n、项目模板市场、Office 集成都还在推进中。
真正的风险：All-in-one 很容易变成 All-in-mess
OpenLoaf 这种产品路线很有野心，也有天然风险。把聊天、文档、画布、邮件、日历、终端、文件管理、任务板都放进一个应用，做得好是工作台，做不好就是大杂烩。
所以试用时别用“能不能替代 5 款工具”来判断。更好的判断标准是：它能不能让一个项目的上下文更稳定，让 Agent 的行为更可复查，让跨项目知识复用更少靠复制粘贴。
可以用三件事验收：
- 创建一个真实小项目，跑完文档、任务、终端、AI 问答；
- 建一个规范库项目，link 到代码项目，看 Agent 是否能引用共享规范；
- 配一个只读 MCP server，看工具权限是否能被项目边界管住。
如果这三件事跑通，OpenLoaf 就不是一个漂亮壳子，而是有机会成为本地 AI 项目桌面。反过来，如果只是拿它当多模型聊天器，那它的优势反而发挥不出来。
AI 工具下一阶段的竞争，不一定是谁的聊天框更聪明，而是谁能把项目现场、长期记忆、工具权限和多模型选择组织得更像一个可持续工作的系统。OpenLoaf 现在还年轻，但它踩的方向是对的：别让 AI 永远漂在会话里，先给它一个能长期工作的项目桌面。