5.Trae_Workflow_Codex 多智能体讨论总结

1. 背景

这份文档整理了我们关于以下主题的讨论：

• 为什么 Trae 和 Workflow 会显式提供“选择智能体 / 专家”
• 为什么 Codex 的使用体验看起来不一样
• 在 Codex 中如何理解 agent、sub-agent、skill、plugin
• 如何在 Codex 里设计一个真实的多智能体研发工作流

2. 为什么 Trae 和 Workflow 会显示“选择智能体”

像 Trae、Workflow 这样的产品，通常会把“多智能体协作”设计成一个前台可见的核心概念。

它们的典型特点是：

• 会直接展示角色卡片，例如架构师、前端专家、测试专家、评审专家、产品经理
• 用户会被引导直接选择某个专家来处理任务
• 产品强调的是“流程编排”和“角色分工”
• “专家”本身就是交互模型的一部分

所以它们给人的体验通常是：

选择专家 -> 分配任务 -> 查看不同角色的输出

这种方式会让用户明显感觉到：“现在是多个智能体在协作工作。”

3. 为什么 Codex 给人的感觉不一样

Codex 并不是优先按“专家市场”或者“智能体选择器”这种产品思路来设计的。

它更常见的工作方式是：

• 用一个主 agent 作为统一入口
• 通过 skills 提供专业化能力
• 通过 plugins 和工具补充额外能力
• 在支持的环境下，由主 agent 按需派生 sub-agents

所以 Codex 的体验更接近：

一个主 agent -> 按需加载 skills / tools / plugins -> 必要时委派 sub-agents

这意味着 Codex 并不是没有多智能体能力，而是没有默认把它做成一个“前台角色选择器”。

4. Codex 里的核心概念

4.1 Agent

agent 是执行者。

它负责：

• 理解用户目标
• 持续维护任务上下文
• 决定下一步做什么
• 调用工具
• 读代码、改文件、执行命令
• 汇总和整合结果

你可以把主 agent 理解成一个项目总控，或者一个主执行工程师。

4.2 Sub-agent

sub-agent 是由主 agent 派生出来、专门负责某个子任务的执行者。

典型用途包括：

• 并行探索代码库
• 独立执行评审任务
• 做交叉验证
• 在工作流里承担某个明确角色

sub-agent 更适合这些场景：

• 任务边界清晰
• 工作可以明确拆开
• 并行处理会明显提高效率

4.3 Skill

skill 不是另一个智能体。

skill 更像一套可复用的“工作手册”或“专家作业说明”。

它会告诉 agent：

• 什么情况下应该启用它
• 启用后应该怎么做
• 哪些脚本、模板、参考资料更重要
• 输出结构应该长什么样

所以可以简单理解为：

• agent = 谁来做
• skill = 按什么专业方法做

4.4 Plugin

plugin 是一个能力包。

它可能会提供：

• 一个或多个 skills
• 工具
• MCP 服务
• 应用集成

所以：

• skill 是具体的能力单元
• plugin 是能力的打包和分发层

5. 如何区分 Skill 和 Agent

一个最简单的判断规则是：

• 如果你需要一个新的执行者，优先考虑 agent
• 如果你需要一套可复用的方法论，优先考虑 skill

例如：

• “PR 评审专家流程” -> 更适合做成 skill
• “一个独立的评审员并行工作” -> 更适合做成 sub-agent
• “固定按 Markdown 输出的写作流程” -> 更适合做成 skill
• “另一个助手独立分析需求” -> 更适合做成 sub-agent

一个比较准确的整体模型是：

Main agent = 总控执行者
Sub-agent = 被委派的执行者
Skill = 专家方法手册
Plugin = 能力包

6. 为什么 Codex 常常让人感觉“只有一个 Agent”

在日常使用中，Codex 常常会让人觉得它像一个单智能体系统，主要原因有：

• 用户入口通常就是一个主助手
• 很多“专家行为”被封装在 skills 里，而不是前台角色
• 不是每个任务都需要显式委派
• sub-agent 更像是一种工作流能力，而不是默认 UI 展示对象

所以正确的理解不是：

Codex 用 skill 替代了 agent

而是：

Codex 默认用一个主 agent 作为入口，再通过 skills、tools、plugins 和 sub-agents 来扩展能力

7. 在 Codex 里如何模拟“专家协作”

主要有两种方式。

方式 A：以 Skill 为主

仍然用一个主 agent，但为它提供多个角色化的 skills。

例如：

• markdown-writer
• pr-code-review
• tfs-pr-review
• multi-agent-workflow

这种方式适合：

• 方法论稳定
• 流程复用要求高
• 不一定需要真正并行

方式 B：以 Sub-agent 为主

使用一个主 agent，把任务拆给多个 sub-agents。

这种方式适合：

• 需要明确角色分工
• 希望有独立视角分析
• 想模拟“多位专家协作”
• 并行处理确实有价值

最理想的组合方式是：

Sub-agents 负责角色分工
Skills 负责角色方法论
Main agent 负责总控编排

8. 我们设计过的一个多智能体研发工作流

我们讨论过一个针对 3 个需求、按顺序完成的研发流程。

外层流程

需求1 -> 需求2 -> 需求3

每个需求的内层流程

产品分析
-> 研发实现
-> 研发自测
-> 代码评审
-> 如果不通过：返回研发继续改造
-> 如果通过：Git 提交
-> 进入下一个需求

角色分工

- sub-agent1：产品经理 / PM 分析
- sub-agent2：研发实现
- sub-agent3：研发自测
- sub-agent4：代码评审
- sub-agent5：Git 提交

主 Agent 的职责

- 维护当前处理到第几个需求
- 维护当前需求所处阶段
- 调度对应的 sub-agent
- 阻止非法流转
- 评审失败时回退到研发阶段
- 只有提交完成后，才能进入下一个需求

这个流程本质上就是一个状态机。

9. 关于 Codex 多智能体工作流的真实结论

对于真实的工程场景来说：

• 不是每个角色都一定要起一个单独的 sub-agent
• 很多步骤其实是强串行依赖的
• 角色清晰更适合演示、规范和审计
• 实际效率上，往往混合模式更合适

所以现实里通常有两种方案：

严格角色流

• PM 子智能体
• 研发子智能体
• 测试子智能体
• 评审子智能体
• 提交子智能体

适合：

• 演示
• 流程治理
• 可审计工作流

混合工作流

- 主 agent 负责总控
- 少量 sub-agent 承担核心独立角色
- 其余流程逻辑用 skills 来约束

适合：

• 提高效率
• 降低调度开销
• 更贴近真实项目交付

10. 我们已经创建的项目级 Skill

我们已经把前面设计的多智能体工作流落成了一个项目级 skill：

multi-agent-workflow

它的结构如下：

• SKILL.md
• workflow-template.md
• openai.yaml

它的作用是：

• 让 Codex 能识别这是一个项目专属工作流
• 为多需求串行交付提供可复用的流程规范
• 支持主 agent + 多 sub-agents 的角色化协作

11. 最终心智模型

如果只保留一段最关键的总结，可以记成：

Trae / Workflow：
  专家是前台可见产品能力

Codex：
  一个主 agent 是默认入口
  skills 提供专家方法
  plugins 打包能力
  sub-agents 提供委派执行

如果放到研发工作流里，可以进一步记成：

Main agent = 工作流编排器
Sub-agents = 角色执行者
Skills = 可复用的专家手册
Plugins = 能力容器

12. 推荐使用策略

针对你的场景，长期最合适的策略是：

1. 用 project-level skills 沉淀重复出现的流程规则
2. 需要明确角色分工时，用 sub-agents
3. 由 main agent 控制顺序、状态和质量门禁
4. 平时真实开发建议用“混合模式”，测试或演示时可以用“严格角色模式”