速览

项	值
仓库	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 工具大致可以分成三层。判断一个项目，先判断它站在哪一层，以及它想往哪一层长：

┌──────────────────────────────────────────────────────────────┐
│  桌面工作台层                                                  │
│  跨引擎、跨项目、跨交付物的统一界面                              │
│  ── 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 给的架构边界是这样的：

Codex / MCP 客户端 ── ipollowork-ui-mcp ──> iPolloWork 桌面/UI
                                                  │
                                                  ├── 本地 API ──> Engine Protocol ──> OpenCode（默认）
                                                  │                             └──> DeepSeek Harness（可选）
                                                  └── 可选账号与控制请求 ──> iPolloCloud

我在这个基础上标一层接入深度，这才是理解它的关键：

┌─ iPolloWork 桌面/UI ────────────────────────────────────────┐
│                                                              │
│  Codex ──[ ipollowork-ui-mcp ]──────────┐                    │  深度：浅（仅控制面）
│                                          ▼                   │
│  本地 API ──[ Engine Protocol ]──> OpenCode（默认 sidecar） │  深度：深（原生 adapter）
│                                 └──> DeepSeek Harness（可选）│  深度：深（peer runtime）
│                                                              │
│  可选 ──> iPolloCloud（身份/组织/权益/托管/商业 App）        │  断网可跑
└──────────────────────────────────────────────────────────────┘

monorepo 布局

仓库是标准的四 app 结构，值得关注的是 apps/orchestrator：

external-plugins 这个目录透露了它的另一面：它不只把别人的引擎接进来，还把自己的插件反向输出到别人的生态里（比如发到 npm 上的 deepseek-idesign / deepseek-ippt / deepseek-ivideo，让 DSH 用户直接用上 iPolloWork 的 Design / PPT / Video 视图）。这是很聪明的双向渗透。

引擎抽象：三种引擎，三种深度

这是全文技术上最该看清的一点。

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 想解决"跑完之后一堆人和一堆产出物怎么管"。

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 人门槛与白标限制是观察其商业化走向的窗口

_{本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 gitinbox/agent-radar}