[功能建议] Web UI 全局响应式布局与移动端支持

[A-normal]

背景

DeepSeek Harness 当前的 Web UI 主要按桌面宽屏布局设计。

但无论是本地开发时缩小浏览器窗口、使用平板，还是通过手机访问已部署的实例，
窄屏下的导航、对话、审批、设置与长工具输出都应保持可用。

本提案讨论 Web UI 的全局响应式布局和移动端交互适配。它不依赖、也不改变任何特定部署方式、反向代理、认证或网络监听策略。

当前问题

在手机或较窄的浏览器窗口中，以下常用操作体验较差：

• 侧栏占用主要可视区域，工作区和会话切换不方便；
• 对话区、输入框与工具输出的高度分配不合理；
• 设置面板、弹窗和确认卡片可能超出视口；
• 工具审批和 Ask User Question 等关键交互不适合触屏操作；
• 长命令、日志和代码输出容易破坏页面横向布局；
• 页面未充分考虑移动端安全区域、软键盘和横竖屏切换。

建议范围

优先在不影响桌面端现有体验的前提下，完成以下适配。

1. 基础断点

• 手机：360–480px；
• 平板：约 768px；
• 桌面：维持现有布局和交互。

2. 窄屏布局与交互

• 侧栏在窄屏下默认收起，通过抽屉或覆盖层打开；
• 对话区作为默认主视图；
• 输入区固定在底部，并避免被移动端软键盘遮挡；
• 工具审批和用户追问卡片保持完整可见、可触摸操作；
• 设置页和弹窗适配视口高度，优先使用内部滚动而不是页面溢出；
• 长工具输出、代码和日志采用折叠、内部滚动或横向滚动策略；
• 不依赖 hover 才能完成关键操作。

3. 移动端细节

• 支持 safe-area-inset-*；
• 横竖屏切换后保持可用；
• 保证主要触摸目标尺寸合理；
• 明确页面、对话区、弹窗和工具输出之间的滚动边界。

非目标

• 不改变现有 Agent、权限、沙箱、认证或网络监听策略；
• 不在本提案中处理公网暴露、反向代理或特权 API 的远程访问问题；
• 不重做桌面端视觉设计；
• 不新增独立移动端客户端；
• 不为某一套特定皮肤实现专属布局。

验证计划

计划至少覆盖以下 viewport：

• Android Chrome：360×800、412×915；
• iPhone Safari：390×844；
• 平板：约 768px；
• 桌面：1280px 以上。

重点验证：

• 工作区、会话和侧栏切换；
• 发送消息与长对话滚动；
• 工具审批与用户追问；
• 设置面板和弹窗；
• 长日志、代码和工具输出；
• 窄屏与桌面宽度之间切换后的布局恢复；
• WebSocket 重连后页面基本交互仍可用。

实现计划

我会先在个人 fork 中完成一个最小、CSS 优先的参考实现：

1. 优先处理主框架、侧栏、对话区、输入区和弹窗；
2. 尽量保持桌面端现有结构与视觉不变；
3. 避免修改 Agent、权限、网络或认证相关代码；
4. 提供改动前后截图/录屏、测试 viewport 和精确 commit；
5. 在本 Discussion 收集反馈后，再决定是否继续扩展覆盖范围。

由于仓库当前不接收外部 PR，本帖的目标是先提供一个可复现、可评估的实现方向，供维护者和社区讨论或后续吸收。

想确认的问题

• 维护者是否认可移动端与窄屏浏览器作为 Web UI 的正式支持场景？
• 对布局改造而言，是否更倾向 CSS 优先的渐进调整，而不是新增独立移动端界面？
• 仓库是否已有推荐的浏览器端响应式测试方式或 viewport 测试矩阵？
• 对侧栏、弹窗和长工具输出的窄屏交互是否已有正在进行的设计方向？

[tianhao8687]

方向合理，但当前布局实现决定了它不可能完全靠 CSS 修好：computeColumns 明确规定 sidebar 永不让步，窄屏仍保留 56px rail，center 吸收剩余亏空。手机模式需要成为 ui-layout 的显式呈现状态。

建议分两步：

1. 小于移动断点时，center 占满宽度；sidebar 变成带遮罩的 overlay drawer，details 变成 sheet/modal。不要改写用户保存的桌面宽度，窗口重新变宽后应恢复原布局。
2. 再处理各表面：composer 使用 100dvh/安全区并验证软键盘；问题和审批卡允许内部滚动；代码/日志容器统一 min-width: 0、overflow-wrap 与横向滚动；关键操作不能只依赖 hover。

drawer 还需要焦点陷阱、Esc 关闭、关闭后恢复触发器焦点、背景不可点击/滚动，以及至少约 44px 的触摸目标。

仓库已有 Playwright 窄视口用例（约 560/640/700/780px），可以在 apps/web/tests 增加 390×844、412×915，并复用 queue-actions、question-composer、approval-composer 与滚动测试。最关键的回归是：窄屏打开/回答审批后，再扩回桌面宽度，原 sidebar/details 偏好和滚动状态仍然正确。

[A-normal]

好的老师。 您的建议非常重要，包含了很多我并没有考虑到的内容。当前我正在尝试实现第一版最小改动，目标与您提供的建议方向整体相同：最小宽度下移除sidebar并采用遮罩层及菜单按钮实现，设计主内容栏占自增长及内容滚动部分关注点；但其中很多测试点我并没有考虑到，可能后续开发与测试流程都会加长（至前较少接触这方面还在学习，尚不足以支撑我自己设计和修改这部分内容）。 我会按照您的建议继续设计并实现对应功能。 tianhao8687 ***@***.***> 于 2026年8月18日周二 00:31写道：

…

方向合理，但当前布局实现决定了它不可能完全靠 CSS 修好：computeColumns <https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/client/ui-layout/src/client/columns.ts> 明确规定 sidebar 永不让步，窄屏仍保留 56px rail，center 吸收剩余亏空。手机模式需要成为 ui-layout 的显式呈现状态。 建议分两步： 1. 小于移动断点时，center 占满宽度；sidebar 变成带遮罩的 overlay drawer，details 变成 sheet/modal。不要改写用户保存的桌面宽度，窗口重新变宽后应恢复原布局。 2. 再处理各表面：composer 使用 100dvh/安全区并验证软键盘；问题和审批卡允许内部滚动；代码/日志容器统一 min-width: 0、overflow-wrap 与横向滚动；关键操作不能只依赖 hover。 drawer 还需要焦点陷阱、Esc 关闭、关闭后恢复触发器焦点、背景不可点击/滚动，以及至少约 44px 的触摸目标。 仓库已有 Playwright 窄视口用例（约 560/640/700/780px），可以在 apps/web/tests 增加 390×844、412×915，并复用 queue-actions、question-composer、approval-composer 与滚动测试。最关键的回归是：窄屏打开/回答审批后，再扩回桌面宽度，原 sidebar/details 偏好和滚动状态仍然正确。 — Reply to this email directly, view it on GitHub <#2869?email_source=notifications&email_token=AZZRPASYIANA6ZLCQCZO7GD5KMXP7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQGUZTONRXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18053767>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZZRPAWFYXKSDZXQI6CMQN35KMXP7AVCNFSNUABJKJSXA33TNF2G64TZHMYTGMZTGA3DKMBZGE5UI2LTMN2XG43JN5XDWMJQGYZTGMBTGGQXMAQ> . You are receiving this because you authored the thread.Message ID: <deepseek-ai/deepseek-harness/repo-discussions/2869/comments/18053767@ github.com>

[tianhao8687]

这个推进方式很好，而且不需要第一版一次覆盖全部测试点。建议把实现切成三个可独立验证的阶段：

1. 先只改 ui-layout：移动断点、sidebar drawer、遮罩、关闭与恢复桌面宽度；配 390px/412px 两个布局测试。
2. 再处理 conversation 的溢出、审批/问题卡和长工具输出。
3. 最后补移动 Safari 软键盘、100dvh、safe area 与横竖屏切换。

第一阶段只要证明“窄屏 center 不再被 rail 挤压、drawer 可键盘关闭、扩宽后偏好恢复”，就是一个完整且容易审阅的最小成果。之后每增加一个表面，就给它补一个窄视口回归，不必把所有移动端细节压在同一轮开发里。

[A-normal]

按照建议和总体方向初步实现了初步框架，给出初步实现与后续优化参考。接下来先继续按主要方向继续推进，完成整体页面全部响应式实现，更多的精调在最终框架完全补足之后再优化。