王杰岸Hookmark 这软件我用了快五年，从它还叫 Hook 的时候就开始折腾。真正让我觉得“知识管理终于有了出路”的时刻，不是它能把两个文件配对，而是我头一回用 Protocol Launcher 把一个带 mailto: 协议的邮件地址，从零散的联系人信息里拉出来，跟项目文档、日程事项写进同一条关系链。那一刻我才意识到：深度链接这件事，难点从来不是“点一下就跳转”，而是你怎么让不同类型的资源，在同一个网络里被平等地链接、被协议正确地识别、被工具稳定地打开。
如果你也囤过知识，却苦于资料之间没有关联；如果你在 Mac 上同时用 Obsidian、Finder、备忘录和浏览器，却总觉得每个 App 都是一座孤岛——这篇文章就是给你写的。我会把 Hookmark 构建知识网络的完整逻辑拆开，重点讲清楚 Protocol Launcher 这个被大多数人忽略的功能，它如何在深度链接中扮演“调度中心”的角色，以及我常年积累下来的避坑经验。
1. 为什么“深度链接”比“整齐的文件夹”更适合知识网络
1.1 文件夹思维的天花板
很多人整理知识，第一步就是建文件夹。我也这么干过：按“项目”“领域”“存档”分好几层，每一层再往下细分。看起来秩序井然，用起来却不舒服。原因很简单：文件夹是树状结构，而知识之间的连接是网状结构。一个 PDF 可能同时属于“营销方法论”“某客户项目”“今年重点学习方向”三个不同的主题。你把它放进哪个文件夹，都意味着其他连接点被强制切断。你只能靠“复制一份”或“加个标签”来补救，但复制会让内容失控，标签则永远有遗漏。
深度链接换了一个思路：先让每个文件、网页、邮件、笔记都拥有一个可以被稳定引用的“地址”，然后通过链接把这些地址两两连接。连接本身不需要移动任何文件，也不需要修改文件夹结构。文件夹变成了“常驻入口”之一，而不是唯一的存在方式。这种模式下，一款 PDF 可以被同时链接到项目文档、会议纪要、相关网址，没有任何归属冲突。
1.2 Hookmark 的底层模型：项目与 hook
Hookmark 的底层模型只有两个核心概念：项目（item）和 hook（关系）。项目是任何可以在 macOS 上通过 URL 定位的资源：一个 Finder 文件、一个网页、一封邮件、一条 Reminders 提醒、一个 Obsidian 笔记、一份日程、一个联系人。Hookmark 给每个项目分配一个规范 ID，存进它的库（Library）里。只要你在 Hookmark 里复制过一次链接，这个项目就被登记了。之后即使文件被移动、重命名，Hookmark 依然可以靠规范 ID 找到它——这一点很关键，等于是给“链接”上了保险。
hook 则是两个项目之间的双向连线。它的本质是 hook:// 协议的一个调用。你在一篇笔记里粘贴另一份 PDF 的 hook 链接，点击时 Hookmark 会被唤起，它去库里解析这个 ID，打开对应文件，然后建立两条指向关系。这个过程看起来只是“打开了链接”，实际上是在关系图谱中新增了一条边，而且这条边是双向的。所以我说，Hookmark 不是在帮你“存链接”，是在帮你“织图”。
1.3 复制链接、贴链接、沿链接回访
使用 Hookmark 形成知识网络，日常操作其实只有三步。第一步，把当前选中的项目加入库并复制链接。全局快捷键默认是 Control+Command+Space，按下去会弹出一个链接面板，里面有这条链接的多种格式，包括 Hookmark 的 hook 链接、Markdown 格式、HTML 格式甚至纯文本 URL。第二步，到另一个项目里粘贴。无论粘贴到哪里，Mac 系统都会把这段内容识别为可点击链接。第三步，回访。点击链接时，Hookmark 打开目标项目，同时把当前项目标记为关联项目，你随时可以通过 Hookmark 的悬浮贴纸或菜单查看“与本项目相关的所有内容”。
三步配合起来，就形成了一个闭环。你不再需要在备忘录里写“那篇文章的 PDF 在 Downloads 里面”，而是直接有一条从备忘录指向 PDF 的深度链接。当你积累了足够多的 hook，知识网络就活起来了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Protocol Launcher：深度链接背后的“协议调度中枢”
2.1 它解决的真正问题，是“一个项目有多重身份”
很多人学 Hookmark 时，会陷入一个误区：认为一个项目只有一个 URL。实际上，一个项目在 macOS 的 URL Scheme 体系里可以拥有多个身份。网页是 https://，本地文件是 file://，邮件是 message://，苹果备忘录是 mobilenotes://，日历日程是 ical://。Hookmark 在展示路径时通常会帮你选择一个“最佳协议”，但你总有需要绕过默认选择的时候。
Protocol Launcher 就是干这个的。它打开后，会列出当前项目在不同协议下的可用表达方式，以及每个协议由哪个应用处理。你可以切换打开应用、复制某个特定协议下的链接、把某个 URL 的变体加入库作为新项目。这不是一个锦上添花的玩具，而是一个真正的调试台和调度器。我在工作中，遇到“网页我想用 Chrome 打开但 Hookmark 默认是 Safari”“笔记里想引用一个本地文件的 file 协议路径”这类需求，全靠它解决。
2.2 在哪里找到它，以及常用的打开方式
Protocol Launcher 的入口不算显眼，但一旦你知道了就会习惯它。在 Hookmark 的主菜单栏图标中能打开“Open Protocol Launcher”，也在工具的菜单里可以找到；我更习惯在 Hookmark 设置里给它分配一个自己的快捷键，例如 Control+Command+Option+P。分配完之后，任何时候选中一个项目，按快捷键就能把这个东西调出来。
界面结构和它的用途非常匹配：上方显示当前项目名称，下方按协议类型分组展示可用链接。比如你正在看一个 Safari 网页，这里会显示 https 协议、当前 URL、系统注册的各个浏览器。你可以点系统链接把它加入 Hookmark，可以用“复制链接”复制当前协议地址，也可以用“打开”直接交给另一个应用。如果你需要查看某个项目当前到底存在几种历史 URL，这个窗口就是最直接的答案。
2.3 “处理协议的应用”列表里，谁说了算
Protocol Launcher 展示的“处理该协议的应用”，并不是 Hookmark 自己硬编码的，而是 macOS 系统根据各应用注册的 CFBundleURLTypes 信息维护的。你要理解一个现象：某个 URL 点到 Protocol Launcher 里，处理应用列表里没有某款浏览器，并不代表这款浏览器装坏了，而是它没有在系统里登记这个协议的处理权限。在这种场景下，Protocol Launcher 更像一个操作台，你可以自己选择一个合适的应用并“指定”给它，也可以在列表里修复系统级协议关联。
这也就引出了 Protocol Launcher 的第一个衍生功能：它把系统底层的协议分配逻辑，摆到了生产环境的前台。你不需要跑 open -a 命令，也不用进 System Settings 去翻默认应用，直接在 Protocol Launcher 里完成。对于那些想深度管理协议的人来说，这相当于把一个原本藏在系统设置里的开关，放到了知识库的日常工作流中。
3. 实战拆解：用 Protocol Launcher 打通三种跨应用深链
3.1 一键让同一个网页在不同浏览器之间切换，并保留网络关系
我工作中经常遇到一个场景：在 Safari 里看到一篇技术文章，想切到 Chrome 里配合浏览器扩展做标注，之后还想在 Obsidian 里记录这篇内容的笔记。以前的做法是手动复制网址、切换浏览器、粘贴地址，再到笔记里粘贴标题。现在用 Protocol Launcher 可以走得更顺，而且多了一层关系保留。
具体步骤是这样：在 Safari 里按 Control+Command+Space，把当前网页复制为 hook 链接；打开 Protocol Launcher；在列表里选中 Chrome 的 https 处理项，执行“用 Chrome 打开”。Chrome 启动后打开同一页面，Hookmark 通常会自动识别这是同一个项目，并弹出提示询问是否将两个窗口视为同一项目。确认合并之后，这个网页在 Hookmark 的体系里就有了“两个窗口指向同一个项目”的属性。之后你在 Safari 里对它建立的链接，到 Chrome 那边点击，也能正常打开——关系没有被浏览器隔离。
这个过程的价值，从“换浏览器”这个表象上看不出来。它的深层价值是：无论你用哪个浏览器访问同一个网站，在你自己的知识网络里，它仍然是同一个节点。你做过的标注、写过的笔记、关联的 PDF，不会因为浏览器的变化而断掉链接。
3.2 把本地文件变成可复用的 file:// 链接，嵌入 Markdown 和知识库
另一个高频场景是本地文件的引用。Obsidian 里经常需要挂载本地 PDF 或图片。直接拖动文件进笔记通常得到的是一个相对路径，换一台电脑就失效了。如果用 Hookmark 复制链接，得到的是 hook:// 链接，好看但并不通用。这时候 Protocol Launcher 就派上了用场。
在 Finder 里选中目标 PDF，按 Control+Command+Space 复制 Hookmark 链接；打开 Protocol Launcher，你会看到这个文件在 file 协议下对应的完整地址。直接用“复制链接”把它复制下来，粘贴进你的 Markdown 笔记，得到一个类似 file:///Users/xxx/Documents/... 的路径。这种做法在本地知识库里非常实用，因为它不依赖 Hookmark 是否运行，只要是 macOS 系统，点这个链接就能打开对应文件。你甚至可以在 Protocol Launcher 里把 file:// 也保存为一个 Hookmark 库项目，这样既能在系统里直接打开，又能跟其他笔记建立 hook 关系。
3.3 邮件、日程、提醒事项等特殊协议，如何变成知识网络的节点
说到特殊协议，邮件一直很关键。我们经常在项目笔记里写“关于合同的邮件在收件箱里”，可这句话在几个月后毫无检索价值。真正有用的方式是，把邮件变成一条可链接的深度链接。在 macOS 邮件 App 中找到那封邮件，用 Hookmark 的“复制链接”普通操作即可为它生成 hook 链接。但如果你想在纯文本记录中引用一封邮件，不加任何 Hookmark 依赖，就可以在 Protocol Launcher 里调出 message:// 协议对应的链接并复制。
日程和提醒事项也差不多。Protocol Launcher 能看到它们的 ical://、x-apple.reminder 等协议。你可以把一条日程的链接放到相关文档里，让文档和日程不再是两张皮。我做项目启动检查时，经常会建一个“项目主页”笔记，把相关的网页、文件、邮件、日程全部以深度链接的形式钉在一页里。这样每次进入项目，只需要打开一个页面，就能通过链接跳到所有相关资源，不需要再翻找邮箱、文件夹和日历。这套东西之所以能成立，正是因为 Protocol Launcher 让我可以控制在每个协议层面，链接到底指向哪里。
4. 链接网络里的各种故障，Protocol Launcher 是最好的排查入口
4.1 点击 hook 链接没反应，第一件事不是重装
Hookmark 用了大半年以后，大概率会遇到一个现象：某个 hook 链接点击之后毫无反应，或提示无法打开指定项目。我看到很多人的第一反应是摸向卸载按钮，其实大多数时候，问题出在项目的 URL 协议上。
把当前受影响的项目在 Hookmark 里选中，打开 Protocol Launcher，你会立刻发现问题端倪。常见情况有三种。第一种，项目对应的应用被移动或卸载，协议处理列表为空；第二种，项目的规范 ID 在库里还存在，但原始文件路径已经失效，Hookmark 无法定位；第三种，链接里写的是旧的 hook:// ID，但库里已经不存在这个项目。
Protocol Launcher 此时不只是展示问题，还能给补救提供线索。如果是协议处理列表为空，你可以重新打开应用让它重新注册协议，或者手动选择一个替代应用处理；如果文件路径失效，可以在 Protocol Launcher 里重新加一个 file 协议的新项目，把它链接到已有项目的旁边。处理速度比你去翻 Hookmark 数据库快得多。
4.2 协议的默认应用被劫持，怎么用 Protocol Launcher 拉回来
在 macOS 上，一个协议可以被多个应用声明。比如 https://，Safari、Chrome、Edge、Arc 都有资格处理。系统通常会记住你最后一次“用某应用打开”的选择，但有时会被安装的新应用切换掉，或者你手动改了系统默认软件，导致 Hookmark 里点击链接跳到了不想去的浏览器。这种事很烦，因为你不是在改一个全局设置，而是在处理“某一个具体项目的打开方式”。
Protocol Launcher 的方案是把选择权放到项目级。你打开它，看到当前项目当前协议的候选应用列表，选择目标应用，执行打开操作。这样修改只影响这个项目的这次打开，不会动系统全局默认软件。如果你希望某个网站的链接以后都走 Chrome，就在 Protocol Launcher 里选用 Chrome 打开，并在提示中记住这个决定。等于你可以在知识网络内做“局部的协议路由”，而不是被全局设置牵着鼻子走。
4.3 已卸载应用留下的“僵尸协议”怎么清理
卸载一个应用之后，它的 URL 协议并不会自动彻底清除，有时会在 Protocol Launcher 的候选列表里留下一个存在但不可用的处理者。点击后系统可能弹出“该应用已损坏”或直接没有反应。清理的办法不算复杂：在系统默认应用设置里，把相关协议重新分配给现存应用；如果协议项本身已经是一个残留的空壳，那么把它在 Protocol Launcher 里的子层级忽略，只保留你需要的那几个备选。
我有一次重装系统后，发现 Protocol Launcher 里列了两个“未知应用”处理 https://。后来我进 ~/Library/Preferences/com.apple.LaunchServices/com.apple.launchservices.secure.plist 手动检查了一下相关记录，删除掉无效项，重置 LaunchServices 数据库，列表才恢复正常。这个操作需要一定命令行经验，平时能不做就不做，用 Protocol Launcher 在应用层重新指定一次，绝大多数场景已经够用。
5. 把 Protocol Launcher 变成自动化工作流的一环
5.1 用快捷指令调用 Hookmark，让链接复制不再靠手速
Hookmark 本身支持快捷指令（Shortcuts）。你在“快捷指令”App 里可以找到“Hookmark：复制当前项目的链接”“Hookmark：显示项目链接面板”等动作。把它们组合进你自己的快捷指令，就能实现一些批处理操作。
我常用的一条快捷指令逻辑是：先获取当前 Safari 网页的 URL，然后调用 Hookmark 的“复制链接”把它变成 hook 链接，再发送到 Obsidian 的“每日笔记”里。这样每次读到值得记录的文章，只需要按一个快捷键，就能把链接放进笔记收集箱。Protocol Launcher 在其中的作用，是让我可以在快捷指令里不固定死协议——我可以先用 Protocol Launcher 把 URL 的协议形式检查清楚，再把它交给快捷指令去处理。对于那些内部批量生成的链接，这个校验步骤能避免一大半无效链接进库。
5.2 用 MD 链接与 HTML 链接输出，把网络和团队协作结合
Hookmark 的“复制链接”面板提供了多种输出格式，Markdown 格式适合写进任何笔记软件，HTML 格式适合放进网页或邮件正文，纯文本格式适合做记录。Protocol Launcher 让你能复制到某个协议下的任意一种格式，例如在网页的项目里，你可以拿到 https:// 协议下的 Markdown 格式链接；在文件项目里，可以拿到 file:// 协议下的链接。
这对团队协作非常有用。假设你在团队共享的 Notion 页面里，想引用本地项目的技术方案 PDF，直接放一个 file:// 链接，对同事的 Mac 不一定有效，但放一个 Hookmark 的 markdown 链接，他们如果也用 Hookmark，就能直接打开并建立双向关系。Protocol Launcher 的价值在于，你可以为同一份资料生成多种协议表达，满足不同协作场景对链接格式的要求，而不是只输出一种“私有链接”。
5.3 建立自己的“协议工作流”，把知识网络升级为执行网络
深度链接的极限，不只是把阅读型资源连接起来，还能把“动作”也变成网络节点。我在 Protocol Launcher 里经常使用 shortcuts:// 协议，把一条快捷指令封装成一个项目；或者在笔记里放一个 x-apple.reminder:// 的提醒链接，把想法与行动绑定。
举个例子：我在项目笔记里写一句“周三前确认合同条款”，同时通过 Protocol Launcher 复制了一条 x-apple.reminder 链接，把它挂在正文下方。点击链接，macOS 会直接唤起提醒事项并定位到对应条目。这样我的笔记既记录了目标，也包含了进入执行动作的路径。知识网络从“链接到资料”跨越到“链接到动作”，这是我觉得深度链接最值得投入的方向。Protocol Launcher 在这里的核心价值，是给所有协议一个统一的管理入口，让我不用每次去记忆各种私有协议的名称和规则。
6. 我的实践心得与三个容易被忽略的小细节
用了这么多年，我的总体体会是：Hookmark 的意义不在于“优雅地打开链接”，而在于让你敢于在笔记里留下更多“关系”。以前我不敢在笔记里放太多外部引用，因为链接容易失效；随着我对 Protocol Launcher 的熟悉，我越来越敢写“详见那封邮件”“相关文件和网页见链接”，因为我知道每个链接都能被检查、被修复、被重新路由。这个安全感，对知识管理很重要。
有几个小细节，对刚上手的人帮助很大。第一，不要把“复制链接”理解为“得到一段网址”，那是在为一个项目登记身份。复制链接之前，确保你当前的窗口是目标项目所在的应用，否则会抓到错误项目。第二，Protocol Launcher 里看到的“项目名称”有时候不是你想要的那种可读名称，它是 Hookmark 从元数据中提取的规范化标题，如果这个名称是“未命名”或乱码，说明这个项目在来源应用中的标题字段没有正确设置，可以再整理一下源数据。第三，Hookmark 的库会有少量重复项，比如同一个网页经过多次协议切换可能会生成两个项目，如果你发现自己的知识图里出现了两个看起来一模一样的节点，可以在 Protocol Launcher 里对比它们的协议链接，把多余的那个从库里清理掉。
最后分享一个我很受用的小技巧：每次新建一个重要项目，我都先用 Protocol Launcher 把它的 hook://、file://、https://（如果存在）三种协议形式分别验证一遍。不是我强迫症，而是验证一遍之后，后续无论我在哪个场景引用这个项目，都能保证它会稳定打开。这个“三协议验证”的习惯，让我这几年几乎没有因为链接失效而翻车过。