驾驭AI智能体：从代码生成到软件工程范式升级的实践指南

1. 项目概述从“工具”到“智能体”的范式转移最近和几个做企业级应用开发的朋友聊天大家不约而同地提到了一个词倦怠。这种倦怠不是对技术本身失去了热情而是对那种“重复造轮子”的日常感到疲惫。一个简单的业务逻辑从前端表单验证、后端接口开发、数据库设计到部署上线每个环节都需要投入大量人力而其中很多代码是高度模式化的。我们不禁在想有没有一种方式能让开发者从这些重复劳动中解放出来更专注于业务逻辑的创新和架构设计本身OpenAI官方发布的“harness-engineering”项目或者说它所代表的一种工程技术理念恰好回应了这种普遍存在的痛点。它不是一个具体的、可以下载安装的软件包而是一套关于如何在一个“智能体优先”的世界里系统性地利用像Codex这样的AI编码模型来构建复杂软件的方法论。这里的“harness”一词非常传神直译为“驾驭”或“利用”意味着这不是简单地调用API生成几行代码而是像驾驭一匹强大的赛马需要缰绳、技巧和策略将其能力引导到正确的轨道上完成复杂的工程任务。传统的软件开发中AI比如代码补全工具扮演的是“辅助者”或“加速器”的角色。我们写一个函数的大致框架AI帮我们补全细节我们写一个注释AI生成对应的代码片段。这很好但它仍然是以“人”为核心AI是围绕人的意图运转的工具。而“智能体优先”的世界观则截然不同。在这里AI智能体被提升为“一等公民”它不再仅仅是响应指令而是能够主动理解高层目标、拆解任务、规划步骤、执行代码生成、甚至进行自我验证和迭代的自主实体。开发者的角色从“写代码的工人”转变为“定义目标、设计规则、监督流程的架构师和教练”。这套方法论之所以重要是因为它直接瞄准了软件工程的核心矛盾日益增长的复杂业务需求与有限的人力开发资源。通过将Codex这类模型深度集成到工程流程中我们有机会构建出能够理解业务上下文、自动生成并整合代码、持续演进的“智能体驱动”系统。这不仅仅是提升个体开发者的效率更是对软件生产方式的系统性升级。接下来我将结合我对AI工程化的理解拆解这套方法的核心思路、实操要点以及落地过程中必然会遇到的挑战。2. 核心思路拆解如何“驾驭”而非“调用”Codex理解“harness-engineering”的关键在于区分“调用一个模型”和“构建一个以模型为核心的工程系统”。前者是点状的、临时的后者是线性的、系统化的。OpenAI团队能在5个月内“零手写代码”产出百万行级别的系统靠的绝不是简单地堆砌API调用次数而是一套精心设计的工程框架。2.1 智能体作为执行单元从函数到智能体在传统编程中函数是基本的执行单元。你定义输入、处理逻辑和输出。在智能体优先的架构中基本的执行单元变成了“智能体”。一个智能体是一个具备特定能力如“生成Python数据类”、“创建React组件”、“编写数据库迁移脚本”的、可配置的Codex调用实例。但它的内涵远大于一个函数上下文感知智能体不仅接收直接的指令还能访问一个共享的、不断丰富的“工程上下文”。这个上下文包括项目结构、已有的接口定义、数据模型、技术栈约定、甚至之前的决策记录。目标导向你给智能体的指令通常是高层目标比如“为用户模块添加一个带分页的查询接口”。智能体需要自己拆解这个目标需要修改哪些文件控制器、服务、模型接口规范是什么RESTful路径、参数、返回值需要引入哪些依赖闭环执行与验证智能体生成的代码不是终点。一个成熟的工程框架会为智能体配备“验证”环节。这可能包括调用另一个“代码静态分析智能体”检查语法和风格生成单元测试用例甚至在一个沙箱环境中尝试运行看是否有明显的运行时错误。为什么这么做因为单纯的代码生成是不可靠的。没有上下文的生成就像让一个不了解项目背景的新手直接写代码极易产生风格不一致、与现有架构冲突、甚至无法编译的代码。通过将Codex包装成具有上下文和目标管理能力的智能体我们极大地提高了生成代码的可用性和一致性。2.2 任务分解与工作流编排智能体的交响乐单个智能体能力再强也无法独立完成一个复杂的特性开发。这就需要“工作流编排”层。你可以把它想象成管弦乐队的指挥。当接到一个“构建用户注册登录系统”的宏观任务时编排引擎会将其分解为一系列有序的子任务分析任务理解“用户注册登录”需要哪些组件用户模型、密码加密服务、认证控制器、JWT令牌生成、邮件服务等。生成序列规划执行顺序。例如必须先定义数据模型然后生成对应的数据库迁移脚本接着创建服务层最后才是控制器和API路由。这个序列本身可以由一个“规划智能体”基于最佳实践来生成。调度智能体按序列将每个子任务分发给对应的专业智能体。生成数据模型的智能体、生成迁移脚本的智能体、生成服务类的智能体依次被调用。传递上下文每个智能体执行完毕后其产出如生成的User模型类会被自动添加到共享上下文中。下一个智能体如生成UserService的智能体在运行时就能知道User类有哪些属性从而生成对应的方法签名。实操心得这里的最大挑战是确保分解的粒度合理。粒度过粗如“生成整个后端”智能体容易迷失方向生成质量低下。粒度过细如“生成一个getUsername方法”则会导致编排过于复杂通信开销巨大。我们的经验是将任务分解到“模块”或“层”的级别比较合适比如“生成领域模型”、“生成数据访问层”、“生成REST API控制器”。2.3 上下文管理与知识库智能体的记忆体这是整个系统的“大脑皮层”。一个健壮的上下文管理系统通常包含两部分动态会话上下文即当前工作流中产生的所有临时信息如刚生成的代码片段、执行过程中遇到的错误、用户提供的额外反馈。这部分上下文生命周期短但关联性强。持久化知识库这是项目的“长期记忆”。它包括项目规范代码风格指南如PEP 8、Airbnb JavaScript规范、项目结构约定、命名规范。架构决策记录为什么选择MongoDB而非PostgreSQL为什么采用洋葱架构这些决策会被记录下来供后续的智能体查询确保生成代码符合整体架构。领域知识业务术语表、核心业务流程描述、实体关系图。这能帮助智能体生成更符合业务语义的代码例如知道“订单”和“库存”的关系生成正确的库存检查逻辑。历史生成案例过去成功生成的类似功能的代码片段可以作为高质量参考范例。为什么这至关重要没有良好的上下文Codex就像一个失忆的天才每次对话都要从头开始。通过精心设计的上下文管理我们可以实现“累积性学习”让智能体在项目进程中越用越“懂”这个项目生成代码的准确率和契合度会随时间显著提升。这直接解决了AI生成代码“缺乏一致性”和“脱离项目背景”的核心痛点。3. 实操框架搭建从零构建你的智能体工程系统理论讲完了我们来看看如何动手搭建一个最小可行版本。我不会推荐某个特定的庞大框架而是展示一种基于现有成熟工具组合的务实路径。这套组合的核心思想是用LangChain管理智能体和记忆用Dify或类似平台提供可视化编排和上下文管理用自定义的验证工具链保证代码质量。3.1 基础环境与工具选型首先你需要准备以下基础OpenAI API访问确保你拥有有效的API密钥并且了解Codex模型如gpt-3.5-turbo-instruct或更新的代码专用模型的调用方式和成本。注意纯粹的gpt-4对话模型在代码生成的结构化输出和长上下文理解上可能不如专门的代码模型。开发环境Python 3.8环境这是目前大多数AI工程化库的首选语言。核心库安装pip install langchain openaiLangChain将成为我们组装智能体的“乐高积木”工具箱。3.2 构建第一个代码生成智能体让我们从构建一个最简单的“Python数据类生成智能体”开始。这个智能体的任务是根据自然语言描述生成符合Pydantic或Pythondataclass规范的类定义。from langchain.llms import OpenAI from langchain.agents import Tool, AgentExecutor, LLMSingleActionAgent from langchain.chains import LLMChain from langchain.prompts import PromptTemplate import re # 1. 定义专用工具 class CodeGeneratorTool: name Python_DataClass_Generator description 根据描述生成Python数据类代码。输入应为对类的自然语言描述如创建一个表示用户的类包含id整数、name字符串、email字符串和is_active布尔值属性。 def _run(self, query: str) - str: # 构造一个强引导性的Prompt prompt_template PromptTemplate( input_variables[description], template 你是一个专业的Python代码生成器。请严格根据以下描述生成一个完整、可运行的Python数据类。 要求 1. 使用Python的dataclasses模块。 2. 为每个字段添加类型注解。 3. 如果描述中提到“可选”则使用Optional[...]并从typing模块导入。 4. 在类顶部添加清晰的文档字符串。 5. 只输出代码不要有任何额外的解释。 描述 {description} ) llm OpenAI(model_namegpt-3.5-turbo-instruct, temperature0.1) # 低随机性确保稳定 chain LLMChain(llmllm, promptprompt_template) raw_output chain.run(descriptionquery) # 简单的后处理提取代码块 code_match re.search(rpython\n(.*?)\n, raw_output, re.DOTALL) if code_match: return code_match.group(1).strip() else: # 如果没有代码块标记假设整个输出就是代码 return raw_output.strip() async def _arun(self, query: str) - str: raise NotImplementedError(此工具不支持异步调用) # 2. 将工具封装进LangChain tools [Tool(nameCodeGeneratorTool.name, funcCodeGeneratorTool()._run, descriptionCodeGeneratorTool.description)] # 3. 创建智能体执行器这里简化使用零样本智能体 from langchain.agents import initialize_agent llm OpenAI(temperature0) agent initialize_agent(tools, llm, agentzero-shot-react-description, verboseTrue) # 4. 运行智能体 result agent.run(创建一个表示博客文章的数据类包含标题字符串、内容字符串、作者ID整数、发布时间datetime和标签列表字符串列表。) print(result)注意事项Prompt工程是关键上面的prompt_template包含了非常具体的指令使用哪个模块、添加文档字符串、只输出代码。这是“驾驭”Codex的核心。模糊的指令会导致五花八门的输出。温度参数temperature0.1使得输出确定性很高适合生成结构化的代码。如果你希望智能体有一些创造性比如为类想一些好用的工具方法可以适当调高但通常不超过0.3。后处理AI的输出可能包含多余的文本。使用正则表达式或解析库来提取纯净的代码是必要的步骤。3.3 实现工作流编排与上下文传递单个智能体意义有限。我们需要一个简单的编排逻辑。假设我们现在有两个智能体一个生成数据模型ModelAgent一个生成对应的CRUD仓库接口RepositoryAgent。RepositoryAgent需要知道ModelAgent生成的类名和属性。我们可以用一个简单的Python字典来模拟共享上下文并编写一个顺序执行器class SimpleOrchestrator: def __init__(self): self.shared_context { project_structure: {}, generated_code: {}, # 按文件名存储生成的代码 decisions: [] } def run_workflow(self, task_description): print(f开始执行任务: {task_description}) # 步骤1调用模型生成智能体 print(步骤1生成数据模型...) model_prompt f基于以下需求生成一个Python Pydantic模型{task_description}。请为模型起一个合适的类名。 model_code self.call_agent(model_prompt, agent_typemodel_generator) # 解析出类名这里简化处理实际应用需要更稳健的解析如AST class_name self.extract_class_name(model_code) self.shared_context[current_model_class] class_name self.shared_context[generated_code][models.py] model_code print(f生成模型类: {class_name}) # 步骤2调用仓库生成智能体并传入上下文 print(f步骤2为 {class_name} 生成仓库接口...) repo_prompt f 请为Pydantic模型 {class_name} 生成一个SQLAlchemy异步仓库接口。 上下文信息 - 项目使用异步SQLAlchemy 1.4。 - 需要包含基础的CRUD方法create, get_by_id, list, update, delete。 - 假设模型的主键字段名为 id。 请只输出仓库类的代码。 repo_code self.call_agent(repo_prompt, agent_typerepository_generator) self.shared_context[generated_code][repositories.py] repo_code # 步骤3汇总输出 print(任务执行完毕。生成文件如下) for filename, code in self.shared_context[generated_code].items(): print(f\n--- {filename} ---) print(code) def call_agent(self, prompt, agent_type): # 这里根据agent_type调用不同的智能体实现为简化示例我们复用之前的简单调用 llm OpenAI(model_namegpt-3.5-turbo-instruct, temperature0.1) # 实际应用中这里会分发到不同的、带有特定Prompt的工具或链 return llm(prompt) def extract_class_name(self, code): # 一个非常简单的正则匹配实际应用需考虑更多边界情况 import re match re.search(rclass\s(\w), code) return match.group(1) if match else UnknownModel # 使用编排器 orchestrator SimpleOrchestrator() orchestrator.run_workflow(需要一个表示‘产品’的模型包含id、名称、描述、价格和库存数量。)这个简单的编排器演示了核心思想任务分解、顺序执行、上下文传递。在真实场景中你会使用更强大的框架如LangChain的SequentialChain、TransformChain或直接使用Dify、AutoGPT等平台的编排能力来实现更复杂、带条件分支的流程。3.4 集成验证与质量门禁生成的代码不能直接信任。必须在流程中嵌入质量检查点。代码风格检查在智能体生成代码后自动调用black格式化、isort导入排序和flake8或pylint静态检查。如果检查不通过可以将错误信息反馈给同一个智能体要求其修正。这形成了一个“生成-检查-修正”的微循环。import subprocess import tempfile def validate_and_fix_python_code(code: str, max_retries3) - str: for i in range(max_retries): # 1. 写入临时文件 with tempfile.NamedTemporaryFile(modew, suffix.py, deleteFalse) as f: f.write(code) temp_file_path f.name # 2. 运行代码风格检查 try: subprocess.run([flake8, temp_file_path], checkTrue, capture_outputTrue) print(代码风格检查通过。) return code # 检查通过返回原代码 except subprocess.CalledProcessError as e: print(f代码风格检查失败第{i1}次尝试: {e.stderr.decode()}) # 3. 将错误信息反馈给修正智能体 fix_prompt f 以下Python代码存在风格或语法问题请修正它。 错误信息 {e.stderr.decode()} 原代码 python {code} 请只输出修正后的完整代码。 # 调用一个专门的“代码修正智能体” llm OpenAI(temperature0) code llm(fix_prompt) # 清理临时文件 os.unlink(temp_file_path) continue raise Exception(f经过{max_retries}次尝试仍无法修复代码。)生成单元测试可以训练一个专门的“测试生成智能体”它读取生成的业务代码然后为其生成对应的单元测试框架。这不仅能验证代码逻辑也为后续维护提供了保障。依赖冲突检查如果生成的代码引入了新的import可以检查其是否与项目已有的requirements.txt或pyproject.toml中的依赖版本冲突。实操心得验证环节是保证整个系统可靠性的“安全网”。一开始可以设置得宽松一些比如只做语法检查。随着对智能体生成质量的信心增加再逐步加入更严格的规则如复杂度检查、安全漏洞扫描。记住目标是“辅助”和“增强”而不是用完美的标准扼杀生产力。允许一定程度的“不完美”通过迭代快速改进往往比追求一次生成完美代码更有效率。4. 高级模式与优化策略当基础框架跑通后你可以考虑引入更高级的模式来提升系统的能力和效率。4.1 智能体专业化与分层设计不要试图用一个“万能智能体”解决所有问题。应该设计一系列专业化的智能体架构智能体负责高层设计决策比如“应该采用微服务还是单体”、“数据库选型是什么”。它基于项目需求和约束性能、团队技能、预算来提供建议。模块生成智能体负责生成具体的代码模块如“用户认证模块”、“支付网关集成模块”。它调用更底层的智能体来完成具体文件生成。代码片段智能体最底层的劳动者负责生成符合规范的函数、类、API路由等。它们被上层的智能体调度。测试智能体专门生成单元测试、集成测试。文档智能体根据代码生成API文档、部署文档。这种分层设计使得系统更易于管理和优化。你可以单独改进“代码片段智能体”的Prompt而不会影响高层的架构逻辑。4.2 基于向量数据库的上下文增强当项目规模变大上下文信息代码库、文档、决策记录太多无法全部塞进模型的Token限制时就需要用到检索增强生成RAG技术。知识库嵌入将项目所有的源代码文件、文档、会议纪要等文本进行分块并使用嵌入模型如OpenAI的text-embedding-ada-002转换为向量存入向量数据库如Chroma、Pinecone、Weaviate。相关性检索当智能体需要执行任务时例如“为ProductService添加一个根据关键词搜索的方法”先将这个任务描述转换为向量然后在向量数据库中搜索与之最相关的代码片段例如已有的UserService搜索方法、Product模型定义、相关的API文档。上下文注入将检索到的Top K个最相关的代码片段或文档作为“参考示例”或“背景信息”插入到发给Codex的Prompt中。这相当于给了模型一个“项目记忆”使其生成的内容与现有代码库高度契合。# 伪代码示例使用LangChain和Chroma实现RAG from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载并分割项目代码 text_splitter RecursiveCharacterTextSplitter(chunk_size1000, chunk_overlap200) docs ... # 从文件系统加载所有.py, .md等文件并分割 # 2. 创建向量存储 vectorstore Chroma.from_documents(documentsdocs, embeddingOpenAIEmbeddings()) # 3. 检索相关上下文 retriever vectorstore.as_retriever(search_kwargs{k: 4}) relevant_docs retriever.get_relevant_documents(如何实现一个带过滤和分页的产品查询服务) # 4. 将检索到的文档内容作为上下文拼接到Prompt中 context \n\n.join([doc.page_content for doc in relevant_docs]) enhanced_prompt f 参考我们项目中类似的代码模式 {context} 现在请基于以上模式为ProductService实现一个search_products方法支持关键词过滤和分页。 4.3 人类在环Human-in-the-loop与持续学习全自动生成是理想但现阶段“人类在环”是保证质量不可或缺的一环。系统应该设计得易于人类干预审核点在关键节点如生成核心领域模型、架构决策设置人工审核。智能体生成多个备选方案由开发者选择或修改最佳的一个。反馈循环当开发者修改或拒绝了智能体生成的代码时这个行为应该被记录并作为反馈。例如如果开发者总是把智能体生成的findUserById改名为get_user_by_id那么系统可以学习到这个命名偏好并调整后续生成。示例库积累被人工采纳和修改后的高质量代码应该被自动清洗、标注并加入到向量知识库中作为未来生成更高质量代码的“黄金标准”样本。这使得系统能够随着项目进展而不断进化越来越贴合团队的习惯和项目的独特需求。5. 常见挑战、陷阱与应对策略在实际落地“harness-engineering”的过程中你会遇到一系列预料之中和预料之外的挑战。以下是一些典型问题及我们的应对经验。5.1 生成代码的“幻觉”与不一致性问题Codex有时会“捏造”不存在的库、API或属性。例如它可能生成db.query(User).filter_by_name(...)这样的代码而你的项目里User模型可能根本没有filter_by_name方法或者ORM的语法完全不同。此外不同时间生成的代码可能在风格、结构上不一致。应对策略强约束Prompt在Prompt中明确指定技术栈、版本和关键约束。例如“使用SQLAlchemy 2.0风格仅使用异步APIasync_session模型类来自models模块。”提供有限上下文不要给模型开放式的上下文。在RAG检索时只提供最相关、最确定的代码片段作为参考避免引入过时或不相关的模式。模式固化与模板化对于高度重复的模式如CRUD接口、REST控制器不要每次都从头生成。可以预先定义好代码模板Jinja2、字符串格式化让智能体只填充其中的变量部分如类名、属性名。这能极大提高一致性和可靠性。即时语法与导入验证在生成后立即运行一个轻量级的语法检查如Python的ast.parse和导入语句验证尝试模拟导入在代码被执行或保存前就捕获低级错误。5.2 复杂逻辑与业务规则的捕捉问题AI不擅长处理深层的、隐含的业务逻辑。例如“用户下单后如果使用优惠券则需验证优惠券是否在有效期内且适用于该商品品类同时更新库存库存不足时触发预警。”这种包含多个条件分支和状态变更的复杂规则仅靠自然语言描述很难让AI一次性生成正确、完整的代码。应对策略分而治之不要试图用一个Prompt描述整个复杂流程。将其分解为一系列原子任务由编排器依次调度智能体完成任务1生成“优惠券验证”服务方法。任务2生成“库存检查与扣减”服务方法。任务3生成“订单创建”主服务方法它调用前两个方法。任务4生成“库存预警”事件处理器。使用领域特定语言DSL或伪代码对于核心业务规则可以先让业务分析师或架构师用更结构化的方式如决策表、状态机图、简单的DSL定义清楚。然后可以训练一个专门的智能体将这种结构化描述转换为目标代码。这比纯自然语言更精确。测试驱动生成先让“测试智能体”根据业务规则描述生成一组测试用例包括正常情况和各种边界情况。然后让“代码生成智能体”以满足这些测试用例为目标来生成实现代码。这相当于用测试用例来精确框定AI的生成范围。5.3 成本控制与性能优化问题频繁调用大型语言模型API成本不菲且生成复杂代码可能耗时较长影响开发体验。应对策略分层模型使用不是所有任务都需要最强大、最贵的模型。可以将任务分类简单模式填充如根据字段列表生成数据类使用更小、更快的模型如gpt-3.5-turbo-instruct。复杂逻辑推理与设计如架构决策、算法设计使用能力更强的模型如gpt-4。代码修正与重构可以使用专门在代码上微调过的、性价比更高的开源模型如CodeLlama系列通过本地部署来控制成本。缓存与复用对于常见的、确定的生成任务如根据相同的数据库Schema生成模型其结果可以缓存起来。下次遇到相同或高度相似的任务时直接使用缓存结果避免重复调用API。Prompt压缩与优化精心设计Prompt移除冗余信息使用更简洁、高效的表达。定期审查和迭代Prompt用更少的Token达到相同或更好的效果。异步与批处理对于不要求实时反馈的生成任务如批量生成数据迁移脚本、为整个模块生成单元测试可以将其放入队列进行异步处理或批量提交避免阻塞主开发流程。5.4 安全与合规风险问题AI生成的代码可能引入安全漏洞如SQL注入、硬编码密钥、许可证冲突或不符合内部合规要求。应对策略安全扫描集成在代码生成和验证流水线中必须集成静态应用安全测试SAST工具如banditPython、ESLintwith security pluginsJavaScript。任何生成的代码都必须通过基础的安全检查才能被接受。依赖审计智能体生成的代码中若包含import或require新依赖必须触发自动化的依赖许可证扫描如使用license-checker和已知漏洞检查如集成npm audit或safety check。敏感信息检测在代码被保存前运行正则表达式或专用工具检查是否意外生成了硬编码的密码、API密钥、内部IP地址等敏感信息。合规规则编码将内部的编码规范、安全基线以机器可读的规则形式如自定义的pylint插件、Semgrep规则嵌入到验证流程中自动拒绝不符合规范的代码。6. 从实验到生产规模化落地的思考将“harness-engineering”从个人玩具升级为团队乃至公司的生产力工具需要跨越工程化、协作和文化三道鸿沟。工程化整合智能体系统不能是独立于现有开发流程的“外星科技”。它必须深度集成到版本控制Git、持续集成/持续部署CI/CD、项目管理Jira、Asana和文档系统中。例如可以开发一个Git钩子当开发者提交一个描述新功能的Markdown文件时自动触发智能体工作流生成初步的代码草案并创建Pull Request。团队协作与知识共享智能体生成代码的“风格”和“决策”应该代表团队的共识而非个人偏好。因此需要建立团队共享的Prompt库、代码模板库和知识库。每次有新的最佳实践被团队采纳都应该同步更新这些共享资源。可以设立一个“提示词工程师”或“AI流程负责人”的角色负责维护和优化这些核心资产。文化转变与技能升级最大的阻力往往不是技术而是人。开发者可能会担心被AI取代或者不信任AI生成的代码。管理者和技术领导者需要明确传达AI是“副驾驶”目标是消除繁琐让开发者能更专注于高价值的架构设计、复杂问题解决和创新。同时为团队提供培训提升大家的“提示工程”能力、代码审查能力现在需要审查AI的产出和系统设计能力这些是在智能体时代更重要的技能。我个人在推动这类系统落地时的体会是起步阶段一定要选择“高重复性、低风险”的场景作为切入点比如生成数据库模型、DTO数据传输对象、简单的CRUD API、单元测试脚手架、部署配置文件Dockerfile, docker-compose.yml等。在这些场景取得立竿见影的效果建立团队信心然后再逐步向更复杂的业务逻辑领域推进。记住目标不是创造一个能完全替代人类的“自动程序员”而是打造一个能够与人类开发者无缝协作、极大提升整体交付速度和质量的“增强智能工程系统”。这条路很长但每一步都值得。