让 AI 生成一张活动海报，现在已经很常见。但让它把这张海报真正直接帮编辑替换使用到业务系统，往往还差几步。
比如，运营人员对本地 AI 助手说：
给这款保温杯生成一张新的主图，再做两张场景图。主图替换掉，场景图加到商品轮播里，原来的尺寸说明图保留。
图片生成了，预览也很好看。接下来，助手却让用户先下载图片，再到商城后台上传，复制地址，然后回来继续对话。
商城其实已经有“更新商品图片”的接口，AI 也已经获得操作这件商品的授权。为什么这件事还是断在中间？
因为生成器交出来的是文件，而商城接口需要的是一个能够访问的图片地址。把文件变成业务系统可使用的资源，是一项需要明确提供的能力。
这篇文章用一件合成商品说明如何接上这段流程。相同思路也适用于活动海报、网站配图、PNG统计图等图片产物。示例假设业务系统已经提供对应能力，不涉及真实客户数据。
一、先分清三个“已经完成”
这条流程至少有三个独立结果。
第一，图片已经生成。说明生成工具产出了文件，本地客户端能够展示它。
第二，图片已经保存。说明文件进入部署者管理的存储空间，并取得可供业务使用的地址。
第三，业务对象已经更新。说明商城接受了这次修改，并把对应地址写进了指定商品的主图或轮播字段。
这三件事需要分别判断。图片预览正常，不代表商城服务器能够读取；上传成功，也不代表商品已经换图。
| 生成图片 | 可读取的实际文件及其引用 | 已有商城可用地址 |
| 保存图片 | 上传结果、图片地址及原上传记录 | 商品已经修改 |
| 应用到商品 | 对应商品的业务执行结果 | 其他商品也已完成 |
用户最终关心的是商品变成什么样，但中间每一步都要有自己的完成依据。这样，一旦失败，助手才能知道应该继续哪一步。
二、本地路径为什么不能直接填进商品接口
本地智能体生成的图片，可能保存在电脑上的工作目录，也可能由生成工具以文件引用的形式交付。
本地客户端能读取这个文件，不代表远端商城也能读到。把一个文件名填进需要URL的参数，或者让模型根据文件名拼出一个看起来像图片地址的字符串，都没有解决文件传输。
在接入设计里，可以给智能体提供一个“附件空间”：它把本次生成的文件交给受控上传入口，由入口保存字节并返回真实地址。
这里有一个实用分工：模型选择文件引用，客户端读取实际文件，存储服务接收文件内容。
模型可以说“使用刚才生成的第二张场景图”，但文件引用到底对应哪些字节，应由能接触文件的宿主程序解析。中枢不需要、也不应假设自己能直接读取用户电脑上的任意目录。
这样，模型处理的是“哪张图、用于什么”，文件传输则由程序完成，不必把整张图片编码成一大段文字塞进对话。
三、附件空间可以复用普通存储
从工程结构看，这条链路并不要求另造一种专用存储产品。
部署者可以复用已有的对象存储，例如COS或OSS，也可以在适合的部署条件下使用服务器本地存储。关键是明确：文件保存在哪里、由谁负责保留、业务系统用哪个地址读取，以及上传失败时如何查询原结果。
图片需要用于商品展示时，读者最终访问到的是商品页面引用的资源。这个地址应当符合部署者为商品素材设定的保留与访问方式，而不是只在当前聊天预览里可见。
如果业务系统会把外部图片转存到自己的素材库，那么上传地址承担的是交接入口；如果业务系统直接保存外链，后续展示就依赖该存储地址继续可用。接入时把这件事说明白即可。
存储的选择可以由部署者配置，模型无需知道桶的密钥，更不需要自行挑选另一个存储账号来完成上传。
文件目录和恢复记录的设计以后可以扩展到其他产物，但访问方式要随用途确定。例如，公开商品图与内部经营文档的读取要求不同，不能仅因为共用“附件”一词，就默认采用相同的公开地址。
四、把换图任务拆成一条能核对的链路
回到前面的保温杯示例。用户要求替换一张主图、追加两张场景图，并保留已有的尺寸说明图。
一条完整流程可以这样组织。
先确定目标。 助手使用本会话选定的商城授权，查询目标商品，确认商品身份和当前图片列表。同名商品不能只靠显示名称区分；有多份授权时，商品还要与原系统、原授权一起绑定。
再生成素材。 生成工具返回三份文件引用。助手知道哪张用于主图、哪两张用于轮播；文件目录保留这些引用与实际产物的对应关系。
然后上传保存。 客户端读取三份文件，使用本次任务允许的上传入口保存。每张图分别取得结果，只有明确成功的项才有可使用的地址。
最后调用业务能力。 助手把这些真实地址交给商城图片更新工具，保留用户要求留下的原图，按照商城原有权限和审批规则执行，再核对商品结果。
这里尤其需要读懂“更新图片”接口的含义。
如果接口接收的是完整轮播列表，那么只提交两张新图，可能会把原列表整体替换掉。此时应根据已查到的原列表，组合出“保留的旧图＋新增场景图”，并按业务接口要求处理主图是否也需要出现在轮播中。
如果接口提供的是追加动作，就使用追加语义，而不是假装所有系统都采用相同参数。
图片内容和展示方案可以交给模型组织，字段含义、覆盖规则和最终写入仍由业务接口定义。附件空间不会替代这些业务语义。
五、三张图只上传成功两张，应该怎么办
假设主图和第一张场景图上传成功，第二张场景图因为网络中断没有得到确定结果。
助手此时应该知道：两张已经有地址，第三张需要确认。它不应把整个任务笼统标成“上传失败”，也不应再上传已经成功的两张。
对于结果不确定的第三张，先查询原上传记录。如果文件已经保存，就复用原地址；如果仍需补传，再根据原记录补传同一份文件。
若用户要求这三张图作为一套更新，完整列表应等到所需图片齐备后再提交。业务上允许分开更新时，也可以按原要求分别执行，但要把部分完成说清楚。
相反，若三张都已上传成功，助手已经拿到三个地址，就可以继续调用商城能力。取得成功地址之后，没有必要为了使用地址而反复询问上传服务。
必要的查询是为了消除不确定性。它不是每次业务调用之前都必须重复经过的一道手续。
六、上传恢复和业务恢复，要沿各自的原记录继续
另一种情况是：图片已经上传，商品修改请求也已经发出，但客户端没收到最后的回包。
这时不能因为界面还没显示成功，就重新上传图片、重新生成参数，再发起一次新的商品修改。
上传是否完成，要查原上传记录；商品是否修改，要查原业务调用。两个结果使用各自的恢复路径，不能互相代替。
| 图片明确保存成功 | 直接使用已返回的地址 |
| 上传结果不确定 | 查询原上传记录，必要时补传原文件 |
| 业务请求明确尚未派发，允许恢复 | 等待条件满足后恢复原业务调用 |
| 业务请求已派发，结果不确定 | 核对原执行结果，不重新创建写操作 |
| 业务审批未完成 | 保留原申请和原参数，按业务审批流程继续 |
例如，商城更新因为限额暂时等待，不意味着三张图片失效，也不意味着需要换一份授权再试。图片地址可以保留，待处理的是原业务动作。
如果整套链路暂时无法确定某一步是否产生了业务后果，就把该项显示为待核对。恢复机制的价值，是接着原来的事情往下走，而不是用一次新请求覆盖上一次的不确定状态。
七、接入团队分别需要补什么
对客户端开发者而言，重点是把生成产物登记成可选择的文件引用，能够读取文件，并保存上传结果与恢复记录。模型需要看见哪些图片已经可用，哪些仍待处理。
对中枢或附件服务而言，重点是校验上传身份和范围，接收实际文件、保存到配置的存储，返回逐项结果，并支持原上传记录查询。存储凭据由部署配置管理，不能交给模型生成或猜测。
对业务后端而言，重点仍是清楚声明图片更新动作：操作哪个商品、主图与轮播如何传参、是追加还是覆盖、如何检查当前权限，以及成功后返回什么。
如果业务接口已经接受图片URL，且地址满足它原有的读取要求，后端通常无需仅为“图片由AI生成”再增加一套接口。新增工作主要落在生成产物到业务地址之间。
这也是把附件空间作为通用能力的意义：同一张已保存的活动海报，可以在获得相应授权后用于商城活动或网站内容；每个业务系统继续独立判断对应动作能否执行。
八、第一次验收，三张图和一件测试商品就够了
先用一件可恢复的测试商品跑通完整链路，不必一开始就批量修改所有商品。
选一张主图、两张场景图，保留商品原有的说明图。检查图片是否真正保存、地址能否读取、最终商品图片列表是否符合要求，以及后台是否能找到同一次操作的执行结果。
再模拟一次上传回包丢失，确认助手复用已经保存的文件；模拟一次业务回包丢失，确认它核对原调用，不再执行一次新的修改。
最后让助手给出一段普通人能理解的结果：
三张图片已保存。测试商品主图已替换，两张场景图已加入轮播，原尺寸说明图保留。商品更新已完成，可在后台核对。
如果实际只完成了上传，就只说明三张图片已保存，商品更新还在等待哪一步。这样的反馈才对应用户真正要交付的工作。
百灵中枢的实践与当前状态
截至2026年9月15日，本文涉及的“本地智能体附件空间”已完成首期图片候选实现和自用链路验证，复用部署者配置的普通COS／OSS等存储；文件保留由部署者管理。首期处理PNG、JPEG和WebP图片，不代表已经交付任意文件类型或所有智能体宿主的支持。
这部分仍是候选能力，尚未进入公开稳定版本。 当前公开与附件候选应分开看；不能仅安装现有同号公开包，就假设具备本文的新上传链路。文章中的通用流程可用于接入设计，具体可安装版本以正式发布说明为准。
如果你已有一个接收图片URL的业务接口，可以先整理“业务系统＋一项图片动作＋脱敏接口示例”：从一件测试商品或一张活动海报开始，验证生成的文件如何变成可用地址，再验证地址如何变成可核对的业务结果。
