AI Agent 这两年火得一塌糊涂。所谓 Agent,通俗说就是能自己理解任务、自己规划步骤、自己调用工具、自己完成执行的数字员工。你给它一个目标,它自己想办法把事办了。听起来很美。但实际用起来,有个让人特别难受的点——Agent 在后台吭哧吭哧干了一堆活,用户在前面却啥也看不见。你跟 Agent 说帮我处理这个客户投诉,然后呢?界面要么是个转圈,要么是一行干巴巴的正在处理...。你不知道它现在调了什么工具、跑到第几步、中间有没有出错、还要多久。整个执行过程对你是个黑盒。等它干完了,蹦出来一个结果。对不对、好不好,你完全不知道它是怎么得出来的。这就是 Agent 产品最大的体验短板——执行过程不可见。这篇文章,讲讲 TokUI——JBoltAI 团队开源的 For AI 流式 UI 引擎——是怎么解决这个问题的。TokUI 也是 JBoltAI 自己平台做 Agent 可视化的核心引擎。一、Agent 为什么需要可视化先说清楚,为什么 Agent 必须可视化。第一,信任问题。Agent 是在替你干活,而干活这事,在企业场景里是要负责任的。如果 Agent 的执行过程是个黑盒,用户敢用吗?出了问题谁负责?只有让用户看到 Agent 每一步在干什么,信任才能建立起来。第二,可控问题。Agent 不是万能的,它会判断错、会跑偏、会调用不该调用的工具。如果执行过程不可见,用户根本没机会介入和纠偏。可视化让用户能在关键节点喊停、能调整方向、能及时止损。第三,体验问题。一个让用户盯着转圈等几十秒的产品,和一个让用户实时看到进度、看到中间结果的产品,体验是天壤之别。后者让用户觉得我在参与,前者让用户觉得我在干等。这三条合起来,就是 Agent 可视化的刚需。而 TokUI,正是为这个需求量身打造的。二、TokUI 的 Agent 可视化组件:过程全透明TokUI 内置了一整套 Agent 可视化组件,专门解决执行过程看不见的问题。思考过程组件。Agent 在干活之前,通常会先想——分析任务、规划步骤。TokUI 的思考过程组件,把 Agent 的思考过程展示出来,而且支持可折叠、分步展示。用户能看到 Agent 是怎么拆解任务的、打算分几步做。透明度上来了,信任度也就上来了。工具调用组件。Agent 干活的核心就是调用工具——查数据库、调接口、跑模型。TokUI 的工具调用卡片,把每一次工具调用都可视化展示:调了什么工具、传了什么参数、返回了什么结果、状态是成功还是失败。而且支持流式状态更新——用户能实时看到正在调用→调用成功的状态流转,而不是等任务结束才看到结果。执行计划组件。复杂任务往往分好几步,Agent 会先列个计划再执行。TokUI 的执行计划组件,把这个计划清单展示出来,每一步的完成状态实时更新。用户能清楚地看到:总共有几步、现在在第几步、哪一步完成了、哪一步还在跑、哪一步出错了。智能体协作组件。多个 Agent 协作完成任务时,谁在干什么、互相怎么配合,TokUI 都能可视化展示。让多 Agent 协作不再是黑盒。代码相关组件。如果 Agent 在写代码、跑代码,TokUI 的代码差异、终端输出、可执行沙箱组件,能让用户实时看到 Agent 写了什么代码、跑出了什么结果。边写边跑边看,开发类 Agent 的体验直接拉满。这套组件组合起来,Agent 的整个执行过程就全透明了——从思考到规划,从调用工具到拿到结果,从单步执行到多 Agent 协作,用户全程可见、全程可控。这套能力也是 JBoltAI 平台做 Agent 产品时的标配。三、流式状态更新:不是事后展示,是实时跟进这里有个特别关键的设计——流式状态更新。很多 Agent 产品的可视化,其实是事后展示——任务全跑完了,才把过程日志翻出来给你看。这跟不可视化没本质区别,因为用户在最需要介入的时候(任务执行中)还是啥也看不见。TokUI 不一样。它的工具调用、执行计划、思考过程组件,全都支持流式状态更新。什么意思?Agent 开始调用一个工具,工具调用卡片立刻显示正在调用;工具调用成功,卡片状态实时变成调用成功,并把返回结果展示出来;同时,执行计划里对应的步骤状态也实时更新为已完成。整个过程是流式的、实时的——用户跟着 Agent 的执行节奏,一步步看到进展。不是事后复盘,是实时跟进。这个区别是本质性的。实时跟进让用户能在关键时刻介入——看到某一步卡住了可以喊停,看到某个工具调用失败了可以重试,看到方向跑偏了可以调整。事后展示根本给不了这种可控性。四、为什么 Agent 可视化是 TokUI 的主场可能有读者会问:做 Agent 可视化,为什么非得用 TokUI?用普通前端框架搭不行吗?能搭,但成本极高,而且体验难做好。原因在于,Agent 的执行过程是流式的、不确定的、随时可能变化的。普通前端框架是为数据完整、一次性渲染设计的,要让它们支持流式状态更新、支持中途插入新组件、支持状态实时变化,工程量巨大。而 TokUI 从底层就是为流式设计的。它的状态机解析器、插槽栈渲染引擎、流式状态更新机制,天生就适合 Agent 这种边执行边展示的场景。用 TokUI 做 Agent 可视化,几乎零工程成本——把 Agent 的执行过程用 TokUI 的 DSL 描述出来,流式推给前端,剩下的渲染、交互、状态更新,TokUI 全包了。这就是为什么说 Agent 可视化是 TokUI 的主场——它就是 JBoltAI 团队为这种场景生的。五、一个具体的场景:处理客户投诉说个具体的。假设你有个客服 Agent,接到一个客户投诉。用 TokUI 的可视化,用户看到的执行过程是这样的:第一步,思考过程卡片弹出——Agent 在分析:这是个什么类型的投诉?需要查哪些信息?分几步处理?第二步,执行计划清单显示——总共五步:查客户历史、查这批货的生产记录、查物流、判断责任、生成处理方案。第三步,工具调用卡片陆续弹出——第一个卡片显示正在查询客户历史,状态实时变成查询成功,展示查询结果;第二个卡片显示正在查询生产记录...第四步,执行计划清单同步更新——每完成一步,对应的步骤状态就变成已完成。第五步,最后生成处理方案卡片——把责任判定、处理建议、赔偿方案展示出来。整个过程,用户跟着 Agent 的节奏,实时看到每一步在干什么、结果是什么。不是事后看日志,是实时跟进。这就是 TokUI 给 Agent 产品带来的体验质变——从黑盒执行变成透明协作。六、回到 Agent 产品的本质收个尾。Agent 产品的核心竞争力,不只是Agent 能干多少活,更是用户能不能看见、能不能信任、能不能掌控 Agent 干活。一个黑盒的 Agent,哪怕能力再强,用户也不敢放手用。一个透明的 Agent,哪怕能力稍弱,用户也愿意尝试,因为看得见、可控、能纠偏。TokUI 干的事,就是让 Agent 从黑盒变透明。它是 JBoltAI 团队开源的项目,MIT 协议,零依赖,克隆即用。Agent 不该只在后台默默干活,它该让用户看见每一步。而 TokUI,就是让它被看见的那个引擎。想看 JBoltAI 平台上的实战效果,可以去找 TokUI 的演示。
