1. 面试官第一问你写的那个聊天机器人算不算Agent上周我去某头部电商平台面一个AI Agent方向的岗位面试官没让我自我介绍上来就抛了一个问题你简历上写的那个智能助手能聊天、能推荐商品、还能生成文案它算Agent吗我当时下意识点头觉得当然算。但面试官紧接着补了一句如果我把你写的Prompt模板抽掉它还能自己决定下一步干什么吗如果不能那它只是套了Agent外壳的ChatBot。这一下把我问住了。回去之后我把整条技术链路重新捋了一遍才发现自己之前对Agent的理解确实浮在表面。这篇文章就是把那次追问的完整过程复盘出来用大白话拆清楚大模型究竟是怎么从会聊天变成会干活的Agent的灵魂到底藏在哪以及一套能直接落地的设计思路。不管你是刚入门的小白还是已经在写Agent应用的开发者这篇都值得收藏。我会尽量少用黑话遇到绕不开的术语就用生活里的例子解释保证你看完能复述给别人听。面试官其实是在提醒一个关键事实会调用大模型不等于懂Agent会设计Agent不等于懂Agent灵魂。灵魂这个东西听起来玄但落到工程上完全可以拆解成可检验的模块。下面我从那场面试的追问链开始讲。1.1 Agent与ChatBot的分界线主动权在哪里先放下概念想一个最简单的场景。你让聊天机器人帮我订一张周五去杭州的高铁票普通ChatBot会怎么做它给你一段回答好的建议您登录12306选择周五出发的车次……它把订票这件事做成了教你怎么订票。Agent会怎么做它会先拆解订票需要哪些信息出发地、目的地、时间、车次偏好缺什么就问什么然后调用订票接口、支付接口一步一步把票订完再把订单号给你。前者的主动权在用户手里后者的主动权在系统手里。主动权是否发生转移就是ChatBot和Agent的第一条分界线。这条线看起来简单实际落地时大部分人在这里就翻车了。因为让语言模型主动决定下一步很容易实现难的是让它的每一个主动决定都是可预期的、可追溯的、不会跑偏的。面试官想听的其实不是Agent会拆解任务这种泛泛之谈而是你知不知道拆解之后有哪几个环节最容易失控。我后来把这条追问链整理成了四层感知层、规划层、行动层、反思层。ChatBot基本只有感知层和一层很薄的话术生成Agent则把后面三层真正做得有厚度。下一节就按这个链条展开。1.2 能干活的三个硬指标工具、状态、反馈听面试官连续追问了几个项目之后我总结出他判断你是不是真做过Agent的三个硬指标这三个词在简历里都见过但多数人没往深里想第一个硬指标是工具调用。你的Agent能不能真正操作外部系统而不是把操作步骤写成文字回复比如查天气、发邮件、改订单状态、写数据库这些动作必须通过真实的函数调用完成。代码实现上通常是一个tools列表加一个解析循环大模型输出结构化参数系统执行函数并把结果喂回模型。第二个硬指标是状态管理。你的Agent能不能记住当前做到哪一步了、已经拿到了什么信息、还缺什么信息聊天机器人只需要记住对话历史Agent需要维护一个任务状态这和上下文完全是两码事。很多新手把整个对话历史全部塞进Prompt看起来是记住了其实模型对有效状态的感知被大量废话稀释了。第三个硬指标是反馈闭环。工具的返回结果能不能真正影响Agent的下一步决策如果工具返回了支付失败、余额不足Agent是机械地回复支付失败还是能自动转入引导用户换支付方式的新分支后者的本质是让模型根据真实世界反馈去做下一轮规划这也是Agent和脚本的本质区别。脚本是写死的if-elseAgent是模型自己决定if后面的分支怎么走。面试官说了一句我印象特别深的话Agent不是大模型的加强版大模型只是Agent的发动机。你是不是真在造车要看轮子、方向盘和仪表盘不能光看引擎参数。工具、状态、反馈这三个指标就是轮子、方向盘和仪表盘。2. 追问链条拆解从能聊天到能干活中间隔着一台规划器面试的第二个环节面试官指着我简历里的一个项目问这里面哪一段代码是你认为最像Agent灵魂的我犹豫了一下说是模型调用那段。他摇头说那段代码最多算灵魂的嘴巴真正的灵魂应该在调用之前——在模型开口之前谁决定它这一秒该调用哪个工具、该回答哪个问题这个谁来决定就是Agent里常说的规划器Planner。市面上所有主流Agent框架不管宣传得多花哨核心都是一个循环感知→规划→行动→观察→再规划。这个循环在学术圈叫ReAct在公司里叫主循环在小白的理解里其实就是一个问题下一步做什么由谁说了算大多数人的第一版Agent下一步做什么是由用户说的用户问什么模型答什么。进阶版是模型自己说了算但经常跑飞。成熟版是由模型提出方案由约束条件做裁决——模型的自由度还在但被任务边界、格式约束、安全护栏框住了。这一段我把规划器的几种主流形态拆开讲。2.1 为什么拆任务是Agent的第一基本功想象一个新人入职第一天领导让他办一场产品发布会。正常人的第一反应不是冲出去订场地而是先拆发布会包含哪些子任务场地、物料、嘉宾、流程、预算、每个子任务需要什么资源、先后顺序是什么、哪些可以并行。大模型也一样。你告诉它帮我制定一个三亚五日游攻略它如果不拆解直接生成一段三千字的指南那就又退化成了ChatBot。Agent的做法是先把三亚五日游拆成确定预算→选择日期→确定航班→预订酒店→规划每日行程→生成行李清单然后逐个执行。执行确定航班时可能还要再拆一层——调用航班查询工具、解析返回结果、对比价格、输出选择建议。这个层层拆解的能力是Agent和ChatBot在任务处理上的分水岭。工程上我们通常会把任务拆解和状态管理绑定在一起形成一个任务树。每个节点记录状态待执行、执行中、已完成、已失败。主循环每次只盯住当前该执行哪个叶子节点执行完再回到父节点判断是否全部完成。我在实际项目里发现一个新手容易忽略的点拆解不是一次性的。模型先拆出一版方案真正执行时会发现航班查询接口返回超时或者预算超了这时候任务树必须支持动态调整。好比发布会筹备到一半发现预定的场地被临时征用你得马上改方案而不是对着旧计划死磕。所以任务树的设计要考虑两个能力节点间的依赖关系、失败节点的重规划入口。这两点做扎实了Agent才经得起真实世界的折腾。2.2 三种主流规划形态ReAct、Plan-and-Execute、混合模式规划器不是只有一种写法我梳理了三种主流形态面试时如果能把它们的取舍讲清楚基本就能证明你不是只会调库。第一种是ReAct推理和行动交替进行。模型的每一次输出既有思考过程Thought又有行动决策Action还有一个观察结果Observation三个字段串成一个循环。它的优点是简单直接模型看到最新观察立刻做下一步决策上下文信息天然连贯缺点是长任务容易陷入走一步看一步缺乏全局视野就像一个人蒙着眼睛下楼每一步都踩稳了才迈下一步但不知道整栋楼有几层。第二种是Plan-and-Execute先规划再执行。模型在开始行动前先产出一份完整计划然后逐步执行计划里的每一项。每一步执行完可以根据结果微调后续计划。它的优点是全局规划让Agent不容易跑偏适合多步骤任务比如自动写调查报告、批量处理数据缺点是计划本身可能不合理一旦初始规划有错后面每一步都在一个错误的框架里打转就像按照一份错版地图开车每走一步都自信地错得更远。第三种是混合模式这也是我现在最推荐的。先让模型产出一版完整计划但执行路径上允许在必要时跳出计划重新规划。具体做法是设置一个重新规划触发器当工具返回异常、执行结果与预期严重不符、或者某个子任务连续重试三次失败就暂停当前计划让模型复盘并生成新计划。这种模式在真实业务里最抗造因为它兼容了前两种的优点又给了失败兜底。从面试官的追问来看他真正在意的是你能否解释为什么这个任务适合这种规划方式。规划不是越复杂越好而是越匹配任务性质越好。比如查询类任务用ReAct就够了硬套Plan-and-Execute反而增加延迟而一个需要二十步操作的数据处理流程只用ReAct不做全局规划跑到第五步大概率就忘了最终目标。2.3 工具调用Agent的手是怎么伸出去的规划器决定了下一步做什么工具调用决定了这一步怎么做。我在项目里见过最蠢的做法是把所有工具塞在一段超长的System Prompt里让模型自己看着选。这么做的问题和把所有代码写在一个文件里一样看起来都能跑实际维护起来想死。规范的Agent工具设计至少要包含三层。第一层是工具注册表每个工具声明名字、用途描述、入参JSON Schema、返回类型大模型靠这些元信息决定什么时候用哪个工具。描述写得好不好直接影响模型的调用准确率——我实测过同样一个天气查询工具描述写成查天气和根据城市名与日期返回实时天气数据适用于出行前气候评估后者的调用触发准确率能高十几个百分点。第二层是参数注入与校验。模型输出的是结构化参数系统负责将参数映射到真实函数。这里必须加一道校验参数类型对不对、必填字段有没有、数值范围合不合理、有没有注入风险。你不可能让模型直接拼SQL但很多人忽略的是——也不能让模型直接拼URL。参数拼接处就是安全边界哪怕内部系统也必须过一层白名单校验。第三层是返回结果的后处理。工具返回的数据通常是脏的字段名不对、格式不统一、内容超长。直接把这些脏数据原样塞回上下文模型的注意力会被垃圾信息打乱。正确做法是设置一个格式化层比如把数据库返回的行记录压成商品名xxx价格xxx的摘要把超长的列表截断成前N条并注明总数。这层处理做得好不好直接影响长链路任务的稳定性。我踩过最深的坑是工具返回结果太长。一次调用某个接口返回了上万字的JSON我原样塞进上下文结果模型彻底失焦开始强行理解堆在一起的字段名。后来养成的习惯是所有工具返回都做摘要且摘要里永远带上本次调用是否成功这个信息。带状态的结果是Agent观察环节的地基。3. Agent灵魂之一让模型自己决定下一步的状态感知机制面试进行到第三个环节面试官的问题开始变得更尖锐。他问如果一个Agent一直重复做同一件事比如反复调用同一个查询接口你会怎么处理你会在代码里用if-else判断次数还是会让模型自己意识到这样不对该换一种方法了这个问题听起来简单其实是灵魂级的。它考验的是你对Agent自主性的理解深度。规约式的防重复机制是一种方案但它没有让Agent拥有真正的自我认知基于状态的自我调整是另一种方案它让Agent具备了我觉得这样下去不行的判断力。后者是我理解的Agent灵魂第一大要素。市面上Agent框架普遍有一个误区把System Prompt写得越长以为Agent就越聪明。实际上真正让Agent灵光一现的往往是运行时的状态信息——现在执行到哪一步、已经尝试过哪些方案、哪些方案被证明无效、剩余预算还有多少。这些信息如果在每一轮决策时都被模型看到它就有了自我感知的依据。3.1 ReAct循环里的Thought字段其实是思维黑匣子前面提到ReAct循环有三个核心字段Thought、Action、Observation。面试官尤其在意Thought字段。他说他面试时会让候选人当场写一个Agent的调试日志然后问他如果某一步出了问题你凭什么知道是模型想错了还是工具执行错了还是观察结果被格式污染了这个问题我当时其实是答不上来的。因为我在开发中主要看最终输出对不对很少去审中间过程对不对。后来才明白Thought字段就是Agent的思维黑匣子它记录模型在每一步决策前的推理过程。如果调试时发现Action不对去看Thought通常能找到根因——可能是工具描述误导了模型可能是上下文里混入了矛盾信息也可能模型真的理解偏了。比如有一次我做的商品推荐Agent在某个类目下频繁推荐错品查日志发现Thought里出现了一句话用户需求不明确尝试根据类目推断偏好。问题就出在推断两个字上——这个场景下模型本应调用历史偏好查询工具但它选择了猜。这既不是工具的问题也不是模型的问题是工具调用规则没有在Prompt里写清楚。原来系统Prompt只写了可以用查询工具获取用户偏好没有写必须优先使用该工具禁止在无数据时猜测。加了这条硬约束并更新了工具描述之后错误率直接降了一半。所以你看Thought字段不只是给模型思考用的它更是给人调试用的。一个合格的Agent系统必须做到每一个Action都有对应的Thought可回溯。这比准确率指标更底层因为不可回溯的准确率出了问题也没法定位。3.2 上下文不是越长越好短期记忆的有效期设计另一个关于状态感知的痛点是上下文管理。很多新人做Agent恨不得把所有历史对话、工具结果、中间思考全部堆在上下文里以为信息越多决策越准。但模型对上下文的注意力是有限的而且超过一定长度之后中间部分的信息很容易被压扁。就像你开一个超长会议开头和结尾记得清楚中间讨论的细节反而模糊了。我后来在项目里把上下文分成三个区核心区放当前的用户目标、关键约束、最近的决策状态工作区放当前步骤需要的工具结果和局部信息归档区放已经完成的子任务的摘要不再保留完整过程。每一轮主循环开始前系统自动裁剪归档区把超过N轮之前的过程压成一行摘要。这套设计的思路很简单模型做决策依赖的不是所有信息而是和当前决策相关的信息。信息过载和信息缺失一样致命甚至更致命——因为它让模型产生虚假的确定性在错误的方向上自信地执行。面试官还追问了一个细节如果用户中途改了需求你的Agent怎么感知到这种变化这其实就是状态感知的另一个维度——目标漂移检测。我当时的做法是在每轮循环开始时做一个目标一致性校验把当前状态和原始目标做一次语义相似度比对低于阈值就触发目标重规划分支。后来发现效果不错但代价是多一次模型调用。如果对延迟敏感也可以用轻量规则先做关键词级校验命中变化信号再走语义级确认。3.3 反思机制让Agent学会这次不行换个思路反思Reflection这个词这两年很热但真正做好的人不多。我理解的反思机制分成三层任务级反思、策略级反思、认知级反思。任务级反思是这一步结果不对我换一种执行方式策略级反思是这套拆解方案整体效率低我重新规划认知级反思是我的工具调用原则有问题需要更新后续所有决策的偏好。很多Agent框架做到了第一层少数做到第二层第三层几乎没人做。原因是第三层意味着要让模型改写自己的决策偏好风险很大。但面试官恰恰最看重这个他说了一句话让我记忆犹新Agent和脚本的本质区别就是Agent可以否定自己之前的决定。如果它只会按照既定路径执行那和Shell脚本没有区别只是包装得更像人。我当时举了一个案例我的自动化数据采集Agent连续跑了两小时突然开始频繁调用一个高延迟接口导致任务超时。我加了反思节点之后模型在执行超过五次、平均延迟超过阈值时主动改了策略跳过那个接口改用备用数据源任务最终在预算时间内完成。这个案例不是炫技它说明一个道理反思机制不是额外功能而是Agent在真实世界长期存活的关键器官。反思机制的工程实现其实不复杂本质是在主循环里加一个检查点当某种模式反复出现时把之前的完整行动轨迹和历史观察打包发给大模型让它产出一个后续策略调整建议。这个建议经过安全校验之后以临时规则的形式覆盖到后续决策中。关键是触发条件和覆盖范围的设置这两个参数需要大量实验才能调稳。4. Agent灵魂之二记忆不是缓存是忘掉什么和记住什么的艺术面试官第四轮开始考记忆。他问得特别直接如果你的Agent服务一千个用户每个用户都有自己的偏好和上下文你怎么设计记忆系统你打算把所有人的对话记录都存进向量数据库吗这个问题很多人的第一反应是那就上向量检索。但面试官想听的显然不是这个。他接着补充如果存了一百万条记忆但检索时每次都召回五十条其中四十条是噪声那你觉得记忆多了是帮助还是负担这一下又把问题拉回到了记忆的核心矛盾记忆不是存得越多越好越精准才越好。Agent的记忆系统设计本质上是在回答三个问题什么该记、什么时候记、什么时候忘。这三个问题对应三种不同的存储机制。很多人只做了记完全没设计忘和取最后系统就像一间堆满杂物的房间找东西比没东西还难。4.1 工作记忆会话内的上下文折叠策略工作记忆是Agent在当前任务或当前会话内的短期存储对应人类的正在手头处理的事情。它和技术上的上下文窗口Context Window直接相关但不等于上下文窗口——窗口是大模型能看到的全部信息的上限工作记忆是Agent在每轮主动挑选并维持的有用信息集合。我在第三节提过三个区的设计这里展开说。核心区要有硬性的长度上限比如固定几百字装的是用户目标、硬性约束、关键进度。工作区存当前正在执行的子任务的中间结果长度可以灵活但也要设置上限。归档区是摘要集中营每条摘要必须控制在几十字以内。这套策略的核心目的是保证模型每一轮决策时核心决策信息始终在注意力的黄金位置。实验数据也很能说明问题同样一个多步骤任务使用上下文折叠策略的Agent比全量堆叠上下文的Agent任务完成率提高了接近两成响应延迟也明显降低。折叠不是偷懒是刻意制造信息稀缺让模型不得不聚焦在最关键的信号上。折叠策略的设计细节也有讲究。折叠动作不是每轮都做而是只有在新信息要写进核心区、核心区空间不足时才触发。折叠的对象是当前最不相关的已完成子任务的完整过程折叠产物是一条结构化摘要。折叠之前系统会把被折叠的原始内容先写入长期记忆存储避免重要信息丢失。4.2 长期记忆向量检索召回率不是越高越好长期记忆解决的是跨会话、跨任务的经验沉淀。现在主流方案是把重要信息向量化存进向量数据库需要时做相似度召回。但这里有一个反直觉的点召回率不是越高越好。召回五十条信息让模型从中挑不如召回精挑细选的五条让模型直接用。信息召回的本质是引入决策依据不是提供可选阅读材料。长期记忆的写入时机比检索方法更值得花心思。我的策略是只有三类信息允许写入长期记忆。第一类是用户明确表达过的偏好比如我订酒店从来不要低楼层第二类是任务结果里被验证为成功或失败的关键经验比如上次用这个接口超时了三次第三类是用户画像类信息比如身份、常驻地、常用支付方式。其他对话内容一律不写入。写入前还有一道过滤关卡模型先对候选信息做一次结构化抽取输出主体属性取值置信度置信度低于阈值就丢弃。这套过滤机制能有效防止把闲聊内容当成偏好存入长期记忆。比如用户说这家店真难吃不应该存成用户认为这家店难吃而应该提取为用户偏好避开该餐厅或者干脆不存因为单次情绪化表达不足以形成稳定偏好。检索侧的技巧是给每条记忆打上元数据标签记忆类型、创建时间、最近访问时间、来源任务ID。召回时可以叠加时间衰减权重和类型过滤比如当前任务是订酒店只从偏好类记忆中召回。这种过滤能让召回命中率大幅提升——把一百条同类型记忆塞给模型和只给十条高度相关的记忆决策质量完全不是一个级别。4.3 遗忘机制为什么说会忘比会记更高级最后说遗忘。这可能是Agent记忆设计里最不受重视、却又最影响体验的环节。很多人设计记忆系统只想着怎么记从没想过怎么删。但真实用户是变化的一个用户去年喜欢重口味川菜今年开始健身饮食清淡一个用户三年前喜欢某个明星现在早就脱粉了。如果Agent把过时的偏好一直当作决策依据体验会越做越差。我的做法是给每条长期记忆一个保质期和刷新机制。保质期按记忆类型设定用户画像类最长偏好类中等临时经验类最短。每次成功使用一条记忆系统自动延长它的有效期如果在有效期内从未被使用到期后先降级为低置信度记忆检索权重降低连续两个周期未使用就直接删除。这种机制背后有一个朴素的信念Agent应该像一个人一样既记得住重要的事也放得下过时的事。一个人的记忆如果从不遗忘反而会形成思维定式。我在项目里专门设计了一个记忆矛盾检测步骤如果用户新的表述和长期记忆里的旧偏好冲突系统不直接覆盖而是标记为待确认冲突在下一轮对话里温和地跟用户核对。这个方法很笨但实测效果比盲目相信记忆库好很多——因为用户会因为你记得他而惊喜也会因为你记错了他而失望这两个体验的差距直接决定了一个Agent能用多久。5. 拿得出手的实战一个可直接复刻的最小Agent设计与跑通记录前面聊了这么多理论和设计原则可能有些读者已经有点飘了觉得Agent不过如此。但面试官从来不会因为你会说而满意他一定会追问那你现场写一个给我看看第五轮面试面试官的原话是从零开始设计一个面向客服场景的售后处理Agent只给三十分钟你会怎么搭既能演示又不会有大量BUG的完整流程这个要求其实很考验基本功。你在纸上写一堆漂亮的设计图没有用得能落成运行起来的代码。下面我把当时的搭建思路和核心步骤完整复现一遍你照着走也能跑出一个能演示的最小Agent。5.1 需求收敛第一件事不是写代码而是砍需求接到售后处理Agent这个命题的时候我做的第一件事是先砍范围。三十分钟能演示的Agent绝对不能做成全品类全场景智能客服否则光意图识别模型就要选半天。我把需求收敛成了三个主流程查单、改地址、退款申请。覆盖了查询类、操作类、高风险类三种典型Agent动作足够演示但也足够简单。砍需求的原则是先证明主循环能跑通再考虑业务复杂度。你能在十分钟内让Agent完整走一遍用户提问→规划→调用工具→格式化结果→回复这个闭环的价值比堆一百个功能点大得多。业务场景可以后续慢慢扩展主循环是灵魂必须先立住。接下来定义工具集。查单需要一个订单查询函数输入订单号输出订单状态改地址需要一个更简单的模拟工具只做参数校验并返回成功或失败退款申请同理想做成模拟工具。工具数量控制在三个以内既能体现多工具协同又不会让演示时手忙脚乱。每个工具都配上JSON Schema格式的入参定义方便模型生成结构化调用参数。5.2 核心主循环Python代码骨架与执行流程架构上我只用一个Python文件不引入重型Agent框架把主循环写得清清楚楚。模型的角色只有一个根据当前状态和工具描述决定调用哪个工具或者直接回复用户。下面是核心代码骨架我简化了错误处理让逻辑更清晰import json from typing import Dict, List # 伪代码以任意支持function calling的大模型接口为例 # llm_chat_with_tools(messages, tools) - response TOOLS [ { name: query_order, description: 根据订单号查询订单状态、物流信息、商品清单, parameters: { type: object, properties: { order_id: {type: string, description: 用户提供的订单号} }, required: [order_id] } }, { name: modify_address, description: 修改未发货订单的收货地址。发货后不可修改, parameters: { type: object, properties: { order_id: {type: string}, new_address: {type: string} }, required: [order_id, new_address] } }, { name: apply_refund, description: 为订单发起退款申请。退款金额由系统根据订单状态计算, parameters: { type: object, properties: { order_id: {type: string}, reason: {type: string} }, required: [order_id, reason] } } ] def run_agent(user_message: str) - str: messages [ {role: system, content: 你是售后处理助手。请严格按工具描述执行用户请求。 如果需要额外信息直接向用户提问不要编造订单数据。}, {role: user, content: user_message} ] max_steps 10 for step in range(max_steps): response llm_chat_with_tools(messages, TOOLS) # 情形一模型决定调用工具 if response.get(tool_calls): for call in response[tool_calls]: result execute_tool(call[name], json.loads(call[arguments])) messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) continue # 情形二模型直接回复用户 return response[content] return 处理超时请稍后重试或联系人工客服 def execute_tool(name: str, arguments: Dict) - Dict: if name query_order: return query_order(arguments[order_id]) if name modify_address: return modify_address(arguments[order_id], arguments[new_address]) if name apply_refund: return apply_refund(arguments[order_id], arguments[reason]) return {error: unknown tool}这段代码麻雀虽小五脏俱全System Prompt定义了行为边界TOOLS注册了工具元信息主循环让模型自己决定调工具还是回复用户工具返回作为新消息追加到上下文中。实际演示时我会准备三条测试路径。路径一是直接查单帮我看看订单20240601到哪了模型应调用query_order并返回物流信息。路径二是改地址订单20240602的收货地址改成某某路某号模型应调用modify_address。路径三是个陷阱场景我要退款但没有给订单号——好的Agent应该反问要订单号而不是编一个假单号去调apply_refund。这三条路径能覆盖主循环的基本形态已经足够应对三十分钟的演示。5.3 跑通后的三轮自问边界、容错、成本代码能跑通只是第一步面试官通常会继续追问三个深度问题。第一问你的Agent边界在哪比如用户说我要骂人模型是会乖乖接话还是礼貌拒绝如果用户问你能帮我写周报吗你一个售后Agent会不会跑去做文档任务这是System Prompt和工具集共同决定的没有对应工具的任务模型应该回复不在我的处理范围内而不是用大模型通用能力硬接。我在System Prompt里特意加了一条仅处理与订单售后服务相关的任务其他请求一律拒绝。第二问工具调用失败怎么容错比如modify_address被调用时参数里没有new_address或者订单已发货不能修改。我在execute_tool里做了兜底返回错误信息会以JSON形式回到上下文。模型看到错误信息后应该能主动判断需要补充信息或告知用户无法修改。这个应对逻辑不用写死在代码里靠模型自然推理就能完成但要保证错误信息是结构化、可解析的不要让模型在垃圾文本里捞线索。第三问一次任务的成本大概多少这是所有Agent上生产前都必须算的账。每次主循环都是一次模型调用一次复杂任务可能循环五到十次。如果用的是商业大模型API按token计费一次售后任务可能消耗几千甚至上万token。所以在演示版里我故意把max_steps设成了10既是防死循环也是在暗示面试官成本控制靠的不是模型而是主循环的退出条件设计。支持用户提供完备信息、工具返回高质量结果、减少无效循环这三个方向的优化空间比换低价模型大得多。我后来在真实项目里对这套最小骨架做了扩展加上了任务状态记录、工具结果缓存、失败重规划分支整体架构没有变但稳定性上了好几个台阶。先跑通主循环再逐步加护栏这是Agent项目最稳妥的推进路径。你不需要一上来就上Agent框架也不需要对标那些复杂的生产级中间件一个文件加上清晰的主循环足够你理解Agent的全部核心机制。6. 复盘那次面试之后我总结出的Agent设计铁律面试结束之后我把整个过程又完整回顾了好几遍。有些道理是当时面试官直接点醒我的有些是后来在实践中摔了跟头才明白的。这些东西不一定写在任何技术文档里但它们决定了一个Agent系统是能站起来还是能跑起来。作为最后一部分我直接分享几条个人总结的设计铁律。6.1 Agent的灵魂在反馈闭环里不在模型参数里很多人以为Agent的灵魂在大模型的参数量、在推理能力、在prompt技巧上。我的结论和面试官高度一致Agent的灵魂在反馈闭环的完整性上。一个Agent系统可以拆成五个节点目标设定、状态感知、规划决策、行动执行、反馈吸收。参数量只是行动执行这一环的底座而多数人会把精力全砸在这一环上——换更大的模型、调更长的上下文、写更花哨的prompt。但真正让Agent显得有灵性的是反馈吸收这个环节做得好不好工具返回的结果有没有被正确解析状态有没有被及时更新失败有没有触发反思这些链路如果不闭合模型参数再大也只是个更聪明的ChatBot。放一个具体例子。我做过一个测试同一个任务一套系统每次工具返回后都做结构化摘要另一套系统把原始结果直接塞上下文。前者的任务完成率高出接近三成。同一个模型、同一个Prompt差异只在反馈吸收这一步。这个实验很朴素但说服力极强——优化Agent优先优化信息流转而不是优化模型。6.2 评估Agent要看最差表现而不是平均表现第二条铁律关于评估。Agent系统的平均表现很容易做得好看因为大多数任务会落在常见路径上模型正常推理就能通过。但一个Agent能不能上生产看的是极端情况下的表现用户乱给参数、工具接口返回超时、上下文里混入干扰信息、多步操作在第三步失败……这些场景才是Agent系统的短板所在。我现在的习惯是维护一份刁钻测试集专门收录真实环境中出现过的异常输入。每改一版Agent先用这套测试集跑一遍把失败case按根因分类是工具描述不清晰、是上下文管理不到位、还是规划策略有问题。修的时候也是按根因修而不是打补丁式地给Prompt加规则。评估Agent不仅要问它能不能做对更要问它能不能知道自己错了。把自己放到Agent的位置上想你会更清楚哪里还不够稳。一个知道自己错了、能主动澄清、能换一种方法继续尝试的Agent比一个90%场景表现优秀但10%场景沉默乱来的Agent更值得信任。这也是面试官反复强调的可靠优先于聪明。6.3 给正在入门Agent的朋友们三个行动建议最后如果你正在入门Agent我给你三条直接可执行的建议都是我当初走了弯路之后总结的。第一条亲手写一个不带框架的最小主循环。不要一上来就上那些流行的Agent框架因为框架帮你隐藏了大量关键机制你用它跑通了Demo但不知道哪里是灵魂。花一个周末写一个像我上面演示的最小Agent一个文件、三个工具、一个循环。这个过程的收获比读十篇框架文档都大。第二条给Agent写思考日志。生产环境里把每一轮的Thought、Action、Observation都记录下来不仅是调试利器更是后续优化的第一手素材。我至少三次在思考日志里发现性能问题的根因而这些根因在最终答案里根本看不出来。第三条每做一个Agent先定义它不该做什么。能力边界比能力本身更重要。写系统提示词时先写绝对禁止清单再写应该做什么。这个顺序颠倒了Agent的确定性就很难保证。如果你已经看到了这里说明你对Agent是真的有兴趣。那就用我这套思路去拆解你手头的项目先从最小主循环开始把反馈闭环做完整把记忆的取舍和遗忘机制设计好。等这些核心模块真正内化了再回头看看那些花哨的框架和论文你会有一种原来它们只是在给这几个铁律包壳的通透感。那时候你就算真正看懂Agent的灵魂了。 大模型Agent灵魂在哪里：从ChatBot到能干活的核心设计与实践
1. 面试官第一问你写的那个聊天机器人算不算Agent上周我去某头部电商平台面一个AI Agent方向的岗位面试官没让我自我介绍上来就抛了一个问题你简历上写的那个智能助手能聊天、能推荐商品、还能生成文案它算Agent吗我当时下意识点头觉得当然算。但面试官紧接着补了一句如果我把你写的Prompt模板抽掉它还能自己决定下一步干什么吗如果不能那它只是套了Agent外壳的ChatBot。这一下把我问住了。回去之后我把整条技术链路重新捋了一遍才发现自己之前对Agent的理解确实浮在表面。这篇文章就是把那次追问的完整过程复盘出来用大白话拆清楚大模型究竟是怎么从会聊天变成会干活的Agent的灵魂到底藏在哪以及一套能直接落地的设计思路。不管你是刚入门的小白还是已经在写Agent应用的开发者这篇都值得收藏。我会尽量少用黑话遇到绕不开的术语就用生活里的例子解释保证你看完能复述给别人听。面试官其实是在提醒一个关键事实会调用大模型不等于懂Agent会设计Agent不等于懂Agent灵魂。灵魂这个东西听起来玄但落到工程上完全可以拆解成可检验的模块。下面我从那场面试的追问链开始讲。1.1 Agent与ChatBot的分界线主动权在哪里先放下概念想一个最简单的场景。你让聊天机器人帮我订一张周五去杭州的高铁票普通ChatBot会怎么做它给你一段回答好的建议您登录12306选择周五出发的车次……它把订票这件事做成了教你怎么订票。Agent会怎么做它会先拆解订票需要哪些信息出发地、目的地、时间、车次偏好缺什么就问什么然后调用订票接口、支付接口一步一步把票订完再把订单号给你。前者的主动权在用户手里后者的主动权在系统手里。主动权是否发生转移就是ChatBot和Agent的第一条分界线。这条线看起来简单实际落地时大部分人在这里就翻车了。因为让语言模型主动决定下一步很容易实现难的是让它的每一个主动决定都是可预期的、可追溯的、不会跑偏的。面试官想听的其实不是Agent会拆解任务这种泛泛之谈而是你知不知道拆解之后有哪几个环节最容易失控。我后来把这条追问链整理成了四层感知层、规划层、行动层、反思层。ChatBot基本只有感知层和一层很薄的话术生成Agent则把后面三层真正做得有厚度。下一节就按这个链条展开。1.2 能干活的三个硬指标工具、状态、反馈听面试官连续追问了几个项目之后我总结出他判断你是不是真做过Agent的三个硬指标这三个词在简历里都见过但多数人没往深里想第一个硬指标是工具调用。你的Agent能不能真正操作外部系统而不是把操作步骤写成文字回复比如查天气、发邮件、改订单状态、写数据库这些动作必须通过真实的函数调用完成。代码实现上通常是一个tools列表加一个解析循环大模型输出结构化参数系统执行函数并把结果喂回模型。第二个硬指标是状态管理。你的Agent能不能记住当前做到哪一步了、已经拿到了什么信息、还缺什么信息聊天机器人只需要记住对话历史Agent需要维护一个任务状态这和上下文完全是两码事。很多新手把整个对话历史全部塞进Prompt看起来是记住了其实模型对有效状态的感知被大量废话稀释了。第三个硬指标是反馈闭环。工具的返回结果能不能真正影响Agent的下一步决策如果工具返回了支付失败、余额不足Agent是机械地回复支付失败还是能自动转入引导用户换支付方式的新分支后者的本质是让模型根据真实世界反馈去做下一轮规划这也是Agent和脚本的本质区别。脚本是写死的if-elseAgent是模型自己决定if后面的分支怎么走。面试官说了一句我印象特别深的话Agent不是大模型的加强版大模型只是Agent的发动机。你是不是真在造车要看轮子、方向盘和仪表盘不能光看引擎参数。工具、状态、反馈这三个指标就是轮子、方向盘和仪表盘。2. 追问链条拆解从能聊天到能干活中间隔着一台规划器面试的第二个环节面试官指着我简历里的一个项目问这里面哪一段代码是你认为最像Agent灵魂的我犹豫了一下说是模型调用那段。他摇头说那段代码最多算灵魂的嘴巴真正的灵魂应该在调用之前——在模型开口之前谁决定它这一秒该调用哪个工具、该回答哪个问题这个谁来决定就是Agent里常说的规划器Planner。市面上所有主流Agent框架不管宣传得多花哨核心都是一个循环感知→规划→行动→观察→再规划。这个循环在学术圈叫ReAct在公司里叫主循环在小白的理解里其实就是一个问题下一步做什么由谁说了算大多数人的第一版Agent下一步做什么是由用户说的用户问什么模型答什么。进阶版是模型自己说了算但经常跑飞。成熟版是由模型提出方案由约束条件做裁决——模型的自由度还在但被任务边界、格式约束、安全护栏框住了。这一段我把规划器的几种主流形态拆开讲。2.1 为什么拆任务是Agent的第一基本功想象一个新人入职第一天领导让他办一场产品发布会。正常人的第一反应不是冲出去订场地而是先拆发布会包含哪些子任务场地、物料、嘉宾、流程、预算、每个子任务需要什么资源、先后顺序是什么、哪些可以并行。大模型也一样。你告诉它帮我制定一个三亚五日游攻略它如果不拆解直接生成一段三千字的指南那就又退化成了ChatBot。Agent的做法是先把三亚五日游拆成确定预算→选择日期→确定航班→预订酒店→规划每日行程→生成行李清单然后逐个执行。执行确定航班时可能还要再拆一层——调用航班查询工具、解析返回结果、对比价格、输出选择建议。这个层层拆解的能力是Agent和ChatBot在任务处理上的分水岭。工程上我们通常会把任务拆解和状态管理绑定在一起形成一个任务树。每个节点记录状态待执行、执行中、已完成、已失败。主循环每次只盯住当前该执行哪个叶子节点执行完再回到父节点判断是否全部完成。我在实际项目里发现一个新手容易忽略的点拆解不是一次性的。模型先拆出一版方案真正执行时会发现航班查询接口返回超时或者预算超了这时候任务树必须支持动态调整。好比发布会筹备到一半发现预定的场地被临时征用你得马上改方案而不是对着旧计划死磕。所以任务树的设计要考虑两个能力节点间的依赖关系、失败节点的重规划入口。这两点做扎实了Agent才经得起真实世界的折腾。2.2 三种主流规划形态ReAct、Plan-and-Execute、混合模式规划器不是只有一种写法我梳理了三种主流形态面试时如果能把它们的取舍讲清楚基本就能证明你不是只会调库。第一种是ReAct推理和行动交替进行。模型的每一次输出既有思考过程Thought又有行动决策Action还有一个观察结果Observation三个字段串成一个循环。它的优点是简单直接模型看到最新观察立刻做下一步决策上下文信息天然连贯缺点是长任务容易陷入走一步看一步缺乏全局视野就像一个人蒙着眼睛下楼每一步都踩稳了才迈下一步但不知道整栋楼有几层。第二种是Plan-and-Execute先规划再执行。模型在开始行动前先产出一份完整计划然后逐步执行计划里的每一项。每一步执行完可以根据结果微调后续计划。它的优点是全局规划让Agent不容易跑偏适合多步骤任务比如自动写调查报告、批量处理数据缺点是计划本身可能不合理一旦初始规划有错后面每一步都在一个错误的框架里打转就像按照一份错版地图开车每走一步都自信地错得更远。第三种是混合模式这也是我现在最推荐的。先让模型产出一版完整计划但执行路径上允许在必要时跳出计划重新规划。具体做法是设置一个重新规划触发器当工具返回异常、执行结果与预期严重不符、或者某个子任务连续重试三次失败就暂停当前计划让模型复盘并生成新计划。这种模式在真实业务里最抗造因为它兼容了前两种的优点又给了失败兜底。从面试官的追问来看他真正在意的是你能否解释为什么这个任务适合这种规划方式。规划不是越复杂越好而是越匹配任务性质越好。比如查询类任务用ReAct就够了硬套Plan-and-Execute反而增加延迟而一个需要二十步操作的数据处理流程只用ReAct不做全局规划跑到第五步大概率就忘了最终目标。2.3 工具调用Agent的手是怎么伸出去的规划器决定了下一步做什么工具调用决定了这一步怎么做。我在项目里见过最蠢的做法是把所有工具塞在一段超长的System Prompt里让模型自己看着选。这么做的问题和把所有代码写在一个文件里一样看起来都能跑实际维护起来想死。规范的Agent工具设计至少要包含三层。第一层是工具注册表每个工具声明名字、用途描述、入参JSON Schema、返回类型大模型靠这些元信息决定什么时候用哪个工具。描述写得好不好直接影响模型的调用准确率——我实测过同样一个天气查询工具描述写成查天气和根据城市名与日期返回实时天气数据适用于出行前气候评估后者的调用触发准确率能高十几个百分点。第二层是参数注入与校验。模型输出的是结构化参数系统负责将参数映射到真实函数。这里必须加一道校验参数类型对不对、必填字段有没有、数值范围合不合理、有没有注入风险。你不可能让模型直接拼SQL但很多人忽略的是——也不能让模型直接拼URL。参数拼接处就是安全边界哪怕内部系统也必须过一层白名单校验。第三层是返回结果的后处理。工具返回的数据通常是脏的字段名不对、格式不统一、内容超长。直接把这些脏数据原样塞回上下文模型的注意力会被垃圾信息打乱。正确做法是设置一个格式化层比如把数据库返回的行记录压成商品名xxx价格xxx的摘要把超长的列表截断成前N条并注明总数。这层处理做得好不好直接影响长链路任务的稳定性。我踩过最深的坑是工具返回结果太长。一次调用某个接口返回了上万字的JSON我原样塞进上下文结果模型彻底失焦开始强行理解堆在一起的字段名。后来养成的习惯是所有工具返回都做摘要且摘要里永远带上本次调用是否成功这个信息。带状态的结果是Agent观察环节的地基。3. Agent灵魂之一让模型自己决定下一步的状态感知机制面试进行到第三个环节面试官的问题开始变得更尖锐。他问如果一个Agent一直重复做同一件事比如反复调用同一个查询接口你会怎么处理你会在代码里用if-else判断次数还是会让模型自己意识到这样不对该换一种方法了这个问题听起来简单其实是灵魂级的。它考验的是你对Agent自主性的理解深度。规约式的防重复机制是一种方案但它没有让Agent拥有真正的自我认知基于状态的自我调整是另一种方案它让Agent具备了我觉得这样下去不行的判断力。后者是我理解的Agent灵魂第一大要素。市面上Agent框架普遍有一个误区把System Prompt写得越长以为Agent就越聪明。实际上真正让Agent灵光一现的往往是运行时的状态信息——现在执行到哪一步、已经尝试过哪些方案、哪些方案被证明无效、剩余预算还有多少。这些信息如果在每一轮决策时都被模型看到它就有了自我感知的依据。3.1 ReAct循环里的Thought字段其实是思维黑匣子前面提到ReAct循环有三个核心字段Thought、Action、Observation。面试官尤其在意Thought字段。他说他面试时会让候选人当场写一个Agent的调试日志然后问他如果某一步出了问题你凭什么知道是模型想错了还是工具执行错了还是观察结果被格式污染了这个问题我当时其实是答不上来的。因为我在开发中主要看最终输出对不对很少去审中间过程对不对。后来才明白Thought字段就是Agent的思维黑匣子它记录模型在每一步决策前的推理过程。如果调试时发现Action不对去看Thought通常能找到根因——可能是工具描述误导了模型可能是上下文里混入了矛盾信息也可能模型真的理解偏了。比如有一次我做的商品推荐Agent在某个类目下频繁推荐错品查日志发现Thought里出现了一句话用户需求不明确尝试根据类目推断偏好。问题就出在推断两个字上——这个场景下模型本应调用历史偏好查询工具但它选择了猜。这既不是工具的问题也不是模型的问题是工具调用规则没有在Prompt里写清楚。原来系统Prompt只写了可以用查询工具获取用户偏好没有写必须优先使用该工具禁止在无数据时猜测。加了这条硬约束并更新了工具描述之后错误率直接降了一半。所以你看Thought字段不只是给模型思考用的它更是给人调试用的。一个合格的Agent系统必须做到每一个Action都有对应的Thought可回溯。这比准确率指标更底层因为不可回溯的准确率出了问题也没法定位。3.2 上下文不是越长越好短期记忆的有效期设计另一个关于状态感知的痛点是上下文管理。很多新人做Agent恨不得把所有历史对话、工具结果、中间思考全部堆在上下文里以为信息越多决策越准。但模型对上下文的注意力是有限的而且超过一定长度之后中间部分的信息很容易被压扁。就像你开一个超长会议开头和结尾记得清楚中间讨论的细节反而模糊了。我后来在项目里把上下文分成三个区核心区放当前的用户目标、关键约束、最近的决策状态工作区放当前步骤需要的工具结果和局部信息归档区放已经完成的子任务的摘要不再保留完整过程。每一轮主循环开始前系统自动裁剪归档区把超过N轮之前的过程压成一行摘要。这套设计的思路很简单模型做决策依赖的不是所有信息而是和当前决策相关的信息。信息过载和信息缺失一样致命甚至更致命——因为它让模型产生虚假的确定性在错误的方向上自信地执行。面试官还追问了一个细节如果用户中途改了需求你的Agent怎么感知到这种变化这其实就是状态感知的另一个维度——目标漂移检测。我当时的做法是在每轮循环开始时做一个目标一致性校验把当前状态和原始目标做一次语义相似度比对低于阈值就触发目标重规划分支。后来发现效果不错但代价是多一次模型调用。如果对延迟敏感也可以用轻量规则先做关键词级校验命中变化信号再走语义级确认。3.3 反思机制让Agent学会这次不行换个思路反思Reflection这个词这两年很热但真正做好的人不多。我理解的反思机制分成三层任务级反思、策略级反思、认知级反思。任务级反思是这一步结果不对我换一种执行方式策略级反思是这套拆解方案整体效率低我重新规划认知级反思是我的工具调用原则有问题需要更新后续所有决策的偏好。很多Agent框架做到了第一层少数做到第二层第三层几乎没人做。原因是第三层意味着要让模型改写自己的决策偏好风险很大。但面试官恰恰最看重这个他说了一句话让我记忆犹新Agent和脚本的本质区别就是Agent可以否定自己之前的决定。如果它只会按照既定路径执行那和Shell脚本没有区别只是包装得更像人。我当时举了一个案例我的自动化数据采集Agent连续跑了两小时突然开始频繁调用一个高延迟接口导致任务超时。我加了反思节点之后模型在执行超过五次、平均延迟超过阈值时主动改了策略跳过那个接口改用备用数据源任务最终在预算时间内完成。这个案例不是炫技它说明一个道理反思机制不是额外功能而是Agent在真实世界长期存活的关键器官。反思机制的工程实现其实不复杂本质是在主循环里加一个检查点当某种模式反复出现时把之前的完整行动轨迹和历史观察打包发给大模型让它产出一个后续策略调整建议。这个建议经过安全校验之后以临时规则的形式覆盖到后续决策中。关键是触发条件和覆盖范围的设置这两个参数需要大量实验才能调稳。4. Agent灵魂之二记忆不是缓存是忘掉什么和记住什么的艺术面试官第四轮开始考记忆。他问得特别直接如果你的Agent服务一千个用户每个用户都有自己的偏好和上下文你怎么设计记忆系统你打算把所有人的对话记录都存进向量数据库吗这个问题很多人的第一反应是那就上向量检索。但面试官想听的显然不是这个。他接着补充如果存了一百万条记忆但检索时每次都召回五十条其中四十条是噪声那你觉得记忆多了是帮助还是负担这一下又把问题拉回到了记忆的核心矛盾记忆不是存得越多越好越精准才越好。Agent的记忆系统设计本质上是在回答三个问题什么该记、什么时候记、什么时候忘。这三个问题对应三种不同的存储机制。很多人只做了记完全没设计忘和取最后系统就像一间堆满杂物的房间找东西比没东西还难。4.1 工作记忆会话内的上下文折叠策略工作记忆是Agent在当前任务或当前会话内的短期存储对应人类的正在手头处理的事情。它和技术上的上下文窗口Context Window直接相关但不等于上下文窗口——窗口是大模型能看到的全部信息的上限工作记忆是Agent在每轮主动挑选并维持的有用信息集合。我在第三节提过三个区的设计这里展开说。核心区要有硬性的长度上限比如固定几百字装的是用户目标、硬性约束、关键进度。工作区存当前正在执行的子任务的中间结果长度可以灵活但也要设置上限。归档区是摘要集中营每条摘要必须控制在几十字以内。这套策略的核心目的是保证模型每一轮决策时核心决策信息始终在注意力的黄金位置。实验数据也很能说明问题同样一个多步骤任务使用上下文折叠策略的Agent比全量堆叠上下文的Agent任务完成率提高了接近两成响应延迟也明显降低。折叠不是偷懒是刻意制造信息稀缺让模型不得不聚焦在最关键的信号上。折叠策略的设计细节也有讲究。折叠动作不是每轮都做而是只有在新信息要写进核心区、核心区空间不足时才触发。折叠的对象是当前最不相关的已完成子任务的完整过程折叠产物是一条结构化摘要。折叠之前系统会把被折叠的原始内容先写入长期记忆存储避免重要信息丢失。4.2 长期记忆向量检索召回率不是越高越好长期记忆解决的是跨会话、跨任务的经验沉淀。现在主流方案是把重要信息向量化存进向量数据库需要时做相似度召回。但这里有一个反直觉的点召回率不是越高越好。召回五十条信息让模型从中挑不如召回精挑细选的五条让模型直接用。信息召回的本质是引入决策依据不是提供可选阅读材料。长期记忆的写入时机比检索方法更值得花心思。我的策略是只有三类信息允许写入长期记忆。第一类是用户明确表达过的偏好比如我订酒店从来不要低楼层第二类是任务结果里被验证为成功或失败的关键经验比如上次用这个接口超时了三次第三类是用户画像类信息比如身份、常驻地、常用支付方式。其他对话内容一律不写入。写入前还有一道过滤关卡模型先对候选信息做一次结构化抽取输出主体属性取值置信度置信度低于阈值就丢弃。这套过滤机制能有效防止把闲聊内容当成偏好存入长期记忆。比如用户说这家店真难吃不应该存成用户认为这家店难吃而应该提取为用户偏好避开该餐厅或者干脆不存因为单次情绪化表达不足以形成稳定偏好。检索侧的技巧是给每条记忆打上元数据标签记忆类型、创建时间、最近访问时间、来源任务ID。召回时可以叠加时间衰减权重和类型过滤比如当前任务是订酒店只从偏好类记忆中召回。这种过滤能让召回命中率大幅提升——把一百条同类型记忆塞给模型和只给十条高度相关的记忆决策质量完全不是一个级别。4.3 遗忘机制为什么说会忘比会记更高级最后说遗忘。这可能是Agent记忆设计里最不受重视、却又最影响体验的环节。很多人设计记忆系统只想着怎么记从没想过怎么删。但真实用户是变化的一个用户去年喜欢重口味川菜今年开始健身饮食清淡一个用户三年前喜欢某个明星现在早就脱粉了。如果Agent把过时的偏好一直当作决策依据体验会越做越差。我的做法是给每条长期记忆一个保质期和刷新机制。保质期按记忆类型设定用户画像类最长偏好类中等临时经验类最短。每次成功使用一条记忆系统自动延长它的有效期如果在有效期内从未被使用到期后先降级为低置信度记忆检索权重降低连续两个周期未使用就直接删除。这种机制背后有一个朴素的信念Agent应该像一个人一样既记得住重要的事也放得下过时的事。一个人的记忆如果从不遗忘反而会形成思维定式。我在项目里专门设计了一个记忆矛盾检测步骤如果用户新的表述和长期记忆里的旧偏好冲突系统不直接覆盖而是标记为待确认冲突在下一轮对话里温和地跟用户核对。这个方法很笨但实测效果比盲目相信记忆库好很多——因为用户会因为你记得他而惊喜也会因为你记错了他而失望这两个体验的差距直接决定了一个Agent能用多久。5. 拿得出手的实战一个可直接复刻的最小Agent设计与跑通记录前面聊了这么多理论和设计原则可能有些读者已经有点飘了觉得Agent不过如此。但面试官从来不会因为你会说而满意他一定会追问那你现场写一个给我看看第五轮面试面试官的原话是从零开始设计一个面向客服场景的售后处理Agent只给三十分钟你会怎么搭既能演示又不会有大量BUG的完整流程这个要求其实很考验基本功。你在纸上写一堆漂亮的设计图没有用得能落成运行起来的代码。下面我把当时的搭建思路和核心步骤完整复现一遍你照着走也能跑出一个能演示的最小Agent。5.1 需求收敛第一件事不是写代码而是砍需求接到售后处理Agent这个命题的时候我做的第一件事是先砍范围。三十分钟能演示的Agent绝对不能做成全品类全场景智能客服否则光意图识别模型就要选半天。我把需求收敛成了三个主流程查单、改地址、退款申请。覆盖了查询类、操作类、高风险类三种典型Agent动作足够演示但也足够简单。砍需求的原则是先证明主循环能跑通再考虑业务复杂度。你能在十分钟内让Agent完整走一遍用户提问→规划→调用工具→格式化结果→回复这个闭环的价值比堆一百个功能点大得多。业务场景可以后续慢慢扩展主循环是灵魂必须先立住。接下来定义工具集。查单需要一个订单查询函数输入订单号输出订单状态改地址需要一个更简单的模拟工具只做参数校验并返回成功或失败退款申请同理想做成模拟工具。工具数量控制在三个以内既能体现多工具协同又不会让演示时手忙脚乱。每个工具都配上JSON Schema格式的入参定义方便模型生成结构化调用参数。5.2 核心主循环Python代码骨架与执行流程架构上我只用一个Python文件不引入重型Agent框架把主循环写得清清楚楚。模型的角色只有一个根据当前状态和工具描述决定调用哪个工具或者直接回复用户。下面是核心代码骨架我简化了错误处理让逻辑更清晰import json from typing import Dict, List # 伪代码以任意支持function calling的大模型接口为例 # llm_chat_with_tools(messages, tools) - response TOOLS [ { name: query_order, description: 根据订单号查询订单状态、物流信息、商品清单, parameters: { type: object, properties: { order_id: {type: string, description: 用户提供的订单号} }, required: [order_id] } }, { name: modify_address, description: 修改未发货订单的收货地址。发货后不可修改, parameters: { type: object, properties: { order_id: {type: string}, new_address: {type: string} }, required: [order_id, new_address] } }, { name: apply_refund, description: 为订单发起退款申请。退款金额由系统根据订单状态计算, parameters: { type: object, properties: { order_id: {type: string}, reason: {type: string} }, required: [order_id, reason] } } ] def run_agent(user_message: str) - str: messages [ {role: system, content: 你是售后处理助手。请严格按工具描述执行用户请求。 如果需要额外信息直接向用户提问不要编造订单数据。}, {role: user, content: user_message} ] max_steps 10 for step in range(max_steps): response llm_chat_with_tools(messages, TOOLS) # 情形一模型决定调用工具 if response.get(tool_calls): for call in response[tool_calls]: result execute_tool(call[name], json.loads(call[arguments])) messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) continue # 情形二模型直接回复用户 return response[content] return 处理超时请稍后重试或联系人工客服 def execute_tool(name: str, arguments: Dict) - Dict: if name query_order: return query_order(arguments[order_id]) if name modify_address: return modify_address(arguments[order_id], arguments[new_address]) if name apply_refund: return apply_refund(arguments[order_id], arguments[reason]) return {error: unknown tool}这段代码麻雀虽小五脏俱全System Prompt定义了行为边界TOOLS注册了工具元信息主循环让模型自己决定调工具还是回复用户工具返回作为新消息追加到上下文中。实际演示时我会准备三条测试路径。路径一是直接查单帮我看看订单20240601到哪了模型应调用query_order并返回物流信息。路径二是改地址订单20240602的收货地址改成某某路某号模型应调用modify_address。路径三是个陷阱场景我要退款但没有给订单号——好的Agent应该反问要订单号而不是编一个假单号去调apply_refund。这三条路径能覆盖主循环的基本形态已经足够应对三十分钟的演示。5.3 跑通后的三轮自问边界、容错、成本代码能跑通只是第一步面试官通常会继续追问三个深度问题。第一问你的Agent边界在哪比如用户说我要骂人模型是会乖乖接话还是礼貌拒绝如果用户问你能帮我写周报吗你一个售后Agent会不会跑去做文档任务这是System Prompt和工具集共同决定的没有对应工具的任务模型应该回复不在我的处理范围内而不是用大模型通用能力硬接。我在System Prompt里特意加了一条仅处理与订单售后服务相关的任务其他请求一律拒绝。第二问工具调用失败怎么容错比如modify_address被调用时参数里没有new_address或者订单已发货不能修改。我在execute_tool里做了兜底返回错误信息会以JSON形式回到上下文。模型看到错误信息后应该能主动判断需要补充信息或告知用户无法修改。这个应对逻辑不用写死在代码里靠模型自然推理就能完成但要保证错误信息是结构化、可解析的不要让模型在垃圾文本里捞线索。第三问一次任务的成本大概多少这是所有Agent上生产前都必须算的账。每次主循环都是一次模型调用一次复杂任务可能循环五到十次。如果用的是商业大模型API按token计费一次售后任务可能消耗几千甚至上万token。所以在演示版里我故意把max_steps设成了10既是防死循环也是在暗示面试官成本控制靠的不是模型而是主循环的退出条件设计。支持用户提供完备信息、工具返回高质量结果、减少无效循环这三个方向的优化空间比换低价模型大得多。我后来在真实项目里对这套最小骨架做了扩展加上了任务状态记录、工具结果缓存、失败重规划分支整体架构没有变但稳定性上了好几个台阶。先跑通主循环再逐步加护栏这是Agent项目最稳妥的推进路径。你不需要一上来就上Agent框架也不需要对标那些复杂的生产级中间件一个文件加上清晰的主循环足够你理解Agent的全部核心机制。6. 复盘那次面试之后我总结出的Agent设计铁律面试结束之后我把整个过程又完整回顾了好几遍。有些道理是当时面试官直接点醒我的有些是后来在实践中摔了跟头才明白的。这些东西不一定写在任何技术文档里但它们决定了一个Agent系统是能站起来还是能跑起来。作为最后一部分我直接分享几条个人总结的设计铁律。6.1 Agent的灵魂在反馈闭环里不在模型参数里很多人以为Agent的灵魂在大模型的参数量、在推理能力、在prompt技巧上。我的结论和面试官高度一致Agent的灵魂在反馈闭环的完整性上。一个Agent系统可以拆成五个节点目标设定、状态感知、规划决策、行动执行、反馈吸收。参数量只是行动执行这一环的底座而多数人会把精力全砸在这一环上——换更大的模型、调更长的上下文、写更花哨的prompt。但真正让Agent显得有灵性的是反馈吸收这个环节做得好不好工具返回的结果有没有被正确解析状态有没有被及时更新失败有没有触发反思这些链路如果不闭合模型参数再大也只是个更聪明的ChatBot。放一个具体例子。我做过一个测试同一个任务一套系统每次工具返回后都做结构化摘要另一套系统把原始结果直接塞上下文。前者的任务完成率高出接近三成。同一个模型、同一个Prompt差异只在反馈吸收这一步。这个实验很朴素但说服力极强——优化Agent优先优化信息流转而不是优化模型。6.2 评估Agent要看最差表现而不是平均表现第二条铁律关于评估。Agent系统的平均表现很容易做得好看因为大多数任务会落在常见路径上模型正常推理就能通过。但一个Agent能不能上生产看的是极端情况下的表现用户乱给参数、工具接口返回超时、上下文里混入干扰信息、多步操作在第三步失败……这些场景才是Agent系统的短板所在。我现在的习惯是维护一份刁钻测试集专门收录真实环境中出现过的异常输入。每改一版Agent先用这套测试集跑一遍把失败case按根因分类是工具描述不清晰、是上下文管理不到位、还是规划策略有问题。修的时候也是按根因修而不是打补丁式地给Prompt加规则。评估Agent不仅要问它能不能做对更要问它能不能知道自己错了。把自己放到Agent的位置上想你会更清楚哪里还不够稳。一个知道自己错了、能主动澄清、能换一种方法继续尝试的Agent比一个90%场景表现优秀但10%场景沉默乱来的Agent更值得信任。这也是面试官反复强调的可靠优先于聪明。6.3 给正在入门Agent的朋友们三个行动建议最后如果你正在入门Agent我给你三条直接可执行的建议都是我当初走了弯路之后总结的。第一条亲手写一个不带框架的最小主循环。不要一上来就上那些流行的Agent框架因为框架帮你隐藏了大量关键机制你用它跑通了Demo但不知道哪里是灵魂。花一个周末写一个像我上面演示的最小Agent一个文件、三个工具、一个循环。这个过程的收获比读十篇框架文档都大。第二条给Agent写思考日志。生产环境里把每一轮的Thought、Action、Observation都记录下来不仅是调试利器更是后续优化的第一手素材。我至少三次在思考日志里发现性能问题的根因而这些根因在最终答案里根本看不出来。第三条每做一个Agent先定义它不该做什么。能力边界比能力本身更重要。写系统提示词时先写绝对禁止清单再写应该做什么。这个顺序颠倒了Agent的确定性就很难保证。如果你已经看到了这里说明你对Agent是真的有兴趣。那就用我这套思路去拆解你手头的项目先从最小主循环开始把反馈闭环做完整把记忆的取舍和遗忘机制设计好。等这些核心模块真正内化了再回头看看那些花哨的框架和论文你会有一种原来它们只是在给这几个铁律包壳的通透感。那时候你就算真正看懂Agent的灵魂了。