商汤大装置 × 上海规划资源局：量子城市首批政务智能体落地复盘

背景：城市治理场景的四条硬约束

城市治理是智能体落地难度偏高的一类场景，原因不在模型能力，而在场景本身自带四条硬约束。

• 结果不可回滚。防汛调度、规划审批这类动作一旦落到现实世界，撤销成本极高。这决定了智能体不能是「先做再改」的形态。
• 数据高度异构。现状、规划、权属、审批分属不同系统，格式从矢量、影像到扫描件不等，还要叠加时间维度——同一块地十年前和现在的规划可能完全不同。
• 专业判断密集。规划资源领域的结论往往依赖行业规范与专家经验，不是通用知识能覆盖的，模型必须先把行业知识吃进去。
• 责任主体明确。政务流程里每一步都有法定责任主体，智能体可以辅助但不能替代决策责任，这就要求人机边界在产品层面被显式设计出来。

官方对这一点的判断说得很直接：城市治理具有高度复杂的业务属性，智能体真正落地并非简单地将一个大模型接入业务系统，而是需要持续解决「业务问题如何定义、数据如何组织、知识如何沉淀、模型如何验证、效果如何迭代」等一系列问题。这句话其实已经把整个项目的方法论说完了——它是一个分五问推进的工程，而不是一个接 API 的集成。

先把基座升级成「能理解空间」的模型

「云宇星空大模型」由商汤大装置与上海市规划和自然资源局联合打造，定位为量子城市大模型体系的智能基座与智能中枢，是全国规划资源领域的行业基础模型。它汇聚规划建设与城市治理领域的行业知识、空间数据及业务规则，已形成 1.3 万对高质量问答和 15 亿 Token 语料，覆盖规划设计、测绘地理、自然资源等主要专业领域。

本次升级从两个维度展开，这两个维度对理解后续三个智能体的能力边界很关键。

• 知识能力维度：以 OLA（对象—关系—动作）为统一组织框架，推进语料、米料、数料的「三料联动」。语料沉淀政策法规、技术标准、业务流程与专家经验；米料以空间单元映射建筑、地块、道路等城市要素的位置与关系；数料整合现状、规划、监测、遥感等多源时空数据。通过统一对象编码、空间索引和时态关系，推动文字、图件、矢量、影像、视频、三维模型和实时感知数据相互关联。
• 推理能力维度：重点攻关调图、识图、读图、生图的「四图贯通」，打通从资料调用、空间识别、专业判断到成果生成的完整能力链，让模型不只「看到」图纸，更能理解空间关系。

这里值得单独拎出「米料」这个概念。常规行业大模型的语料组织以文本为主，而空间治理的核心信息其实是「谁在哪、和谁相邻、什么时候变成这样」。把它单列为一种和语料、数料并列的素材，等于承认空间关系是一类需要独立建模的知识，而不是可以从文本里顺带学到的东西。这是本项目在方法论上真正有增量的地方。

三个数字员工：防汛、洞察、规划更新

基于升级后的基座，上海市规划资源局集中发布了量子城市首批政务智能体，包括「禹智河洛」防汛智能体、「美好生活掌中宝」智能体、「沪派江南行」智能体等，其中三个由商汤大装置团队研发并交付。

智能体	职责	工作机制	公开效果
禹智河洛	防汛调度	综合运用天气、水位、排水流量数据，分区分时精准调度；48 小时乃至 2 小时提前研判、实时调度推演，实现「河网—管网—街区」调蓄空间的智能动态水平衡	苏州河流域场景：空间智算 +65%、动态模拟 +70%、智能调度 +80%
大略之眼	空间洞察	汇聚 18 年现状、规划、权属、审批等高质量时空数据，构建覆盖建、耕、林、水、湿全要素的数字孪生底图	过去需数月开发的数据分析指标，如今通过自然语言几分钟内定制
详规小工单	规划更新	面向存量时代城市更新管理需求，打造智能协同助手	企业需求一键智能导办、众创平台汇聚众智、规划底图一键速审

三个智能体的分工有一个共同特征：都嵌在已有业务流程里，而不是另起一个对话窗口。禹智河洛接的是防汛调度的既有决策链路，大略之眼接的是数据分析指标的定制流程，详规小工单接的是规划管理的工单流转。这一点看似平常，却是它能被称作「数字员工」而非「问答机器人」的原因——它替代的是流程中的某个环节，而不是在流程旁边加了一个新入口。

禹智河洛的设计细节最能说明问题。它的核心不是「预测会不会淹」，而是「把调度跑在风雨前」：通过 48 小时乃至 2 小时的提前研判与实时调度推演，在「河网—管网—街区」三级调蓄空间之间做动态水平衡。这是一个典型的多约束时序决策问题，也正是四图贯通与三料联动真正被调用的地方——它需要同时理解管网拓扑（空间关系）、降雨预报（时序数据）和调度规则（行业知识）。

量化结果与口径辨析

本案例公开的量化数据集中在禹智河洛上：在苏州河流域防汛安全场景应用中，空间智算、动态模拟、智能调度效率分别提升了 65%、70%、80%。大略之眼给出的是时间量级对比：过去需要数月开发的数据分析指标，如今通过自然语言即可在几分钟内快速定制。

指标	数值	口径说明	引用时应补充的信息
空间智算效率	提升 65%	苏州河流域防汛安全场景	基线方法、测量单位、样本时段均未披露
动态模拟效率	提升 70%	同上	同上；「效率」指耗时还是算力未说明
智能调度效率	提升 80%	同上	同上；与人工调度是否为同一约束条件未说明
指标定制周期	数月 → 几分钟	大略之眼，自然语言定制数据分析指标	「数月」为人力开发周期，「几分钟」为单次交互耗时，两者口径不同
语料规模	1.3 万对问答、15 亿 Token	云宇星空大模型基座	相对同规模行业模型属中等量级，专业深度优于广度

必须说清楚的是：这三组百分比是厂商与项目方自报的场景实测值，截至发稿未见第三方独立复现，也未披露基线方法、测量单位与样本时段。它们应当被读作「在该场景的既定对照下观测到的提升幅度」，而不是「防汛调度整体效率提升 65%–80%」。

「数月 → 几分钟」这组对比也需要分开看：前者是传统定制开发的端到端周期（含需求沟通、开发、测试、上线），后者是单次交互的生成耗时。两者的计量对象不同，直接相除得到的倍数没有意义。真正可比较的是「过去需要专门排期才能拿到一个指标」变成「业务人员当场就能拿到」——这是一种能力可获得性的变化，而非单纯的耗时压缩。

平台底座：模型路由、数据供给、任务执行、能力沉淀

三个智能体不是各自独立搭建的，它们共用一个贯通「模型调度—信息供给—任务执行—能力沉淀」端到端任务链路的通用平台能力底座。这套底座有四项能力值得记录，因为它们构成了可复制的部分。

• 统一模型服务与分层灵活调度。可根据任务复杂度，通过模型路由与任务拆解机制灵活调用不同模型及专业算法：高频查询、信息抽取、基础校验等由轻量模型快速处理；复杂空间推理、方案研判、任务规划等由核心大模型承接。这是一条非常务实的成本—能力折中，也是当前企业级智能体平台的通行做法。
• 数据与知识底座。以高质量时空数据为支撑，向智能体供给精准信息，解决「数据如何组织、知识如何沉淀」两个问题。
• 任务执行能力。以智能体开发运行平台为载体，把模型能力转换为可执行的动作序列，嵌入规划建设与城市治理业务全流程。
• 能力沉淀机制。把业务验证中产生的反馈回流，形成下一轮迭代的输入。

分层调度这一条尤其值得划重点。它对应的是本轮行业报告里反复出现的成本焦虑：不是所有步骤都值得用旗舰模型。把路由做成显式能力而不是隐式默认，是这类平台走向可治理的前提——因为只有先分层，才能谈每一层的预算与审计。

FDE 场景共创：一条可复现的五步闭环

本次项目在方法论上最值得借鉴的是 FDE（Forward Deployed Engineer，前置部署工程师）场景共创机制。商汤大装置依托这一机制，组织业务专家与研发团队深入业务一线，从真实业务需求出发，共同梳理业务流程、定义问题标准并验证应用效果，形成「问题定义—数据与知识准备—智能体开发—业务验证—反馈迭代」的闭环。

这个闭环与本站此前复盘过的多个企业级案例高度同构。瓴羊 AgentOne 在雅迪项目中用 24 天完成 78 场驻场调研，本质上是同一个动作：把工程师放到业务现场，让「问题定义」这一步不被远程沟通损耗。区别在于，本案例面对的是政务流程，业务专家本身就是规则的制定者，因此共创的产出同时包含流程梳理与标准定义。

六步打法与三条避坑红线

把上述内容抽象成可迁移的打法，可以得到六步：

• 步骤一：先问场景是否可核验。选那些有明确对错标准、结果可回溯的流程入手。防汛调度、规划底图审核都属于这一类；开放式政策咨询不属于。
• 步骤二：把行业知识做成独立的一层。不要指望通用模型顺带学会行业规则。云宇星空用 1.3 万对问答与 15 亿 Token 语料打底，并单列「米料」承载空间关系，是这一步的样板。
• 步骤三：把推理链路拆开验证。四图贯通（调图、识图、读图、生图）的意义在于每一环都可单独评估，出问题能定位到环，而不是整体返工。
• 步骤四：明确人机边界。哪些环节智能体可自主完成，哪些必须人工确认，要在产品设计阶段定死。政务场景尤其如此——责任主体是法定的，不能靠事后约定。
• 步骤五：做分层模型路由。高频低复杂度走轻量模型，复杂推理走核心模型，并把这一层做成显式可配置的能力。
• 步骤六：把业务验证接入迭代回路。FDE 共创的价值不在驻场本身，而在让业务方成为验证环节的一环，使反馈不必跨组织传递。

对应的三条避坑红线：

• 红线一：不要把「效率提升百分比」当成效果证明。本案例的 65% / 70% / 80% 缺乏基线方法与测量单位披露，属于自报场景值。内部立项时应自建对照：固定任务集、固定人工基线、记录耗时与准确率两个维度，只报一个维度必然失真。
• 红线二：不要在流程未改造前接智能体。行业调研显示仅约 5% 的组织认为业务流程已高度就绪。本案例能落地，前提是三个智能体对应的流程本身有明确的输入输出与责任节点；流程本身混乱的场景，接上智能体只会把混乱加速。
• 红线三：不要用「数字员工」模糊责任归属。「数字员工」是一个形象的说法，但它容易让人误以为责任可以一并转移。政务与准政务场景里，智能体的输出必须保留可追溯链路与人工确认点，尤其在涉及公共安全（如防汛调度）时更是如此。

局限与冷静判断

• 全部效果数据为项目方与厂商自报：65% / 70% / 80% 与「数月 → 分钟」均未见第三方独立复现，基线方法、测量单位、样本时段均未披露，引用时应标注口径。
• 场景范围有限：量化结果集中在苏州河流域一个防汛场景，能否推广到其它流域或其它城市治理场景，尚缺跨场景验证。
• 基座语料规模相对克制：1.3 万对高质量问答、15 亿 Token 语料在行业模型里属中等量级，说明其专业深度优先于广度；这对垂直场景是优势，对通用政务问答则可能是短板。
• 发布形态为「首批」：本次为量子城市首批政务智能体集中发布，属于阶段性成果而非终态，后续迭代节奏与稳定性尚待观察。
• 模型与算法细节未充分公开：云宇星空的具体参数规模、训练配置、以及四图贯通各环节的单独评测成绩均未披露，外部无法独立评估其能力边界。
• 涉及公共安全场景的容错边界未说明：防汛调度属于高后果场景，智能体建议与实际调度指令之间的权限关系、人工否决机制、误报处理流程均未在公开材料中说明，这是部署前必须补齐的信息。
• 数据来源口径需交叉：本文引用的量化数据来自科技日报、南方+、新民晚报与新浪财经等多家媒体，表述高度一致，说明信息同源度较高，独立信源数量有限。

综合来看，这是一个方法论价值高于数字价值的案例。65% / 70% / 80% 这三组数字在缺乏基线的情况下不宜作为选型依据；但 OLA 框架下的三料联动、四图贯通的可拆解验证链、FDE 五步闭环、以及分层模型路由这四项，是可以被其它行业直接借用的工程结构。对正在推进政务或准政务智能体的团队，真正值得抄的不是那三个百分比，而是「先做基座、再切流程、共创定义、分层路由」这条顺序。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。