最近这两年AI Agent 大概是整个技术圈里出场率最高的词之一。可如果你真的坐下来跟人聊上十分钟会发现大家对它的理解可以差出整个银河系——有人拿它指一个带工具的聊天机器人有人拿它指一群模型互相开会的系统有人干脆把所有带自动化的大模型应用都叫 Agent。“概念串烧”这个题目我觉得特别贴切现在 AI Agent 确实是一锅概念搅在一起的大杂烩但杂烩归杂烩里头每一样食材都有自己的来路和作用。这篇文章想做的事很简单把 AI Agent 这条主线上最常出现的那些概念一个个拆开、串好讲清楚它们各自在解决什么问题、彼此之间怎么衔接以及看完之后你怎么用这套概念去判断手头的项目该不该上 Agent、该从哪一步入手。这篇内容适合两类人一类是对 Agent 只有模糊印象、想系统把概念理清楚的开发者或产品经理另一类是已经在写代码、但被各种术语搞得头大、想在动手前搞清楚“这些概念到底哪个是哪个”的实践者。我会尽量用讲人话的方式不堆术语但该深入的也会深入。1. 串烧之前先把Agent这条主线的轮廓画出来1.1 AI Agent不是新瓶子是LLM应用的新骨架Agent 这个概念本身并不新。人工智能早期的教材里就有它的经典定义处在某个环境之中能够感知环境、做出决策、并采取行动来影响环境的自主实体。一个恒温器算半个 Agent因为它感知温度、做出开关决策、执行加热或制冷一个扫地机器人是一个更完整的 Agent因为它能感知障碍物、规划清扫路线、执行移动和清洁。过去几十年里Agent 一直是人工智能研究里的一个理想化目标但真正做得好的成品并不多原因是“决策大脑”太难做了——传统规则系统只能处理有限的场景一旦环境复杂一点规则就写不完。大语言模型出现之后整个局面变了。LLM 本身就是一个极强的大规模“决策大脑”给它一段文本它能理解目标、拆解任务、生成下一步指令。于是现在大家说的 AI Agent本质上是把传统 Agent 的“大脑”换成了大模型其余部件依然沿袭了感知、规划、记忆、工具、行动这一套老框架。这也是为什么很多人第一次接触 Agent 时会觉得“这东西没有多新鲜”——骨架确实是老的新鲜的是骨架上面那个会推理、会表达、能应对开放任务的脑。我比较喜欢用一句话跟非技术背景的朋友解释普通 AI 产品是你问一句、它答一句而 Agent 是你说一个目标它自己决定中间要做哪些操作来完成这个目标。前者是问答后者是干活。这也是 Agent 和传统 Chatbot 之间的分界线——Chatbot 的核心价值在“答得准”Agent 的核心价值在“做得完”。1.2 先记一张Agent的“零件清单”概念串烧之前建议先把所有概念归类挂靠。我常跟团队说你不要记一个概念对应一个名词而是记这个概念在整个 Agent 的哪个环节起作用。下面这张零件清单基本能覆盖当前市面上 90% 的 Agent 系统组成部分承担角色常见实现手段大脑决策中枢理解目标、拆分任务、做出下一步决策大语言模型LLM感知接收用户输入、外部环境信息多模态输入、接口数据接入、消息解析规划把大任务拆成子任务、排优先级、决定先后思维链、ReAct、Plan-and-Execute 等模式记忆保存任务状态、历史对话和长期事实上下文窗口、向量数据库、结构化存储工具执行具体动作、访问外部系统函数调用、API 接口、代码解释器反馈与反思检查输出质量、发现错误并自我修正自我反思、外部评估、人工审核这张表的好处是当你听到任何一个 Agent 相关的术语时可以先问一句它挂在这张表的哪一行比如“RAG”挂的是记忆和感知那一层“函数调用”挂的是工具那一层“ReAct”挂的是规划那一层“多智能体”挂的是整张系统结构那一层。概念一旦落到零件上就不太容易被绕晕。需要特别提一句一个真正完整的 Agent 是缺不了这些零件协同的。只会对话不会调用工具它顶多算一个会聊天的助手只会检索资料没有规划能力它也只是个搜索引擎套壳没有记忆它每轮任务都得从头来根本支撑不起复杂工作流。概念的串烧本质就是这些零件之间的联动。2. 第一串被最先聊滥的概念——上下文、Token与函数调用2.1 上下文窗口Agent的工作内存第一个绕不开的概念是上下文窗口。每个大模型都有一个上下文窗口它决定了一次请求里模型最多能“看到”多少文本。你可以把上下文窗口想象成一张固定大小的会议桌桌上能摊开的资料数量有限新资料放上来太旧的东西就得被收走或者干脆丢掉。对 Agent 来说这张会议桌就是它的工作内存。这个内存非常宝贵因为 Agent 的运行机制是——把系统提示、用户目标、当前任务状态、工具返回结果、过往对话历史全部拼在一起塞给模型做决策。多步任务执行下来这些文本会越堆越多一旦超出上下文窗口就会发生两件麻烦事一是程序直接报错二是即便没报错模型也会“忘掉”早期信息表现得很像人类思维里的注意力涣散。这里顺带说下 Token 是什么。Token 是模型计数的基本单位通俗理解就是一个词、一个片段、一个字符块被切成的最小单元。中文场景下大概 1000 个汉字折算成 1000 到 2000 个 Token具体取决于模型的分词器。Token 有两个直接作用它决定上下文窗口能装多少内容也决定你为每次请求花多少钱。所以很多做 Agent 的人聊到“上下文优化”时本质是在想办法用更少的 Token 装下更关键的信息——这个话题我们下一章细聊。2.2 Function Calling大模型长出“手脚”如果说上下文窗口是 Agent 的大脑内存那函数调用Function Calling / Tool Calling就是让 Agent 长出“手脚”的关键机制。大模型本质上是一个文本进、文本出的系统它不会真的去访问数据库、调用第三方 API 或执行代码。函数调用做的事情是让模型以结构化的方式“声明”它想要调用哪个工具、传什么参数然后由我们的程序去真正执行这个工具最后把执行结果放回上下文供模型继续推理。整个流程拆开看是这样的给模型注册一批工具描述包括工具名称、功能说明、参数格式通常以 JSON Schema 的形式提供模型在推理过程中判断“我需要调用某个工具来完成这一步”模型输出一段结构化的调用指令而不是自然语言我们的程序解析这段指令执行真实的函数把执行结果作为新的上下文片段返回给模型模型基于这个结果决定下一步做什么。举个最简单的例子让一个 Agent 查某个订单的物流信息。传统做法是你写死一段代码调接口函数调用方式则是你给模型描述一个工具叫“查询物流”参数是订单号。模型读懂了你的问题里包含订单号就自动输出调用这个工具的指令程序执行完把物流状态文本塞回去模型再把结果组织成正常人话告诉你。这个机制的意义怎么说都不为过——它彻底改变了“人和程序打交道的方式”。以前是人去适配软件的菜单按钮现在是模型理解人的意图后自己去按按钮。所以它几乎成了所有 Agent 框架的标配能力。2.3 上下文、Token与工具之间的联动关系这三个概念看着独立实际在 Agent 系统里是绑在一起的。每注册一个工具给模型工具描述就会占用上下文空间每让模型思考一步思考过程也占 Token工具返回的结果要进上下文又多占一批 Token。我以前做个调研型 Agent 时遇到过最头疼的问题就是跑着跑着上下文被工具返回的一堆原始文本塞满模型反而开始“迷路”不知道自己的主任务是什么了。关于这一点有几个实践建议可以直接抄第一工具描述要写得“又短又准”不要把所有参数机制的细节都堆上去。你可以告诉模型“这个工具用来查天气参数填城市名”但没必要把超时重试逻辑写在描述里模型不需要看那些。第二工具返回结果尽量做截断或摘要。如果某个接口返回 200 行日志先把关键部分提取出来再放进上下文。别让模型自己去大海捞针它捞出来的概率很不稳定。第三上下文里信息一多模型对中间部分内容的关注度会明显下降。学术上有个现象叫“lost in the middle”——放在上下文中段的信息最容易丢失。因此关键的指令放在开头结论性的内容放在结尾需要模型精确处理的资料尽量靠前靠后别堆在中间。第一串串完你会发现上下文是内存Token 是计量单位函数调用是手脚。没有手和脚内存再大也只会空谈没有内存手脚动几下就不知道怎么继续了。3. 第二串Agent的知识与记忆系统——RAG、上下文工程与记忆机制3.1 RAG给Agent接上外部知识源RAGRetrieval-Augmented Generation检索增强生成可能是大模型应用里最被人熟悉的技术名词之一。它的核心思想很朴素大模型的知识截止到训练数据为止而且训练阶段不可能把你公司的内部文档、产品手册、客服工单全部装进去。那怎么办先把这些私有知识切成小片、用向量化模型转成向量、存进向量数据库等用户提出问题时把问题也转成向量去检索最相关的知识片段最后再把检索结果拼进模型的上下文里让模型基于这些材料作答。放到 Agent 的语境里RAG 通常不是独立存在而是被封装成一个“知识检索工具”挂在 Agent 上。Agent 收到任务后判断需要哪些资料调用检索工具去知识库捞内容捞完再继续推理。比如一个客服 Agent 接到“客户问退款流程是什么”这个问题它会先去知识库检索退款相关的最新政策然后根据政策原文生成回答。这样既保证了回答基于最新信息也把“胡说八道”的概率压到较低水平。但 RAG 听着简单落地时坑不少。最容易翻车的是切片策略切片太大检索回来的内容包含大量噪声稀释注意力切片太小关键信息被切断模型看到的都是片段拼不出完整答案。另一个关键点是检索后的重排——很多系统只取 TopK 直接丢给模型但如果前十篇里只有两篇真正相关模型很容易被不相关内容带偏。一套成熟的 RAG 管线通常需要持续调 Embedding 模型和重排序策略这一步的性价比甚至比换更大参数的模型都高。3.2 上下文工程有限窗口里排信息的优先级如果说 RAG 解决的是“信息从哪来”那上下文工程Context Engineering解决的则是“这些信息怎么摆给模型看”。这是最近一两年才被频繁提起的概念但它的重要性一点不亚于提示词工程。我常跟自己做比喻给模型一条很长的上下文就像给一个特别忙的项目经理开会前准备材料。你不能把所有原始资料都甩过去而应该按优先级和内在逻辑重新组织成一份既有背景、又有当前问题、又有行动建议的简报。上下文工程干的就是这件事决定哪些内容进上下文、哪些不进以什么顺序放什么时候更新以及如何对历史信息做压缩摘要。实操时通常会这样排优先级系统指令和任务说明最重要放在最前面当前用户目标和任务状态次之工具执行返回的关键结果放在任务所需的对应节点历史对话绝不完整堆砌而是定期压缩成摘要至于大段大段的原始文本只在必要时才以附件形式带入。上下文工程和 Token 管理也是绑在一起的。很多团队一开始会把所有历史消息都保留结果成本直线上升模型反而变迟钝。后来改成“滑动窗口 关键信息摘要”的方案体验立刻好很多。所以如果要做 Agent我建议把“上下文预算”当成一个正式设计环节来对待——先给每次请求定一个 Token 预算然后严格执行超了就得做压缩而不是任它膨胀。3.3 记忆机制短期、长期与工作记忆的分工记忆这个概念在 Agent 里比在普通大模型应用里更复杂。大模型的上下文窗口本身就是一种短期记忆你在这个对话里说的内容它还记得但新开一个会话之后它就什么都忘了。所以真正做 Agent 系统的人一定会考虑给 Agent 搭一套分层记忆第一层叫短期记忆也就是当前正在进行的对话上下文。比如用户说“我要订一份去某城市的机票预算 3000 元”这些信息就存在短期记忆里整个订票流程中模型都要时刻记住。第二层叫长期记忆通常落在外部存储里最常见的是向量数据库加关系型数据库。用户的偏好、项目的历史决策、过去处理过的问题这些信息在任务开始时被检索出来放进上下文用完再存回去。第三层叫工作记忆承载的是当前任务的结构化中间状态。比如一个多步骤研究任务做到一半的进展、已经完成的子任务清单、下一步待办事项。工作记忆的设计好坏直接决定 Agent 是不是一个合格的“打工人”——工作记忆清晰Agent 中断后还能接着干工作记忆混乱Agent 做两步就丢三落四。我见过很多初期 Agent 项目犯同一个错误把长期记忆直接等同于“把所有东西都塞进向量库”然后查询的时候又不知道该检索什么。实际上记忆应该是有结构侧重点的偏好类信息、事实类信息、过程类信息分别放不同的存储检索策略也完全不同。结构比容量重要得多。3.4 三者合流一套可持续运转的知识回路把 RAG、上下文工程和记忆机制放一起看其实是一条完整的知识回路。RAG 是 Agent 和外部知识库的连接通道负责把外部资料拉进来记忆机制是 Agent 自身经验的沉淀负责把历史经验留住而上下文工程是这条回路上最关键的编排器负责决定当前这一轮模型到底能看到哪些信息。我用一个具体例子串起来给你看。假设我们做一个技术文档编写助手它的工作流程是这样用户丢进来一堆素材说明要写一篇上线方案。Agent 先启动从长期记忆中调出团队偏好的文档模板和风格要求再从 RAG 检索到相关系统的架构资料把这些信息交给上下文工程压缩整理组成当前工作记忆模型根据这些材料生成初稿后把初稿关键摘要写回长期记忆同时保留一份工作记忆方便用户后续追问。这个流程跑几轮之后Agent 用得越久越了解团队的写法偏好产出质量也越稳定。设计知识回路时有一条底线不要让任何一环变成瓶颈。RAG 检索慢模型就得干等记忆写回没有做去重脏数据会越来越多上下文压缩做不好模型每轮都感觉像第一次见面。回路里每一环都需要有意识地做质量保障。4. 第三串让Agent“动手干活”的思维框架——CoT、ReAct、Plan-and-Execute与反思4.1 思维链与思维树把思考过程显式化前面聊的都是 Agent 的“硬件设施”接下来这串概念管的是“软件逻辑”——也就是 Agent 的大脑怎么运转。第一个要提的当然是思维链Chain-of-ThoughtCoT。这个方法其实非常朴素你让模型不要直接给答案而是先写出一步步的推理过程。早期研究发现当模型被要求“think step by step”时在数学题、逻辑题上的正确率会明显提升因为显式的推理路径降低了跳步犯错的可能性。这背后的机制可以理解成大模型的隐空间里存了很多推理能力但默认输出时倾向于“走捷径”思维链强制它把捷径拆成一段段可检查的路径每一步都受注意力监督出错的概率自然下降。思维树Tree-of-ThoughtToT是思维链的升级版它不止生成一条推理路径而是同时探索多个候选思路交叉对比后选最优。这种多路径分支的代价是 Token 消耗成倍增加实际应用时通常只在难题上使用。不过要泼一盆冷水思维链并非万能。任务很简单时硬套思维链只会拉长回答、增加成本模型能力本身不够时思维链也无法让它突破上限。因此更合理的做法是把思维链当作可配置项复杂逻辑任务启用简单查询任务关闭动态决定要不要“让子弹飞一会儿”。4.2 ReAct思考与行动交替循环如果说 CoT 是“光思考不行动”那 ReAct 就是在思考和对环境的行动之间来回切换。ReAct 这个名字由 Reason推理和 Act行动拼在一起它的循环模式大致是观察输入 → 推理当前该做什么 → 执行一个动作比如调用工具 → 观察动作结果 → 再次推理如此往复直到完成目标。这个模式特别适合那些需要多步探索的动态任务。举个例子让一个 Agent 去调研某个产品在电商平台上的用户评价它第一步可能先调用搜索工具找到商品列表第二步打开某个商品详情页第三步调出评论区摘要每一步的观察结果都驱动下一步决策。整个行为看起来很像一个实习生在那儿查资料——只是这个实习生反应快一点、同时也会犯糊涂。ReAct 的好处是灵活能应对事先没预料到的情况坏处是执行步数不可控而且上下文会随着循环次数增加不断膨胀。现实中经常出现 Agent 在一件小事上反复调用工具就是不收尾的情况。所以落地 ReAct 时必须设置两个硬约束一是最大循环次数比如 10 步就强制终止二是“显式收尾”条件让模型在自认为目标已达成时必须主动输出结束标记而不是继续探索。4.3 Plan-and-Execute先画路线图再逐步落地和 ReAct 的走一步看一步不同Plan-and-Execute 的思路是先规划后执行。模型拿到任务后先输出一份完整的行动计划列清楚要做哪几件事、按什么顺序、每件事的输出是什么然后系统按这份计划逐步执行每执行一步模型可以选择复核计划是否需要调整但大部分步骤是不需要重新思考的。这种做法带来的最大好处是可控和可审计。计划本身就是一份中间产物你可以让用户看到 Agent 打算怎么干不满意可以中途改执行过程也更容易打日志、做追踪。很多做企业内部工具的人喜欢 Plan-and-Execute因为“让模型先生成一个可检查的方案”比“直接开始自动操作”更符合企业流程的审批习惯。当然 Plan-and-Execute 也有自己的问题如果开头生成的计划就跑偏后面每一步都是错的。好在实践中几乎不会让计划一成不变照做而是加了一个“重规划点”——每完成几个子任务就重新审视剩余计划是否需要调整。这样一来它兼顾了 ReAct 的灵活性和计划模式的可控性算是一种更稳妥的折中。4.4 反思机制Agent自己给自己挑刺反思Reflection / Self-Refine是近一年讨论度很高的概念。它的实现方式通常是让模型先产出一版结果然后用一个额外的提示词或者一个独立的“评审模型”去检查这版结果找出问题再让原模型基于这些反馈重写。这个过程可以跑一轮也可以跑多轮。说通俗点就是让 Agent 干完活后自己再当一遍质检员。反思机制在代码生成和内容创作里效果非常明显。比如一个代码 Agent 生成了代码先让它自己跑一遍测试再把报错信息拿回来修改一个文案 Agent 写完初稿后先让“评审者”角色检查逻辑漏洞和语气是否一致再基于意见修改。这种“先产出、再批评、再修订”的模式往往能显著提升第一版结果的完成度。但反思不是免费的。每一轮反思都要消耗一笔额外的 Token 和延迟而且如果评审 prompt 设计得不好模型可能把原本不错的输出改得越来越平淡。实操中要注意两点给反思设置明确标准比如检查清单式的评价维度而不是笼统说“请检查”给反思设置轮数上限一般 1 到 2 轮足够超过这个极限收益曲线会快速递减。4.5 不同思维框架怎么选一张对比表模式核心思路优点缺点典型场景思维链CoT显式写下推理过程再作答简单、成本低、提升逻辑性不接触外部信息数学题、逻辑分析、方案推理思维树ToT并行探索多条推理路径对难题更稳、可对比选优Token 消耗大高难度规划、多方案权衡ReAct推理与行动交替循环灵活、动态适应环境步数不可控、上下文膨胀多步调研、带工具的探索任务Plan-and-Execute先出计划再逐步执行可控、可审计、适合审批计划错误需要重规划流程清晰的企业任务Reflection输出后自我评审修订提升质量、减少低级错误额外成本、可能过度修改代码生成、文案审核这些模式不是互斥的实际 Agent 系统里经常混用。比如一个复杂任务可以用 Plan-and-Execute 先做顶层规划每个子步骤内部又跑 ReAct 循环结束前再加一轮 Reflection 做质检。模式的选择本质上是针对任务特点做“可预测性和灵活性的权衡”——任务越标准化就越往前两种靠任务越开放就越需要 ReAct 和重规划。5. 第四串从单打独斗到排兵布阵——多智能体、编排与协作模式5.1 多智能体为什么成了必选项单个 Agent 做得再强也有几个天花板。第一个是上下文窗口的限制你不可能让一个 Agent 同时精通十种行业知识、装进几十个工具的完整说明并保持思路清晰第二个是角色冲突让模型同时扮演“严谨的审查者”和“自由的创作者”时两个角色会互相干扰第三个是故障隔离一个全功能 Agent 出问题整个任务就瘫了。多智能体架构的出发点正是把这些问题拆开。多智能体的思路有点像一个项目组一个项目经理负责拆任务、分配任务、汇总结果底下几个成员分别负责自己最擅长的领域——有人管检索有人管分析有人管写报告各司其职互不干扰。每个子 Agent 的上下文较短、工具域较窄、提示词更聚焦单个质量反而更容易做高。这种拆分的另一个好处是可以并行——几个子任务同时跑整体延迟并不可怕。当然天下没有免费的午餐。多智能体带来了新的问题消息怎么在 Agent 之间传递谁来仲裁不同 Agent 给出的冲突结论多个 Agent 各自消耗的 Token 怎么控制调试的时候一个问题出在两个 Agent 的交互上定位起来比单 Agent 麻烦得多。所以我的个人建议是单 Agent 能解决的绝不强行上多智能体只有当一个 Agent 的上下文和职责确实塞不下或者任务天然有分离的职责边界时才考虑拆分。5.2 常见协作模式与适用场景多智能体的组织方式目前主要有四种可落地的模式主管-下属模式一个主 Agent 负责接收任务、拆分子任务、分派给下属 Agent再收集结果统一汇总。适合任务可以明显拆成多个独立模块的场景比如调研报告、产品方案生成。流水线模式每个 Agent 只负责一个固定环节A 的输出直接作为 B 的输入。适合流程相对固定的场景比如“数据清洗 → 数据分析 → 摘要生成 → 报告格式化”中间不需要太多来回讨论。辩论/评审模式让多个 Agent 分别独立产出观点再由一个仲裁 Agent 综合评判。适合对质量要求高、需要尽量排除偏差的任务比如代码走查、方案设计评审。缺点是多轮交互的成本很高。自由协作模式没有固定结构Agent 之间按需通信通过一个消息中心协调。最灵活也最难控制当前生产环境里用得较少多数还停留在实验阶段。模式控制难度成本适用场景主管-下属中中任务可变、模块可拆流水线低低流程固定、步骤明确辩论/评审高高追求质量、接受延迟自由协作很高高探索性场景不推荐选哪种模式核心看两件事一是任务本身的确定性二是你对结果可控性的要求。确定性越高越适合流水线和计划模式确定性越低越需要主管-下属这种能动态调整的编排。5.3 人在回路保留人类审批的边界讲多智能体讲的都是“自动化”但真正成熟的 Agent 系统一定会强调人在回路Human-in-the-loop。原因很简单大模型的输出天然带有不确定性而且有些操作一旦执行就不可逆。发一封邮件、提交一笔订单、删除一段生产数据、向用户承诺一个方案这些操作如果全自动执行出了事故谁来背锅所以我见过的实践中普遍采用分级处理纯内部信息处理类操作比如查文档、生成草稿、整理数据让 Agent 全自动干外部可见或者有副作用的高风险操作比如对外发送、写数据库、购买下单则强制加入人工确认环节——Agent 把草稿准备好人工点一下确认系统才真正执行。这相当于给 Agent 加了一道“人类闸门”。有些读者可能觉得这样不够“智能”但从工程稳定性角度看人是整条链路里最便宜也最有效的安全防线。算力成本再低也比不上一次误操作带来的业务损失。尤其是客户服务、金融、医疗这类行业人工审批不仅是指标问题很多时候是合规要求。所以做 Agent 设计的时候务必提前定好哪些环节要人工介入在这个问题上宁严勿松。5.4 可观测性Agent系统最难补的一课传统软件项目的可观测性很成熟打日志、抓异常、查监控就行。但 Agent 系统天生难调试——因为模型输出有随机性同一输入跑两次结果可能不同因为决策链很长一个错误可能源于 20 步之前某次工具的返回内容因为没有“代码栈”你很难定位到具体哪一行逻辑出了问题。这也是为什么可观测性需要从第一天就设计进去。我强烈建议由 Agent 系统从最开始就记录这样几类数据每一步输入和输出的完整内容、模型调用的 Token 消耗和耗时、工具调用次数与返回结果摘要、每次任务最终是否达成目标。有条件的团队可以把这些日志汇总成可回放的任务轨迹——出问题时把整条轨迹回放一遍基本能在几分钟内定位问题发生在哪一跳。另一个常被忽视的点是成本观测。多智能体系统跑一轮任务可能消耗非常高不做 Token 账单审计月底你会发现成本超支但根本说不清钱花在了哪个环节。给每个环节打上成本标签按任务维度汇总是 Agent 上生产的必修课。可观测性和评估我会在下一节继续展开。6. 概念串完了动手之前先想清楚这几件事6.1 什么时候真需要Agent什么时候是凑热闹概念了解得再多回到实际开发时第一件事永远是这个需求到底用不用得上 Agent我的判断标准很简单——画一遍传统实现的流程如果规则分支太多、组合空间太大而且后续需求肯定经常变Agent 就有价值如果任务步骤固定、输出结构确定、延迟要求高那老老实实写代码调用大模型接口就够了完全不必要上 Agent。换句话说Agent 适合的是“路径不确定的开放任务”不适合的是“路径确定的重复任务”。硬拿 Agent 做规则引擎能做的事情结果往往是成本更高、延迟更大、还出现不稳定的随机行为。有一阵子大家都喜欢在项目里加 Agent 撑场面但冷静下来很多功能用几个条件判断加一次模型调用就能干完加 Agent 纯粹是给自己添堵。给一个更实操的判断方法你把用户需求完整写下来想象用一个固定代码实现的话需要多少个 if-else 分支。如果分支数量就三五个别用 Agent如果一旦需求变化这些分支就要大改那 Agent 的动态规划能力才有真正发挥空间。6.2 概念落地的推荐路径从稳定小闭环开始就算确定要用 Agent我也建议别一次把所有概念全上。我见过不少团队第一次做 Agent 就想搞多智能体加记忆加 RAG 全家桶结果连主链路都没有调通就被各种变量搅晕项目直接烂尾。比较好的路径是这样第一步先用一个单 Agent 加一到两个必需工具跑通最核心的一条用户链路。此时不搞复杂记忆不做多智能体甚至不加反思。目标是让 Agent 在主路径上稳定完成任务准确率达到可接受水平。第二步引入上下文工程和基础记忆。把历史对话压缩成摘要把用户偏好存起来在任务开始时自动带入相关背景。这一步优化的是可持续使用的体验成本相对可控。第三步按需加入 RAG 和反思。如果说第二步是“让它记得”这一步是“让它知道更多”和“让结果更可靠”。RAG 的切片与检索质量要花专门的精力调试反思的评审标准也要单独打磨。最后才考虑多智能体拆分。而且拆分的理由必须是“当前 Agent 确实忙不过来”而不是“听起来比较先进”。每一步叠加时都要保持上一个功能稳定不退回否则几层复杂度叠在一起问题定位的难度会呈指数级上升。6.3 一件被低估的事评估与回归最后聊一个很多人直到上线出 bug 才会后悔的事评估。传统代码写得好不好可以靠单元测试和代码评审Agent 没有这么直接的验证手段。模型输出是概率性的同一条输入可能给出不同的答案你怎么知道这一版比上一版好怎么判断一次改动究竟是提升了整体效果还是导致某些场景退化务实的做法是从项目第一天就维护一个固定的评估集。挑 20 到 50 个典型用户请求覆盖主流程和边界情况每个版本发布前都用同一批请求跑一遍记录每项任务是否达成目标、工具调用是否正确、回答是否跑偏。因为输出有随机性单次跑不够同一个 case 至少要跑 2 到 3 次看稳定性。评估集一开始不需要大但要随着功能迭代持续补充尤其是把线上用户真实反馈过的坏案例加进去——这相当于给 Agent 做“单元测试”只是它的断言要从“输出某个值”变成“达成某个目标”。另一个值得强调的是中间步骤评估。很多团队只看最终回答对错但 Agent 是一个过程敏感的系统——即便最终结果碰巧正确中间的规划乱套、工具乱调也一样是隐藏风险。我见过一个 Agent 明明最终答案对了但中间为了拿到这个答案绕了五遍弯路多花了三倍 Token。把每个中间步骤是否合理也纳入评估才能真正控制成本和稳定性。串了这么一圈概念我自己最大的体会是AI Agent 的术语虽多但每个概念都在回答一个非常具体的问题。上下文解决“它能看到什么”函数调用解决“它能做什么”RAG 解决“它知道什么”记忆解决“它记得什么”思维框架解决“它怎么想”多智能体解决“一个人忙不过来怎么办”。把这些问题挨个问一遍你自然就知道自己的项目卡在哪里了。我最初做概念验证那会儿总想一步到位把所有概念都用上结果系统又贵又难查问题。后来收敛到先用最简单的单 Agent 加工具闭环把主链路跑稳再一点点往里加记忆、加检索、加评审反而顺利得多。这套概念串烧帮你把盘里的菜挨个认清楚了至于先吃哪一道那得由你手头的任务来决定。 
长河君 · 2026/10/22 14:51:39 · 阅读 1.2k AI Agent概念串烧：一文理清上下文、函数调用与多智能体
最近这两年AI Agent 大概是整个技术圈里出场率最高的词之一。可如果你真的坐下来跟人聊上十分钟会发现大家对它的理解可以差出整个银河系——有人拿它指一个带工具的聊天机器人有人拿它指一群模型互相开会的系统有人干脆把所有带自动化的大模型应用都叫 Agent。“概念串烧”这个题目我觉得特别贴切现在 AI Agent 确实是一锅概念搅在一起的大杂烩但杂烩归杂烩里头每一样食材都有自己的来路和作用。这篇文章想做的事很简单把 AI Agent 这条主线上最常出现的那些概念一个个拆开、串好讲清楚它们各自在解决什么问题、彼此之间怎么衔接以及看完之后你怎么用这套概念去判断手头的项目该不该上 Agent、该从哪一步入手。这篇内容适合两类人一类是对 Agent 只有模糊印象、想系统把概念理清楚的开发者或产品经理另一类是已经在写代码、但被各种术语搞得头大、想在动手前搞清楚“这些概念到底哪个是哪个”的实践者。我会尽量用讲人话的方式不堆术语但该深入的也会深入。1. 串烧之前先把Agent这条主线的轮廓画出来1.1 AI Agent不是新瓶子是LLM应用的新骨架Agent 这个概念本身并不新。人工智能早期的教材里就有它的经典定义处在某个环境之中能够感知环境、做出决策、并采取行动来影响环境的自主实体。一个恒温器算半个 Agent因为它感知温度、做出开关决策、执行加热或制冷一个扫地机器人是一个更完整的 Agent因为它能感知障碍物、规划清扫路线、执行移动和清洁。过去几十年里Agent 一直是人工智能研究里的一个理想化目标但真正做得好的成品并不多原因是“决策大脑”太难做了——传统规则系统只能处理有限的场景一旦环境复杂一点规则就写不完。大语言模型出现之后整个局面变了。LLM 本身就是一个极强的大规模“决策大脑”给它一段文本它能理解目标、拆解任务、生成下一步指令。于是现在大家说的 AI Agent本质上是把传统 Agent 的“大脑”换成了大模型其余部件依然沿袭了感知、规划、记忆、工具、行动这一套老框架。这也是为什么很多人第一次接触 Agent 时会觉得“这东西没有多新鲜”——骨架确实是老的新鲜的是骨架上面那个会推理、会表达、能应对开放任务的脑。我比较喜欢用一句话跟非技术背景的朋友解释普通 AI 产品是你问一句、它答一句而 Agent 是你说一个目标它自己决定中间要做哪些操作来完成这个目标。前者是问答后者是干活。这也是 Agent 和传统 Chatbot 之间的分界线——Chatbot 的核心价值在“答得准”Agent 的核心价值在“做得完”。1.2 先记一张Agent的“零件清单”概念串烧之前建议先把所有概念归类挂靠。我常跟团队说你不要记一个概念对应一个名词而是记这个概念在整个 Agent 的哪个环节起作用。下面这张零件清单基本能覆盖当前市面上 90% 的 Agent 系统组成部分承担角色常见实现手段大脑决策中枢理解目标、拆分任务、做出下一步决策大语言模型LLM感知接收用户输入、外部环境信息多模态输入、接口数据接入、消息解析规划把大任务拆成子任务、排优先级、决定先后思维链、ReAct、Plan-and-Execute 等模式记忆保存任务状态、历史对话和长期事实上下文窗口、向量数据库、结构化存储工具执行具体动作、访问外部系统函数调用、API 接口、代码解释器反馈与反思检查输出质量、发现错误并自我修正自我反思、外部评估、人工审核这张表的好处是当你听到任何一个 Agent 相关的术语时可以先问一句它挂在这张表的哪一行比如“RAG”挂的是记忆和感知那一层“函数调用”挂的是工具那一层“ReAct”挂的是规划那一层“多智能体”挂的是整张系统结构那一层。概念一旦落到零件上就不太容易被绕晕。需要特别提一句一个真正完整的 Agent 是缺不了这些零件协同的。只会对话不会调用工具它顶多算一个会聊天的助手只会检索资料没有规划能力它也只是个搜索引擎套壳没有记忆它每轮任务都得从头来根本支撑不起复杂工作流。概念的串烧本质就是这些零件之间的联动。2. 第一串被最先聊滥的概念——上下文、Token与函数调用2.1 上下文窗口Agent的工作内存第一个绕不开的概念是上下文窗口。每个大模型都有一个上下文窗口它决定了一次请求里模型最多能“看到”多少文本。你可以把上下文窗口想象成一张固定大小的会议桌桌上能摊开的资料数量有限新资料放上来太旧的东西就得被收走或者干脆丢掉。对 Agent 来说这张会议桌就是它的工作内存。这个内存非常宝贵因为 Agent 的运行机制是——把系统提示、用户目标、当前任务状态、工具返回结果、过往对话历史全部拼在一起塞给模型做决策。多步任务执行下来这些文本会越堆越多一旦超出上下文窗口就会发生两件麻烦事一是程序直接报错二是即便没报错模型也会“忘掉”早期信息表现得很像人类思维里的注意力涣散。这里顺带说下 Token 是什么。Token 是模型计数的基本单位通俗理解就是一个词、一个片段、一个字符块被切成的最小单元。中文场景下大概 1000 个汉字折算成 1000 到 2000 个 Token具体取决于模型的分词器。Token 有两个直接作用它决定上下文窗口能装多少内容也决定你为每次请求花多少钱。所以很多做 Agent 的人聊到“上下文优化”时本质是在想办法用更少的 Token 装下更关键的信息——这个话题我们下一章细聊。2.2 Function Calling大模型长出“手脚”如果说上下文窗口是 Agent 的大脑内存那函数调用Function Calling / Tool Calling就是让 Agent 长出“手脚”的关键机制。大模型本质上是一个文本进、文本出的系统它不会真的去访问数据库、调用第三方 API 或执行代码。函数调用做的事情是让模型以结构化的方式“声明”它想要调用哪个工具、传什么参数然后由我们的程序去真正执行这个工具最后把执行结果放回上下文供模型继续推理。整个流程拆开看是这样的给模型注册一批工具描述包括工具名称、功能说明、参数格式通常以 JSON Schema 的形式提供模型在推理过程中判断“我需要调用某个工具来完成这一步”模型输出一段结构化的调用指令而不是自然语言我们的程序解析这段指令执行真实的函数把执行结果作为新的上下文片段返回给模型模型基于这个结果决定下一步做什么。举个最简单的例子让一个 Agent 查某个订单的物流信息。传统做法是你写死一段代码调接口函数调用方式则是你给模型描述一个工具叫“查询物流”参数是订单号。模型读懂了你的问题里包含订单号就自动输出调用这个工具的指令程序执行完把物流状态文本塞回去模型再把结果组织成正常人话告诉你。这个机制的意义怎么说都不为过——它彻底改变了“人和程序打交道的方式”。以前是人去适配软件的菜单按钮现在是模型理解人的意图后自己去按按钮。所以它几乎成了所有 Agent 框架的标配能力。2.3 上下文、Token与工具之间的联动关系这三个概念看着独立实际在 Agent 系统里是绑在一起的。每注册一个工具给模型工具描述就会占用上下文空间每让模型思考一步思考过程也占 Token工具返回的结果要进上下文又多占一批 Token。我以前做个调研型 Agent 时遇到过最头疼的问题就是跑着跑着上下文被工具返回的一堆原始文本塞满模型反而开始“迷路”不知道自己的主任务是什么了。关于这一点有几个实践建议可以直接抄第一工具描述要写得“又短又准”不要把所有参数机制的细节都堆上去。你可以告诉模型“这个工具用来查天气参数填城市名”但没必要把超时重试逻辑写在描述里模型不需要看那些。第二工具返回结果尽量做截断或摘要。如果某个接口返回 200 行日志先把关键部分提取出来再放进上下文。别让模型自己去大海捞针它捞出来的概率很不稳定。第三上下文里信息一多模型对中间部分内容的关注度会明显下降。学术上有个现象叫“lost in the middle”——放在上下文中段的信息最容易丢失。因此关键的指令放在开头结论性的内容放在结尾需要模型精确处理的资料尽量靠前靠后别堆在中间。第一串串完你会发现上下文是内存Token 是计量单位函数调用是手脚。没有手和脚内存再大也只会空谈没有内存手脚动几下就不知道怎么继续了。3. 第二串Agent的知识与记忆系统——RAG、上下文工程与记忆机制3.1 RAG给Agent接上外部知识源RAGRetrieval-Augmented Generation检索增强生成可能是大模型应用里最被人熟悉的技术名词之一。它的核心思想很朴素大模型的知识截止到训练数据为止而且训练阶段不可能把你公司的内部文档、产品手册、客服工单全部装进去。那怎么办先把这些私有知识切成小片、用向量化模型转成向量、存进向量数据库等用户提出问题时把问题也转成向量去检索最相关的知识片段最后再把检索结果拼进模型的上下文里让模型基于这些材料作答。放到 Agent 的语境里RAG 通常不是独立存在而是被封装成一个“知识检索工具”挂在 Agent 上。Agent 收到任务后判断需要哪些资料调用检索工具去知识库捞内容捞完再继续推理。比如一个客服 Agent 接到“客户问退款流程是什么”这个问题它会先去知识库检索退款相关的最新政策然后根据政策原文生成回答。这样既保证了回答基于最新信息也把“胡说八道”的概率压到较低水平。但 RAG 听着简单落地时坑不少。最容易翻车的是切片策略切片太大检索回来的内容包含大量噪声稀释注意力切片太小关键信息被切断模型看到的都是片段拼不出完整答案。另一个关键点是检索后的重排——很多系统只取 TopK 直接丢给模型但如果前十篇里只有两篇真正相关模型很容易被不相关内容带偏。一套成熟的 RAG 管线通常需要持续调 Embedding 模型和重排序策略这一步的性价比甚至比换更大参数的模型都高。3.2 上下文工程有限窗口里排信息的优先级如果说 RAG 解决的是“信息从哪来”那上下文工程Context Engineering解决的则是“这些信息怎么摆给模型看”。这是最近一两年才被频繁提起的概念但它的重要性一点不亚于提示词工程。我常跟自己做比喻给模型一条很长的上下文就像给一个特别忙的项目经理开会前准备材料。你不能把所有原始资料都甩过去而应该按优先级和内在逻辑重新组织成一份既有背景、又有当前问题、又有行动建议的简报。上下文工程干的就是这件事决定哪些内容进上下文、哪些不进以什么顺序放什么时候更新以及如何对历史信息做压缩摘要。实操时通常会这样排优先级系统指令和任务说明最重要放在最前面当前用户目标和任务状态次之工具执行返回的关键结果放在任务所需的对应节点历史对话绝不完整堆砌而是定期压缩成摘要至于大段大段的原始文本只在必要时才以附件形式带入。上下文工程和 Token 管理也是绑在一起的。很多团队一开始会把所有历史消息都保留结果成本直线上升模型反而变迟钝。后来改成“滑动窗口 关键信息摘要”的方案体验立刻好很多。所以如果要做 Agent我建议把“上下文预算”当成一个正式设计环节来对待——先给每次请求定一个 Token 预算然后严格执行超了就得做压缩而不是任它膨胀。3.3 记忆机制短期、长期与工作记忆的分工记忆这个概念在 Agent 里比在普通大模型应用里更复杂。大模型的上下文窗口本身就是一种短期记忆你在这个对话里说的内容它还记得但新开一个会话之后它就什么都忘了。所以真正做 Agent 系统的人一定会考虑给 Agent 搭一套分层记忆第一层叫短期记忆也就是当前正在进行的对话上下文。比如用户说“我要订一份去某城市的机票预算 3000 元”这些信息就存在短期记忆里整个订票流程中模型都要时刻记住。第二层叫长期记忆通常落在外部存储里最常见的是向量数据库加关系型数据库。用户的偏好、项目的历史决策、过去处理过的问题这些信息在任务开始时被检索出来放进上下文用完再存回去。第三层叫工作记忆承载的是当前任务的结构化中间状态。比如一个多步骤研究任务做到一半的进展、已经完成的子任务清单、下一步待办事项。工作记忆的设计好坏直接决定 Agent 是不是一个合格的“打工人”——工作记忆清晰Agent 中断后还能接着干工作记忆混乱Agent 做两步就丢三落四。我见过很多初期 Agent 项目犯同一个错误把长期记忆直接等同于“把所有东西都塞进向量库”然后查询的时候又不知道该检索什么。实际上记忆应该是有结构侧重点的偏好类信息、事实类信息、过程类信息分别放不同的存储检索策略也完全不同。结构比容量重要得多。3.4 三者合流一套可持续运转的知识回路把 RAG、上下文工程和记忆机制放一起看其实是一条完整的知识回路。RAG 是 Agent 和外部知识库的连接通道负责把外部资料拉进来记忆机制是 Agent 自身经验的沉淀负责把历史经验留住而上下文工程是这条回路上最关键的编排器负责决定当前这一轮模型到底能看到哪些信息。我用一个具体例子串起来给你看。假设我们做一个技术文档编写助手它的工作流程是这样用户丢进来一堆素材说明要写一篇上线方案。Agent 先启动从长期记忆中调出团队偏好的文档模板和风格要求再从 RAG 检索到相关系统的架构资料把这些信息交给上下文工程压缩整理组成当前工作记忆模型根据这些材料生成初稿后把初稿关键摘要写回长期记忆同时保留一份工作记忆方便用户后续追问。这个流程跑几轮之后Agent 用得越久越了解团队的写法偏好产出质量也越稳定。设计知识回路时有一条底线不要让任何一环变成瓶颈。RAG 检索慢模型就得干等记忆写回没有做去重脏数据会越来越多上下文压缩做不好模型每轮都感觉像第一次见面。回路里每一环都需要有意识地做质量保障。4. 第三串让Agent“动手干活”的思维框架——CoT、ReAct、Plan-and-Execute与反思4.1 思维链与思维树把思考过程显式化前面聊的都是 Agent 的“硬件设施”接下来这串概念管的是“软件逻辑”——也就是 Agent 的大脑怎么运转。第一个要提的当然是思维链Chain-of-ThoughtCoT。这个方法其实非常朴素你让模型不要直接给答案而是先写出一步步的推理过程。早期研究发现当模型被要求“think step by step”时在数学题、逻辑题上的正确率会明显提升因为显式的推理路径降低了跳步犯错的可能性。这背后的机制可以理解成大模型的隐空间里存了很多推理能力但默认输出时倾向于“走捷径”思维链强制它把捷径拆成一段段可检查的路径每一步都受注意力监督出错的概率自然下降。思维树Tree-of-ThoughtToT是思维链的升级版它不止生成一条推理路径而是同时探索多个候选思路交叉对比后选最优。这种多路径分支的代价是 Token 消耗成倍增加实际应用时通常只在难题上使用。不过要泼一盆冷水思维链并非万能。任务很简单时硬套思维链只会拉长回答、增加成本模型能力本身不够时思维链也无法让它突破上限。因此更合理的做法是把思维链当作可配置项复杂逻辑任务启用简单查询任务关闭动态决定要不要“让子弹飞一会儿”。4.2 ReAct思考与行动交替循环如果说 CoT 是“光思考不行动”那 ReAct 就是在思考和对环境的行动之间来回切换。ReAct 这个名字由 Reason推理和 Act行动拼在一起它的循环模式大致是观察输入 → 推理当前该做什么 → 执行一个动作比如调用工具 → 观察动作结果 → 再次推理如此往复直到完成目标。这个模式特别适合那些需要多步探索的动态任务。举个例子让一个 Agent 去调研某个产品在电商平台上的用户评价它第一步可能先调用搜索工具找到商品列表第二步打开某个商品详情页第三步调出评论区摘要每一步的观察结果都驱动下一步决策。整个行为看起来很像一个实习生在那儿查资料——只是这个实习生反应快一点、同时也会犯糊涂。ReAct 的好处是灵活能应对事先没预料到的情况坏处是执行步数不可控而且上下文会随着循环次数增加不断膨胀。现实中经常出现 Agent 在一件小事上反复调用工具就是不收尾的情况。所以落地 ReAct 时必须设置两个硬约束一是最大循环次数比如 10 步就强制终止二是“显式收尾”条件让模型在自认为目标已达成时必须主动输出结束标记而不是继续探索。4.3 Plan-and-Execute先画路线图再逐步落地和 ReAct 的走一步看一步不同Plan-and-Execute 的思路是先规划后执行。模型拿到任务后先输出一份完整的行动计划列清楚要做哪几件事、按什么顺序、每件事的输出是什么然后系统按这份计划逐步执行每执行一步模型可以选择复核计划是否需要调整但大部分步骤是不需要重新思考的。这种做法带来的最大好处是可控和可审计。计划本身就是一份中间产物你可以让用户看到 Agent 打算怎么干不满意可以中途改执行过程也更容易打日志、做追踪。很多做企业内部工具的人喜欢 Plan-and-Execute因为“让模型先生成一个可检查的方案”比“直接开始自动操作”更符合企业流程的审批习惯。当然 Plan-and-Execute 也有自己的问题如果开头生成的计划就跑偏后面每一步都是错的。好在实践中几乎不会让计划一成不变照做而是加了一个“重规划点”——每完成几个子任务就重新审视剩余计划是否需要调整。这样一来它兼顾了 ReAct 的灵活性和计划模式的可控性算是一种更稳妥的折中。4.4 反思机制Agent自己给自己挑刺反思Reflection / Self-Refine是近一年讨论度很高的概念。它的实现方式通常是让模型先产出一版结果然后用一个额外的提示词或者一个独立的“评审模型”去检查这版结果找出问题再让原模型基于这些反馈重写。这个过程可以跑一轮也可以跑多轮。说通俗点就是让 Agent 干完活后自己再当一遍质检员。反思机制在代码生成和内容创作里效果非常明显。比如一个代码 Agent 生成了代码先让它自己跑一遍测试再把报错信息拿回来修改一个文案 Agent 写完初稿后先让“评审者”角色检查逻辑漏洞和语气是否一致再基于意见修改。这种“先产出、再批评、再修订”的模式往往能显著提升第一版结果的完成度。但反思不是免费的。每一轮反思都要消耗一笔额外的 Token 和延迟而且如果评审 prompt 设计得不好模型可能把原本不错的输出改得越来越平淡。实操中要注意两点给反思设置明确标准比如检查清单式的评价维度而不是笼统说“请检查”给反思设置轮数上限一般 1 到 2 轮足够超过这个极限收益曲线会快速递减。4.5 不同思维框架怎么选一张对比表模式核心思路优点缺点典型场景思维链CoT显式写下推理过程再作答简单、成本低、提升逻辑性不接触外部信息数学题、逻辑分析、方案推理思维树ToT并行探索多条推理路径对难题更稳、可对比选优Token 消耗大高难度规划、多方案权衡ReAct推理与行动交替循环灵活、动态适应环境步数不可控、上下文膨胀多步调研、带工具的探索任务Plan-and-Execute先出计划再逐步执行可控、可审计、适合审批计划错误需要重规划流程清晰的企业任务Reflection输出后自我评审修订提升质量、减少低级错误额外成本、可能过度修改代码生成、文案审核这些模式不是互斥的实际 Agent 系统里经常混用。比如一个复杂任务可以用 Plan-and-Execute 先做顶层规划每个子步骤内部又跑 ReAct 循环结束前再加一轮 Reflection 做质检。模式的选择本质上是针对任务特点做“可预测性和灵活性的权衡”——任务越标准化就越往前两种靠任务越开放就越需要 ReAct 和重规划。5. 第四串从单打独斗到排兵布阵——多智能体、编排与协作模式5.1 多智能体为什么成了必选项单个 Agent 做得再强也有几个天花板。第一个是上下文窗口的限制你不可能让一个 Agent 同时精通十种行业知识、装进几十个工具的完整说明并保持思路清晰第二个是角色冲突让模型同时扮演“严谨的审查者”和“自由的创作者”时两个角色会互相干扰第三个是故障隔离一个全功能 Agent 出问题整个任务就瘫了。多智能体架构的出发点正是把这些问题拆开。多智能体的思路有点像一个项目组一个项目经理负责拆任务、分配任务、汇总结果底下几个成员分别负责自己最擅长的领域——有人管检索有人管分析有人管写报告各司其职互不干扰。每个子 Agent 的上下文较短、工具域较窄、提示词更聚焦单个质量反而更容易做高。这种拆分的另一个好处是可以并行——几个子任务同时跑整体延迟并不可怕。当然天下没有免费的午餐。多智能体带来了新的问题消息怎么在 Agent 之间传递谁来仲裁不同 Agent 给出的冲突结论多个 Agent 各自消耗的 Token 怎么控制调试的时候一个问题出在两个 Agent 的交互上定位起来比单 Agent 麻烦得多。所以我的个人建议是单 Agent 能解决的绝不强行上多智能体只有当一个 Agent 的上下文和职责确实塞不下或者任务天然有分离的职责边界时才考虑拆分。5.2 常见协作模式与适用场景多智能体的组织方式目前主要有四种可落地的模式主管-下属模式一个主 Agent 负责接收任务、拆分子任务、分派给下属 Agent再收集结果统一汇总。适合任务可以明显拆成多个独立模块的场景比如调研报告、产品方案生成。流水线模式每个 Agent 只负责一个固定环节A 的输出直接作为 B 的输入。适合流程相对固定的场景比如“数据清洗 → 数据分析 → 摘要生成 → 报告格式化”中间不需要太多来回讨论。辩论/评审模式让多个 Agent 分别独立产出观点再由一个仲裁 Agent 综合评判。适合对质量要求高、需要尽量排除偏差的任务比如代码走查、方案设计评审。缺点是多轮交互的成本很高。自由协作模式没有固定结构Agent 之间按需通信通过一个消息中心协调。最灵活也最难控制当前生产环境里用得较少多数还停留在实验阶段。模式控制难度成本适用场景主管-下属中中任务可变、模块可拆流水线低低流程固定、步骤明确辩论/评审高高追求质量、接受延迟自由协作很高高探索性场景不推荐选哪种模式核心看两件事一是任务本身的确定性二是你对结果可控性的要求。确定性越高越适合流水线和计划模式确定性越低越需要主管-下属这种能动态调整的编排。5.3 人在回路保留人类审批的边界讲多智能体讲的都是“自动化”但真正成熟的 Agent 系统一定会强调人在回路Human-in-the-loop。原因很简单大模型的输出天然带有不确定性而且有些操作一旦执行就不可逆。发一封邮件、提交一笔订单、删除一段生产数据、向用户承诺一个方案这些操作如果全自动执行出了事故谁来背锅所以我见过的实践中普遍采用分级处理纯内部信息处理类操作比如查文档、生成草稿、整理数据让 Agent 全自动干外部可见或者有副作用的高风险操作比如对外发送、写数据库、购买下单则强制加入人工确认环节——Agent 把草稿准备好人工点一下确认系统才真正执行。这相当于给 Agent 加了一道“人类闸门”。有些读者可能觉得这样不够“智能”但从工程稳定性角度看人是整条链路里最便宜也最有效的安全防线。算力成本再低也比不上一次误操作带来的业务损失。尤其是客户服务、金融、医疗这类行业人工审批不仅是指标问题很多时候是合规要求。所以做 Agent 设计的时候务必提前定好哪些环节要人工介入在这个问题上宁严勿松。5.4 可观测性Agent系统最难补的一课传统软件项目的可观测性很成熟打日志、抓异常、查监控就行。但 Agent 系统天生难调试——因为模型输出有随机性同一输入跑两次结果可能不同因为决策链很长一个错误可能源于 20 步之前某次工具的返回内容因为没有“代码栈”你很难定位到具体哪一行逻辑出了问题。这也是为什么可观测性需要从第一天就设计进去。我强烈建议由 Agent 系统从最开始就记录这样几类数据每一步输入和输出的完整内容、模型调用的 Token 消耗和耗时、工具调用次数与返回结果摘要、每次任务最终是否达成目标。有条件的团队可以把这些日志汇总成可回放的任务轨迹——出问题时把整条轨迹回放一遍基本能在几分钟内定位问题发生在哪一跳。另一个常被忽视的点是成本观测。多智能体系统跑一轮任务可能消耗非常高不做 Token 账单审计月底你会发现成本超支但根本说不清钱花在了哪个环节。给每个环节打上成本标签按任务维度汇总是 Agent 上生产的必修课。可观测性和评估我会在下一节继续展开。6. 概念串完了动手之前先想清楚这几件事6.1 什么时候真需要Agent什么时候是凑热闹概念了解得再多回到实际开发时第一件事永远是这个需求到底用不用得上 Agent我的判断标准很简单——画一遍传统实现的流程如果规则分支太多、组合空间太大而且后续需求肯定经常变Agent 就有价值如果任务步骤固定、输出结构确定、延迟要求高那老老实实写代码调用大模型接口就够了完全不必要上 Agent。换句话说Agent 适合的是“路径不确定的开放任务”不适合的是“路径确定的重复任务”。硬拿 Agent 做规则引擎能做的事情结果往往是成本更高、延迟更大、还出现不稳定的随机行为。有一阵子大家都喜欢在项目里加 Agent 撑场面但冷静下来很多功能用几个条件判断加一次模型调用就能干完加 Agent 纯粹是给自己添堵。给一个更实操的判断方法你把用户需求完整写下来想象用一个固定代码实现的话需要多少个 if-else 分支。如果分支数量就三五个别用 Agent如果一旦需求变化这些分支就要大改那 Agent 的动态规划能力才有真正发挥空间。6.2 概念落地的推荐路径从稳定小闭环开始就算确定要用 Agent我也建议别一次把所有概念全上。我见过不少团队第一次做 Agent 就想搞多智能体加记忆加 RAG 全家桶结果连主链路都没有调通就被各种变量搅晕项目直接烂尾。比较好的路径是这样第一步先用一个单 Agent 加一到两个必需工具跑通最核心的一条用户链路。此时不搞复杂记忆不做多智能体甚至不加反思。目标是让 Agent 在主路径上稳定完成任务准确率达到可接受水平。第二步引入上下文工程和基础记忆。把历史对话压缩成摘要把用户偏好存起来在任务开始时自动带入相关背景。这一步优化的是可持续使用的体验成本相对可控。第三步按需加入 RAG 和反思。如果说第二步是“让它记得”这一步是“让它知道更多”和“让结果更可靠”。RAG 的切片与检索质量要花专门的精力调试反思的评审标准也要单独打磨。最后才考虑多智能体拆分。而且拆分的理由必须是“当前 Agent 确实忙不过来”而不是“听起来比较先进”。每一步叠加时都要保持上一个功能稳定不退回否则几层复杂度叠在一起问题定位的难度会呈指数级上升。6.3 一件被低估的事评估与回归最后聊一个很多人直到上线出 bug 才会后悔的事评估。传统代码写得好不好可以靠单元测试和代码评审Agent 没有这么直接的验证手段。模型输出是概率性的同一条输入可能给出不同的答案你怎么知道这一版比上一版好怎么判断一次改动究竟是提升了整体效果还是导致某些场景退化务实的做法是从项目第一天就维护一个固定的评估集。挑 20 到 50 个典型用户请求覆盖主流程和边界情况每个版本发布前都用同一批请求跑一遍记录每项任务是否达成目标、工具调用是否正确、回答是否跑偏。因为输出有随机性单次跑不够同一个 case 至少要跑 2 到 3 次看稳定性。评估集一开始不需要大但要随着功能迭代持续补充尤其是把线上用户真实反馈过的坏案例加进去——这相当于给 Agent 做“单元测试”只是它的断言要从“输出某个值”变成“达成某个目标”。另一个值得强调的是中间步骤评估。很多团队只看最终回答对错但 Agent 是一个过程敏感的系统——即便最终结果碰巧正确中间的规划乱套、工具乱调也一样是隐藏风险。我见过一个 Agent 明明最终答案对了但中间为了拿到这个答案绕了五遍弯路多花了三倍 Token。把每个中间步骤是否合理也纳入评估才能真正控制成本和稳定性。串了这么一圈概念我自己最大的体会是AI Agent 的术语虽多但每个概念都在回答一个非常具体的问题。上下文解决“它能看到什么”函数调用解决“它能做什么”RAG 解决“它知道什么”记忆解决“它记得什么”思维框架解决“它怎么想”多智能体解决“一个人忙不过来怎么办”。把这些问题挨个问一遍你自然就知道自己的项目卡在哪里了。我最初做概念验证那会儿总想一步到位把所有概念都用上结果系统又贵又难查问题。后来收敛到先用最简单的单 Agent 加工具闭环把主链路跑稳再一点点往里加记忆、加检索、加评审反而顺利得多。这套概念串烧帮你把盘里的菜挨个认清楚了至于先吃哪一道那得由你手头的任务来决定。