朋友在淘宝开店，拿着一张随手拍的保温杯照片问我：能不能帮他出一整套商品详情页？我说能，但要给我两天时间。他接着问：那二十个SKU呢？我当场沉默了。那会儿我电脑里还摊着PS、AI和各种排版软件，来回切换，调色、抠图、写文案、排版，每一步都是重复劳动。
后来我花了两周时间，用 Go 自己搭了一条 AI Agent 流水线，从 1 张商品图进去，到整套详情页出来，中间基本不用人管。这篇文章就是把这条流水线从选型到落地、再到踩坑避坑的全部过程拆开讲一遍，适合正在做电商素材生产、又不想被低代码平台绑死的开发者，也适合想用 Go 练手搭建 AI Agent 但不知道从哪里下手的同学。
1. 为什么拿 Go 写 Agent 流水线，而不是 Python 或低代码平台
1.1 这是一道编排题，不是算法题
先说我自己的认知转变。最开始我也觉得，做 AI 流水线不就应该用 Python 吗？模型生态、图像库、教程几乎全是 Python 的。但真正动手之后我发现，我想要的不是什么模型训练、微调，也不是在 Python 生态里反复试错，而是一个稳定的任务编排系统：把一张图片送进去，经过解析、文案生成、图像处理、模板装配这几个环节，最终吐出一个目录结构完整的详情页包。
Agent 流水线的本质是编排，不是算法。模型能力是别人已经做好的，API 也是现成的，你真正要解决的是：环节怎么拆、数据怎么传、失败怎么重试、并发怎么控制、产物怎么落盘。而这恰好是 Go 最舒服的战场。goroutine 处理并发任务，channel 做环节之间的数据流转，结构体定义中间产物，一个静态编译的二进制扔到任何一台电脑上都能跑，不用配 Python 环境、不用装 conda、不用担心依赖冲突。
1.2 为什么不直接用 Dify、Coze 这类现成平台
我知道很多人看到"AI 流水线"第一反应是 Dify、Coze 这类低代码平台。它们确实能快速搭出一条"输入图片，输出文案"的流程，我之前也试过。但真正要拿去做电商详情页生产的时候，卡住了：
- 详情页最终是一套 HTML/CSS 页面，不是一段文本，平台层面的自定义模板能力非常有限；
- 我需要把抠图、缩图、场景合成这类本地图像处理和 LLM 调用混合编排，低代码平台的编排很不顺手；
- 产物要打包成 zip、要生成预览页、要方便运营反复审稿，平台给不了这么细的交付控制；
- 我手里的商品数据要想沉淀成结构化 JSON，方便后续复用和人工微调，平台的数据流很多人不透明。
结论是：低代码平台适合快速验证想法，不适合做固定生产力的交付工具。当一条流水线要反复跑、要精准控制每个输出、要变成团队的生产工具时，自己用代码写编排是最稳妥的。
1.3 Go 在 AI 生态里的真实位置
实话实说，Go 的图像生态和 Python 没法比。但 Agent 流水线不需要你在 Go 里从零实现图像分割、语义理解，这些都是通过 API 调用或者外部工具完成的。Go 负责的只是"调度"和"组装"。
举个具体例子：抠图这个环节，我可以用 Go 起一个 HTTP 请求去调现成的分割服务，也可以用exec.Command去调一个本地的 Python 脚本，Go 只负责拿到透明底 PNG 之后继续走流程。这是很务实的分工——让合适的工具干自己擅长的事，Go 做粘合层。
另一个 Go 的天然优势是部署。流水线做出来后，我把它编译成一个agent-pipeline二进制文件，运营同学的 Windows 电脑上双击或者拉一个命令行就能用，不需要他们装任何运行环境。这一点在落地时的价值怎么强调都不过分。
2. 流水线骨架：把"做详情页"拆成可以单独重试的环节
2.1 一张图进去，一个目录出来
在动手写代码之前，我先把人工做详情页的流程拆了一遍。人工是怎么做的？
- 看商品图，提取品类、颜色、材质、卖点这些基本要素；
- 想标题、想主图卖点、写详情文案、罗列规格参数；
- 修图：抠白底图、调色、做场景合成、按平台的尺寸要求切片；
- 排版：把文案和图片按详情页的通用结构组合成页面。
这个过程映射到流水线上，就是四个独立的 Agent 环节：视觉解析（analyze）、文案生成（copy）、图像处理（imgs）、模板装配（render）。四个环节串成一条线，前一环的输出就是后一环的输入。
跑的时候，流水线在执行目录下建一个workspace文件夹：
workspace/ ├── meta.json # 视觉解析输出的商品结构化数据 ├── copy.json # 文案生成输出的所有文字素材 ├── images/ # 图像处理产出的所有图片切片 └── pages/ # 模板装配产出的最终详情页这个目录结构就是整条流水线的"内存"，环节之间不共享任何全局状态，全部通过文件 + JSON 传递。好处非常直白：任何一个环节挂了，你只需要单独重跑那一步，不用从头再来。
2.2 中间数据契约：所有 Agent 只认 JSON
流水线里最容易翻车的地方是环节之间的数据格式各说各话。我一开始也走过弯路，每个 Agent 都输出自己顺手的数据结构，结果连到第四环的时候发现，字段名对不上，气得想拍桌子。
后来我定了一条铁律：环节之间只通过 JSON 通信，而且每个 JSON 的结构在编译期就定死。比如视觉解析输出的是一个GoodsMeta结构：
type GoodsMeta struct { Name string `json:"name"` Category string `json:"category"` Color string `json:"color"` Material string `json:"material"` Size string `json:"size"` Style string `json:"style"` SellPoints []string `json:"sell_points"` Scenes []string `json:"scenes"` RawText []string `json:"raw_text,omitempty"` }这个结构体同时作为 JSON Schema 传入多模态模型的请求里，让模型按这个结构输出。后续文案 Agent 和图像处理 Agent 读到的永远是这个结构化的 GoodsMeta，代码里直接用类型安全的 Go 结构体解析，完全不碰"字符串里抠信息"这种事。
2.3 流水线必须容忍单个环节挂掉
真实场景下，任何第三方 API 都可能超时，任何模型都可能给出意料之外的输出。所以在设计流水线的时候，我直接把"失败"当成正常状态来处理，而不是意外。
每一环都做了这几件事：超时控制、指数退避重试、失败兜底。比如文案生成环节，如果调用模型超时了，就间隔 1 秒、2 秒、4 秒地重试三次，重试还不行就把这个环节标记为失败，但流水线不会直接退出，而是用一个可手工编辑的占位文件继续往下走，等人来补。
这也是我把中间产物全部落到文件的原因：流水线挂了不可怕，可怕的是挂了你没有入口去改中间状态。现在 meta.json、copy.json 都摆在那里，运营同事可以直接打开手动改，改完重新跑后续环节就完成了人工兜底。
3. 商品信息抽取 Agent：让模型先学会"看图说话"
3.1 为什么第一个环节必须是结构化抽取
一开始我想偷懒，想着直接把原图丢给文案 Agent，让它"看着图写文案"。结果写出来的东西天马行空，因为模型在长上下文里同时看图又看长 Prompt，非常容易跑偏。
后来我把问题拆开了：文案生成需要的是"信息"，不是"像素"。如果先让一个多模态模型看完图，输出一份规整的商品元数据（是什么、什么颜色、什么材质、有什么设计点），后面的文案 Agent 拿到的就是干净、可靠的输入，发挥空间就大多了。
这就像拍电影之前先出剧本大纲一样。大纲错了，后面全错；大纲对了，后面的发挥就有章法。
3.2 用多模态模型把图片转成结构化 JSON
视觉解析环节的实现，本质上是一次多模态模型调用。我用的是 OpenAI 兼容接口，在 Go 里可以直接用官方的openai-goSDK，也可以通过任何兼容 HTTP 接口调用。核心是把GoodsMeta的 JSON Schema 写进 Prompt，然后要求模型只能输出纯 JSON，开启 JSON Mode。
我当时的实现大致是这样的：
func AnalyzeImage(ctx context.Context, client *openai.Client, imagePath string) (*GoodsMeta, error) { data, err := os.ReadFile(imagePath) if err != nil { return nil, fmt.Errorf("read image: %w", err) } resp, err := client.CreateChatCompletion(ctx, openai.ChatCompletionRequest{ Model: "multimodal-vision-model", Messages: []openai.Message{ { Role: "system", Content: "你是一名资深的电商商品分析师。请仔细观察这张商品图，" + "提取商品的基础信息，并严格按照 JSON 格式输出，" + "不要输出任何 JSON 以外的内容，不要使用 Markdown 代码块。", }, { Role: "user", Content: []openai.ContentPart{ {Type: "image", Image: &openai.ImagePart{Data: data}}, {Type: "text", Text: &openai.TextPart{Text: jsonSchemaPrompt}}, }, }, }, ResponseFormat: &openai.ResponseFormat{Type: "json_object"}, }) if err != nil { return nil, fmt.Errorf("call vision model: %w", err) } var meta GoodsMeta if err := json.Unmarshal([]byte(resp.Choices[0].Message.Content), &meta); err != nil { return nil, fmt.Errorf("parse meta json: %w", err) } return &meta, nil }这段代码只是框架示意，实际跑的时候还有一个关键输入：jsonSchemaPrompt。我把它做成了一段"字段说明 + 示例"的文本，告诉模型每个字段里应该写什么、不写什么。比如size字段，要求它从图上找可见的尺寸或容量标识，找不到就填"未知"，不能自己编。
3.3 视觉抽取的实测感受与兜底策略
我拿几十张不同类型的商品图测过，包括水杯、小家电、服饰、数码配件。整体来说，模型对品类、颜色的判断非常准，材质和风格次之，最不靠谱的是图上印刷的小字识别，经常出现"不锈钢"被读成"钢不锈"、容量 500ml 被读成 50ml 的情况。
针对这个问题，我加了两层兜底：
- 必填字段校验：解析出 GoodsMeta 后，先做一次字段可用性检查，任选
name、category、sell_points三个字段如果为空，直接判定本次解析失败并触发重试。 - 人工确认入口：把解析结果在跑批时打印出来，如果跑单张图，默认停下来让人扫一眼，确认无误再继续。批量跑的时候才跳过确认流程。
我的体会是：不要指望模型一次看准所有细节，老老实实加校验和人工确认，比反复调 Prompt 有用得多。
4. 文案 Agent：把卖点拆成子任务，而不是一次生成全文
4.1 一次生成的痛点：越长的内容越容易失控
很多人做文案生成时，习惯一句话交代模型："给我写一整套详情页文案"。我一开始也这样干，然后发现输出必然存在两个问题：一是太啰嗦，每个模块都写得像散文；二是风格漂移，标题像小红书博主、详情描述又突然像说明书，前后根本不统一。
原因不复杂：详情页文案实际上是四种不同性质的内容——商品标题、主图卖点、详情模块文案、规格参数表。它们的目标读者、篇幅、语气、信息密度都不一样，硬塞进同一个 Prompt 里让模型一次性输出，等于让一个人同时扮演四个角色，效果自然混乱。
所以我做了一件非常朴素的事：拆成四个子 Agent，各干各的。四个子 Agent 共享 GoodsMeta 这份结构化数据，各自有独立的 Prompt 和 Temperature。
4.2 广告法合规与输出约束
电商文案还有一个绕不开的问题：绝对化用语。淘宝对"最""第一""100%""顶级"这一类的表述查得很严，模型如果不约束，它会天然生成"全网最好的保温杯"这种文案。我不能靠人工一条条改，几十个 SKU 改下来会疯掉。
我的方案分两层：
- Prompt 层：在系统提示里明确给出负面清单，列出绝对化用语和常见违规词，要求一律禁止出现；
- 代码层：写一个
keywordFilter校验器，对模型输出做一次关键词扫描，命中违规词就自动打回重写，并附带一句"上轮输出包含违规词，请重新生成"。
Temperature 的设置也很有讲究。标题生成我用 0.2，因为标题需要准确、克制；主图卖点和详情描述用 0.7，保留一定的表达张力，但不至于漫天乱写；规格参数表不走 LLM，直接拿 GoodsMeta 渲染成表格数据结构。什么内容该让模型折腾、什么内容不该让模型碰，这个边界越早划清，后面返工越少。
4.3 文案 Agent 的 Go 实现要点
我在代码里定义了一个统一的 Agent 接口，每个环节都实现这个接口，流水线调度的时候一视同仁：
type Agent interface { Name() string Process(ctx context.Context, input *PipelineInput) (*PipelineOutput, error) }文案环节内部再拆成标题子任务、卖点子任务等。每个子任务只是对 LLM 的一次调用，包在 context 超时控制里。比如生成标题：
func (a *copyAgent) generateTitle(ctx context.Context, meta *GoodsMeta) (string, error) { ctx, cancel := context.WithTimeout(ctx, 30*time.Second) defer cancel() prompt := fmt.Sprintf("根据以下商品信息生成3个淘宝风格的商品标题，每个标题不超过30个字：\n%s", metaToText(meta)) resp, err := callLLM(ctx, "title-model", prompt, 0.2) if err != nil { return "", err } return filterKeyword(resp) }这里我特意把context.WithTimeout放在每个子任务上，而不是放在整个文案环节上。原因很实际：光生成标题可能只要十几秒，但生成详情描述可能得一分多钟，如果统一用一个超时时间，不是浪费就是来不及，拆开才能精细控制。
5. 图片处理：抠图、切片与尺寸规范，工程量比想象中大
5.1 淘宝详情页的通用尺寸底线
做电商的人都知道，淘宝详情页虽然不限制最长长度，但宽度有明确的使用习惯：移动端详情页的通用宽度是 750px。主图方面，一般是 800×800 或 750×750。所以我在开工前就定了一个规矩：所有进入最终模板的图片一律处理成 750px 宽，高度允许不等，但必须是整数，避免页面拼接时出现半像素的缝隙。
图像处理环节的实际产出包括三大类：
- 基础图：白底图（电商平台通用要求）、由原图裁剪出的细节图；
- 卖点图：首屏大图，一般是一张 750×750 的氛围图；
- 场景图：把商品"放进"一个使用场景里的合成图。
这个环节的产物数量和商品本身有关系。一个保温杯，我一般产出 1 张首屏图、3 张卖点图、2 张细节图，一共 6 张图，外加一张白底图备用。这些数量都是可以在配置文件里调的。
5.2 抠图与场景合成，Go 生态弱的地方绝不硬扛
坦白讲，Go 的纯图像算法生态比 Python 弱了一截。我不会在 Go 里自己实现语义分割，那是自找麻烦。我的做法是：抠图调用现成的图像分割 API，或者用 Go 的 exec 调本地的 Python 分割脚本，Go 只负责读取结果、继续走流程。
场景合成也类似。如果要生成"保温杯放在办公桌上"的氛围图，我会先把商品从图中分割出来，把白底图调好角度和比例，然后调用 AIGC 生图接口，把白底图和场景描述一起送进去，生成之后再拿白底图做一次贴合校验。
这里有一个很深的教训：AIGC 生成的场景图，光源方向和商品本身经常不一致。商品图是室内顶光拍的，生成的场景图若是窗边侧光，合成结果一眼假。所以我通常会在 Prompt 里注明"主光源来自上方，柔和均匀"，并且在生成后做一个亮度匹配的简单调色，把场景图压暗或提亮到和商品主体差不多的水平。
5.3 Go 图像处理能做和不能做的事
虽然不碰算法，但 Go 在图像处理上能做的基础工作其实不少。解码、缩放、裁剪、白底扩展、JPEG/WebP 编码，这些用标准库和几个常用库就能搞定。
比如把所有处理后的图片统一转成 750px 宽并按需加白边的逻辑：
func normalizeImage(srcPath, dstPath string, width int) error { src, err := imaging.Open(srcPath, imaging.AutoOrientation(true)) if err != nil { return err } resized := imaging.Resize(src, width, 0, imaging.Lanczos) // 如果图片高度小于目标高度，用白底 Canvas 补齐 bg := imaging.New(width, width, color.White) bg = imaging.PasteCenter(bg, resized) return imaging.Save(bg, dstPath, imaging.JPEGQuality(85)) }但涉及语义理解的事情——哪些区域是产品、哪里该抠掉、阴影要不要保留——Go 就完全没有优势。我的建议是：看清自己的能力边界，把 Go 用在编排和文件处理上，把重活交给专门的服务，整条流水线依然能跑得很顺。
6. 装配 Agent：用 Go 模板把零散素材变成一套页面
6.1 详情页模板的结构设计
所有文案和图片都齐了之后，最后一个环节就是把它们"装"进详情页模板。我看到过很多 AI 生成详情页的方案是用代码直接拼 HTML 字符串，这种做法的维护成本高到离谱，稍微改一点结构就要动代码。
我的做法是用 Go 的html/template，把详情页定义成一组模板文件，页面结构固定，数据完全从 copy.json 和 images/ 目录注入。详情页我拆成了五个固定区块：
- 首屏区：商品大图 + 标题 + 价格锚点氛围（活动标签）；
- 卖点区：三条核心卖点，每条配一张图；
- 规格区：以表格形式展示商品参数；
- 细节区：细节图 + 对应的说明文字；
- 售后区：固定的售后保障文案，这部分完全不走 LLM。
模板的做法很简单，就是一个page.tmpl，里面用模板语法循环渲染图片和文案。核心代码大致是这样：
tmpl, err := template.ParseFS(templatesFS, "templates/*.tmpl") if err != nil { return err } var buf bytes.Buffer if err := tmpl.ExecuteTemplate(&buf, "page.tmpl", pageData); err != nil { return err } // 把 buf 写入 workspace/pages/index.html6.2 为什么坚持用 html/template 而不是 text/template
这个地方有一个非常值得提醒的细节：Go 的标准库里有两个模板包，text/template和html/template。做网页渲染必须用html/template，因为它会自动做 HTML 转义。
你想一下这个场景：模型生成的文案里带了一个<script>，或者只是带了一个没闭合的<div>。如果用text/template，这些内容会被原样塞进页面里，轻则页面结构错乱，重则直接变成一个 XSS 漏洞。html/template会在渲染时把<、>、&这些字符正确转义，保证页面结构安全。
这看起来是个小选择，但实际是整条流水线里极少数"选错就要返工"的决定。我当初先用text/template跑通，结果一测就发现 CSS 崩了，排查半天才意识到是模板包的问题。
6.3 输出目录与预览
装配完成后，产物是这样的结构：
pages/ ├── index.html └── assets/ └── images/ ├── hero.jpg ├── sellpoint-1.jpg ├── ...为了让运营的同学能直接看效果，我在流水线里顺手加了一个参数：--preview。如果加了，它就起一个本地静态文件服务，打开浏览器直接预览页面效果。这个功能看起来小，但在实际交付时帮了大忙，大家不用先传到淘宝后台再刷新看效果，本地一眼就能确认布局对不对、图片有没有错位。
7. 串起来跑通：从命令输入到整套详情页落地的完整流程
7.1 CLI 设计与流水线调度
整个流水线的入口是一个简单的命令行程序。用法长这样：
agent-pipeline -in product.jpg -out ./workspace --preview可选参数包括：--no-copy（跳过文案生成，适合只更新图片时用）、--from-meta meta.json（直接用已有的 meta 文件继续后面的环节，跳过视觉解析）、--batch（批量模式，不对中间产物做人工确认）。
调度逻辑的核心并不复杂，就是一个按顺序执行、部分环节可以并发的编排器。视觉解析必须先跑，拿到 GoodsMeta 之后，文案生成和图片处理其实是互相独立的，可以并行跑。我直接用 goroutine 把它们发出去，再用sync.WaitGroup等两边都完成，最后进入装配环节。
这里我专门强调一下：流水线调度的核心不是并发本身，而是"哪些环节可以并行、哪些环节必须串行"这个决策。视觉解析不完成，后面全是空中楼阁；文案和图片处理互相不看对方的产物，自然可以一起跑。把这个依赖关系画清楚，代码就顺了。
7.2 实测一轮的耗时、成本与产物
我拿自己的项目实测了几轮。以一张手机拍摄的 1200 万像素商品图为例，整条流水线从开始到输出详情页目录，大概耗时两分钟左右。主要时间花在抠图分割和场景合成上，文案生成和视觉解析反而很快。
成本方面，按当前常见 API 的价格量级估算，跑一整套：视觉解析一次、文案调用四次左右、场景合成一次到三次，整条流水线的 API 费用大概在几块钱到十几块钱的量级。大头永远是图像生成，所以我把图像生成次数控制得很保守，能复用白底图做模板渲染的就绝不额外生成。
跑完后的输出大概长这样：
workspace/ ├── meta.json ├── copy.json ├── images/ │ ├── hero.jpg │ ├── sellpoint-1.jpg │ ├── sellpoint-2.jpg │ └── detail-1.jpg └── pages/ ├── index.html └── assets/images/...7.3 运营侧的反馈与后续迭代
把这套流水线拿给朋友实际用了两周之后，得到的真实反馈是：大概六成到七成的页面可以直接用，剩下的需要微调文案或换图片，但每一条的修改量都远小于从零做。
我根据这个反馈做了一个关键迭代：把"人在回环"做成流水线的一等公民。每次跑完，流水线会生成一个review.json，把所有产物的来源、占位状态、潜在问题都记录下来。人工打开这个文件就能快速知道哪些内容需要确认，改完之后重跑后续环节即可。
另一个重要迭代是批量模式。朋友那边一跑就是十来个 SKU，我加了一个--batch参数，跑的时候不再逐张图停下来等人确认，而是在最后统一输出一份"待确认清单"。工程化的胜利从来不是模型多聪明，而是它老老实实地把活干完了、还留好了给人修改的后路。
8. 踩过的坑与成本控制心得
8.1 模型输出格式不稳定：JSON 解析比想象中花的时间更多
整条流水线里，我花在"解析模型输出"上的调试时间，比写 Agent 逻辑本身还多。模型明明收了 JSON Schema，仍然可能多出注释、用 Markdown 代码块包住 JSON、把布尔值写成字符串、在数组末尾多留一个逗号。这些在 Python 里可能不算大事，但在 Go 的json.Unmarshal面前全是硬错误。
我最后的解决方案是三层防护：第一层，让模型严格输出纯 JSON，这是承诺而非保证；第二层，解析失败后自动重发一次，把上次的报错信息原样回传给模型，让它自己修正；第三层，写了一个 sanitize 函数，专门处理最常见的"代码块包裹"和"尾逗号"问题。三层下来，成功率就能稳定拉到可接受的水平。
把"输出解析"当成第一公民来设计，而不是 LLM 调用的配菜，这也算是我这条流水线踩出来的最重要经验之一。
8.2 并发限流与成本控制
流水线并行跑起来之后，紧接着就撞上了 API 限流。并发调几次图像生成的接口，直接给我返回 429。解决方案是一个朴素的令牌桶限速器：用一个带缓冲的 channel 当令牌池，每个请求要取到令牌才发出去，控制住峰值 QPS。
成本控制上，我总结了一个省钱口诀：能少调一次就少调一次，能用便宜模型就不上贵模型。具体操作是：标题、规格描述这类简单任务用轻量模型；视觉解析和卖点剖析这种需要理解能力的任务才用高端多模态模型；图像生成能复用就不会额外生成。
另外一个很多人看不上的省钱点：Prompt 要短。输入 token 也要花钱，而且你给模型的 System Prompt 越长，模型越容易"学着你的啰嗦"。我把每个环节的 Prompt 精简到只保留必要指令和负面清单，输出质量没有下降，成本倒是肉眼可见地降了一截。
8.3 图像尺寸不一导致的模板错位
第一个版本跑出来的页面，卡在了一张图上：模板里明明写了width: 100%，但图片和图片之间总有一条细缝，有的图还超出容器一点点。排查了半天才意识到，问题不在 CSS，而在于生成的图宽高比太乱，100%宽度也救不了一张 800 宽和一张 720 宽的图排版出来的缝隙。
解决方案在我前面已经提过了，就是在进入装配前，把每一张图都统一成 750px 宽，高度取整，必要时用白色像素补齐。从那以后，模板错位的问题基本绝迹。这个坑给我的教训是：不要在模板里试图"包容"脏数据，数据在上游端正了，下游才干净。
8.4 一个兜底原则：所有 LLM 输出都要能被"无痛替换"
流水线跑久了你就会发现，模型输出再好也是"草稿级"的。真正能规模化落地的前提，是让所有 LLM 产物都具备可替换性。我的做法是：流水线每一步的产物都保留一个可手工编辑的版本，meta.json、copy.json 都可以直接改，改完从对应环节重跑，流水线的后续逻辑完全感知不到"这段内容是人工改的"。
这个原则解决了两个痛点：一是模型给出不满意结果时，人工可以快速修正；二是让非技术人员也愿意用，因为他们知道 AI 不是"最终裁决者"，自己永远有最后的发言权。我觉得这也算得上是我这套 Agent 流水线最值得借鉴的设计思路。
最后再分享一个小技巧：我把整条流水线封装成了一个右键菜单和一个小脚本，运营同事不用记任何命令，把商品图拖进来、双击运行，等着收pages.zip就行。真正让一套 AI 工具在团队里活下来的，往往不是模型多聪明，而是它足够皮实、足够省心。希望这篇流水线的拆解过程，能给你搭自己的 Agent 体系一点启发。
