plannotator
为中华之崛起而读书。——周恩来
我们造了十个 agent，然后发明了一个新岗位：审阅员
先吐个槽
过去两年，行业干了这么一件事：把编程 agent 从一个做到十几个。
Claude Code、Codex、Copilot CLI、Gemini CLI、OpenCode、Kiro、Droid、Amp、Pi、DeepSeek Harness——每一个都有自己的命令、自己的配置、自己的脾气，以及一个共同的假设：你应该住在它的终端里。
然后我们发现了新问题。
问题不是 agent 不够强，是它们产出太多了。一个 agent 跑完，丢给你一个计划、一份规格、一个 HTML 原型、一个 diff。十个 agent 跑完，你面前堆着四十份东西，每一份都等着你说「行」或者「不行」。
于是这个行业最荒诞的一幕出现了：我们发明了一堆替你干活的工具，然后被它们的产出淹了。
Plannotator 就是来捞人的。它的描述写得很长，但核心只有一句：一个让你留在循环里的工作区——成形、决定、规划、标注、审代码、分享给团队，然后一键把反馈发回给 agent。
项目地址：https://github.com/backnotprop/plannotator
注意「留在循环里」这四个字。它没有说「让你的 agent 更聪明」，它说的是——别被踢出局。
它到底是什么
一句话：一个本地的、跑在浏览器里的审阅面。
它不生成代码，不做推理，不当 orchestrator。它做的事情非常窄：把 agent 想给你看的东西，摊在一个可以标注的界面上，然后把你标注的结果，原路送回去。
而它接进 agent 的方式也很朴素：插件、hooks、命令。
当 agent 提出一个决定、一份计划、一个 HTML，或者干脆干完活了，这个应用就在你的浏览器里打开。你在上面划、写、圈，然后把反馈发回去，让它照着改。
这个流程听起来平平无奇，但它填的是一个很具体的坑：agent 的输出，不适合在终端里审。
终端是给「一行行往下滚」的东西准备的。而一份计划有层级、一份规格有段落、一个 HTML 原型有布局。你没法在终端里指着第三段的第二句话说「这里不对」。
浏览器可以。这就是它存在的一整个理由。
三个面，一个数据目录
它把自己分成三块：
Inbox。 官方管它叫「你和多 agent 工作之间缺失的那层审阅」。它把决定、原型、变体、计划这些东西收集起来，让你知道有哪些东西在等你。
Artifacts。 计划、规格、Markdown、HTML，以及「其他可交互的产物」。这个词用得很宽，宽到有点可疑——但至少它没假装自己只能审 Markdown。
Code Review。 审本地改动或者远端 PR，在 diff 上评论、建议代码，然后评论回到 agent 那里。
代码审阅那一段，有一个细节值得单独拿出来：它支持 Git、GitButler、Jujutsu、Perforce、GitHub、GitLab。
前四个是本地版本控制工具，后两个是托管平台。把 jj 和 p4 和 GitHub 并列，说明作者不是只在自己那一套工作流里测过。Jujutsu 这两年在爱折腾的人里很流行，Perforce 则是游戏和芯片行业的老人——这两个用户群几乎不重叠，而它都接。
一个工具的兼容列表，往往比它的功能列表更能说明它想服务谁。
命令：四种目标，一个「上一条」
Annotate 那一节的示例，写得像一份菜单：
1 | /plannotator-annotate README.md # 本地 markdown 文件 |
四种目标：一个文件、一个目录、一个网址、一份要原样渲染的 HTML。
最后那条最实用。/plannotator-last 的意思是：别费劲找文件了，就审它刚才说的那段话。
因为真实场景里，你最想吐槽的往往不是仓库里的文件，而是 agent 刚刚在对话里洋洋洒洒写的那三百字。而终端里你只能回一句「不对，重来」——它还得猜哪里不对。
那个 --render-html 说明了产品的一个小心思
示例里有一条命令带了个开关：report.html --render-html，注释写着「按原样渲染 HTML，而不是转换」。
这个「而不是转换」值得琢磨。
它的默认行为是把 HTML 转成更适合标注的形态——这在审阅长文档时是对的，你想要的是一段段可引用的内容，而不是一个跑在浏览器里的页面。
但有一类产物不行：原型。
如果 agent 给你的是一个带布局、带交互、带状态的页面，你把它转成文本，等于把要审的东西审没了。你没法判断「这个按钮的位置对不对」，因为按钮已经不是按钮了。
所以这个开关的存在，等于承认了：审文字和审界面，是两种不同的审阅。
一个工具愿意为这件事留一个后门，说明它见过真实场景里那次翻车——转完之后，人看着一堆 div 发呆，不知道自己在审什么。
Codex 用户请换一种语法
有一段小字，藏在命令标题下面：
在 Codex 上，把斜杠命令换成 !plannotator …，或者用 $plannotator-* 技能。
这句话短，但它是一份行业现状的切片。
同一个功能，在 A 家是斜杠命令，在 B 家要加感叹号，在 C 家是技能，在 D 家是 MCP 工具。于是任何一个想「支持所有 agent」的工具，第一件要干的活不是写功能，是写适配层。
而适配层是没有尽头的。今天 Codex 用感叹号，明天它可能改成别的；今天 Copilot CLI 认这个目录，明天它换个路径。
这就是「十种 agent」这个数字的真实成本：它不是十份快乐，是十份维护。
Herdr：把审阅搬回终端
这一节挺有意思，因为它和整个产品的立意相反。
Plannotator 的主张是「去浏览器里审」，而 Herdr Annotate 的主张是「回终端里审」。
它做的事：在 Herdr 里标注终端文本、审整份 Markdown 文档、审 coding agent 的回复，然后把反馈作为下一条消息直接发给 agent。支持 Claude Code、Codex、Pi、Copilot CLI、Droid 的回复。
关键在于最后一句：标注保存在 Plannotator 的数据目录里，所以终端里的审阅和应用里的审阅会累积在一起。
这句话解决了一个很容易被忽略的问题：审阅是有上下文的。你在终端里标了一段，又在浏览器里标了一段，如果这两份东西各自为政，那 agent 收到的是两份互不相干的意见；而如果它们进同一个账本，agent 看到的是一条连续的讨论。
装法有两种：作为 Herdr 插件，或者单独装一个 TUI。后者说明它没打算把用户锁在 Herdr 里——你可以只用那半个产品。
支持列表：十加四
文档顶部挂了两排图标。
第一排是编码 agent：Amp、Claude Code、Codex、Copilot CLI、Droid、Gemini CLI、Kiro、OpenCode、Pi。
正文里数了一遍，还有 DeepSeek Harness。十个。
第二排没画图标，但在文字里点了名：Grok Bot、Muse、Hermes、OpenClaw。四个「个人助理」。
这个区分挺讲究。前十个是「写代码的」，后四个更像「陪你办事的」。而 Inbox 那个面，是唯一同时服务两边的东西——因为不管是写代码还是办事，你都需要一个地方看看「它在等我决定什么」。
换句话说，它把自己从「代码审阅工具」往上抬了半格：它审的不是代码，是决定。
所以它卖的是什么
不是功能，是节奏。
多 agent 工作最难受的地方，不是某个 agent 不听话，是你不知道现在该看哪个。十个进程各跑各的，谁在等审批、谁跑完了、谁跑歪了，全靠你自己维护一张脑内表格。
而这张表格总会漏。
Plannotator 赌的是：把「等你看」的东西集中到一个面上，把「你的意见」集中到一条回路上，人的注意力就能重新变成一个可管理的资源。
它当然不解决根本问题——agent 越多，要审的越多，这个数字不会因为它而下降。它只是让你不至于在第四个 agent 的输出面前放弃治疗。
最后
回到开头那个荒诞。
我们花了两年让 agent 能自己干活，然后发现瓶颈挪到了「人点头」这一步。而且这个瓶颈比写代码那个更硬——因为代码可以并行，点头不能。
于是工具开始往回长：不是让 agent 更自主，是让人更省力地当那个审批的人。
Plannotator 是这个方向上做得挺老实的一个：它不假装能替你做决定，它只是把「要看的东西」和「你的意见」这两端接起来，中间那一下还是你自己按。
听着不够革命。但说真的，这个行业现在缺的不是更多会写代码的东西，是更少需要你来回切换窗口的东西。
至于那十个 agent 各自的命令语法——祝适配层长命百岁。