每天一个开源项目#79 Apache Maka：3K星本地Agent工作台

Trending 排名：#9｜快照日期：2026-08-25｜Stars：3,052｜Forks：312｜主语言：TypeScript｜License：Apache-2.0｜仓库：github.com/apache/maka

如果你已经把 Claude Code、Codex 或各类 Agent CLI 用进日常开发，很快会遇到一个不太舒服的问题：一次长任务到底发生过什么？模型读了哪些文件，发起过哪些工具调用，哪些操作被批准了，哪里中断了，重启之后能不能继续？很多工具把这些东西当成一段聊天记录处理，窗口塞不下就压缩，进程挂了就重跑。短任务能凑合，真拿来改项目就很容易失去现场。

Apache Maka 想解决的不是"再做一个聊天壳"，而是把 Agent 的执行过程变成可恢复、可投影、可审计的本地事实日志。它把 Desktop、TUI、CLI、Eval 都收束到同一个 Runtime Host 下，模型消息、工具调用、工具结果、权限决策和终止事件都进入 SQLite 里的 Runtime Event Log。上下文压缩只是从日志生成给模型看的投影，原始事实不被摘要覆盖。

我比较喜欢它的一点是安全边界写得很诚实。README 说有 sandbox boundary，SECURITY.md 里又明确补了一刀：真正能挡住恶意 LLM 的边界只有操作系统账号；权限引擎、脱敏、URL 过滤这些只是进程内安全网，不等于 OS 级隔离。这种说法没有那么好卖，但对准备用 Agent 改真实仓库的人更有用。

📋 项目概览

项目	内容
项目名	Apache Maka (Incubating)
一句话	本地优先的 Agent 工作台，用 Runtime Host 和 SQLite 事件日志保存可恢复的执行事实
GitHub	github.com/apache/maka
Stars	3,052（GitHub API 补充核验，2026-08-25）
Forks	312
语言	TypeScript 93.3%，JavaScript 3.8%，CSS 1.5%，Rust 0.6%，Python 0.5%
License	Apache-2.0；项目处于 Apache Incubator 阶段
版本	GitHub Release v0.1.11；CLI 预发布 cli-v0.1.0-beta.1；main 分支 package.json 为 0.2.0
当前 HEAD	d413895，提交信息为 `feat(cli): managed update reconciliation with scheduler ready check (#3747)`
本地数据	默认写入 Electron userData 下的 `workspaces/default/runtime.sqlite` 等文件

🔥 为什么值得关注

Agent 工具正在从"帮我写一段代码"变成"在我的仓库里连续工作半小时"。边界一变，系统设计也要跟着变。以前聊天记录够用了，现在你需要知道一次工具调用是否真的落盘、一次权限批准覆盖了什么范围、一次 crash 之后模型看到的历史是否合法。否则 Agent 不是帮你省时间，而是在你看不见的地方制造状态债。

Maka 的设计抓住了这个变化。它把 Runtime Event 当成事实源，把 Session、UI、上下文、恢复流程都做成可重建的投影。这个思路有点像事件溯源在 Agent Runtime 里的落地：先承认"模型看到的上下文"和"系统保存的事实"不是一回事，再用高水位、digest、continuation claim 这些结构把两者接起来。

这套架构最适合两类人看。一类是想用本地 Agent 真改代码的开发者，关心失败恢复、权限、凭据、日志和版本漂移。另一类是做 Agent 平台的人，Maka 的 Runtime Host、Graph 调度、Eval 边界和安全文档提供了不少可借鉴的工程切面。它还早，坑也不少，但方向比普通包装器更值得拆。

🏗️ 核心特性

本地优先的 Runtime Host

Maka 明确规定只有一个执行权威：Runtime Host。Desktop、TUI、CLI、Bot、Eval 都只是客户端或入口，不各自维护一套 Runtime。源码里的 ARCHITECTURE.md 把边界写得很清楚：Runtime Host 持有 Session / Turn 身份、Agent 生命周期、工具、权限和事件；Eval 只负责实验语义。

text 复制代码

Desktop / TUI / CLI / Bot
        ↓
   Runtime Host
        ↓
   SessionManager
        ↓
AgentRun + RuntimeKernel
        ↓
Tool Runtime + Model Adapter
        ↓
Runtime Event Log
        ↓
Context / Session / UI / Recovery projections

这个分层的好处是恢复和审计不用在多个入口之间猜。你从 Desktop 里开的会话、CLI 里跑的一次 maka run、Eval 里执行的 Maka subject，都回到同一个执行脊柱。

Runtime Event Log，而不是普通聊天记录

packages/core/src/runtime-event.ts 定义了 RuntimeEvent 的身份字段：id、invocationId、runId、sessionId、turnId、ts。事件还记录 role、author、状态、内容、权限请求、权限决策、工具分发、token 用量、continuation 起点和 workspace fact。

ts 复制代码

export interface RuntimeEvent {
  id: string;
  invocationId: string;
  runId: string;
  sessionId: string;
  turnId: string;
  ts: number;
  partial: boolean;
  role: RuntimeEventRole;
  author: RuntimeEventAuthor;
  status?: RuntimeEventStatus;
  content?: RuntimeEventContent;
  actions?: RuntimeEventActions;
  refs?: RuntimeEventRefs;
}

真正落库的地方在 packages/storage/src/sqlite-runtime-schema.ts。第一版 migration 就创建了三张关键表：runtime_events、tool_journal_events、tool_operations。其中 runtime_events 是语义事实，tool_operations 和 tool_journal_events 更像查询与恢复用的投影。

表	作用	关键字段
`runtime_events`	保存模型、用户、工具、权限、终止等不可变事实	`event_id`、`invocation_id`、`run_id`、`turn_id`、`event_seq`、`payload_json`
`tool_operations`	查询一次工具操作的当前状态	`operation_id`、`tool_name`、`canonical_args_hash`、`current_state`、`call_event_id`、`result_event_id`
`tool_journal_events`	记录工具操作状态流转	`journal_seq`、`operation_id`、`state`、`runtime_event_id`

上下文压缩是投影，不是删历史

长会话里最容易犯的错是把摘要当历史。Maka 的 compaction 文档把这件事拆开：Runtime Event Log 保存事实；History Compact Checkpoint 保存带覆盖边界的有损视图；Provider Request Messages 才是这次模型调用实际看到的上下文。

text 复制代码

Canonical history = RuntimeEvents[0..n]

Compact checkpoint = Project(
  RuntimeEvents[0..k],
  compaction policy,
  summarizer
)

Next model context = Materialize(
  compact checkpoint,
  RuntimeEvents[k+1..n],
  provider capabilities,
  current context budget
)

这里 LLM 可以参与生成摘要，但不能决定摘要覆盖了哪些事件、source digest 是什么、哪些 raw tail 必须保留、checkpoint 能不能替代当前请求里的历史。确定性 Runtime 代码做这些判断。这点很关键，因为摘要错了还能回头查事实；如果事实被摘要覆盖，恢复链路就断了。

Crash 之后先修事实，再决定能不能继续

runtime-resume-architecture.md 里有个很典型的例子：模型把 config.json 的端口从 3000 改到 4000，写文件时应用崩溃。缺少工具结果不代表工具没执行，也不代表执行成功。Maka 把恢复拆成 repair、reconcile、resume 三件事。

text 复制代码

old process disappears
  → reopen durable facts
  → repair the old Run's terminal state
  → let RecoveryResolver interpret every tool operation
  → let the host inspect workspace / tools / background work
  → safe: create a new Run / Invocation / Turn
  → unsafe or unprovable: park

当前文档标注 Phase 0、Phase 1、Phase 2 和 Phase 3A 已实现；更完整的工具特定 evidence reconciler、Git checkpoint restore、durable rebaseline 还在后续阶段。也就是说，Maka 已经有比较严肃的恢复骨架，但还不能把所有外部副作用都自动判清楚。

Graph 是调度层，不是第二套 Runtime

Graph Mode 容易被写成"多 Agent 并发执行"的宣传词。Maka 的文档更克制：Graph 是 Runtime 事实之上的 durable schedule。每个 child Session 仍然走普通 AgentRun、权限、上下文、工具和恢复路径；Graph 只保存拓扑、调度意图、admission claim 和 supervisor wake。

text 复制代码

Root Session
└── Graph namespace
    ├── Schedule revisions
    ├── Operator A → Child Session → AgentRun → RuntimeEvents
    ├── Operator B → Child Session → AgentRun → RuntimeEvents
    ├── Admission claims
    └── Supervisor wakes

这比"开几个子进程一起跑"复杂，但也更可控。Graph 记录只引用已提交的 RuntimeEvent，不复制完整工具参数和结果。主 Agent 需要真正读取子 Agent 输出时，再通过 agent_output 用 childSessionId 和 runId 去查权威账本。

权限与沙箱边界说得很直

SECURITY.md 写明 Maka 是单租户个人桌面 Agent，默认以用户自己的 OS 账号运行。权限引擎会在写文件、危险 shell、网络访问等操作前提示，但它不是安全边界。当前产品组合也没有默认把工具跑进容器或单独进程。

层	Maka 当前说法	读者该怎么理解
OS 用户账号	真正的强边界	不信任仓库或任务时，用非管理员账号、容器、VM 或临时工作区
Renderer sandbox + preload IPC	桌面 UI 与主进程之间的边界	渲染进程不能直接读文件、网络、shell；IPC 是审计重点
credential store	本地明文 JSON，靠 0700/0600 和 OS 账号保护	不是系统 Keychain，也不是硬件安全模块
Permission Engine	UX 安全网	能减少误操作，不能保证抵挡恶意提示注入
sandbox manager	有 macOS Seatbelt、Linux bubblewrap、Windows AppContainer 转换层	README 与 SECURITY.md 对产品默认启用程度要分开看

验证与工程规模

我在浅克隆的 main 分支上做了源码核验。git ls-files -z 写入临时文件后解析，避免终端输出截断导致误计数。当前仓库有 3,011 个 tracked files，其中 TypeScript 文件 2,274 个，测试文件按文件名和目录规则粗分约 971 个。

指标	数值	说明
tracked files	3,011	来自 NUL 分隔的 `git ls-files -z`，与 shell 计数一致
生产类文件	1,768	物理行约 632,475，包含 JSON 和源码类文件，非严格 SLOC
测试类文件	971	物理行约 390,904
文档类文件	144	物理行约 41,115
生成类文件	3	物理行约 30,905，主要是 model metadata generated 文件
最大源码协调文件	`packages/runtime/src/session-manager.ts`	6,793 行，Runtime 协调复杂度集中在这里

本地构建验证结果也能说明项目状态。安装依赖时使用 npm ci --ignore-scripts，避免 Electron postinstall 下载带来的额外变量。随后 @maka/core、@maka/storage、@maka/mcp、@maka/runtime、@maka/runtime-host 和 maka-agent 的 TypeScript build 可以通过。测试方面，@maka/core 跑完；@maka/storage 的 dist 测试汇总为 951 个 tests，936 pass、14 skipped、1 fail。失败项是 managed-dependency-environment-crash.test.js 中"另一个进程占用同一 storage root"的场景，stderr 里只有 Node SQLite ExperimentalWarning，整体 exit code 为 1，所以这里不能写成测试全绿。

验证项	结果
Node / npm	Node v22.22.3，npm 10.9.8，满足 README 的 Node >=22.19 要求
npm registry	`maka-agent@next` 为 0.1.0-beta.1，`latest` 为 0.0.0-alpha.0
已核验 CLI	`maka --help`、`maka run --help`、`maka eval --help`
文档漂移	main 分支 CLI 已有 `runtime-host service ...` 命令；npm `next` 包的 help 暂未支持这一组 service 子命令
本地构建	core / storage / mcp / runtime / runtime-host / cli build 通过
局部测试	core 通过；storage 有 1 个进程边界测试失败，需要维护者确认环境与 Node SQLite warning 处理

🔬 技术架构深度解析

Maka 的架构可以按数据面和控制面来读。数据面保存"发生了什么"，控制面决定"谁能让什么继续发生"。这两个面混在一起，Agent Runtime 很快会变成一锅状态粥。

text 复制代码

                 Control Plane
┌─────────────────────────────────────────────┐
│ Runtime Host                                │
│  - Session / Turn admission                 │
│  - permissions and sandbox boundary         │
│  - continuation claim                       │
│  - Graph schedule and supervisor wake       │
└─────────────────────────────────────────────┘
                    │
                    ▼
                  Data Plane
┌─────────────────────────────────────────────┐
│ SQLite runtime.sqlite                       │
│  - immutable RuntimeEvents                  │
│  - tool operation projections               │
│  - session metadata                         │
│  - workspace epochs / versions              │
│  - usage, artifacts, plans, task ledger     │
└─────────────────────────────────────────────┘
                    │
                    ▼
                Projections
┌─────────────────────────────────────────────┐
│ UI timeline / model history / recovery plan │
│ eval artifacts / graph read model           │
└─────────────────────────────────────────────┘

1. Runtime Host 的权限边界

SessionManager 的注释很直接：它把 SessionStore、AgentBackend 和 ExecutionBoundary 绑在一起。RuntimeKernelLike 暴露的能力包括 startTurn、resumeContinuation、compactSession、startChildTurn、stopSession、respondToSandboxBoundary、steer、queueMessage、runningTurnIds 等。也就是说，Maka 没把"发消息给模型"和"管理一次执行生命周期"分散到 UI 层。

更细一点，RuntimeKernel 有 session quiescent mutation 的概念：当某个 Session 正在执行时，某些突变不能并发开始。这是 Agent 工具里经常被忽略的事。用户点了 stop、模型还在 stream、工具刚写完文件、UI 又发起 retry，谁说了算？Maka 把这类问题放在 Runtime 里处理，而不是留给 React 组件和回调顺序碰运气。

2. SQLite schema 里的恢复意图

SQLITE_RUNTIME_SCHEMA_VERSION = 12。schema 里有 runtime_continuation_claims，字段包括 source session/run/turn、高水位、source prefix digest、boundary digest、provider replay digest、target run header、claimed_at 和 start_event_id。这不是普通"resume=true"开关，而是一张记录新旧执行边界如何衔接的表。

text 复制代码

source RuntimeEvents prefix
  ├─ highWater
  ├─ sourcePrefixDigest
  ├─ boundaryDigest
  └─ providerReplayDigest
        ↓
runtime_continuation_claims
        ↓
new invocation / run / turn

工具调用也用 T1/T2 思路约束副作用窗口。T1 是工具分发前的事实，T2 是工具结果返回前的事实。崩溃时如果只有 T1 没有 T2，系统不能擅自说"没执行"，也不能擅自说"成功"。Maka 当前的做法是把不确定状态 park 住，等更强 evidence 或人工处理。

3. Workspace 版本能力还在铺路

schema 里能看到 runtime_workspace_epochs、runtime_workspace_versions、runtime_workspace_heads 相关结构，字段包含 Git object format、source commit、source tree、policy hash、materialization semantics 等。这说明 Maka 正在把"哪个工作区版本与哪段 Runtime 事实对应"也纳入账本。

但这里要分清当前能力和目标能力。README 与恢复文档都指出 Phase 4 的 Git checkpoint、isolated restore 和 durable rebaseline 还没完全落地。现阶段的 .maka-workspace.json 更像 workspace identity marker，能证明"这是哪个工作区"，不能证明"每个文件内容仍然与旧历史完全一致"。

4. Graph 调度的三道闸

Graph 不是随便启动 child Agent。源码和文档里能看到三道闸：拓扑验证、readiness projection、admission claim。

text 复制代码

Supervisor schedule update
        ↓
Topology validation
  - missing operator rejected
  - self-loop rejected
  - duplicate edge rejected
  - cycle rejected
        ↓
Readiness projection
  - which records are visible
  - which operator can run
        ↓
Admission claim in SQLite
  - bind intent to exact Turn / Run identity
  - exact retry is idempotent
  - drift is rejected
        ↓
Child Session executes through normal Runtime

这套设计带来的代价也明显：状态结构多，协调文件大，阅读门槛高。session-manager.ts 已经接近 6,800 行，Graph、恢复、权限、上下文、子会话都往这里汇。Maka 的后续可维护性，很大程度要看它能不能继续把权威边界拆清楚，而不是把所有 Runtime 判断塞进一个巨型协调器。

5. 性能数据怎么读

Maka 仓库里有 packages/runtime-host/scripts/transcript-data-plane-benchmark.mjs 这样的脚本，但我没有看到可直接引用的独立 benchmark 结果。这里不应该替维护者发明"快多少"。从架构上看，它的成本模型大概是这样：

场景	主要成本	Maka 的设计取舍
冷启动	Node/Electron、Runtime Host 初始化、SQLite schema 检查	本地优先带来可恢复性，但启动成本不会像单文件 CLI 那么低
单轮对话	Provider 网络与推理延迟为主	Runtime 记录事件、权限、usage，会增加少量本地写入成本
长会话	上下文增长、工具输出膨胀、历史重放	compaction 做成投影，保留事实但缩短模型输入
多 Agent Graph	child Session、调度投影、admission、supervisor wake	换来可恢复调度与可审计 lineage，延迟和复杂度都会上升
恢复场景	读 ledger、修 terminal state、判断 tool operation	fail closed 比盲目重试慢，但能避免重复副作用

如果团队要评估它，应该自己测冷启动、首 token 时间、完整 turn 时间、工具 P95/P99、长会话内存、SQLite 文件增长、Graph 并发下的调度延迟。对 Agent 平台来说，这些指标比"模型回答快不快"更接近真实瓶颈。

📖 README 核心内容摘要

README 把 Maka 定位为本地优先 Agent workspace。当前公开能力主要有三块：Agent Runtime、Desktop workspace、Evaluation。

模块	README 描述	源码对应位置
Agent Runtime	多模型连接、streaming、thinking、usage、provider error、内置 Read/Write/Edit/Bash/Glob/Grep	`packages/runtime`、`packages/core`
Desktop workspace	session 创建、归档、搜索、重命名、retry、regenerate、branch、artifact 预览	`apps/desktop`、`packages/ui`
Evaluation	declarative multi-arm experiments，task × repetition × subject cells	`packages/eval`
CLI / TUI	`maka`、`maka run`、`maka eval`	`packages/cli`
Runtime Host	本地或远端 Host，项目根、profile、access credential	`packages/runtime-host`、`packages/cli/src/runtime-host-cli.ts`

README 里有几个边界值得记住：

目前还没有 Apache 官方批准的 source release。GitHub Release、npm 包、Desktop installer 都要按 incubating 阶段的 convenience artifact 看。
Desktop 当前主要面向 Apple Silicon Mac；Windows 是 unsigned preview；Linux README 标注 soon。
CLI 包名是 maka-agent，公开命令是 maka。npm 上无作用域的 maka 包不是这个项目，所以安装时要写 maka-agent@next。
首次运行需要配置模型连接。Maka 不捆绑共享模型账号，API key、OAuth token 等本地保存，credential vault 不是 OS Keychain。
maka run --yolo 会给任务完整文件和网络访问，README 自己也提醒只在你愿意让任务修改的环境里用。

一个最小的非交互示例是：

sh 复制代码

maka run "Summarize this project and identify its highest-risk area"

我用 maka-agent@next 实际跑了 help 核验，maka run 支持 --cwd、--connection、--host、--project、--model、--thinking、--timeout、--max-steps、--yolo、--resume、--continue、--graph。这说明 --graph 已进入当前 npm 预发布包；但 main 分支 README 中提到的 runtime-host service check-update、update-policy、reconcile-update 等 service 管理命令，在 maka-agent@next 0.1.0-beta.1 的 help 里还不可用。main 源码构建后 help 已能看到这些命令，所以这是典型的 main 分支领先 npm 预发布包。

🚀 快速上手

如果只是试 CLI，使用 npm 预发布包更简单。下面命令已用 maka-agent@next 的 help 输出核验，运行真实任务仍然需要你配置模型连接，可能消耗 API 或订阅额度。

sh 复制代码

npm install --global maka-agent@next
maka --version
maka --help

进入你希望 Agent 工作的项目目录：

sh 复制代码

cd path/to/project
maka

跑一次非交互任务：

sh 复制代码

maka run "Summarize this project and identify its highest-risk area"
maka run --help

如果想从源码跑 Desktop，README 推荐下面的开发路径。package.json 中 dev 对应 npm --workspace @maka/desktop run dev:hmr --，dev:full 会先执行完整 build 再启动 Electron。

sh 复制代码

git clone https://github.com/apache/maka.git
cd maka
npm ci
npm run dev

开发 CLI 时，README 使用源码 checkout 下的脚本：

sh 复制代码

npm run build
npm run cli:dev -- --help
npm run cli:dev -- run "Summarize this repository and identify its most important risk"
npm run cli:dev -- run --graph "Implement two independent slices, integrate them, then review the result"

这里有两个实用建议。第一，不要在重要工作区第一次尝试 --yolo，先用默认 ask 模式看权限提示和工具边界。第二，Maka 当前数据格式还在变，README 也明确说 CLI 和本地数据格式可能在稳定版前调整。用它跑真实项目时，最好单独建临时 clone，并把仓库状态交给 Git 控制。

📊 增长速度与社区热度

GitHub API 显示 apache/maka 创建于 2026-05-27，2026-08-25 的补充核验为 3,052 Stars、312 Forks。按创建日至快照日粗略计算，生命周期平均约 34.3 Stars/天。这只是曝光基线，不等于当天新增 Stars；本次脚本保存的 Trending 列表没有保留每个仓库的 today stars 字段，所以日增量不做推断。

社区活动比 Star 数更有意思。GitHub API 的 open_issues_count 为 267，但这个字段混合 Issues 和 PRs。Search API 拆开后是 149 个 open issues、118 个 open PRs；近 30 天 merged PR 统计为 1,475。最近提交也很密集，2026-08-25 当天能看到 Runtime Host managed update、provider endpoint 展示、DeepSeek V4 Flash effort 修复、transcript page not-found 处理等提交。

社区指标	数值	解读
Stars	3,052	对 Apache Incubator 阶段项目来说关注度不低
Forks	312	Fork / Star 约 10.2%，说明不少人愿意拉代码看或改
Open Issues	149	真实 issue 数，需要与 PR 分开看
Open PRs	118	活跃开发中，积压也不小
近 30 天 merged PR	1,475	维护节奏非常快，版本漂移风险也随之上升
Top contributor 提交	jackwener 1,793；Astro-Han 862；likun666661 261；M4n5ter 186	头部贡献者集中，但不是单人项目
最近 Release	v0.1.11，2026-08-18；CLI v0.1.0-beta.1，2026-08-18	Desktop 与 CLI 版本面不同，不能合并成一个版本号

完整 Trending 榜单如下。Stars、Forks、语言为 GitHub API 同日补充核验；today stars 未被脚本保留。

Rank	Repository	Language	Stars	Forks	Today Stars
1	Alishahryar1/free-claude-code	Python	49,375	8,044	未保留
2	openai/codex	Rust	117,579	17,937	未保留
3	MadsLorentzen/ai-job-search	Python	34,454	11,960	未保留
4	multica-ai/andrej-karpathy-skills	未标注	206,789	21,107	未保留
5	makeplane/plane	TypeScript	58,123	5,502	未保留
6	NousResearch/hermes-agent	Python	236,049	47,621	未保留
7	anthropics/claude-plugins-community	Python	1,484	162	未保留
8	AprilNEA/OpenLogi	Rust	16,099	439	未保留
9	apache/maka	TypeScript	3,051	312	未保留
10	PostHog/posthog	Python	39,086	3,278	未保留
11	openclaw/openclaw	TypeScript	387,514	81,352	未保留
12	AgriciDaniel/claude-obsidian	Python	12,166	1,353	未保留
13	rohitg00/ai-engineering-from-scratch	Python	48,481	8,517	未保留
14	basecamp/omarchy	Shell	30,502	3,096	未保留
15	tashfeenahmed/freellmapi	TypeScript	19,982	2,893	未保留
16	dani-garcia/vaultwarden	Rust	66,174	3,142	未保留
17	freestylefly/awesome-gpt-image-2	JavaScript	16,163	1,694	未保留
18	VoltAgent/awesome-agent-skills	未标注	32,079	3,411	未保留
19	tinyhumansai/openhuman	Rust	37,448	3,713	未保留

🎯 适用场景

场景	为什么适合	注意点
本地代码 Agent 工作台	Desktop、TUI、CLI 共享 Runtime Host，能保留工具调用和执行事实	早期版本，数据格式和命令仍可能变化
长任务恢复	RuntimeEvent、tool journal、continuation claim 能减少盲目重试	工具特定 reconcile 还没完全产品化，不确定状态可能 park
多 Agent 调度实验	Graph 把 child Session、activation、record、route、claim 拆开	复杂度高，适合有 Runtime 工程能力的团队
Agent 平台架构参考	事件日志、上下文投影、权限边界、安全文档都值得借鉴	不要把 Maka 的 UX guard 当 OS sandbox 复制宣传
Agent 评测	`packages/eval` 支持 declarative multi-arm experiment	Harbor / Pier 需要机器本地环境和框架版本，不会自动安装
企业内部试点	本地存储、BYOK、权限提示、审计记录更符合谨慎引入 Agent 的方式	凭据本地明文保存，依赖 OS 账号和文件权限，需要安全评审

💡 总结

Apache Maka 让我觉得有价值的地方，不是它又接了多少模型，也不是界面能做多少 Agent 操作，而是它把 Agent Runtime 中最麻烦的状态问题摆到了台面上：事实日志、上下文投影、工具副作用、恢复边界、权限语义、Graph 调度。很多工具会把这些细节藏在"智能体自动完成任务"的叙述里，Maka 反而把账本和边界摊开给你看。

它现在还不是一个可以闭眼上生产的成熟平台。Apache incubating 状态、CLI 预发布、main 与 npm 包的命令漂移、局部测试失败、凭据本地明文存储，这些都需要认真对待。但如果你关心的是"Agent 真正在我机器上长期工作时，系统该怎么保存事实并安全恢复"，Maka 是一个值得读源码的项目。

对个人开发者，我的建议是从临时仓库和默认 ask 权限开始，把它当成可观察的 Agent 工作台试。对平台团队，Maka 更像一份活的架构样本：Runtime Host 管入口，SQLite 记事实，Graph 做调度，LLM 负责生成但不负责判定权威事实。这个分工，比再套一层漂亮 UI 更接近 Agent 工程的硬问题。