天津
智猩猩AI整理
编辑： 没方
把现在大多数 Agent 拆开看，会发现它们的底层逻辑其实还很“聊天机器人”。
用户发消息，模型调用工具，工具返回结果，再把这些内容继续塞进 Session。
如果只让 Agent 改几个文件、跑一次测试，这些小活问题不大。可一旦任务从 5 分钟拉长到半小时甚至几小时，事情就开始变复杂了。
程序崩了以后从哪里继续？某个 Tool 到底执行没执行？上下文压缩以后，被模型忘掉的执行结果还算不算“事实”？如果一条有副作用的命令已经跑过一次，重启后怎么避免重复执行？
这些正是 Maka 想解决的问题，它是 Apache 孵化器接纳的第一个 Agent Harness 项目，最近还登顶 GitHub 趋势榜。
和很多 Harness 主要追求模型打榜性能不同，Maka 更想从底层重构现有Session-based Agent的运行方式。
01
使用教程
在仓库中下载对应的安装包，目前Mac系统的桌面版做的比较完整，Windows还有部分功能还不支持：
安装完，打开后界面长这样，它会自动配上OpenCode上的免费模型：
Maka 自带的能力已经覆盖了一个完整 Agent 工作台所需要的主要环节。
除了可以配置和切换不同模型，它还内置子 Agent、记忆、远程接入和联网搜索能力，能够把复杂任务拆分执行，并在长期保留必要信息。
我让它帮忙看X上的推文：
它能准确的输出我想要的结果：
同时，Maka 还提供使用统计、已归档任务、任务导入和每日回顾，方便用户追踪和复盘 Agent 的工作过程。
在系统层面，它还集成数据管理、权限与能力控制以及健康检查，可以统一管理 Agent 能访问哪些资源、调用哪些工具，以及当前运行状态是否正常。
02
和 Pi Harness v2 撞车了：
Agent 最后又走回数据库
更有意思的是，Maka 的核心开发者jakevin发现，Pi 新公布的 Harness v2 架构，和 Maka 已经采用的设计思路高度相似。
Jakevin 在 X 上感叹：
“Pi 的新架构和 Maka 告诉我们，Harness 的答案早就在数据库论文里了。”
按照他的总结，两套系统背后的主线几乎都是：持久化事实 → 派生运行状态 → 派生模型上下文 → 派生 UI → 崩溃以后重新归约。
这种设计思路其实和数据库里的 Write-Ahead Logging 很像。
数据库在真正修改磁盘数据之前，会先把准备做什么写进日志。这样即使中途掉电，重启以后也能根据日志判断哪些操作完成了，哪些操作需要恢复。
更巧的是，Maka 这支团队本身就带着很浓的数据库背景。
jakevin 过去长期做数据库，曾在字节跳动数据库团队、SelectDB 等公司工作，也是多个 Apache 数据库/数据基础设施项目的核心开发者。Maka 仓库里的其他主要贡献者，也有不少来自数据库、查询引擎和分布式系统方向。
Maka 没有把重点只放在“怎么让模型多想几步”，而是在反复处理另一类问题：状态怎么持久化、执行事实怎么记录、崩溃以后怎么恢复、副作用怎么避免重复执行、长任务怎么保证一致性。
这些问题听起来像 Agent 的新问题，但其实就是数据库和分布式系统过去几十年一直在解决的问题。
以前保证事务不要丢，现在开始保证 Agent 的一次工具调用不要丢。以前恢复数据库状态，现在开始恢复 Agent 的任务状态。
从这个角度看，Maka 和 Pi Harness v2 的“撞车”或许并不偶然。
当 Agent 真正从聊天机器人走向长时间运行的软件系统之后，大家最后都不得不重新面对日志、状态、恢复、一致性和副作用这些老问题。
Agent Harness 往下走，也越来越像一门新的数据库与运行时工程。
关注+星标，获取AI前沿进展与开源一线动态
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
