全球智能体开源应用追踪

这是一个持续更新的追踪索引。每收录一个新项目会先建档，够一批样本就发一篇横向对比，再按价值排序补单项目深度文——所以索引里「待发布」是常态，不是遗漏。所有数据来自 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
maka	站在「执行记录层」：不追功能广度，把「agent 干过什么必须可复现、可审计、可评测」做成地基。同时是唯一自带评测框架的项目。	对可审计性与数据主权有硬要求的团队、需要横向评测不同 agent / 模型的研究者与工程团队、愿意用功能丰富度换确定性的自用开发者	无。Apache 孵化项目，无商业实体、无双许可、无付费层。	Apache License 2.0	L1
OpenClaw	站在「个人助理执行层」，而且是唯一一个不面向开发者的样本。它不接入别的 agent，自己就是 agent；不产出代码交付物，产出的是"事儿办完了"—— 邮件发了、日程改了、值机办了。入口是用户已经在用的聊天软件，不是 IDE 也不是桌面工作台。这一条把它和本体系其余 6 个样本彻底分开：它们的用户是开发者，OpenClaw 的用户是普通人。	想让 AI 接管日常事务（收件箱、日历、出行）的非技术用户、重度聊天软件用户（WhatsApp / Telegram / iMessage / Signal）、想在自己机器上跑私人助理、拒绝 SaaS 托管的数据敏感用户	免费开源 + 赞助（README 有 Sponsors 段）。创始人 2026-02 加入 OpenAI 后， OpenAI 承诺在保持 MIT 的前提下继续赞助，项目转由独立基金会运营。目前看不到收费层。	MIT（SPDX 误判，人工复核确认）	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
QwenPaw	与 OpenClaw 同处「个人助理执行层」，是本项目在本体系中唯一的正面对手。但立足点不同：OpenClaw 靠渠道覆盖与生态规模取胜，QwenPaw 靠安全默认值与本地可跑取胜。它把自己定位成"能长期记住你、数据不离开你机器的私人助理"，而不是功能最全的助理。团队背景决定了差异化：背靠 AgentScope（AgentScope / AgentScope Runtime / ReMe），记忆系统直接建在 ReMe 个人知识框架上。	对数据主权与隐私有硬要求、希望助理完全跑在本地的个人用户、需要在钉钉 / 飞书 / 微信 / QQ 等国内渠道里用助理的团队、想不买 API key 就先跑起来的尝鲜用户（QwenPaw-Flash 本地模型）、愿意用功能广度换安全确定性的自用开发者	Apache-2.0 全开源，未见收费层；提供 Docker / 阿里云 ECS / AgentScope 平台 / ModelScope 创空间等多条部署路径（云部署路径隐含云厂商导流）。与 OpenClaw 一样没有明示的变现路径。	Apache License 2.0	L1
Tutti	站在「多人 × 多 Agent 的实时协作空间层」，是七个样本里唯一把"多人"写进定位的。它不造引擎、不卖模型，做的是"让你已有的 agent 订阅在同一个工作区里协同"： Claude 写了一半的活儿交给 Codex 接着干，中间不用重新讲一遍背景。但它的商业模式是清晰的 open-core：开源版只给"单人 + 多 Agent"， "多人 + 多设备 + 云同步"全在闭源的 Tutti · VM 侧（Early Access，需邀请码）。	同时用多个 agent 订阅（Claude Code + Codex + Hermes）的重度开发者、需要 agent 之间共享上下文、接力同一件事的小团队、想让 agent 产出不止代码（设计稿 / 文档 / PPT）的人、需要多人 × 多 Agent 同屏协作的团队（但这类需求会被引流到闭源 VM 版）	Open-core 双轨：开源版（Apache-2.0）免费且自托管；Tutti · VM 为 Early Access 商业版，需邀请码创建 Cloud Room。Tutti 内置 Agent 在 Early Access 期免费， README 明示"后续可能按用量计费"。这是七个样本里变现路径最清晰的一个。	Apache License 2.0	L1

场景维度

项目	交互形态	人机协作	交付物
iPolloWork	desktop-app	approval-gated	code、doc、ppt、website、design、video
maka	桌面应用、TUI / CLI、评测框架	强：工具越过沙箱边界必须审批；运行可中止；失败被分类。	code、artifact、eval-report、execution-record
OpenClaw	聊天软件频道（主要入口）、本地守护进程 Gateway（控制面）、Web Control UI / CLI / TUI、桌面与移动端伴侣 App（macOS / Windows / iOS / Android）	配对审批：支持 DM 的频道默认会配对未知发送者，需人工 `openclaw pairing approve` 确认。 2.0 新增私密凭据请求（遮罩输入，敏感信息不进聊天记录与模型上下文）与插件安装前能力展示。	事务结果（邮件 / 日程 / 预订 / 消息）——不是文件型交付物、文件与本地系统操作、Canvas / 语音 / 图像（伴侣 App 侧）
openwork	MCP 远程服务、桌面应用（可选）、浏览器登录授权	能力调用需人工在浏览器登录并选择组织；企业侧由管理员通过策略管控。	workflow、skill-package、capability
orca	桌面应用、移动端伴随、CLI、SSH 远程	强人在环：需人工比并结果、批注 diff、批准合并。但 5000 个自开 issue 说明产品自身也在被 AI 自动改进。	code、diff、review-comment
QwenPaw	Web 控制台（默认 127.0.0.1:8088）、Terminal UI（TUI）、IM 渠道（钉钉 / 飞书 / 微信 / QQ / Discord / Telegram / iMessage）、桌面应用（Beta）	Access Policy 是声明式访问规则，可对每次能力调用设置放行 / 拒绝 / 请求人工批准，粒度到工具级、可按来源匹配。Tool Guard 提供 STRICT / SMART / AUTO / OFF 四档。	code（Coding Mode 三栏 IDE）、文档处理结果（PDF / Word / Excel / PowerPoint）、记忆条目（可读可编辑可搜索的 Markdown 记忆）、定时推送内容（资讯摘要 / 视频脚本）
Tutti	桌面应用（Electron）、TUI / CLI（Go）、Workbench 节点（Browser / Terminal / App Center）、【闭源 VM】Cloud Room 多人多设备	Agent Board 可视化所有 agent 的任务与状态，统一调度；goal review / plan feedback （Tutti Mode 执行）。活动复制与状态探针（agentstatus + account-usage）提供过程可见性。	code、设计稿（AI Canvas / UI-UX 原型）、文档 / PPT（Docs / AI PPT 内置 App）、会话回放（session-replay）

技术维度

项目	形态	引擎抽象	接入深度	模型绑定	本地优先
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"）。	是
OpenClaw	本地守护进程（Gateway）为控制面 + 多渠道接入。注意它没有 IDE 形态，也不是传统意义的桌面工作台——Control UI 只是 Gateway 的一个 Web 前端。	无（自身即引擎）	把 OpenClaw 和"多引擎中立"放在一起比较会得出误导性结论。横向对比时应把它的引擎立场标记为「自身即引擎」而非「绑定单引擎」，两者在用户侧的风险完全不同：绑定单引擎是"换不了"，自身即引擎是"不用换"。	不绑定：支持 hosted 与 local model providers。2.0 默认 GPT-5.6，本地模型方面把 node-llama-cpp 换成托管 llama-server，默认上下文提到 64K。	是
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 的订阅与额度	是
QwenPaw	Python 包（pip / 安装脚本）+ Web 控制台 + TUI + 桌面应用（Beta）+ Docker。形态偏"服务端 + 多渠道"，与 OpenClaw 的"本地守护进程 Gateway"思路接近，但更传统——没有 OpenClaw 那套原生伴侣 App 与设备节点。	无（自身即引擎）；模型层有统一 provider 抽象	注意区分两个"中立"：模型层是真中立（14+ provider 可换）， agent 引擎层不存在中立问题（它自己就是）。横向比较时不要混为一谈。	不绑定。本地侧主推自研 QwenPaw-Flash（2B / 4B / 9B，Q4 / Q8 量化， ModelScope 与 Hugging Face 可下载），云侧 14+ provider。 "无需 API key 即可跑"是它相对所有竞品的硬差异。	是
Tutti	pnpm + Go Workspace 混合 monorepo；桌面端 Electron；守护进程 tuttid（Go）； CLI（Go）；Agent 运行时基于 ACP（Agent Client Protocol） + uv / npm / pnpm 托管运行时。语言构成 TypeScript 48.8% / Go 45.4% —— 后端用 Go 而不是 Node，这是它和其余 Electron 系样本的关键差异（守护进程的稳定性与并发模型更好）。	ACP（Agent Client Protocol）+ runtimeprep 准备层	⚠️ 接入深度极不对等，实测数据如下（packages/agent/runtimeprep/，非测试行数）： Codex 16 文件 2170 行 ← 一国独大 Tutti 内置 2 文件 653 行 Cursor 2 文件 446 行 Claude 3 文件 410 行 OpenCode 2 文件 392 行 Kimi 1 文件 127 行 ComputerUse 1 文件 43 行 BrowserUse 1 文件 43 行 Codex 是 Kimi 的 17 倍。且只有 Codex 有 Windows 变体文件（codex_directory_windows.go 149 行、codex_file_windows.go、 codex_models_cache_windows.go 等 4 个），其余引擎一个 Windows 变体都没有 ——说明只有 Codex 在 Windows 上被真正验证过。更有意思的是测试密度与实现规模成反比： OpenCode 392 行实现 / 218 行测试 = 0.56（密度最高） Cursor 446 / 187 = 0.42 Tutti 内置 653 / 274 = 0.42 Claude 410 / 136 = 0.33 Codex 2170 / 261 = 0.12（投入最大，保障最薄） Kimi 127 / 0 = 0.00 ComputerUse / BrowserUse 43 / 0 = 0.00 即：投入最重的 Codex 恰恰是质量保障最薄弱的地方，因为它的边界情况最多（Windows 兼容、模型缓存、配置依赖、skill roots、用户指令），测试却没跟上。另有 19 个通用测试文件共 7851 行（preparer_test.go 单文件 2906 行）覆盖跨引擎路径，部分弥补了单引擎测试的缺失。	不绑定模型，但绑定 agent 订阅：README 明确"用你已有的 Claude / Codex / 其他订阅"。没有订阅的用户可用 Tutti 内置 Agent（Early Access 期免费）。	是

生态与风险

项目	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
OpenClaw	388438	81543	5925	v2026.8.1	约 4 天/版本	高速迭代期	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
QwenPaw	34758	3052	898	v2.2.0-beta.5	约 1 天/版本	beta 活跃期	2026-09-01
Tutti	3660	371	185	stable	约 3 天/版本	快速成长期	2026-09-01

成熟度详解

iPolloWork：beta
maka：治理成熟度最高（ASF 流程 + 评测框架 + 文档契约），产品成熟度最低（无正式 release、平台只支持 arm64 macOS、功能默认保守）。属于「地基打得最实，房子盖得最慢」。
OpenClaw：功能面极广、迭代极快（10 个月 237 次版本迭代），但版本号体系失序、安全默认值偏松、巴士系数接近 1。适合愿意自己加固环境并接受高频变更的个人，不适合需要可预测升级路径与稳定 SLA 的团队——尤其考虑到 2.0 自己都承认 "从 v2026.7.1 及更早版本升级时可能破坏原有 Agent 配置"，官方建议升级前先备份。
openwork：工程成熟度最高：有可执行测试规格（evals/）、声明式环境（worlds/）、明确的贡献契约与许可边界。但仍处 0.x 主版本（v0.18.40）， API 与数据格式可能变动。
orca：功能广度第一，工程治理末位。一天多版（v1.4.194）说明迭代极快，但 issue 只进不出、巴士系数为 1，属于「高速原型期」而非「可托付生产期」。
QwenPaw：工程治理（巴士系数最健康、安全分层最完整）明显强于它的星标邻居们，但发布纪律是短板——所有 release 都是 beta，且一天能发多个 beta。功能面广、迭代快，适合自用与尝鲜；不适合作为团队关键链路的基础设施。
Tutti：建仓仅 2.5 个月，处在快速成长期。发布纪律是七个样本里最好的（全部正式版 + stable 滚动 tag），工程规范度高（NOTICE 精确到 revision hash、通用测试 7851 行、 Go 守护进程），但引擎接入深度严重向 Codex 倾斜、开源版功能完整度约一半。适合自用与"多 agent 接力"场景，不适合指望开源版承担团队协同。

宣称 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」段
OpenClaw	停更 7 周（多家媒体转述，指 7 月中旬 v2026.7.1 之后断更）	失真。查 release 时间轴：7-18 → 7-28 → 8-01 → 8-02 → 8-04 → 8-08 → 8-15 → 8-24 → 8-28 → 8-31 一直在发。停的是稳定版，beta 从未停。但真实问题比"停更"更值得警惕：版本号体系已经乱到无法从版本号判断新旧—— 8-28 发的 v2026.9.1-beta.1 早于 8-31 的正式版 v2026.8.1；而 v2026.6.33 / v2026.6.34（8-08）又晚于 v2026.7.1-1 / -2（8-04）。多线并行导致版本号与实际时间顺序倒挂。	GitHub releases API（2026-09-01 取最近 12 个 release 的 published_at）
OpenClaw	3001 名贡献者 / 933 人共建 2.0（项目方与媒体反复引用）	数字属实，但不能推导出"去中心化"。抽样最近 100 次提交：创始人 steipete 独占 64 次（64%），第二名 vincentkoc 仅 4 次，去重作者 27 人。巴士系数接近 1 —— 贡献者基数和实际决策集中度是两回事。	GitHub commits API（2026-09-01 取 main 分支最近 100 次提交的 author.login 分布）
OpenClaw	PR 已经泛化成 Prompt Requests，AI 批量灌水（多家媒体报道）	我抽样最新 60 条 open PR，不支持这个说法：标题全部是规范的 conventional commits（fix(memory-core)、refactor(sessions)、perf(media)），去重 22 位作者，未见灌水特征。但另一组数字确实异常：60 条全部创建于 2026-09-01 同一天，说明日 PR 量超过 60 条——流量压力真实存在，只是"质量崩坏"缺乏证据。媒体报道的"必须附对话记录/截图/测试证据才能过审"是维护方的应对动作，从这批样本看，它似乎有效。	GitHub pulls API（state=open, sort=created, direction=desc, per_page=60）
OpenClaw	跑在你自己的设备上、own your data	前半句属实（Gateway 是本地控制面，支持本地模型）。但安全默认值偏松：README 原文承认工具默认跑在宿主机上、除非你配置沙箱；支持 DM 的频道默认配对未知发送者（需人工 approve）。历史上出过 CVE-2026-25253（CVSS 8.8）：访问一个恶意页面即可窃取令牌、禁用沙箱、在宿主机执行任意代码。"本地运行"不等于"默认安全"。	README Security 章节原文；CVE-2026-25253（媒体报道，CVSS 8.8）
OpenClaw	MIT 开源	属实，但机器读不出来。GitHub 的 licensee 因为 LICENSE 末尾多了一段第三方声明指引（THIRD_PARTY_NOTICES.md）而判定 NOASSERTION。自动定级会给出 L3/private 的错误结论，必须人工读 LICENSE 原文才能纠正。（本体系第二次遇到这类误判，前一次是 OpenWork 的目录切分许可。）	GitHub license API 取原始文件，人工阅读全文 1170 字节
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 段
QwenPaw	数据归你、本地优先、不上传任何本地使用记录	主力诉求成立（本地模型可完全离线跑，遥测一键可关）。但 README 的 Telemetry 章节写明：`qwenpaw init --defaults` 会自动接受遥测，且"每升级一个版本会重新收集一次"。而 `--defaults` 恰恰是快速上手文档推荐的默认路径。收集的是匿名环境数据、不影响功能，但"默认接受" 与"数据归你"的叙事存在张力——尤其对把隐私当核心卖点的产品。	README Telemetry 章节原文（'If you choose --defaults, telemetry is accepted automatically.'）
QwenPaw	34.7k star 的成熟个人助理	星标属实，但至今没有任何正式 release。查最近 8 个 release， v2.1.1-beta.1 到 v2.2.0-beta.5 全部 prerelease=True。也就是说它处在"高关注度 + 持续 beta"状态，与同赛道 OpenClaw （有 v2026.8.1 正式版）相比，发布纪律反而更松。	GitHub releases API（per_page=8，全部返回 prerelease=true）
QwenPaw	五层安全，内核级沙箱	五层的实现描述相当具体（Seatbelt / Bubblewrap+Landlock / AppContainer， ShellEvasionGuardian 检测命令注入与反弹 shell），可信度高。但 Tool Guard 提供 OFF 档，整层可以关掉；Access Policy 也是"可配置为放行"。安全强度取决于用户配置，不是不可绕过的硬边界。	README Security Features 章节（列出 Tool Guard 的 STRICT / SMART / AUTO / OFF 四档）
QwenPaw	无需 API key，本地模型即可跑	技术上成立：QwenPaw-Flash 2B / 4B / 9B（Q4 / Q8 量化）内置 llama.cpp 后端，在 Web UI 点下载即可用，并提供硬件感知推荐。但要清醒：2B / 4B 量级的模型在复杂 agent 任务上的能力天花板很低， "无需 key 跑起来"和"无需 key 好用"是两件事，重度任务仍要接云端 provider。	README Local Models 章节（列出 2B/4B/9B 与 Q4/Q8 量化）
QwenPaw	（历史）QwenPaw 是一个 2026 年 4 月后出现的全新项目	不是。它是 2026-02-24 以 CoPaw 之名建仓的项目，2026-04-12 才更名。检索 2026 年 4 月之前的社区讨论、issue 与技术文章时必须按 CoPaw 检索，否则会严重低估它的历史沉淀与已知问题。	GitHub repo API（created_at=2026-02-24）+ README News 章节的更名公告
QwenPaw	（检索风险）github.com/agentscope-ai/QwenPaw 是唯一官方仓库	存在同名仓库 `aqua88hn/qwenpaw`，README 内容与官方高度相似。以 star 数（官方 34.7k）与组织归属判断，官方仓库在 agentscope-ai 组织下；但同名仓库的存在会让"按名字搜仓库"直接得到错误结果。	GitHub 搜索结果与 repo API 交叉核对（agentscope-ai/QwenPaw = 34758 star，非 fork）
Tutti	（README）Currently Claude Code, Codex, and Hermes；OpenClaw is in development	README 与代码对不上，两个方向都偏。宣称"当前支持"的 Hermes，在 runtimeprep 里没有 hermes.go —— 它走的是 extension_runtime.go 的 RTK Python 插件机制（provider 标识 `acp:hermes`，用 Python 插件重写命令），只有测试文件 hermes_test.go(580) 与 hermes_verify_test.go(77)，没有原生 adapter。宣称"in development"的 OpenClaw，确实只有 acp_provider_openclaw.go 52 行、零测试（对比 OpenCode 的 301 行 + 540 行测试）—— README 这处倒是诚实的。反过来，Cursor / OpenCode / Kimi / ComputerUse / BrowserUse 在代码里都有完整实现，README 的支持列表却一个字没提。结论：README 的支持列表更像"营销优先级排序"，不是代码覆盖的如实反映。	本地源码实测：runtimeprep 目录文件清单 + daemon/runtime/acp_provider_*.go 行数 + grep hermes 引用
Tutti	多引擎中立	协议层中立（都走 ACP），深度层远不中立。Codex 2170 行 vs Kimi 127 行， 17 倍差距；只有 Codex 有 Windows 变体，其余引擎在 Windows 上未验证。而且测试密度反常：Codex 0.12（最低）vs OpenCode 0.56（最高）， Kimi / ComputerUse / BrowserUse 测试为零。所谓"中立"是接入方式的中立，不是投入与保障的中立。	本地源码 wc -l 实测（实现文件与测试文件分别统计）
Tutti	Where people and agents build in tune（多人 × 多 Agent）	开源版里只有 "agents"，"people" 那部分在闭源侧。README 的 Two Versions 对照表明确：Group chat / Work with others / Work with others' agents / Simultaneous editing / Agent borrowing / Across devices / No-deploy sharing —— 七项全部是 VM 版专属，开源版一格 ✓ 都没有。而 VM 版是 Early Access，创建 Room 需要邀请码。 Big @ 在开源版里只能在"你自己的 agent 之间"引用，跨人引用要 VM 版。	README 'Two Versions of Tutti' 与 'Tutti vs Tutti · VM' 两张对照表原文
Tutti	Apache-2.0 开源	许可证属实且 NOTICE 写得极其规范（5 处第三方代码全部精确到文件路径、上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的）。但"开源"不等于"功能完整"——结合上一条，开源版的功能完整度约一半，核心价值（协作）在闭源侧。Apache-2.0 保证了你能自由改代码，不保证你能用到它宣传的完整体验。	本地源码 NOTICE 全文 + README 版本对照表
Tutti	（隐含）体量小 = 成熟度低	反例。它是七个样本里 star 最少（3.6k）、建仓最晚（2026-06-12）的，但发布纪律最好：8 个 release 全是正式版，且维护 `stable` 滚动 tag。工程规范度（NOTICE 精度、测试投入 7851 行通用测试、Go 守护进程）明显超过 star 数比它高一个数量级的 OpenClaw 与 QwenPaw。 star 数与工程成熟度在本体系的七个样本里呈负相关。	GitHub releases API + 本地源码 NOTICE 与测试文件实测

一句话结论

项目	结论	适合	不适合
iPolloWork	把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用	想在同一个界面管理多引擎项目、并希望 agent 产出的 PPT / 网页 / 设计 / 视频之后还能继续手工修改的个人开发者，或少于 3 人的极小团队	3 人以上需要正式落地的团队（许可证要求书面授权）、期待 Codex 原生级集成的用户（目前只有 MCP 控制面）、以及追求稳定的生产环境（v0.50.x、一天多版、DSH 集成未进稳定版）
maka	唯一把「执行记录」当地基的项目——治理与可复现性最强，产品成熟度最弱。	对审计、数据主权、可复现评测有硬要求的团队；做 agent 横向对比研究的工程团队。	要开箱即用、要 Windows / Linux、要丰富第三方集成的人；以为 ASF 品牌等于生产可用的决策者。
OpenClaw	388k star 的个人 AI 助理，常驻你自己的机器、从聊天软件驱动—— 但沙箱默认关闭、版本号已经乱到读不懂发布节奏、关键提交仍系于一人之手。	想让 AI 真正接管日常事务且愿意自己加固部署环境的重度个人用户；想研究"非开发者向 agent 产品长什么样"的人（本体系里唯一的样本）。	把 star 数当成生产就绪度的人；指望沙箱开箱即保护的人；需要可预测升级路径的团队；希望助理"中立接入多个引擎"的人（它自己就是引擎，不接别人）。
openwork	把「能力」而不是「桌面」做成产品——工程治理最好的一个，但它和自称要替代的东西不是一个物种。	已固定在某款 agent 上、只想让团队能力跨工具复用的开发者；需要统一管控 agent 能力与模型配额的组织 IT。	想要一个开箱即用的桌面 agent 工作台的人；以为拿到的是完整 Cowork 平替的人。
orca	兼容面最广的并行 agent 编排外壳——广度做到极致，深度与治理都还是草稿。	已在重度使用 CLI agent、想同时跑多个方案横向比对的个人开发者与小团队。	需要稳定 SLA、指望社区 triage 与多人维护保障的团队；指望它统一各引擎能力（结构化调用、统一权限、一致口径）的架构选型者。
QwenPaw	安全默认值最完整、巴士系数最健康的个人助理—— 但至今没有发过一个正式版，且 `--defaults` 安装路径会默认打开遥测。	把数据与隐私放第一位、希望助理完全跑在本地的个人与小团队；需要在钉钉 / 飞书 / 微信 / QQ 渠道里用助理的国内团队；想不买 API key 先把流程跑通的尝鲜者。	需要正式版与稳定升级路径的团队（它全是 beta）；指望 2B / 4B 本地模型扛复杂 agent 任务的人；把「五层安全」当成不可绕过硬边界的人（Tool Guard 有 OFF 档）。
Tutti	把「多 agent 共享上下文、接力干活」做成了产品，且是发布纪律最好的—— 但接入深度严重偏袒 Codex（17 倍差距），而宣传的「多人协作」全在闭源 VM 版。	手里已有多个 agent 订阅、想让它们在同一工作区里接力与共享上下文的开发者；想让 agent 产出设计稿 / 文档 / PPT 而不只是代码的人；看重发布纪律与工程规范（NOTICE 精度、正式版节奏）的人。	指望开源版做团队多人协作的人（那七项功能全在闭源 VM 侧，且需邀请码）；主要用 Kimi / ComputerUse / BrowserUse 的人（这三个接入最薄、测试为零）； Windows 用户且主力引擎不是 Codex 的人（只有 Codex 做了 Windows 适配）。

文章索引

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

项目	一句话结论	深度文
iPolloWork	把多个 Agent 引擎收进同一个可编辑工作台的野心之作	已发布
maka	唯一把「执行记录」当地基的项目	已发布
OpenClaw	388k star 的个人 AI 助理，常驻你自己的机器、从聊天软件驱动	已发布
openwork	把「能力」而不是「桌面」做成产品	已发布
orca	兼容面最广的并行 agent 编排外壳	已发布
QwenPaw	安全默认值最完整、巴士系数最健康的个人助理	已发布
Tutti	把「多 agent 共享上下文、接力干活」做成了产品，且是发布纪律最好的	已发布

跨项目文章

四个 Agent 工作台的路线分野：把「多引擎中立」拆开看 — 2026-09-01
七个 Agent 项目，三种「开源」：当 star 数开始说反话 — 2026-09-01

收录标准

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	不镜像，仅存链接