从效率工具到生产力系统：我为什么做 Pi-67 Desktop

为什么选择 Pi SDK#

选择 Pi SDK 的原因很直接：它开源、克制，而且给了开发者足够大的自定义空间。

很多 Agent 产品一开始就替你决定好了界面、工作方式、模型、工具和上下文组织方式。你可以使用它，却很难真正把它变成自己的产品。Pi 不一样。它更接近一套可以被嵌入的 Agent Runtime：模型、工具、Session、扩展、Prompt、Skills 和上下文都可以继续组合，我可以在它之上设计工作台，而不必重新实现第二套 Agent 内核。

这件事对 Pi-67 Desktop 很重要。

我不希望桌面端拥有一套 Session，命令行又拥有另一套 Session；界面认为任务已经完成，底层却没有对应的执行记录；或者为了增加团队功能，把成熟的本地 Agent 能力重新复制一遍。Pi 应该继续是唯一的 Agent Runtime，Pi 的 JSONL Session 应该继续是对话和执行历史的事实来源。Desktop 所做的，是把这些能力组织成更完整的产品体验：工作区、会话、工具调用、文件变化、安全确认、失败恢复，以及未来的团队协作。

所以，Pi-67 Desktop 不是要把 Pi 藏起来。恰恰相反，它要尊重 Pi 已经建立的能力边界，在这块可靠的地基上继续生长。

个人效率很高，不等于组织生产力很高#

今天主流 Agent 产品最成熟的闭环，仍然大多围绕个人展开：我提出任务，Agent 在我的环境里执行，我检查结果，然后继续下一轮。

这套模式已经非常有价值。WorkBuddy 把自己定义为面向每个人的 AI 工作伙伴，Codex 也在继续补齐团队和企业能力。准确地说，它们已经不再“只给个人使用”。但从产品的默认视角看，第一主体通常仍然是一个用户、一段会话和一次任务。团队能力更多是在个人工作闭环之外，增加账号、管理、共享或安全层。

问题是，组织的生产力并不等于所有个人效率的简单相加。

一个人让 Agent 完成了一次高质量排障，如果过程只留在他的本地 Session 里，下一位同事仍然会从头调查；一个人整理出了客户沟通方法，如果它只存在于私人文档中，团队并没有真正获得这项能力；一个 Agent 修改了代码，如果任务状态、验证结果和决策依据无法回到协作空间，其他人看到的仍然只是“他说已经做完了”。

个人工具关心的是：我怎样更快完成这次任务。

团队系统还必须回答：

• 谁正在做什么，为什么要做？
• Agent 使用了哪些上下文、能力和权限？
• 工作进行到哪里，谁可以接手？
• 哪些结果已经验证，哪些只是推断？
• 这次解决问题形成了什么可复用经验？
• 哪些内容可以进入团队知识，哪些必须保持私有？

企业真正需要的不是给每个人发一把更快的锤子，而是让人、Agent、知识和工作流逐渐形成一套共同工作的系统。

飞书和钉钉真正落后的地方#

飞书、钉钉完成了一件很重要的事：它们把办公室数字化了。消息、文档、会议、审批、项目和组织关系被搬进同一个应用，信息传递更快，管理也更容易规模化。

但办公室数字化，不等于组织智能化。

今天再说它们“没有 AI”已经不准确。飞书 已经在知识问答、会议纪要和智能伙伴等方向持续产品化，钉钉 也在强调 AI 助理、Agent 和 AI 平台。问题恰恰在这里：当越来越多 AI 功能被塞进消息、文档、会议和审批以后，它们仍然没有改变产品最底层的假设——工作由人完成，软件负责传递信息、记录过程和催促下一个人。

于是，AI 最终很容易变成一个更能干的秘书：帮人读完看不完的群聊，整理开不完的会议，总结堆积的文档，再替越来越复杂的旧流程补上自动化。它缓解了传统协同软件制造的信息过载，却没有真正重写工作本身。

人在群里讨论问题，仍然要自己提炼任务；把上下文复制给 Agent，仍然要自己挑选工具和环境；Agent 做完以后，仍然要有人把结果贴回群里、解释发生了什么，再追着下一个人继续执行。界面里已经有了 AI，组织却依然靠人充当各个系统之间的胶水。

所以，问题从来不是它们少了某个模型、某个入口或者某个智能助手，而是它们仍在优化一台以“人传递信息”为中心的旧组织机器。模块可以越来越多，AI 可以越来越强，但只要 Agent 没有自己的身份、任务、环境、记忆、权限和责任闭环，它就始终只是工具栏里更聪明的一项功能。

AI-native 的工作系统不应该继续问“怎样让人更快地处理消息和流程”，而应该重新问：当 Agent 已经能够理解上下文、规划、执行和反馈时，哪些工作还需要在人与人之间反复传递，哪些可以直接成为系统里的行动？

传统协同软件的最小单位是消息、文档和流程；AI-native 工作系统的最小单位，应该是一个有身份、有记忆、有权限、能执行、可追责的生产力单元。

效率工具帮助劳动者更快地操作旧流程；生产力系统则开始把一部分感知、判断、执行和学习能力直接组织进产品。人负责提出真正的问题、设定目标和边界、作出关键决策；Agent 承担可以被执行和验证的工作，并对自己的过程与结果留下证据。

企业知识应该流通，但不能裸奔#

团队版最吸引人的想象，是让每个人和 Agent 学到的知识、经验与记忆在企业里流通。

这个方向没有错，但“共享一切”会是非常危险的设计。

原始 Session 里可能包含个人偏好、未完成的推断、客户信息、环境路径、内部代码、失败尝试，甚至短期凭据。把所有本地记忆直接同步到一个企业知识库，表面上消除了信息孤岛，实际上也同时制造了隐私、权限、污染和错误传播问题。

所以我更愿意把企业记忆拆成不同层次：

1
私人记忆 → 可分享案例 → 审核后的 Experience / SOP → 团队能力

私人记忆默认只服务于个人和当前环境；值得复用的任务可以被提炼成案例；案例经过脱敏、审阅、版本化和适用范围说明以后，才有资格成为团队 Experience 或 SOP。错误内容要能撤回，过期经验要能失效，引用时要知道来源，使用时还要受权限与审计约束。

我正在探索的 OpenViking，承担的正是这部分记忆与经验基础设施。它不是把聊天记录换一个地方保存，而是试图回答：什么值得记住，谁可以看到，怎样从一次工作中提炼经验，以及这些经验如何在不破坏私人边界的前提下为团队所用。

企业知识的目标不是“大家都能看到更多”，而是让正确的知识，在正确的范围内，以可追踪的方式流到下一次工作中。

Work × Chat：Pi-67 Desktop 的产品骨架#

基于这些判断，我对 Pi-67 Desktop 的下一阶段规划逐渐变得清晰：桌面端不是一个无限延伸的聊天窗口，而是两个彼此独立、又必须真正贯通的工作区域。

左边是 Work。

Work 是本地执行现场。它首先让用户选择当前机器和 Workspace，再进入一段由 Pi Runtime 驱动的真实 Session。这里不只有对话，还要同时看见 Agent 正在使用的终端、工具调用、文件、Diff、浏览器、计划、权限请求和验证结果。

当 Agent 处理代码任务时，Work 应该知道自己进入了哪个仓库、当前分支是否干净、加载了哪些配置和 Skills、运行过什么命令、改变了哪些文件、测试是否通过。任务中断后可以恢复，交给另一个人时可以 Handoff，发生危险操作时必须等待批准。一个 Work 的终点不是 Agent 回答“已经完成”，而是交付一组可以被检查的变化与回执。

这也是为什么 Work 必须尽可能靠近本地机器。代码、设计文件、数据、浏览器登录态和专业工具往往都在本地环境里；有些任务还依赖较高的 CPU、内存、GPU 或完整开发链。云端 Chat 可以很轻，但真正执行工作的地方不能假装这些环境不存在。

右边是 Chat。

Chat 是团队协作与调度现场。它保留频道、私聊、Thread、@、通知和文件分享，因为人仍然需要讨论、质疑和作出决定；但每段对话都可以进一步成为任务，而不是最后沉没在消息流里。

一个频道里既有人，也有拥有明确身份的 Agent。成员可以在 Thread 中补充背景、引用团队 Experience、指定验收条件，然后把这段上下文直接创建为任务。Chat 需要显示的也不只是“对方正在输入”，而是 Agent 当前处于排队、执行、等待授权、阻塞、待验收还是已完成；团队成员可以继续追问、改变优先级、批准动作、接管任务，或者把它路由到一台具备正确环境的本地 Work。

Chat 不需要把 Work 的每一行终端日志都刷进频道。它应该回传对协作真正有意义的状态：Agent 做出了什么关键判断，遇到了什么阻塞，需要谁批准，改动范围是什么，验证到了哪一层，以及最终结果在哪里。想看细节的人可以进入对应 Work；只关心协作的人留在 Chat 也能理解事情是否真的完成。

举一个具体场景。假设同事在产品频道里提出“桌面端恢复 Session 后文件变化丢失”，Agent 先结合 Thread 和已有 Experience 整理出目标、仓库、约束与验收条件，创建任务卡；系统发现这个任务需要本地源码和桌面运行环境，便把它路由到合适机器上的 Work。Pi 在那里检查仓库、复现问题、修改文件并运行测试。Chat 中持续显示“正在复现”“需要授权启动桌面应用”“修复完成，等待视觉验收”等关键节点。最后，Diff、测试、截图和未验证项组成回执返回原 Thread，团队可以审阅、继续追问或交给另一个人接手，而不需要重新拼装全部上下文。

两边之间不是靠复制粘贴贯通，而是靠明确的任务与证据合同：

1
Chat 中形成目标与约束
2
        ↓
3
创建任务并路由到合适的人 / Agent / 本地 Work
4
        ↓
5
Work 调用本地环境执行，持续回传状态与关键决策
6
        ↓
7
验证结果、生成回执、回到 Chat 供团队审阅
8
        ↓
9
有价值的方法经治理后沉淀为团队 Experience

Chat 不是给 Work 再加一个输入框；它是把本地执行能力接入团队协作网络。点击图片可打开交互图。

这套结构里，Work 与 Chat 谁也不是谁的附属品。它们之间至少要共享同一个任务身份、同一组目标与验收条件，以及可以互相引用的状态、权限、回执和 Handoff；但本地文件、原始 Session 和私人记忆又不能因为进入 Chat 就自动变成团队公共数据。

没有 Work，Chat 里的 Agent 很容易停留在回答、总结和转发；没有 Chat，Work 再强也只是散落在每个人电脑里的孤立执行器。两者真正连接起来以后，讨论可以直接变成任务，任务可以找到正确的环境，执行状态可以被团队理解，结果可以带着证据回来，个人解决问题的方法也才有机会经过治理成为组织能力。

Raft 给我的启发#

Raft 对这个方向给了我很直接的启发。

它提出“聊天就是工作空间”：人和 Agent 在频道、私聊和 Thread 中共享上下文；Agent 有持续存在的身份和记忆；同时通过运行在本地的 Computer 接近文件、工具和真实环境。它没有把 Agent 放在协作产品边缘，而是让 Agent 进入团队的日常工作流。

我认同这个判断，尤其是 Chat 不只是对话界面，而是一层团队协作网络。

但 Pi-67 Desktop 不会简单复刻 Raft。它有自己的几个坚持：Pi 继续作为唯一 Agent Runtime；本地 Work 是产品核心，而不是远程 Chat 的附属执行节点；Pi Session 继续保存真实执行历史；私人记忆默认留在本地；共享经验必须经过治理，而不是把所有上下文自动上传。

我想吸收的是它重新定义协作空间的方式，而不是复制一套界面。

Chat 里的 Agent，不应该只是机器人账号#

今天很多协作产品已经可以把机器人拉进群里。但“能在群里回复”与“成为团队成员”之间，还有很长的距离。

一个真正进入协作系统的 Agent，至少需要一组稳定的产品属性：

• 身份：它是谁，代表什么角色，由谁创建和负责；
• 能力：它使用什么 Runtime、模型、工具和 Skills；
• 权限：它能读什么、能改什么，哪些动作需要批准；
• 状态：它当前在处理什么任务，进度和阻塞在哪里；
• 记忆：哪些只属于当前用户，哪些可以进入团队范围；
• 证据：它做过什么、依据是什么、结果是否经过验证；
• 生命周期：什么时候启用、暂停、接管、撤销或归档。

有了这些属性，Agent 才不是一个披着头像的 API。团队可以把工作交给它，可以检查它，也可以在必要时让人接管。

这并不意味着人会从系统中消失。相反，人的责任会变得更清楚：提出真正的问题，设定目标和边界，在不确定性中作出判断，并对那些不能外包给模型的结果负责。Agent 承担可执行工作，人掌握方向、授权和最终决策。

现在已经有什么，未来还要做什么#

Pi-67 Desktop 目前仍然是 Alpha。

现在已经有相对清晰的本地工作台骨架：Workspace、Conversation、工具调用、文件与变更、Session 恢复、安全确认等能力都围绕真实 Pi 任务展开。我也在继续建设私人记忆、经验提炼和 OpenViking 相关能力，让 Agent 不只完成一次任务，也能够在边界清晰的前提下从过去的工作中获得帮助。

但真正的 Team 与 Enterprise 形态还没有完成。

接下来需要建设的，不只是右边多一个聊天界面，还包括真实的团队与账号服务、频道和 Thread、Agent 身份、任务路由、跨成员协作、在线状态、共享 Experience、权限策略、审批与审计，以及本地 Work 和团队 Chat 之间稳定的交接协议。

这会是一个比“增加 Chat 功能”大得多的工程，因为它改变了产品的信任边界，也改变了谁可以调用谁的机器、知识与能力。

这是路线图，不是完成清单。名字已经出现，不代表产品已经交付。

在更大的产品版图里，我也在分别探索 Pi SDK Agent、Team Agent、OpenViking、Work & Chat、Agent Governance 和 Deep Research。它们是彼此直接相连的能力方向，但并不全部从属于 Pi-67 Desktop，也不应该因为出现在同一张路线图里，就被包装成一套已经完成的超级产品。

我更愿意让每一项能力先回答一个具体问题，再在真实需求和清晰边界中逐渐连接。

写在最后#

做 Pi-67 Desktop 的起点很简单：Pi 开源、可嵌入、可自定义，我想给自己做一套真正顺手的本地 Agent 工作台。

但如果它最终只是让我一个人写代码更快、调用工具更方便，那它仍然只是一个更好的个人客户端。这当然有价值，却不是我现在真正想去的地方。

我想做的是另一种工作系统：问题在 Chat 中被团队看见，目标和边界被共同确认，任务找到拥有正确能力与环境的人或 Agent；行动在 Work 中真实发生，过程受到权限约束，结果带着证据返回；一次成功不只属于完成任务的人，还可以经过治理成为下一次工作能够直接调用的经验。

这意味着 Pi-67 Desktop 要面对的竞争，不是谁的聊天框更顺滑、谁接入的模型更多，也不只是能不能做出一个“企业版 Coding Agent”。它真正要回答的是：当 Agent 已经成为生产力，团队是否还需要围绕消息、会议、文档和审批来组织全部工作？

飞书和钉钉连接了人和信息，Coding Agent 连接了模型和本地环境。下一代产品应该连接目标与行动、人和 Agent、个人能力与组织经验，并让其中的权限、证据与责任始终清楚。

Pi-67 Desktop 现在还远没有完成。但我愿意沿着这个方向把它做下去：以 Pi 为执行内核，以 Work × Chat 为产品骨架，以记忆和治理为长期基础，逐步建立一套真正面向团队与企业的 AI-native 生产力系统。

我不是想给飞书、钉钉加一个更强的 Agent；我想从 Agent 已经是生产力这一事实出发，重新做一遍团队协作。