先把状态聚合到一个地方#

本地助手的状态散在不同动作里：

• bot.brief 给出简短健康概况。
• tasks.status 汇总任务、提醒和临时成果。
• tasks.agent_readiness 看自然语言任务入口是否准备好。
• actions.pending 列出待确认动作。
• projects.list 展示注册项目。
• plugins.status 展示能力包状态。
• audit.recent 展示最近动作摘要。
• memory.today 展示今日记忆片段。

如果每次都在聊天里分别调用这些动作，维护成本会很高。控制台第一版最有用的地方，是把这些只读视图按人能扫描的方式排好。

这也是 Mission Control 原型的重点：一个本机页面，几个固定 API view，每个 view 调用一组已注册的只读动作。

只绑定本机，不先做远程入口#

控制台服务应该先绑定本机回环地址。

原因很简单：这类页面汇总的是本机助手的运行状态，哪怕已经做了脱敏，也不该默认暴露到局域网或公网。

第一版只需要本机浏览器能打开即可。真要远程访问，也应该在后面单独设计鉴权、网络范围和审计，别把一个还在成形的运维页面直接挂出去。

“只能在本机看”听起来不酷，但它让控制台先解决可观测性问题，不急着增加新的攻击面。

API view 要固定，别做 action passthrough#

一个危险的控制台设计，是提供这样的接口：

1
POST /api/run
2
{ "action": "...", "args": { ... } }

这看起来很通用，但它等于把 action layer 的调度器搬到了网页入口。后续任何页面按钮、浏览器插件、脚本或误点，都可能绕出新的执行面。

更稳的做法是只提供固定 view：

1
GET /api/overview
2
GET /api/tasks
3
GET /api/pending
4
GET /api/projects
5
GET /api/plugins
6
GET /api/audit
7
GET /api/memory

每个 view 在服务端写死会调用哪些 action，以及传什么固定参数。没有“任意 action id”，没有“任意 command”，也没有“传什么就跑什么”。

这会让页面少一些扩展性，但可用范围清楚很多。

待确认请求只能展示，不能执行#

控制台里最容易被误设计的部分，是 pending confirmations。

待确认请求很适合展示：动作 id、风险等级、过期时间、是否已过期、下一步应该回到哪里处理。

但确认码不该出现在控制台里，控制台也不该提供“点击确认执行”。

原因是确认流程本来就在隔离风险。用户在聊天卡片或本地维护命令里确认，是为了让“计划”和“执行”分开。如果控制台直接提供执行按钮，就要重新设计 CSRF、权限、审计、二次确认和会话隔离。

第一版没必要背这些风险。它只需要告诉你：现在有多少请求卡住了，是什么风险，是否过期，应该回到原确认渠道处理。

页面要像运维工具，不像营销首页#

Mission Control 这种页面主要用于反复扫状态，不是给访客看的。

所以 UI 应该克制：

• 顶部只有标题、只读说明和刷新按钮。
• 标签页按 Overview、Tasks、Pending、Projects、Files、Plugins、Audit、Memory 分组。
• 卡片用浅色、边框和稳定间距，不做重动画。
• 表格能横向容纳长 id，但不把敏感内容完整铺出来。
• 失败状态用 warn/error 标识，不用夸张视觉效果。

这类页面最重要的是密度和可读性。它应该让你在十秒内知道“服务是否健康、任务是否堆积、是否有外部确认、插件是否异常”，不要展示一堆漂亮但无关的组件。

刷新也要保守#

控制台可以有刷新按钮，但第一版不需要实时 WebSocket。

原因很实际：第一版没有必要上毫秒级更新。只读状态页通常不需要实时刷新；手动刷新或后续加一个低频轮询就够了。

更重要的是，刷新动作本身也应该只触发固定 read-only API view。不能因为“刷新所有状态”就顺手清理过期请求、重启服务或触发调度器。

把读取和维护动作分开，页面行为会更容易解释。

测试要证明它没有变成执行入口#

这种控制台的测试，要覆盖页面之外的风险。

还要专门测它没有提供危险入口：

• API route 必须是固定集合。
• 不存在通用 run route。
• 只允许 GET。
• route 里的 action id 必须是显式字符串。
• route 参数不能接受 action passthrough。
• route 参数不能接受 command passthrough。
• 响应里标明 read-only。

这些测试看起来有点反直觉：它们在证明“没有功能”。不过对本地助手控制台来说，第一版最重要的功能恰恰是没有越权入口。

现阶段的判断#

本地助手需要控制台，但控制台不该一上来就变成遥控器。

第一版 Mission Control 更适合解决三个问题：

• 本地助手当前是否健康。
• 有哪些任务、插件、项目和待确认项需要注意。
• 最近动作和记忆状态有没有异常。

它不需要解决：

• 从网页执行任意 action。
• 从网页输入任意命令。
• 从网页确认高风险动作。
• 从网页发送、上传、发布或修改外部系统。

这件事不算保守过头，主要是顺序问题。

先把状态看清楚，再讨论操作入口。对一个能触发本机动作的系统来说，只读仪表盘不是半成品，它是控制台该有的第一层。