dsh-im-humanize

  

让 DeepSeek Harness 触手可及 Connecting DeepSeek Harness

简体中文 · English

[!NOTE]

DSH-IM 已获得 DeepSeek Harness 官方 Token 赞助，价值人民币 2,000 元。感谢官方对本项目的支持！

本项目由社区开发者独立开发与维护。

简介

通过扫码、App Manifest 或已有机器人凭据把 IM 机器人接入 DeepSeek Harness，并让本机 Harness 主动连接公网 AI Office。一个插件、一个设置入口，统一管理内置 IM 渠道和 AI Office Connector。每个 IM 渠道都支持接入多个机器人，各机器人的连接状态、工作区、模型和会话绑定彼此独立；iMessage 是本机 Messages.app 身份接入的例外，详见iMessage 渠道说明。

Connect IM bots to DeepSeek Harness by scanning a QR code, using an App Manifest, or entering existing bot credentials, and let the local Harness connect outward to a public AI Office. One plugin and one settings entry manage the built-in IM channels and the AI Office Connector.

本 Fork 的改动（拟人化）

本包发布为 @johnnren/dsh-im-humanize（基于上游 4.21.2）：

dsh plugin --profile web add @johnnren/dsh-im-humanize

本仓库是从 xmanrui/dsh-im fork 出来的"拟人化"分支，在保留上游全部功能的基础上，新增面向角色扮演沉浸体验的设置。全局项在「设置 → IM机器人 → 通用设置」的拟人化设置面板中配置；全部拟人化设置还支持在每个渠道的机器人卡片里按机器人逐项覆盖。

速览：与上游的全部差异

改动 · 默认 · 说明 流式回复 streaming · 开 · 关闭后一次性发送完整回复，不逐字推送 分步消息 message_break · 开 · 注册 no-op 工具，模型主动调用拆长回复为多条消息；与流式同开时每段各自流式输出。只在有 IM 投递消费者的回合启用，Web/CLI 会话不会被引导也不生效 消息处理方式 busyMessageMode · interrupt · interrupt / queue / steer 三档，全局默认 + 每机器人可单独覆盖；上游仅 queue/steer 状态表情回应 statusReaction · 开 · 关闭后六渠道停发处理中/成功/失败表情 回复引用 replyQuote · 开 · 关闭后 Telegram/Discord/WhatsApp 回复不带引用头 过程进度提示 progressStatus · 开 · 关闭后不发"正在处理…/正在使用工具…/正在整理结果…"占位与中间进度气泡，回复直达；流式文本仍逐字显示 发送延迟 sendDelay · 关 · 阅读延迟 + 分段间隔两阶段，含活跃响应 输入状态指示 typingIndicator · burst · off / continuous / burst 三档 QQ 桥接 messageBreak 修复 · — · 修复上游 messageBreakHandler 作用域缺陷 QQ 输入状态会话重写 · — · 桥内自管理 55s/50s 替代失效的 SDK 中间件 延迟窗口双回复修复 · — · 被取代回合静默取消，无双回复 主动回合自动投递 · — · proactive 唤醒、定时任务、后台子代理完成通知等「agent 主动发起」回合的可见回复，自动投递到当前 Session 绑定的私聊（原文无前缀，不依赖双向同步开关） send_im 投递工具 imSendTool · 开 · 注册模型工具，仅用于显式投递到「非绑定」的指定目标（botId+targetId）；主动回合的绑定私聊已自动投递，无需调用

上游同步说明：本分支为长期维护的 fork，会持续合并 xmanrui/dsh-im 上游更新；上游修复与功能在合并时保持完全兼容。分步消息（message_break）、流式开关（streaming）、发送延迟与输入状态指示依赖本 fork 对 Harness 回复追踪（HarnessReplyTracker）与渠道桥接的扩展，在上游仓库中不可用。

• 流式回复（streaming，默认开启）：关闭后不再逐字推送模型输出，而是等回合结束后一次性发送完整回复，更接近真人回复节奏。与 message_break 同时开启时按分段流式：每段在各自的流式载体里逐字输出，断点处定稿为一条消息（见下条）。
• 分步消息（message_break，默认开启）：插件会注册一个名为 message_break 的 no-op 工具（不执行任何操作，仅作为回复中的断点标记）。模型在长回复中主动调用它来"换气"时，插件把断点之前的内容作为一条独立消息交付，随后继续后续分段，整段回答因此变成多条消息，读起来更像真人逐条输入。三个分隔点（思考/工具进度与最终回答之间、长回答的段落之间、前后文切换处）最自然；单回合最多拆分 20 段，纯空白分段会被跳过。与流式回复同时开启时是"分段 + 每段流式"：每段在各自的流式载体里逐字输出（Telegram 私聊、群聊与话题统一为可编辑的占位消息，私聊不占用输入框草稿位，见上游 #276），断点处定稿成一条真实消息，随后为下一段新开一条流；流式关闭时则退化为每段整条发送（带拟人分段间隔）。只在 IM 会话里生效：只有本回合有活跃 IM 投递消费者（即某个渠道桥正在投递这条回复）时才会引导模型使用它，Web/CLI 会话与 AI Office 任务既不会被引导，调用也会被拒绝——判据与 dsh_im_return_file 相同。
• 消息处理方式（busyMessageMode，默认 interrupt）：模型生成过程中用户又发来新消息时的处理方式。全局默认在「拟人化设置」面板配置；每个机器人可在其「通用设置 → 消息处理方式」里单独指定，机器人没指定过时跟随全局默认，改全局默认会同步影响这些机器人：
• 打断重发（interrupt）：取消当前回合并立即用新消息重新提问。被打断的旧回合静默退场——不再发送"已停止。"之类的提示，新消息直接接管（显式 /stop 仍会反馈；旧回合已定稿的分段消息、已产生的部分回答与已存在的流式载体不受影响）；
• 排队等待（queue）：等当前回合结束后再处理新消息（上游默认行为）；
• 注入纠偏（steer）：不中断生成，把新消息文本注入为当前回合的纠偏指令，模型在回答末尾顺势回应。

当回合正在等待用户交互（提问/审批等待、验证码等）时，一律按排队处理，保证交互流程不被新消息打乱。

生效优先级：机器人自己的设置 → 全局「消息处理方式」→ 默认 interrupt。

• 状态表情回应（statusReaction，默认开启）：机器人在用户消息上用表情标记任务状态（处理中/成功/失败，例如 Telegram 的 👀 → 👍/👎）。关闭后不再发送任何表情，回复照常送达。支持 Telegram、Discord、WhatsApp、Slack、飞书、钉钉。
• 回复引用（replyQuote，默认开启）：机器人回复时引用你的消息（回复顶部的引用样式）。关闭后回复以普通消息发出。仅影响 Telegram、Discord、WhatsApp 的引用样式；话题路由（Telegram 话题、Discord Thread、Slack 线程、飞书话题回复）与会话归组不受影响。
• 过程进度提示（progressStatus，默认开启）：处理任务时显示中间状态气泡（如"正在处理…""正在使用工具…""正在整理结果…"）。关闭后不再发送占位气泡与中间进度文案，回复直达；流式文本仍正常逐字显示。与 message_break 同时开启时，关闭此项只跳过占位初态（每段仍各自流式，断点定稿为独立消息），不再影响流式本身。支持所有聊天渠道；QQ/微信本就无中间进度，AI Office 任务进度不受影响（属产品核心 UX）。

发送延迟（两阶段模型）

发送延迟把"真人感"拆成两个阶段，对应真人在 IM 里的两个真实间隙：

1. 阅读延迟（readDelay，阶段①）：机器人收到消息后先静默一段时间才开始处理，模拟"过了一段时间才读到消息"。静默期没有任何输入状态或已读提示。时长为 minMs–maxMs 区间随机值，另有两个可选加项：

• 按消息长度阅读项（charsPerSecond）：用户消息越长，"读"得越久（按字符数除以阅读速度累加）；
• 活跃响应（activityBoost）：刚聊完天时"秒回"，闲置越久延迟越接近完整区间——上一回合结束后 0–fastWindowMs（默认 1 分钟）内直接用 fastReplyMs（默认约 1 秒）；minWindowMs（默认 2 分钟）前线性回升到阅读延迟下限；超过 fullWindowMs（默认 5 分钟）回到完整随机区间。首条消息不加速。

总延迟受 maxTotalMs 封顶；无输入状态接口的渠道（钉钉、企业微信、飞书、Slack 等）阅读延迟封顶 5 秒。钉钉的分段间隔额外强制 ≥3 秒（webhook 频控）。

1. 分段间隔（segmentGap，阶段②的一部分）：分步消息或流式分段的两条消息之间"正在打下一条"的停顿，同样为 minMs–maxMs 随机，可按分段长度加项。

取代（supersede）语义：阅读延迟期间用户又发来新消息（interrupt 模式）或执行 /stop 时，旧回合静默取消——不生成、不发送、无"处理失败"提示、无双回复，新消息立即接管。该静默语义覆盖整条时间线：旧回合无论还在阅读延迟里，还是已经进入 Harness 开始生成，interrupt 都不会留下"已停止。"气泡（/stop 例外，仍会反馈）。排队（queue）模式下多条消息依次处理，延迟会累积（每条都"被读一遍"）。

发送延迟默认关闭（enabled=false），此时除上述取代修复外行为与上游完全一致。设置面板提供全参数面：阅读延迟 min/max、阅读速度（字/秒）、单回合封顶、活跃响应（快速回复 + 秒回/恢复下限/完全恢复三个时间窗）、分段间隔与分段打字速度，折叠区内的断续节奏高级参数（亮/灭四档毫秒），以及探索预设（轻拟人 / 慢性子 / 沉浸角色扮演 / 即刻应答，一键填充全部字段）。配置文件（~/.dsh/integrations/dsh-im/humanize.json）支持同样的全部参数。每个机器人可在其渠道卡片的「拟人化」折叠面板中逐项覆盖全部设置（流式回复、分步消息、状态表情回应、回复引用、过程进度提示、输入状态指示、断续节奏、发送延迟）：每项可选择「跟随全局」或自定义值，保存只写被自定义的项，未自定义的项继续跟随全局默认变化。

输入状态指示（typingIndicator）

进入处理阶段后"正在输入"的显示方式，三档：

• 关闭（off）：完全不显示输入状态；
• 持续（continuous）：处理期间持续显示；
• 断续（burst，默认）：像真人一样时断时续——显示几秒、熄灭一两秒、再显示，避免长时间挂机的机器人感。断续节奏（typingBurst 的 on/off 区间）可在配置文件中调整。

渠道能力差异：Telegram / Discord / WhatsApp（composing）支持全部三档；微信在阅读延迟结束后拉取输入票据并保活；QQ 仅私聊支持（群聊无此 API），且改用桥内自管理的输入状态会话（55 秒显示 / 50 秒续期）替代上游依赖的、已失效的 SDK 中间件；钉钉、企业微信、飞书、Slack 无输入状态接口，自动忽略此项。交互等待（提问/审批）期间输入状态暂停显示，回合结束（含 /stop、出错）后必定熄灭。

修复的缺陷（上游 bug）

以下问题在上游 xmanrui/dsh-im v4.13.0 中存在，本 fork 已修复：

• QQ 桥接 `messageBreakHandler` 作用域缺陷：上游中任何成功回合只要启用 message_break 就会触发 ReferenceError 并误报"任务未完成"（也是 4 个基线测试失败的根因）。本 fork 修复了作用域，message_break 在 QQ 渠道正常工作。

Fixes a QQ bridge messageBreakHandler scoping bug in upstream: any successful turn with message_break enabled threw a ReferenceError and misreported a task failure (also the root cause behind 4 baseline test failures).

• 延迟窗口内被取代回合的双回复：阅读延迟计时期间用户又发来新消息（interrupt）或执行 /stop 时，旧回合会被静默取消——不生成、不发送、无"处理失败"提示、无双回复，新消息立即接管。被取代的批量输入保留待 /send 重试。上游的 queue 模式无此问题；本修复覆盖 interrupt 模式。

Fixes double replies for turns superseded during the delay window: a new message (interrupt) or /stop while the read delay is ticking silently cancels the old turn — no generation, no send, no failure notice, no double reply; superseded batch inputs are retained for /send retry. Upstream's queue mode was unaffected; this fix covers interrupt mode.

配置迁移

• `readDelay.idleBoost` → `readDelay.activityBoost`（语义反转）：早期版本的"闲置加成"（闲置越久延迟 ×N）已被语义反转并替换为"活跃响应"（刚聊完天"秒回"）。已存的 idleBoost 键在读取时被忽略并回落新默认值——如果你之前调过闲置加成，请在设置面板重配活跃响应。

`readDelay.idleBoost` → `readDelay.activityBoost` (semantic inversion): the early "idle boost" (the longer the idle, the slower the reply) is semantically inverted and replaced by "activity boost" (fast replies right after a quick exchange). A stored idleBoost key is ignored on load and falls back to the new defaults; if you had tuned the idle boost, re-configure the activity boost in the settings panel.

界面

当前内置渠道

渠道 · 接入方式 · 消息与回复 飞书 · 扫码创建机器人，或使用 App ID + App Secret 手动绑定 · 长连接接收消息；可选择飞书原生“实时直播”、单张实时过程卡或逐步消息展示任务过程；每机器人可开启语音交互（可选渠道能力，默认关闭）：语音消息转写为文字走正常流程，答案同时以语音回复 微信 · 使用微信扫码绑定机器人 · 腾讯 iLink 长轮询收发消息；等待 Harness 回答时显示“正在输入”，最终回复按 1,800 字符分段发送 钉钉 · 扫码创建机器人，或使用 Client ID + Client Secret 手动绑定 · 钉钉 Stream 长连接；通过 AI Card 流式显示回答 企业微信 · 使用企业微信 App 扫码创建智能机器人，或使用 Bot ID + Secret 手动绑定 · 官方 WebSocket 长连接；原生显示“正在思考中”、工具执行进度和流式回答 企业微信应用 · 在企业微信管理后台创建自建应用，填写企业 ID、AgentId、Secret、Token、EncodingAESKey（可选代理地址） · HTTP 回调接收；私聊支持流式回复（微信端不支持时自动改为分段文本），支持图片输入与结果文件回传；成员的微信关注该企业的微信插件后可在微信中直接使用 QQ · 使用手机 QQ 扫码创建机器人，或使用 AppID + AppSecret 手动绑定 · WebSocket 长连接；私聊显示“正在输入”并以单条 Markdown 回复，群聊被 @ 后只发送最终答案 Slack · 使用预置 App Manifest 创建应用，再填写 Bot Token（xoxb-）和 App Token（xapp-） · Socket Mode 长连接；私聊直接回复，频道被 @ 后响应，优先使用官方流式消息 API Telegram · 使用 @BotFather 生成的 Bot Token · Bot API 长轮询；默认私聊直接响应、群聊被提及或回复时响应，也可为每个机器人独立启用私聊白名单安全模式；关闭思考过程留痕时，私聊、群聊和 Topic 均通过占位消息编辑展示进度并原位完成富文本回复，避免 Android 私聊 Draft 占用发送入口，平台不支持富文本时回退为普通文字 Discord · 使用 Developer Portal 生成的 Bot Token · Gateway v10 长连接；私信直接回复；服务器文字/公告频道首次 @ 后创建原生 Thread，后续在线程中无需重复 @，并通过编辑消息流式显示回答 WhatsApp · 使用手机 WhatsApp 扫码关联设备 · WhatsApp Web 长连接；默认仅响应账号自聊，也可切换到指定联系人或开放响应模式；显示已读和“正在输入”，通过每秒编辑同一条消息显示工具进度和逐步生成的回答，长回复自动分段，编辑失败时回退为完整文字回复 iMessage · 在 macOS Messages.app 中登录 iMessage，并按渠道说明授予本机权限 · 使用 macOS 原生 Messages.app 收发文本私聊；不依赖 BlueBubbles；每个 macOS 用户账户使用一个本机 iMessage 身份 Matrix（实验功能） · 填写 homeserver 地址，并提供访问令牌，或用户 ID 与密码 · CS API 长轮询接收；私聊直接回复，房间被 @ 后响应，支持线程回复、HTML 白名单富文本与编辑式流式输出，可回传图片和结果文件；包含实验性房间消息加解密，限制见下文

Matrix 加密目前仅供非敏感测试：默认 optional 模式尝试启动加密引擎，失败时跳过收到的加密消息；required 模式在引擎启动失败时拒绝连接。尚未实现交互式设备验证、密钥备份、SSSS 或媒体附件内容加密，本次发布未验证真实 homeserver／Element 互通，请勿将其视为完整的端到端保密保障。

企业微信自建应用的回调基址、代理地址和企业可信 IP 配置，见企业微信自建应用接入说明。

其他 IM 平台可继续按同一渠道适配器结构接入。

扫码新建的飞书和 QQ 机器人，默认允许所有用户在私聊和群聊中聊天及执行内置命令；可在机器人的访问设置中调整白名单和命令权限。已有机器人的访问设置保持不变。

飞书群聊默认接收其他机器人明确 @ 当前机器人的消息，无需额外开关；未 @、仅 @ 其他成员或全体、机器人自身发送的消息和机器人私聊消息仍会忽略，即使群聊响应方式设为“全部”。消息仍受群聊白名单与命令权限约束。飞书应用需要租户权限 im:message.group_at_msg.include_bot:readonly（“获取群组中其他机器人和用户@当前机器人的消息”）；扫码新建应用会默认申请，已有或手动绑定的应用可点击“补全权限”或私聊执行 /repair，扫码并完成飞书要求的发布审批后生效。详见飞书接收消息权限说明。

支持图片输入的内置渠道均支持把 JPEG、PNG、WebP 图片，以及以图片文件方式发送的 GIF，连同可选文字说明发送给 Harness；默认每张原图最多接收 30 MB、每条消息最多 20 张；原图保存到会话工作区，模型副本自动缩放或压缩到单张 5 MB、总计 20 MB 以内，仍超限或模型不支持图片时按文件交给模型处理。这四项限制可在「通用设置 → 附件 → 图片输入」调整，对后续消息生效；原图沿用附件保留时长。调高模型输入上限会增加请求体积、处理耗时和模型成本，也仍受平台及宿主限制。iMessage 首版仅支持文本私聊，不包含在图片能力中。飞书下载用户消息中的图片或文件需要租户权限 im:message:readonly，确认页将其显示为“获取单聊、群组消息”；飞书目前没有为该下载接口提供仅限图片的更窄权限。扫码新建的应用会默认申请；已有或手动绑定的应用可私聊机器人执行 /repair，或在「IM机器人」设置页点击“补全权限”，扫码增量补全该权限、上传机器人图片或文件所需的 im:resource、原生命令面板所需的 application:app_slash_command:read / write，以及卡片回调。

超时后的结果补发

已接入的 IM 渠道共用超时任务跟踪：收到“等待模型回复超时”后，插件会继续检查原任务，完成后向原聊天或线程补发最终文字；插件重启或连接恢复后也会继续检查。/stop 只停止当前聊天提交的对应回合，切换会话后不再向该聊天补发旧会话的结果。无需新增设置，正常回复流程保持原样。

补发仍受渠道发送权限和配额限制。明确发送失败最多尝试三次；发送结果不确定时保留记录并停止自动重试，避免重复消息。此机制恢复文字结果和终态通知，不重放问题、审批或文件工具调用。详见延迟交付说明。

结果文件与图片回传

支持文件回传的内置渠道均可把 Harness 可读取的文件作为渠道原生附件回传。已有文件和当前任务新生成的文件都可以直接发送；该能力对所有已连接机器人默认可用，无需开关或机器人白名单，原有文字、图片、流式回复、命令和会话行为保持不变。iMessage 首版不支持文件或附件回传。

模型调用文件回传工具后，插件把指定文件交给当前渠道的原生接口。图片会优先以原生图片消息呈现；渠道不支持或明确拒绝图片发送时自动回退为文件附件，发送结果不确定时不会补发文件造成重复消息。插件不额外设置文件来源、创建时间、工作区边界、扩展名、内容、数量、大小或有效期规则；文件只需真实存在且可读取。渠道平台仍可能依据自身权限、配额、文件能力或账号等级拒绝发送，插件会按平台返回结果提示。

GIF 动图按各渠道原生能力呈现，存在差异：Telegram 把 .gif 走原生动画消息（sendAnimation），客户端内联循环播放；微信（iLink）协议只提供图片消息、没有独立的表情/动图消息类型，GIF 经图片消息只显示静态首帧，无法内联动图（这是协议层限制，非插件可修）；其余渠道以各自图片消息对 GIF 的原生表现为准。文件名需带 .gif 扩展名才会走图片/动画路径，无扩展名的 GIF 会被当作普通文件发送。

渠道 · 平台要求 微信 · 当前绑定协议和会话需支持原生文件消息，实际可发送范围以微信接口返回为准。 飞书 · 飞书文件上传接口要求文件非空且不超过平台 30 MB；应用需有租户权限 im:resource（“读取与上传图片或文件资源”）。内置扫码流程新建应用时默认申请该权限；已有或手动绑定的应用可通过“补全权限”或私聊 /repair 增量补全并完成飞书要求的审批。飞书开发者后台当前没有单独的 im:resource:upload 权限。 钉钉 · 应用需开通 qyapi_base，机器人需具备文件消息能力；实际格式和大小以当前 OAPI 与机器人能力返回为准。 企业微信 · 应用需具备素材上传和文件消息能力，实际可发送范围以企业微信接口返回为准。 QQ · 机器人需具备文件消息能力，并受 QQ 当日文件上传配额约束；额度耗尽时会明确提示稍后重试。 Slack · Bot Token 需有 files:read、files:write 和 reactions:write；实际文件大小上限由 Workspace 当前策略决定。已有 App 新增或变更 Scope 后，必须重新授权/安装 App 并重新连接机器人。 Telegram · 机器人必须能在当前聊天发送文档，实际可发送范围以 Bot API 返回为准。 Discord · Developer Portal 的 Bot 设置中需启用 Message Content Intent；机器人需有 Send Messages、Create Public Threads、Send Messages in Threads 和 Read Message History 权限；发送结果文件还需 Attach Files。实际附件额度由当前账号与服务器能力决定。 WhatsApp · 当前绑定会话需支持 Document Message，实际可发送范围以 WhatsApp/Baileys 返回为准。 Matrix · homeserver 需允许媒体上传，单文件实际上限由其媒体仓库配置决定；被拒绝时插件会明确提示检查媒体大小限制与上传权限。

AI Office Connector

安装

推荐从 npm 安装已发布的稳定版本：

dsh plugin --profile web add -w @xmanrui/dsh-im

重启 dsh web、刷新浏览器，然后打开「设置 → IM机器人」。IM机器人使用 order: 21，尽量排在一级设置菜单的「Agent 预设」之后；插件页面不再保留旧入口。从旧版升级不会改变已有机器人、凭据、工作区、Agent Preset 或会话绑定。

本机 dsh web 和 DSH Desktop 默认直接复用当前 Host 的内部服务：旧版 Harness 使用 apiProxy，新版 Harness 自动使用 Typert Gateway、Session Controller 和 Workspace Controller，不需要配置 Harness 地址，也不绕行本机 HTTP 端口。Desktop 的兼容模式、扩展窗口和增强模式均无需开启“允许在浏览器中打开”或局域网访问。渠道配置中显式设置的 harnessBaseUrl 仅保留给旧版远程 HTTP/WebSocket Harness；内部调用失败不会自动改连其他 Host。

如需试用尚未发布到 npm 的最新代码，可以改用 GitHub 源安装器：

npx -y github:xmanrui/dsh-im install

GitHub 源安装会直接拉取并构建 Git 依赖；pnpm 10 及以上版本可能要求先在 profile 的 pnpm-workspace.yaml 中允许该依赖执行构建脚本。普通用户建议优先使用 npm 稳定版。

安装后，在对应渠道页面按照内置引导完成扫码或凭据配置。所有 Secret 和 Token 只提交给本机 Harness Host，并写入受保护的凭据存储；状态接口和机器人列表不会回传这些凭据。

如果本机必须通过正向代理访问飞书，请在启动 dsh web 前把 HTTPS_PROXY 设置为包含协议的 HTTP 代理 URL（例如 http://proxy:8080；也支持小写 https_proxy，并兼容使用 HTTP_PROXY 作为回退），修改后重启 Host。飞书注册和凭据验证会复用 SDK 的代理感知 HTTP 客户端，消息长连接会显式通过这个代理建立 WebSocket；长连接目前不读取 ALL_PROXY 或 NO_PROXY。

如果本机无法直连 Telegram Bot API，请使用 Node.js 22.21 或更高版本，并在启动 dsh web 前启用 Node 的环境变量代理支持：

NODE_USE_ENV_PROXY=1 \
HTTPS_PROXY=http://proxy:8080 \
HTTP_PROXY=http://proxy:8080 \
NO_PROXY=localhost,127.0.0.1 \
dsh web

代理地址按本机网络环境填写；修改代理后需要重启 Host。绑定 Telegram Bot Token 时，如果页面提示无法访问 Bot API，请优先检查代理地址、Node.js 版本和 NO_PROXY 配置。

默认行为 · 说明 机器人别名 · 点击机器人名称旁的铅笔设置别名，保存后立即显示，无需重启或重连。原名称始终保留，可点击“恢复原名称”或清空别名后保存；仅影响本机设置页中的显示名称。 机器人工作区 · 每个机器人独立保存工作区。新机器人默认使用 $DSH_HOME/im（未设置时为 ~/.dsh/im），机器人或对话实际选用该目录时自动创建；全部使用其他工作区时，不会仅因启动插件而创建该目录。新会话显示在「未分组」；之后可在机器人卡片中修改。显式配置的 workspace 优先，dshHome 可覆盖环境变量 DSH_HOME。 模型 · 每个 IM 渠道的每个机器人都可在工作区下方独立选择模型；未选择时跟随 Host 默认。切换只影响之后新建的会话；当前聊天先发送 /new，再发送普通消息才会使用新选择。 思考强度 · 在模型下方显式选择该模型支持的思考强度，或跟随模型默认。档位、说明和默认值来自 DSH；切换模型后恢复新模型默认强度。每个机器人独立保存，只影响之后新建的会话。 Agent Preset · 每个机器人可在设置页卡片中选择 Agent Preset。未选择时跟随 Host 的 agent-presets.default；渠道级 config.agentPreset 只作为该渠道之后新接入机器人的默认值。切换不会修改或清空已有会话；若当前聊天已有会话，需先发送 /new，再发送一条普通消息，才会按新选择创建会话。 上下文增强 · 从机器人卡片打开设置，分别决定群聊、私聊是否增强；两个开关默认均关闭，旧机器人升级后也不会自动开启。 飞书指令面板 · 每个飞书机器人可在「更多设置 → 指令面板」里决定聊天输入框打 / 时列出哪些指令、按什么顺序：「跟随默认」使用插件自带的 31 条清单（随插件版本更新），「自定义」则恰好是所选指令和所选顺序。隐藏只是不在候选里出现，手动输入同一命令照旧可用；清单之外手工添加的指令不会被删除。配好一个机器人后，可用「保存并同步到其他机器人」一次写到该渠道的其他所有机器人（会覆盖它们各自的面板设置；离线机器人下次启动时生效）。保存后由机器人后台同步，指令较多时需要一点时间。 飞书被 @ 时开话题 · 默认开启。在群聊或私聊里 @机器人 提问时，机器人会在那条消息下新建一条飞书话题，问答都落在话题内；该话题是 dsh 会话列表里一条独立会话，话题里的后续消息属于同一个会话。只发一个 @机器人（打开菜单）不会新建话题，没有 @机器人 的消息仍留在原会话。可在机器人卡片的「群聊」设置里关闭，关闭后群聊与私聊都恢复平铺回复。 飞书任务过程展示 · 每个飞书机器人可选择不显示过程、实时直播、实时过程卡或逐步消息。实时直播使用飞书原生思考过程展示推理、工具调用和结果，最终答案单独发送；需要飞书 PC 7.70、移动端 7.74 或更新版本。飞书原生思考过程目前无法发到话题内，因此话题中的回合会改用实时过程卡，过程与答案都留在话题里。 会话渠道标识 · 本机 Host 的 IM 渠道与 AI Office 会话自动标记来源。Web 会话列表和搜索结果将「微信 ·」等前缀显示为渠道 Logo；保留 DSH 原有的自动标题生成与更新。已有会话在下次加载时补上。

渠道前缀在 DSH 生成标题后追加，完整保留原始标题与自动／手动来源，不会将自动标题锁定为手动命名，也不会额外调用模型。重复生成、刷新或重启不会叠加前缀；真实的手动命名仍遵循 DSH 原有的锁定规则。此功能由当前 Host 的会话事件驱动，显式连接远程 harnessBaseUrl 时需在目标 Host 上安装该插件。

Logo 由 dsh-im 的浏览器适配显示，无需修改 DSH。适配保留原始文字节点和点击、菜单、拖拽操作；复制、读屏及其他界面仍保留文字渠道名。DSH 页面结构不匹配、浏览器不支持或图标加载失败时，自动保留文字前缀；插件卸载后恢复原始显示。

消息处理方式（打断 / 排队 / 插话）

在机器人卡片中打开 「更多设置 → 通用」，选择 「消息处理方式」，然后保存。每个机器人独立设置，覆盖全部 13 个聊天渠道；机器人没指定过时跟随「拟人化设置」里的全局默认（默认 打断）。

• 打断（默认）：取消当前回合并立即用新消息重新提问；旧回合静默退场，不发送「已停止」提示。
• 排队：当前任务结束后再处理新消息，需要等待时会回复排队提示。
• 插话：任务运行期间，新的普通纯文字作为补充指令加入当前任务，Agent 在下一步读取，并回复提交提示。无需每次输入 /steer。

模式、优先级与全局默认的完整说明见上文 消息处理方式（busyMessageMode） 条目。

保存后立即影响新收到的消息，已排队的消息不会转为插话。AI Office 当前没有普通聊天消息追加入口，此设置不适用。