企业官网建设流程全解析

完结一个全栈项目的感觉，就像跑完一场马拉松，冲线那刻的轻松是真的，但回头看路上一脚深一脚浅的坑也是真的。这个AI修图Agent从立项到交付，我前后折腾了将近三个月，横跨了模型接入、后端服务、前端交互和移动端适配，属于典型的"一个人活成一支队伍"的全栈项目。今天把这套东西完整拆出来，从架构设计到具体实现，从选型逻辑到排坑链路，一次性说清楚。如果你正打算做一个带AI能力的多端产品，或者对Agent的工作机制感兴趣，这篇应该能帮你少走不少弯路。

1. 为什么做的是一个"Agent"而不是一个"修图工具"

修图工具市面上太多了，从Photoshop到美图秀秀，从Canva到Figma，每个都有庞大的用户群。那为什么还要做一个AI修图Agent？说实话，在最开始想这个项目的时候，我反复问过自己这个问题，直到后来想明白了一个关键的差异点。

传统修图工具的核心交互逻辑是"人找功能"。你想抠图，先找到抠图按钮；你想调色，先找到色阶、曲线、色相饱和度这些面板。这要求用户不仅知道自己要什么，还得知道用什么功能、怎么操作才能达成目标。对专业设计师来说这没问题，但对普通用户来说，学习成本太高了—这就像一个只能靠菜单驱动的傻瓜相机，功能再多，不会用就等于没有。

Agent不一样，它的核心交互逻辑是"功能找人"。用户只需要说一句"帮我把这张图调成夏日清新风格""把背景里的人去掉"或者"把这张产品图变成白底"，Agent会自己去理解意图、拆解任务、选择工具、执行操作、返回结果。用户不需要知道背后调用了哪个算法、用了什么参数，只需要用自然语言描述"我想要什么"。

这次项目的技术架构就是围绕这个理念设计的：前端负责自然交互和结果展示，后端负责Agent的调度编排和工具执行，底层接入了多模态大模型做意图识别和图像处理。整体分为四层，每一层都有自己的职责边界。

• 交互层：面向用户的上传、预览、对话、操作确认界面，覆盖Web端和移动端，统一体验
• 调度层：Agent的核心大脑，理解用户指令，拆解为可执行步骤，管理多工具调用顺序
• 工具层：封装修图算法和AI能力的工具集合，包括基础处理和AI生成两类，以标准接口注册到Agent
• 模型层：底层接入的大模型和图像算法服务，包括对话理解模型、图像理解模型、图像生成模型等

这个分层设计最大的好处是每层都可以独立替换和迭代。模型层今天用这家的大模型，明天换另一家的，只要接口兼容，Agent的调度逻辑完全不用动；工具层新增一个"老照片修复"能力，只需要注册一个新的工具描述，Agent立刻就能学会使用它。

从商业价值角度看，Agent化修图的意义在于降低了专业能力的门槛。普通人不会Photoshop，但同样有修图需求；专业设计师用传统工具效率高，但重复性的"抠图、调色、规格化"操作同样可以用Agent来批量处理。这两种需求其实指向同一个结论：自然语言将成为下一代图像处理的交互入口。

2. 技术选型逻辑：Vue + Golang + UniApp + 大模型这套组合怎么定下来的

技术选型这件事，很多人喜欢追新，哪个框架火用哪个，最后做出来的东西性能和维护性一塌糊涂。我的选型原则很朴素：团队能力范围内最稳的组合 + 生态最成熟的方案 + 对最终交付最有保障的路径。这个项目最终定了Vue 3 + Golang + UniApp + 多模态大模型的组合，都是经过了实际对比和验证的。

2.1 前端为什么用Vue 3而不是React

说实话，React和Vue 3在能力上难分伯仲，选哪个更多是看团队习惯和项目属性。这个项目我选择Vue 3，核心原因有三个。

第一是Composition API对复杂状态的组织能力。AI修图场景的前端状态是非常复杂的：原图、中间过程图、多个版本的结果图、每一步操作的参数记录、Agent执行状态（等待中、执行中、已完成、失败）、对话历史……如果还用Options API那套data/methods/computed的组织方式，代码很快就会乱成一团。而Composition API可以按业务逻辑域来组织代码，比如把"图像状态"相关的东西封在一个composable里，把"Agent通信"相关的封在另一个composable里，互不干扰，维护起来清晰得多。

第二是生态的完整度。图像处理类前端项目离不开Canvas相关操作，Vue 3生态里有vue-use带来的useEventListener，也有社区比较成熟的图像处理组件可以参考。第三点是TypeScript的支持，Vue 3本身就是用TS写的，类型推导体验比Vue 2时代强了一个量级，这对一个代码量大、状态复杂的全栈项目来说非常重要。

2.2 后端为什么选Golang而不是Node.js

后端服务的核心职责是接入大模型、调度Agent执行工具、处理图片上传下载、管理任务队列。按理说Node.js也能干这些活，而且前后端统一用JavaScript还少一门语言的知识成本。但我最后选了Golang，主要从四个维度做了比较。

实际开发下来，Golang在并发处理Agent任务时确实省心很多。每来一个修图请求，我开一个goroutine去跑Agent调度逻辑，相互之间不干扰，资源消耗也低。如果换成Node.js，高并发场景下的回调地狱和内存问题处理起来会多花不少功夫。

2.3 多端统一选UniApp而不是纯原生

UniApp被一些人诟病性能不如原生，这个我不否认，但它的核心价值在于"一套代码，多端运行"。这个项目需要覆盖Web端、iOS端和Android端，如果分别用Vue/RNC/Flutter写三套，人力成本直接翻三倍，对于一个个人全栈项目来说根本不可能。

UniApp基于Vue语法，和前端主栈Vue 3完美衔接，这是个很舒服的点。根据Vue官方的说明，Vue 3已经将响应式系统核心包@vue/reactivity独立发布，而UniApp的Vue 3版本也基于这个核心实现，所以响应式机制的可靠性和性能有保障。我只需要写一套界面代码，编译到H5、微信小程序和App端，就都能跑起来。

当然，多端适配的代价一定有，这个后面在坑的章节详细说。

2.4 大模型选型的思路

大模型是整个Agent大脑的核心，这部分的选型我考虑了三个关键约束：图像理解能力、工具调用的准确性、成本可控性。

最终定下来的方案是：对话理解用国内可直连的商用大模型API，图像处理任务（抠图、去背景、超分辨率、老照片修复）用专门的开源模型服务，而不是指望一个大模型什么都干。原因很简单：术业有专攻。通用的多模态大模型做意图理解很强，但让它真的去执行像素级的图像处理，效率和效果都不如专门的模型。

这种"大模型当大脑、专业模型当手脚"的组合，是当前AI Agent落地比较成熟的模式。Agent判断用户意图后，决定调用哪个专业工具或者模型，真正的像素操作交给专业工具去完成。

3. Agent的核心机制：从一句自然语言到一张成片

这个项目最核心的部分不是界面，不是上传下载，而是Agent如何把一句模糊的自然语言转化为一系列精确的修图操作。这里面的机制拆开来看，分为意图理解、任务拆解、工具调用、结果校验四个环节，每个环节都有值得细说的设计。

3.1 意图理解的prompt工程设计

Agent理解用户意图靠的就是大模型，但同样一个大模型，用不同的prompt给它，效果天差地别。我在prompt工程上花了不少心思，核心原则是"给足上下文 + 明确输出格式 + 约束行为边界"。

我设计了一套结构化的System Prompt，关键内容是这样的：

你是一个图像处理Agent，负责理解用户的修图需求并生成操作计划。 你可以使用的工具包括： 1. crop: 裁剪图片，参数为x, y, width, height 2. resize: 调整图片尺寸，参数为width, height 3. brightness: 调整亮度，参数为-100到100 4. contrast: 调整对比度，参数为-100到100 5. saturation: 调整饱和度，参数为-100到100 6. remove_background: 去除背景，无参数 7. blur_background: 背景虚化，无参数 8. super_resolution: 图像超分辨率，无参数 9. restore_old_photo: 老照片修复，无参数 10. draw_text: 添加文字水印，参数为text, x, y, font_size, color 你必须遵循以下规则： - 只能使用上述工具，不能编造工具 - 如果用户的需求不明确，必须向用户澄清 - 输出必须是无额外文字的JSON数组，每个元素包含tool和params两个字段 - 如果需要多个操作，按执行顺序排列

这套Prompt设计最关键的地方是约束了输出格式。让大模型自由发挥产生自然语言描述，Agent那边还要另写一段解析逻辑来理解，容易出错。直接限定JSON数组输出，解析就变成了一个简单的反序列化操作，稳定可靠。

当然，约束也有代价，就是模型偶尔会在输出里混入解释性文字（比如"好的，我来帮你处理这张图片：{...}"），所以我在后端做了容错解析，先尝试标准JSON解析，失败就尝试提取JSON片段，再失败就走重试逻辑。

3.2 任务执行链的编排与状态机

用户的需求往往不是单一操作。比如"帮我把这张照片调成日系清新风格，然后加上一句'夏日物语'的水印"，这就包含了调色和加文字两个操作，而且有先后顺序。Agent执行这类复合任务的机制，本质是一个状态机。

每个任务都会经历这几个状态：

• Pending（待执行）：任务创建，等待调度
• Running（执行中）：有一个工具正在执行
• ToolSuccess（工具成功）：当前工具执行完毕且返回结果
• ToolFailed（工具失败）：当前工具执行失败，需要决定是重试、跳过还是中止
• WaitingUserInput（等待用户输入）：遇到歧义，等待用户澄清
• Completed（完成）：所有操作执行完毕，结果已返回
• Rejected（已拒绝/失败）：任务整体失败

后端我用Golang的channel实现了这个状态机的流转。每个任务有一个goroutine负责推进状态，工具调用通过channel发消息，状态变化后返回给前端做进度展示。这个设计让前端能实时看到"正在识别意图→正在调色→正在加文字"的完整过程，用户体验比干等一个接口返回强得多。

type TaskStatus string const ( TaskPending TaskStatus = "pending" TaskRunning TaskStatus = "running" TaskToolSuccess TaskStatus = "tool_success" TaskToolFailed TaskStatus = "tool_failed" TaskWaitUserInput TaskStatus = "waiting_user_input" TaskCompleted TaskStatus = "completed" TaskRejected TaskStatus = "rejected" ) type Task struct { ID string UserID string ImageURL string Status TaskStatus Plan []ToolCall CurrentStep int Result *TaskResult CreatedAt time.Time }

3.3 工具注册机制：让Agent学会用新工具

工具注册是Agent设计里非常核心的一个抽象。按照OpenAI函数调用（Function Calling）的成熟模式，每个工具需要向Agent描述清楚"我是谁""我能干什么""我需要什么参数"。这个项目的工具注册表定义如下：

type ToolSchema struct { Name string `json:"name"` Description string `json:"description"` Parameters []ToolParam `json:"parameters"` Handler func(params map[string]interface{}, image []byte) ([]byte, error) } type ToolParam struct { Name string `json:"name"` Type string `json:"type"` Required bool `json:"required"` Desc string `json:"desc"` }

实际调用阶段，Agent生成JSON计划后，后端调度器按顺序执行每个tool call。执行前从ImageURL下载图片，执行中把工具调用结果（可能是处理后的图片URL、参数信息、或者错误信息）追加到上下文里，再决定下一步动作。

这个过程像一个厨师做菜：大模型是"点菜的人"，它知道菜谱，告诉后厨要做哪几道菜，后厨（工具层）动手做，做完端上来给顾客看（返回结果给前端）。如果一道菜做得不满意（用户看到结果后说"还不够亮"），Agent根据反馈再调整，直到满意为止。

3.4 多轮对话与参数记忆

真正用得顺手的Agent必须支持多轮对话。用户说"把这张图调亮一点"，接着新上传一张图说"这张也这样调"，Agent需要能理解"这样"指的是上一张图的调亮参数。

这个机制的实现方式是：在Agent的上下文里始终携带"当前图片参数状态"信息。每一次工具执行完，就把最新的图片参数快照写回上下文，后续对话时模型可以看到当前图片的参数配置，从而理解"这张也这样调"的具体含义。

同时，我在Prompt工程里增加了"记忆规则"：如果用户提到"可以""这张也"等代词性表述，优先参考上下文历史里的最近参数配置。这套设计让Agent具备了一定的"记忆"能力，不会再出现用户说了"和刚才一样"却无从下手的尴尬。

4. 全栈链路里的技术细节：从上传到出图的完整生命周期

Agent逻辑搞定之后，真正的工程量其实在前后的全链路打通。一张图片从用户的手机相册出发，到最后在屏幕上显示处理结果，中间经过上传、存储、网络传输、任务调度、工具执行、结果回传等多个环节。任何一个环节出问题，整体体验都会崩塌。

4.1 图片上传的断点续传与压缩策略

多端产品都会遇到一个问题：用户手机上的照片动不动就是5MB、10MB甚至更大，而服务端的接收能力和大模型处理的速度都是有限的。直接无脑上传大图，轻则超级慢，重则直接超时。

我实现了一套三级上传策略：

• 前端压缩：图片在本地先做一次压缩，最长边压到2048px，JPEG质量设为0.85。对大部分修图场景（调色、裁剪、加文字）来说，2048px足够用了，但文件的体积能压缩掉60%-70%。这一步能省下大量的上传时间和服务端处理时间。
• 断点续传：对于超过10MB的图片（比如用户选择了原图上传），走分片上传。每片2MB，失败自动重试，上传完成后服务端合并。
• 原图保留：对于需要高质量输出的场景（比如老照片修复、超分辨率），前端保留原始图片URL，后端在需要大图时通过URL二次拉取原图，而不是一开始就上传全量原图。

这套策略实现之后，我的实测数据是：一张12MB的智能手机照片，常规修图场景下实际从用户开始选图到图片可编辑的等待时间从原来的8~10秒降到了2~3秒，整个体验的流畅感提升非常明显。

4.2 流式返回与进度感知

传统后端API的做法是等所有处理完成后一次性返回结果，但对AI修图Agent来说这不行。一次修图要经过模型推理、工具执行等多个耗时步骤，总时间可能达到5~20秒。如果让用户对着一个转圈的loading等十几秒，大概率会觉得产品坏了。

我的方案是服务端SSE（Server-Sent Events）流式推送。

每次Agent状态变化，后端就主动向前端推送一条事件。前端收到事件后实时更新界面上的进度条和文案提示。

事件推送格式如下：

{ "type": "status_change", "data": { "taskId": "task_123456", "status": "tool_success", "toolName": "brightness", "message": "亮度调整完成", "previewUrl": "https://xxx.com/preview/xxx.jpg" } }

前端实现SSE的方式不复杂：

const eventSource = new EventSource(`/api/v1/tasks/${taskId}/events`); eventSource.onmessage = (e) => { const payload = JSON.parse(e.data); // 更新任务状态 updateTaskStatus(payload.data); // 有新的预览图就刷新展示 if (payload.data.previewUrl) { previewImage.value = payload.data.previewUrl; } };

这里我用了Golang标准库自带的能力实现SSE，重点是设置正确的响应头，让连接保持长连接不断开。每一步工具执行完就推一条事件，用户能实时看到"正在处理亮度→正在加文字→正在导出",在心理上极大地缓解了等待焦虑。

4.3 UniApp多端的适配代价与策略

UniApp表面上一套代码跑多端，实际操作起来，条件编译（#ifdef）是家常便饭。不同端的差异主要集中在三块：上传API的差异、Canvas绘制的差异、安全区域的差异。

上传这块Web端用的是XMLHttpRequest方式，App端用的是plus.uploader，小程序端用的是wx.uploadFile。UniApp提供了uni.uploadFile统一封装，但返回的数据结构在各个端上还有细小的差异。我通通包了一层uploadImage函数，内部做差异兼容。

Canvas调色的差异是最烦的。Web端和App端对Canvas的像素级操作API虽然都叫getImageData/putImageData，但H5端受跨域问题限制，App端对canvas类型（2d vs webgl）的支持又有所区别。我的处理策略是：Canvas只用于用户预览和轻量级绘制，真正服务端处理的图像操作不依赖前端Canvas能力，这才彻底规避了不同端canvas兼容性的物理坑。

4.4 数据模型与图片存储方案

图片存储是AI修图项目的基础设施。如果自己搭对象存储服务，得考虑扩缩容、数据冗余、CDN加速，运维成本不低。我的方案是把图片放到云端对象存储（兼容S3协议），服务端生成预签名URL供前端上传和展示。

数据表结构方面，这个项目涉及的核心模型有用户表、图片资产表、任务表、工具执行日志表，关键表的设计如下：

• 图片资产表（image_assets）：记录原始图、中间图、成品图的URL列表、宽高信息、大小、所有者ID、上传时间
• 任务表（agent_tasks）：记录Agent任务的状态、计划JSON、当前执行步骤、错误信息、创建时间和完成时间
• 工具日志表（tool_logs）：记录每一次工具调用的入参、出参、耗时、错误信息，用于排查问题和后续调优

日志表的设计当时看起来有点多余，但实际在排查线上问题的时候帮了大忙。有一次某个用户一直反馈"调色后图片异常"，我通过工具日志表发现是特定的输入图片格式触发了一个色值转换的边界bug——没有日志表的话，这种问题根本无从查起。

5. 踩坑实录：从"能用"到"好用"的三次关键排障

一个项目从能跑通到真正好用，中间隔着无数个坑。这个项目一路走来，我记录了十几个值得分享的问题，挑选三个最有代表性的展开来说，它们分别涉及Agent逻辑、性能、多端交互三个层面。

5.1 Agent幻觉：模型生成了不存在的工具

上线内测第一周，我就遇到了一个让人抓狂的问题。用户上传了一张图片说"帮我把背景换成的草坪"，Agent返回的计划里居然有一个change_background工具。问题是，我压根没有注册这个工具！原因在于我的工具清单里确实有一个remove_background，模型似乎"理解"了换背景的需求，但出于某种原因编造了一个自以为合理的工具名，而没有选用remove_background组合后续操作。

排查过程：我先在日志里找到了这条错误记录，然后复现了用户的输入，用同样的Prompt去调大模型接口，发现确实能稳定复现。接着我对比了正常的工具调用Request Body和这次的差异，发现模型生成的函数名在语义上接近但名称不对，也就是典型的"幻觉"。根源在于我Prompt里的工具描述还不够清晰严格，模型在生成时存在一定的自由度。

修复方案有两层：第一层是在Prompt里加强约束，明确写"只能从工具列表中选取，不允许自行创造工具名称，如果用户需求不匹配任何工具，请使用error工具反馈不支持的请求"；第二层是后端兜底，在反序列化JSON时做白名单校验，一旦发现未注册的工具名，自动将任务标记为失败并返回友好错误提示"这个操作目前还在开发中"。双保险下来，这个问题再没出现过。

5.2 图片处理的内存溢出：高清大图的死局

有一个周末，我收到一条服务告警：后端进程内存飙升到80%，然后直接OOM被操作系统杀掉。我一看监控，发现是一个用户上传了一张超高清的扫描图，像素达到了8000×6000，直接触发了super_resolution超分模型处理。

问题出在超分模型上。超分模型需要把输入图片的像素放大4倍，8000×6000的原图放大4倍后是32000×24000，换算下来是7.68亿像素，内存占用直奔2GB以上，直接把进程干崩了。

排查链路：内存突然飙升→盯日志发现是超分功能→用同样的尺寸的测试图复现→果然复现了OOM→阅读超分模型的源码发现没有做尺寸限制→确认根因是没有任何前置的尺寸检查。

修复方案是两层：第一，入口做限制，后端在调用超分工具之前检查图片尺寸，超过4000×3000限制就直接拒绝并提示用户先用resize缩小；第二，模型层做分块处理，把大图切成若干个1024×1024的小块分别超分，再拼接回来。这两个修复落地后，即使遇到超出限制的大图，也不会再出现整进程挂掉的情况。

5.3 小程序端的Canvas跨域污染

小程序端有个奇怪的问题：图片处理完成后，结果图用Canvas绘制并导出时，在某些Android机型上报"canvas is tainted"错误。查了半天，发现是图片资源域名没有配置到小程序后台downloadFile合法域名导致的跨域问题。

排查链路：用户反馈结果图无法分享到朋友圈→我从小程序日志里发现canvas导出异常→检查代码，发现Canvas绘制的Image元素src直接指向了对象存储的CDN域名→查微信小程序文档，发现必须是downloadFile和uploadFile合法域名白名单内的资源才能正常绘制→比对后确认CDN域名确实没加。

修复方案：先把图片资源域名和API域名加到小程序的合法域名白名单，同时代码层面做了兜底——在Canvas绘制前先调uni.downloadFile把图片下载到本地临时目录，用本地路径做绘制，彻底绕开跨域限制。这个坑给所有做UniApp多端的提了个醒：域名白名单配置一定要最先搞定，不然后续的图片类功能全会被卡住。

6. 性能优化与并发控制：一整套可复用的实战参数

全栈项目不能只满足于"能跑"，还得面对并发、延迟、成本这些问题。这个项目落地过程中，我在性能优化上投入了不少精力，很多参数是可以直接抄作业的。

6.1 Agent任务队列与并发限流

AI修图Agent和普通CRUD最不一样的地方在于：每个任务都要调用外部大模型API和图像处理服务，这些服务都是收费的，而且都有速率限制。如果放任用户并发请求，一方面费用会失控，另一方面会触达上游API的QPS限制被限流，反而拖垮整体体验。

我实现了一个基于Golang Channel的任务队列，设计参数如下：

var ( maxConcurrentTasks = 8 // 最大同时执行任务数 maxQueueLen = 200 // 队列最大长度 taskQueue = make(chan *Task, maxQueueLen) )

任务进来先入队，worker goroutine从队列里取任务执行。超过队列长度后返回"当前任务过多，请稍后重试"的友好提示。

实测下来，单机8并发的情况下，既能保证单任务响应速度（不至于机器资源耗尽），又能控制单日大模型API的费用在一个合理范围。如果把并发改为16，费用直接翻倍，但用户体验几乎无差别，性价比不高。

6.2 SSE推送带宽与消息合并

SSE解决了实时性问题，也带来了新问题：每个事件都是一次HTTP消息，高频推送时网络开销不小。尤其当一个用户连续执行多个工具步骤时，如果每一步都推送一次，消息量很可观。

我的策略是合并+节流：对状态查询类的低频信息（比如排队中）采用定时汇总推送；对预览图更新类的高频信息采用100ms级别的节流，只推送最新状态；同时对于无需前端响应的中间过程日志（比如"模型推理完成，耗时2.3秒"）,不推送到前端，只记录到服务端日志表，前端只接收真正需要展示的状态变化事件。这样SSE消息量减少了60%，但用户感知上并没有太大区别。

6.3 图片缓存的终极方案：URL指纹

图片处理的一个高频需求是"同一张图反复用不同参数处理"。如果每次处理都走完整链路，效率和成本都很不划算。我的方案是在后端加了一个URL指纹缓存。

核心逻辑是：每个任务生成时，根据图片内容哈希和工具参数列表生成一个唯一指纹，缓存的key就是指纹。下一次用户用相同参数处理相同图片时，直接命中缓存，秒级返回结果，连大模型都不用调用。这个策略在实际使用中命中率大概在15%~20%，别小看这个比例，对大模型API的费用节省非常可观。

func generateCacheKey(userID string, imageURL string, toolCalls []ToolCall) string { h := sha256.New() h.Write([]byte(userID + "|" + imageURL)) for _, tc := range toolCalls { h.Write([]byte(tc.Tool + "|" + fmt.Sprint(tc.Params))) } return fmt.Sprintf("%x", h.Sum(nil)) }

7. 这个项目做完，我对全栈AI应用开发的四点体会

项目交付那一刻，我复盘了整个开发过程，有两个感受特别强烈。一个是"全栈"这个词的分量——它不是会写几行前端、几个后端接口那么简单，而是要从用户体验一直想到底层模型调用，任何一个环节的知识短板都会成为整个链条的瓶颈。另一个是对"Agent"这件事的理解——真正的Agent不是套壳聊天机器人，而是把大模型的能力和外部工具的能力编织在一起，形成一个能闭环解决问题的系统。

第一点体会是技术选型要为业务目标服务，不要为技术本身服务。这套Vue+Golang+UniApp的组合，单独拆开看都不是最"性感"的技术，但组合在一起就是这个项目的最优解。你不应该因为某个框架流行就追着用，而应该问自己：我的用户是谁？我要交付什么体验？哪个技术栈能最快守住这个体验？

第二点体会是Agent的质量上限，一半取决于Prompt工程，一半取决于工具链的设计。Prompt工程决定了大模型能不能准确理解意图并生成合理的计划，工具链设计决定了计划能不能被稳定执行。两者缺一不可。如果工具没有做参数校验，再好的计划也会执行失败；如果Prompt没有约束输出格式，整个Agent就像脱缰的野马，根本不能控制。

第三点是全栈AI应用调试的难度，远超传统应用。传统应用出问题，链路是清晰的：前端→后端接口→数据库。AI应用出问题，可能是模型理解错了，可能是Prompt没写对，可能是工具参数校验漏了，可能是缓存命中了错误的结果，排查链路长了不止一倍。所以我强烈建议在项目一开始就做好日志和追踪体系，这个投资一定值得。

第四点是前端体验决定了一个AI产品的口碑。模型能力再强，如果前端的交互和进度提示做得不到位，用户感知到的依然是"卡""慢""不知道在干什么"。这次项目里流式状态推送的那套交互，虽然实现起来多花了一些时间，但用户的反馈非常正面，很多人说"能看到每一步的执行过程，感觉这个AI很聪明"。

如果你的下一步规划也在这个方向上，我建议重点关注这几件事：一是Agent工具的生态扩展，把更多专业图像算法纳入进来，比如风格化迁移、局部重绘、AI扩图这样的能力；二是进一步优化推理成本，尝试更小的蒸馏模型做意图识别，降低对大型API的依赖；三是往多用户协同方向延伸，让一个团队可以共享修图流程模板和参数预设。

全栈AI修图Agent这个品类还有很多空间可以挖，市面上真正把交互体验和Agent机制结合得很完善的产品还不多，做下去一定还有机会。