DeepSeek Harness Superagent 运维面板：只回答三个问题

系列第 6 篇。本文介绍如何通过 DeepSeek Harness Web 侧栏中的 Superagent 面板监督 Agent。它建立在前五篇之上。

一、面板只回答三个问题

打开面板时，按顺序回答：

1. 现在有什么需要我处理吗？
2. 系统是否健康、是否在做正确的事？
3. 某一件工作的完整历史是什么，从 Trigger 到 Eval 再到 Ticket？

这三点就是整个面板的产品定义。其他内容要么服务这三问，要么被删除。

二、Tabs：沿着工作流组织

Tabs 顺序是 Overview、Source、Trigger、Eval、Execution、Settings。直到仓库和账号 setup 成功，Overview 会显示缺少什么，并链接到相关设置。

单条记录如何读

Dropped message 链接到它的 Ticket；没有 Ticket 时链接到 Thread。Source page 会解释是会话消失了，还是 Source 停止监听它。

仍由 Executor 拥有的人类 follow-up 标记为 Delivered to Ticket，没有 Eval。Thread 还显示 hand-back reasons 和 context-only Subscriptions。Evaluate again 可以把 follow-up 送入 Eval，或重试没有有效裁决的 Trigger：被 Source filtered、unavailable Eval、既没有 non-stop Decision 也没有 Executor acknowledgement 的 delivered message。

Ticket details 显示原始 Trigger、Decision 与 reason、scope 和 Policy version。Assignments 与 secondary details 折叠在直接操作下方。Retry 可用于 Input delivery 失败，或在 blocked/failed Report 后等待人的 Ticket。Ended Tickets 显示 outcome，例如 Pull request merged 或 Stopped by a person。

三、Settings groups

• Sources： 每个 Source 一张 card，包含开关、字段和已核实的账号事实。GitHub 还提供新 Issue、PR、comment、default-branch CI 的 receive-all 开关。Polling 和 read limits 在 Advanced 下。

• Eval： Policy version 和 rules，然后是 On each Source 和 Eval settings。每个 Source tab 包含允许名单、成员同步、admission table、bot list。Sync 在 startup 和 Sync now 时运行。Admission table 区分接收范围、sender membership、消息是否对 Agent 说话。Eval settings 选择 accept mode、timeout、assessment model。

• Execution： worker model、concurrency、directory root、prepare command、blocked commands。点击可用变量会把它插入 prepare command。

• Prompts： Edit 修改 team sections、built-in parts 和 skills。Full prompt 显示组装后文本，并与已保存文本或默认值比较。History 列版本。修改过的 built-in part 标记 changed，可 reset；templates 列出必需占位符。

  升级改变 overridden default 时，会标记 Default updated（默认内容已更新）。面板在团队文本上方比较旧、新默认值。如果旧默认值未记录，则比较团队文本与新默认值。选择 Keep my text 或 Use the new default。被移除 part 的 overrides 列在 tab bar 下方，并在下次 save 时 dropped。

• Deployment： startup problems 与 Check again、state directory、machine limits。Saved limits 无需 restart 生效。DeepSeek Harness Plugin Manager 暴露同一页面。

四、Search

Header search 可按 text、id、Feishu message id 或存储链接（例如 GitHub comment URL）查找 Trigger。原消息中没有的 Feishu link，只有 host 在当前进程生命周期内读过它后才可搜索。

Search 也按 #12 或 GitHub URL 等引用查找 Thread，并按标题或匹配 Thread 查找 Ticket。

五、面板的七条设计原则

1. Focus on what matters. 每个元素回答三个问题之一，否则删除。一个数字只有在改变 supervisor 行为时才出现。
2. Precise definitions. 分类有可检查定义、互斥且覆盖所有情况，正如 Ticket stages。Label 说明这一行在等谁、需要什么，而不是内部状态码。
3. One place per concept. Source state 属于 Source；Threads 和 Triggers 在 Trigger；Decisions 在 Eval；Tickets 在 Execution。Settings 按所配置的概念分组。Overview 汇总并链接，不成为另一个详情页。
4. Domain structure. 面板使用领域术语。内部 id 只出现在折叠详情中；能解析的名字替代 id。
5. Honest state. 计数等于其链接列表长度，任何状态不与其他事实矛盾。
6. Quiet by default. 健康状态不占空间。Problems 必须可行动；一次性网络错误不足以成为 problem。需要人的行直接提供 action。页面说明不超过一句话，细节放入 (?) tooltip。破坏性操作需要确认。
7. Consistent controls. 使用 DeepSeek Harness design tokens 与控件行为。同样信息在面板各处保持一致。每个 settings block 只有一个 save bar，只在有变更、正在 save 或 save 失败时可见。

六、面板为什么不是“仪表盘”

传统后台喜欢把状态堆在一起：运行中的 Session、消息计数、模型名称、配置版本。这个面板拒绝这样做。它把健康状态折叠起来，把需要人的东西提前，并让所有数字都能点击到证据。

这就是注意力预算在 UI 上的最终形态：不让人监控一个正常系统，而是在异常真正需要行动时精准出现。