Agent AOP切面怎么设计？QwenPaw两套正交切面体系与五大执行模式详解

尼恩说在前面

在45岁老架构师尼恩的读者交流群（50+）中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团、蚂蚁的面试资格，遇到了很多重要的 Agent AOP 切面相关面试题。

比如前几天，一个面大厂挂了的小伙伴遇到了这样的问题：

面试官：Agent AOP 切面怎么设计？他说了 LangChain 洋葱责任链。面试官说太 low 了，要用 QwenPaw 两套正交切面体系、五大执行模式。

伙伴没有系统地去梳理和总结，面试官不满意，面试挂了，赶紧来找尼恩复盘。

在这里，尼恩结合最新的《Agent Swarm 蜂群架构学习圣经 1》给大家做系统化、体系化的梳理，帮助大家充分展示雄厚的“技术肌肉”，让面试官爱到“不能自已、口水直流”，进而实现 offer 直提。

面试官：Agent AOP 切面怎么设计？我说了 LangChain 洋葱责任链。面试官说太 low 了，要用 QwenPaw 两套正交切面体系、五大执行模式

本文基于《尼恩蜂群架构圣经》05、07 篇文档，结合 LangChain、AgentScope 这些业界框架做对照分析。

LangChain 洋葱责任链无法支撑企业级生产场景？

LangChain 将请求处理抽象为串行中间件链：请求由外向内逐层穿透，响应再逆序逐层退出。这套模型和 Web 框架中间件思路一致。

LangChain 的 AgentMiddleware 采用经典洋葱责任链模型：

• 一组中间件按注册顺序串联形成管道，请求从外层向内逐层穿过各个中间件、进入 Agent ReAct 循环执行；
• 拿到结果后，再沿着原链路逆序向外逐层退出。每一层中间件都可以在进入前和返回后插入自定义逻辑，适合对模型调用、工具调用做横切拦截，比如埋点日志、结果改写、简单权限校验。

它是面向 Agent 循环内部事件的单维拦截机制。

在简单场景下它足够好用，比如在模型调用前后埋日志、对工具返回结果做轻量转换，少量代码即可实现。但落地到生产级 Agent 系统，这套架构存在三处结构性短板：

第一，仅有循环内拦截能力，缺失完整请求生命周期钩子。LangChain 的中间件全部挂载在 Agent 实例就绪之后，只能拦截 ReAct 循环内部单次模型调用、单次工具调用。而会话加载、全局鉴权、请求限流这类前置逻辑，需要在 Agent 实例创建之前执行；框架没有原生前置钩子，开发者只能把这类逻辑硬塞进中间件，再依靠 if agent is None 分支做兼容。最终中间件入参充斥大量可空对象，类型约束失效，空指针类问题成为线上高频故障。

第二，缺少原生模式门控，中间件无法按场景隔离启用。LangChain 中间件默认全局生效，没有“仅在指定模式启用”的原生能力。例如同一个 Agent 同时支持代码编写、日常闲聊两种模式，代码审查类中间件在闲聊链路也会被加载，只能在中间件内部手写 if mode == "coding" 做跳过判断。随着业务模式持续增多，散落的条件分支会指数级膨胀，中间件最终演变为难以维护的条件判断泥潭。

本质上，LangChain 洋葱模型是单维度拦截管线：它只解决 ReAct 循环内部的拦截变换，不覆盖循环前置准备、循环后置清理、多模式隔离这些诉求。

Demo 场景足够轻便，但面对企业级多模式、长周期、高可靠的 Agent 任务，架构存在明显天花板。

1. 先分别介绍两个核心概念

QwenPaw 的两套正交切面，正是针对以上缺陷给出的系统性解法：

• 通过 Runtime Hooks 补齐完整请求生命周期；
• 依靠 ModeGatedHook 实现多种执行模式门控。

两套正交切面体系、五大执行模式，共同构成一套顶级的 Agent 运行时 AOP 治理底座。

1.1 什么是两套正交切面体系

设计动机：为什么需要两套正交切面 AOP 治理底座

任何 Agent 运行时都面临一个工程困境：ReAct 主循环（也就是 react_agent.py）里如果直接写日志、观测、记忆、会话持久化、权限校验这些逻辑，内核会迅速膨胀、难以维护。更棘手的是，部分逻辑（比如会话加载）必须在 Agent 实例创建之前执行；而另一部分逻辑（比如模型调用拦截、工具结果截断）必须等 Agent 实例就绪之后才能执行。

如果只用一套钩子体系，那么所有钩子的签名都得带着一个可空的 Agent 参数，这就导致大量防御性的空值判断，连类型系统都没法帮上忙。

QwenPaw 的解法是：把 ReAct 主循环精简到极致，只保留“推理 + 工具调用 + 迭代推理”这一最小闭环，其余所有横切关注点全部抽离到两套正交的 AOP 切面中，以零侵入、可插拔的方式注册和运行。这种正交拆分，不只是代码组织上的一种优化，更是类型安全和执行顺序确定性的根本保障。

Agent 的 ReAct 主循环只保留推理 + 工具调用 + 迭代推理这个核心流程，保证 react_agent.py 内核精简、稳定。日志采集、链路观测、记忆读写、会话持久化、插件扩展这类横切逻辑，不侵入主循环，全部抽离到两套正交切面，依靠可插拔的方式实现扩展。

两套切面按照执行作用域来划分，解决的其实是一个核心矛盾：有一部分逻辑要在 Agent 实例创建之前执行；而模型拦截、工具拦截这类逻辑，必须等待 Agent 实例就绪之后才能执行。

第一套：Runtime Hooks 请求级生命周期钩子，粗粒度，覆盖完整用户请求的全生命周期，在 Agent 还没实例化的时候就可以执行逻辑。

一共包含 8 个生命周期阶段：PRE_DISPATCH、POST_DISPATCH、PRE_AGENT_BUILD、POST_AGENT_BUILD、PRE_EXECUTE、POST_RESPONSE、ON_ERROR、FINALLY。

• 采用生命周期钩子模型，支持 before / after 声明式依赖、Kahn 拓扑排序；
• 提供 LifecycleHook 全局常开、ModeGatedHook 带模式门控两套基类；
• 返回值拥有三值语义：CONTINUE 表示继续执行、SHORT_CIRCUIT 表示终止当前阶段、SKIP_AGENT 表示仅跳过 Agent 执行步骤。

典型用途：会话加载持久化、Cron 上下文快照、全局异常捕获、资源幂等清理。

这里展开说明一下三值语义的设计深意：

• CONTINUE 是默认的正常流转；
• SHORT_CIRCUIT 用于“请求已被缓存命中”或者“前置校验不通过”这类需要快速返回、但又不丢失清理逻辑的场景；
• SKIP_AGENT 则是专门为斜杠命令设计的——斜杠命令不需要走完整的 ReAct 推理，但是必须走完会话保存这类收尾流程。

这三个值不是简单的布尔扩展，而是精确对应了请求处理中三种截然不同的控制需求。

关键语义区分：

• SHORT_CIRCUIT：终止当前阶段、返回载荷，但是 ON_ERROR、FINALLY 这种收尾阶段一定会执行；
• SKIP_AGENT：只跳过 AgentBuilder.build、AgentExecutor.run，完整 8 段生命周期仍然跑完，用于斜杠命令，防止会话数据丢失。

第二套：Middleware 洋葱中间件，细粒度，仅在 Agent 实例就绪之后，拦截单次 ReAct 循环内部流程。

提供 6 个切点：on_system_prompt、on_model_call、on_reasoning、on_acting、on_reply、on_compress_context，遵循洋葱模型，请求由外向内进入，响应逆序退出。

复用 AgentScope2.0 的 MiddlewareBase 基类；通过 PluginApi.register_middleware 注册工厂而非实例，每个请求可以动态决定是否启用中间件。

重点：on_acting 是每次工具调用都会触发，不是一轮 ReAct 仅触发一次。典型用途：模型调用拦截、工具返回结果截断、Langfuse 链路埋点、上下文压缩。

补充一点工程细节：工厂模式注册中间件，意味着每次请求都会调用工厂函数来决定是否创建中间件实例。这使得中间件可以根据请求上下文（比如当前用户、当前模式、请求类型）动态启用或者跳过，而不是无条件地加载所有中间件。工厂返回 None 即表示该请求不需要这个中间件，零开销。

1.1.1 和业界框架对比与集群同构思想

和主流框架做对比，可以看出设计上的差异：

• QwenPaw：两套切面严格拆分，区分请求级、循环级；原生拓扑排序、模式门控、三值返回语义；会话加载可以放在 Agent 实例创建之前执行，减少大量空对象判断。
• LangChain AgentMiddleware：单套中间件大一统，没有区分 Agent 未实例化场景；无原生模式门控与拓扑排序；短路逻辑容易丢失会话、清理逻辑。
• AgentScope2.0：只提供循环级 Middleware，缺少请求级生命周期，会话、全局异常处理需要业务自己手写封装。

LangChain 的单套中间件之所以在复杂场景下出问题，根本原因在于，LangChain 把所有关注点塞进一套体系之后，钩子签名必须携带 AgentState。但是在请求最早期（比如鉴权、限流），Agent 还没创建，根本没有 AgentState，开发者被迫传入 None 并在中间件内部做空判断。这种请求级、循环级的“伪统一”，实际上把类型安全的负担转嫁给了业务代码。

而 AgentScope2.0 虽然提供了优秀的循环级中间件，但是它完全依赖业务层自行处理请求前后的会话加载和异常兜底，缺少框架级的治理保证。

QwenPaw 这套进程内切面，和 AgentTeams 集群层的 CRD + Reconcile 是架构同构的。

• 钩子 before / after 对应 CRD 资源依赖，拓扑环检测对应 helm 安装期依赖校验；
• FINALLY 幂等清理对应集群 Deprovision 资源回收。

统一铁律：拦截器可以终止业务，但是资源收尾清理逻辑必须由框架兜底执行，不能被拦截切断。

这个原则，是进程内治理和集群治理共同遵守的一条底线。

---

1.2 什么是五大执行模式

五大执行模式属于上层业务范式，做到的是同一套 Agent 内核，切换不同模式，适配不同任务场景。

为什么需要模式体系？

即使有了完善的 AOP 治理底座，Agent 面对不同任务时仍然需要不同的“能力组合”。

• 写代码需要的工具集，和闲聊完全不同；
• 长周期任务需要状态追踪和人工确认；
• 目标攻坚需要资源预算和量化验收。

如果每次都手动组装工具、提示词、钩子，那么不仅繁琐，还容易出现“工具加载了但是提示词没更新”这种半激活异常。

五大模式体系，正是为了解决这个问题而生的。

内置五大模式：

(1) default 默认模式： 普通闲聊、简单问答。轻量化工具，低延迟；审批管控力度弱，仅拦截系统高危操作。

(2) coding 编程模式： 代码开发、调试重构。挂载 LSP、ast-grep、shell 工具；配套代码审查钩子；中等审批强度，拦截删除、shell 执行。

(3) mission 任务模式： 长周期多步骤任务，遵循计划-执行-校验循环。任务拆解、子任务追踪；高审批强度，关键子任务需要人工确认。

(4) goal 目标模式： 目标攻坚、资源受限、量化验收。配置 Token 预算、Rubric 验收规则；严格审批，超预算、偏离目标强制拦截。

(5) custom_loop 自定义循环模式： 承接第三方自定义 think-act-observe 实现，全部能力由开发者自定义，审批策略可自主配置。

每一种模式的核心载体是 AgentMode 四元组：commands 斜杠命令 + tools 工具集合 + hooks 生命周期钩子 + prompt_contributors 提示词贡献器。

唯一入口 setup(workspace) 做原子批量注册，模式启用、销毁是原子操作，避免出现“工具加载成功，但是钩子、提示词没有卸载”这种半激活 bug。

模式专属钩子继承 ModeGatedHook，基类自动判断模式激活状态，业务代码不需要手写 if mode.active 这种判断。

四元组设计的深层逻辑：早期版本只考虑 tools + prompt_contributors 两个维度，但是实践中发现两个缺失。

• 一是斜杠命令缺失——不同模式下用户可用的命令集不同，如果命令不随模式切换，用户会在错误模式下看到不相关的命令。
• 二是钩子缺失——不同模式需要不同的横切逻辑（比如 coding 模式需要代码审查钩子），如果钩子不随模式切换，所有钩子全局常开，增加不必要的性能开销。

四元组将这四类异构组件打包为一个原子单元，切换模式，就是切换一整套“能力包”。

关于 GoalMode 唯一内置循环模式的设计取舍：GoalMode 作为标杆实现，展示了多道闸门（轮次限制、Token 预算、Rubric 量化验收）的组合方式。其余第三方循环全部以插件形式接入 custom_loop 模式加载。这种“一内置 + N 插件”的架构，保证了内核的轻量化，不为每一种新循环范式做修改。

1.2.1 和业界模式方案对比

业界大多只做简单的工具集切换；QwenPaw 的创新在于把命令、工具、钩子、提示词四类异构组件打包为四元组，原子装卸，搭配基类自动管控钩子启停。

• OpenAI-Agents SDK：工具、提示词分散配置，没有统一模式封装；没有自动门控钩子。
• Claude-Code / Gemini-CLI Plan/Build：只做工具权限划分，钩子、提示词需要业务手动组装。
• LangGraph：用 StateGraph 状态图实现业务逻辑，没有原生模式概念，条件分支全部业务手写；HITL 需要手动写 human 节点。

OpenAI Agents SDK 允许运行时动态增删工具，但是工具和提示词是分开管理的，没有统一的模式入口，切换“模式”实际上是一系列分散的手动操作，容易遗漏。

Claude-Code 的 Plan/Build 模式只管控工具权限集合，提示词和钩子完全由业务自行组装，缺少框架级的模式门控。

LangGraph 则把模式差异编码在 StateGraph 的节点和边中，没有独立的模式抽象，导致条件分支散落在业务代码各处，难以复用和测试。QwenPaw 的四元组原子装卸 + ModeGatedHook 自动启停，从架构层面彻底解决了这些问题。

---

2. 两套切面体系与五大执行模式的核心关系

尼恩核心结论：两套正交切面 = 底层通用运行治理底座；五大执行模式 = 上层可插拔业务能力包。

底座不感知上层业务；业务模式依赖底座完成注册、执行、自动启停。

可以概括为三点：职责解耦隔离、运行时挂载联动、完整链路协同。

2.1 职责解耦隔离

(1) 两套切面是通用基础设施。 不管当前激活哪一种执行模式，切面整套能力始终存在。它只负责提供钩子注册、切点拦截、拓扑排序、模式门控基类、流程控制，不关心是写代码还是做任务拆解。

(2) AgentMode 五大执行模式是业务配置包。 模式本身不会新增底层拦截机制。它只是定义好该模式需要哪些命令、工具、钩子、提示词，然后注册到底层切面体系；切换、新增模式，不需要修改切面底座源码。

这种解耦带来一个关键工程收益：

• 切面底座可以被充分测试和优化，因为它不包含任何业务逻辑；
• 业务模式的迭代也不会影响底层稳定性，比如新增一种模式、修改某模式的工具集等。

底座和模式各自独立演进，互不干扰。

2.2 运行时挂载联动

模式内部定义的钩子、中间件，全部注册到切面体系中执行：

(1) 模式的钩子，大多继承 ModeGatedHook，注册进入 Runtime Hooks 钩子注册中心。 Runtime Hooks 在执行回调的时候，基类自动校验当前模式是否激活；模式关闭，钩子直接跳过，不需要业务写条件判断。例如 coding 模式的代码审查钩子，切换到 default 闲聊模式就自动不运行。

(2) 模式如果定义业务中间件，会注册到 Middleware 洋葱链路。 进入 ReAct 循环之后，中间件就会对模型调用、工具执行做拦截。高危工具在 on_acting 切点触发 ApprovalService 审批门控。

补充区分：ModeGatedHook 基类属于切面底座提供；各个模式写的业务子类，归属于 AgentMode 模式层。这属于框架提供的能力，上层业务做实现。

进一步说明运行时挂载联动的行为：

• 当请求进入时，Runtime Hooks 按 8 阶段顺序执行。在 PRE_AGENT_BUILD 阶段加载会话之后，AgentBuilder.build() 根据请求上下文激活对应模式并调用 setup()。
• 此时模式的钩子被注册到底座，但是这不意味着它们会无条件执行——每次钩子被调用时，ModeGatedHook 基类都会检查当前模式是否匹配。

这种“注册时不筛选、执行时自动门控”的设计，既保证了钩子能拿到完整的请求上下文，又避免了模式切换时的手动清理工作。

2.3 完整请求链路，看两者如何协同工作

用户请求进入
→ Runtime Hooks 【PRE_DISPATCH】请求前置初始化
→ Runtime Hooks 【PRE_AGENT_BUILD】加载会话历史（Agent尚未实例化）
→ 固定步骤 AgentBuilder.build() 激活对应 AgentMode
    └── AgentMode.setup() 原子注册四元组：commands / tools / hooks / prompt_contributors
        └── ModeGatedHook 基类自动校验 is_active，未激活直接跳过业务逻辑
→ Runtime Hooks【POST_AGENT_BUILD】
→ Runtime Hooks【PRE_EXECUTE】Cron任务做上下文快照备份
→ 固定步骤 AgentExecutor.run() 进入 ReAct 循环
    └── Middleware 洋葱中间件链路开始执行
        on_system_prompt → on_model_call → on_reasoning → on_acting → on_reply → on_compress_context
            └── on_acting：工具风险校验，高危操作触发 ApprovalService 异步审批
→ ReAct 执行完成回到 Runtime Hooks【POST_RESPONSE】Cron还原上下文快照
→ 发生异常自动进入【ON_ERROR】
→ ✅无论成功、短路、异常，必定执行【FINALLY】做资源清理、会话持久化

整个请求生命周期中，切面底座始终在“默默工作”——它不关心当前是什么模式，只是忠实地按阶段执行钩子、按切点执行中间件。

而模式体系，则在 AgentBuilder.build() 这个关键节点“注入”自己的能力包。

两者在 ModeGatedHook 处汇合：底座负责调用和门控校验，模式负责具体业务逻辑。

这种“底座驱动 + 模式注入”的协同模型架构，是 QwenPaw 架构比较精妙的设计之一。

2.4 “底座驱动 + 模式注入”的协同模型架构目标

“底座驱动 + 模式注入”目标，实现了清晰的权责划分：流程编排权归底座，业务实现权归模式。

先说“底座驱动”。

• 请求进来先走 Runtime Hooks 的 8 段生命周期，顺序是框架写死的。整个请求从进来到结束，什么阶段先跑、什么阶段后跑，不是由任何业务代码决定的，而是由切面底座定死的。
• 进入 ReAct 循环之后，on_system_prompt、on_model_call、on_reasoning、on_acting、on_reply、on_compress_context 这 6 个切点分别在什么时机触发、每次工具调用都会触发一次 on_acting，也是框架写死的。
• 多个钩子之间谁先谁后，由声明式依赖加拓扑排序算出结果；钩子返回 CONTINUE、SHORT_CIRCUIT 还是 SKIP_AGENT，后续流程怎么跳转，依然由底座来解释。

换句话说，底座是导演，它手里握着完整的流程剧本。

五大模式体系无法插进来自定义执行节奏，它只能回答一个问题：“在这个剧本里，我扮演哪个角色？”

再说“模式注入”。

• AgentMode 的四元组（commands、tools、hooks、prompt_contributors）通过 setup() 一次性注册进钩子注册中心和中间件工厂，其中模式专属钩子继承 ModeGatedHook，业务逻辑写在子类的 _run() 方法里。
• 这里有一个关键点：模式自己永远不会主动发起调用。它不会说“我现在要执行了”，而是老老实实把自己挂载到底座上，等底座在某个阶段到了、某个切点触发的时候，回头来调用它——这是典型的控制反转（IoC）：不是业务代码调用框架，而是框架调用业务代码。
• 底座在流程节点上“喊到名字”，模式才上去执行一小段业务逻辑，执行完把结果交回底座，底座继续推进自己的流程。

两者在 ModeGatedHook 处汇合，分工极其干净：底座负责“什么时候调、当前模式该不该调”，模式负责“被调了之后干什么”。

打个比方：

• 底座是一座按固定脚本运行的舞台，8 个阶段和 6 个切点是舞台上的固定流程；模式是上台的演员，四元组是演员的剧本、道具和服装。
• 演员在 setup() 时登台注册，底座按流程节点一个个点名，点到了就上台演一段（_run() 业务逻辑），演完退下，舞台继续按剧本走。
• 如果这个演员不在状态（模式未激活），底座看一眼门控标志直接喊下一位，连上台的机会都没有。

用一个具体请求串起来看：用户当前处于 default 闲聊模式。

• 请求进来，底座先跑 PRE_DISPATCH、PRE_AGENT_BUILD 加载会话历史，此时模式还没登场，全是底座自己的活；
• 接着 AgentBuilder.build() 激活 default 模式，模式调用 setup() 把四元组注入底座；
• 进入 ReAct 循环后，底座按固定切点依次触发——此时 coding 模式注册的代码审查钩子虽然还挂在注册中心里，但是 ModeGatedHook 检查到当前不是 coding 模式，直接跳过，连它的 _run() 都不会调用；
• 假如某个工具属于高风险操作，底座在 on_acting 切点先做风险校验，再触发 ApprovalService 审批，而模式只是提供了这个工具的定义和该模式对应的审批强度；
• 无论请求成功、短路还是异常，底座都保证走完 FINALLY 做清理和会话保存，这一步与模式完全无关。

整条链路里，底座始终按自己的剧本推进、按需点名，模式始终只负责被点到名之后的那一小段演出。

---

3. 带来的工程收益

3.1 两套正交切面体系收益

(1) 内核保持稳定。 ReAct 主循环干净，横切能力全部插件化，新增扩展不用修改内核源码。

(2) 作用域边界清晰。 区分 Agent 创建前后场景，消除大量对象空值判断。

(3) 执行顺序可预测。 声明式依赖 + 拓扑排序，循环依赖在服务启动期暴露。

(4) 流程控制精细。 三值语义区分不同终止逻辑，保证收尾逻辑不会被短路吃掉。

(5) 模式门控自动化。 ModeGatedHook 把模式判断下沉到框架基类，消灭手写 if 的高频 bug。

(6) 架构思想可延续。 进程内 AOP 和 AgentTeams 集群 Reconcile 同构，方便向多 Agent 蜂群演进。

拓扑排序 + 启动期环检测，可以解决循环依赖问题。如果一个新插件引入了与已有钩子的循环依赖（比如 A before B，B before C，C before A），框架在启动阶段就会直接抛出 HookCycleError，阻止服务启动。这把原本可能在上线后间歇性出现的执行顺序异常，提前到了部署阶段暴露，大幅降低了线上排障成本。

3.2 五大执行模式收益

(1) 一套内核支撑多套业务范式。 coding / mission / goal 不用维护多套 Agent 内核。

(2) 杜绝半激活异常。 setup 原子批量注册，模式加载卸载成套。

(3) 钩子自动启停。 依托切面提供的 ModeGatedHook，业务不用手写模式判断。

(4) HITL 审批能力完备。 支持跨会话审批推送、精确 / 相似授权粒度，平衡安全和审批疲劳。

(5) 高扩展性逃生舱。 custom_loop 支持接入第三方 ReAct 循环，不用改动内核。

ApprovalService 基于 asyncio.Future 实现点状工具前置审批，支持 EXACT（精确匹配，仅本次授权）和 SIMILAR（相似匹配，同类操作复用授权）两种作用域。在分布式部署场景下，虽然原生 asyncio.Future 不能跨进程，但是通过 Redis PubSub / MQ 降级为本地协程原语即可解决。这种“点状 HITL”与 AgentTeams 集群层的“线状全流程 HITL”形成互补——前者处理微观的单次工具调用审批，后者处理宏观的整个任务流程人机协作。

---

4. 面试高频追问速记

(1) 为什么要设计两套切面，而不是一套？

会话加载需要 Agent 实例化之前执行；模型、工具拦截要在 Agent 就绪之后执行；
合并一套切面，所有钩子都要处理 Agent 可为空，签名臃肿。
Runtime Hooks 管请求全生命周期，Middleware 管 ReAct 循环内部，二者正交。

(2) SHORT_CIRCUIT 和 SKIP_AGENT 的区别，使用场景？

SHORT_CIRCUIT 终止当前阶段；SKIP_AGENT 只跳过 Agent 的 build 与 run 步骤；
两者都保证 ON_ERROR、FINALLY 执行；斜杠命令场景使用 SKIP_AGENT，防止会话丢失。

(3) AgentMode 四元组解决了什么痛点？

commands、tools、hooks、prompt_contributors；
通过 setup 原子批量注册，解决组件分开注册带来的半激活残留问题，整套范式整体装卸。

(4) ModeGatedHook 属于切面还是模式？

基类定义属于 Runtime Hooks 切面底座；各个模式写的业务实现子类，属于 AgentMode 模式层。
框架提供底座能力，上层模式做业务实现。

(5) 新增一个全新业务模式，是否需要修改两套切面的源码？

不需要。只需要新增 AgentMode 子类，定义四元组，继承 ModeGatedHook 写业务钩子；
通过 setup 注册到底座，完全零侵入切面内核。