很多搞大模型应用的朋友都遇到过这种情况：用单个Prompt写出来的所谓Agent，其实就是一个套了壳的ChatGPT问答工具，跑几个固定流程还行，一遇到稍微复杂点、需要多步决策的任务，就彻底乱套。真正能扛事儿的Agent，它的内核并不是“会聊天”，而是一整套围绕目标拆解、工具调度、记忆管理和自我纠错运转的决策引擎。这篇教程第二篇，我想把AI Agent的核心原理和主流架构彻底拆开揉碎讲清楚，包括LLM是怎么一步步“想清楚”再“动起来”的，编排层为什么会成为系统里的承重墙，还有工程落地时那些文档里不写、但你必须知道的隐患和坑。
先回答一个很多人问过我的问题：Agent和普通的“LLM+API”到底差在哪？你可以把普通的大模型应用理解成一个“实习生”，你交代一句，他做一步；做得对不对，你得自己盯着。而Agent不一样，它是那种你把目标丢过去，它会自己拆任务、排队执行、发现出错还会自己重新规划路径的“老油条”。为了实现这种自主性，Agent的核心运行逻辑依赖一个非常重要的模式——ReAct（Reason + Act），也就是“先推理，再行动，观察结果，再循环”。你可以在日常开发中把它看作一个“思考-行动-观察”的死循环，模型每一步输出都包括思维轨迹（Thought）、行动指令（Action）和观察结果（Observation），直到最终得到答案。
这套东西听起来不复杂，但落到工程上，难点从Prompt层面瞬间转移到了架构和组织层面。上下文窗口是有限的，工具调用是不可靠的，多Agent之间通信是容易失控的。所以这一篇我不只想讲清楚原理，更想结合我自己在实际项目里踩过的坑，和你聊聊不同Agent架构的取舍、模型的选型依据、调度策略的设计，以及如何让你的Agent真正具备“干活儿”的能力，而不是在演示视频里好看。篇幅会比较长，纯干货，建议有时间的话读完，没时间的话建议先收藏。
1. 深入拆解Agent的基本运行逻辑与核心前提
1.1 从“回答问题”到“完成任务”：Agent的本质转变
在开始聊架构之前，我觉得有必要先把Agent的运行逻辑对齐了。很多人对Agent的认知停留在“调用大模型API，然后解析返回的JSON，再调用下一个函数”，但这个理解太浅了。Agent的本质是：一个能够感知环境、做出决策、执行行动，并根据反馈修正后续策略的自主系统。它不再是“一锤子买卖”式的问答，而是多轮决策的闭环。
我用一个生活化的类比来帮你理解。假设你让一个普通聊天机器人帮你“订一张去北京的火车票”。它的表现大概是：先告诉你需要提供身份证号、出发日期，然后给你12306的链接，让你自己去买。最后你还要自己跳转到别的系统操作。这对用户来说，它并没有“完成任务”，只是在“回答问题”。
但Agent的思维模式完全不是这样的。一个成熟的Agent收到“订火车票”这个目标之后，它会启动内部的多步推理：
- 确认当前时间和出发日期；
- 查询可用的车次和余票；
- 对比不同车次的票价和时刻；
- 根据用户的偏好（比如“不坐夜车”）筛选；
- 调用支付接口完成下单；
- 最后把订单信息反馈给你。
你看，这里面的每一步都是“决策+行动+反馈”的循环。模型需要在一开始就把这个复杂目标拆分成若干子目标，然后逐个击破。这种能力，不光是靠聊天提示词就能实现的，它要求系统在架构层面就支持多轮状态管理、任务编排和工具调用链。所以我在做项目时判断一个Agent写得好不好，从来不看它聊天多流畅，只看它能不能自主闭环完成一个多步骤任务。
1.2 “思考-行动-观察”的循环：ReAct模式到底在React什么
这里我想再深入展开一下ReAct模式，因为这是整个Agent动力的核心源头，也是理解后面所有架构设计的基础。ReAct模式最早由Google Research和普林斯顿大学在2022年提出，它的初衷是解决大模型在复杂任务中“只动嘴不动手”的问题。它的核心结构是一个循环，每个循环包含三个关键组件：
- Thought（思维轨迹）：模型用自然语言描述对当前局势的理解，比如“我需要先查询天气，才能决定是否推荐户外活动”。
- Action（行动）：模型根据思维轨迹，从预先定义的工具列表中选择一个工具调用。比如“查询天气工具，参数：城市=北京”。
- Observation（观察结果）：系统执行工具后把结果返回给模型，模型看到结果后修正自己的判断，进入下一个循环。
我用一个代码片段来直观展示这个循环在底层长什么样：
Thought: 用户想知道北京明天的天气，这需要调用天气查询工具。 Action: call_weather_api(city="北京", date="2026-02-12") Observation: {"status": "success", "data": {"temp": "-2~5", "condition": "晴", "wind": "西北风3级"}} Thought: 拿到了天气信息，接下来我可以把结果整理成回复用户。 Action: reply_to_user("北京明天晴，气温-2~5度，注意保暖。")这个循环最大的好处在于：它将推理过程变成了可观测、可干预的中间产物。你不必让模型一次性输出最终结果，而是在每一步都能介入、验证、纠正。如果你在调试时发现Agent卡住了，你可以直接查看最后几步的Thought输出，就能定位问题出在“推理错了”还是“工具返回格式不对”。
在我的实际项目里，我会把这种“三步循环”再升级一层，加上“计划修正”的环节。具体做法是：在每执行三步Action之后，强制模型重新审视一遍原始目标，看看“我现在做的事情，是否还在推进主线任务”。这一步看起来简单，却能大幅度提升Agent在长链路任务中的成功率，因为模型在复杂的多步推理中很容易“跑偏”。
1.3 Agent能跑起来的四大前置条件
聊完运行逻辑，再说说让Agent真正跑起来需要哪些前置条件。很多初学者把“能调用工具”当成Agent的全部，结果做出来的东西极其脆弱。根据我踩过的坑，一个能稳定运行的Agent前置条件至少包括四个：
第一是系统提示词（System Prompt）的结构化设计。这玩意儿的质量基本决定了Agent的智商上限。我一般会要求系统Prompt包含：角色定义、任务边界、可用工具清单及使用场景、回复格式规范、危险操作防护规则。尤其是防护规则，这点很多团队都不重视，结果闹出过Agent拿着测试库的连接串跑生产库的笑话。
第二是模型的能力下限。Agent对底层模型的要求比单纯对话要高得多，它需要模型具备：遵循指令的能力、多步推理能力、识别工具调用意图的能力、从错误中恢复的能力。我实测下来，开源模型里至少要7B以上参数才能勉强完成工具调度，想要稳定运行多步复杂任务，13B到70B之间才靠谱，闭源模型效果则明显好一截。
第三是工具层的抽象稳定。Agent要调用的所有工具都必须做统一的接口封装。你不能让Agent直接面对“一个函数返回JSON数组，另一个函数返回XML”这种混乱情况，它会疯掉的。我通常会把所有工具统一成“名（参数）-> 执行 -> 统一格式返回”的模式，并额外包一个错误处理的结构，让工具抛出的异常也能变成一个Agent能理解的Observation。
第四是状态管理和记忆机制。这一点涉及Agent是“一次性对话”还是“有持续记忆”的问题。短期记忆就是对话历史，长期记忆则需要向量数据库配合。没有记忆的Agent，就像金鱼一样，七秒钟后连自己最初的目标都忘了。这一块在后面的架构篇里我还会专门展开。
提示：如果你现在准备从零开发一个Agent，我建议先不要贪多，先把“单轮任务”跑通，再扩展到多轮。所谓单轮任务，就是User发出一个复杂指令后，Agent在内部自主完成多个工具调用并返回结果，全程不中断。这个稳定了，再去考虑长期对话和记忆。
2. 主流Agent架构模式与系统设计思路
2.1 单Agent的极简架构与致命短板
市面上80%的Agent Demo都采用单Agent架构。这种架构，你可以理解成：底层一个大模型，上面挂一个工具集，中间穿插一个调度循环。整个系统只有一条执行流水线，所有输入输出都经过同一个大脑处理。它在工程实现上极度友好，代码结构也很清晰，非常适合作POC验证或内部工具使用。
我早期做过一个数据分析Agent就是这种架构。它负责的任务是读取用户上传的Excel，分析数据，生成图表。整个链路是：用户上传文件 -> Agent解析文件路径 -> 调用Pandas工具做清洗和计算 -> 调用Matplotlib画图 -> 返回图片给用户。这个系统在任务比较固定时表现非常稳定，准确率可以达到95%以上。但一旦遇到需要同时处理“财务数据清洗+竞品价格分析+生成同比环比图表+撰写结论报告”的复合任务时，它就开始捉襟见肘了。因为单Agent的上下文窗口是有限的，推理链条过长时很容易丢失早期的关键信息，而且一旦中间某一步出错，它很难准确地定位、回滚和重试。
所以在实际架构设计中，我对单Agent的定位非常明确：它是“手工作坊”，适合单点任务深度优化，但不适合复杂多元化场景。如果你非要拿它硬扛复杂任务，性能会断崖式下降，而且调试成本会成倍增长。
2.2 多Agent协作架构：分配、监督与融合
既然单Agent处理复杂任务力不从心，自然会有人想到“一个大脑不够，那就上多个大脑”的解决方案。于是多Agent协作架构诞生了。这种架构的关键不再是单个Agent的智商，而是Agent之间的交互机制。我总结了三种最主流的协作模式：
第一种是编排者-执行者模式（Orchestrator-Worker）。这是目前最实用、最好落地的一种架构。系统里有一个核心的编排者Agent负责接收用户请求、分解任务、派发子任务给Worker Agent、回收结果、做最终整合。Worker Agent是执行特定功能的“专业打工人”，比如Excel处理Agent、爬虫Agent、报表生成Agent。这种架构的优势是每个Worker可以被单独优化、单独测试，同时编排者的上下文不会被各种繁杂的执行细节塞满，不至于“太忙而短路”。
第二种是评委模式（Judge）。这个模式特别适合内容创作场景。比如你让一个Agent写营销文案，可以同时让另一个Agent扮演目标用户，从用户视角挑毛病。还有一个Agent扮演营销总监，从专业度上把质量关。最后由一个聚合Agent综合两边的评审意见，修改出最终稿。这种模式下，质量上限会大幅提升，因为不同角色从不同维度轮番挑刺，效果往往比单个Agent自我反思要好。
第三种是对话式委派模式（Conversation-Delegate）。这种架构比较轻量，它把多Agent当作一个“群聊”，每个Agent在群里有自己的角色，所有消息都广播到群里，谁觉得自己能解决谁就接手。它的灵活性很高，但也是失控风险最高的一种。我在实践中发现，这种架构非常考验底层模型的语义理解能力，一旦模型能力不够，群里就会出现好几个Agent抢任务，或者互相推诿，导致任务卡死。
从实际落地难度来看，我个人的排序是：编排者-执行者模式 > 评委模式 > 对话式委派模式。如果你想通过Agent解决业务问题，强烈建议先从编排者-执行者模式入手，它是可控性和效果之间的最优解。
2.3 编排层到底在编排些什么：从任务拆分到结果合并
多Agent架构里，编排层（Orchestration Layer）的设计几乎是决定成败的关键。很多从单Agent转过来的团队，最容易犯的错误就是把编排层做成了一个“调用管理器”，只是机械地按顺序调用各个Worker，完全失去了“编排”的智能性。
真正的编排层要做的事情至少包括：
任务拆分：这是编排的核心功能。举个例子，用户请求“对上个季度的销售数据做分析并生成PPT汇报”。编排层需要把目标拆解成可执行的子任务树，至少包含：数据提取与清洗、销售趋势分析、客户流失分析、图表生成，最后才是汇报PPT组装。每一棵任务树的节点还要定义依赖关系，比如“图表生成”必须等待“销售趋势分析”完成，但可以和“客户流失分析”并行执行。
动态规划：好的编排层不是死板的先验规则，而是能根据任务的实时进展动态调整执行顺序。我通常会让编排者Agent把任务树构建成JSON格式，给每个任务节点设置“状态”，比如pending、running、completed、failed，再根据状态决定下一步调度方向。这种设计方案，回滚和重试也比较好实现。
结果融合与冲突消解：这是多Agent落地中最容易翻车的一环。多个Worker返回的结果可能是矛盾的，比如一个分析Agent认为客户流失率上升是因为产品价格，另一个Agent认为是竞品挤压市场。编排层需要有能力做信息交叉验证，或者返回给一个更高层级的决策Agent来仲裁。这个“结果仲裁环节”在新手搭建的系统里基本看不到，但恰恰是它决定了Agent输出的可靠性。
进度追踪与用户反馈注入：编排层必须保存任务执行的全过程记录。这一点在长耗时任务（比如自动生成一份深度行业研究报告）中特别重要，用户需要能实时看到“当前执行到哪一步了”，而不是干等。我习惯用Redis或者数据库把整个执行链路做成一个可查询的状态机，对外提供一个接口供前端轮询状态。
2.4 分层架构实战：五层解耦让Agent从“能跑”变“稳健”
前面讲了很多概念，这里我想给出一套我自己在落地多Agent系统时比较常用的“五层解耦”参考架构，这也是我在多个生产项目中沉淀下来的模式，你可以直接当成一个起点来用。
- 接入层：负责与外部交互，统一API接口、WebSocket消息推送、鉴权控制。它是最靠近用户的一层，主要解决“谁能用、用什么方式用”的问题。
- 编排层：负责接收接入层解析后的目标，做任务规划、调度、状态管理。这是整个Agent智能性的中枢，对应我前面说的任务拆分、动态规划、结果融合。
- 执行层：由多个专业Agent组成。每个Agent只负责一个抽象粒度较粗的技能，比如Excel分析、SQL查询、网页信息抽取、邮件发送。
- 工具层：执行层调用的是封装好的原子能力。比如“数据可视化工具”被封装成“输入DataFrame和图表类型，输出图片URL”。工具层的核心是标准化、可复用、可观测。
- 数据与记忆层：管理短期对话上下文、长期向量记忆、用户画像和业务数据库连接。它保证了Agent在不同会话之间的“记性”。
这种架构最大的优势是解耦。每一层的改动都不会直接影响其他层。举个例子，后期如果你想升级底层大模型，只需修改编排层和Agent组件里的模型调用参数，接入层和工具层完全不受影响。而如果你用单Agent或者不区分模块的方式堆积代码，后期升级任何一个环节都可能牵一发动全身，维护成本会极其痛苦。
在模型选型这块，我也可以给出一点参考。如果你的Agent主要跑在云端，预算充足，优先选GPT-4级别的闭源模型，推理架构和工具调用能力目前还是T0水平。如果你想私有化部署，那就要重视推理速度和显存开销了。Qwen系列开源模型在国内环境里兼容性不错，LLaMA系列在英文场景下表现稳定，Mistral系速度较快。一个小建议：不要只看模型跑基准分，要多用你自己系统里的真实任务请求去测，看它在你的工具定义下能不能正确输出函数调用参数。
3. 可落地的架构方案拆解与核心环节实现
3.1 一份可直接参考的Agent执行流程伪代码
理论讲完了，肯定有朋友想直接看代码。这里我不打算贴某一种具体语言的完整生产代码，因为不同团队选型不同，我更想分享一个适用于绝大多数场景的伪代码流程，它能把前面提到的最核心理念串起来：
用户发送请求 -> 系统加载System Prompt（包含角色定义和全局防护规则） -> 编排Agent接收并解析请求，生成目标描述（结构化JSON） -> 编排Agent调用“任务拆解模块”，产出任务树DAG -> 根据DAG依赖关系，调度队列依次或并发执行： 每个Worker Agent执行： Thought -> Action -> Observation 循环 直到某个Worker报告“任务完成”或“无法解决（需要升级）” -> 编排Agent收集所有Worker输出 -> 调用结果仲裁Agent或规则去冲突，判定最终输出 -> 格式化为统一响应结构，返回给接入层 -> 记录完整Session上下文到记忆层这段伪代码看起来不难，但实操落地时有非常多的细节需要注意。比如任务树DAG的实现，我建议不要自己去写调度引擎，直接引入像LangGraph、CrewAI这类成熟的编排框架，或者用DAG工具配合消息队列来做。很多时候你认为自己“造轮子更可控”，结果你会发现你在用未来的半年时间修复调度器本身的并发bug。
3.2 工具调用层的统一封装与参数格式设计
工具调用是Agent与现实世界互动的桥梁。一个设计糟糕的工具层，会让模型频繁报错，进而拖垮整个Agent系统。在设计工具层时，我遵循一个黄金法则：给模型的接口必须比给人的接口更简单，并且容错性更强。
我通常会把每个工具封装成一个JSON Schema描述，包含name、description、parameters（类型、必填性、枚举值等）。这里分享一个我常用的工具定义参考：
{ "name": "query_sales_data", "description": "查询指定日期范围的销售数据，返回汇总统计结果", "parameters": { "type": "object", "properties": { "start_date": { "type": "string", "description": "开始日期，格式YYYY-MM-DD" }, "end_date": { "type": "string", "description": "结束日期，格式YYYY-MM-DD" }, "dimension": { "type": "string", "enum": ["product", "region", "channel"], "description": "数据聚合维度" } }, "required": ["start_date", "end_date"] } }注意这里面的细节：每个参数都写了description，并且明确标注了格式。这能极大程度降低模型“编造”参数值的概率。在工程实现上，我还会额外做一层“参数校验器”，当模型返回的JSON缺少必填项或格式异常时，不是直接抛异常，而是把这个错误转换成Agent的一个Observation，让它自我修正。比如“工具执行失败：缺少必填参数end_date”，模型看到这个观察结果后会自动补上参数重试。
另外，工具层还有一个容易踩的坑——幂等性。你在设计工具的时候一定要考虑到Agent可能在执行超时后重发同一个请求。比如“发送邮件”这种工具，如果重试就可能导致客户收到两封一模一样的邮件。我的做法是给所有非查询类工具增加一个幂等键，每次调用生成一个唯一ID，在执行前先查一下这个ID是否已经执行过。这在金融、电商领域直接决定了系统能不能上生产。
3.3 短期记忆与长期记忆的分工与实现要点
记忆机制是Agent架构里非常重要的一环，它直接决定Agent是否“越用越懂你”。我习惯把记忆拆成两条线来看：
短期记忆就是当前任务上下文。它不需要存储到数据库，直接存在内存或Redis里即可。核心是控制Token长度，避免对话历史太长导致超出大模型上下文窗口。我常用的策略是滑动窗口加摘要压缩：保留最近N轮完整对话，更早的内容先用一个“摘要Agent”压缩成要点文本，再拼到上下文的前置部分。这个技巧在长对话场景里非常有效。
长期记忆是对用户画像、历史偏好和类似任务的经验积累。它必须落到向量数据库中。实现路径大致是：
- 系统定期将有用的信息（比如用户偏好、项目关键决策）做Embedding向量化；
- 存入向量数据库（Milvus、Qdrant、pgvector都可以）；
- 每次任务开始前，Agent先从向量库中检索出与当前任务最相似的Top-K条记忆，注入到System Prompt中。
这里有一个非常容易犯的错误：把所有的原始对话都存入向量库。结果就是检索出来的记忆极其碎片化，甚至还有相互矛盾的记录，严重干扰模型判断。我的建议是，在长期记忆里只存“加工后的结论”，例如“用户明确表示不喜欢在上午9点前开会”、“该项目使用技术栈是Java+React，团队对Docker特别熟”。这些结论不仅节省检索时间，命中准确率也远高于原始日志。
3.4 系统提示词（System Prompt）的结构化写法参考
前面反复提到System Prompt的重要性，这里我想直接给一个我在Agent项目里常用的Prompt骨架。这个骨架不偏科，适用于绝大多数的通用业务Agent，你可以直接拿来改：
你是[角色名]，一名专业的[业务领域]助理。 你的核心目标是：帮助用户完成[核心任务类型]。 工作原则： 1. 始终以用户的目标为导向，不进行无关的闲聊。 2. 必须按步骤推理，输出思考过程，但最终回复用户时只展示结论和必要解释。 3. 如果信息不足，优先调用工具获取，不要瞎编。 4. 遇到需要用户确认的决策点时，先询问再执行。 5. 在执行不可逆操作（删除、发送、支付）前，必须向用户明确确认。 可用工具： [工具名]：用于[用途]，参数[参数说明]，适用场景[场景描述]。 [工具名2]：用于... 回复格式要求： - 任务执行中：输出JSON格式的进度状态。 - 最终回复：使用简洁的markdown格式，包含结论、依据和下一步建议。 - 如果任务失败，必须给出原因和可操作的解决方案。这里特别提醒一点：不要在一份Prompt里塞太多工具。模型能同时正确调用的工具数量是有限的，实测下来，一次性展示的工具超过10个时，模型的工具选择准确率会明显下降。如果你确实有几十个工具，建议按场景划分成多个“工具包”，由编排层根据用户意图先确定工具包，然后再将限定的工具列表注入当前Agent的Prompt。这种“先粗筛后细调”的思路，能让准确率提升不少。
4. 工程落地避坑指南与常见故障排查
4.1 上下文失控：Token爆炸与关键信息丢失
在我见过的所有Agent生产事故中，出现频率最高的就是上下文管理失控。表现主要有两种：一种是对话轮次变多后，配上各种工具返回结果，Token直接暴增，单次请求费用飙升；另一种更隐蔽，就是早期对话里的关键信息被后期大量内容稀释，模型“忘了”用户最初的约束条件。
处理这个问题的核心武器是上下文压缩与关键信息抽取。我会在Agent运行过程中设置一个“检查点”，强行抽取三类信息：
- 用户的硬性约束（比如“预算不要超过5万”）
- 已确认的决策结论（比如“方案A已经确定，不再考虑方案B”）
- 还未完成的待办事项清单
这三类信息会被单独缓存，在每一轮对话的Prompt最前部反复注入。这相当于给Agent上了一个“印象强化保险”，它忘性再大，也能在关键时刻找回主线。另外，在执行多步骤工具调用时，我会在工具返回结果里只保留摘要和关键指标，而不是一股脑把几万行数据全部塞进上下文。
4.2 工具调用幻觉：模型“假装成功”的应对方案
工具调用幻觉是大模型Agent落地时最无语的问题。具体表现为：模型声称“已成功查询”，但实际上对应的API根本没有被调用，或者调用了但被系统拒绝了，它依然在返回里说“一切正常”。还有一种情况是“参数编造”，模型会凭空生成一个不存在的ID去查数据，然后因为没查到而陷入死循环。
应对这个问题的方案只有一个：强制校验+明确反馈。工具执行层必须把每一次调用的真实状态码、原始返回、错误信息原原本本地注入到Observation里。同时，在Prompt中明确加一句“除非你收到了工具的真实成功返回，否则不得向用户宣称操作完成”。这里我还喜欢加一个“双check”机制：先让Agent调用工具，再让一个独立的校验Agent对调用记录做抽查。双Agent校验虽然会增加一些成本，但在关键业务场景里非常值得。
4.3 多Agent通信死锁与任务循环：如何优雅终止
在多Agent系统里，协同工作经常会出现“死循环”。典型场景是：Agent A生成了一份报告，Agent B觉得格式不合格要求重写，Agent A重写后Agent B还是不满意，于是无限循环下去。这种问题单靠堆算力解决不了，必须在架构层设定终止条件。
我的做法是把所有循环类协作都装进“有限轮次循环”里，并设一个阈值。比如规定Agent B最多返回3次修改意见，超过3次后自动升级给一个更高权限的“主编Agent”做最终裁决。编排层在调度时也要记录每个子任务的成功/失败次数，超过阈值就直接标记为失败，并准备降级方案或人工介入。这个降级方案非常重要，现实中没有一个Agent系统能做到100%成功率，关键是失败后怎么兜底。
这里给一个简单的排查路径供参考：如果发现Agent执行任务卡住，先看卡在哪一步，是Thought产生不了下一步行动，还是Action一直报错，还是编排层的DAG没有触发下一步。用状态机记录全过程的话，这一步定位会非常快。
4.4 Agent稳定性评估：质量测评与回归测试框架
说了这么多架构和经验，最后聊一下Agent上线前必须要做的评估工作。Agent不像传统软件，可以靠单元测试覆盖逻辑分支。Agent的行为带有概率性，同一输入多次运行可能得到不同输出。所以评估Agent必须用“统计思维”，而不是“样例思维”。
我常用的评估框架包含两层。第一层是流程正确性检查，比如：必要工具是否被调用、参数格式是否合法、是否有危险操作被主动阻止、是否在信息不足时主动追问。这类检查可以用规则脚本或者轻量模型做。第二层是结果质量打分，需要根据任务目标设计若干评分维度，比如准确性、完整性、可读性、行动可执行性。我一般会准备一个几十条到上百条的评测集，每条任务都标注好期望的工具调用路径和最终答案要点。然后让Agent批量跑，算出一个综合通过率。每次改动Prompt或架构后，都把同一套评测集再跑一遍，得到回归结果。这样你才能知道你的“优化”到底是真的让系统变好了，还是只是碰巧修好了某一个偶然病例。
注意：Agent评测集一定要定期扩容。你现在覆盖的N个场景可能很全面，但真实用户永远会提出第N+1种想法。当线上监测到正确率下降时，不要焦虑，把线上失败案例沉淀到评测集里，再针对性调整Prompt和工具描述。这个过程有点像给小孩改错题，持续迭代，系统才会越用越稳。
最后再分享一个我个人的经验。刚开始接触Agent开发时，我特别喜欢研究复杂的“多智能体协作”架构，总觉得Agent越多越智能。后来在真实项目里被毒打了几次才明白：能用单Agent解决的绝不上多Agent，能用规则解决的绝不交给模型。Agent架构真正考验的不是你用了多炫酷的框架，而是你在不断简化系统的同时，还能把复杂任务稳定地消化掉。多Agent的优势在于“分工”，但劣势在于“通信成本和失控风险”。如果你能把编排、记忆、工具封装这三件基本功练扎实，哪怕只是单Agent系统，也足够处理80%以上的实际业务问题。这套底层原理搞透了，后面不管哪个新的Agent框架冒出来，你都能一眼看穿它的核心逻辑，快速上手。
