要点概览
- 品味来自语境。 模型已经能写出不错的代码，但它们需要你的设计师的设计原则、防止AI垃圾内容的防护栏，以及反馈背后的推理，才能做出看起来像你风格的作品。
- 给智能体一台设计师的电脑。 每个 Slack 线程都有自己的沙盒，智能体在其中在各轮对话之间保存项目状态，跨视频引擎、图像工具和共享画布进行工作，并检查自己的渲染结果。
- 当模型改进时删除规则。 弥补模型弱点的规则会过期失效，因此随着模型不断改进，应保留设计原则并移除那些权宜之计。
- 长期运行的智能体需要多人交互体验。 大型任务会在异步子代理上运行数小时，因此 Slack 线程会显示计划、实时进度，以及在 anything ships 之前的审批，团队中的任何人都可以在运行中途引导该代理。
- 你可以对它进行复刻(fork)。 开源代码库包含完整的测试框架,而 Managed Deep Agents 可将其部署到你团队的 Slack 中。
上面的宣传视频由 Content Studio 制作，它是我们的设计智能体，只需在 Slack 中输入一条提示词，就能创建视频、社交图形、复刻的 UI 图像、幻灯片等。该智能体生成的每个资产都是以代码编写的。
Content Studio完全由内部团队基于构建于 托管式深度智能体。它现在是我们公司内使用最广泛的 GTM 智能体之一，但一开始并非如此。早期反馈……并不理想。
那么，我们是如何从如此低的画质发展到这一步的呢？
我们花了四个月时间向 Content Studio 传授我们的品味和设计原则，主要是通过观察它在全公司面前犯错来实现的。
这篇文章将带您了解我们的GTM工程团队如何与设计团队合作从零开始构建Content Studio：好的设计对我们意味着什么，我们如何教会这个智能体我们的品味，以及让它能够制作从静态图到发布影片等任何内容的支撑框架。
我们已将我们的设计代理开源。 Fork 该 开源仓库，添加您的品牌令牌、字体和技能，然后将其部署到您团队的 Slack，使用 托管式深度智能体.
那就来参加我们的 GTM Engineering Live 于10月28日。我们将深入探讨该测试框架与用户体验的内部机制，并展示那些未能放入本文的工作。
构建可规模化运行的设计智能体
LangChain 发展迅速。我们有持续的产品发布活动、网络研讨会、博客和活动。每项举措都需要素材，从博客头图和图表到演示文稿、视频和广告创意。我们的设计团队不堪重负，重复性的请求挤占了更具战略性和创新性的工作。作为一家精简的初创公司，我们需要一种低摩擦的方式，让公司里的任何人都能创作出高质量、符合品牌规范的作品。
为了满足这些需求，我们构建了 Content Studio，一个驻留在 Slack 中的设计智能体。团队成员描述他们想要什么，并附上相关内容或简报，智能体就会返回成品且符合品牌规范的文件。为了构建 Content Studio，我们需要三样东西：
- 我们设计师的专业判断，写入该智能体的技能和检查中，使其知道好的结果是什么样子。
- 自定义环境 围绕该模型，包括一台视频编辑计算机，为设计工作的每一层提供工具。
- 恰当的用户体验，这样整个团队就可以通过一个 Slack 线程协作完成运行数小时的项目。
托管式深度智能体 为我们提供了在公司内部将 Content Studio 投入生产所需的一切：一个托管式 LangSmith 沙盒、与 Slack 的集成、托管工具、限定范围的智能体记忆以及智能体运行调度。这使得小型团队可以把时间花在设计工作、技能、工具和 Slack 体验上,而不是花在底层管道工作上。
关键结果
- Content Studio 已在全公司交付了超过 3,000 个素材，其中包括 80 多套幻灯片。其中一套幻灯片甚至被用于我们观看量最高的自然流量 YouTube 视频。
- Posts with its work在X上获得了约4.5M次浏览量。
- 在LangChain账号上，带其视觉图的帖子的点赞数约为其他帖子的2倍，收藏数约为3.7倍。
- 如今四分之三的请求来自营销部门之外，75%的用户是每周都会回访的常客。
- 目前每次请求的中位成本约为50美分的模型支出,低于9月中旬的约8美元。在迁移到之后,我们自己的代码缩减了约80%。 托管式深度智能体.
AI真的擅长设计吗？
在开始构建之前，让我们先来讨论一下这个世纪之辩：AI 究竟能否做出好的设计？
该模型在执行方面已经很强，能够编写HTML和CSS、图表规格和动画时间线。然而，它没有我们的上下文，所以它倾向于使用熟悉的模式，即 Anthropic 称之为“分布收敛”。结果可能看起来精致，却仍然像其他一百个作品一样，或者动画很精美，却始终无法传达其要点。熟悉并不总是坏事，但我们希望我们的智能体做出符合其目标的选择。
Katie Dill，Stripe 的设计负责人，作了一个很有帮助的类比。二战后，在快速建设的压力下，建造者们一次又一次地复制现代主义干净的形状和裸露的表面。这些复制保留了外观，却丢失了背后的思考与品格。她的警示是，AI 也可能对软件做同样的事。她称之为“僵尸 UI”，并说我们需要有自己的观点，因为“如果你没有，AI 会替你给一个。”
我们不认为 AI 不擅长设计。它只是没有自己的观点，除非你提供给它，而把我们观点交给它，意味着要教它我们的品味。
教会设计智能体品味
品味是一种判断力，它区分“正确”的作品和“优秀”的作品。在设计中，两个版式可以使用正确的字体、颜色和间距，但只有一个能表达出要点。品味来自 Dill 所说的“非常善于观察”。
正是这种观察力让我们学会了识别 AI 垃圾内容，它最常出现在简报把某个决定留给智能体去处理的时候。
例如，下面左边的图像是由一个带有我们品牌技能的本地编码智能体创建的（其中包含颜色、字体、logo 等）。但最终结果遗漏了关键组件，比如正确的 logo 组合、文本对齐，以及哪些颜色是我们的主品牌色还是次品牌色。
同样的提示词在 Content Studio 中生成了一张完全符合品牌形象的图像。这是因为本地智能体用它见得最多的东西填补了简报未涵盖的每一个决定。而通过这套方法，Content Studio 用我们的选择填补了同样的空白。
我们给 Content Studio 的指南从基础开始，包括颜色 token、字重、间距和对齐。但很多改进来自我们在其之上添加的内容。我们引入了设计原则，比如每一帧只设一个焦点、针对常见 AI 设计模式的防护栏，以及每条反馈背后的推理逻辑。结合更好的底层模型，这些帮助 Content Studio 学会更像设计师那样思考和沟通。
起初并非如此。在我们早期的一部动态图形中，一只鸟飞出屏幕，身后拖着一条光带，时间不到一秒。我们要求没有生硬的边缘，但第一版效果很笨拙，带有粗糙的圆角。设计师会理解我们的意思。边缘应该柔化，尾巴应逐渐变细，并沿与鸟运动相反的方向淡出。
到后来的迭代，智能体已经能以设计师的眼光评估这个细节。它用一张快速草图确定鸟尾巴应该在哪里，并构建了自己的逐帧检查，以确保光带保持连接。大多数观众不会在有意识层面注意到这个细节，但如果哪里不对劲，他们会感觉到。
可衡量的问题最容易解决。默认大小写过去常常在审查中出现，但现在一个自动检查能捕捉每一个实例。更难的决策则更主观，比如一个营销活动创意是否足够强、信息是否传达清晰，或者执行是否引起观众共鸣。当设计师做出这类判断时，我们会把推理记录到一个技能中，让智能体能将其应用到未来的草稿中。
Content Studio 改变了谁能做设计工作。PM、工程师或创始人可以在 Slack 中给智能体下达简报，然后拿到符合品牌形象、可以发布的东西。现在每四个请求中就有三个来自营销部门之外。对设计师来说，角色更接近创意总监，负责设定方向和审查作品，而不是自己制作每一个素材。
把设计判断力做好只是流程的一部分。我们还需要给智能体执行这些判断所需的工具和环境。
构建媒体 harness
设计师会使用多个工具，从用于静态图的 Photoshop、用于动效的视频引擎，到用于原型设计和协作的共享画布。他们还依赖品牌指南、设计素材和公司文档。
智能体也需要类似的配置：一台工作的计算机、覆盖设计过程不同部分的工具，以及设计师工作中所具备的上下文。harness 将这些部分整合在一起。 Deep Agents 提供了底层的 harness，包括智能体循环、规划、文件、子智能体和上下文管理。 Managed Deep Agents 将其打包并在生产环境中运行。我们围绕它构建了环境，给智能体提供了一台计算机，让它可以维护一个项目、跨工具工作并检查结果。
harness_v1
该 harness 的第一个版本试图替模型完成设计工作。早期模型需要大量帮助，才能制作出我们愿意发布的动态图形或发布影片。为了弥补它们自己还搞不定的地方，我们的直觉是把更多我们自己的设计判断写入指令和代码中。
于是，我们构建了一个包含 115 个可复用 UI 组件的设计系统，涵盖标题、版式和动画，并附有关于何时以及如何使用它们的指导。这给了模型一套现成的设计可作参考，减少了它必须从零做出的创意决策数量。
这帮助它保持了品牌一致性，但智能体会对每一帧重复相同的版式和动画，缺乏变化：
我们知道模型最终会在这个任务上表现出色，所以我们一直在为那一刻打造环境，并在此过程中不断试验各种技能和工具。有时我们会添加更多参考或更详细的指令来帮助模型。其他时候我们会完全删掉它们，看看模型自己能做什么。
但结果仍未达到我们的预期，而缩小差距需要越来越多的工程工作。我们不断往技能里添加规则，编写更多动效代码，构建更多组件来弥补模型做不到的部分。
然后 Opus 5.5 到来了，我们立刻看到了质量上的跃升。我们重新审视了这些技能，删除了大部分硬编码的规则，只保留设计原则和高层次指导。结果进一步改善，变化更多、重复更少。模型终于开始做出那些我们过去试图预先替它构建好的创意决策。
这就是我们的 苦涩教训（Bitter Lesson）。为弥补模型弱点而设计的规则，会随着模型进步而变得不那么有用。能够留存下来的，是模型周围的环境，包括它使用的工具、它获取的上下文，以及人们如何引导它的工作。我们没有预构建创意决策，而是专注于让这个支撑框架足够灵活，以充分利用每一代新模型。
设计师的电脑
为了展示这个支撑框架的实际运作，我们让 Content Studio 制作一部短片，完整呈现它如何端到端地处理一个视频项目。结果的主角是一只生活在像素丛林中的鹦鹉，以大卫·爱登堡（David Attenborough）的风格进行解说（配音使用 ElevenLabs）。让我们借助这部片子来逐一了解支撑框架的各个层次：它工作背后的电脑、工具和上下文。
设计是迭代的。你做出一个东西，看看它，然后修改，往往要重复很多次。因此智能体需要一台能在整个对话过程中持续使用的电脑。每个 Slack 线程都有自己的 LangSmith Sandbox，这是一台带文件系统和 shell 的隔离 Linux 机器，项目在线程存续期间都保存在那里。
智能体创建的一切都是用代码构建的，无论是幻灯片的 HTML 页面、图表的数据规范，还是视频的动画时间轴。这使得迭代变得容易，无需从头再来。如果有人要求让鹦鹉更早出场，智能体只需修改一个时间值并重新渲染，而不会影响画面或文案。如果是一张扁平图片或一段生成的视频片段，即使是很小的修改也可能意味着要重新创建整个素材。
简报、计划、场景代码、音频和渲染结果都存放在同一个项目文件夹中，参与这项任务的每个子智能体都基于这个文件夹工作。
在此之上，我们安装了设计师在工作的每个层次中会用到的工具：
动效是最难的层次。它运行在两个引擎上：
- HyperFrames 用于剪辑： HyperFrames是 HeyGen 的开源视频框架，它把视频变成一个网页。片段、屏幕录制、字幕和文本都只是那个网页上的元素，而一条 GSAP 时间轴负责移动它们。所以当有人要求为网络研讨会添加字幕或剪辑产品演示时，智能体就像编辑网页一样进行剪辑。它的 CLI 基本上就是智能体的剪辑套件：检查组合、抽取某一帧来确认、渲染成片。我们还安装了 HeyGen 的官方技能，这样智能体就能从构建这套框架的人那里学到这种格式。
motion-studio用于动画： 网页无法对快速运动做模糊处理、无法做出发光效果，也无法让一个 logo 做 3D 旋转，而这正是我们希望原创动画达到的质感。所以我们构建了自己的画布引擎。智能体编写代码来绘制每一帧的每一个像素，而引擎会把最多 16 个时刻混合进每一帧，就像相机快门模糊运动一样。鹦鹉短片就是这样制作的。
两个引擎都基于时间戳渲染每一帧，所以十秒处的帧无论何时渲染看起来都一样。这让智能体可以检查单个时刻而无需渲染整部影片，同时也让我们能够并行渲染多帧。音频运行在同一条时间轴上，使旁白、音乐和音效与画面保持同步。
有了这套配置，智能体几乎可以创造任何东西。但如果没有进一步的指导，它会默认采用模型自身的设计选择，而不是我们的。下一个挑战是教它在我们的品牌和设计标准之内工作。
设计师的大脑
我们将智能体的知识组织为四个不同的功能，每个都有明确的用途。技能（Skills）指导如何执行特定任务，而维基（wiki）提供关于我们公司以及什么是优秀工作的背景信息。任何可衡量的内容都由一个门控（gate）处理，即用代码编写的确定性检查。一个单独的记忆层则记录人们随时间教会智能体的内容。
技能
智能体收到请求后做的第一件事，是判断这是哪一类工作。这由我们的 media-production 技能处理。我们称之为 路由技能（router skill） 因为其中大部分其实只是一张表。每一行将一种请求类型(一次营销活动、一次改版、一张缩略图、一篇帖子、一个 YouTube 套件、一部发布影片、一段短动画)映射到相应的路径和处理它的专业技能。这个路由器还会判断该工作是否需要一个共享的视觉画布,并且让小的编辑绕开完整流程。
对于像上面这样的影片,路由器会选择 launch-film 专为导演大型动态影片制作而设计的技能。我们的 48 个技能总共接近 1,000 个文件,每个技能都按工作而非主题划分范围,因此其描述读起来就像一条路由规则,包括何时不该使用它。
技能相互组合,而不是彼此重复。 launch-film 负责导演, motion-studio 负责制作画面和声音,因此动画的技艺只需编写一次。 launch-film 还包含它将启动的子智能体的角色简报,以及一个真实 88 秒发布影片的案例研究,我们逐个镜头用代码重建了这部影片。正是在这个案例研究中,智能体学会了如何在子智能体之间拆分一部影片。它在硬性场景切换处剪辑,让一个子智能体保持连续的镜头运动,并在任何人并行工作之前冻结共享代码。
描述对工具和对技能同样重要。为了降低上下文使用量,我们将 MCP 工具置于内置搜索之后。智能体起初只有我们自己的工具,并按需加载额外的工具模式,通过跨工具名称和描述的关键词搜索来实现。
Wiki
技能解释如何完成一项工作,而 wiki 则提供做好这项工作所需的上下文和参考资料。它涵盖从品牌令牌、图形语言和声音到平台、活动和产品信息的所有内容。专门的动态 wiki 涵盖导演、技艺、声音和评审,并附有对 70 部参考影片的拆解分析。
我们没有在各技能之间复制这些信息,而是直接链接到 wiki。这使得共享知识集中在一处,也使更新更加容易。当诸如字体规则之类的某项内容发生变化时,我们只需更新一次,每个技能都能引用最新版本。
了解我们的工作方式并不一定能让动态设计变得更便宜。一个错误的创意决定仍然可能耗费数小时的渲染时间。
规格驱动设计
动态设计尤其经不起出错,无论是渲染时间还是令牌成本。渲染一个分镜画面大约需要 50 毫秒,而渲染一秒钟成品影片则需要 8 到 40 秒。当子智能体为每一幕进行编写、渲染和评审时,这些成本会迅速累积。因此,智能体首先在分镜中发展创意,在这里可以低成本地探索不同方向,待方向获得批准后再进入完整制作。
为支持这种探索,我们为智能体提供了一个可供汲取灵感的参考影片库,就像设计师参考情绪板一样。当它找不到合适的外观时,会使用图像模型生成新的参考,先从快速草稿开始,再对最有前景的选项进行细化。这些图像帮助确立视觉方向,而分镜和最终影片仍使用真实排版和品牌资产以代码构建。
一旦我们选定了方向,经批准的分镜就成为影片其余部分构建所依据的规格。然后,项目经历三个阶段:
- 分镜,用于就视觉创意、文案和镜头达成一致。
- 动态分镜(animatic),与音频同步的粗剪,用于检查静帧无法体现的节奏。
- 制作,由子智能体构建、检查并渲染经批准的镜头。
我们最初在技能指令中描述了这个顺序,而智能体有时会跳过评审以节省时间。现在,流水线在代码中强制执行这一顺序,因此组装会等待每一幕都通过评审,而指令仍用于引导创意决策。必须始终遵守的顺序存在于代码中,而判断力保留在提示词中。
指点,而非提示
在这些方向之间做出选择是一项团队决策。Slack 适合用来请求和接收工作成果,但线程是线性的文字,而分镜是空间性的,因此反馈最终只能描述某个东西在哪里,而不是直接指向它,并且每一次修改,哪怕只是一个词的修正,都必须作为新的提示词回传给智能体。
Paper 为我们解决了这个问题。它是一个专为智能体协作而构建的设计画布,配有 MCP 服务器,使智能体能够直接控制文件。人们可以在同一个文件中工作,并排比较不同方向,对特定帧发表评论,或亲自进行编辑。由于画布是共享的,智能体可以返回文件,利用这些评论和编辑来指导下一次迭代。
挑战在于 Paper 的智能体工具只能在其桌面应用内运行,而我们的智能体在云端沙箱中运行。为了弥合这一差距,我们在一台始终在线的 Linux 工作机上以无头模式运行 Paper Desktop,使用虚拟显示和经过身份验证的桥接来连接两者。只需一次设置即可支持整个团队。
即使获得批准后,将分镜变成成品影片也可能需要数小时。到那时,这项工作已类似一个小型项目,多个部件正在并行构建并需要汇聚到一起。协调这一切超出了单个智能体回合所能处理的范围。
智能体作为幕僚长
想想前面提到的鹦鹉影片,当时正处于 Slack 中的制作中期。一个人分享了一个参考,另一个人建议不同的开场,还有第三个人对第四帧留下反馈,而这一切都发生在智能体仍在构建的时候。这就像一场头脑风暴,而做笔记的人同时还要负责制作影片。同步子智能体在这里并不适用,因为主智能体必须等待它们完成,期间人们无法与它互动。
为了解决这个问题,我们将子智能体改为异步运行,并将主智能体的角色从执行者转变为幕僚长。它将复杂项目拆分为更小、隔离的任务,分配给子智能体并并行执行工作。与此同时,它随着情况变化让团队随时了解进展,使人们能够继续提供反馈并引导项目方向。
对于每个任务，主智能体会创建一个子智能体档案，包含清晰的简报，涵盖其角色、相关上下文、文件所有权以及如何验证工作。它还会根据任务复杂度选择模型和努力程度。
我们还为协调工作的主智能体添加了一小部分工具：
start_task在后台将一部分工作交给子智能体check_tasks显示正在运行的内容并读取已完成的报告cancel_task以及resume_task停止不再符合简报的工作，或从上次中断的地方继续report_progress允许子智能体在任务中途发送更新schedule_wakeup为主智能体提供一个计时器以触发下一次运行并继续任务
在底层，每个子智能体都是作为后台任务运行的普通 Deep Agents task 工具。当它完成时，我们的代码会排队运行一次新的主智能体运行并携带结果。人们还可以在主智能体运行中途进行引导，因为它工作时收到的消息会插入到下一次模型调用之前。子智能体通过项目文件夹进行协调，各自只写入自己拥有的文件，并将进度保存在磁盘上。
工作在后台运行时，会话线程必须展示正在发生的事情。主智能体通过计划和预计完成时间、显示正在运行的子智能体、渲染进度和花费的实时状态行、每次编辑的确认，以及在内容公开发布前的审批卡片来保持更新。
对这种方法最清晰的考验之一来自一项通宵工作：为一份52页幻灯片的演示文稿重新设计外观。智能体首先创建了三张示例幻灯片并审查了自己的工作，然后按编号批次处理演示文稿的其余部分以供审批。它还在此过程中新增了两张幻灯片。通宵期间，主智能体运行了大约一个小时，而其子智能体总共工作了超过六个小时，全程没有阻塞对话。
自我改进的框架
与团队合作数月的设计师会了解团队的偏好，不需要重复听取同样的反馈。如果没有记忆，智能体在每次新会话中都得从零开始。为避免这种情况，我们构建了两个学习循环。快速循环在人们给出反馈时即时捕获，而慢速循环则在后台从已完成的项目中学习。
快速循环： 当有人分享规则或偏好时，智能体会在同一回合内将其保存。 Managed Deep Agents 以普通文件的形式将记忆存储在两个层级中，一层为团队共享，另一层为每个人专属。
个人偏好可以跨会话保留，但共享标准优先，为公司频道创建的任何内容都遵循公司语调。每一层都有一个 AGENTS.md 文件，随每次模型调用加载。在早期版本增长到500K tokens后，我们现在将这些文件限制为200行的索引。
慢速循环： 每次任务完成后，我们的 learn_from_job 工具会启动一个轻量子智能体，捕获最多五条有依据的经验教训，并将它们与所使用的技能关联起来。未来的任务会阅读这些经验教训并对其评分，每周一次，一个后台智能体会将证明有用的经验教训融入技能和维基中。
下一步
还记得那些早期的审查吗？最大的改进来自于将我们设计师的判断力捕获到一个智能体可以学习的共享环境中，而不是让它们散落在各个审查会话中。在此过程中，我们让更多人能够参与设计工作。
接下来，我们希望智能体管理整个营销活动生命周期，其中一部分已经在运作。它会在获得授权审批人签字后通过 Buffer 发布公司社交帖子，起草供员工从自己账号分享的帖子，并运行定时例程，包括一项每日审查，建议值得引用的帖子。
我们的目标是更进一步，让一个经过批准的创意方向可以在一个会话中贯穿整个营销活动。智能体将撰写简报、为每个频道创建素材、安排帖子发布、帮助团队放大传播，并利用表现数据为下一次活动提供参考。在公开发布之前，人们仍然会审查并批准所有内容。
构建你自己的设计智能体： 这个 开源仓库 包含了本文中的框架：沙盒计算机、技能、维基和记忆、异步子智能体以及 Slack 用户体验。Fork 它，添加你的品牌 token、字体和技能，然后通过部署到你们团队的 Slack。 托管式深度智能体.
那就来参加我们的活动 GTM Engineering Live 时间是10月28日。我们将深入剖析这个 harness 和用户体验,并展示那些未能写入本文的工作。