第 4 章 — AI 智能体与工具调用

《LLM Primer V: Building Real-World LLM Applications》 章节走读的第四篇。这一章把智能体当作一个针对工具循环起来的语言模型来处理,而工具的 schema、记忆的分层、以及多智能体的接线,都要先被工程化,循环才谈得上能被托付真正的活。

这一章为什么存在

一个只接受文本、只发出文本的无状态模型,是一台计算器。生产级的活要求把它变成一个跨多步追目标的行动者 —— 先调这个工具,再调那个工具,再决定挑哪一个结果给用户,然后在任务完成时停下。这一步在架构图上看着简单,实际上不简单。智能体会漫游、会打转、会调错工具、会编工具接不了的参数、会忘掉自己已经取过什么、会做超出自己权限的事。第 4 章讲的就是让循环可读、可界的那些工程 —— schema、记忆纪律,以及能把一个看着能跑的 demo 变成一个生产级行动者的多智能体结构。

4.1 智能体架构是组合,不是选一

基座循环是 ReAct:对当下情境做推理,通过调用工具去行动,观察结果,重复,直到达成目标或用完步数预算。生产系统会在基座之上组合三种增强,而不是在里面选一。原生函数调用 —— 供应商在解码时就用 JSON Schema 约束工具参数 —— 让 I/O 合同硬起来,循环不再需要从坏格式的调用里恢复。显式规划,以 Plan-and-Execute 风格,把 “长时程任务” 前置为一份计划,只有世界变了才重新跑规划器。工作流编排把任务里已知的状态转移编成一张图,把 “阶段内的决策” 留给模型 —— 这是多数企业部署收敛的形态,因为它把 “可知” 和 “需要判断” 分开了。反射循环、跨成本分级机群的多模型路由、专职子智能体,都是并列在这之上的更进一步增强。

4.2 工具调用机制 —— schema 就是合同

每一个工具都有 schema,而 schema 是循环对模型强制的合同。属性级的描述是写给模型看的文档,不是写给人看的;能用枚举就把参数空间关起来;幂等键让循环重试一次工具调用不会把效果翻倍;结构化的可重试错误让模型能干净地恢复,而不是靠猜。工具要小 —— 一个工具做一件明确的事 —— 因为一个带十个可选标志的胖工具就是一个模型会调错的工具。目录里应该显式地放一个 ask_user 工具,让智能体在遇到歧义时有一个正当的升级方式,而不是自己编参数。并发只在工具声明了独立性的时候才安全;循环把声明独立的工具当作可并行,其他一律严格顺序。追到根源的每一起 “智能体做错事” 的生产事故,都会露出是某个工具的 schema 没说清楚它的参数究竟是什么意思。

4.3 三层记忆:短期、长期、语义

智能体需要记忆,因为任务很少能在一轮里做完。短期记忆是最近对话的滑动窗口,再加上滑动时被保留下来的置顶消息 —— system prompt、当前目标、正在跑的计划 —— 以及对滑出窗口的那些轮次的定期摘要。长期记忆是一份精心整理的事实向量库,写入是在 “被确认” 的时候,不是每一次观察都写,而检索是在循环里的多个点做,不是只在起点做。语义记忆是一张三元组构成的知识图,用于需要结构化组合、而不是相似度的查询 —— “谁向谁汇报”、“哪些产品属于哪个类别”,这些是向量库会压扁的关系。三层分开存,是因为它们被用的方式不一样,而纪律是把写入和读取路由到对的那一层,而不是把所有东西塌进同一个 embedding 索引。

第 4 章为后面铺了什么

智能体和 RAG 都会产生随机的 trace。用户抱怨了,日志里横着一百个 span、跨三种工具、八次模型调用,而团队要判断这次失败是检索回归、prompt 漂移、工具 schema 问题,还是智能体在一个坏掉的下游系统面前做出了正确的选择。这个问题,没有 “把 trace 变成可测量的通过/不通过信号” 的一门纪律,是回答不了的。第 5 章就是这门纪律 —— LLM-as-judge、RAG 三角、针对智能体的轨迹测试,以及那条 “生产 trace 喂进评估集,评估集把下一次发布卡住” 的持续闭环。

明天 — 第 5 章:LLM 应用的评估。把随机 trace 变成团队能据以发布的通过/不通过信号的那门评估纪律。