真实模型有随机性、网络波动和供应商变化。Eval 需要两层： 第一层用 deterministic mock model 测 runtime 逻辑。它按照脚本返回固定 tool calls，用来验证 schema 校验、权限、checkpoint、trace、停止条件。 第二层用真实模型测端到端能力
现在可以动手了：把模型、工具和观察结果接成一个受控循环。 最小 Agent Loop 是本书第一座桥。过了这座桥，你就不再只是调用一次模型，而是在写一个会观察、会行动、会停止的运行系统。这个系统可以非常小，但边界必须正确。
长任务一定会中断。问题是：失败后怎么继续，而不是重来？ Agent Runtime 一旦进入真实工程任务，就会遇到长运行：改多个文件、跑多轮测试、安装依赖、查文档、等待用户确认。长运行必然遇到中断。浏览器刷新、进程崩溃、网络超时、模型失败、用户临时离开，都可能打断 run。如果没有 checkpoi
本书统一使用以下术语。 turn 是一次用户与系统的交互轮次。用户提出一个任务，是一个 turn 的开始。 step 是 runtime 在一个 turn 内的一次模型决策或工具执行推进。一次 turn 可以有很多 step。 run 是一次完整执行，从收到用户请求到最终回答、失败或取消。长任务中，
幂等性是恢复执行的核心词。一个工具如果重复执行不会造成额外副作用，就更容易恢复。例如读文件幂等，搜索幂等，纯计算幂等。写文件如果基于相同 base hash 应用同一个 patch，也可以设计成近似幂等。发邮件、支付、删除远程资源通常不幂等。 工具定义中应声明： 这会直接影响 resume 策略。
第八章 Checkpoint、Resume、Rollback：8.3 gitbased checkpoint 另一种做法是借助 git。每个 step 或关键写入点创建临时 commit、stash、worktree 或 patch 文件。 gitbased 的优点是成熟、可审计、适合代码项目。缺点
第八章 Checkpoint、Resume、Rollback：8.2 patchbased checkpoint 对 coding agent 来说，文件系统状态是第一等公民。最轻量的做法是 patchbased checkpoint：每次工具执行前后记录 diff。 优点： 存储小； 容易审计；
写 Agent Runtime 之前，先补一门不太体面的课：异步任务和进程控制。 Agent Runtime 表面上是在调用模型，实际上是在管理一串可能很慢、会失败、有副作用、需要取消的异步任务。模型请求会流式返回，shell 命令会持续输出，文件系统可能被修改，用户可能中途按下取消，工具可能超时，
Agent Runtime Engineering v0.1 发布 今天把这个项目正式按 v0.1 的方式放出来。 仓库地址： https://github.com/zeeklog/agentruntimeengineering 先说清楚：
Sandbox 应该属于 Harness 还是 Runtime？ 这个问题看起来像架构洁癖。 其实不是。 你把 Sandbox 放错位置，后面权限、审批、恢复、trace 都会跟着乱。 我的答案是： Sandbox 的执行环境属于 Harn
给 Tool Call 加 Exponential Backoff Retry 很多人写 retry，第一版都是这样： 看上去挺负责。 坏也坏在这里。 在 Agent Runtime 里，retry 不是'失败了再来一次'。它要先回答三个问
一个 Agent Runtime 失败案例的完整 Trace Agent 出问题后，最没用的一句话是： 它可能是真的。 但它不能指导修复。 如果你只剩聊天记录，确实很容易把问题归到模型身上。模型说它修好了，用户说没修好，日志里只有几段自然语
Agent Runtime 和 Workflow Engine 有什么区别？ 很多人第一次做 Agent 系统，会问： 既然 Temporal、Step Functions、Airflow、Dagster 这类 workflow engin
MCP 解决了什么，又没有解决什么？ MCP 很容易被讲成一句话： AI 时代的 USBC。 这个比喻有用，但也有点危险。 它会让人误以为：只要插上 MCP Server，Agent 就自然拥有了一套安全、可靠、可治理的工具系统。 不是。
Agent 生产事故 001：Retry 为什么会导致重复下单？ 凌晨两点，客服群里开始有人截图。 同一个用户，同一个购物车，出现了两张订单。金额一样，收货地址一样，创建时间差 18 秒。业务同学第一反应是接口重复提交。后端第一反应是前端按
Production Agent Checklist v1.0 发布 前 21 天，我一直在讲一个判断： Agent Runtime 不是框架名。 它是一组工程责任。 今天把这组责任整理成第一版清单： 这不是最终版。 也不是'照着打勾就永远
读到这里，读者不需要被带回课堂作业。商业化技术书应该把读者送到下一段真实工作的入口。本章要做的事，是把前面十章拆成几条可以长期深挖的能力路线，并说明每条路线怎样从学习样例走向真实项目。 这几条路线不是互斥选项。它们像 Runtime 的几根梁：评测、上下文、工具协议、权限安全、恢复、观测和产品化。你可以先从最贴近自己工作的问题开始，但最终要把它们连成一套系统
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确认，或者直接拒绝。 安全不是最后加的一层'确认弹窗'。它应该
工具通常分散在文件系统、终端、浏览器、搜索、编辑、MCP 等模块里。读工具时问： 工具 schema 在哪里定义？ 描述如何送给模型？ 参数在哪里校验？ 执行前是否有 preview？ 用户确认如何表达？ 失败如何反馈给模型？ 输出如何截断？ 如果一个项目有 MCP，继续问： MCP Server
用户审批不能只当 UI 事件。对 runtime 来说，它是一条系统事实，每次都应写入 audit log： 恢复执行时，这些记录尤其重要。已经被拒绝的危险工具，不能因为进程重启就再次自动执行。已经批准的一次性操作，也不应无限期复用授权。
