“智能体来了当我给Bot换上卡片界面它终于变得‘像个产品’了”——这个标题背后其实藏着一个很普遍的困境做了大半年智能体模型能力调得挺顺工具调用也通了但给同事演示的时候对方第一句话永远是“这不就是一个带AI的聊天窗口吗”。更扎心的是用户明明完成了任务却总觉得“差点意思”不知道刚才发生了什么、接下来能干什么。我后来想明白了问题不在模型也不在提示词而在交互层。纯文本对话承载不了复杂任务的中间状态用户看不见进度、摸不清边界、也不知道自己的操作有没有生效。直到我把Bot从“纯聊”改成“卡片式交互”它才第一次让我觉得这东西是个产品不是个demo。这篇文章就聊聊这次改造的全过程包括我为什么坚持换卡片、卡片协议怎么设计、Agent在哪个环节发卡片、前端渲染踩了哪些坑以及做完之后暴露出的新问题。如果你也在做智能体或者想把自己的Bot做得更像正经产品这应该能帮你少走不少弯路。1. 智能体为什么“不像产品”先想清楚再动手1.1 对话是第一步不是最后一步多数智能体项目的起点都是“能不能用自然语言完成任务”这本身没错。但做久了你会发现对话式交互有一个很微妙的矛盾它把一切信息都拍平了。一段回复无论是三步操作还是三十步操作最终呈现在用户面前的就是聊天窗口里的几行文字。模型能力强的时候文字里能塞下细节模型偷懒的时候用户根本察觉不到它漏了哪一步。更麻烦的是任务一旦涉及结构化信息——表格、清单、状态机、分步执行结果——纯文本的表达效率会直线下降。你让模型输出一份项目排期它能给你一段漂亮的中文但用户想看到的可能是每个任务的负责人、截止时间、依赖关系这些东西在文本里存在感极弱。这其实是交互范式的错位模型内部的推理和工具调用是高度结构化的但用户侧看到的却是线性文本。信息在传递过程中经历了一次“有损压缩”用户感知到的智能水平远低于模型实际的能力水平。我举一个自己的例子。最早做的销售线索清洗Bot能把客户对话转成结构化线索落到表格里字段有公司、联系人、意向等级、下一步动作。纯文本输出时用户看到的是“已识别3条线索其中A公司意向等级为高”听起来没问题但要真去核对每一条信息用户得自己在文字里找。换成卡片以后每条线索独立一张卡等级有颜色标签下一步动作有按钮用户扫一眼就全明白了。这不是视觉优化是信息传递效率的质变。1.2 用户不关心模型怎么想只关心发生了什么另一个被忽视的问题是“过程可见性”。聊天窗口里模型生成答案是一个黑盒用户发出指令然后等待然后看到结果。中间模型调了哪些工具、查了哪些数据、做出过什么判断用户一概不知。如果最终结果正确这些缺失的信息问题不大一旦结果不对或者用户想追问就麻烦了。比如一个做竞品分析的Agent用户问“帮我整理一下三家竞品的最新动态”。文本模式下Agent可能默默调用了五个搜索接口聚合成一份报告。但用户不知道这个报告覆盖了哪些时间范围、引用了哪些信源、哪些结论是推测而非实证。追问时用户只能说“这个数据哪来的”Agent再解释一遍一来一回体验断裂。卡片界面提供了一个很自然的解决思路把Agent的思考过程映射成一组可视化的状态卡片。搜索阶段发一张“正在检索”卡分析完成发一张“结论摘要”卡引用来源单独一张“信源列表”卡。用户虽然不看代码但能看见Agent“正在做什么”“做过什么”“下一步是什么”。这种透明度对信任感的提升远远超过任何一句“我很可靠”的提示词。这个思路和ReAct模式的理念是一脉相承的。ReActReasoning Acting强调的是让大模型交替进行推理和行动边想边做。既然推理和行动是交替出现的那么每个阶段都可以对应一种卡片类型把“内部过程”翻译成“外部状态”。换句话说卡片界面不只是UI层面的装饰它是对智能体运行机制的一种忠实呈现。理解了这一点后面设计卡片类型时思路就会清晰很多。2. 卡片界面的真实价值不是换皮肤是重新发明“对话的语言”2.1 信息密度与信息结构的双赢很多人第一反应是“卡片不就是把文字排版整好看点吗”这句话对一半。排版确实重要但卡片真正的意义在于引入了“结构”。文本是线性的、一维的卡片是块状的、二维的。用户可以跳读、可以对比、可以扫描而不必逐行阅读。拿一个信息密集型场景来说。财务Bot给用户回月度收支分析如果输出纯文本大概是“本月收入35000元支出28700元其中餐饮4800元交通3200元居住11000元其他9700元结余6300元”。这段信息量不小但用户要自己从中提炼“钱花哪了”。如果换成卡片情况就完全不同头图卡本月结余6300元一条迷你趋势线表明收支变化分类明细卡每个支出类别单独一行配进度条显示占比异常提醒卡居住支出环比上涨18%标红提示建议卡给出下月预算调整建议附带“一键生成预算”按钮信息还是那些信息但用户在3秒内就能定位关键结论。这种体验提升并不是靠“把字变大”实现的而是靠“把信息的层次感还给用户”。好的卡片设计本质上是在替用户做初筛把优先级最高的信息推到第一眼视区。这里要强调一个原则卡片不是把文字塞进盒子里。如果只是给每段文字加个边框背景那跟排版工具没区别。真正的卡片化要求你先想清楚一条消息里包含几个独立的信息单元每个单元应该用什么形式呈现——纯文本、数字高亮、进度条、标签、按钮、图片还是这些元素的组合。形态跟着语义走而不是内容跟着形态走。2.2 把Agent的“内耗”变成用户可感知的“进度”做Agent的人都知道多步骤任务里模型的中间过程很漫长。它可能要先调用搜索、再读文档、再调数据库、再写结论整个过程在文本模式下对用户完全不可见。用户只看到转圈然后突然收到一大段文字。这种体验放在聊天里还能接受但如果你想让产品承担更复杂的任务这种“长沉默”会大量劝退用户。卡片界面能在很大程度上解决这个问题但前提是你得为Agent设计一套“过程卡片”。“正在思考”这种占位卡只是最低级的做法更好的做法是把过程拆成有意义的阶段让用户看到Agent最近在做什么。我改造后的流程是这样的。用户提一个复杂需求Agent先发一张“任务理解卡”用简短的话复述它将要执行的任务让用户有机会在真正执行前纠正方向。然后进入工具调用阶段每调一个重要工具Agent发一张“进度卡”卡上写清楚“正在分析XX数据源”“已找到3份相关文档”。最后任务完成发一张“结果汇总卡”和若干“明细卡”。这套机制跑起来以后一个很微妙的变化出现了用户开始觉得“AI在做正事”而不是“AI在打字”。即便最终结果不理想用户也能指出“你分析的时候漏了第二份文档”而不是笼统地说“你做错了”。对智能体产品来讲这种反馈质量的价值怎么强调都不过分。我还想提一句“渐进披露”的设计原则。卡片可以做多层信息嵌套初始状态下只展示核心结论和几个关键数字需要深入了解的用户可以点击展开或跳转次级视图。你不能把全量信息一股脑堆给用户那样又回到了文本超载的老路。卡片给了你做信息分层的能力就得用起来轻量的看结论重度的看明细多模态的内容走独立浏览页面。2.3 卡片是“语义容器”不是“UI组件”再往前推一步。卡片界面看起来是前端的事情但如果只是前端的事情那它很快就会变成维护噩梦。真正的卡片系统应该是你的智能体后端主动产出的一种“语义消息”。我这样设计消息结构每条消息有一个type字段表示卡片类型一个payload字段存放结构化数据前端根据type找到对应的渲染模板把payload渲染成可视界面。后端只负责产出语义正确的数据前端只负责把它们忠实呈现两边通过协议解耦。这样做有三个直接好处。第一同一个Agent可以在不同端上复用同样的卡片协议前端只要适配一次iOS、Web、小程序都能用。第二卡片可以组合嵌套一张汇总卡里可以内嵌三张明细卡逻辑上干净渲染上灵活。第三后续接入多模态内容也方便比如某个卡片类型对应的是图表或视频前端模板一换就行。我在项目里把卡片当成Agent的输出原语来用配合函数调用和结构化输出一次交互里可能混合多种卡片类型。这套东西跑顺以后你会发现自然语言在智能体里的角色慢慢从“承载全部信息”退回到“衔接和组织信息”结构化的卡片承担了更重也更准确的信息传递任务。这个变化是智能体产品走向成熟的必经之路。3. 实操记录给Bot换一套卡片界面的完整过程3.1 第一步定义卡片类型先画业务地图再写代码动手之前我先整理了一份“当前Agent会产生的所有输出类型”清单。这一步非常关键因为卡片类型直接对应业务场景你没有完整看清业务流程之前设计出来的卡片一定缺胳膊少腿。我当时的做法是把所有场景罗列出来然后归并成几大类交互类任务确认、结果反馈、异常预警、操作按钮——这类卡片负责跟用户对话状态类进度更新、流程步骤、完成通知——这类卡片让用户感知过程数据类指标汇总、明细列表、对比分析——这类卡片承载结构化信息行动类建议操作、一键执行、外部链接跳转——这类卡片引导用户下一步动作3.2 第二步用结构化输出约束Agent让它“说”卡片的话定义好协议之后接下来要解决的问题是怎么让Agent稳定地产出卡片数据。现阶段最可靠的做法是约束大模型的输出格式。我通常会在系统提示词里明确告诉模型“当需要输出流程进度时使用progress类型的卡片消息payload结构如下……”。同时配合函数调用让模型直接输出一个结构化的JSON对象由后端校验后再交给前端渲染。这里有几个关键细节值得注意。第一JSON Schema校验必不可少。模型偶尔会漏字段或给错类型比如把items数组里的对象传成字符串。我在后端加了一层校验中间件专门做格式兜底。校验不通过时不会直接把错误抛给用户而是转成一个通用错误卡告诉用户“数据格式稍有异常已重新整理”。实测下来这比让用户看一堆JSON报错体面得多。第二对于需要外部数据支撑的卡片内容我会让Agent先调用工具拿真实数据再把数据填进卡片模板。这么做是为了避免模型凭空捏造数字。卡片这种结构化形式会让用户更信任内容信任就意味着一旦出错代价也更大。所以我在提示词里反复强调卡片里的数据必须是工具返回值里的原样数据不得自行推导或加工。第三当展示结果需要多个来源时同名数据字段要统一。我遇到过一个典型的坑Agent从A接口拿到的日期格式是时间戳从B接口拿到的是字符串两种数据混进同一个卡片后前端渲染直接乱套。后来我在数据准备层加了一个统一的字段归一化操作所有卡片数据进渲染引擎前先跑一遍清洗把格式差异吞掉。3.3 第三步前端渲染与流式输出的兼容处理做完后端前端这边有几个绕不开的问题。第一个是流式输出和卡片的冲突。大模型生成文本时可以逐字输出体验很顺滑但卡片是整体性的不可能让用户看到一个半成品卡片逐渐渲染。我的方案是“分流渲染”文本部分继续走流式而卡片消息等Agent完整生成JSON后再整体插入。用户看到的效果就是对话内容一行行蹦出来到某个节点时整张卡片“啪”地出现信息完整、布局稳定体验反而比纯文本更惊喜。不过这种方案要处理消息排序问题。流式文本和最终卡片到达前端的时间不一致如果处理不当会出现“文本发完了卡片还没到”“卡片插到旧消息后面”的错乱。我的解决方式是给每条消息分配一个递增序列号前端按序号排序渲染哪怕实际接收顺序乱掉最终展示仍然是正确的。第二个是滚动行为。卡片比文本高得多尤其是带表格和按钮的复杂卡片很容易把当前视口顶出去。用户可能正在看上面的历史消息一条卡片突然插入页面就自动跳到最底部非常恼人。我的处理是卡片消息到达时如果用户正处于底部区域才触发自动滚动如果用户往上翻看历史内容则完全不打扰只在最新消息入口处显示一个小红点提示。这个小交互改动直接消除了大部分“卡片打断阅读”的吐槽。第三个是图片和多媒体素材的加载策略。卡片里如果涉及远程图片别等所有图片加载完再渲染整个卡片。我采用“骨架屏逐步加载”的策略卡片骨架先展示结构核心文字内容立即可读图片各自异步加载。这样既视觉稳定又不会因为某个慢图片卡住整张卡。3.4 第四步平台智能体与自研卡片方案怎么选现在市面上有很多智能体平台比如Coze、Dify这类它们也提供了不少对话框组件和交互元素。不少朋友问我直接用平台能力做卡片效果行不行跟自研方案差在哪。我的看法是分场景。如果项目周期短、以验证逻辑和快速落地为主平台的现成组件完全够用。它们的卡片化和按钮交互能力已经做得不错尤其适合客服、营销这类相对标准化的场景。你甚至可以拖动几个组件就搭出一个带表格、带按钮、带跳转的对话流程非常省时。但如果你想把卡片体系做得更贴合自己业务的语义或者要跨平台复用一套逻辑那自研协议的价值就体现出来了。平台的组件往往是为“通用对话”设计的很难实现完全自定义的信息层次和交互逻辑。更关键的是平台智能体往往把“流程编排”和“输出组件”绑在一起想单独升级交互层而不动业务逻辑会比较受限。还有一个点数据反馈闭环。自研方案可以精确记录每张卡片的曝光、点击、展开和按钮操作这些数据对持续优化智能体的行为有巨大价值。平台方案虽然也会给一些流量统计但粒度通常到不了卡片内部对产品迭代的指导意义有限。我个人的习惯是逻辑验证阶段用平台快速验证交互假设一旦核心体验确定下来再把整个卡片协议迁到自研体系里做精细化运营。两条路线不是二选一而是先快后稳。3.5 第五步从“单卡片”到“卡片流”的设计思维单个卡片设计好不算完真正的产品体验取决于卡片与卡片之间的流。我在做完第一版后明显感觉到零散的卡片堆在一起如果衔接不好用户还是会晕。后来我把注意力从“特定卡片怎么画”转移到“一段对话里卡片应该以什么顺序出现、每种卡片出现几次、怎么排版”。做销售线索场景时我给“一条客户线索的完整处理流”设计了这样一个顺序任务理解卡确认用户意图列出待识别的线索数量进度卡识别过程中更新处理进度每次补充已找到的线索概要结果汇总卡告诉用户共识别几个高意向、几个中意向、几个低意向明细列表卡按意向等级排序展示每条线索的关键字段行动按钮卡“一键倒入CRM”“导出CSV”“标记为今日跟进”这套流程跑下来用户对整个任务的心智模型非常清晰。一次再复杂的任务也因为被拆成几个连续的“卡片节点”而变得可预期。这种设计方式本质上是在用“信息架构”的思路来规划对话流程——只不过信息架构的单元不是页面而是卡片。4. 踩坑与排查做卡片界面的那些“不试不知道”的细节4.1 高频Bug与排查速查表这套体系跑顺以后我总结了一个踩坑速查表基本上新项目里再遇到类似问题可以直接对照排查。问题现象可能原因排查步骤与解法卡片出现但内容为空Agent返回的JSON里字段与后端校验Schema不一致先看Agent原始返回再对比Schema定义确认字段名大小写与嵌套层级卡片顺序错乱流式文本与卡片到达前端时间不一致给消息加序列号前端按序号排序后再渲染卡片数据与用户期望不符模型在卡片里自行加工了工具返回值提示词里强制要求原样使用工具返回数据后端再加一致性校验卡片图片加载慢导致整体渲染卡顿渲染依赖图片完成事件改为骨架屏文字先渲染图片异步加载老会话里的历史卡片无法正常显示卡片协议升级后旧消息结构不再兼容为协议加版本号旧数据按旧版本解析或做数据迁移按钮点击后无反馈回调接口没有正确处理会话状态为按钮回调设计统一的事件类型前端做好loading态与成功/失败反馈用户向上翻阅时页面总被新卡片打断自动滚动逻辑触发时机太激进只在用户位于底部区域时才触发自动滚动移动端卡片溢出屏宽卡片容器没有做响应式适配固定了宽度使用百分比或弹性布局并为大表格类卡片提供横向滚动容器4.2 几个容易忽略但影响很大的小细节第一个是卡片内按钮的回调机制。这不是前端加个onClick就完事的事情。按钮点下去之后后续动作到底由Agent重新规划还是直接触发一个固定函数这要在协议层就定清楚。我见过不少团队把两者的界限做得模糊最后出现“点了按钮又触发一次模型推理结果回复又臭又长”的诡异体验。我的方案是简单动作确认、跳转、下载走函数触发需要理解上下文的动作重新生成、修改方案走Agent推理两者分开处理互不干扰。第二个是会话超时带来的状态污染。用户可能隔了很久才回来点一张旧卡片里的按钮此时会话里的相关上下文可能已经被清理或者数据已经过期。这种场景要在设计时就想好过期卡片点击时要给出明确的过期提示而不是默默地用旧数据执行操作。第三个是降级方案。当模型返回的不是预期卡片类型或者卡片协议解析失败时如果没有降级逻辑用户界面就会直接崩掉。我习惯在渲染层做一个兜底模板任何不认识的卡片类型都渲染成一个通用的文本块保证对话不会中断。稳定性的优先级永远高于新形式的炫技。第四个是卡片内容的可访问性。很多人做卡片只盯着视觉忽略了读屏用户。给每个信息区块补充语义标签给按钮配一个描述性文案成本很低但对特殊人群的体验帮助巨大。这件事不只是合规要求更是产品品质的一部分。4.3 卡片化之后真正暴露出的新问题卡片界面上线一段时间后我遇到了一个此前文本交互下完全没出现的新问题用户更频繁地质疑数据准确性。想了一下其实不奇怪。文字回复里用户对数字往往半信半疑但卡片把数字放到工整的布局里加上进度条、标签这些视觉元素人脑会倾向于认为“这应该是核实过的数据”。所以卡片化以后“内容可信度”的标准也被拉高了。如果卡片里的数据来源于模型推测而非工具检索就很容易崩塌信任。应对措施有几条。一是明确标注信息来源——卡片底部加一行小字“数据来源CRM系统更新于2026-01-15”用户自己判断可信度。二是对推测性内容使用不同的视觉样式比如用虚线边框或“AI推理”标签把“预测”和“事实”区分开。三是给关键结论做引用链接用户可以点开卡片里引用的原始文档自行核对。另一个新问题是“卡片疲劳”。最初我把一切信息都卡片化结果用户反馈“刷起来很累全是块块”。后来才意识到不是所有内容都适合卡片。简单的一句话确认用轻量的文本消息反而更自然只有承载结构信息、操作入口或状态变化的内容才需要卡片。交互形式永远服务于信息性质而不是反过来。5. 智能体工程的下一步卡片只是基础设施卡片界面做完Bot终于有了“产品感”但我知道这只是智能体工程化道路上的一个节点。从更广的视角看卡片协议要做得扎实背后离不开几个关键工程的支撑函数与工具调用的稳定性、结构化输出的校验能力、会话状态的管理与恢复以及面向数据反馈的埋点体系。这里也想回应一下很多人纠结的问题“用平台搭智能体和用代码自研到底差在哪”卡片这套东西就是一个很好的例子平台给了你组件的默认实现但如果你要做深度的、跟业务语义对齐的交互最终还是得自己写协议、自己控制渲染、自己埋点分析。平台帮你降低的是快速验证的成本而自研帮你打开的是精细控制的上限。多智能体协同也是接下来绕不开的方向。一旦多个Agent协作完成任务每个Agent的中途输出都值得以卡片形式同步到主线程里让用户看到“哪个Agent正在处理哪部分”。我之前在做一个小型多智能体销售分析系统时就打算把每个子Agent的关键结论做成不同颜色的区块卡片汇聚到主会话里用户一眼就能看清分工和进度。这类场景对卡片的依赖只会越来越重而不是越来越轻。安全方面也要多说一句。卡片化之后用户点击按钮的频率会显著提升这意味着Agent暴露了更多可操作入口。“行为审计”这类机制就变得很必要——每次按钮触发、每次卡片跳转都要有日志可查尤其是当智能体被接入工作流、能操作真实业务系统的时候。卡片不是UI孤岛它背后连着业务流程和权限边界这些都要在工程上同步考虑。最后分享一个我在实际项目里非常受用的习惯每设计一种新卡片先自己扮演用户连发十个不同变体的请求看同一个卡片类型在十种语境下呈现是否都舒服。这个测试量不大但能逼你把卡片的语义边界磨得更清楚也会让你提前发现那些“听起来能行一用就别扭”的设计。智能体产品化这条路还很长但每次往前踏一步都能感觉到“它离真正接客的产品更近了一点”。卡片界面只是一个入口支撑这个入口的工程能力才是真正沉淀下来的东西。
“智能体来了当我给Bot换上卡片界面它终于变得‘像个产品’了”——这个标题背后其实藏着一个很普遍的困境做了大半年智能体模型能力调得挺顺工具调用也通了但给同事演示的时候对方第一句话永远是“这不就是一个带AI的聊天窗口吗”。更扎心的是用户明明完成了任务却总觉得“差点意思”不知道刚才发生了什么、接下来能干什么。我后来想明白了问题不在模型也不在提示词而在交互层。纯文本对话承载不了复杂任务的中间状态用户看不见进度、摸不清边界、也不知道自己的操作有没有生效。直到我把Bot从“纯聊”改成“卡片式交互”它才第一次让我觉得这东西是个产品不是个demo。这篇文章就聊聊这次改造的全过程包括我为什么坚持换卡片、卡片协议怎么设计、Agent在哪个环节发卡片、前端渲染踩了哪些坑以及做完之后暴露出的新问题。如果你也在做智能体或者想把自己的Bot做得更像正经产品这应该能帮你少走不少弯路。1. 智能体为什么“不像产品”先想清楚再动手1.1 对话是第一步不是最后一步多数智能体项目的起点都是“能不能用自然语言完成任务”这本身没错。但做久了你会发现对话式交互有一个很微妙的矛盾它把一切信息都拍平了。一段回复无论是三步操作还是三十步操作最终呈现在用户面前的就是聊天窗口里的几行文字。模型能力强的时候文字里能塞下细节模型偷懒的时候用户根本察觉不到它漏了哪一步。更麻烦的是任务一旦涉及结构化信息——表格、清单、状态机、分步执行结果——纯文本的表达效率会直线下降。你让模型输出一份项目排期它能给你一段漂亮的中文但用户想看到的可能是每个任务的负责人、截止时间、依赖关系这些东西在文本里存在感极弱。这其实是交互范式的错位模型内部的推理和工具调用是高度结构化的但用户侧看到的却是线性文本。信息在传递过程中经历了一次“有损压缩”用户感知到的智能水平远低于模型实际的能力水平。我举一个自己的例子。最早做的销售线索清洗Bot能把客户对话转成结构化线索落到表格里字段有公司、联系人、意向等级、下一步动作。纯文本输出时用户看到的是“已识别3条线索其中A公司意向等级为高”听起来没问题但要真去核对每一条信息用户得自己在文字里找。换成卡片以后每条线索独立一张卡等级有颜色标签下一步动作有按钮用户扫一眼就全明白了。这不是视觉优化是信息传递效率的质变。1.2 用户不关心模型怎么想只关心发生了什么另一个被忽视的问题是“过程可见性”。聊天窗口里模型生成答案是一个黑盒用户发出指令然后等待然后看到结果。中间模型调了哪些工具、查了哪些数据、做出过什么判断用户一概不知。如果最终结果正确这些缺失的信息问题不大一旦结果不对或者用户想追问就麻烦了。比如一个做竞品分析的Agent用户问“帮我整理一下三家竞品的最新动态”。文本模式下Agent可能默默调用了五个搜索接口聚合成一份报告。但用户不知道这个报告覆盖了哪些时间范围、引用了哪些信源、哪些结论是推测而非实证。追问时用户只能说“这个数据哪来的”Agent再解释一遍一来一回体验断裂。卡片界面提供了一个很自然的解决思路把Agent的思考过程映射成一组可视化的状态卡片。搜索阶段发一张“正在检索”卡分析完成发一张“结论摘要”卡引用来源单独一张“信源列表”卡。用户虽然不看代码但能看见Agent“正在做什么”“做过什么”“下一步是什么”。这种透明度对信任感的提升远远超过任何一句“我很可靠”的提示词。这个思路和ReAct模式的理念是一脉相承的。ReActReasoning Acting强调的是让大模型交替进行推理和行动边想边做。既然推理和行动是交替出现的那么每个阶段都可以对应一种卡片类型把“内部过程”翻译成“外部状态”。换句话说卡片界面不只是UI层面的装饰它是对智能体运行机制的一种忠实呈现。理解了这一点后面设计卡片类型时思路就会清晰很多。2. 卡片界面的真实价值不是换皮肤是重新发明“对话的语言”2.1 信息密度与信息结构的双赢很多人第一反应是“卡片不就是把文字排版整好看点吗”这句话对一半。排版确实重要但卡片真正的意义在于引入了“结构”。文本是线性的、一维的卡片是块状的、二维的。用户可以跳读、可以对比、可以扫描而不必逐行阅读。拿一个信息密集型场景来说。财务Bot给用户回月度收支分析如果输出纯文本大概是“本月收入35000元支出28700元其中餐饮4800元交通3200元居住11000元其他9700元结余6300元”。这段信息量不小但用户要自己从中提炼“钱花哪了”。如果换成卡片情况就完全不同头图卡本月结余6300元一条迷你趋势线表明收支变化分类明细卡每个支出类别单独一行配进度条显示占比异常提醒卡居住支出环比上涨18%标红提示建议卡给出下月预算调整建议附带“一键生成预算”按钮信息还是那些信息但用户在3秒内就能定位关键结论。这种体验提升并不是靠“把字变大”实现的而是靠“把信息的层次感还给用户”。好的卡片设计本质上是在替用户做初筛把优先级最高的信息推到第一眼视区。这里要强调一个原则卡片不是把文字塞进盒子里。如果只是给每段文字加个边框背景那跟排版工具没区别。真正的卡片化要求你先想清楚一条消息里包含几个独立的信息单元每个单元应该用什么形式呈现——纯文本、数字高亮、进度条、标签、按钮、图片还是这些元素的组合。形态跟着语义走而不是内容跟着形态走。2.2 把Agent的“内耗”变成用户可感知的“进度”做Agent的人都知道多步骤任务里模型的中间过程很漫长。它可能要先调用搜索、再读文档、再调数据库、再写结论整个过程在文本模式下对用户完全不可见。用户只看到转圈然后突然收到一大段文字。这种体验放在聊天里还能接受但如果你想让产品承担更复杂的任务这种“长沉默”会大量劝退用户。卡片界面能在很大程度上解决这个问题但前提是你得为Agent设计一套“过程卡片”。“正在思考”这种占位卡只是最低级的做法更好的做法是把过程拆成有意义的阶段让用户看到Agent最近在做什么。我改造后的流程是这样的。用户提一个复杂需求Agent先发一张“任务理解卡”用简短的话复述它将要执行的任务让用户有机会在真正执行前纠正方向。然后进入工具调用阶段每调一个重要工具Agent发一张“进度卡”卡上写清楚“正在分析XX数据源”“已找到3份相关文档”。最后任务完成发一张“结果汇总卡”和若干“明细卡”。这套机制跑起来以后一个很微妙的变化出现了用户开始觉得“AI在做正事”而不是“AI在打字”。即便最终结果不理想用户也能指出“你分析的时候漏了第二份文档”而不是笼统地说“你做错了”。对智能体产品来讲这种反馈质量的价值怎么强调都不过分。我还想提一句“渐进披露”的设计原则。卡片可以做多层信息嵌套初始状态下只展示核心结论和几个关键数字需要深入了解的用户可以点击展开或跳转次级视图。你不能把全量信息一股脑堆给用户那样又回到了文本超载的老路。卡片给了你做信息分层的能力就得用起来轻量的看结论重度的看明细多模态的内容走独立浏览页面。2.3 卡片是“语义容器”不是“UI组件”再往前推一步。卡片界面看起来是前端的事情但如果只是前端的事情那它很快就会变成维护噩梦。真正的卡片系统应该是你的智能体后端主动产出的一种“语义消息”。我这样设计消息结构每条消息有一个type字段表示卡片类型一个payload字段存放结构化数据前端根据type找到对应的渲染模板把payload渲染成可视界面。后端只负责产出语义正确的数据前端只负责把它们忠实呈现两边通过协议解耦。这样做有三个直接好处。第一同一个Agent可以在不同端上复用同样的卡片协议前端只要适配一次iOS、Web、小程序都能用。第二卡片可以组合嵌套一张汇总卡里可以内嵌三张明细卡逻辑上干净渲染上灵活。第三后续接入多模态内容也方便比如某个卡片类型对应的是图表或视频前端模板一换就行。我在项目里把卡片当成Agent的输出原语来用配合函数调用和结构化输出一次交互里可能混合多种卡片类型。这套东西跑顺以后你会发现自然语言在智能体里的角色慢慢从“承载全部信息”退回到“衔接和组织信息”结构化的卡片承担了更重也更准确的信息传递任务。这个变化是智能体产品走向成熟的必经之路。3. 实操记录给Bot换一套卡片界面的完整过程3.1 第一步定义卡片类型先画业务地图再写代码动手之前我先整理了一份“当前Agent会产生的所有输出类型”清单。这一步非常关键因为卡片类型直接对应业务场景你没有完整看清业务流程之前设计出来的卡片一定缺胳膊少腿。我当时的做法是把所有场景罗列出来然后归并成几大类交互类任务确认、结果反馈、异常预警、操作按钮——这类卡片负责跟用户对话状态类进度更新、流程步骤、完成通知——这类卡片让用户感知过程数据类指标汇总、明细列表、对比分析——这类卡片承载结构化信息行动类建议操作、一键执行、外部链接跳转——这类卡片引导用户下一步动作3.2 第二步用结构化输出约束Agent让它“说”卡片的话定义好协议之后接下来要解决的问题是怎么让Agent稳定地产出卡片数据。现阶段最可靠的做法是约束大模型的输出格式。我通常会在系统提示词里明确告诉模型“当需要输出流程进度时使用progress类型的卡片消息payload结构如下……”。同时配合函数调用让模型直接输出一个结构化的JSON对象由后端校验后再交给前端渲染。这里有几个关键细节值得注意。第一JSON Schema校验必不可少。模型偶尔会漏字段或给错类型比如把items数组里的对象传成字符串。我在后端加了一层校验中间件专门做格式兜底。校验不通过时不会直接把错误抛给用户而是转成一个通用错误卡告诉用户“数据格式稍有异常已重新整理”。实测下来这比让用户看一堆JSON报错体面得多。第二对于需要外部数据支撑的卡片内容我会让Agent先调用工具拿真实数据再把数据填进卡片模板。这么做是为了避免模型凭空捏造数字。卡片这种结构化形式会让用户更信任内容信任就意味着一旦出错代价也更大。所以我在提示词里反复强调卡片里的数据必须是工具返回值里的原样数据不得自行推导或加工。第三当展示结果需要多个来源时同名数据字段要统一。我遇到过一个典型的坑Agent从A接口拿到的日期格式是时间戳从B接口拿到的是字符串两种数据混进同一个卡片后前端渲染直接乱套。后来我在数据准备层加了一个统一的字段归一化操作所有卡片数据进渲染引擎前先跑一遍清洗把格式差异吞掉。3.3 第三步前端渲染与流式输出的兼容处理做完后端前端这边有几个绕不开的问题。第一个是流式输出和卡片的冲突。大模型生成文本时可以逐字输出体验很顺滑但卡片是整体性的不可能让用户看到一个半成品卡片逐渐渲染。我的方案是“分流渲染”文本部分继续走流式而卡片消息等Agent完整生成JSON后再整体插入。用户看到的效果就是对话内容一行行蹦出来到某个节点时整张卡片“啪”地出现信息完整、布局稳定体验反而比纯文本更惊喜。不过这种方案要处理消息排序问题。流式文本和最终卡片到达前端的时间不一致如果处理不当会出现“文本发完了卡片还没到”“卡片插到旧消息后面”的错乱。我的解决方式是给每条消息分配一个递增序列号前端按序号排序渲染哪怕实际接收顺序乱掉最终展示仍然是正确的。第二个是滚动行为。卡片比文本高得多尤其是带表格和按钮的复杂卡片很容易把当前视口顶出去。用户可能正在看上面的历史消息一条卡片突然插入页面就自动跳到最底部非常恼人。我的处理是卡片消息到达时如果用户正处于底部区域才触发自动滚动如果用户往上翻看历史内容则完全不打扰只在最新消息入口处显示一个小红点提示。这个小交互改动直接消除了大部分“卡片打断阅读”的吐槽。第三个是图片和多媒体素材的加载策略。卡片里如果涉及远程图片别等所有图片加载完再渲染整个卡片。我采用“骨架屏逐步加载”的策略卡片骨架先展示结构核心文字内容立即可读图片各自异步加载。这样既视觉稳定又不会因为某个慢图片卡住整张卡。3.4 第四步平台智能体与自研卡片方案怎么选现在市面上有很多智能体平台比如Coze、Dify这类它们也提供了不少对话框组件和交互元素。不少朋友问我直接用平台能力做卡片效果行不行跟自研方案差在哪。我的看法是分场景。如果项目周期短、以验证逻辑和快速落地为主平台的现成组件完全够用。它们的卡片化和按钮交互能力已经做得不错尤其适合客服、营销这类相对标准化的场景。你甚至可以拖动几个组件就搭出一个带表格、带按钮、带跳转的对话流程非常省时。但如果你想把卡片体系做得更贴合自己业务的语义或者要跨平台复用一套逻辑那自研协议的价值就体现出来了。平台的组件往往是为“通用对话”设计的很难实现完全自定义的信息层次和交互逻辑。更关键的是平台智能体往往把“流程编排”和“输出组件”绑在一起想单独升级交互层而不动业务逻辑会比较受限。还有一个点数据反馈闭环。自研方案可以精确记录每张卡片的曝光、点击、展开和按钮操作这些数据对持续优化智能体的行为有巨大价值。平台方案虽然也会给一些流量统计但粒度通常到不了卡片内部对产品迭代的指导意义有限。我个人的习惯是逻辑验证阶段用平台快速验证交互假设一旦核心体验确定下来再把整个卡片协议迁到自研体系里做精细化运营。两条路线不是二选一而是先快后稳。3.5 第五步从“单卡片”到“卡片流”的设计思维单个卡片设计好不算完真正的产品体验取决于卡片与卡片之间的流。我在做完第一版后明显感觉到零散的卡片堆在一起如果衔接不好用户还是会晕。后来我把注意力从“特定卡片怎么画”转移到“一段对话里卡片应该以什么顺序出现、每种卡片出现几次、怎么排版”。做销售线索场景时我给“一条客户线索的完整处理流”设计了这样一个顺序任务理解卡确认用户意图列出待识别的线索数量进度卡识别过程中更新处理进度每次补充已找到的线索概要结果汇总卡告诉用户共识别几个高意向、几个中意向、几个低意向明细列表卡按意向等级排序展示每条线索的关键字段行动按钮卡“一键倒入CRM”“导出CSV”“标记为今日跟进”这套流程跑下来用户对整个任务的心智模型非常清晰。一次再复杂的任务也因为被拆成几个连续的“卡片节点”而变得可预期。这种设计方式本质上是在用“信息架构”的思路来规划对话流程——只不过信息架构的单元不是页面而是卡片。4. 踩坑与排查做卡片界面的那些“不试不知道”的细节4.1 高频Bug与排查速查表这套体系跑顺以后我总结了一个踩坑速查表基本上新项目里再遇到类似问题可以直接对照排查。问题现象可能原因排查步骤与解法卡片出现但内容为空Agent返回的JSON里字段与后端校验Schema不一致先看Agent原始返回再对比Schema定义确认字段名大小写与嵌套层级卡片顺序错乱流式文本与卡片到达前端时间不一致给消息加序列号前端按序号排序后再渲染卡片数据与用户期望不符模型在卡片里自行加工了工具返回值提示词里强制要求原样使用工具返回数据后端再加一致性校验卡片图片加载慢导致整体渲染卡顿渲染依赖图片完成事件改为骨架屏文字先渲染图片异步加载老会话里的历史卡片无法正常显示卡片协议升级后旧消息结构不再兼容为协议加版本号旧数据按旧版本解析或做数据迁移按钮点击后无反馈回调接口没有正确处理会话状态为按钮回调设计统一的事件类型前端做好loading态与成功/失败反馈用户向上翻阅时页面总被新卡片打断自动滚动逻辑触发时机太激进只在用户位于底部区域时才触发自动滚动移动端卡片溢出屏宽卡片容器没有做响应式适配固定了宽度使用百分比或弹性布局并为大表格类卡片提供横向滚动容器4.2 几个容易忽略但影响很大的小细节第一个是卡片内按钮的回调机制。这不是前端加个onClick就完事的事情。按钮点下去之后后续动作到底由Agent重新规划还是直接触发一个固定函数这要在协议层就定清楚。我见过不少团队把两者的界限做得模糊最后出现“点了按钮又触发一次模型推理结果回复又臭又长”的诡异体验。我的方案是简单动作确认、跳转、下载走函数触发需要理解上下文的动作重新生成、修改方案走Agent推理两者分开处理互不干扰。第二个是会话超时带来的状态污染。用户可能隔了很久才回来点一张旧卡片里的按钮此时会话里的相关上下文可能已经被清理或者数据已经过期。这种场景要在设计时就想好过期卡片点击时要给出明确的过期提示而不是默默地用旧数据执行操作。第三个是降级方案。当模型返回的不是预期卡片类型或者卡片协议解析失败时如果没有降级逻辑用户界面就会直接崩掉。我习惯在渲染层做一个兜底模板任何不认识的卡片类型都渲染成一个通用的文本块保证对话不会中断。稳定性的优先级永远高于新形式的炫技。第四个是卡片内容的可访问性。很多人做卡片只盯着视觉忽略了读屏用户。给每个信息区块补充语义标签给按钮配一个描述性文案成本很低但对特殊人群的体验帮助巨大。这件事不只是合规要求更是产品品质的一部分。4.3 卡片化之后真正暴露出的新问题卡片界面上线一段时间后我遇到了一个此前文本交互下完全没出现的新问题用户更频繁地质疑数据准确性。想了一下其实不奇怪。文字回复里用户对数字往往半信半疑但卡片把数字放到工整的布局里加上进度条、标签这些视觉元素人脑会倾向于认为“这应该是核实过的数据”。所以卡片化以后“内容可信度”的标准也被拉高了。如果卡片里的数据来源于模型推测而非工具检索就很容易崩塌信任。应对措施有几条。一是明确标注信息来源——卡片底部加一行小字“数据来源CRM系统更新于2026-01-15”用户自己判断可信度。二是对推测性内容使用不同的视觉样式比如用虚线边框或“AI推理”标签把“预测”和“事实”区分开。三是给关键结论做引用链接用户可以点开卡片里引用的原始文档自行核对。另一个新问题是“卡片疲劳”。最初我把一切信息都卡片化结果用户反馈“刷起来很累全是块块”。后来才意识到不是所有内容都适合卡片。简单的一句话确认用轻量的文本消息反而更自然只有承载结构信息、操作入口或状态变化的内容才需要卡片。交互形式永远服务于信息性质而不是反过来。5. 智能体工程的下一步卡片只是基础设施卡片界面做完Bot终于有了“产品感”但我知道这只是智能体工程化道路上的一个节点。从更广的视角看卡片协议要做得扎实背后离不开几个关键工程的支撑函数与工具调用的稳定性、结构化输出的校验能力、会话状态的管理与恢复以及面向数据反馈的埋点体系。这里也想回应一下很多人纠结的问题“用平台搭智能体和用代码自研到底差在哪”卡片这套东西就是一个很好的例子平台给了你组件的默认实现但如果你要做深度的、跟业务语义对齐的交互最终还是得自己写协议、自己控制渲染、自己埋点分析。平台帮你降低的是快速验证的成本而自研帮你打开的是精细控制的上限。多智能体协同也是接下来绕不开的方向。一旦多个Agent协作完成任务每个Agent的中途输出都值得以卡片形式同步到主线程里让用户看到“哪个Agent正在处理哪部分”。我之前在做一个小型多智能体销售分析系统时就打算把每个子Agent的关键结论做成不同颜色的区块卡片汇聚到主会话里用户一眼就能看清分工和进度。这类场景对卡片的依赖只会越来越重而不是越来越轻。安全方面也要多说一句。卡片化之后用户点击按钮的频率会显著提升这意味着Agent暴露了更多可操作入口。“行为审计”这类机制就变得很必要——每次按钮触发、每次卡片跳转都要有日志可查尤其是当智能体被接入工作流、能操作真实业务系统的时候。卡片不是UI孤岛它背后连着业务流程和权限边界这些都要在工程上同步考虑。最后分享一个我在实际项目里非常受用的习惯每设计一种新卡片先自己扮演用户连发十个不同变体的请求看同一个卡片类型在十种语境下呈现是否都舒服。这个测试量不大但能逼你把卡片的语义边界磨得更清楚也会让你提前发现那些“听起来能行一用就别扭”的设计。智能体产品化这条路还很长但每次往前踏一步都能感觉到“它离真正接客的产品更近了一点”。卡片界面只是一个入口支撑这个入口的工程能力才是真正沉淀下来的东西。
