GitOS-inbox/agent-radar
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Publish agent-radar via gitea-publish skill

Browse Source
This commit is contained in:
gitea-publish
2026-09-01 15:14:54 +08:00
commit 78b87e8b2f
17 changed files with 2279 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
articles/00-overview.md
+161
View File
@@ -0,0 +1,161 @@
# 全球智能体开源应用追踪 · 总纲
> 这是一个**持续更新**的追踪索引。每收录一个新项目，会先发一篇深度文，再回来回填这里。
> 所有数据来自 GitHub API 的定时快照，所有结论都标注了核实来源。
> 数据与脚本开源在 `gitinbox/agent-radar`。
---
## 这个系列在追什么
2026 年的 Agent 赛道，竞争焦点正在从"模型能力"转向"Harness / Agent Runtime 与执行工作流"。
Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出来单独发布——
**引擎层在碎片化，而使用引擎的人需要一个不随引擎漂移的落脚点。**
这个系列持续追踪全球 Agent 开源应用，回答三个问题：
1. 它到底站在 Agent 工具链的哪一层？
2. 它的宣称和实际状态之间，差多少？
3. 什么人该用它，什么人不该？
---
## 方法论
每个项目按**五个维度**建档，字段定义开源在 `schema/project.schema.yaml`：
| 维度 | 回答的问题 |
| --- | --- |
| 业务 | 它靠什么活着、为谁活着 |
| 场景 | 它在什么场合被用、产出什么 |
| 技术 | 它怎么做到的、抽象在哪一层 |
| 生态 | 它的社区动能（由脚本定时抓取，附带数据日期） |
| 风险 | 它的坑在哪、宣称与实测的落差 |
其中 **「宣称 vs 实测」是本系列最看重的一节**。
写它的时候我会专门去抓 README 里的限定词——`currently`、`today`、`in development`、`optional`——
这些词往往是落差的藏身处。项目方没说谎，但也没说全。
---
## 赛道坐标系
> Agent 工具大致分三层。判断一个项目，先判断它站在哪一层，以及它想往哪一层长。
```text
┌─────────────────────────────────────────────────────────────┐
│ 桌面工作台层 │
│ 跨引擎、跨项目、跨交付物的统一界面 │
│ 代表：iPolloWork │
├─────────────────────────────────────────────────────────────┤
│ 编辑器内 Agent 层 │
│ 嵌在 IDE / 编辑器里的交互层 │
│ 代表：Cline、Roo Code、Kilo Code │
├─────────────────────────────────────────────────────────────┤
│ 执行引擎层 │
│ 真正跑 agent loop 的地方 │
│ 代表：Codex、DeepSeek Harness、OpenCode、Gemini CLI │
└─────────────────────────────────────────────────────────────┘
```
越往上，离"模型"越远、离"交付物"越近，也越容易形成用户黏性——
但也越容易被下一层向上长出来的能力挤压。
---
<!-- MATRIX:BEGIN -->
### 业务维度
| 项目 | 定位 | 目标用户 | 变现 | 许可证 | 成色 |
| --- | --- | --- | --- | --- | --- |
| **iPolloWork** | 站在 Agent 工具链的**工作台层**而非引擎层：不替代 Codex / DSH / OpenCode 中任何一个，而是把它们收进同一个项目空间，并把交付物从代码延伸到文档、演示稿、网站、设计与视频 | 企业研发团队、需要人机协作的 agent 团队、需要产出并持续修改 PPT / 网页 / 设计 / 视频的内容团队 | 双轨：个人自用与少于 3 人的小规模内部使用免费；3 人及以上、以及任何售卖 / 转售 / 付费服务 / SaaS / 托管 / 白标 / 市场分发 / 面向客户的使用，均需书面授权。配套 iPolloCloud 承载身份、组织、权益与商业 App | iPolloWork Source Available License 1.0 | L3 |
### 场景维度
| 项目 | 交互形态 | 人机协作 | 交付物 |
| --- | --- | --- | --- |
| **iPolloWork** | desktop-app | approval-gated | code、doc、ppt、website、design、video |
### 技术维度
| 项目 | 形态 | 引擎抽象 | 接入深度 | 模型绑定 | 本地优先 |
| --- | --- | --- | --- | --- | --- |
| **iPolloWork** | Electron 桌面应用（另支持 dev:ui 只起浏览器 UI） | Engine Protocol（经 local API）；Codex 与 MCP 客户端另经 ipollowork-ui-mcp 控制面接入 | **三种引擎的接入深度并不对等**：OpenCode 是默认本地执行 runtime，走 local API → Engine Protocol 的原生 adapter，以独立 sidecar 形式存在（首次桌面构建时下载，不 fork、可独立升级）；DeepSeek Harness 是可选 peer runtime 与子代理委派目标，同样走 Engine Protocol；Codex 则**仅**通过 ipollowork-ui-mcp 的 MCP 控制面接入，README 明确写明 currently uses the MCP control surface rather than claiming a native Codex engine adapter | byom | 是 |
### 生态与风险
| 项目 | Star | Fork | Issues | 最新 release | 节奏 | 成熟度 | 数据日期 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| **iPolloWork** | 5201 | 976 | 80 | v0.50.12 | 一天多版 | beta | 2026-09-01 |
### 宣称 vs 实测
| 项目 | 宣称 | 实际 | 证据来源 |
| --- | --- | --- | --- |
| **iPolloWork** | 兼容 Codex、DeepSeek Harness、OpenCode 三大引擎 | 三者接入深度不对等。OpenCode 与 DSH 走 Engine Protocol 原生 adapter；Codex 只通过 ipollowork-ui-mcp 的 MCP 控制面接入，README 自己否认这是原生 Codex engine adapter | 仓库 README 的 Architecture boundary 一节原文 |
| **iPolloWork** | 集成 DeepSeek Harness 用于子代理委派 | 第三方插件目录标注为 integration in active development, not yet in the stable release；且 DSH 本身处于 developer preview 阶段。功能方向成立，但尚未进入稳定版 | deepseekharnessplugins.com 插件页；README 关于 DSH developer preview 的说明 |
| **iPolloWork** | 8 小时完成 Codex Harness 适配，登顶相关主题榜第一 | 响应速度属实且有第三方报道佐证，但「适配」指的是打通 MCP 控制面路径，不等于原生引擎级集成。快是因为走控制面，深度也受限于控制面 | ME News 报道；README 关于 Codex 接入方式的表述 |
| **iPolloWork** | 本地优先、不连云也能完整运行 | 这一点基本成立：iPolloCloud 明确为可选，负责身份、组织、权益、托管 worker 与商业 App。但默认本地 runtime 是 OpenCode sidecar，首次桌面构建时需联网下载，且开发模式与 Orchestrator sidecar 都由 iPolloWork 侧编排 | README 架构边界与安装章节 |
| **iPolloWork** | 统一的插件与 Skills 生态 | 统一的是**生命周期**（安装/启用/更新/卸载一次），不是能力本身。README 明确各 runtime 保留自己的 agents、Skills、插件与执行模型，引擎专属增强只是可选 | README 的 Agent runtime compatibility 一节 |
| **iPolloWork** | 仓库 topics 标注 claude-code | 中英文 README 均未描述任何 Claude Code 接入方式。topic 更像搜索曝光策略，不应视为已支持的能力 | GitHub topics 与 README 全文对照 |
| **iPolloWork** | 企业级（enterprise-grade） | 版本号仍在 0.50.x，无公开 Roadmap，发布节奏为一天多版，仓库体积 591 MB。工程投入可观，但版本语义上尚未到企业可用的稳定态 | GitHub releases；README 版本说明；仓库 size 字段 |
### 一句话结论
| 项目 | 结论 | 适合 | 不适合 |
| --- | --- | --- | --- |
| **iPolloWork** | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用 | 想在同一个界面管理多引擎项目、并希望 agent 产出的 PPT / 网页 / 设计 / 视频之后还能继续手工修改的个人开发者，或少于 3 人的极小团队 | 3 人以上需要正式落地的团队（许可证要求书面授权）、期待 Codex 原生级集成的用户（目前只有 MCP 控制面）、以及追求稳定的生产环境（v0.50.x、一天多版、DSH 集成未进稳定版） |
```text
┌─────────────────────────────────────────────────────────┐
│ 执行引擎层 （暂无收录）
│ └ 真正跑 agent loop 的地方
│ │
│ 编辑器内 Agent 层 （暂无收录）
│ └ 嵌在 IDE / 编辑器里的交互层
│ │
│ 桌面工作台层 iPolloWork★5201
│ └ 跨引擎、跨项目、跨交付物的统一界面
└─────────────────────────────────────────────────────────┘
```
> 当前收录 1 个项目，不足 4 个，此阶段只出分层图。样本够了之后会自动切换为象限图。
<!-- MATRIX:END -->
---
## 深度文索引
| 项目 | 一句话结论 | 文章 |
| --- | --- | --- |
| iPolloWork | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用 | 见同期发布的《iPolloWork 深度拆解》 |
---
## 收录标准
| status | 含义 |
| --- | --- |
| `active` | 有实际影响力，或技术路线有代表性，持续跟进 |
| `watch` | 早期项目，方向有意思但尚未验证 |
| `archived` | 停更 / 被收购 / 路线变更 |
不收录：纯模型权重、纯数据集、无公开代码的论文复现、营销型空壳仓库。
### 源码镜像的可见性规则
源码会镜像到 `gitinbox` 组织做代码级追踪，可见性**按许可证分级**，不做人工例外：
| 级 | 判定 | 镜像可见性 |
| --- | --- | --- |
| L1 | MIT / Apache-2.0 / BSD / ISC / GPL / MPL | 公开 |
| L2 | AGPL / SSPL / BUSL / Elastic-2.0 | 公开（标注限制） |
| L3 | 自定义 source-available（如 iPolloWork） | **私有** |
| L4 | 无 LICENSE / proprietary | 不镜像，仅存链接 |
L3 之所以必须私有：这类协议的条款通常明确要求「任何 SaaS / 托管 / 市场分发均需事先书面授权」，
公开镜像会落进这个解释空间里。替别人的源码做一次未经授权的公开分发，不值得。
---
<sub>本页由 `gitinbox/agent-radar` 的脚本自动生成与维护 · 数据快照为追加式时间序列，可回溯任意时点的指标</sub>
articles/00-overview.meta.yaml
+4
View File
@@ -0,0 +1,4 @@
# 总纲文发布元数据（由 scripts/publish_emlog.py 维护）
emlog_id: 98
url: "https://blog.apescale.com/?post=98"
last_published: "2026-09-01"
articles/ipollowork.md
+268
View File
@@ -0,0 +1,268 @@
# 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>