#序：为什么今天必须重新理解 Agent
过去几年，AI 领域的变化非常快。
最初大家讨论的是模型本身：参数规模、训练方法、推理能力、上下文长度。
后来讨论开始转向模型能不能接工具、能不能联网、能不能写代码、能不能执行任务。
再往后，Agent 这个词逐渐成为一个新的中心词。
但问题也随之出现了。
一方面，Agent 被说得越来越强，仿佛只要把模型接上工具，它就会自动变成一个能够独立完成复杂工作的智能体。 另一方面，很多实际项目做出来之后，却发现系统并没有想象中那么稳，甚至经常只是把原本简单的问题做复杂了。
这说明一个现实：
Agent 不是一个自然清晰的概念，而是一个同时带着技术热度、想象投射和工程复杂度的复合词。也正因为如此，今天如果还用“会调用工具的聊天机器人”去理解 Agent，已经远远不够。 如果只用“智能体”这种宽泛说法去理解，又会失去工程抓手。
我们需要一套更稳定的理解方式。
这套理解方式既要足够高，能解释为什么 Agent 会成为一种新的系统形态； 又要足够低，能落到代码、状态、工具、工作流、评测和业务建模上。
这本书就是围绕这个目标写的。
再往现实一点说，之所以今天必须重新理解 Agent，是因为公开实践和公开 benchmark 已经反复证明了一件事：
- 当任务只是单轮问答时，很多系统差异不明显
- 当任务进入真实网页、真实代码库、真实软件环境和真实工作流时，系统差异会被迅速放大
例如，公开 benchmark 里：
WebShop显示最佳模型成功率大约只有专家人类的一半WebArena显示强模型在真实网页任务上的端到端成功率远低于人类OSWorld显示真实电脑环境里的差距更大SWE-bench则说明一旦任务进入真实仓库修复，问题已经不再是“会不会答”，而是“能不能真正把事情做完”
这些结果的共同含义很清楚：
Agent 不是语言表现问题，而是执行系统问题。这也是这本书的现实出发点。
#导言：这本书试图解决什么问题
这本书不打算回答“哪个框架最好”或者“哪个模型最强”。
它更想回答四个更根本的问题：
- Agent 到底是什么
- 为什么 Agent 和传统模型系统不一样
- 怎样系统性理解一个 Agent
- 怎样把 Agent 从一个概念，变成可设计、可落地、可评审的系统方法
因此，这本书既不是产品手册，也不是论文综述，更不是某个特定框架的教程。
它更像一本方法论手册。
它要做的事情，是把几条原本分散的线索重新整合起来：
- 概念层的理解
- 业务层的理解
- 模型层的理解
- 系统层的理解
- 协作层的理解
- 治理层的理解
- 研究层的理解
- 工程层的理解
如果这些线索不被重新整理，Agent 很容易被理解成两种极端之一：
- 一种玄学化的“智能体想象”
- 一种工程化但过于局部的“工具调用封装”
这本书的目的，就是避免这两个极端。
如果换一种说法，这本书想补上的，是 Agent 领域里最缺的一层“中间语言”。
在太高的层面，人们容易把 Agent 神秘化。 在太低的层面，人们又容易把 Agent 局限成一些零散技巧。
而真正有效的理解，必须能同时连接三件事：
- 研究论文在说什么
- 官方工程文档在强调什么
- 业务和系统落地时到底卡在什么地方
只有三者一起看，Agent 才会从热词变成方法。
#阅读说明：这本书适合谁，应该怎么读
这本书适合三类读者。
第一类，是已经在做 Agent 的工程师和架构师。 他们通常已经见过框架、prompt、tool call、workflow、memory 这些概念，但仍然缺一个更稳定的总视角。
第二类，是业务负责人、产品经理和技术管理者。 他们不一定写代码，但需要判断：哪些业务适合做 Agent，哪些不适合，风险在哪里，投入和收益如何平衡。
第三类，是希望系统性建立 Agent 方法论的学习者。 他们可能读过很多碎片资料，但还没有形成一个完整的认知框架。
如果你是第一次认真理解 Agent，建议按顺序往下读。 如果你已经在做系统设计，可以把第一编和第二编看作“统一语言”，把后面的章节看作“设计视角”。
如果你想把这本书用于实际工作，我建议采用下面的读法：
- 业务负责人优先读第二编、第八编和第九编
- 工程负责人优先读第四编、第五编、第六编
- 研究或方法论读者优先读第一编和第七编
这样的原因很简单：
- 业务负责人最需要判断“值不值得做、适不适合做”
- 工程负责人最需要判断“怎么搭、怎么控、怎么测”
- 研究读者最需要判断“这套方法论的逻辑支点是什么”