当 Agent 开始拥有可追溯的过去:Apache Maka 的事件日志架构、现实边界与工程启示

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

目录

一、长任务 Agent 的真正故障，不是断线，而是证据断裂

（一）一段对话无法代表一次执行

1、聊天记录缺少动作语义

2、崩溃会制造“副作用不确定区”

3、上下文窗口会造成“认知历史”和“执行历史”分叉

（二）三个经常被混为一谈的目标

1、可恢复不等于可重放

2、可重放不等于可审计

3、可审计不等于不可篡改

二、Maka 的核心改变：把事实、投影与执行权威拆开

（一）从“会话对象”转向“事件事实”

1、可变状态为何容易失去过去

2、追加式记录提供稳定坐标

3、事件粒度决定系统能回答什么

（二）“一个 Runtime Host”解决的是权威分裂

1、多个界面不能拥有多个真相

2、投影不是复制数据库，而是按用途读取

3、分支与重试因此获得更清楚的语义

（三）本地优先与自带模型的实际含义

三、上下文压缩的代际变化：让模型忘记，而不是让系统失忆

（一）三层对象必须分清

1、Runtime Events Log：语义事实层

2、History Compact Checkpoint：耐久的有损视图

3、Provider Request：一次性的工作上下文

（二）为什么必须压缩“有序前缀”

1、前缀让回放规则保持简单

2、工具调用与结果不能被拆开

3、摘要模型不能决定证据边界

（三）滚动 checkpoint 解决成本，却引入摘要漂移

1、不要反复总结整个世界

2、摘要仍然可能累积偏差

3、重新投影能力取决于写入端是否保存了足够事实

四、崩溃恢复的核心纪律：Resume Is Not Retry

（一）恢复流程的五个判断点

1、旧进程消失后，先修复终止边界

2、恢复器解释每个工具操作

3、宿主环境必须再次接受检查

4、安全时创建新的执行

5、证据不足时停放

（二）为什么幂等性仍然不可缺席

1、日志不能撤销外部世界

2、工具协议应暴露可恢复身份

3、文件操作也需要版本证据

（三）当前恢复能力应如何表述

五、安全边界：从逐工具询问走向会话执行边界

（一）权限提示不是 containment

1、基于命令文本的分类只能做交互辅助

2、真正的边界来自操作系统强制机制

3、覆盖范围比“是否支持沙箱”更重要

（二）会话边界比单次授权更可推理

1、边界扩张应成为持久事实

2、重启时未决请求必须失败关闭

3、Bypass 需要清晰的治理语义

（三）本地日志自身也是高价值敏感资产

六、与 LangGraph、Temporal 的比较：不要用一个维度排座次

（一）Maka 与 LangGraph：事件流和图状态快照解决不同层次的问题

1、LangGraph 的强项是显式状态图

2、Maka 的强项是 Agent 执行语义

3、二者可以组合而不是替代

（二）Maka 与 Temporal：Agent 证据工作台和耐久工作流引擎

1、Temporal 把 Event History 变成执行机制

2、Maka 更贴近模型请求与本地工具

3、Temporal 的严格性揭示 Maka 仍需补齐的部分

（三）一张更实用的选型表

七、真正的技术跃迁在哪里，又有哪些容易被夸大的地方

（一）值得肯定的四个跃迁

1、从“保存聊天”到“保存执行事实”

2、从“删历史”到“换投影”

3、从“恢复旧线程”到“创建新执行”

4、从“逐条弹窗”到“可持久执行边界”

（二）需要降温的四个宣传误区

1、“有事件日志”不代表所有输入都完整

2、“能恢复”不代表副作用可以自动继续

3、“本地优先”不代表数据不会出机

4、“Apache 孵化”不代表已获最终背书

八、落地判断：把 Maka 当作架构实验场，而不是即插即用生产底座

（一）当前最合适的使用方式

1、Agent 可审计性研究

2、个人或小团队的受控试用

3、评测与回放数据采集

（二）现阶段不建议直接承载的工作负载

1、不可重复的高风险外部动作

2、严格监管与长期取证

3、大规模跨主机调度

（三）企业 PoC 的建议验收清单

1、证据完整性

1.1 捕获链路

1.2 投影链路

2、副作用恢复

2.1 工具协议

2.2 恢复决策

3、安全边界

3.1 覆盖测试

3.2 旁路治理

4、数据治理与运维

4.1 数据生命周期

4.2 兼容性与指标

（四）一个可复用的四层参考架构

九、结语：Agent 的竞争将从“会做事”转向“能证明自己做过什么”

参考资料

干货分享，感谢您的阅读！

在 Agent 从“回答一次问题”走向“连续工作数小时”以后，真正稀缺的能力不再只是更强的模型或更多的工具，而是对执行历史的治理能力。一次长任务会跨越多轮模型调用、数十次工具动作、权限边界变化、上下文压缩、后台命令和人工干预。任何一个环节都可能让进程中断，也可能让系统在恢复时陷入一个危险问题：我们知道它停了，却不知道它停在“动作之前”“动作之后”，还是“动作已经发生但结果尚未记下”的缝隙里。

Apache Maka（Incubating）把这个问题放到了架构中心。它不是把聊天窗口当成工作台的全部，而是把模型消息、工具调用、工具结果、边界扩张、权限决策和终止事件记录为追加式执行事实。桌面端、终端界面、下一次模型请求、恢复流程，均从这些事实计算出各自需要的视图。这个选择的意义并不局限于“崩溃后还能打开会话”，而是试图给 Agent 建立一种可追溯的时间结构：已经发生的事情尽量不被后来的摘要、裁剪或界面状态覆盖。

但这并不意味着 Maka 已经完成了一个生产级事件溯源系统。公开仓库同时暴露出很有价值的现实张力：架构文档把 Runtime Event Log 定义为权威来源，而公开问题曾指出 Bash 输出、部分工具结果和请求时动态输入存在写入前截断或未完整快照的情况；恢复文档也明确区分已实现阶段与尚未接通的副作用核验、工作区检查点。Maka 最值得研究之处，恰恰不是它已经“解决了一切”，而是它把 Agent 系统中此前被对话界面掩盖的问题——证据完整性、投影合法性、副作用不确定性和安全边界覆盖——变成了可讨论、可测试的工程对象。

一、长任务 Agent 的真正故障，不是断线，而是证据断裂

（一）一段对话无法代表一次执行

1、聊天记录缺少动作语义

传统聊天产品保存的是“用户说了什么、模型回答了什么”。可执行 Agent 还需要回答更多问题：模型在回答前读过哪些文件？发出了哪个命令？工具返回值是否完整？某次写操作是否越过了工作区？用户批准的是单次动作，还是整个会话中的边界扩张？任务最终是成功、失败、取消，还是进程在没有终止事件时消失？

如果系统只保留最终对话，那么工具轨迹通常被压成几句自然语言。自然语言适合沟通，却不适合充当精确执行证据。模型可能说“测试全部通过”，但真实工具结果可能是“37 项通过、2 项跳过、1 项因网络超时未执行”；模型可能说“我没有修改配置”，但 Bash 可能已生成临时文件；界面可能显示“已停止”，但后台子进程仍在清理。复盘需要的不是一个更会讲故事的摘要，而是能够区分消息、意图、动作、结果与终止状态的结构化记录。

2、崩溃会制造“副作用不确定区”

设想 Agent 将 config.json 的端口从 3000 改成 4000。工具调用已经下发，进程随后崩溃，而日志中没有工具结果。至少存在四种可能：工具从未启动；工具启动但尚未落盘；文件已经写入，只是完成事件没来得及提交；文件写入后又被用户或其他进程改变。把这四种状态都视为“失败后重试”，可能重复发送邮件、重复付款、重复迁移数据；把它们都视为“已经成功”，又会制造虚假历史。

因此，恢复不是重启一个函数那么简单。它要求系统拥有工具调用身份、派发事实、完成收据、终止边界，以及对外部世界现状的检查能力。缺少结果只能证明“证据不完整”，不能证明动作没有发生。这个结论是长任务 Agent 与普通聊天机器人之间最重要的分水岭之一。

3、上下文窗口会造成“认知历史”和“执行历史”分叉

长会话必然超出模型可以高质量消费的上下文。简单做法是删除较早消息、截断大段工具输出，或把历史压成一段摘要。这样可以继续调用模型，却会让模型的工作记忆与系统的执行证据一起缩水。若摘要遗漏了一个精确路径、权限约束或失败命令，后续 Agent 不仅忘记它，开发者也可能再也找不到它。

更合理的做法是承认两种历史本就承担不同职责：执行历史负责“发生了什么”，模型上下文负责“这一次需要看到什么”。前者追求完整、稳定和可审计；后者受 token 预算、模型能力与当前目标约束，可以有损。二者若共享同一个可变数组，压缩上下文就等于销毁证据；二者若被分开，压缩只是重新计算一个视图。

（二）三个经常被混为一谈的目标

1、可恢复不等于可重放

可恢复可以只是：进程重启后读到最近状态，然后从某个安全点继续。可重放则更严格：给定历史与策略，系统能够重新构造当时的状态变化或请求输入。若工具输出在持久化前已经截断，系统仍可能恢复到“模型当时看到的截断结果”，却无法计算“如果当时采用更宽预算会怎样”。前者接近恢复级 WAL，后者才接近完整事实源。

2、可重放不等于可审计

确定性重放关注机器能否得到兼容结果；审计还关心人能否理解谁发起了动作、依据是什么、权限如何变化、敏感数据如何处理。一个事件序列即使技术上可重放，如果没有主体身份、策略版本、模型与工具 schema、外部资源版本，也很难支持合规复盘。

3、可审计不等于不可篡改

“追加式”描述写入模型，不自动等同于密码学防篡改。数据库中的旧行若仍可被高权限进程修改，日志只是按约定不更新，而不是具备独立证明能力。真正的防篡改还需要哈希链、签名、WORM 存储、访问控制、备份与外部时间戳等机制。Maka 的价值主要在于语义层的 log-first 设计，不能把它扩大解释为完整的取证级不可抵赖体系。

二、Maka 的核心改变：把事实、投影与执行权威拆开

（一）从“会话对象”转向“事件事实”

1、可变状态为何容易失去过去

许多 Agent 框架会维护一个不断增长的状态对象，其中包括消息列表、文件摘要、当前计划、工具缓存和权限标记。当窗口变长时，应用直接删除旧消息或用摘要替换；当节点执行结束时，再保存整个对象的快照。这个模型易于开发，但它把“当前最方便的工作状态”误当成“所有已经发生的事实”。任何一次原地修改都会让过去被现在覆盖。

这种方式并非一无是处。对短会话、无副作用的问答、明确节点边界的图工作流，它成本低、读取快、心智负担小。问题只在于一旦系统需要回答反事实问题——模型当时看到了哪个工具结果、换一种压缩策略会怎样、权限为何从只读变为可写——快照往往缺少足够的来源信息。

2、追加式记录提供稳定坐标

Maka 把模型消息、工具调用、工具结果和终止事实写入 Runtime Event Log，并把日志视为构建上下文与恢复状态的起点。事件的价值不只是“留档”，更在于提供有序身份：某个结果对应哪次调用，调用属于哪个 Run、Turn 和 Session，终止发生在什么边界，checkpoint 覆盖到哪一条事件。只有有了稳定坐标，系统才能讨论“覆盖前缀”“未覆盖尾部”“缺失结果”“后继 checkpoint”等问题。

3、事件粒度决定系统能回答什么

如果只在每轮对话结束时写一条记录，崩溃发生在工具执行中间时仍然无从判断。粒度细化到调用、派发、输出、完成与终止，恢复器才有可能区分明确未派发、已完成、状态未知与损坏。粒度越细，存储量、模式演进和查询复杂度越高；粒度越粗，审计与恢复能力越弱。Maka 选择贴近 Agent 语义的粒度，是它区别于普通会话持久化的核心。

（二）“一个 Runtime Host”解决的是权威分裂

1、多个界面不能拥有多个真相

Maka 的桌面端、TUI、CLI、评测入口和部分机器人表面都通过 Runtime Host 执行工作。这个安排看似只是后端复用，实际上解决了另一个常见故障：桌面端维护一套会话状态，CLI 又维护一套，评测框架直接绕过运行时调用模型，最终同一个“Agent”在不同入口拥有不同的工具、权限与事件语义。

统一执行权威意味着 Session 与 Turn 身份、Agent 生命周期、工具调用、边界协商和事件写入都由同一条后端脊柱负责。入口只提交意图、订阅事件并呈现结果。这样，界面故障不会自动变成执行事实丢失，评测也不需要发明第二套 Agent 行为。

2、投影不是复制数据库，而是按用途读取

从同一日志可以得到至少四类投影：界面投影关注可读时间线、搜索和分支；会话投影关注标题、归档与当前 Turn；模型上下文投影关注 token 预算、最近事件和工具配对；恢复投影关注终止边界、工具状态与安全继续条件。这些视图可以采用不同数据结构和缓存，也可以独立失效。

关键规则是：投影可以缺失，事实提交不能由投影伪装完成；投影损坏时，应从日志重建或失败关闭；投影若覆盖了一段历史，必须说明覆盖范围与来源摘要，而不能仅凭一个 checkpoint ID 宣称自己“代表过去”。

3、分支与重试因此获得更清楚的语义

在可变会话里，“重新生成”常常直接覆盖上一条答案；在事件模型里，更合理的做法是保留旧分支并追加新事实。重试也不应把旧 Run 改写为成功，而应创建新的 attempt 或新的 Run，并明确它来自哪个边界。这样，评测可以选择最早有效尝试，用户也能看到失败路径，而不是只留下最终看起来正确的结果。

（三）本地优先与自带模型的实际含义

Maka 的工作区状态、会话、工具结果和设置默认保存在本机，模型连接由用户配置，可以是云 API、本地模型或兼容网关。这个设计减少了中央服务对所有执行历史的天然占有，也让敏感项目更容易在本地边界内管理。

但“本地”不等于“离线”或“天然安全”。只要使用云模型、Web Search、MCP 或连接器，内容仍可能离开机器；本地凭据的安全取决于操作系统账户、文件权限和进程边界；日志越完整，留在本地的敏感证据也越集中。因此，本地优先应与数据分级、凭据管理、保留期限、脱敏和加密策略一起理解，而不是被当作单一安全标签。

三、上下文压缩的代际变化：让模型忘记，而不是让系统失忆

（一）三层对象必须分清

1、Runtime Events Log：语义事实层

这一层记录用户、模型、工具和运行时已经发生的事实。理想状态下，它不因后续模型窗口变小而改变，也不因 UI 只显示摘要而删除。它是审计、恢复和重新投影的共同来源。

2、History Compact Checkpoint：耐久的有损视图

Maka 的 compaction 不是把一段历史替换成裸摘要，而是形成带身份、覆盖边界、source digest、估算 token、局限说明和前驱关系的 checkpoint。文本型 checkpoint 保存 continuation summary；provider-native 类型可以保存由服务端生成的紧凑状态。两者都不是新的事实权威，只是对某个有序事件前缀的耐久投影。

覆盖信息极其重要。一个摘要如果没有说明它涵盖哪个 Session、多少事件、截至哪个 runId/turnId/runtimeEventId、源前缀摘要是否匹配，它只能算一条笔记，不能安全替代历史。Maka 通过覆盖前缀和 digest 把“摘要内容”与“被摘要的事实集合”绑定起来，这比单纯保存一段几千字的总结更接近可验证物化视图。

3、Provider Request：一次性的工作上下文

本次模型请求由可用 checkpoint、未覆盖事件尾部、当前用户消息、最新系统提示和工具定义共同物化。它只服务于当前决策，可以根据模型窗口、成本与当前目标改变。checkpoint 曾经适合某个模型，不代表换到更小窗口后仍然适合；因此进入请求前还需要再次接受当前策略校验。

（二）为什么必须压缩“有序前缀”

1、前缀让回放规则保持简单

如果 checkpoint 可以随意挑选散落事件，后续系统就必须解决复杂的洞、重复与因果配对。限定覆盖有序前缀后，请求可以表示为“checkpoint + 未覆盖后缀”。高水位只向前移动，滚动更新也能明确识别新增折叠的事件。

2、工具调用与结果不能被拆开

模型工具协议通常要求 call/result 成对出现。若预算裁剪只删除结果而保留调用，provider 可能拒绝请求；若只留下结果，模型又不知道结果来自什么动作。安全前缀选择必须避开尚未完成的事件、被固定保留的实时事件和不完整工具对。上下文管理不是普通字符串截断，而是维护协议合法性与因果完整性。

3、摘要模型不能决定证据边界

LLM 可以生成“目标、已完成、关键决定、下一步、精确路径与错误”的 continuation summary，但它不应决定覆盖到哪条事件、digest 是什么、checkpoint 是否已耐久提交，也不应决定近期尾部可以删到哪里。这些属于确定性 Runtime 代码的职责。换句话说，模型负责“怎样概括”，运行时负责“概括了什么、何时可用、何时失效”。

（三）滚动 checkpoint 解决成本，却引入摘要漂移

1、不要反复总结整个世界

长期会话会多次越过上下文高水位。每次都把所有旧事件重新送给摘要模型，会让 compaction 本身越来越昂贵。滚动方式让 checkpoint N+1 只消费 checkpoint N 与新被折叠的事件，再把 coverage 向前推进。这降低成本，也避免旧事实反复被不同模型重写。

2、摘要仍然可能累积偏差

滚动摘要不是无损编码。一次遗漏可能被后继摘要继承，一次错误归因可能变成后续模型的默认前提。source digest 只能证明 checkpoint 对应哪段源事件，不能证明自然语言概括百分之百正确。因此，系统需要在 UI 中标注 checkpoint 的有损性质，允许按需回看精确事件，并通过评测检查关键约束、路径和失败证据的保留率。

3、重新投影能力取决于写入端是否保存了足够事实

这里出现了 Maka 最值得警惕的实现边界。仓库公开问题 #615 曾指出，部分 Bash 输出在持久化前被行数或字节上限截断，某些后端也会在 ToolResultEvent 创建前限制文本长度；系统提示、实时工作区信息和工具 schema 可能只保存哈希而未快照内容。若这些情况存在，日志可以忠实恢复“当时已经被裁剪的视图”，却无法生成更宽松预算下的反事实视图，也难以字节级重建同一次请求。

这说明“投影时压缩”必须从源头贯彻：除有意的敏感信息脱敏外，预算、清理和裁剪应尽量发生在读取路径；超大输出可以存为内容寻址附件并在日志中保存引用；动态系统提示、工具 schema、策略参数和环境事实需要在请求时形成快照。否则，架构图上写着 canonical source，实际能力仍停留在 recovery-grade。

四、崩溃恢复的核心纪律：Resume Is Not Retry

（一）恢复流程的五个判断点

1、旧进程消失后，先修复终止边界

进程崩溃不会留下一个可以继续 await 的 Promise，也不能复活旧 socket、JavaScript 栈或 OS 子进程。启动恢复首先需要把永久停留在 running 的旧 Run 变为明确终态，并追加对应终止事实。这个动作只是在历史上封口，不代表未完成工具已经失败或成功。

2、恢复器解释每个工具操作

恢复器应根据事件组合把工具状态分类为已完成、明确未派发、未知、停放或损坏。只有明确未派发的动作才可能安全重新下发；已完成动作应使用已有结果；未知副作用不能由模型一句“应该没执行”提升证据等级。模型自述是线索，不是执行收据。

3、宿主环境必须再次接受检查

即使事件序列合法，当前工作区、工具目录、后台任务和边界策略也可能已变化。会话恢复不能只检查“是不是同一个路径”，还要考虑文件是否被外部改动、工具版本是否漂移、后台命令是否仍在运行、沙箱边界是否与先前一致。工作区身份只能证明位置相同，不能证明内容未变。

4、安全时创建新的执行

通过检查后，Resume 应创建新的 Run、Invocation 和 Turn，并记录它从哪个源边界继续。这样旧执行的终止事实保持不变，新执行拥有独立身份、用量、失败原因和审计链。把旧 Run 改回 running 会抹去崩溃本身，并让计费与追踪变得混乱。

5、证据不足时停放

“停放”不是体验失败，而是副作用系统的安全输出。它意味着系统保留事实、拒绝盲目继续，并等待人工核验或更强证据。成熟的 Agent 平台不应把所有中断都包装成无缝恢复；它应能清楚表达“这里无法证明，继续可能重复产生外部效果”。

（二）为什么幂等性仍然不可缺席

1、日志不能撤销外部世界

追加式记录可以告诉我们调用过支付 API，却不能自动撤回支付；可以记录发送邮件的请求，却不能保证服务端没有在超时前完成发送。任何跨进程、跨网络副作用都需要业务侧幂等键、操作收据、查询接口或补偿动作。

2、工具协议应暴露可恢复身份

理想工具调用包含稳定的 invocation ID、目标资源版本、幂等键与可查询状态。工具返回不仅有文本，还应有结构化 outcome、外部 receipt ID、变更摘要和可验证的 postcondition。这样，崩溃后系统可以查询“调用 123 是否已完成”，而不是再次执行同一动作。

3、文件操作也需要版本证据

文件写入看似本地，仍可能遇到并发修改、部分写入和符号链接逃逸。恢复时若只比较路径，无法判断内容是否一致。更强方案可以记录写入前后哈希、原子替换结果、Git commit/worktree 身份或受控工作区 checkpoint。Maka 的恢复文档将完整工作区检查点与重基线列为后续阶段，说明当前“可恢复”仍有明确边界。

（三）当前恢复能力应如何表述

仓库 README 宣称具备耐久执行记录、崩溃恢复和可选的中断 Turn 继续；同时明确安全边界恢复默认关闭，启用后会再次调用模型并消耗 token。恢复架构文档则指出基础阶段、恢复事实写入权威与 Resolver 已实现，但生产级副作用 reconciler、文件证据、完整 host-owner 生命周期，以及 Git 检查点与隔离恢复仍未全部完成。

因此，更准确的评价是：Maka 已经建立了恢复所需的语义骨架，并实现了部分安全边界继续，但尚不能把所有工具副作用自动判定为可重放。它比“重开应用继续聊天”严谨得多，却还不是 Temporal 那类经过大规模生产验证的通用耐久执行基础设施。

五、安全边界：从逐工具询问走向会话执行边界

（一）权限提示不是 containment

1、基于命令文本的分类只能做交互辅助

早期 Agent 常通过正则或前缀判断命令是否危险，再决定是否弹窗。问题是同一副作用可以用无数方式表达：sed -i、Python 一行脚本、构建钩子、包管理器生命周期脚本都可能修改文件。即便分类正确，模型也可能用社会工程式理由诱导用户批准。权限提示可以降低误操作，不能成为对抗恶意模型的唯一边界。

2、真正的边界来自操作系统强制机制

Maka 当前安全策略明确把 OS 用户账户视为外层信任包络，并在受限 managed ExecutionBoundary 下，将部分 Agent 工具效果路由到操作系统强制的子进程沙箱：macOS 使用 Seatbelt，Linux 使用 bubblewrap，Windows 的 AppContainer 目前覆盖专用文件系统 worker。要求沙箱却无法提供时，相关路径应失败关闭，而不是静默回退宿主机执行。

3、覆盖范围比“是否支持沙箱”更重要

非 PTY Bash、文件工具、managed PTY、集成终端、Bypass 与 external profile 的行为并不相同。受限边界下的 managed PTY Bash 可能被拒绝；客户端集成终端是宿主 PTY，不在 Agent 管理边界内；Bypass 不添加 Maka 本地沙箱；external 依赖调用方提供隔离。对企业评审而言，必须形成“平台 × 工具表面 × 边界模式 × 网络/文件/进程能力”的矩阵，不能用一个绿色勾表示全部安全。

（二）会话边界比单次授权更可推理

1、边界扩张应成为持久事实

Maka 的方向是让会话 ExecutionBoundary 成为执行权威：普通工作在 Auto 的受控范围内运行，只有跨越当前 profile 时才请求扩张；用户批准的是明确路径或网络能力的边界变化，而非模糊的“一次允许”。边界具有 revision，扩张请求带 session、turn、run 与理由，并在重启后仍可解释。

2、重启时未决请求必须失败关闭

若应用在权限对话框出现后崩溃，系统不能在重启时猜测用户会点击允许。未决边界请求应以 host_restarted 等原因持久结算为拒绝，并让恢复器把这个事实归因到相应 Turn。这个细节说明事件日志不仅记录业务动作，也承担控制平面的一致性。

3、Bypass 需要清晰的治理语义

任何允许用户关闭沙箱的产品都需要明确：Bypass 适用于可信且已有外部隔离的环境；进入动作必须显式、可见并可审计；非交互模式不能悄悄扩张权限；企业部署应能够禁止或集中治理 Bypass。否则，“默认安全”会被一个便利开关轻易消解。

（三）本地日志自身也是高价值敏感资产

完整工具结果可能包含源代码、数据库片段、内部 URL、个人信息和访问令牌。Maka 对部分秘密采用写入前脱敏是合理例外：为了可重放而把明文秘密写入磁盘，代价往往不可接受。但脱敏也会降低精确重放能力，因此应记录“发生过脱敏”与不确定性边界，同时避免存储可逆片段。

企业落地还需要补齐静态加密、密钥轮换、按项目保留、按主体访问、导出审批与安全删除。追加式不意味着无限期保留。一个成熟系统应把热事件、冷附件、审计索引和敏感字段分层存储，在满足调查需求的同时控制泄露半径与存储膨胀。

六、与 LangGraph、Temporal 的比较：不要用一个维度排座次

（一）Maka 与 LangGraph：事件流和图状态快照解决不同层次的问题

1、LangGraph 的强项是显式状态图

LangGraph 通过 checkpointer 持久化线程的图状态快照，用于会话连续、人机协同、time travel 和容错；Store 则保存跨线程的长期数据。应用开发者显式定义节点、边和状态 reducer，适合构建结构化流程。使用持久 checkpointer 后，进程重启仍可恢复 thread 状态。

2、Maka 的强项是 Agent 执行语义

Maka 更靠近通用本地 Agent 工作台：模型消息、工具调用、结果、终止与执行边界都是平台内建语义，桌面端和 CLI 共用 Runtime Host。它不要求用户先把任务完整建模为图节点，因而更适合开放式代码与知识工作；对应代价是动态 Agent Loop 的恢复和副作用判定更难。

3、二者可以组合而不是替代

一个企业系统可以用 LangGraph 表达审批与业务节点，用 Maka 式细粒度事件记录每个 Agent 节点内部的工具证据。选择关键在于恢复边界：如果业务认为“节点完成”是最小事实，checkpoint 足够；如果需要回答节点内部哪个命令改变了什么、用户为何放宽边界，就需要更细的事件层。

（二）Maka 与 Temporal：Agent 证据工作台和耐久工作流引擎

1、Temporal 把 Event History 变成执行机制

Temporal Service 通过追加 Event History 跟踪 Workflow Execution，并依赖历史恢复崩溃后的应用状态。Workflow 代码必须保持确定性，外部副作用通过 Activity 等机制隔离，代码升级还需要 versioning、patching 与 replay testing。它提供的是一套通用、分布式、服务化的耐久执行体系。

2、Maka 更贴近模型请求与本地工具

Maka 的事件包含 provider history、工具证据、上下文 compaction 和交互边界，面向模型驱动工作；部署上本地优先，不要求先运营一套工作流集群。它降低了个人开发者研究 Agent 可审计性的门槛，也使桌面交互、文件预览和模型连接成为一等能力。

3、Temporal 的严格性揭示 Maka 仍需补齐的部分

Temporal 强调确定性、Activity 重试、历史大小限制、Continue-As-New、Worker 版本和历史回放测试。这些概念提醒 Agent 平台：日志无限增长需要代际切分；代码和投影策略变化需要兼容性测试；外部动作需要幂等与收据；恢复不能依赖当前代码“碰巧还能读懂旧事件”。Maka 不必复制 Temporal 的全部复杂度，但生产化时绕不开同类问题。

（三）一张更实用的选型表

七、真正的技术跃迁在哪里，又有哪些容易被夸大的地方

（一）值得肯定的四个跃迁

1、从“保存聊天”到“保存执行事实”

这改变了产品能够回答的问题。系统不再只展示一段自然语言回忆，而能围绕工具调用、权限和终止建立证据链。对开发、评测和安全审计都具有基础价值。

2、从“删历史”到“换投影”

把 context compaction 定义为日志上的有损物化视图，使模型窗口策略可以演进，而不必同步销毁历史。coverage、digest、lineage 和 replay gate 让摘要从随意文本升级为可验证投影。

3、从“恢复旧线程”到“创建新执行”

Resume 不复活旧进程，而是封口旧 Run、解释工具状态、检查宿主条件，再创建新 Run。这一语义能保留崩溃事实，也避免把重试伪装成恢复。

4、从“逐条弹窗”到“可持久执行边界”

会话边界把权限变化变成可版本化事实，并让操作系统沙箱承担实际约束。相比不断要求用户判断复杂命令文本，这更接近可推理的安全模型。

（二）需要降温的四个宣传误区

1、“有事件日志”不代表所有输入都完整

写入前截断、动态系统提示未快照、工具 schema 只存哈希，都会降低重投影能力。评价系统时应检查 capture completeness，而不是只看数据库表名或架构图。

2、“能恢复”不代表副作用可以自动继续

只要外部动作缺乏幂等键、收据和查询接口，崩溃后就可能存在未知状态。安全停放是正确行为，而不是一个需要被 UI 隐藏的错误。

3、“本地优先”不代表数据不会出机

云模型、搜索、连接器、遥测和更新都可能产生网络流量。必须按能力表面核查 egress，而不是从“会话存本地”推导“任务全程离线”。

4、“Apache 孵化”不代表已获最终背书

Apache Incubator 状态页显示 Maka 于 2026 年 8 月 13 日进入孵化。孵化说明项目正在接受治理、基础设施与社区成熟度审查，不代表代码已经稳定，也不等于 ASF 已完成正式认可。仓库 README 明确表示目前尚无正式 Apache release，现有包或安装器不能被当作经 Incubator PMC 投票批准的发行版。

八、落地判断：把 Maka 当作架构实验场，而不是即插即用生产底座

（一）当前最合适的使用方式

1、Agent 可审计性研究

Maka 很适合作为事件类型、上下文投影、恢复分类与边界协商的参考实现。团队可以通过它验证“我们到底需要记录哪些事实”“一次恢复需要哪些证据”“摘要如何声明覆盖范围”，再决定是否在现有 Agent 平台中引入类似机制。

2、个人或小团队的受控试用

在非生产代码库、独立 OS 账户、无高价值凭据、可回滚 Git 工作区中试用，可以观察长任务、分支、恢复与沙箱行为。应使用最小权限模型连接，关闭不必要的实验能力，避免将 Bypass 当作默认便利模式，并定期备份工作区数据。

3、评测与回放数据采集

细粒度事件对评测很有价值：不仅能比较最终分数，还能分析工具次数、失败分类、成本、时长、证据覆盖和边界请求。但若要做严格反事实评估，需要先验证大输出是否完整保存、请求形状是否可复现、模型与工具版本是否快照。

（二）现阶段不建议直接承载的工作负载

1、不可重复的高风险外部动作

付款、生产数据库迁移、批量消息、账号权限变更等任务，一旦重复或误判就会造成真实损失。除非工具层具备完善幂等、审批、收据、补偿和独立审计，否则不应依赖 Agent 自身恢复判断。

2、严格监管与长期取证

医疗、金融、政务等场景通常要求强身份、不可抵赖、保留策略、数据驻留、法务冻结和审计导出。追加式语义只是起点，还需密码学完整性、集中访问控制与合规运营体系。

3、大规模跨主机调度

Maka 的本地工作台定位与 Temporal 的服务化工作流定位不同。若目标是跨区域、跨服务、成千上万长流程的 SLA、队列与容灾，成熟工作流引擎仍更合适；可以在其中嵌入 Agent 节点，而不是让桌面 Runtime 取代整个调度平面。

（三）企业 PoC 的建议验收清单

1、证据完整性

1.1 捕获链路

• 随机抽取长输出工具，验证磁盘事实与工具真实输出的截断边界；

• 保存模型、provider、系统提示、工具 schema 与有效策略版本；

1.2 投影链路

• 检查 checkpoint 的 coverage、digest、lineage 与失效行为；

• 确认导出内容可解释当时模型实际看到的请求形状。

2、副作用恢复

2.1 工具协议

• 为每个有副作用工具定义 invocation ID、幂等键和外部收据；

• 构造“动作完成但完成事件未提交”的故障注入；

2.2 恢复决策

• 验证未知状态会停放，而不是静默重试；

• 检查用户在恢复前修改工作区时，系统是否拒绝不安全继续。

3、安全边界

3.1 覆盖测试

• 按操作系统分别测试 Bash、文件工具、PTY、集成终端与连接器；

• 验证沙箱不可用时失败关闭；

3.2 旁路治理

• 限制 Bypass，并记录进入与退出；

• 检查网络、临时目录、符号链接、子进程和凭据暴露范围。

4、数据治理与运维

4.1 数据生命周期

• 定义事件与大附件的保留、归档和删除策略；

• 对敏感结果实施脱敏与静态加密，并记录信息损失边界；

4.2 兼容性与指标

• 建立 schema 迁移、备份恢复和历史回放测试；

• 监控日志增长、compaction 成本、恢复停放率和边界扩张率。

（四）一个可复用的四层参考架构

团队不必完整采用 Maka，也可以吸收其核心原则，构建四层结构：第一层是语义事件层，只追加调用、结果、边界和终止事实；第二层是内容寻址附件层，承载大输出、截图、补丁与请求快照；第三层是确定性投影层，生成 UI、搜索、计费、恢复和模型上下文；第四层是执行控制层，负责幂等、沙箱、审批与补偿。

这四层之间应有清晰契约：事件引用附件而不是塞入无限文本；投影声明 source coverage 与版本；执行控制把外部收据写回事件；任何无法证明的恢复状态都进入人工队列。这样，即使使用完全不同的 Agent 框架，也能获得“事实稳定、视图可变、边界可证”的基本属性。

九、结语：Agent 的竞争将从“会做事”转向“能证明自己做过什么”

Maka 提出的最重要问题，不是怎样让 Agent 再多跑几个工具，而是怎样让一次执行拥有可追溯的过去。追加式事件日志把时间从 UI 的滚动列表中解放出来：历史不再只是供人阅读的聊天，而是恢复、投影、审计和评测的共同基础。上下文压缩也因此不必和销毁证据绑定；模型可以只看一份适合当前决策的工作视图，系统仍保有查证与重算的可能。

更深一层看，Agent 不是确定性工作流。模型输出会变，工具会产生外部副作用，系统提示与工具目录会漂移，环境在崩溃期间也可能继续变化。因此，事件溯源不能单独解决一切。它必须和请求快照、内容寻址附件、幂等协议、工作区版本证据、OS 强制沙箱、schema 迁移和人工停放机制结合。日志提供的是回答问题的基础，不是问题已经被回答的证明。

截至研究快照日期，Maka 已经把许多正确概念落实为具体对象：统一 Runtime Host、RuntimeEvent、带 coverage 的 compaction checkpoint、RecoveryResolver、持久执行边界与平台化沙箱矩阵；与此同时，仓库公开问题和架构文档也诚实保留了未完成部分。它最适合被视为快速演进的架构实验场和参考实现，而非无需验证即可承载关键业务的生产底座。

未来真正可靠的 Agent 平台，竞争力不会只来自更高的任务成功率。它还要能回答：模型当时看到了什么？动作是否真的发生？权限由谁、在什么范围内批准？上下文为何省略了某段证据？崩溃后为什么选择继续或停放？当系统能够用稳定事实回答这些问题时，Agent 才从“会调用工具的模型”迈向“可运营、可治理的执行系统”。

参考资料