LangChain 如何搭建设计智能体 Content Studio

上面的宣传片由 Content Studio 制作，它是我们的设计智能体，只需在 Slack 中给出一个提示词，就能创建视频、社交图片、重建的 UI 图像、幻灯片等。该智能体产出的每一项资产都以代码形式编写。

Content Studio 完全基于 Managed Deep Agents 在内部构建。它现在是我们公司内部使用最广泛的 GTM 智能体之一，但起初并非如此。早期的反馈……并不理想。

那么，我们是如何从如此低的质量走到这一步的？

我们花了四个月时间，教 Content Studio 我们的品味和设计原则，主要方式就是看着它在全公司面前出错。

本文介绍了我们的 GTM 工程团队如何与设计团队合作，从零开始构建 Content Studio：对我们而言什么是好的设计，我们如何教会智能体我们的品味，以及让它能够制作从静态图片到发布影片的各类内容的运行框架。

We've open-sourced our design agent. Fork the open-source repo, add your brand tokens, fonts and skills, and deploy it to your team's Slack with Managed Deep Agents.

然后请在 10 月 28 日参加我们的 GTM Engineering Live。我们将深入介绍运行框架和用户体验的内部机制，并展示本文未能容纳的工作内容。

构建可扩展的设计智能体

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

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

1. 我们设计师的专业判断，将其写入智能体的技能和检查中，让它知道什么是好的。
2. 围绕模型的自定义环境，包括一台视频编辑计算机，配备设计工作各层级的工具。
3. 合适的用户体验，让整个团队能够在一个 Slack 线程中协作处理一个运行数小时的项目。

Managed Deep Agents 提供了我们在公司内部将 Content Studio 投入生产所需的一切：托管的 LangSmith Sandbox、与 Slack 的集成、托管工具、限定范围的智能体记忆以及智能体运行调度。这让小团队能够把时间花在设计工作、技能、工具和 Slack 体验上，而不是基础设施上。

关键成果

• Content Studio 已在全公司交付了 3,000 多项资产，包括 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 中向智能体下达简报，然后带着符合品牌且可直接交付的成果离开。现在四分之三的请求来自营销部门之外。对设计师而言，角色已更接近创意总监，负责设定方向并审阅作品，而不是亲自制作每一个素材。

把设计判断做对只是流程的一部分。我们还需要为智能体提供执行这些判断的工具和环境。

构建媒体 harness

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

智能体需要类似的配置：一台用于工作的计算机、覆盖设计流程不同环节的工具，以及设计师在工作中所带入的上下文。harness 将这些部分整合在一起。Deep Agents 提供底层的 harness，包括智能体循环、规划、文件、子智能体和上下文管理。Managed Deep Agents 将其打包并在生产环境中运行。我们围绕它构建了环境，为智能体提供一台计算机，使其能够维护项目、跨工具工作并检查结果。

harness_v1

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

因此，我们构建了一个设计系统，包含 115 个可复用的 UI 组件，用于标题、布局和动画，并附有关于何时以及如何使用它们的指导。这为模型提供了一组现有设计作为基础，减少了它必须从零开始的创意决策数量。

这帮助它保持了品牌一致性，但智能体会为每一帧重复相同的布局和动画，缺乏多样性：

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

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

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

这就是我们的苦涩教训。为弥补模型弱点而设计的规则，会随着模型能力的提升而变得不那么有用。真正持久的是模型周围的环境，包括它使用的工具、它汲取的上下文，以及人们如何引导它的工作。我们没有预先构建创意决策，而是专注于让这套 harness 足够灵活，以便利用每一代新模型。

设计师的电脑

为了展示这套 harness 的实际运作，我们让 Content Studio 制作一部影片，完整呈现它如何从头到尾配合一个视频项目。成片的主角是一只像素丛林中的鹦鹉，旁白采用 David Attenborough 的风格（由 ElevenLabs 配音）。我们就用它来逐层拆解这套 harness：计算机、工具，以及其工作背后的上下文。

设计是迭代的。你做出东西，看一看，再修改，往往要反复很多次。因此，智能体需要一台能在整个对话过程中持续工作的计算机。每个 Slack 线程都会获得自己的 LangSmith Sandbox，这是一台带有文件系统和 shell 的隔离 Linux 机器，项目在整个线程存续期间都存放在那里。

智能体创建的一切都是用代码构建的，无论是幻灯片的 HTML 页面、图表的数据规范，还是视频的动画时间线。这使得迭代变得容易，无需从头开始。如果有人要求把鹦鹉出场提前，智能体只需修改一个时间值并重新渲染，而不会影响美术或文案。而对于一张平面图像或生成的视频片段，哪怕是很小的修改，也可能意味着要重新制作整个素材。

简报、计划、场景代码、音频和渲染结果都存放在同一个项目文件夹中，参与任务的每个子智能体都基于该文件夹工作。

在此基础上，我们安装了设计师在工作的每个层面都会用到的工具：

动态效果是最困难的一层。它由两个引擎驱动：

1. 用于剪辑的 HyperFrames：HyperFrames 是 HeyGen 的开源视频框架，可将视频变成一个网页。片段、屏幕录制、字幕和文字都只是该页面上的元素，由一条 GSAP 时间线来移动它们。因此，当有人要求为网络研讨会添加字幕或剪辑产品演示时，智能体会像编辑网页一样编辑它。它的 CLI 基本上就是智能体的剪辑套件：检查合成、抽取一帧来查看、渲染剪辑。我们还安装了 HeyGen 官方技能，让智能体从构建者那里学习格式。
2. 用于动画的 motion-studio：网页无法让快速运动产生模糊、让物体发光或在 3D 中旋转标志，而这正是我们为原创动画想要的质感。因此我们构建了自己的 canvas 引擎。智能体编写代码，绘制每一帧的每一个像素，引擎将最多 16 个瞬间混合到每一帧中，就像相机快门让运动产生模糊一样。鹦鹉影片就是这样制作的。

两个引擎都根据时间戳渲染每一帧，因此十秒处的帧无论何时渲染看起来都一样。这让智能体可以检查单个瞬间而无需渲染整部影片，同时也让我们能够并行渲染多帧。音频运行在同一条时间线上，使旁白、音乐和音效与画面保持同步。

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

设计师的大脑

我们围绕四个不同的功能来组织智能体的知识，每个功能都有明确的目的。技能指导如何执行特定任务，而 wiki 提供关于我们公司以及什么算作优秀工作的背景信息。任何可衡量的内容都由 gate 处理，即用代码编写的确定性检查。一个独立的记忆层记录人们随时间教给智能体的内容。

技能

智能体处理请求时做的第一件事是判断这属于哪类工作。这由我们的 media-production 技能处理。我们称之为路由技能，因为它的大部分内容就是一张表。每一行将一种请求（营销活动、改版、缩略图、帖子、YouTube 打包、发布影片、短动画）映射到处理它的路径和专家技能。路由器还决定工作是否需要共享视觉画布，并将小修改排除在完整流程之外。

对于像上面那样的影片，路由器会选择 launch-film 技能，该技能专为执导大型动态制作而设计。我们的 48 个技能（总共近 1,000 个文件）每个都按工作而非主题划定范围，因此其描述读起来像一条路由规则，包括何时不应使用它。

技能之间相互组合，而不是彼此重复。launch-film 负责执导，motion-studio 负责制作画面和声音，因此动画技艺只写一次。launch-film 还包含它将启动的子智能体的角色简报，以及一个真实 88 秒发布影片的案例研究，我们用代码逐镜头重建了该影片。正是在这个案例研究中，智能体学会了如何在子智能体之间拆分影片。它在硬切场景处切分，让一个子智能体保持连续的镜头运动，并在任何人并行工作之前冻结共享代码。

描述对工具的重要性不亚于对技能。为降低上下文占用，我们将 MCP 工具置于内置搜索之后。智能体启动时只加载我们自己的工具，并根据需要加载额外的工具 schema，使用跨工具名称和描述的关键词搜索。

Wiki

技能解释如何完成工作，而 wiki 提供做好工作所需的背景和参考资料。它涵盖从品牌令牌、图形语言和语调到平台、营销活动和产品信息的一切内容。一个专门的动态 wiki 涵盖执导、技艺、声音和评审，以及 70 部参考影片的拆解。

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

了解我们的工作方式未必能让动态设计变得更便宜。一个错误的创意决策仍可能耗费数小时的渲染时间。

规范驱动设计

动态制作一旦出错，代价尤其高昂，无论是在渲染时间还是 token 上。一个故事板帧渲染约需 50 毫秒，而成片一秒钟则需要 8 到 40 秒。由于子智能体要编写、渲染并评审每一幕，这些成本会迅速累积。因此，智能体先在故事板中构思，在那里可以低成本地探索不同方向，待方向获批后再进入完整制作。

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

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

1. 故事板，用于就视觉创意、文案和镜头达成一致。
2. 动态分镜，即与音频同步的粗剪，用于检查静帧无法呈现的节奏。
3. 制作阶段，由子智能体构建、检查并渲染获批的镜头。

我们最初在技能的说明中描述了这个顺序，但智能体有时为了节省时间而跳过审查。现在流水线在代码中强制执行该顺序，因此组装会等到每一幕都通过审查后才进行，而说明仍然指导创意决策。必须始终遵守的顺序存在于代码中，而判断则留在提示词中。

指向，而非提示

在这些方向之间做选择是团队的决定。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 token 后，我们现在将这些文件限制为 200 行的索引。

慢速循环：每项工作完成后，我们的 learn_from_job 工具会启动一个轻量子智能体，捕获最多五条有证据支持的教训，并将它们与所使用的技能关联起来。未来的工作会读取并评价这些教训，并且每周一次，一个后台智能体会将证明有用的教训纳入技能和 wiki 中。

下一步是什么

还记得那些早期的评审吗？最大的改进来自于将设计师的判断捕获到一个智能体可以学习的共享环境中，而不是让它分散在评审线程中。在此过程中，我们让设计工作对更多人变得可及。

接下来，我们希望让智能体管理整个营销活动生命周期，其中部分功能已经实现。在获得授权审批人批准后，它会通过 Buffer 发布公司社交帖子，为员工起草可从个人账号分享的帖子，并运行定时例程，包括每日审查并推荐值得引用的帖子。

我们的目标是更进一步，让一个获批的创意方向能通过一个线程承载整个营销活动。智能体将撰写简报、为每个渠道创建素材、安排帖子发布、帮助团队扩大传播，并利用效果数据为下一次营销活动提供参考。在内容公开发布之前，人们仍会审查并批准所有内容。

Build your own design agent: The open-source repo has the harness from this post: the sandbox computer, skills, wiki and memory, async subagents and the Slack UX. Fork it, add your brand tokens, fonts and skills, and deploy it to your team's Slack with Managed Deep Agents.

那么，请于 10 月 28 日参加 GTM Engineering Live。我们将深入介绍该框架和用户体验的内部机制，并展示本文未能容纳的工作。