1. 为什么普通聊天机器人做不了英语陪练得靠Agent先说个背景。我最初的想法很简单想做个英语情景对话练习工具让AI扮演酒店前台、机场安检员、咖啡店员像真实场景一样跟我对话。谁不想有个随叫随到的口语陪练呢。但试过几个方案之后我很快就发现了问题。直接用大模型API套一层Prompt写“你现在是一个酒店前台请和用户进行英语对话练习”效果非常差。差在哪里几个典型表现模型为了“照顾”用户情绪会主动降低难度用户说一句“I want a room”它马上切换到简单模式全程只用初中词汇迁就你。它只会顺着对话走用户说错的地方不纠正或者纠正了但没有解释说完就完了。对话进行到第五轮之后模型开始忘记之前聊过的内容比如用户第一轮说“I prefer a room with a view”聊到后面要订带景观的房间模型已经完全不记得了。用户其实是想练某个具体主题比如“在餐厅点餐”模型却经常聊着聊着就飘逸到经济舱、旅游攻略、天气去了。说白了普通的“Prompt 模型调用”是一个问答系统而不是一个按照教学目标推进的陪练系统。它既没有明确的任务目标也没有状态管理和纠错机制更没有针对学习者水平动态调整难度的能力。你让一个聊天机器人陪练它只会“陪聊”不会“教学”。所以我决定换一条路做成一个真正的Agent。这个Agent的核心不是“聊天”而是在一个情景任务里跟用户完成多轮交互并且在这个过程中持续做三件事识别用户的表达错误、评估用户的沟通效果、控制对话的节奏和难度。这就不是单次Prompt能搞定的了需要规划、工具调用、记忆、反思评估这些完整能力。可能有人会问这跟“套一层壳的智能对话机器人”到底区别在哪一句话总结普通对话模型是被动应答Agent是主动规划的。它会把“完成一次酒店预订对话”这个大目标拆成“询问需求”、“获取信息”、“确认订单”、“处理意外情况”这些子任务每一步都知道自己在哪个阶段、接下来该引导用户说什么、用户说错了该怎么反馈。我一开始也是在“分享一个英语AI项目”和“从零到一搭建一个Agent”这两个角度之间犹豫过。后来发现没必要割裂因为做英语情景教学Agent本身就是一条特别适合练手Agent开发的路——场景足够垂直、状态管理足够复杂、评估机制足够明确做完这个项目你对Agent的理解会提升一大截。这篇文章就按我实际开发的过程来写从架构选型、情景库设计、记忆系统实现、主链路开发到最后排坑完整走一遍。2. 架构与选型决定用“规划器 工具”思路而不是大模型一把梭2.1 先分清“Agent框架”和“Agent模式”开工前我花了不少时间调研主流的Agent开发方式也看了很多网上的讨论。目前主流路线大致分两类一类是直接在大模型能力之上手写Agent逻辑比如手写ReAct循环自己管理上下文、调用工具、解析输出另一类是直接用Agent框架比如LangGraph、AutoGen、CrewAI、MetaGPT这些框架帮你处理状态流转和工具调用的编排。就这个话题网上讨论很多有人推荐LangGraph说它灵活有人推荐AutoGen说它对话驱动适合多角色场景还有人说初学者先用轻量方案手写一个ReAct就够了。我都试了一圈说说我的感受。LangGraph确实灵活它的核心思想是把Agent的每一步都定义成图里的一个节点节点之间通过状态传递数据切换逻辑清晰可控。但问题是对初学者来说它的概念有点多节点、边、状态Schema、条件边、Checkpointer……一上来容易迷。AutoGen的特点是让两个Agent互相聊解决复杂任务但英语情景教学这种场景不需要两个AI互相辩论有点杀鸡用牛刀。MetaGPT主打软件开发团队协作跟教学场景差得更远。所以最终我决定不套任何重量级框架自己写一个轻量的“规划器 工具”结构。原因很简单这个Agent的决策链路没有复杂到需要图引擎。核心链路就是“理解输入 - 决定要不要检索 - 调用记忆和评估工具 - 生成回复”。这个链路由主程序顺序控制就够了。自己写能看清每一步发生了什么排查问题方便。用框架封装得太好报错时往往得翻框架源码。教学场景的“规划”核心是对话状态管理而不是任务分解成多步执行。我用一个状态机就能管理不需要复杂的DAG编排。2.2 整体架构长什么样我先画一下这个Agent的最终架构虽然是轻量实现但五脏俱全入口用户的语音或文字输入。规划器决定当前轮次的行为。判断是“继续情景对话”“修正用户错误”“切换难度”还是“结束情景”。工具集合三个核心工具——情景检索工具、记忆读写工具、表达评估工具。状态存储短期对话状态、长期学习者档案、永久能力画像。大模型负责生成自然语言回复但它的输出被约束在规划器决定的任务范围内。用一句话概括规划器是大脑大模型是嘴工具是手和眼。2.3 状态机的状态定义情景对话和自由聊天最大的不同是它必须有阶段。酒店入住check-in的对话流程正常情况下是问候 - 确认预订信息 - 办理入住可能需要押金/信用卡 - 介绍酒店设施 - 结束。如果用户在前台说“I lost my passport”这属于意外情况Agent需要有专门的应对路径而不是把它当成正常check-in流程继续走。所以状态机我定义了五种状态GREETING对话开场Agent打招呼引导用户说明来意。INFO_COLLECTING收集完成情景任务所需的信息。CONFIRMING确认信息、感慨确认动作。HANDLING_EXCEPTION处理用户的异常请求。CLOSING收尾、总结本次练习、给反馈。每个状态下Agent要说什么、接住什么样的话题都由状态机约束。这样就不会出现用户说“I dont have a reservation”时Agent还在自顾自地介绍健身房开放时间这种智障回复。这部分的经验是不要试图让大模型自己决定“下一步该干什么”。在垂直场景里流程是相对固定的你把它写死成状态流转比让模型自由发挥要稳得多。大模型的角色是“在给定的状态下生成合适的表达”而不是“设计整个对话的走向”。3. 情景库设计Agent好不好用七成看素材库3.1 情景库的元数据结构这个环节很多人会忽略。大家以为Agent最重要的是模型和编排逻辑但我做完之后发现在英语情景教学这个场景真正决定学习效果的是情景库本身的质量和结构。一个情景要能支撑Agent的教学行为它不能只是一个“人名 场景描述”得有结构化的引导信息。我给每个情景定义了这样一组字段情景ID唯一标识。主题类别酒店入住、餐厅点餐、机场值机、购物退换、看病问诊等。这个决定了情景库的索引维度。预设角色Agent扮演的角色以及对应的背景人设。目标语言点这个情景想训练的重点表达比如“礼貌请求”“描述问题”“表达偏好”。常用表达列表该情景下最常出现的句式比如check-in会涉及“I have a reservation under...”、“Could I see your passport, please?”。高频词汇情景绑定的词汇集合比如“deposit”“amenities”“boarding pass”这些。常见错误列表这个情景下中国学习者容易犯的典型错误。意外事件列表用于触发HANDLING_EXCEPTION状态比如“护照丢了”“航班取消了”“食物过敏”等。这个设计解决了一个核心问题Agent不再靠“幻觉”去扮演角色而是有据可依地调用情景数据来生成对话。比如在“餐厅点餐”情景里用户说“I want a beef”Agent通过情景库能判断出这里缺少了礼貌表达“Id like...”这就是一个可纠正的语言点。没有情景库模型根本不会意识到用户是在练“礼貌点餐”这个语言点它只以为用户在陈述一个事实。3.2 混合检索向量检索加关键词召回的务实组合情景库做大了以后会遇到一个实际问题用户说“我想练一下预订酒店的对话”Agent怎么找到对应情景直接向量检索是一种方案但实测下来单纯靠向量检索会有问题。用户表达很口语化比如“我想练练出去旅游住酒店怎么说”向量检索可能召回一堆“旅游推荐”“景点介绍”这类不相干的内容因为“旅游”和“酒店”在语义上确实相关但用户真正想要的是“酒店预订对话”。我在这个项目里用的是混合检索方案两路召回再加结果重排第一路关键词精确匹配。用户输入里的“酒店”“餐厅”“机场”“医院”这些词先跟情景库的功能标签做字符匹配精确命中优先。第二路向量语义召回。用Embedding模型把用户输入转成向量跟情景库里的“主题描述”字段做相似度检索。最后合并打分。精确命中给一个较高的基础分向量相似度作为加分项最终排序取Top 1。这套方案在实测中比只用向量检索靠谱很多。因为用户描述情景的时候往往带有关键的功能性词汇这些词在Embedding空间里不一定能精准反映意图但字符匹配一定能锁定。比如“我想练一下机场值机”无论怎么向量化“机场”这个词都不会和“餐厅”搞混。3.3 英语能力等级与情景难度的映射还有一个必须想清楚的设计同一个情景对初学者和advanced学习者教学目标应该不一样。刚开始我偷懒每个情景只做了一套内容。结果一个四级水平的用户和一个雅思7分的用户上来练“酒店入住”前者还在学“I need a room”后者已经在聊特殊需求和无障碍设施了。同样的内容对一方太简单对另一方太没挑战。所以我在情景库结构里加了两个字段难度等级A1-C2和难度增强指令。检索时根据学习者的能力等级选择对应难度的情景配置。具体做法是每个情景内置三档素材——基础表达、进阶表达、高阶表达。基础表达是完成情景任务的必要句式进阶表达是更地道、更复杂的说法高阶表达涉及特殊情况处理和复杂交际策略。Agent初始化时会读取学习者的等级只加载对应档位的内容。等级越高模型被允许使用的句式越复杂纠错时也更侧重语用层面的问题而不只是语法。4. 记忆系统三层记忆让Agent记住你的每一处错误4.1 为什么要单独设计记忆模块做过Agent的人都知道大模型的上下文窗口再大它也是“一次会话一个世界”。上一轮你说“I prefer vegetarian food”这一轮你问“What do you recommend?”模型很可能忘了你是素食者。在自由聊天里这个缺陷还可以忍受但在教学场景里用户会觉得这个老师非常不专业。解决办法就是外部记忆。我在项目里实现了三层记忆架构对应热词里常提的“记忆中短期、长期、永久记忆如何实现”这个问题。这个项目的分层方式是这样的短期工作记忆存当前对话轮次里的临时信息比如用户本轮说了什么、刚才被纠正了哪个错误、还没完成的目标是什么。长期学习者档案存用户跨会话的学习数据包括已练过的情景、常犯的错误、掌握的语言点、等级变化。永久能力画像存用户的长期能力评分和偏好设置几乎不变化类似于“学籍档案”。三者用不同的存储策略。短期工作记忆直接放在内存里用Context对象管理会话结束即清空。长期档案用JSON文件持久化每次会话结束后更新。永久画像单独存放只有等级变动时才修改。4.2 记忆的读和写记忆模块对Agent来说是一个工具而不是模型的“潜意识”。在每次Agent生成回复之前主程序会把相关的记忆内容“注入”到Prompt上下文里每次对话结束后主程序会调用记忆写入工具把本次会话产生的信息更新到档案里。这里有个很关键的实操细节记忆注入不是越多越好。我一开始把所有历史错误全部塞进Prompt结果上下文直接爆炸不说模型还会被旧信息干扰回复里总想“复习”之前的内容影响当前对话的流畅度。后来我定了一个原则短期记忆只保留当前对话状态长期记忆只注入当前情景相关的部分。比如用户之前练过“点餐”情景“餐厅点餐”这个标签下存了“混淆soup和soap”的记录那么他下次练同一个情景时才注入这条记忆练“机场值机”时就不注入。这个按主题切分的记忆读取方式既保证了相关性又控制了上下文长度。4.3 用JSON还是用数据库数据量小的时候我建议直接上JSON文件别急着上数据库。Agent项目的初期数据结构是变动的你很难保证今天想记录的一个字段明天不会被重构。JSON文件改起来成本最低一个dict加一层键盘即可。等积累了上千个学习者档案再迁移到SQLite也不迟JSON导出导入都很方便。我这边学习者档案的Schema大致长这样{ learner_id: u_001, level: B1, preferences: { focus_areas: [fluency, pronunciation], scenario_history: [hotel_checkin, restaurant_order] }, language_points: { mastered: [asking_for_directions, polite_requests], needs_review: [conditionals, modal_verbs], error_patterns: [ { error: I am agree, correct: I agree, frequency: 3, last_seen: 2024-06-18 } ] } }这套结构虽然简单但已经能支撑Agent做不少智能行为看到needs_review里有“conditionals”那这次情景如果在介绍酒店设施时涉及条件句Agent就会顺势多抛一个相关练习看到error_patterns里“I am agree”出现了三次Agent会在会话结束时主动安排一次针对性复习。5. Agent主链路开发从用户输入到教学回复的完整旅程5.1 主循环的最简实现这个Agent的核心执行逻辑其实就是一个循环。我把它拆成了五个阶段接收输入拿到用户的文本或语音转写后的文本。状态识别用规则加模型判断当前对话处于哪个状态是继续收集信息还是该纠正错误还是已经可以收尾。工具调用根据状态判断需要哪些工具包括去情景库查内容、写记忆、查历史错误。生成回复把状态、工具结果、相关记忆拼装成Prompt让大模型生成自然语言回复。更新状态根据模型输出和用户输入更新短期工作记忆。如果是会话结束再更新长期档案。这里最核心的技巧是把“评估用户表达”这一步拆出来用独立的工具做而不是让模型在生成回复的同时顺便评估。因为“教学反馈”和“情景对话”这两个任务在同一个Prompt里让模型做模型往往会牺牲其中一个——要么只顾着纠正错误把对话搞得很生硬要么只顾着对话流畅把纠错完全忽略。我的做法是双步推理第一步先单独调用“表达评估器”让它只负责一件事找出用户本轮英文表达里的错误和不自然之处。第二步把评估结果和情景目标一起交给生成模型让它决定“这轮以对话推进为主还是需要穿插一个简短纠正”。这样做之后反馈质量和对话流畅度都上了一个台阶。5.2 工具函数把Agent的“能力圈”清晰地暴露给模型在轻量实现里“工具”就是一组普通函数函数名和功能描述通过JSON列表传给大模型模型根据任务需要决定调用哪个。我给你看一下我核心代码的结构不算复杂但能说明问题。import json from typing import Dict, Any # 工具注册表 TOOL_DESCRIPTIONS [ { type: function, function: { name: query_scenario_knowledge, description: 根据当前情景和用户输入检索该情景下的常用表达、词汇、常见错误和意外事件。, parameters: { type: object, properties: { scenario: {type: string, description: 当前情景ID}, user_within_scene: {type: string, description: 用户在当前情景内的原话} }, required: [scenario, user_within_scene] } } }, { type: function, function: { name: evaluate_expression, description: 评估用户的一句英文表达返回错误类型、原因和纠正建议。, parameters: { type: object, properties: { learner_utterance: {type: string, description: 用户英文原句} }, required: [learner_utterance] } } }, { type: function, function: { name: read_memory, description: 读取当前学习者与当前情景相关的历史错误和已掌握语言点。, parameters: { type: object, properties: { scenario: {type: string, description: 当前情景ID} }, required: [scenario] } } } ]实际执行时主循环先根据模型返回的tool_calls参数决定调用哪些函数然后把函数返回结果拼进下一轮Prompt。这个模式跟OpenAI的Function Calling机制一致换成ReAct模式的思考-行动-观察循环也一样本质都是“模型决定调用什么 - 程序执行真实动作 - 结果回填给模型”。5.3 Prompt模板的组装艺术工具写好了怎么把模型调用顺滑地跑起来又是一个问题。我踩了不少坑之后确定了下面这个Prompt模板结构分为四块任务背景你是英语情景教学Agent你的任务是带领学习者完成一个具体的现实情景对话。当前状态当前处于“信息收集阶段”你正在确认用户的入住日期。情景知识这部分直接填入从情景库检索到的常用表达、高频词、意外事件列表。学习者记忆这里填入当前情景相关的历史错误记录。用户输入用户本轮说的一句话。这个结构的好处是每一块信息的边界清楚模型不用在长上下文里自己翻找“我现在该干嘛”。实际效果很直观模型的角色稳定性明显提高了不会突然从英语老师变成闲聊助手。还有一个很多人忽视的细节在Prompt里明确告诉模型“不要一次性纠正超过两个错误”。这是从真实教学经验里来的一长段回复里密密麻麻全是纠错学习者会崩溃对自信心打击很大。把“纠正数量限制”写在Prompt里等于把教学法直接编码进了Agent的行为。5.4 状态机的流转怎么跟模型结果联动状态机的跳转我最初也想“让模型自己判断”后来发现还是得半自动。具体做法是模型输出里带一个结构化字段标明本轮建议跳转到哪个状态。主程序收到后会根据规则校验这个跳转是否合法。为什么要校验因为模型可能过早建议“结束情景”。比如用户在办理入住时忘了说押金的事模型觉得信息收集得差不多了想直接跳到CLOSING。这时候规则会把它拦住因为当前情景的必备信息不完整不允许结束。这个“必备清单”就定义在情景库里每个情景都有一条完成条件列表。比如说“酒店入住”情景的完成条件是确认了预订人姓名、确认了入住和退房日期、确认了支付方式。哪怕模型觉得用户已经掌握得不错了只要这些信息没收集齐状态机就会停在CONFIRMING或INFO_COLLECTING。这保证了练习的系统性不会“半途而废”。6. 实测中的坑与完整排查链路Agent执行终止、上下文膨胀和输出解析失败6.1 踩坑一Agent执行中途终止没有任何有效输出这个坑是很多初学者第一次跑Agent时遇到的网上也经常能看到“agent execution terminated due to error”这类报错。我一开始跑通主循环的时候也遇到了而且第一次看到这个错误时我整个人是蒙的因为日志里根本没有说具体是哪一行代码出了问题。排查的完整过程是这样的先查输入输出。我把这一轮用户输入和上一轮模型输出打印出来看是不是模型输出里带了合法的tool_calls参数。看了之后发现模型在上一轮返回了工具调用请求但在“工具执行 - 回填模型”这一步工具返回的结果格式是纯文本里面含有换行符和特殊字符。问题出在这里我写的是轻量手写Agent自己解析模型输出的JSON。标准的json.loads在面对嵌套在文本里的JSON对象时很容易失败因为模型返回的格式可能不完全是标准的JSON可能有前后缀字符。解决办法不直接对模型输出做json.loads而是先做一层“提取JSON”的预处理把{...}之间的内容用正则抽出来再做解析。这样即使模型回复里夹带了自然语言也能稳定提取工具调用参数。这个坑本质上是你自己手写Agent解析逻辑的时候不能默认模型一定会输出标准JSON。兼容性处理是必须的。6.2 踩坑二上下文膨胀导致模型“忘事”第二个坑更隐蔽。我一开始为了方便把整个会话的所有历史消息一股脑全部传给模型想着“反正上下文窗口够大”。结果跑了十几轮之后模型反而开始忘记前面说过的内容——不是因为它真的忘了而是因为上下文里塞了大量的工具返回结果、检索到的情景知识、历史记忆这些“噪声”把真正关键的信息比如用户刚才说过自己是对某种食物过敏给淹没了。排查链路我把传给模型的完整Prompt记录下来用Token计数器统计大小。发现跑到第20轮的时候单轮Prompt已经到2万多Token。检查这2万多Token里有多少是重复性的工具返回结果。结果发现每次调用query_scenario_knowledge都会把整个情景的常用表达列表塞进去这些内容十几轮之前已经给过模型一次了后面每轮再给一遍纯属浪费。解决办法是双管齐下工具返回结果只保留当前轮次需要的部分历史对话消息做窗口裁剪只保留最近六轮对话更早的信息要么已写入记忆要么直接丢弃。在记忆里加一层“去重”逻辑同一个情景的知识如果已经在本会话注入过下一次不再重复注入除非用户切换了话题。实测做完整改之后Prompt稳定在4000到5000 Token区间模型的回复质量和关键信息记忆力都恢复了。教训就是上下文窗口不是越大越好信息密度才是决定模型效果的关键。6.3 踩坑三表达评估工具输出不稳定把“没问题”误判成“有错误”第三个坑是评估工具本身。我用大模型做错误反馈但它偶尔会把“用户本来就说得对”的句子标注成错误。这个在技术上叫“误报”在教育场景里是大忌——明明没说错你却纠正了学习者会非常困惑甚至开始怀疑自己的英语。排查链路首先我把评估工具的Prompt单独拿出来看。发现里面只写了“找出错误并纠正”没有告诉模型“如果没有错误就明确说没有错误”。更深层的问题在于模型默认情况下有“纠错倾向”。你说“评估这句话”它就倾向于找点东西出来哪怕只是“不够地道”这种非常主观的判断也会当成错误反馈。我的解决办法是给评估工具增加一层“置信度门槛”要求模型首先要判断“该表达是否会影响沟通”如果影响沟通再判定为错误。如果只是风格偏好不算错误可以记为“优化建议”但优先级低于错误。模型必须输出一个severity字段取值是error、suggestion、ok三者之一。程序侧再做一层校验如果severity为error但没有任何具体的纠正建议就自动降级为suggestion。这套机制上线之后误报率明显下降。核心思路其实就是不要让大模型直接决定“是不是错”而是让它先给出判断依据再由规则层把关。这是Agent开发里很有用的一个思路——模型负责理解规则负责裁决。6.4 踩坑四学习者等级提升后Agent还在用旧反馈方式最后一个坑属于产品逻辑层面的。当学习者的等级从B1提升到B2之后Agent的反馈方式没有跟着变还在用B1阶段的方式——大段大段解释基础语法。学习者明显觉得不耐烦了说“我知道这个语法别讲了”。排查链路我先去看等级变动逻辑发现等级提升后只在“永久画像”里更新了字段但Prompt模板里的“反馈风格”段没有跟着切换。问题根因反馈风格和等级绑定在初始化时一次性注入整个会话期间不会重新读取。解决办法不是每次会话开始时读等级而是在每次生成回复之前都动态读取一次。如果检测到等级变化就重新触发生成Prompt。这个坑提醒了我Agent的状态不能只在前端UI上更新模型实际拿到的上下文才是影响行为的真正变量。前端显示“B2级别”没意义Prompt里的反馈策略如果不是B2的那这个等级就是摆设。7. 进阶优化从单Agent到多Agent协作还差多远做到这一步这个英语情景教学Agent其实已经能稳定跑起来了。但网上关于“多Agent协作”“Agent框架与编排”的讨论非常多我也在想这个项目要不要升级成多Agent结构。我的结论是在当前阶段单Agent加工具是这个场景最合适的选择。道理很简单——多Agent协作的收益来自任务分解和角色隔离但如果你的任务本身就不需要多个角色视角硬拆多Agent只会增加稳定性的负担。Agent之间传消息的格式一旦有分毫差错整个链路都会崩。不过确实有两个方向值得尝试。第一个方向是“教师Agent 评估Agent”的双Agent模式。教师Agent只负责推进对话和维持情景评估Agent在暗处记录用户的错误和表达质量。这样教师Agent的输出不会被“纠错”任务污染对话会更自然。评估Agent在每轮对话后异步生成反馈在适当的时候由教师Agent决定是否抛出。这个设计比我现在的“先评估后决策”模式更进一步代价是需要管理两个Agent的通信和状态同步。第二个方向是“角色扮演Agent”和“复盘Agent”的分离。情景练习结束后复盘Agent不参与对话而是综合分析整个会话的学习数据生成一份详细的学习报告包括错误分布、流利度变化、词汇丰富度、建议的下一次练习方向。这个复盘Agent可以做成一个独立的异步任务完全不占用用户和教师Agent之间的练习时间。这两个方向都需要引入一个轻量级的消息总线来协调Agent之间的通信也就到了该考虑上LangGraph或者自己写一个编排引擎的时候了。但如果你也打算从零开始做一个类似的Agent我的建议是先别想多Agent的事把单Agent的工具、记忆、状态机做到稳定再谈编排。地基不稳盖再多楼层都是白搭。8. 最后补充两点我觉得很值钱的细节先说记忆系统的操作技巧。学习档案的更新我是在每次对话结束后统一做的而不是每轮对话实时写几十次文件。一小时的练习大概会触发一两次档案更新读写成本可以忽略不计。但如果你的Agent跑在Serverless环境上函数实例随时可能被冻结我建议改成每轮对话结束都做一次增量更新防止实例销毁导致数据丢失。再说说测试方法。Agent开发跟普通后端开发最大的不同是你不能只测“正常流程”和“错误流程”还要测“对话里的意外”。我的做法是准备了一个测试脚本内置了十几个刁难用户的输入比如用户故意不回答、用户突然切换话题、用户用中文反问你“啥意思”。这些输入在普通后端测试里根本不是有效测试用例但在Agent开发里你必须确保模型在遇到这些情况时不崩不跳出教学语境不产生幻觉。总的来说这个项目让我最深刻的体会就是Agent不是“大模型加了工具调用”它是一套完整的工程系统状态、记忆、工具、反馈策略、异常处理每一块都得单独搭建、单独调优。而英语教学这个场景恰好把这些环节的复杂性都逼了出来。做一遍这个项目市面上Agent面试题里的那些概念你基本都会有实感了。