最近跟几个做后端的朋友聊 AI 落地，我发现大家聊到 AI Agent 的时候经常会各说各话：有人觉得能读写文件的就是 Agent，有人坚持要一口气跑完整个任务才算 Agent，还有人觉得不搭个编排框架就不配叫 Agent。我理解这种分歧，这个领域变化太快，很多词还没凝固，每个人切入的场景不一样，理解自然不一样。所以这篇文章想做一件事：把围绕 AI Agent 的一堆概念串起来，理清它们之间的边界、连接点和实际落地时的取舍。
这锅概念串烧里我打算串这几样东西：Agent 的定义和它跟 Chatbot、Copilot、Workflow 的区别，记忆是怎么做的，规划是怎么落地的，工具调用为什么是 Agent 的"手脚"，多智能体到底解决什么问题，以及 RAG 和 Agent 的关系。最后给一套我踩过坑之后总结出来的落地检查方法。内容不会太学院派，更多是站在工程实践的角度去拆这些概念。
1. Agent 到底是什么：不同人语境里的不同东西
1.1 从"问答机器"到"目标执行体"的关键跨越
先说最基础的问题。一个东西要被称为 Agent，我觉得至少要满足一条：它不是在回答问题，而是在达成目标。
普通的大模型对话机器人是"你给我问题，我给你回答"，它是静态的、被动的。你问一句它答一句，问得不好它就乱答，它不会主动去查证、去尝试、去修正。而 Agent 不太一样，它的核心是一个循环：感知环境、基于目标做决策、调用资源行动、观察行动结果、再修正下一步。这个循环一旦成立，它就不再是一个"会说话的模型"，而是一个"会做事的系统"。
为了方便理解，我经常打这个比方：聊天机器人是一个坐在工位上只动嘴的专家，你问他什么都给你头头是道地讲，但你让他把桌子收拾了他是不会动的。Agent 是那种接了任务会自己查工具清单、拆步骤、干完还回头检查一遍的新员工。差别不在"知不知道答案"，而在"有没有闭环的执行链路"。
所以当你评估一个方案是不是 Agent 时，不要看它用了多大参数量的模型，要看系统里有没有这么一条"目标 -> 行动 -> 反馈 -> 调整"的环路。
1.2 Chatbot、Copilot、Agent、Workflow：四兄弟容易认错
这四种东西在实际产品里经常被混着叫，原因是它们都会"用大模型"，而且很多产品是混合形态。但我觉得它们的分工其实可以切得很清楚。
我用一张表来对比它们的核心差异：
| 类型 | 核心交互 | 是否闭环 | 决策点在哪 | 典型场景 |
|---|---|---|---|---|
| Chatbot | 问答 | 否 | 没有决策 | 客服、知识问答 |
| Copilot | 辅助用户在流程里做事 | 半闭环，人在环路 | 用户拍板 | 写代码、写文档 |
| Agent | 自主执行目标 | 闭环 | 模型根据情况临场决策 | 数据分析、运维处置 |
| Workflow | 走预定义好的处理链路 | 闭环但路径固定 | 路径写死在前端 | 单据审批、定时清洗 |
最容易混淆的是 Agent 和 Workflow。很多人觉得"只要流程里有模型参与就算 Agent"，其实不对。我自己的判断标准很朴素：把任务中间步骤的正确答案隐掉，看系统还能不能找到替代路径。如果它只会按写死的规则一步步往下走，那就是 Workflow；如果它能根据中间结果改变策略、换一种办法，那才算沾上 Agent 的边。
还有一点要提醒：这四个不互斥。实际系统里经常是外层用 Workflow 做流程骨架，遇到需要临时判断的节点才把 Agent 能力嵌进去。认清概念是为了更好地组装，不是非要分个孰优孰劣。
2. 记忆：Agent 的草稿纸和硬盘
2.1 短期记忆等于上下文窗口，但窗口不是越大越好
Agent 的记忆问题，本质上就是"信息放哪里、放多久"。短期记忆对应的是模型的上下文窗口，也就是一次调用里能塞进去的所有对话历史和参考材料。窗口越大，单次能"记住"的东西越多，这是直觉。
但我实际用下来的结论是：窗口不是越大越好。首先是成本问题，token 是按量计的，长上下文会让每次调用的开销直线上升。其次是更反直觉的一点——模型在很长的上下文里并不会对每条信息保持同等注意力，塞进去大量无关材料之后，关键信息反而容易被淹没。我曾经做过对比实验，在上下文里混入大量相关性低的文档，模型回答错误率明显高于只给精炼摘要的情况。
所以正确做法是控制"工作台面积"：上下文里只放当前这一步真正需要的临场信息，其余的全部放到外部存储去。
2.2 长期记忆怎么做：总结压缩与向量检索的组合拳
长期记忆的实现，工程上已经有一套比较成熟的路子，我把它拆成三个动作。
第一步，把历史信息做切片和向量化。对话记录、文档、知识条目都要切成适当长度的 chunk，转成向量存进向量数据库。第二步，当 Agent 需要回溯信息时，把当前问题也向量化，做相似度检索，取回 Top-K 个相关切片，拼进上下文。第三步最关键也最容易被忽略：定期对旧对话做总结压缩，把耗时很长的历史记录提炼成"结论清单"而不是保留原文全文。
这个流程可以用一段很朴素的伪代码表达：
question_vec = embed(user_question) candidates = vector_store.search(question_vec, top_k=5) context = [] for chunk in candidates: context.append(chunk) # 相关切片放回上下文 if conversation_age > threshold: summary = llm.summarize(old_conversation) memory_store.save(summary) # 旧对话降级为总结这么做的好处是：相关细节在需要时能被精确捞回，不需要时不会占着上下文；旧信息不会无限膨胀，成本可控。代价是引入了一个新的薄弱点——检索质量直接决定 Agent 的"记忆力"，如果向量检索召回不准，Agent 就会表现得像失忆。
2.3 记忆管理的三个坑：过期、漂移、污染
围绕记忆我踩过的坑不少，挑三个最常见的说。
过期是指捡回旧数据当新鲜事用。比如数据库里的价格昨天调了，但记忆里还存着旧价格，Agent 按旧信息做判断，结果自然是错的。处理办法是给每份记忆打时间戳，写入时记录时间，检索时过滤过期数据，或者让 Agent 对时效敏感的信息一律现查现用。
漂移是指同一个对象在不同语境下说法不一样，导致检索不到。比如用户第一次说"华东区"、第二次说"东区"，如果向量空间里这俩表示距离较远，Agent 就串不起来。缓解办法是建立别名表和实体归一化管道，在写入记忆之前先把实体归一化。
污染是最隐蔽的坑：上一次任务产生的错误结论被当成事实存进长期记忆，下次检索时被捞出来当真理用。这个问题我吃亏最深，一开始我以为记忆越多越好，结果系统经常拿错结论当依据。后来我在写入环节加了一道审核，只有被确认过的信息才允许进长期记忆，检索端再标注"疑似过期/低置信"提示，明显改善。
这三个坑说明一个问题：记忆不是"存就完事"，它是一个需要生命周期管理的模块，写入、读取、更新、淘汰都要有规则。
3. 规划：Agent 的"项目管理"能力怎么落地
3.1 ReAct：交替推理与行动的经典循环
光有记忆还不够，Agent 得有目标拆解和执行规划的能力。业界最经典、也最容易理解的范式是 ReAct，就是推理和行动交替进行：模型先想一步"我现在缺什么信息、下一步该干什么"，然后执行一个动作，拿到结果之后再看一眼"结果符不符合预期"，符合就继续，不符合就调整策略。
我在工程里给它写过一个很直接的提示词模板，大概长这样：
任务：<目标> 请反复执行以下过程直到任务完成： 思考：当前处于哪一步，还缺什么关键信息； 行动：调用某个工具去获取该信息或执行某操作； 观察：工具返回了什么结果，结果是否合理； 如果结果不合理，请换一种方式重新尝试； 最终给出结论与依据。ReAct 最大的优点是抗意外。真实任务里，外部接口不一定按预期返回，中间步骤会失败，ReAct 这种"走一步看一步"的节奏让 Agent 能根据实际观察不断纠偏。缺点也明显：如果任务路径非常长，它可能沉迷于局部调整，忘了整体目标，所以需要设置总步数上限。
3.2 从单步规划到分支计划：Plan-and-Execute 的取舍
比 ReAct 更高一层的是 Plan-and-Execute：先让模型一次性把大任务拆成一份步骤清单，然后逐个执行，每完成一步校验一次，必要时重新规划。
这两种范式我都在项目里试过，感受是它们解决的是不同类型的问题。Plan-and-Execute 的好处是全局可见、可控、好追溯，适合那些过程可以被预先设计清楚的任务，比如"每周一拉取报表、清洗数据、生成摘要、发送邮件"，每个环节边界清晰，先做计划再跑就很舒服。
但它的弱点是弹性不足。一旦实际执行中出现计划外的情况，比如数据源变了、某个接口挂了、中间冒出来一个分支，原来预定的计划就得作废重新生成。这时候 ReAct 反而更自然。我自己总结的取舍逻辑是：看中途可能需要拐弯的次数。路线明确就 Plan-and-Execute，路线随时可能变的就用 ReAct，复杂系统里两者也可以嵌套。
3.3 任务分解的本质：把模糊需求拆成可执行步骤
不管是哪种范式，底层都要会做任务分解。我发现很多人一上来就指望模型自己把需求拆得明明白白，这是理想状态，但实际工程里需要你在系统层面给一些约束。
任务分解的本质是把一个模糊的大目标，变成一组有前后依赖、可验证的小目标。我常用的分解维度是这样的：先提炼显性和隐性的目标词，再拆可验证的子目标，每个子目标要写清完成标准和期望产出物，最后标出依赖顺序并马上发现缺失的信息。举个例子，"分析上周销售数据并生成汇报"这件事，好的拆解会产生这种序列：导出数据源 -> 清洗缺失值 -> 计算关键指标 -> 生成结论 -> 制作图表。步骤之间存在明确依赖，每一步又能独立验收。
这里我想强调一个判断原则，也是我常跟人讲的：如果你把任务拆完之后发现步骤顺序完全固定、没有变化空间，那这个任务本来就不需要 Agent，写 Workflow 更便宜也更稳妥。任务分解的价值正是在于筛选——那些拆完之后依然需要临场判断的步骤，才是 Agent 真正发挥作用的地方。
4. 工具调用：Agent 的手和脚
4.1 Function Calling 是怎么让模型触达外部系统的
记忆和规划给了 Agent"脑子"，但真正让它能改变外部世界的是工具调用。现在主流商用模型基本都支持功能调用，模型在合适的时机输出一个结构化的调用指令，系统接收到之后去执行真实的函数，再把返回值喂回模型。
一个典型的功能调用指令长这样：
{ "function_call": { "name": "get_weather", "arguments": { "city": "某市", "date": "2025-01-15" } } }这个机制的关键在于：模型不是自己编答案，而是学会"在不确定时就申请调用外部函数"。它把"我的知识库没有这个数据"和"我可以去查"这两件事解绑了。我接触过的很多项目里，Agent 能不能做出真事，往往就取决于是不是接上了正确的工具集。
4.2 工具调用的编排：让 Agent 学会在正确的时机开口
工具接口写好了不代表模型会合理使用。我见过很多失败案例是工具清单全部丢给模型，结果模型频繁调错工具或者反复尝试同一个失败动作。
合理的做法需要做这几件事。一，工具清单要控制粒度，一次暴露十几个工具不如只暴露当前阶段最相关的几个，让模型的选择范围小一点。二，每个工具的描述要写成"何时该用、何时不该用"，模型对工具触发条件的理解基本来自描述文本，描述写得越像菜谱，调用越准，反而把它写成标准 API 文档会让模型犹豫。三，要预设失败重试策略：调用失败之后是重试一次、换备选工具、还是直接转给人工，必须提前定好，不然 Agent 会卡在同一个失败动作上死循环。四，权限分级，低风险的查询类工具放开自动执行，写库、发消息、删数据这类高影响操作必须人工确认。
我自己的一个体会是：工具描述里加上"不要用于处理……"的负例说明，比只写"可以用于……"更能减少模型乱用工具的次数。
4.3 为什么工具比提示词更能约束 Agent
再分享一个我后来才想明白的事情：想约束 Agent 的行为，工具设计比提示词更可靠。
提示词是"口头约束"，它请求模型"尽量"不要做某事，但模型有时还是会越界。但如果你把接口设计成"只允许查询这份文档"，那 Agent 在能力层面就不可能去查别的东西。与其反复强调"仅限于数据库 A"，不如只给它一个只能访问数据库 A 的工具。"能力边界"永远比"嘴上边界"硬。
这个原则也解决了之前记忆里的一个大问题：Agent 的上下文是通用的，但工具集是可以按任务隔离的。做数据分析的 Agent 不需要集成下单工具，做内容生成的 Agent 不需要能调用财务查询接口。工具即权限，这是 Agent 工程里相当实用的一条设计准则。
5. 多智能体：从单打独斗到团队作战
5.1 多智能体解决的是单体的"能力偏科"问题
当任务变复杂之后，你会遇到一个现实瓶颈：单个 Agent 什么都要会，工具集越塞越多，知识上下文越装越杂，最后容易互相干扰。就像一个既当分析师又当程序员还兼项目经理的人，真到高压任务里反而样样都做不精。
多智能体就是针对这个问题来的：把一个大而全的 Agent 拆成多个专业分工的小 Agent，每个只负责一个环节，工具集和知识上下文按角色隔离。负责检索的 Agent 只需要专注于数据源，负责执行的 Agent 只需要专注于操作步骤，负责质控的 Agent 只需要专注于检查产出。这种隔离让每个环节的上下文更干净，行为也更容易预测。
5.2 常见的协作模式：主管分配、同伴协作、辩论对抗
多智能体并不是简单地把几个 Agent 扔在一起，它们之间的协作方式直接决定成败。常见的模式有三种。
第一种是主管-员工模式，一个主控 Agent 拆解任务，把子任务派发给不同角色 Agent，收回结果后做汇总。这种模式适合任务层次分明、可以切分成独立模块的场景。
第二种是同伴协作模式，多个 Agent 共享一块"黑板"，也就是一块公共消息区，各自在上面认领自己能做的那部分，互相补充。这种模式适合步骤上高度耦合、信息需要频繁交换的任务。
第三种是辩论对抗模式，多个 Agent 对同一个问题各自独立给出判断和依据，然后互相质疑、自我辩护，最后要么投票要么交给一个裁决者。这种模式在事实核查、方案评审类场景很好用，能把明显的错误过滤掉。
一条消息在各 Agent 之间传递的格式可以参考下面这样，关键是消息里必须带发送方角色和期望接收方，不然群体协作很快就会变成信息混乱。
{ "from": "search_agent", "to": "analysis_agent", "task": "查上市公司的行业排名", "status": "done", "summary": "已返回前三名及其关键指标", "attachment_ids": ["doc_001", "doc_002"] }5.3 编排多智能体时最容易翻车的点
协作模式看着很爽，落地时坑更多。第一个坑是成本爆炸：几个 Agent 之间来回传话，每传一次就要调一次模型，对话轮数一多，token 消耗立刻翻倍。我有个项目把三个 Agent 接上线之后，成本比单体高了一倍还多，后来靠压缩消息体和限制对话轮数才压住。
第二个坑是死循环式争论：两个 Agent 对一个分歧点各执一词，没有终止条件，就会在同一句话上重复讨论。这种情况必须强制设定最大轮数和超时时间，到点就交给裁决者或人工拍板。
第三个坑是责任边界模糊：系统出了错，很难定位是哪个子 Agent 的问题，因为结果经过了多层加工。所以从一开始就要给每条中间消息打标记、写链路追踪，不然线上排查会让人崩溃。
说句实在话，大多数真实业务场景里，两三个 Agent 就足够了。先定义清楚每个角色要什么、产出什么、和谁交互，再考虑加人，别为了架构好听硬堆数量。
6. RAG 与 Agent：查资料的人和做决定的人
6.1 RAG 解决幻觉的边界在哪里
RAG 是检索增强生成，简单说就是：先在外面检索资料，把资料作为参考塞给模型，再让模型基于这些资料回答。它最大价值是显著压低事实性错误——模型不再"凭空想"，而是在给定资料范围内组织答案，这是目前对付幻觉性价比最高的手段之一。
但它有边界。RAG 本身并不负责判断"该不该查资料、该查哪些资料、查到的够不够"。这些决策仍然依赖模型和背后的编排逻辑。传统 RAG 管线做得比较死：收到问题就用同样的方式检索 Top-K，然后把结果一拼，生成回答。问题变了、资料库变了，这个固定管线不会随之调整。
6.2 Agent 化之后的检索：从一次回答到多轮求证
把 RAG 嵌进 Agent 之后，检索行为会发生质的变化。传统 RAG 是"一次检索 -> 一次生成"，Agent 化之后的检索变成"按需检索、多轮求证、边查边判"。
一个典型的 Agent 化 RAG 流程是：用户提问之后，Agent 先判断自己是否了解这个领域，不确定就选择合适的数据源去查；如果检索结果里信息互相矛盾，它会发起第二次检索做交叉验证；如果结果不足以支撑回答，它会重新表述查询条件再试一次；最后给出回答时，它能告诉你哪些结论来自哪份资料。
这个过程的价值在于，检索不再是固定动作，而是 Agent 的可调用能力之一。Agent 可以根据对回答置信度的判断，决定要不要继续查。真实业务里，"资料够不够"本来就是个动态判断，这正好是 Agent 的强项。
6.3 什么时候该上 RAG，什么时候该上 Agent
很多人分不清这两个，其实它们不是一个维度上的东西。RAG 是一种信息增强手段，Agent 是一种任务执行范式，两者可以组合也可以分开。
我给了自己一个选型判断表，分享出来供参考：
| 业务特征 | 推荐方案 |
|---|---|
| 问题类型固定、参考资料基本静态 | 传统 RAG 管线 |
| 需要跨多个数据源、多轮验证才能回答 | Agent + RAG |
| 任务不仅要回答，还要修改系统状态、执行操作 | Agent + 工具调用 |
| 只是想让模型回答更准确、减少幻觉 | 先上 RAG，不必上 Agent |
我也见过不少项目在这个环节上头，上来就要做全套 Agent，结果成本翻了几倍，问题却用简单 RAG 就能解决。我的建议是：先做最小方案跑通，指标证明不够再升级，升级之前想清楚"现在缺的是检索质量，还是决策能力"。
7. 串烧之后的落地检查：评测、坑点与最小启动
7.1 Agent 评测的三个维度：成功率、成本、稳定性
串了这么多概念，最后回到落地的问题：一个 Agent 系统做得行不行，凭什么是行。我的评估框架就三个维度。
成功率最容易理解：同一个任务重复跑 20 次，统计有多少次真正完成了目标，而不是只完成了"看起来像完成"。这里要特别注意，Agent 经常会在最后一步输出一个听起来合理的结论，但实操并没有真正发生——所以评测必须校验结果状态，而不仅是看回答文本。
成本是 Agent 项目最容易失控的维度。一次复杂的 Agent 任务可能会在内部调用几十次模型，token 开销比普通问答多一个量级。评测阶段如果不对每次任务的总 token 做统计，上线之后很容易被账单吓到。我自己会额外加一个指标：平均每次任务调用模型多少次。这个数字一旦超过预期，就要回头查是不是在无效循环或反复重试。
稳定性则是对极端情况的耐受能力：外部接口超时、返回格式异常、用户输入特别简短或特别长，Agent 会不会因此滚雪球失败。对生产系统来说，稳定性的重要性往往高于单次成功率。
7.2 反复踩到的坑：死循环、成本失控、幻觉放大
这里集中讲我反复踩过的三个坑，每一回都让我长记性。
死循环是最常见的翻车点。Agent 在某个工具调用上反复失败，然后不停以近乎一样的姿势重试，看起来"很努力"，实则消耗了大量时间和 token。解决办法是两层保险：一是设置最大步数上限，到数强制结束；二是动作去重，连续 N 次相同的失败尝试直接跳转人工或换工具。
成本失控是第二个坑。一次复杂的 Agent 任务可能调用几十次模型，因为任务执行过程中每一步都可能触发新的推理循环。上线前必须设单任务 token 上限和每日总预算，没有上限的 Agent 系统在异常流量下能把预算吃穿。
幻觉放大是最隐蔽也最危险的坑。单次问答里模型的幻觉可能只是答错一句话，但如果 Agent 带着错误认知去做工具调用，比如把错误金额写进数据库，这个幻觉就被"放大"成了真实操作事故。所以我坚持高风险动作必须有人工审批接口，模型负责建议，关键指令必须人来确认。这不算退步，这是 Agent 能长期稳定运行的前提。
7.3 一个最小可行的 Agent 长什么样
如果你现在要启动一个 Agent 项目，我给的最小闭环清单是这样的：一个定义明确的目标，一个到两个工具，一个明确的截止条件，一个结果校验环节，以及一份完整的运行日志。
我拿"自动提取合同关键字段并入库"举例：目标是从 PDF 合同里提取金额、甲方、日期；工具只需要一个文档解析工具和一个写入数据库的工具；截止条件是成功写入或者解析失败超过三次；校验环节由一个质检 Agent 负责，把提取结果和原文做比对，差异过大就标记；整个处理过程全部记录日志，方便追查哪一步出错。这样一个系统，复杂度不高，每一步都能被验证，已经能满足一类真实的业务需求。
下一层再逐步加能力：需要跨文档总结时就接长期记忆，需要多轮复杂操作时就调整规划范式，需要多人写作或交叉验证时再考虑多智能体。顺序上我强烈建议从最小闭环起步，缺什么补什么，不要一上来就把概念全上齐。
最后再多说一句我自己的体会：概念串烧的意义不在于把名词背熟，而在于知道它们在系统里各自承担什么职责。下次你跟人聊 Agent，可以先问一句"你的系统决策点在哪里"。搞清楚这句话，聊 Agent 基本就能聊到一块去了。
深度解析：从TD(0)到GAE的强化学习核心)