从“聊天框”到“工作台”：如何设计一个真正可用的多模态 Agent 窗口

如果我们回看过去两年大多数 AI 产品的界面，会发现一个很有意思的现象：大家表面上都在做“聊天”，但真正决定产品上限的，从来不是那个输入框，而是输入框背后的执行系统、状态系统，以及用户是否能把一次问题咨询，升级为一条可持续推进的任务链路。

这也是为什么，越来越多的新一代 AI 产品，不再满足于做一个“会回答问题的大模型外壳”，而是开始向“Agent 工作台”演进。用户不只是输入一句话、等待一段文本，而是希望交给系统一个目标，然后让它在文本、图像、文件、网页、工具调用、任务执行之间自然切换，最终输出一个结果，甚至沉淀出一个可复用流程。

从产品形态上看，这类界面通常会借鉴桌面应用的窗口感：左侧是线程、任务、技能或工作区，中间是主对话与执行记录，顶部是状态与控制栏，底部是多模态输入与提交区。它看起来像聊天，但本质上已经是一个轻量化的操作系统前台。

这篇文章想系统讲清楚一件事：如果我们要做一个类似 Manus、Gemini 或下一代智能工作台的“多模态 Agent 窗口”，它在产品设计、前端架构、交互状态、工具调用和工程实现上，究竟应该如何搭建。

一、为什么“聊天框”不够了

传统聊天式 AI 产品有一个天然优势：交互成本低，任何人都知道怎么打字和回车，因此它非常适合作为通用入口。但它也有非常明显的上限。

第一，聊天框天然偏向“单轮输入 -> 单轮输出”的模式。即便背后接了复杂能力，用户看到的仍然只是消息列表，这会导致系统的中间状态不可见，执行过程不可理解，失败原因也难以定位。对于简单问答，这不是问题；但一旦用户希望 AI 去读网页、分析文档、生成方案、调用工具、跨步骤执行任务，纯聊天流就会变得过于扁平。

第二，聊天框天然缺乏“任务感”。用户发出一个复杂请求后，系统到底是正在思考、正在检索、正在调用浏览器、正在读取文件，还是已经卡住了？如果没有明确的状态层，用户会把所有等待都理解为“模型还没回复”，这会严重损害信任。

第三，聊天框对多模态的支持往往停留在“可以上传文件”层面，而没有形成统一的输入协议。文本、图片、网页、PDF、代码仓库、工具执行结果，本质上是不同语义层级的上下文对象。如果前端只是把它们都压扁成一条消息附件，系统就很难做真正高质量的上下文组织。

因此，当我们说要做“多模态 Agent 窗口”时，真正的升级点不是视觉更酷，也不是输入框更大，而是把产品的交互模型从“消息流”升级为“任务流 + 上下文流 + 执行流”的复合结构。

二、一个优秀 Agent 窗口，核心不在 UI，而在模型化

很多团队做这类产品时，一开始会陷入一个误区：先画一个高级的窗口壳子，再往里面塞大模型。这通常会得到一个“看起来像桌面应用”的聊天页面，但很快就会暴露出结构问题。

因为真正决定这个窗口是否成立的，是你怎么定义内部对象。

至少要先定义四类核心实体：

第一类是 Thread。它不是简单的聊天记录，而是一次持续目标的容器。一个线程下可能包含多轮用户输入、多次工具调用、多条执行状态、多个中间结果以及最终产出。

第二类是 Artifact。用户上传的图片、PDF、网页快照、代码片段、生成出的摘要、表格、Markdown 文档，都不应该只是消息文本的一部分，而应该成为可引用、可预览、可复用的独立对象。只有把结果对象化，后续才可能做沉淀与复用。

第三类是 Run。这是任务执行实例。用户提出“帮我分析这 3 个网页并输出一份竞品摘要”时，系统实际会启动一个 run。这个 run 会经历排队、规划、检索、调用、生成、失败重试、完成等状态。如果没有 run 层，整个系统就无法解释“当前到底在执行什么”。

第四类是 Tool Invocation。Agent 真正区别于传统 LLM 应用的地方，在于它会调用外部能力。浏览器、搜索、OCR、代码执行、数据库查询、工作流引擎，这些都应该有结构化调用记录，而不只是藏在一句“我正在分析中”的自然语言里。

这四层一旦建立起来，前端的设计就会自然清晰：线程列表对应 Thread，主消息区承载消息与结果，侧边预览区展示 Artifact，状态条和时间线展示 Run，细粒度事件流反映 Tool Invocation。也就是说，产品结构不是从 UI 画出来的，而是从数据结构长出来的。

三、视觉为什么要“克制”，而不是“炫技”

多模态 Agent 产品的视觉设计，和普通营销官网非常不同。它面对的是一个长期使用、长时间停留、需要连续思考的工作场景，而不是一个几秒钟内抢注意力的转化页。

因此，这类窗口应该尽量满足三个原则：低干扰、高秩序、可持续阅读。

低干扰意味着背景、颜色、装饰都不能喧宾夺主。很多 AI 产品喜欢用发光边框、强渐变、巨大的 3D 球体来暗示“智能感”，但这类元素通常只适合首屏海报，不适合长期承载高密度信息。一个真正优雅的 Agent 窗口，更像是精致的操作系统，而不是科技展板。

高秩序意味着层级必须清晰。顶部负责控制，左侧负责导航，中间负责当前任务，底部负责输入。颜色只在必要时承担状态意义，例如蓝灰表示可交互、绿色表示成功、橙色表示警告、红色表示失败。不要让颜色承担过多装饰任务。

可持续阅读意味着排版必须有“空气感”。无论是系统消息、推理过程、工具调用记录还是最终输出，都需要足够的行高、段落间距和边界感。Agent 产品最忌讳的不是信息少，而是信息挤在一起。用户在这类页面里停留的时间，远高于普通 landing page，因此“读起来不累”本身就是核心体验。

这也是为什么很多看起来高级的 AI 界面，实际上并不耐用。它们适合截图，不适合工作。而一个真正成熟的 Agent 窗口，第一感觉不应该是“哇，很炫”，而应该是“这里看起来值得长期待着”。

四、前端架构的关键：不要把一切都塞进消息列表

一旦产品走向 Agent 化，前端最容易出现的技术问题就是：所有状态都挂在 message list 上。用户一发消息，开发者就往数组里 push 一条“用户消息”，然后再 push 一条“助手消息”，工具调用和状态提示也继续往里 push。短期看很方便，长期一定失控。

正确做法是把“对话呈现”和“执行状态”拆开。

消息流只负责表达对用户有意义的沟通内容，例如用户说了什么、系统最终给出了什么结论、有哪些产出可查看。执行流则负责表达系统在后台发生了什么，例如开始检索、打开网页、提取正文、调用 OCR、执行解析脚本、重试失败步骤等。这两者有关联，但不应混为一体。

在工程上，比较理想的状态组织方式是：

• threadStore 管理线程级状态
• runStore 管理当前任务执行状态
• artifactStore 管理文件与产物
• composerStore 管理输入区状态
• uiStore 管理窗口、面板、弹层、选中项等界面状态

如果用 React 或 Next.js 来做，最忌讳的是把这些状态全部塞进页面根组件，然后通过 props 一层层往下传。随着产品复杂度提升，这种结构会迅速变成不可维护的状态泥潭。更好的方式是围绕“领域对象”拆分状态，组件只订阅自己需要的切片。

另外，流式更新也是这类产品的关键难点。很多人理解的流式输出只有“逐字打印文本”，但在 Agent 产品中，真正需要流式更新的对象远不止文本本身。工具状态、进度条、文件解析结果、阶段切换、实时生成的结构化卡片，都应该支持增量刷新。

因此，前端接收的数据协议最好不是单一的字符串流，而是事件流。比如：

• message.delta
• run.started
• tool.called
• tool.completed
• artifact.created
• artifact.updated
• run.failed
• run.completed

当系统以事件流驱动 UI 时，界面就不再只是“打字机效果”，而会真正拥有过程感和任务感。

五、多模态输入，不是“上传附件”那么简单

很多产品说自己支持多模态，实际上只是给输入框旁边加了一个上传按钮。用户可以传图、传 PDF、传截图，但系统内部并没有真正理解这些输入之间的差异。

一个成熟的多模态 Agent 窗口，需要先解决“输入标准化”的问题。

文本输入通常最简单，它天然是用户显式表达目标的方式。但图片输入并不只是“一张图”，它可能是截图、设计稿、白板照片、报表截屏、证件、手写笔记，不同图像需要不同的解析路径。PDF 也不是同一种对象，有的是排版文档，有的是扫描件，有的是表格集合，有的是图文混排手册。网页链接则可能是文章页、搜索结果页、动态应用、受登录保护页面或视频详情页。

如果前端把这些对象都统一打包成一个 attachments[] 然后发给后端，系统很难做高质量处理。更合理的方案是前端先做一轮轻量识别和标注，例如：

• 输入类型：text / image / pdf / url / code / table
• 来源方式：paste / upload / drag / share
• 基础元信息：文件名、大小、维度、页数、域名、标题
• 预处理状态：已解析、待 OCR、待抽取、待索引

这样做的价值在于，后端收到的不是一个模糊附件，而是一组语义更明确的上下文对象。模型编排层可以基于这些信息，决定哪些对象先做预处理，哪些直接进入上下文，哪些需要转成摘要后再送入模型。

从前端体验角度看，这也能带来更好的可控性。用户不只是“上传了一个东西”，而是看见系统明确知道自己收到的是“网页链接”“扫描版 PDF”“界面截图”，这种反馈会显著提升信任。

六、为什么工具调用的可见性，比模型能力本身更重要

当用户把复杂任务交给 Agent 时，最容易产生焦虑的不是结果慢，而是过程黑箱。特别是在浏览网页、调用搜索、处理文件、执行脚本这类操作中，如果系统没有过程可视化，用户会本能地怀疑它到底有没有在工作。

因此，工具调用不应完全隐藏。

但“可见”并不意味着把全部内部细节裸露出来。真正好的可见性，是一种节制后的透明：用户能知道系统正在做什么，但不会被无意义噪音淹没。

可以把工具调用分成三层表达：

第一层是自然语言层。比如“正在读取网页内容”“正在分析上传的文档”“正在整理输出结构”。这层面向大多数用户，最易理解。

第二层是结构化状态层。比如一个小卡片显示“Browser / Fetch / Parse / Summarize”这样的阶段，并标明成功、失败、耗时、重试次数。它适合有更强控制欲的专业用户。

第三层是开发者级日志层。包括请求参数、返回片段、错误详情、调用链路等，这部分不必默认展开，但应该在调试模式中可用。

这三层的存在，能让一个 Agent 产品同时兼顾普通用户与专业用户。前者获得安心感，后者获得控制感。很多团队只盯着“模型智商”，却忽略了用户对系统可解释性的需求，这会导致一个很强的系统在感知上显得“不可靠”。

七、真正困难的部分：上下文管理与记忆边界

多模态 Agent 的另一个核心难题，不在界面，而在上下文管理。用户今天上传一张图、明天补一个 PDF、后天再丢几个网页链接，希望系统还能记住之前的目标和过程。问题在于，大模型上下文窗口再大，也不能无限无损地承载一切内容。

所以，前端与后端都必须接受一个事实：上下文不是简单堆叠，而是持续压缩、重组与选择。

一个成熟系统通常会把上下文分成至少三层：

第一层是即时上下文，也就是当前轮执行真正送入模型的内容。这一层必须高度精简，只保留对当前任务直接相关的信息。

第二层是线程记忆，也就是当前 thread 的长期状态，包括用户目标、阶段结论、关键约束、已生成产物引用等。这层不一定整段进入模型，但应该随时可被检索或摘要注入。

第三层是工作区记忆，它属于更长期的偏好、资产与项目背景，例如品牌设定、常用模板、团队术语、数据表结构等。

为什么这对前端也重要？因为前端不应假装“系统什么都记得”。相反，它应该通过交互让用户理解记忆边界。例如让用户看到“已引用的文件”“当前任务使用的上下文”“可追加到长期记忆的产物”“本轮不会继续沿用的临时附件”。当用户知道系统记住了什么、丢掉了什么、引用了什么，整套交互会变得清晰很多。

从这个角度看，Agent 窗口不是一个消息容器，而是一个上下文调度器的前台。

八、工程落地时，最值得优先做的不是功能，而是稳定性

如果要把这类产品真正推向可用，工程上优先级最高的通常不是“再接一个新工具”，而是让现有链路足够稳定。

至少有五件事必须优先做好。

第一，错误处理。工具调用失败、网页打不开、OCR 超时、模型响应中断、文件解析异常，这些都不是边缘问题，而是日常问题。如果错误只表现为“助手停止说话”，用户会迅速失去信心。

第二，重试机制。很多失败不是致命错误，而是临时波动。系统应该具备可控重试、幂等执行和中断恢复能力。尤其是多步骤任务，如果某一步失败，不应整条链路从头来过。

第三，观测能力。你必须知道用户在什么阶段流失、哪种文件最容易解析失败、哪个工具最慢、哪个模型组合最稳定。没有埋点和追踪，优化永远只能靠猜。

第四，性能治理。用户对 AI 产品的宽容度并没有想象中那么高。特别是在桌面窗口式体验中，任何卡顿都会被理解为“系统笨”。首屏渲染、流式响应启动时间、工具结果回填时间、文件预处理耗时，都需要被精细监控。

第五，权限与安全。多模态 Agent 很容易触碰到更敏感的数据与操作边界。文件上传、网页访问、外部工具调用、账号连接、本地工作区读取，任何一项都需要清晰的权限模型和用户提示。一个“会做事”的系统，如果没有边界感，很快就会变成一个让人不敢用的系统。

换句话说，Agent 产品一旦脱离单纯问答，它就不再只是模型应用，而更像一个带推理能力的执行系统前端。你必须用构建系统产品的方式来构建它，而不是用搭一个 demo 的方式来搭。

九、如果今天从零开始，我会怎么做这个产品

如果今天让我从零做一个“简洁但高端”的多模态 Agent 窗口，我会优先选择相对稳定、可控的技术路线，而不是最炫的路线。

前端层面，我会采用 Next.js + TypeScript 作为基础壳，原因不是它最时髦，而是它足够适合官网、应用入口、鉴权、静态内容和动态交互共存的场景。样式层我会用 Tailwind CSS 做高效构建，但不会把视觉交给默认组件库，而是保留自定义设计语言。动效上只加少量 Framer Motion 或原生动画，重点做微弱但可信的状态反馈，而不是大面积视觉秀场。

数据层我会强制把 thread、run、artifact、tool invocation 分离，哪怕产品早期功能不多，也不把它们混成一层消息数组。传输协议优先采用事件流，让文本输出、工具调用、状态变化都能统一驱动前端更新。输入层则提前建立对象标准化流程，让图片、PDF、网页和文本从一开始就进入统一的上下文管线。

最重要的是，我不会一开始就试图做“万能 agent”。相反，我会先选择 2 到 3 个最能体现价值的高频场景，例如网页研究、文档总结、素材分析。因为 Agent 产品真正建立口碑，不是靠“我理论上什么都能做”，而是靠“在几个场景里，我真的比人手快很多，而且过程还可信”。

十、结语：未来的入口不是聊天，而是可交付的执行界面

我们今天依然习惯把 AI 产品称为“聊天机器人”，但这个说法正在迅速失效。真正有价值的下一代产品，不是更会聊天的机器人，而是更会承接目标、组织上下文、调用能力、生成结果、沉淀资产的执行界面。

在这个趋势里，“多模态 Agent 窗口”之所以重要，不是因为它看起来高级，而是因为它代表了一种新的交互契约：用户不再只向系统提问，而是把工作交给系统；系统也不再只给出答案，而是展示过程、管理状态、调用工具并产出成果。

所以，设计这样一个窗口，不能只从 UI 出发，也不能只从模型出发。它需要产品设计、系统设计、前端架构、工具编排、状态管理、权限控制共同完成。只有当这些层真正协同起来，这个窗口才不会只是“一个很像 AI 的页面”，而会成为一个真正能被长期使用的数字工作台。

而这，也许才是 Agent 产品和上一代 LLM 应用之间，最本质的分界线。