【营销Agent实战】从0到1搭建AI Agent:我们的架构演进之路

💡导语：2026年1月，我们接到了一个需求：给广告投放团队做一个AI助手。听起来简单对吧？3个月后，这个"聊天机器人"演变成了一个Multi-Agent架构的复杂系统。这篇文章聊聊那些关键决策和踩过的坑。

       我将从现在开始进行我的AI-开发全纪录，环境大家关注！

说实话，开始这个项目的时候，我并不知道自己会踩多少坑。

2026年1月，我们团队接到了一个需求：给广告投放团队做一个AI助手。听起来挺简单的对吧？就是一个能聊天的机器人，回答点问题而已。

但当我真正坐下来想这个问题的时候，发现事情没那么简单。

这篇文章我想聊聊，这个项目是怎么从一个模糊的想法，慢慢演变成现在的Mokiwi AI Agent的。不是什么高大上的架构演讲，就是我自己的一些思考过程。

🎯为什么会有这个项目？

先说说背景。我们在做广告投放业务，每天要处理大量数据：哪个渠道效果好、ROI多少、竞品在做什么、行业趋势怎么样。这些问题以前都是人工去查、去问、去分析的。

我们有个数据分析师小李，每天的工作就是被各种业务方轰炸：

• "帮我看一下上周的投放数据"
• "对比一下抖音和快手的效果"
• "最近竞品有什么动作？"
• "这个SQL怎么写？"

小李都快疯了。

所以问题很明确：怎么让业务人员自己就能获取这些信息，而不需要每次都找数据团队？

一开始我们想到的是传统的BI报表。但问题是，报表是固定的，业务问题千变万化。今天你做了一个"上周投放效果"的报表，明天人家就问"上上周"，后天又问"按地区拆分"。报表永远追不上问题。

我们需要的是：一个能理解自然语言、能查数据、能分析、还能告诉你为什么的AI助手。

🏗️我对这个产品的想象

确定了要做AI助手，下一步就是要想清楚它到底能做什么。

我给自己列了几个核心场景：

1️⃣ 智能对话

这个是最基础的。不能只是简单的一问一答，要能记住上下文。比如用户先问"上周的投放效果如何"，然后接着问"那抖音渠道呢"，AI得知道"那"指的是什么。

2️⃣ 数据分析

这是重头戏。要能理解"帮我看看最近一周转化率低于5%的计划"这种话，然后转成SQL去查数据库，再把结果用人类能看懂的方式呈现出来。

3️⃣ 市场洞察

业务人员经常问"竞品最近在做什么"。我们需要让AI能去网上搜索相关信息，然后总结成报告。不能只是一堆链接，要有分析、有结论。

4️⃣ 深度思考

有些问题需要推理。比如"为什么上周ROI突然下降了"，这可能需要分析多个维度的数据，找出原因。我们希望AI能像一个有经验的分析师一样，一步步推理，最后给出结论。

这四个需求，对应了我后来设计的四个核心Agent。但在当时，我并不知道会做成Multi-Agent架构。这些都是慢慢演化出来的。

🔧技术选型：那些纠结的日子

为什么选Go而不是Python？

做AI项目，很多人第一反应是Python。毕竟Python生态好，各种LLM库都是Python写的。我一开始也犹豫过。

但考虑再三，还是选了Go。几个原因：

📌 第一，团队技术栈我们后端团队主要用Go，大家的代码库、工具链、部署流程都是围绕Go的。如果为了这个项目引入Python，维护成本会很高。📌 第二，性能Go的并发模型真的很香。AI请求响应慢，如果用Python，高并发的时候很容易卡死。Go的goroutine可以轻松处理大量并发连接。📌 第三，部署简单Go编译成单个二进制文件，扔到服务器就能跑。Python要考虑虚拟环境、依赖版本，太麻烦。

当然，代价也有。Go的AI生态确实不如Python。但好在现在大多数LLM都提供HTTP API，用Go调用也没什么问题。

为什么选择Eino框架？

选框架的时候，我调研了好几个选项：

• LangChain
  
  ：Python生态的事实标准，但Go版本LangChainGo不够成熟
• 自己写
  
  ：从零开始，灵活但工作量大
• Eino
  
  ：字节跳动CloudWeGo开源的Go框架，专门做AI Agent

最后选了Eino。说实话，当时Eino还挺新的，网上资料不多。但我看了它的设计文档，感觉理念很对：

1. Graph编排
   
   ：把AI流程抽象成图，节点是各种操作（调用模型、执行工具），边是数据流。这种可视化思路我很喜欢。
2. Multi-Agent支持
   
   ：内置了Host Multi-Agent模式，正好符合我们的需求。
3. 与Go生态融合
   
   ：用Go的惯用写法，没有奇怪的魔法。

更重要的是，Eino是中国人写的框架，文档是中文的，有问题去GitHub提issue响应也很快。这点比用国外的框架舒服多了。

为什么选择DeepSeek？

这个选择其实是有演变的。

最开始我们用的是火山引擎的VeADK。接入简单，在国内访问快，效果也不错。

但后来我们试了DeepSeek，发现几个优势：

1. 便宜
   
   ：同样的效果，价格是火山引擎的1/3左右。这对我们这种要控制成本的项目很重要。
2. DeepSeek-R1的推理能力
   
   ：R1是专门针对推理优化的模型，在复杂问题上表现比通用模型好很多。我们那个"为什么ROI下降"的场景，R1的表现明显更好。
3. OpenAI兼容接口
   
   ：这意味着我们可以随时切换到其他模型，不会被绑死。

现在我们用的是双模型策略：日常对话用DeepSeek-Chat（快、便宜），复杂推理用DeepSeek-R1（准、贵但值得）。

🏛️架构是怎么长出来的

整体架构

Multi-Agent设计

这个架构最核心的想法是：不要指望一个Agent能干所有事。

我设计了一个Host Agent，它的工作不是直接回答问题，而是判断这个问题应该交给谁。有点像前台接待员，你来了，他判断你是要看病还是买药，然后把你引导到对应的科室。

我们有三个Specialist Agent：

🤖 ChatAgent处理闲聊和通用问题。"你好""今天天气怎么样""Go语言有什么特点"这种。🔍 MarketAgent处理市场相关问题。"分析一下竞品XX的最新动态""这个行业最近有什么趋势"。它会调用web_search工具去网上搜信息，然后总结回答。📊 AdAnalysisAgent处理数据分析问题。"帮我看看上周的投放数据""转化率低于5%的计划有哪些"。它会调用sql_query工具查数据库，还可以做简单的数据分析。

Function Calling：让AI有"手"

光有大脑不行，AI还得有"手"去操作外部世界。这就是Function Calling（函数调用）。

我们在系统里注册了几个工具：

// 网络搜索tools.Register("web_search",func(paramsmap[string]interface{}) {    query := params["query"].(string)returnserpapi.Search(query)})// SQL查询tools.Register("sql_query",func(paramsmap[string]interface{}) {    sql := params["query"].(string)returndb.Query(sql)})

当用户问"帮我搜一下竞品的最新动态"，Host Agent会把这个问题丢给MarketAgent。MarketAgent分析后觉得需要搜索，就调用web_search工具。工具返回结果后，MarketAgent再基于这个结果给出最终回答。

这个过程对用户是透明的，他只会看到一个完整的回答，但背后其实是AI先调用工具、再整理信息的过程。

会话管理：让AI有"记忆"

一个常见的误区是觉得AI天生就能记住对话历史。其实不是，每次请求都是独立的。要实现多轮对话，需要我们自己把历史消息存下来，每次请求的时候一起带过去。

我们用MySQL存会话和消息，Redis做缓存。结构大概是这样：

session (会话)  └── messages (消息列表)        ├── user: "帮我看看上周的数据"        ├── assistant: "好的，这是上周的投放数据..."        ├── user: "那抖音渠道呢"        └── assistant: "抖音渠道上周的表现是..."

这里有个细节：AI有上下文长度限制，不能无限地把历史消息都带过去。我们目前的策略是保留最近的10轮对话，更久的历史会做一个摘要。

🐛那些踩过的坑（提前剧透）

写到这里，我想先剧透几个后面会详细讲的问题。如果你也在做类似的项目，或许能少走点弯路。

⚠️SSE流式响应的中文乱码用SSE做流式输出的时候，中文字符会被截断，出现乱码。后来我们做了UTF-8边界检测才解决。

⚠️Agent路由的准确率一开始Host Agent经常选错Specialist，比如把数据分析的问题丢给了聊天Agent。后来通过优化Prompt、加Few-shot示例才改善。

⚠️SQL生成的安全性让AI生成SQL有SQL注入的风险。我们做了参数清理、权限控制、只读账号等多重防护。

这些问题我会在后面的文章里详细聊。

📝总结一下

这个项目从最初的"做个聊天机器人"，慢慢演变成了现在的Multi-Agent架构。回头看，有几个关键决策我觉得是做对了的：

1. 选Go而不是Python
   
   ：虽然生态差点，但开发和部署效率高很多。
2. 用Eino框架
   
   ：省了大量自己造轮子的时间，Graph编排的思想也很清晰。
3. Multi-Agent架构
   
   ：不要指望一个Agent万能，专业的事情交给专业的Agent去做。
4. 双模型策略
   
   ：根据场景选择不同的模型，平衡成本和效果。

当然，也走了一些弯路。比如一开始试图把所有功能塞给一个Agent，结果发现效果很差。后来拆分成多个Agent才好起来。

这个系列我会持续更新，下一篇聊聊Eino框架的详细用法，以及我们是怎么做Multi-Agent编排的。如果你也在做AI Agent，欢迎一起交流。

🎁 福利

📎 源码获取：关注后回复「Mokiwi」获取项目GitHub地址

📚 系列文章：

• 第1篇：从需求到架构（本文）

• 第2篇：Eino框架深度解析（待更新）

• 第3篇：从VeADK到DeepSeek（待更新）

如果觉得有用，欢迎：

👍 点赞 + 在看，让更多人看到

💬 留言交流，你的问题我会回复

🔗 转发给需要的朋友

M

专注于AI Agent和云原生架构，正在记录从0到1构建企业级AI系统的全过程。

#AIAgent#Go语言#架构设计#MultiAgent#技术实战