更多 Agent 预设 R-LEI2536/dsh-more-agent-presets

dsh-more-agent-presets

多个可选择的 DeepSeek Harness Agent Presets 集合。

这些 preset 针对 DeepSeek Harness (DSH) 做了适配。

使用场景

本插件特别适用于以下场景：

非 DeepSeek 或老旧模型：
- 改善未针对 DSH 进行专门适配的模型的性能
- 增强缺乏 DSH 特定适配的旧模型

个人偏好：
- 部分用户可能更喜欢交互式、讨论型的编程辅助，而非独立完成任务的方式

为什么有帮助：
- DSH 的默认提示针对 DeepSeek 模型进行了优化
- 非 DeepSeek 或老旧模型使用默认提示时可能无法发挥最佳性能
- 这些 preset 提供了适合不同模型的替代交互模式

可用 Presets

Qwen Code 编程模式 (qwencode-coding-agent)

注重代码规范与项目约定的专业编程助手，采用迭代式工作流和 CLI 友好的交互风格。

IFlow 编程模式 (iflow-coding-agent)

具备动态环境感知、自动 Git 上下文注入和结构化任务工作流的交互式 CLI 编程助手。特性包括自动检测的平台信息、安全优先的权限处理，以及优化的 CLI 交互风格。

IFlow 创造模式 (iflow-cre-agent)

用于创建自定义 Agent preset 的增强模式。具备标准模式的全部能力，并提供运行时检查、插件实验和 preset 创作指导。

功能特性：
- DSH 上下文信息（Web UI URL、源码路径）
- Git 仓库感知
- 自定义提示段落
- Cordis 插件开发和组合编辑技能

当前限制： ⚠️ Cordis Tool (@deepseek-ai/dsh-tool-cordis) 因上游问题暂不可用。动态 Cordis 插件创建功能需等待上游修复后可用。

协作编程模式 (pair-coding-agent)

与用户结对工作的编程助手：每一步先与用户对齐方向，对非平凡的改动先讨论再动手，等待用户确认，而不是独自把任务推到完成。

Codex 编程模式 (codex-coding-agent)

移植开源 Codex CLI 的 agent 提示词：每次工具调用前先说明要做什么、先读代码再动手、自主把任务推进到完成，并沿用 Codex 的规划、验证与最终答复格式规范。工具名已映射到本 harness 的工具（apply_patch → edit/write，update_plan → todo_write，request_user_input → ask_user_question），Codex 的计划模式协议通过 exit_plan_mode 保留。Codex 的三块 input[]——<permissions instructions>、<collaboration_mode>、<environment_context>——通过三个 DSH agent/pre-step 插件（codex-permissions.mjs、codex-collab-mode.mjs、codex-environment.mjs）作为 user-role 消息注入到每步准入输入的头部，沙箱/审批策略和 cwd/platform/shell/日期实时从 DSH 运行时解析。与这里其他 preset 不同，它保留的是 Codex 的自主推进姿态，而非先讨论后动手。

通用聊天模式 (chat-agent)

纯聊天助手：不挂任何工具行，通过 preset 层的 ctx.tools.restrict({ allow: [] }) 屏蔽继承得来的工具，并用 ctx.tools.guard(...) 拒绝执行注册在 agent 自身 scope 里的工具——因此它不能产生动作：不能读写文件、不能执行命令、不能联网搜索、也不能创建队友。两条边界是刻意的，机制与源码指引写在 presets/chat-agent/no-tools.mjs：其一，preset 层的 restriction 只覆盖继承面（全局层 + 每个祖先 scope），agent 自身 scope 的注册天然豁免，所以挂了这类插件的 profile（例如 @deepseek-ai/dsh-experimental-agent-team-profile，它的 9 个 Team 工具会注册进每个 root agent 的 agent.ctx）下，那些工具仍会列在该会话的工具目录里，guard 负责让它们的调用返回拒绝而不是真的执行；其二，这个拒绝与「已被过滤的工具」返回的 unknown tool 不是同一种。系统提示词按当前模型自动切换（Default / Codex GPT-5 · GPT-6 / Qwen / DeepSeek-R1 / Gemini 3.7 · 3.8 文案，表源见 presets/shared/model-personas.json），所选文案即该会话的全部提示词。自动压缩（上下文压力／溢出触发）与人工 /compact 命令保留，因为聊天会话天然很长。当你想要一个聊天对象、而不是一个会动你机器的 agent 时用它。

通用聊天模式 · 可派活 (chat-subagent)

能力就是一个能启动工作的工具的聊天助手：subagent——外加模型选择开关注册的只读 list_subagent_models，它只报告本会话可以点名的路由。顶层会话的工具目录里只有这两个派活名字（部署挂了 agent-team bundle 时还会列出它的 9 个 Team 工具，见本节末尾）：一条 depth-0 目录 mask（ctx.tools.restrict({ allow: [] })，装在 Agent 自身 scope 上，由 presets/chat-subagent/delegator.mjs 安装）把 preset 继承来的行全部藏起来；而 restriction 从不过滤 agent 自身层，这两个派活工具恰好注册在那里。藏起来不等于强制：同插件在 preset 的 standing scope 上装一条 guard（ctx.tools.guard(...)），除下面两个名字之外的所有调用一律拒绝：subagent 与 list_subagent_models。mask 在 Agent scope 上，所以被派出去的子 agent 不会继承它（子 agent 的 scope 父节点是 preset 的 standing scope）；guard 则按调用方 agent 的 scope 链取，所以同一条 standing 安装同时覆盖顶层会话和每个子 agent，由 delegation depth 决定放行哪些名字。mask 刻意晚一个 macrotask 安装（agent/created 之后、切换之后），离场时同样延后解除：restrict() 会发 tools/change，guard() 不会，而官方派活插件正是在这个事件上安装到活着的 agent 上——从 agent/created 同步装 agent-scope restriction 让同一个 scope 装了两次，第二次抛 tool "list_subagent_models" is already registered in this scope，它的 install() 在 mount() 之前中止，会话一个派活工具都不剩（1.7.3 实测）。因此该会话自己不能产生动作；它调用一次 subagent，再依据运行时以完成通知送达的报告回复用户。（own-plane 的 9 个 Team 工具一律拒绝，见本节末尾。）DSH 0.2.1 直接删除了那两个背景键，所以每次派活都是异步的受管激活：调用立刻返回 { kind: 'activation', subagentId }，子 agent 的终答随后以完成通知送达；它走 spawn provider，并用 maxDepth: 1 把递归预算写死。

真正干活的是被派出去的子 agent，它只读。 delegated child 会加入父会话的同一个 preset，因此继承同一批行，也继承同一条 guard；约束它的是 guard 的 depth 分支：子 agent 只能调用声明里 subagentTools 名单——默认 read、glob、grep、read_image、list_directory、todo_write、job_list——其余一律拒绝。名单里没有 bash、write、edit：子 agent 只做调查与汇报，不能跑命令、不能跑测试、不能改文件（可写版本记在 TODO.md）。其中两个名字取决于部署——read_image 只在挂了附件存储时存在，list_directory 来自 profile 里的第三方插件——现在已经不做探测：guard 按声明名单判定，没有任何行注册的名字只是不在目录里。mask 只装在父 Agent 的 scope、绝不装在 preset 层，原因正是这一点：preset 层的 restriction 同样在子 agent 的 scope 链上（它加入的就是同一个 preset），而 restriction 只能收窄，子 agent 解不开。

系统提示词按当前模型自动切换：文案来自两个聊天 preset 共用的那张表（presets/shared/model-personas.json，由 presets/shared/model-persona.mjs 读取，chat-agent 也把它当作自己的全部提示词），再拼上一段派活说明（presets/chat-subagent/delegation-note.md，挂载时逐字读入），两者合起来就是该会话的全部提示词。自动压缩（上下文压力／溢出）、人工 /compact 命令与工具结果剪枝都保留：子 agent 会 grep 仓库，它的工具结果需要剪枝，尽管顶层会话根本不产生工具结果。

要改子 agent 的工具名单，就在 profile patch 里按 Loader 行 id 覆盖这条声明。config 是整体替换，每一行都要重述；这份名单就是 guard 给子 agent 的白名单，所以没有任何行注册的名字只是不在目录里：

~/.dsh/profiles/<profile>/cordis.patch.yml（节选：其余行必须原样重述）
- id: preset-chat-subagent
name: '@deepseek-ai/dsh-agent-preset'
config:
id: chat-subagent
order: 16
name: "通用聊天模式 · 可派活" description: "顶层只放行 subagent 与 list_subagent_models（可为子 agent 指定模型）：把任务交给只读子 agent 去查、去读，自己专注对话。"
plugins:
- id: delegator
name: 'dsh-more-agent-presets/presets/chat-subagent/delegator.mjs'
config:
presetId: chat-subagent
subagentTools: [read, glob, grep, todo_write]
……以及原声明里其余每一行，原样照抄……

放开名单不会自动改写那段派活说明：说明就是文件 presets/chat-subagent/delegation-note.md，挂载时逐字读入，描述的是随包发布的只读默认值——子 agent 能力变了就改这个文件，或在某个 profile 里用 delegator 行的 delegationNote 覆盖它。没有任何东西从说明里反推工具名单：它只用人话说了子 agent 能做什么、不能做什么。

有一条边界是刻意保留的：挂了 agent-team bundle 的 profile 下，顶层会话的工具目录里仍然会列出那 9 个 Team 工具（agent 自身 scope 的注册天然豁免于任何 restriction，depth-0 mask 也藏不掉它们）。但它们一个都不可调用。 它们是 Team 语义，面向 Team 成员，而 subagent 派出的子 agent 不是 Team 成员：list_agents 只会列出本会话自己，send_message 发往这些名字一律被拒，子 agent 仍以完成通知交件。1.8.1 曾放行 list_agents/send_message，实测反而制造自旋：刚派完活儿的模型连续 8 次 wait_agent、反复列出自己、给自己发消息，并在第一个子 agent 还在跑时又派了两次同样的任务。本 preset 自己的 read/write/todo_/job_ 等行则相反，已被 mask 从目录里藏掉，强行调用时由 guard 拒绝。另外 job_list 对子 agent 目前是空转（它起不了后台任务），保留在默认名单里是为了以后放开"可写"时不必再改第二处。

子 agent 模型选择（qwencode / iflow / iflow-cre / pair / codex）

这 5 个编程 preset 与 chat-subagent 的委派行都开了 Host 的子模型选择开关（modelSelectionSettings: true），与随产品发布的 standard/ptc/cordis preset 是同一个一键 opt-in。顶层 Agent 因此多两样东西：

- list_subagent_models：查这个会话能用的路由。不带参数列授权范围内的提供方，带 provider 列该提供方的模型，再带 model 看它的推理强度。
- subagent 多了三个可选参数：provider、model、reasoning_effort。三个都省略时，子 agent 仍然继承父会话模型——这是官方默认，也正是没开这个开关前的行为。

授权名单来自 Host 的 @deepseek-ai/dsh-tool-subagent/model-selection-settings 行，就是 Web UI 里那一栏「允许 Agent 为子智能体选择模型」。名单外的显式路由会报错，报错信息列出可用路由。名单在会话创建时采样，只影响新会话。开关关掉（或名单为空）时行为回到「一律继承」，不报错。

Host 必须挂着那一行。随产品发布的 dsh-base + dsh-web-app 默认挂，本仓库用的 profile 也都有。缺了它，开了这个开关的 preset 会整块挂载失败，报错原文是 tool-subagent: \modelSelectionSettings\ requires @deepseek-ai/dsh-tool-subagent/model-selection-settings in the Host scope。

chat-subagent 也开了这个开关，所以聊天会话同样能给子 agent 指定模型。它的顶层目录不为空——两个派活名字，加上部署挂 agent-team bundle 时的 9 个 Team 工具（均不可调用）——只有一个能启动工作，所以它的不变量读作「只有一个能启动工作的工具」。开关还会把派活工具从 preset 平面挪进每个 agent 自身层：自身层正好是任何 restriction 都不过滤的层，这也是 depth-0 mask 可以写 allow: [] 而不至于把派活本身藏掉的原因（见上一节）。chat-agent 没有任何工具行，不涉及。

chat-subagent 有一处不同：当授权名单非空时，它的 standing guard 会拒绝 depth-0 上不带 provider 和 model 的 subagent 调用，所以没调过 list_subagent_models 的会话不能静默用继承来的路由派活。名单为空、开关关闭、或这份策略读不到时，「省略即继承」仍然成立。5 个编程 preset 保持官方的省略即继承：它们的派活说明只是要求点名，不点名不会被拒。

子 agent 究竟跑在哪个模型上，看终端那一行。 每次派活都打一行：这 5 个 preset 由 presets/shared/subagent-route-log.mjs 打，chat-subagent 由它自己的 delegator 打：

[I] pair-coding-agent/subagent-route-log: subagent 3f1c… route opencode-chat/deepseek-v4.1-flash [I] chat-subagent/delegator: subagent 3f1c… route opencode-go/deepseek-v4-flash

这一行报的是子 agent 创建时那条路由：要么是调用点名的，要么是从父会话继承的；只有当真身两半都没给出时才显示 unknown。顶层会话不打这一行。

短命子 agent 收尾时可能带出两条上游告警，都是噪音：agent-registry … agent/disposed listener threw: TypeError: Cannot read properties of undefined (reading 'catch')（工具把 .catch 链在可能返回 undefined 的 dispose() 上——正是这个开关启用的 per-Agent 安装路径），以及 session-projection-cache … write for "…" failed (cache stays stale)（子会话句柄先关、节流检查点后写的 fail-soft 竞态）。来源记在 TODO.md；实测该子会话的缓存记录是完整的。

设计理念

这些 preset 在用户交互和规划方式上与 DSH 默认 prompt 有所不同：

交互风格：

- DSH 默认：倾向于独立完成任务，减少与用户交互
- Qwen/IFlow/Pair：倾向与用户讨论，保持沟通

Plan Mode：

- DSH 默认：静态审批流程——AI 输出完整计划文档，等待用户审批
- Qwen/IFlow/Pair：动态结对流程——AI 与用户多轮交互，逐步完善计划

已知限制

Preset 显示名称不跟随 Web UI 语言切换。 本插件提供的每个 preset，其 name 与 description 都从声明行（declaration）读取，并由 Web UI 原样渲染，与界面语言无关。只有 DeepSeek Harness 自带的四个内置 preset（standard、ptc、minimal、cordis）走 Harness 的 i18n 系统；社区插件提供的 preset（包括本插件内的所有 preset）都做不到。因此在 Web UI 把语言从中文切到英文时，这些 preset 的显示文案仍是中文。

这是 Harness 读取 preset metadata 的方式带来的限制，不是本插件的问题。截至目前，DSH 没有给插件暴露注册本地化字符串的入口。

环境要求

- DeepSeek Harness 0.2.1-rc.1 及以上。本版本是声明式 preset bundle（0.1.7 之前的 .agent-presets 目录安装器已不存在），并在 engines.dsh 里钉住这条下限，因此更旧的宿主会通过兼容门整包跳过本插件，请先升级宿主。
- 子 agent 模型选择这一项需要 Host 挂 @deepseek-ai/dsh-tool-subagent/model-selection-settings 行。随产品发布的 dsh-base + dsh-web-app 默认挂这一行；缺它会让开了该开关的 preset（5 个编程 preset 与 chat-subagent）整块挂载失败。

安装

dsh plugin --profile web add github:R-LEI2536/dsh-more-agent-presets

重启 Web profile，然后在创建会话时选择 preset。

本插件是一个声明式 preset bundle：安装后通过 dsh.bundle.patch 向 profile 注入 7 行 @deepseek-ai/dsh-agent-preset 声明（每个 preset 一个声明，位于 presets/<id>.patch.yml）。声明行由 @deepseek-ai/dsh-agent-preset-registry 注册，自动出现在 preset 选择器里。插件不向用户目录写入任何内容——不做任何文件拷贝。

行为说明

声明式 preset（DSH 0.1.7+）：
- 每个 preset 是一行声明在 bundle patch 中的 @deepseek-ai/dsh-agent-preset；config.plugins 持有子插件行（工具、提示段、带 isolate realm 的组，以及以包子路径 dsh-more-agent-presets/presets/<id>/ 引用的本插件内嵌 .mjs 插件；多个 preset 共用的资源放在 dsh-more-agent-presets/presets/shared/）。
- preset id（chat-agent、chat-subagent、codex-coding-agent、iflow-coding-agent、iflow-cre-agent、pair-coding-agent、qwencode-coding-agent）与旧版本一致，已有会话的选择不会失效；chat-subagent 是本 bundle 这次新增的一行，它是新 preset，而不是对 chat-agent 的修改。
- registry 为在线会话保留声明对应的组合；修改声明只影响之后创建的 Agent。

多文件 patch、bundle 自身那一行，与根入口产物：
- dsh.bundle.patch 是一个有序列表（cordis.patch.yml 外加每个 preset 一个 presets/<id>.patch.yml）——这正是 DSH 核心支持的数组形式。宿主会按序组合这 8 个 patch 层；因为这是 bundle，生效时机是下一次启动，而不是热挂载。
- cordis.patch.yml 声明的是这个 bundle 自身的 loader 行（id/name 都是 dsh-more-agent-presets），index.mjs 是它背后的空插件。这一行才是让 bundle 出现在运行中组合里的东西，也是每个 bundle 给自身声明行的固定做法（dshmarket 插的是 dsh-market / dshmarket；@deepseek-ai/dsh-web-app 插的是 web-runtime / @deepseek-ai/dsh-web-app）。缺了它，dshmarket 的存活判定（liveIncludes）无从匹配——7 个 preset 行的 name 是 @deepseek-ai/dsh-agent-preset——插件管理器于是每次打开页面都显示「已安装，重启后生效」，重启也不例外，而 7 个 preset 其实一直是好的。
- 部分第三方工具只识别字符串形式，并按「声明的根入口产物」判断已安装的构建是否可加载。index.mjs（通过 main、exports["."] 声明，并由 files 打进产物）既是为了让这项检查看到一个真实产物，也是为了让上面那一行有个真正的插件可挂。
- 不要删除那一行自身行，也不要删除 index.mjs、main 或 exports["."]。 缺了它们，插件管理器会把本插件标成损坏（「已安装，校验未通过／声明的入口产物缺失」）、拒绝安装或更新（「updated build has no loadable entry」），或者永远显示「重启后生效」——尽管 DSH 本身能正常加载这个 bundle。

从 ≤1.4.x 迁移：
- ≤1.4.4 版本会把 preset 目录拷贝到 $DSH_HOME/.agent-presets（通常是 ~/.dsh/.agent-presets）并写入 .dsh-preset-owner.json 标记。DSH 0.1.7 不再读取该目录，本插件也不再写入。
- 升级后，旧拷贝目录是无用残留。如需清净可直接手动删除：
rm -rf ~/.dsh/.agent-presets

（只针对你自己的 ~/.dsh/.agent-presets；在新机制下不存在其他插件或用户手写 preset 放在那里的情况——preset 现在都是 profile patch 声明。）

卸载

dsh plugin --profile web remove dsh-more-agent-presets

卸载 bundle 会移除它的 patch 层，7 行 preset 声明随之从 profile 消失；安装在 profile node_modules 下的 preset plugins 资源随包移除。0.1.7+ 无需清理 ~/.dsh/.agent-presets（若从 ≤1.4.x 迁移，参见上方「行为说明」）。

许可证

MIT。部分 preset 组合源自其他开源项目。

贡献

欢迎贡献！欢迎提交 issue 和 pull request。