目标、后台任务与工作流

本页说明 CLI 的基础组合（DSH Base Composition）中与目标（goal）、本地后台任务（jobs）和工作流（workflow）相关的插件装配关系。当前仓库证据主要来自自动生成的 apps/cli/composition.md；该文件描述配置补丁如何把这些插件纳入 web、headless、sdk 与 acp profile 的共享基础 bundle。

Purpose and Scope

本页覆盖以下边界：

• @deepseek-ai/dsh-goal、@deepseek-ai/dsh-goal-round-driver 与 @deepseek-ai/dsh-command-goal 的组合关系；
• @deepseek-ai/dsh-jobs-local 提供的 jobs 基础插件，以及 @deepseek-ai/dsh-tool-jobs 工具插件；
• @deepseek-ai/dsh-workflow-ptc 与 @deepseek-ai/dsh-tool-workflow 的基础装配；
• 它们在 packages/bundle/base/cordis.patch.yml / cordis.yml 这一配置入口下的注册关系。

本页不展开这些包内部的运行时实现、任务调度算法、工作流步骤协议、持久化格式或 CLI 参数语义，因为当前仓库摘录中没有这些实现文件。对 session、agent、tool、存储及 sandbox 的详细行为，应由相应的 sibling catalog 页面负责；本页只描述它们与本主题的已验证组合边界。

Overview

apps/cli/composition.md 将 dsh-base 描述为 web、headless、sdk 和 acp profiles 共享的 bundle patch；这些 profile 的 mode bundle 与 user layer 会在其上继续 patch，而 sdk-minimal 使用独立树。配置入口 packages/bundle/base/cordis.patch.yml / cordis.yml 通过 cfg 节点连接基础插件。

在该组合中，目标相关能力被拆成三个插件节点：

• goal：目标能力的基础插件；
• goal-round-driver：目标轮次驱动器；
• command-goal：命令层目标入口。

后台任务与工作流则分别以本地 jobs 插件、jobs 工具、PTC workflow 插件和 workflow 工具呈现。这表明 bundle 层采用“能力插件 + 工具插件”的装配方式，而不是在 CLI composition 文件中实现业务逻辑。这里的“后台任务”仅能确认其插件组合名称为 jobs / tool-jobs；源码没有提供足够证据证明其执行队列、并发限制或重试策略。

Architecture

图中的每条边都表示 composition 文件中由 cfg 指向对应插件的配置装配关系；它不表示插件之间存在直接调用关系。尤其不能仅凭该文件推断 goal 一定调用 jobs，或 tool-workflow 一定调用 workflow-ptc。

Main Content

组合入口与生成性质

文件开头明确标记 composition.md 由 scripts/gen-doc-graphs.ts 生成且不应手工编辑。因此它适合作为 bundle 结构的事实来源，而不是业务实现的修改入口。对本主题进行扩展时，应先定位生成该图的配置源与对应 package，再修改源配置并重新生成文档图。

目标插件的分层

目标能力在共享基础 bundle 中不是单一节点，而是三个独立节点：goal、goal-round-driver 和 command-goal。从命名和装配事实可确认它们被同时纳入基础配置；但当前证据没有声明它们之间的依赖顺序、生命周期或数据结构。因此，工程人员排查目标执行问题时，可以先确认三个 package 是否都存在于实际 profile 的 patch 结果中，但不能把 composition 图当作调用时序图。

后台任务与工具边界

jobs 指向 @deepseek-ai/dsh-jobs-local，而 tool-jobs 指向 @deepseek-ai/dsh-tool-jobs。这至少表明本地 jobs 能力和面向 agent/tool 的 jobs 接口在 bundle 中分别注册。源码摘录未暴露 job 名称、参数、结果类型、持久化位置、取消方式或并发模型；这些信息应从对应包的源码或 package 文档补充，当前页面不做推断。

工作流与 PTC

基础 bundle 同时装配 ptc-runtime、workflow-ptc 和 tool-workflow；其中本页直接关注后两个 workflow 节点。workflow-ptc 的包名显示其属于 PTC workflow 集成，tool-workflow 是工具侧入口。composition 文件只证明它们被配置入口引用，并未证明运行时一定按“tool-workflow → workflow-ptc”顺序执行。

Core Flow

从当前证据能够确认的流程是“配置生成/加载 → 插件进入共享基础 bundle”，而不是具体 job 或 workflow 的运行时流程：

该顺序中只有生成关系和 bundle 组合关系有源码支持。jobs、goal 或 workflow 的实际执行步骤、状态转换和错误路径：Implementation details not found in source。

Usage Examples

目标插件组合片段

以下是仓库生成图中目标插件的原始组合片段：

Source: composition.md

jobs 与 workflow 组合片段

Source: composition.md · composition.md · composition.md

Configuration Options

当前读取到的 composition 文件只显示配置入口标签 packages/bundle/base/cordis.patch.yml / cordis.yml，没有展开 YAML 键、默认值、环境变量覆盖或 profile-specific 参数。因此可确认的配置项如下：

更细的 job、goal 或 workflow 配置：Implementation details not found in source。

API Reference

本页所读取的源文件是生成的组合关系文档，不是 TypeScript/JavaScript API 实现；因此没有可安全列出的函数签名、参数、返回值或异常类型。对应 package 的公共 API 未在当前证据中出现，不能根据 package 名称猜测。

Failure Modes, Edge Cases & Concurrency

已确认的边界

• composition.md 明确声明由生成脚本产生；手工修改该文件会被下次生成覆盖。
• sdk-minimal 使用独立 standalone tree，因此不能假设本页列出的 dsh-base 插件集合自动适用于该 profile。
• profile 会在 dsh-base 之上继续叠加 mode bundle 和 user layer；实际运行集合可能因此不同于基础图。

未能从源码确认的行为

当前摘录没有提供 job 调度器、workflow executor 或 goal round driver 的实现，因此以下问题均不能下结论：任务是否并行、是否有队列上限、是否支持取消、失败是否重试、工作流是否持久化、目标轮次是否串行，以及多个 session 同时使用这些能力时如何同步。应在对应包源码可见后补充，而不是在本页推断。

Performance / Operational Notes

组合图本身不描述运行时性能。可操作的维护注意事项只有：修改应针对配置源或生成脚本，而不是 composition.md；修改后应重新运行仓库规定的文档图生成流程，并检查目标 profile 与 sdk-minimal 的差异。具体启动耗时、任务吞吐、超时和资源隔离信息：Implementation details not found in source。

Extension Points

从已读内容能够确认的扩展方式是 bundle patch：共享基础配置先装配基础插件，profile 的 mode bundle 与 user layer 再继续 patch。这使目标、jobs 和 workflow 能力可以作为独立 package 节点被纳入或由上层配置覆盖。但新增插件的具体 YAML 语法、依赖声明格式和加载顺序未出现在摘录中；扩展时应以 packages/bundle/base 的真实配置文件和对应生成脚本为准。

Related Links

• DSH Base Composition：共享基础 bundle 的总体说明。
• 目标插件装配：goal、goal-round-driver、command-goal。
• 本地 jobs 装配：@deepseek-ai/dsh-jobs-local。
• jobs 工具装配：@deepseek-ai/dsh-tool-jobs。
• workflow 装配：workflow-ptc 与 tool-workflow。