前言：任务没有结束，进程却已经不在
一个助手生成了退款方案，用户同意，工具开始执行。几秒后服务进程重启。界面没有收到结果，工具侧却可能已经记下一笔退款。让模型再回答一次，或者把整个函数从头运行，都不能直接回答那笔业务到底发生了什么。
这本书关心这种跨越请求、进程和等待时间的执行过程。规划、审批、领取、调用和核查分别留下什么证据；谁有权继续一项任务；恢复之后哪些动作可以重复；结果未知时怎样向操作者交代。它适合已经理解 HTTP、数据库事务和基本 Go 的开发者，也适合正在把 Agent 从交互演示扩展为后台业务系统的人。
本书沿用“Agent 提出行动、受控系统决定怎样执行”的分工。模型产生的是不可信提案，不能自己指定租户、审批人、凭据、工具地址或者幂等能力。执行引擎把经过校验的意图持久化，等待有权限的主体确认，再依据工具合同安排执行。一个流畅的回答不能替代这些持久事实。
随书工程使用真正的 PostgreSQL、真实 HTTP 工具服务和独立 worker 进程。工具效果在独立数据库事务中提交；故障可以发生在领取之后、工具提交之后，也可以故意丢掉成功响应。实验会检查数据库与外部效果，不只检查函数有没有返回错误。它是一个范围清楚的教学执行内核，包含单个副作用节点，不是完整的通用工作流平台。
怎样沿着问题阅读
第 1 至 5 章建立执行合同、业务身份、持久状态、提案准入和审批模型。第 6 至 10 章讨论领取、租约、围栏、工具幂等、未知结果和定时重试。第 11 至 15 章处理进程崩溃、取消、版本、并发与观察。最后三章带读者运行实验、读取证据，并完成一次生产设计评审。
可以先读实验首跑章，看到一项任务从提案到成功，也可以先读响应丢失章节，再回来解释为什么客户端报错并不意味着副作用没有发生。练习参考给出判断方向，不把每个系统选择都写成唯一答案。
模型规划能力、执行正确性和基础设施持久性是不同的验证对象。可控提案适合稳定制造故障窗口；实际小模型的输出需要另行记录模型、输入、约束和结果。数据库提交记录能支持本实验的恢复判断，却不等于已经演练主从切换、断电持久性或跨区域灾难恢复。每一项结论都应保留它真正经过验证的范围。
阅读时一直保留的三个问题
第一，眼前这条记录是谁的事实：模型的建议、应用的审批、worker 的观察，还是工具的业务结果？第二，另一位执行者如果现在接手，能凭持久记录做出什么判断？第三，如果这个判断暂时不能成立，系统是否允许诚实地停在待核查状态？
把这些问题带进代码，比给任务起一个“可靠”的名字更有帮助。希望读完之后，你能用一次真实崩溃、一份账本和一组可重复实验，解释一项长任务怎样继续。