大部分插件在「你按下按钮之后」才有价值。dsh-speak-up 反过来了：它的价值发生在你什么都没做的时候。下面拆它为什么这样设计。
一条链路：定时器 → 掷骰子 → 命中才开口
定时器到点
└─ 掷一次本地骰子（Math.random，一个 token 都不花）
├─ 没掷中 → 什么都不做，只留一条记录
└─ 掷中 → 往「目标会话」送一句话 → agent.followup(message)
→ DSH 自己开一轮：人格、历史、工具、记忆全都照旧落到实现是三步：定时器按「掷骰子间隔」触发（默认 30 分钟，1–1440 可调）；先掷一次纯本地随机数；掷中才把一句话送进目标会话，走 agent.followup(message)。
成本闸门为什么放在掷骰子
间隔 30 分钟，一天理论上触发 48 次。每次都真发一条，就是 48 轮完整的模型调用，而你要的只是一天开口三五次。所以最关键的一刀不是「怎么说话」，而是「在什么条件下才允许自己花 token」：插件把这个问题从模型手里拿回来，交给一个 Math.random。这也是它必须「先掷、再发」的原因——顺序反过来，钱已经花出去了。
命中线：把「要不要开口」折算成概率
命中线 = min(100, 峰时/谷时命中线 × 时机因子（刚聊过 0.15 / 冷太久 1.5 / 中间 1）
+ min(加成上限, 连着没中几次 × 没中加成))规则是掷到命中线以下才开口。默认峰时 20%、谷时 60%、没中加成 +10 个百分点、上限 +40 个百分点，掷的是均匀随机数，所以命中线 60 大致对应六成概率。
命中线为什么分峰谷
模型调用有价格，而价格随时段变，谷时「价钱是峰时的一半」。把开口次数挪到便宜的那一半时间里，同样的预算能换更多次主动。有意思的是峰谷时段写死在代码里，不给设置项：
峰时（贵）：周一~周五 09:00–12:00 和 14:00–18:00
谷时（便宜）：其余全部 —— 含 12:00–14:00 午休、18:00~次日 09:00、周六周日全天按本机本地时区判断，周末直接算谷时。为什么不开放成配置？一旦给出时段编辑器，使用者会陷入「我这作息算峰还是谷」的自省，而计价规则不会因为你改设置项而变——写死一条能背下来的规则，比给一个能填错的表单更诚实。
时机因子：概率跟着「关系」走
- 距上次说话不到 20 分钟 → ×0.15，更难开口
- 20 到 360 分钟 → ×1
- 超过 360 分钟（6 小时）→ ×1.5，更容易开口
这一项处理的不是成本，是体验：刚聊完又冒一句最容易让人当场关掉插件；冷太久则相反，概率该往上抬。两个默认值直接写在设置页的项名上——「近：刚聊过 → 命中线 ×0.15」「远：冷太久 → 命中线 ×1.5」。
没中加成：连续沉默要补偿
每没掷中一次，下次命中线 +10 个百分点，最多 +40，掷中即清零。谷时、因子为 1 时第 1 次 60、第 2 次 70……到第 5 次顶满 100 必中，所以它不会永远不出声。但「连着没中」只存在内存里，DSH 一重启就归零，别指望「关了两天，下次一定开口」；这两格也只影响自动定时掷骰，手动按钮不动计数器。
为什么不用 cron
cron 的语义是「到点就执行」，而主动搭话要的是「到点考虑一下要不要发」。直接 cron 加发送只有两条路：接受一天几十条消息，或者在外面再写一层判断——而「判断写成什么样」绕一圈还是回到概率调度。插件把判断内建了，而且它不花钱，所以敢每 30 分钟就问自己一次。
还有一层更细的差别：cron 按绝对时间对齐，搭话需要的是相对时间。插件用 ctx.sessionController.inspect(sid) 翻一次已落盘历史，找到最后一条 user/message 算出间隔，再乘时机因子。它也故意不唤醒冷会话：DSH 自带的 dsh-schedule 会用 resolveAgent(id) 把没活着的会话 resume 起来，本插件没有活着的 agent 就什么都不做，免得为了开口付一次冷启动。
绕不过去：角色只能是 user
触发消息只能是 user 角色，developer 送不了。 作者读了 DSH 本体源码，给出三条证据：
1. dsh-agent-loop 的 step() 把收件箱认领到的消息写死成 user/message 事件，完全不看 message.role。
2. dsh-session 的 append() 校验事件与角色是否匹配，user/message 配 developer 会直接抛错，那一轮变成 error。
3. 反方向也堵着：developer 消息在 dsh-llm 里会被 withoutDeveloperMessages() 从请求里摘掉，它只服务于「工具清单变更」——塞进历史模型也看不见。
所以插件送出的是 source.kind = "speak-up" 的 user 消息：角色是 user（唯一放行的），来源标记是自己的；设置里填 developer 时插件主动拒发并记一条，而不是去写坏会话日志。这条限制也说明了一件事：在别人的宿主上做主动行为，能走多远取决于宿主允许什么。
几个不显眼但关键的取舍
engines 未声明。package.json 里既没有 engines.node，也没有 dsh 版本约束。好处是装上就跑，代价是宿主升级后的兼容性只能靠作者跟版。本站的实装结论是在 dsh 0.2.1-rc.2 下真实安装成功（L4 · 真实安装，非静态推断）。
许可是自定义的。写的是「Yuuyuko-uu 插件许可 1.2」，GitHub 侧记为 NOASSERTION：允许安装、修改、商用，再分发须保留 LICENSE、写明派生自哪个仓库、不得去署名。它不是 OSI 认证许可，企业合规审查通常会卡在「能不能自动进白名单」。
配置放在自己家。~/.dsh/speak-up-config.json 不是 DSH 的 config，卸载不删，所以重装后设置和记录都还在。更新得先 remove 再 add，直接 add 可能拿到缓存里的旧副本。星标两个口径：站内 184、GitHub API 实测 195；周下载 184 是 npm 全网口径，含 CI 和镜像，不等于本站安装数。
安静时段：两个合理的默认值叠成了不合理
安静时段会盖住谷时：时段内根本不掷，谷时命中线再高也用不上。默认安静 1~8 点，而默认谷时含 18:00~次日 09:00——你以为谷时能多开口，实际上凌晨那七小时它一声不吭。想让谷时真生效，得把安静时段改小、或让起 === 止关掉它。这是「两个合理的默认值叠在一起变成不合理」的典型，README 写了，代码没替你修。
总结
它真正做的事，是把「要不要花一次模型调用」从模型手里拿回来交给一次不花钱的本地随机，再按时段和关系把概率拧到能接受的刻度；更多同类插件的清单见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：想给长期挂着的会话一点自主性、又不想被刷屏的人；对模型调用成本敏感、要按时段压预算的人；愿意花十分钟把命中线和间隔调到顺手的人；正在做 DSH 插件、想看「主动行为 + 成本闸门」实现的人。
不适合：需要精确「每天 9 点提醒我」这种绝对时间调度的人，那是 cron 的活；指望它唤醒冷会话的人，它故意不这么做；公司要求 OSI 认证许可、走自动白名单的人，自定义许可这关就过不去；想用 developer 角色投递的人，DSH 当前版本直接堵死。
标签：dsh-speak-up、DeepSeek Harness、概率调度、成本控制、DSH 插件
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。