Kitaru借MLOps机制实现Agent持久执行

ZenML 的 Kitaru 项目尝试把机器学习运维（MLOps）的基础设施搬到 Agent 执行过程中：记录状态、保存版本化产物，并支持从检查点回放。按现有节选，它关注的是 Agent 出错后如何追溯与恢复，让一次运行留下可检查的执行记录。

目前能确认什么

节选将 Agent Harness 定义为运行时包装层，放在 Agent 代码与执行环境之间，负责捕获状态变化、工具调用和决策节点，不规定 Agent 必须采用哪种架构。

它借用了 MLOps 的几个常见机制：把中间结果保存为带版本的产物，用执行图描述步骤关系，通过链路追踪串起调用过程。对于会循环、会分支的 Agent，节选描述的做法是把每轮迭代作为流水线步骤，让执行图动态增长。

回放也有区别：可以重新执行，可以复用已保存的工具结果，也可以从某一步修改输入，观察后续路径如何变化。节选还提到通过 OpenTelemetry 输出追踪数据。

保存执行记录，不等于保证再次运行得到相同结果。

我的判断

对程序员来说，最有用的场景是定位长任务中的失败：保留失败前的上下文，只重跑需要验证的后续步骤。比较两次执行在哪里分叉，也比单看最终回答更容易定位问题。

但恢复执行还有一道具体门槛：工具可能已经发出了消息、创建了订单。缓存返回值能避免部分重复调用，却不能自动解决外部操作是否完成、能否重复的问题。节选没有交代这类副作用的处理规则。

远程模型和实时 API 也未必能还原到原来的状态。记录响应有助于重建历史，重新请求则可能走向另一条路径。检查点边界、状态保存范围，以及示例中的 AgentHarness API 是否属于正式可用接口，都还需要官方文档确认。