1. 为什么我用 Go 来搭这条 AI Agent 流水线，而不是 Python
1.1 这条流水线到底在解决什么问题
上个月接了个挺现实的需求：运营团队每天要上新几十个品，每个品都要配一整套淘宝详情页——标题、卖点、规格参数、场景文案、详情模块，一套下来少说要半小时，写多了以后你会发现内容还高度同质化。甲方问了我一句话：能不能丢一张商品图进去，自动把详情页给我生成出来？
我当时的第一反应和大家一样，用 Python 写 Agent，毕竟 AI 生态的 SDK、教程、开源项目基本都是 Python。但冷静下来算了一笔账：这本质上不是一个“AI 能力”问题，而是一个“工程编排”问题。图片上传、预处理、调用多模态模型、解析 JSON、并行生成多段文案、模板渲染、打包输出，这些环节里没有一个是 Python 独有的，反而是 Go 的强项。最后这版从 1 张商品图到一整套淘宝详情页的流水线，我用 Go 从零搭完，前后端一起跑，生产环境吃并发比我预期中稳得多。
这篇文章就聊聊这条流水线怎么设计、怎么落地，以及我在实际开发中踩过的坑。你能看到完整的数据流设计、流水线编排思路、并发与限流方案、还有结构化输出的兜底处理。如果你正打算做类似的 AI Agent 项目，或者想知道 Go 到底适不适合写 Agent，这篇应该对你有用。
1.2 为什么选 Go：不是抬杠，是算过账的
先摆结论：AI 模型本身的能力和你用什么语言无关。模型 API 就是 HTTP 接口，你给我 JSON，我给你 JSON，Go 调用起来和 Python 一样顺手。真正的差异在工程侧。
我整理过一张对比表，直接说结论：
| 维度 | Go | Python |
|---|---|---|
| 并发模型 | goroutine + channel，轻量直接 | 协程/asyncio，心智负担高 |
| 部署 | 单二进制，拉起来就能跑 | 依赖环境、pip、虚拟环境，麻烦 |
| 内存 | 静态类型，长驻服务友好 | 脚本进程一多，内存容易飙升 |
| JSON 处理 | encoding/json 性能好 | 方便但慢 |
| AI SDK 生态 | 一般，但调用 API 足够 | 丰富，但很多用不到 |
| 运维监控 | 原生可观测，亲和 | 要额外接框架 |
关键要理解一点：Agent 流水线里的瓶颈通常是外部模型的响应时间，不是语言本身的执行速度。真正的工程难点是怎么把几十个请求编排好、重试好、限流好、观测好。这些恰恰是 Go 的主场。我线上跑了一周，单机 8 个 worker 并发处理图片，每天处理几百个商品，没有一次因为语言性能出问题。
还有一点很多人忽略：如果你已经有一个 Go 写的电商后台，用 Go 写 Agent 意味着可以直接嵌入现有服务，共享配置中心、日志系统、链路追踪，不需要再起一个 Python 微服务来“伺候”它。实际维护成本会低很多。
1.3 流水线整体设计：每个环节都是独立的“工位”
整条流水线我拆成了六个阶段，每个阶段只做一件事，输出给下一个阶段：
商品图 → 图片预处理 → VLM 结构化抽取 → 标题/卖点/详情段落（并行） → 模板渲染 → 打包输出为什么要拆这么细？三个理由：
第一，每一段都能独立重试和观测。哪一步慢、哪一步挂了，日志里一目了然。
第二，中间产物可以缓存。商品图处理过一次，抽取结果就不会再变，不需要每次都重新调模型烧钱。
第三，将来换模型供应商时，只需要替换对应阶段的实现，流水线骨架完全不用动。
我在设计时给每个阶段定义了一个标准接口，后面会详细说。总之记住这句话：流水线不是把代码写成一长串顺序调用，而是把每个环节都做成可以单独替换、单独测试的“工位”。
2. 核心链路拆解：从一张图到结构化商品信息
2.1 图片预处理：先压图，再进模型
很多第一次做多模态 Agent 的人会直接把原图丢给 VLM，这是最容易翻车的点。淘宝的商品图动辄几 MB，甚至还有高分辨率大图，直接传进去，不仅模型侧 token 消耗大，接口超时率也会直线上升。我在流水线最前面加了一个预处理环节，做三件事：
- 等比缩放到最长边不超过 1024 像素，同时保持清晰度；
- 统一转成 JPEG 格式，避免遇到 HEIC、PNG 大图时模型 API 不支持或解析过慢；
- 顺便做一次基础的图片方向纠正，减少 VLM 识别时的误判。
代码也很简单，用 Go 的image标准库加上github.com/disintegration/imaging就能搞定：
func preprocessImage(srcPath string) (string, error) { src, err := imaging.Open(srcPath, imaging.AutoOrientation(true)) if err != nil { return "", err } dst := imaging.Fit(src, 1024, 1024, imaging.Lanczos) tmp, _ := os.CreateTemp("", "prep-*.jpg") err = imaging.Encode(tmp, dst, imaging.JPEG, imaging.JPEGQuality(90)) if err != nil { return "", err } return tmp.Name(), nil }注意：不要做超过 1024 的无脑压缩，否则商品细节（比如面料纹理、产品型号）丢失，后面抽取出来的属性会不准。我实测 1024 是一个性价比比较高的值，VLM 能看清细节，token 也控制得住。
预处理输出的这张标准图，会贯穿整个流水线，所有后续模型调用都用它，避免不同环节看到不同图片导致信息对不上。
2.2 VLM 结构化抽取：让模型输出 JSON，而不是让它“自由发挥”
预处理完，接下来的核心是把一张图变成结构化的商品信息。这里我用的不是普通 LLM，而是多模态大模型（VLM）。你可以用 GPT-4o、Qwen-VL、或者国内各种支持图片输入的模型，底层逻辑是一样的：把图片和一段强约束的 Prompt 一起发给模型，让它输出固定结构的 JSON。
Prompt 我反复迭代过，最后长这样：
你是资深电商运营，请分析这张商品主图，只做信息提取，不做文案创作。 输出 JSON，格式如下： { "category": "商品类目", "attributes": { "颜色": "...", "材质": "...", "形状": "...", "型号": "..." }, "selling_points": ["卖点1", "卖点2", "卖点3"], "target_users": "目标人群描述" } 要求： 1. 只依据图片中可见信息，不要脑补。 2. 忽略图中的水印、促销文字、logo 等干扰信息。 3. attributes 只输出视觉可见的属性，最多 5 个。 4. selling_points 不超过 5 条，每条不超过 20 字。这里有一个容易被忽略的细节：不是所有模型 API 都原生支持 JSON 模式。能开结构化输出（比如response_format={"type": "json_object"}）的尽量开，不能开的就必须做解析兜底。我在流水线里写了三级降级：先尝试用 JSON mode，不行就靠后处理把模型回复里的 JSON 块抠出来，再不行就重试。下面这段解析函数在线上救了我很多次：
func extractJSON(raw string) ([]byte, error) { // 去掉 ```json 和 ``` 包裹 re := regexp.MustCompile("(?s)```(?:json)?\\s*(.*?)```") if m := re.FindStringSubmatch(raw); m != nil { return []byte(m[1]), nil } // 去掉首尾可能的非 JSON 文本 start := strings.Index(raw, "{") end := strings.LastIndex(raw, "}") if start >= 0 && end > start { return []byte(raw[start : end+1]), nil } return nil, fmt.Errorf("no json block found") }解析成功后，再json.Unmarshal到预定义的结构体。这一步的输出是整个流水线的“黄金中间产物”，后面所有文案生成都基于它，不再直接看图，既省钱又稳定。
2.3 结构化输出的校验与兜底：模型给的数据也不能全信
模型再强，也会偶发幻觉。比如图片里根本没有“材质”信息，它硬编一个“纯棉”出来，后面的标题就跟着一起错了。所以我在抽取阶段之后加了一个校验层，做三件事：
- 字段缺失检测：关键字段（category、attributes）缺失就重试一次；
- 枚举校验：类目必须在我预先维护的类目表里，不在就做相似度匹配或者抛错；
- 长度校验：selling_points 每条超过 20 字就截断，避免后续文案结构崩掉。
这块逻辑看起来琐碎，但非常重要。流水线越往后走，错误越会被放大。你在第一步让模型“猜”了一个不存在的属性，后面生成的整段文案都会围绕这个假属性展开，像滚雪球一样，最后出来的详情页根本不能看。所以我情愿在早期多花一次重试的成本，也不愿意让脏数据流到下游。
3. 流水线编排：Go 里的状态流转与并发控制
3.1 数据模型设计：一个 Context 贯穿全程
流水线的核心数据结构我设计成了PipelineContext，所有阶段共享它，每个阶段只修改其中属于自己的字段：
type ProductInfo struct { Category string `json:"category"` Attributes map[string]string `json:"attributes"` SellingPoints []string `json:"selling_points"` TargetUsers string `json:"target_users"` } type Section struct { Title string `json:"title"` Content string `json:"content"` } type PipelineContext struct { RequestID string ImagePath string ProcessedImage string Product ProductInfo Title string SellingPoints []string Sections []Section HTML string StageDurations map[string]time.Duration Meta map[string]any }有人可能会问，为什么不直接用context.Context传递数据？我的做法是：用标准库的context.Context传递取消信号和超时控制，用PipelineContext传递业务数据，两者职责分离，互不混用。
RequestID字段特别重要，每个请求进来先赋一个 UUID，整个流水线的日志、模型调用参数、错误信息都带上它，排查问题的时候才知道是哪一单、哪一步出了问题。
3.2 把每个环节做成接口，而不是一坨顺序代码
流水线调度器我定义了一个Stage接口：
type Stage interface { Name() string Run(ctx context.Context, pc *PipelineContext) error }然后实现一个最简单的 Runner：
type Pipeline struct { stages []Stage } func (p *Pipeline) Add(s Stage) *Pipeline { p.stages = append(p.stages, s) return p } func (p *Pipeline) Execute(ctx context.Context, pc *PipelineContext) error { for _, s := range p.stages { start := time.Now() if err := s.Run(ctx, pc); err != nil { return fmt.Errorf("stage %s failed: %w", s.Name(), err) } pc.StageDurations[s.Name()] = time.Since(start) slog.Info("stage finished", "req", pc.RequestID, "stage", s.Name(), "cost", time.Since(start).String()) } return nil }接口的好处是：想加一个“文生图”环节，写个新 Stage 塞进去就行；想换掉某个模型供应商，只改对应 Stage 的内部实现。每个 Stage 可以单独写测试、单独 mock，不需要把整条链路都跑起来才能验证。
3.3 哪里该并行，哪里必须串行
流水线不是所有环节都能并行的。回到这条链路上：
- 图片预处理 → VLM 抽取，这两步必须串行，因为抽取依赖预处理结果；
- 抽取完之后，标题生成、卖点生成、详情段落生成，这三者互不依赖，可以并行；
- 最后模板渲染又必须等前面都完成。
所以我用一个errgroup把三个独立的生成任务并发跑起来：
var g errgroup.Group g.Go(func() error { return genTitle(ctx, pc) }) g.Go(func() error { return genSellingPoints(ctx, pc) }) g.Go(func() error { return genSections(ctx, pc) }) if err := g.Wait(); err != nil { return fmt.Errorf("parallel generation failed: %w", err) }实测效果很明显：串行时单条详情页生成需要 25 秒左右，并行优化后压到 12 秒以内，其中大头还是卡在外部的两次模型调用上。
这里提醒一个新手容易踩的坑：errgroup默认会在第一个错误返回时取消其它 goroutine，但你调用的模型 API 不一定响应 context 取消。如果确实需要“等所有子任务跑完再统一判断”，就用errgroup.WithContext配合，或者干脆自己用sync.WaitGroup加错误通道自己实现，别默认它一定会立刻中断。
3.4 断点续跑：把中间结果缓存下来
线上跑了一段时间后我发现，模型接口偶尔不稳定，重试了三五次还是失败。如果从图片预处理重新开始，等于把已经花掉的模型调用费用和等待时间又烧一遍。所以我加了一个很关键的能力：阶段级缓存。
实现思路很简单：每个 Stage 的输出都以RequestID + StageName + 参数hash为 key 缓存到本地磁盘或 Redis。如果后续阶段失败，重新拉起流水线时，Runner 检查到某个阶段的产物已经存在，就直接跳过，从失败点接着跑。
func (r *cachedRunner) runStage(ctx context.Context, s Stage, pc *PipelineContext) error { key := cacheKey(pc.RequestID, s.Name(), stageInputHash(s, pc)) if data, ok := r.cache.Get(key); ok { return json.Unmarshal(data, pc) // 恢复阶段输出 } if err := s.Run(ctx, pc); err != nil { return err } data, _ := json.Marshal(pc) r.cache.Set(key, data, 24*time.Hour) return nil }这个机制对重试、对批量任务的重跑，省下的时间和成本非常可观。尤其是在大促前批量生成商品页的场景里，哪怕 10% 的任务失败，重跑时大部分中间产物都能命中缓存，整体完成时间能缩短一半以上。
4. 模型接口的稳定工程：超时、重试、限流一个都不能少
4.1 超时和重试要分级，不是所有错误都值得重试
调用外部模型 API 是流水线里最容易出问题的环节。我把超时分成两档：
- 连接超时：10 秒，超过直接判定失败；
- 整体响应超时：VLM 调用给 120 秒，普通 LLM 给 60 秒。
Go 的http.Client可以直接设置，不需要额外框架：
client := &http.Client{ Timeout: 120 * time.Second, Transport: &http.Transport{ DialContext: (&net.Dialer{Timeout: 10 * time.Second}).DialContext, MaxIdleConns: 100, }, }重试策略我也做过分级整理：
- 429、5xx：重试，但要退避（指数退避 + 随机抖动）；
- 400、401、403：不重试，立刻返回错误，这是你代码或者配置的问题；
- 超时：重试一次，如果第二次还是超时，直接放弃这一单，进入失败队列。
指数退避的代码很简单，但随机抖动很重要。不加热抖动的话，批量任务同时超时重试，会在上游 API 形成第二次“惊群”，把限流打得更死：
func nextBackoff(attempt int) time.Duration { base := time.Duration(math.Pow(2, float64(attempt))) * time.Second jitter := time.Duration(rand.Int63n(int64(base / 2))) return base + jitter }4.2 并发保护：Agent 扛并发，卡点在上游限流
“AI Agent 怎么扛并发”这个问题，我当时的答案是：先把你自己的代码扛住，再去处理上游。Go 的 goroutine 很便宜，真正危险的是同时发出大量模型请求，把自己的上游 key 打爆。
我的做法是用一个带缓冲的 channel 作为信号量，限制同时进行的模型调用数量：
var sem = make(chan struct{}, 5) // 最多 5 个并发模型请求 func callModel(ctx context.Context, payload string) (*Result, error) { select { case sem <- struct{}{}: defer func() { <-sem }() case <-ctx.Done(): return nil, ctx.Err() } // 实际 HTTP 调用 return doCall(ctx, payload) }这个信号量的大小不是拍脑袋定的，我是先查了模型服务的限流文档，再压测调整。如果你的上游限制是每分钟 60 次，那信号量设为 5、配合 12 秒左右一个请求，比较稳。
另外，建议把“模型服务”单独抽象成一层，统一处理鉴权、限流、重试、prompt 组装。别在 Stage 里散落着各种裸 HTTP 调用，否则换供应商的时候你会想哭。
4.3 可观测性：每个阶段都要有“账本”
排查 Agent 流水线问题，最痛苦的是不知道哪一步慢、哪一步挂了。我从一开始就用 Go 标准库的log/slog打结构化日志，每条日志带上RequestID和StageName。下面是典型的一条：
time="2025-01-08T14:22:10+08:00" level=INFO msg="stage finished" req="a3f9e1" stage="vlm_extract" cost="8.2s" tokens=1243线上排查的时候，我一般先用grep req="a3f9e1"拉出某一单的所有日志，看它在哪个阶段耗时最长、报了什么错，再决定是调 Prompt 还是调超时参数。这一步省下的时间，比任何“AI 技巧”都实在。
如果你有 Jaeger 或者别的链路追踪系统，给每个 Stage 加个 span 也不难，但千万别在最开始就上重量级方案，先用 slog 把事情记清楚，等真正需要再演进。
5. 从结构化数据到淘宝详情页：模板渲染与成稿
5.1 详情页的构成：标题、卖点、参数、模块一个不少
淘宝详情页看起来长，其实结构是固定的。我拆成了五个标准模块：
| 模块 | 内容来源 | 生成方式 |
|---|---|---|
| 商品标题 | 基于属性拼装 + 后处理 | LLM 生成候选，规则校验 |
| 核心卖点 | VLM 抽取的 selling_points | 直接使用 + 句式润色 |
| 规格参数 | attributes | 直接渲染成表格 |
| 详情描述 | 场景文案、使用说明 | LLM 分模块生成 |
| 页面包装 | 整体 HTML/CSS | Go 模板引擎渲染 |
这里有个经验：不要让 LLM 直接输出整段详情页 HTML。大模型写 HTML 容易结构混乱，而且毫无必要。应该让模型输出干净的结构化文案，渲染的事交给 Go 的html/template，这样既能保证页面样式统一，又能避免模型输出注入非法标签。
我用 Go 标准库html/template写了几个模板，比如卖点模块：
const sellingPointsTpl = ` <ul class="points"> {{range .SellingPoints}} <li>{{.}}</li> {{end}} </ul>`模板是预编译的，执行速度飞快，一个页面渲染耗时基本在 1 毫秒内，比模型调用消耗的时间少几个数量级。这就是我把渲染放在流水线最后一环的原因：前面的模型调用再慢，最后的拼装也必须快到可以忽略不计。
5.2 标题的“字数与关键词”后处理：SEO 不是玄学
淘宝标题有一个硬性限制：60 个字符以内，而且前 12 个字基本决定了搜索结果里的展示效果。让 LLM 自由发挥的标题经常超长，或者关键词堆砌得不像人话。我加了一个后处理函数：
- 超长截断：按“核心词 > 属性词 > 场景词”的优先级保留；
- 去除违禁词：比如“最”、“第一”、“国家级”等广告法违禁词；
- 类目兜底：如果标题里没有类目词（比如“连衣裙”），自动追加一个。
func normalizeTitle(raw string, category string) string { title := stripForbiddenWords(raw) title = truncateByRune(title, 60) if !strings.Contains(title, category) { title = category + " " + title } return title }注意这里用truncateByRune而不是简单的title[:n]，因为中文是 UTF-8 编码，按字节切会把汉字截断成乱码。这是很多 Go 新手写中文处理时最容易忽略的细节。
5.3 打包输出：不只是 HTML，而是一整个“素材包”
最后一环，我把生成结果打包成一个标准目录，包含三样东西：
detail.html：可直接预览的详情页；data.json：结构化商品信息，方便运营后台二次编辑；assets/：预处理后的商品图、以及各模块需要引用的图片资源。
打包用archive/zip标准库，几十行代码就能搞定。之所以做成压缩包而不是只给 HTML，是因为运营拿到后可以直接解压上传到商品编辑后台，省掉手工复制粘贴的步骤。
这一步也让我意识到，Agent 流水线的最终交付物不一定是“一篇文案”，更可能是一套可以进入现有业务系统的资产。设计流水线时，多想想下游怎么用，而不是只盯着模型输出。
6. 实测过程、踩坑记录与问题速查
6.1 端到端实测数据
我用一张典型的电商商品图（一款保温杯）跑了一遍完整流水线，各阶段耗时如下：
| 阶段 | 模型 | 耗时 | 说明 |
|---|---|---|---|
| 图片预处理 | 无 | 480ms | 本地压缩 |
| VLM 结构化抽取 | 多模态模型 | 8.1s | 最大耗时点 |
| 标题生成 | LLM | 2.3s | 并行执行 |
| 卖点生成 | LLM | 2.1s | 并行执行 |
| 详情段落生成 | LLM | 4.8s | 并行执行 |
| 模板渲染 | 无 | <10ms | 本地执行 |
| 打包输出 | 无 | 50ms | 本地执行 |
总耗时约 18 秒，但并行优化后实际墙钟时间在 12 秒以内。这个速度对批量生成场景完全够用，毕竟人工写一套详情页要半小时起步，机器 12 秒出初稿，运营再花几分钟修改就能上架。
值得注意的是，耗时大头 100% 都在外部模型调用上。这也再次印证了我的判断：语言选型不是瓶颈，模型调用链路才是。
6.2 我踩过的五个坑
第一，图片太大导致 token 爆炸。最开始没加预处理，一张 4000×3000 的商品图直接传上去，不仅慢，费用也高。加了缩放到 1024 之后，效果几乎无损，成本降了 70%。
第二，VLM 把包装上的字当成了卖点。商品图上有“限时特惠”“热卖”这类水印文字，模型很容易当成商品信息抽取出来。后来在 Prompt 里明确加了一条“忽略图中的水印、促销文字、logo 等干扰信息”，问题才缓解。
第三，模型输出里带```json包裹。即使你让它“只输出 JSON”，它偶尔也会礼貌地给你包上 Markdown 代码块。没有兜底解析的话，json.Unmarshal必然报错。所以我写了上面那个extractJSON函数，先去代码块再去首尾花括号。
第四，标题超长且带违禁词。LLM 生成的标题经常超过 60 字符，还动不动冒出来“最”“纯天然”“顶级”这些词。发了几个线上版本之后被运营反馈，我才把后处理那套逻辑加上去。现在这条规则已经沉淀成流水线的标准环节了。
第五，上游限流导致批量任务连环失败。一次性提交 50 个商品时，50 个 goroutine 同时打模型 API，直接触发限流。后来加了信号量限流 + 指数退避，批量任务的完成率从 60% 提升到 99% 以上。
6.3 排查技巧与问题速查表
我把平时遇到最多的问题整理成了一个速查表，方便你遇到类似情况直接对号入座：
| 现象 | 可能原因 | 排查手段 |
|---|---|---|
| 模型返回空内容 | prompt 太长/输入图无效 | 检查预处理输出，缩短 prompt |
| JSON 解析失败 | 模型输出带 markdown | 用 extractJSON 兜底 |
| 接口超时 | 图片过大 | 确认预处理阶段已执行 |
| 批量任务大量 429 | 并发超过上游限流 | 调小信号量，加退避重试 |
| 标题乱码 | 按字节截断中文 | 改用 rune 截断 |
| 生成内容与图不符 | VLM 幻觉 | 校验阶段重试一次，或调整 prompt |
| 详情页样式崩 | LLM 直接输出 HTML | 改为只输出结构数据，模板渲染 |
排查问题有个基本原则：先看日志，再猜原因。我的日志里每一单都有RequestID，每一个阶段都有耗时。遇到线上问题，第一步永远是grep req="xxx"拉出整条链路的时间线，而不是凭感觉调 prompt。这样定位问题通常不超过五分钟。
6.4 一个能救命的调试技巧：重放工具
最后分享一个我压箱底的小技巧。线上任务失败后，很多临时文件（比如预处理后的图片、模型返回的原始响应）会随着进程退出而丢失，导致你没法复现。我后来给流水线的失败分支加了一个“证据收集器”：任务失败时，自动把当前PipelineContext、模型原始响应、错误堆栈一起序列化成一个 debug 包，存到专门的目录。
调 bug 的时候，直接写一个小工具加载这个 pack，就能在本地完整重放当时的现场，不需要再调一次模型、烧一次钱。这看起来是个不起眼的工程细节，但在真实项目中，它节省的调试时间可能比整个流水线开发时间还多。
我个人在实际开发中的体会是，这类 AI Agent 流水线项目，真正决定成败的往往不是模型选得多强，而是工程细节有多扎实：图片处理、JSON 解析、超时重试、限流、日志、缓存，每一步都在给你的系统“续命”。把这一圈地基打好，后面换更强的模型、加新的场景，都只是换个 Stage 的事。
