不是又一本 agent 框架指南

引言

agent 这个领域正在被“怎么做”淹没。框架文档、编排教程、multi-agent 速查表、prompt 模板合集、“年度最值得关注的 N 个 agent 框架”——它们默认读者只想知道一件事：怎么搭。

怎么挂工具，怎么串 multi-agent，怎么写 ReAct 循环，怎么接 MCP。这些问题值得回答，但它们背后有同一个盲区：很少有人停下来问，当 agent 进入软件系统的核心位置，工程要改什么。

这本书关注的是“怎么想”，然后才是“怎么做”。

这本书只回答一个问题：当 agent 进入软件系统的核心位置，工程该怎么做。

它表达个人观点，有明确的偏好、判断和品味。偏见和盲区放在下一篇，方便你校准。

这本书做三件事：

立一个稳定的抽象。agent 到底是什么？如果这个问题没有答案，框架只能统一表面的流程，零件只能堆在一起。第一章从这里开始。

顺着这套抽象走一遍 agent 的一生。出生、入职、上岗、安家、试用、晋升、退休，这些词听起来像人力资源，其实对应一组工程问题：模型从哪里来、岗位怎么定、能力怎么补、环境怎么留、表现怎么验、什么时候该换岗或下线。

从个体写到团队与组织。一个 agent 还只是角色；很多 agent 在一起，就会出现分工、交接、授权、升级路径、绩效记录和最终责任。这些问题不是多画几条连线就能解决。

这本书的起点是：假设你已经知道怎么把一个 agent 跑起来，现在的问题是怎么把它当成一个可靠的、能共事的角色来工程化。所以某个 SDK 的 API 怎么调、某个框架的工作流怎么配、ReAct 和 Plan-and-Execute 的循环细节，这些有专门的文档讲，这里不重复。

agent 的定义这两年换得太快。一会儿它是“会调工具的程序”，一会儿又被吹成“无所不能的智能体”。两个说法都停在能做什么，没说清 agent 是谁。

与此同时，工程零件已经开始定型：模型分级、skill、长期记忆、持久化沙箱、可观测 trace、工具权限。它们各自有用，但如果没有一个更高一层的抽象，就只能各管各的堆在一起。比起再添一个框架名字，现在更缺一套能把这些零件放到同一张图里的看法。

第一章立抽象：agent 到底是什么，为什么“把它当人看”能承重，而不是顺手的比喻。

第二章到第六章顺着这套抽象走完 agent 的个体一生：出生以前的训练，岗位先于候选人，上岗培训与职业证书，工作电脑与职业履历，试用、晋升与退休。

第七、第八章从个体走到团队与组织：一群 agent 怎么协作；当传统组织变成 agentic 组织，什么会变，什么不会变。

起点是一个判断：agent 是比模型高一层的工程对象。终点也是一个判断：agentic 组织里，最终责任必须落在有利害、能担责的人或组织身上——agent 当不了这个终点。

如果你在搭 agent 系统时撞上了“prompt 调不稳”“不知道该信哪个 eval”“multi-agent 越编排越乱”这类问题，可以直接跳到对应章节，但建议回头补读第一、二章——很多问题的根不在框架层，在你还没想清这个 agent 到底是谁。

如果你对框架和工具本身更感兴趣，这本书可能让你不舒服。它会反复追问“为什么”，而不是直接给你“怎么做”。框架会过时，抽象不会。今天的 SDK 三年后可能没人用，但“先定义岗位，再挑候选人”这件事，只要 agent 还像个打工人，就一直成立。

不必同意书里的每个判断。有些地方让你点头，有些地方让你想反驳，这才是它该有的读法。反驳也有用，它会逼你把自己的立场讲清楚。