让本地 Qwen3.8 Flash Next UD-IQ4_XS 主导开发：按需向 GPT-6.1 Sol、GPT-6 Astra 分派任务，并集成 Codex 图片生成服务

在上一篇 Strata 实测中，我已经用 64 GB RAM 与 RTX 5060 Ti 16 GB 运行 Qwen3.8-Flash-Next UD-IQ4_XS。模型能在自己的电脑上运行之后，下一个问题是：如何让它接手日常开发，并在需要时找到合适的外援？

此前的尝试，是由云端模型向本地 Qwen 分派任务，再通过代码审查与 harness 调整它的工作方式。这次我把主导权交给本地 Qwen，让 OpenCode 提供读取文件、修改、测试与任务分派能力；GPT-6.1 Sol 和 GPT-6 Astra 则成为可按需调用的子代理。图片生成单独封装成工具，通过本地 Codex 执行。

截至 2026 年 10 月 25 日，这套配置已完成新会话默认模型验证、两条子代理路由测试，以及生成图片后交回 OpenCode 打开的完整流程。以下记录实际采用的配置、过程中遇到的问题，以及这些测试能说明的范围。

本地 Qwen 负责主流程，云端模型提供外援

这套配置包含三个代理与一个图片工具：

这里的分工是我为工作流设定的角色，没有把 Sol 限制为只能写代码，也没有把 Astra 限制为只能提建议。两个外援在获得明确的修改范围后，都可以直接实现与测试；如果任务只要求诊断或代码审查，就保持只读。

Qwen 保留规划与验收责任。简单修改通过验收后即可交付，不为每次修改固定安排另一个模型再审查一轮。

实际协作关系可以整理为：

“本地”描述的是 Qwen 的推理位置，以及 Codex CLI 的启动位置。Sol、Astra 与图片生成仍会使用云端能力；交给外援的任务内容也会随请求发送到云端。

先明确任务分派条件与交接内容

我在 Qwen 的工作指令中设定了几个判断原则。

目标清晰、范围可控、验收条件明确的任务，由 Qwen 自己处理。方向已经确定，但需要较大范围的跨文件实现或持续调试时，可以交给 Sol。遇到根因不明、证据相互矛盾，或需要架构取舍的问题，则可以直接找 Astra。

这意味着 Qwen 不必先找 Sol，失败后才能找 Astra。分派给谁取决于问题本身。

另一条规则是：同一问题经过两次有实质差异的修正仍无进展，或开始重复已证明无效的方法时，应停止自行重试并寻求外援。单纯重新运行命令或换个说法，不算新的修正；测试仍然失败，也不一定意味着没有进展。

这些是写在代理提示词中的工作规范，仍由模型判断如何执行。目前没有另外实现失败次数计数器或自动切换状态机。

子代理会获得新的会话，因此每次交接都要求包含：

• 任务目标与可观察的验收条件。
• 工作区、相关文件、现有差异与不可改动的限制。
• 本次是只读诊断，还是允许修改及测试。
• 错误输出、复现方式、已尝试的方法与结果。
• 需要报告的修改、验证结果与尚未确认的事项。

对于共享文件，我另外写入了“同一范围同时只由一名代理修改”的规范。外援接手后，Qwen 暂停修改该范围，直到结果交回；已经应用的补丁，也不应再次应用。这项协作规则目前同样由提示词约束，没有新增文件锁。

OpenCode 的模型与权限配置

本次使用 OpenCode 2.0.32，配置放在用户的全局配置目录。Windows 上的位置为：

C:\Users\<你的账号>\.config\opencode\
├─ opencode.json
├─ agents\
│  ├─ qwen-main.md
│  ├─ sol.md
│  └─ astra.md
└─ plugins\
   └─ codex-image\

OpenCode V2 可以使用 Markdown 文件定义代理，包括模型、模式、权限与工作指令；全局代理文件会应用到不同项目。以下摘录本次已应用的配置，省略已有的 provider、MCP 与其他插件内容。OpenCode 代理文档

{
  "default_agent": "qwen-main",
  "model": "strata/qwen3.8-flash-next-unsloth-ud-iq4_xs",
  "permissions": [
    {
      "action": "subagent",
      "resource": "*",
      "effect": "deny"
    }
  ]
}

这段应合并到已有配置中，不宜直接用它覆盖整个文件。前提是 Strata provider 与 OpenAI 登录已经配置完成，模型标识符也能被当前 OpenCode 环境解析。这里保留的 strata/...unsloth... 是已有服务的配置标识符；本次路由测试没有重新核对后端实际加载的权重版本。

在 qwen-main.md 中，主代理只允许向两个对象分派任务：

---
mode: primary
model: strata/qwen3.8-flash-next-unsloth-ud-iq4_xs
permissions:
  - action: subagent
    resource: "*"
    effect: deny
  - action: subagent
    resource: sol
    effect: allow
  - action: subagent
    resource: astra
    effect: allow
---

sol.md 的模式、模型与任务分派权限为：

---
mode: subagent
model: openai/gpt-6.1-sol
permissions:
  - action: subagent
    resource: "*"
    effect: deny
---

astra.md 则使用：

---
mode: subagent
model: openai/gpt-6-astra
permissions:
  - action: subagent
    resource: "*"
    effect: deny
---

以上是配置部分的摘录。Markdown 正文会成为该代理的 system prompt，替代 provider 的默认提示词，因此正式代理文件也保留完整的开发、工具使用、交接与验收规范。只有模型名称与权限并不足以表达整套工作方式。

全局的 subagent: "*" 拒绝规则仍然保留。OpenCode 会先应用全局权限，再应用代理自己的规则，最后一条匹配的规则生效，因此 Qwen 可以额外允许 Sol、Astra；没有单独开放权限的代理，则继续受全局规则限制。OpenCode 权限合并与规则顺序

目前的任务分派关系如下：

我最终保留了这个单层结构，没有新增 Qwen worker，也没有加入多层任务分派或额外的 Strata 并发调度。这让每次任务的责任与交接更容易追踪。

修改配置后还有一点容易忽略：已有会话会保存自己的代理与模型选择。新的默认值不会自动替换旧会话的选项，因此我另外创建了未指定代理与模型、也没有被项目配置覆盖的新会话，确认它确实使用 Qwen。

完整代理文件、图片插件与配置合并示例已整理为文章配套源代码。复现时先确认 OpenCode 的 Strata 与 OpenAI 连接可用，再单独确认本地 Codex CLI 已完成 ChatGPT 登录；两者的登录状态需要分别检查。接着备份已有配置、放入代理文件与插件、合并配置并重新加载，最后创建新会话逐项测试。配套说明列出了文件位置与检查命令。

通过实际文件读取验证 Sol 与 Astra 的路由

模型出现在菜单中，只代表它可以被选中。为了确认任务分派确实可用，我安排了一个小型测试：让 Qwen 分别启动 Sol 与 Astra，要求它们读取工作区内的测试文件，返回预先写好的值。

验证时除了看回复内容，也检查子会话记录中的工具执行与模型标识符。

这次测试明确要求 Qwen 使用两个外援，任务也没有涉及修改代码。它证明了连接、任务分派、工具读文件与结果返回可以正常运作。

至于 Qwen 能否在实际开发中选对求助时机，以及这种分工是否提高完成率、缩短耗时，仍需要另外设计编程任务来评估。角色分工已写入配置，实际开发收益还需要持续测量。

将本地 Codex 的图片生成能力封装成工具

图片生成采用另一条路径。

OpenCode 已经可以通过已有登录使用 Sol 与 Astra，但图片生成仍需要相应的工具入口。因此我先确认本地 Codex 能生成图片，再把流程封装成 OpenCode 插件，提供名为 codex_image 的工具。

这是本次实现的自定义工具。仅在提示词中写上 codex_image，不会让尚未安装插件的 OpenCode 自动具备这项能力。

实际调用流程为：

1. Qwen 把用途、主题、构图与风格整理成图片需求。
2. OpenCode 调用 codex_image。
3. 插件启动本地 Codex CLI，确认使用已有的 ChatGPT 登录。
4. Codex 使用内置图片生成能力，生成图片文件。
5. 插件检查文件后，复制到当前项目。
6. Qwen 使用 read 打开交付文件；工作指令还要求检查图片是否符合需求。

这次图片工具内部固定使用 GPT-6.1 Sol、low 推理设置执行 Codex 任务。这个执行层与 OpenCode 的 sol 子代理相互独立，图片测试也没有先委派 Sol 或 Astra。Sol 在这里负责执行图片任务，实际图片由 Codex 的图片生成能力产出。

OpenAI 的文档说明，Codex 内置图片生成会计入常规 Codex 使用额度；使用 API key 则适用 API 计费方式。这次沿用已有的 ChatGPT 登录，没有另外配置 Images API key，也没有加入失败后自动改用 API key 的备用路径。Codex 图片生成说明

因此，“集成已有订阅”仍然会消耗额度。本次测试没有测量每张图片实际扣除多少额度，也没有把 API token 价格换算成订阅成本。

第一次遇到的阻碍是图片交付

本地 Codex 的前两次测试都生成了图片，但整体流程没有立即通过。

问题出在最后一步：当子进程尝试把图片复制到指定的项目位置时，被文件权限策略阻止。图片已经存在，用户需要的交付位置却没有完成写入，所以仍不能把整个流程算作成功。

正式版本把两项工作分开：

• Codex 按已有的图片生成机制保存原始产物。
• OpenCode 插件确认来源与图片内容后，负责复制到项目。

这样保留了 Codex 子进程的只读沙箱设置，也让输出位置与文件检查由调用方处理。

验证不只看扩展名。插件会检查文件是否属于本次新建的生成目录、时间与真实路径是否合理，以及 PNG 结构与像素数据能否解码，避免把旧图片或无法打开的文件当作新结果。

安装时还遇到一个小问题：插件一开始被全局目录自动加载，又在配置数组中显式加入，导致重复注册。移除重复项后，插件列表只保留一条 local.codex-image。

通过完整流程交付一张可打开的 PNG

最后一轮测试从 OpenCode 的 Qwen 主代理开始，要求生成陶瓷赤狐摆件图片。工具接收的需求示例如下：

{
  "prompt": "一只陶瓷赤狐摆件，柔和自然日光，米白背景，写实产品摄影，无文字。",
  "output_name": "fox"
}

实际验证结果为：

34.7 秒是这一次 runner 工具部分的耗时，包含登录检查、Codex 执行、图片验证与复制；它不是整段 OpenCode 会话的等待时间，也不是多张图片的平均速度。

工具每次会创建独立的输出文件夹，保存图片及相关记录。输出位置的一般形式为：

<当前项目>/output/codex-images/<作业名称>-<唯一标识符>/image.png

这次还有一项验证边界：所用 Codex CLI 的 JSON 事件没有提供完整的内置图片工具调用记录，所以结果保留 nativeToolCallVerified: false。我们确认了本次新生成的文件、文件可读性与 OpenCode 交付流程，但没有把模型对工具名称的自述当作完整的内部调用审计。

配套测试方面，runner 的 21 项测试与工具入口的 6 项测试通过；另外两项创建符号链接或 junction 的测试，因测试环境不允许创建链接而跳过。

日常使用时，直接描述工作即可

完成工具安装后，我在 Qwen 的指令中加入：

需要生成新图片时，使用已提供的 codex_image 工具。

因此，日常使用可以直接说：

帮我生成首页插画，主题是智慧农业，风格简洁、绿色系，左侧留白放标题。

用户不必记住工具名称。Qwen 应从需求判断需要生成图片，整理参数并调用工具。需要较复杂的构图或视觉规划时，也可以交给 Sol；涉及整体视觉方向与复杂设计问题时，再由 Astra 协助。

Sol、Astra 的工作指令也允许在受委派的范围内使用图片工具。codex_image 有自己的工具权限，与启动子代理的 subagent 权限分开，所以禁止它们继续分派任务，不等于禁止使用图片功能。

这次完整流程测试明确指定了图片工具；自然语言能否稳定触发正确的工具选择，仍有待后续使用验证。现有指令已经配置好，但不能把一次明确指令的成功，当作各种说法都会正确执行的保证。

目前工具只开放从文本生成新图片，参考图与已有图片编辑尚未接入。Codex 生成阶段的等待上限设为 8 分钟，另有登录检查、停止进程与文件验证时间。失败、取消或超时后不自动重试，先检查结果与错误；停止本地进程也无法保证云端已开始的生成同步取消。

下一步测量真实开发任务

这次先建立了一条可以验证的工作流程：新会话由本地 Qwen 接手，Sol 与 Astra 能收到任务并交回结果，图片需求也能通过本地 Codex 生成文件，再回到 OpenCode 打开。

接下来值得记录的是实际开发任务：Qwen 自行完成的比例、外援介入原因、交接信息是否充分、测试通过所需时间，以及订阅额度的使用情况。用这些数据，才能判断目前的分工是否合适，或哪些任务应该更早交给外援。

在积累足够的测量数据之前，我会保持目前的单层任务分派。让 Qwen 持续掌握需求与交付责任，让 Sol、Astra 处理有明确理由的外援任务，图片则通过已验证的工具流程交付。