Plugin Design Patterns

不是每个 plugin 都应该长得一样。

在当前 Downcity 里，健康的 plugin 设计通常从“先选主形态”开始。

1. Action-first plugin

适合这些目标：

• 显式用户触发能力
• 明确的命令或 API 入口
• 边界清楚的一次性工作

典型例子：

• skill
• tts

2. Hook / resolve plugin

当 plugin 需要参与现有运行链路时，使用这种形态。

典型例子：

• auth
• asr
• 各类 role resolver 风格 plugin

3. System-text plugin

当 plugin 的主工作是增加稳定运行时指导文本时，使用这种形态。

典型例子：

• skill
• web
• memory

4. Lifecycle-owned runtime plugin

当 plugin 必须拥有长期运行态时，使用这种形态。

典型例子：

• chat
• task
• shell

ActionSchedule 有意不建模成 plugin；它是共享的 Agent action 模块。

它适合这些能力：

• start
• stop
• recover
• 持有内存状态
• 随时间 poll 或 react

5. Runtime HTTP plugin

当 plugin 主要通过 HTTP 暴露状态或控制面时，使用这种形态。

典型例子：

• workboard

一个实用判断

不要先问“这段代码最方便塞在哪里”。

先问：

• 它是不是显式命令
• 它是不是链路参与点
• 它是不是稳定 system 指导
• 它是不是生命周期拥有的 runtime state
• 它是不是 HTTP 暴露面

相关文档

• Plugin Lifecycle
• Plugin Actions
• Plugin Hooks
• Plugin Runtime Composition