AI摘要

Apache Maka是一个本地优先的AI Agent工作空间，提供多Agent调度和可恢复执行记录。它的核心是Runtime Host，所有执行都需经过它，强调Event Log作为执行事实的Source of Truth。Maka的架构具有Event Sourcing特征，将历史与上下文解耦，适合作为企业Agent Runtime或软件工程Agent。Maka还内置了多种工具，支持MCP，并与Codex模型协议/登录/Context行为深度适配。Maka的Memory是透明的，用户可控，与ai-memory项目不同，后者服务于多个外部Agent。Maka的技术栈包括TypeScript、Node.js、Electron、React等，目前主要支持macOS Apple Silicon，Windows和Linux支持正在开发中。Maka适合个人AI工作台、企业Agent Runtime、软件工程Agent和Agent评测平台等场景。

这个项目很有意思，而且从架构层面看，Apache Maka 和你前面看的 ai-memory 完全不是同一类产品。

我把当前 apache/maka 的 README、架构文档、Agent Graph、本地 Memory、MCP 以及 Codex 相关实现都看了一遍。我的定位是：

Apache Maka = Local-first AI Agent Workspace + Agent Runtime + 多 Agent 调度 + 可恢复执行记录。

它更接近一个开源版的 Codex / Claude Code Desktop + Agent Runtime 平台，而不是一个单纯的 Agent SDK。

截至当前，仓库约 3,062 Stars、312 Forks，主语言 TypeScript，Apache-2.0 License，目前处于 Apache Incubator 孵化阶段。仓库在 2026 年 5 月创建，仍然处于高频开发期。

Apache Maka.png

一、Apache Maka 是什么？

官方给自己的定义是：

A local-first Agent workspace built for real work.

即：

一个面向真实工作的、本地优先的 AI Agent 工作空间。

它不是让你写：

agent = Agent(...)
agent.run(...)

这种 SDK。

而是直接给你一套：

                 Apache Maka
                      │
       ┌──────────────┼──────────────┐
       │              │              │
    Desktop          TUI            CLI
       │              │              │
       └──────────────┼──────────────┘
                      │
                Runtime Host
                      │
                SessionManager
                      │
                   AgentRun
                      │
           ┌──────────┼──────────┐
           │          │          │
         Model       Tools      MCP
           │          │          │
           └──────────┼──────────┘
                      │
              Runtime Event Log
                      │
          ┌───────────┼────────────┐
          │           │            │
       Context      Session       Recovery

这就是 Maka 的核心。

官方架构规定：

整个系统只有一个执行权威：Runtime Host。

Desktop、TUI、CLI、Bot、Eval 都不能自己再搞一套 Runtime，而必须经过 Runtime Host。

这是它很重要的设计原则。

二、我认为 Maka 最重要的概念：Runtime Event Log

很多 Agent 系统的基本模型是：

Prompt
  ↓
LLM
  ↓
Tool
  ↓
Answer

Maka 的模型不是这样。

它更像：

          Agent 执行
              │
              ▼
       Runtime Event Log
              │
 ┌────────────┼────────────┐
 │            │            │
Model       Tool Call    Tool Result
Message
 │            │            │
 ├─权限决定
 ├─失败
 ├─终止
 ├─Usage
 └─Artifacts
              │
              ▼
        所有事实永久记录

也就是说：

Event Log 是执行事实的 Source of Truth。

官方明确规定，模型消息、工具调用、工具结果以及终止事实都写入 Runtime Event Log；Context pruning 和 compaction 只是改变“下一次给模型看的上下文”，不会删除历史事实。

这个架构非常重要。

三、Context 和 History 被彻底分开了

普通 Agent：

History ≈ Context

历史越来越长：

10K
 ↓
50K
 ↓
100K
 ↓
200K Tokens

最后开始：

截断
压缩
丢历史

Maka 的设计是：

         Runtime Event Log
          完整历史事实
                │
                │ Projection
                ▼
           Model Context
                │
        ┌───────┴───────┐
        │               │
     当前需要        Compact
      的信息           Summary

所以：

历史 ≠ 当前 Context。

这其实和数据库领域：

Event Store
    ↓
Projection
    ↓
Read Model

是一个思想。

严格来说 Maka 有明显的：

Event Sourcing

架构特征。

仓库 Topics 里也明确标了 event-sourcing。

四、为什么这个设计特别适合 Agent？

假设 Agent 做了：

1. 查看 billing.ts

2. 修改代码

3. npm test

4. 测试失败

5. 修改方案

6. 再测试

7. 成功

8. 用户拒绝一个 Bash 权限请求

传统 Chat 可能最终只保留：

User:
修改 billing

Assistant:
已经完成。

而 Maka 会有：

Runtime Event Log

├── model_message
├── tool_call: Read
├── tool_result
├── tool_call: Edit
├── tool_result
├── tool_call: Bash
├── permission_request
├── permission_decision
├── tool_result
├── model_message
├── tool_call
├── tool_result
└── completed

于是：

UI 崩了可以恢复。
Context 被压缩了，历史还在。
Agent 中断了，可以 Resume。
工具失败了，可以审计。
权限批准过什么，可以查询。

这实际上是在构建：

Agent Execution Ledger

也就是 Agent 执行账本。

五、它已经不是单 Agent 系统

Maka 最近非常值得关注的一部分叫：

Agent Graph

但它的设计思想非常克制。

官方甚至直接把设计文档标题写成：

Graph Is a Schedule, Not a Second Runtime

即：

Graph 是调度器，不是第二套 Agent Runtime。

这点我非常认同。

六、Maka 的多 Agent 模型

例如：

                     Main Agent
                    Supervisor
                        │
          ┌─────────────┼─────────────┐
          │             │             │
          ▼             ▼             ▼
       Agent A        Agent B       Agent C
     Runtime分析      数据库分析      UI分析
          │             │             │
          └──────┬──────┴──────┬──────┘
                 │             │
                 ▼             ▼
             Agent D         Agent E
             综合分析         Review

但它并不会建立：

Graph Runtime
Agent Runtime
Workflow Runtime

三套执行体系。

而是全部：

Agent Graph
      │
   调度任务
      │
      ▼
Child Session
      │
      ▼
AgentRun
      │
      ▼
Runtime Event Log

七、Maka 对 Operator 的定义也很漂亮

Maka 把：

Child Session

定义为：

Operator Container

而：

AgentRun

定义为：

Activation

所以：

Operator A
   │
   └── Child Session
           │
           ├── AgentRun #1
           │
           ├── AgentRun #2
           │
           └── AgentRun #3

这样 Agent A 可以：

第一次：

分析 Billing

后来 Supervisor 再告诉它：

结合 Agent B 的发现继续分析

它不需要创建一个完全陌生的新 Agent。

而是：

同一个 Child Session
+
新的 AgentRun

继续执行。

这是非常符合工程实际的。

八、Maka 内置了哪些工具？

当前 README 明确列出的基础工具包括：

Read
Write
Edit
Bash
Glob
Grep

另外还有可选：

Computer Use
Catalog Skills
Web Search
MCP Tools

所以从使用体验上看，它已经比较像：

Codex
Claude Code
Cursor Agent

这一类 Coding Agent。

九、MCP 支持值得特别关注

Maka 有独立：

packages/mcp

并且 Runtime 可以把 MCP Server 暴露的工具转换成：

MakaTool

例如：

企业 CRM MCP
      │
      ▼
     Maka
      │
      ▼
mcp__crm__getCustomer

然后 Agent 就能调用。

但 Maka 做了一件很重要的事：

MCP annotation 不能成为安全边界。

即便某个 MCP 自己声称工具安全，Maka 仍然有自己的：

Permission
Sandbox
Network Boundary

例如网络型 MCP Tool，如果当前 Sandbox 不允许网络访问，会先要求批准，而不是直接调用。

这个设计对于企业 Agent 非常正确。

十、它和 Codex 的关系，比我最初预期还深

我进一步看代码时发现：

Maka 并不是只有：

OpenAI API

这种简单支持。

代码中已经存在：

openai-codex

Provider，并实现了：

Codex Device Authorization

流程。

甚至代码注释明确说明：

这个 Device Auth 流程参考并对齐官方 codex-rs CLI 的登录实现。

流程大致：

Maka
 │
 ▼
OpenAI Device Auth
 │
 ▼
auth.openai.com/codex/device
 │
 ▼
用户授权
 │
 ▼
OAuth Token
 │
 ▼
openai-codex connection

这点对你尤其值得关注。

但需要准确区分：

Maka 并不是启动一个 Codex CLI 当 Agent。

而是：

Maka 自己是 Agent Runtime，只是可以使用 OpenAI Codex 的 OAuth/模型连接通道。

仓库里还有：

codex-model-compatibility.ts
codex-v4a-patch.ts
openai-codex-history-compactor.ts
codex-session-adapter.ts

等针对 Codex 的兼容代码。

所以它不是“顺便支持 OpenAI”。

而是对：

Codex 模型协议 / 登录 / Context 行为

做了专门适配。

十一、它还有自己的 Local Memory

这就正好可以和我们上一轮讨论的 ai-memory 对比。

Maka 当前 Local Memory 核心是：

MEMORY.md

而且强调：

Transparent Local Memory

也就是：

用户看得见、能编辑、能控制。

当前代码设定：

最大 MEMORY.md：128 KB

注入 Prompt：
最多约 12,000 字符

并支持：

manual
extracted
imported

active
archived
review_required
rejected

workspace scope
session scope

同时：

agentReadEnabled = false

默认情况下 Agent 不能直接读取 Memory，需要用户显式开启。

这体现了 Maka 一个很明显的设计理念：

Memory 应该是透明和用户可控的。

十二、但 Maka Memory 和 ai-memory 差别很大

这两个项目正好可以这样理解：

	Apache Maka	ai-memory
核心定位	Agent 工作平台	Agent 长期记忆基础设施
Agent Runtime	✅ 自己有	❌
Desktop	✅	❌
CLI/TUI	✅	✅ CLI
Session	✅	接入外部 Session
Tools	✅	❌
Sandbox	✅	❌
MCP	MCP Client/Tool 集成	MCP Memory Server
Event Log	✅ 核心	Observation
Memory	MEMORY.md	Markdown Wiki
Vector Search	Memory 当前不是核心	可选
Codex	模型/认证深度适配	Codex Agent 记忆外挂
多 Agent	Agent Graph	Cross-Agent Handoff

所以：

ai-memory

更像：

Codex ─┐
Claude ├── ai-memory
Cursor ┘

它服务多个外部 Agent。

Maka

则是：

          Maka
           │
     Agent Runtime
           │
  ┌────────┼────────┐
  │        │        │
Model    Tools    Memory
  │        │        │
  └────────┼────────┘
           │
       Event Log

自己就是整个 Agent 容器。

十三、和 Eino 又完全不同

如果把你最近关注的三套东西放在一起：

项目	本质
Eino	Agent 开发框架
ai-memory	Agent Memory 基础设施
Apache Maka	Agent Runtime + Workspace

换一种说法：

Eino
=
给程序员造 Agent 的 SDK


ai-memory
=
给 Agent 安装长期大脑


Apache Maka
=
直接造了一台 Agent 电脑

这是最容易理解的区别。

十四、Maka 的 Eval 系统也很专业

Maka 不是只有聊天界面。

它还把：

Agent Evaluation

做成第一等公民。

模型大概是：

Experiment
     │
     ├── Task
     ├── Subject
     ├── Repetition
     │
     ▼
    Cell
     │
     ▼
   Attempt
     │
     ▼
   Result

例如你要比较：

GPT-5.6
vs
Claude Opus
vs
DeepSeek

可以：

同一个任务
同一个预算
相同重复次数
相同 verifier

然后比较：

Score
Token Usage
Cost
Duration
Failure
Artifacts

而 Maka 自己作为 Subject 时，也必须经过 Runtime Host，不能偷偷走另一套执行路径。

这个设计对企业做模型选型非常有价值。

十五、技术栈

目前主技术栈比较清晰：

TypeScript

Node.js >= 22.19

npm Workspaces

Electron
React

SQLite

MCP SDK

AI SDK

Monorepo 结构：

apps/desktop

packages/
├── core
├── storage
├── mcp
├── runtime
├── runtime-host
├── eval
├── computer-use
├── cli
└── ui

根 package.json 当前标记版本为 0.2.0。

不过这里有一个重要区别：

0.2.0 ≠ Apache 官方 Release。

README 明确说明：

Maka 目前还没有完成一次正式 ASF Release。

当前代码/预构建物仍属于孵化阶段产物。

十六、当前平台成熟度

现在平台支持大致是：

平台	状态
macOS Apple Silicon	✅ 主要支持
Windows	🟡 Preview
Linux	❌ 尚未正式支持
Desktop	✅
CLI	✅
TUI	✅

README 目前建议：

git clone https://github.com/apache/maka.git
cd maka

npm ci
npm run dev

而不是推荐直接下载正式 Apache Binary，因为正式 ASF Release 尚未产生。

十七、我认为 Maka 最有价值的四个地方

如果只让我挑核心，我不会挑 UI，也不会挑模型支持，而会挑这四个：

① Runtime Host
      │
      └── 单一执行权威

② Runtime Event Log
      │
      └── Agent Execution Ledger

③ Context Projection
      │
      └── 历史与上下文解耦

④ Agent Graph
      │
      └── 调度多个 Child Sessions
          而不是再造第二套 Runtime

把它们放在一起：

                    Maka
                     │
               Runtime Host
                     │
              SessionManager
                     │
          ┌──────────┴──────────┐
          │                     │
      Main Agent            Agent Graph
          │                     │
          │             ┌───────┼───────┐
          │             │       │       │
          │          Child A Child B Child C
          │             │       │       │
          └─────────────┼───────┼───────┘
                        │
                    AgentRun
                        │
              Model + Tool Runtime
                        │
                        ▼
                Runtime Event Log
                        │
       ┌────────────────┼────────────────┐
       │                │                │
    Context          Recovery         UI
    Projection                       Projection

我认为这是 Maka 真正值得研究的架构。

十八、它适合什么场景？

它尤其适合下面这一类：

个人 AI 工作台：

Codex Desktop
+
Claude Code
+
Cursor

这一类工具的开源替代探索。

企业 Agent Runtime：

企业模型
+
企业 MCP
+
权限
+
Sandbox
+
Agent
+
Audit

软件工程 Agent：

读取代码
→ 修改代码
→ Bash
→ 测试
→ Review
→ 多 Agent 协作

Agent 评测平台：

GPT
Claude
DeepSeek
Qwen
Local Model

统一跑 Benchmark。

十九、它目前还不是什么

这一点同样重要。

Maka 不是：

企业知识库平台

也不是：

RAG 平台

更不是：

Flowable 那样的 BPM 工作流引擎

它的 Agent Graph 目前也明确不是：

任意循环 Workflow、分布式执行系统、图形化 BPM 编排器。

所以不要把它理解成：

Dify
n8n
Flowable

那一类产品。

它真正解决的是：

Agent 如何可靠地执行工作。

二十、我对 Maka 的评价

从你最近研究的方向来看，我认为 Maka 的研究价值甚至比很多 Agent Framework 更高。

我的评分：

维度	评价
Agent Runtime 架构	★★★★★
Event Sourcing 思想	★★★★★
Session/Recovery	★★★★★
多 Agent 架构	★★★★★
Codex 适配	★★★★☆
MCP	★★★★☆
Memory	★★★
企业权限体系	★★★
跨平台成熟度	★★★
当前生产成熟度	★★★

综合我会给：

8.7 / 10

现在还偏早期，但架构思想明显高于它当前产品成熟度。

特别是这三个设计，我认为值得吸收到企业 Agent 底座里：

Agent 的执行过程应该 Event Sourcing。
Context 是历史的 Projection，而不是历史本身。
多 Agent Graph 应该是调度层，而不是再造一套 Runtime。

如果把我们前面看的 ai-memory 加进来，实际上已经可以组成一套非常有意思的架构：

                     Enterprise AI Platform
                              │
                         Agent Runtime
                              │
                        Apache Maka 思路
                              │
             ┌────────────────┼────────────────┐
             │                │                │
        Runtime Log       Agent Graph       Sandbox
             │                │                │
             └────────────────┼────────────────┘
                              │
                          MCP Layer
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
      Knowledge            Business             Memory
        RAG                 SQL/API            ai-memory
          │                   │                   │
          └───────────────────┼───────────────────┘
                              │
                       Enterprise Context

如果目标是自研一个“企业版 Codex / AI 办公 Agent 平台”，Maka 我认为属于应该认真拆源码的项目，而不只是安装体验一下。它里面的 Runtime Host、Runtime Event Log、Agent Graph、Recovery、Permission/Sandbox 这几块尤其值得借鉴。

Apache Maka：一个面向真实工作的、本地优先的 AI Agent 工作空间