1. 先搞清楚AI Agent 到底是什么1.1 一句话分清模型、大语言模型、Agent 三者关系这几天热搜词里反复出现一个很有意思的提问“Agent、LLM 和 AI 模型之间有什么区别比如常说的 DeepSeek 到底是属于哪一种”这个问题问得特别基础但也特别关键。很多朋友一上来就急着写代码、调接口结果连最基本的“自己在造什么”都没想明白后面必然会走弯路。先把这三层关系捋清楚。AI 模型Model是最大的范畴指的是用数据训练出来的数学函数能完成识别、分类、生成等任务。大语言模型LLM是 AI 模型里专门处理文本的那一类它读进去一串文字吐出来一串文字本质上是做“下一个 Token 预测”。而 DeepSeek、GPT、Claude、Qwen 这些名字指的都是具体的 LLM 产品或者模型权重。它们就像发动机很强但是如果没人把它装进车架、接上方向盘它就只是一台孤零零的机器。Agent 则完全不同。Agent 不是模型而是跑在模型之上的一整套程序。它把 LLM 当作“大脑”在外面包上了“记忆系统”“工具调用模块”“任务规划逻辑”和“执行反馈回路”让它能自主完成一个相对完整的任务。打个比方LLM 是一个知识渊博但只会坐在那里等问题的顾问而 Agent 是那个知道什么时候该问、什么时候该查资料、什么时候该动手写代码、甚至能自我纠错的“同事”。所以答案很明确DeepSeek 属于“大语言模型”这一层它不是 Agent。你可以用 DeepSeek 的 API 去搭一个 Agent也可以不搭——直接用对话界面提问那它就是一个聊天机器人而不是一个 Agent。ChatGPT 官网里的默认对话窗口很多场景也只是 LLM不是 Agent只有当它在背后调用了浏览器工具、代码解释器、文件读写能力时它才以 Agent 的形态在工作。1.2 Agent 的四个核心部件大脑、记忆、工具、行动理解了 Agent 不是模型之后下一个问题就是一个能被称为“Agent”的系统内部到底由什么组成互联网上关于 Agent 组成结构的文章很多各家说法略有差异但拆到底逃不开四个核心部件。大脑。这是 Agent 的推理中枢也就是 LLM 本身。它负责理解用户的意图、拆解任务步骤、决定下一步该调用哪个工具、评估执行结果是否满足要求。选什么样的模型做大脑直接决定了 Agent 的智商上限。逻辑推理类的任务用推理强的大参数模型简单分类整理类的任务用小参数模型成本和速度差异非常大。记忆。这个太好理解了——你招一个新同事他不可能每次都让你从头交代所有背景。Agent 也是一样需要短期记忆当前对话上下文和长期记忆跨会话保存的偏好、历史结论、业务知识。完全没有记忆的 Agent 就像一个失忆症患者每次对话都从零开始实用性大打折扣。工具。这是 Agent 和普通聊天机器人拉开差距的关键。工具可以是一个函数、一个 API、一个数据库查询接口、一段 Shell 命令、一个浏览器操作动作。Agent 通过“函数调用Function Calling”来决定什么时候调用什么工具拿到结果之后再把结果喂回大脑做下一步判断。没有工具的 Agent 只能纸上谈兵有了工具的 Agent 才能动手干活。行动。行动是把决策落到现实世界的最后一环。它可能是执行一行 Python 代码、发送一封邮件、提交一个订单、在工业设备上改写一段 PLC 程序。行动的闭环还包括“反馈”——执行完之后结果要能传回给大脑大脑根据结果判断是已经完成任务还是需要调整策略再来一次。这四个部件缺一不可。我在实际项目里见过很多“半成品 Agent”要么只有大脑和对话界面没有工具调用本质上还是个聊天机器人要么有工具但没记忆每次请求都要重新灌一堆背景信息要么有记忆有工具但缺少行动反馈闭环任务做到一半卡住了也不会自救。所以后面我们聊“从 0 到 1 搭建”本质上就是在把这四个部件一个个拼起来。2. 开始造“同事”从 0 到 1 的路线图2.1 定岗位你的 Agent 要干什么活我在给团队做分享时最喜欢问一个问题你要造的这个“同事”岗位职责是什么很多人回答不上来只说要做一个 Agent。那就相当于你去人才市场说“我要招一个人”却不写岗位 JDHR 根本没法帮你。先定岗位再谈技术。常见的 Agent 岗位有以下几种客服/答疑类 Agent。负责回答用户问题核心能力是检索知识库、理解用户情绪、给出合规答案。这类 Agent 的技术难度较低重点是知识库整理和提示词设计。代码开发类 Agent。负责写代码、改 Bug、做 Code Review。核心能力是理解代码仓库结构、调用编译/测试工具、读取上下文文件。这类 Agent 是当前最火的方向也是难度较高的一类需要和 IDE、CI/CD、代码仓库深度集成。数据分析类 Agent。负责人查数、做报表、写分析结论。核心能力是操作数据库、调用可视化组件、生成结构化文档。业务流程自动化 Agent。负责处理表单、审批、通知、跨系统数据流转。核心能力是调用多个业务系统 API维护状态机处理异常分支。工业控制辅助 Agent。比如热搜词里提到的“AI Agent 与 PLC 编程”这类 Agent 负责根据自然语言描述生成 PLC 程序框架、检查梯形图逻辑、辅助生成设备文档。这类场景很专业需要把行业知识沉淀到提示词和知识库中而且因为涉及工业安全通常只做“辅助生成人工审核”不允许全自动下发控制指令。岗位定义越清晰后面的框架选型、模型选型、工具设计就越轻松。我见过特别多“什么都能干”的通用 Agent 项目最后全都死在“什么都干不好”上。Agent 的能力边界越明确表现越稳定用户口碑越好。2.2 选框架从代码到低代码的选择定好岗位之后就要选开发路径。市面上有几种做法各有利弊。直接调 API 手写 Agent。用 Python 或 Java 写一个主循环自己管理 LLM 调用、工具注册、对话历史。优势是完全可控没有框架黑盒适合深度定制劣势是开发量大轮子都要自己造而且容易在工具调用解析、错误处理等细节上踩坑。适合学习原理和做 PoC。用成熟 Agent 框架。目前比较主流的开源自部署方案有 LangChain、LlamaIndex、AutoGen、CrewAI 等Java 生态里有 Spring AI。这些框架帮你封装了 Agent 循环、工具调用、记忆管理、多 Agent 协作等通用能力。优势是开发效率高社区方案多劣势是抽象层级多出了问题要翻框架源码调试难度不低。适合有一定基础、追求交付速度的团队。用平台型产品。各云厂商都推出了 Agent 搭建平台主打可视化编排、拖拽式工作流。优势是上手快业务同学也能参与劣势是平台绑定、灵活度低、私有化部署成本高。适合政企客户或业务验证阶段。我个人对学习路径的建议是第一步一定要手写一个最小的 Agent 主循环把原理吃透第二步再引入框架提升效率。直接上手框架写业务遇到问题容易两眼一抹黑因为你不知道框架底下发生了什么。2.3 推荐一个快速起步的技术栈如果你现在带着一个小团队想在两周内做一个能内部使用的 Agent 平台我会推荐这样的技术栈组合后端用 Python FastAPI或者 Spring AI 如果你偏 Java 生态模型接口层封装成统一的 Gateway支持切换不同的 LLM。框架层建议直接用 LangChain 的 LCEL 表达式语法来串联简单链路复杂交互场景拆成多个独立 Agent。前端可以用 React Next.js或者干脆先用 Gradio / Streamlit 做一个内部演示版。记住Agent 平台的用户界面不是重点重点是后台的任务调度和工具调用链路。工具层准备好一套标准接口让 Agent 能调用内部 API、数据库、文件系统、搜索服务。记忆层建议先用向量数据库 Redis向量库存长期记忆Redis 存短期会话缓存。部署用 Docker Compose 起步跑通了再考虑 Kubernetes。这个组合的好处是每层技术都是行业主流遇到问题社区资料非常多组件之间耦合度低后面想换任何一层——换模型、换向量库、换前端——都不会伤筋动骨。3. 动手实操5 步搭一个能干活的最小 Agent3.1 第 1 步搭建模型接入层万事开头难模型接入是最简单也最容易被忽视的一步。很多人觉得“不就是调 API 吗”结果一上来就踩坑上下文长度不够、返回格式不稳定、并发控制缺失、模型版本突然变化导致输出格式崩掉。我建议一开始就把模型接入层设计成独立模块用工厂模式适配器模式。核心思想就是你的业务代码不直接依赖任何具体模型 SDK而是依赖你自己定义的一个接口。这样以后想从模型 A 换到模型 B只需要新增一个适配器业务代码完全不用动。做这层时要特别注意两个点。第一统一处理 Token 计数和上下文截断逻辑不同模型的上下文窗口不一样截断策略也不一样必须在我的“Memory 层”里统一处理而不是散落在各处。第二给每个模型配好独立的超参数比如 temperature、top_p、max_tokens因为不同模型对同样参数的表现差异其实很大复制粘贴别人的配置往往不出效果。3.2 第 2 步实现工具调用工具调用是整个 Agent 里最有“智能感”的一环也是工程上最容易翻车的一环。它的基本原理是这样的你把一堆工具的“说明书”以 JSON Schema 的格式发给 LLMLLM 判断当前任务需要哪个工具、参数是什么然后返回一个结构化的工具调用请求你的程序去执行真正的工具函数把结果再传给 LLMLLM 基于结果继续推理。说得直白点LLM 本身不执行任何工具它只负责“点菜”真正“做菜”的是你的代码。下面是一个最小实现的伪代码我用 Python 写核心逻辑看注释就能懂def run_agent_turn(user_query, tools, model_client): # 第一轮把用户问题 工具说明发给 LLM response model_client.chat( messages[{role: user, content: user_query}], toolstools, # tools 是 JSON Schema 列表 ) # LLM 如果决定要调用工具会返回 tool_calls if response.tool_calls: tool_results [] for call in response.tool_calls: function_name call.function.name arguments json.loads(call.function.arguments) # 在代码库里找到对应函数并执行 func resolve_tool_function(function_name) result func(**arguments) tool_results.append({ role: tool, tool_call_id: call.id, content: json.dumps(result) }) # 第二轮把工具结果喂回去让 LLM 生成最终答案 final_response model_client.chat( messages[ {role: user, content: user_query}, response, # 包含第一轮的 assistant 输出 *tool_results, ], ) return final_response.content # 不需要调用工具直接返回 return response.content这段代码看起来简单但工程化时要做的细节非常多。比如函数参数校验做没做如果 LLM 生成的参数是字符串但是函数需要整数怎么转换有些格式不兼容怎么处理错误信息能不能回传给 LLM 让它自主修复超时机制有没有工具执行时间太长怎么中断调用失败后应该告诉用户失败还是重试一次我踩过最经典的坑是LLM 连续两次调用同一个工具拿到同样结果后开始“原地打转”陷入死循环。解决方法是在循环里加最大迭代次数比如说 10 轮超过就强制停止并返回已获得的信息。3.3 第 3 步加入记忆机制记忆机制分两块短期记忆和长期记忆。短期记忆相对简单就是当前会话的消息列表。长期记忆就比较复杂了通常有两种实现方式向量检索式记忆和结构化摘要式记忆。向量检索式记忆的思路是把用户的历史提问、偏好、重要结论全部做向量化存进向量数据库。当新对话进来时把当前问题向量化检索出最相似的历史记录把它们塞进上下文。这种方式的优点是不用做太多结构化设计缺点是有时检索出来的内容并不相关。结构化摘要式记忆的思路是每轮对话结束后用 LLM 自动生成一段摘要包括“用户是谁”“用户偏好”“当前任务进展”“已知结论”存成结构化 JSON。新对话开始时直接读取这些摘要。优点是精准缺点是设计成本高摘要本身也有延迟写入的问题。比较稳妥的做法是两者结合。用短期上下文管理当前任务用结构化摘要管理用户级偏好用向量检索做补充记忆。另外提醒一句记忆机制会显著增加 Token 消耗做之前先算清楚成本。3.4 第 4 步挂上知识库RAGRAG检索增强生成是让 Agent 学会“查资料”的最基础手段。核心逻辑是用户提问进来先从知识库中检索出相关的文档片段拼到提示词里再让 LLM 基于这些片段回答。这样做的目的是让模型在回答时能有依据而不是凭空瞎编。但很多人把 RAG 想得太简单了觉得装一个向量数据库、分个块、做个相似度检索就完事。实践过就会知道真正的难点在“知识入库”这一侧。文档格式多种多样PDF、Word、HTML、Excel不同格式的解析策略完全不同。表格要转成什么文本格式才能让 LLM 看明白长文档怎么切块才能保证语义完整切得太大浪费 Token 且检索不精准切得太小语义破碎检索效果反而差。我的个人习惯是先用“结构感知切块”保留 Markdown 标题层级或 PDF 的自然段落结构再为每一块生成一个简短摘要作为检索的“路由索引”最后把原块作为“参考答案”拼进提示词。即检索时用摘要匹配回答时读原文块这个小技巧能显著提升命中率。3.5 第 5 步让 Agent 学会“技能”和 MCP“技能Skill”是现在 AI Agent 圈特别火的概念。热搜词里也出现了“ai agent skill memory mcp”这种组合词——Skill、Memory、MCP 被并列讨论说明大家都在关心同一件事怎么让 Agent 拥有可复用的能力包。Skill 本质上是一组预置的提示词模板 工具脚本 示例数据的组合。举个例子如果你想造一个“会议纪要 Agent”一个完整的 Skill 应该包括会议记录整理提示词、录音转文字工具调用脚本、待办事项提取规则、周报同步格式模板。有了 Skill你不需要每次开会前从头写提示词直接唤起这个技能包就行。MCPModel Context Protocol模型上下文协议是最近讨论热度很高的开放协议。它想解决的核心问题是Agent 要对接各种外部数据源和工具如果每个源都单独开发一套接口就是“N 方对接 N 倍的复杂度”。MCP 提出一种标准化协议让模型、Agent 框架和数据源之间的连接方式统一起来。打个比方没有 MCP 的时代你家里每个电器都要自带专用的遥控器有了 MCP 之后你有了一个万能遥控器电器只需要遵守同一个通信协议。目前各大模型厂商和框架都在积极推进 MCP 支持做新项目时建议优先支持 MCP避免重复开发已经有人做过的工具适配。4. 平台化从单个 Agent 到 Agent 平台4.1 Agent 平台该有哪些模块单 Agent 能干活之后下一个阶段一定是平台化。“平台”这两个字意味着它不是跑一次就结束的脚本而是能持续运行、多人使用、不断迭代的系统。一个合格的 Agent 平台至少要包含六个模块模型管理模块。统一管理多个 LLM 的接入、配额、密钥、版本切换。线上环境不能把 API Key 写死在代码里必须有独立的配置中心和密钥管理。Agent 编排模块。支持像画流程图一样把多个 Agent、工具、知识库串联起来支持条件分支和循环。工具体系模块。提供工具注册中心让开发者可以上传新工具并设置工具权限哪些 Agent 能用哪些工具需要管控。工具必须有版本管理和调用审计。知识库模块。管理文档上传、切块、向量化、权限控制。知识库是企业 Agent 平台最容易出问题的地方权限一不小心就会造成数据泄露。记忆与状态模块。管理会话状态、用户画像、长期记忆。跨 Agent 的记忆共享也要在这里统一设计不能每个 Agent 各存一套。运营与审计模块。记录每一次 Agent 调用的输入、输出、耗时、费用支持告警和人工介入。企业落地时这个模块几乎是第一个被要求做的合规审计都靠它。4.2 多智能体让同事们协作起来单打独斗的 Agent 能力有限多智能体协作是平台化的高级形态。热搜词里有“多智能体 ai agent coding 协助开发规范”说明很多人已经在研究怎么让多个 Agent 分工协作。多智能体有三种典型协作模式。第一种是“主管-下属”模式一个主 Agent 负责拆解任务把子任务分发给多个专业 Agent然后汇总结果。第二种是“流水线”模式Agent A 的输出作为 Agent B 的输入按固定顺序处理比如先搜索、再分析、后写报告。第三种是“辩论/评审”模式多个 Agent 从不同角度分析同一个问题互相质疑最后综合结论。协作模式的选型要看任务类型。流水线适合流程固定、步骤清晰的任务主管模式适合目标开放、需要动态规划的任务辩论模式适合高风险决策比如代码评审、方案评审。很多人在这个阶段会过度设计我建议一开始先用主管模式跑通后面根据业务反馈逐步演进。这里也顺带回答热搜词里另一个问题“Codex 可以直接读取其他 AI Agent 会话内容吗”如果你用的是同一平台内的服务通过 API 按会话 ID 去读取在权限允许的前提下是可以做到的。但跨平台、跨厂商的代理工具空间目前还没有统一的协议去强制开放。在自建平台上我一般会把跨 Agent 会话读取做成显式的授权接口谁读谁的会话要留有审计记录。4.3 场景实战企业内部 Java 平台上怎么落地搜索引擎的数据显示最近“企业级 Java AI Agent 应用平台”以及“Spring Cloud Spring AI 开发自己的 Agent”的搜索量涨得很猛。这背后是大量传统 Java 技术栈企业的共同诉求不是所有团队都愿意为了 Agent 换语言换生态在现有 Java 体系里把事情做成就够了。Spring AI 是 Spring 生态官方推出的 AI 应用开发框架目前已经支持 OpenAI、Azure OpenAI、Ollama、Qwen 等多种模型接口。它把 ChatClient、PromptTemplate、EmbeddingModel、VectorStore 这些常用组件都封装成了 Spring Boot 的 StarterJava 工程师上手几乎没有门槛。在企业级落地时最大的优势不是写 Agent 逻辑有多快而是能和现有的 Spring Cloud 微服务体系无缝整合。你可以把 Agent 做成一个独立的微服务用 Nacos 做注册发现用 OpenFeign 调用内部业务接口用 Sentinel 做流量控制和熔断用 Seata 处理分布式事务——只不过这里的“事务”已经变成一个任务的多个工具调用步骤。这种整合能力是 Python 系框架很难直接提供的。我的建议是如果你们团队以 Java 为主不要强行上 LangChain直接用 Spring AI 加上代码自研状态机。宁可自己多写几行代码也不要引入一个团队里没人能维护的复杂框架。另外提醒一句Spring AI 迭代速度很快API 在不同版本之间变动较大项目开始时要锁版本不要用最新发布的功能直接上生产。4.4 场景实战CI/CD 流程里的 AI Agent“Jenkins AI Agent”这个热搜词很有意思。CI/CD 和 AI Agent 的结合是当前最贴近实际生产力提升的落地场景之一。我见过不少团队已经在尝试效果参差不齐但方向是对的。Jenkins 流水线里的 AI Agent 可以做几件事首先是构建失败的智能分析以前 Jenkins 构建挂掉要人工翻日志找原因现在可以让 Agent 读取构建日志定位错误原因甚至直接给出修复建议其次是自动化代码评审PR 提交后触发 Agent 做静态分析、逻辑审查和代码风格检查输出评审意见到评论里再就是自动化测试用例生成Agent 读取方法源码生成单元测试用例提交回仓库。我前阵子做了一个 PoC给 Jenkins 挂了一个 Agent 节点构建失败时自动触发一个“诊断 Agent”它会读取构建日志、对比上一次成功构建的变更、分析最近提交的代码最后在工单里生成一个带修复方案的报告。实测下来对于常见依赖冲突、语法错误、单测失败这三类问题它的准确率相当高能直接给出可用的修复补丁。对逻辑性强的业务 Bug它只能给出方向性建议但这也已经能帮开发者节省大量排查时间了。4.5 场景实战和 PLC 编程结合的工业场景“AI Agent 与 PLC 编程”是热搜词里特别有行业特色的一条。PLC可编程逻辑控制器是工业自动化控制的核心设备传统 PLC 编程要求工程师熟悉梯形图、结构化文本等专业语言门槛不低。AI Agent 进这个领域核心价值是降低编程门槛和辅助诊断。入门级用法是用自然语言描述控制逻辑Agent 生成对应的结构化文本ST或指令表代码。高阶用法是让 Agent 分析现有 PLC 程序的逻辑生成说明书、排查故障点。更进一步的设想是巡检 Agent 读取设备运行数据判断异常状态给出处理建议。但工业场景有一条底线必须守住Agent 的输出永远只能作为“辅助”不能直接下发到设备执行。控制系统的安全性是生命线Agent 生成代码后必须经过资深工程师审核在仿真环境验证然后才能下载到 PLC。我在项目里给 Agent 设定了严格的输出边界它只能写代码建议、只能出诊断报告、只能做自然语言与代码的翻译任何写回控制器的操作都需要人工确认。这套约束在系统设计上写死了谁也不能绕过。5. 常见问题与排查技巧实录5.1 Agent“胡说八道”怎么办幻觉问题排在所有 Agent 实践问题第一位。原因无非几种模型本身能力不足、上下文里没有足够依据、提示词让模型自由发挥、检索到的知识本身就是错的。排查时我一般按这个顺序走。第一检查上下文里有没有引用真实内容——如果回答不是基于检索结果生成的那就是 API 在自由发挥需要改成强制引用模式。第二换更强的模型对比测试经济允许的情况下同一任务用小模型和大模型跑一遍能快速判断是模型能力上限还是工程问题。第三在提示词里给模型“认怂”的选项明确告诉它“如果信息中不包含答案直接说不知道不要编造。”这一条对缓解幻觉非常有效。5.2 工具调用老是失败工具调用失败是工程问题最多的环节。常见场景包括LLM 返回的 JSON 参数格式不合法、参数类型对不上、工具函数内部抛异常、超时、权限不足。最有效的排查方法是“分阶段日志法”。在 LLM 返回 tool_calls 之后、执行工具函数之前、工具返回之后三个阶段各打印一条详细日志记录完整请求和响应。这样一旦出问题你立刻能判断是模型生成参数的问题还是工具函数本身的问题。另外要说一个经验不要完全信任 LLM 生成的参数。在执行工具函数之前先用 JSON Schema 校验参数格式不合法就让 LLM 重新生成一次。重试超过两次还不行就停止调用返回错误提示。5.3 上下文一长就“失忆”Agent 一次会话中处理的内容越来越多时效果会急剧下降。核心原因是 LLM 的注意力机制对长上下文中关键信息的感知能力有限越靠中间的内容越容易被忽略专业上叫“迷失在中间Lost in the Middle”。解决办法有两个方向。一是压缩上下文把不重要的历史对话替换成摘要把大段知识替换为检索命中片段只保留关键信息在上下文中。二是把 Agent 的“记忆”外置重要信息写入长期记忆库下一轮工作时通过检索拉回而不是把全部历史都塞进去。很多人的误区是觉得上下文越长越好其实上了 10 万 Token 之后模型的有效理解能力断崖式下降做 Agent 架构时一定要控制上下文质量大于数量。5.4 成本失控怎么办有朋友说做了一个 Agent 平台跑了一个月模型 API 账单出来差点吓到自己。原因几乎都是同一个没有做 Token 成本预算和配额管理。从第一天就要做三件事。第一给每个 Agent 设置单次调用 Token 上限和月度费用上限。第二任务能用小模型的绝不用大模型比如简单的意图识别、分类任务用参数量小的模型完全够用成本能省下 80%。第三缓存命中率要做好同一类问题如果知识库内容没变可以用语义缓存直接返回不再调用模型。这三点做完整体成本能控制在预期的十分之一到二分之一之间。5.5 面试视角一个 Agent 题目的标准回答思路热搜词里有“ai agent 面试题”顺便说两句。现在越来越多后端岗位面试会问 Agent 相关问题考察的重点通常不是你会不会用某个具体框架而是“组成结构”和“设计取舍”。标准的回答思路是先讲清楚 Agent 的四个核心部件——大脑LLM、记忆短期长期、工具调用Function Calling、行动反馈闭环然后讲清楚 LLM 和 Agent 的区别——模型是被调用的能力Agent 是组织这种能力的系统再结合你做过的最简单例子讲一次完整的工作循环最后提一嘴当前框架的优缺点、你想怎么改进。这套回答下来面试官基本能判断你不是“背了概念”而是真做过。最后再分享一点个人经验做 AI Agent 这一年多的体会是技术难点从来不在“跑通一个 Demo”而在“让它稳定地跑一百次”。一次两次效果好不叫好一百次里能有九十五次稳定输出才算一个合格的 Agent。所以我在项目里坚持做两件事一是给每一次 Agent 调用记录完整轨迹方便事后复盘二是把“输出结构化”当成硬指标无论哪个环节都要求模型返回可解析的 JSON而不是自由文本。另外如果你也是半路出家开始做 Agent别急着追新框架新协议。踏踏实实把模型接入、工具调用、记忆管理、RAG 这四件事吃透你已经能超过多数只会套模板的开发者了。Agent 的边界其实就是你的想象力加上工程能力前者大家都有后者练一练一定会到。