Plannotator统一审阅编程Agent产出
Plannotator提供本地浏览器审阅界面，可批注计划、规格、Markdown、HTML产物，并审查代码差异和PR，再将反馈发送给Agent。它通过插件、钩子及命令接入Claude Code、Codex等多种工具，Inbox集中呈现待处理决策与产物。
AI 深度解读
AI 编程助手能同时写计划、改代码、生成页面，人却未必跟得上：问题散在不同会话里，反馈得来回复制，页面上的修改意见也很难用文字定位。Plannotator 想补上的，就是人与 agent 之间的审阅入口。
它把计划批注、HTML 标注、代码评审和多 agent 收件箱放到本地界面里，再把意见送回对应会话。这个方向值得看，但原文提供的是功能与机制说明，没有效率对照实验；是否适合你，取决于审阅是否已经成为工作瓶颈。
多个 agent 同时工作，缺的是一个收件箱
Plannotator 最初围绕计划审阅展开，现在的范围已经扩展到文档、消息、HTML 产物、代码差异，以及需要人作决定的各种事项。
它的基本流程很直接：agent 通过插件、钩子（hook）或命令触发审阅，浏览器打开本地页面；人选中具体内容，写批注，再把反馈交回 agent。相比在聊天框里描述「第三段不对」，它能让意见落到对应位置。
新加入的 Plannotator Inbox 则处理另一个问题：多个 agent 都在推进任务时，人不应该靠轮流翻终端找待办。
启动入口是 plannotator inbox。agent 可以往这个本地窗口投递问题、文件和引导式审阅，人有空时再回答，回复会送回发起请求的会话。
Inbox 的关键不是集中显示消息，而是让等待人工反馈成为可异步处理的环节。
原文称，等待回复时不需要一直保持 agent 会话开启。Claude Code、Pi、OpenCode 通过插件连接，回复作为下一轮消息到达；其他 agent 可以通过 plannotator inbox mcp 接入，并读取 plannotator inbox --help 了解用法。
这里要区分「支持接入」和「体验完全一致」。项目列出了 Codex、Copilot CLI、Gemini CLI、Kiro、Droid、Amp 等编码工具，也覆盖部分个人助手，但没有逐一说明它们在异步回复、自动唤起和上下文恢复上的差异。
Claude Code 的版本条件比较明确：在 2.1.287 或更新版本中，计划审阅、代码评审和批注不会让 Claude 一直等待；它结束当前轮次，决定随后以消息送达。设置 PLANNOTATOR_CLAUDE_MOD=0 可以恢复经典流程。
审计划、看页面和查 diff，为什么要放在一起
AI 编程的人工反馈往往跨越三种对象：准备怎么做、实际做出了什么、代码具体改了哪里。Plannotator 把这些对象放进同一套反馈流程，减少在不同工具之间搬运意见。
计划审阅可以通过各个 agent 的 hook 自动触发。原文给出的经典流程是：agent 调用 ExitPlanMode，触发 PermissionRequest hook，本地服务读取计划并打开浏览器。通过后继续执行；拒绝则把结构化反馈交回 agent，修改后的计划还可以查看差异。前面提到的新版 Claude Code 异步模式，则改变了等待和送达方式。
HTML 标注适合检查 agent 生成的页面原型。人直接面对渲染结果指出问题，避免把页面位置全部翻译成文字描述。需要按原样渲染文件时，参数是 --render-html。
代码评审继续使用程序员熟悉的 diff：查看改动、按行评论、提出代码建议，再把意见送回会话。下面这组命令覆盖本地改动、远程评审和静态补丁：
/plannotator-review # 审阅未提交的改动
/plannotator-review <github-pr-url> # 审阅 GitHub pull request
/plannotator-review <gitlab-mr-url> # 审阅 GitLab merge request
plannotator review --gitbutler # 审阅当前 GitButler 工作区
plannotator review --patch-file reading.diff # 审阅调用方提供的静态 unified diff
要注意前面的调用形式：这些斜杠命令适用于多数 agent；Codex 使用 !plannotator …，例如 !plannotator review，或者使用 $plannotator-* skills。
项目还提供 Ask AI 和 AI review：可以针对正在审阅的内容提问，也可以让 AI 把评审意见写到 diff 上。不过，这属于辅助审阅能力，原文没有给出误报率或缺陷发现率。
偏好终端的人可以选择 Herdr Annotate，通过 herdr plugin install plannotator/herdr-annotate 安装；独立文档审阅工具则可以用 brew install plannotator/tap/plannotator-tui 安装。终端批注也保存到 Plannotator 数据目录中，方便积累同一套审阅记录。
本地运行，哪些内容仍然会走网络
原文对数据边界交代得比较细。计划、diff、批注、草稿、历史和配置默认留在本地，项目声明不收集使用遥测或分析数据。但「本地工具」不能直接理解成「完全离线」。
各个审阅界面加载时会向 GitHub 检查最新版本，不发送计划或评审内容，目前也没有关闭这个检查的设置。本地 Git 评审还可能运行 git ls-remote，查询默认分支和基线是否过时；它不上传本地 diff，也不靠定时器轮询。
如果要关闭 Git 远程检查，可以使用 plannotator review --no-git-remote-check、设置 PLANNOTATOR_GIT_REMOTE_CHECK=0，或者在 ~/.plannotator/config.json 中配置 { "gitRemoteCheck": false }。
真正涉及内容外发的入口包括：抓取 URL、获取 GitHub PR 或 GitLab MR、向配置的模型供应商发送 AI 问题及相关上下文，以及分享内容。URL 批注默认通过 Jina Reader 抓取公开页面；「Ask this session」则把问题交给打开 Plannotator 的原 agent 会话。
分享也有两套机制。小型 Markdown 压缩后放进 URL fragment，浏览器请求不会携带 fragment，但内容没有加密，拿到完整链接的人或消息服务都能读取。大型 Markdown 和原始 HTML 使用短链，上传前通过 AES-256-GCM 加密，密钥放在 fragment 中；持有完整链接的人仍然可以解密，托管内容在 7 天后过期。需要彻底禁用分享时，可设置 PLANNOTATOR_SHARE=disabled。
完整分享链接本身就携带了读取内容的能力。
另外，开源异步链接分享正在转向弃用支持，尚未公布移除日期；团队共享的主要方向是独立托管产品 Workspaces。放进 Workspaces 的内容，不适用开源应用的本地存储模型。
远程开发还有一处直接影响部署方式的限制。SSH 会话默认使用端口 19432；容器或自定义端口可以这样设置：
export PLANNOTATOR_REMOTE=1
export PLANNOTATOR_PORT=9999 # 转发这个端口
需要关注的是第一行：原文明确说明，远程模式监听 0.0.0.0，且没有登录认证。即使用 SSH 隧道，也必须保证该端口不会被不可信网络直接访问。
我的判断
Plannotator 选中了一个实际存在的问题：当 agent 产出越来越多，人的注意力和反馈组织方式可能先跟不上。把意见附着在计划、页面和代码行上，再送回正确会话，比复制整段聊天记录更容易保留修改目标。
但原文没有证明它能让团队更快交付，也没有给出与聊天反馈、IDE 批注或 GitHub、GitLab 原生评审的对照数据。现有材料能支持「它提供了这些审阅机制」，还不足以支持「它显著提高了研发效率」。
取舍取决于协作结构。单人只开一个 agent、改动也很小时，聊天加 git diff 可能已经够用。多个 agent 并行产出计划、页面和代码时，统一收件箱更有吸引力。团队已经围绕 PR 建立责任归属、审批和 CI 流程时，则应该先验证 Plannotator 的反馈如何进入现有记录，避免多出一处需要维护的审阅入口。
安装也建议按需求选范围。默认安装器会识别 agent，并配置 hooks、skills 和命令；--minimal 或 PLANNOTATOR_MINIMAL=1 只安装二进制到 ~/.local/bin，更适合先摸清工具边界。
供应链方面，原文说明从 v0.17.2 起提供 SLSA 来源证明，也描述了 CycloneDX JSON SBOM 和 Grype 发布检查。不过，SBOM 是整个发布所用构建输入与依赖的清单，不是每个二进制精确的运行时依赖清单；文中还保留了首个启用 SBOM 的发布前需要同步文档的说明，不能据此断言某个具体版本已经包含全部证据。安装参数 --verify-attestation 是可选项，验证的是 SLSA 构建来源，需要 gh CLI。
能拿来做什么
- 如果经常让 agent 生成 HTML 页面原型，可以先用
/plannotator-annotate report.html --render-html审阅一次，把布局和内容问题直接标在页面上，再观察反馈是否足够准确。 - 如果日常主要依赖 AI 改代码，可以先从
/plannotator-review检查未提交改动开始，在提交前把按行意见交回 agent 修正；Codex 中使用对应的!plannotator review调用方式。 - 如果同时运行多个 agent，可以用
plannotator inbox集中处理待回答的问题，重点验证回复能否回到正确会话，以及 agent 后续是否保留了必要上下文。 - 如果在 SSH、Docker 或 devcontainer 中使用，先确认端口转发和访问范围，再开启远程模式；处理内部代码时，同时检查 Ask AI、URL 抓取和分享功能各自的数据去向。