具体问题与边界
“扩展 Codex”至少可能指四件事：在生命周期点运行受限命令、连接外部工具服务、打包可安装能力，或 在宿主进程内贡献强类型对象。如果统称插件，开发者会误判信任和失败半径。Codex 的 Hook、MCP、 Plugin/Skill 与 Extension Contributor 处于不同进程边界和生命周期。
本节讨论架构选型；具体安装 UI 和产品可用性以官方文档为准。
能力与信任矩阵
| 扩展面 | 运行位置 | 主要合同 | 信任/失败半径 | 适合场景 |
|---|---|---|---|---|
| Hook | 外部命令进程 | lifecycle JSON in/out | timeout、kill、解析限制 | 阻断、通知、附加上下文 |
| MCP | STDIO/HTTP 服务 | tools/resources/schema/auth | 服务边界、网络与审批 | 外部数据和受控动作 |
| Skill | 模型上下文 + 资源 | SKILL.md 工作流 | 指令作用域 | 可重复流程指导 |
| Plugin | 安装包 | skill/MCP/hook/assets manifest | 安装与管理边界 | 分发一组能力 |
| Extension Contributor | 宿主进程 Rust | typed contributor traits | 最高信任、可影响 Session | 原生工具、上下文和生命周期集成 |
官方 Plugin architecture 同样建议从满足用例的最小形态开始：只有工作流指导就用 Skill，需要服务 能力再加 MCP；这与源码中的不同信任边界相互补充。
正常选择与接入
- 只需告诉模型怎样完成稳定流程时，使用 Skill；全文按需进入上下文，不创造新执行权限。
- 需要认证外部服务或动态工具目录时，使用 MCP；Catalog revision 在 Step 边界进入 ToolPlan。
- 需要围绕已有事件阻断、改写或通知时，使用 Hook；配置发现、trust、matcher、timeout 和 JSON schema 构成护栏。
- 需要把 Skill、MCP、Hook 与资产作为一个可安装单元分发时，使用 Plugin manifest。
- 只有宿主编译并完全信任的原生能力才进入 Extension Contributor；它可贡献 Tool、Context、MCP 或生命周期对象，因此故障半径也最大。
扩展面可以组合，但组合不消除边界。例如 Plugin 打包 MCP server，并不会让 MCP 代码获得进程内 Extension 的信任；Skill 引导工具使用，也不会绕过工具自身审批。
Python 风格伪代码
class ExtensionKind(Enum):
SKILL = "skill"
MCP = "mcp"
HOOK = "hook"
PLUGIN = "plugin"
IN_PROCESS = "in_process"
def choose_extension(requirement: Requirement) -> ExtensionKind:
if requirement.needs_host_objects:
assert requirement.code_is_fully_trusted
return ExtensionKind.IN_PROCESS
if requirement.needs_external_service:
return ExtensionKind.MCP
if requirement.needs_lifecycle_gate:
return ExtensionKind.HOOK
if requirement.needs_installable_bundle:
return ExtensionKind.PLUGIN
return ExtensionKind.SKILL
async def run_hook(command: HookCommand, payload: dict[str, object]) -> HookOutcome:
process = await spawn_limited(command, kill_on_drop=True)
stdout, stderr = await wait_with_timeout(process, command.timeout)
return parse_bounded_hook_output(stdout, stderr)伪代码只展开 Hook，因为它最容易被误当作宿主回调。MCP 必须另有 transport/auth/schema，进程内
Contributor 则依赖编译期类型，不应被一个统一 run_extension() 抹平。
失败与错误选型
| 错误选型 | 结果 | 调整 |
|---|---|---|
| 用 Skill 代替权限系统 | 只有提示约束 | 保留 Runtime Policy/Sandbox |
| 用 Post Hook 做回滚 | 副作用已经发生 | 将阻断前移到 Pre/Policy |
| 用 Hook 注册原生 Tool | 只有事件回调，无 typed executor | 使用 MCP 或受信 Contributor |
| 不可信逻辑做 Contributor | 可崩溃/阻塞宿主 | 移到 Hook/MCP 进程边界 |
| MCP 目录原地热改 | 旧 Step ToolCall 漂移 | revision + 新 Step snapshot |
| Plugin 安装成功即视为授权 | 能力包存在但权限未确认 | 各 MCP/Hook/Tool 继续独立审批 |
| 一个通用错误策略 | 忽略不同失败半径 | Hook soft-fail、required MCP fail-fast 等分别定义 |
设计判断
扩展架构的第一问题不是“API 是否统一”，而是代码在哪里运行、能贡献什么、失败由谁吸收。统一发现 和打包体验有价值，但运行期边界必须保持差异，否则安全和可观测性都会退化。
小型 Agent 通常从 Skill + MCP 足够；只有需要稳定生命周期策略时再加 Hook。进程内扩展要求版本、 panic/timeout 和 API 兼容治理，不应为了少一次 IPC 而默认采用。
证据与 Mini Codex
生产锚点为 hooks/src/engine/*、ext/extension-api/src/contributors.rs、MCP ConnectionManager、
Plugin manifest/loader；7.24—7.40 已覆盖发现、刷新、调用和信任。
Mini Codex 只有 Tool Hook 与最小 MCP Catalog Adapter：
cd examples/mini-codex
uv run pytest -q -k 'hook or mcp'它不实现 Skill/Plugin 安装和进程内 Contributor，只能用于比较 Hook/MCP 的控制面差异。
本节边界
前九节归纳了生产设计。下一节回到可执行 Mini Codex，区分测试真正证明的合同与仍未覆盖的区域。 详细源码映射由研究仓库中的配套索引维护。
评论
登录后即可评论