第一步：对信息模型既GDMO文件和ASN.1文件的理解，信息模型是TMN系统开发的基础和关键。特别是对信息模型中对象类和其中各种属性清晰的认识和理解，对于实际的TMN系统来说，其信息模型可能很复杂，其中对象类在数量上可能很多。也就是说，在设计和实现agent之前，必须作到对MO心中有数。

　　第二步：被管对象MO的定制。这一部分是agent设计和实现中的关键部分，工具对这方面的支持也不是很多，特别是涉及到MO与MR之间的通信，更为复杂，故将MO专门作为一个模块进行设计和实现MO和MR之间的通信以及数据和消息格式的转换问题，利用网关原理设计一个网关来解决。

　　第三步：创建内置的M0。所谓内置MO就是指在系统运行时，已经存在的物理实体的抽象。为了保证能对这些物理实体进行管理，必须将这些被管对象的各种固有的属性值和操作预先加以定义。

　　第四步：创建外部服务访问点SAP。如前所述，TMN系统中各个基于分布式处理的worker之间通过SAP进行通信，所以要为agent与管理者manager之间、agent与网关之间创建SAP。

　　第五步：SAP同内置MO的捆绑注册。由于在TMN系统中，agent的所有操作是针对MO的，即所有的CMIP请求经解析后必须送到相应的M0，而基于DSG平台的worker之间的通信是通过SAP来实现的。因而，在系统处理过程中，当进行信息的传输时，必须知道相应MO的SAP，所以，在agent的设计过程中，必须为内置MO注册某一个SAP。

　　第六步：agent配置。对agent中有些参数必须加以配置和说明。如队列长度、流量控制门限值、agent处理单元组中worker的最大/最小数目。报告的处理方式、同步通信方式中超时门限等。

　　第七步：agent用户函数的编写，如agentworker初始化函数、子代理函数等的编写。

　　第八步：将所有函数编译，连接生成可运行的agent。

　　MO模块是agent设计中的一个重要而又复杂的部分。这是由于，一方面工具对该部分的支持不是很多：另一方面，用户的大部分处理函数位于这一部分;最主要的还在于它与被管资源要跨平台，在不同的环境下进行通信。MO模块的设计思想是在MO和MR之间设计一个网关(gateway)，来实现两者之间的消息、数据、协议等转换。

　　MO部分的主要功能是解析，执行来自管理者的CMIP请求，维持各MO的属性值同被管资源的一致性，生成CMIP请求结果，并上报通用agent模块，同时与MR通信，接收和处理来自MR的事件报告信息，并转发给通用agent。

　　MO部分有大量的用户定制工作。工具只能完成其中一半的工作，而另一半工作都需要用户自己去定制。用户定制分为两大类;

　　第一类是PRE-/POST-函数。PRE-/POST-函数的主要功能是在agent正式处理CMIP请求之前/之后与被管资源打交道，传送数据到MR或从MR获取数据并做一些简单的处理。通过对这些PRE-/POST-函数的执行，可以确保代理能够真实地反映出被管资源的运行状态。PRE-/POST-函数分为两个层次：MO级别和属性级别。MO级别层次较高，所有对该对象类的CMIP操作都会调用MO级别的PRE-/POST-函数。属性级别层次低，只有对该属性的CMIP操作才会调用这些函数。DSET工具只提供了PRE-/POST-函数的人口参数和返回值，具体的代码需要完全由用户自己编写。由于agent与被管资源有两种不同的通信方式，不同的方式会导致不同的编程结构和运行效率，如果是同步方式，编程较为简单，但会阻塞被管资源，适合于由大量数据返回的情况。异步方式不会阻塞被管资源，但编程需要作特殊处理，根据不同的返回值做不同的处理，适合于数据不多的情况，在选择通信方式时还要根据MO的实现方式来确定。比如，MO若采用Doer来实现，则只能用同步方式。

　　第二类是动作、事件报告和通知的处理，动作的处理相对比较容易，只需考虑其通信方式采用同步还是异步方式。对事件报告和通知的处理比较复杂。首先，需要对事件进行分类，对不同类别的事件采用不同的处理方法，由哪一个事件前向鉴别器EFD(EventForwardingDiscriminator)来处理等等。比如，告警事件的处理就可以单独成为一类。其次，对每一类事件需要确定相应的EFD的条件是什么，哪些需要上报管理应用，哪些不需要。是否需要记入日志，这些日志记录的维护策略等等。

　　除了这两类定制外，MO也存在着优化问题。比如MO用worker还是Doer来实现，通信方式采用同步还是异步，面向连接还是无连接等等，都会影响整个代理的性能。