用 ToolJet MCP 与 Jev 构建客服工单分拣应用

客服团队最头疼的场景之一，是收件箱里堆积了大量消息，却没人能及时完成分类，导致真正紧急的请求被淹没。一个可复用的思路是：让 AI 先为每条工单打上结构化标签，再由人做最终决策。ToolJet 官方博客展示了一个由编码代理生成的「Support Ticket Sorter」应用——用 ToolJet MCP 搭建应用骨架，用 TypeSafe 的决策模型 Jev 完成分拣判断，100 条合成工单最终变成一条可复核的处理队列。

这个工单分拣器解决什么问题

传统工单分拣依赖人工逐条阅读，速度慢、标准不统一，而且分类结果难以沉淀。这个应用的核心设计是把「分类」和「决策」拆开：Jev 负责读取消息并返回结构化结果，包括主题（topic）、紧急程度（urgency）、清晰度（clarity）、是否建议升级（escalation）、置信度（confidence）以及一句简短的原因说明；人则在界面上确认或修改团队归属、优先级并添加备注，最后保存决策。

原文特别强调一个边界：应用不会自动发送回复、不会发起退款、也不会自动变更账户。AI 只提供建议，最终判断权始终在人手里。这个约束对于客服、金融、电信等强合规场景非常关键。

分拣流程是怎么运转的

整个应用是一个密集的控制台界面，包含顶部导航栏、队列标签页、筛选器、工单表格和右侧详情面板。主操作是「Sort」按钮，点击后从批次中填充队列，复核者可以在 All、Untriaged、Respond now、Standard 和 Needs human review 之间切换。

点击任意一行，会同时打开客户原文和 Jev 的结构化结果，复核者可以调整团队或优先级、添加备注并保存。界面上还有一个实时处理的计数器和一个 Jev 计时器，用来追踪已完成并保存的决策，让复核者随时了解运行进度。

路由规则是明确可见的：当主题不清晰、主题置信度低于 60%、或清晰度评分小于等于 1 时，工单会被路由到人工复核队列。Jev 的原始值与人工覆盖值会同时保留。

搭建前的准备工作

应用建立在两个基础组件之上。ToolJet MCP 负责把编码代理连接到 ToolJet 工作区，让代理直接创建表、查询和界面组件；TypeSafe 则是一个决策模型平台，其数据源允许应用向 Jev 提出带类型的问题，并获得结构化答案——比如一个选项、一个分数，或一个带置信度的「是/否」判断。

在配置时，需要把 TypeSafe 数据源添加到工作区并命名为 typesafe，因为构建提示词中引用的就是这个名称。构建期和运行期的分工很清晰：构建期由 MCP 生成应用，运行期应用通过 typesafe 数据源实时调用 Jev。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底提出并开源的协议标准，用于规范大语言模型与外部工具、数据源之间的连接方式。在传统模式下，每个 AI 应用都要为访问数据库、文件系统或第三方服务单独编写适配代码，形成大量重复集成。MCP 通过统一的客户端—服务器抽象，让模型可以像调用标准接口一样发现和调用工具。ToolJet MCP 则是该协议在 ToolJet 低代码平台上的实现，使编码代理能够直接读取工作区结构、创建数据表和查询、生成界面组件，而不必依赖人工在 GUI 中逐步拖拽配置。理解这一点有助于把握本案例的关键：应用骨架不是手写的，而是代理通过 MCP 与 ToolJet 工作区交互后生成的结果，代码文件为 0 正得益于这种协议层的集成能力。

TypeSafe 与 Jev：TypeSafe 是一个面向大模型决策的模型平台，其核心理念是将 LLM 的自由文本输出约束为带类型（typed）的结构化结果。Jev 是该平台上的决策模型运行时，应用通过数据源向其提交带类型的问题，Jev 返回选项、分数或带置信度的布尔判断，而不是一段需要额外解析的自然语言。这种设计中，"主题置信度低于 60%"或"清晰度评分≤1"这类阈值才能被程序稳定判定，因为返回值已经是数字或枚举，而非含糊措辞。相比让模型直接输出 JSON 再自行校验，类型化决策把约束前移到模型层，降低了运行时解析失败的风险，这也是本案例能把分拣规则写死在路由逻辑中的前提。

生成应用用了什么提示词

原文公开了完整的构建提示词，核心约束包括：单页面、密集的深色控制台风格、海军蓝顶栏配青绿色按钮、只用原生组件、不添加动画和渐变；使用已有的 PostgreSQL 而非 ToolJet DB，创建 stk_tickets、stk_triage、stk_notes、stk_runs 四张表；播种 100 条虚构的 SaaS 客服工单，覆盖账单、登录、Bug、功能请求和账户访问问题；通过 Jev 对每条工单进行分拣。

运行时要求同样具体：12 个并行 worker 执行分拣，结果先保存在内存中，每 50 条批量写入 PostgreSQL 并在最后补写一次，每次批量保存后重新加载看板，结束时关闭运行并同步重载看板。权限上创建了 Support Sorter - Agents、Leads 和 Viewers 三个组，只有 Agents 和管理员可以执行分拣、Jev、保存和备注操作，Reset 仅限管理员，Leads 和 Viewers 为只读。

生成结果与一次真实修复

根据原文的数据，ToolJet MCP 最终生成了 1 个页面、4 张 PostgreSQL 表、21 条查询、29 个组件，需要维护的代码文件为 0，经历了 2 轮修复。

第一次点击 Sort 时曾出现故障：队列没有填充，详情面板空白。原因是查询参数没有在每个查询的 options 中声明，导致参数插值解析为空字符串，run id 变成 undefined。在所有查询中补上参数声明后，运行和面板都恢复正常。这个细节值得记录，因为它说明即便应用由 AI 生成，参数声明这类基础约定仍然需要显式满足。

谁适合使用这种队列模式

任何需要处理稳定流入的客户消息的团队都可以复用这套结构：SaaS 和软件支持、电商与市场平台客服、金融科技与银行支持、电信与公用事业，以及 IT 或 HR 服务台。同样的「收件箱到队列」布局也适用于其他需要 AI 建议辅助人工决策的场景，比如用户反馈分拣或内部请求路由。

权限方面，这个应用使用三个 ToolJet 组来划分职责，规则强制执行在查询层面本身，被拦截的用户会收到服务端拒绝，而不只是按钮被隐藏。原文提到这些组目前还没有成员。

用工作流承接队列之外的动作

工单分拣器往往需要一些后台动作，ToolJet Workflows 用可视化节点编辑器来处理，可以由应用、webhook 或定时计划触发，通知、多系统更新和审批都在服务端运行，而不是依赖某个人的浏览器。

具体到触发方式：可以在查询面板中添加 Run Workflow 查询，传入参数并绑定到按钮点击或表单提交等事件处理器；也可以用 webhook 触发，让外部系统通过 HTTP 请求启动工作流；还可以按间隔或 cron 表达式定时运行。逻辑层面支持 If-Else 分支和 Loop 迭代，数据源节点可以读写数据库、REST 或 GraphQL API 以及 SaaS 工具，JavaScript 和 Python 节点则用于服务端的数据转换和业务逻辑。子工作流机制让日志、通知这类共享步骤可以复用一个子流程。

一个自然的应用是：当工单被保存进 Needs human review 时，交给工作流处理——在 Slack 发布工单摘要、通过 Gmail 给负责人发邮件，并把交接备注写回 stk_notes，而不需要离开队列。

Workflow 与查询（Query）的区别：查询通常绑定在界面组件上，由用户操作或页面加载在浏览器侧触发，生命周期与当前会话相关；Workflow 则是运行在服务端的独立流程，可由应用通过 Run Workflow 查询调用，也可由 webhook 或 cron 计划外部触发。这一区分的实际意义在于：通知、审批、多系统写入这类动作不应依赖某个复核者保持页面打开，把逻辑放进 Workflow 后，即使触发者离线，流程仍会执行完毕。同时 Workflow 支持 If-Else、Loop、子工作流以及 JavaScript/Python 节点，适合承载比单条查询更复杂的业务编排。本案例中，工单进入人工复核后向 Slack 和 Gmail 发通知、回写 stk_notes，正是典型的"队列之外"动作，交给 Workflow 而非界面查询更为稳健。

企业级治理能力

工单、备注和复核者的覆盖决策往往涉及客户上下文和内部判断，ToolJet 在平台层提供了相应治理能力：支持 SAML、OIDC 或 LDAP 单点登录与 SCIM 自动开通账号；基于角色的访问控制可以细化到应用、数据源和每条查询；审计日志记录每次登录、编辑和审批决策；支持在 Docker 或 Kubernetes 上自托管实现气隙部署；多人协同编辑配合版本管理和 Git 同步；ToolJet AI 也可以运行在自有部署环境内，而不是共享服务。

总结

这个案例的价值不在于「用 AI 自动处理工单」，而在于展示了一种人机分工的落地形态：AI 负责读消息、打标签、给出建议和理由，人负责确认和覆盖，最终决策被结构化地保存下来。100 条消息变成一条有实时计数、队列标签、筛选器、详情面板和已保存编辑的队列。ToolJet MCP 负责应用结构，Jev 负责判断，人负责拍板——这三者的边界清晰，才是这套方案可以持续运行的原因。