一张商品主图丢进去几分钟后吐出一整套可以直接上架的淘宝详情页——主标题、卖点区块、规格参数、场景描述、售后说明全齐。这就是我用 Go 搭的一条 AI Agent 流水线在做的事。严格说它不是单独调用一次大模型而是把“看图识别商品属性、拆解用户买点、分模块生成文案、按版式组装 HTML、最后渲染成详情页”这几个环节串成了一条自动化的 Agent 链路。这条链路搭好之后原来需要设计师、运营、文案三个人来回折腾两三个小时的活压缩到了十分钟以内。这篇文章把我整个拆解过程、选型逻辑、核心代码和踩过的坑完整记录下来给那些想在电商场景里落地 AI Agent 的同学一个可以参考的实战样本。1. 为什么拿 Go 来搭这条 AI Agent 流水线1.1 先搞清楚AI Agent 在这一行到底解决什么问题我一开始也天真过觉得详情页生成这事直接写脚本掉大模型 API 不就行了稍微想深一层就发现根本不是那么回事。一张商品图要变成详情页中间隔着的不是一次生成而是一次完整的“理解—决策—生产”过程先判断这是什么商品、什么材质、什么风格然后要想清楚卖给谁、主打什么卖点再决定哪些内容放主标题、哪些放卖点区、哪些放场景图最后还得套进淘宝详情页的版式规范里。这种多步骤、多模型、多决策的链路特别适合用 Agent 的方式去编排。Agent 跟普通脚本最大的区别在于它会根据上一步的输出动态决定下一步怎么做而不是把所有逻辑写死在代码里。比如视觉模型识别出商品是“哑光陶瓷杯”那文案模块的 prompt 会自动加强“质感”“温度”“办公场景”的方向如果识别出来是“户外保温杯”prompt 又会偏重“续航”“便携”“户外运动”。这一步的动态分流用传统 if-else 也能写但模型返回的结果千奇百怪判断条件会越写越多用 Agent 编排之后决策逻辑收敛到 prompt 和结构化输出里反而好维护得多。1.2 Go 在 AI 流水线里的位置选 Go 而不是 Python是我在动手之前反复权衡过的决定。Python 在 AI 生态上确实无敌做原型最快但这条流水线的核心不是模型训练而是工程化编排——多路并发调用、任务状态管理、中间结果缓存、模板渲染这些恰恰是 Go 的强项。尤其是并发视觉识别、文案生成、图片处理这几个环节之间没有强依赖完全可以并行跑。Go 的 goroutine 加 errgroup写出来的并发代码比 Python 里用 asyncio 或者 multiprocessing 要直观太多了。部署也是现实问题。这条流水线要跑在服务器上定时处理商品图Go 编译出来是单一二进制文件扔到服务器上就能跑不需要装 Python 环境、不需要管理一堆 pip 包。我实际部署的时候连 Dockerfile 都没写直接 scp 一个编译好的文件上去systemd 一托管就完事了。另外生态上也没有想象中那么贫瘠跟 OpenAI 兼容协议的模型服务对接有 go-openai 这个库HTML 渲染用标准库 html/template 就够图片处理用标准库 image 加一个压缩库也覆盖了。真到了要扩展的时候Go 的生态足够撑起这条链路的全部需求。1.3 我最终确定的技术栈清单环节选型理由语言Go 1.22并发模型优秀、部署简单、单一二进制模型接入go-openai OpenAI 兼容协议支持视觉模型和文本模型统一调用视觉识别多模态模型返回 JSON一次请求拿到商品全部属性减少链路环节文本生成LLM 流式生成分模块调用避免长文本截断便于分段审核并发编排errgroup SetLimit并发处理多个商品同时限制并发保护限流模板渲染html/template内置安全转义防注入满足详情页 HTML 输出图片处理标准库 image 压缩库裁剪、压缩、加水印够用不折腾另外我在本地还起了一个极简的管理面板用来人工审核中间结果这个后面会细说。整体原则就一个能用标准库就不引第三方能少一层中间件就少一层。因为 AI 链路本身的不确定性已经很足基础设施越简单越好排查问题。2. 从 1 张商品图到详情页流水线是怎么拆的2.1 先看整条链路的骨架整条流水线我拆成了五个阶段每个阶段都有明确输入和输出上一个阶段的输出就是下一个阶段的输入。第一是商品主图识别产出结构化的属性 JSON第二是卖点提炼与人群匹配产出一份卖点优先级列表第三是分模块文案生成产出主标题、卖点文案、规格说明、场景文案、FAQ 五块文本第四是版式化与人工审核产出一份可以直接渲染的页面结构数据第五是 HTML 渲染与图片处理最终合成详情页文件。这个顺序看起来是线性的实际上执行的时候阶段二和阶段三以及部分文案的生成是并行的靠一个编排器来统一调度。我特意在第四阶段留了人工审核的口子。AI 生成的文案直接上架风险太高平台有违禁词审核消费者对不靠谱的描述也会带来售后问题。所以整条流水线跑完之后不是立刻出成品而是先出一个可编辑的中间态运营在这个状态下改完再渲染终稿。这一步看起来多了一道流程实际上反而是缩短总时长的关键——人工只需要改错不需要从零开始写工作量从两三个小时降到了十几分钟。2.2 第一步多模态识别抽取商品属性这一阶段的任务很明确把一张商品主图变成一份规格化数据。我设计了一个固定的 JSON Schema要求模型严格按这个结构返回。给一个具体例子当输入一张“奶油白色的不锈钢保温杯”图片时模型返回的大概是下面这样的数据{ product_name: 316不锈钢保温杯 500ml, category: 水具/保温杯, style: 简约现代, color: 奶油白, material: 316不锈钢, capacity: 500ml, target_users: 都市白领、户外运动人群, feature_keywords: [轻量便携, 316不锈钢内胆, 长效保温, 一键弹盖], estimated_scene: [办公室, 通勤路上, 户外徒步] }这里的关键是把视觉模型当成“结构化数据抽取器”而不是“看图说话”。所以 prompt 里我必须写清楚只返回 JSON不要任何解释字段名严格用我给定的枚举不确定的字段可以填空但不要编造。模型一旦开始自由发挥后面的文案生成阶段就会被脏数据带偏整条链路的质量就崩了。为了稳我在代码层还加了一道校验和一次重试机制JSON 解析失败或者必填字段缺失就自动重试一次重试还失败就转人工处理。这个设计在后面踩坑部分会详细讲。2.3 第二步卖点提炼与人群匹配拿到了属性 JSON 之后第二步是把“产品有什么”翻译成“用户为什么买”。这一步我同样用 LLM 来做输入是属性 JSON输出是一份按优先级排好的卖点列表。比如同一款保温杯给“职场白领”讲的是“一键弹盖单手操作会议室进出自如”给“户外人群”讲的是“500ml 容量刚好放进取架杯位316 内胆耐腐蚀”。如果人工运营来做这件事脑子里过一遍人群和场景基本就有数了但要写成 prompt 让模型也达到这个水平就需要给出足够清晰的人群定义和卖点评分规则。我给模型提供了一份人群画像库内置了都市白领、学生党、母婴人群、户外运动、送礼场景五类模板每类模板都有对应的文案偏好。模型的任务是先判断这张商品图最匹配哪一类或哪几类人群然后从属性 JSON 里挑出 3 到 5 个核心卖点按“用户敏感度”从高到低排序。这一步输出的不只是文案素材还是一份后续所有文案模块的统一大纲确保主标题、卖点区、详情段落讲的是同一件事不会各说各话。2.4 第三步分模块生成文案卖点定完之后就进入了文案生产阶段。我没有让模型一次性生成整篇详情页而是拆成了五个独立模块分别调用主标题、卖点区块、规格参数表、场景描述、FAQ 问答。每个模块是一个独立的 prompt 任务这样好处非常明显。第一是即使某个模块生成失败也不会牵连整篇内容第二是每个模块的文本长度可控不容易触发大模型的输出截断第三是人工审核时可以只改有问题的模块不用重写整篇。这五个模块我并行去跑全部完成后统一进入下一个阶段。实测下来五个模块并行比串行快了将近四倍而且单个模块的 prompt 设计更聚焦生成质量明显高于一个超级长 prompt 让模型输出一整篇。每个模块的 prompt 风格也不一样。主标题要求 20 字以内、含核心关键词、不用夸大词卖点区块要求每条 30 字左右、必须有数据支撑规格参数表则直接从属性 JSON 映射不做任何文学加工。这个模块化设计的思路跟代码设计里的单一职责原则是一回事。把复杂任务拆小让每个子任务只有一个目标模型的输出质量天然会更高。2.5 第四步版式化与人工审核模块化文案生成完我让所有文本收敛到一个统一的结构化对象里这个对象描述了详情页的版式骨架。比如第一屏是主标题大图区第二屏是三个卖点卡片第三屏是规格表第四屏是场景长图第五屏是 FAQ。我定义了一套简单的版式 DSL允许运营调整区块顺序、增删区块。这一步的设计相当于是把“AI 出草稿”和“人工定稿”解耦了。草稿的版式由模型根据商品类目自动判断比如美妆类目会前置“使用前后对比”数码类目会前置“参数配置”再经过运营在管理面板上微调最终才确认渲染。这个人工审核环节还有一个作用就是给模型输出做一个安全过滤。我在管理面板里整合了违禁词扫描文案生成完先自动跑一遍过滤命中敏感词就在面板上标红运营一眼就能看到需要改哪里。电商平台的审核规则每个阶段都在变与其把希望全压在 prompt 里让模型自我约束不如在工程层面加一道可控的检查程序这是我认为整个链路里性价比最高的一步。3. 核心模块的 Go 实现3.1 多模态识别的调用实现第一个要写的就是视觉识别这一环。我用 go-openai 库调一个支持图片输入的对话模型把商品图转成 Base64然后塞进 message 里。下面是核心代码func recognizeProduct(ctx context.Context, imgBase64 string) (*ProductInfo, error) { client : openai.NewClient(os.Getenv(AI_PROVIDER_KEY)) dataURL : data:image/jpeg;base64, imgBase64 resp, err : client.CreateChatCompletion(ctx, openai.ChatCompletionRequest{ Model: gpt-4o-mini, Messages: []openai.ChatCompletionMessage{ { Role: system, Content: 你是资深电商视觉分析助手。只输出 JSON不输出任何其他内容。, }, { Role: user, Content: []openai.ChatMessagePart{ { Type: openai.ChatMessagePartTypeImageURL, ImageURL: openai.ChatMessageImageURL{ URL: dataURL, }, }, { Type: openai.ChatMessagePartTypeText, Text: 请根据这张商品图提取以下字段并严格返回 JSON 格式product_name, category, style, color, material, capacity, target_users, feature_keywords, estimated_scene。缺失的字段填空字符串或空数组不要编造。, }, }, }, }, ResponseFormat: openai.ChatCompletionResponseFormat{ Type: json_object, }, }) if err ! nil { return nil, err } var info ProductInfo if err : json.Unmarshal([]byte(resp.Choices[0].Message.Content), info); err ! nil { return nil, err } return info, nil }有两个细节要特别提醒。第一是data:image/jpeg;base64,这个前缀不能省很多模型服务就是通过这个前缀来判断图片格式的我一开始漏了它服务端直接报错。第二是ResponseFormat强制 JSON 输出这个参数在生成结构化数据时非常重要。如果不强制模型偶尔会夹带几句解释性文字你的 JSON 解析就会崩。实测下来加上这个参数之后解析失败率从百分之十几降到了百分之一以下。3.2 用 errgroup 做并发编排第二步的卖点提炼、第三步的五个文案模块之间并没有前后依赖可以全部并发。Go 里最顺手的并发编排工具是errgroup配合SetLimit控制并发数代码结构非常干净。func generateDetailContent(ctx context.Context, info *ProductInfo, audience string) (*DetailContent, error) { g, ctx : errgroup.WithContext(ctx) // 并发数控制在 3避免撞上模型服务限流 g.SetLimit(3) content : DetailContent{} g.Go(func() error { headline, err : generateHeadline(ctx, info, audience) if err ! nil { return err } content.Headline headline return nil }) g.Go(func() error { sellingPoints, err : generateSellingPoints(ctx, info, audience) if err ! nil { return err } content.SellingPoints sellingPoints return nil }) // 其他模块规格表、场景文案、FAQ 同理每组 g.Go 包一个生成函数 return content, g.Wait() }SetLimit(3)这个数字是我试出来的。一开始并发拉满五个 goroutine 同时往外打请求结果没跑几条就被模型服务限流报 429 错误。后来我把并发压到 3配合超时重试整条链路稳定性明显好转。这里要理解一个点errgroup里任何一个 goroutine 返回错误g.Wait()就会立刻返回这个错误同时WithContext会取消共享的 Context其他还在跑的 goroutine 也会收到取消信号退出。所以在处理模型调用时每个子任务内部都应该检查ctx.Err()避免白白在网络请求上浪费时间。3.3 从结构化数据到 HTML 模板所有文案生成完毕接下来就是把数据渲染成详情页 HTML。我用了标准库html/template它自带 HTML 转义能力可以防止模型输出的内容带着奇怪的字符把页面结构搞坏。我定义了一个页面数据结构包含区块类型和内容字段然后用一套预置的 CSS 来控制视觉效果。type PageSection struct { Kind string // hero | feature | spec | scene | faq Title string Body string Items []string } type DetailPage struct { ProductName string Sections []PageSection }渲染的时候一个简单的 range 循环加 switch 就能把结构化区块映射成不同的 HTML 片段。比如hero区块输出大标题feature区块循环输出三个卖点卡片spec区块输出表格faq区块输出折叠面板。这套设计的好处是模板和业务逻辑分离以后要适配其他平台拼多多、抖音等的详情页规范只需要改模板文件业务代码完全不用动。配合template.FuncMap我还能在模板里直接调用contains、trim这类字符串函数做展示层面的微调非常灵活。3.4 图片处理与压缩详情页不能只有文字还需要对原始商品图做加工。我这里做了一个独立的图片处理模块负责三件事裁剪出适合作为头图的比例、压缩图片体积、叠加位置水印。Go 标准库image在这块能力非常够用下面是压图的一个核心片段func compressImage(raw []byte, maxWidth int, quality int) ([]byte, error) { img, _, err : image.Decode(bytes.NewReader(raw)) if err ! nil { return nil, err } bounds : img.Bounds() ratio : float64(maxWidth) / float64(bounds.Dx()) if ratio 1.0 { // 宽度已经足够小直接用原图 } else { img resizeImage(img, maxWidth, int(float64(bounds.Dy())*ratio)) } var buf bytes.Buffer if err : jpeg.Encode(buf, img, jpeg.Options{Quality: quality}); err ! nil { return nil, err } return buf.Bytes(), nil }图片压缩这里有一个经验值淘宝详情页的图宽一般建议不超过 750px单张图大小控制在 200KB 以内否则影响买家加载速度。jpeg.Quality我通常设 85视觉损失肉眼几乎看不出但体积能压掉百分之六七十。还有一个坑是 Go 的image.Decode默认只注册了 PNG 和 JPEG 解码器如果商品图是 WEBP 格式会直接报image: unknown format。所以上线前我在init()里加了_ golang.org/x/image/webp这个匿名导入把这个坑提前堵上。4. 实操过程中踩过的坑4.1 多模态识别结果经常不按 JSON 规范走我最开始的 prompt 写得比较随意结果模型偶尔会返回{product_name: ...} 以上就是这款商品的信息末尾夹带一句废话直接导致json.Unmarshal失败。后来我做了三重防护。第一prompt 里强制写明“只输出 JSON不要输出任何其他内容”并且用 ResponseFormat 锁定 JSON 输出。第二代码里加上二次清洗逻辑如果直接解析失败尝试从返回内容里截取第一个{到最后一个}的子串再解析。第三解析失败自动重试一次重试还失败就把这条任务标记为“人工处理”丢进管理面板的待审核列表。这三重防护下来识别阶段基本不会阻塞整条流水线。4.2 长文案生成经常被截断第一次让模型一口气生成整篇详情页文案时输出在三四百字左右就开始断句后半段直接没了。这不是模型笨是我 prompt 设计的问题。后来我改成模块化生成每个模块控制在 200 字内这种情况基本消失。还有一个小细节检查返回结果的FinishReason字段。如果某个模块出现length而不是stop说明输出被 max tokens 截断了这时候需要拼接下一次续写结果或者干脆把该模块的 prompt 再拆小重跑一次。我在代码里加了一个简单判断FinishReason length时自动对该模块重试一次实测能救回不少截断内容。4.3 并发拉满被接口限流这个前面提过但值得单独立一条。模型服务商给免费额度或者基础套餐的 RPM每分钟请求数限制通常很低最开始我五个模块全并发经常撞 429。用errgroup.SetLimit(3)把并发压下来之后情况立刻好了。但有些时候模型服务本身的响应很慢一个请求要二十秒三个并发同时被占住新的任务就会排队业务流程会拖慢。我的处理办法是给请求加一个合理超时时间比如 45 秒超时就返回错误触发重试不能让一个慢请求卡死整条队列。配合指数退避策略第一次重试等 1 秒第二次等 3 秒第三次等 8 秒几次实测下来基本不会再连续撞限流。4.4 详情页图片路径和字体渲染问题这是渲染阶段最容易忽视的坑。模型生成的 HTML 或者模板里的图片路径如果不做处理直接引用本地相对路径打开详情页的时候全部裂图。我的做法是在渲染前把图片路径统一改写为https://开头的绝对路径或者直接把小图转成 Base64 内嵌进 HTML。另外详情页预览时中文字体乱码也坑过我一次服务器上没装中文字体生成的图片和 PDF 预览全变成方块。因为最终详情页是 HTML 格式在平台上渲染字体问题不像做 PDF 那么突出但如果以后要扩展生成预览图功能服务器必须安装中文字体包比如fonts-wqy-microhei。4.5 模型输出里混进特殊符号导致版面错乱AI 生成文案偶尔会带一些排版符号比如 markdown 的**、#、-或者奇怪的引号。这些东西直接塞进 HTML 模板轻则显示异常重则把整个页面结构撑烂。我用html/template之后默认转义能挡掉大部分危险字符但 markdown 符号还是会原样显示出来。所以我给文案加了一层清洗函数去掉**、##、行首的-把全角引号转成半角同时把连续多个空格压缩成一个。这个清洗函数在模板渲染前统一执行成本极低收益非常明显属于那种不做不会立刻发现、做了就回不去的优化。5. 效果复盘与扩展方向5.1 一条流水线实际能跑出什么拿一款保温杯实测输入一张白底商品图流水线跑完大约花了 6 分钟其中视觉识别约 15 秒卖点提炼和五路文案并发约 40 秒人工审核改动了两个卖点的措辞花了 10 分钟渲染合成不到 1 秒。对比原来人工流程——找参考款、想卖点、写文案、排版、切图——怎么也要两三个小时而且每次改版都要从头再来。现在这个效率提升是非常直观的。环节人工方式AI 流水线差距商品属性梳理约 20 分钟约 15 秒80 倍卖点提炼与文案约 60 分钟约 40 秒90 倍版式设计约 60 分钟约 5 分钟含审核12 倍图片处理与合成约 30 分钟约 1 分钟30 倍整体2-3 小时10-15 分钟10 倍以上当然这里有个前提人工审核仍然需要一个人但他的角色从“从零创作”变成了“修改和确认”。AI 生成的内容质量大概在 70 分左右够看但不一定能直接上架经过运营修改后能到 90 分。这个“AI 生成 人工微调”的组合是目前电商内容生产里最现实的落地路径不是要完全取代人而是把人的时间从重复劳动里解放出来。5.2 后面还能往哪些方向扩展这条流水线的架构决定了它的扩展成本很低。现在我在规划三个方向的改进。第一是多平台适配拼多多、抖音电商、小红书对详情页格式的要求各不相同我现在已经把版式数据和渲染模板分离了理论上只需要为每个平台写一套模板就能复用整条链路。第二是 A/B 测试能力同一个商品生成多个版本的卖点文案和版式上线后根据转化率数据反馈回模型不断优化 prompt形成一个数据闭环。第三是商品图输入从单张扩展到多张比如支持详情页里的场景图、细节图、对比图自动挑选和拼接进一步提升整条链路能输出的内容完整度。这些方向都不需要推翻现有代码而是在现在的结构化中间层上往里再加节点就行。我个人在实际操作中最大的体会是搭 AI Agent 流水线真正的难点不在模型选型也不在怎么调 prompt而在于把一条模糊的业务需求拆成可执行的工程链路并且每一步都留好后路。模型一定会出错并发一定会撞限流生成结果一定会偶尔离谱这些都不是设计失败而是链路中必须被吸收掉的不确定性。只要每一层都有校验、重试和人工兜底整条流水线就能在各种意外中稳定往前跑。最后再分享一个小技巧所有中间产物——视觉识别的 JSON、每个模块的文案、版式结构数据——都会落一份日志到本地。出问题的时候翻中间产物比翻代码日志好排查得多因为你能清楚看到是哪个环节把整条链路带偏了。这个习惯我从第一天保持到现在救过我不下十次。