先从结论说起这年头聊天机器人很便宜Agent 很贵。贵不是指价格而是指你要为“让模型真正动手干活”这件事付出的架构设计成本和学习成本。如果你已经跑通了第一个 Agent demo跟着教程点了几下让它查了天气、订了闹钟那你现在大概率处于“会跑但不知道怎么造”的状态——这就是本篇文章要补上的那段空隙AI Agent 的核心原理到底是什么主流架构为什么长成现在这个样子以及当你要把它搬到生产环境时哪几层是你绕不过去的。这篇教程是系列的第二篇默认你已经了解了大模型的调用方式、Function Calling 的基本用法也知道一个最简单的 Agent 循环大概长什么样。本篇会用大量“底层机制拆解 框架对照 工程落地方案”的写法把 Agent 从概念层拉到代码层和部署层。适合准备自己动手设计 Agent 系统、或者正在选型框架但不知道各家优劣的开发者。1. 模型、聊天机器人与 Agent能力边界到底划在哪很多人第一次接触 Agent 的概念是在 ChatGPT 大火之后看到的各种“AutoGPT 自动完成一切”的惊悚标题。实际动手之后会发现事情远没有那么神奇。为了搞清楚 Agent 的原理我们得先精确地定位一件事模型、聊天机器人、Agent 这三者究竟差在哪。1.1 聊天机器人是“有话就答”Agent 是“要事闭环”聊天机器人Chatbot的核心能力是生成文本。你给它一段对话历史它负责续写一段合理的回复。这个“合理”只针对文本本身不针对外部世界的真实状态。你说“帮我关一下空调”它回“好的已为您关闭空调”但空调实际上纹丝不动——因为文本世界和物理世界之间没有桥。Agent 就不一样了。Agent 的定义里包含一个关键动作在真实环境里采取行动然后观察行动的结果再决定下一步干什么。这个“行动-观察-再决策”的闭环是把 Agent 和 Chatbot 区分开的本质界限。一个只有文本生成能力的模型哪怕你给它一万个角色设定它也不会变成 Agent因为没有行动接口没有反馈回路。1.2 把模型当成“实习生”而不是“资料库”用一个更贴近日常的比喻大语言模型是实习生它知识面广、反应快、表达流利但没在公司待过一天。你要是把它当成一个什么都知道的数据库来用那它给你的答案就会呈现出幻觉与自信并存的状态。你要是把它当成一个可以分派任务并持续纠偏的实习生来用那你就得给它工具、给反馈、给截止时间甚至要盯它的过程而不只看结果。这个视角转换是理解 Agent 原理的第一道坎。Agent 不是模型本身的能力跃迁而是一种围绕模型搭建的工程脚手架。模型是脑子Agent 是完整的“人”——有眼睛、有手、有短期记忆和长期笔记甚至要有脾气检测机制也就是 result 反馈。架构设计的本质就是在给这个“实习生”配上他缺的所有部件。1.3 理解“推理”与“执行”的分离大模型在 Agent 里承担的角色严格来说是“推理器”而不是“执行器”。它负责把用户的目标拆解成步骤、选择合适的工具、根据中间结果调整策略——这一切都是推理。真正执行动作的是工具、API、代码、机器人硬件甚至另一个子 Agent。把这个分离想明白你就能理解为什么 ARM 架构、微服务架构这些词汇会出现在 Agent 相关讨论里——Agent 的编排层和模型推理层混在一起会非常混乱所以生产级架构一定会把“推理决策”和“工具执行”拆成独立的模块来部署和维护。推理服务是一组带显存上限的模型进程工具执行则是完全不同的、可能是 PHP 也可能是 Node.js 写的老服务。二者之间靠消息格式对齐而非共享内存。这个分离是后续一切架构讨论的起点。2. Agent 内核的四件套模型、记忆、工具与执行循环抛开所有花哨的架构名词一个 Agent 的“最小可行内核”由四样东西组成。我把它们称为四件套。先记住这四个部分后面的所有架构模式都是围绕它们的不同排列组合。2.1 模型层这不是选哪个 GPT 版本的问题模型层是最容易被低估的一层。很多人选模型只看“聪明不聪明”但在 Agent 场景里你更加需要关注三个指标指令遵循的稳定性、Function Calling 的成功率、上下文窗口与实际成本的比例。指令遵循稳定性指模型是否会漏掉你规定的输出格式约束。你规定它“只输出 JSON”它偶尔给你夹带几句 Markdown这在对话场景无伤大雅但在 Agent 自动化链路里会直接导致解析崩溃。我实测过不少小参数模型单轮对话看上去可用一旦进入三步以上的工具调用循环遗忘指令的概率会显著上升——这和一个实习生干久了开始偷懒是同一个原理。Function Calling 成功率更是核心中的核心。模型需要从一段自然语言里判断“现在该调天气接口了”并且还要正确地从对话上下文里抽出城市名填进参数。这个过程的错误率在两步以内可能不显眼但在十步以上的长链路里会被指数级放大。所以选择模型时不要只看榜单分数一定要去翻各家模型在 tool-use 专项测试上的表现。2.2 记忆层短期靠上下文长期靠外置存储记忆是 Agent 架构里最容易被误解的部分。很多新手以为把对话历史一股脑塞进 prompt 就算“给 Agent 装上了记忆”这其实混淆了两种完全不同的记忆工作记忆Working Memory存放在上下文窗口内是模型决策时能实时看到的全部信息。它的特点是快但容量有限而且随着 token 增长成本和时间都会非线性上升。长期记忆Long-term Memory存放在外部数据库或向量索引里Agent 在执行任务时按需检索把相关的历史片段“召回”进工作记忆。这才是真正持久的记忆。生产级 Agent 的记忆设计核心思路是“不要把记忆交给模型要把记忆交给数据库”。模型只负责读取最近一小段相关性最高的记忆其余历史全部搁在向量库里待命。这样做的好处是上下文长度可控成本和延迟都稳定。这里可以顺带解释为什么向量检索在 Agent 架构里地位这么高——它不是用来做“语义搜题”的玩具而是 Agent 长期记忆的标准存取接口。2.3 工具层给模型插上接真实世界的接口工具层是 Agent 区别于纯聊天的最关键拼图。每个工具的本质是一个“模型的意图 参数”到“外部系统的一次确定性操作”的转译器。模型先说“我想查询北京的天气参数 city北京”工具层负责把这个意图翻译成一个真实的 HTTP 请求然后把返回结果收拾干净、交回给模型。这里值得多说一句工具的设计质量会直接决定 Agent 的整体成功率。一个工具应该做到“名称自解释、描述写清楚、参数有约束、返回是结构化数据”。很多人写工具描述时很随意比如只写“获取天气信息”模型面对“今天要不要带伞”这种需求时很可能不知道该不该调用这个工具或者不知道应该传城市还是传日期。好的工具描述应该像写给同事的接口注释工具名: get_weather 描述: 根据城市名获取当天天气概况与降水概率用于回答出行、穿衣、是否带伞等日常问题。 参数: city, string, 必填, 城市中文名或拼音; date, string, 选填, 默认当天工具返回的结果同样重要。如果工具返回一段冗长的 HTML模型从中提取关键信息的准确率会下降还会浪费大量 token。生产实践里最好让工具层预先清洗好返回结果只给模型喂摘要化、结构化的信息。一句话模型不值得去读原始返回工具层才是数据清洗该发生的地方。2.4 执行循环Agent 的“思考-行动-观察”节拍器把四件套串联起来的是执行循环。目前最主流、也最容易被理解的一种循环范式叫 ReActReasoning Acting它的逻辑用伪代码写出来非常直白while not done: thought llm.complete( promptbuild_reasoning_prompt( tasktask, contextcontext, # 工作记忆 tool_resultstool_results # 上一轮工具观察结果 ) ) if thought.action finish: return thought.answer else: result execute_tool(thought.action) # 确定性执行 context compress_context(context, thought, result) tool_results result current_step 1这段循环看起来简单但里面藏着三个最折磨人的问题何时结束、何时重试、怎么防止死循环。没有经验的实现者往往写一个无限循环让它跑结果模型在同一个错误上反复横跳直到把成本烧穿。所以执行循环一定要有硬性边界——最大迭代次数、结果校验规则、失败重试的上限缺一不可。3. 主流的 Agent 架构模式单兵、规划师与多智能体了解了最小内核之后我们来聊架构。你去看市面上的 Agent 框架LangChain、AutoGPT、MetaGPT、AutoGen、CrewAI 等会发现它们本质上没有脱离少数几种“组织模式”。理解了这些模式你就能看懂框架的设计意图而不是被文档牵着鼻子走。3.1 单 Agent 模式ReAct 的吃过见过单 Agent 模式是最简单的架构也是最容易被低估的。它的形态就是第 2 章说的那个循环一个模型、一组工具、一段上下文、一个循环。LangChain 里的 AgentExecutor、OpenAI 的 Assistants API 默认行为差不多都是这种模式。这种模式的优势是逻辑简单、链路短、调试直观。它的问题是单线程思维——整个任务的处理深度受限于上下文窗口一旦任务步骤超过十几个早期的关键信息就可能被挤出窗口Agent 就会变成“金鱼记忆”。所以 ReAct 单兵最适合的场景是工具数量不多十几个以内、任务步骤中等几步到十几步、对实时性要求较高的交互场景。3.2 规划-执行分离模式Plan-and-Execute 的两段式单兵模式的痛点在于“走一步看一步”于是有一种更稳的架构第一步让模型专门做规划输出一份完整的任务步骤清单第二步再按清单逐项执行执行过程中可以随时返回去修订计划。这就是 Plan-and-Execute 架构也是“规划器 执行器”的双模块架构。拆开的好处非常明显规划时不被工具返回结果干扰执行时不被全局任务压垮。规划器可以把大任务拆成粒度合适的子任务执行器专注于当前子任务的“行动-观察”循环。这种架构对复杂任务比如“整理一批销售数据并生成月报 PPT”表现远好于单 Agent因为它把“想”和“做”解耦有效降低了上下文碎片化的问题。它的代价是多了一次额外的模型往返——先规划再执行中间多消耗一次 token 和一轮延迟。在流程非常短的场景里这个开销有点不划算但在长耗时任务里多花这一次调用的时间是赚的。3.3 多智能体协作模式把“一个全能人”换成“一队专才”当你觉得单 Agent 再怎么做也绕不过上下文限制时多智能体Multi-Agent架构出现了。核心思路是不逼一个模型当全才而是让多个模型/Agent 各司其职彼此之间通过消息传递协作。MetaGPT 里就设定了产品经理、架构师、程序员、测试员等角色每个角色由独立的 Agent 承担通过共享信息池逐级传递产物。AutoGen 则更灵活支持两个 Agent 之间对话式协作一个出方案、一个挑毛病CrewAI 则强调角色和流程的编排让不同 Agent 像团队成员一样按流程接力。多智能体架构解决的问题很实际角色职责清晰、上下文隔离每个 Agent 只需关心与自己职责相关的信息、可扩展性强加一个“审计 Agent”不需要重写现有代码。但代价同样沉重消息协议设计难度陡增、编排逻辑复杂度指数上升、整体延迟和成本几乎成倍增长。我见过不少项目为了炫技引入多智能体结果反而因为消息解析失败、角色间相互干扰而比单 Agent 跑得还差。下表是三种主流模式的横向对比架构模式核心优势主要瓶颈上下文压力工程复杂度适用场景单 AgentReAct简单直观、调试快长任务易失忆高低工具少、步骤少的交互任务Plan-and-Execute规划稳定、执行专注多一次模型往返中中步骤较长的复杂任务Multi-Agent角色隔离、职责清晰协作协议复杂低分而治之高多人协作模拟、复杂流水线3.4 为什么主流框架都在“缝合”这些模式现在再看 LangChain、LlamaIndex 这类框架你会看到它们既支持 AgentExecutor单 Agent又支持 Plan-and-Execute还支持多 Agent 的编排。原因在于真实世界的任务根本不是单一模式能覆盖的——一个生产系统里简单工具直接走 ReAct复杂子任务派发给规划器拆解跨部门协作才需要多 Agent。框架存在的意义是让你在同一套抽象里自由组合这些模式而不是替你决定用哪一种。理解这一点选型纠结就会少很多。4. 生产级 Agent 的分层架构设计从模型调用到可观测性原理和模式聊清楚了现在落到工程。你可以在 Jupyter Notebook 里玩 Agent但如果你要把它做成线上服务需要的是分层架构而不是一个循环写到底。下面我按生产实践里的部署视角把 Agent 系统拆成六个清晰的层。4.1 接入与对话管理层Gateway Layer接入层是用户和 Agent 之间的第一道门。它的职责不光是接收消息还包括身份认证、会话管理、并发控制、请求路由。在 Agent 场景下有一个特殊的难点长时任务的会话管理。用户可能上午发起一个“分析全站日志”的任务下午才回来看结果接入层必须管理这种异步状态。我的建议是接入层不要直接持有 Agent 实例而是维护一个“任务状态机”。每个用户请求进入后先创建任务任务轮询、取消、超时都由接入层统一管。这样即使 Agent 崩溃重启任务状态依然能从持久层恢复不至于让用户莫名其妙丢进度。4.2 编排层Orchestration LayerAgent 的大脑中枢编排层是整个系统的核心。它负责选择用哪种架构模式单 Agent、Plan-and-Execute 还是 Multi-Agent、调度执行循环、维护工作记忆上下文。这一层体现的是你对第 3 章所有模式的理解。编排层最关键的设计决策是把“策略”与“机制”分开。机制是指执行循环、工具调用、重试、终止这些固定动作策略是指“现在该走哪条路”“这个任务要不要拆给别的 Agent”这种灵活决策。如果你把策略硬编码进机制里系统会变得极其脆弱如果你把策略全部交给模型又会变得不可控。好的实践是机制做扎实策略做成可配置规则规则覆盖不到的部分才让模型发挥。4.3 模型路由层Model Router不止一个模型在干活生产系统里基本不会只用一个大模型。我见过的一个典型配置是轻量级任务用速度快、成本低的小模型复杂推理任务路由给旗舰大模型特定结构化输出任务甚至可能用微调过的专用模型。模型路由层的目标是让每一类请求都以“性价比最优”的方式完成。实现上可以很简单——一个基于规则的分类器先判断任务复杂度再决定调用哪个模型。也可以复杂到用一个专门的“路由小模型”通常是一个分类模型实时选路。不管怎么做关键是指标要明确准确率和成本往往比“每一步都用最强模型”更重要。4.4 工具注册与执行层Tool Gateway工具层应该是你投入最多精细化打磨的地方。生产级的工具不是简单的 Python 函数它是一个完整的“执行单元”包含工具描述、参数 Schema、权限校验、超时控制、错误映射、结果标准化。有一个常见坑工具的权限校验放在 Agent 内部做。这其实很危险因为 Agent 的上下文里可能有越权信息比如一个工具返回了另一个用户的数据一旦模型误用就可能产生严重问题。我的习惯是**工具的权限校验永远在工具网关层做与模型决策完全无关。**模型只负责表达意图能不能执行、允许执行是工具网关根据当前用户的身份和角色决定的。4.5 记忆与上下文工程层Memory Context Layer这一层承担的是第 2.2 节说的记忆职责但在生产环境下复杂度高得多。你需要考虑的不只是“存到向量库里”还有几个实际问题上下文预算管理。每轮对话的 token 上限是硬约束。执行循环每走一步都会产生新的工具返回和模型思考如果一直往上下文里追加很快会触顶。所以常见做法是“滚动窗口 摘要压缩”保留最近的 N 轮对话再往前的内容由模型做一个摘要把摘要留在上下文里原始内容进长期存储。这样既保留了大局又控制了体积。向量检索的召回质量。长期记忆不是“存进去就能用”的。召回效果取决于你的索引拆分方式、检索 top-k 以及重排策略。我见过不少人把整段历史带标题一起塞给向量模型然后抱怨“检索结果跟没检索一样”。正确的做法是记忆条目的信息密度要控制在一个合理范围——太长则语义被稀释太短则缺少上下文需要你根据任务类型反复调优。记忆写入策略。不是所有对话细节都值得存进长期记忆。生产环境要设置“记忆写入条件”——比如用户明确表达偏好、任务完成后的总结性信息、错误修正的记录这才值得写入。普通寒暄和过程日志写了反而是噪音。4.6 可观测性与评估层Observability EvalAgent 的仪表盘最后一层是大家最容易忽略、但生产环境里最救命的一层。Agent 系统的非确定性比传统服务高得多没有可观测性你根本没法回答“为什么这个用户的任务失败了”这种基本问题。我的建议是至少记录以下信息每轮循环的完整状态模型输入prompt 文本、模型输出thinking/action/tool_call、工具返回结果每步的 token 消耗与延迟按模型、按用户聚合工具调用的分布哪些工具被频繁调用、哪些工具长期无调用可以考虑下线任务终态成功完成、达到最大步数、触发安全熔断以及对应原因用户反馈最终答案被点赞还是被举报与过程链路的关联关系。评估层则更偏“离线”。你要有一套覆盖典型任务和边缘案例的评测集每次改模型版本或改 prompt都先在这套评测集上跑一遍用任务成功率、平均步数、工具调用正确率等指标来量化变化。“没有评测的 Agent 迭代就是盲飞”这句话值得贴在所有 Agent 项目代码仓库的 README 第一行。5. 架构落地时最折磨人的几个坑我的实测记录最后分享几个我在生产环境里真实踩过的坑。这些坑不是教程里会写的那种但它们几乎是每个 Agent 项目从 demo 到上线必然遇到的坎。5.1 循环失控模型会在同一个错误上反复横跳第一次跑长任务时我遭遇了 Agent 在“查询天气失败”和“重试查询天气”之间来回循环。原因很典型工具因为参数校验失败返回了错误模型看到了错误但没意识到要换参数名而是以为工具临时故障于是用同一套错误参数重试了十几次。解决这个问题我在架构层面加了两道保险一是执行循环的最大迭代次数一般不超过 15二是工具错误信息的“结构化引导”——工具不仅在返回值里说“调用失败”还要给出失败原因和可行的修正建议比如“city 参数期望格式为中文城市名如‘北京’当前收到‘beijing123’”。这个引导词的加入让模型从“瞎试”变成“有方向地修正”成功率显著提升。5.2 工具返回的“自由文本”会摧毁模型判断力早期我把工具返回设计成“人类可读的自然语言描述”比如工具直接返回“北京今天晴气温 12~22 摄氏度北风 3 级”。人类看着很舒服但模型在长链任务中会开始“二次加工”——一会儿说“北风 3 级”一会儿说“有风”最后在总结时出现事实漂移。后来我把工具返回改成强结构化的 JSON并在工具描述里规定“模型不得复述工具返回原文只能基于结构化字段生成回答”。这个改动直接把下游生成的事实一致性拉高了一个台阶。所以工具的返回结构越僵化越好模型发挥的空间越小越好。5.3 “接上向量库就有长期记忆”是个危险幻觉第二版架构里我给 Agent 加了向量记忆结果出现了“记忆污染”Agent 从向量库里召回了一条无关但语义相似的历史信息并且把它当成当前任务的指令执行了。排查下来发现问题出在记忆写入时的“顺手存档”——我们把每轮工具日志都写进了长期记忆。正确做法是记忆写入前必须经过一个筛选策略只保存对以后任务有帮助的信息而且保存时要标注好时间、任务来源、有效范围。召回端也要加一个“相关性判定”步骤低于相关性阈值的记忆宁可拒绝召回也不放它进上下文。5.4 没有评估体系的 Agent 改起来就是在赌博有一次我调整了一个工具的描述自认为改得更“准确”了结果在线上跑了一周后任务成功率反而掉了 8 个百分点。回头复盘才发现新描述让模型更频繁地选择了另一个工具那个工具虽然描述更贴近用户意图但真实执行质量较差。之后我痛定思痛搭了一套最小评估闭环录下真实用户任务 50 条给每条的期望执行步骤做标注每次改动prompt、工具描述、模型版本都先在评测集上重跑对比“任务成功率、平均步数、工具选择准确率”三项指标。“看起来合理”和“实际有效”之间永远隔着一次评测的距离。个人体会Agent 架构设计这件事90% 的时间不是在写循环逻辑而是在反反复复打磨上下文格式、工具描述、记忆策略和评测集。模型本身的迭代是加法而架构设计是乘法——底层架构做对了模型换一个更强的版本系统整体质量会直接跟着涨底层架构乱七八糟换什么模型都救不回来。希望这篇教程能帮你把这个“乘法系数”尽量抬高一点。