把合同、银行流水、病历这类私密文件直接丢进云端聊天机器人，已经成了很多人的习惯，但很少有人在意这些数据此后”漂”在哪里。XDA Developers 撰稿人 Nolen Jonker 在文中分享，随着对隐私和自托管了解加深，他基本停止了把私人文档上传给 Claude 等云端工具。他并不是不再需要 AI 辅助读文件，而是换了个更稳妥的本地方案——开源桌面应用 Cherry Studio。

一、装上 Cherry Studio

这是一款免费、开源、本地优先的 AI 工作台，支持 Windows、Mac 和 Linux。它能对接 OpenAI、Anthropic、Gemini、DeepSeek、通义千问等云端模型，也能通过 Ollama 或 LM Studio 接入本地模型（LM Studio 起一个服务约两分钟，就能搭起一套完全自托管的 AI 工作栈）。一个实用技巧：可以把同一句话同时发给多个模型，并排看回答差异。

二、把文件放进知识库

Cherry Studio 支持 PDF、Word、PowerPoint、Excel、纯文本、Markdown 和网页链接。导入后走 RAG（检索增强生成）：文档被切分建索引，提问时只把相关片段连同问题一起交给模型，因此能处理的资料量远超模型上下文窗口。要注意，只有用本地嵌入模型时检索才完全离线；若用云端嵌入器，建索引阶段文档仍会发出去，敏感材料务必搭配本地模型。

三、调用内置助手与 MCP 工具

它自带 300 多个预设助手（编辑、法务、医嘱摘要等），也能自建；还能把常用提示词存成”可复用提示”，配一个触发词就能一键调用。更关键的是支持 MCP（让模型调用外部工具的标准）：软件已预接好文件系统、网页搜索、GitHub、抓取、记忆等工具，开启文件系统后，直接让模型”读一下我 2025 报税文件夹”即可就地取数，不必每次手动导入。

注意事项

API 密钥、对话、附件、知识库与设置默认都留在本地，请求直达你配置的提供方，没有中间转发。但给模型开文件系统权限有风险，建议只在特定对话启用，且只给小文件夹的只读权限。

来源：XDA Developers

很多人想在自己电脑上跑大模型，第一反应就是得配一张昂贵的独立显卡。XDA Developers 撰稿人 Yash Patel 在文中分享，他只用一台搭载 AMD 锐龙 7 5000 系列处理器、16GB 内存与 AMD Radeon 核显的联想 IdeaPad Slim 3，就跑通了多个本地模型，日常写稿、写代码完全够用。他的体会是：只要选对模型、放低预期，核显机器照样能玩转本地 AI，而且所有提示词和文件都留在自己电脑上，不必担心隐私外泄。

一、先装一个轻量运行器

他用的开源工具是 KoboldCpp，专门用来加载 GGUF 格式的模型文件。它的好处是简单、可控：下载后把模型文件拖进去、按需调整参数，就能在本机直接对话，不需要复杂的部署流程，换模型也只需重新加载，不必关掉整个程序。

二、按用途挑 4 款模型

1. Mistral 7B（Mistral-7B-Instruct-v0.3-Q8_0，8 位量化）：他用来头脑风暴、列提纲、扩展思路，是能力与核显负载之间最平衡的一款，适合写作前先理框架；
2. Phi-4 Mini（Phi-4-mini-instruct-Q6_K，6 位量化）：体积小、启动快，适合改写字句、总结短文、解释概念这类零碎活，随手就用；
3. Gemma 3 4B（gemma-3-4b-it-Q4_K_M，4 位量化）：需要多一点推理时用，比如拆解问题、比较方案、核对思路，资源占用也不高；
4. Qwen 3.5 4B（Qwen3.5-4B-UD-Q8_K_XL，8 位量化）：他主要的本地写代码助手，能写代码、修报错、解释代码段，小任务尤其顺手。

三、控制模型规模

他的经验是，3B 到 7B 区间的模型在速度与质量上最均衡；再大的模型（比如 12B 以上）也能跑，但明显变慢，往往不值当。按任务切模型，比死守一个大模型更省心。

注意事项

模型文件名里的 Q8_0、Q6_K、Q4_K_M 代表量化精度，位数越低体积越小、越省显存，但输出质量也会略降，可按自己机器灵活取舍。若从模型社区下载，记得确认文件来自可信来源。

来源：XDA Developers

Cua 的团队此前以 macOS 虚拟化栈 Lume 起步。苹果自家的 Virtualization.framework 让 macOS 客户机通过虚拟 GPU 使用宿主的 Apple GPU，但在默认配置下，这个虚拟设备上报了一套非常保守的 Metal 能力档。应用程序正是根据这些应答来选择计算内核和渲染路径，于是 llama.cpp 在虚拟机里走了更慢的 GPU 代码路径。

虚拟机里的 GPU 被「降级」了

问题出在能力查询的应答上。在 Cua 基于 macOS Tahoe 的标准虚拟机里，这块虚拟显卡上报的近似能力是「Apple 5 时代家族」、最大线程组内存仅 32 KB，并且不支持 SIMD 组矩阵运算。现代 Metal 软件会依据这些应答挑选内核，即便设备其实能跑更新的内核，llama.cpp 也只会选择更慢的实现。

苹果官方文档通过「GPU 家族与特性表」来描述 GPU 能力，并建议应用在运行时查询设备。换言之，应用程序只是照着平台告诉它的边界来工作。这与常见的 GPU 直通不同：在 x86 Linux 上可以通过 VFIO 把物理 PCI 设备直接分配给虚拟机，而苹果这套是半虚拟化架构，宿主机仍掌控硬件，客户机使用的是虚拟化感知的设备。

进程级补丁做了什么

Cua 团队写了一个很小的 Metal 能力补丁，作为兼容层插在某个客户机进程与 Metal API 之间。它只拦截并改写该进程读到的少数几项能力应答：把支持的家族档提升到 Apple family 9（编号 1009），并把最大线程组内存从 32 KB 提到 64 KB。就这两项改动，足以让被测的 llama.cpp 版本改用更新的 SIMD 组归约、SIMD 组矩阵与 bfloat16 路径。

关键在于，这个补丁只作用于被注入的那个工作进程及其子进程，工作负载仍然跑在苹果现有的虚拟 GPU 通道上，由宿主的 Apple GPU 执行；它不涉及物理 GPU 直连、原始 PCI 或 VFIO 直通，也不改动内核。其余能力档保持默认不变，配置缺失或格式错误时会自动回落到标准路径。

实测：提速 7 到 16 倍

测试在一台 Apple M1 Ultra（48 核 GPU）、宿主 macOS 26.6.1 上进行，客户机为当前公开的 Tahoe Cua 镜像（macOS 26.5.2、8 个虚拟 CPU、16 GiB 内存），运行 Lume 0.5.1，统一使用官方 llama.cpp b10167 版本。

使用 TinyLlama 1.1B 对话模型（Q4_K_M）时，提示处理从标准虚拟机的每秒 431.86 个词元提升到解锁后的 4786.70 个词元，达到裸机的 98.25%；生成速度从每秒 12.63 个词元提升到 206.60 个词元，相当于裸机的 72.06%。两项提升分别为 11.08 倍与 16.36 倍。

换成 Google 今年发布的 Gemma 4 12B（QAT Q4_0，约 6.98 GB）后，提示处理从每秒 71.66 个词元提升到 515.76 个词元，达到裸机的 99.59%；生成从每秒 3.41 个词元提升到 49.67 个词元，相当于裸机的 94.82%，提升分别为 7.20 倍与 14.54 倍。

再用 Meta 官方的 Muse Glimmer 30B（Q4_K-M，约 16.76 GB，客户机内存提到 64 GiB）测试，提示处理从每秒 25.83 个词元提升到 194.97 个词元，生成从每秒 2.38 个词元提升到 21.08 个词元，提升分别为 7.55 倍与 8.87 倍。作为对照，MLX-LM 0.31.3 在标准中就已经很快，补丁前后几乎持平（提示 1.005 倍、生成 0.993 倍），这也帮助团队定义了发布时所覆盖的能力档范围。

局限与适用边界

这项技术仍是实验性的，且对版本敏感：它依赖客户机 Metal 实现中私有的、随 macOS 版本可能变化的行为，因此每一个宿主与客户机组合都需要单独验证。补丁只影响被注入的工作负载，加固或受平台保护的程序可能拒绝库注入；它覆盖的能力档也仅限于已测试的范围，物理 GPU 能力发现不在其内。

Cua 已将相关源码以与 Lume、Cua 相同的宽松许可证开放，并附带构建脚本、能力探测与原始基准日志，供他人复现。对于需要在苹果芯片虚拟机里跑本地推理的开发者，这层补丁提供了一个值得关注的起点——前提是接受它的实验属性，并为每个系统组合自行核验。

来源：Cua 官方博客（GitHub 项目 trycua/cua），作者 Francesco Bonacci 与 Johnny Franks

很多人以为跑本地大模型一定得配一张昂贵的独立显卡。这个说法有一半是对的——确实有不少任务离不开显卡。但模型世界里还藏着一大批体积小、却能把事情做漂亮的小模型。只要手边有一台近五年内生产的旧电脑或笔记本，内存不低于 8GB，就能跑起来，速度大约在每秒 10 个词元上下。这个速度听起来不起眼，可在不少实际场景里，原始速度根本不是关键。

第一行命令：用 Ollama 起一个本地服务

对于大多数想自己托管 AI 的人来说，Ollama 几乎成了默认选择。它内置模型库，提供一套兼容 OpenAI 的接口，能在本地直接拉起一个服务进程。基于开放权重模型搭建真正能执行任务的 AI、而非单纯对话，它再合适不过。

最大的好处是省心。硬件探测、量化版本选择这类琐碎活儿，Ollama 都替用户打理了。唯一要盯紧的是量化设置：选错格式的后果很严重，仅仅两比特的差别，就能让整机性能天差地别。选定模型后，执行 ollama pull 模型名 拉取，再 ollama run 模型名 就能对话。

要榨干性能：试试 llama.cpp

llama.cpp 是一套专门跑 GGUF 格式模型的推理引擎。它没有界面开销，把能用的 CPU 优化都用到了极致，适合那种「每一分性能都要抠」的场景，代价是上手更费劲。

它高度依赖命令行（不过也有网页界面可用），模型文件得自己管理，量化格式也得自己搞明白。起步方式是下载发布版或自行编译，再从 Hugging Face 取一份 GGUF 模型，用 llama-cli 或 llama-server 跑起来。有一项设置至关重要：把上下文长度封顶，别用默认值。KV 缓存吃掉内存的速度快得惊人，设太高整机立刻卡死。

给老旧硬件的礼物：Gemma 4 边缘模型

Gemma 4 家族里最小的两员——E2B 与 E4B——于 2026 年春天专为「边缘」硬件发布。名字里的「E」代表有效参数量，用更少的显存堆出更深的层次。举例来说，E4B 在 4 比特量化下大约只占 5GB 内存。

它们擅长摘要、起草、抽取结构化数据、翻译这类基础活儿，也能做一点推理，只是比不上更大的思考型模型。通过 Ollama 使用时，按内存选型号：有 8GB 就上 E4B，更少就退到 E2B。上下文也别拉太高，一样会挤占内存。

慢笔记本的绝配：给相册自动写说明

这篇文章里最受青睐的本地 AI 项目之一，是个给截图自动生成描述的小程序。这套配置跑在显卡上，但完全没有理由不能挪到 CPU 上，尤其是不要求实时的时候。批量给一整个文件夹的照片生成说明文字或替代文本，正是慢笔记本的理想任务——模型每秒吐三个词元，即便在无人值守时运行，慢一点也无妨。

可选方案有好几个：Moondream2（或 Moondream3，约 16 亿参数）专为边缘设计，4 比特量化下轻松塞进 3GB；SmolVLM 2B 是开放权重模型，擅长批处理；Gemma 4 E4B 每个版本都带视觉能力。要是想翻找过去十年的照片并让它们变得可搜索，这招极其实用。建议先用十几张差异很大的图试试水，再决定要不要丢进上万张的图库。

把文档搜索变聪明：私有语义检索

电脑自带搜索基本是「傻瓜式」的，只认敲进去的字面关键词。换上 AI，就能做语义搜索——用更自然的描述去找东西，不必字字对应。推荐先从 EmbeddingGemma 入手：它只有 3.08 亿参数，量化后内存占用不到 200MB，甚至能把输出向量从 768 维截到 128 维而几乎不损质量。把它接在 Ollama 服务后，配合 AnythingLLM 或 Open WebUI 就能用。只是要记住，在 CPU 上扫一遍庞大的文档库，动辄要等上几个小时。

怎么选：快用 llama.cpp，图省心用 Ollama

想要最快的搭建，选 llama.cpp；对其他人，作者强烈推荐 Ollama，那份省心简直是游戏规则的改变者。若一时没有特定模型目标，先从 Gemma 4 的边缘型号起步最稳妥——它们能做的事多到惊人，而且哪怕是一台「土豆机」也带得动。

来源：How-To Geek（作者 Nick Lewis，2026 年 8 月 11 日）

MakeUseOf 撰稿人 Yadullah Abidi 分享了一个反例。DeepReinforce 的 Ornith 1.0 家族中体积最小的 Ornith 9B，在他 16GB 内存的笔记本上给出了接近 35B 级别的回答，换个版本还能读图。要复现这个结果，第一步是把硬件账算清楚。

一、先分清内存和显存

1. 全精度 bf16 运行 Ornith 9B 大约需要 19GB 内存，官方建议用 80GB 显存的 GPU 做非量化部署，个人机器基本无缘。
2. 量化版本才是可行路径。Q4_K_M 量化后模型体积压到约 5.6GB，扣掉系统占用和一个合理的上下文窗口，16GB 内存放得下。
3. 这里的 16GB 指系统内存，不是苹果芯片 Mac 那种 GPU 可以直接调用的统一内存。Abidi 的机器是 16GB 内存搭配 RTX 4060，显存 8GB。
4. 在装了独立显卡的机器上，决定速度的是显存而非总内存。5.6GB 的量化模型若塞不进显存，Ollama 会把一部分交给 CPU 处理，速度立刻掉下来。这与显卡品牌无关，显存只有几 GB 就会撞上同一堵墙。Mac 的内存和 GPU 共用一个池子，在这件事上反而占便宜。

二、想要读图能力，别拉错版本

1. Ornith-1.0-9B 的官方模型卡把文本列为主要模态。直接拉默认的 GGUF 或标准权重，是没有图像能力的。
2. 视觉能力来自单独导出的版本，在 Ollama 上以社区标签 robit/ornith-vision:9b 分发，并非 DeepReinforce 官方发布，它在同一套推理骨干上叠加了视觉和工具调用。
3. 另有至少一个量化 MLX 版本在模型卡上同时标注了文本和图像两种模态。也就是说多模态是特定构建的附加项，并非所有 Ornith 9B 文件都具备。
4. 结论很直接：按命名空间拉带 vision 标签的那一个，别随手拉搜索结果里第一个 Ornith 9B 量化包。Ollama 和 LM Studio 目前对多模态模型的支持都已经比较顺畅。

三、它强在哪，弱在哪

这个家族的特别之处在训练方式。Ornith 1.0 以 Qwen 3.5 为底座做后训练，采用自我改进的强化学习配方，让模型自行搭建并打磨解题脚手架，而不是依赖人工写死的智能体流程。体积小却能打，靠的是这一点，不是参数量。家族里还有 31B 稠密版、35B 混合专家版和一个 397B 混合专家版。

成绩方面，Ornith 9B 在 SWE-bench Verified 拿到 69.4%，Terminal-Bench 2.1 得 43.1，对手是 Gemma 4-31B、Qwen 3.6-35B 这类三到四倍体积的模型。不过同门的 35B 混合专家版在相同基准上仍明显更强。

短板也很明确：面对很长的多步智能体任务，9B 版本容易打转或卡住，大一号的兄弟处理得从容得多；如果模型有一部分跑在 CPU 上，这种情况来得更早。它的优势集中在编程和终端类任务，通用推理不要按 35B 的水准去期待。

来源：MakeUseOf

XDA 撰稿人分享了自己的排查过程：元凶往往不是模型，而是设置面板里两个几乎没人动过的滑块——重复惩罚（repeat penalty）与出现惩罚（presence penalty）。二者功能相近却各司其职，网上大量教程把它们混为一谈，反而误导了调参方向。

一、默认值为什么不适合日常使用

本地模型的默认参数多为跑分评测调校，并非为日常对话设计。日常很少人每次都精心挑选示例、配上完整思维链指令。

LM Studio、Ollama、llama.cpp 基于同一核心引擎，但默认参数各自不同。

量化会把问题继续放大。多数人为了塞进显存跑 Q4 或 Q5 而非 FP16，精度一降最先冒头的就是重复和循环，小模型尤其明显。另外 Qwen 倾向过度解释，Gemma 长对话易啰嗦。

二、两个滑块分别管什么

重复惩罚是词元级别的控制，来自 2019 年的 CTRL 论文，作用是惩罚已出现过的具体词元。中性值 1.0，高于 1.0 开始抑制复用。甜区很窄，调到 1.05 或 1.1 通常就能清掉词语层面的循环；一旦推到 1.2，模型可能连「的」这类常用词都开始躲，输出反而古怪。命名上需留意：llama.cpp 称 repeat_penalty，OpenAI 接口最接近 frequency_penalty，Hugging Face 则名 repetition_penalty。

出现惩罚同样作用在词元层，算法却不同。重复惩罚随复用次数加重，出现惩罚是「出现过就扣一次固定分」，出现十次和一次扣得一样多，中性值 0，常见区间 -2.0 到 2.0。它把模型推离刚用过的那批词，换了词往往就换了话题——「同一个观点绕四遍」正源于此，并非模型真在做语义理解，只是好用的词元被耗尽后的副产品。

三、三组实测对照

这位撰稿人用同一条提示词跑了三轮，模型、温度、min-p、系统提示词全部固定，只改这两个参数：「用三种方式解释什么是 REST API：面向新手、懂 HTTP 的人、正在动手实现的人」。

1. 两项都保持中性：回答表面正常，但 Qwen 犯了老毛病，每个小节都要先把「REST API 是一套规则」重述一遍才进入正题。
2. 两项都拉满（重复 1.3、出现 1.8）：开头尚可，接近结尾时不再生成完整句子，退化成一串地理名词堆砌，只能手动中止。这就是过度矫正——惩罚把合理的高概率词元也饿死了。
3. 取中间值（重复 1.1、出现 0.6）：输出干净的三段式解释，三类读者各自拿到了不同角度。

注意事项

这两个滑块奖励微调、惩罚猛拉。上述数值是在 LM Studio 里跑 Qwen 9B 得出的，只能当起点。温度也会参与其中：处于 0 或 0.1 时模型本就趋于确定，惩罚几乎没有发挥空间，0.6 到 0.8 之间才留有余地。

按任务微调同样重要：写代码时重复惩罚应贴近中性，因为代码本就要重复语法；推理类模型需要更低的出现惩罚；Q3、Q4 这类低精度量化整体宜用更轻的惩罚。模型的 Hugging Face 页面若给了推荐配置，从那里开始最省事。

来源：XDA Developers

How-To Geek 作者 Nick Lewis 用自己的经历给出了对照：8GB 显存大致只能跑 70 亿参数（7B）模型，12GB 能跑 140 亿（14B），到了 16GB 才够跑 240 亿（24B）量级；而一个 270 亿（27B）的 Q4_K_M 量化模型，单是权重就要吃掉约 16GB 显存。

这还没算注意力缓存（KV cache）。它是模型记住上下文的临时内存，会额外占用显存的 25%（在 8K 上下文下）到翻倍（32K 上下文）。很多工具的默认上下文很短，比如 Ollama 默认只有 4096，所以小测试里显得很省，一旦把上下文拉长，显存立刻见底。

更关键的是，真实场景往往是好几个模型一起跑：主对话模型、负责向量检索的嵌入模型、再做一遍重排序的模型……一条典型的自动化流水线里同时跑 4 到 5 个模型并不稀奇。

混合专家模型（MoE）是个出路。这类模型只在每次推理时激活其中一部分参数，一个 200 亿级量化模型配 6 万上下文，在 RTX 5070 Ti 这样的显卡上能跑出每秒 100 个词以上的速度。优化手段还包括：把注意力缓存量化到 8 位或 4 位（一行配置即可）、主动限制上下文长度、用 MoE 替代稠密模型、把放不下的层卸载到 32GB 或 64GB 的系统内存。

说白了，16GB 不是「过剩」，而是「刚好及格」。想同时舒服地跑多个模型、留足上下文，24GB 才是真正的甜点档。打算本地玩 AI 的人，买卡时显存容量比核心频率更该排在前头。

来源：How-To Geek（作者 Nick Lewis，2026-08-09）

模型在别处跑，智能体留在手机上

XDA 试的 RikkaHub Agent 是开源安卓大模型客户端 RikkaHub 的一个分支，只在 GitHub 上发布，装完得自己填接口地址。它在聊天客户端之上加了一层智能体，带来 80 多个设备工具：点按、滑动、输入、截屏、开应用、读通知和传感器、收发短信，还有内置浏览器、SSH 和文件搜索。

模型不必装在手机里。对它来说家里的服务器和云端没区别，都是 OpenAI 兼容接口，填成自定义服务商即可，测试跑的是 Qwen 3.6 的 27B 和 35B。手机只跑循环、调工具、递结果。

它真的会自己动手

撰稿人问手机上装没装 whisper.cpp。它自查后回答没装，指出缺命令行工具和模型两样，再问要不要装。得到同意后装依赖、拉仓库、在 Termux 里编译完，前后七分钟，还自己挑了 75MB 的小模型。

权限默认全关

安全分三层：所有工具默认关闭，且按「助手」分别开，可以给云端模型单独配一个没有设备权限的助手；有副作用的操作会弹窗，允许一次、本次会话、永久或拒绝；抹机、重启、毁系统文件这类命令另有一份硬拦截清单，弹窗之前就被挡下。开发者也讲明这层只是基础正则，抓不住先赋值给变量的写法。

代价是开关藏得深：不在应用设置里，而在助手配置里。工具开得越多提示词越长，默认 7000 个输入词元，全开涨到 32000。

我的判断是，模型放服务器、智能体跑手机上，眼下是最合理的分工。想试先在电脑上把本地模型的兼容接口开好，再从读通知、搜文件这类只读工具开起，别一上来全勾。

来源：XDA Developers

装完直接指向原来的库

他用 winget 一条命令装好，十秒左右，没有注册向导。首次启动问要不要配置 AI，跳过；接着让选文件夹，他没新建，直接指向自己的 Obsidian 库。

文件树原样加载：嵌套结构、文件名、格式全对得上，日记笔记的 frontmatter 完好，双链正常渲染。

关键在于 .obsidian 配置文件夹没被动过——工作区布局、启用的插件、快捷键、主题、图谱设置都在里面，动了就等于 Obsidian 被重置。试完不满意直接卸载，Obsidian 还是原样。只有一点：改了 .md 笔记本身，库里的笔记就真的改了。

Obsidian 要开插件的功能，它自带

反向链接、出链、标签、属性在 Obsidian 里属于核心插件，能开能关，也就可能被禁用或出毛病；在 SoloMD 里它们是应用本体。

打开任意笔记，右侧反链面板直接从已有双链填好，不用重建索引；标签面板读 YAML frontmatter 自动归类；属性检查器用快捷键唤出，字段带类型选择器，写入逐行精准，不会搅乱行内注释和数组格式。分屏做成工具栏按钮，命令面板集齐搜索、视图和文件操作。

缺的两样是 Bases 和 Canvas，把笔记当数据库查询仍是 Obsidian 的地盘。

AI 面板能接本地模型

AI 面板是自带密钥模式，列了 14 家供应商。OpenAI 那一项允许改 base URL，他把地址指向本机 LM Studio 服务，API key 随便填——LM Studio 不校验，SoloMD 只检查非空，几秒就接上本地模型。

选中文本用 Rewrite 会开对比视图：左边原文，右边改写，底下是接受、拒绝、重新生成。小毛病是模型选择器只列官方目录，指向本地服务时显示的仍是官方型号名，能用但没法确认哪个模型在回答。

眼下它的社区主题还很少，移动端也只有 iPad 版。

来源：XDA Developers

三个工具，各管一摊事

1. Claude Code。它常被当成写代码的，本质却是个能读写文件、能用终端的大模型。第一步在库根目录建 CLAUDE.md，写清文件夹结构、命名规范和它可能不认识的双向链接语法。它的”技能”就是一个装着 SKILL.md 的文件夹，任务对得上会自动调用；子代理是 .claude/agents/ 下的 Markdown 文件。工作流因此成了库的一部分，跟着一起备份、进版本管理。注意它跑在系统层面，不懂 Obsidian 改名时自动更新链接的规矩，这条得写进 CLAUDE.md。
2. Google Antigravity。从 VS Code 分支出来的智能体优先开发环境，建个项目指向笔记库，锁死不想被动的目录权限。它胜在多智能体规划：先给一份计划，还能派子代理并行。”审计孤立笔记、找出失效双链、标出重复内容”，一句话换回一份完整报告。做库审计时它中途自己写了段 Python 脚本验证结论。
3. AnythingLLM。本地智能工作区桌面应用，聊天、检索增强、代理都齐，通过 LM Studio 或 Ollama 接本地模型。要么开文件系统访问、填库目录路径直接读写，要么用内置的 Obsidian 连接器把整库导入做向量化。工作区还能切片，不同笔记各配一套模型和提示词。短板是检索效果取决于嵌入模型和分块质量，长期跑得配块好显卡。

我的判断是，值钱的不是某个具体工具，而是把库当目录、让外部程序进来干活这个思路——要可复用工作流选 Claude Code，要能全库审计选 Antigravity，要内容不出本机选 AnythingLLM。Obsidian 本体免费，官方同步每月 4 美元。插件换代你得重配，目录结构却始终是自己的。你库里躺着多少条失效双链？

来源：XDA Developers