基于LLM多智能体框架的翼型设计风险感知与自动化实践 1. 项目概述当大模型智能体遇上传统翼型设计最近和几个在航空航天院所搞气动设计的老朋友聊天他们都在为一个事儿头疼新项目周期压得越来越紧但传统的翼型设计流程从初步构型、CFD计算流体力学仿真、再到多学科优化和风险评估链条长、迭代慢而且高度依赖资深工程师的经验。一个参数的微小调整可能需要在多个软件和团队间来回传递数据做大量的重复性仿真来验证效率瓶颈非常明显。与此同时我看到AI领域特别是基于大语言模型LLM的多智能体框架正火得不行大家都在琢磨怎么把这些“聪明的”AI助手用到具体的工程场景里。我就在想能不能把这两件事结合起来于是就有了这个探索性的想法基于LLM的多智能体框架在翼型设计中的风险感知集基工程应用。简单来说这不是要取代工程师而是想打造一个“AI设计协作战队”。这个战队里有专门负责解读设计需求的“需求分析智能体”有精通CFD仿真设置的“仿真专家智能体”有能从海量历史数据里挖宝的“数据挖掘智能体”还有一个时刻绷紧安全弦的“风险感知智能体”。它们在一个统一的“集基”我理解为集成化、基于知识的平台上协同工作共同完成从概念到初步验证的翼型设计任务。核心目标就一个利用多智能体的分工协作与LLM的语义理解、逻辑推理能力将工程师从繁琐、重复的流程性工作中解放出来并提前识别设计中的潜在风险加速设计迭代让专家能更专注于创造性的决策。这听起来有点“未来感”但其实每一步都有现实的技术支撑。LLM不再是那个只会聊天的“鹦鹉”通过特定的提示工程Prompt Engineering和工具调用Function Calling它可以理解“最大升力系数”、“失速特性”、“跨音速阻力发散”这些专业术语并按照预设的规则去调用仿真软件、查询数据库。多智能体框架则负责给这些“AI专家”分派角色、制定协作规则、管理对话状态。而“风险感知”是这个系统的灵魂它要求智能体不仅能执行任务还要能对自身输出的不确定性、对设计参数偏离安全边界的可能性进行“感知”和“预警”。如果你是一名气动设计工程师正苦于如何提升效率或者是一名AI应用开发者想寻找LLM落地工业场景的突破口亦或是对数字化工程、智能设计感兴趣的研究者那么这次结合了传统工程智慧和前沿AI技术的探索或许能给你带来一些新的思路和可参考的实践路径。2. 核心思路与框架设计构建一个懂工程的AI团队要让AI真正辅助翼型设计不能只靠一个“万能”的大模型。翼型设计本身就是一个多阶段、多学科、强耦合的复杂过程涉及空气动力学、结构力学、优化理论等多方面知识。一个智能体很难面面俱到且容易在复杂任务中“迷失”。因此采用多智能体框架是更合理的选择。其核心思路是**“分而治之协同进化”**——将宏大的设计任务分解为一系列子任务由各具专长的智能体负责并通过有效的通信与协作机制共同推进任务完成。2.1 多智能体框架的选型与角色定义目前开源的多智能体框架不少例如AutoGen、CrewAI、ChatDev等。在这个项目中我倾向于选择CrewAI。原因在于CrewAI的“Crew”团队、“Agent”成员、“Task”任务概念与我们的工程团队模型高度契合其角色定义清晰任务流程直观更适合构建有明确分工的协作系统。相比之下AutoGen更侧重于智能体间的自由对话在需要严格流程控制的工程场景中管理复杂度可能会更高。基于CrewAI我为这个翼型设计协作战队定义了四个核心智能体角色需求解析与任务规划智能体这是团队的“项目经理”。它的核心能力是理解自然语言描述的设计需求例如“设计一个适用于亚音速通航飞机、巡航马赫数0.6、高升阻比且具备良好失速特性的翼型”并将其拆解为具体的、可执行的设计目标如目标升力系数Cl、目标阻力系数Cd、失速迎角范围等和任务序列先进行参数化建模再进行初步CFD评估然后进行敏感性分析...。参数化建模与几何生成智能体这是团队的“造型师”。它精通翼型的参数化表示方法如NACA系列解析式、B样条曲线控制点、CSTClass-Shape Transformation方法等。给定一组设计参数如最大厚度、最大弯度、前缘半径等它能生成精确的翼型坐标点并输出为CFD软件如OpenFOAM、Fluent可识别的几何文件格式如IGES、STL。CFD仿真与后处理智能体这是团队的“分析师”。它负责自动化CFD仿真流程。任务包括根据翼型几何和飞行条件马赫数、雷诺数、迎角自动生成计算网格、设置湍流模型和边界条件、提交计算任务、监控求解过程并在计算完成后自动提取关键气动性能数据升力、阻力、力矩系数、压力分布云图等。它需要集成外部仿真软件的命令行接口或API。风险感知与多目标评估智能体这是团队的“安全官”兼“评审员”。这是整个系统的关键。它不直接参与设计生成和仿真而是持续监控整个流程中的数据流和决策点。它的职责包括性能风险感知实时评估当前设计点的气动性能是否满足约束如是否出现流动分离、激波位置是否不利、升阻比是否达标。过程风险感知监控CFD仿真是否收敛、网格质量是否可靠、参数是否超出常规经验范围。多目标权衡基于提取的性能数据评估不同设计目标如升阻比 vs. 失速特性之间的冲突给出权衡建议。不确定性量化对关键输入参数如湍流模型常数、网格密度进行敏感性分析评估输出结果的可信度区间。这四个智能体通过一个共享的“工作区”可以是数据库、共享内存或消息队列交换数据如翼型坐标、性能数据、评估报告并通过框架内建的协调机制在CrewAI中是通过“Process”来定义任务执行顺序和依赖关系来有序推进工作。2.2 LLM如何赋能从“聊天”到“干活”LLM在这里扮演的是每个智能体的“大脑”或“决策核心”。但它不是凭空工作的我们需要为其搭建一个“工具箱”并制定“工作手册”。工具调用Function Calling这是LLM与外部世界交互的手。我们将工程软件的功能封装成一个个工具函数。例如generate_airfoil_geometry(params): 调用参数化建模程序生成几何。run_cfd_simulation(config_file): 提交CFD计算任务。query_design_database(condition): 从历史设计案例库中检索相似案例。calculate_performance_metrics(raw_data): 从CFD结果文件中提取并计算性能指标。 LLM根据对话上下文和任务目标决定调用哪个工具并生成正确的调用参数。提示工程Prompt Engineering这是LLM的“工作手册”。我们需要为每个智能体角色编写详细的系统提示词System Prompt明确其身份、职责、专业知识范围和行动规范。例如给“风险感知智能体”的提示词可能包含“你是一名资深气动安全评估专家。你的任务是审查翼型设计过程中的所有中间数据和最终结果识别潜在风险。你必须熟知以下知识1. NACA 6系列翼型在最大厚度超过12%时跨音速性能可能恶化。2. 前缘半径过小可能导致低雷诺数下过早失速。3. CFD仿真中y值远大于1或小于1都可能影响壁面摩擦阻力预测的准确性。当你看到[数据]时你需要检查[指标]并与[阈值]对比。如果发现异常你的输出必须以‘【风险预警】’开头并清晰说明风险点、可能原因和建议措施。”通过这种“角色定义工具赋能提示引导”的三重方式我们将通用的LLM“驯化”成了各个工程领域的“专业助手”。2.3 “集基工程”的内涵集成化与知识化平台“集基”在这里我理解为“集成化”和“基于知识”的双重含义。集成化这个框架不是一个孤立的AI程序而是一个集成平台。它需要无缝集成现有的工程工具链参数化建模软件如Python的pyAirfoil库、CFD求解器如OpenFOAM、网格生成工具如gmsh、数据管理系统和可视化工具。多智能体框架作为“总控大脑”负责调度这些工具。基于知识系统的智能不仅来自LLM的预训练知识更来自注入的领域知识。这包括结构化知识翼型设计手册、气动数据库、材料属性库、设计规范如适航条例中的部分气动要求。非结构化知识历史项目报告、仿真案例、专家经验总结以文本形式存在。过程知识成功的设计流程模板、常见的错误排查清单。 这些知识可以通过向量数据库如ChromaDB, Weaviate进行存储和检索供智能体在需要时查询参考从而实现“经验”的传承和复用。3. 系统实现与关键技术拆解理论说得再多不如一行代码。下面我将以一个简化的设计场景为例拆解如何利用CrewAI和Qwen通义千问这样的LLM来搭建这个系统的核心部分。我们假设一个简化目标给定一个初始NACA翼型通过调整最大厚度和最大弯度两个参数在固定迎角下寻求升阻比最大化同时满足最小升力系数约束。3.1 智能体定义与工具封装首先定义智能体并为他们装备工具。这里以“CFD仿真智能体”和“风险感知智能体”为例。# 示例工具函数定义 import subprocess import json import numpy as np from typing import Dict, Any class CFDTools: CFD仿真工具集 staticmethod def generate_mesh(airfoil_coords: list, output_path: str) - bool: 调用外部网格生成工具例如通过Python接口调用gmsh # 此处简化实际应生成网格文件 print(f“正在为翼型生成网格输出到 {output_path}”) # ... 调用 gmsh API 或执行命令行 ... return True staticmethod def run_openfoam_case(case_dir: str) - Dict[str, Any]: 在指定目录运行OpenFOAM算例 try: # 假设 case_dir 下已有完整的OpenFOAM算例文件 result subprocess.run([“cd”, case_dir, “”, “simpleFoam”], capture_outputTrue, textTrue, timeout300) if result.returncode 0: return {“status”: “success”, “log”: result.stdout} else: return {“status”: “failed”, “error”: result.stderr} except subprocess.TimeoutExpired: return {“status”: “timeout”, “error”: “CFD计算超时”} staticmethod def extract_forces(log_file: str) - Dict[str, float]: 从OpenFOAM日志文件中提取升力、阻力 # 简化解析逻辑 with open(log_file, ‘r’) as f: lines f.readlines() # ... 实际应解析特定的输出行 ... cl, cd 0.5, 0.01 # 示例值 return {“Cl”: cl, “Cd”: cd, “L/D”: cl/cd if cd !0 else 0} class RiskAssessmentTools: 风险评估工具集 staticmethod def check_performance_constraints(performance: Dict, constraints: Dict) - Dict: 检查性能是否满足约束 violations [] if performance.get(“Cl”, 0) constraints.get(“min_Cl”, 0): violations.append(f“升力系数{performance[‘Cl’]}低于最低要求{constraints[‘min_Cl’]}”) if performance.get(“Cd”, float(‘inf’)) constraints.get(“max_Cd”, 0.05): violations.append(f“阻力系数{performance[‘Cd’]}超过最高限制{constraints[‘max_Cd’]}”) return {“passed”: len(violations)0, “violations”: violations} staticmethod def retrieve_similar_cases(airfoil_params: Dict, top_k: int3) - list: 从向量数据库中检索相似历史案例 # 连接向量数据库查询相似设计参数的历史案例及其性能 # 返回格式[{“params”: {...}, “performance”: {...}, “lessons”: “...”}, ...] return [] # 示例使用CrewAI定义智能体 from crewai import Agent, Task, Crew, Process from langchain_openai import ChatOpenAI # 这里以OpenAI为例实际可用Qwen等 # 1. 定义LLM实际部署时替换为本地Qwen等模型 llm ChatOpenAI(model“gpt-4”, temperature0.1) # temperature调低使输出更确定 # 2. 定义CFD仿真智能体 cfd_agent Agent( role‘CFD仿真专家’, goal‘准确、高效地完成指定翼型的CFD气动性能仿真并提取可靠数据’, backstory“””你是一名拥有十年经验的CFD工程师精通OpenFOAM、Fluent等工具 对网格划分、湍流模型选择、边界条件设置和结果后处理有深刻理解。你注重仿真流程的 规范性和结果的可重复性。“””, tools[CFDTools.generate_mesh, CFDTools.run_openfoam_case, CFDTools.extract_forces], llmllm, verboseTrue ) # 3. 定义风险感知智能体 risk_agent Agent( role‘气动风险感知与评估专家’, goal‘识别设计过程中的性能风险、过程风险并提供预警和改进建议’, backstory“””你是一名严谨的安全评审官具有敏锐的风险嗅觉。你熟知各类翼型的 失速特性、跨音速流动规律以及CFD仿真中常见的数值误差来源。你不轻易放过任何 一个可疑的数据点。“””, tools[RiskAssessmentTools.check_performance_constraints, RiskAssessmentTools.retrieve_similar_cases], llmllm, verboseTrue )3.2 任务编排与协同流程定义了智能体之后需要为他们创建任务并编排执行顺序。这是多智能体协作的核心。# 定义任务 # 任务1CFD仿真任务 cfd_task Task( description“””对给定的翼型几何文件 {airfoil_file} 在如下条件下进行CFD仿真 马赫数: {mach}, 雷诺数: {reynolds}, 迎角: {aoa}度。 请完成网格生成、求解设置、运行计算并最终提取升力系数(Cl)、阻力系数(Cd)和压力分布数据。 将提取的性能数据以JSON格式保存。“””, agentcfd_agent, expected_output“一个包含Cl, Cd, L/D等关键性能指标的JSON字典以及仿真成功与否的状态。” ) # 任务2风险评估任务依赖于CFD任务的结果 risk_task Task( description“””基于CFD仿真任务提供的性能数据 {performance_data} 和设计约束 {constraints} 进行全面的风险评估。你需要 1. 检查性能指标是否满足所有约束条件。 2. 与历史相似案例进行对比判断当前设计是否处于合理区间。 3. 评估CFD仿真过程日志 {cfd_log} 中是否有异常警告如发散、网格质量差。 4. 输出一份风险评估报告明确指出任何潜在风险点并按高、中、低分级。 5. 如果发现高风险项必须给出具体的调整建议例如建议减小前缘半径以改善失速特性。“””, agentrisk_agent, context[cfd_task], # 此任务需要等待cfd_task完成 expected_output“一份详细的风险评估报告包含风险项列表、等级、依据和建议措施。” ) # 组建团队并运行 design_crew Crew( agents[cfd_agent, risk_agent], tasks[cfd_task, risk_task], processProcess.sequential, # 顺序执行cfd_task先于risk_task verbose2 ) # 运行设计流程 inputs { “airfoil_file”: “naca2412.dat”, “mach”: 0.6, “reynolds”: 5e6, “aoa”: 2.0, “constraints”: {“min_Cl”: 0.4, “max_Cd”: 0.015} } result design_crew.kickoff(inputsinputs) print(result)在这个流程中cfd_task先执行执行完毕后其输出性能数据、日志会自动作为上下文传递给risk_task。风险感知智能体收到这些数据后调用它的工具函数进行检查、比对、分析最终生成风险评估报告。这种依赖关系确保了风险评估是基于真实的仿真结果而不是凭空臆断。3.3 风险感知的具体实现逻辑风险感知是灵魂其实现质量直接决定系统的实用性。它不仅仅是事后检查更应追求事中预警。我们可以从以下几个层面构建感知能力规则库匹配这是最直接的方法。建立一套“IF-THEN”规则库。IF 最大厚度/弦长 0.15 AND 马赫数 0.7 THEN 风险“厚度过大可能导致强激波增加波阻”。IF 前缘半径 0.005 AND 雷诺数 1e6 THEN 风险“前缘过尖低雷诺数下易导致层流分离泡破裂引发过早失速”。IF CFD残差曲线在迭代后期仍不下降或震荡 THEN 风险“求解可能未充分收敛结果可信度低”。 这些规则可以编码在RiskAssessmentTools的方法中由LLM驱动执行。数据驱动异常检测利用历史成功/失败案例数据训练简单的分类或异常检测模型如One-Class SVM、Isolation Forest。将当前设计参数或中间性能指标输入模型判断其是否偏离“正常”设计集群。这可以捕捉到那些未在明确规则中定义但实际存在风险的“异常模式”。基于LLM的语义推理与报告生成这是LLM的强项。将规则检查结果、异常检测分数、仿真日志文本、历史案例文本描述一并输入给风险感知智能体。LLM可以综合这些多源、异构的信息生成一段连贯、易懂、有洞察力的风险评估文本指出最可能的风险根源而不仅仅是罗列报警项。例如LLM可能生成“【风险预警-中级】当前设计最大厚度12%弯度4%在Ma0.65时CFD结果显示上翼面后缘出现了轻微的压力平台且升力曲线斜率略低于同类NACA 6系列翼型的历史平均值。综合分析这可能是由于当前厚度下翼型上表面加速不足导致边界层抗分离能力稍弱。建议可尝试将最大厚度位置略微前移从30%弦长移至25%或微增前缘半径2%以改善前缘吸力峰和上表面速度分布。已检索到3个类似调整的成功案例可供参考。”这种结合了规则明确知识、数据隐式模式和语义推理综合解释的三层风险感知体系比单一方法更全面、更智能。4. 实操部署、调试与优化心得将这样一个系统从概念落到实际可运行的代码会遇到不少挑战。下面分享一些我在搭建和调试过程中的关键步骤与心得。4.1 环境搭建与本地LLM部署为了确保可控性和数据安全工程应用通常倾向于本地部署LLM。模型选型Qwen、ChatGLM、Baichuan等国内优秀开源模型是首选。考虑到工程领域需要较强的逻辑和指令跟随能力Qwen-7B/14B-Chat或Qwen1.5-7B/14B-Chat版本是不错的起点。它们对中文提示词理解好且支持工具调用格式如OpenAI Function Calling格式。部署框架推荐使用Ollama或LM Studio。Ollama部署和管理极其简单一条命令ollama run qwen:7b即可拉取并运行模型并提供一个兼容OpenAI API的本地端点http://localhost:11434/v1方便CrewAI等框架直接调用。LM Studio则提供了更图形化的模型管理和对话测试界面。硬件要求7B模型在16GB内存的机器上可流畅运行14B模型建议32GB内存。使用GPU如NVIDIA RTX 3090/4090能极大提升推理速度。务必确保有足够的硬盘空间存放模型文件7B约4-5GB14B约8-10GB。部署完成后将CrewAI中LLM的配置指向本地端点即可from langchain_openai import ChatOpenAI # 将base_url指向Ollama的API地址 llm_local ChatOpenAI(base_url“http://localhost:11434/v1”, api_key“ollama”, model“qwen:7b”)4.2 工具链集成与封装技巧工程软件如OpenFOAM、Pointwise通常通过命令行或特定文件进行交互。封装的关键在于鲁棒性和错误处理。使用子进程封装命令行工具如前文CFDTools.run_openfoam_case所示使用Python的subprocess模块。务必设置超时timeout参数并捕获标准输出和错误输出stdout,stderr以便后续分析。参数化模板文件CFD仿真需要大量配置文件如OpenFOAM的controlDict,fvSchemes。不要用代码硬拼接字符串。最佳实践是创建模板文件使用Jinja2这样的模板引擎进行渲染。from jinja2 import Template with open(‘templates/controlDict.template’, ‘r’) as f: tmpl Template(f.read()) rendered tmpl.render(endTime1000, writeInterval100) with open(‘case/system/controlDict’, ‘w’) as f: f.write(rendered)状态检查与重试机制工具调用可能因各种原因资源不足、临时文件锁失败。在工具函数中加入状态检查如检查目标文件是否生成和简单的重试逻辑如最多重试3次能显著提升系统稳定性。4.3 提示词工程让LLM更“专业”为工程智能体编写提示词不同于通用聊天。核心原则是明确、具体、结构化、提供范例。结构化输出要求明确要求LLM以特定格式如JSON、Markdown表格输出便于后续程序自动解析。例如在任务描述中写明“请以以下JSON格式输出性能数据{“Cl”: value, “Cd”: value, “converged”: bool}”提供少样本示例Few-shot在提示词中直接给出一两个输入输出的例子能极大提升LLM遵循复杂指令的能力。例如在风险感知智能体的提示词中加入 “示例1 输入{“Cl”: 0.35, “Cd”: 0.018}, 约束{“min_Cl”: 0.4} 你应输出{“risk_level”: “high”, “message”: “升力系数0.35低于约束值0.4不满足基本升力要求。”}示例2...”分步骤思考Chain-of-Thought对于复杂判断引导LLM展示推理过程。这不仅能提高准确性也便于我们调试其逻辑。在提示词中要求“请按以下步骤分析1. 提取关键性能指标。2. 逐条比对设计约束。3. 查询历史数据区间。4. 综合给出风险判断和理由。”4.4 调试与迭代从“跑通”到“好用”系统初步搭建后会经历一个密集的调试和迭代期。从简单场景开始不要一开始就挑战复杂的三维机翼优化。从一个最简化的二维翼型、单点设计固定迎角、马赫数开始确保智能体能正确调用工具、传递数据、完成闭环。日志是生命线为每个智能体的决策过程、工具调用输入输出、LLM的原始回复都添加详细日志。当出现错误或不符合预期的行为时这些日志是定位问题的唯一依据。CrewAI的verboseTrue参数会输出很多有用信息。人工监督与干预在初期设置“人在回路”的检查点。例如在风险智能体给出高风险预警后暂停流程等待工程师确认。这既能保证安全也能收集人类专家的反馈用于优化提示词和规则库。持续优化提示词观察LLM的“错误”输出分析是知识不足、指令歧义还是逻辑错误。针对性地修改提示词补充知识澄清指令。这是一个持续的过程。5. 潜在挑战、应对策略与未来展望尽管前景诱人但在实际工程中应用这套系统必须清醒地认识到当前的局限和挑战。5.1 主要挑战与应对思路LLM的“幻觉”与不确定性LLM可能生成看似合理但完全错误的知识或建议这在工程领域是致命的。应对严格工具化。将LLM的“决策”范围限制在“选择调用哪个工具”和“解释工具结果”上而把核心计算、仿真、规则判断等确定性工作交给封装好的工具函数。LLM不“计算”升力系数它只“解读”计算出的升力系数。应对建立事实核查层。对于LLM生成的任何涉及具体数值、公式、结论的陈述都尝试用工具如查询数据库、调用计算库进行二次验证。计算成本与效率CFD仿真本身计算量巨大。多智能体间的多次对话和LLM推理也会带来额外开销。应对流程优化与缓存。避免不必要的重复仿真。使用代理模型如Kriging、神经网络或降阶模型对高保真CFD进行快速近似让智能体在代理模型空间进行大量探索仅对优选点进行高保真验证。应对异步与并行。设计可以并行的任务流。例如参数化建模智能体可以同时生成多个候选几何CFD智能体可以并行提交多个算例如果有足够计算资源。多智能体框架应支持异步任务调度。领域知识的深度与准确性LLM的通用知识无法覆盖所有细分领域的“深水区”经验。应对构建高质量的领域知识库。系统性地整理内部设计规范、仿真指南、故障案例、专家经验录并将其向量化存入知识库。让智能体在决策时优先检索和引用这些“权威”知识。应对专家反馈闭环。建立机制将智能体在项目中产生的决策和结果由专家进行评审和打分。这些反馈数据可以用来微调Fine-tuneLLM使其越来越“像”本单位的专家。系统集成与数据流转与现有CAD/CAE/PLM系统的集成是落地的一大难关。应对采用中间件和标准化接口。优先考虑通过API或标准文件格式如STEP, XML, JSON进行数据交换。可以开发轻量级的适配器将智能体平台的请求“翻译”成下游系统能理解的指令。5.2 未来可能的演进方向这次实践只是一个起点。随着技术和应用的深入这个框架可能会向以下几个方向演进从辅助到半自主当前系统仍需工程师给出明确的设计需求。未来智能体或许能根据更高层的任务目标如“设计一款省油的无人机机翼”自主拆解出气动、结构、重量等多学科子目标并协调更多的专业智能体如结构强度智能体、成本评估智能体进行协同设计与优化。强化学习与自适应优化将多智能体系统与强化学习结合。风险感知智能体的“预警”和评估结果可以作为优化智能体的“奖励信号”引导设计参数向更安全、更优的方向自动调整形成“感知-评估-优化”的自适应闭环。数字孪生中的实时感知在未来飞行器的数字孪生体中这样的多智能体框架可以扮演“在线健康管理”角色。实时接收来自传感器和仿真模型的数据由风险感知智能体持续评估当前和未来的安全状态实现预测性维护和飞行包线动态保护。最后一点个人体会构建这样一个系统最大的收获不是做出了一个多么智能的工具而是倒逼着自己和团队将过去模糊、依赖个人经验的工程知识变得清晰、结构化、可编码。这个过程本身就是对设计流程的一次深刻梳理和优化。即使AI智能体暂时还不能完全替代工程师但它作为一个永不疲倦的“协作者”和“提醒者”已经展现出了巨大的潜力。对于工程师而言拥抱它不是被替代而是让自己从重复劳动中解放出来去从事更具创造性的工作。这条路还很长但第一步不妨就从用一个智能体帮你自动化一个最繁琐的CFD后处理脚本开始。