设计业务用户的 Agent 界面时，第一屏放什么讨论了好几次。聊天框容易理解，可每天来处理告警、看运行和做审批的人，未必想从一个空白输入框开始。
我把主对话、业务状态页和伴随式助手放回实际任务里看。它们可以共存，没有一种形态适合承载所有工作。
用户已经知道对象，界面就不该要求重述
查看既有业务，首页适合给出待处理项、运行中任务、最近产出和关键指标。用户据此选择工作，聊天作为进一步解释或操作的入口。
从空白做分析、报告或应用，对话更适合占主视图，给讨论和产出预览足够空间。用户在编辑一份配置时，旁边的助手则接收当前对象，不要求跳到另一个中心重新描述。
抽屉适合简短问答与回到原任务，长对话、文件和复杂工具状态放进去容易拥挤。入口形态由任务决定，而不是只按“全局聊天”给一个固定窄窗。
应用首页与个人工作中心查询范围不同
应用首页围绕当前业务，个人工作中心跨应用聚合与用户有关的事项。跨应用卡片要保留业务来源、对象和权限范围，点击以后回到对应工作，而不是打开一段失去上下文的聊天。
聚合也不能复用管理员总表作为普通用户数据。任务存在不等于用户有权查看，查询与统计都按当前访问范围限制。
会话引用任务，不承担任务数据库的职责
任务、产出与待批准动作有稳定标识和可查询状态，消息引用它们。窗口关闭、刷新和换设备以后，工作仍可以找到。进度来自运行记录，不靠消息写着“正在执行”来维持。
例如表格点选告警，抽屉加载该对象的会话；关闭抽屉不取消任务；重新打开按对象恢复；完成后列表显示结果，点击进入固定产出。用户不必翻聊天找最后一句。
关闭、取消、隐藏和删除也应有不同含义。界面状态变化不能暗中决定后台执行生命周期。
当前选区与已运行任务分别保存
selection 定位页面对象，context 固定本轮发送信息，run 保存执行。用户提问后改选另一行，可以提示更新上下文，但不能改变已经启动任务的目标。
结果保留所依据的对象版本。页面切换以后，旧解释可以进入对应历史，却不能被误放到新的选区上。多个页面查看同一任务，都读取同一运行状态。
用完整工作检查页面安排
从找到一条异常，到追问、确认建议、离开再回来查结果，检查对象是否丢失、任务是否重复创建、等待和失败是否可区分。长对话创建产出物也要单独走通。
这轮设计的交付应包含各入口的任务、对象关联、关闭恢复规则与状态来源。面积和展开方式可以调整，用户仍知道自己在处理什么，任务也不依赖某个聊天窗口一直打开。