别再盯着你的智能体干活了
我能想到的最没效率的事，就是盯着 Agent 干活。但我还是会忍不住看。看它调用工具，看文件被改来改去，等着看它到底有没有理解我的意思。感觉像是在监督，但这其实是一种很奇怪的委派方式。我们不会花一下午盯着同事敲键盘，确认他有没有在解对的问题。跟同事合作，我们只需要对目标达成一致，然后看结果。我希望跟编程 Agent 也能这样：开始之前聊一次，回来之后再聊一次。中间最好别管它。但问题是，读一大篇计划和总结很费神。看着看着脑子就糊了，关键决策反而被淹没。我想要的是扫一眼就能看懂的东西。给我看接入步骤，给我看 API 契约，出了问题的时候给我一个可以指着说「这里不对」的地方。
这正是我们在探索的问题，为此做了 Agent-Native Plans——一个免费、开源的工具，用来审查 Agent 打算构建什么、实际又构建了什么。想看演示？这里是 Plans 的实际操作演示：
Agent-Native Plans 是什么？
Agent-Native Plans 让编程 Agent 能够生成可视化文档，用于规划和审查。主要靠两个技能完成工作。
Visual Plan 解释一个提议的改动。根据具体工作内容，可能包括线框图、API 流程图、带注释的代码、待解决的问题，或者实现步骤顺序。
Visual Recap 解释一个已完成的改动，把代码和它带来的行为变化联系起来。你还可以把它接入 CI，让 recap 自动出现在 pull request 上。
这些文档可以分享，也可以对具体部分评论。你、你的队友和 Agent 在面对「接下来该怎么做」的时候，看到的是同一份东西。
下面看一个 UI 改动的提议，再看 Agent-Native 仓库里两个已完成的 pull request。
实现之前：先看看 Agent 以为你要的是什么
假设要对 Clips（我们的录音应用）做个小改动：把录音侧边栏从播放器右侧移到左侧，并且让它可折叠。
这听起来是个很明确的请求。Agent 完全可以马上开始挪组件、加个开关。
不过，它仍然得做一些选择：侧边栏收起后，什么还留在屏幕上？重新打开它的控件放在哪？面板要不要记住你之前看的内容？屏幕变小时又该怎么表现？这些问题我可能都有自己的想法，只是第一条消息里没想起来要说明。我漏掉的部分，智能体就得自己补上。装上视觉规划技能后，Codex 可以在动手写代码之前，把这些选择先摆出来给我看。
Clips 侧边栏的方案展示了当前布局、建议的展开与收起布局、移动端状态，还有一个可交互的原型。里面还写了行为要求和一份测试清单。现在我可以对比不同布局，看清收起控件到底放在哪。我不再是笼统地同意「让它能收起」，而是针对某个具体位置上的某个具体控件表示同意或反对。
文字部分依然重要。比如，线框图不会告诉我面板是否记住自己的状态。但我可以一边看着它描述的面板，一边读那条要求。
这正是我想从跟智能体的第一轮对话中得到的东西：在它花时间和 token 去实现之前，我们先把需要我拍板的决定理清楚。
指出你想改的地方
在方案上直接评论，比试图向智能体描述一个屏幕要自然得多。我可以高亮一段文字，或者把评论钉在线框图的某个位置。「能不能换个版本试试？」——这句话会精确对应到我想改的文字或控件。在 Clips 的方案里，评论就放在建议的重新打开控件旁边。智能体拿到的是一个具体的设计决定，不用猜我说的是哪个开关。
我可以把这条反馈发回给智能体，让它修改方案。设计师或产品经理也能审阅同一份文档，在上下文中留下反馈，不需要去翻原始编码对话，也不用在本地把应用跑起来。侧边栏在这里还只是一个提案。与其等智能体把它做出来再要求换一种方式，不如现在就把这个控件的问题解决掉。
实现之后：看懂回来的东西
第二轮对话，发生在智能体带着代码回来的时候。
再看一个已经完成的改动：PR #3774「Add selection-triggered reference tagging for design generation」。光看标题，我大致知道改了什么，但还想搞清楚它在编辑器里意味着什么。用户选中一个图层时会怎样？新的上下文去了哪里？代码里我该看哪些地方？
可视化回顾展示了改动前后的编辑器交互，包括新增的「添加到上下文」（Add to Context）操作。它还说明了选中项变化时，编辑器怎么跟踪被选中的元素。代码 diff 是按文件和改动行来组织的，这种做法在我知道该看哪之后很好用。回顾则给了我一条更快的评审入口：先看交互，再借助概览和带注释的代码，去提具体问题。选中的上下文，和作者想引用的东西一致吗？选中项变化时又会怎样？这样我就知道该在代码和运行中的应用里检查什么了。
智能体跑完一个长任务回来时，我想看到的正是这样一份说明：改了什么、它应该表现成什么样、我该把评审的精力放在哪。
截图看不出来的改动，同样适用
同样的方法也帮我说明了自己那个 PR——通过 MCP 暴露 Content 评论操作。它改变了工具创建和更新评论的方式，包括由谁决定评论的作者。工具不再从调用方接收作者信息，而是从已认证的用户那里获取。回复还必须属于正确的文档和讨论串。回顾用一张图和带注释的代码，展示这些校验怎么拼在一起。于是我就有了具体的检查点：调用方还能用新的输入来操作这个工具吗？它能正确识别作者、校验回复吗？一张有用的可视化图，既能解释界面，也能解释系统。API 边界，或者一串操作步骤，都能给我们具体的讨论对象，哪怕应用之后看起来毫无变化。
少花点时间盯着
有了计划（Plans），我就不用一直盯着，可以放手让智能体干活。它在开始之前，我们先就做法达成一致。等它做完回来，我可以把它做出来的东西和我们当初约定的一致之处对照一下。这样我就能更快进入真正有用的评审。
我依然会读代码、跑测试，确保它按计划实现。但我希望少花时间盯着 agent 干活，多花时间做那些只有我能拍板的决策。
下次你要改点什么的时候，不妨试试：搭一套 Agent-Native Plans。让 agent 给你一份可视化计划，指出你想改的地方，然后放手让它去做。免费且开源。
完整文章见 Builder.io 博客。