Files
agent-radar/articles/00-overview.md
T

162 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 全球智能体开源应用追踪 · 总纲
> 这是一个**持续更新**的追踪索引。每收录一个新项目,会先发一篇深度文,再回来回填这里。
> 所有数据来自 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>