如何用大模型设计一个国标级智能体从 prompt 到落地的完整指南上一篇我们介绍了 GB/Z 185 智能体互联标准的五大核心发现。这篇文章更进一步如果你正在使用大模型如 Kimi、Deepseek、通义千问等来设计或生成智能体如何确保它生来合规本文提供一份面向开发者和产品经理的实操指南让大模型从无师自通变成按标作业。一、为什么大模型需要学标准现状大模型设计智能体的常见缺陷今天很多开发者用大模型辅助生成智能体代码或架构。但大模型训练数据中GB/Z 1852026年5月才发布几乎是空白。因此如果你直接问它“帮我设计一个智能体”它可能会生成❌ 没有唯一身份标识只有自增ID或UUID❌ 功能描述随意写没有标准化的技能声明❌ 交互协议自定义无法与其他智能体对接❌ 工具调用硬编码没有动态发现和标准化流程❌ 安全设计缺失没有身份鉴别和权限边界这就好比让一位建筑师设计房子但他没学过建筑规范——房子能住但经不起验收。核心思路把标准教给大模型GB/Z 185 的本质是一套智能体的设计规范。你需要做的不是让大模型背诵标准全文而是把标准的关键约束结构化地写入 prompt让它在设计时自动遵循。本文要做的就是把这套标准翻译成**“大模型能听懂的设计语言”**。二、标准智能体的七大设计要素基于 GB/Z 185 系列一个标准智能体的设计必须覆盖以下七个要素。每个要素我们都给出标准要求 设计指引 Prompt 示例。要素一身份标识——给智能体一张数字身份证标准要求GB/Z 185.2 185.3每个智能体必须有智能体身份码OID 分层结构1.2.156.3088.版本.服务方.请求方.序列号身份凭证经数字签名的防篡改数据用于身份鉴别身份账户全生命周期管理注册、更新、锁定、注销设计指引在大模型设计阶段必须让智能体意识到它的身份不是自增的id123而是有全球唯一语义的身份码它出门社交时需要携带凭证并支持双向验证它的身份有生命周期状态激活/锁定/注销状态变化需要日志记录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: stringOID格式, 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智能体发现有两种方式基于发现服务通过 API/GUI/LUI 查询按自然语言描述、名称、身份码等条件匹配基于预置信息从本地缓存、用户配置、.well-known 地址获取设计指引设计智能体时必须同时考虑**“被发现的和发现者”**两种角色被发现的智能体需要发布自己的描述信息到发现服务支持被检索和匹配发现的智能体需要实现查询接口能够向发现服务发送条件请求解析返回的结果集进行符合性检查Prompt 设计示例你正在设计一个智能体的发现机制。请确保该智能体同时支持以下两种能力 【作为被发现的智能体】 1. 提供 publishToDiscoveryService() 方法将自身的 agentDescription 注册到智能体发现服务 2. 支持配置可被发现属性 discoverabletrue/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: stringMIME类型, 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解析 code0成功非0失败和 message 6. 判断任务是否完成 - 完成 → 结束流程 - 未完成 → 循环执行步骤1-5最多N次防止死循环 - 失败 → 根据错误码决定重试/换工具/返回错误 【错误处理】 - 工具调用失败时应记录失败原因 - 支持fallback机制首选工具失败后尝试备用工具 - 支持超时处理工具调用超过预设时间应返回超时状态 请输出完整的工具调用模块类图或接口定义并包含数据格式说明。Checklist是否实现了动态获取工具列表的能力工具缓存是否包含完整的输入/输出参数定义是否支持工具更新提醒和重新同步调用流程是否支持多轮循环直到任务完成是否包含错误处理和 fallback 机制是否包含超时处理要素六协作模式——让智能体会 teamwork标准要求GB/Z 185.6 附录B三种协作方式主从方式Master-Slave主智能体规划拆分任务分发子任务给从智能体汇总结果代理协商方式Broker-Negotiation代理智能体转发任务目标智能体评估自身能力后决定接受或交还任务订阅方式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 示例和架构建议供开发实践参考具体实现请结合业务需求调整。