Codex核心概念
Agent = 模型（Model）+ 运行框架（Harness）
- 模型（Model） 提供推理和决策能力，比如 GPT-5.3-Codex。
- 运行框架（Harness） 提供执行环境、工具接口和循环控制。
Codex 的核心是一个 “智能体运行框架”（Agent Harness）。它并非简单的“提示词+模型”，而是一个有状态的运行时系统，负责管理对话状态、流式执行、工具调用、沙箱隔离和审批流程等。
Agent Loop（智能体循环） 是这个框架的心脏，它协调用户、模型和工具三者之间的交互，形成一个闭环。其基本流程是：
- 接收输入：从用户获取指令，整合为模型可用的文本提示。
- 模型推理：模型分析提示，决定是直接回复还是调用工具。
- 工具执行：若需调用工具（如执行Shell命令），框架会执行该工具并捕获结果。
- 结果反馈：将工具执行结果返回给模型，进入下一轮推理，直至任务完成。
Codex 的哲学可以概括为：可复用的部分是智能体循环，仓库即事实来源，工程的价值在于设计环境、表达意图、构建反馈循环。
Multi-Agent：从“单兵”到“团队”
当任务变得庞大或需要不同领域的知识时，单一 Agent 的上下文会变得臃肿，效率也会下降。Multi-Agent 系统通过任务分解和并行执行来解决这个问题。其核心理念是，将一个主任务拆解为多个子任务，交给专门的 Agent 并行处理，最后汇总结果。
在 Codex 中，这通常被称为 子代理（Subagents）。它们是由主 Agent 派生出的“专项助手”，每个都在独立的上下文中工作，避免污染主对话的“记忆”。Codex 内置了 default、worker、explorer 等基础角色，你也可以通过 TOML 文件自定义 Agent 的模型、指令和权限。
一个关键特性是：Codex 默认不会自动拆分任务。只有在你明确要求“并行处理”或“开几个 agent”时，它才会启用子代理。这样做是为了避免不必要的复杂度和资源消耗。
🏗️ 多智能体的协作“拓扑”
多 Agent 系统并非简单地把任务扔给一群 Agent，它们之间需要明确的协作模式。常见的编排模式包括：
| 模式 | 运作方式 | 适用场景 |
|---|---|---|
| 顺序流水线 | Agent 按预定顺序执行，上一个的输出是下一个的输入 | 步骤明确、依赖性强的工作流 |
| 协调者-工作者 | 一个协调者 Agent 拆解任务，分发给多个工作者 Agent 并汇总结果 | 任务可清晰拆分为独立子任务 |
| 扇出/合并 | 多个 Agent 并行处理同一任务的不同部分，最后合并结果 | 大规模搜索、多角度分析 |
| 生成-验证 | 一个 Agent 生成方案，另一个 Agent 专门负责审查和验证 | 代码生成、安全审查 |
| 辩论/对抗 | 多个 Agent 就同一问题提出不同观点并进行辩论，以提升结论质量 | 复杂决策、方案评估 |
在 Codex 的实践中，这意味着你可以让一个 Agent 负责重构前端组件，同时让另一个 Agent 并行处理后端 API 的兼容性，最后由主 Agent 统一集成和测试。
总结
Agent 是具备自主循环能力的个体，能够独立感知、决策和行动。Multi-Agent 则是通过分工与协作，将单个 Agent 的能力边界向外扩展的系统性方法。在 Codex 中，这体现为以 Agent Loop 为核心的可复用引擎，以及由你按需调遣的 Subagents 团队。
扩展机制：Skill、Plugin 与 MCP 的关系
Skill 、Plugin 和 MCP 构成了 Codex 的扩展装配层，它们共同定义和扩展了 Codex 的能力边界。三者的定位和关系如下：
| 概念 | 核心定位 | 一句话理解 |
|---|---|---|
| Skill（技能） | 可复用的工作流“说明书” | 告诉 Codex “怎么做” 某类重复性任务 |
| MCP（模型上下文协议） | 连接外部工具与数据的“标准接口” | 让 Codex “能调用” 外部服务 |
| Plugin（插件） | 可安装、可分发的“能力包” | 将 Skill 和 MCP 服务器等打包，方便**“一键安装和共享”** |
