AI工作流编排框架skill-conductor：从原理到实战的智能体开发指南

1. 项目概述与核心价值

最近在GitHub上看到一个挺有意思的项目，叫skill-conductor，作者是Samuelkebede24。光看名字，你可能会有点摸不着头脑，“技能指挥家”？这到底是干嘛的？我花了一些时间深入研究它的代码、文档和设计理念，发现这其实是一个面向AI应用开发，特别是基于大型语言模型（LLM）构建智能体（Agent）或工作流（Workflow）的编排框架。简单来说，它就像是一个乐队的指挥，负责协调和管理多个不同的“技能”（即AI能力或工具），让它们按照既定的乐谱（流程）和谐地演奏，最终完成复杂的任务。

在当前的AI开发浪潮中，我们经常遇到一个痛点：单个模型的能力是有限的。比如，一个文本生成模型可能不擅长数学计算，一个代码生成模型可能不懂如何调用外部API。为了构建真正强大的应用，我们往往需要将多个模型、工具、API甚至人工步骤串联起来。这个过程如果手动编码，会变得异常繁琐，代码耦合度高，难以维护和扩展。skill-conductor就是为了解决这个问题而生的。它提供了一套声明式的、可组合的框架，让开发者能够像搭积木一样，轻松定义和运行由多个技能组成的复杂流程。

这个项目特别适合以下几类人：一是正在探索AI智能体应用的开发者，厌倦了手动写胶水代码；二是希望将企业内部多个AI服务或工具集成到一个统一流程中的技术团队；三是研究者或学生，想要快速实验不同技能组合的效果。它的核心价值在于降低复杂AI工作流的开发门槛，通过清晰的抽象和可靠的执行引擎，让开发者能更专注于业务逻辑本身，而不是底层的调度和错误处理。

2. 核心架构与设计哲学拆解

要理解skill-conductor，首先得拆解它的核心架构。它的设计非常模块化，核心思想是将一个复杂的任务分解为一系列可执行的“技能”，然后通过一个“指挥家”来协调它们的执行顺序、处理它们之间的数据传递，并管理整个流程的状态。

2.1 核心概念解析

项目里有几个关键概念，理解了它们就理解了整个框架：

1. 技能（Skill）：这是最基本的执行单元。一个技能可以是一个调用OpenAI API的文本生成函数，一个执行数学计算的工具，一个查询数据库的操作，甚至是一个需要人工审核的节点。在skill-conductor中，每个技能都被封装成一个独立的、可复用的组件，它有明确的输入和输出定义。

2. 工作流（Workflow）：工作流是由多个技能按照特定逻辑（顺序、并行、条件分支、循环）组合而成的蓝图。它定义了“要做什么”以及“先做什么后做什么”，但不负责具体执行。你可以把工作流看作是一张流程图或一份乐谱。

3. 指挥家（Conductor）：这是框架的核心引擎。它的职责是加载工作流蓝图，实例化各个技能，根据蓝图逻辑驱动技能执行，在技能之间传递数据，并处理执行过程中可能出现的异常。指挥家确保了工作流能够从起点可靠地运行到终点。

4. 上下文（Context）：这是在工作流执行过程中流动的数据总线。当一个技能执行完毕后，它的输出会被写入上下文。下一个技能可以从上下文中读取它需要的数据作为输入。上下文保证了数据在不同技能间的无缝传递，避免了硬编码的数据依赖。

这种架构带来的最大好处是解耦和可观测性。技能开发者只需要关心自己的功能实现，无需知道它会被谁调用、输出会给谁用。工作流设计者可以像拼图一样组合技能，快速构建新流程。同时，由于执行过程被框架标准化，我们很容易在整个链条上加入日志、监控、性能追踪等能力，这对于调试和生产部署至关重要。

2.2 与同类方案的对比

市面上已经有一些工作流编排工具，比如 Apache Airflow、Prefect，以及更偏向AI的 LangChain、LlamaIndex。skill-conductor的定位有其独特之处。

与Airflow/Prefect相比，skill-conductor更轻量、更专注于AI技能的组合。Airflow是一个功能强大的任务调度平台，适合ETL等数据管道，但其学习曲线较陡，对于快速迭代的AI原型开发来说可能过于“重”了。skill-conductor的API设计更简洁，与Python生态的AI库（如OpenAI SDK）集成更直接。

与LangChain相比，skill-conductor的抽象层次有所不同。LangChain提供了极其丰富的“链”（Chain）和“智能体”（Agent）原语，功能强大但概念繁多，有时会让初学者感到困惑。skill-conductor的概念模型相对更简单、更统一（核心就是技能和工作流），可能更容易上手和理解。它更像是一个专注于“编排”的轻量级层，你可以很方便地将LangChain的链包装成一个skill，然后由skill-conductor来调度更复杂的工作流。

注意：选择框架永远是一个权衡。如果你需要LangChain生态中大量的现成工具和集成，那么直接使用LangChain可能更高效。但如果你想要一个更干净、更可控的编排层，或者你的工作流中包含大量非LLM的步骤（如数据库操作、API调用），skill-conductor这种更通用的编排思想可能会更合适。

3. 从零开始：快速上手与核心配置

理论讲得再多，不如动手跑一遍。我们来看如何快速搭建一个skill-conductor环境并运行你的第一个工作流。假设你已经有了Python环境。

3.1 环境安装与初始化

首先，通过pip安装。目前项目可能还在活跃开发中，最直接的方式是从GitHub克隆并安装。

# 克隆仓库 git clone https://github.com/Samuelkebede24/skill-conductor.git cd skill-conductor # 使用pip从本地安装（推荐用于开发和体验） pip install -e . # 或者，如果作者已发布到PyPI，也可以直接（未来可能） # pip install skill-conductor

安装完成后，我们来创建一个最简单的技能。在项目结构中，技能通常被定义在独立的模块中。我们创建一个my_skills.py文件：

# my_skills.py from skill_conductor.skill import Skill, SkillInput, SkillOutput from pydantic import BaseModel, Field # 定义技能的输入数据模型 class GreetingInput(SkillInput): name: str = Field(..., description="The name of the person to greet") # 定义技能的输出数据模型 class GreetingOutput(SkillOutput): message: str = Field(..., description="The generated greeting message") # 创建技能类 class GreetingSkill(Skill): # 定义技能的元数据：唯一标识、描述、输入输出模型 id = "greeting_skill" description = "A skill that generates a friendly greeting." input_model = GreetingInput output_model = GreetingOutput # 核心执行逻辑 async def execute(self, input_data: GreetingInput, context) -> GreetingOutput: # 从输入中获取名字 name = input_data.name # 生成问候语 greeting_message = f"Hello, {name}! Welcome to the world of Skill Conductor." # 返回输出 return GreetingOutput(message=greeting_message)

这个GreetingSkill技能非常简单：它接收一个名字，返回一句问候语。注意几个关键点：

1. 输入输出都使用Pydantic模型定义，这确保了类型安全和清晰的接口契约。
2. 技能继承自Skill基类，并必须实现id,description,input_model,output_model和execute方法。
3. execute方法是异步的（async），这有利于I/O密集型操作（如网络请求）的并发执行。

3.2 定义并运行你的第一个工作流

有了技能，我们需要创建一个工作流来使用它。工作流通常用YAML或JSON定义，这里我们用YAML，因为它更易读。创建my_first_workflow.yaml：

# my_first_workflow.yaml id: simple_greeting_workflow name: A Simple Greeting Workflow description: This workflow demonstrates a single skill execution. version: "1.0" skills: - id: greeting_skill # 必须与技能类中定义的id一致 type: GreetingSkill # 技能类的名称 config: {} # 可以传递技能特定的配置参数 flow: start: - to: greeting_skill greeting_skill: - to: end

这个工作流定义了一个线性流程：从start开始，执行greeting_skill，然后到end结束。

接下来，编写一个Python脚本来加载并执行这个工作流：

# run_workflow.py import asyncio import yaml from skill_conductor.conductor import Conductor from my_skills import GreetingSkill # 导入我们自定义的技能 async def main(): # 1. 初始化指挥家，并注册我们的技能 conductor = Conductor() conductor.register_skill(GreetingSkill()) # 2. 从YAML文件加载工作流定义 with open('my_first_workflow.yaml', 'r') as f: workflow_definition = yaml.safe_load(f) # 3. 创建初始上下文数据（即工作流的输入） initial_context = { "name": "Alex" # 这个数据会被映射到 greeting_skill 的输入 } # 4. 执行工作流 result_context = await conductor.execute_workflow( workflow_definition=workflow_definition, initial_context=initial_context ) # 5. 打印结果 print("Workflow execution completed!") print("Final context:", result_context) # 可以从上下文中取出特定技能的输出 if 'greeting_skill' in result_context: print("Greeting:", result_context['greeting_skill']['message']) if __name__ == "__main__": asyncio.run(main())

运行这个脚本，你应该能看到输出：

Workflow execution completed! Final context: {..., 'greeting_skill': {'message': 'Hello, Alex! Welcome to the world of Skill Conductor.'}} Greeting: Hello, Alex! Welcome to the world of Skill Conductor.

恭喜！你已经成功运行了第一个skill-conductor工作流。这个过程清晰地展示了框架的工作模式：定义技能 -> 组合成工作流 -> 由指挥家驱动执行。

4. 高级特性与复杂工作流构建

只会线性执行一个技能显然不够。skill-conductor的强大之处在于它支持构建包含条件判断、并行执行、循环等复杂逻辑的工作流。我们通过一个更贴近实际的例子来探索这些特性。

假设我们要构建一个“智能内容摘要与分发”工作流。它的功能是：给定一篇文章的URL，先抓取文章内容，然后调用AI模型生成摘要，同时分析文章的情感倾向，最后根据情感倾向决定是将摘要发送到Slack频道还是存档到数据库。

4.1 定义多个协同技能

首先，我们需要定义四个技能（这里用伪代码示意核心逻辑）：

1. FetchArticleSkill：从URL抓取文章正文。
2. SummarizeSkill：调用LLM（如GPT-4）生成文章摘要。
3. SentimentAnalysisSkill：调用情感分析API或模型判断文章情感（积极/消极/中性）。
4. DispatchSummarySkill：根据情感结果，选择不同的分发动作。

每个技能的定义方式与之前的GreetingSkill类似，都有明确的输入输出模型。例如，SummarizeSkill的输入可能是article_text，输出是summary。

4.2 设计复杂流程逻辑

现在，我们用YAML来设计这个包含分支的工作流：

# content_summary_workflow.yaml id: content_summary_workflow name: Content Summary and Dispatch Workflow description: Fetches an article, summarizes it, analyzes sentiment, and dispatches accordingly. skills: - id: fetch_article type: FetchArticleSkill - id: summarize type: SummarizeSkill - id: analyze_sentiment type: SentimentAnalysisSkill - id: dispatch_to_slack type: DispatchSummarySkill config: target: "slack" - id: dispatch_to_db type: DispatchSummarySkill config: target: "database" flow: start: - to: fetch_article fetch_article: - to: summarize - to: analyze_sentiment # 并行执行摘要和情感分析 summarize: # 这个节点执行完后，数据会存入上下文，但不决定下一步流向 - to: wait_for_dispatch_decision # 需要一个“等待”或“汇聚”节点 analyze_sentiment: - to: decide_dispatch # 情感分析结果用于决策 decide_dispatch: # 这是一个“条件”节点（需要框架支持或通过特定技能实现） # 假设框架支持基于上下文的条件路由 - condition: ${context.analyze_sentiment.sentiment == 'positive'} to: dispatch_to_slack - condition: default to: dispatch_to_db dispatch_to_slack: - to: end dispatch_to_db: - to: end wait_for_dispatch_decision: # 一个虚拟节点，等待dispatch节点完成后一起结束 - to: end

这个工作流展示了几个关键模式：

• 并行执行：fetch_article之后，summarize和analyze_sentiment可以同时进行，提高效率。
• 条件分支：decide_dispatch节点根据情感分析的结果，决定走哪条分发路径。
• 数据依赖：summarize技能需要fetch_article的输出，decide_dispatch需要analyze_sentiment的输出。框架的上下文机制自动处理了这些数据传递。

实操心得：在设计包含并行和条件分支的工作流时，要特别注意数据同步问题。在上面的例子中，dispatch_to_slack和dispatch_to_db都需要summarize技能产生的摘要。但摘要任务和情感分析是并行的，且摘要可能先完成。因此，我们需要确保在分发节点执行时，摘要数据已经就绪。示例中通过一个虚拟的wait_for_dispatch_decision节点来示意这种同步需求，在实际实现中，框架可能需要更精细的控制原语，或者需要在技能内部检查所需数据是否已在上下文中。

4.3 错误处理与重试机制

在生产环境中，任何步骤都可能失败（网络超时、API限额、临时错误）。一个健壮的工作流必须包含错误处理。skill-conductor通常允许在工作流或技能级别定义重试策略。

例如，我们可以在技能配置或工作流定义中为fetch_article添加重试逻辑：

skills: - id: fetch_article type: FetchArticleSkill config: retry_policy: max_attempts: 3 delay_seconds: 2 backoff_factor: 2 # 指数退避

这样，如果抓取文章失败，框架会自动重试最多3次，每次重试间隔按指数增长（2秒，4秒，8秒）。对于整个工作流，也可以定义全局的失败处理策略，比如某个技能最终失败后，是终止整个工作流，还是记录错误后继续执行其他分支，或者跳转到特定的补偿处理节点。

5. 实战：集成外部AI服务与自定义技能

skill-conductor的真正威力在于它能轻松集成各种外部服务。让我们以集成OpenAI API为例，创建一个更真实的SummarizeSkill。

5.1 创建集成OpenAI的摘要技能

首先，确保安装了OpenAI Python包：pip install openai。

# advanced_skills.py import os from openai import AsyncOpenAI from skill_conductor.skill import Skill, SkillInput, SkillOutput from pydantic import BaseModel, Field, SecretStr from typing import Optional class SummarizeInput(SkillInput): article_text: str = Field(..., description="The full text of the article to summarize") max_length: Optional[int] = Field(100, description="Maximum length of the summary") class SummarizeOutput(SkillOutput): summary: str = Field(..., description="The generated summary") model_used: str = Field(..., description="The OpenAI model used for generation") class SummarizeSkill(Skill): id = "summarize_openai" description = "Summarizes an article using OpenAI's GPT model." input_model = SummarizeInput output_model = SummarizeOutput def __init__(self, api_key: Optional[str] = None, model: str = "gpt-3.5-turbo"): super().__init__() # 可以从环境变量或配置中读取API Key self.api_key = api_key or os.getenv("OPENAI_API_KEY") if not self.api_key: raise ValueError("OpenAI API key must be provided via config or OPENAI_API_KEY environment variable.") # 初始化异步客户端 self.client = AsyncOpenAI(api_key=self.api_key) self.model = model async def execute(self, input_data: SummarizeInput, context) -> SummarizeOutput: article_text = input_data.article_text max_length = input_data.max_length # 构建给LLM的提示词（Prompt） prompt = f""" Please summarize the following article in no more than {max_length} words. Article: {article_text} Summary: """ try: response = await self.client.chat.completions.create( model=self.model, messages=[{"role": "user", "content": prompt}], temperature=0.5, # 控制创造性，摘要任务可以低一些 max_tokens=150 # 控制生成摘要的最大长度 ) summary = response.choices[0].message.content.strip() return SummarizeOutput( summary=summary, model_used=self.model ) except Exception as e: # 非常重要：技能执行必须妥善处理异常，并抛出框架能理解的错误 self.logger.error(f"OpenAI API call failed: {e}") # 可以抛出特定的异常，由工作流的错误处理策略来接管 raise RuntimeError(f"Summarization failed: {e}") from e

这个技能演示了几个高级要点：

1. 配置化：技能通过__init__方法接收配置（如API Key和模型名称），使得技能更灵活、可复用。
2. 异步操作：使用AsyncOpenAI客户端进行异步调用，避免阻塞工作流引擎，这在并发执行多个技能时性能优势明显。
3. 健壮的提示工程：构建了一个清晰的提示词（Prompt），指导模型完成任务。在实际应用中，提示词的设计直接决定输出质量，可能需要反复调试。
4. 错误处理：使用try-except块捕获API调用异常，并记录日志后重新抛出。这允许工作流层面的重试或失败处理机制介入。

5.2 在工作流中使用配置化技能

在YAML中，我们可以这样配置这个技能：

skills: - id: summarize type: SummarizeSkill config: model: "gpt-4" # 覆盖默认的gpt-3.5-turbo # api_key 可以从环境变量读取，不建议硬编码在YAML中

通过这种配置方式，我们可以轻松切换不同的模型，或者为开发、测试、生产环境配置不同的API密钥，而无需修改技能代码。

6. 部署、监控与性能考量

当你开发完成一个复杂的工作流后，下一步就是考虑如何将其部署到生产环境，并确保其稳定、可观测。

6.1 部署模式

skill-conductor作为一个库，可以嵌入到各种应用中：

1. 独立脚本：像我们之前的例子一样，在一个Python脚本中运行。适合简单的自动化任务或Cron作业。
2. Web服务：使用FastAPI、Flask等框架，将指挥家（Conductor）封装成REST API。前端或其他系统可以通过HTTP请求触发工作流执行。这是最常见的生产部署方式。
3. 消息队列驱动：将工作流执行请求发布到消息队列（如RabbitMQ、Redis Streams、Kafka），然后由后台Worker消费消息并执行。这种方式解耦性好，能处理高并发，并易于水平扩展Worker数量。

例如，一个基于FastAPI的简单服务可能长这样：

from fastapi import FastAPI, BackgroundTasks from skill_conductor.conductor import Conductor import yaml import asyncio app = FastAPI() conductor = Conductor() # ... 注册所有技能 ... with open('workflow.yaml') as f: WORKFLOW_DEF = yaml.safe_load(f) @app.post("/run-workflow/") async def run_workflow(initial_data: dict, background_tasks: BackgroundTasks): # 将执行任务放入后台，立即返回请求ID，实现异步执行 task_id = generate_task_id() background_tasks.add_task(execute_workflow_async, task_id, initial_data) return {"task_id": task_id, "status": "accepted"} async def execute_workflow_async(task_id: str, initial_context: dict): try: result = await conductor.execute_workflow(WORKFLOW_DEF, initial_context) # 将结果存储到数据库或缓存中，供客户端查询 save_result(task_id, "success", result) except Exception as e: save_result(task_id, "failed", {"error": str(e)})

6.2 可观测性与监控

对于生产系统，你必须知道工作流是否在正常运行，哪里慢了，哪里出错了。

1. 日志：确保每个技能都进行了恰当的日志记录。skill-conductor框架自身也应该提供执行轨迹的日志。使用结构化的日志格式（如JSON），方便后续收集到ELK或Loki等日志系统中。
2. 指标（Metrics）：收集关键指标，如每个技能的执行耗时、成功率、工作流的整体执行时间、并发执行数等。这些数据可以推送到Prometheus，并在Grafana中展示。
3. 分布式追踪：在微服务架构中，一个用户请求可能触发多个工作流，每个工作流又包含多个技能。使用OpenTelemetry等工具进行分布式追踪，可以清晰地看到一个请求的完整生命周期，快速定位性能瓶颈或故障点。

你可以在技能类的execute方法开始和结束时打点，或者更理想的是，通过框架的中间件或装饰器机制统一实现这些横切关注点。

6.3 性能优化技巧

• 技能异步化：尽可能将技能设计为异步的。如果技能内部涉及网络I/O（数据库查询、API调用），使用异步库（如aiohttp,asyncpg）可以极大提高并发能力。
• 连接池：对于数据库、HTTP客户端等，使用连接池并在技能间共享，避免为每次执行都创建新连接的开销。
• 技能预热：对于初始化成本高的技能（如加载大模型），可以在指挥家启动时进行预热，而不是在第一次执行时初始化。
• 流程设计优化：
  • 并行化：识别工作流中不相互依赖的步骤，将它们设计为并行执行。
  • 超时设置：为每个技能设置合理的超时时间，防止一个技能的僵死导致整个工作流卡住。
  • 限流与熔断：对于调用外部API的技能，实现限流和熔断机制，防止被下游服务拖垮或产生过高费用。

7. 常见问题与调试技巧实录

在实际使用skill-conductor或类似框架时，你肯定会遇到各种问题。下面是我在实践和测试中遇到的一些典型情况及其解决方法。

7.1 技能执行失败，但错误信息不明确

问题：工作流执行到一半停了，日志只显示SkillExecutionError，不知道具体是哪个参数错了或者网络超时。

排查步骤：

1. 检查技能日志：首先确保你的技能在execute方法内部有详细的日志记录，特别是在调用外部服务前后。使用self.logger（如果框架提供）或Python标准logging。
2. 包装异常：在技能代码中，不要简单地except Exception as e: pass。至少应该记录错误详情，并将有意义的错误信息向上抛出。

   try: result = await some_api_call() except requests.exceptions.Timeout: self.logger.error("API request timed out after 30s") raise RuntimeError("External service timeout") from None except ValidationError as e: self.logger.error(f"Input validation failed: {e.errors()}") raise

3. 启用框架调试模式：查看skill-conductor是否有调试日志级别，开启它可以打印更详细的执行步骤和上下文数据变化。

7.2 上下文数据传递错误

问题：技能B预期从上下文中读取技能A的输出字段result，但运行时发现result是None或字段不存在。

排查步骤：

1. 检查技能ID：确保工作流YAML中引用的技能ID与技能类中定义的id完全一致（大小写敏感）。
2. 检查输出模型：确认技能A的output_model中确实定义了名为result的字段，并且在execute方法中返回的实例包含了这个字段的正确值。
3. 检查上下文键名：框架通常以技能ID作为键，将技能的输出字典存入上下文。所以技能B应该通过context['skill_a_id']['result']来访问。打印整个上下文看看结构是否正确。
4. 数据映射：有些框架支持在YAML中定义数据映射。检查你是否需要显式地将技能A的输出映射到技能B的输入，而不是依赖自动匹配。

7.3 工作流陷入等待或循环

问题：工作流启动后似乎没有进展，日志也没有错误。

排查步骤：

1. 检查条件表达式：如果工作流有条件分支，仔细检查条件表达式（如${context.sentiment == 'positive'}）的语法是否正确，以及所引用的上下文路径是否存在。
2. 检查并行汇聚：对于并行执行后需要汇聚的节点，确保所有并行分支最终都能到达汇聚点。如果某个分支因条件不满足而无法执行，可能导致汇聚节点永远等不到所有输入。
3. 超时设置：为整个工作流或每个技能设置全局超时。如果某个技能内部有死循环或无限等待，超时机制可以强制将其标记为失败，使工作流继续或终止。
4. 可视化工具：如果框架提供或将工作流定义导入到流程图工具中，直观地检查流程逻辑是否有死胡同或循环依赖。

7.4 性能瓶颈分析

问题：工作流执行速度很慢，但不知道时间花在哪里。

排查技巧：

1. 为每个技能添加计时：最简单的方法是在每个技能的execute方法开始和结束时记录时间戳，计算耗时。
2. 使用Profiling工具：对于Python应用，可以使用cProfile或py-spy进行性能剖析，找出是CPU计算慢还是I/O等待长。
3. 分析并行度：理论上可以并行的步骤是否真的在并行执行？检查框架的并行执行引擎是否正常工作，以及你是否正确地将任务定义为并行。有时因为资源限制（如数据库连接数、API速率限制），并行可能退化为串行。
4. 外部依赖检查：慢往往不是框架本身，而是外部服务（如LLM API、数据库）。检查这些服务的响应时间，考虑增加缓存、批量请求或使用更快的替代方案。

7.5 版本管理与工作流演进

问题：线上运行着一个重要的工作流，现在需要修改它（比如增加一个新技能，或改变逻辑）。如何安全地更新？

经验之谈：

1. 工作流版本化：像对待代码一样对待工作流定义。使用Git管理YAML文件，每次更改都有提交记录。在工作流定义中明确加入version字段。
2. 蓝绿部署：不要直接修改正在运行的工作流定义。可以部署一个新版本的工作流（如v2），将新的流量逐步切到新版本，同时老版本（v1）继续处理存量任务。skill-conductor需要支持同时加载多个版本的工作流定义。
3. 数据迁移考量：如果工作流修改涉及上下文数据结构的重大变化（比如删除了一个字段），需要考虑如何兼容正在执行中的老版本工作流实例，或者设计一个数据迁移策略。
4. 回滚计划：确保能快速回滚到上一个稳定版本。这意味着旧版本的工作流定义和对应的技能代码必须保留。

skill-conductor这个项目展示了一种构建AI应用的清晰思路：通过编排和组合，将复杂问题分解为可管理的部分。它可能不像一些明星项目那样功能繁多，但其简洁的设计和明确的抽象，对于需要构建可靠、可维护AI流水线的团队来说，是一个非常值得研究和尝试的起点。在实际使用中，你会逐渐积累起一套自己的技能库和工作流模板，开发效率会得到质的提升。