ICS 35.240.01 CCS L 70 --- **DB32** **江苏省地方标准（征求意见稿）** 标准号：DB32/T XXXX—2026 --- # 政务服务智能体协同对接规范 ## Specification for interconnection and collaboration of government service agents （征求意见稿） 文件编号：SMART-SU/A2A 1.0 归口主张：江苏省政务数据管理机构 适用范围：江苏省政务服务领域智能体的建设、接入、对接与运营 --- 2026 - XX - XX 发布　　2026 - XX - XX 实施 --- ## 目次 - 前言 - 引言 - 1 范围 - 2 规范性引用文件 - 3 术语和定义 - 4 缩略语 - 5 总体架构与基本原则 - 6 智能体描述要求 - 7 输入（Input）要求 - 8 输出与渲染（Output）要求 - 9 任务状态（Task）要求 - 10 调用与交互流程要求 - 11 安全要求 - 12 符合性要求 - 13 版本管理与演进 - 14 互操作与生态兼容 - 15 可扩展性与能力协商 - 附录A（资料性）调用示例 - 附录B（规范性）任务状态机 - 附录C（资料性）渲染组件库 - 附录D（资料性）接口调用示例代码 - 参考文献 --- ## 前言 本文件按照 GB/T 1.1—2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。 本文件规定了政务服务领域智能体之间对接协同的输入、输出与任务状态三类核心要素，以及描述、调用、安全与符合性要求。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 本文件由江苏省政务数据管理机构提出并归口。 本文件起草单位：智慧晓苏项目组及相关协作单位。 本文件主要起草人：（略）。 本文件为首次发布。 本文件中的助动词按下列约定理解： - "应/应当"（shall）表示要求，即严格遵守才能符合本文件； - "不应/不得"（shall not）表示禁止； - "宜"（should）表示推荐； - "不宜"（should not）表示不推荐； - "可"（may）表示允许； - "能"（can）表示可能或能够。 --- ## 引言 政务服务智能化建设已由"物理集中""平台集约"进入"智能集成"阶段。各部门、各地区相继建设政务服务智能体，形成能力分散、接口各异、重复建设、难以协同的局面。 为支撑"一企来办"综合数智化服务与数字政府建设，需要在不限制各智能体内部技术实现（模型、检索、框架、算力等）的前提下，统一智能体之间"如何对接"的最小必要约定，使智能体能够被发现、被调用、被监督、被复用，并支持能力的持续演进与生态化协同。 本文件遵循"**对接标准统一、技术底座可演进**"的原则：仅规范智能体对外暴露的**输入（Input）、输出（Output）、任务状态（Task）**三类要素及其安全与符合性要求，不规定智能体的内部实现路线，以保证标准的**切实可行**与**可扩展**。 本文件**对齐国家标准体系**：遵循 GB/Z 185《人工智能 智能体互联》系列（智能体互联协议 AIP）确立的总体架构与智能体描述、发现、交互、工具调用框架，落实《数字政府 智能政务 第2部分：政务服务智能体建设规范》对政务服务智能体的总体要求，并衔接《智能体规范应用与创新发展实施意见》关于标准体系、注册发现、分类分级治理与安全可信的要求。本文件定位为上述国家标准与政策在江苏省"问、查、办、评"政务服务场景下的**落地细化与对接约定**，与之保持兼容、向其对齐，不替代国家标准原文。 本文件**对齐国家标准体系**：遵循 GB/Z 185《人工智能 智能体互联》系列（智能体互联协议 AIP）确立的总体架构与智能体描述、发现、交互、工具调用框架，落实《数字政府 智能政务 第2部分：政务服务智能体建设规范》对政务服务智能体的总体要求，并衔接《智能体规范应用与创新发展实施意见》关于标准体系、注册发现、分类分级治理与安全可信的要求。本文件定位为上述国家标准与政策在江苏省"问、查、办、评"政务服务场景下的**落地细化与对接约定**，与之保持兼容、向其对齐，不替代国家标准原文。 --- ## 1 范围 本文件规定了政务服务智能体协同对接的总体架构与基本原则、智能体描述要求、输入要求、输出与渲染要求、任务状态要求、调用与交互流程要求、安全要求、符合性要求以及版本管理与演进要求。 本文件适用于江苏省政务服务领域智能体（含政务服务、企业服务、12345 等场景）的设计、开发、接入、对接、测评与运营，可供省级统一平台、各厅局、各设区市及第三方服务机构参照执行。 本文件不规定智能体内部使用的大模型、检索算法、编排框架、运行算力等技术实现方式。 ## 2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 - GB/T 1.1—2020 标准化工作导则 第1部分：标准化文件的结构和起草规则 - GB/Z 185.1-2026 人工智能 智能体互联 第1部分：总体架构 - GB/Z 185.2-2026 人工智能 智能体互联 第2部分：身份码 - GB/Z 185.3-2026 人工智能 智能体互联 第3部分：身份管理 - GB/Z 185.4-2026 人工智能 智能体互联 第4部分：智能体描述 - GB/Z 185.5-2026 人工智能 智能体互联 第5部分：智能体发现 - GB/Z 185.6-2026 人工智能 智能体互联 第6部分：智能体交互 - GB/Z 185.7-2026 人工智能 智能体互联 第7部分：智能体工具调用 - 数字政府 智能政务 第2部分：政务服务智能体建设规范（制定中，国务院办公厅主管，TC594 归口） - GB/T 2260 中华人民共和国行政区划代码 - GB/T 25069 信息安全技术 术语 - GB/T 35273 信息安全技术 个人信息安全规范 - GB/T 22239 信息安全技术 网络安全等级保护基本要求 - GB/T 36478（所有部分）物联网 信息交换和共享（接口与数据约定参照） - RFC 2119 Key words for use in RFCs to Indicate Requirement Levels（助动词分级参照） - RFC 8259 The JavaScript Object Notation (JSON) Data Interchange Format ## 3 术语和定义 下列术语和定义适用于本文件。 **3.1 智能体 agent** 能够理解意图、调用能力、自主或按流程完成政务服务任务，并对外提供可对接接口的软件实体。 **3.2 政务服务智能体 government service agent** 面向政务服务、企业服务及诉求受理等场景，提供咨询、查询、办理、评价等能力的智能体。 **3.3 协同对接 interconnection and collaboration** 不同智能体之间，按统一约定交换输入、输出与任务状态，以接力完成跨部门、跨层级服务的过程。 **3.4 输入 input** 调用方向被调用智能体传入的、用于表达意图与参数的结构化数据。 **3.5 输出 output** 被调用智能体返回的、包含回复内容、渲染单元、可执行动作与依据引用的结构化数据。 **3.6 任务状态 task state** 异步任务在其生命周期中所处的阶段及其可查询的中间态信息。 **3.7 渲染单元 render unit** 由预设模板生成、用于前端展示的结构化展示对象，如表单、卡片、选项、表格、进度等。 **3.8 符合性 conformance** 被测对象满足本文件相应条款要求的程度。 **3.9 统一受理 unified acceptance** 事项业务由统一平台受理办理的模式，是"边问边办"得以落地的前提条件。 ## 4 缩略语 下列缩略语适用于本文件。 - AIP：智能体互联协议（Agent Interconnection Protocol，见 GB/Z 185） - A2A：智能体到智能体（Agent to Agent） - API：应用程序编程接口（Application Programming Interface） - JSON：JavaScript 对象表示法（JavaScript Object Notation） - MCP：模型上下文协议/工具调用协议（Model Context Protocol） - RAG：检索增强生成（Retrieval-Augmented Generation） - SSE：服务器发送事件（Server-Sent Events） - SSO：单点登录（Single Sign-On） ## 5 总体架构与基本原则 ### 5.1 总体架构 政务服务智能体协同对接的总体架构由调用方、被调用智能体、统一目录与统一网关组成。智能体经统一目录注册后被发现，经统一网关按本文件约定完成调用与状态查询。 ### 5.2 基本原则 5.2.1 标准统一原则。智能体之间的对接**应**遵循统一的输入、输出与任务状态约定。 5.2.2 技术中立原则。本文件**不应**限制智能体内部所采用的模型、算法、框架与算力；符合本文件的智能体**可**自由选择并演进其内部实现。 5.2.3 可发现可监督原则。接入的智能体**应**在统一目录注册其描述信息，**应**支持调用留痕与审计。 5.2.4 可演进原则。本文件**应**支持向后兼容的能力扩展；扩展项**应**显式声明并公示（见第 13 章）。 5.2.5 安全合规原则。对接过程**应**满足数据安全、个人信息保护与网络安全等级保护的相关要求（见第 11 章）。 5.2.6 务实落地原则。"边问边办"类办理能力**应**优先在统一受理事项上实现。 5.2.7 互操作优先原则。对接面**应**优先复用成熟的开放规范（见第 14 章），**不宜**自创与既有生态不可映射的私有约定。 ## 6 智能体描述要求 6.1 接入的智能体**应**提供机器可读的描述信息（智能体描述符），并在统一目录注册。 6.2 智能体描述符**应**符合本文件配套的 JSON Schema（见 `api/a2a/a2a-agent.schema.json`），且**应**至少包含下列字段： - 标识（id）：全局唯一； - 名称（name）； - 归属部门（department）； - 版本（version）； - 形态（type）：取值为 `qa`（问答机）、`workflow`（工作流）、`agent`（智能体）之一； - 能力标签（capabilities）。 6.3 智能体描述符**宜**包含调用入口（endpoint）与鉴权方式（auth）。 6.4 智能体形态划分**应**符合下列约定： - a）问答机：一次输入对应一次输出，无外部数据交互； - b）工作流：具有意图识别与分流，按既定流程完成确定目标； - c）智能体：可对给定目标进行自主规划，由平台提供原子能力并由其自行组合。 6.5 仅嵌入于业务系统内部工作流、无法独立对外暴露三要素接口的能力，**不宜**作为可集约对接的智能体登记；对话式、可独立调用的智能体**应**优先纳入对接。 ## 7 输入（Input）要求 7.1 输入**应**为符合 RFC 8259 的 JSON 对象。 7.2 输入**应**包含意图字段（intent），用于表达用户诉求文本。 7.3 输入**宜**包含下列字段： - 用户上下文（user）：包含已脱敏且在授权范围内的用户标识、属地（按 GB/T 2260）、主体类型（个人/企业）； - 会话标识（session_id）：用于支持多轮交互； - 结构化参数（params）：由表单或上一轮交互收集所得； - 附件（attachments）：图片、音频、文件等多模态输入的引用。 7.4 输入中涉及个人信息的字段，**应**遵循 GB/T 35273 的最小必要与授权要求；**不应**在输入中明文传输敏感个人信息。 7.5 调用方**应**保证输入字段的命名与类型符合配套 JSON Schema。 ## 8 输出与渲染（Output）要求 8.1 输出**应**为符合 RFC 8259 的 JSON 对象，并**应**包含状态（status）与回复消息（messages）。 8.2 输出状态（status）**应**取下列值之一： - `succeeded`：本次处理完成； - `need_input`：需调用方补充信息后继续； - `running`：异步处理中，**应**同时返回任务标识（task_id）； - `failed`：处理失败，**宜**给出错误说明。 8.3 输出**宜**包含下列字段： - 渲染单元（render）：见 8.4； - 可执行动作（actions）：如提交、跳转、转人工； - 依据引用（citations）：见 8.5。 8.4 渲染单元要求： - 8.4.1 渲染单元**应**由预设模板生成，**不应**由模型实时无约束生成，以保证字段完整性与校验有效性。 - 8.4.2 渲染单元类型（component）**应**取下列值之一：`form`（表单）、`card`（卡片）、`options`（选项）、`table`（表格）、`progress`（进度）。 - 8.4.3 当渲染单元为表单时，**应**给出字段定义；明确取值的字段**应**采用 `select`/`radio`/`checkbox` 等形式提供选项，**不宜**要求用户以长文本自由描述明确字段。 - 8.4.4 表单字段**应**声明类型与必填性；涉及格式约束的字段**应**给出校验规则（validation）。 8.5 依据引用要求： - 8.5.1 涉及政策、办理条件、办事指南的回复，**应**给出依据引用，并**应**可溯源。 - 8.5.2 依据引用**宜**包含发布部门（source）、链接（url）与生效日期（effective_date）。 8.6 输出内容**应**满足可评价、可追溯、可修正的要求；同一确定性问题在数据未变更时，**不应**出现不一致的结论。 ## 9 任务状态（Task）要求 9.1 异步任务**应**返回任务标识（task_id），并**应**提供按任务标识查询状态的能力。 9.2 任务状态（state）**应**符合附录B 规定的状态机，取下列值之一：`pending`、`running`、`need_input`、`succeeded`、`failed`、`cancelled`。 9.3 任务状态信息**宜**包含进度（progress，取值 0 至 1）、更新时间（updated_at）与结果引用（result_ref）。 9.4 任务失败时，**应**返回错误码（code）与错误说明（message）。 ## 10 调用与交互流程要求 10.1 调用**应**通过统一网关进行，并**应**经过身份认证与授权。 10.2 同步调用在处理完成后**应**直接返回输出；异步调用**应**先返回 `running` 状态与任务标识，由调用方按 9.1 查询结果。 10.3 当被调用智能体返回 `need_input` 时，调用方**应**根据渲染单元收集信息后再次调用，形成"边问边办、边办边问"的多轮交互。 10.4 跨部门事项**宜**由多个智能体按本文件接力完成，并**应**保持任务标识在接力过程中的可追溯性。 10.5 长文本回复**宜**采用 SSE 等流式方式返回，以改善交互体验。 ## 11 安全要求 11.1 对接**应**符合 GB/T 22239 网络安全等级保护的相应级别要求。 11.2 涉及个人信息的处理**应**符合 GB/T 35273 的要求，遵循最小必要、授权同意与脱敏原则。 11.3 调用**应**采用传输层加密；鉴权方式**宜**采用政务统一身份认证（gov-sso）或等效机制。 11.4 调用与办理动作**应**全链路留痕，**应**支持审计。 11.5 敏感数据处理**应**限定在合规边界内；涉及不出域要求的数据，**不应**经由公有侧能力处理。 11.6 智能体**应**具备降级能力；当依赖的模型或外部能力不可用时，**宜**降级为基于知识的直接答复或兜底应答。 11.7 分类分级治理。智能体**应**按应用场景与潜在影响实施分类分级治理；敏感领域及重点事项**应**按主管部门要求实行备案、检测与问题召回；低风险场景**可**采用合规自测与信息报告（对齐《智能体规范应用与创新发展实施意见》）。 11.8 决策权限边界。智能体**应**厘清"仅用户本人决策、用户授权决策、智能体自主决策"的边界；用户对自主决策**应**享有知情权与最终决策权；智能体执行**不应**超出用户授权范围。 11.9 可验证可追溯。重要事项的智能体行为**应**可验证、可追溯；决策依据、调用链路与办理动作**应**留痕，**宜**采用防篡改机制保障审计证据完整。 ## 12 符合性要求 12.1 符合性分级。符合性**应**按下列等级评定： - a）基础级（L1）：满足第 6、7、8、9 章中全部"应"的要求； - b）增强级（L2）：在 L1 基础上，满足全部"宜"的要求，并通过附录A 的交互示例验证； - c）协同级（L3）：在 L2 基础上，支持跨智能体接力（10.4）与统一审计（11.4）。 12.2 声称符合本文件的智能体，**应**通过配套 JSON Schema 校验，并**应**通过符合性测试（见《政务服务智能体协同对接符合性测试规范》）。 12.3 符合性测试**宜**借助统一的在线校验服务进行（见标准门户的在线校验功能）。 ## 13 版本管理与演进 13.1 本文件采用语义化版本（主版本.次版本.修订版本）管理。 13.2 向后兼容的能力扩展**应**通过增加可选字段或新增渲染单元类型实现，并**应**递增次版本号。 13.3 不兼容变更**应**递增主版本号，并**应**提供迁移说明与过渡期。 13.4 实现方在使用本文件未定义的交互或字段时，**应**显式声明（自定义命名空间），并**应**向标准维护方公示，以纳入后续版本评估。 13.5 标准维护**宜**以"政务智能体联盟"机制开展，吸纳各单位与厂商共同演进。 --- ## 14 互操作与生态兼容 14.1 本文件遵循"对接标准统一、技术底座可演进"。对接面**应**与下列开放规范保持兼容或可映射，以降低集成成本、避免重复建设： - a）接口风格：服务调用**宜**采用 RESTful 风格，并**可**由 OpenAPI 描述； - b）数据契约：输入、输出、任务状态的数据结构**应**以 JSON Schema（Draft 2020-12 或兼容版本）表达，并提供机器可读文件； - c）能力暴露：厅局能力**可**经 MCP（模型上下文协议）、Tool/函数调用等机制暴露，并**应**统一以本文件三要素（输入/输出/任务状态）封装对接； - d）智能体协作：本文件与业界"智能体到智能体（A2A）"协作理念一致，**宜**在能力发现、任务委派、状态回传等概念上保持互认，便于跨部门、跨厂商接力； - e）模型接入：底层大模型**不应**被本文件绑定；模型服务**宜**采用 OpenAI 兼容等通用接口，支持多模型中立路由与故障切换。 14.2 身份与鉴权**应**兼容政务统一身份认证（SSO）与 OAuth2/OIDC；跨域调用**应**支持令牌传递与最小授权。 14.3 对接双方**应**就基础约定保持一致：字符编码采用 UTF-8、时间采用 ISO 8601、行政区划采用 GB/T 2260、货币与计量采用法定单位。 14.4 标准的机器可读制品（JSON Schema、示例、描述符模板）**应**对外发布并版本化，供各方在线校验与代码生成；**宜**提供统一的在线校验服务。 14.5 与国家标准的对应关系。本文件三要素与 GB/Z 185《人工智能 智能体互联》(AIP) 系列对应如下，实现方**应**保持可映射、可衔接： | 本文件 | 对应 GB/Z 185 部分 | |---|---| | 总体架构（第 5 章） | 185.1 总体架构 | | 标识与鉴权（11.2~11.3、14.2） | 185.2 身份码 / 185.3 身份管理 | | 智能体描述符（第 6 章） | 185.4 智能体描述 | | 统一目录与发现（5.1、6.x） | 185.5 智能体发现 | | 输入 / 输出 / 任务状态（第 7~9 章） | 185.6 智能体交互 | | 工具 / MCP 调用（8.x、14.1 c） | 185.7 智能体工具调用 | 14.6 本文件的 `need_input` 状态与业界 A2A 实践的 `input-required` 语义等价；智能体描述符与 A2A 的"代理卡片（Agent Card）"概念互认，**宜**支持经约定的 well-known 路径发布，以便统一目录的自动发现。 ## 15 可扩展性与能力协商 15.1 能力声明。智能体**应**在描述符中声明自身形态、能力标签及所支持的渲染组件；调用方**应**据此进行能力发现与适配。 15.2 能力协商。当调用方与被调用方能力不一致时，双方**宜**按"取交集、可降级"原则协商；被调用方对其不支持的可选字段**应**安全忽略，并**不应**因此报错失败。 15.3 扩展机制。实现方新增本文件未定义的字段、渲染组件或交互时，**应**使用自定义命名空间（建议形如 `x-<机构>-<名称>`）以避免冲突，并**应**向标准维护方公示。 15.4 版本协商。调用**宜**携带所遵循的 `spec_version`；被调用方**应**兼容同一主版本内的全部次版本，遇更高次版本引入的未知可选字段**应**安全忽略（向前兼容）。 15.5 向后兼容。新增能力**应**以可选字段或新增枚举值实现，**不应**改变既有字段的语义；破坏性变更**应**递增主版本号，并提供迁移期与新旧映射说明。 15.6 演进治理。标准**宜**以"政务智能体联盟"机制收集扩展诉求、组织评审并纳入后续版本，形成"声明 → 公示 → 评审 → 合并"的可持续演进闭环。 ## 附录A（资料性）调用示例 A.1 "出生一件事"调用示例见 `api/a2a/examples/birth-one-thing.json`。该示例演示了 `need_input` 状态下，被调用智能体以表单渲染单元收集"随父姓/随母姓"等明确字段（采用 `radio` 选项而非自由文本），并附办事指南依据引用。 A.2 典型多轮交互（边问边办）： - a）调用方传入意图 → 被调用方返回 `need_input` 与表单； - b）调用方按表单收集并校验后再次调用 → 被调用方返回 `succeeded` 与办理结果及引用。 ## 附录B（规范性）任务状态机 B.1 任务状态的迁移**应**符合下列规则： ``` pending ──→ running ──→ succeeded │ │ │ │ │ └────→ need_input ──→ running │ └───────→ failed └───────────────────→ cancelled ``` B.2 状态迁移约束： - `pending` 可迁移至 `running` 或 `cancelled`； - `running` 可迁移至 `succeeded`、`failed` 或 `need_input`； - `need_input` 在补充输入后**应**迁移回 `running`； - `succeeded`、`failed`、`cancelled` 为终态，**不应**再迁出。 ## 附录C（资料性）渲染组件库 | 组件（component） | 用途 | 关键属性 | |---|---|---| | form | 信息采集表单 | fields（含 type、required、options、validation） | | card | 信息卡片/办理结果 | title、内容字段 | | options | 单选/多选引导 | 选项列表 | | table | 列表/明细 | 列定义与行数据 | | progress | 办理进度/任务进度 | 状态、百分比 | --- ## 附录D（资料性）接口调用示例代码 D.1 发起调用（智能体返回 `need_input` 状态与结构化表单）： ```bash curl -X POST https://a2a.wattad.cn/api/a2a/invoke \ -H "Content-Type: application/json" \ -d '{"agent_id":"jsweijian.birth-one-thing","input":{"intent":"我要给宝宝办出生一件事"}}' ``` D.2 按表单补充信息后提交（返回 `succeeded` 状态与办理结果及可溯源依据）： ```python import requests done = requests.post("https://a2a.wattad.cn/api/a2a/invoke", json={ "agent_id": "jsweijian.birth-one-thing", "input": {"intent": "提交出生一件事", "params": { "baby_name": "张小苏", "surname_follow": "随父姓", "birth_date": "2026-06-01", "hospital": "南京市妇幼保健院", "mother_idcard": "3201**********0028"}}}).json() print(done["status"], done["result"], done["citations"]) ``` D.3 符合性在线校验（校验 输入/输出/任务状态/描述符 是否符合本文件）： ```javascript const r = await fetch("https://a2a.wattad.cn/api/validate", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ target: "input", payload: { intent: "办理社保参保" } }) }); console.log(await r.json()); // { valid: true, target: "input", errors: [] } ``` 注：可在标准门户"接入示例"页（`/playground.html`）进行在线交互演示与代码复制。 ## 参考文献 [1] GB/T 1.1—2020 标准化工作导则 第1部分：标准化文件的结构和起草规则 [2] GB/T 2260 中华人民共和国行政区划代码 [3] GB/T 35273 信息安全技术 个人信息安全规范 [4] GB/T 22239 信息安全技术 网络安全等级保护基本要求 [5] RFC 2119 / RFC 8174 规范性助动词 [6] RFC 8259 JSON 数据交换格式 [7] 国务院办公厅 关于全国一体化政务服务平台建设的有关文件