track: 新增 OpenWork / Orca / Maka 三项目,样本达到 4 个

样本
- openwork (different-ai/openwork) 23.2k★ 能力分发层,DCO + evals + worlds
- orca (stablyai/orca) 58.8k★ 并行编排外壳,5000 issue 实为团队自开任务板
- maka (apache/maka) 4.4k★ 执行记录层,Apache 孵化但无正式 release

档案
- 三份五维档案填完,risk.claim_vs_reality 均已核实到证据
- ipollowork 象限坐标从占位 9/9/9/9 校准为 8/7/7/7(与新样本同一标尺)

文章
- 新增横评文《四个 Agent 工作台的路线分野:把「多引擎中立」拆开看》(emlog id=99)
- 总纲文回填四项目矩阵 + 双视图象限图 (emlog id=98)

镜像
- gitinbox/maka 已推送(public,source-only 快照 12 MB)
- openwork(291MB) / orca(671MB) 受 50KB/s 带宽约束,档案标 mode: pending

规则
- license-tiers.yaml 新增「目录切分许可」降级流程(OpenWork 判例:
  排除 ee/ 后为纯 MIT → public,完整镜像 → private)
- registry.yaml openwork 可见性改 public + mirror_excludes: ["ee/"]

脚本修复
- _common.py 新增 upsert_block:手工整块覆盖 ecosystem 删掉 metrics 时能自愈
- mirror_sync.sh:SOURCE_ONLY 未初始化(set -u 下偶发炸);
  浅仓推送被服务端拒绝 → 自动 --unshallow,失败降级快照;
  量体积前先 repack(此前新 commit 全是 loose object,恒打印 0 MB)
- build_matrix.py:成熟度长文本移出表格(新增 maturity_level 短标签);
  象限图标签靠右时翻转到左侧防溢出;SVG 加 max-width 防窄屏溢出;
  文章索引改为自动生成(原先手抄,横评文发了索引里却没有)
- publish_emlog.py:ID 回写按「有无同名档案」分流,
  00-* 跨项目文章落到 articles/<id>.meta.yaml(此前 ID 无处可写)
This commit is contained in:
gitea-publish
2026-09-01 19:27:21 +08:00
parent 78b87e8b2f
commit e5cdb1801e
18 changed files with 1771 additions and 114 deletions
+238
View File
@@ -0,0 +1,238 @@
# orca · 项目档案
# 生成于 2026-09-01 · 由 scripts/new_project.py 从 schema 生成
# 人工补完重点:business / scenario / tech / risk.claim_vs_reality / verdict
# 字段规范见 schema/project.schema.yaml
id: orca
name: "orca"
repo: "stablyai/orca"
homepage: "https://onOrca.dev"
added_at: "2026-09-01"
status: active
identity:
tagline: "Orca is the ADE for working with a fleet of parallel agents. Run any coding agent with your own subscription. Available on desktop, mobile and VPS."
vendor: "Stably AI(stablyai)"
vendor_type: "vendor"
region: "美国(据 Discord / App Store 与社群信息推断,未公开确认)"
first_seen: "2026-03-17"
business:
positioning: |-
站在「执行编排层」:不造引擎、不卖模型,只做并行 agent 的调度与可观测外壳。
上游是各家 CLI agent,下游是开发者的本机/远程 worktree。
target_users:
- 自称 100x builders 的重度个人开发者
- 需要同时试多种实现方案再择优合并的小团队
- 已在用 Codex / Claude Code / OpenCode 并想并行跑的人
monetization: |-
未明示,且这是它最大的商业不确定性。MIT 全开源、无企业版、无订阅层,
README 明确不提供模型也不代买订阅。收入路径尚未公开。
license:
spdx: "MIT"
name: "MIT License"
openness: L1
redistributable: true
key_restrictions:
- 无实质性使用限制
- MIT 不含商标许可,Orca 名称与 Logo 未单独授权
moat: |-
并行 worktree + 自研 WebGL 终端 + 移动端配对 + Design Mode 的组合体验,
以及已铺开的 30+ agent 兼容面。功能广度本身构成短期壁垒。
competitive_risk: |-
最容易被 Anthropic / OpenAI 官方桌面端直接吃掉——因为 Orca 既不拥有引擎
也不拥有模型,只拥有外壳。一旦官方 IDE 原生支持并行 worktree,差异化立刻归零。
scenario:
primary:
- 同一任务并行分派给多个 agent 各自实现,人工比对后合并优胜解
- 在远程大机上跑 agent(SSH worktree)
- 移动端监控 agent 并追加指令
typical_use_cases:
- 一条 prompt 扇出到 5 个 agent,各自在独立 git worktree 里改,最后 diff 对比选一个 merge
- 开 Design Mode 点页面元素,把 HTML/CSS/裁剪截图直接塞进 agent 的提示词
- 通勤路上用手机查看刚跑完的 agent 结果并追加一句 follow-up
industries:
- 软件研发
- 独立开发者 / 外包交付
interaction_mode:
- 桌面应用
- 移动端伴随
- CLI
- SSH 远程
human_in_the_loop: |-
强人在环:需人工比并结果、批注 diff、批准合并。
但 5000 个自开 issue 说明产品自身也在被 AI 自动改进。
deliverables:
- code
- diff
- review-comment
tech:
form_factor: 桌面应用(含移动端伴随 + CLI)
stack:
- Electron
- React
- TypeScript
- Node.js
- WebGL 终端
- Swift(iOS 伴随端)
engine_abstraction:
supported:
- Codex
- Claude Code
- OpenCode
- Pi
- Grok
- Cursor
- GitHub Copilot
- MiMo Code
- Amp
- Antigravity
- Hermes Agent
- Devin
- Goose
- Auggie
- Cline
- Continue
- Droid
- Kilocode
- Kimi
- Kiro
- Mistral Vibe
- Qwen Code
- Rovo Dev
- oh-my-pi
mechanism: |-
「只要在终端里能跑」即为兼容——通过 PTY 拉起任意 CLI agent,
不做协议级抽象,不解析结构化 tool call。
abstraction_layer: 无统一抽象层;实际是终端 PTY + 约定式输出解析
depth_notes: |-
接入深度「完全对等,但对等在低处」:30+ 引擎共享同一套 PTY 外壳,
因此没有任何一家能拿到原生能力——拿不到结构化 tool call、
拿不到统一权限回调、拿不到一致口径的 token 统计。
广度最大,深度最浅。对照 iPolloWork 为 OpenCode 做的原生
Engine Protocol adapter,Orca 与任一单引擎的耦合都明显更浅。
extension_system:
skills: README 未提及独立 skills 体系
plugins: 无插件机制,能力依赖各 agent 自身生态
mcp: 未作为一等公民提及
model_binding: 完全 BYO——用户自带各 agent 的订阅与额度
local_first: true
multi_agent: |-
并行 worktree 编排:一条 prompt 扇出到 N 个独立 git worktree,
比对结果后合并优胜解;另有任务页与 CLI 编排能力。
permission_sandbox: |-
README 未强调沙箱边界。Computer Use(操控桌面应用)与 SSH 远程执行
均属高权限面,且未见统一的越界审批机制描述。
observability: |-
终端分屏 + AI diff 批注 + 通知与未读态 + 用量与限流追踪 + 账号热切换。
观测的是「agent 的输出与结果」,不是「agent 的内部执行轨迹」。
ecosystem:
community: |-
Discord + X(@orca_build) + 微信社群(已开到第 8 群),中文市场渗透明显。
但 5000 个 open issue 中绝大多数由主力开发者自开,社区 triage 尚未成型。
standards: []
notable_events:
- 2026-03-17 建仓
- 2026-09-01 达 58.7k star、5000 open issue、版本 v1.4.194
metrics:
stars: 58771
forks: 3987
open_issues: 5000
subscribers: 121
created_at: 2026-03-17
pushed_at: 2026-09-01
size_kb: 687575
languages: {TypeScript: 97.0, JavaScript: 2.3, Swift: 0.2, CSS: 0.2, HTML: 0.1, PowerShell: 0.1}
latest_release: v1.4.194
release_cadence: 约 1 天/版本
data_date: 2026-09-01
stale: false
risk:
maturity_level: "原型期"
license_risk: |-
MIT,无许可证风险。但「商业模式的空白」本身就是风险:
一旦融资或转型,存在事后变更许可的可能(参考 Redis / Terraform 先例)。
vendor_lockin: |-
锁定点很弱——这既是优点也是缺点。用户锁的是 worktree 布局与 UI 习惯,
不是数据格式,迁移成本低;但反过来用户粘性也低。
claim_vs_reality:
- claim: |-
5000 个 open issue 反映社区问题积压与项目质量压力
actual: |-
抽样最近 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 条
从未被当作对外承诺来管理。
source: GitHub API /repos/stablyai/orca/issues?state=open,2026-09-01 抽样 100 条
- claim: |-
「100x builders 的 AI Orchestrator」,面向多人协作的成熟开发环境
actual: |-
巴士系数为 1:最近 100 次提交中 nwparker 独占 79 次,
第二名 AmethystLiang 仅 9 次。功能面由单人 + AI 高强度驱动,
而非团队协作成果。
source: GitHub API /repos/stablyai/orca/commits?per_page=100,2026-09-01
- claim: |-
支持 30+ 种 agent,生态最开放
actual: |-
兼容判据是「能在终端里跑」,靠 PTY 拉起而非协议对接。
广度最大但深度最浅——所有引擎都拿不到结构化 tool call
与统一的权限回调。与 iPolloWork 为 OpenCode 做原生
Engine Protocol adapter 相比,Orca 与任一单引擎的耦合都更浅。
source: README「Works with any CLI agent — if it runs in a terminal, it runs in Orca」
- claim: |-
MIT 全开源,可放心用于生产
actual: |-
许可证本身无风险,但项目没有任何公开的营收路径
(无企业版、无订阅、不卖模型、不代买订阅)。
58k star 的体量与零商业化不匹配,属于「要么即将融资、
要么后续变更条款」的不稳定态。
source: README License 段;README 明确「Orca does not provide models, nor does it buy subscriptions for you」
- claim: |-
桌面 / 移动 / VPS 全覆盖
actual: |-
三端成熟度不对等:Android 仍是手工分发 APK(0.0.47)、
iOS 走 App Store 与 TestFlight、VPS 场景需另查 headless Linux 指南。
移动端实际是「监控与追加指令」的伴随形态,不是完整工作环境。
source: README Install 段与 Mobile Companion 段
maturity: |-
功能广度第一,工程治理末位。一天多版(v1.4.194)说明迭代极快,
但 issue 只进不出、巴士系数为 1,属于「高速原型期」而非「可托付生产期」。
chart:
form_depth: 8 # 桌面 + 移动伴随 + CLI + SSH,形态铺得最广
engine_neutral: 9 # 30+ 引擎,兼容面第一
local_first_score: 6 # 本地起进程,但强依赖各家云端订阅
deliverable_depth: 3 # 主要产出 code / diff / review comment
verdict:
one_liner: 兼容面最广的并行 agent 编排外壳——广度做到极致,深度与治理都还是草稿。
who_should_use: |-
已在重度使用 CLI agent、想同时跑多个方案横向比对的个人开发者与小团队。
who_should_not: |-
需要稳定 SLA、指望社区 triage 与多人维护保障的团队;
指望它统一各引擎能力(结构化调用、统一权限、一致口径)的架构选型者。
mirror:
gitea_repo: "gitinbox/orca"
visibility: public
upstream: "https://github.com/stablyai/orca"
last_sync: ""
mode: pending
sync_note: "暂未镜像。仓库 671 MB,按实测 50 KB/s 需 3.7 小时,且 git clone 无断点续传,中途失败即全部作废。MIT 许可(L1)无分发障碍,纯粹是带宽约束。待服务器侧放开或改用服务端迁移后再补。"
article:
emlog_id: 0 # emlog 文章 ID,发布后回写
published_at: ""
url: ""