做设计 Agent，模型不是最难的：先把“好看”做成验收

“帮我做一张产品发布图，明天上午要用。”

这类消息，大概每个做产品的团队都见过。以前它会进设计排期；现在，很多人会顺手 @ 一下 AI。它通常也真能给你一张像样的图：有渐变、有大标题、有几个看起来很懂科技的圆角卡片。

问题也出在这里。“像样”离“能代表公司发出去”还隔着一条很长的路。 字体不对、信息层级错了、产品名写错、图表没有口径、改第三轮时把第一轮修好的地方又弄丢……这些事，单靠多写两句 Prompt 很难稳定解决。

LangChain 刚把内部的设计 Agent Content Studio 开源。它驻留在 Slack：同事丢一条需求和几份素材进去，系统可以产出社媒图、演示文稿、图表、动效和视频。官方披露，自 8 月以来它交付了 3,000 多个素材和 80 多套 deck；中位模型成本从 9 月中旬约 8 美元降到约 50 美分。相关工作流与代码都能在 官方说明 和仓库中核对。

这组数字很亮眼，但我更在意另一个信号：他们没有把它包装成“一个会画图的模型”。他们把品牌、技能、沙盒、协作线程、记忆和渲染检查捆在了一起。

如果你也在考虑让 AI 帮团队做 PPT、产品配图或活动物料，下面这四层，往往比先选哪个模型重要。

先别把“会出图”当成“会设计”

一个设计需求里，模型最容易完成的是表面动作：排几行字、挑一组颜色、生成一张插画。最难的是判断：这张图是不是我们的；信息有没有先后；数据图能不能读；用户看到后会不会误解；下一位同事接着改时，规则还在不在。

Content Studio 的做法很直白：把“设计师脑子里的判断”拆成可调用的技能、设计 wiki 和品牌包。它的常驻提示词不塞满所有规范；收到需求后，先由路由技能选择工作流，再按任务加载对应的技能。仓库当前公开了 35 个技能，覆盖静态图、图表、deck、视频等不同路径。

这不是为了让 Agent 显得更复杂，而是为了把一句模糊的“不要做得像 AI 模板”换成可执行条件。例如：

• 品牌色、字体、间距来自 token，而不是临时让模型猜；
• 图表有坐标轴、单位和数据校验，不靠渐变柱子制造“数据感”；
• 标题、Logo、安全边距这些能机器检查的部分，在渲染时直接拦住；
• 仍然需要人判断的品味问题，留给设计师写进规则和复盘。

同一张招聘图需求：右侧的 Content Studio 版本把品牌规则落实到了版式、字体和图表。图源：LangChain 开源仓库。

这里有个很容易被忽略的顺序：先把“什么算过关”写出来，再谈让模型多做一点。

一支两三人的团队，不需要一上来写 35 个技能。可以先找一个每周反复出现的任务，例如“把产品更新整理成 1200×627 的发布卡片”。给它列一页规则就够了：标题最多几行、哪些词不能改、何时必须展示数据来源、哪几种颜色不许搭配、交付前要跑哪几个尺寸。那页规则，才是后续 Prompt、工具和评估的共同地基。

设计 Agent 的“电脑”，不是背景配置

很多演示看起来像这样：输入一段话，模型吐出一张图片。真放进团队协作后，交付物不是一张图片，而是一个可以继续修改的项目。

Content Studio 给每个 Slack 线程分配一个独立 sandbox：里面有浏览器、视频和图形工具、字体以及项目目录。幻灯片是 HTML，视频是动画时间线；需求改动后，系统修改源文件再渲染，而不是把上一张 PNG 当起点重新赌一次。

按官方架构重新绘制：一个线程、一台隔离电脑、一个可复用项目目录都放在模型之外。图源：LangChain 官方说明。

这层设计解决的不是炫技，而是三件很工程的事。

第一，改稿要有可追溯的底稿。 如果每次修改都只是“再生成一次”，团队永远不知道这次变好是因为改了文案、换了图，还是模型碰巧发挥稳定。把图表、页面、脚本和素材放在项目目录里，才有 diff、版本和可重复渲染。

第二，长任务不能让对话窗口当文件系统。 做一套几十页的演示，或者一条有配音和镜头的片子，等待、失败和中途追加意见是常态。官方实现中，主 Agent 可以把大任务拆给异步子任务；线程里新增的消息会进入正在运行的项目。这里真正有价值的是状态管理：什么在跑、什么失败、费用到哪了、下一次从哪里接上，而不是“同时开了几个 Agent”。

第三，权限必须跟素材流分开。 官方仓库明确写了 sandbox 默认无网络，也不放 API key；取资料、生成图片、交付文件这些动作由宿主工具处理，再把结果作为文件交给项目。你不必照抄它的基础设施，但至少要回答：哪个组件能读公司的文档？哪个组件能访问素材库？谁能把成品发到外部？如果没有这些答案，设计 Agent 很容易从“帮忙做图”滑向“有权限的自动化入口”。

一条好看的结果，背后至少有一次“看回去”

LangChain 在仓库里放了一张很诚实的对比图：同一个招聘图需求，普通编码 Agent 做出的版本里，Logo 错了、字体泛化、柱状图没有坐标；Content Studio 的版本才更接近他们自己的规范。

差别不在模型突然学会了审美。官方给出的机制是：先渲染、再查看；色彩、字体、对比度、尺寸和图表数学这些能计算的项目，在每次渲染时检查；设计师保留对品味的判断。

这给团队一个很实用的分工法：

事情	更适合谁负责	交付前怎么验
文案是否漏字段、Logo 是否正确、图片是否超出尺寸	规则与脚本	自动阻断或给出明确报错
图表数值、坐标轴、百分比合计	数据与规则	数据源、计算和渲染三处对照
版式是否清楚、是否符合品牌气质	设计师与可学习的规范	小样评审、规则沉淀与回归测试
要不要发布、是否适合这次活动	业务负责人	人工确认，不交给“看起来不错”的自动判断

很多团队的第一个版本只做了最上面一行：把文案和 Logo 塞进去，跑完就发。结果当然会越来越像批量生成，因为系统从来没有机会知道哪里不及格。

一个更稳的起点，是给每个重复任务留一张小小的验收单。比如一张发布卡至少检查：产品名与版本号、品牌字体、主标题在手机缩略图是否可读、数据口径、图片授权或来源、导出尺寸、需要人工确认的风险点。它不需要华丽，但必须能在每次交付前重复执行。

把“别再犯这个错”留在系统里，而不是聊天记录里

设计协作里最贵的返工，通常不是第一次做错，而是同一个错每周再来一次。

Content Studio 设计了团队记忆和个人记忆两层：前者放所有人都要遵守的品牌约束，后者保存某位同事的偏好。每次任务结束后，系统会记录哪些做法有效；后续任务读取并给这些经验打分，不可靠的记录会被丢弃。

这个思路比“给 Agent 一个超长系统提示词”靠谱得多。因为长提示词的两个常见结局是：要么所有规则都塞进去，模型每次都带着一整本说明书；要么大家在不同聊天里补了一堆临时要求，下一次又从头犯错。

更好的做法是区分三类东西：

1. 不可讨论的公共规则：品牌名、禁用色、授权要求、数据标注方式。它们应该版本化，改动要有人负责。
2. 任务技能：做发布卡、做路线图、做会议 deck、做图表。每个技能只加载完成任务需要的规则和工具。
3. 可被推翻的经验：某种布局在移动端不易读、某位同事偏好先给三个方向、某个图片工具容易改坏中文。这类记录要能被新证据更新，不能变成永久教条。

这三层混在一起，Agent 就会时而死板、时而失忆。拆开之后，团队才知道哪一处是在改制度，哪一处是在补流程，哪一处只是一次试验。

开源仓库能省掉搭架子的时间，不能替你完成四件事

Content Studio 采用 Apache 2.0 开源，仓库给了本地 demo、Slack 部署路径、sandbox 配方和自托管方向。它默认使用 Claude Opus 5.5，也支持其他兼容模型；但官方同时说明，托管运行、sandbox、Slack 集成和排程本身有独立成本。约 50 美分是 LangChain 内部的中位模型开销，不是把仓库 clone 下来就能保证拿到的报价。

如果准备试，先别把目标定成“让 AI 替代设计师”。拿下面四件事做一周试验，收获会更真实：

1. 选一个窄任务。 不是“所有营销素材”，而是每周都会出现、输入相对完整、输出尺寸固定的一类图或一页 deck。
2. 准备品牌最小包。 Logo、颜色、字体许可、常用版式、不能说的话、三个优秀样例和三个反例。缺这一步，后面只是在让模型模仿互联网平均值。
3. 写下验收与人工关口。 哪些能自动检查，哪些必须由设计、法务或业务确认；没有通过时要返回什么信息，而不是只写“请优化”。
4. 用十个真实需求做回放。 记录首稿可用率、平均改稿轮数、失败原因、模型和工具成本。若只看一张最好看的样例，任何 Agent 都容易显得无所不能。

官方 README 也给出了一个很小的本地入口：先构建 sandbox，再运行 demo；真要部署到团队 Slack，则需要准备 LangSmith、模型密钥和对应集成。命令本身不难，难的是你是否已经能回答“它输出不合格时，系统怎么知道”。

curl -fsSL https://raw.githubusercontent.com/langchain-ai/design-agent/main/install.sh | bash
cd design-agent
uv run design-agent sandbox publish
uv run mda deploy

上面这四行是官方 quickstart 的缩略版。它适合有 Docker、Slack 和相应托管服务条件的团队；不具备这些条件时，也可以先从仓库的本地 demo 和一个固定尺寸的静态物料开始。不要为了追一次“全自动”，把品牌资料、权限边界和验收环节全跳过去。

再回到那条 Slack 消息。

“明天上午要一张发布图”这件事，真正该自动化的不是按下生成按钮，而是团队已经反复做过、已经说清标准、已经知道怎么验收的那一部分。模型负责加速，系统负责不让速度把质量和边界一起冲掉。

你们团队里，哪一类设计需求最重复、也最适合先被写成一条可验收的 Skill？