DSH Personal Agent 工具链

DSH Personal Agent 工具链：召回、提示与缓存审计

Personal Agent 用久以后，问题通常不再是“能不能调用工具”，而是怎样在正确的时间找回记忆、提醒可用能力、控制长期运行成本，并确认正在使用的模型没有发生非预期变化。

一位 DSH 社区用户公开了自己的长期工作流：记忆文件、承诺清单、Watchdog、手机 Dashboard、图片生成和文档写作逐步组合成日常系统，并拆成 4 个插件和 2 个 Skill。这个案例提供了一套可讨论的工具链结构；其中代码属于社区项目，安装前仍需检查权限、依赖和数据流向。

四条独立链路

dsh-recall 在每轮开始前检索相关记忆，并把结果追加到当前上下文尾部，而不是重写系统提示词。这样做便于保持稳定前缀，也能让召回结果靠近当前问题。

召回应先运行在 dryRun：记录命中项、分数和最终注入长度，不写入会话。确认误召回率后，再逐步开放自动注入，并给每轮设置条数与 Token 上限。

dsh-capability-nudge 将用户消息与能力清单匹配，只在命中时加入一段短提示；没有匹配时保持当前轮不变。它解决的是“能力已经安装，但模型此刻没有想起来”的问题。

能力提示应只说明可用路径，不直接替用户批准高风险操作。提示文本也要短且稳定，避免每轮动态改写大段前缀。

dsh-cache-audit 关注每轮都会变化的文件或提示片段。时间戳、随机顺序、自动更新统计和不断增长的日志，如果位于稳定前缀中，会让 KV Cache 更早失效。

缓存审计的产物应是一份变动来源列表：哪个文件变化、位于提示词什么位置、变化是否有业务价值。先移动高频动态内容到上下文尾部，再讨论更复杂的缓存优化。

dsh-modeltrace 用模型指纹进行定时检查，并可以给出警告或阻断。对长期 Personal Agent 来说，这一层用于发现 Provider 路由、模型别名或上游服务变化。

模型核对不应依赖单一输出特征。应同时保存 Provider、模型 ID、请求时间、关键能力和供应商用量记录，形成可审计的调用轨迹。

更稳妥的建设顺序是：

Dashboard 放在最后，是因为远程入口会扩大认证、网络与设备丢失的风险面。核心 Agent 在本地工作流中稳定后，再增加移动端观察和低风险控制。

每次自动动作至少留下以下字段：

这样才能区分“记忆找错了”“能力没有被提醒”“模型路由变了”和“工具执行失败”。所有信息塞进一个总日志，反而会让问题更难定位。