我为什么写《Agent Runtime 工程化》
过去几天，我连续写了 6 篇关于 Agent Runtime 的文章。
先讲 Demo 为什么上不了生产，再讲 Agent Loop、Harness、Runtime 的边界。然后写 Retry 重复下单、token 成本失控、Production Runtime 架构、Memory 污染。
这些问题看起来分散，其实都指向同一件事：
Agent 真正难的部分，已经从'怎么做 demo'转到'怎么可靠运行'。
所以我决定把这套东西系统写下来。
书名就叫：
《Agent Runtime 工程化：生产级 AI Agent 架构、运行时与工程实践》
这篇算正式官宣。
为什么不是再写一本 Prompt 书
Prompt 很重要。RAG 也重要。Tool calling、MCP、Agent framework 都重要。
但这些东西进到生产环境后，会不断撞上更底层的问题：
- 谁拥有 run state？
- 谁决定工具能不能执行？
- 谁处理超时和取消？
- 谁保证 retry 不会重复副作用？
- 谁知道模型这一轮看见了哪些上下文？
- 谁控制 token 和成本？
- 谁保存 checkpoint？
- 谁记录 trace？
- 谁把事故变成 eval case？
- 谁让用户能理解 Agent 到底做了什么？
这些问题靠 prompt 很难补好。
它们属于 Runtime。
很多团队一开始会以为自己在做 Agent，做着做着发现自己在写一个小型操作系统：状态、调度、权限、日志、恢复、资源预算、外部工具、审计、回归测试。名字不一样，味道很像。
这本书想讲的就是这部分。
社区窗口已经打开了
现在中文技术社区里，'Agent Runtime'已经不是没人讲的概念。
英文社区更明显。Anthropic 在讲 effective agents 时，会区分 workflow 和 agent。LangGraph 把 durable execution、human-in-the-loop、persistence 放到 agent orchestration 的核心能力里。OpenAI Agents SDK 也把 sessions、tracing、guardrails、handoffs、human approval flows 做成一套开发体验。MCP 把外部工具连接标准化，但同时也把工具安全、用户同意、隐私边界摆到了台面上。OWASP 已经把 Excessive Agency 写进 LLM 应用风险。
这些信号说明一件事：
Agent 的竞争不再只是'谁接了更多工具'。下一阶段会变成'谁能把这些工具安全、稳定、可恢复地跑起来'。
我不想把这本书包装成'国内第一本'。这种说法风险很高，也没必要。
更准确的位置是：
系统讲清楚一个 Agent 如何从 Demo 进入生产环境。
我真正想解决的读者问题
这本书不是给完全没写过代码的人看的。
它面向三类人：
有 TypeScript/Node.js 基础的后端、全栈、工具链工程师。
准备二开 coding agent 或企业内部 agent 平台的架构师。
希望从 prompt 使用者升级为 runtime 工程师的技术负责人。
读者读完后，不应该只是'知道很多概念'。
我希望你能真的做到：
- 解释 Agent、Workflow、Tool、Runtime 的边界。
- 设计一个 TypeScript/Node.js 版最小 Agent Loop。
- 为工具设计 schema、风险等级、输出策略和失败语义。
- 建立上下文预算、repo map、滚动摘要和 debug report。
- 接入 MCP Server，并处理动态工具变化和信任分层。
- 设计 shell、文件、网络、安装、破坏性操作的权限策略。
- 实现 checkpoint、resume、rollback 的核心数据结构。