Pinvou Agent：把工作、设计与编码放进一个桌面 Agent 工作区

它想解决的是聊天窗口交不出东西的问题

大多数桌面 AI 客户端的终点是一段回复文本。用户把内容复制出去，再自己去找文件、改格式、发出去。Pinvou Agent 的 README 把这一点写得很直白：它面向的是应该以结果收尾的任务，而不是又一段聊天回复。具体做法是给智能体配一套真实工具，让它读写文件、调用外部服务、把产物收集到 artifact 面板里。

目标用户有三类。第一类是日常办公场景，需要把附件、个人知识库、专家角色、Skills 和 workflow 组合起来，产出可复用的文件。第二类是设计场景，用自然语言生成海报或数据可视化，再进入 design mode 直接选中元素改文案、字体、颜色、尺寸和布局。第三类是开发场景，通过 ACP 把 Codex、Claude Code 或 Kimi 拉进同一个工作区，让编码代理读写真实项目或隔离的临时工作区、执行命令、把计划、工具步骤、权限请求和文件变更展示出来。

这三类场景共享同一套会话、附件和产物机制，这是它区别于单一用途工具的地方。但也要看清楚，README 描述的是产品意图，不是已验证的效果。

Rust 外壳、React 前端与 ACP 会话绑定

仓库的主语言是 Rust，前端是 React，桌面壳用 Tauri，这些从 topics 和目录结构可以确认。应用主体位于 pinvou3-app 目录，Tauri 侧的配置和图标在 pinvou3-app/src-tauri/ 下。

从 README 能看到的机制有几层。会话层：多会话工作区支持标题搜索，消息、工具调用和产物随会话持久化。工具层：统一工具商店管理本地 MCP 服务器、远程 MCP 服务器、CLI 工具和 API 连接器，在支持的场景下走 OAuth 或 SSO 授权，不需要手动粘贴密钥。知识层：本地知识库提供文件管理、全文检索和向量检索，一个会话可以挂载多个集合，每个集合独立开关，回答里保留集合与文件的来源标注。产物层：artifact 面板自动收集智能体创建或修改的每个文件，Markdown 产物可以直接编辑，也可以选中一段让智能体改写。

编码模式走的是 ACP，这是它架构上最值得注意的一点。README 说明会话与工作区绑定，重启应用后可以继续。这意味着 Pinvou 自己不实现编码能力，而是充当宿主，把 Codex、Claude Code、Kimi 这类代理接进来，再把它们的计划和工具步骤渲染到界面上。文档在 docs/multi-agent-acp.md 里展开。

数据落盘位置统一在 ~/.pinvou3/ 下，包括会话、设置、知识库和运行时扩展。这是一个明确的边界，备份和迁移都围绕它做。

启动前要准备的模型配置与目录

README 没有给出完整的安装命令，只提供了下载入口和模型接入示例，这一点需要如实说明。可确认的启动路径是：从 GitHub Releases 页面下载预览版安装包，Windows、macOS、Linux 三个平台都在支持范围内。

模型接入有两种方式。一种是在应用设置里管理端点、模型名和 API 密钥；另一种是用环境变量，README 给出的本地 vLLM 示例是：

export DEEPSEEK_BASE_URL="http://127.0.0.1:8000/v1" export DEEPSEEK_API_KEY="local-no-auth" export DEEPSEEK_MODEL="your-model-name"

内置模板覆盖本地 vLLM、DeepSeek、Kimi、Qwen、Doubao、MiniMax、Zhipu (GLM)、MiMo、OpenAI、Anthropic、Gemini 和 xAI，也允许填任意兼容端点。可以保存多份模型配置，给云端配置加一个显示别名，然后在会话之间切换，而不改变发送给服务商的模型标识符。

语音输入需要按需下载语音模型，不是开箱即用。扩展能力通过 MCP 服务器、CLI 连接器和 Skills 接入，现成连接器包括飞书、钉钉、企业微信、腾讯会议、腾讯 ima、Obsidian，以及企业知识库和法律、企业数据服务。

需要提前确认的是更新机制：README 明确写着通过 GitHub Releases 更新，应用内更新检查尚未启用。也就是说升级要手动完成。

本地优先是有条件的，取决于你打开了什么

local-first 是仓库的 topic 之一，但 README 的提示条款给出了更准确的边界：数据是否离开本机，取决于你启用的模型和工具。本地模型加本地工具构成完全本地的闭环；云端模型、远程 MCP 服务器和第三方连接器会把相关请求发到各自的服务。

这个区分很重要，因为知识库和记忆中心容易被误读成纯本地能力。知识库本身在本地做检索，但一旦挂载了远程 MCP 工具，或者把会话交给云端模型，检索到的内容就可能作为上下文被发送出去。记忆中心捕获长期偏好和上下文，README 说明它有明确的候选审核与确认环节，这是对自动写入记忆的一种约束，但确认之后的内容去向仍由模型和工具决定。

远程控制功能同样值得留意：用手机扫码可以查看和操控正在运行的工作区。README 没有说明这条通道的鉴权与加密细节，文档材料里也没有展开。如果你的环境对这类远程入口有要求，这是需要先去仓库文档和 SECURITY.md 里确认的部分，而不是默认接受。

预览版节奏与维护成本

最近三个版本是 v0.9.1（9 月 2 日）、v0.9.2（9 月 7 日）、v0.9.3（9 月 9 日），发布说明里都标注为预览版，版本号停在 0.9.x。两天到五天一个版本的节奏，说明项目处于快速迭代期。对使用者来说，这意味着升级频率高、行为可能变化，而且因为应用内更新检查尚未启用，每次升级都要自己去 Releases 页面取包。

维护成本主要体现在三处。一是模型配置，多份配置和别名机制降低了切换成本，但端点、密钥和模型名的维护仍然落在使用者身上。二是扩展，MCP 服务器、CLI 连接器和 Skills 需要各自维护，连接器列表越长，失效面越大。三是数据目录，~/.pinvou3/ 下同时放会话、设置、知识库和运行时扩展，升级时如果目录结构变化，迁移方案需要自己准备。

许可证是 MIT，这是仓库元数据里可以直接确认的。MIT 允许商业使用、修改和再分发，约束较少。但要注意一个容易被忽略的点：通过 ACP 接入的 Codex、Claude Code 等编码代理有自己的许可证，它们的条款不会因为宿主是 MIT 而改变。把这类代理嵌入团队流程前，需要单独核对它们各自的许可条件。以上是许可事实的陈述，不构成法律意见。

什么时候该换别的工具

Pinvou Agent 的定位是桌面工作区，这决定了它在几类场景里不是合适的选择。

如果任务是无头自动化，比如在 CI 里跑一个批量处理流程，桌面应用形态本身就是负担，命令行智能体更直接。如果需要的是深度绑定某一家的编码体验，直接用 Codex 或 Claude Code 的原生客户端，能拿到更完整的上下文管理和更少的中间层，Pinvou 在这里的价值是统一界面和会话持久化，代价是多一层宿主。如果团队要求所有推理都在内网完成且不允许任何外部连接，那么必须把模型限制在本地 vLLM、把所有远程 MCP 服务器和第三方连接器全部关闭，此时工具商店里的大部分现成连接器都用不上，产品优势会被削掉一大块。

作为替代方向，可以对照的是两类项目。一类是纯命令行、可脚本化的智能体框架，它们没有 GUI，但更容易嵌入流水线和版本控制。另一类是不带 ACP 宿主的单一编码客户端，它们不做多模式工作区，但在自己那条路径上更专注。两者的差别不在功能多少，而在是否愿意为统一工作区承担桌面应用的部署与升级成本。

编辑结论

如果你需要的是一个桌面端、能同时处理文件与知识库、并且愿意通过 ACP 复用 Codex 或 Claude Code 的工作台，Pinvou Agent 值得下载预览版试一次；如果你要的是稳定可预期的生产工具，或者团队无法接受 AGPL 类许可的编码代理被嵌入到自己的流程里，现在还不是时候。上手前先确认三件事：README 明确写着应用内更新检查尚未启用，升级要走 GitHub Releases 手动路径；所有会话、设置、知识库和运行时扩展都落在 ~/.pinvou3/ 下，先确认这个目录在你的备份与合规范围内；再确认你打算启用的远程 MCP 服务器和第三方连接器会把哪些请求发到外部服务，因为 README 的提示条款写明，数据是否离开本机取决于你启用的模型和工具。版本号仍停在 0.9.x 预览版，最近几个版本间隔只有两三天，接口和行为都可能变动。

官方来源

1. License: MIT
2. Pinvou/pinvou-agent on GitHub
3. Project website
4. README
5. Releases