diff --git a/zh-cn/application-dev/ability/figures/AbilityComponentInstanceMission.png b/zh-cn/application-dev/ability/figures/AbilityComponentInstanceMission.png
new file mode 100644
index 0000000000000000000000000000000000000000..2d2c2f3d339ee6107ffbd65fa2e1a73fd7774304
Binary files /dev/null and b/zh-cn/application-dev/ability/figures/AbilityComponentInstanceMission.png differ
diff --git a/zh-cn/application-dev/ability/stage-brief.md b/zh-cn/application-dev/ability/stage-brief.md
index e9dc4ffcf5ef57016353dfc79ce9d10057e97b55..167a4bd90513a33a1de513a9d126e73c7f8eb676 100644
--- a/zh-cn/application-dev/ability/stage-brief.md
+++ b/zh-cn/application-dev/ability/stage-brief.md
@@ -49,6 +49,23 @@
 
 ​        为了实现多设备形态上的裁剪和多窗口的可扩展性，OpenHarmony对组件管理和窗口管理进行了解耦。Stage模型定义Ability组件的生命周期，只包含创建、销毁、前后台等状态，而将与界面相关内容强相关的获焦、失焦状态放在WindowStage之中，从而实现Ability与窗口之间的弱耦合；在服务侧，窗口管理服务依赖于组件管理服务，前者通知后者前后台变化，这样组件管理服务仅感知前后台变化，不感知焦点变化。
 
+
+### Ability组件实例与任务
+
+​        Ability组件有三种启动类型：
+
++ **Singleton**：应用进程中只存在一个该类型的Ability实例，如下图Ability1；
+
++ **Standard**：每次startAbility调用，都会在应用进程中创建一个该类型的实例，如下图Ability2的两个实例；
+
++ **Specified**：允许开发者在系统创建AbilityRecord之前，为该实例创建一个key，后续每次创建该类型的Ability实例都会询问应用使用哪个key对应的Ability实例，来响应startAbility请求，如下图Ability3。
+
+​        每个Ability实例都对应了一个Launcher Recent中看到的Mission(任务)。
+
+​        每个Ability实例对应的Mission都留有该Ability实例的快照，Ability实例销毁后，Mission中的会保留Ability的类的信息和快照，直到用户删除，或者超过存储上限。
+
+ ![AbilityComponentInstanceMission](figures/AbilityComponentInstanceMission.png)
+
 ### ExtensionAbility机制
 
 ​        不同于用于页面展示的Ability，ExtensionAbility提供的是一种受限的服务运行环境。ExtensionAbility具有如下特点：