DSH 桌宠状态联动
DSH 桌宠状态联动：Tool Call 与低打扰反馈
- 作者
- DeepSeekAgent.io 编辑部
- 发布
- 更新
Agent 任务越来越长以后，用户真正缺少的往往不是另一条“正在处理”消息，而是一种能持续说明当前状态、又不抢占主工作区的反馈。社区桌宠插件提供了一个有意思的实现：监听 DeepSeek Harness 的结构化工作标记，在命令、文件修改、搜索、测试、评审、部署和调试开始时切换姿态，任务结束后再回到待机。
它把 Agent 的后台活动变成环境式界面。用户不必盯着终端输出，也不需要打开日志面板，扫一眼屏幕角落就能知道系统仍在工作。
状态联动需要结构化事件
可靠的桌宠不能通过“页面上出现了某个词”来猜测状态。更稳定的输入包括 Tool Call 生命周期、会话运行状态、终端任务状态和明确的完成事件。插件可以把这些事件归并为少量可理解的状态：
- 待机：没有正在运行的会话或工具；
- 工作中：至少一个工具任务处于执行状态；
- 成功：本轮正常结束，短暂展示完成反馈；
- 失败：工具返回错误或任务被中断；
- 等待用户：Agent 已提出确认或补充信息请求。
社区实现会根据工具类型切换不同姿态，同时在工作状态保持安静。这比不断生成拟人台词更适合开发环境：状态可见，注意力仍留给代码和交付物。
为什么要给状态切换做防抖
一次 Agent 操作可能连续触发文件读取、搜索、修改和测试。若每个事件都立即换图，桌宠会抖动、闪烁，甚至比日志更干扰。状态层需要合并短事件，并设置最短展示时间：
- 工具开始后进入工作态；
- 连续工具之间保持工作态，不回到待机；
- 最后一个工具结束后等待一个很短的稳定窗口；
- 只有没有新任务时才恢复待机；
- 错误和等待用户状态拥有更高优先级。
社区项目还通过素材预加载和动势遮断减少换图时的黑帧。对低打扰界面而言，动画是否稳定比动画数量更重要。
桌宠不能成为执行链的一部分
状态反馈应只读观察 DSH，不应决定 Tool Call 是否执行。即使桌宠脚本崩溃、素材缺失或用户关闭插件，Agent 的会话、终端和工具仍应正常运行。推荐保持三条边界：
- 只订阅事件，不改写任务状态；
- 动画和养成数据单独保存，不写入 Session 核心记录；
- 卸载后不修改 DSH 内置包，也不留下必须加载的启动钩子。
社区插件采用前端注入与只读资源路由，并强调不修改 DSH 业务 DOM。这个方向能降低宿主升级后的耦合风险，但每次 DSH 更新后仍要检查结构化标记和插件契约是否变化。
从桌宠扩展到通用 Agent 状态设计
同一套状态模型也可以用于菜单栏图标、手机通知、实体灯或远程看板。关键不是角色形象，而是把复杂执行过程压缩成用户能立即理解的几个阶段，并且允许展开查看原始证据。
一个成熟的实现可以让用户点击工作态，直接跳转到当前 Tool Call；点击错误态，打开失败日志；点击等待态，回到需要确认的消息。环境式反馈负责提醒，DSH 主界面负责解释。
参考资料
常见问题
桌宠会读取完整聊天内容吗？
基础工作状态联动只需要结构化运行事件。关键词感知等涉及聊天内容的功能应独立开关，并默认关闭。
为什么任务结束后还保持工作姿态？
应检查是否仍有子任务、终端进程或未关闭的 Tool Call。也可能是完成事件没有被插件正确识别。
可以用这套状态判断任务成功吗？
状态反馈只能显示事件结果。真正的成功仍应由测试、文件变化和验收条件确认。