LangChain 如何构建设计智能体：Content Studio 的品味、工具与运行环境

教品味，而不只是写规则

LangChain 把品味定义为区分“正确”和“好”的判断力。两个版式可以使用完全正确的字体、颜色、间距和对齐，但只有一个能表达目标。品味始于 Dill 所说的“变得非常擅长注意”。

团队也通过这种观察学会识别 AI slop。它最常出现在 brief 没有明确规定的决策处。LangChain 展示了同一个 prompt 分别交给带品牌 skill 的本地 coding agent 和 Content Studio 的结果。本地 agent 漏掉了正确的 logo lockup、文字对齐，也分不清主品牌色和辅助品牌色。它拿到了品牌 token，却用通用默认值填满剩余空白。Content Studio 则用公司的既有选择补上同样这些空白。

最初加入的是常规基础：颜色 token、字重、间距和对齐。更大的提升来自更高一层的内容，包括每帧只有一个视觉焦点、针对常见 AI 设计套路的 guardrail，以及每条反馈背后的原因。更强模型当然有帮助，但 harness 让模型能力真正能够服务于一种具体工作文化。

一个很小的动效例子说明了为什么只写规则不够。早期动画里，一只鸟飞出画面，身后拖着不到一秒的光带。需求写了“不要尖锐边缘”，第一版却交回了末端粗糙、轮廓僵硬的圆边。设计师真正想表达的是：边缘应当逐渐变软，尾部要沿鸟运动的反方向收束并淡出。

到了后续迭代，智能体已经能自己检查这个细节。它先画一张快速示意图定位鸟尾，再建立逐帧验证，确认光带的根部一直附着在鸟尾上，直到光带离开画面。大多数观众不会主动说出这层关系，但如果附着断了，感觉就会不对。

可测量的问题最容易解决。例如 capitalization 曾经经常出现在 review 里，后来一个自动检查替代了重复人工反馈。更主观的决定仍然更难：campaign idea 是否足够强？信息是否传达到位？观众能否感受到目标语气？设计师做出这类判断时，团队会把理由记录进 skill，让后续草稿复用。

工作环境：每个 Slack thread 都有一台设计师电脑

Content Studio 生活在 Slack 中。同事描述需求、附上 brief 或源文件，智能体在同一 thread 里返回完成文件。要做出这种体验，需要三部分：写进智能体运行上下文的设计师判断、覆盖设计各层的专用工具环境，以及适合数小时长任务的协作界面。

Deep Agents 提供底层 agent loop、规划、文件系统、子智能体机制和上下文管理。Managed Deep Agents 负责生产运行所需的 LangSmith 沙箱、Slack 集成、托管工具、团队与个人记忆、调度及 tracing。LangChain 表示，这替代了大量基础设施代码，使自己的实现缩小约 80%。

设计是反复迭代的：做出来、看一眼、修改，再重复很多次。所以智能体需要一台能跨多轮保留状态的电脑。每个 Slack thread 都有自己的 Linux 沙箱、shell 和文件系统。项目文件夹在整个 thread 生命周期内持续存在，主智能体和 helper 共用它。brief、计划、场景代码、音频、中间渲染和最终结果都留在同一个目录。

在这台电脑之上，LangChain 安装了设计师在每一层工作中会使用的工具。整套 toolbox 包含 24 个工具、库和 MCP server，覆盖版式、图像、图表、运动、声音、评审、调研和发布。skills 与 scripts 提供面向具体任务的工作流，确定性的 gates 则检查每一次渲染。

所有东西都是代码。一张 slide 是 HTML 页面，一个图表是交给确定性图形库的 specification，一部影片是动画时间线。如果有人说“让鹦鹉早点出现”，智能体可以只改一个时间值再重新渲染。对一张平面图片或生成视频来说，同样的修改往往意味着重新制作整个资产。

第一代 harness：预置组件与 Bitter Lesson

第一版 harness 试图替模型完成太多设计。早期模型需要大量帮助才能做出团队愿意发布的 launch film，于是工程师不断增加指令和代码。他们构建了 115 个可复用的 UI 组件，覆盖标题、版式和动画，并规定每个组件何时、如何使用。

这些组件帮助智能体维持品牌风格，但它开始反复使用同一套版式和动态。团队继续增加规则、组件和手写 motion code，试图补齐质量差距。这个办法越来越昂贵。

Opus 5.5 到来后，质量出现明显跃升。团队重新检查 skills，保留设计原则和高层指导，删除大部分硬编码规则。结果变得更丰富，重复显著减少。过去 harness 试图替模型预建的创作决策，现在由模型自己完成。

LangChain 把这称为自己的 Bitter Lesson。为了弥补模型暂时弱点而写下的规则，会随着模型进步逐渐失去价值。真正持久的是模型周围的环境：工具、公司上下文、评审流程，以及人如何引导工作。与其预先写死每个创作决策，团队开始建设一套能跟上下一代模型的灵活 harness。

两套运动引擎

运动是整条工具链最难的一层，Content Studio 使用两套引擎承担不同任务。

HyperFrames 是 HeyGen 的开源视频框架，它把视频表示成网页。视频片段、录屏、字幕和文字都是 composition 里的元素，GSAP timeline 负责移动它们。这样，常规剪辑对智能体来说就变成了可读的页面结构：它可以通过编辑页面和时间线来给 webinar 加字幕、剪产品 demo。CLI 相当于智能体的剪辑套件，可以 lint composition、抽取单帧检查、渲染成片。LangChain 还安装了 HeyGen 官方 skills，让智能体直接向格式维护者学习。

motion-studio 是 LangChain 为原创动画自研的 canvas 引擎。网页本身无法自然完成快速 motion blur、glow，或者让 logo 在 3D 中旋转到团队想要的完成度。在 motion-studio 中，智能体写的代码决定每一帧的每一个像素。为了生成动态模糊，引擎会把最多 16 个时刻混合进同一帧，类似相机快门在一段时间内积累光线。下一节的鹦鹉影片就是这样制作的。

两套引擎都根据时间戳计算每一帧，所以第 10 秒的画面无论何时渲染都应该一致。这种确定性让智能体可以只检查某个时刻，而不渲染完整影片，也允许不同帧并行渲染。音频使用同一条时间线，因此旁白、音乐和音效能够与视觉状态同步。

这套环境给了模型很强的执行能力，但它仍会默认选择通用方案。还需要下一层告诉它 LangChain 如何工作、品牌意味着什么，以及哪些属性应该由程序检查，而不是靠语言争论。

设计师的大脑：skills、wiki、gates 与 memory

LangChain 把智能体知识分为四类功能：

• Skills 说明一类任务如何执行。
• Wiki 提供公司背景和“什么算好作品”的参考材料。
• Gates 用确定性代码检查可测量属性。
• Memory 保存人们长期教给智能体的规则与经验。

常驻 system prompt 刻意保持很小。请求开始时，一个名为 media-production 的 router skill 先判断任务类型。这个 skill 的主体基本是一张路由表，每一行把 campaign、restyle、thumbnail、社交帖子、YouTube package、launch film、short animation 等请求映射到对应流程和专家 skill。Router 还判断任务是否需要共享 Paper 画布，并让小修改绕开完整制作链。

例如 launch film 会进入 launch-film skill。LangChain 共有 48 个 skills，接近 1,000 个文件。每个 skill 对应一种工作，而不是一个大主题；描述里还写明什么时候不该使用它，以便路由更可靠。

Skills 之间组合，而不是复制相同知识。launch-film 负责导演和统筹，motion-studio 负责画面与声音的制作。Skill 还可以包含它将要启动的子智能体角色说明。launch-film 中保存了一部 88 秒影片逐镜用代码重建的案例。这个案例教智能体如何在硬场景切换处分包，让连续镜头始终由同一个子智能体负责，并在并行工作开始前冻结共享代码。

工具描述也遵循同样逻辑。为了控制上下文，MCP 工具藏在内置搜索后面。模型一开始只看到 LangChain 自己的工具，需要时再按工具名称和描述的语义搜索加载额外 schema。

Wiki 作为公司上下文的单一来源

Skills 说明怎么做，wiki 提供做好工作所需的事实和标准。它覆盖品牌 token、图形语言、语气、平台、campaign 和产品信息。独立的 motion wiki 则覆盖导演、工艺、声音、review，以及 70 部参考影片的拆解。

团队不把这些内容复制到每个 skill，而是让 skill 直接链接 wiki。共享知识留在单一位置，更新时所有工作流自然读到最新版。字体规则变化时，只改一次即可。

Spec-driven motion：先 storyboard，再进入制作

知道怎么做，并不意味着运动设计便宜。一个错误方向可能消耗数小时算力。LangChain 给出的量级是：storyboard 单帧渲染约 50 毫秒，而一秒钟成片通常需要 8 到 40 秒。再加上多个子智能体同时编写、渲染和评审，如果直到完整制作阶段才发现方向错误，成本会迅速累积。

因此智能体先在 storyboard 里探索。它可以使用参考影片库，像设计师看 mood board 一样寻找方向。找不到合适外观时，它用图像模型生成快速视觉参考，再细化最有希望的几张。这些图片帮助确定 look，但 storyboard 和最终影片仍然使用真实字体、品牌资产和代码制作。

方向确定后，已批准的 storyboard 成为后续制作的 specification。项目经过三个阶段：

1. Storyboard：确认视觉想法、文案、时间与镜头。
2. Animatic：制作与音频同步的粗剪，让团队判断静态画面无法呈现的节奏。
3. Production：由子智能体制作、检查并渲染已批准的镜头。

LangChain 最初把顺序写在指令里，但智能体有时为了节省时间跳过 review。现在 pipeline 由代码强制：所有 act 通过评审前不能进入 assembly。固定顺序放在确定性软件中，创作判断仍留在 prompt 和专业 skill 里。

Point, don't prompt

在多个视觉方向中做选择，是团队决策。Slack 适合提出需求与接收结果，但 thread 是线性文本，storyboard 是空间结构。反馈很容易变成“把那个东西往左一点”这类描述，而不是直接指向目标。即使只改一个词，也要被重新翻译成给智能体的 prompt。

LangChain 用 Paper 去掉这层翻译。Paper 是一款面向智能体设计的画布，其 MCP server 允许智能体直接控制文件。人们可以打开同一个文件，并排比较方向、在具体帧上评论，或者自己动手编辑。因为画布共享，智能体能重新读取这些评论和修改，作为下一轮迭代的指令。

难点在于 Paper 的智能体工具只运行在桌面应用中，而 Content Studio 工作在云端沙箱。LangChain 在常驻 Linux worker 上无头运行 Paper Desktop，用虚拟 display 和认证 bridge 连接两边。一次配置即可服务整个团队。

主智能体成为 chief of staff

把已批准的 storyboard 变成成片可能需要数小时。此时工作已经像一个小型项目，多个部分并行制作，最后必须拼成一个结果。单个同步 agent turn 很难同时协调这些工作，并保持与团队互动。

设想鹦鹉影片进行到中段：一个人分享参考，另一个人建议更换开头，第三个人在第四帧留反馈，而智能体仍在制作。同步子智能体会迫使 lead 等待，期间无法与团队有效互动。

因此 Content Studio 改用异步子智能体，并把主智能体从 implementer 变成 chief of staff。Lead 把项目拆成相互隔离的任务，为每个 helper 写 profile，在后台启动工作，同时继续与团队沟通。

每个子智能体 profile 都包含角色、相关上下文、它负责的文件，以及验证结果的方法。Lead 还会按任务复杂度选择模型与 reasoning effort。一组小型协调工具给 lead 明确动作：

• start_task：在后台启动子智能体。
• check_tasks：查看运行状态，读取已完成报告。
• cancel_task：停止不再符合 brief 的工作。
• resume_task：从持久化状态继续任务。
• report_progress：让 helper 在完成前发送进度。
• schedule_wakeup：给 lead 设置定时器，到时继续运行。

每个 helper 实际上都是普通的 Deep Agents task，作为后台任务运行。某个 helper 完成后，代码会把结果附到一次新的 lead run 中并排队执行。Lead 思考期间收到的新消息会插在下一次模型调用之前，因此用户可以在运行中改变方向。子智能体通过项目目录协作，只写各自拥有的文件，并把进度持久化到磁盘。

长时间后台工作还需要 multiplayer UX。在 Slack 中，lead 持续维护计划与 ETA、显示活跃子智能体的实时状态行、渲染进度和当前花费、每条修改的确认，以及对外发布前的 approval card。生产过程继续运行，对话也不会被阻塞。

一个代表性测试是通宵重做 52 页幻灯片。智能体先制作三张 sample slides 并自检，然后按带编号的批次处理剩余页面，每批等待批准。过程中它还主动新增了两页。整晚 lead 运行约一小时，而子智能体累计工作超过六小时。Slack 对话在整个过程中保持可用。

两套学习回路

一个和团队合作数月的人类设计师会记住偏好，不需要重复听同一句纠正。没有记忆的智能体则会在每个 thread 里从零开始。LangChain 因此建立两套回路：快速回路直接接收用户反馈，慢速回路在任务结束后从经验中提取知识。

快速回路会在用户提出规则的同一轮把它保存下来。Managed Deep Agents 用普通文件保存两层记忆：全团队共享的 team memory 和每位用户独立的 personal memory。个人偏好可以跨 thread 持续，但共享标准优先；为公司频道创建的内容遵循公司语气。

每层记忆都有一个 AGENTS.md 索引，在每次模型调用时加载。现在索引限制在 200 行。早期版本一度增长到 50 万 token，使本来用于帮助模型的记忆变得极其昂贵，也稀释了有效上下文。新索引只指向知识，不再把所有内容塞进每一轮。

慢速回路在交付后运行。learn_from_job 工具启动一个轻量级子智能体，最多提取五条有证据支撑的经验，并把它们关联到当时使用的 skill。后续任务会读取并评价这些 notes。每周另一个后台智能体把经过多次证明有效的经验合并进 skills 和 wiki，淘汰站不住脚的内容。

下一步

Content Studio 已经可以在授权审批人确认后，通过 Buffer 发布公司社交帖子；也可以为员工起草供个人账号分享的内容，并运行每日筛选“值得引用帖子”等定时任务。LangChain 的下一目标是管理完整 campaign 生命周期：从一份 thread 里的 brief 开始，生成各渠道资产、安排发布、帮助团队扩散，再用表现数据影响下一次 campaign。所有内容在公开前仍由人审核批准。

更大的经验是：质量提升来自把设计师判断集中到一个智能体可以重复使用的环境中，而不是让判断散落在 review thread 和一次性纠正里。上下文、工具、检查与记忆形成了更完整的系统，智能体才随之变好。

机器人团队可以借鉴什么

Content Studio 是设计系统，不是机器人系统；它公布的使用数据也是内部采用指标，而非受控评测。不过，它的 harness 暴露了一种可以迁移到物理 AI 的结构：把需要灵活判断的部分，与应该保持确定性的部分分开，并明确两者的交接。

第一个可迁移思路是：模型能力不等于完整产品。机器人或具身智能体同样需要持久上下文、接口清晰且边界狭窄的工具、可复用工作区、执行轨迹，以及让人检查中间产物的方式。Content Studio 把 brief、计划、代码、音频、渲染和交付状态放在同一项目目录。机器人栈可以把同一原则用于任务 specification、地图、轨迹、仿真场景、评测报告和控制器配置。

第二个是学习判断与代码 gate 的分工。LangChain 把创意选择留在 prompt 和 skill 中，却用代码强制阶段顺序、artifact contract、对比度、字体 fallback 和图表算术。机器人团队也常做类似区分：策略提出动作，安全监控器在执行前检查关节限位、碰撞约束、时序和状态有效性。

第三个是 chief-of-staff 模式。长时程工作可以让 lead 负责计划与协调，让 helpers 负责边界清晰的任务、文件和验证标准。相同结构可以组织数据采集、仿真 sweep、硬件 bring-up 和评测，前提是共享状态有明确 ownership，失败能够回报给控制 agent。

第四个是双速学习。即时记忆适合保存操作员的明确纠正；延迟晋升则避免把一次成功当作强证据。Content Studio 每周一次的晋升步骤，是把经验变成经过评审的组织知识，而不是让每个结束的任务静默改写整个系统。

边界同样重要。这篇文章没有证明这套 harness 能让所有设计任务都可靠，也没有证明它的成本或互动数据可以迁移到另一家公司，更不能证明同样结构会保证物理行为安全。那些结论需要外部 benchmark、留出任务和失败分析。它真正展示的是一个严肃的 harness 实现：模型提供可适应的推理，周围软件提供上下文、工具、约束、记忆与评审。

---

来源：LangChain，“How We Built Our Design Agent”，由 Amal Irgashev 与 Shreya Talegaonkar 于 2026 年 10 月 27 日发布。文章通过 LangChain 的 X 帖子传播。更多实现细节见 langchain-ai/design-agent 仓库及架构文档。文末机器人团队借鉴部分为 RobotWorld 基于原文的原创分析。