TL;DR：一个界面操作多种 Agent，最先解决的是工具切换与上下文搬运的摩擦。更深一层，它让用户可以依照任务场景选择合适的 Agent，再让 Claude、Codex、Antigravity 与 Grok 共同完成工作。模型页面负责缩小选择范围，统一界面负责调度与交接，人类则保留权限、证据与最终判断。

目前我的工作环境已经实现了在单一界面上操作多种 Agent。这体验极其奇妙，宛如《射雕英雄传》中的郭靖，竟能一人集结降龙十八掌、七十二路空明拳、左右互搏术、易筋锻骨章、九阴真经总纲、疗伤篇、上天梯、蛇行狸翻、飞絮劲、收筋缩骨法、移魂大法、大伏魔拳法、手挥五弦、摧坚神爪、白蟒鞭法、全真内功、金雁功、天罡北斗阵、南山拳法、开山掌法、分筋错骨手、空空拳、越女剑法、伏魔杖法、金龙鞭法、南山刀法、呼延枪法、金钟罩铁布衫、哲别神箭术、蒙古摔角、逍遥游、奇门遁甲与武穆遗书等万般绝学于一身。

Claude 可以操作 Codex，Codex 也可以操作 Claude。这个工作方式再延展出去，也可以让 Antigravity 与 Grok 参与其中。

表面上看，这像是多了几个工具选项。实际上，它改变的是我们使用 AI 的基本方式。

过去使用多个 AI 工具时，通常需要自己处理中间的摩擦：

图 1｜多工具切换如何造成工作中断

flowchart LR
    A[想到一个问题] --> B[打开第一个工具]
    B --> C[复制内容]
    C --> D[切换到第二个工具]
    D --> E[重新说明背景]
    E --> F[再切换其他工具]
    F --> G[整理多份输出]
    G --> H[回到原本的工作]

每个工具可能都很强，但用户必须一直负责搬运内容、维持上下文、记住工作进度，也要判断哪一份输出应该交给下一个工具。

现在的变化是，这些 Agent 可以被放进同一个操作面里。

图 2｜单一界面把多个 Agent 放进同一个工作脉络

flowchart TB
    U[用户]
    I[统一操作界面]
    C[Claude]
    X[Codex]
    A[Antigravity]
    G[Grok]
    U --> I
    I --> C
    I --> X
    I --> A
    I --> G

少开几个窗口只是表面结果。

它让用户开始从「使用某一个 AI」转向「调度一组可以互相协作的 Agent」。

真正的便利，是减少工作被切碎

多种 AI 工具同时存在，原本是一种选择自由，也可能变成一种操作负担。

每增加一个工具，就可能增加一套界面、一种操作方式、一组上下文，以及一种输出格式。工作者看似拥有更多能力，实际上却要花更多时间管理工具本身。

这里至少有四种摩擦。

第一种是界面摩擦。

用户要不断开启、关闭与切换不同的窗口。这些动作本身不产生价值，却会中断思考。

第二种是上下文摩擦。

同一项任务交给不同 Agent 时，用户经常需要重新说明背景、目标、限制与目前进度。只要其中一段信息没有传过去，下一个 Agent 就可能从错误的前提开始工作。

第三种是流程摩擦。

用户需要自己记住，哪一个 Agent 已经完成什么，下一步应该交给谁，哪些输出已经确认，哪些内容还只是建议。

第四种是责任摩擦。

当多份结果散落在不同工具中，用户很难回头追踪：哪一个 Agent 做了哪个决定？哪一段内容是原始资料？哪一段是推论？哪一个结果经过人工验收？

因此，一个界面操作多种 Agent 的价值，首先在于降低工具摩擦，让人的工作不要被工具切碎。

从「一个 AI 回答」变成「一个工作网络」

传统的 AI 使用方式，大致是这样：

图 3｜传统的一问一答式 AI 使用方式

flowchart LR
    H[人提出问题] --> M[一个 AI 产生答案]
    M --> J[人判断是否采用]

跨 Agent 工作流则更接近这个结构：

图 4｜跨 Agent 工作网络的基本结构

flowchart TB
    H[人提出任务] --> I[统一界面接收任务]
    I --> P[任务拆解与角色分配]
    P --> E[不同 Agent 分别执行]
    E --> T[Agent 之间交接结果]
    T --> R[统一界面整合进度]
    R --> J[人类验收与决策]

这个变化的关键，在于工作能否在不同 Agent 之间流动。

一个 Agent 可以负责理解问题，另一个 Agent 可以负责执行，第三个 Agent 可以负责找错，第四个 Agent 可以提供独立观点。最后，再由用户或指定的整合 Agent 收敛结果。

在这种架构中，AI 不再只是回答问题的工具，也成为工作网络中的不同节点。

我之前写过一篇〈三个 Claude，一个循环：我如何把设计探索接到实作上线〉，当时谈的是不同 Claude 界面之间如何通过 mock、spec 与 screenshot 接成一个循环。现在的跨 Agent 工作流再往前走了一步：交接的对象不再只是同一个产品的不同界面，而可能是不同系统、不同模型、不同权限环境中的 Agent。

模型选择要跟着场景走，而不是跟着品牌走

我每周会定期更新两次模型前沿实时仪表板。这个页面不是固定的模型排行榜，而是一张选择地图：依照写作、研究、程序开发与日常任务，整理目前值得考虑的模型与成本。

这一点对跨 Agent 工作流很重要。模型会更新，价格会变动，同一个模型在不同任务上的表现也可能不同。今天适合某个角色的模型，下一次更新后可能已经有更好的选择。

因此，文章不应该把 Claude 永远写成规划者、Codex 永远写成执行者，也不应该把 Antigravity 或 Grok 固定成某一种性格。比较准确的说法是：先看任务，再看当期模型资料，最后决定哪个 Agent 在这一轮工作中负责哪个角色。

模型页目前采取的阅读顺序，也可以直接转成跨 Agent 的选择流程：先看能力差异是否超过误差范围；如果分数接近，再比较成本；接着确认评测是否真的对应自己的任务；最后把数据主权与安全风险放进决定里。

图 5｜依任务场景选择本轮 Agent

flowchart TB
    A[输入任务场景] --> B[查看模型选择地图]
    B --> C{主要限制是什么？}
    C --> D[能力与任务适配]
    C --> E[成本与使用频率]
    C --> F[泛化能力与陌生问题]
    C --> G[安全与提示注入风险]
    D --> H[选择本轮 Agent]
    E --> H
    F --> H
    G --> H
    H --> I[设定角色与权限]
    I --> J[执行、交接与验收]

这张地图不是要替用户做最后决定。它的作用，是先把选择范围缩小，让用户可以再用自己的任务测试。尤其要注意，长程 agentic 编码的结果，不能直接当成日常对话、写作或研究的总排名；成本也要确认计算基准，API 用量成本与聊天订阅费不是同一件事。

这也代表模型角色是一种工作配置，不是品牌本质。

不同 Agent 可以在同一项工作里分工

跨 Agent 协作的前提，是不要把所有 Agent 都当成同一种工具。

在一项任务里，Agent 可以有不同角色：

角色主要工作
规划者理解需求、拆解任务、安排顺序
执行者写代码、整理资料、产出文件
审查者找错、提出反例、检查遗漏
外部顾问提供另一个系统或模型的观点
整合者比较结果、处理冲突、形成最后输出

同一个 Agent 在不同任务中，也可能扮演不同角色。

例如，一次任务可以采取以下流程：

图 6｜不同 Agent 在同一项工作中的角色分工

flowchart LR
    H[用户提出任务] --> C[Claude：理解与规划]
    C --> X[Codex：执行或修改]
    X --> G[Grok：提出独立观点]
    G --> A[Antigravity：协助检查或延伸]
    A --> C2[Claude：整合结果]
    C2 --> H2[用户：确认是否采用]

这张图是角色示意，实际流程仍然要依任务内容决定，不必固定成同一条路径。

这里真正要问的是：「哪个 Agent 适合负责目前这一步？」

当工作被拆成不同阶段后，Agent 的价值就不再只由单次回答品质决定，也包含它能否正确接收任务、交付结果，以及让下一个 Agent 继续工作。

Claude 与 Codex 的双向操作

目前已经可以看见一种更接近协作的关系：Claude 可以提供建议，也可以把工作交给 Codex；Codex 可以独立执行，再把结果交回 Claude。

流程可以表示为：

图 7｜Claude 与 Codex 的正向交接流程

sequenceDiagram
    participant U as 用户
    participant C as Claude
    participant X as Codex
    participant I as 统一界面

    U->>I: 提出工作目标
    I->>C: 交给 Claude 分析
    C->>I: 回报任务拆解
    C->>X: 交接具体工作
    X->>I: 回报执行结果与证据
    I->>C: 提供结果供整合
    C->>U: 提出下一步或待确认事项

反向流程则是：

图 8｜从执行回到分析的反向反馈流程

flowchart LR
    X[Codex 执行中] --> Q[发现需要重新分析的问题]
    Q --> C[交给 Claude 重新整理]
    C --> D[Claude 提出判断或替代方案]
    D --> X2[Codex 继续执行]
    X2 --> U[用户验收]

这里的重点，在于任务能否顺利流动。

真正重要的是，任务不必在某一个工具里结束。它可以从规划进入执行，再从执行回到分析，最后形成一个可以被人类验收的结果。

这种工作方式也延续了我之前让 Codex 审查 Claude 的经验。那篇〈我让 codex 挑 Claude 的错，但不照它说了算〉谈的是如何保留第二意见的独立性；这篇更进一步处理的是，当第二个 Agent 不只审查，还可以被纳入同一个工作流时，交接与权限要怎么设计。

另外，〈让 Claude Code 借 Codex CLI 生图〉已经是一个具体的跨 Agent 实例：一个工作环境中的 Agent 借用另一个 Agent 的能力，完成原本不在单一工具里的任务。本文要讨论的范围更大，从单一能力借用，延伸到一个界面里的多 Agent 调度。

一个界面扮演的是工作控制面

统一界面的重要角色，是让用户掌握整个工作的状态，而不只是把不同品牌的按钮放在一起。

理想的操作面，至少要让人看见：

图 9｜统一界面需要呈现的工作状态

flowchart TB
    T[目前任务] --> R[目前负责的 Agent]
    R --> P[目前进度]
    P --> D[已完成的工作]
    D --> N[下一步接手者]
    N --> H[需要人工确认的地方]

因此，统一界面可以被理解成一个工作控制面：

图 10｜统一界面作为跨 Agent 工作控制面

flowchart TB
    U[用户]
    I[统一工作控制面]
    T[任务规划]
    S[Agent 选择]
    P[权限管理]
    V[进度追踪]
    R[结果整合]
    H[人工验收]
    U --> I
    I --> T
    I --> S
    I --> P
    I --> V
    I --> R
    I --> H

这个控制面将不同 Agent 的能力放在同一个工作脉络里。

用户可以先说明自己要完成什么工作，再决定这项工作适合由哪个 Agent 负责，不必先思考「我现在应该打开哪个工具」。

这是很大的差异。

工具导向的工作方式，是人配合工具。

任务导向的工作方式，则是工具配合任务。

一次跨 Agent 任务的完整流程

一个比较完整的跨 Agent 工作流，可以拆成九个步骤：

图 11｜一次跨 Agent 任务的九步流程

flowchart TB
    A[1. 输入需求] --> B[2. 拆解任务]
    B --> C[3. 选择适合的 Agent]
    C --> D[4. 设定上下文与权限]
    D --> E[5. Agent 执行]
    E --> F[6. 交接输出与证据]
    F --> G[7. 另一个 Agent 审查或延伸]
    G --> H[8. 统一界面整合]
    H --> I[9. 人类验收、继续或停止]

每一个步骤都有自己的责任。

「输入需求」要处理的是目标。

「拆解任务」要处理的是工作顺序。

「选择 Agent」要处理的是角色分工。

「设定上下文与权限」要处理的是边界。

「交接输出与证据」要处理的是可追踪性。

「人类验收」则要处理最终责任。

如果只把多个 Agent 放在一起，没有这些流程，最后可能只是多个答案并排出现。只有当任务、资料与责任能够被传递，才真正形成工作流。

Agent 交接不能只靠复制聊天记录

跨 Agent 工作最容易出现的问题，是把一整段聊天记录直接交给下一个 Agent。

这样看似保留了完整上下文，却不一定真的有帮助。下一个 Agent 仍然需要自己判断：

  • 哪一句是任务
  • 哪一句是背景
  • 哪一句只是讨论中的想法
  • 哪些内容已经确认
  • 哪些内容只是暂时假设
  • 哪些事情不能执行

因此，Agent 交接应该整理成一份简单的工作契约：

任务目标：
目前进度：
已知上下文：
可使用的资料：
不可使用或不可外传的资料：
允许的操作：
禁止的操作：
期待输出：
验收条件：
停止条件：
下一步接手者：

这份交接资料的价值，在于让下一个 Agent 不需要重新猜测工作边界。

更完整的交接流程如下：

图 12｜从 Agent A 到 Agent B 的交接信息流

flowchart LR
    A[Agent A]
    B[整理任务目标]
    C[整理已知上下文]
    D[标示证据与待确认事项]
    E[标示权限与限制]
    F[交给 Agent B]
    G[Agent B 产出结果与依据]
    H[回到统一界面]
    I[人工或其他 Agent 验收]
    A --> B --> C --> D --> E --> F --> G --> H --> I

好的交接应传递下一步工作真正需要的信息，而不是把所有聊天记录全部搬过去。

便利性越高，权限边界越重要

一个界面可以操作多种 Agent，会大幅降低使用门槛。但这种便利性也会带来新的问题。

如果 Agent 可以操作其他 Agent，谁决定它可以做什么？

如果一个 Agent 可以启动另一个 Agent，这个权限是否会一路扩大？

如果多个 Agent 都能看到同一份资料，哪些内容可以共用，哪些内容不能离开原本的工作范围？

因此，跨 Agent 工作流除了确认「能不能做」，还需要处理「允许做到哪里」。

可以把权限分成几个层次：

图 13｜权限从信息查看逐步接近外部行动

flowchart TB
    A[查看信息] --> B[分析信息]
    B --> C[提出建议]
    C --> D[修改工作内容]
    D --> E[执行外部操作]
    E --> F[代表用户对外行动]
    F --> H[人工确认]

越接近外部世界，越需要人工确认。

例如，以下事项不应该只因为工作流很顺，就直接自动完成：

  • 登录账号
  • 使用私人资料
  • 读取或传递机密
  • 使用 API 密钥
  • 发送对外消息
  • 执行付款
  • 发布内容
  • 部署网站
  • 进行不可逆的删除或修改

统一界面可以把这些操作集中起来，但集中不等于放任。

它应该让用户更清楚看见：现在是哪个 Agent 在工作、它正在使用什么权限，以及下一个动作是否需要本人确认。

Agent 越多，判断未必更可靠

多个 Agent 可以协助找出不同角度，但数量本身不会自动产生正确答案。

它们可能共享同一个错误前提，也可能因为上下文相同而一起得出相似的错误结论。

因此，跨 Agent 协作需要区分三种东西：

图 14｜原始资料、Agent 分析与人类判断的分层

flowchart TB
    A[原始资料] --> B[Agent 的分析]
    B --> C[用户或其他 Agent 的判断]
    A -. 必须保留来源 .-> C

这三者不能混在一起。

在交接时，最好标明：

  • 哪些内容已经确认
  • 哪些内容来自原始资料
  • 哪些内容是 Agent 的推论
  • 哪些内容仍然待查
  • 哪些内容只是暂时方向

这也是为什么我不会把「多个 Agent 都同意」直接当成证明。

共识可以增加信心，但不能取代证据。

统一界面也需要失败时的退路

一个工作流如果只有成功路径，还不能算完整。

跨 Agent 协作可能在不同地方中断：某个 Agent 无法使用、权限不足、上下文不完整、输出格式不符合、外部服务没有回应，或不同 Agent 对同一个问题得出互相冲突的判断。

因此，流程中应该预先保留退路：

图 15｜Agent 失败时的修正、转交与人工接管

flowchart TB
    A[Agent 执行] --> B{结果符合验收条件吗？}
    B -->|是| C[交给下一步]
    B -->|否| D{问题是否可修正？}
    D -->|是| E[回到原 Agent 修正]
    D -->|否| F[交给另一个 Agent 审查]
    F --> G{是否需要人工判断？}
    G -->|否| C
    G -->|是| H[停止并交回用户]

这个设计有一个重要含义：Agent 失败时，系统应该清楚显示失败，不能为了让流程看起来顺利，就偷偷改变任务目标或降低验收标准。

对用户来说，「现在需要我判断」本身就是一种有效的结果。

从多模型使用，走向跨 Agent 工作系统

Claude、Codex、Antigravity 与 Grok 的存在，让我们可以依照不同任务安排不同 Agent。

更值得注意的是，这些工具被放进了什么样的系统里。

一个成熟的跨 Agent 工作系统，应该具备：

图 16｜成熟跨 Agent 工作系统的核心组成

flowchart TB
    A[统一界面] --> B[清楚的任务拆解]
    B --> C[明确的角色分工]
    C --> D[可追踪的 Agent 交接]
    D --> E[受控的权限边界]
    E --> F[可验收的输出]
    F --> G[保留人工决策]

这个系统的中心仍然是人。

人不必亲自完成每一个步骤，但需要知道每一个步骤发生了什么，也需要在关键地方保留停止与修正的能力。

对我来说，最有价值的变化，在于我可以在一个界面里，让不同 Agent 进入同一项工作，让任务从规划流向执行，再流向检查与整合。

人开始设计自己的 Agent 工作环境

过去我们问的是：

哪一个 AI 最适合我？

现在更值得问的是：

我能不能在同一个界面里，让不同 Agent 各自完成适合自己的工作？

这个问题的答案，取决于模型能力、界面设计、任务交接、权限管理与人工判断如何被放在一起。

当 Claude 可以操作 Codex，Codex 可以回到 Claude，工作又能延展到 Antigravity 与 Grok，AI 的使用方式就不再只是「打开一个聊天窗口，等待一个回答」。

我与我们身边的同温层，已经开始建立的是一个由人类设定方向、由多个 Agent 协作完成的工作环境。

・一个界面解决了工具切换的问题。 ・跨 Agent 交接解决了工作流动的问题。

而权限与人工验收，则决定这个系统是否值得信任。重要的是我们能不能让多个 Agent 在清楚的边界内，为同一项工作彼此接力。每一位后AI时代的工作者都需要自己设计与优化最适合自己工作模式与流程的系统。