gitea-publish
de6cf8f3c0
- articles/: 新增 5 篇深度文（八段结构，每篇含 claim_vs_reality） - maka.md → emlog_id=105 - openclaw.md → emlog_id=106 - openwork.md → emlog_id=107 - qwenpaw.md → emlog_id=108 - tutti.md → emlog_id=109 - data/projects/*.yaml: 回写 emlog_id 到 6 个档案（orca 前序已回写） - articles/00-overview.md: build_matrix.py 重算矩阵 + 回填总纲
240 lines
20 KiB
Markdown
240 lines
20 KiB
Markdown
# maka 深度拆解：唯一把「执行记录」当地基的 agent 工作区
|
||
|
||
> **速览**
|
||
>
|
||
> | 项 | 值 |
|
||
> | --- | --- |
|
||
> | 仓库 | [apache/maka](https://github.com/apache/maka) |
|
||
> | 一句话 | local-first 的 AI agent 工作区——消息、工具调用、工具结果、权限决策、终止事件全部落 append-only 日志 |
|
||
> | Star / Fork / Issues | 4373 / 406 / 398 open（2026-09-01） |
|
||
> | 主语言 / 体积 | TypeScript 91.7% / ~100 MB |
|
||
> | 最新版本 / 节奏 | v0.2.0-dev.9.20260831 / 一天多版（全部为 Nightly，无正式 release） |
|
||
> | 许可证 | Apache-2.0（**L1 · 真开源，可自由再分发，自带专利授权**） |
|
||
> | 成熟度 | **孵化期**（ASF Incubating，治理最成熟、产品最年轻） |
|
||
>
|
||
> **一句话结论**：七个样本里唯一在「执行记录层」做事的项目——地基打得最实，房子盖得最慢；它和另外六家不是同一类选手，不该用同一把尺子量。
|
||
|
||
---
|
||
|
||
## 0. 先给结论
|
||
|
||
maka 的口号是 *"a local-first AI agent workspace"*，但真正定义它的是 tagline 后半句：**model messages, tool calls, tool results, permission decisions, and termination events are recorded as an append-only log**——把 agent 干过什么做成不可篡改的执行记录。
|
||
|
||
它真正有意思的地方有三个：
|
||
|
||
1. **它赌「可复现」是 agent 的生死线。** 别人卷功能广度（多少引擎、多少工具、多少平台），maka 卷的是"这个 agent 到底干了什么、能不能复现、能不能审计"。README 里有一句值得抄下来：*"Shorter context is not deleted history"*——上下文压缩只省略下次 prompt 里的旧 tool 输出，**已存证据不删**。
|
||
2. **它是七个样本里唯一自带评测框架的。** `maka eval run <spec>` 支持 task × repetition × subject 的 multi-arm 实验，对同一任务横向比较得分/成本/耗时，还可以把外部 agent（Codex / Claude Code 等）当被测对象（external subject adapter）拉进来跑。这让它在「agent 评测」这个还没被产品化的赛道上占了先发。
|
||
3. **它是 Apache 孵化项目，但没有任何正式 release。** 截至 2026-09-01，对外分发的只有 Desktop Nightly，README 明确标注 *"not an ASF release, not intended for production use"*。治理流程（DISCLAIMER-WIP、ASF_SOURCE_RELEASE 候选契约、SECURITY、中文文档）一步没少，产品交付一步未成。
|
||
|
||
而它最大的问题也有三个：**平台支持最窄**（macOS arm64 是唯一正式档，Windows 未签名预览，Linux 标 "soon"）、**功能面最保守**（内置工具只有 Read/Write/Edit/Bash/Glob/Grep 六个）、**API key 明文落盘**。
|
||
|
||
---
|
||
|
||
## 1. 赛道定位：它站在哪一层
|
||
|
||
沿用本系列的分层法：
|
||
|
||
```text
|
||
┌──────────────────────────────────────────────────────────────┐
|
||
│ 编排 / 工作台层 │
|
||
│ 跨引擎、跨 worktree、跨交付物的调度与观测外壳 │
|
||
│ ── orca（执行编排）/ iPolloWork（桌面工作台）在这里 ── │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ 编辑器内 Agent 层 │
|
||
│ 嵌在 IDE / 编辑器里的交互层 │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ 执行引擎层 │
|
||
│ 真正跑 agent loop 的地方 │
|
||
│ ── maka 的 AgentRun 在这里，且它是自己引擎的满分实现者 ── │
|
||
├──────────────────────────────────────────────────────────────┤
|
||
│ 执行记录层（maka 额外占的一层） │
|
||
│ append-only 日志 + 评测框架：agent 行为的可复现底座 │
|
||
└──────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**maka 的站位在七个样本里是独一份**：它对**自己的**引擎深度是满分（Desktop / TUI / CLI / Eval 四个入口全部经同一个 Runtime Host 执行），对**外部**引擎深度是零（只在 eval 里把外部 agent 当被测对象，不做执行层兼容）。
|
||
|
||
它压根不参与「多引擎中立」这条赛道的竞争——这是**定位选择而非能力缺陷**。Orca 用 PTY 外壳把 30+ 引擎拉平到最薄的一层；iPolloWork 用原生 adapter 给个别引擎做深；maka 直接不接，自己造引擎、自己记录、自己评测。它想回答的问题不是"怎么接最多 agent"，而是"agent 干了什么，怎么证明"。
|
||
|
||
越往这层走，越接近基础设施而非产品。风险也在这里：**「执行记录 + 评测」是引擎厂商最容易原生化的能力**——一旦 Codex / Claude Code 自己把 event log 和 eval 做进产品，maka 的地基优势会被稀释成一层"合规装饰"。这是它护城河最薄弱的地方，也是它最该被盯住的地方。
|
||
|
||
---
|
||
|
||
## 2. 业务维度：它靠什么活着（答案是：不靠）
|
||
|
||
**目标用户**三类，且都很垂直：
|
||
|
||
- 对**可审计性与数据主权**有硬要求的团队（金融、政务等受监管场景）
|
||
- 需要**横向评测**不同 agent / 模型的研究者与工程团队
|
||
- 愿意**用功能丰富度换确定性**的自用开发者
|
||
|
||
**变现路径：无。** Apache 孵化项目，无商业实体、无双许可、无付费层、不卖模型。这是七个样本里商业色彩最淡的一个——甚至淡到"商业模式空白"都不算风险，因为人家根本没打算有。它要的是标准、是治理背书、是生态位，不是营收。
|
||
|
||
**许可证**是 Apache-2.0，L1，七个样本里最干净的一档：可自由镜像与再分发、自带专利授权与反诉终止条款、修改需声明、NOTICE 须随分发保留、不授予 Apache/ASF 商标使用权。没有任何商业条款陷阱。
|
||
|
||
**护城河**由三件需要长期投入、无法速成的东西构成：**执行记录模型 + 可复现评测框架 + ASF 治理背书**。三者互相咬合——记录模型是评测框架的数据源，评测框架是记录模型的价值出口，ASF 治理背书则是前两者在"可信"维度上的放大器。但三者的共同弱点是**都不产生用户黏性**：换掉 maka 的迁移成本主要是历史执行记录，而非生态锁定（见 `vendor_lockin`：无付费层、无共享账号、数据落本地 SQLite、执行记录格式公开）。
|
||
|
||
---
|
||
|
||
## 3. 场景维度：它在什么场合被用
|
||
|
||
**人机协作是强人在环**，且是审批式：工具越过沙箱边界（写文件 / 跑 shell）必须先过审批；运行可中止；失败被分类。它不追求全自动——对"可审计"这个核心承诺来说，人的审批决策本身就是执行记录的一部分（permission decisions 也落日志）。
|
||
|
||
**三端形态，一个 Runtime Host：**
|
||
|
||
| 形态 | 定位 | 成熟度 |
|
||
| --- | --- | --- |
|
||
| 桌面应用（Electron） | 主工作环境 | Nightly，macOS arm64 唯一正式档 |
|
||
| TUI / CLI | 终端工作区 + 评测入口（`maka eval`） | 与桌面共用 Runtime Host |
|
||
| 评测框架 | multi-arm 实验：task × repetition × subject | 七个样本里独一份 |
|
||
|
||
**典型用例三类：**
|
||
|
||
- 在保密项目里用本地模型跑 agent，所有 tool call 与权限决策落 append-only 日志备查
|
||
- `maka eval run <spec>` 对同一任务跑 multi-arm 实验，横向比较不同 agent / 模型的得分 / 成本 / 耗时
|
||
- 会话崩了以后从执行记录恢复，并从任一 Turn 分叉出新会话继续
|
||
|
||
**交付物**是 code、artifact、**eval-report、execution-record**——后两项是七个样本里独一份的。orca 的交付纵深停在"代码 + 比对"，iPolloWork 纵深在"生成后仍可编辑"，maka 纵深在"过程本身成为可交付、可审计的资产"。
|
||
|
||
---
|
||
|
||
## 4. 技术维度：它怎么做到的
|
||
|
||
### 架构：四个入口，一个 Runtime Host
|
||
|
||
maka 的技术骨架一句话：**Desktop / TUI / CLI / Eval 全部经同一个 Runtime Host 执行**——单一所有者的生命周期 + 协议 + 客户端引导。技术栈是 Electron + React + TypeScript + Node.js + SQLite，外加两块"硬"的：peer mesh 的 **Rust native addon**（本地多设备 mesh）和 Runtime 的 Grep 工具对 **ripgrep** 的依赖。
|
||
|
||
```text
|
||
┌─ 桌面 / TUI / CLI / Eval ──────────────────────────────┐
|
||
│ │
|
||
│ 四个入口 ──统一──> Runtime Host（单一生命周期所有者） │
|
||
│ │ │
|
||
│ ├──> AgentRun（自带 agent loop）│
|
||
│ ├──> append-only 执行记录 │
|
||
│ └──> 沙箱边界审批（越界必过） │
|
||
│ │
|
||
│ 外部 agent：仅在 eval 环节经 external subject adapter │
|
||
│ 作为被测对象接入，不参与执行层 │
|
||
└─────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
与 orca 正好相反：orca 的 Runtime 是"薄外壳 + N 个别人的引擎"，maka 的 Runtime 是"厚内核 + 零个别人的引擎"。
|
||
|
||
### 引擎抽象：对内满分，对外为零
|
||
|
||
| 维度 | maka 的做法 |
|
||
| --- | --- |
|
||
| 兼容判据 | **不兼容外部引擎**（执行层） |
|
||
| 抽象层 | Runtime Host（单一所有者的生命周期 + 协议 + 客户端引导） |
|
||
| 结构化 tool call | 自家引擎全量结构化（自己记录，当然拿得到） |
|
||
| 统一权限回调 | 自家引擎全量统一（越界审批走 Runtime Host） |
|
||
| 外部 agent 对接 | 仅 eval 环节的 external subject adapter，当被测对象 |
|
||
|
||
这是 `engine_neutral = 1` 的含义：**它不是"中立做得差"，是"根本不玩这个游戏"**。把它和 orca（9 分）画在同一个坐标轴上，是系列对比的刻意选择——极端样本互相校准坐标系，中间值才有意义。
|
||
|
||
### 多 agent：Graph 模式，偏实验性
|
||
|
||
Graph 多算子并行，实现算子跑在**独立 git worktree**，但**要求源项目是干净 worktree**——有未提交改动就用不了。对比 orca 的并行 worktree（产品级封装，对脏工作区有处理），maka 的 Graph 更接近实验性能力。
|
||
|
||
### 本地优先：全场最彻底，但有一个明文暗礁
|
||
|
||
`local_first_score = 10`，七个样本最高——数据与执行记录不出机器，模型完全 BYO（云 API、本地模型或兼容网关，README 原话 *"You bring the model"*，不捆绑任何共享账号）。
|
||
|
||
但有一个细节必须单独说（见第 6 节 ②）：**API key 以明文文件存放**，README 自己承认 `credential-vault.json` 是 *"local plaintext file, readable only by your OS account"*。防护靠操作系统账户权限，不靠加密、不靠系统钥匙串。"数据不出机器"是真的，"数据都安全"则打问号。
|
||
|
||
### 扩展体系：有 MCP，skills 默认关，无插件市场
|
||
|
||
- **MCP**：`packages/mcp` 提供 provider-neutral 的 MCP 客户端集成
|
||
- **skills**：catalog skills 存在，但可选且**默认关闭**
|
||
- **plugins**：无独立插件市场
|
||
|
||
功能面是七个样本里最保守的：内置工具只有 **Read / Write / Edit / Bash / Glob / Grep** 六个；Computer Use 与 catalog skills 属可选且默认关闭；IM bot（聊天应用接入）标注 experimental。取舍很明确：**用广度换确定性**——每个内置能力都要先过"能不能落进执行记录"这道闸。
|
||
|
||
### 观测性：全场最强项
|
||
|
||
append-only 执行记录：model 消息、tool call、tool result、**turn 结束方式**全部落盘。上下文压缩只省略下次 prompt 里的旧 tool 输出，**不删已存证据**——*"Shorter context is not deleted history"*。崩溃恢复与可选续跑（注意：续跑**默认关闭**，见第 6 节 ③）。
|
||
|
||
---
|
||
|
||
## 5. 横向对比
|
||
|
||
> 说明：下表项目均已收录进本系列追踪库，数据来自各自档案（`data/projects/*.yaml`，2026-09-01 快照）。"引擎中立度 / 本地优先"取自档案 `chart.*`（1–10）。
|
||
|
||
| 维度 | maka | orca | iPolloWork | openwork | Tutti | QwenPaw | OpenClaw |
|
||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||
| 站位层次 | **执行记录层 + 自带引擎** | 执行编排层（并行 fan-out） | 桌面工作台层 | 能力分发层 | 多人×多 agent 协作层 | 个人助理执行层 | 个人助理执行层（多渠道 Gateway） |
|
||
| 引擎中立度（1–10） | **1（不参与该赛道）** | 9（全场最高） | 7 | 6 | 8 | 2 | 1（自身即引擎） |
|
||
| 本地优先（1–10） | **10（全场最高）** | 6 | 7 | 6 | 7 | 9 | 8 |
|
||
| 交付纵深 | code + artifact + **eval-report + execution-record** | code + diff + review-comment | 生成后可编辑的多形态交付物 | 能力（MCP） | 多人协作会话 | 个人助理任务 | 个人助理任务 |
|
||
| 许可证 | **Apache-2.0（L1）** | MIT（L1） | L3 source-available | L3（目录切分） | Apache-2.0（L1） | Apache-2.0（L1） | MIT（L1，机器读不出） |
|
||
| 成熟度 | **孵化期（无正式 release）** | 原型期（一天一版） | beta（v0.50.x） | 0.x 活跃 | 快速成长期 | beta 活跃 | 高速迭代（约 4 天/版本） |
|
||
| 评测能力 | **唯一自带 eval 框架** | 无 | 无 | 无 | 无 | 无 | 无 |
|
||
|
||
maka 在谱系里的位置，用一句话概括：**引擎中立度清零、本地优先打满、观测性独一份的那个角落。** orca 与 QwenPaw/OpenClaw 是同一坐标轴上的两个极端（9 分 vs 1-2 分），maka 是第三个极端——它让"引擎中立"这个维度对自己失去意义，换来"执行记录"这个新维度上的独占。七个样本里，只有它值得问"agent 干了什么"；其他六家的交付物回答的是"agent 做出了什么"。
|
||
|
||
---
|
||
|
||
## 6. 宣称 vs 实测
|
||
|
||
这一节是本系列最看重的部分。maka 项目方没有说谎——它的 README 甚至是七个样本里自我披露最充分的（多处主动写限制）——但"披露得充分"和"没有坑"是两回事。
|
||
|
||
**① 宣称：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。
|
||
|
||
**② 宣称：「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_RUNTIME_SAFE_BOUNDARY_RESUME=1`，且 README 明确警告该调用会打模型、消耗 token。另存在**升级断代**：旧版 JSONL transcripts 与 Electron safeStorage 凭据不会被导入，升级后的工作区可能出现空线程，凭据必须重新录入。
|
||
**来源**：README「Local data and recovery」段。
|
||
|
||
**④ 宣称：（无明确宣称，但易被期待为开箱即用的完整工作台）。**
|
||
**实际**：内置工具只有 Read / Write / Edit / Bash / Glob / Grep 六个；Computer Use 与 catalog skills 属可选且**默认关闭**；IM bot（聊天应用接入）标注 experimental。功能面是七个样本里最保守的——取舍很明确：用广度换确定性。
|
||
**来源**：README「Current capabilities」段。
|
||
|
||
**⑤ 宣称：支持 Graph 多算子并行。**
|
||
**实际**：Graph 的实现算子跑在独立 git worktree，且**要求源项目是干净 worktree**——有未提交改动就用不了。相比 Orca 的并行 worktree（产品级封装），Maka 的 Graph 更接近实验性能力。
|
||
**来源**：README「Terminal entry points」段。
|
||
|
||
五条里有四条是 README **自己写出来的**——这是 maka 工程文化的一个侧面：不藏限制，但也不粉饰。① 和 ② 合起来看是理解 maka 的钥匙：**「治理成熟度最高、产品成熟度最低」**——治理文件（DISCLAIMER-WIP、ASF_SOURCE_RELEASE 候选契约、CONTRIBUTING、SECURITY、中文文档齐全）一步没少，产品交付（正式 release、平台覆盖、功能面）一步未成。
|
||
|
||
---
|
||
|
||
## 7. 结论：什么人该用它
|
||
|
||
**该用：**
|
||
- 对**审计、数据主权、可复现评测**有硬要求的团队（受监管场景尤甚）
|
||
- 做 **agent 横向对比研究**的工程团队——`maka eval` 是当前唯一"自带、可复现、multi-arm"的开源评测入口
|
||
- 愿意用 Nightly 的稳定性风险，换"执行记录不出机器 + Apache-2.0 可再分发 + 无商业实体锁定"的自用开发者
|
||
|
||
**不该用：**
|
||
- 要**开箱即用完整工作台**的人——六个内置工具、skills 默认关、Computer Use 默认关，功能面全场最保守
|
||
- 需要 **Windows / Linux 正式支持**的人——目前只有 macOS arm64 是正式档
|
||
- 以为 **ASF 品牌等于生产可用**的决策者——没有正式 release 就是没有正式 release
|
||
- 把 **API key 安全**托付给应用层的团队——明文文件 + OS 账户权限，不满足最小权限/加密存储的合规要求
|
||
|
||
**再看看：** 等四件事落地再评估——① 第一个 **Apache 正式 release**（INCUBATING → 毕业信号，当前连 ASF_SOURCE_RELEASE 候选都还没有）② Linux 与 Windows 是否进入正式支持档 ③ 上游引擎是否把「event log + eval」原生化（这是它护城河的头号威胁，**Codex / Claude Code 官方做评测框架的动作值得每季度盯一次**）④ 续跑与 Graph 是否从实验能力走向默认能力（worktree 干净度要求是否会放宽）。
|
||
|
||
---
|
||
|
||
## 8. 追踪备注
|
||
|
||
- **数据日期**：2026-09-01（GitHub API 快照）
|
||
- **指标**：★ 4373 / fork 406 / open issues 398 / subscribers 23 / ~100 MB / TypeScript 91.7% + Rust 1.7%
|
||
- **最新版本**：v0.2.0-dev.9.20260831，一天多版（均为 Nightly，无正式 release）
|
||
- **源码镜像**：`gitinbox/maka`（**public**，source-only 快照 ~12 MB——depth=1 浅仓被 Gitea 拒绝，--unshallow 后完整裸仓 163 MB 超 nginx ~50 MB 上限，遂剔除 png/gif/mp4/字体降级为源码快照；完整保真裸仓保留在本地 `.mirrors/maka.git`，服务器放开上限后可推完整版）
|
||
- **结构化档案**：`data/projects/maka.yaml`
|
||
|
||
**下次跟进点：**
|
||
|
||
1. ASF 孵化进度：DISCLAIMER-WIP 何时移除、第一个正式 release 何时出（毕业信号）
|
||
2. 平台覆盖：Linux / Windows 是否从 "soon" / 未签名预览 进入正式档
|
||
3. 上游威胁：Codex / Claude Code 官方是否原生化「执行记录 + 评测」能力
|
||
4. 功能面：续跑（safe boundary resume）与 Graph 是否从实验/默认关闭走向默认开启
|
||
|
||
---
|
||
|
||
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
|