用Go构建AI Agent流水线：从商品图自动生成淘宝详情页

最近几个月我用 Go 搭了一条 AI Agent 流水线专门干一件事把一张商品图变成一整套可以直接上架的淘宝详情页。这个想法源于一个非常现实的痛点上新节奏快、SKU 又多每个链接都要单独做详情页物料设计师排期永远不够用。我最初的设想很简单——让多模态模型先看懂商品图再让大模型生成文案最后用代码把内容组装成页面。听起来不复杂真正落地时却踩了不少坑。这篇文章把这套流水线的设计思路、核心代码、并发容错和真实成本完整复盘一遍希望能给同样想用 Go 做 Agent 自动化工具的朋友一些参考。1. 项目缘起一份详情页报价让我动了手1.1 商品详情页生产的真实成本做电商的朋友应该都能理解这个场景详情页不是一张图而是一整套图加文案的组合。首屏主图、卖点轮播图、参数规格表、使用场景图、售后说明一个链接点开用户要在这段滚动内容里完成对商品的全部认知然后决定要不要下单。所以每次新品上新都意味着一次完整的内容制作流程。传统做法是什么运营提需求、设计师拍照修图排版写文案一个链接的详情页素材从沟通到交付顺利的话半天赶上排期紧张磨两三天很正常。这里有个容易被忽略的问题模板是固定的但每个商品的卖点完全不同指望一套模板覆盖所有 SKU出来的详情页大多千篇一律转化效果自然打折。我当时手上正好有一批商品要换季上新二十几个链接都需要重做详情页。问了一圈外包报价单个链接设计费就抵得上半个月的模型调用成本。加上我们团队本身就有 Go 后端服务在跑我就动了念头与其等排期不如把这套流程标准化机器能做的让机器做机器做不了的才找人做。这才是这个项目真正的起点。1.2 为什么选 Go而不是 Python如果是纯 AI 研究项目第一反应肯定选 Python生态最全、教程最多。我自己也写 Python但在这个场景下我最终选了 Go原因很实在单二进制部署流水线要常驻服务器跑还得定时触发Go 编译出一个可执行文件扔上去就能跑不用折腾虚拟环境和依赖冲突。Python 在这点上要麻烦得多。goroutine 天然适合流水线并发一批商品进来每个商品走同一套流程相互之间完全独立这是教科书级别的并发场景。goroutine 加 channel 写 worker pool代码非常直接。调用大模型 APIGo 的生态没有 Python 那么丰富但基础 HTTP 调用和 JSON 处理能力绰绰有余。国内外主流模型平台基本都有官方或社区维护的 Go SDK做一个内部自动化工具完全够用。技术栈统一我后端主栈就是 Go把这条流水线作为独立服务接进现有系统后续也方便别人维护不用引入第二门语言。对比维度GoPython部署运维单二进制直接执行需要虚拟环境、依赖管理并发模型goroutine channel简单清晰多线程/异步心智负担稍重AI 生态SDK 较全但示例少最丰富实验成本低与现有后端整合同栈无缝接入需要额外桥接服务补充一句如果你的目标是快速验证不同模型效果、做研究型实验Python 更合适但如果你要做一个能长期跑、部署维护省心的内部工具Go 的性价比明显更高。工具选型没有绝对标准我选 Go 是冲着运行期省心去的。2. 流水线规划把一张图到一整套详情页拆成四段2.1 先拆任务再谈 Agent很多人一谈 AI Agent 就想着丢给大模型让它自己全干这个思路在实际项目中多半要翻车。我做完这个项目的最大体会是Agent 的本质是能自主完成一个子任务的单元流水线则是多个 Agent 的组合工作流。关键在先把任务拆清楚。我拆下来一张商品图到淘宝详情页至少包含四个子任务图像理解让多模态模型识别图片里是什么商品、颜色、形态、有没有文字、大致场景。文案生成基于视觉理解结果结合类目和目标人群写出主标题、卖点、参数表、品牌故事。页面组装把文案和图片素材放进详情页模板生成可发布的 HTML 或长图。输出管理重命名、格式校验、打包产物让运营拿到手的东西可以直接用。每个子任务对应一个专门的 Agent 或工具函数。我的核心设计思路是大模型负责生成和理解普通代码负责流程控制和格式校验。大模型不是不可靠而是你不能假设它每次都可靠所以可控的流程必须握在代码手里。2.2 中间数据契约一份 JSON Schema 定义了整条流水线拆完任务之后我做的第一件事不是写代码而是定义每站之间的数据契约。这是整个项目里最关键的决策之一没有之一。我定义了一份统一的商品信息结构type ProductInfo struct { Name string json:name Category string json:category SellingPoints []string json:selling_points Attributes map[string]string json:attributes CareNotes string json:care_notes HasText bool json:has_text Scene string json:scene }图像理解 Agent 输出这份结构文案 Agent 基于它生成内容渲染模块再拿它填模板。整条流水线本质上是一条数据管线每一站的输出就是下一站的输入。数据结构定好之后后面无论是调整 prompt 还是换模型只要保证输出兼容这份 JSON 就行其他模块完全不用动。这是很多人做 Agent 流水线时容易忽略的点模型可以换、prompt 可以调但中间数据契约必须稳定。数据接口一旦稳定下来你就有底气做各种优化否则改一处牵动全身项目越做越乱。2.3 编排框架的取舍为什么没上 LangGraph 也没用 Dify现在社区里的编排方案不少Dify 有可视化工作流LangGraph 有状态图Temporal 有工作流引擎。我也调研过最后都没采用理由分层说明。Dify 这类平台型产品优势是零代码、可视化、内置知识库适合快速搭建给非技术人员用。但我这条流水线要嵌进现有 Go 服务里Dify 是独立应用职责边界和能力托管方式跟我的需求不匹配。而且我需要精细控制并发、重试、持久化用平台反而绕。LangGraph 这类框架状态管理做得好但引入后抽象层更多学习成本不低核心逻辑还是得自己写。我的场景是线性流水线加少量分支用 Go 原生能力就能管理得清楚明白何必再包一层我的观点是编排框架不是用的人多就一定适合。判断标准很简单——项目里有几个人维护整个团队对这个抽象熟不熟不上框架能不能控制住复杂度对于个人项目或小团队内部工具先用原生能力把业务逻辑跑通等复杂度真上来了再引入编排也不迟。我给自己的要求是先能跑再谈优化。3. 图像理解与文案生成两个核心 Agent 的实现细节3.1 视觉 Agentprompt 决定看懂的程度视觉理解这一步我用的是通义千问的视觉模型 Qwen-VL 系列。选它主要因为接口稳定、中文理解好而且调用链路顺畅不需要额外折腾。这个 Agent 的代码本质就是一次多模态接口调用但 prompt 怎么写直接决定后面所有环节的质量。我第一版 prompt 写得太简略描述这张图片结果模型返回了一段优美的散文完全没法结构化使用。后来我把 prompt 改成强约束的结构化指令const visionPrompt 请识别这张商品图中的关键信息仅输出 JSON不要输出任何其他内容。 要求 1. 用简洁的中文词汇描述商品名称 2. 判断商品类目服装/数码/家居/食品/其他 3. 提取最多 5 个可见卖点例如材质、颜色、形态、设计细节 4. 如果图片中有文字请全部识别出来 5. 判断适用场景例如日常通勤、户外运动、居家 输出格式必须是合法 JSON { name: ..., category: ..., selling_points: [..., ...], image_text: , scene: ... }这里有一个特别容易被忽略的细节我在 prompt 里明确写了输出格式必须是合法 JSON。加上这句话模型输出的直接就是 JSON 文本省去大量清洗工作。否则模型偶尔会在代码块里包一层 json 标记解析时还得先剥壳。再补充几个实操细节图片预处理模型接口对图片大小有限制我通常在调用前先把商品图压缩到宽不超过 1024 像素JPEG 质量调到 80识别效果几乎不受影响速度和费用都更好。图片文字校验如果包装盒上有品名模型识别偶尔会出错。我在后面加了一道人工确认步骤把识别出的文字和原图一起展示给运营确认防止错字流进详情页。输出稳定性视觉模型的输出相对稳定但不是百分百稳定所以我对返回结果做 JSON Schema 校验字段类型不对就自动重试一次。3.2 文案 Agent卖点不是编出来的是对着事实推出来的图像理解拿到的是事实文案生成要做的是从这些事实里推导出卖点、组织语言、匹配场景。这里有一个很多 AI 文案翻车的根源模型没看过商品图全靠想象出来的内容要么空洞要么言之无物。我的做法是把视觉 Agent 输出的结构化事实完整塞进 prompt让文案 Agent 基于事实发挥严禁编造参数func (a *CopyAgent) Generate(ctx context.Context, info *ProductInfo) (*CopyResult, error) { prompt : fmt.Sprintf(你是一位资深电商文案专家请根据以下商品信息创作淘宝详情页文案。 商品名称%s 商品类目%s 可见卖点%s 场景%s 图片文字%s 规则 1. 主标题不超过20字要求有吸引力和信息量 2. 扩展出 3 到 5 条卖点每条不超过30字必须基于给出的卖点推演不得编造具体参数 3. 输出参数规格表只列出可从信息中推断的字段不确定的标注详见实物 4. 生成一段 80 字以内的品牌故事 5. 只输出 JSON { main_title: ..., selling_points: [..., ...], spec_table: [{key: ..., value: ...}], brand_story: ... }, info.Name, info.Category, strings.Join(info.SellingPoints, ), info.Scene, info.ImageText) // 调用模型 // 解析 JSON }有朋友会问为什么不直接把商品图丢给文案模型让它图文一起看答案是成本。多模态输入的 token 开销明显高于纯文本而且视觉结论已经在第一站结构化过了。流水线的一个优势恰恰是一次理解、多处复用——图片只被模型看一次后面所有环节都基于文字继续。这个决策帮我省了不少钱。实测下来一个商品从图片到完成文案多模态调用只在第一站发生一次文字模型调用三次以内就能搞定整体成本比我最初设想低了一个量级。3.3 结构化校验与纠错让模型自己修复自己的输出大模型的输出具有随机性哪怕 prompt 里写了只输出 JSON仍可能在个别情况下给出残缺结构。我在两个 Agent 后面都加了校验器用 Go 的 encoding/json 反序列化到 struct字段不合法就组装一条错误信息连同原本的结果一起回传给模型让它自己修复。这个循环实现不复杂for attempt : 1; attempt 3; attempt { raw, err : callModel(ctx, prompt) if err ! nil { return nil, err } var out CopyResult if err : json.Unmarshal([]byte(raw), out); err ! nil { repairPrompt : fmt.Sprintf(你上一次的输出无法通过 JSON 解析解析错误%s。请修正后重新输出合法 JSON。原始输出%s, err.Error(), raw) prompt \n repairPrompt continue } if out.MainTitle { prompt \n主标题不能为空请补充后重新输出。 continue } return out, nil }被校验器拦截的概率其实不高但这套重试机制多次救了我。最典型的一次模型把字符串数组输出成了逗号分隔的字符串JSON 解析失败重试一次后就正常了。如果没有校验器错误数据会直接进渲染模块最后生成一堆脏页面再回头排查就麻烦多了。这里是我对 Agent 的最小理解行动生成→ 检查校验→ 反馈错误信息→ 再行动修复。与其把 Agent 概念包装得花里胡哨不如先在真实流程里把这种循环用熟练。4. 模板组装与页面渲染内容如何变成能上架的详情页4.1 详情页的结构与模板设计拿到文案和图片素材后下一步是组装详情页。淘宝详情页在实际运营里通常是一张长图拼接或者是一段图文混排的富文本。我做的时候把页面拆成标准模块首屏主图加大字卖点、卖点轮播区、参数规格表、品牌故事区、售后与注意事项区。每个模块对应一个 Gohtml/template文件填充 Agent 生成的数据。这套模板化方案的好处是后续要调整视觉风格只改模板不碰流水线逻辑。4.2 模板变量填充与踩过的渲染细节Go 的html/template做动态页面非常自然。模板的大致形态是这样div classhero h1{{.MainTitle}}/h1 img src/images/{{.ImageName}} alt商品主图 / /div div classselling-points {{range .SellingPoints}} div classpoint{{.}}/div {{end}} /div div classspec-table {{range .SpecTable}} div classspec-rowspan classkey{{.Key}}/spanspan classvalue{{.Value}}/span/div {{end}} /div这个环节看起来简单实操中我踩过几个坑值得单独说说图片素材统一命名流水线里先把所有图片做尺寸归一化和统一重命名最终详情页只引用相对路径再一次性打包。否则每轮生成的产物文件名乱七八糟运营拿到手根本不知道怎么用。中文字体问题如果用 HTML 渲染成图片服务器上可能缺少中文字体页面会出现方块字。这个坑我部署时踩过后来在服务器上专门装好中文字体包解决。字数敏感详情页面向手机用户卖点太长会折行影响美观。我在渲染前对文案长度做了硬性校验超过上限的直接截断并告警保证产物至少是可用的。4.3 从 HTML 到最终页面我同时保留了两种输出项目做到后期我把最终输出做成两种形态适配不同使用场景。第一种是 HTML 源码。淘宝装修后台的自定义页面支持粘贴 HTML运营可以直接把生成好的代码粘进去微调后发布。这是最轻量的方式不依赖任何额外组件。第二种是长图 PNG。有些平台不方便贴代码发布一张整体长图更省事。我用 chromedp 这个 Go 库启动 headless 浏览器渲染 HTML再截取完整页面生成长图。chromedp 有两个细节值得注意无显示环境下要设置好--disable-gpu等参数否则偶尔渲染出空白页截图前必须等图片资源全部加载完成用固定time.Sleep不够稳我后来改成轮询页面里的加载完成标记可靠性高了很多。5. 并发、重试与容错从演示能跑到批量能跑5.1 worker pool用 goroutine 把批量任务撑起来演示场景下一次处理一张图串行完全没问题。但真实场景是一批商品图丢进来二十个五十个一个个串行太慢了。Go 的 goroutine 在这里派上大用场。我用 channel 实现了一个简单的 worker pool主协程把所有商品图片路径塞进 job channel固定数量的 worker 从 channel 取任务跑完整条流水线。func main() { jobs : make(chan string, 100) results : make(chan Result, 100) var wg sync.WaitGroup for i : 0; i 4; i { wg.Add(1) go func(workerID int) { defer wg.Done() for imgPath : range jobs { result : processOne(ctx, imgPath) results - result } }(i) } go func() { for _, path : range allImagePaths { jobs - path } close(jobs) }() // 收集结果并汇总 }这段代码不复杂但它是项目从给自己用进入给团队用的分水岭。并发带来吞吐量提升的同时也带来新问题并发调用大模型 API 时很容易触发平台的限流。5.2 限流与成本并发不是越高越好大模型 API 基本都有并发限制和 QPS 限制。我一开始把 worker 拉到 8 个跑了不到一分钟就开始收到 HTTP 429 限流错误。后来调回 4 个再加限流控制才稳定。用标准库golang.org/x/time/rate可以很便宜地实现限流limiter : rate.NewLimiter(rate.Every(500*time.Millisecond), 2) err : limiter.Wait(ctx)每次调用模型前先过一道限流器就能把请求间隔控制在合理范围。限流参数要按平台文档来不同模型限制不同宁可保守一点也不要频繁踩 429。成本控制上我的经验是看清楚每次调用花多少钱。视觉模型和文字模型计费单位不同图片大小影响 token 数prompt 长度也影响 token 数。我后来给流水线加了日志记录每个商品的调用成本和总成本。只有拿过一次真实账单你才知道这个工具到底值不值。5.3 失败恢复让流水线在中断之后能续跑这是一个我一开始完全没做、后来被坑惨的功能。详情页生成中间步骤多一旦某个商品在文案 Agent 那一步挂掉整条流水线就会中断。如果中断发生在深夜定时任务里第二天早上才发现这批产出基本作废。我后来加了一个简单的任务状态持久化每个任务开始前先在本地 SQLite 里记一条记录状态是 pending进入某个 Agent 调用前更新为 processing 并记录当前阶段成功后更新为 done。下次流水线启动时扫描所有不是 done 的任务从断点继续跑。用 SQLite 而不是内存 map是因为进程可能重启内存状态会丢。SQLite 文件放本地零运维成本对单机流水线足够。表结构很简单CREATE TABLE IF NOT EXISTS tasks ( id TEXT PRIMARY KEY, image_path TEXT, status TEXT DEFAULT pending, stage TEXT DEFAULT , error_msg TEXT DEFAULT , created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP );有了这张表出问题后我不再焦虑。晚上跑挂了第二天看一眼日志把失败任务重跑一遍就行已经完成的商品不会重复生成。5.4 重试设计指数退避和随机抖动前面说过Agent 内部有输出不合法 JSON的自修复循环。但还有一类错误来自网络波动或 API 临时故障。针对这类错误我做了指数退避重试这是实用性最强的策略。func retry(ctx context.Context, fn func() error, maxAttempts int, baseDelay time.Duration) error { for attempt : 1; ; attempt { if err : fn(); err nil { return nil } else if attempt maxAttempts { return err } delay : baseDelay * (1 (attempt - 1)) delay time.Duration(rand.Intn(500)) * time.Millisecond select { case -time.After(delay): case -ctx.Done(): return ctx.Err() } } }指数退避为什么一定要加随机抖动如果不加多个 worker 同时失败时会在同一时刻重试形成重试风暴反而把原本就紧张的 API 打得更过载。加一个 0 到 500 毫秒的随机值能明显降低同频碰撞概率。这是我做分布式系统时学到的经验放在 Agent 流水线上同样适用。6. 实测效果与成本账我把这个工具用了三个月之后6.1 一批真实商品跑下来的数据工具能稳定跑之后我拿一批 30 个 SKU 的商品图真实跑了三个月分享几个有参考价值的数据指标实测数据单商品平均耗时约 3 到 5 分钟30 个 SKU 整批耗时约 1.5 到 2 小时产物可直接使用率约七成单商品模型调用成本几毛到 1 元人民币平台的 API 限制实际上是主要耗时来源真正代码处理时间几乎可以忽略。这说明瓶颈在模型接口不在 Go 程序本身。生成结果里大约三成需要人工介入一半是文案需要微调一半是视觉识别错误需要确认。也就是说完全不用人工审核的全自动方案目前还做不到但AI 生成加人工微调已经比纯人工从零开始写快了一个量级。我自己的体会是这个项目真正的价值不是省钱而是把从 0 到 1的空间释放出来了。以前上新前最头疼的详情页物料现在变成一条可控的流水线运营同事可以随时上传图片、生成详情页不再被设计师的排期卡着。6.2 人工介入的必要环节尽管流水线自动化程度高有两个环节我坚持保留人工介入。第一是主图和核心卖点的审核。详情页直接面对消费者一个错误参数或有误导性的卖点轻则退货重则投诉。机器可以生产但人必须把关。系统里做了一个简单的待审核队列运营确认后产物才算正式完成。第二是图片文字的人工确认。模型识别包装文字偶尔出错比如咖啡识别成珈啡这种错误放进详情页非常低级。我在第一版吃过亏后来宁可多花 10 秒让人确认也不让错字溜进发布环节。6.3 后续可能的扩展方向这项目目前停在内部工具阶段但我会继续沿几条线扩展。一是从批处理走向实时 API。现在流水线是批量文件输入后续包一层 HTTP 接口让运营在后台网页直接上传图片、实时预览详情页、在线编辑文案、一键导出就变成真正的 SaaS 化小工具。二是从单图生成走向多图组合。当前输入是 1 张商品图输出主要靠文本和模板。后续可以让 Agent 同时处理多张图白底图、场景图、细节图在模板里做更复杂的排版组合。三是跨渠道输出。淘宝详情页、京东主图、拼多多长图结构其实大同小异。只要把模板层抽象成多渠道适配同一份结构化数据就能产出多个平台的素材边际成本极低。最后分享一个最朴素的建议这类项目不要追求一步到位。先把从输入到输出的最小闭环跑通再逐步加并发、持久化、审核流程、多渠道输出。我第一版连错误恢复都没有拿了 10 张图硬跑跑通了才敢加量。先让它能跑比让它跑得完美重要得多。