用Rust重新定义Agent运行方式：一个能断点续跑、可全程回放的Agent框架

当Agent开始承担越来越复杂的长期任务时，一个致命的问题浮出水面：一旦进程意外崩溃或被手动中断，长达数十分钟积累的上下文、读过的文件、做了一半的修改全部归零。这种痛点在Agent越强大的情况下反而越难以忍受——能干意味着任务时间长，时间越长风险越高。 近日，一个基于Rust实现的Agent运行时框架引发了技术社区的关注。该框架借鉴了DeepSeek Harness的设计思路，尝试从根本上解决Agent运行时的可靠性和可观测性问题。

事件日志：唯一的真相来源

传统Agent框架的起点通常是一个简单的二十行循环：调用模型、遇到工具调用则执行、将结果拼回消息列表。这个模式能工作，但对话状态散落在内存的多个变量中，没有任何一方拥有完整的记录。框架提到的四个核心能力——对话进度与进程解绑、全程可回放、出事不连坐、插件化架构——本质上都在呼唤同一个基础设施：一份权威的、只追加不修改的事件日志。 这个框架的设计哲学是：框架的中心就是事件日志，所有操作都向日志追加，用户消息、模型输出的每个增量、每次工具调用和结果、每次发往模型的完整请求各占一条。我们熟悉的消息列表并不单独存在，它是重放日志计算出来的结果，只在需要发送给模型时才生成一份，用完即丢弃。这种设计直接带来了两个核心能力：可审计和可恢复。

六个步骤构建完整回合

日志里包含专门的request/header事件，将系统提示、工具清单、模型参数原样落盘。想知道模型当时到底看见了什么，查日志就有答案，没有靠猜测的成分。 更重要的是，框架在每次发请求前都会进行自检验证，确保即将发出的请求必须能从日志重放出来，一字不差。任何代码路径想偷偷往消息里塞东西，或者改了系统提示却没记事件，这里直接报错。这条自检在开发期拦下过好几个潜在的bug，是整个设计里性价比最高的一行代码。 在进程解绑能力的验证实验中，当Agent从1数到300时，使用SIGKILL信号强制终止进程（连清理代码都没机会执行），然后恢复同一会话并继续执行。结果显示，Agent能够精确地从被杀位置继续计数，最终完整输出1到300。这种「进程变成了一次性的，对话不是」的设计，让长时间运行Agent任务变得真正可行。

消息收件箱的精细设计

完整的Agent执行流程分为六个精心设计的步骤。 第一步是消息进收件箱。用户输入不直接进入对话，而是先进一个带状态的Inbox。Inbox内部只有两个槽位：NextTurn（下一个回合处理）和NextStep（当前回合下一步处理），由此派生出三种投递语义——followup将消息排进下一回合，steer插队到当前回合的下一步，inject安静等待直到唤醒消息出现。每次收件箱变动都以splice事件落盘，记录插入位置、删除数量和消息全文。 第二步是组装上下文。系统提示由注册表拼装而成，包含静态部分（身份、规则）和动态部分（工作区路径、召回的记忆）。动态部分有严格的纪律：内容没变就不重发。这样可以避免同一份工作区说明被反复塞进对话，白白消耗宝贵的上下文窗口。

工具调度的有序性保证

第三步是发请求前先落盘。请求头作为事件写入日志后，适配器发起真正的SSE流。适配器把provider的增量流映射成框架内部的块协议：每个内容块以BlockStart开场，中间是TextDelta或ToolCallDelta增量，收尾的BlockEnd事件带着装配完成的完整块。增量用于实时渲染，完整块用于组装最终消息，同一个流服务两个消费方。 第四步是工具调度。模型一次可能发起多个调用，框架按工具自报的执行模式分类：只读操作（read、search）进入并行批，互斥操作（shell、写文件）排队串行。并行批用信号量限流，用FuturesUnordered收集，谁先完成就先回填自己的坑位。关键规则是：执行可以乱序，提交必须有序。工具结果必须按模型发起调用的顺序写入日志、拼进对话。如果按完成顺序提交，同一段代码在不同机器上会产生不同的对话历史，日志重放也就不可复现。 第五步是闭合括号。回合的骨架是turn/start到turn/end的一对事件，中间嵌着step/start和step/end。无论体面结束、被取消还是出错，turn/end都带着原因写入日志。括号里的内容可以有残缺

如有侵权，请联系删除。