dsh-typesafe-ask:在 DSH 里用 TypeSafe Jev 做结构化决策

前言

在 DeepSeek Harness(DSH)里开发智能体时,常见需求不是「再生成一段说明文字」,而是对当前状态做判断:工单该分给哪个组、优先级多高、某条陈述是否成立、候选方案如何排序。若完全依赖主对话模型自由发挥,输出往往是自然语言,难以稳定地接入路由、阈值门禁或自动化分支。

下面介绍社区插件 dsh-typesafe-ask(维护者 onepayzk-glitch)。它在 Harness 内暴露工具 typesafe_ask,把待评估的 state 与一组类型化问题发给 TypeSafe 的 System One 模型 Jev(POST /v1/systemone),返回带校准概率的结构化答案,供代码或智能体逻辑直接使用。

这是什么

dsh-typesafe-ask 属于 DSH 社区插件目录中的「模型推理」类条目(目录页:skillhub.cn/plugins/onepayzk-glitch/dsh-typesafe-ask)。源码与说明见 GitHub 仓库,许可证为 MIT。

插件定位可以概括为:给 Harness 智能体一个「决策 oracle」——输入 typed questions,输出可选分支、量表分数或陈述为真的概率,而不是替代主聊天模型去写长文或写代码。

核心功能

安装并配置 API Key 后,主要能力如下。

入口 作用
工具 typesafe_ask 将 state 与问题映射发往 TypeSafe,并在对话中返回结构化答案
设置页 Settings → TypeSafe / Jev 一次性粘贴 API Key;密钥经 Harness 凭据存储保存,不会写入 profile 配置文件

工具参数(摘自 README):

参数 类型 必填 含义
state string | object | array 是 待评估内容:文本、记录或应用状态
questions object 是 问题 id → 类型化问题定义的映射
model string 否 默认 jev-latest

支持三类问题:

  • choice:从 criteria 给出的选项中选一项。
  • score:在有序量表(criteria 为具体情境描述数组)上定位。
  • noul:返回某陈述为真的概率(无单独 confidence 字段)。

典型返回形态示例:

department: choice=technical (confidence=0.78) [technical=0.85, billing=0.15, sales=0]
frustration: score=1=Frustrated but civil (confidence=1)
is_urgent: noul=0.99

适用判断包括:请求路由到正确 handler、工单分类、紧急或情绪强度打分、候选排序、在置信度阈值后放行操作等——README 明确 Jev 不生成文本、不写代码、不流式输出、不调用工具,不能替代智能体背后的聊天模型(TypeSafe 文档 Jev with coding agents 有说明)。

安装与启用

DSH 生态采用「一切皆插件」的扩展方式;社区目录是独立站点,与 DeepSeek / 幻方无官方从属关系。安装前建议自行查看仓库源码与 MIT 许可证;插件在当前 dsh 进程权限下运行,且需要能访问 api.typesafe.ai。

方式一:插件市场

  1. 打开 Settings → Plugin Market
  2. 搜索 typesafe-ask
  3. 安装

方式二:命令行

dsh plugin --profile <your-profile> add dsh-typesafe-ask

经过上面的步骤后,重启或刷新 Harness,打开 Settings → TypeSafe / Jev,从 console.typesafe.ai/keys 创建并粘贴 API Key。密钥仅在主机侧工具调用时从凭据存储读取。

若需改默认项(如凭据引用名、模型、端点、超时),可在 profile 的 cordis.patch.yml 中覆盖插件行,例如:

- id: dsh-typesafe-ask
  config:
    apiKeyRef: MY_TYPESAFE_KEY
    model: jev-latest
    baseUrl: https://api.typesafe.ai/v1/systemone
    timeoutMs: 60000

插件包内默认 apiKeyRef 指向 TYPESAFE_API_KEY,model 为 jev-latest;市场热挂载场景下插件行可以是 bare insert,无需重启即可挂载(详见 README Configuration)。

典型用法

Key 配置完成后,可以用自然语言让智能体判断(例如「这条工单该哪个团队负责?」),或由智能体自行调用 typesafe_ask。

先做问题设计,再构造一次调用。下面 JSON 示例来自 README,展示三类问题如何写:

{
  "department": {
    "type": "choice",
    "instructions": "Which team should handle this",
    "criteria": {
      "billing": "Payment or subscription issues",
      "technical": "Bugs or integration problems",
      "sales": "Pricing or account questions"
    }
  },
  "frustration": {
    "type": "score",
    "instructions": "How frustrated the customer appears",
    "criteria": ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]
  },
  "is_urgent": {
    "type": "noul",
    "instructions": "The message conveys urgency or time-sensitivity"
  }
}

同一次调用中的多个问题会并行评估同一 state,彼此看不到对方答案;只有当前序答案需要用来构造新 state 或新选项时,才应发起第二次调用。

设计问题时的注意点

README「Designing good questions」一节值得在安装后对照实践:

  1. 一次多问独立维度;不要把本应分步依赖的判断硬塞进同一轮。
  2. 每个问题只承载一个窄而连贯的判断;问题 id 不会发给模型,语义应写在 instructions 里。
  3. 多个标签可能同时成立时,用多个 noul 分别问,而不是强行 choice。
  4. score 各级别要是可独立理解的具体情境,避免「低/中/高」这类空泛标签;返回的 score 可能是带概率权重的分数位置。
  5. choice 置信度偏低通常表示选项重叠,应收紧 criteria 互斥性,而不是单纯调低阈值。
  6. 阈值由业务数据校准;noul ≈ 0.5 表示正反概率相当,不等于「中等强度」。

适用场景与边界

适合:需要在 Harness 工作流里做可分支的结构化判断——路由、分类、打分、排序、基于概率的门禁——且愿意使用 TypeSafe Jev 作为专用 System One 推理面。

边界(README Boundaries):

  • 依赖外网访问 api.typesafe.ai。
  • API Key 为服务端密钥,仅存凭据存储。
  • Jev 不能替代主对话模型完成生成式任务。

插件为纯 ESM、无构建步骤;package.json 声明 DSH 引擎 >=0.1.0-rc.1、Node >=20。当前仓库 GitHub 星标为 0,属较新的社区贡献,使用前以仓库最新 README 为准。

结尾

dsh-typesafe-ask 把 TypeSafe Jev 的 typed questions 与校准概率接进 DSH 工具链,让智能体在需要「判断」而非「叙述」时有一条稳定、可编程的路径。

羽毛球分组比赛记分
小程序二维码

欢迎使用《羽毛球分组比赛记分》微信小程序

小夜