你写的可能根本不是 Agent
书里最狠的判断藏在 prologue：大多数人在用的"AI"，只是 Level 0——裸 LLM，没有工具、没有记忆、不会行动。你问它 2025 年奥斯卡最佳影片是哪部，它猜。这种东西不是 Agent。
往上才是真 Agent，分四级。
Level 1 工具使用者：Agent 开始用工具，搜索、API、数据库。但关键不是"能调接口"，而是它自己判断什么时候该调、调什么、结果怎么用。用户问"最近有什么新剧"，Agent 自己意识到这条信息不在训练数据里，主动调搜索工具去找，再合成结果。"自己意识到"这一步，是 Level 1 的门槛。
Level 2 战略思考者：多了规划和 Context Engineering 两样东西。书里对 Context Engineering 的定义很妙：不做信息堆砌，做精心筛选、裁剪、打包上下文。例子是用户要在两个地点之间找咖啡店——Agent 先调地图工具拿到一堆数据，然后判断"下一步只需要街道名称"，把地图输出裁剪成短列表，再喂给本地搜索工具。每一步都在做信息降噪。书里反复强调一句："要让 AI 达到最高准确率，必须给它短小、聚焦、有力的上下文。"
到这个级别，Agent 还能自我反思——干完活后自己审一遍，发现问题自己改。
Level 3 多 Agent 协作：书的立场很明确——别老想着造一个全能 super agent，靠谱的做法是搭团队。项目经理 Agent + 研究员 Agent + 设计师 Agent + 文案 Agent。书里举的例子是新产品发布：一个"项目经理 Agent"做总调度，下发任务给"市场研究 Agent""产品设计 Agent""营销 Agent"。这章画了六种通信拓扑结构，每种适合什么场景都标得清楚。
看完这四级，我突然明白为什么很多人说"我的 Agent 不好用"。模型没问题，问题是你在把它当聊天机器人用，它可能连 Level 1 都没到。
Context Engineering：被严重低估的概念
传统 Prompt Engineering 只管"你怎么问"。Context Engineering 管的是"问之前，Agent 的眼前摆着什么"。书里把它拆成四层：
- System prompt：定义 Agent 是谁、什么语气、什么边界。大多数人只写到这一层就停了。
- 外部数据：RAG 检索到的文档、工具调用返回值、实时 API 数据。大部分人卡在这里——知道要喂数据，但不知道怎么喂才不会把模型淹没。
- 隐式数据：用户身份、交互历史、环境状态。你没明说但 Agent 应该知道的东西。比如让 Agent 给 John 发邮件确认明天的会议，它应该知道明天的会议是什么、John 是谁。
- 反馈回路：Agent 每次输出之后，自动评估质量、调整下次的上下文策略。Google 的 Vertex AI Prompt Optimizer 就是这个思路的工程化实现。
很多人花一周时间写 prompt，但只动了第一层。真正的差距在后面三层。
Reflection：两个 Agent 比一个好，但要分开
这是书里实战价值最高的 Pattern。Reflection 的核心很简单：Agent 干完活后自己审一遍，发现问题自己改。但实现方式有讲究——Producer 和 Critic 必须用两个不同的 Agent，给不同的 system prompt。同一个 persona 审自己的东西，一定有盲区。让同一个 LLM 先写代码再审查自己写的代码，它大概率会说"挺好的"。
书里给的代码示例很直接：
- Producer 的 prompt 是"你是一个 Python 开发者，写一个计算阶乘的函数，处理边界条件和异常"
- Critic 的 prompt 是"你是一个吹毛求疵的高级工程师，逐行审查代码……如果完美就输出 CODE_IS_PERFECT，否则列出所有问题"
- 然后一个 for 循环：Producer 写 → Critic 审 → Producer 改 → Critic 再审 → 直到满意或达到最大迭代
成本问题不能忽略：每次反射循环都是一次新的 LLM 调用，对话历史还在持续膨胀，上下文窗口被前期版本和批评意见占满，实际可用的推理空间在缩小。书里给的建议是设一个合理的最大迭代次数（默认 3），Critic 满意就停，不追求完美。
写文章、做计划、总结文档、解决逻辑题，Producer-Critic 模型都能套。核心逻辑一样：先产出，后审查，再修正。
Multi-Agent 不是越复杂越好
很多人搭 Multi-Agent 时花 80% 时间在通信协议上，忘了问一个更基本的问题：这个任务真的需要多个 Agent 吗？
书里画了六种拓扑，但实际场景三种就够：
- 单 Agent：任务能拆成互不依赖的子问题，每个 Agent 自己搞定。简单、好维护。
- 对等网络（Peer-to-Peer）：Agent 之间直接通信，没有中心节点。去中心化，容错性好，但协调成本高，容易乱。
- Supervisor（中心调度）：一个 Supervisor Agent 管一群 Worker。层级清晰，好管理，但 Supervisor 是单点故障也是性能瓶颈。
剩下三种（Supervisor-as-Tool、层级式、自定义混合）是组合变体。书里说得很实在：拓扑结构取决于任务复杂度。任务拆得越碎，通信成本越高，到一定程度 Supervisor 反而比层级式效率更高。
更直接的判断是：Level 2 的单 Agent + Reflection 往往已经够用了。Level 3 是给单 Agent 确实搞不定的场景准备的。大多数人的问题不是 Agent 不够多，是一个 Agent 都没调好。
Memory 三层模型
记忆该怎么分层是个老问题，书里给了清晰答案：
- Session（会话层）：当前对话的上下文窗口。最短的记忆，对话结束就没了。长上下文模型只是放大了这个窗口，本质上仍是临时的，而且每次推理都要处理整个窗口，又贵又慢。
- State（状态层）：当前任务进行中的临时数据。比 Session 长，但任务结束就清理。Google ADK 的 State 机制做了完整示例。
- Memory（持久层）：跨会话、跨任务的长期记忆。用户偏好、学到的经验、重要的历史决策，存数据库或向量库，语义检索。书里强调一个关键点：Memory 不只是存下来，还要设计"存什么、什么时候存、怎么检索"的整套策略。存太多噪声大，存少了不够用。
很多人手搓的"状态文件"和"工作区文档"本质上就是在做 State 和 Memory 层。书里只是把这件事框架化了。
五种假设，第五个最离谱
书末提了五个关于 Agent 未来的假设，前四个还算合理：通用型 Agent 从写代码到管项目、深度个性化主动发现需求、具身智能走出屏幕、Agent 成为独立经济实体。
第五个把我震住了——变形 Multi-Agent。你只声明目标，比如"做一个卖精品咖啡的电商生意"。系统自动决定：先创建"市场研究 Agent"和"品牌 Agent"。跑完一轮数据后，自己判断品牌 Agent 不需要了，拆成三个新的："Logo 设计 Agent""建站 Agent""供应链 Agent"。如果建站 Agent 成了瓶颈，系统会自动复制出三个并行 Agent 同时干不同的页面。整个过程中，系统持续自动调优每个 Agent 的 prompt，不断重组团队架构。
书里把它叫"目标驱动的、自我变形的多 Agent 系统"。它不是在执行你写的计划，是在自己生成计划、自己调整计划、自己重组执行团队。人类只声明"要什么"。
这条赛道目前还没看到真正的壁垒。但路径已经清晰，剩下的是工程化。
三件可以马上做的事
读完这本书有三个立刻可以落地的动作。
第一，给你现在的 Agent 加一个 Critic。 不管你用的是 Claude Code、CrewAI 还是自己搭的框架，在现有 workflow 末尾加一步：让另一个 Agent（用不同的 system prompt）审查上一步的输出。代码生成加代码审查，文章撰写加事实核查，计划制定加可行性评审。多一次 LLM 调用，质量往往翻倍。
第二，从 Prompt Engineering 升级到 Context Engineering。 回头看你写给 Agent 的指令文件。如果全是"你要怎么做"的规则，缺少"你现在面对什么环境"的上下文，补上。告诉 Agent 它现在在哪个项目里、之前做过什么决定、用户偏好是什么。AGENTS.md 和 Context Engineering 是同一件事的两个表述。
第三，先别急着上 Multi-Agent。 把你的单 Agent 做到 Level 2：有工具、有 Reflection、有 Memory。绝大多数实际场景，Level 2 的单 Agent 加 Producer-Critic 加 Context Engineering 已经够用。Level 3 是给真正跨领域、多阶段、需要并行分工的任务准备的。
这本书是 Springer 2025 年出版，代码示例覆盖 LangChain/LangGraph、Google ADK、CrewAI、OpenAI API。前言由 Google Cloud AI VP 撰写，还有 Goldman Sachs CIO 的推荐序。
推荐它的理由不是"全面"，而是读完之后你会意识到：你不需要再发明 Reflection，不需要再猜 Memory 该怎么分层，不需要再试 Multi-Agent 该用哪种拓扑。有人替你画了地图。剩下的就是走。