案例分析一：Coding Agent 为什么必须保存 State——一次中断后还能不能继续？

场景背景

假设我们的 Coding Agent 正在执行，“修复项目启动错误，并验证测试。”

它已经完成：

Step 1：list_files
Step 2：read_file("src/main.py")
Step 3：read_file("requirements.txt")
Step 4：run_test

测试返回：

ModuleNotFoundError: requests

Agent 决定：

下一步修改 requirements.txt

就在这时，系统准备执行修改。

问题矛盾

修改文件属于有风险动作。

我们要求人工确认。

如果程序只是：

print("请确认")
return

那用户确认以后，系统怎么知道：

• 刚才要改哪个文件；
• 改什么内容；
• 已经跑到第几步；
• 前面测试报了什么错；
• 任务目标是什么？

如果没有 State，任务只能从头重跑。

输入与前置条件

假设 State：

{
    "goal": "修复项目启动错误",
    "step": 4,
    "status": "WAITING_APPROVAL",
    "current_tool_call": {
        "name": "edit_file",
        "arguments": {
            "path": "requirements.txt",
            "content": "Flask==3.0.0\nrequests==2.32.0"
        }
    },
    "last_error": "ModuleNotFoundError: requests"
}

解决过程

当 Agent 进入：

WAITING_APPROVAL

系统暂停 Loop。

用户点击：

Approve

Harness 加载 State：

status = WAITING_APPROVAL
current_tool_call = edit_file(...)

然后恢复：

WAITING_APPROVAL
 ↓
TOOL_CALLING
 ↓
OBSERVING
 ↓
THINKING

执行修改。

再运行测试。

这段恢复过程可以沿时间线读：测试发现缺少 requests，准备修改依赖文件时先进入待审批；即便中间服务重启，也要先加载快照、核对动作尚未执行，等批准后才真正修改并复测。

图中只放了最核心的状态线索。要做到真正安全的续跑，快照还必须保存完整动作参数、审批标识、消息或 Artifact 引用、持久化版本和避免重复执行的幂等依据；仅有 status=WAITING_APPROVAL 并不够。

输出结果

最终：

COMPLETED

并保存：

step = 6
final_answer = "依赖已补齐，测试通过。"

复盘与迁移

这个案例说明，State 不只是“方便打印”。

它决定 Agent 能不能暂停、恢复、继续。

Human Approval、断点续跑、服务重启恢复，都需要 State。

这也是为什么后面做 Run 持久化时，我们会把关键 State 写入 SQLite。