关于重复造轮子这件事，做政务 AI 的朋友应该都深有体会——在开发环境调好的智能体，到了生产环境就得重新摆节点、填提示词，错了还不容易找。我最近在 12345 热线分拨项目里试了一把 openJiuwen 的导出导入，把整个工作流打成 JSON 模板，换个环境直接导入就能用，确实少了那种'在我这儿能跑，到你那儿就卡'的尴尬。下面按实际过程整理一遍，算是个参考。
痛点：为什么政务智能体特别需要导入导出
这几年各地 12345 都上了大模型，但几个坑几乎每个项目都会踩：
- 环境割裂：云上调好的分拨模型，到了政务外网或物理隔离的生产环境，经常得手动重建，漏一个条件分支查半天。
- 协作原始：A 区做了一个识别率 95% 的分拨助手，B 区想用，只能截图照着搭，不光慢，还容易抄错提示词。
- 无法追溯：工作流改过十几版，想回退到上个月的逻辑，只能凭记忆重连。
国家这两年一直在推'一地创新、多地复用'，智能体要能跨科室、跨区县快速复制，导入导出就是落地这个想法的关键一步。openJiuwen 的思路是把整个智能体配置打包成一幅独立于机器和网络的'数字图纸'，接收方导入就能得到一模一样的能力。
从零搭建一个分拨助手
我做的场景是 12345 热线智能分拨：话务员输入市民描述，系统自动推荐责任部门，确认后派单。逻辑很清晰——输入文本 → 大模型理解 → 映射到预定义类别 → 分部门处理。下面一步步拆开，有些细节是调出来的，我会特别提一下。
准备工作：市局开发人员在 openJiuwen Studio 里搭模板，区县同事在另一套环境导入。账号、服务器不同，但导入导出不挑这些。
进入 Studio，新建工作流 Government_Hotline_Dispatch。
开始节点
定义一个 query 变量，类型 String，用来接收市民提问。样例：'你好，房产证在哪里办理。'
意图识别与部门匹配（大模型节点）
这是整个工作流的核心。模型用的 deepseekR1，通过 API 接入。系统提示词我反复测了几版，最后稳定成这样：
你是一个政务业务分类专家。请分析用户咨询，判断其主要涉及以下哪个或哪几个科室：1. 住建局，2. 公安局，3. 人社局 4. 水务局，5. 环保局 6 市场监督局 请输出格式为 JSON: {"departments": ["科室 A", "科室 B"]}。若无明确对应，则为 ["其他科室"]。
用户提示词直接传入开始节点的 query 变量：{{query}}。输出字段叫 output。
