完成本书和毕业项目后，你应能做到： 从零实现一个 TypeScript Agent Runtime； 讲清楚 tool call loop 的完整生命周期； 设计工具 schema、权限模型和审批流； 解决 context 超限与历史压缩； 实现 checkpoint、resume、rollback
一个成熟 runtime 必须支持取消。取消不是'UI 不显示了'，而是从用户操作一路传播到模型请求、工具执行、子进程和资源清理。 这段代码只是开始。上线后的 runtime 需要把 AbortSignal 传给 HTTP client、模型 SDK、工具 executor、子进程管理器。任何一层吞
Agent Runtime 和 Workflow Engine 有什么区别？ 很多人第一次做 Agent 系统，会问： 既然 Temporal、Step Functions、Airflow、Dagster 这类 workflow engin
恢复流程要保守： 1. 找到最新完整 checkpoint； 2. 校验 workspace 状态； 3. 恢复 message history 和 run state； 4. 检查最后一个 tool call 是否已完成； 5. 对不可重复工具禁止自动重放； 6. 给模型注入恢复说明； 7. 从下
Agent 迟早要接外部工具。本章讨论怎么接，以及怎么避免被某个供应商或协议绑死。 Agent Runtime 不能永远只使用本地写死的工具。它需要连接数据库、浏览器、设计工具、代码托管平台、内部系统、文档库和企业权限系统。MCP 的出现，正是为了解决 LLM 应用与外部数据、工具之间缺少统一连接方
MCP Tools 规范里，Client 通过 tools/list 发现可用工具，通过 tools/call 调用工具。工具包含名称、描述和输入 schema。Server 声明 tools capability 后，必须响应 tools/list；工具列表可以为空，也可以随时间变化。 对 run
真实模型有随机性、网络波动和供应商变化。Eval 需要两层： 第一层用 deterministic mock model 测 runtime 逻辑。它按照脚本返回固定 tool calls，用来验证 schema 校验、权限、checkpoint、trace、停止条件。 第二层用真实模型测端到端能力
Agent Memory 应该放在 Runtime 还是 Application？ Agent Memory 是个很容易被讲乱的词。 有的人说 memory，就是把聊天记录存起来。 有的人说 memory，是向量库。 有的人说 memory
给 Agent Loop 加 Max Iteration 昨天我们手写了一个 100 行 Agent Loop。 今天给它加 max iteration。 很多教程会把这一步写得很轻： 这当然要写。 但如果你的理解停在这里，max iter
试读章节：Agent Loop 的完整生命周期 这篇放一段《Agent Runtime 工程化》的试读。 不是整章原样贴。 我把第三章里最核心的部分抽出来，重新整理成一篇社区版：一次 Agent Loop 到底应该怎么跑。 很多 Agent
Agent Framework 会被模型原生 Tool Use 淘汰吗？ 会。 但只会淘汰一部分。 更准确地说：模型原生 Tool Use 会淘汰很多薄薄的 Agent Framework 胶水代码。 它淘汰不了 Runtime 责任。 这
一次线上失败，如果不能转化为 eval，它就会再次发生。建议流程： 1. 从 trace 中提取用户目标、关键上下文、工具调用和失败结果； 2. 去除 secret 和用户隐私； 3. 固化 workspace fixture； 4. 写 expected behavior； 5. 加入 CI； 6
从 Agent Loop 重构成 Agent Runtime 写到第 14 天，可以把前面几篇收一下了。 前面写了 100 行 Agent Loop。 随后加了 max steps。 再往后加了 token budget。 接着处理了 re
日志不是 trace。日志多半给开发者看，trace 应能还原运行路径。读项目时找： 每次模型调用是否记录； token usage 是否记录； tool call args 是否脱敏； tool result 是否保存； latency 是否可见； 错误是否分类； 用户确认是否入 log； 是否能
一个 Agent trace 至少包含： span 至少包含： 不要把 trace 做成聊天 transcript。聊天记录回答'说了什么'，trace 回答'系统做了什么'。
无论选哪个方向，最终交付都应包括： 设计文档； 最小实现； 单元测试； 至少 5 个 eval 或 fixture； trace/log 示例； README 使用说明； 失败场景说明； 安全和隐私影响说明； 后续工作清单。 PR 描述建议结构： 一个好 PR 不只是'代码能跑'，还要让维护者相信你
trace 很敏感。它可能包含用户代码、命令输出、环境变量、文件路径、API 响应、模型输入输出。生产系统中，trace 需要： secret 脱敏； 访问控制； 保留期限； 采样策略； 用户可删除机制； 外部导出审计。 不要为了调试方便，把所有 trace 原样传到第三方系统。可观测追求的不是越多
Sandbox 应该属于 Harness 还是 Runtime？ 这个问题看起来像架构洁癖。 其实不是。 你把 Sandbox 放错位置，后面权限、审批、恢复、trace 都会跟着乱。 我的答案是： Sandbox 的执行环境属于 Harn
《Agent Runtime 工程化：从工具调用循环到可恢复执行系统》电子版系列完整目录，收录系列导读、12 章导读、全部小节与附录链接。
说 Agent '变好了'很容易。证明它变好了，要靠 eval。 Agent 产品很容易陷入'今天试了几个问题，感觉不错'的幻觉。工程系统不能靠感觉上线。Eval Harness 的任务，是把真实任务变成可重复的测试，把 trace 变成回归样本，把 prompt、工具、上下文、权限和 runtime 策略的变化变成可比较的数据。 截至 2026 年 8 月
