269 lines
17 KiB
Markdown
269 lines
17 KiB
Markdown
# iPolloWork 深度拆解：当"多引擎中立"成为 Agent 工作台的新战场
|
||
|
||
> **速览**
|
||
>
|
||
> | 项 | 值 |
|
||
> | --- | --- |
|
||
> | 仓库 | [Devin-AXIS/iPolloWork](https://github.com/Devin-AXIS/iPolloWork) |
|
||
> | 一句话 | 面向人与智能体团队的企业级、本地优先 Agent 工作台 |
|
||
> | Star / Fork / Issues | 5201 / 976 / 80（2026-09-01） |
|
||
> | 主语言 / 体积 | TypeScript 49.5% / **591 MB** |
|
||
> | 最新版本 / 节奏 | v0.50.12 / **一天多版** |
|
||
> | 许可证 | iPolloWork Source Available License 1.0（**L3 · 源码可得，非开源**） |
|
||
> | 成熟度 | beta |
|
||
>
|
||
> **一句话结论**：把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用。
|
||
|
||
---
|
||
|
||
## 0. 先给结论
|
||
|
||
iPolloWork 不是一个编程 Agent，也不是某个引擎的"平替"。它想做的是 **Agent 时代的 IDE —— 但不是给代码用的 IDE，而是给"agent 项目"用的工作台**。
|
||
|
||
它真正有意思的地方有三个：
|
||
|
||
1. **它赌引擎会继续碎片化。** Codex Harness 开放了、DeepSeek Harness 开放了、OpenCode 在长——引擎层在分裂，而它把自己放在引擎之上，让引擎可换。这个站位是有战略眼光的。
|
||
2. **它把"交付物能不能继续改"当成核心卖点。** 大多数 Agent 工具交付的是一段聊天记录或一个成品文件；iPolloWork 要的是产出 PPT、网页、设计、视频之后，文字、图片、布局、时间线、场景都还能继续编辑。这是从"生成工具"跨向"工作台"的关键一步。
|
||
3. **它同时也是一个正在快速商业化的产品。** 源码可用，但不是开源。3 人以上就要书面授权。
|
||
|
||
而它最大的问题也有三个：**三种引擎的接入深度不对等**、**DSH 集成尚未进稳定版**、**版本还在 0.50.x 却一天发好几版**。这三件事放在一起，意味着它现在更适合观察，而不是押注。
|
||
|
||
---
|
||
|
||
## 1. 赛道定位：它站在哪一层
|
||
|
||
Agent 工具大致可以分成三层。判断一个项目，先判断它站在哪一层，以及它想往哪一层长：
|
||
|
||
```text
|
||
┌──────────────────────────────────────────────────────────────┐
|
||
│ 桌面工作台层 │
|
||
│ 跨引擎、跨项目、跨交付物的统一界面 │
|
||
│ ── iPolloWork 在这里 ── │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ 编辑器内 Agent 层 │
|
||
│ 嵌在 IDE / 编辑器里的交互层（Cline、Roo Code、Kilo Code 一类） │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ 执行引擎层 │
|
||
│ 真正跑 agent loop 的地方 │
|
||
│ Codex、DeepSeek Harness、OpenCode、Gemini CLI │
|
||
└──────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**iPolloWork 明确站在最上层，并且明确声明不往下走。** README 里写得很直白：它不会 fork OpenCode，也不会 fork DeepSeek Harness，两者都可以继续独立演进。这是相当克制的产品决策——放弃了对执行层的控制，换来了"任何引擎都能接"的合法性。
|
||
|
||
越往上，离模型越远、离交付物越近，用户黏性越强；但风险也一样明显：**它依赖的每一层都可能向上长**。OpenCode 可以自己做工作台，IDE 厂商可以从编辑器层往上爬。中立是它的护城河，反过来说，也是"它没有独占能力"的另一种表述。
|
||
|
||
---
|
||
|
||
## 2. 业务维度：它靠什么活着
|
||
|
||
**目标用户**是"人与 agent 团队"——注意不是个人开发者。README 反复出现的是 responsibilities、tasks、schedules、execution health、approves actions 这类词，全是团队协作语义。
|
||
|
||
**变现走的是典型双轨制**：个人自用免费，少于 3 人的小规模内部使用免费；超过这条线，以及任何售卖、转售、付费服务、SaaS、托管、白标、市场分发或面向客户的使用，都要书面授权。配套的 iPolloCloud 负责身份、组织、权益、托管 Worker 生命周期和商业 App。
|
||
|
||
### 许可证：这是"源码可用"，不是"开源"
|
||
|
||
这一节值得单独说，因为很多人会看错。
|
||
|
||
iPolloWork 用的是自家写的 *iPolloWork Source Available License 1.0*，GitHub 上 SPDX 识别为 `NOASSERTION`。项目方自己在中英文 README 里都写清楚了：**这是源码可用协议，不是 OSI 认可的开源协议**。
|
||
|
||
关键条款有三条：
|
||
|
||
- **3 名及以上用户**的任何形式使用——不管个人、企业、内部、外部、商业还是非商业——都需要事先书面授权。
|
||
- 任何**售卖、转售、收费服务、SaaS、托管、白标、市场分发或面向客户**的使用，都需要事先书面授权。
|
||
- 面向用户的前端**必须保留** iPolloWork 名称、Logo 和产品归属，除非书面授权明确允许换品牌。
|
||
|
||
第三条尤其值得注意：**它连白标都要管**。这说明它的商业意图不只是卖授权，还要保住品牌资产。
|
||
|
||
顺带说一个实操层面的推论：正因为第二条里写了"托管、市场分发"，我做源码追踪时把它的镜像设成了**私有**。替别人的源码做一次未经授权的公开分发，不值得。这也是本系列把"许可证分级"做成自动化规则的原因——这种判断不该每次都靠临时想起来。
|
||
|
||
---
|
||
|
||
## 3. 场景维度：它在什么场合被用
|
||
|
||
**人机协作模式是"审批式"**（approval-gated）。README 的原话是：你描述目标，agent 负责规划和执行，团队可以检查进度、批准操作，并在同一个地方继续编辑结果。不是全自动，也不是全程盯着，是**关键动作逐项批准**。
|
||
|
||
**交付物是它最想讲的差异化。** 覆盖代码、文档、网站、演示稿、设计和视频六类，而且强调生成之后**仍然可编辑**：
|
||
|
||
| 产出类型 | 生成后仍可修改的要素 |
|
||
| --- | --- |
|
||
| 文档 / 演示稿 | 文字、图片、布局 |
|
||
| 网站 | 文字、图片、布局 |
|
||
| 设计 | 文字、图片、布局 |
|
||
| 视频 | 时间线、场景 |
|
||
|
||
这个设计判断我认同。当前 Agent 工具最大的浪费不是生成得不够好，而是**生成出来的东西没法接着改**——一次不满意，整段推倒重来，最后只剩一段聊天记录。把"可编辑"做成一等公民，是把 Agent 从"一次性生成器"推向"生产工具"的必要一步。
|
||
|
||
典型用例大致是这三类：
|
||
|
||
- 同一项目里混用 OpenCode 和 DSH，任务状态与流式输出统一在工作台呈现，而不是散在多个终端会话里
|
||
- 让 agent 产出一份 PPT 或网页后，人工继续改文字、图片、布局，而不是只拿到一个成品文件
|
||
- 团队在同一项目视图里查看职责、任务、日程与执行健康度，并逐项批准 agent 的动作
|
||
|
||
---
|
||
|
||
## 4. 技术维度：它怎么做到的
|
||
|
||
### 架构
|
||
|
||
README 给的架构边界是这样的：
|
||
|
||
```text
|
||
Codex / MCP 客户端 ── ipollowork-ui-mcp ──> iPolloWork 桌面/UI
|
||
│
|
||
├── 本地 API ──> Engine Protocol ──> OpenCode（默认）
|
||
│ └──> DeepSeek Harness（可选）
|
||
└── 可选账号与控制请求 ──> iPolloCloud
|
||
```
|
||
|
||
我在这个基础上标一层**接入深度**，这才是理解它的关键：
|
||
|
||
```text
|
||
┌─ iPolloWork 桌面/UI ────────────────────────────────────────┐
|
||
│ │
|
||
│ Codex ──[ ipollowork-ui-mcp ]──────────┐ │ 深度：浅（仅控制面）
|
||
│ ▼ │
|
||
│ 本地 API ──[ Engine Protocol ]──> OpenCode（默认 sidecar） │ 深度：深（原生 adapter）
|
||
│ └──> DeepSeek Harness（可选）│ 深度：深（peer runtime）
|
||
│ │
|
||
│ 可选 ──> iPolloCloud（身份/组织/权益/托管/商业 App） │ 断网可跑
|
||
└──────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### monorepo 布局
|
||
|
||
仓库是标准的四 app 结构，值得关注的是 `apps/orchestrator`：
|
||
|
||
| 目录 | 职责 |
|
||
| --- | --- |
|
||
| `apps/app` | 共享 React UI |
|
||
| `apps/desktop` | Electron 外壳与打包 |
|
||
| `apps/server` | 服务端 API |
|
||
| `apps/orchestrator` | **headless 运行时编排**（用 Bun 1.3.10+ 构建） |
|
||
| `packages` | 共享 types、components、docs、integrations |
|
||
| `evals` | 可执行产品流与验证工具 |
|
||
| `external-plugins` | 面向**外部** agent host 独立发布的插件 |
|
||
| `vendor` | pinned 第三方源码，随主仓一起构建 |
|
||
|
||
`external-plugins` 这个目录透露了它的另一面：它不只把别人的引擎接进来，还把自己的插件**反向输出**到别人的生态里（比如发到 npm 上的 `deepseek-idesign` / `deepseek-ippt` / `deepseek-ivideo`，让 DSH 用户直接用上 iPolloWork 的 Design / PPT / Video 视图）。这是很聪明的双向渗透。
|
||
|
||
### 引擎抽象：三种引擎，三种深度
|
||
|
||
这是全文技术上最该看清的一点。
|
||
|
||
| 引擎 | 接入路径 | 深度 | 状态 |
|
||
| --- | --- | --- | --- |
|
||
| **OpenCode** | 本地 API → Engine Protocol | 原生 adapter | 默认本地执行 runtime |
|
||
| **DeepSeek Harness** | 本地 API → Engine Protocol | peer runtime + 子代理委派目标 | 可选，**仍在开发中** |
|
||
| **Codex** | `ipollowork-ui-mcp` MCP 控制面 | **仅控制面** | 已打通，但非原生 adapter |
|
||
|
||
README 对 Codex 的表述相当诚实，原话是：
|
||
|
||
> Codex compatibility **currently** uses the MCP control surface **rather than claiming** a native Codex engine adapter.
|
||
|
||
也就是说，项目方自己承认了 Codex 这条路径和 OpenCode / DSH 不是一回事。注意加粗的两个词——`currently`（目前）和 `rather than claiming`（而不是声称）——**限定词往往就是落差的藏身处**。
|
||
|
||
### 统一的是生命周期，不是能力
|
||
|
||
"统一插件与 Skills"是它主打的卖点之一，但要准确理解：
|
||
|
||
统一的是**生命周期**（安装、启用、更新、卸载一次搞定），不是能力本身。README 明确写着，各 runtime 保留自己的 agents、Skills、插件与执行模型，引擎专属增强只是可选。
|
||
|
||
这个设计其实是对的——硬要统一能力，要么牺牲深度，要么逼引擎做适配。但它意味着"一次安装处处可用"是有限度的。
|
||
|
||
### 本地优先是真的
|
||
|
||
iPolloCloud 明确是可选的，负责身份、组织、权益、托管 Worker 和商业 App。**不连 Cloud 也能完整本地运行**，这一点属实。
|
||
|
||
细节上：默认本地 runtime 是 OpenCode，以**独立 sidecar** 形式存在，首次桌面构建时下载，iPolloWork 不 fork、不改写它，OpenCode 可以独立升级。开发模式还用了隔离状态，不会污染用户原有的 OpenCode 配置。
|
||
|
||
---
|
||
|
||
## 5. 横向对比
|
||
|
||
> 说明：下表除 iPolloWork 外的项目尚未正式收录进追踪库，仅作为**参照项**列出，数据未做逐项核实。
|
||
|
||
| 维度 | iPolloWork | 执行引擎（Codex / OpenCode / DSH） | 编辑器内 Agent（Cline / Roo / Kilo） |
|
||
| --- | --- | --- | --- |
|
||
| 站位层次 | 桌面工作台层 | 执行引擎层 | 编辑器内 Agent 层 |
|
||
| 引擎立场 | 多引擎中立 | 自己就是引擎 | 通常绑定单一或少数模型 |
|
||
| 交付物纵深 | 代码→文档→PPT→网站→设计→视频，均可续改 | 以代码为主 | 以代码为主 |
|
||
| 人机协作 | 审批式，团队共看一张项目视图 | 多为单人命令行 | 单人、编辑器内 |
|
||
| 许可证 | L3 source-available | 多为 MIT / Apache | 多为 MIT / Apache |
|
||
| 成熟度 | beta（v0.50.x） | 相对成熟 | 相对成熟 |
|
||
|
||
一句话概括差异：**引擎层解决"怎么跑"，编辑器层解决"在哪写"，iPolloWork 想解决"跑完之后一堆人和一堆产出物怎么管"。**
|
||
|
||
---
|
||
|
||
## 6. 宣称 vs 实测
|
||
|
||
这一节是本系列最看重的部分。项目方基本没说谎，但有几处没说全。
|
||
|
||
**① 宣称：兼容 Codex、DeepSeek Harness、OpenCode 三大引擎。**
|
||
**实际**：三者接入深度不对等。OpenCode 与 DSH 走 Engine Protocol 原生 adapter；Codex 只通过 `ipollowork-ui-mcp` 的 MCP 控制面接入，README 自己否认这是原生 Codex engine adapter。
|
||
**来源**：仓库 README 的 *Architecture boundary* 一节原文。
|
||
|
||
**② 宣称：集成 DeepSeek Harness 用于子代理委派。**
|
||
**实际**：第三方插件目录标注为「integration in active development, **not yet in the stable release**」；且 DSH 本身处于 developer preview 阶段。功能方向成立，但尚未落地到稳定版。
|
||
**来源**：deepseekharnessplugins.com 插件页；README 关于 DSH developer preview 的说明。
|
||
|
||
**③ 宣称：8 小时完成 Codex Harness 适配，登顶相关主题榜第一。**
|
||
**实际**：响应速度属实，有第三方报道佐证。但"适配"指的是打通 MCP 控制面路径，不等于原生引擎级集成——**快是因为走控制面，深度也受限于控制面**。这两件事是一体两面。
|
||
**来源**：ME News 报道；README 关于 Codex 接入方式的表述。
|
||
|
||
**④ 宣称：本地优先、不连云也能完整运行。**
|
||
**实际**：基本成立。iPolloCloud 确实可选。但默认本地 runtime 是 OpenCode sidecar，首次桌面构建时需联网下载；Orchestrator sidecar 也由 iPolloWork 侧编排。
|
||
**来源**：README 架构边界与安装章节。
|
||
|
||
**⑤ 宣称：统一的插件与 Skills 生态。**
|
||
**实际**：统一的是生命周期，不是能力。各 runtime 保留自己的 agents、Skills、插件与执行模型。
|
||
**来源**：README 的 *Agent runtime compatibility* 一节。
|
||
|
||
**⑥ 宣称：仓库 topics 里标了 `claude-code`。**
|
||
**实际**：中英文 README 均未描述任何 Claude Code 接入方式。这个 topic 更像搜索曝光策略，不应视为已支持的能力。
|
||
**来源**：GitHub topics 与 README 全文对照。
|
||
|
||
**⑦ 宣称：企业级（enterprise-grade）。**
|
||
**实际**：版本号仍在 0.50.x，无公开 Roadmap，发布节奏为**一天多版**，仓库体积 **591 MB**。工程投入相当可观，但版本语义上离"企业级稳定"还有距离。
|
||
**来源**：GitHub releases；README 版本说明；仓库 size 字段。
|
||
|
||
第 ⑦ 条值得展开一下。一天发好几版可以是"迭代快"，也可以是"在追 bug"。结合 591 MB 的仓库体积和 80 个 open issues 看，我倾向于认为它正处在**高速冲刺期**——这个阶段的产品，功能边界和稳定性都在剧烈变动。
|
||
|
||
---
|
||
|
||
## 7. 结论：什么人该用它
|
||
|
||
**该用：**
|
||
- 想在同一个界面里管理多引擎项目、不想被某个 runtime 绑死的个人开发者
|
||
- 需要 agent 产出的 PPT / 网页 / 设计 / 视频**之后还能继续手工修改**的人
|
||
- 少于 3 人的极小团队（在许可证免费范围内试用）
|
||
|
||
**不该用：**
|
||
- **3 人以上需要正式落地的团队**——许可证明确要求书面授权，别等用到一半才发现
|
||
- **期待 Codex 原生级集成的用户**——目前只有 MCP 控制面
|
||
- **追求稳定的生产环境**——v0.50.x、一天多版、DSH 集成未进稳定版，这三个叠在一起风险不低
|
||
- **想要完全自主可控的团队**——工作台层本身是闭源商业产品，资产沉淀在它的项目模型里，退出成本高于纯 CLI 方案
|
||
|
||
**再看看：** 等三件事落地再评估——① DSH 集成进稳定版 ② Codex 从 MCP 控制面升级到原生 adapter ③ 版本号进 1.0。
|
||
|
||
---
|
||
|
||
## 8. 追踪备注
|
||
|
||
- **数据日期**：2026-09-01（GitHub API 快照）
|
||
- **指标**：★ 5201 / fork 976 / issues 80 / watchers 640 / 591 MB / TypeScript 49.5%
|
||
- **最新版本**：v0.50.12（2026-08-31），节奏为一天多版
|
||
- **源码镜像**：`gitinbox/iPolloWork`（**私有**，因 L3 source-available 许可证）
|
||
- **结构化档案**：`data/projects/ipollowork.yaml`
|
||
|
||
**下次跟进点：**
|
||
|
||
1. DSH 子代理委派是否进入稳定版（当前第三方标注为 in active development）
|
||
2. Codex 是否从 MCP 控制面升级为原生 Engine Protocol adapter
|
||
3. 许可证条款是否调整——3 人门槛与白标限制是观察其商业化走向的窗口
|
||
|
||
---
|
||
|
||
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
|