10 转型：如何在Agent平台上构建一个AI营销智能体？
你好，我是金伟。
上节课说的AI营销功能还是微信单点能力，在现实营销项目中，还需要“化零为整”，把更多的功能及合成一个智能体。
从整个系统的角度来看，就是通过Agent智能体升级我们原来的营销平台，即原有广告平台 + AI = 营销平台 2.0。
这节课，我就带你开发几个营销领域的Agent智能体，让你从零开始，学会Agent智能体开发。
营销Agent开发思路
Agent平台应用的范式说来并不复杂，交互上，是聊天机器人为基础的交互界面，架构上，支持低成本开发和分享新的AI智能体应用，也可以快速复用原有的成熟应用逻辑。
市场上有一些低代码的Agent开发平台，比如斑头雁、扣子等等。我们基于这些平台就可以开发自己的Agent智能体应用，也可以直接把这些应用分享给用户。
我们的目标是把原有营销平台的工具全都转换成Agent智能体，同时，把Agent智能体的开发能力分享给我们的客户。具体选型上，一方面基于成本考量，另一方面团队也抱着学习的态度，我们选择在扣子Agent平台上，开发1-2个Agent智能体，组合完成一个完整的业务逻辑。
在做单个的工具之前，我们最大的挑战就是理解、适应Agent平台的开发模式。
我先从Agent平台的助理这个概念入手分析。
助理是Agent平台的核心概念，有的平台也把助理就叫做Agent或机器人，其实它们都是一回事。你可以把助理看做一个AI first的应用。
Agent平台里的助理不是只有聊天能力，它还能做很多事。比如下面这个客服助理自带有客服能力，用户跟这个助理聊天的时候就是在跟一个客服聊天。你还可以自建和扩展助理的能力，比如这个客服助理的退款功能就是我自定义的，它可以自动识别订单号，发起退款流程。
退款功能先要要用到私有数据库。那很多公有的能力比如搜索数据等如何实现呢？这就要靠Agent平台的另外一个核心概念，插件能力，也就是类似下面展示的这些能力。
比如搜索能力可以用Google Web Search插件，上面提到的退款流程则需要用到Database插件。
可以说，Agent智能体开发效率高，就是因为这些平台提供了大量插件能力和多种大模型提供的接入能力。
你可能会奇怪Agent是怎么具备业务逻辑的，Agent和大模型是什么关系呢？
我的答案是，助理可以看做Agent应用的界面，比如例子里的客服助理。但你其实就是在和大模型在聊天，只不过在你和大模型之间还有一个代理程序，它就是Agent。我们可以把Agent看做大模型的代理人。
在Agent平台里还有一个重要概念就是工作流。助理负责识别具体的业务逻辑并调取工作流，一个工作流其实就是一个原有业务逻辑。比如客服里的退货业务，实际上工作流是被动配合助理的。
几个概念综合起来，内部的实现就很容易理解了，由外到内一共四层关系：助理 -> 工作流 -> 插件->知识库。
可以这样理解，工作流就是传统应用里的独立功能的函数或程序，那插件呢，就是传统程序里的系统库函数，知识库就是传统数据库。
总结一下，助理通过提示词配置具体的沟通能力以及业务能力，具体业务能力的承接通过工作流实现，其他的模块都是配合工作流的，有了这些部件，我们就可以基于Agent平台开发一个实际的营销Agent应用了。
营销Agent开发过程
Agent（助理）的设计分为三个部分。其一是配置助理的系统提示词，其二是配置Agent（助理）的工作流能力，其三就是设计具体的工作流逻辑。
例1：公司信息营销AI
我们来看一个实际给用户提供营销的Agent。它的功能是通过公司名找到这家公司的邮箱信息。
第一步，设计Agent（助理）的系统提示词。如果把Agent类比为一个公司的前台的话，这一步就是告诉前台整体的工作职责和对客户的态度，或者说，限定大模型的交互边界。
没有什么比直接写一个提示词的例子能更清楚地表示这一步了。看下我们依据“通过公司名找到联系方式”这个需求写出来的提示词。核心就是一句话：说明清楚这是一个人机交互的助理，目的是帮用户收集公司联系方式信息。
# 角色
您是一位营销代理机器人，旨在帮助用户通过公司名称找到联系方式并将信息存入数据库。
## 技能
... ...
## 限制
- 使用简单明了的语言，以确保用户可以轻松理解和使用。
- 遵守提供的输出格式。
实际上，我们只要将提示提交给Agent平台，就已经创建好一个助理了。它甚至可以马上开始工作。
当然，要让其真正具备工作能力还需要第二步，配置Agent的工作流能力。比如该需求中的联系方式获取、信息入库，都需要在提示词中用 Skill技能 这个模块给大模型标出来。这一步相当于告诉前台，咱们公司后台有哪些能力，当客户需要的时候你可以直接调取。
具体实现就是补充助理提示词里Skill技能模块。
# 角色
您是一位营销代理机器人，旨在帮助用户通过公司名称找到联系方式并将信息存入数据库。
## 技能
### 技能1：提供联系方式
- 根据用户提供的公司名称找到相关的联系方式（如公司联系邮箱）。
- 确保提供的联系方式准确且易于使用。
- 格式示例：
=====
- 公司名称: <公司名称>
- 联系方式: <详细联系方式>
=====
### 技能2：信息入库
- 将找到的公司名称和联系方式存入数据库。
- 确保信息存储过程准确无误。
- 格式示例：
=====
- 信息已成功存入数据库:
- 公司名称: <公司名称>
- 联系方式: <详细联系方式>
=====
## 限制
- 使用简单明了的语言，以确保用户可以轻松理解和使用。
- 遵守提供的输出格式。
助理提示编写的要求，一是要说明清楚总体工作目标，二是说明清楚具体工作细节方法。比如提示词里的格式示例信息就非常关键。
这样编写的目的实际上是让助理（背后是大模型）准确地提取出用户聊天过程中的 公司名称，将其作为输入调用具体工作流 技能1：提供联系方式，得到结果。就像一个公司的前台，接收到客户投诉时，总要把客户具体的出错信息整理出来告诉程序员，才方便他进一步处理。
做完前两步配置，后续的工作流实现就变得极其简单了。你可以回想一下传统的程序开发，我们需要开发很多用户界面和判断逻辑，才能准确识别出一次用户的需求。接着，又需要做大量数据整理逻辑才能调用具体的实现函数。现在，助理提示词+大模型就搞定这一切了。
第三步，工作流设计。你可以把一个工作流看做一个函数，比如例子里的 联系方式 工作流。我用一张图给你说明清楚。
这个图很好地说明了工作流的两个特点。一是每一步的输出就是下一步的输入，二是工作流一般来说只要顺序处理数据，就像一个公司里最基础的岗位，业务和流程非常明确。
设计上，我们还要思考，抓取联系方式是用大模型实现，还是用传统的爬虫技术实现？当然了，信息存储显然要用传统程序来实现。如果想开发省事，可以直接交给大模型分析处理，想运行成本低一些，则可以用传统爬虫程序。
好了，思路已经非常清晰了，接下来说说具体实现。首先，我们将刚才梳理的工作流在Coze平台上编排为具体的工作流。
注意看，这个工作流的具体流程图和我画的示意图就是工作流的一体两面。一个是实现，一个是设计，具体工作流上的节点都可以通过Coze平台拖拽配置。我在工作流上加入了Google搜索插件和自己的爬虫代码逻辑，把它们的输入输出编排为顺序的工作流，最终能实现输入是公司名称，输出是公司的联系方式。
虽然说Agent平台拖拽式开发非常方便，但是做过编程的朋友都知道，要实现哪怕一个很小的产品也不容易。
比如，工作流每一步的需求都可以用输入-输出来表示，第一步的输入是公司名字，输出是公司网址。在之前的设计里，这一步是通过Google搜索插件完成的。这里就要提到工作流开发第一个特点：每个插件或代码节点都可以单独调试。
假设我们要调试Google搜索插件，可以单独运行它，填入测试的 query 参数就可以。
在这个图里，插件的实际参数是 query，也就是搜索的关键词。这个参数可以在插件节点编辑界面用 Reference 关联上一步的输出，这样就可以实现整体工作流的运行了。
好了，现在我们说回单步调试，当我们的 query 设置为 极客时间，它的运行结果也是可以直接查看的。下面是这次调用的具体结果。
你可能注意到这次调用的搜索结果第一项的 url 并不是我们想要的，这正是单步调试的意义，它让我们及时发现问题。经过调整，最后我们将 query 设定为 极客时间 官网，就能达到提取网址的目的。
这样调整的话，就要求Google搜索前置流程需要把 company 参数加入 官网 字样，具体方法是加一个工作流节点，直接用Code节点实现。
具体的Code节点代码例子如下。
async def main(args: Args) -> Output:
params = args.params
ret: Output = {
"company_name": params['input'] + " 官网"
}
return ret
最后把这个Code节点插入到Google插件之前，就完成了输入是公司名字，输出是公司网址的逻辑。
你可能会想，如果通过这个关键字搜索的第一项还不是公司官网怎么办？在实战环境中肯定会出现这种情况，因此更实战的逻辑还要更加复杂。我们要加入搜索结果的进一步比对分析，比如比较每个网址、内容和Title，以便确认是这个公司的官网。工作流开发过程是一样的，此处不再展开。
好了，这只是实现了第一步，你跟着我的思路继续。
第二步的输入是公司网址，输出是公司联系方式。这一步我的思路不是拿着官网网址去下载网页内容，而是先从官网内容里查询联系方式或“联系我们”之类的单独网址，再从这个网址里提取联系方式就方便了。
我先把编排完的结果展示一下。
注意，这个流程的第一个节点是我找的一个插件，功能是根据网址抓取网页内容，提示词1 和 提示词2的目的都是通过大模型来分析网页内容，找到联系方式的具体网址。
#提示词1
下面是一个html内容，你要解析这个html，找到网址的导航部分，只去分析链接和相应的链接名称，
提取出链接-链接名称这样的数据对,注意链接和名称要一一对应，用json格式输出：
{{input}}
#提示词2
从下面的json内容里取出链接名称是 联系方式，公司信息的网址,输出1个网址就行，不要名称：
{{input}}
你可以对照这两个提示词好好梳理一下这一步的逻辑。拿到联系方式的 网址2 之后，还可以继续接 jina_reader 节点读取内容。最后接一个code节点，用正则提取电话、邮箱这些联系方式，开发方法跟前面类似。
到此为止，你应该可以发现Agent工作流的这种开发模式其实非常适合非编程人员使用。使用合适的插件，再结合 LLM 的强大能力，只要会简单的代码逻辑就可以完成一个功能，我想这也正是Agent智能体的核心价值所在。
现在，你只需要单独调试好这个工作流，Agent的交换界面上就能自动更新获得的最新能力了。
例2：邮件营销AI
下面，我们继续在这个助理基础上扩展邮件营销能力。
如果要实现邮件营销推广Agent，要包括营销文案生成，营销邮件发送等功能，只需要在上一步的助理基础上扩展即可，不需要新建一个Agent。
第一步修改助理核心提示词。我们需要加入的是营销文案和邮件发送的能力，也就是下面的技能3和技能4。
# 角色
您是一位营销代理机器人，旨在帮助用户通过公司名称找到联系方式，生成营销文案，并发送营销邮件。
## 技能
...
### 技能3：生成营销文案
- 根据用户的需求生成定制化的营销文案。
- 确保文案能够有效地传达信息并吸引目标受众。
- 格式示例：
=====
- 营销文案: <详细营销文案>
=====
### 技能4：发送营销邮件
- 使用生成的营销文案发送营销邮件到指定的公司联系邮箱。
- 确保邮件发送过程顺利且无误。
- 格式示例：
=====
- 公司名称: <公司名称>
- 联系方式: <详细联系方式>
- 邮件发送状态: <发送成功/失败>
=====
...
然后是第二步。我在设计的时候发现，因为还需要加上按标签筛选客户邮箱的功能，所以具体的工作流实际上是三个，我先用一张图表示这三个工作流。
标签筛选这个工作流的实现，需要复用原平台的标签库功能。营销文案的生产复用上一节课说的营销文章工厂能力，两步都是原有功能对接，就不再展开了。
而发邮件的工作流就要用插件能力来实现邮件EDM功能了。我在Coze上找到一个叫SendMail的插件，用了它的SendGird邮件服务。
你可以在SendGird申请一个key，就能完成邮件发送任务。工作流的代码开发和调试和前述方法一致，这里我就略去细节了。
案例总结
如果我们回顾这几个简单的例子，会发现Agent平台提供了什么价值呢？
对传统应用来说，Agent平台提供了统一的界面，也就是助理聊天界面。这种交互模式几乎可以替代传统的应用交互界面。因为传统界面交互需要大量的选项、按钮、输入框等，新的交互呢，用户通过自然语言就可以说清需求；而且这个交互界面，随时可以通过我们配置的提示词调整具体的交互逻辑，也就是Agent（助理）设计的第一，二步。本质是因为大模型具有很强的可塑性，这让交互界面的开发成本直接降为零。
而工作流和插件的低代码开发模式，也就是Agent（助理）设计的第三步，复用现有业务和复用现有云计算能力，这些都非常方便，至少有10-20倍的业务开发速度提升。而且你开发的工作流可以直接分享，进一步提高了别人的开发效率。
营销Agent优化有哪些额外考虑？
我们初始的目标，是要实现营销AI 2.0版本，并且将自定义能力开放给我们的客户。如果是单个新增应用，基于Coze这类Agent开发平台来开发，由于Coze平台本身提供了整套的基础设施，开发效率有很大的提升。但是当我们想基于它构建一整套系统时，遇到了不少困难。
第一个挑战是数据和能力复用问题。
其一，数据私有化这是企业的常见需求，利用现有Agent平台开发营销AI 2.0平台，不可避免地要将私有数据和现有Agent平台打通，企业客户不一定能接受这个方案。
其二，在能力复用方面，我们现有的营销平台功能非常多，如果用现有Agent平台来开发，就需要适配Agent平台重新开发一遍，开发成本很高。现有Agent平台对创建新应用更友好，这也是我这节课没有细讲标签功能的原因。
而且，我们发现，想要搭建一个完整的营销平台2.0版本，会有很大的成本问题。用现有的Agent平台本身需要成本，使用它代理的大模型也需要token成本。
为了解决这些问题，我们团队只好从底层实现一套类似Coze平台的架构，这就是下节课进一步展开的内容了。
小结
好了，总结一下，从客户角度来分析，单独的AI聊天不能解决客户实际问题，客户实际是想用AI提高获客效率，提高老客户的复购率。而原来的营销平台是靠着平台技术能力加人力运营实现的这些目标。
从我们之前开发这些单体的智能体应用经验看，如果搭建一个营销Agent平台，可以用极低的成本将原有运营逻辑变为自动化的过程，提升效率，同时意味着成本也会降低。
这是我们接触Coze这类的Agent开发平台的原因，如果你使用过Coze平台，同时具备一定的编程能力，你可能会惊呼，这样开发一个Agent应用也太简单了吧！几乎人人都可以开发自己的Agent智能体了。
Agent智能体在平台的核心其实就两个，一是用于限定机器人交互的系统提示词，二是用于实现业务逻辑的工作流。工作流开发在系统插件、LLM能力以及知识库、Memory系统记忆等大量系统能力的加持下，能够提升不小的开发效率。
但是当你深入到Agent开发中，又会发现同样的问题。这个平台作为个人开发完全足够，但是对于我们团队这类的系统整体升级需求而言，还要做适配，开发成本不小。最后我们意识到，我们要做的是整体的营销AI 2.0，又因为我们有自研能力，所以开始自研Agent平台底层，这部分内容，我会在下节课详细展开。
思考题
在工作流系统中，最重要的就是输入和输出数据，比如例子里公司名词：百度，工作流系统是如何准确识别这个输入的，和大模型有什么关系？
欢迎你在留言区和我交流。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！
- jerremyZhang 👍（1） 💬（1）
非常期待后续
2024-08-28 - 大魔王汪汪 👍（1） 💬（0）
想问下，现在对于Agent的定义，如果实现一个基于用户问题+简单的function call+答案生成的功能可以叫做Agent，那如果后面是一个复杂的工作流也可以叫Agent，所以从功能复杂度角度来说应该怎么定义一个Agent呢？
2024-12-30