政务一网通APP如何引入AI能力，通过一个AI助手就能够调用所有的功能，实现对话即办事

2024 年以来，城市一网通办基本完成了"基础设施统一"的阶段。一个城市级 APP 把 20 多个委办局的小程序集中到同一个入口------社保局、公积金管理中心、卫健委、教育局、交通局、人社局、医保局、城管局等等部门，各自的小程序都已经能在统一入口里被搜索到。

但"能搜到"和"能办成事"之间还差得远。基本上市民在政务 APP 里办一件具体事情的平均跳转次数是 3.7 次、重复实名认证 2.1 次、账号体系 4 套。

例如一个新生儿落户的常见路径：先在卫健委小程序预约出生证明，再去户口小程序预约户籍登记，再去社保小程序办医保参保，再去教育小程序登记未来入学------四个部分、四个独立账号、四次重复填表。

第二个层面的问题更隐性。20+ 委办局小程序背后是 20+ 套业务系统，每套系统都有自己的数据口径和权限模型。市民问"我家附近的幼儿园学位还剩多少"，这个问题横跨教育局和自然资源局，单纯靠把小程序集中到一个入口解决不了。通用大模型（例如直接接 GPT-4 或通义千问）又被"水土不服"卡住------它不理解"新生儿落户"具体要调哪些接口、不理解不同委办局之间的数据依赖、不理解哪些操作需要双重认证。

第三个层面是治理层。AI 调委办局小程序意味着 AI 拥有了"代办"能力------它能帮你提交表单、调用支付、修改户籍信息。这种能力如果用错地方，后果比单纯的"点错按钮"严重得多。AI 决策过程不透明、调用不可追溯、权限不收敛，事后追责找不到人。现在，监管层面对"政务 AI 自动化决策"的合规要求明显收紧，留痕、可回放、可审计已经从"加分项"变成"准入门槛"。

二、技术选型------"建生态 + 加智能 + 强治理"三段式方案

现在引入AI的主流路径有：自建 AI 助手、嵌入通用大模型、"建生态 + 加智能 + 强治理"三段式。

完全自建 AI 助手被否掉的理由是成本和周期。要做一个能调度 20+ 委办局小程序的 AI 助手，光是把每个委办局的核心业务接口抽象成"AI 可调用的能力清单"，工作量就已经是 6-12 个月团队投入。后续还要做意图识别、上下文管理、对话界面、合规审计、人机协同------这些加起来没有 18 个月根本跑不通。对一个市级项目来说，不太现实。

嵌入通用大模型被否掉的理由是合规和上下文。直接接 GPT-4 或通义千问，模型本身的能力没问题，但政务场景有三条硬约束：数据不能出域（私有化部署是硬要求）、AI 决策必须可审计（通用大模型是黑盒）、AI 调用必须有限定（不能让 AI 直接代扣社保、修改户籍）。这三条硬约束在通用大模型上要么做不到，要么定制成本极高。

"建生态 + 加智能 + 强治理"三段式是最终方案。核心思路是分三步走：

• 第一步，建生态：用小程序容器技术把 20+ 委办局小程序从微信、支付宝迁到城市 APP 自有宿主上，每个委办局的小程序以独立租户的方式接入，OpenAPI 自动化管理。这一步解决"统一入口"的问题，但不解决"AI 调度"的问题。
• 第二步，加智能：在统一入口上叠加 ChatKit类型的对话式 AI 入口。市民从原来的"点 5 个小程序填 5 张表"变成"说一句意图，AI 自动拆解任务、调用对应小程序、跨委办局联办"。ChatKit 作为统一对话界面，背后是"云脑 + 端手"协同架构：云脑做意图理解和任务编排，端手做上下文采集和执行沙箱。
• 第三步，强治理：用"入口闸 + 调用闸 + 审计闸"三道闸门兜底，确保 AI 调委办局小程序的行为是可控、可审计、可回放的。这部分是合规准入门槛，不做完第二步白做。

整体架构如下：

城市政务 APP（端手）
  ├── ChatKit 对话入口（意图识别 / 多轮会话）
  ├── 端侧上下文采集（时间 / 位置 / 设备 / 历史）
  ├── FinClip 小程序运行时（执行沙箱）
  │     ├── 卫健委小程序
  │     ├── 公安小程序
  │     ├── 社保小程序
  │     ├── ...... 20+ 委办局小程序
  └── 政务小程序管理后台（OpenAPI 自动化 / 灰度发布）

ChatKit 云脑（云端）
  ├── 意图理解与任务编排
  ├── Agent 注册中心（每个委办局小程序注册为一个 Agent）
  ├── 上下文工程（短期 / 长期 / 跨会话）
  ├── RAG 检索（政策法规 / 业务知识）
  ├── 合规与留痕（审计日志 / 事件回放）
  └── LLM 可替换（私有化 / 多模型）

这套架构的关键设计是"AI 不直接调用业务系统，AI 只调度小程序"------每个委办局的业务逻辑都封装在小程序里，AI 通过 OpenAPI 调起小程序、传入参数、获取结果。这样 AI 不碰业务系统的后端数据库，权限边界清晰，合规审计也只针对"AI 调度小程序"这一行为做留痕。

三、关键技术路径

3.1 第一步：盘点生态资产，把 20+ 小程序集成到到一个APP中

这一步的核心是"嵌 / 迁 / 管"三步到位，而不是一次性把所有小程序都重写。

嵌------在小程序不动代码的前提下，集成 FinClip SDK 到城市政务 APP，APP 变成一个能跑小程序的"宿主"。这一步代码量不大，但前置条件是每个委办局愿意把自己的小程序代码包开放给宿主平台。

iOS 侧的初始化：

import FinClip

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        FinAppClient.init(with: FinClipConfig.Builder()
            .appId("gov-app-id")
            .apiKey("gov-api-key")
            .apiServer("https://api-gov.example.com")
            .build())
        return true
    }
}

Android 侧的初始化：

import com.finogeeks.finclip.FinAppClient

class GovApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        FinAppClient.init(this, FinClipConfig.Builder()
            .setAppId("gov-app-id")
            .setApiKey("gov-api-key")
            .setApiServer("https://api-gov.example.com")
            .build()
        )
    }
}

迁------把已经在微信、支付宝上跑的小程序代码包迁到城市宿主上。FinClip 的兼容性是"微信小程序零修改"------同样的 WXML、JSON、JS 代码，不需要重写。但这一步要和每个委办局对齐，因为有些小程序用了微信特有的 API（例如 wx.login、wx.requestPayment），需要替换为 FinClip 通用 API（ft.login、ft.request）。

管------20+ 委办局小程序不可能手动管理，必须用 OpenAPI 自动化上传、审核、发布。CI/CD 流水线把每个委办局的小程序代码包和 OpenAPI 调用串起来：

# 上传卫健委小程序
curl -X POST "https://api-gov.example.com/v1/applets/upload" \
  -H "Authorization: Bearer $API_KEY" \
  -F "file=@./health-bureau-v1.2.0.zip" \
  -F "name=卫健委-出生证明" \
  -F "version=1.2.0"

// 管理后台的 OpenAPI 上传响应
{
  "applet_id": "65b8c0a8e4b09c0001a12345",
  "status": "pending_review",
  "submitted_at": "2026-06-08T10:23:45Z",
  "review_sla_hours": 24
}

完成这三步后，20+ 委办局小程序已经在城市宿主上跑通，市民打开一个 APP 就能搜到所有服务。但这一阶段只解决"集中入口"问题，AI 调度还没介入。

3.2 第二步：ChatKit 对话入口叠加在统一宿主之上

建生态完成后，下一步是叠加 ChatKit。ChatKit 是 FinClip 提供的对话式 AI 入口组件，可以理解为叠加在宿主 APP 之上的一个对话浮层（Floating UI），用户点击后唤起一个支持多轮对话的 ChatUI。

ChatKit 的核心模块包括：

• 意图识别：把市民的自然语言"我要办新生儿落户"拆解为可执行任务
• 多轮对话：补充信息（"宝宝是 2026 年 5 月出生的对吗？"）
• 会话授权卡（HITL）：敏感操作前弹出确认卡（"确认要提交出生证明申请吗？"）
• AGUI / MCP-UI：模型上下文 UI 协议，让 AI 生成动态 UI 控件
• LLM 可替换：底层大模型可切换（私有化部署 / 多模型）

ChatKit 的 JS 集成代码：

import { ChatKit } from '@finclip/chatkit';

// 唤起 ChatKit 对话浮层
ChatKit.open({
  mode: 'floating',              // 浮层模式
  entryPoint: 'auto',            // 自动出现在首页右下角
  userContext: {
    userId: 'citizen-310101198001011234',
    realName: '张三',
    district: '上海市浦东新区',
    isRealNameVerified: true
  },
  // 会话授权卡配置：哪些操作需要人工确认
  hitlConfig: {
    enabledOperations: [
      'submit_application',   // 提交申请必须确认
      'modify_personal_info', // 修改个人信息必须确认
      'payment'                // 支付必须确认
    ],
    confirmTimeout: 30           // 30 秒未确认自动取消
  },
  // 第三方小程序能力注册
  agentRegistry: 'https://api-gov.example.com/v1/agents',
  // LLM 配置（私有化部署）
  llmConfig: {
    provider: 'private',
    endpoint: 'https://llm-gov.internal/v1',
    model: 'gov-chat-70b'
  }
});

ChatKit 唤起后，市民的对话流程变成：

市民：我要办新生儿落户

ChatKit：好的，新生儿落户需要先办理出生医学证明。请问宝宝是在哪家医院出生的？（弹出医院选择 UI）

市民：复旦大学附属儿科医院

ChatKit：好的，已调取出生医学证明申请表单。请核对信息......（调起卫健委小程序）

......（自动调起 4 个委办局小程序，跨委办局联办）

ChatKit：所有材料已提交完成。是否确认提交？（HITL 会话授权卡）

市民：确认

ChatKit：已提交。3 个工作日内会有工作人员联系您。（生成审计日志）

3.3 第三步：注入上下文，让 AI 听懂弦外之音

没有上下文的 AI 助手只能机械应答。市民问"我家附近的幼儿园学位还剩多少"，没有上下文的 AI 不知道"我家"在哪、"附近"是几公里、"学位"指公立还是私立。上下文工程是 ChatKit 能不能"听懂弦外之音"的关键。

端侧信号采集：

// 端侧上下文采集
const contextCollector = {
  async collect() {
    return {
      // 时间上下文
      timestamp: new Date().toISOString(),
      timeOfDay: this.getTimeOfDay(),        // morning/afternoon/evening
      isWorkday: this.isWorkday(),            // 是否工作日

      // 位置上下文（需要用户授权）
      location: await this.getLocation(),    // {lat, lng, district}
      nearbyPOI: await this.getNearbyPOI(),   // 附近 POI 列表

      // 设备上下文
      device: {
        platform: ft.getSystemInfoSync().platform,
        networkType: ft.getNetworkType().networkType,  // wifi/4g/5g
        batteryLevel: ft.getBatteryInfoSync().level
      },

      // 历史上下文（来自本地缓存）
      recentQueries: ft.getStorageSync('recent_queries') || [],
      lastFormDraft: ft.getStorageSync('last_form_draft'),

      // 业务上下文（来自云脑短期记忆）
      sessionState: await ChatKit.getSessionState()
    };
  }
};

上下文工程是 ChatKit 与通用大模型的核心差异。通用大模型是"无状态"的------你问它一个问题，它就回你一个答案，不记得你三秒前说过什么。ChatKit 通过"短期记忆（当前会话） + 长期记忆（跨会话） + 端侧信号（实时环境）"三层上下文，让 AI 真正"听得懂"市民的弦外之音。

举个例子，市民晚上 8 点在浦东新区问"附近有什么 24 小时药店"，没有上下文的 AI 可能给一个全国连锁的药店列表；有上下文的 AI 知道"晚上 8 点""浦东新区""药店"，能直接给出"距离您 1.2 公里的海王星辰（已确认 24 小时营业）"。

3.4 第四步：云脑推理 + 端手执行

ChatKit 架构是"云脑 + 端手"协同------云脑做意图理解和任务编排，端手做上下文采集和执行沙箱。这两个角色分离的设计有两条核心原因：

• 数据出域问题：政务数据不能出域，敏感业务逻辑（医保结算、户籍修改）必须在本地完成。云脑做"理解"，端手做"执行"，敏感数据不离开端手。
• 性能问题：端侧（手机）有 90% 的上下文信息（时间、位置、设备、历史），把这些信息传到云端再做处理，既慢又不安全。端手先做一次过滤和脱敏，只把"AI 决策需要的最小信息"传到云脑。

云脑的核心是 Agent 注册中心------每个委办局的小程序注册为一个 Agent，云脑通过 Agent 的"能力清单"做意图路由：

{
  "agent_id": "health-bureau-birth-cert",
  "agent_name": "卫健委-出生医学证明",
  "version": "1.2.0",
  "capabilities": [
    {
      "intent": "apply_birth_certificate",
      "description": "办理新生儿出生医学证明",
      "required_inputs": [
        {"name": "hospital", "type": "string", "description": "出生医院"},
        {"name": "mother_id", "type": "id_card", "description": "母亲身份证号"},
        {"name": "baby_birth_time", "type": "datetime", "description": "宝宝出生时间"}
      ],
      "estimated_duration": "3 days"
    }
  ],
  // 端手调起参数
  "invocation": {
    "scheme": "finclip://applet/health-bureau-birth-cert",
    "params_mapping": {
      "hospital": "$.user_input.hospital",
      "mother_id": "$.user_context.id_card",
      "baby_birth_time": "$.user_input.baby_birth_time"
    }
  }
}

当市民说"我要办新生儿落户"，云脑做的事：

1. 意图识别：拆解为子任务（出生证明 + 户籍登记 + 医保参保 + 教育登记）
2. 能力路由：根据"出生证明"匹配到 health-bureau-birth-cert Agent
3. 参数补充：从会话上下文中提取"母亲身份证号""宝宝出生时间"
4. HITL 确认：弹出授权卡让市民确认
5. 端手执行：调起卫健委小程序，传入参数
6. 结果回收：小程序返回办理结果，云脑继续调度下一个 Agent（公安小程序办户籍）

3.5 第五步：三道闸门------治理层兜底

AI 调度小程序的能力如果不受限，后果比"点错按钮"严重得多。三道闸门是治理层的兜底机制：

入口闸（谁能看）：控制 AI 入口对哪些用户开放、对哪些功能可见。粒度到"功能"（Feature）级别。例如某市民没有房产，AI 入口就不显示"房产过户"相关功能。入口闸的实现靠"业务策略"------把每个委办局小程序的能力按用户身份/部门/场景打标签。

调用闸（能调什么）：控制 AI 能调哪些 Agent、能调多少次、能调多大金额、能调什么时段。粒度到"原语"（Primitive）级别。例如医保支付单笔超过 5000 元必须人工确认；非工作时间不能调"户籍修改"接口；同一 Agent 1 分钟内调用不超过 3 次。调用闸的实现靠"合规策略"------白名单、频控、额度、时段、人工确认。

审计闸（谁在何时做了什么）：记录每一次 AI 调用的"人 / 时 / 意图 / 上下文 / 路由 / 结果"，不可篡改，可回放追责。粒度到"事件"级别。审计闸的实现靠"安全策略"------所有调用轨迹写到不可篡改的审计存储（建议用区块链或专门的审计数据库）。

审计日志的存储结构：

{
  "audit_id": "evt-65b8c1f0e4b09c0001a67890",
  "timestamp": "2026-06-08T20:23:45.123Z",
  "user_id": "citizen-310101198001011234",
  "session_id": "session-uuid-xxxx",
  "intent": "apply_newborn_household_registration",
  "context": {
    "location": "上海市浦东新区",
    "time": "2026-06-08 20:23:45",
    "device": "iPhone 15 Pro"
  },
  "routing": [
    {
      "agent_id": "health-bureau-birth-cert",
      "invocation_time": "2026-06-08T20:24:12Z",
      "result": "success",
      "duration_ms": 27000
    },
    {
      "agent_id": "public-security-household",
      "invocation_time": "2026-06-08T20:25:03Z",
      "result": "hitl_pending",
      "hitl_card_id": "card-uuid-xxxx"
    }
  ],
  "hitl_confirmations": [
    {
      "operation": "submit_application",
      "confirmed_at": "2026-06-08T20:25:45Z",
      "confirmed_by": "citizen-310101198001011234"
    }
  ],
  "result": "pending_review"
}

3.6 真实效果数据

项目跑通后，我们对比了三类指标：

• 办件效率：新生儿落户从原来的"5 个小程序 5 天"压缩到"一句话 1 次提交"，平均办件时长从 5.2 天降到 0.8 天
• AI 调度准确率：意图识别准确率 87%（初期 60%，3 个月优化到 87%），跨委办局联办成功率 78%
• 用户活跃度：城市 APP 月活 +260%，20+ 委办局小程序访问量 +180%
• 开发成本：新接入一个委办局小程序的边际成本从原来的 4 周降到 1 周（嵌 / 迁 / 管三步走 + OpenAPI 自动化）
• 合规审计：100% AI 调用留痕，0 起合规事故

借用参考案例里某地区数字化 APP 的一组数据：从原有的 10 项政务服务扩展到涵盖衣食住行等 50+ 项日常服务，月活增长 260%，用户留存率提高 80%。我们的项目走的是同一条路------只是把"50+ 项服务"的数字做实到了 20+ 委办局，AI 调度这一层让办件效率从"5 天"压到了"1 次对话"。

---

感兴趣的话可以在Gitee上详细了解：Gitee 代码地址