11 KiB
11 KiB
全球智能体开源应用追踪 · 总纲
这是一个持续更新的追踪索引。每收录一个新项目，会先发一篇深度文，再回来回填这里。 所有数据来自 GitHub API 的定时快照，所有结论都标注了核实来源。 数据与脚本开源在
gitinbox/agent-radar。
这个系列在追什么
2026 年的 Agent 赛道，竞争焦点正在从"模型能力"转向"Harness / Agent Runtime 与执行工作流"。 Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出来单独发布—— 引擎层在碎片化，而使用引擎的人需要一个不随引擎漂移的落脚点。
这个系列持续追踪全球 Agent 开源应用，回答三个问题：
- 它到底站在 Agent 工具链的哪一层？
- 它的宣称和实际状态之间，差多少？
- 什么人该用它，什么人不该？
方法论
每个项目按五个维度建档，字段定义开源在 schema/project.schema.yaml：
| 维度 | 回答的问题 |
|---|---|
| 业务 | 它靠什么活着、为谁活着 |
| 场景 | 它在什么场合被用、产出什么 |
| 技术 | 它怎么做到的、抽象在哪一层 |
| 生态 | 它的社区动能（由脚本定时抓取，附带数据日期） |
| 风险 | 它的坑在哪、宣称与实测的落差 |
其中 「宣称 vs 实测」是本系列最看重的一节。
写它的时候我会专门去抓 README 里的限定词——currently、today、in development、optional——
这些词往往是落差的藏身处。项目方没说谎，但也没说全。
赛道坐标系
Agent 工具大致分三层。判断一个项目，先判断它站在哪一层，以及它想往哪一层长。
┌─────────────────────────────────────────────────────────────┐
│ 桌面工作台层 │
│ 跨引擎、跨项目、跨交付物的统一界面 │
│ 代表：iPolloWork │
├─────────────────────────────────────────────────────────────┤
│ 编辑器内 Agent 层 │
│ 嵌在 IDE / 编辑器里的交互层 │
│ 代表：Cline、Roo Code、Kilo Code │
├─────────────────────────────────────────────────────────────┤
│ 执行引擎层 │
│ 真正跑 agent loop 的地方 │
│ 代表：Codex、DeepSeek Harness、OpenCode、Gemini CLI │
└─────────────────────────────────────────────────────────────┘
越往上，离"模型"越远、离"交付物"越近，也越容易形成用户黏性—— 但也越容易被下一层向上长出来的能力挤压。
业务维度
| 项目 | 定位 | 目标用户 | 变现 | 许可证 | 成色 |
|---|---|---|---|---|---|
| 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 集成未进稳定版） |
┌─────────────────────────────────────────────────────────┐
│ 执行引擎层 （暂无收录）
│ └ 真正跑 agent loop 的地方
│ │
│ 编辑器内 Agent 层 （暂无收录）
│ └ 嵌在 IDE / 编辑器里的交互层
│ │
│ 桌面工作台层 iPolloWork★5201
│ └ 跨引擎、跨项目、跨交付物的统一界面
└─────────────────────────────────────────────────────────┘
当前收录 1 个项目，不足 4 个，此阶段只出分层图。样本够了之后会自动切换为象限图。
深度文索引
| 项目 | 一句话结论 | 文章 |
|---|---|---|
| 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 / 托管 / 市场分发均需事先书面授权」， 公开镜像会落进这个解释空间里。替别人的源码做一次未经授权的公开分发，不值得。
本页由 gitinbox/agent-radar 的脚本自动生成与维护 · 数据快照为追加式时间序列，可回溯任意时点的指标