DeepSeek Harness用 TUI /status 命令诊断下一次模型请求的系统提示词与注册工具【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harnessDeepSeek Harness 的 TUI 交互界面中会话计数器只能描述“活动情况”却无法回答“下一次模型请求到底会收到哪些指令和能力”。本文围绕仓库中归档的功能决策笔记 TUI 状态检查模型请求输入英文对照版见 English note完整还原/status命令如何在终端内展示渲染后的系统提示词与按顺序排列的已注册工具名称并结合仓库源码剖析命令注册、作用域组装与取消信号传递的底层机制帮助读者理解“诊断视图与真实请求保持一致”这一设计目标的实现路径。背景TUI 诊断能力的缺口在增强/status命令之前用户面对的是一个典型的可观测性盲区会话计数器session counters可以描述会话是否活跃、正在做什么但下一次模型请求将收到的指令系统提示词与能力工具集对终端用户是不可见的若要诊断“按作用域scope贡献的提示词与工具限制”用户只能离开 TUI或根据配置文件推断结果。对于按插件分层、按 agent 作用域组装提示词与工具的架构而言这种“推断”往往并不可靠——最终进入请求的内容取决于提示词组装 waterfall瀑布式事件、工具排序、呈现模式以及按 agent 的限制任何一环在配置文件里都不直接可见。该笔记将这一问题列为决策的出发点见 笔记“问题”一节。方案/status 复用 agent loop 的真实组装路径笔记记录的决策Status: implemented归档于 2026-08-04是/status通过ctx.systemPrompt为**当前 agent智能体**组装系统提示词使用与agent loop智能体循环相同的渲染器完成渲染——即诊断视图与真实请求走同一条代码路径在带边框的诊断卡片之后以独立且无边框的System prompt与Registered tools两个区域分别显示渲染后的提示词与 assembly 中按顺序排列的工具名称工具名称对应当前 agent 与呈现模式向模型公开的 schema——展示的是“模型实际能看到的工具”而非插件声明的全集。这个设计的关键在于复用而非旁路/status不自己拼一份近似结果而是调用与真实请求完全相同的组装入口从而让诊断输出天然反映下一次请求的实际输入。系统提示词组装ctx.systemPrompt 的作用域语义笔记指出“组装使用命令的取消信号和当前 agent 作用域因此按作用域注册的 section、变量、工具限制及 assembly listener 与此时发起的请求保持一致。” 这句话对应仓库中的两条实现线索命令侧Harness 的插件命令注册表 CommandRuntime 在执行命令时构造的 CommandInvocation 明确携带agent“Exact agent whose UI received the command”与signal“Cancellation signal owned by the dispatching UI request”。也就是说/status的处理器在语义上运行在某个具体 agent 的上下文中并持有可传递的取消信号——这正是笔记中“当前 agent 作用域”与“取消信号”的落点。命令行的解析与执行路径可见 parseCommand 与 execute。提示词侧deepseek-ai/dsh-system-prompt包README负责提示词的 section 注册与组装。从源码结构看该包配套了 按作用域组装的测试、工具顺序测试 与 系统提示词主测试与笔记提到的“按作用域注册的 section、变量、工具限制”相互印证更完整的组装模型说明可参阅 system-prompt 子系统文档。展示格式与净化规则笔记对呈现层还有两条具体约定属于可直接验证的实现事实空值标签空提示词显示为(empty)空工具列表显示为(none)——区分“组装结果为空”与“组装未发生”终端控制字符净化提示词和工具值在呈现前经过 TUI 的终端控制字符净化避免提示词内容中的转义序列破坏卡片布局。这两条约定直接服务于终端渲染的健壮性系统提示词本身可能包含任何插件注入的文本未经净化的控制字符会篡改 TUI 的输出区域。被否决的替代方案及原因笔记完整记录了两个曾考虑但被否决的替代设计其否决理由体现了“诊断必须等于真实请求”这一不变量替代一分别读取提示词 section 和工具注册表。已否决。该做法会绕过提示词组装 waterfall瀑布式事件、工具排序、呈现模式和按 agent 的限制因此诊断结果可能与下一次请求不一致——例如直接读 section 注册表会漏掉 assembly listener 在组装时动态追加的内容直接读工具注册表则会绕过按 agent 的工具限制与呈现模式的过滤。替代二显示完整工具 schema。已否决。工具名称足以回答“注册了哪些能力”而完整参数 JSON 会占据状态卡片的大部分篇幅。完整的 schema 详情并非不可得笔记指向了两个去处生成的工具目录tool-catalog中文见 tool-catalog.zh.md与源代码中的工具定义本身。后果时点快照与错误路径笔记在“后果”一节明确了两个必须理解的边界命令可能触发真实的副作用型回调。/status可能像一次请求准备一样运行提示词提供方provider与 assembly listener——这些回调本是为请求准备的诊断命令也会触发它们失败则通过现有命令错误提示报告。结合 命令执行生命周期已解析命令在执行前后会追加command/run与command/done事件log-only不包裹 turnhandler 抛出或被 abort 时以kind: error结算——这与笔记中“通过现有命令错误提示报告失败”一致。结果是时点快照point-in-time snapshot。后续注册、限制变更、呈现模式切换或动态提供方的变化都可能改变下一次真实请求的内容。因此/status回答的是“此刻发起的请求会看到什么”而不是“永远会看到什么”。测试策略笔记给出的测试安排分三层对应不同层级的验收职责包行为测试package behavioral tests固定按作用域组装的输出、工具名称顺序、空值标签(empty)/(none)以及终端控制字符转义包级语义快照在正常宽度与窄宽度两种终端宽度下执行/status覆盖 TUI 的自适应布局交付验收交付 TUI 的部署负责其组装后的进程验收——即真实进程中的端到端验证归属部署层而非包内测试。从仓库测试惯例看这种“行为测试固定关键值 快照固定呈现 部署层验收真实进程”的分层与 commands 注册表的包级测试 所体现的“注册、解析、生命周期、错误结算各测各的”风格一致。小结/status的提示词与工具展示功能本质上解决的是可观测性的一致性问题与其给 TUI 造一个可能失真的镜像视图不如直接复用 agent loop 的ctx.systemPrompt组装路径与渲染器让诊断卡片成为下一次模型请求的忠实快照。其工程取舍——按顺序展示工具名而非完整 schema、空值显式标签、控制字符净化、时点快照语义——都值得在构建任何“诊断型命令”时参照。读者若希望继续深入可依次查看 agent-lifecycle 文档、system-prompt 子系统文档 与 工具目录它们共同构成了/status背后组装链路的完整文档面。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考