如何用大模型设计一个"国标级"智能体：从 prompt 到落地的完整指南

上一篇我们介绍了 GB/Z 185 智能体互联标准的五大核心发现。这篇文章更进一步：如果你正在使用大模型（如 Kimi、Deepseek、通义千问等）来设计或生成智能体，如何确保它"生来合规"？ 本文提供一份面向开发者和产品经理的实操指南，让大模型从"无师自通"变成"按标作业"。

---

一、为什么大模型需要"学标准"？

现状：大模型设计智能体的常见缺陷

今天，很多开发者用大模型辅助生成智能体代码或架构。但大模型训练数据中，GB/Z 185（2026年5月才发布）几乎是空白。因此，如果你直接问它：“帮我设计一个智能体”，它可能会生成：

• ❌ 没有唯一身份标识，只有自增ID或UUID
• ❌ 功能描述随意写，没有标准化的技能声明
• ❌ 交互协议自定义，无法与其他智能体对接
• ❌ 工具调用硬编码，没有动态发现和标准化流程
• ❌ 安全设计缺失，没有身份鉴别和权限边界

这就好比让一位建筑师设计房子，但他没学过建筑规范——房子能住，但经不起验收。

核心思路：把标准"教"给大模型

GB/Z 185 的本质是一套智能体的设计规范。你需要做的，不是让大模型"背诵"标准全文，而是把标准的关键约束结构化地写入 prompt，让它在设计时自动遵循。

本文要做的，就是把这套标准翻译成**“大模型能听懂的设计语言”**。

---

二、标准智能体的七大设计要素

基于 GB/Z 185 系列，一个标准智能体的设计必须覆盖以下七个要素。每个要素，我们都给出：标准要求 + 设计指引 + Prompt 示例。

---

要素一：身份标识——给智能体一张"数字身份证"

标准要求（GB/Z 185.2 + 185.3）

每个智能体必须有：

• 智能体身份码：OID 分层结构（1.2.156.3088.版本.服务方.请求方.序列号）
• 身份凭证：经数字签名的防篡改数据，用于身份鉴别
• 身份账户：全生命周期管理（注册、更新、锁定、注销）

设计指引

在大模型设计阶段，必须让智能体"意识"到：

1. 它的身份不是自增的 id=123，而是有全球唯一语义的身份码
2. 它出门"社交"时，需要携带凭证并支持双向验证
3. 它的身份有生命周期状态（激活/锁定/注销），状态变化需要日志记录

Prompt 设计示例

你正在设计一个符合 GB/Z 185 标准的智能体。请确保该智能体具备以下身份能力：

1. 【身份码】：该智能体应有一个符合 OID 结构的身份码字段 agentId，格式参考 1.2.156.3088.x.x.x.x，在系统中全局唯一。
2. 【身份凭证】：该智能体应维护一个凭证对象 agentCredential，包含：
   - 凭证发行方签名
   - 有效期（issuedAt, expiresAt）
   - 关联的身份码
   - 委托方信息（如有）
3. 【生命周期状态】：该智能体应维护一个状态字段 identityStatus，取值为：active（激活）、locked（锁定）、revoked（注销），状态变更需记录审计日志。
4. 【双向鉴别】：该智能体应实现 authenticate(peerAgent) 方法，能够：
   - 向其他智能体出示自己的过程凭证包
   - 验证对方智能体的身份凭证（完整性、时效性、状态、委托链）
   - 返回鉴别断言（成功/失败/需进一步验证）

请在输出架构设计时，显式包含以上字段和方法，并给出数据类型定义。

Checklist

• 身份码字段是否采用 OID 结构？
• 是否有凭证对象及有效期管理？
• 是否支持身份状态（active/locked/revoked）？
• 是否实现了双向身份鉴别接口？
• 状态变更是否生成防篡改日志？

---

要素二：自我描述——让智能体会写"简历"

标准要求（GB/Z 185.4）

每个智能体必须提供标准化的描述信息，共14项属性，包括身份码、名称、版本、描述、提供方、访问地址、访问方法、服务区域、认证方式、辅助功能、默认输入/输出类型、技能列表。

技能列表中，每个技能包含8项属性：标识、名称、描述、标签、样例、输入类型、输出类型、运行依赖。

设计指引

让大模型设计智能体时，不要只写"功能列表"，而要输出一份结构化的机器可读简历。这决定了：

• 其他智能体能否"发现"你
• 其他智能体是否知道你能帮什么忙
• 协作时双方能否正确对接数据格式

Prompt 设计示例

你正在设计一个智能体的自我描述（Agent Description）。请按照 GB/Z 185.4 标准，输出以下 JSON 结构：

{
  "agentId": "string（OID格式）",
  "name": "string",
  "version": "string",
  "description": "string（用自然语言说明该智能体的用途和定位）",
  "provider": "string（开发或运营机构）",
  "accessAddress": "string",
  "accessMethod": ["URL", "IP", "FQDN"],
  "servingArea": { /* 服务地理区域描述 */ },
  "authentication": { /* 认证方式说明 */ },
  "capabilities": { /* 辅助功能：是否支持SSE、异步消息、状态查询等 */ },
  "defaultInputTypes": ["text", "image", "file"],
  "defaultOutputTypes": ["text", "json"],
  "skills": [
    {
      "skillId": "string（范围内唯一）",
      "skillName": "string",
      "skillDescription": "string",
      "tags": ["string数组"],
      "examples": ["string数组（输入输出样例）"],
      "inputTypes": ["text", "file"],
      "outputTypes": ["json"],
      "dependencies": [ /* 运行依赖：环境、配置、硬件等 */ ]
    }
  ]
}

要求：
- 技能描述必须包含至少1个典型输入/输出样例（examples）
- 输入/输出类型必须明确，不可写"多种格式"
- 如果某智能体没有某项技能，skills数组应为空，而非省略该字段

关键提示：大模型容易把技能描述写成"产品功能介绍"，你要提醒它：技能描述是给其他智能体看的"API文档"，不是给人类用户看的"营销文案"。必须包含输入/输出类型、样例、依赖——这些信息是机器对接时的关键参数。

Checklist

• 是否包含全部14项描述属性（含可选字段）？
• 技能列表中每个技能是否有输入/输出类型声明？
• 是否包含至少一个典型输入/输出样例？
• 访问地址和访问方法是否明确？
• 描述信息是否机器可读（结构化、非自然语言散文）？

---

要素三：发现机制——让智能体"找得到人"也"被人找到"

标准要求（GB/Z 185.5）

智能体发现有两种方式：

1. 基于发现服务：通过 API/GUI/LUI 查询，按自然语言描述、名称、身份码等条件匹配
2. 基于预置信息：从本地缓存、用户配置、.well-known 地址获取

设计指引

设计智能体时，必须同时考虑**“被发现的"和"发现者”**两种角色：

• 被发现的智能体：需要发布自己的描述信息到发现服务，支持被检索和匹配
• 发现的智能体：需要实现查询接口，能够向发现服务发送条件请求，解析返回的结果集，进行符合性检查

Prompt 设计示例

你正在设计一个智能体的发现机制。请确保该智能体同时支持以下两种能力：

【作为被发现的智能体】
1. 提供 publishToDiscoveryService() 方法，将自身的 agentDescription 注册到智能体发现服务
2. 支持配置可被发现属性 discoverable（true/false），当为 false 时不出现在查询结果中
3. 支持可用性配置（如付费、限定用户群），发现服务在返回结果时遵循这些配置

【作为发现者智能体】
1. 提供 discoverAgents(query) 方法，query 应支持：
   - 自然语言描述（如"能处理中文法律文档翻译的智能体"）
   - 精确匹配条件（如身份码、名称、服务区域）
   - 组合条件查询
2. 返回结果后，应实现 evaluateMatch(result) 方法，检查返回的智能体是否满足当前业务需求
3. 如果首次查询无结果，应支持修改查询条件后重新查询

请在架构设计中显式包含以上方法的接口定义和输入/输出格式。

Checklist

• 是否实现了向发现服务注册/发布描述的方法？
• 是否支持可被发现配置（discoverable）？
• 是否实现了查询发现服务的接口？
• 查询是否支持自然语言描述 + 精确条件组合？
• 返回结果后是否有符合性评估逻辑？

---

要素四：交互协议——让智能体"说同一种语言"

标准要求（GB/Z 185.6）

• 三种交互模式：点对点（必须支持）、群组（宜支持）、混合（宜支持）
• 四种内容元素：数据（Data）、消息（Message）、任务（Task）、会话（Session）
• 任务状态：任务接受、任务拒绝、任务进行中、任务完成、任务失败、任务取消、进度信息
• 消息结构：发送方角色、身份码、会话/任务标识、信息类型、数据载荷、分块索引等

设计指引

这是大模型最容易"自由发挥"的部分。很多开发者用大模型生成智能体时，交互协议往往是自定义的 JSON 格式，与标准不兼容。你需要在 prompt 中显式约束数据结构和字段命名。

Prompt 设计示例

你正在设计一个智能体的交互协议。必须严格遵循 GB/Z 185.6 的内容元素定义，输出以下数据结构：

【数据 Data】
{
  "type": "string（MIME类型）",
  "metadata": { /* 说明载荷结构 */ },
  "payload": { /* 数据内容 */ }
}

【消息 Message】
{
  "senderRole": "enum: requesterAgent | serviceAgent",
  "senderId": "string（智能体身份码）",
  "sessionId": "string",
  "taskId": "string（可选，若无从属任务则为空）",
  "id": "string（消息唯一标识）",
  "artifact": "enum: workCommunication | workProduct",
  "final": "boolean（是否最终成果）",
  "chunkIndex": "integer（消息分块索引）",
  "lastChunk": "boolean（是否最后一块）",
  "dataItems": [Data对象]
}

【任务 Task】
{
  "id": "string",
  "sessionId": "string",
  "state": "enum: accepted | rejected | inProgress | completed | failed | cancelled | progressInfo",
  "stateChangedAt": "ISO8601时间字符串",
  "messages": [Message对象],
  "artifacts": [Message或Task对象]  // 依赖信息
}

【会话 Session】
{
  "id": "string",
  "sender": { /* 请求智能体身份码+访问地址 */ },
  "receivers": [ /* 服务智能体信息列表，含交互模式（点对点/群组） */ ],
  "context": [Message或Task对象]  // 历史上下文
}

交互模式要求：
- 必须支持点对点交互（point-to-point）
- 宜支持群组交互（group），通过消息分发模块实现
- 宜支持混合交互（mixed）

请在架构设计中显式包含以上结构，并说明每种交互模式的实现方式（远程调用/流式/通知）。

关键提示：大模型容易遗漏任务状态机的设计。你要强调：任务不是"发送→接收"这么简单，而是有完整生命周期状态的。智能体必须正确处理任务接受、拒绝、失败、取消等边界情况。

Checklist

• 是否定义了标准的消息/任务/会话/数据结构？
• 任务是否包含完整状态机（接受/拒绝/进行中/完成/失败/取消/进度）？
• 是否支持消息分块传输（chunkIndex + lastChunk）？
• 是否支持点对点交互（必须）？
• 是否支持群组/混合交互（宜）？
• 会话是否管理历史上下文？

---

要素五：工具集成——让智能体"会用工具"

标准要求（GB/Z 185.7）

• 工具调用流程：获取工具列表 → 理解用户意图 → 选择工具 → 发送调用请求 → 工具执行 → 接收结果 → 判断任务完成（循环）
• 工具属性：工具标识符、名称、描述、版本、输入参数、输出参数
• 数据格式：工具请求、工具同步、工具更新、请求调用、返回结果，全部标准化 JSON

设计指引

大模型设计工具调用时，常见问题是：

• 硬编码工具，没有动态获取工具列表的能力
• 工具描述不完整，没有输入/输出参数定义
• 没有处理工具调用失败和重试的逻辑

标准要求智能体先查清单再调用，类似人类"先看说明书再操作"。

Prompt 设计示例

你正在设计一个智能体的工具调用模块。请确保该模块遵循 GB/Z 185.7 标准，实现以下流程：

【工具列表获取】
1. 提供 connectToToolService() 方法，与工具服务建立连接
2. 提供 requestToolList() 方法，向工具服务申请工具列表
3. 接收工具服务返回的 toolSyncList，解析并缓存为本地可用工具列表
4. 工具服务更新时，接收 toolUpdate 提醒并重新同步

【工具描述格式】
每个工具的本地缓存应包含：
{
  "toolId": "string（唯一标识）",
  "toolName": "string",
  "toolDescription": "string（功能简介）",
  "toolVersion": "string",
  "toolInputParam": { /* 参数名称、类型、描述、是否必填 */ },
  "toolOutputParam": { /* 参数名称、类型、描述 */ }
}

【工具调用流程】
1. 理解用户请求，分析任务和工具需求
2. 在本地工具列表中选择匹配的工具（可多选）
3. 构建 toolInvokeList，包含：toolId、toolVersion、toolInputParam
4. 发送调用请求，携带 sessionId 和 taskInfo
5. 接收 toolResultList，解析 code（0=成功，非0=失败）和 message
6. 判断任务是否完成：
   - 完成 → 结束流程
   - 未完成 → 循环执行步骤1-5（最多N次，防止死循环）
   - 失败 → 根据错误码决定重试/换工具/返回错误

【错误处理】
- 工具调用失败时，应记录失败原因
- 支持fallback机制：首选工具失败后，尝试备用工具
- 支持超时处理：工具调用超过预设时间应返回超时状态

请输出完整的工具调用模块类图或接口定义，并包含数据格式说明。

Checklist

• 是否实现了动态获取工具列表的能力？
• 工具缓存是否包含完整的输入/输出参数定义？
• 是否支持工具更新提醒和重新同步？
• 调用流程是否支持多轮循环（直到任务完成）？
• 是否包含错误处理和 fallback 机制？
• 是否包含超时处理？

---

要素六：协作模式——让智能体"会 teamwork"

标准要求（GB/Z 185.6 附录B）

三种协作方式：

1. 主从方式（Master-Slave）：主智能体规划拆分任务，分发子任务给从智能体，汇总结果
2. 代理协商方式（Broker-Negotiation）：代理智能体转发任务，目标智能体评估自身能力后决定接受或交还
3. 任务订阅方式（Event-Driven）：基于触发信号（时间、事件、地点）条件触发任务

设计指引

大模型设计多智能体协作时，容易把所有交互都设计成"一问一答"的点对点。标准告诉我们，要根据场景选择合适的协作模式。你需要在 prompt 中显式要求大模型选择并声明协作模式。

Prompt 设计示例

你正在设计一个多智能体协作场景。请根据任务特点，从以下三种协作模式中选择一种，并说明理由：

【模式一：主从方式（Master-Slave）】
适用场景：任务可以明确拆分为多个独立子任务，需要统一汇总结果。
要求：
- 主智能体实现 taskPlanning() 和 taskSplitting() 方法
- 支持并行分发（同时分发多个子任务）和异步分发（串行执行）
- 从智能体执行后返回子结果，主智能体实现 resultFusion() 汇总
- 输出格式：子任务列表 + 执行状态 + 汇总结果

【模式二：代理协商方式（Broker-Negotiation）】
适用场景：不确定哪个智能体最适合完成任务，需要动态协商。
要求：
- 代理智能体实现 taskForward(agent, task) 方法
- 目标智能体实现 capabilityEvaluation(task) 方法，返回 accept / reject
- 拒绝时，代理智能体选择下一个候选智能体
- 输出格式：候选列表 + 协商记录 + 最终执行结果

【模式三：任务订阅方式（Event-Driven）】
适用场景：任务需要在特定条件触发时自动执行（如定时、事件触发）。
要求：
- 智能体实现 triggerSubscription(signalSource, condition, task) 方法
- 支持信号源：时间（cron表达式）、事件（消息队列）、地点（地理围栏）
- 条件满足时自动触发任务分发
- 输出格式：订阅列表 + 触发日志 + 执行结果

请在你的设计中显式声明：
1. 选择了哪种协作模式？
2. 为什么选择该模式？（匹配业务场景）
3. 各角色的接口定义是什么？
4. 异常情况下（如从智能体失败、协商超时）的处理策略是什么？

Checklist

• 是否根据任务特点选择了合适的协作模式？
• 主从模式中是否支持并行和异步分发？
• 代理协商模式中是否有备选方案和超时处理？
• 任务订阅模式中是否支持多种触发信号源？
• 各角色接口定义是否清晰？
• 异常情况处理策略是否完备？

---

要素七：安全与合规——让智能体"守规矩"

标准要求（GB/Z 185.3 + 全系列安全要求）

• 身份鉴别：双向验证、信任链验证（追溯至国家认可CA根证书）、委托链验证
• 行为边界：用途声明、权限边界、操作目标、可访问资源、时空约束
• 日志审计：关键操作生成日志，防篡改
• 风险自适应：根据交互上下文动态调整凭证出示策略

设计指引

安全设计不能是"事后补丁"，必须内嵌在架构设计中。让大模型设计智能体时，把安全作为一等公民，而非可选模块。

Prompt 设计示例

你正在设计一个智能体的安全与合规模块。请确保以下安全要素内嵌在架构中，而非作为外部插件：

【身份鉴别安全】
1. 实现双向 authenticate(peer) 方法，验证流程必须包含：
   - 完整性验证：数字签名验证，追溯至可信根证书
   - 时效性验证：检查凭证有效期
   - 状态验证：检查凭证是否被锁定或注销
   - 受众验证：确认凭证预期接收方与当前交互方一致
   - 委托链验证：验证从委托方到智能体的授权链真实有效
2. 支持风险自适应：根据交易风险等级、对方历史交互记录、当前场景，动态调整验证严格程度

【行为边界声明】
该智能体应包含一个 behaviorBoundary 对象，显式声明：
- 用途（purpose）：该智能体的设计用途
- 权限边界（permissionScope）：可访问的资源、可执行的操作
- 操作目标（operationTargets）：允许操作的具体目标范围
- 时空约束（constraints）：时间范围、地理范围、网络环境等限制
- 禁止行为（prohibitedActions）：明确列出不允许的行为

【日志与审计】
1. 所有关键操作（身份注册、更新、锁定、注销、凭证发行、交互鉴权、工具调用）必须生成审计日志
2. 日志应包含：操作类型、时间戳、操作者身份、操作对象、结果、原因代码
3. 日志存储应采用防篡改技术（如哈希链、数字签名、区块链等）
4. 支持日志查询和导出，满足合规审计需求

【隐私与数据保护】
1. 智能体在处理数据时应遵循最小必要原则
2. 敏感数据（如个人隐私、商业秘密）传输应加密
3. 数据留存期限应可配置，超期自动清理

请在架构设计中显式包含 securityModule 的设计，包含以上所有字段、方法和策略。

Checklist

• 身份鉴别是否包含完整性/时效性/状态/受众/委托链五项验证？
• 是否包含行为边界声明（用途、权限、约束、禁止行为）？
• 关键操作是否生成防篡改审计日志？
• 是否支持风险自适应的凭证策略？
• 数据传输是否加密？
• 数据留存和清理策略是否明确？

---

三、完整 Prompt 模板：一键生成标准智能体

如果你不想分段提示，可以使用以下完整版 Prompt，一次性让大模型生成符合 GB/Z 185 标准的智能体设计：

你是一位资深智能体架构师，精通中国国家标准 GB/Z 185《人工智能 智能体互联》。请基于以下标准约束，设计一个完整的智能体架构。

【标准依据】
- GB/Z 185.1：总体架构（五域模型、功能参考架构、10个FRAI接口）
- GB/Z 185.2：身份码（OID分层结构：1.2.156.3088...）
- GB/Z 185.3：身份管理（注册、核验、账户管理、凭证管理、身份鉴别）
- GB/Z 185.4：智能体描述（14项属性 + 技能8项属性）
- GB/Z 185.5：智能体发现（基于发现服务 + 基于预置信息）
- GB/Z 185.6：智能体交互（点对点/群组/混合模式、数据/消息/任务/会话四层结构）
- GB/Z 185.7：智能体工具调用（获取列表→更新→调用→结果返回的标准流程）

【设计要求】
请设计一个智能体，名称为"[在此填入智能体名称]"，其核心功能为"[在此填入核心功能描述]"。

该智能体的架构设计必须包含以下模块，并输出为结构化文档：

1. 【身份模块】agentIdentityModule
   - 身份码结构（OID格式）、凭证对象、生命周期状态管理、双向鉴别方法

2. 【描述模块】agentDescriptionModule
   - 符合标准14项属性的完整描述JSON + 技能列表（每项含8项属性）

3. 【发现模块】agentDiscoveryModule
   - 发布到发现服务的方法 + 查询发现服务的方法 + 预置信息管理

4. 【交互模块】agentInteractionModule
   - 支持点对点/群组/混合三种模式 + 数据/消息/任务/会话数据结构 + 任务状态机

5. 【工具模块】agentToolModule
   - 工具列表获取与同步 + 工具调用循环 + 错误处理与fallback

6. 【协作模块】agentCollaborationModule
   - 选择并声明一种协作模式（主从/代理协商/任务订阅）+ 角色接口定义

7. 【安全模块】securityModule
   - 身份鉴别五项验证 + 行为边界声明 + 防篡改审计日志 + 风险自适应 + 数据加密

输出格式：
- 每个模块给出类/接口定义、核心字段、方法签名、数据类型
- 关键数据格式用 JSON 示例说明
- 给出模块间的关系图（可用文字描述或ASCII图）
- 最后附一份 "标准合规性检查清单"，逐条确认是否满足 GB/Z 185 要求

---

四、开发者自查清单（最终版）

使用大模型生成智能体设计后，请对照以下清单进行人工复核：

身份与凭证

• 身份码是否符合 OID 结构（1.2.156.3088…）？
• 凭证是否有数字签名和有效期？
• 是否支持身份状态管理和审计日志？
• 是否实现双向身份鉴别（含五项验证）？

描述与发现

• 描述是否包含14项标准属性（含技能列表）？
• 技能描述是否有输入/输出类型和样例？
• 是否支持发布到发现服务和被查询？
• 是否支持本地预置信息缓存？

交互与协作

• 是否定义标准的消息/任务/会话数据结构？
• 任务状态机是否完整（接受/拒绝/进行中/完成/失败/取消/进度）？
• 是否支持点对点交互（必须）？
• 是否声明了协作模式（主从/代理/订阅）？

工具调用

• 是否动态获取工具列表而非硬编码？
• 工具描述是否包含输入/输出参数定义？
• 是否支持调用失败的重试和fallback？
• 是否支持多轮调用直到任务完成？

安全合规

• 是否有行为边界声明？
• 关键操作是否有防篡改日志？
• 是否支持风险自适应凭证策略？
• 敏感数据传输是否加密？

---

五、结语：标准不是枷锁，而是通行证

有人可能会问：给大模型设计智能体加这么多"标准约束"，会不会限制创新？

恰恰相反。GB/Z 185 不是创新天花板，而是创新地板——它确保你设计的智能体能与其他智能体互联互通，而不是困在自己的孤岛上。

想象一下：

• 没有 HTTP 标准，就没有万维网的繁荣
• 没有 TCP/IP 标准，就没有互联网的互联互通
• 没有 USB 标准，就没有外设即插即用的便利

GB/Z 185 正在做同样的事情：为 AI 智能体世界制定**“通用连接器”**。当每个智能体都遵循这套标准，它们就能自由组合、协作、创新，形成真正强大的智能体生态。

而作为开发者的你，只需要做一件事：在 prompt 中把这七条规则"告诉"大模型，让它设计出来的智能体"生来合规"。

剩下的——让智能体们自己去协作、进化、创造吧。

---

延伸阅读

• 上篇：《中国发布智能体"互联互通"国家标准：你的AI助手终于能互相聊天了》
• 标准原文：GB/Z 185.1~185.7—2026《人工智能 智能体互联》
• 归口单位：全国信息技术标准化技术委员会（SAC/TC 28）

---

本文基于 GB/Z 185 系列标准梳理撰写，prompt 示例和架构建议供开发实践参考，具体实现请结合业务需求调整。