@jakevin7: Pi 和 Maka 独立地收敛到了相同的运行时架构。有趣之处在于我们不同的地方。当Pi…

X AI KOLs Timeline 新闻
runtime-architecture crash-recovery concurrency agent-harness event-sourcing durable-workflow open-source

摘要

两个AI代理系统，Pi和Maka，在相似的运行时架构上收敛，但在崩溃恢复等关键领域有所不同，展示了持久工作流设计中的不同权衡。

Pi 和 Maka 独立地收敛到了相同的运行时架构。有趣之处在于我们不同的地方。 当 Pi 的 harness v2 文档发布时，我们吃了一惊——它几乎精确地描述了我们构建到 Maka 中的管道： 持久事实 → 运行状态 → 模型上下文 → 用户界面 → 崩溃后重新缩减 同样的工具边界：持久化意图 → 执行效果 → 持久化结果。 我们让一个代理逐行对比了两个架构文档。总体相似度约 50%；“日志是真相，状态是投影”和“工具副作用边界”都达到了约 80%。但没有共享的术语、类型名称或文档结构——而意图先于效果的模式只是标准的 WAL / Saga / 事件溯源 / 持久工作流实践。 时间线，不加解释地陈述：Maka 的日志优先运行时章节发布于 2026-07-12。Pi 的 harness-v2.md 首次提交于 2026-07-29。 我宁愿将此视为收敛。当两个不相关的团队从不同方向到达同一个地方时，方向可能是正确的。代理 harness 层正在形成共识——而这种共识借鉴了操作系统和数据库。预写日志、事件溯源、持久操作。这些都是几十年前的想法。 分歧才是有趣的部分。 在崩溃恢复上，我们做出了相反的决定： Pi：原始操作保持挂起；resume() 继续它。声明为可重放的工具在恢复时可能重新执行。 Maka：首先将旧的 Run 封闭到终态。Resume 永远不会恢复它——它会创建一个新的 runId / invocationId / turnId。如果 T1 存在但 T2 缺失，状态是不确定的，我们**停靠而不是根据通用的工具级别安全声明重新运行**。 Pi： 恢复持久操作 Maka： 关闭旧尝试 → 证明安全 → 创建延续 并发性也不同。Pi 的通道就像共享对话树上的 git 分支——并行单元是一个会话内的通道。Maka 允许每个会话最多一个根执行；并行性来自单独的子会话，代理图作为持久调度控制平面位于运行时之上。 哪个更好？我认为没有普遍的答案。Pi 的路径恢复更快，并保持更一致的思维模型。我们的更保守——更重的 resume，以换取永不重复无法证明安全的外部副作用。 我们团队中有人今天说得好：软件工程中没有银弹。重要的不是收集聪明的设计，而是知道这种权衡对于你实际定义的问题是否可接受。 Maka 选择了 fail-closed，因为我们赌的是具有真实副作用的长期运行任务——其中重新运行一次的成本远比过于谨慎地恢复一次高得多。 Apache Maka (Incubating) ·
查看原文
查看缓存全文

缓存时间: 2026/08/25 08:09

Apache Maka（孵化中）

在 Apache 软件基金会孵化

一个为实际工作构建的本地优先智能体工作站。Maka 能够检查项目，在沙箱边界内运行工具，并将模型消息与工具调用记录为可恢复的执行记录——所有操作均在您的机器上，通过单一运行时主机完成。

相似文章

@jakevin7: Maka 这两天密集冲刺，最值得关注的东西出来了。 Autonomous Task Loop v1 上线。 之前 maka 跑一次 agent 就结束。现在是一个持久化循环： preflight → runtime → SelfCheck…

X AI KOLs Following

Maka 发布 Autonomous Task Loop v1，实现了 agent 的持久化循环：preflight → runtime → SelfCheck → FeedbackObservation → Decision，支持自我检查、预算控制和状态恢复，使 Maka 桌面 AI 工作台具备了运行持续任务的基础能力。