企业官网建设流程全解析

1. 为什么是英语情景教学Agent：从需求到产品定位

1.1 看似热闹的AI口语产品，其实缺一块拼图

先聊一个我自己的真实经历。前年冬天我试着用市面上的AI口语陪练产品练了两个月英语，每天跟读十分钟。效果确实有，但总觉得哪里不对——练的是"点菜""问路"这种标准对话，一到真实场景，比如同事临时拉我去参加一个英文会议、或者房东打电话来谈维修，脑子还是转不过来。后来我复盘了一下，发现这些产品普遍存在三个问题：一是对话脚本太固定，翻来覆去就那几句；二是AI不会根据我的水平动态调整难度；三是没有真正解决"开口前要想很久"这个核心痛点。

这三件事，恰好是我决定自己做一个英语情景教学Agent的直接动机。市面上不是没有好产品，但它们大多把精力花在语音识别和发音打分上，对"情景"的理解其实很浅。所谓情景教学，关键在于让用户沉浸在一个具体、连续、有目标感的场景里，完成一次真实的沟通任务，而不是机械地念完一段对话。

1.2 这个Agent到底是什么，以及它解决什么问题

我定义的英语情景教学Agent，是一个基于大语言模型、具备多轮对话能力、能动态生成剧情分支、并提供针对性反馈的在线学习系统。它跟传统口语App的区别在于：传统App是"人跟着脚本走"，Agent是"脚本跟着人走"。

具体来说，它要做三件事：

• 模拟一个真实的互动场景，比如机场值机、餐厅投诉、项目汇报、租房谈判；
• 由用户扮演场景中的一个角色，自主决定说什么、怎么接话；
• 会话结束后，Agent针对语法、表达准确性、流畅度和情景契合度给出评价和改进建议。

这个东西最核心的价值，不是替代真人外教，而是解决"练得少"和"不敢说"的问题。它把练口语的门槛从"找个语伴、凑个时间"降到了"打开App就能演一场戏"，而且用户不用担心说错丢面子。

1.3 目标用户与功能边界

我在技术预研阶段先划定了边界，不然这个东西会做成一个没有尽头的怪物。核心目标用户有两类：一是有一定英语基础、想提升口语流利度的职场人；二是备考雅思口语、需要大量情景演练的学生。所以功能重点放在四块：场景引导、角色扮演、实时纠错、学习报告。

不做什么也很重要。我不做语音识别本身，直接调用成熟ASR；我不做复杂的发音音素级打分，只做可懂度层面的判断；我不做真人社交匹配，那是另一个产品形态。把边界划清楚以后，开发路径就清晰多了：核心工作在于剧情引擎和反馈引擎，其余环节尽量复用成熟组件。

2. 技术选型：大模型、框架与整体架构

2.1 模型选择的几个考量维度

Agent的大脑选择，我前后对比了四五款主流大模型。评估维度不是简单的"谁聪明"，而是：指令遵循能力、中文理解能力、多轮稳定性、延迟、成本。因为英语教学Agent的输入可能是中英混杂的——用户可能用中文说"这个场景我应该怎么回答"——所以模型必须兼容中英双语上下文。

选型结论是这样的：主线教学对话用GPT-4o这个级别的大模型最稳，尤其是角色一致性和复杂情景推理；但考虑到成本，我设计了一个双模型路由方案——日常简单轮次走轻量模型，遇到情节转折、深度纠错这种复杂任务再切换到大模型。这个策略实测能把成本压到纯大模型方案的40%左右。

2.2 Agent框架：为什么我最终自己搭了编排层

2024到2025年，市面上出现了大量Agent框架，早期的LangChain、AutoGen、以及更轻量的Dify，甚至字节的Coze。我前期花了整整一周测试这些框架。结论很真实：框架解决的是"通用Agent问题"，而我要做的是"特定教学闭环"，硬套框架反而被它的抽象层绊住。

比如LangChain的记忆管理，对一句话剧情推进这种高频状态切换来说太笨重了。我自己搭了一个极简的事件驱动编排层：用户输入 -> 意图理解 -> 状态更新 -> 剧情生成 -> 反馈判断。整个过程用异步事件流串起来，没有复杂的Chain调用图，调试起来非常清晰。

2.3 Agent的技术栈全景

我最终的技术栈长这样：

这里有一个关键点值得展开：语音链路延迟。用户说一句话到听见AI回应，全链路超过3秒，教学体验就会明显变差。所以ASR必须用流式接口，TTS也选择流式合成，模型推理则通过流式输出配合打字机效果，三路并行把总延迟压到2秒左右。

2.4 为什么用"双对话引擎"而不是单一Prompt

这是我开发到中期踩坑之后做的重构。最开始我把角色扮演、剧情推进、纠错、学习报告全都塞进一个系统Prompt，让大模型自己决定什么时候做什么事。结果就是：角色扮演好好的，突然跳出一段评价；或者用户犯了个语法错误，AI只顾着推进剧情，完全没纠错。

拆开之后变成两个引擎：

• 剧情引擎：只负责沉浸式推进故事，以角色身份回应，永远不说教；
• 反馈引擎：一个人智囊团，独立分析用户说错的部分、应该怎么改、为什么改。

剧情引擎在对话过程中运行，反馈引擎在每轮结尾触发一次轻量判断，并在整场会话结束后输出完整报告。这个拆法让两个任务的Prompt互不干扰，质量直线上升。

3. 情景剧本设计：从静态Prompt到动态剧情引擎

3.1 情景场景库的搭建逻辑

情景剧本是这个Agent的灵魂。我一开始犯的错误是试图让模型"凭空生成场景"——结果生成出来的场景千篇一律，全是餐厅点餐。后来我换了一种做法：人工建立场景骨架，模型在骨架内动态填充血肉。

什么是场景骨架？它包含几个要素：场景名称、用户角色、AI角色、初始目标、核心冲突、可能的发展分支。比如"机场转机延误"这个场景，用户角色是赶转机航班的乘客，AI角色是机场地勤。核心冲突是：原定航班取消，用户必须找到替代方案。

我按照"生活类、职场类、学术类、旅行类"四个大类，人工策划了40个骨架，每个骨架配3-5个可选的"事件触发器"——比如机场场景里，可能触发"突然广播登机口变更""护照信息有误""行李没跟上"等子事件。模型在对话过程中根据用户的反应随机或智能地触发这些事件，这样即使同一个骨架，用户练十次也不会觉得重复。

3.2 Prompt工程的迭代过程

情景Prompt的编写，我经历了三个阶段。第一阶段是"一段话描述完所有要求"，效果是场景有了，但对话很干瘪；第二阶段是"结构化角色卡+规则列表"，效果好了很多，但模型还是会偶尔跳出角色；第三阶段是"角色卡+世界观+对话风格样例+硬性禁令"。

目前沉淀下来的角色卡结构大致是这样的：

你是【角色名】，身份是【职业/关系】。 你正处于【场景描述】中，当前核心诉求是【角色目标】。 你对用户的态度：【友好/紧张/不耐烦/公事公办】。 你的说话风格：【简短/话痨/使用俚语/正式】。 你需要遵守： 1. 永远不跳出角色，不承认你是AI。 2. 每轮回复不超过3句话，除非用户明确要求你解释。 3. 当空用户提出关键信息时，记住它并在后续对话中引用。 4. 如果用户偏离场景太远，温和地把对话拉回主线。 禁区：绝不替用户完成他的表达任务。

第四条和"禁区"是踩了无数次坑之后加上的。没有这两个规则，模型会变成"话痨"，用户说半句它就帮你说完了，那就完全失去了练习意义。

3.3 动态分支：状态机与概率选择

剧情动态化，技术上我用了一个轻量的剧情状态机。每个场景的会话过程被分成几个阶段，比如"开局 -> 冲突升级 -> 转折 -> 收尾"。每个阶段挂载若干可能的"剧情事件"，模型根据用户表现选择触发哪个。

触发方式我是这么设计的：不把全部事件一次性告诉模型，而是按状态分组。比如开局阶段只给"顺利办理/证件不全/柜台暂停服务"三个事件选择；当用户用较好的口语应对了开局，就触发"证件不全"这种更高难度的事件。这其实是一个基于用户表现的难度自适应系统。

状态切换的判断依据是什么？我会让模型在回复中附带一个不可见的JSON状态标记，类似{"state":"conflict_intensified", "event": "lost_boarding_pass"}，前端解析标记来更新UI上的"当前进度条"，而后端将这个状态写入Redis，用于后续生成反馈报告。

3.4 难度自适应的底层逻辑

自适应不是玄学，本质就是一套评分+调参逻辑。我在每轮对话结束后，让反馈引擎给用户打四个维度的分：语法准确度(0-1)、词汇丰富度(0-1)、流利度(基于ASR的停顿/重复检测)、情景应对度(模型主观评分)。

之后这套分数会进入一个简单的规则引擎：

• 四维平均分低于0.4，下轮降低事件难度，比如地勤说话放慢、用简单词；
• 平均分高于0.8，触发隐藏挑战事件，比如突然插入一个电话干扰；
• 平均分在0.4-0.8之间，保持当前难度，但随机微调事件选项。

这套机制花了大概两周时间打磨，但效果远比"让模型自己判断用户水平"要可控。模型自己的判断波动太大，规则引擎至少保证逻辑可解释、可调参。

4. 核心模块实现：对话管理、角色扮演与反馈评价

4.1 对话管理：长短期记忆分离

实现过程中，对话管理是最容易翻车的地方。市面上很多RAG方案把整个历史记录一股脑塞给模型，轮次短还好，到第20轮Prompt会爆炸，而且模型会忘记前面细节。我采用了一个三级记忆架构：

• 短期记忆：最近5轮对话原文，直接放入上下文；
• 剧情记忆：一个结构化的JSON，记录当前状态、已触发事件、用户角色的关键属性（比如用户选的出发地、目的地、时间等）；
• 长期档案：用户的历史学习记录，包括常犯的错误类型、最近练习节奏，这部分不进入每轮上下文，只在生成反馈报告时使用。

剧情记忆JSON是一个很关键的工程决策。比如机场场景里，用户在第一轮说"我的航班号是CA981，飞洛杉矶"。这个信息如果不单独存，到了第8轮模型很可能就忘了。我把它抽取出来存成{"flight":"CA981", "destination":"LAX", "issue":"none"}，在每一轮构造Prompt时拼接到上下文里。这一个改动，让角色一致性的用户评分从6.2分涨到了8.5分。

4.2 角色一致性：内容过滤与人格锚定

角色"精分"是LLM扮演类应用的通病。我用了两层机制来解决。

第一层在系统指令中写了"人格锚定"语句：每轮模型输出前面都会由框架自动注入一句角色内心独白，比如地勤角色在用户语气很不耐烦时，内心独白是"旅客情绪比较激动，需要更耐心地解释"，这帮助模型稳定在当前角色视角。

第二层是输出内容的硬约束：模型返回值必须是JSON包住的{"dialogue": "角色说的话", "inner_thought": "...", "state_update": {...}}。通过结构化约束，防止模型在角色话术里插入"作为AI"之类的破墙台词。一旦检测到dialogue中包含"作为一个语言模型"或"我无法"之类的教学口吻，后端会重试生成一次。

4.3 练习意图识别与动态干预

用户的意图不只是"扮演角色"，他还会问："这里我不太会，能不能给我提示？"或者直接说："用中文告诉我应该怎么回答。"

我在编排层加了意图分类器，用一个小模型（或者正则+关键词兜底）识别用户输入属于哪一类：继续角色扮演、请求帮助、请求翻译、脱离场景闲聊、要求更换话题。这个分类器的结果决定请求交给哪个引擎处理。

这个模块的引入背景是一次真实翻车：用户说"等等，我不知道该说什么"，结果剧情引擎一本正经地用角色语气回应"您可以在值机柜台办理登机手续"，完全无视用户的求助信号。后来一旦识别到"请求帮助"，就会切换到教学模式，由反馈引擎生成一段"思路提示+示例句型+关键词汇"，然后再回到剧情引擎继续扮演。这个体验细节非常影响留存率，用户卡壳时能不能得到温柔接管，直接决定他会不会继续用下去。

4.4 反馈生成：从"挑错"到"教练式反馈"

最开始的反馈设计走偏了，以为用户需要的就是一堆红叉和语法批改。测试发现，用户看到满屏错误会挫败，有的人直接卸载。后来参考语言学习理论里的"情感过滤假说"，把反馈改成了三层结构：

• 第一层：肯定亮点。先是具体夸奖，比如"你在表达航班变更时用了'result in'，搭配很地道"；
• 第二层：分级纠错。按严重程度分三类：影响理解的硬伤（必须改）、明显但不影响理解的错误（建议改）、优化空间（随意）；
• 第三层：替代表达。提供两种以上更自然的说法，并说明使用情境。

还有一个细节：反馈不能只看单句语法，还要看"情景契合度"。我让反馈引擎结合当前剧情状态判断，比如用户在机场角色扮演里说了一句很地道的商务英语，语法没错，但在这个情景里显得突兀——反馈会指出"这个表达更适合会议室，在机场你可以更直接一些"。这个维度是情景教学Agent相对传统口语App的差异点。

5. 评估体系：不靠感觉，靠数据驱动迭代

5.1 评测集构建

做Agent，最怕的就是自己觉得好用。我花了很大精力建了一套评测集，包含三个层次。

第一层是"情景完整性测试"：每个场景跑一遍完整会话，检查开始、转折、收尾三个阶段是否都有正常推进，有没有卡死在某个状态。自动化测试通过35个场景骨架各跑3遍，产出105条会话记录。

第二层是"行为规范测试"：检查每轮AI回复是否遵守了"不跳出角色""不超过三句话""不替用户说话"等硬指标，用规则+人工抽检完成。

第三层是"用户表现评估"：招募8名不同英语水平的内测用户，每人跑完5个场景后填深度问卷，从"压迫感""有趣度""帮助价值""自然度"四个维度打分。这一层最花时间但最有价值。

5.2 失败模式与修复记录

以下几类失败是我在整个开发中高频出现的，直接列出来供参考：

5.3 技术债与成本的平衡

大模型项目的成本控制是个绕不开的话题。我的实测数据：一个完整10轮左右的场景练习，如果全部用GPT-4o，成本大约0.35美元；做了双模型路由后，降到0.12-0.15美元。

成本优化还有两个小技巧。第一个是Prompt精简：把不必要的装饰性文字去掉，上下文能少100个token，累计下来省5%-8%成本。第二个是缓存策略：同一场景骨架的静态部分（场景描述、角色卡、初始Prompt）按版本缓存，不重复计入输入token。对于可能被反复练习的高频场景，这个优化收益很可观。

我个人不太建议为了省成本去硬套一个明显能力不足的小模型。教学场景里一次生硬的回复，流失用户的成本远高于省下的几分钱。关键是精准路由，让每一分钱花在刀刃上。

6. 上线后的迭代方向：Agent发展的下一站

6.1 语音交互的延迟优化

目前整个链路在4G网络下平均延迟2.3秒，5G或Wi-Fi环境下可以压到1.8秒。下一步的计划是引入端侧轻量模型做首轮意图预判，在用户还没说完时就预生成部分回复候选，等ASR结果确认后直接无缝衔接。这个方案参考了语音助手的"early decision"思路，预计能把感知延迟降到1秒以内。

6.2 多模态教学信号

还有一个更长远的方向，是把视觉信号加进来。比如用户扮演"在餐厅向服务员描述一道菜的口感"时，Agent如果能"看到"用户的表情和手势，就能给出更丰富的反馈。这个对硬件和带宽要求都不低，但教学价值很高——毕竟真实交流中，非语言信息占比很大。目前我还在评估方案，优先考虑的是简化版——从WebRTC视频流截帧做表情识别。

6.3 数据飞轮与个性化

内容的生产不能一直靠人工。我计划引入一个"社区场景创作"机制：用户提交自己遇到的真实交流场景，Agent自动加工成结构化骨架，由其他用户测试，投票高的进入正式场景库。这就是数据飞轮的雏形——使用的人越多，场景越真实；场景越真实，使用的人越多。

个性化方面，下一步要做的是"错题驱动的内容推荐"：用户在反馈报告里暴露的弱点，会有针对性地推荐下一个练习场景。比如数值型语法错误频繁，推荐"购物砍价""房租谈判"这类数字表达密集的场景。

踩过这么多坑之后，我最大的体会是：做一个英语情景教学Agent，60%的精力不在AI技术上，而在内容设计和用户体验细节上。模型能力已经足够强了，关键是怎么把它驯化成可靠的教学角色。如果你的目标也是做一个自己的Agent，建议想清楚一句话的答案：你做的Agent让用户的哪种体验发生了本质变化？想不清楚这个，技术再花哨也立不住。