Jotbus：给 coding agent 之间传递上下文的一个加密便签板，上手只要一行命令

在 Hacker News 上看到一个 Show HN 项目，叫 Jotbus，一个专门给 coding agent 用的共享加密速记板。发布者一句话点透了痛点：我经常要在不同 coding agent 之间复制粘贴上下文和文件，要么跨机器，要么从我到队友。我做了 Jotbus，就是为了不再干这事。

上手方式简单得有点不像话，一条 npx jotbus 就能跑起来，不需要注册登录。它会创建一个临时共享工作区，通过 MCP 把它接到你在用的 coding agents 上。装好之后你直接跟 agent 说一句「write this handoff note to jotbus」，或者「send that PDF over Jotbus to @codex」，另一个 agent 加入这个 workspace 把它拉走就行。

这类「给 agent 传递上下文」的工具，其实不是全新概念。评论区第一位就发问：这跟用一个 skill 配合私有 git 仓库 / 文件存储 / 服务器有什么本质区别？我自己已经用远程 git、通过 push/pull 让 agent 之间互传分支和文件，Jotbus 凭什么值得我多搭一遍这个 overhead？

作者自己的回答挺实在：如果你的 repo/server/skills 已经把这套东西调通了，那 Jotbus 确实给你的增量不大。他做这东西的动机就两条——第一，他频繁要「找地方倒东西」给人和 agent，想要一个跨环境简单、不用维护 infra 和 glue 的办法；第二，他传递的很多是进行中的临时内容：日志、半成品实现、截图之类。这些东西还不适合 commit，也不一定要进 git history，就想找个地方快速交接然后继续干。所以他坦白说：这不是什么新颖的原生原语，就是个让这件事更快更省事的工具。

评论区的氛围也很典型，一个人提到自己同样思路的东西做了两次（分别给个人和工作用），一边觉得这东西不够独特到值得打磨和商业化，一边又好奇：要是真能像付费服务一样直接 drop in 而不是自己搭，会不会反而更划算。还有个做类似工具的哥们儿直接在帖子里打起了广告，说自己做的也支持文件共享，甚至被另一位用户认成是「一直在找的 provider-agnostic 版 Claude Artifacts」。

Jotbus 在加密上下了一点功夫。消息和文件端到端加密，加密在本地完成，托管服务只存密文，workspace key 永远到不了 Jotbus。有人把这个拎出来单独说，觉得加密不只是保护自己想法隐私这么简单，它某种程度上也在影响「独特 / 多元想法」的生成和演化。这个观察有点意思，不过我没法替作者确认这算不算设计初衷。

另一位评论者的观点值得写下来：如果觉得成本吃不消，真该去试试类似 OPs（应该指 Operations，大概是某种 summary/next-steps 的交接工作流）的做法——把长任务拆开，靠生成 summary 和 next step 再起新 agent，能大幅降低运行成本。他说自己经常不是被 $20 的 Claude 订阅卡住，而是时间不够、精力不够，如果不提前分步共享，配额 20 分钟就能烧光。这话对常年跑长任务、反复喂上下文的人应该很有共鸣。

Jotbus 这个项目目前 21 分、13 条评论，算不上大热，但它正好戳中一个越来越普遍的现场：当 coding agent 从「单次对话」变成「多 agent 协作」的产物，上下文交接就成了一件需要专门工具去解决的问题。而且它选的切入点是「临时、进行中、不想进 git history」的中间态，这恰好是现有 git 工作流不太好覆盖的一段。至于它能不能靠这个立足，评论区里「我做过两次了，不觉得够独特」和「如果真能 drop in 就用付费的」这两派意见，大概就是这类工具接下来的真实处境。

想试的人直接 npx jotbus 就行，不需要账号。至少对「临时倒上下文给 @codex」这种场景，它比手动复制粘贴省事得多。