让智能体走出聊天窗口

Pi Companion 是我给自己做的一个 Pi 桌面 GUI。

在使用智能体处理真实任务时，我想验证两个关于交互体验的想法：

1. 智能体任务能不能从工作发生的位置直接开始，而不是先打开一个聊天窗口？
2. 当智能体需要工作几分钟甚至更久时，我能不能继续做别的事，只在它真正需要我时介入？

为了验证这两个想法，我在 Pi Companion 里加入了两个功能：快捷任务入口和任务监视器。智能体对话仍然负责完整过程与连续交流，而这两个更轻的界面分别承担任务的开始、运行中的监督与必要介入。

在工作发生的地方启动智能体，让它在后台工作，只在需要你时出现。

为什么聊天窗口不该承担所有事情

聊天很适合澄清需求、连续讨论和查看详细过程。但当智能体从“回答问题”变成“执行任务”，交互条件也随之改变。

一个真实的编程任务可能会持续几分钟甚至更久。智能体需要读取文件、搜索代码、修改内容、执行命令、等待测试，然后在某个时刻请求权限或提出问题。在这段时间里，我往往还要浏览文档、查看其他代码，或者继续处理另一件事。

如果聊天窗口是唯一界面，我就需要：

• 一直保留一个占据大量空间的窗口；
• 不时切回去确认智能体是否还在工作；
• 在不断增长的工具调用中寻找真正需要处理的内容；
• 担心错过权限请求、问题或失败状态。

这并不是聊天界面本身有什么问题，而是启动任务、监督运行和深入检查，对界面与注意力的要求并不相同。把它们全部放进一个聊天窗口，意味着我必须用最重的界面完成最轻的确认。

快捷任务入口与任务监视器，就是对这层关系的重新拆分。

快捷任务入口：从工作上下文开始

在桌面上，一项任务通常不是从一句孤立的话开始的。它往往已经有明确的位置：一个目录、一个仓库，或者几份刚刚选中的文件。

所以 Pi Companion 的快捷任务入口不在智能体对话首页，而在 Windows 资源管理器。

我可以对当前目录、单个文件或一组选中文件点击 “询问 Pi Companion”。快捷任务入口会出现在鼠标附近，并自动带入工作目录和附件。我只需要描述任务、选择模型和权限，然后点击“开始任务”。

这个入口看似只是少打开一个窗口，但它改变了任务的起点：

• 不必先创建项目或导入仓库；
• 当前目录直接成为智能体的工作上下文和默认边界；
• 已经选中的文件直接成为任务附件；
• 提交完成后，入口立即离开，不再占据屏幕。

它更像系统中的“分享”或“打开方式”，而不是另一个必须先进入的应用。任务从工作现场开始，Pi Companion 只负责接住当前上下文。

任务监视器：保持可见，但不持续打扰

任务提交以后，我最关心的不再是智能体刚刚说了什么，而是三个更简单的问题：

• 它现在处于什么状态？
• 它是否需要我？
• 如果完成了，结果是什么？

Pi Companion 用一个常驻桌面的任务监视器回答这些问题。

收起时，它只保留任务标题和当前状态；展开后，它显示精简的活动、待处理交互和最终结果。它不会把每一条底层事件都变成需要阅读的新消息，也不会因为普通状态更新抢走当前窗口的焦点。

我为任务监视器设定了三条原则。

状态变化不等于打断

智能体读取文件、搜索代码或运行工具时，任务监视器可以更新文字、颜色和动画，但不能主动激活窗口。

它应该像下载进度或系统状态一样安静地存在：我想确认时随时可以看见，不想关注时也可以继续手上的工作。可见性应该让人安心，而不是制造一条新的通知流。

需要人时，交互取代进度

当智能体请求权限或提出问题时，最重要的信息不再是“它刚刚做过什么”，而是“它现在需要我做什么”。

因此，任务监视器会用待处理交互取代普通活动。我可以直接允许一次操作、拒绝请求、回答问题，或者立即调整智能体的方向，不必先找到对应的聊天窗口，再从完整记录中定位阻塞点。

任务监视器不是聊天记录的缩小版，而是任务当前状态和高频人工介入的入口。

完成意味着可以快速离开

任务结束后，任务监视器显示简洁的结果摘要、文件变更、测试状态和警告。

这些信息不负责复述完整过程，只需要帮助我快速做出下一步判断：结果已经足够，可以结束；还需要继续一轮；或者值得打开智能体对话检查具体修改。

智能体对话负责深入查看

加入快捷任务入口和任务监视器，并不意味着聊天不重要。智能体对话仍然适合：

• 查看完整消息和推理过程；
• 审查工具调用、命令、文件差异和测试证据；
• 搜索历史任务；
• 进行需要完整上下文的连续交流；
• 在任务完成后继续下一轮工作。

区别在于，我不再需要为了知道“任务是否还在运行”而打开它。

三个界面由此形成了明确的层级：

快捷任务入口负责开始，任务监视器负责陪伴和介入，智能体对话负责深入检查。

快捷任务入口是短暂的，任务监视器是环境式的，智能体对话是按需打开的。三者共享同一套任务、运行与事件状态，但承担不同的信息密度与注意力成本。

在自用的 Pi 桌面 GUI 里验证想法

Pi 的吸引力之一，是简单和可定制。不同的人可以通过扩展、技能和提示，把它变成完全不同的智能体。

Pi Companion 本来就是我自己的 Pi 桌面 GUI，因此也带有明确的个人偏好：Windows、资源管理器入口、常驻桌面的轻量窗口，以及我自己的任务处理方式。它首先需要解决我的问题，而不是覆盖所有 Pi 用户的工作流。

也正因为它是我真正使用的 GUI，我才能把两个产品假设放进真实任务里验证：

• 从工作上下文直接启动任务，是否真的比先进入聊天窗口自然？
• 一个不抢焦点、只在必要时要求介入的任务监视器，是否真的能降低长任务的注意力成本？

为了实现这两个功能，我选择 Windows 资源管理器作为任务入口，选择桌面悬浮窗口作为任务监视器，并继续使用 Pi RPC 作为智能体后端。这些是 Pi Companion 的具体方案，不代表其他实现必须作出相同选择。

这个项目也没有试图重新实现 Pi 的所有可定制能力。完整聊天、模型设置、技能与扩展仍然有各自的位置；快捷任务入口和任务监视器只负责它们最擅长的部分。

从界面问题走向状态问题

真正实现这套体验后，我发现最关键的工作并不是画两个悬浮窗口，而是确保三个界面看到的是同一个任务。

一次运行可能处于排队、启动、执行、等待授权、等待回答、完成、失败或中止等状态。权限请求既可能在任务监视器中处理，也可能在智能体对话中处理；无论从哪里响应，另一个界面都必须立即得到一致结果。应用或智能体进程退出以后，历史与上下文也需要恢复。

因此，Pi Companion 没有让各个界面分别维护自己的任务状态。快捷任务入口只负责创建任务；任务监视器和智能体对话读取同一套任务投影；所有操作通过统一的应用命令进入运行链路。

这使“任务监视器不抢焦点”不只是一个视觉细节，而成为明确的产品边界：状态可以持续更新，但只有新的权限请求或问题值得主动提升交互优先级。即使如此，它也只改变任务监视器的内容，不夺走用户正在使用的窗口。

界面越轻，背后的状态定义反而越需要严谨。只有状态可靠，用户才敢把注意力从聊天窗口移开。

当前实现

Pi Companion 目前已经实现：

• 从 Windows 11 资源管理器的当前目录或选中文件启动任务；
• 自动带入工作目录与附件的快捷任务入口；
• 支持多个任务状态与任务切换的桌面任务监视器；
• 在任务监视器中处理权限、智能体提问和方向调整；
• 任务完成摘要、文件变更和测试状态；
• 用于查看完整过程和继续交流的智能体对话；
• 本地任务与事件存储、会话恢复和 Pi RPC 运行链路。

项目以 MIT License 开源，目前仍处于早期开发阶段。它面向 Windows 11，需要从源码构建，并自行配置 Pi Runtime 与模型服务。

Pi Companion 不是一套关于智能体界面的最终答案。对我而言，它首先是一个可以每天使用的 Pi 桌面 GUI；快捷任务入口和任务监视器，则是其中两个仍在被真实任务检验的答案。

如果你也在思考智能体是否一定要以聊天窗口为中心，可以在 GitHub 查看完整代码和产品文档。