LangChain 解析自研设计 agent Content Studio 并开源其 harness

上面这支宣传片出自 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 里给智能体下达需求，然后直接拿到符合品牌规范、可以发布的东西。现在四分之三的需求来自市场部以外。对设计师来说，角色更接近创意总监：定方向、审作品，而不是亲手产出每一份素材。

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

搭建媒体运行框架

设计师要在多个工具之间切换：用 Photoshop 处理静态图，用视频引擎做动效，用共享画布做原型和协作。他们还依赖品牌规范、设计素材和公司文档。

智能体也需要类似的配置：一台可以干活的电脑、覆盖设计流程各环节的工具，以及设计师工作时所带的上下文。运行框架把这些部分整合在一起。Deep Agents 提供底层的运行框架，包括智能体循环、规划、文件、子智能体和上下文管理。Managed Deep Agents 负责打包并在生产环境中运行。我们围绕它搭建了环境，给智能体一台电脑，让它能维护项目、跨工具工作并检查结果。

harness_v1

我们第一版运行框架试图替模型做设计。早期模型需要大量帮助，才能做出我们愿意发布的动效图形或发布短片。为了弥补模型自己还搞不定的部分，我们的直觉是把更多自己的设计判断写进指令和代码里。

于是我们搭了一套设计系统，包含 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 旋转 logo，而这正是我们想要的原创动画质感。于是我们自研了 canvas 引擎。智能体编写代码，逐帧绘制每一个像素，引擎则把最多 16 个瞬间混合进每一帧，就像相机快门让运动产生模糊一样。鹦鹉那部影片就是这样制作的。

两个引擎都按时间戳渲染每一帧，所以第 10 秒的那一帧无论何时渲染都完全一致。这让智能体可以只检查某个瞬间而不必渲染整部影片，也让我们能并行渲染多帧。音频走同一条时间线，使旁白、音乐和音效与画面保持同步。

有了这套配置，智能体几乎什么都能做。但如果没有进一步引导，它会默认采用模型自己的设计选择，而不是我们的。下一个挑战，就是教它在我们的品牌和设计规范内工作。

设计师的大脑

我们把智能体的知识围绕四项不同职能来组织，每项都有明确用途。技能（Skills）规定具体任务该怎么做，wiki 则提供公司背景和“好作品长什么样”的参照。凡是可衡量的部分都交给 gate——用代码写成的确定性检查。另有一层独立的记忆，记录人们随时间教给智能体的东西。

技能

智能体接到请求后，第一件事是判断这属于哪类工作。这由我们的 media-production 技能负责。我们叫它路由技能，因为它大部分内容就是一张表。每一行把一类需求（营销活动、改版、缩略图、帖子、YouTube 打包、发布短片、短动画）映射到对应的处理路径和专项技能。路由还会判断这项工作是否需要共享的视觉画布，并把小改动挡在完整流程之外。

像上面那样的影片，路由会选中 launch-film 技能，它专为执导大型动效制作而设计。我们的 48 个技能合计近 1,000 个文件，每个都按“工作”而非“主题”来划定范围，所以它的描述读起来像一条路由规则，连“什么情况下不该用”也写进去了。

技能之间是组合关系，而不是互相重复。launch-film 负责执导，motion-studio 负责画面和声音，动画的手艺只写一次。launch-film 还带有它将要启动的子智能体的角色简报，以及一个真实案例研究：我们把一支 88 秒的发布短片用代码逐镜头重建了一遍。智能体正是从这个案例里学会如何把一部影片拆分给子智能体：在硬切处分割，连续的镜头运动交给同一个子智能体，并在任何人并行开工之前先冻结共享代码。

工具的描述和技能一样重要。为了控制上下文占用，我们把 MCP 工具放在内置搜索之后。智能体一开始只加载我们自己的工具，需要时再按需加载其他工具的 schema，方式是在工具名称和描述里做关键词搜索。

Wiki

技能讲的是怎么做一项工作，wiki 提供的则是把这项工作做好所需的背景和参考资料。内容涵盖品牌 token、图形语言、语调，以及平台、营销活动和产品信息。另有一个专门的动效 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 文件，在每次模型调用时加载。早期版本曾膨胀到 50 万 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。我们会深入讲解这套 harness 和 UX 的内部机制，并展示这篇帖子没能放下的工作。