Stop watching your agent work别再盯着你的代理工作了
Agent-Native
Alice Moore· September 24, 2026
6 min read
The least productive thing I can imagine doing is watching an agent work.我能想象到的最没效率的事，就是盯着一个代理（Agent）工作。
I still catch myself doing it. Reading the tool calls, watching files change, waiting to see whether it understood what I meant. It feels like oversight, but it’s a strange way to delegate. We don’t spend the afternoon watching a coworker type to make sure they’re solving the right problem.我有时还是会忍不住这样做。看着它调用工具、看着文件变动、等着看它是否理解了我的意图。这感觉像是监督，但作为一种委派方式，这很奇怪。我们不会花一下午时间盯着同事打字，以确保他们正在解决正确的问题。
With coworkers, we agree on what we’re trying to accomplish and review the result. I want the same thing with a coding agent: a conversation before it starts, and another when it comes back. Ideally, I can leave it alone in between.在与同事协作时，我们会就目标达成一致，然后审查结果。我希望对编码代理也有同样的要求：在开始前进行沟通，完成后再进行交流。理想情况下，在这期间我可以不去管它。
But reading pages of plans and summaries takes attention. My eyes glaze over, and the important decisions get buried. I want something I can understand at a glance.但阅读长篇大论的计划和总结很费精力。我看得眼花缭乱，重要的决策反而被淹没了。我需要一种能让我一目了然的东西。
Show me the onboarding steps. Show me the API contract. Give me somewhere to point when something is wrong.给我展示入职步骤，给我看 API 合约。当出现问题时，让我有据可依。
That’s the problem we’re exploring with Agent-Native Plans, a free, open-source tool for reviewing what an agent plans to build and what it built.这正是我们通过 Agent-Native Plans 所探索的问题，它是一个免费的开源工具，用于审查代理计划构建的内容及其已构建的内容。
Prefer a walkthrough? Here’s a demo of Plans in action:想看演示吗？这是 Plans 运行的演示：
What is Agent-Native Plans?什么是 Agent-Native Plans？
Agent-Native Plans gives a coding agent a way to produce visual documents for planning and review. Two skills do most of the work.Agent-Native Plans 为编码代理提供了一种生成可视化文档以进行规划和审查的方法。两项技能完成了大部分工作。
- Visual Plan explains a proposed change. Depending on the work, that might include wireframes, a diagram of an API flow, annotated code, open questions, or an implementation sequence.“可视化计划”（Visual Plan）用于解释拟议的变更。根据工作内容，这可能包括线框图、API 流程图、带注释的代码、待解决问题或实施顺序。
- Visual Recap explains a completed change, connecting the code to the behavior it changes. You can also connect it to CI so recaps appear automatically on pull requests.“可视化回顾”（Visual Recap）用于解释已完成的变更，将代码与其所改变的行为联系起来。你还可以将其连接到 CI，这样回顾就会自动出现在拉取请求（Pull Request）中。
You can share these documents and comment on specific parts of them. You, your teammates, and the agent have the same thing in front of you when talking about what should happen next.你可以分享这些文档并对其中的特定部分进行评论。当你和队友以及代理讨论下一步该做什么时，大家面对的是相同的内容。
Let’s look at a proposed UI change, then two completed pull requests from the Agent-Native repository.让我们看看一个拟议的 UI 变更，以及来自 Agent-Native 存储库的两个已完成的拉取请求。
Before implementation: inspect what the agent thinks you mean实施前：检查代理对你意图的理解
Consider a small change to Clips, our recording app: move the recording sidebar from the right side of the player to the left, and make it collapsible.考虑对我们的录制应用 Clips 进行一个小改动：将录制侧边栏从播放器的右侧移到左侧，并使其可折叠。
That sounds like a clear request. An agent could start moving components and adding a toggle right away. But it still has to make a few choices:这听起来是个明确的需求。代理可能会立即开始移动组件并添加一个切换开关。但它仍然需要做出一些选择：
- When the sidebar collapses, what stays visible?当侧边栏折叠时，什么内容保持可见？
- Where does the control for reopening it go?重新打开它的控件放在哪里？
- Should the panel remember what you were looking at?面板是否应该记住你之前查看的内容？
- What happens on a smaller screen?在较小的屏幕上会发生什么？
I might have opinions about all of those without thinking to specify them in my first message. The agent will need to fill in whatever I leave out.我可能对所有这些都有自己的想法，却没在第一条消息中明确说明。代理需要填补我遗漏的任何内容。
With the visual-plan skill installed, Codex can make those choices visible before writing the implementation. The Clips sidebar plan shows the current layout, the proposed expanded and collapsed layouts, a mobile state, and an interactive prototype. It also includes behavior requirements and a checklist for testing the change.安装了可视化计划技能后，Codex 可以在编写代码之前将这些选择可视化。Clips 侧边栏计划展示了当前的布局、拟议的展开和折叠布局、移动端状态以及交互式原型。它还包括行为要求和测试变更的清单。
Now I can compare the layouts and see where the collapse control goes. Instead of agreeing to “make it collapsible,” I’m agreeing—or objecting—to a particular control in a particular place.现在我可以对比布局，看看折叠控件放在哪里。我不再是仅仅同意“使其可折叠”，而是同意或反对特定位置的特定控件。
The text still matters. A wireframe won’t tell me whether the panel remembers its state, for example. But I can read that requirement while looking at the panel it describes.文字依然很重要。例如，线框图不会告诉我面板是否记住了它的状态。但我可以在查看面板的同时阅读该要求。
This is what I want from the first conversation with an agent. We work through the decisions that need me before it spends time and tokens implementing them.这就是我希望从与代理的第一次对话中获得的结果。在它花费时间和 Token 进行实施之前，我们先处理好需要我参与的决策。
Point to what you want changed指出你想要更改的地方
Commenting on a plan feels much more natural than trying to describe a screen back to an agent. I can highlight a passage or pin a comment to a spot in a wireframe. “Can we try another version of this?” comes with the exact text or control I mean.对计划进行评论比试图向代理描述屏幕内容要自然得多。我可以高亮一段文字或将评论固定在线框图的某个位置。“我们可以试试这个的另一个版本吗？”——这句话直接指向我所指的具体文本或控件。
In the Clips plan, the comment sits beside the proposed reopen control. The agent gets a specific design decision to revisit, without having to guess which toggle I’m talking about. I can send that feedback back to the agent and ask it to revise the plan.在 Clips 计划中，评论位于拟议的重新打开控件旁边。代理无需猜测我指的是哪个开关，就能得到一个需要重新审视的具体设计决策。我可以将该反馈发回给代理，并要求它修改计划。
A designer or PM can review the same document and leave feedback in context, without reading the original coding conversation or setting up the app locally.设计师或产品经理可以审查同一文档并在上下文中留下反馈，而无需阅读原始的编码对话或在本地设置应用程序。
The sidebar is still a proposal here. I’d rather sort out the control now than ask for a different one after the agent has built it.侧边栏在这里仍然是一个提案。我宁愿现在就确定好控件，也不想在代理构建完成后再要求更改。
After implementation: understand what came back实施后：了解返回的结果
The second conversation happens when the agent comes back with code. Take a separate, completed change: PR #3774, “Add selection-triggered reference tagging for design generation.”第二次对话发生在代理带着代码回来时。以一个已完成的独立变更为例：PR #3774，“为设计生成添加选择触发的引用标记”。
That title tells me roughly what changed, but I still want to know what it means in the editor. What happens when someone selects a layer? Where does the new context go? What should I look for in the code?标题大致告诉我发生了什么变化，但我仍然想知道它在编辑器中意味着什么。当有人选择图层时会发生什么？新的上下文去了哪里？我在代码中应该寻找什么？
The visual recap shows the editor interaction before and after, including the new Add to Context action. It also explains how the editor tracks the selected element as that selection changes.可视化回顾展示了编辑器交互的前后对比，包括新的“添加到上下文”操作。它还解释了编辑器如何随着选择的变化来跟踪所选元素。
A diff is organized around files and changed lines. That’s useful once I know where to look. The recap gives me a faster way into the review: I can see the interaction first, then use the overview and annotated code to ask specific questions. Does the selected context match what the person meant to reference? What happens when the selection changes?差异对比（Diff）是围绕文件和变更行组织的。一旦我知道去哪里看，这很有用。回顾为我提供了一种更快的审查切入点：我可以先看到交互，然后利用概述和带注释的代码提出具体问题。所选上下文是否与用户想要引用的内容匹配？选择更改时会发生什么？
Now I know what to check in the code and the running app. When an agent comes back from a long task, this is the explanation I want: what changed, how it should behave, and where I should focus my review.现在我知道要在代码和运行中的应用程序中检查什么了。当代理完成一项长期任务回来时，这就是我想要的解释：发生了什么变化、它应该如何表现，以及我应该重点审查哪里。
This also applies to changes you can’t screenshot这也适用于无法截图的变更
The same approach helped explain my PR exposing Content comment actions through MCP. It changes how tools create and update comments, including who gets to decide a comment’s author.同样的方法有助于解释我通过 MCP 公开内容评论操作的 PR。它改变了工具创建和更新评论的方式，包括谁有权决定评论的作者。
The tool no longer accepts author information from its caller. It gets that information from the authenticated user instead. Replies also need to belong to the right document and thread.该工具不再接受来自调用者的作者信息。它转而从经过身份验证的用户那里获取该信息。回复也需要归属于正确的文档和线程。
The recap uses a diagram and annotated code to show how those checks fit together.回顾使用图表和带注释的代码来展示这些检查是如何结合在一起的。
That gives me specific things to check: can callers still use the tool with its new inputs? Does it correctly identify the author and validate replies?这给了我需要检查的具体事项：调用者还能使用带有新输入的工具吗？它是否能正确识别作者并验证回复？
A useful visual can explain a system as well as a screen. An API boundary or a sequence of operations gives us something concrete to talk about, even when the app looks the same afterward.一个有用的可视化内容可以像解释屏幕界面一样解释系统。即使应用程序在操作后看起来一样，API 边界或操作序列也能为我们提供具体的话题。
Spend less time watching减少盯着看的时间
Plans helps me stop watching and let the agent work. We agree on the approach before it starts. When it comes back, I can compare what it built with what we agreed on.Plans 帮助我不再盯着看，让代理去工作。我们在开始前就方法达成一致。当它完成后，我可以将它构建的内容与我们商定的内容进行比较。
That gets me to a useful review faster. I still read and test the code to make sure it does what the plan says.这让我能更快地进行有效的审查。我仍然会阅读和测试代码，以确保它符合计划所述。
I want to spend less time watching an agent work and more time making the decisions it needs from me.我希望减少盯着代理工作的时间，将更多时间花在做出它需要我做的决策上。
Try it on the next change you’re about to make: set up Agent-Native Plans. Ask your agent for a visual plan, point out what you want changed, and then let it work. It’s free and open source.在你下一次进行变更时尝试一下：设置 Agent-Native Plans。让你的代理提供一份可视化计划，指出你想要更改的地方，然后让它工作。它是免费且开源的。
Continue reading继续阅读
What is Jev and how to use it什么是 Jev 以及如何使用它
