本地 Codex/Claude Code 审核回路的搭建经验

我最近频繁使用 Codex 和 Claude Code，却始终遇到同一个有些荒谬的问题。

我会给 Agent 一个任务，让它开始工作，然后离开工位——几分钟后回来只是想看看发生了什么。大多数时候，我回来并不是要发送下一个 prompt，纯粹只是想查看一下 diff、打开某个文件、确认应用是否还能正常运行，或者看看 Agent 是否在等待我的回复。

经历过足够多次之后，我意识到聊天界面并不是我真正缺失的那部分。我真正想要的是 Agent 工作的同时，项目的其他部分依然触手可及。

聊天不是任务的全部

一次编码 Agent 会话只是整个工作中的一部分。

有对话本身，也有磁盘上的代码仓库、当前的 Git 状态、文件本身，还有通常在后台运行的开发服务器。

对话记录很有用，因为它告诉了我 Agent 尝试做了什么。但当我需要判断结果是否真的好用时，最终还是会去看项目本身。

正确的文件改动了吗？代码逻辑合理吗？应用还能启动吗？界面看起来对不对？

我也认为工具不应该假装自己知道得比实际更多。如果工作树中包含某个改动，并不自动意味着它是由某个特定的 Agent 创建的。也可能是我自己编辑了这个文件，另一个进程修改了它，或者这个改动之前就已经存在了。

所以我不再执着于重建某种完美的"Agent 状态"，而是更感兴趣把真实的项目状态放到 Agent 会话旁边。

我最终形成的思维模型是：

观察 → 回顾 → 引导

看清 Agent 在做什么，检查实际的结果，然后决定接下来该怎么做。

对于我自己的工作流，通常演变成：

对话 → 改动 → 文件 → 预览 → 下一个 prompt

缺失的那一环，是能够不用守在终端前就完成上述流程。

这个尝试最终变成了 DeskCue。

这是一个开源的、本地优先的工具，与我机器上已有的编码工具协同运行。它不是要取代 Codex 或 Claude Code，而是让我在一个地方看到围绕它们的任务状态。

目前它支持的功能包括：

现有的 Codex 和 Claude Code 会话

运行中的应用预览

后续 prompt 和停止控制

有事需要关注时的通知

它同时支持 Ollama、LM Studio 和通用的 CLI 会话。

支持多种工具并不是最初的主要目标。我主要是想让周围的workflow在切换 Agent 或使用本地模型时依然保持可用。

重要的一点是，Agent 仍然运行在我的电脑上，针对真实项目工作。DeskCue 只是给我另一个 surface，用于从笔记本电脑、另一台电脑或手机上回顾和引导那些工作。

快速概览当前流程：会话 → 改动 → 文件 → 预览。

这部分实际上是相对容易做的决定之一。

仓库已经在我的机器上了。开发服务器已经在运行了。编码 Agent 已经具备了所需的环境。

为了远程检查而把项目上传到其他地方，感觉就像是为了同样的状态又增加了一份副本，毫无必要。

我宁愿保持一个真实的开发环境，只暴露我关心的那部分。

这意味着我打开的文件就是工作区里真实的文件。Git diff 就是真实的工作树。预览就是作为开发流程一部分已经在运行的应用。

当然，本地优先也带来了自己的问题。远程访问需要认证。设备凭证需要可撤销。通知必须能够触达我，但又不能把整个东西变成一个托管的 IDE。不同的 Agent 工具暴露会话的方式各不相同。

那些看似简单的 UI 背后有大量枯燥的底层工作。

但比起让第二个开发环境慢慢偏离第一个，我更愿意接受这些。

手机使用场景与我预期的不同

起初我把 DeskCue 主要当作在手机上使用编码 Agent 的一种方式。

我现在不再这样描述它了。

我不想用手机取代工作站，更不想花一整天在小小的键盘上写长篇编码 prompt。

有用的场景要简单得多。

我在电脑上启动一个任务，让 Agent 开始工作。稍后我想知道它是否完成了，以及结果是否值得保留。

有时候这意味着查看 diff。有时候我只需要打开一个文件。对于前端工作，我通常只是想看看应用。

如果 Agent 卡在某个决策上，我可以回答它。如果一切看起来都好，我可以发送下一个 prompt，然后继续其他事情。

手机不是我做开发的地方。它只是一个方便的场所，让我在离开电脑时能关注任务状态。

通知让这一切变得更有用。我宁愿在真正需要我注意时收到一条通知，而不是一直打开终端去看 Agent 是否完成了。

从这个项目中我学到了什么

有一件事我越来越清楚：围绕编码 Agent 的工具是多么容易变成另一个 IDE。

你加一个会话视图，然后你觉得它需要一个终端。然后是编辑器。然后是 Git 控制。然后是模型选择、编排、部署……

最终你在做一个平台，而不是解决最初的那个烦恼。

我试着让 DeskCue保持在那条线的另一边。我不想让它成为 Agent、编辑器或模型宿主。我希望它专注于回顾和引导正在发生的工作。

其他几件事也在这个过程中变得更加清晰了。

我依然更信任工作区而不是对话记录

对话记录是有用的上下文，但我最终要提交的那些代码在代码仓库里。

当两者不一致时，我关心的是磁盘上的实际内容。

Diff 告诉我改了什么，而不是为什么改

这完全没有问题。

我不需要 UI 去编造归属关系。展示真实的工作树就已经足够有用了。

预览是我使用最频繁的屏幕之一

这有点出乎我的意料。

尤其是对于前端工作，我经常不在乎又一份关于改动了什么的详细解释。我只想打开应用看看。

页面还能工作吗？间距奇怪吗？Agent 是否误解了布局？

在真实应用里花几秒钟往往比读对话记录更快得到答案。

只支持多种 Agent 是不够的

DeskCue 可以配合 Codex、Claude Code、本地模型和通用 CLI 会话工作，但我不认为"一个 UI 适配多种 Agent"是一个特别强的使用理由。

我觉得有用的部分是在它们周围有相同的回顾循环。

我可能会切换做工作的工具，但我依然想检查项目、查看应用，然后决定接下来怎么做。

目前我主要在 Windows 和 Ubuntu 上测试过。macOS 还需要更多验证，而且目前是从源码安装，而不是通过打包的安装程序。

它采用 Apache-2.0 开源协议：

github.com/AleksandrKornev/DeskCue

还有很多我想改进的地方，特别是在 Agent 需要人类输入、而你希望回到正确上下文的那个节点上。

但基本的循环从我开始到现在基本没变：

Agent 工作 → 回顾项目 → 决定下一步

我很想知道其他人是怎么处理这件事的。

当你让一个编码 Agent 处理任务时，在决定下一步做什么之前，你实际想看到的是什么？