最近在开发一个开源 Agent 项目 Maka ，想来 V2EX 分享一下，顺便听听大家的意见。
项目地址： https://github.com/maka-agent/maka-agent
欢迎大家 star 和 阅读学习。
先说数据，不吹：项目 5 月 27 日创建，到今天正好 7 周，666 star ，70 fork 。过去 9 天（ 7.6-7.14 ）提交了 300 个 commit ，111 个 fix ，103 个 feat ，日均 33 个 commit 。核心贡献者两三人，其余是陆续加入的社区开发者。
这是个什么东西
市面上 AI Desktop 已经很多了，Maka 想解决的不是"聊天界面好不好看"，而是一个更底层的问题：Agent 执行的过程，要不要被当作一等公民保留下来。
大多数 Agent 工具的模式是：用户提问 → 模型执行一堆 tool call → 给一个最终答案，中间过程用完就丢。任务成功了皆大欢喜，失败了只剩一个 pass/fail ，过程里发生了什么、模型看到了什么、系统实际留下了什么证据——都没有了。
Maka 的做法是把这条主线做成系统骨架：
Runtime Event Log → Context/Session/UI 投影 → Task Event Log → TaskRun → Self-check/AHE 证据
模型消息、Tool Call 、Tool Result 、任务终止事实，全部先写入一份只增不改的 Runtime Event Log ，然后 UI 、上下文、恢复能力都是这份 log 上的投影（ projection ），而不是各自维护一份状态。
有个内部同学写过一句话我很喜欢：Maka preserves experience as evidence （ Maka 把经验当作证据保存下来）。
几个具体的技术点
-
Tool Result pruning + Compaction：上下文会被裁剪和压缩，但裁剪的是"下一次推理看到什么"，不是删除已经记录的历史事实。日志和上下文是两回事。
-
Headless + Task Event Log：一个任务可以比一次 Turn 、一次进程生命周期更长。可以中断、恢复、导出证据，这对做长程/无人值守任务是刚需。
-
Self-check 不是 authority：模型自己说"我做完了"不算数，需要独立的验证逻辑来判断，防止 agent 自己给自己批卷子。
-
AHE （自动化经验演化）：让系统从历史运行记录里迭代自身（比如 prompt 、策略），但刻意设计了很多约束——candidate 必须绑定 target snapshot 、不能篡改 runtime evidence 、必须声明失败证据和风险——避免滑向"让模型随便改 prompt 然后看分数"的老路子。
跑分数据（已经跑完的，不是画饼）
用 Maka + DeepSeek Flash V4 跑 terminal-bench sample （ 10 道编程 Agent 任务）：
- 总 token 消耗 6000 万，其中 5850 万命中 cache （ 97.5% 命中率）
- 花费约 4 元人民币
- 分数 0.8-0.9
这个成绩不是因为模型变强了，是 agent loop 里 self-check 机制的两轮迭代带来的。模型能力有上限，但 harness 工程质量能大幅影响模型在具体任务上的实际表现。
社区速度（这个我觉得挺值得说）
过去两天，有个同学建了个 issue ，说想把 provider 支持对齐 models.dev 全量列表，然后写了句"一个 provider 一个 PR ，欢迎认领"。结果两天内社区陆续提交了 20 多个 provider 支持：Cloudflare Workers AI 、Hugging Face 、Vercel AI Gateway 、Cohere 、Mistral 、xAI 、Together AI 、国内的火山方舟/腾讯/StepFun 系列等等。不是核心团队自己肝出来的，是路人开发者认领 PR 刷出来的。这种自发生长的状态是我最喜欢这个项目现在的地方。
坦白说还不够好的地方
Runtime 这套设计目前的问题是：思想的先进程度已经超过了产品闭环和新手上手体验。 概念是对的，但对一个第一次接触的开发者来说，"五分钟跑起来、看清楚一次 Agent Run 长什么样"这件事还没做顺。这是接下来要优先补的。
如果你对 Agent 底层架构、long-horizon task 、上下文管理这些方向感兴趣，欢迎来看看代码或者提 issue 。项目还在快速迭代中，欢迎拍砖。
Select Language