Slack里的设计代理：交付3000+资产，请求成本从8美元降到50美分

关键要点

- 品味来自上下文。 模型已经能写好代码，但它们需要你的设计师的原则、防止 AI 平庸输出的护栏，以及反馈背后的推理过程，才能产出像你风格的作品。
- 给代理一台设计师的电脑。 每个 Slack 线程都有自己的沙箱，代理在沙箱中跨轮次保留项目，在视频引擎、图像工具和共享画布之间工作，并检查自己的渲染结果。
- 当模型进步时删除规则。 那些弥补模型弱点的规则会过期，所以保留设计原则，并在模型变好时移除变通方案。
- 长时间运行的代理需要多人协作的 UX。 大型任务由异步子代理运行数小时，因此 Slack 线程会显示计划、实时进度和上线前的审批，团队中的任何人都可以在运行中引导代理。
- 你可以 fork 它。 开源仓库包含完整的脚手架，Managed Deep Agents 可以将它部署到你团队的 Slack 中。

上面的宣传片是由 Content Studio 制作的。Content Studio 是我们的设计代理，只需在 Slack 中发送一条提示，它就能创建视频、社交媒体图形、重建的 UI 图像、幻灯片等。代理生成的每个资产都是用代码编写的。

Content Studio 完全由内部基于 Managed Deep Agents 构建。现在它是公司内使用最广泛的 GTM 代理之一，但一开始并非如此。早期反馈……不太好。

那么，我们是如何从如此低的质量走到今天的？

我们花了四个月时间教 Content Studio 学会我们的品味和设计原则，主要是通过在全公司面前看它犯错。

这篇文章讲述了我们的 GTM 工程团队如何与设计团队一起从零构建 Content Studio：好设计对我们意味着什么，我们如何教会代理我们的品味，以及让它能从静图到发布视频制作任何内容的脚手架。

我们已经开源了我们的设计代理。Fork 开源仓库，添加你的品牌令牌、字体和技能，然后使用 Managed Deep Agents 将其部署到你团队的 Slack。

构建可扩展的设计代理

LangChain 发展很快。我们有持续的产品发布活动、网络研讨会、博客和活动。每项活动都需要资产，从博客头图、图表到幻灯片、视频和广告创意。我们的设计团队捉襟见肘，重复请求挤占了更具战略性和创新性的工作。作为一家精益创业公司，我们需要一种低摩擦的方式，让公司任何人都能创作出高质量、符合品牌调性的作品。

为了满足这些需求，我们构建了 Content Studio，一个驻留在 Slack 中的设计代理。团队成员描述他们想要什么并附上内容或简报，代理返回成品、符合品牌调性的文件。要构建 Content Studio，我们需要三样东西：

- 我们设计师的专业判断力，写入代理的技能和检查中，让它知道好的作品是什么样的。
- 模型周围的自定义环境，包括一台视频编辑计算机，为设计工作的每一层配备工具。
- 正确的 UX，使整个团队可以在一个 Slack 线程中对一个运行数小时的项目进行协作。

Managed Deep Agents 为我们提供了在公司内部将 Content Studio 生产化所需的一切：托管的 LangSmith Sandbox、Slack 集成、托管工具、限定范围的代理记忆和代理运行调度。这使一个小团队可以把时间花在设计工作、技能、工具和 Slack 体验上，而不是花在管道工程上。

关键结果

- Content Studio 已在公司内交付了 3000 多个资产，包括 80 多套幻灯片。其中一套幻灯片甚至被用在了我们观看量最高的自然 YouTube 视频中。
- 使用其作品发布的帖子在 X 上获得了约 450 万次浏览。
- 在 LangChain 账号上，使用其视觉内容的帖子获得的点赞数约为其他帖子的 2 倍，书签数为 3.7 倍。
- 如今四分之三的请求来自营销部门之外，75% 的用户是每周回访的重复用户。
- 现在，一个请求的模型花费中位数约为 50 美分，低于 9 月中旬的约 8 美元。迁移到 Managed Deep Agents 后，我们自己的代码减少了约 80%。

AI 真的擅长设计吗？

在深入构建之前，让我们先谈谈世纪之问：AI 真的能产出好的设计吗？

模型已经很擅长执行，能写 HTML 和 CSS、图表规范和动画时间线。然而，它没有我们的上下文，所以它会求助于熟悉的模式，Anthropic 将这种策略称为“分布收敛”。结果可能看起来很精致，但也可能看起来像其他一百个作品，或者动画很漂亮却词不达意。熟悉并不总是坏事，但我们希望代理做出遵循其目的的选择。

Stripe 的设计主管 Katie Dill 做了一个很有帮助的比较。二战后，在快速建设的压力下，建造者们一遍又一遍地复制现代主义的简洁形状和裸露表面。这些复制品保留了外观，却失去了背后的思想和特征。她警告说，AI 可能对软件做同样的事情。她称之为“僵尸 UI”，并说我们需要一个观点，因为“如果你没有，AI 会替你决定。”

我们不认为 AI 不擅长设计。它只是没有观点，除非你提供给它。而给它我们的观点，意味着教会它我们的品味。

教会设计代理品味

品味是将“正确”的作品与“优秀”的作品区分开来的判断力。在设计领域，两种布局可以使用正确的字体、颜色和间距，但只有一种能传达其意图。品味来自 Dill 所说的“真正擅长注意”。

正是这种注意让我们学会了识别 AI 的平庸输出，这通常出现在简报将决定权留给代理的时候。

例如，下图中左边的图像是由一个本地编码代理使用我们的品牌技能（包括颜色、字体、标志等）创建的。但最终结果缺少关键组件，例如正确的标志组合、文本对齐，以及哪些颜色是我们的主品牌色与次品牌色。

同样的提示在 Content Studio 中产生了完全符合品牌的图像。这是因为本地代理用最常见的内容填补了简报未覆盖的每个决定。而通过我们的方法论，Content Studio 用我们的选择填补了同样的空白。

我们给 Content Studio 的指导方针从基础开始，包括颜色令牌、字体粗细、间距和对齐。但大部分改进来自我们在其上添加的内容。我们引入了设计原则，如每帧一个焦点、针对常见 AI 设计模式的护栏，以及每条反馈背后的推理。结合更好的底层模型，这些帮助 Content Studio 学会更像设计师一样思考和沟通。

一开始并非如此。在我们早期的一个动态图形中，一只鸟飞离屏幕，身后拖着一条光丝带，持续不到一秒。我们要求没有尖锐边缘，但第一遍结果很笨拙，带有生硬的圆角。设计师会理解我们的意思：边缘应该柔化，同时尾巴逐渐变细并朝与鸟运动相反的方向淡出。

到后来的迭代，代理已经能用设计师的眼光评估那个细节了。它通过一个快速草图确定鸟尾巴应该在的位置，然后构建了自己的逐帧检查，以确保丝带保持连接。大多数观众永远不会刻意注意到这个细节，但如果哪里不对，他们会感觉到。

可测量的问题最容易解决。默认大写过去经常在评审中出现，但现在一个自动化检查可以捕获所有实例。更难的决定则更主观，比如一个活动创意是否足够有力、信息是否清晰传达、执行是否引起观众共鸣。当设计师做出这样的判断时，我们会把推理过程捕获到技能中，以便代理在未来的草稿中应用。

Content Studio 改变了谁可以从事设计工作。产品经理、工程师或创始人可以在 Slack 中给代理下简报，然后带着符合品牌且可交付的作品离开。如今四分之三的请求来自营销部门之外。对于设计师来说，角色更接近创意总监：设定方向并评审工作，而不是自己制作每个资产。

获得正确的设计判断只是过程的一部分。我们还需要给代理执行所需的工具和环境。

构建媒体脚手架

设计师会使用多种工具，从用于静图的 Photoshop、用于动态的视频引擎，到用于原型设计和协作的共享画布。他们还依赖品牌指南、设计资产和公司文档。

代理也需要类似的设置：一台可以工作的计算机、设计过程不同部分的工具，以及设计师工作时所依赖的上下文。脚手架将这些部分整合在一起。Deep Agents 提供了底层脚手架，包括代理循环、规划、文件、子代理和上下文管理。Managed Deep Agents 将其打包并在生产中运行。我们在其周围构建了环境，给代理一台可以维护项目、跨工具工作和检查结果的计算机。

第一版脚手架

我们的第一版脚手架试图替模型做设计。早期模型需要很多帮助才能做出我们愿意发布的动态图形或发布影片。为了弥补它们当时还无法自行解决的问题，我们的直觉是把更多我们自己的设计判断放入指令和代码中。

于是，我们构建了一个包含 115 个可复用 UI 组件的设计系统，用于标题、布局和动画，并附带何时以及如何使用它们的指南。这给了模型一组现成的设计可供使用，减少了它必须从头做出的创意决策数量。

这帮助它保持在品牌轨道上，但代理只是重复同样的布局和动画，缺少变化：

我们知道模型最终会擅长这项任务，所以我们继续为那个时刻构建环境，同时试验技能和工具。有时我们添加更多参考或更详细的指令来帮助模型。其他时候我们完全移除它们，看看它能自己做什么。

但结果仍未达到我们的期望，缩小差距需要越来越多的工程工作。我们不断向技能中添加规则，编写更多运动代码，构建更多组件来弥补模型做不到的事。

然后 Opus 5.5 来了，我们立即看到了质量飞跃。我们重新审视了技能，移除了大部分硬编码规则，保留了设计原则和高层指导。结果进一步改善，更多变化且更少重复。模型终于开始做出我们之前试图预先构建的创意决策。

这是我们的“苦涩教训”。为弥补模型弱点而设计的规则，随着模型改进而变得不那么有用。持久的是模型周围的环境，包括它使用的工具、它汲取的上下文，以及人们如何引导它的工作。我们不再预构建创意决策，而是专注于让脚手架足够灵活，以利用每一代新模型。

设计师的计算机

为了展示脚手架的实际运作，我们要求 Content Studio 制作一部关于它如何端到端处理视频项目的影片。结果的主角是一只像素丛林中的鹦鹉，由 David Attenborough 配音。让我们用它来走一遍脚手架的层级：计算机、工具和其工作背后的上下文。

设计是迭代的。你做出一个东西，看它，然后修改，通常要改很多次。因此，代理需要一台可以在整个对话中持续工作的计算机。每个 Slack 线程都有自己的 LangSmith Sandbox，一台带有文件系统和 shell 的隔离 Linux 机器，项目在该线程的整个生命周期中驻留于此。

代理创建的每个东西都是用代码构建的，无论是幻灯片的 HTML 页面、图表的数据规范，还是视频的动画时间线。这使得迭代很容易，而无需从头开始。如果有人要求让鹦鹉更早出现，代理可以更改一个时间值并重新渲染，而不会影响艺术作品或文案。而对于平面图像或生成的视频片段，即使是一个小编辑也可能意味着重新创建整个资产。

简报、计划、场景代码、音频和渲染都保存在一个项目文件夹中，工作中的每个子代理都从中读取。

在此基础上，我们安装了设计师在工作每一层会使用的工具：

动态是最难的一层。 它运行在两个引擎上：

- HyperFrames 用于剪辑： HyperFrames 是 HeyGen 的开源视频框架，将视频变成网页。剪辑、屏幕录制、字幕和文本只是该页面上的元素，GSAP 时间线让它们移动。所以当有人要求给网络研讨会加字幕或剪辑产品演示时，代理像编辑网页一样编辑它。它的 CLI 基本上就是代理的剪辑套件：检查组合、拉取一帧检查、渲染剪辑。我们还安装了 HeyGen 的官方技能，让代理从构建者那里学习格式。
- motion-studio 用于动画： 网页无法模糊快速运动、让东西发光或以 3D 方式旋转标志，而那是我们希望原创动画拥有的质感。所以我们构建了自己的画布引擎。代理编写代码绘制每一帧的每个像素，引擎将多达 16 个时刻混合到每一帧中，就像相机快门模糊运动一样。鹦鹉影片就是用这种方式制作的。

两个引擎都基于时间戳渲染每一帧，因此十秒处的帧无论何时渲染看起来都相同。这让代理可以检查单个时刻而无需渲染整个影片，也允许我们并行渲染多个帧。音频运行在同一条时间线上，保持旁白、音乐和音效与视觉同步。

有了这个设置，代理几乎可以创造任何东西。但如果没有进一步指导，它会默认采用模型自己的设计选择而不是我们的。下一个挑战是教它在我们的品牌和设计标准内工作。

设计师的大脑

我们围绕四个不同的功能来组织代理的知识，每个功能有明确的用途。技能指导如何执行特定任务，而 wiki 提供关于我们公司和优秀作品样子的上下文。任何可测量的东西都由 gate 处理，这是一种用代码编写的确定性检查。一个独立的记忆层捕获人们随时间教给代理的东西。

技能

代理收到请求后做的第一件事是判断它属于什么类型的工作。这由我们的媒体生产技能处理。我们称之为路由器技能，因为它大部分内容是一张表。每一行将一种请求类型（活动、重设计、缩略图、帖子、YouTube 套餐、发布视频、短片动画）映射到处理它的路径和专家技能。路由器还决定工作是否需要共享视觉画布，并保持小编辑不进入完整流程。

对于像上面这样的影片，路由器会选择为导演大型动态制作而设计的发布视频技能。我们的 48 个技能，总共接近 1000 个文件，每个技能都针对一个工作而不是一个主题，所以它的描述读起来像路由规则，包括什么时候不使用它。

技能之间组合而不是重复。launch-film 负责导演，motion-studio 负责画面和声音，所以动画工艺只写一次。launch-film 还携带它将启动的子代理的角色简报，以及一个真实的 88 秒发布影片的案例研究——我们曾用代码逐镜头重建了它。那个案例研究是代理学习如何在子代理之间拆分影片的地方：它在场景硬切换处切割，保持一个连续镜头由一个子代理负责，并在任何人并行工作之前冻结共享代码。

描述对工具和技能同样重要。为了降低上下文使用量，我们将 MCP 工具放在内置搜索之后。代理开始时只有我们自己的工具，需要时通过跨工具名称和描述的关键词搜索加载额外的工具架构。

Wiki

技能解释如何做一项工作，而 wiki 提供做好工作所需的上下文和参考材料。它涵盖了从品牌令牌、图形语言、语音，到平台、活动和产品信息。一个专门的动态 wiki 涵盖导演、工艺、声音和评审，以及 70 个参考影片的分解。

我们没有在技能中重复这些信息，而是直接链接到 wiki。这使共享知识集中在一处，更新更容易。当字体规则之类变化时，我们只需更新一次，每个技能都可以引用最新版本。

知道我们如何工作并不一定使动态设计更便宜。一个错误的创意决策仍然可能花费数小时渲染。

规范驱动设计

动态特别容易出错，无论是在渲染时间还是令牌上。一个故事板帧渲染约 50 毫秒，而一秒成片需要 8 到 40 秒。当子代理编写、渲染和评审每一幕时，这些成本迅速累积。所以代理先在故事板中发展想法，在那里可以低成本探索不同方向，然后在方向获批后再进入完整生产。

为了支持这种探索，我们给代理一个参考影片库来汲取灵感，就像设计师使用情绪板一样。当找不到合适的风格时，它使用图像模型生成新参考，从快速草稿开始，然后细化最有希望的选项。这些图像帮助建立视觉方向，而故事板和最终影片仍然用真实字体和品牌资产在代码中构建。

一旦我们选定方向，批准的故事板就成为后续影片构建所依据的规范。然后项目经过三个阶段：

1. 故事板，用于确定视觉创意、文案和镜头。
2. 动画分镜（animatic），一个按音频定时的粗剪，用来检查静态图无法显示的节奏。
3. 生产，子代理构建、检查和渲染已批准的镜头。

我们最初在技能指令中描述了这一顺序，但代理有时为了省时间会跳过评审。现在管道在代码中强制执行它：组装要等每一幕通过评审，而指令仍然指导创意决策。必须始终成立的顺序放在代码中，判断则保留在提示中。

指向，而不是提示

在这些方向之间做选择是团队的决定。Slack 非常适合请求工作和接收结果，但线程是线性文本，而故事板是空间的，所以反馈最终会变成描述某物在哪里，而不是指向它。每个更改，即使是一个词，都必须作为新提示重新通过代理。

Paper 为我们解决了这个问题。它是一个为代理而设计的设计画布，带有一个 MCP 服务器，让代理直接控制文件。人们可以在同一个文件中工作，并排比较方向，在特定帧上留下评论，或自己进行编辑。因为画布是共享的，代理可以返回文件，利用这些评论和编辑来指导其下一次迭代。

挑战在于 Paper 的代理工具只能在其桌面应用中运行，而我们的代理在云沙箱中运行。为了弥合这一差距，我们在一个常开的 Linux worker 上无头运行 Paper Desktop，使用虚拟显示和经过身份验证的桥接来连接两者。一个设置支持整个团队。

即使在批准之后，把故事板变成成片也可能需要数小时。此时，工作类似于一个小型项目，多块内容并行构建，需要最终整合。协调所有这些超出了单个代理回合的能力。

代理作为幕僚长

考虑之前的鹦鹉影片，在生产中途的 Slack 中。一个人分享了一个参考，另一个人建议不同的开场，第三个人在第四帧留下反馈，而代理仍在构建。这就像一场头脑风暴，记笔记的人还要负责制作影片。同步子代理在这里效果不佳，因为主代理必须等待它们完成，期间无法让人与它交互。

为了解决这个问题，我们让子代理异步化，并将主代理的角色从执行者转变为幕僚长。它将复杂项目分解为更小、更独立的任务，分配给子代理，并并行运行工作。同时，它让团队随时了解变化，以便人们可以继续给出反馈并引导项目。

对于每个任务，主代理创建一个子代理档案，包含清晰的简报，涵盖其角色、相关上下文、文件所有权以及如何验证工作。它还根据任务的复杂性选择模型和努力级别。

我们还添加了一小组工具让主代理协调工作：

- start_task 在后台将一部分任务交给子代理
- check_tasks 显示正在运行的内容并读取完成的报告
- cancel_task 和 resume_task 停止不再符合简报的工作，或从停止处继续
- report_progress 让子代理在任务中发送更新
- schedule_wakeup 为主代理提供一个计时器来触发另一次运行并继续工作

在底层，每个子代理都是普通的 Deep Agents 任务工具，作为后台任务运行。当它完成时，我们的代码将携带结果的新的主代理运行排队。人们还可以在主代理运行中引导它，因为当它工作时收到的消息会被插入到其下一次模型调用之前。子代理通过项目文件夹协调，每个只写自己拥有的文件，并将其进度保存在磁盘上。

随着工作在后台运行，线程必须显示正在发生的事情。主代理通过以下方式保持更新：计划和 ETA、包含运行中子代理、渲染进度和花费的实时状态行、对每次编辑的确认，以及任何内容公开前的审批卡片。

这种方法最清晰的测试之一来自一项通宵工作：为 52 页演示文稿换皮。代理首先创建三个示例幻灯片并自我评审，然后按编号批次处理其余幻灯片以供审批。它还在过程中添加了两张新幻灯片。一夜之间，主代理运行了大约一小时，而它的子代理总共工作了六个多小时，全程没有阻塞对话。

自我改进的脚手架

一位与团队合作数月的设计师会学会其偏好，不需要听到同样的反馈两次。没有记忆，代理会在每个新线程中从零开始。为了避免这种情况，我们构建了两个学习循环。快速循环在人们给出反馈时捕获反馈，而慢速循环在后台从已完成的项目中学习。

快速循环： 当有人分享规则或偏好时，代理在同一回合中将其保存。Managed Deep Agents 将记忆作为普通文件存储在两个层中：一个跨团队共享，另一个针对每个人。

个人偏好跨线程携带，但共享标准优先，任何为公司频道创建的内容都遵循公司声音。每一层都有一个 AGENTS.md 文件，在每次模型调用时加载。早期版本增长到 500K 令牌后，我们现在将这些文件限制为 200 行的索引。

慢速循环： 每次工作结束后，我们的 learn_from_job 工具启动一个轻量子代理，捕获最多五个有证据支持的教训，并将其与使用的技能关联。未来的作业读取并评分这些教训，每周一次，后台代理将有价值的教训纳入技能和 wiki。

下一步

还记得那些早期评审吗？最大的改进来自将设计师的判断捕获到代理可以学习的共享环境中，而不是让其散落在评审线程中。在这个过程中，我们让更多人能够参与设计工作。

接下来，我们希望代理管理整个活动生命周期，其中一些已经在运作。它在授权的审批人批准后通过 Buffer 发布公司社交媒体帖子，为员工起草帖子以便从其个人账号分享，并运行定时例程，包括每日评审，建议值得引用的帖子。

我们的目标是进一步推进，让一个经批准的创意方向可以从一个线程承载整个活动。代理将撰写简报、为每个频道创建资产、安排发布、帮助团队放大内容，并使用性能数据为下一个活动提供信息。在公开之前，人们仍然会评审和批准一切。

构建你自己的设计代理

开源仓库包含这篇文章中的脚手架：沙箱计算机、技能、wiki 和记忆、异步子代理以及 Slack UX。Fork 它，添加你的品牌令牌、字体和技能，然后使用 Managed Deep Agents 将其部署到你团队的 Slack。