agent-radar/articles/00-overview.md

全球智能体开源应用追踪 · 总纲

这是一个持续更新的追踪索引。每收录一个新项目会先建档，够一批样本就发一篇横向对比， 再按价值排序补单项目深度文——所以索引里「待发布」是常态，不是遗漏。 所有数据来自 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 工具大致分三层。判断一个项目，先判断它站在哪一层，以及它想往哪一层长。

┌─────────────────────────────────────────────────────────────┐
│  桌面工作台层                                                 │
│  跨引擎、跨项目、跨交付物的统一界面                            │
│  代表：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
maka	站在「执行记录层」：不追功能广度，把「agent 干过什么必须可复现、 可审计、可评测」做成地基。同时是四个里唯一自带评测框架的项目。	对可审计性与数据主权有硬要求的团队、需要横向评测不同 agent / 模型的研究者与工程团队、愿意用功能丰富度换确定性的自用开发者	无。Apache 孵化项目，无商业实体、无双许可、无付费层。	Apache License 2.0	L1
openwork	站在「能力分发层」，不争桌面入口。核心资产是 OpenWork MCP 与 Den 控制面—— 把 skills / MCP / 连接服务做成可跨工具、跨人、跨机器复用的组织级能力包。	已在使用 Codex / Claude Code / Cursor 且不想换工具的开发者、需要统一管控 agent 能力的中大型组织、想把自己搭好的工作流分发给同事或朋友的团队	Den 订阅（组织控制面）。免费额度写得很明确： 5 人以下组织的非 Enterprise 功能全免、任意规模 30 天评估、开发测试永久免费。	目录切分许可（GitLab 式）：ee/ 之外为 MIT；ee/ 为 OpenWork EE License	L3
orca	站在「执行编排层」：不造引擎、不卖模型，只做并行 agent 的调度与可观测外壳。 上游是各家 CLI agent，下游是开发者的本机/远程 worktree。	自称 100x builders 的重度个人开发者、需要同时试多种实现方案再择优合并的小团队、已在用 Codex / Claude Code / OpenCode 并想并行跑的人	未明示，且这是它最大的商业不确定性。MIT 全开源、无企业版、无订阅层， README 明确不提供模型也不代买订阅。收入路径尚未公开。	MIT License	L1

场景维度

项目	交互形态	人机协作	交付物
iPolloWork	desktop-app	approval-gated	code、doc、ppt、website、design、video
maka	桌面应用、TUI / CLI、评测框架	强：工具越过沙箱边界必须审批；运行可中止；失败被分类。	code、artifact、eval-report、execution-record
openwork	MCP 远程服务、桌面应用（可选）、浏览器登录授权	能力调用需人工在浏览器登录并选择组织；企业侧由管理员通过策略管控。	workflow、skill-package、capability
orca	桌面应用、移动端伴随、CLI、SSH 远程	强人在环：需人工比并结果、批注 diff、批准合并。 但 5000 个自开 issue 说明产品自身也在被 AI 自动改进。	code、diff、review-comment

技术维度

项目	形态	引擎抽象	接入深度	模型绑定	本地优先
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	是
maka	桌面应用 + TUI/CLI + 评测框架，三者共用同一 Runtime Host	Runtime Host（单一所有者的生命周期 + 协议 + 客户端引导）	与另外三家正好相反：Maka 对自己的引擎深度是满分 （一个 Runtime Host 统管所有入口），对外部引擎深度是零 （只在 eval 里当被测对象）。 它压根不参与「多引擎中立」这条赛道的竞争——这是定位选择而非能力缺陷， 但读者必须知道它和 Orca / OpenWork / iPolloWork 不是同一类选手。	完全 BYO：云 API、本地模型或兼容网关， 不捆绑任何共享账号（README 明确 "You bring the model"）。	是
openwork	MCP 远程服务 + 可选桌面应用 + Web 控制面	OpenWork MCP（能力面，不是执行面）	接入「对等且都浅」：所有引擎都以同一个 MCP 客户端身份接入， 拿到的是能力调用，不是执行控制——OpenWork 不接管 agent 的执行循环、 不负责上下文管理、不做权限回调。 真正深度绑定的是 OpenCode：仓库描述即写 powered by opencode， 桌面端属 OpenCode 生态，其余引擎只是 MCP 外挂。 这与 iPolloWork 的「Codex 仅 MCP 控制面」是同一个问题的两种解法： iPolloWork 把 MCP 当补丁（主体是桌面），OpenWork 把 MCP 当主体（桌面是可选）。	Den 侧可统一配置与配额控制 model provider；桌面 app 本身 BYO	是
orca	桌面应用（含移动端伴随 + CLI）	无统一抽象层；实际是终端 PTY + 约定式输出解析	接入深度「完全对等，但对等在低处」：30+ 引擎共享同一套 PTY 外壳， 因此没有任何一家能拿到原生能力——拿不到结构化 tool call、 拿不到统一权限回调、拿不到一致口径的 token 统计。 广度最大，深度最浅。对照 iPolloWork 为 OpenCode 做的原生 Engine Protocol adapter，Orca 与任一单引擎的耦合都明显更浅。	完全 BYO——用户自带各 agent 的订阅与额度	是

生态与风险

项目	Star	Fork	Issues	最新 release	节奏	成熟度	数据日期
iPolloWork	5201	976	80	v0.50.12	一天多版	beta	2026-09-01
maka	4373	406	398	v0.2.0-dev.9.20260831	一天多版	孵化期	2026-09-01
openwork	23253	2307	414	v0.18.40	约 1 天/版本	0.x 活跃	2026-09-01
orca	58771	3987	5000	v1.4.194	约 1 天/版本	原型期	2026-09-01

成熟度详解

• iPolloWork：beta
• maka：治理成熟度最高（ASF 流程 + 评测框架 + 文档契约）， 产品成熟度最低（无正式 release、平台只支持 arm64 macOS、功能默认保守）。 属于「地基打得最实，房子盖得最慢」。
• openwork：工程成熟度最高：有可执行测试规格（evals/）、声明式环境（worlds/）、 明确的贡献契约与许可边界。但仍处 0.x 主版本（v0.18.40）， API 与数据格式可能变动。
• orca：功能广度第一，工程治理末位。一天多版（v1.4.194）说明迭代极快， 但 issue 只进不出、巴士系数为 1，属于「高速原型期」而非「可托付生产期」。

宣称 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 字段
maka	Apache 品牌 = 成熟稳定、可用于生产	孵化状态恰恰是「尚未被 ASF 完全背书」的标记，README 自带官方免责声明。 且截至 2026-09-01 没有任何 Apache 正式 release， 对外分发的只有 Desktop Nightly，README 明确标注 「not an ASF release, not intended for production use」。 平台支持也最窄：macOS arm64 是唯一正式档， Windows 为未签名预览，Linux 标注 soon。	README 的 NOTE / IMPORTANT 段、Releases and downloads 段、平台 badge
maka	「Your machine, your data」本地优先、数据主权	数据确实不出机器，但 API key 以明文文件存放—— README 原文承认 credential-vault.json 是 「local plaintext file, readable only by your OS account」。 防护依赖操作系统账户权限，而非加密或系统钥匙串。 renderer 进程拿不到，但同机任一以你身份运行的进程都能读到。	README「Local data and recovery」段
maka	崩溃恢复与可选续跑	续跑默认关闭，需手动设 MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1， 且 README 明确警告该调用会打模型、消耗 token。 另存在升级断代：旧版 JSONL transcripts 与 Electron safeStorage 凭据不会被导入，升级后的工作区可能出现空线程，凭据必须重新录入。	README「Local data and recovery」段
maka	（无明确宣称，但易被期待为开箱即用的完整工作台）	内置工具只有 Read / Write / Edit / Bash / Glob / Grep 六个； Computer Use 与 catalog skills 属可选且默认关闭； IM bot（聊天应用接入）标注 experimental。 功能面是四个里最保守的——取舍很明确：用广度换确定性。	README「Current capabilities」段
maka	支持 Graph 多算子并行	Graph 的实现算子跑在独立 git worktree，且要求源项目是干净 worktree—— 有未提交改动就用不了。相比 Orca 的并行 worktree（产品级封装）， Maka 的 Graph 更接近实验性能力。	README「Terminal entry points」段
openwork	「Claude Cowork 的开源替代品」	形态完全不同。Cowork 是桌面操控型 agent（直接操作你的电脑完成工作）； OpenWork 是能力分发型 MCP 层，桌面 app 被明确定位为可选—— README 原文「The desktop app is there when you want a dedicated workspace, but it is not required」。 它替代的是 Cowork 唤起的「能力复用」诉求，不是 Cowork 本身。	README 开篇与「Use OpenWork from any agent」段
openwork	跨 Codex / Claude Code / Cursor / OpenCode 多引擎通用	对 OpenCode 是原生的（仓库描述 powered by opencode，桌面端属其生态）； 对其余引擎只通过自己暴露的两个 MCP 工具对接。 这是能力调用面，不是引擎执行面——OpenWork 不接管这些引擎的执行循环、 上下文与权限。对外宣称的「跨引擎」与内部实际的主从关系存在落差。	README「It exposes two tools」段；仓库 description「powered by opencode」
openwork	free, open-source（免费开源）	需要分目录看：ee/ 之外确实 MIT 且免费；但 ee/（Den 组织控制面、 MCP 网关、推理）属 source-available，生产使用需付费订阅， 只有 5 人以下组织、30 天评估、开发测试三种情形豁免。 个人免费，团队与企业要付费。	README Licensing 段 + ee/LICENSE 原文 72 行
openwork	（无明确宣称，但 SPDX 为 NOASSERTION，易被误读为「不够开源」）	恰恰相反——它是四个项目里工程治理最规范的：强制 DCO sign-off、 ee/ 需额外 CLA、evals/ 目录放可执行测试规格并要求 PR 附测试证据、 worlds/ 放声明式的开发与测试环境定义。 NOASSERTION 只因根目录 LICENSE 是混合声明文件，不代表开放度低。	README「Getting started (contributors)」与「Sending a pull request」段
orca	5000 个 open issue 反映社区问题积压与项目质量压力	抽样最近 100 条：全部创建于 2026-09-01 同一天，94% 无任何标签， 标题为 fix(ssh) / refactor / fix(task-page) 等内部任务口吻； 提交者 TOP3 为 nwparker(51)、OrcaWin(13)、klaidliadon(12)。 实为「团队自开的任务待办板」，且带明显 AI 批量生成痕迹 （如 OrcaWin 提交的「pty.spawn can leak a running agent process unboundedly: host holds the door open」）。 它不是社区投诉，也不构成 triage 压力——但同样说明这 5000 条 从未被当作对外承诺来管理。	GitHub API /repos/stablyai/orca/issues?state=open，2026-09-01 抽样 100 条
orca	「100x builders 的 AI Orchestrator」，面向多人协作的成熟开发环境	巴士系数为 1：最近 100 次提交中 nwparker 独占 79 次， 第二名 AmethystLiang 仅 9 次。功能面由单人 + AI 高强度驱动， 而非团队协作成果。	GitHub API /repos/stablyai/orca/commits?per_page=100，2026-09-01
orca	支持 30+ 种 agent，生态最开放	兼容判据是「能在终端里跑」，靠 PTY 拉起而非协议对接。 广度最大但深度最浅——所有引擎都拿不到结构化 tool call 与统一的权限回调。与 iPolloWork 为 OpenCode 做原生 Engine Protocol adapter 相比，Orca 与任一单引擎的耦合都更浅。	README「Works with any CLI agent — if it runs in a terminal, it runs in Orca」
orca	MIT 全开源，可放心用于生产	许可证本身无风险，但项目没有任何公开的营收路径 （无企业版、无订阅、不卖模型、不代买订阅）。 58k star 的体量与零商业化不匹配，属于「要么即将融资、 要么后续变更条款」的不稳定态。	README License 段；README 明确「Orca does not provide models, nor does it buy subscriptions for you」
orca	桌面 / 移动 / VPS 全覆盖	三端成熟度不对等：Android 仍是手工分发 APK（0.0.47）、 iOS 走 App Store 与 TestFlight、VPS 场景需另查 headless Linux 指南。 移动端实际是「监控与追加指令」的伴随形态，不是完整工作环境。	README Install 段与 Mobile Companion 段

一句话结论

项目	结论	适合	不适合
iPolloWork	把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用	想在同一个界面管理多引擎项目、并希望 agent 产出的 PPT / 网页 / 设计 / 视频之后还能继续手工修改的个人开发者，或少于 3 人的极小团队	3 人以上需要正式落地的团队（许可证要求书面授权）、期待 Codex 原生级集成的用户（目前只有 MCP 控制面）、以及追求稳定的生产环境（v0.50.x、一天多版、DSH 集成未进稳定版）
maka	四个里唯一把「执行记录」当地基的项目——治理与可复现性最强，产品成熟度最弱。	对审计、数据主权、可复现评测有硬要求的团队； 做 agent 横向对比研究的工程团队。	要开箱即用、要 Windows / Linux、要丰富第三方集成的人； 以为 ASF 品牌等于生产可用的决策者。
openwork	把「能力」而不是「桌面」做成产品——工程治理最好的一个，但它和自称要替代的东西不是一个物种。	已固定在某款 agent 上、只想让团队能力跨工具复用的开发者； 需要统一管控 agent 能力与模型配额的组织 IT。	想要一个开箱即用的桌面 agent 工作台的人； 以为拿到的是完整 Cowork 平替的人。
orca	兼容面最广的并行 agent 编排外壳——广度做到极致，深度与治理都还是草稿。	已在重度使用 CLI agent、想同时跑多个方案横向比对的个人开发者与小团队。	需要稳定 SLA、指望社区 triage 与多人维护保障的团队； 指望它统一各引擎能力（结构化调用、统一权限、一致口径）的架构选型者。

---

文章索引

这一段由 scripts/build_matrix.py 从项目档案的 article 块与 articles/*.meta.yaml 自动生成。发新文后重跑脚本即可，不要手工改。

项目	一句话结论	深度文
iPolloWork	把多个 Agent 引擎收进同一个可编辑工作台的野心之作	已发布
maka	四个里唯一把「执行记录」当地基的项目	待发布（见下方横评）
openwork	把「能力」而不是「桌面」做成产品	待发布（见下方横评）
orca	兼容面最广的并行 agent 编排外壳	待发布（见下方横评）

跨项目文章

• 四个 Agent 工作台的路线分野：把「多引擎中立」拆开看 — 2026-09-01

待补深度文：maka、openwork、orca。当前可先读上方跨项目文章，其中已包含这些项目的完整分维度对比。

---

收录标准

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 的脚本自动生成与维护 · 数据快照为追加式时间序列，可回溯任意时点的指标}