wumohan1814/dsh-architect-flash

Architect-Flash · 架构师模式（Pro+Flash）

License: MIT
DeepSeek Harness

削减你的编码 token 账单。 一个 DeepSeek Harness 智能体预设，在你的主模型上进行规划与
审查，并将所有底层代码实现交给廉价的 Flash 子智能体——因此昂贵的模型永远不写代码。

英文

为什么选择 Architect-Flash

- 💸 节省 token 和成本——代码实现是任何编码任务中 token 消耗最大的部分；在这里，它运行在廉价的 Flash 子模型上，而不是你的主模型上。
- 🧠 清晰的关注点分离——一位架构师负责规划、设计和审查；一位工作者负责实现。职责不再模糊。
- 🔒 隔离的上下文——工作者在自己的上下文中编辑文件，使架构师的上下文保持精简且对缓存友好。
- 🔌 无硬编码模型——工作者遵循你在子智能体设置中选择的子模型，因此该预设可跨部署移植。
- 🧰 完整的原生工具链——标准的编码工具目录，外加一个可直接调用的 code_flash 委派工具。

架构

┌────────────────────────────────────────────────────────────┐
│  Architect  (main model, e.g. deepseek-v4-pro)            │
│  plan · design · review · git · verify builds             │
└────────────────────────────┬───────────────────────────────┘
│  delegate to code_flash
▼
┌────────────────────────────────────────────────────────────┐
│  code_flash worker  (selected sub-model, e.g. Flash)      │
│  read · write · edit · glob · grep · pwsh · todo_write    │
│  isolated context · maxDepth 1 (no recursion)             │
└────────────────────────────────────────────────────────────┘

对比

| | standard | ptc（PTC 模式） | architect-flash |
| --- | --- | --- | --- |
| 工具呈现 | 原生 | 单一 run_code | 原生 |
| 模型分层 | 单一模型 | 单一模型 | Pro（主）+ Flash（工作者） |
| 谁编写代码 | 模型自身 | 模型自身（在 run_code 中） | Flash 工作者 |
| 委派工具 | subagent | 隐藏在 run_code SDK 之后 | code_flash，直接调用 |
| Token 成本 | 单一模型全价 | 单一模型全价 | 代码运行在更便宜的模型上 |
| 缓存/schema | 中等 | 最佳（极小的 schema） | 中等（但模型更便宜） |

PTC 模式优化 schema 和往返次数；Architect-Flash 优化的是由哪个模型承担繁重工作。如果你的代码实现主导了 token 支出，那么 Flash 拆分通常比 PTC 的 schema 节省更多。

快速开始

Linux / macOS
cp -r architect-flash "$HOME/.dsh/.agent-presets/architect-flash"

Windows (PowerShell)
Copy-Item -Recurse architect-flash "$env:USERPROFILE\.dsh\.agent-presets\architect-flash"
重启主机，启动新会话，然后选择 Architect-Flash（架构师模式）。

要求

- 带有 dsh-agent-tool-presentation 架构的 DeepSeek Harness
（native / ptc / both），以及带有
modelSelectionSettings 的 @deepseek-ai/dsh-tool-subagent。
- 在会话的
subagent-model-selection.allowedModels 策略下注册一个支持 Flash 的 LLM 路由。code_flash 不硬编码任何
路由——它跟随子代理所选的子模型。

选择子模型

子模型是会话级设置，而不是预设旋钮。在
settings.yaml 中的 subagent-model-selection.allowedModels 下注册
code_flash 工作器可以使用的路由：

subagent-model-selection:
enabled: true
allowedModels:
- provider: ark
model: deepseek-v4-flash

code_flash 使用 modelSelectionSettings: true 来遵循此策略。架构师
通过 list_subagent_models 发现子模型，并传入其
provider/model，因此子模型就是子代理设置所选择的那个。

行为契约

该角色编码了两条规则：

1. 对于代码实现——尤其是重复性或底层代码——
委托给所选子模型上的 code_flash 工作器，而不是
内联编写。
2. 当被委托的工作器正在运行时，不要用目标更新进行轮询；停下来
等待其结果被注入。

这些是行为层面的（角色），而不是物理层面的。要让“编写代码”成为单一
物理路径，可以从主代理的工具中移除 write/edit——但
架构师仍然需要它们来编写文档（需求/缺陷表），因此
代码与文档的边界最好保留为工作区指令。

常见问题

为什么用 native 而不是 PTC？ PTC 将所有工具折叠为一个 run_code 工具，
并把委托工具隐藏在其 SDK 之后——在那里不可能存在一个独立的、可直接调用的
code_flash。Native 让 code_flash 保持为一等公民。

我应该选哪个子模型？ 你的提供商提供的任何更便宜的、具备推理能力的模型
（例如 deepseek-v4-flash）。将其注册到
subagent-model-selection.allowedModels 下。

如何强制所有代码都交给工作器？ 从
主代理的目录中移除 write/edit。这样文档编辑也会经过工作器，因此
请决定你是否想要那样。

它在 Windows 上能用吗？ 能。在 Windows 上 shell 工具是 pwsh；在其他
平台上则是 bash。code_flash 工具过滤器会指定正确的那个。

文件

| 文件 | 用途 |
| --- | --- |
| agent.cordis.yml | 代理平面组合（角色、工具、委托）。 |
| preset.yml | 显示元数据（name、description）。 |
| NOTICE | 衍生 standard 预设的署名。 |
| LICENSE | MIT。 |

中文

为什么用 Architect-Flash

- 💸 省 token、省成本 —— 代码实现是编码任务里 token 最重的部分，这里它跑在便宜的
Flash 子模型上，而不是主模型上。
- 🧠 职责清晰 —— 一个架构师负责规划/设计/审查，一个工人负责实现，互不混淆。
- 🔒 上下文隔离 —— 工人在自己的上下文里改文件，架构师的上下文保持精简、利于缓存。
- 🔌 不硬编码模型 —— 工人跟随你在 sub-agent 设置里选择的子模型，preset 跨部署可移植。
- 🧰 完整原生工具 —— 标准编码目录 + 可直接调用的 code_flash 委派工具。

架构

┌────────────────────────────────────────────────────────────┐
│  架构师  （主模型，如 deepseek-v4-pro）                    │
│  规划 · 设计 · 审查 · git · 验证构建                       │
└────────────────────────────┬───────────────────────────────┘
│  委派给 code_flash
▼
┌────────────────────────────────────────────────────────────┐
│  code_flash 工人  （所选子模型，如 Flash）                 │
│  read · write · edit · glob · grep · pwsh · todo_write     │
│  独立上下文 · maxDepth 1（禁止递归）                       │
└────────────────────────────────────────────────────────────┘

对比

| | standard | ptc（PTC 模式） | architect-flash |
| --- | --- | --- | --- |
| 工具呈现 | 原生 | 单一 run_code | 原生 |
| 模型分级 | 单模型 | 单模型 | Pro（主）+ Flash（工人） |
| 谁写代码 | 模型自己 | 模型自己（在 run_code 里） | Flash 工人 |
| 委派工具 | subagent | 藏在 run_code SDK 后 | code_flash，直接调用 |
| token 成本 | 单模型全价 | 单模型全价 | 代码跑在便宜模型上 |
| 缓存/schema | 中 | 最优（极小 schema） | 中（但模型更便宜） |

PTC 优化的是 schema 和往返；Architect-Flash 优化的是哪个模型干重活。当代码实现占大头
时，Flash 分级通常比 PTC 省得更多。

快速开始

Linux / macOS
cp -r architect-flash "$HOME/.dsh/.agent-presets/architect-flash"

Windows (PowerShell)
Copy-Item -Recurse architect-flash "$env:USERPROFILE\.dsh\.agent-presets\architect-flash"

重启宿主，新建会话，选择 Architect-Flash（架构师模式）。

依赖

- 具备 dsh-agent-tool-presentation（native/ptc/both）架构、以及支持
modelSelectionSettings 的 @deepseek-ai/dsh-tool-subagent 的 DeepSeek Harness。
- 一条在会话 subagent-model-selection.allowedModels 策略下注册、能承载 Flash 的
LLM 路由。code_flash 不硬编码任何路由 —— 它跟随 sub-agent 选择的子模型。

选择子模型

子模型是会话级设置，不是 preset 的开关。在 settings.yaml 的
subagent-model-selection.allowedModels 下注册 code_flash 可用的路由：

subagent-model-selection:
enabled: true
allowedModels:
- provider: ark
model: deepseek-v4-flash

code_flash 用 modelSelectionSettings: true 遵循该策略。架构师通过
list_subagent_models 发现子模型并传入其 provider/model，因此子模型就是 sub-agent
设置里选中的那一个。

行为契约

persona 编码了两条规则：

1. 代码实现 —— 尤其是重复性或底层代码 —— 委派给所选子模型上的 code_flash，不要
内联编写。
2. 子代理运行时，不要用 goal 轮询；停下并等待其结果注入。

这是行为约束（靠 persona），不是物理约束。要让"写代码"成为唯一物理路径，可把主 Agent
的 write/edit 摘掉 —— 但注意架构师维护文档仍需要它们，所以"代码 vs 文档"的边界
最好放在工作区指令里。

FAQ

为什么用原生而不是 PTC？ PTC 把所有工具折叠成一个 run_code，委派工具藏在其 SDK
后面 —— 那里无法存在可直接调用的 code_flash。原生让 code_flash 保持一等工具。

该选哪个子模型？ 你的 provider 提供的任意更便宜的推理模型（例如
deepseek-v4-flash），把它注册进 subagent-model-selection.allowedModels 即可。

怎么强制所有代码都进工人？ 把主 Agent 目录里的 write/edit 摘掉。那样文档编辑
也得走工人，想清楚是否需要。

Windows 能用吗？ 能。Windows 上 shell 工具是 pwsh，其它平台是 bash；code_flash
的工具过滤会点名正确的那一个。

文件

| 文件 | 用途 |
| --- | --- |
| agent.cordis.yml | agent-plane 组合（persona、工具、委派）。 |
| preset.yml | 展示元数据（name、description）。 |
| NOTICE | 对派生来源 standard 预设的归属声明。 |
| LICENSE | MIT。 |