MCP 火了很久，但大部分示例停在「查天气」「读文件」这类玩具场景。这篇写一个真在生产里跑的东西：让 AI 助手直接调用电商出图，从「把这款做成欧美模特上身图」到拿到成品，不离开对话框。
一、为什么出图适合 Agent 化
不是所有任务都适合交给 Agent。出图这件事恰好符合四个条件：
- - 输入结构化：商品图 + 功能 ID + 参数
- - 输出结构化：任务 ID + 状态 + 图片地址
- - 可批量：一次几十上百个 SKU
- - 失败模式明确：保真度不够、姿态崩坏、超时
也就是说，它不需要模糊判断，只需要可靠执行。这正是 Agent 擅长的部分。
二、架构
`
Claude Desktop / Cursor
↓ MCP（stdio）
shangtuce-mcp-server
↓ HTTPS + Device Token
Bridge API
↓
出图队列 → 结果回调
`
关键设计是设备中继：不在客户端存长期密钥，而是走一次性设备配对。
- 1. Agent 调用
shangtu_connect - 2. 返回一个
verification_uri_complete - 3. 用户在浏览器完成一次性配对
- 4. 凭据落到本地安全路径，后续自动复用
这么做有两个好处：配置文件里不会出现明文 Key；算力归属和创作者分成仍然绑在账号上，不会被中继环节截断。
三、配置
`json
{
"mcpServers": {
"shangtuce": {
"command": "node",
"args": ["/absolute/path/to/dist/packages/mcp-server/src/index.js"],
"env": {
"SHANGTU_BASE_URL": "https://<your-app>.runninghub.cn/__pb/api/shangtu/v1",
"SHANGTU_UPLOAD_ROOTS": "/Users/me/ecommerce-assets"
}
}
}
}
`
重启客户端，工具列表里会出现三个方法：shangtu_connect、shangtu_submit_job、shangtu_get_job。
SHANGTU_UPLOAD_ROOTS 是本地素材白名单，用分号分隔。只允许上传这个范围内的文件，避免 Agent 误传别的东西。
四、一次真实的任务流
`
你：把这件衬衫做成欧美模特上身图，2K，要三个不同姿态
Agent：
- 1. shangtu_connect → 已授权
- 2. shangtu_submit_job({
feature_id: "template_transfer",
inputs: {
product_images: ["/Users/me/ecommerce-assets/shirt-01.jpg"],
reference_images: ["/Users/me/ecommerce-assets/model-ref.jpg"]
},
options: { resolution: "2k", poses: 3, replace_target: "garment" }
})
→ bridge_job_id: job_8f3a...
- 3. shangtu_get_job(job_8f3a...) → status: queued
- 4. （轮询）→ status: succeeded
outputs: [url1, url2, url3]
`
注意 replace_target: "garment" 这个参数。它的意思是替换目标是人，不是衣服——衣服作为不可修改层保留。这个参数设错，整个流程就白跑。
五、从单次到批量：四个生产环境的坑
单次跑通很容易，跑 100 个 SKU 是另一回事。
坑一：幂等键必须自己生成
API 支持 Idempotency-Key，但不会替你生成。重试时如果 key 变了，就会重复建单、重复扣费。正确做法：
`python
def idempotency_key(sku, feature, payload):
raw = f"{sku}|{feature}|{sorted(payload.items())}"
return hashlib.sha256(raw.encode()).hexdigest()[:32]
`
同一个 SKU + 同一功能 + 同一参数，永远得到同一个 key。这样网络抖动重试也不会多扣钱。
坑二：轮询要退避
不要 200 毫秒轮一次。任务平均耗时 20—60 秒，高频轮询会直接撞上速率限制。
我的参数：2 秒起步，每次乘 1.6，封顶 15 秒。
坑三：并发不要拉满
实测 3—5 并发是稳态上限。超过 5 开始返回 429，总耗时反而更长——因为要处理退避重试。
用 ThreadPoolExecutor(max_workers=3) 是最省心的配置。
坑四：结果必须落盘
API 返回的图片 URL 有有效期。生产环境一定要下载到自己的对象存储（OSS / S3 / R2），别直接把这个 URL 写进商品详情页——过期就是全站破图。
六、一个反直觉的观察
接入 MCP 之后，我原本以为最大的收益是「自动化省人力」。实际跑了一个季度，收益最大的是另一件事。
以前美工做图，中间会有大量的上下文切换：打开素材、找参考、上传、等结果、挑图、改参数、再跑。这些动作单看都不费时，但每次切换都有认知成本。
接入 Agent 之后，人只做两件事：定义任务和审核结果。中间的循环交给机器。
结果是同一个人，日产出从 15 款涨到 40 款左右，而且出错率下降了——因为人不再疲劳地重复机械动作，审核时的注意力反而更集中。
这可能才是 Agent 真正的价值：不是替代人，是把人从循环里摘出来，只保留判断。
七、边界
说清楚做不到的：
- - Agent 不会替你判断哪张图能用。保真度是否达标、姿态是否自然，必须人眼过一遍。
- - Agent 不会替你决定拍什么。选题和卖点是人的事。
- - 失败重试有上限。连续失败的 SKU 应该进人工队列，而不是无限重跑烧钱。
把这三条记住，这套东西才真的省事，而不是制造新的麻烦。