diff --git a/GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs b/GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs
new file mode 100644
index 00000000..5844cee1
--- /dev/null
+++ b/GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs
@@ -0,0 +1,100 @@
+// Copyright (c) 2025-2026 GeWuYou
+// SPDX-License-Identifier: Apache-2.0
+
+using System;
+using System.Collections.Generic;
+using System.Reflection;
+using System.Threading;
+using System.Threading.Tasks;
+using GFramework.Core.Abstractions.Logging;
+using GFramework.Cqrs.Abstractions.Cqrs;
+using Microsoft.Extensions.DependencyInjection;
+
+[assembly: GFramework.Cqrs.CqrsHandlerRegistryAttribute(
+    typeof(GFramework.Cqrs.Benchmarks.Messaging.GeneratedRequestPipelineBenchmarkRegistry))]
+
+namespace GFramework.Cqrs.Benchmarks.Messaging;
+
+/// <summary>
+///     为 request pipeline benchmark 提供 handwritten generated registry，
+///     让默认 pipeline 宿主也能走真实的 generated request invoker provider 接线路径。
+/// </summary>
+public sealed class GeneratedRequestPipelineBenchmarkRegistry :
+    GFramework.Cqrs.ICqrsHandlerRegistry,
+    GFramework.Cqrs.ICqrsRequestInvokerProvider,
+    GFramework.Cqrs.IEnumeratesCqrsRequestInvokerDescriptors
+{
+    private static readonly GFramework.Cqrs.CqrsRequestInvokerDescriptor Descriptor =
+        new(
+            typeof(IRequestHandler<
+                RequestPipelineBenchmarks.BenchmarkRequest,
+                RequestPipelineBenchmarks.BenchmarkResponse>),
+            typeof(GeneratedRequestPipelineBenchmarkRegistry).GetMethod(
+                nameof(InvokeBenchmarkRequestHandler),
+                BindingFlags.Public | BindingFlags.Static)
+            ?? throw new InvalidOperationException("Missing generated request pipeline benchmark method."));
+
+    private static readonly IReadOnlyList<GFramework.Cqrs.CqrsRequestInvokerDescriptorEntry> Descriptors =
+    [
+        new GFramework.Cqrs.CqrsRequestInvokerDescriptorEntry(
+            typeof(RequestPipelineBenchmarks.BenchmarkRequest),
+            typeof(RequestPipelineBenchmarks.BenchmarkResponse),
+            Descriptor)
+    ];
+
+    /// <summary>
+    ///     将 request pipeline benchmark handler 注册为单例，保持与当前矩阵宿主一致的生命周期语义。
+    /// </summary>
+    public void Register(IServiceCollection services, ILogger logger)
+    {
+        ArgumentNullException.ThrowIfNull(services);
+        ArgumentNullException.ThrowIfNull(logger);
+
+        services.AddSingleton(
+            typeof(IRequestHandler<RequestPipelineBenchmarks.BenchmarkRequest, RequestPipelineBenchmarks.BenchmarkResponse>),
+            typeof(RequestPipelineBenchmarks.BenchmarkRequestHandler));
+        logger.Debug("Registered generated request pipeline benchmark handler.");
+    }
+
+    /// <summary>
+    ///     返回当前 provider 暴露的全部 generated request invoker 描述符。
+    /// </summary>
+    public IReadOnlyList<GFramework.Cqrs.CqrsRequestInvokerDescriptorEntry> GetDescriptors()
+    {
+        return Descriptors;
+    }
+
+    /// <summary>
+    ///     为目标请求/响应类型对返回 generated request invoker 描述符。
+    /// </summary>
+    public bool TryGetDescriptor(
+        Type requestType,
+        Type responseType,
+        out GFramework.Cqrs.CqrsRequestInvokerDescriptor? descriptor)
+    {
+        if (requestType == typeof(RequestPipelineBenchmarks.BenchmarkRequest) &&
+            responseType == typeof(RequestPipelineBenchmarks.BenchmarkResponse))
+        {
+            descriptor = Descriptor;
+            return true;
+        }
+
+        descriptor = null;
+        return false;
+    }
+
+    /// <summary>
+    ///     模拟 generated invoker provider 为 request pipeline benchmark 产出的开放静态调用入口。
+    /// </summary>
+    public static ValueTask<RequestPipelineBenchmarks.BenchmarkResponse> InvokeBenchmarkRequestHandler(
+        object handler,
+        object request,
+        CancellationToken cancellationToken)
+    {
+        var typedHandler = (IRequestHandler<
+            RequestPipelineBenchmarks.BenchmarkRequest,
+            RequestPipelineBenchmarks.BenchmarkResponse>)handler;
+        var typedRequest = (RequestPipelineBenchmarks.BenchmarkRequest)request;
+        return typedHandler.Handle(typedRequest, cancellationToken);
+    }
+}
diff --git a/GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs b/GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs
index 07dbc0c5..23d703ec 100644
--- a/GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs
+++ b/GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs
@@ -69,8 +69,7 @@ public class RequestPipelineBenchmarks
         _baselineHandler = new BenchmarkRequestHandler();
         _container = BenchmarkHostFactory.CreateFrozenGFrameworkContainer(container =>
         {
-            container.RegisterSingleton<GFramework.Cqrs.Abstractions.Cqrs.IRequestHandler<BenchmarkRequest, BenchmarkResponse>>(
-                _baselineHandler);
+            container.RegisterCqrsHandlersFromAssembly(typeof(RequestPipelineBenchmarks).Assembly);
             RegisterGFrameworkPipelineBehaviors(container, PipelineCount);
         });
         _runtime = GFramework.Cqrs.CqrsRuntimeFactory.CreateRuntime(
diff --git a/GFramework.Cqrs.Benchmarks/README.md b/GFramework.Cqrs.Benchmarks/README.md
index 20558821..35d7c81e 100644
--- a/GFramework.Cqrs.Benchmarks/README.md
+++ b/GFramework.Cqrs.Benchmarks/README.md
@@ -19,7 +19,7 @@
 - `Messaging/RequestLifetimeBenchmarks.cs`
   - `Singleton / Transient` 两类 handler 生命周期下，direct handler、`GFramework.Cqrs` runtime 与 `MediatR` 的 request steady-state dispatch 对比
 - `Messaging/RequestPipelineBenchmarks.cs`
-  - `0 / 1 / 4` 个 pipeline 行为下，direct handler、`GFramework.Cqrs` runtime 与 `MediatR` 的 request steady-state dispatch 对比
+  - `0 / 1 / 4` 个 pipeline 行为下，direct handler、已接上 handwritten generated request invoker provider 的 `GFramework.Cqrs` runtime 与 `MediatR` 的 request steady-state dispatch 对比
 - `Messaging/RequestStartupBenchmarks.cs`
   - `Initialization` 与 `ColdStart` 两组 request startup 成本对比，补齐与 `Mediator` comparison benchmark 更接近的 startup 维度
 - `Messaging/RequestInvokerBenchmarks.cs`
diff --git a/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md b/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md
index 01865d69..c075d643 100644
--- a/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md
+++ b/ai-plan/public/cqrs-rewrite/todos/cqrs-rewrite-migration-tracking.md
@@ -7,7 +7,7 @@ CQRS 迁移与收敛。
 
 ## 当前恢复点
 
-- 恢复点编号：`CQRS-REWRITE-RP-105`
+- 恢复点编号：`CQRS-REWRITE-RP-106`
 - 当前阶段：`Phase 8`
 - 当前 PR 锚点：`PR #340`
 - 当前结论：
@@ -42,18 +42,21 @@ CQRS 迁移与收敛。
   - 当前 `RP-103` 已使用 `$gframework-pr-review` 复核 `PR #340` latest-head review：修复 `CreateStream_Should_Throw_When_Stream_Pipeline_Behavior_Context_Does_Not_Implement_IArchitectureContext` 因 strict mock 未配置 `HasRegistration(Type)` 产生的 CI 失败，收紧 `MicrosoftDiContainer.HasRegistration(Type)` 到与 `GetAll(Type)` 一致的服务键可见性语义，补齐 `IIocContainer.HasRegistration(Type)` 的异常/XML 契约与 `docs/zh-CN/core/ioc.md` 的用户接入说明，并同步 benchmark 注释与 active tracking/trace 到当前 PR 锚点
   - 当前 `RP-104` 已继续沿用 `$gframework-batch-boot 50` 压 request 热路径：先把 `CqrsDispatcher.SendAsync(...)` 改成 direct-return `ValueTask`，移除 dispatcher 自身的 `async/await` 状态机；再让 `MicrosoftDiContainer.HasRegistration(Type)` 在冻结后复用预构建的服务键索引，避免每次命中零 pipeline request 都线性扫描全部描述符；本轮 benchmark 表明第一刀显著压低 steady-state / lifetime request，第二刀在当前短跑下主要确认“无回退、收益不明显”
   - 当前 `RP-105` 已继续沿用 `$gframework-batch-boot 50` 压默认 request steady-state：为 benchmark 最小宿主补齐 CQRS runtime / registrar / registration service 基础设施，让 `RequestBenchmarks` 不再只测反射路径，而是通过 handwritten generated registry + `RegisterCqrsHandlersFromAssembly(...)` 真实接上 generated request invoker provider；本轮 benchmark 表明默认 request 路径进一步从约 `70.298 ns / 32 B` 压到约 `65.296 ns / 32 B`，`Singleton / Transient` lifetime 也同步收敛到约 `68.772 ns / 32 B` 与 `73.157 ns / 56 B`
-- `ai-plan` active 入口现以 `RP-105` 为最新恢复锚点；`PR #340`、`PR #339`、`PR #334`、`PR #331`、`PR #326`、`PR #323`、`PR #307` 与其他更早阶段细节均以下方归档或说明为准
+  - 当前 `RP-106` 已把同一套 generated-provider 宿主收口扩展到 `RequestPipelineBenchmarks`：新增 handwritten `GeneratedRequestPipelineBenchmarkRegistry`，并让 `RequestPipelineBenchmarks` 改走 `RegisterCqrsHandlersFromAssembly(...)` + benchmark CQRS 基础设施预接线；本轮 benchmark 表明 `0 pipeline` steady-state 进一步收敛到约 `64.755 ns / 32 B`，`1 pipeline` 约 `353.141 ns / 536 B`，`4 pipeline` 在短跑噪音下维持约 `555.083 ns / 896 B`
+- `ai-plan` active 入口现以 `RP-106` 为最新恢复锚点；`PR #340`、`PR #339`、`PR #334`、`PR #331`、`PR #326`、`PR #323`、`PR #307` 与其他更早阶段细节均以下方归档或说明为准
 
 ## 当前活跃事实
 
 - 当前分支为 `feat/cqrs-optimization`
 - 本轮 `$gframework-batch-boot 50` 以 `origin/main` (`4d6dbba6`, 2026-05-08 11:13:33 +0800) 为基线；本地 `main` 仍落后，不作为 branch diff 基线
-- 当前已提交分支相对 `origin/main` 的累计 branch diff 为 `4 files / 154 lines`；本批待提交工作树额外集中在 `GFramework.Cqrs.Benchmarks/Messaging/BenchmarkHostFactory.cs`、`GFramework.Cqrs.Benchmarks/Messaging/RequestBenchmarks.cs`、`GFramework.Cqrs.Benchmarks/Messaging/GeneratedDefaultRequestBenchmarkRegistry.cs` 与 `GFramework.Cqrs.Benchmarks/README.md`，约 `4 files / 160 changed lines`，合并后仍明显低于 `$gframework-batch-boot 50` 的文件阈值
+- 当前已提交分支相对 `origin/main` 的累计 branch diff 为 `8 files / 358 lines`
+- 本批待提交工作树集中在 `GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs`、`GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs` 与 `GFramework.Cqrs.Benchmarks/README.md`，新增 generated-provider pipeline 宿主接线后仍明显低于 `$gframework-batch-boot 50` 的文件阈值
 - `GFramework.Cqrs.Benchmarks` 作为 benchmark 基础设施项目，必须持续排除在 NuGet / GitHub Packages 发布集合之外
 - `GFramework.Cqrs.Benchmarks` 现已覆盖 request steady-state、pipeline 数量矩阵、startup、request/stream generated invoker，以及 request handler `Singleton / Transient` 生命周期矩阵
 - `GFramework.Cqrs.Benchmarks` 当前以 NuGet 方式引用 `Mediator.Abstractions` / `Mediator.SourceGenerator` `3.0.2`；`ai-libs/Mediator` 只保留为本地源码/README 对照资料，不再参与 benchmark 项目编译
-- 当前 request steady-state benchmark 已形成 baseline / `Mediator` / `MediatR` / `GFramework.Cqrs` 四方对照：最新约 `5.013 ns / 32 B`、`5.747 ns / 32 B`、`51.588 ns / 232 B`、`65.296 ns / 32 B`
-- 当前 request lifetime benchmark 已继续收敛：`Singleton` 下 `GFramework.Cqrs` 最新约 `68.772 ns / 32 B`，`Transient` 下约 `73.157 ns / 56 B`；相较 `RP-104` 前的 `73.005 ns / 32 B` 与 `74.757 ns / 56 B` 已继续下降
+- 当前 request steady-state benchmark 已形成 baseline / `Mediator` / `MediatR` / `GFramework.Cqrs` 四方对照：最新约 `5.680 ns / 32 B`、`6.565 ns / 32 B`、`54.737 ns / 232 B`、`63.644 ns / 32 B`
+- 当前 request lifetime benchmark 已继续收敛：`Singleton` 下 `GFramework.Cqrs` 最新约 `69.896 ns / 32 B`，`Transient` 下约 `72.880 ns / 56 B`；相较 `RP-104` 前的 `73.005 ns / 32 B` 与 `74.757 ns / 56 B` 已继续下降
+- 当前 request pipeline benchmark 已改为与默认 request steady-state 相同的 generated-provider 宿主接线路径：`0 pipeline` 约 `64.755 ns / 32 B`，`1 pipeline` 约 `353.141 ns / 536 B`，`4 pipeline` 约 `555.083 ns / 896 B`
 - 本轮已验证旧 benchmark 劣化的两个主热点：`0 pipeline` 场景下仍解析空行为列表，以及容器查询热路径在 debug 禁用时仍构造日志字符串；两者收口后，`GFramework.Cqrs` request 路径不再出现额外数百字节分配
 - `HasRegistration(Type)` 现在只把“同一服务键已注册”或“开放泛型服务键可闭合到目标类型”视为命中，不再把“仅以具体实现类型自注册”的行为误判为接口服务已注册；该语义与 `Get(Type)` / `GetAll(Type)` 已重新对齐
 - `GFramework.Cqrs.Tests/Cqrs/CqrsDispatcherContextValidationTests.cs` 已同步适配 `HasRegistration(Type)` fast-path，避免 strict mock 因缺少新调用配置而在上下文失败语义断言前提前抛出 `Moq.MockException`
@@ -61,7 +64,7 @@ CQRS 迁移与收敛。
 - 当前 request steady-state 仍落后于 source-generated `Mediator` 与 `MediatR`，但差距已从“额外数百字节分配 + 近 300ns”收敛到“零 pipeline fast-path 仍慢约 `31ns` / `3.6x` 于 `Mediator`”；下一批若继续压 request dispatch，应优先评估默认路径吸收 generated invoker/provider 的空间
 - 本轮 `SendAsync(...)` 的 direct-return `ValueTask` 改动已证明确实是有效热点：同样的短跑配置下，`GFramework.Cqrs` steady-state request 从约 `83.823 ns` 下探到 `69-70 ns` 区间
 - 冻结后 `HasRegistration(Type)` 服务键索引化在当前短跑下没有带来同等量级的可见收益，但也没有引入功能回退或额外分配；后续若继续压零 pipeline request，应优先重新评估“默认 request 路径进一步吸收 generated invoker/provider”而不是继续堆叠同层级微优化
-- 默认 `RequestBenchmarks` 现在已通过 handwritten generated registry + 真实 `RegisterCqrsHandlersFromAssembly(...)` 宿主接线命中 generated request invoker provider，不再只代表纯反射 request binding 路径
+- 默认 `RequestBenchmarks` 与 `RequestPipelineBenchmarks` 现在都已通过 handwritten generated registry + 真实 `RegisterCqrsHandlersFromAssembly(...)` 宿主接线命中 generated request invoker provider，不再只代表纯反射 request binding 路径
 - 当前性能回归门槛已收紧为：只要改动触达 `GFramework.Cqrs` request dispatch、DI 热路径、invoker/provider、pipeline 或 benchmark 宿主，就必须至少复跑 `RequestBenchmarks.SendRequest_*` 与 `RequestLifetimeBenchmarks.SendRequest_*`
 - 当前阶段的性能验收目标已明确为：默认 request steady-state 路径不要求超过 source-generated `Mediator`，但必须持续逼近它，并至少稳定快于基于反射 / 扫描的 `MediatR`
 - `GFramework.Core` 当前已通过内部 bridge request / handler 把 legacy `ICommand`、`IAsyncCommand`、`IQuery`、`IAsyncQuery` 接到统一 `ICqrsRuntime`
@@ -294,9 +297,9 @@ CQRS 迁移与收敛。
 
 ## 下一推荐步骤
 
-1. 若继续沿用 `$gframework-batch-boot 50` 且优先处理性能，下一批先集中评估默认 request 路径进一步吸收 generated invoker/provider 的空间，而不是继续堆叠同层级容器微优化
-2. 若要把“至少超过反射版 `MediatR`”变成可执行目标，下一批应拆分 `RequestDispatchBinding` / handler 调用适配层的剩余常量开销，并在每次改动后立即复跑 `RequestBenchmarks` 与 `RequestLifetimeBenchmarks`
-3. 若 benchmark 对照需要继续贴近 `Mediator` 官方设计，再扩 `Mediator` 的 compile-time lifetime 矩阵，而不是先横向堆更多低价值场景
+1. 若继续沿用 `$gframework-batch-boot 50` 且优先处理性能，下一批先查看 `RequestLifetimeBenchmarks` 与 stream/notification 对照里是否还有未吸收 generated-provider 宿主收益的低风险切片
+2. 若要把“至少超过反射版 `MediatR`”变成可执行目标，下一批应继续围绕 request dispatch / pipeline 路径的剩余常量开销下钻，并在每次改动后立即复跑 `RequestBenchmarks`、`RequestLifetimeBenchmarks` 与 `RequestPipelineBenchmarks`
+3. 若 benchmark 对照需要继续贴近 `Mediator` 官方设计，再扩 `Mediator` 的 compile-time lifetime 或 stream 对照矩阵，而不是回头重试已被 benchmark 否决的 `GetAll(Type)` 零行为探测方案
 
 ## 活跃文档
 
diff --git a/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md b/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md
index bdf12ccc..7f910b24 100644
--- a/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md
+++ b/ai-plan/public/cqrs-rewrite/traces/cqrs-rewrite-migration-trace.md
@@ -2,6 +2,45 @@
 
 ## 2026-05-08
 
+### 阶段：request pipeline benchmark 吸收 generated provider 宿主（CQRS-REWRITE-RP-106）
+
+- 延续 `$gframework-batch-boot 50`，本轮基于 `RP-105` 已验证的默认 request 宿主接线继续推进，并先复核 branch diff 基线：
+  - `origin/main` = `4d6dbba6`，提交时间 `2026-05-08 11:13:33 +0800`
+  - 当前分支 `feat/cqrs-optimization` 相对 `origin/main` 的累计 branch diff 为 `8 files / 358 lines`
+  - 当前工作树待提交改动只集中在 `RequestPipelineBenchmarks`、对应 handwritten generated registry 与 benchmark `README`，因此继续自动推进下一批 pipeline 宿主收口
+- 本轮接受的只读探索结论：
+  - `RP-105` 已证明“让默认 request 宿主真实接上 generated request invoker provider”能稳定压低 steady-state request，因此 pipeline benchmark 仍保留旧的“直接注册单个 handler”路径会让口径不对齐
+  - 之前已被 benchmark 否决的“总是 `GetAll(Type)` 做零 pipeline 探测”不应回头重试；下一刀更合理的是把 pipeline benchmark 也切到真实程序集注册入口
+  - `RequestPipelineBenchmarks` 只需要补一份与 `RequestBenchmarks` 对称的 handwritten generated registry，就能最小化改动并保持 runtime 语义不变
+- 本轮主线程决策：
+  - 新增 `GeneratedRequestPipelineBenchmarkRegistry`，用 handwritten generated registry + `ICqrsRequestInvokerProvider` + `IEnumeratesCqrsRequestInvokerDescriptors` 为 `RequestPipelineBenchmarks.BenchmarkRequest` 提供真实的 generated request invoker descriptor
+  - 让 `RequestPipelineBenchmarks` 改用 `RegisterCqrsHandlersFromAssembly(typeof(RequestPipelineBenchmarks).Assembly)` 建容器，只把 pipeline 行为数量矩阵保留在 benchmark 自己的显式注册里
+  - 更新 `GFramework.Cqrs.Benchmarks/README.md`，明确 request pipeline benchmark 也已接上 handwritten generated request invoker provider
+- 本轮权威验证：
+  - `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release`
+    - 结果：通过，`0 warning / 0 error`
+  - `python3 scripts/license-header.py --check --paths GFramework.Cqrs.Benchmarks/Messaging/GeneratedRequestPipelineBenchmarkRegistry.cs GFramework.Cqrs.Benchmarks/Messaging/RequestPipelineBenchmarks.cs GFramework.Cqrs.Benchmarks/README.md`
+    - 结果：通过
+  - `git diff --check`
+    - 结果：通过
+  - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1`
+    - 结果：通过
+    - 备注：steady-state request 对照约为 baseline `5.680 ns / 32 B`、`Mediator` `6.565 ns / 32 B`、`MediatR` `54.737 ns / 232 B`、`GFramework.Cqrs` `63.644 ns / 32 B`
+  - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestLifetimeBenchmarks.SendRequest_*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1`
+    - 结果：通过
+    - 备注：`Singleton` 下 `GFramework.Cqrs` / `MediatR` 约 `69.896 ns / 32 B` vs `57.469 ns / 232 B`；`Transient` 下约 `72.880 ns / 56 B` vs `55.106 ns / 232 B`
+  - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestPipelineBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1`
+    - 结果：通过
+    - 备注：第一次短跑为 `PipelineCount=0` `64.928 ns / 32 B`、`PipelineCount=1` `366.468 ns / 536 B`、`PipelineCount=4` `547.800 ns / 896 B`
+  - `dotnet run --project GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release -- --filter "*RequestPipelineBenchmarks.SendRequest_GFrameworkCqrs*" --job short --warmupCount 1 --iterationCount 1 --launchCount 1`
+    - 结果：通过
+    - 备注：复跑确认后为 `PipelineCount=0` `64.755 ns / 32 B`、`PipelineCount=1` `353.141 ns / 536 B`、`PipelineCount=4` `555.083 ns / 896 B`
+- 本轮结论：
+  - request pipeline benchmark 现在已与默认 request steady-state 使用同一条 generated-provider 宿主接线路径，后续再看 `0 / 1 / 4` 行为矩阵时不再混入“默认 request 已吸收 generated invoker，而 pipeline 还停在纯反射宿主”的口径偏差
+  - `0 pipeline` steady-state 继续下探到约 `64.755 ns / 32 B`，与 `RP-105` 的默认 request benchmark 收敛方向一致，说明这条宿主接线收益能稳定复用到 pipeline benchmark
+  - `1 pipeline` 与 `4 pipeline` 结果在当前 short job 配置下存在噪音，但没有出现清晰的新增分配或显著退化；因此本轮适合作为低风险宿主收口批次接受
+  - 下一批若继续沿用 `$gframework-batch-boot 50`，应优先查看 request lifetime、stream 或 notification benchmark 中是否还存在未吸收 generated-provider 宿主收益的对称切片，而不是回头重试已被 benchmark 否决的 runtime 微优化
+
 ### 阶段：默认 request benchmark 吸收 generated provider 宿主（CQRS-REWRITE-RP-105）
 
 - 延续 `$gframework-batch-boot 50`，本轮先确认失败试验已手工回退回 `RP-104` 的已验证状态，再重新评估“默认 request 路径继续逼近 source-generated `Mediator`”的下一刀