让智能体走出聊天窗口

智能体常被用来写代码、应付比较大的工程任务，但它的能力其实更宽：在一个真实环境里读写文件、执行命令、调用工具，直到把事情做完。这些能力并不挑任务大小——一件几分钟就能说完的琐事，用的也是同一套东西。

Pi Companion 是我基于命令行智能体工具 Pi 给自己做的一个桌面 GUI，主要用来处理这类琐事，也就是日常杂活。比较典型的几种：把一张 spritesheet 切成单个帧、从一张原图导出几个不同尺寸的版本、给一批图片反色、按规则重命名下载目录里的文件。它们的共同点是我清楚自己要什么，只是不值得为它专门学一个 CLI 工具、或者装一个插件；而这类任务的输入往往就是几个文件，意图一句话能说清，结果也能一眼看出对不对。

这类任务通常很短，可一旦要等我把它描述清楚、再看着它做完，往往比自己动手还麻烦。

一件杂活有两个成本：开始它，和看着它。打开对话窗口、把上下文交代清楚，是启动成本；任务跑起来之后还得不时切回去确认，是看守成本。这两个成本主要由界面决定，而聊天窗口把两者同时抬高了。

所以在把杂活交给智能体的过程中，我想验证两个关于交互体验的想法：

1. 智能体任务能否直接从工作发生的位置开始？
2. 当智能体需要工作一段时间时，我能不能继续做别的事，只在它真正需要我时介入？

为了验证这两个想法，我在 Pi Companion 里加入了两个功能：快捷任务入口和任务监视器，分别针对这两个成本。智能体对话仍然负责完整过程与连续交流。

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

入口：降低启动成本

聊天很适合澄清需求、连续讨论和查看详细过程。但当任务从“需要我参与的工作”变成“我只想让它做完的杂活”，界面的要求就变了——意图一句话交代清楚之后，就没什么可讨论的。

可如果每次都从聊天窗口启动，我就需要：

• 为一件一分钟的事打开并保留一个占据大量空间的窗口；
• 手动交代“在哪个目录、涉及哪些文件”；
• 等上下文描述清楚才开始，而描述本身有时比杂活还长。

如果开始一件杂活的成本接近做它本身，我就不会用它。 聊天窗口的问题不是不能做杂活，而是启动得太重。

快捷任务入口：从工作现场开始

在桌面上，我的杂活通常由明确的工作现场触发：一个目录，或者几份刚刚选中的文件。

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

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

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

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

它更接近系统中的“分享”或“打开方式”。任务从工作现场开始，Pi Companion 负责接住当前上下文。

右键菜单之所以合适，是因为它本来就是杂活工具的聚集地：批量改名、压缩、格式转换、复制路径……每多一种杂活，就多一个要安装的插件。快捷任务入口占的正是这个位置，却只留一个入口——不再需要为每种杂活预先安装工具，只要智能体能根据任务现场生成脚本，或者从已有的技能里挑一个合适的。右键菜单因此从“已安装工具的清单”变成了“表达意图的地方”。

这不意味着专用工具会被全部取代。固定规则的批量改名或压缩这类高频、确定的操作，装好的插件仍然更快也更可预期。智能体接住的是长尾：那些一年做两三次、不值得为它装插件，却又确实麻烦的杂活——比如把一张 spritesheet 切成单个帧。

这个入口覆盖的是从文件开始的杂活。剪贴板里的内容、或者让它起几个名字这类没有文件现场的事，仍然要从对话框开始。

结果：入口改变的是任务的粒度

从工作现场启动确实让开始杂活更自然了。但真正有用的不是省了几步，而是启动阈值降低了：不用交代“在哪个目录、哪些文件”，我会更愿意把小事直接丢给智能体——任务的粒度反而变小了。

入口应该挂在用户已有的工作表面上，而不是要求用户先来到智能体的界面。 在 Windows 上，处理文件杂活的人本来就在资源管理器里——与其让人带着文件去找智能体，不如把入口直接放在人已经在用的地方。

监视：降低看守成本

能不能只看状态、不看过程，取决于任务本身。杂活大多失败代价低、结果容易检查——切出来的帧对不对，看一眼就知道。因此任务提交以后，我最关心的不再是智能体刚刚说了什么，而是三个更简单的问题：

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

用最重的界面完成最轻的确认，是聊天窗口作为唯一界面时最难忍受的部分。

对于这类可以放心移开视线的任务，Pi Companion 用一个常驻桌面的任务监视器来回答这些问题。收起时，它只保留任务标题和当前状态；展开后，它显示精简的活动、待处理交互和最终结果。它不会把每一条底层事件都变成需要阅读的新消息，也不会因为普通状态更新抢走当前窗口的焦点。

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

状态变化不等于打断

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

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

需要人时，交互取代进度

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

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

完成意味着可以快速离开

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

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

对话仍然负责需要投入注意力的事

让杂活走出聊天窗口，并不意味着聊天窗口不再重要。

当任务重要、结果需要我负责，或者过程本身值得看时，观察智能体的实时行为与推理就不是负担，而是我本来就想做的事：它读了哪些文件、为什么这样改、命令输出了什么。这时候把过程压缩成一个状态指示，反而是信息损失。

所以智能体对话仍然负责：

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

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

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

快捷任务入口负责开始，任务监视器负责陪伴和介入，对话负责需要我投入注意力的事。

快捷任务入口是短暂的，任务监视器是环境式的，智能体对话是按需打开的。它们承担不同的信息密度与注意力成本——而决定该用哪一个的，不是我，是任务本身。

结果：监视器改变的是信息的取舍

任务监视器真正难做的地方在于信息的取舍：什么才算“需要我”，什么时候该让交互盖过状态。显示得越全，就越退回聊天窗口；显示得太少，我又会忍不住切回去核对。

前面提到的三条原则，本质上都是在划定这条边界——普通状态可以变但不打断，只有权限请求和提问能占据前台，完成之后只回答“结果够不够用”。守住这个取舍，我才能放心地把视线移开去做别的事。

当前实现与下一步

Pi Companion 目前已经实现：

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

往后看，右键菜单这个位置还指向另一个方向：文件杂活高频、涉及你自己的文件、规则通常不复杂，正好落在本地小模型的适用范围里。如果其中一部分能交给不联网的本地模型处理，这个入口就会更接近系统自带的能力，而不是一个需要额外配置的服务。前提是任务可以被检查、可以回滚——删除、移动这类不可逆操作仍然需要更谨慎的确认。这部分目前只是方向，还没有实现。

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

Pi Companion 只对一类事负责：描述清楚之后我就不想再管的杂活。需要持续投入注意力的任务，仍然留在完整的对话里。

如果你也在想，日常杂活是否一定要经过聊天窗口，可以在 GitHub 查看完整代码和产品文档。