为什么写这本书
1. 一个尴尬的事实
到了 2026 年，几乎每个团队都能在一个下午做出「会调用工具的 agent」；但能把 agent 稳定运行一周、出事能定位、改版不回归的团队，仍然是少数。
差距不在模型。同一个模型，在 demo 里能修 bug，在生产里会重复退款；在评测集上能拿高分，在真实用户面前会引用错文档；在提示词里被要求「不要删除文件」，却因为一次网页注入把仓库清空。这些事故的根因，几乎都能归到同一类：把 agent 当成一次模型调用，而不是一个系统。
一次模型调用只需要关心输入、输出与价格。一个系统还要关心：
- 循环靠什么停，预算怎么分，失败怎么退；
- 工具的能力边界、参数来源、幂等性与权限；
- 进程、文件、网络、资源四层隔离；
- 上下文里哪些能压缩、哪些不能；
- 记忆怎么写入、检索、引用、删除；
- 规划与多智能体的收益是否大于协调成本；
- 评估的置信区间、回归门禁与成本约束；
- trace、日志、指标、回放；
- 注入、外泄、投毒与供应链；
- 审计、最小权限、人工审批与合规。
这些主题横跨操作系统、分布式系统、安全工程、统计与产品设计。单独看，每一块都有成熟文献；连起来，才是一个 agent 平台。这本书做的就是「连起来」，并且只写模型之外的那一层。
2. 为什么是现在
2025–2026 年，agent 的工程接口终于开始标准化：
- MCP 从 2024-11-05 走到 2025-11-25，再到 2026-07-28。最新版把协议改成无状态、用
server/discover协商版本、用 MRTR 取代 server-initiated requests，并弃用了 Roots/Sampling/Logging。这意味着「initialize 握手 + 会话」不再是唯一前提，实现者必须理解版本矩阵。 - OpenAI function calling 与结构化输出把「工具 schema」变成了模型接口的一部分；
strict、parallel_tool_calls、流式增量、tool_call_id都有明确语义。 - OCI Runtime Spec 1.3.0 把进程、namespace、capability、seccomp、rlimit 的配置固定成
config.json；agent 沙箱不必自己发明一套。 - OpenTelemetry GenAI/MCP 语义约定让 trace 有了可交换的字段名；没有它，每个平台的 trace 都是一座孤岛。
- NIST AI RMF、ISO/IEC 42001、EU AI Act 把「审计、风险管理、人工监督」从最佳实践变成可检查的义务。
标准化的好处是：你不需要从零发明协议；坏处是：版本变化很快，把旧版当永恒会写出过时的代码。本书的处理方式是：给出基线版本 + 迁移路径 + 判断依据，而不是抄一份规范。
3. 这本书不做什么
它不教你训练模型，不教你写 Transformer，不教你 Linux 内核，也不教你 TCP 三次握手。这些是《深度学习导论》与《Linux 系统与内核》的领土。本书在需要时给出交叉引用，并明确「为什么这个边界会影响 agent」。
它也不是框架手册。LangChain、LlamaIndex、AutoGen 等框架会变，机制不会。书里的代码尽量只用标准库，目的是让你看清每一层在做什么；换成任何框架时，你知道该检查哪些点。
它更不是「最佳实践清单」。每个方法都有适用条件与失败边界；书里会写「什么时候不要用」，而不是只写「应该用」。
4. 你怎么用这本书
如果你只有一周：读第 1、2、5、9、10 章，跑通第 1 章与第 9 章实验，建立一个能观测、能评估的最小闭环。
如果你有一个月：按「平台工程路线」读 1–4、9–12，做项目二；遇到沙箱细节再回第 3、4 章。
如果你在做安全评审：读 1–4、11、12，把项目一的红队用例跑一遍，再用附录 B 的五条勘误检查现有系统。
每章末尾都有「本章陷阱」与「出口检查」。陷阱表是从真实事故里抽出来的；出口检查是进入下一章的最低门槛。不要跳过出口检查——后面的章节默认你已经会了。
5. 一个请求
这本书的示例都尽量可运行、可复现。如果你发现某段代码跑不通、某个版本号写错、某条结论与你的实践不符，请把它当成缺陷而不是「风格问题」：记录你的环境、命令与输出，对照 附录 B 的勘误格式提出来。
Agent 系统工程还在快速变化。比「记住结论」更重要的是：知道每个结论依赖哪个版本、哪条假设、哪次实验。这本书试图把这种可检验性写进正文，而不是留给你去猜。