最近一段时间聊AI的人基本绕不开一个词LLM Agent。不管是在技术社区还是产品讨论群里你都会看到有人在问“怎么让大模型自动完成一整条任务链路”也有人在晒自己搭的Agent跑出了多复杂的工作流。坦白说Agent确实是这波大模型浪潮里少有的、既让开发者兴奋又让业务方眼前一亮的落地方向。但问题也很明显资料大多又散又深新人翻半小时就晕了。这篇文章就是干这个事的。我从核心架构讲起按“规划、记忆、工具、行动”四个模块拆开揉碎再配合40多个我在实际项目里接触过或复现过的案例把Agent全链路给你梳理清楚。不管你是刚入门的技术爱好者还是要评估这个方向的业务负责人都能从这里找到可以直接抄走的思路。全文没有高深数学不绕弯子看完你应该能回答三个问题Agent解决什么问题、内部怎么工作、我的场景到底怎么用它。1. Agent到底是什么它和普通AI应用差在哪1.1 一个例子看懂“聊天机器人”和“Agent”的区别我先用一个对比把概念讲清楚。你打开一个普通的大模型聊天页面对它说“帮我写一份关于智能仓储的调研报告”。它会干嘛它会直接给你输出一份报告。写得挺像样但内容可能是基于训练数据的记忆编出来的不会上网查最新的行业数据也不会去翻你公司的业务文档。如果你说“报告里的第三个表格用今年第一季度的数据”它就傻了因为它没有联网、没有记忆、没有执行动作的能力。Agent的玩法完全不同。同样一句话Agent会先把它拆成任务清单查行业资料、找政策文件、分析趋势、生成报告框架、填充内容、转成你想要的格式。然后它自己决定调用哪些工具——可能在知识库里检索可能去搜索引擎抓最新数据也可能调一个数据分析脚本算指标。每一步执行完它还会看看结果符不符合预期有问题就回头调整。最后你拿到的是一个真正经过“查证—整理—生成—自检”的交付物而不是一段凭空生成的话。一句话总结普通AI应用是大模型的三寸不烂之舌Agent是大模型的四肢加大脑。它不只是“会说”还会“做”而且自己能判断该做什么、怎么做、做得对不对。1.2 Agent爆火背后的核心技术与应用图谱Agent的这轮热度本质上是几项能力凑齐了才爆发的。第一是基础模型的推理能力上来了。现在的顶级大模型在逻辑推断、多步推理上明显更强这是Agent“规划”的底子。第二是接口标准化模型厂商陆续开放了函数调用能力模型可以按固定格式输出一个“我要调某工具、参数是什么”的指令外部系统再执行这个指令并返回结果这就形成了工具调用的闭环。第三是上下文窗口变大模型可以在单次对话里承载更长的任务链条和中间结果不至于聊两步就断片。这三件事叠加之后Agent从“实验室玩具”变成了能稳定干活的工具。目前我见过的高频场景主要有六大类信息搜集与调研、内容生产与润色、软件开发辅助、办公自动化、数据分析、以及垂直行业问答。这些场景共同的特点是任务可以拆解、过程可以观测、结果可以验收。如果一个任务完全不可拆、结果无法判断好坏那Agent还真帮不上忙。1.3 小白最容易踩进的两个心智误区第一个误区把Agent当成“一个更聪明的对话框”。实际上Agent的威力不在单次回答而在多轮决策链。它不是问一句答一句而是一个“自己给自己派活”的流程控制器。抱着聊天心态去用你会觉得它又慢又啰嗦因为你没给它足够的自主空间。第二个误区以为Agent能“全自动无监督”。至少在现阶段我还没见过哪个生产级的Agent能够完全脱离人工验收。更现实的做法是“人在环上”——让Agent批量干活人在关键节点检查、审批、纠偏。认清楚这一点你对效果预期就不会跑偏。2. 核心架构拆解规划、记忆、工具、行动是怎么回事2.1 规划模块任务怎么拆、先做什么后做什么规划是Agent大脑里的“总指挥”负责把用户最终目标拆成子任务并且排列执行顺序。目前最主流的做法是ReAct范式也就是“推理—行动”交替进行。Agent每一步先想一想“当前情况是什么、要达成目标还缺什么”基于这个判断决定调哪个工具观察工具返回的结果后再进入下一轮思考。你去看让它干活时的日志会看到类似“思考用户需要数据我应该先查询数据库”再“行动调用查询接口”的交替记录。这个模式的好处是过程透明出问题你可以追责到具体某一步。除了ReAct还有一种常用的规划手段是“任务分解”。复杂目标会被Agent拆成若干可独立执行的小步骤甚至形成一棵任务树多个分支可以并行跑。比如让它做一个季度经营分析它可能拆出“拉取订单表”“计算毛利率”“生成趋势图”“写结论段落”四个分支有的分支之间没有依赖关系就能并发执行整体效率高很多。要注意的是现在的规划能力还做不到完全零失误。如果任务描述模糊Agent拆出来的步骤很可能是错的。所以我的习惯是给Agent下达任务时一定带上明确约束背景是什么、产出物是什么、质量标准是什么、边界是什么。你给它提需求的方式和给一个刚入职的新人交代工作一模一样。2.2 记忆模块短期工作记忆与长期知识记忆Agent聊到一半忘了之前说了什么、查过的数据下次对话还在不在这都归记忆模块管。短期记忆通常就是一个上下文窗口相当于Agent手里的便签纸记着当前任务的中间状态。但便签纸有尺寸限制塞太满就会“忘事”。所以很多成熟的Agent会做上下文压缩把历史对话里的细枝末节总结成要点只保留关键信息继续推进。这里有个小技巧不是所有对话记录都值得保留像“用户回复了一个‘好’”“中间某次工具调用失败”这类信息直接精简掉不影响主流程反而能节省大量窗口空间。长期记忆更像是Agent的私人笔记本通常用向量数据库存储。Agent可以把用户偏好、历史决策、领域知识等内容转成向量存起来需要的时候按语义相似度取回。比如你之前让它生成过一份偏“保守稳健”风格的报告再那次对话结束后它把这个偏好写入了长期记忆。下次你再让它写报告它检索到这条习惯风格就会自动对齐。记忆模块最容易忽略的反而是“记什么、不记什么”的规则设计。无脑把所有历史都塞进记忆库检索时反而会因为噪声太多抓不到重点。实际项目里我会给记忆内容打来源标签和质量标签用户明确说的、高置信度的推理、外部已验证的事实分别存储检索时按优先级返回。2.3 工具模块Agent的双手怎么伸出去没有工具的Agent只是一个“嘴强王者”有了工具它才能真的干活。工具模块解决两件事每个工具负责什么能力、Agent怎么样正确调用它们。工具的类型跨度很大。有普通的信息类工具比如搜索引擎检索、企业内部知识库查询有操作类工具比如发邮件、改在线表格、跑一段代码还有容器类工具比如操作浏览器页面、执行数据库脚本。关键是工具的描述要让模型看得懂一个工具对外暴露的名称、功能描述、参数格式都相当于给模型的一份“产品使用说明”。说明写得不清楚模型就会瞎调、传错参数。这里插一个主流实践有人把工具定义成开放协议的形式工具方按统一规范暴露接口模型侧按协议解析调用指令进一步缩小了模型理解工具的成本。这个抽象层次我建议新手不用管太多专心上手“写清楚工具描述”这一件事效果提升就非常明显。工具描述里不要只写“查询订单”至少要写明“参数order_id是下单时系统生成的16位数字编号必填查不到返回空列表”。描述越具体模型选错工具的概率越低。2.4 行动与反馈怎么确保Agent真把活干对了行动模块是Agent落到真实世界的那一脚。工具调用发出去了总得有东西拿回来把执行结果反馈给Agent才能进入下一轮决策。反馈有两个来源成功路径和失败路径。成功路径上工具会返回结构化结果。比如数据库查询返回数据表搜索接口返回标题和摘要代码执行器返回运行日志。Agent拿到这些结果后会结合当前任务判断下一步数据够了就进入生成环节不够就继续补充查询。这个环节要求工具返回格式尽量干净否则Agent沉浸在解析复杂返回值里反而耽误了主线任务。失败路径上常见情况有两种。一种是工具抛异常比如接口超时、权限不足、脚本报错。稳健的Agent要把异常信息原样传给模型并给出可选择的修复动作比如“搜索超时可以重试一次或改用备选关键词”。另一种是执行成功但结果不合理比如搜索返回的和话题完全无关的内容。这时我会在Agent的指令里加一条自检规则要求它在写进最终答案前逐条核对引用来源是否和原始问题相关。这一条自检习惯能直接过滤掉很大比例的错误输出。3. 手把手搭一个最小可用的Agent选型与配置3.1 框架选型自己写还是站在别人肩上我先说结论个人项目或快速验证原型建议直接上主流的Agent编排框架别自己造轮子团队项目或深度定制场景可以考虑基于框架二次开发。主流的Agent编排框架通常已经把“模型调用、工具注册、记忆存储、任务循环”这几件核心事封装好了。你只要写模型的配置、注册几个工具函数就能跑出一个能自主决策的Agent。好处是起步快生态里已经有一堆现成的工具插件从搜索到数据库到办公软件都有。坏处是抽象层次高出了问题不好排查底层逻辑特别是任务循环卡住的时候你得会看它的内部执行日志否则就是黑盒。如果选择自己写一个极简Agent核心代码并不复杂。我在最早期试过只用一个主循环来实现接收任务把任务和上下文发给大模型模型输出要么是“需要调用工具”的请求要么是“最终答案”代码判断输出类型后执行对应动作。整个循环不超过200行。这种方式的好处是你对每一步都了如指掌调优起来非常顺手。等循环稳了再逐步往里面加记忆、加多任务调度。我给一个实际的选型建议编程能力强、喜欢掌控细节的人从手写循环开始目标是快速出成果、验证业务的人直接用框架。前者练内功后者抢时间没有谁一定优于谁。3.2 最简实现一个能自己规划并搜索的Agent我用虚构的伪代码给你演示一个最简Agent帮助你建立全局概念不依赖具体技术栈。初始化配置: 模型 某大模型服务, 温度 0.2 定义工具集: search(关键词) - 返回搜索结果的标题和链接 fetch_page(链接) - 返回页面正文前3000字 主循环(用户目标): 输入历史 系统提示 用户目标 工具清单 历史对话 模型输出 模型(输入历史) 如果 模型输出 是 工具调用指令: 执行对应工具, 拿到结果 把结果追加到历史对话 回到主循环开头 如果 模型输出 是 最终答案: 返回答案给用户这个流程看着简单但已经具备Agent的完整骨架了。我做第一版的时候踩过一个坑忘记在工具清单里写明“search适合用来找实时信息fetch_page适合用来提取正文细节”结果模型用fetch_page去处理概括性问题一步就抓了3000字无关内容把上下文塞得又满又乱。后来我在工具描述里加了适用场景说明准确率直接上了一个台阶。配置这个最简Agent我还建议你把模型温度调低到0.2左右。Agent任务不是创意写作而是带约束的决策与执行温度越低输出越稳定、越不容易天马行空。这个细节属于“知道的人不说、不知道的人反复试错”的那种经验。3.3 Prompt在Agent里的反直觉用法别让它“自由发挥”很多人把Agent里的Prompt当成普通对话提示词来写写着“你是一个智能助手请帮我完成任务”。这种写法在Agent里效率很低因为你的核心目标不是激发出模型的创造性而是约束执行边界。我给Agent写系统提示词通常会包含五个部分角色定位、任务背景、可用工具以及各自的适用条件、执行流程要求、输出格式规范。举例来说我会写明“如果你需要查证实时数据必须调用search如果用户没有明确要求深度分析最终答案控制在500字以内每一步执行前先输出一句思考过程”。你可能会觉得这样约束太多了模型放不开手脚。但Agent的使用场景恰恰就是要收敛而不是发散。真正会玩Agent的人都在想尽办法减少不确定性让每个决策点都有规则可依让每种边界情况都有兜底策略。越是“不自由”的Agent在真实业务里越听话、越可靠。4. 40多个实战案例全景拆解从场景分类到深度复盘4.1 按业务场景分类的案例全图这一节我把这些年见过的、亲手做过的案例集中做一个大盘点。每个案例都代表一类可复制的模式你可以对照自己的业务找灵感。我把案例按场景分成八组每组都有明确的模式可以参考。信息搜集与调研类竞品动态监控定时搜索竞品消息生成日报摘要。行业报告生成抓取行业数据自动整理成结构化报告。论文文献调研按主题检索论文提炼研究脉络。政策法规更新追踪监控指定网站更新归类解析。舆情热点聚合按时间线汇总事件发展附关键词云。人物背景调研从多源信息中汇总公开资料。线下活动信息收集整理活动时间、地点、议程。招聘岗位分析抓取岗位描述提炼技能要求共性。电商用户评价洞察汇总评论归纳产品优缺点。学术会议预告汇总追踪多个会议网站生成日历。内容生产类长文自动撰写给定提纲逐段扩写并配小标题。短视频脚本生成按爆款结构产出分镜和台词。营销邮件个性化改写按用户画像调整语气和卖点。周报自动汇总从聊天记录和任务工具里提取进展。多语言内容翻译与本地化不只是翻译还调整文化表达。产品卖点提炼从功能介绍里抽取核心优势。幻灯片大纲生成按照听众角色定制结构。公众号排版辅助生成标题、摘要、段落分割建议。新闻通稿改写从素材里提取口径生成通稿。小说人设与世界观工具协助创作者搭建虚构设定。软件开发辅助类需求文档转代码框架从PRD生成项目脚手架。Bug根因分析助手结合报错日志定位可疑代码段。代码评审小助手按规范清单检查提交代码。单元测试自动生成为函数生成边界用例。数据库查询优化分析慢查询提供索引建议。API文档生成从代码注释生成接口文档。遗留系统重构辅助识别重复代码给出拆分方案。每日代码提交信息整理从git记录汇总成发布说明。技术选型对比从多个维度对比框架与方案。部署日志异常检测扫描日志关键词提前预警。办公自动化类会议纪要与待办提取从录音转写稿提炼行动项。合同关键条款抽取扫描合同正文高亮风险点。发票信息录入解析票据图片写入费用系统。项目日报自动生成从协作平台拉取动态。邮件分类与优先级排序按发件人与主题分班。客户工单分诊根据用户描述判断部门与紧急度。员工入职问答机器人解答制度政策类高频问题。报销单合规预检按财务规则检查附件与金额。知识库文章自动归档给文档打标签、写摘要。排期冲突检测比对多个日历找空档。数据分析类销售数据异常归因查出指标波动背后因素。问卷开放题自动编码把文本答案归类成量化标签。日志聚类分析把同类报错聚合成几个核心模式。报表解读摘要生成给核心指标变化配文字解释。因果实验效果分析辅助分析AB测试结果。用户分群特征描述从用户数据里提炼群体画像。数据质量巡检扫描空值、异常值、重复记录。趋势预测与解释基于时间序列给出趋势和理由。竞品价格跟踪分析采集价格变化生成调价建议。流量渠道归因分析整理各渠道贡献度。教育与知识服务类个性化学习计划生成按目标和时间生成课程表。题库自动出题按知识点生成练习题与解析。错题原因归类根据错题记录分析薄弱点。知识点通俗讲解把复杂概念转成生活化类比。面试模拟陪练按岗位提问并给反馈。读书笔记生成按章节提取核心观点。技能图谱构建从招聘和行业资料生成技能树。语言学习对话陪练场景对话与纠错。生活与效率类旅行行程规划按时间与预算生成路线。健身计划调整根据身体反馈更新训练量。购物决策对比从参数、口碑、价格多维度对比。家庭物品管理记录存放位置并提醒补充。菜谱推荐与替换根据冰箱库存生成菜谱。租房信息筛选按关键词过滤和排序房源。活动策划助手从预算、人数、主题生成方案。专业领域垂类法律条文关联检索给出相关法条与解释。医疗报告解读辅助解释指标含义与建议方向非诊断。金融产品说明书解读拆解条款和风险点。心理咨询情绪回应的辅助文案生成温和沟通用语。建筑方案说明生成从图纸标注整理成说明文档。以上覆盖了市面上极大部分Agent的应用场景。你不需要一次性全部上手挑和你工作最近的三个试试跑通之后你对Agent的感知会完全不一样。4.2 实战案例一竞品动态监控Agent这个案例是我建议初学者第一个上手的项目因为它技术难度适中但价值立竿见影。需求很简单每天定时搜索几个竞品的新闻和官方公告去重后生成一张摘要表。我最初手动做这件事每天花半小时后来搭了一个Agent每天自动跑我只需要早上花三分钟检查。实现思路分三段定时触发、信息搜集、汇总推送。定时触发的做法很成熟用操作系统的定时任务就行每天上午九点触发一次脚本。信息搜集用的是搜索工具加页面抓取搜索关键词设为竞品名称加上“发布”“更新”“动态”这样的动作词。抓回源页面后Agent会把正文截断到关键词周边的内容而不是整页保存这样既省token又避免上下文塞满无用信息。汇总推送是整个Agent里最体现细节的部分。我不需要它把原文复制一遍我要的是“今天有什么值得注意的事”。所以给它的生成指令是对每条新闻写一句话摘要标明影响程度高/中/低再单独给一个“值得关注的变化”栏。影响程度的判断规则提前写死比如出现“融资”“涨价”“重大合作”判断为高影响出现常规内容则判断为中低影响。跑了一段时间后我总结出一个经验信息去重比想象中重要。多个源会报道同一条新闻如果不做去重Agent生成的日报会有一半内容是重复的。后来我在流程里加了一步把新闻标题先用关键词归一化相同事件只保留信息量最大的那条源。这个改进之后日报质量有明显提升。4.3 实战案例二代码仓库智能问答Agent给一个中大型代码仓库做一个能回答问题的Agent是我做过最有挑战的案例之一。它和普通问答Agent最大的区别在于代码答案必须准确不能“差不多”就行否则误导开发者。这个Agent本质上做的是检索增强生成核心链路是“建立代码索引—检索定位—生成解释”。第一步把代码仓库里的文件切片每个切片不超过几百行并且让切片保留函数名和类名等结构信息方便后续检索。第二步给每个切片生成向量表示存入向量数据库。第三步用户提问时把问题转成向量检索出最相关的若干代码片段再连同问题和片段一起发给模型让模型基于片段回答。我在这里遇到的最大坑是检索粒度问题。最初我把整个文件作为一个单元存储导致检索返回的是整份几十行的文件模型回答时容易受到无关代码的干扰指向错误的函数。后来改成函数级粒度存储检索命中率明显提升。所谓函数级就是按代码里的函数或类定义去切一个函数对应一个存储单元保证回答时引用的上下文足够聚焦。还有一个容易被忽略但很重要的细节这类Agent应该在答案后面附上引用位置。我会要求模型在回答里明确指出“这个逻辑在xxx模块的xxx函数里”而不是只丢结论。这样开发者拿到答案后能快速跳到代码位置确认效果可信度立刻不一样。4.4 实战案例三多Agent协作写作工坊上面案例都是单Agent在跑这个案例我想聊聊多Agent协作模式因为这种模式在处理复杂任务时确实有亮点但也更容易翻车。写作工坊的思路是不把写作任务交给一个Agent全程负责而是拆成几个专职Agent角色——研究Agent先搜集选题素材大纲Agent整理素材并生成结构初稿Agent按结构落笔成文审校Agent检查逻辑漏洞和事实错误再由编辑Agent统一风格和语气。每个Agent只做自己最擅长的一段任务链上每个环节都可以单独替换和调优。我试跑这个方案时最明显的提升是长文的逻辑连贯性好过单个Agent写。单个Agent写到后半程容易忘掉开头定的风格和素材重点而多Agent模式下每个Agent拿到的输入都经过了结构化交接比如大纲Agent传给初稿Agent的不是原始素材而是带重点标注的章节提纲这样就避免了信息衰减。但这个模式也有很烦人的地方延迟高、token消耗高。五个Agent串行跑一篇长文确实比单Agent慢不少而且中间任何一环输出不规范后面全乱。后来我做了两个调整一是把交接格式固定成JSON结构必须包含“要点”“素材编号”“风格指示”三个字段减少歧义二是加了一个超时重试机制某个Agent超过预期时间还没输出就自动重跑一次。这两个调整让工坊从“偶尔能用”变成了“稳定可用”。5. 上线之后最容易踩的八个坑问题排查实录5.1 上下文越跑越乱从“忘了前提”到“记住太多垃圾”Agent跑长了之后最典型的问题就是上下文失控。具体会有两种表现一种是最开始的任务要求被后续内容冲淡Agent越做越偏另一种是完全相反上下文中塞入了大量无关过程信息模型判断变慢甚至被噪声带偏。我的处理办法是“分阶段快照”。每个阶段性任务完成之后让Agent生成一份阶段摘要把原始目标和已完成情况写清楚后续步骤从摘要继续而不是从完整历史继续。这类似给Agent做了一次“记忆整理”只保留骨架丢掉琐碎的肌肉。这个习惯一旦养成了Agent的长任务稳定性会明显改善。另外还要控制“每次对话只做一件事”。如果用户在一个会话里既要求查资料又要求做表格还要润色文风最好先拆成三个子任务不要指望一个Agent在一条上下文里同时完成。这不是模型能力问题而是上下文管理策略问题。5.2 工具选择错乱与死循环工具选择错乱我见过很多种形态出题类任务去调搜索、分析类任务去查数据库、明明给了专用的绘图工具不用偏要用通用页面抓取去处理。本质原因是工具描述不够具体或者工具之间存在能力边界模糊。解决思路非常朴素每个工具的描述里写明“适用于什么场景、不适用于什么场景”并且给工具之间设置优先级。如果你有两个工具都可能被选中可以在描述里注明“查询订单状态优先使用订单查询接口数据库工具仅供数据管理员排障使用”。这种“路标式”的说明能让模型的决策稳定很多。死循环则是另一个让人头皮发麻的问题。Agent反复调用同一个工具拿到相同的结果又重复发起调用活活把预算烧完。我的做法是加一个“重复动作检测”如果Agent在同一任务里对同一工具发起超过N次相同参数的调用系统就强制中断并在提示中告诉它“你已经试过这个方法了请更换路径”。这个限制看起来简单但能规避掉大部分失控场景。5.3 效果评估与成本控制怎么知道你做的Agent真的行很多新手做完Agent后只会一句“感觉还挺好用的”但在正式场景里这是不够的。我建议给Agent建立一套可量化的评估集。收集50条典型任务手工标注标准答案每次修改Prompt或调整工具后都跑一遍这个评估集对比正确率变化。这个过程很枯燥但它是Agent持续优化的基础。你改了一个工具描述就压测一次你会非常清楚地知道什么改动有效、什么改动反而搞砸了。成本控制也很有讲究。我见过一个翻车案例某同事用Agent批量处理一千条客服工单没有做任何缓存和拦截设计一个下午烧掉了一笔不小的预算。合理做法是三层控制第一层是设置单次任务最大模型调用次数超出即终止第二层是工具返回结果做规模限制比如搜索只取前三条网页正文只截取关键段第三层是批量场景先跑10条小样本估算成本再决定是否全量执行。5.4 大规模落地代理的避坑经验速查表我把这几年实操中积攒的关键经验整理成一张速查表方便你对照自检。风险环节常见表现我的对策任务指令拆解错误、方向跑偏给背景、产出物、质量标准、边界约束四要素工具描述选错工具、传错参数写清适用场景、参数格式、不适用场景上下文管理长任务丢失目标阶段性快照只保留摘要和关键结果执行循环死循环、重复动作加重复动作检测和最大调用次数信息可靠性引用错误、数据过期强制要求附引用来源自检相关性成本预算费用超支小样本试跑再全量限制单任务调用次数效果评估无法判断好坏建评估集改一次压测一次用户信任结果“差不多但不对”提供追溯链路让用户能看到决策过程前面说的这些坑几乎无一例外是“不跑生产环境根本看不出来”的。做Demo和跑生产是完全两码事很多Agent项目在上线之前看着挺完美一上真实数据、真实流量各种边角问题全暴露出来了。这一节的速查表就是帮你少交点学费的。写在最后的几句真心话从我自己的实操感受来说Agent确实是大模型应用里最有“作品感”的方向。相比单次问答它在更长的时间维度上执行任务、协同工具、自我修正我经常觉得像是在带一个不怎么睡觉得实习生你得把目标讲清楚、把工具教明白、把过程盯住还要在它跑偏的时候及时拉回来。这个比喻虽然有点半开玩笑但如果你搭建过Agent你一定会点头。最后再分享一个实用技巧做Agent别一上来就想搞多复杂先从一个极小的闭环跑通哪怕只是“搜索一个关键词然后把第一条结果读给你听”。这个最小闭环跑通之后你会对规划、工具、反馈这些抽象概念建立起真实的体感。后面再逐步加记忆、加多步任务、加多Agent协作都是顺理成章的事。技术的路从来都是越走越熟的Agent更是如此。