在上一篇介绍智能体的“身份证号”--身份码的文章中，我们了解到，这智能体身份码的格式定义中，第7级为“智能体程序包的序列号标识”，第8级为“智能体实例的序列号标识”。

这里的“智能体程序包”和“智能体实例”，是我们对智能体产业做出的创新定义，将极大地促进个人智能体的快速发展。

今天这一篇，我们就来回答这个问题：什么是“智能体程序包“与“智能体实例”？

【先看PPT再看文章】

---

【问题】什么是“智能体程序包”与“智能体实例”？

【解答】

目前，我们所使用的智能体，绝大多数是以网页形式存在的云端智能体。例如刘老师现在几乎每天都用的写PPT的notebookLM智能体，其本质，就是一个运行在云端服务器上、通过网页形式访问的PPT制作智能体。这种web形式的云端智能体，可以理解为大家使用的都是一个智能体服务器端程序，只不过每个人的会话和上下文数据不同。

但是，随着智能体技术的发展和普及，将来会出现越来越多的端侧智能体和个性化智能体。我们一起来设想一个简单的场景：

• 一家智能体专业公司B公司，制作了一个很好用的个人助手智能体C。

• 这个个人助手智能体使用端侧大模型即可很好地完成用户意图识别，并通过智能体互联协议调用其他智能体协作完成用户交办的任务。

在与其他智能体协作时，这个个人助手智能体，需要使用自己的身份码向其他智能体表明身份。那么，一个新的问题就出现了：

• 两个不同用户的个人助手智能体C，怎么才能获取不同的智能体身份码以进行区分？

为了解决这一问题，我们创新性地提出了“智能体程序包”与“智能体实例”两个关键概念：

• 智能体程序包（agent program package）：实现特定功能，与智能体描述配套的可执行程序。

• 智能体实例（agent instance）：智能体程序包创建的、具有独立状态和生命周期的实体。

在《人工智能 智能体互联》第2部分 身份码中，这些概念和关系如下图所示：

• 智能体身份注册服务方，假定为一个提供智能体身份注册服务的A公司。

• 智能体身份注册请求方，假定为上面为我们提供智能体的B公司。

• 公司B，先为上面提到的智能体C的程序包申请智能体身份码，即将智能体C的能力描述文件和其他相关资料，提供给智能体身份注册服务方A公司。

• A公司对智能体C的相关资料进行审核并通过后，给智能体C的程序包分配一个智能体程序包身份码，例如：

  - 1.2.156.****.1.34C2.478BDF.0.1

  其中第7级的478BDF为智能体程序包C的序列号

  其中第8级的0代表这个智能体身份码对应的是一个智能体程序包。

• 在完成智能体程序包C的注册后，当一个用户要申请使用该智能体服务时，B公司在保障程序包一致性的前提下，基于该程序包为用户创建一个智能体实例，即某用户的个人助手智能体实例C1。

• B公司通过自动化程序，向A公司申请为智能体实例C1分配身份码。

• A公司在审核程序包与实例的一致性后，为智能体实例C1分配身份码，例如：

  - 1.2.156.****.1.34C2.478BDF.3GF546.1

  其中第7级的478BDF为智能体程序包C的序列号

  其中第8级的3GF546为智能体实例C1的序列号

• 如果又有一个用户向B公司申请一个新的个人助手智能体C2，基于上述过程，智能体实例C2将获得一个不一样的智能体身份码，例如：

  - 1.2.156.****.1.34C2.478BDF.3GF547.1

基于以上过程，智能体身份码的审核与发放，就可以实现以下目标：

• 智能体程序包的有序审核：对每个提供执行能力的智能体的来源，程序包，采用基于人工审核的严格审核方式（可以类比为网站备案），以确保安全与有序。

• 智能体实例的快速创建：基于OID的逐级责权利明确的管理体系，在进行智能体程序包的审核后，智能体实例可以通过自动化分配的方式快速获得身份码。

• 智能体实体的身份码唯一性：为将来海量的与个人或个人服务关联的智能体实体，提供了一套安全且高效的身份码唯一性分配方案。

需要特别说明的是，为了兼容唯一云端智能体服务和厂商智能体实现的差异性，身份码的申请和分配方式也保留了上图中，直接为智能体实例申请身份码的方式。

---

【往期回顾】

北邮ACPs协议和代码与智能体互联AIP标准的关系

AIP是MCP/A2A的替代品吗？

ACPs/AIP为什么还在用“落后”的“中心化”架构？

一个完整的智能体互联协作流程

身份码-智能体的身份证号

【点击关注不迷路】