Vellum Assistant：八类记忆的本地个人 AI，但先看清它的边界

它解决什么问题：告别反复孵化 AI 的折腾

如果你用过 OpenClaw、Hermes Agent 或 Claude Code，你会知道搭建一个像样的个人 AI 有多费劲：要配记忆、调行为、写一堆配置文件，还经常得从头再来。Vellum Assistant 的目标就是把这个过程压缩成一条命令。README 里说，它开箱即用，下载就能得到想要的结果。它的核心卖点是八类记忆：情景、语义、程序、情感、预期、行为、叙事和共享。每种记忆都有自己的过期窗口，使用混合稠密加稀疏检索，并且按用户和渠道隔离。这意味着它不只是把对话存进 SQLite 或 Markdown 文件，而是有一套结构化的提取和去重机制。适合的人群很明确：那些想要一个长期使用、能记住偏好和工作习惯的助手，而不是每次对话都从零开始的临时工具。

记忆是怎么工作的：不是数据库，是行为模型

Vellum 的记忆不是简单的键值存储。文档指出，结构化条目如身份、偏好、项目和事件，会从对话中提取，并带有来源归属和去重。嵌入默认在本地运行，用的是 ONNX 模型，如果失败会自动回退到云服务。这个设计有实际意义：本地嵌入保护隐私，但也意味着你的机器要承担推理负载。记忆的隔离是双重的，既按用户隔离，也按渠道隔离。这意味着你在 Telegram 上说的话，不会自动出现在 Slack 的上下文里，除非你主动跨渠道延续。另外，行为定义在 SOUL.md 里，助手在 onboarding 时会观察你的沟通方式，然后自己写人格文件。它还维护一个按用户记录的反思日志，并用 NOW.md 作为当前焦点和活动线程的草稿纸。这套机制让记忆不只是存储，而是动态更新的行为模型。

运行方式：一条命令 hatch，但 CLI 只是配角

安装很简单，用 bun 全局安装：bun install -g vellum，然后运行 vellum hatch 来孵化你的助手。从源码安装也直接：克隆仓库，运行 ./setup.sh，然后 source ~/.bashrc，再 vellum hatch。常用命令包括 vellum wake 启动服务，vellum sleep 停止服务但保留数据，vellum client 通过终端交互，vellum ps 查看运行中的助手，vellum terminal 打开管理容器的 shell，vellum upgrade 升级版本。所有命令默认操作默认助手，如果你有多个，就把助手 ID 作为第二个参数传进去。但 README 明确说，CLI 能用，但桌面应用是主要焦点，CLI 只面向高级用户、贡献者和非 macOS 环境。这意味着如果你在 Linux 或 Windows 上，你只能依赖 CLI，而它显然不是优先维护的对象。

安全模型：默认拒绝，但边界要自己验证

安全设计是 Vellum 的一个亮点。actor 身份分为 guardian、trusted 和 unknown，只解析一次，然后在整个系统中强制执行。未知 actor 不能读记忆、不能触发工具、也不能升级权限。凭据放在独立进程中，模型永远接触不到。每个工具调用都跑在沙箱里，默认策略是拒绝。这意味着即使模型被诱导，也无法直接访问你的真实系统，除非你明确批准。这种设计在个人 AI 里算激进，但也很务实。不过，文档没有详细说明沙箱的具体实现，比如是容器还是进程级隔离。如果你要自托管，你需要自己确认沙箱是否真的能挡住恶意工具调用。另外，计算机使用功能允许助手在你的批准下读取和编辑文件、运行命令、驱动浏览器，批准可以是一次性、十分钟或永久。这个功能风险很高，永久批准等于放弃安全边界。

渠道和 OAuth：一个助手，多个入口

Vellum 支持 macOS、iOS、Web、Voice、Email、Telegram、Slack 和 Twilio 等渠道。关键是，一个助手只有一个记忆，跨渠道共享。你可以在 Telegram 上开始一个想法，然后在 Slack 上继续。OAuth 支持 Slack、Notion、Google、HubSpot、Linear、Discord、Twitter、Telegram 和 Twilio，不用自己手写 token 刷新。这对集成开发是实实在在的省事。但渠道多也意味着攻击面大，每个渠道都可能成为未知 actor 的入口。虽然安全模型声称统一执行身份解析，但你得检查每个渠道的接入点是否都正确调用了同一个验证逻辑。文档没有给出每个渠道的详细配置示例，所以实际接入时你可能需要翻 docs 站点的具体页面。

自托管 vs 托管：同一个代码库，不同的运维负担

Vellum 提供两种托管方式：Vellum Platform 的托管运行时，或者完全自托管。README 说两者使用同一个代码库和同一个数据模型。托管模式意味着你不用管基础设施，但你要依赖 Vellum 的云服务。自托管则一切自己来，包括本地嵌入模型、沙箱环境、凭据进程和渠道连接。自托管的好处是数据完全在你的机器上，但代价是你得处理升级、备份和安全补丁。CLI 的 vellum upgrade 命令可以升级，但升级会不会破坏现有记忆数据，文档没有说明。另外，配对设备的功能，通过开隧道和配对设备，让手机或其他电脑访问自托管的助手，这引入了网络暴露，你需要自己管理隧道安全。如果你选择托管，Vellum 的隐私政策和服务条款是你必须提前看的，因为你的对话和记忆会经过他们的服务器。

局限和替代方案：什么场景它不合适

Vellum 的第一个局限是 CLI 的次要地位。如果你不在 macOS 上，你只能依赖 CLI，而它显然不是主要开发方向。第二个局限是本地嵌入模型，虽然默认本地运行，但低配机器可能卡顿，文档没有给出最低硬件要求。第三个局限是记忆的复杂性，八类记忆听起来强大，但如果你只需要简单的上下文，这套机制是过度设计。替代方案方面，你可以考虑开源的 OpenClaw 或 Hermes Agent，它们也做个人 AI，但记忆机制更简单，通常基于文件或数据库，没有 Vellum 的混合检索和结构化提取。区别在于，Vellum 把记忆做成了内置的智能系统，而其他方案往往要求你自己搭建和调优。如果你想要一个能记住你偏好的助手，Vellum 值得试，但如果你只想快速跑一个对话代理，轻量方案更合适。

编辑结论

Vellum Assistant 适合那些想要一个开箱即用、记忆机制完整的个人 AI 助手，并且愿意接受托管服务或投入时间自托管的开发者。它不适合只想要一个简单聊天机器人、不愿处理记忆数据或担心安全边界的用户。在采用前，你应该验证三件事：一是本地嵌入模型在你的硬件上是否流畅，二是 SOUL.md 和 NOW.md 的生成是否符合你的预期，三是沙箱和凭据分离机制在你的工作流中是否真的能挡住未知 actor。如果你的需求是快速原型或临时任务，这个项目的复杂度可能超出你的需要。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes