Amal IrgashevShreya Talegaonkar2026年10月27日22分钟返回博客创建智能体创建智能体分享核心要点
- 品味来自上下文。 模型已经能写出不错的代码，但它们需要你们设计师的原则、防止AI粗制滥造的护栏，以及反馈背后的推理过程，才能做出看起来像你们风格的作品。
- 给智能体一台设计师的电脑。 每个Slack线程都有自己的沙箱，智能体在其中跨轮次保留项目状态，在视频引擎、图像工具和共享画布之间协同工作，并检查自己渲染出的结果。
- 当模型进步时，删除规则。 那些用来弥补模型弱点的规则会过期，所以要保留设计原则，并随着模型变强移除这些变通做法。
- 长时间运行的智能体需要多人协作式用户体验。 大型任务会在异步子智能体上运行数小时，因此Slack线程会展示计划、实时进度，并在任何内容交付前进行审批，团队中的任何人都可以在运行中途引导智能体。
- 你可以将它分叉。 这个开源仓库包含完整的harness，而Managed Deep Agents会把它部署到你团队的Slack中。
上面的宣传片由Content Studio制作，它是我们的设计智能体，只需在Slack中给出一个提示，就能创建视频、社交图形、重建的UI图像、幻灯片等。该智能体产出的每一个素材都是用代码写成的。
Content Studio完全是在 Managed Deep Agents上内部构建的。它现在是我们公司内部使用最广泛的GTM智能体之一，但一开始并非如此。早期的反馈……并不理想。
那么，我们是如何从如此低的质量走到今天这一步的？
我们花了四个月时间，教Content Studio我们的品味和设计原则，主要方式就是看着它在全公司面前出错。
本文详细介绍了我们的GTM工程团队如何与设计团队合作，从零开始构建Content Studio：优秀设计对我们意味着什么，我们如何把品味教给这个智能体，以及让它能从静态图制作到发布影片的harness。
我们已开源了我们的设计智能体。 分叉这个 开源仓库，加入你的品牌 token、字体和技能，并将它部署到你团队的 Slack 中，使用 Managed Deep Agents.
那么，欢迎参加我们10月28日的GTM Engineering直播。 GTM Engineering Live 10月28日。我们将深入剖析这套 harness 和用户体验，并展示这篇博文中未能容纳的工作。
构建一个可扩展的设计智能体
LangChain 发展迅速。我们持续开展产品发布活动、网络研讨会、博客和活动。每项举措都需要素材，从博客头图和图表到演示文稿、视频和广告创意。我们的设计团队人手紧张，重复性的请求挤占了更具战略性和创新性的工作。作为一家精益初创公司，我们需要一种低摩擦的方式，让公司里的任何人都能创作出高质量、符合品牌调性的作品。
为了满足这些需求，我们构建了 Content Studio，一个驻留在 Slack 中的设计智能体。团队成员描述他们想要的内容，并附上相关素材或简报，智能体便会返回完成且符合品牌规范的成品文件。为了构建 Content Studio，我们需要三样东西：
- 我们设计师的专业判断，并将其写入智能体的技能和校验规则中，让它知道什么才算好。
- 一个自定义环境 围绕模型构建，包括一台视频编辑电脑，配备覆盖设计工作每一层的工具。
- 合适的用户体验，这样整个团队就能在一个 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%。 Managed Deep Agents.
AI 真的擅长设计吗？
在深入构建过程之前，我们先来讨论这个世纪之争：AI 真的能做出好的设计吗？
这个模型在执行方面已经表现出色，能够编写 HTML 和 CSS、图表规格以及动画时间线。然而，它并不了解我们的上下文，因此会沿用熟悉的模式，也就是 Anthropic 称之为“分布收敛”结果可能看起来很精致，却仍然和另外上百个作品如出一辙；或者动画做得美轮美奂，却始终没能把要点传达出去。熟悉并不总是坏事，但我们希望我们的智能体做出的选择能够契合它的目的。
Katie Dill，Stripe 的设计负责人，做了一个很有帮助的类比。二战后，在快速建设的压力下，建造者们一遍又一遍地照搬现代主义的简洁造型和裸露表面。这些复制品保留了外观，却丢掉了背后的思考与个性。她的警告是，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 组件，用于标题、布局和动画，并附上关于何时以及如何使用它们的指导。这为模型提供了一组现成的……
我们对该执行框架的第一个版本试图替模型完成设计工作。早期的模型需要大量帮助，才能做出我们愿意交付的动态图形或发布影片。为了弥补它们当时还无法自行解决的部分，我们的直觉是把更多自己的设计判断写进指令和代码中。
于是，我们构建了一套设计系统，包含 115 个可复用的 UI 组件，用于标题、布局和动画，并附上关于何时以及如何使用它们的指导。这为模型提供了一组现成的设计可供参考，减少了它必须从零开始的创意决策数量。
这有助于它保持品牌一致性，但智能体会为每一帧重复相同的布局和动画，缺乏变化：
我们知道模型最终会在这项任务上表现出色，因此我们持续为那一刻搭建环境，并在此过程中不断试验各种技能和工具。有时我们会添加更多参考或更详细的指令来帮助模型。另一些时候，我们会把它们全部移除，看看模型自己能做成什么样。
但结果仍未达到我们的期望，而缩小差距需要越来越多的工程工作。我们不断为技能添加规则、编写更多动效代码，并构建更多组件，以弥补模型做不到的部分。
随后 Opus 5.5 发布，我们立刻看到了质量上的跃升。我们重新审视了各项技能，移除了大部分硬编码规则，只保留设计原则和高层指导。结果进一步提升，变化更多、重复更少。模型终于开始做出我们此前试图为它预先构建的创意决策。
这就是我们的 苦涩的教训旨在弥补模型弱点的规则，会随着模型能力的提升而变得不那么有用。真正持久的是模型周围的环境，包括它使用的工具、它汲取的上下文，以及人们如何引导它的工作。我们没有预先构建创意决策，而是专注于让这套执行框架足够灵活，以便充分利用每一代新模型。
设计师的电脑
为了展示这套执行框架的实际运行效果，我们让 Content Studio 制作一部影片，完整演示它如何端到端地处理一个视频项目。成片的主角是一只身处像素丛林中的鹦鹉，旁白采用 David Attenborough 的风格（由 ElevenLabs 配音）。我们就用它来逐层拆解这套执行框架：计算机、工具，以及支撑其工作的上下文。
设计是迭代的。你做出一些东西，看看它，然后修改它，往往要反复很多次。因此，智能体需要一台能在整个对话过程中持续使用的计算机。每个 Slack 线程都有自己独立的 LangSmith Sandbox，一台拥有文件系统和 shell 的隔离 Linux 机器，项目在整个线程存续期间都驻留在那里。
智能体创建的一切都由代码构建，无论是用于幻灯片的 HTML 页面、用于图表的数据规范，还是用于视频的动画时间线。这使得迭代变得容易，无需从头开始。如果有人要求把鹦鹉提前出现，智能体只需更改一个时间值并重新渲染，而不会影响画面或文案。而对于平面图像或生成的视频片段，即使是很小的编辑也可能意味着要重新创建整个素材。
简报、方案、场景代码、音频和渲染结果都存放在同一个项目文件夹中，参与这项工作的每个子智能体都基于这个文件夹开展工作。
在此基础上，我们还安装了设计师在工作的每个环节都会用到的工具：
动效是最难的一层。它由两个引擎驱动：
- 用于编辑的 HyperFrames： ，即 HeyGen 的开源视频框架，可将视频转换为网页。片段、屏幕录制、字幕和文本都只是该页面上的元素，GSAP 时间线负责移动它们。因此，当有人要求为网络研讨会添加字幕或剪辑产品演示时，智能体会像编辑网页一样进行编辑。其 CLI 基本上就是智能体的编辑套件：检查合成、拉取一帧进行核对、渲染剪辑。我们还安装了 HeyGen 的官方技能，让智能体向构建该格式的人学习。用于动画的 motion-studio：网页无法对快速运动进行模糊处理、让物体发光或在 3D 中旋转标志，而这正是我们为原创动画所追求的质感。因此我们构建了 GSAP 时间线会移动它们。因此，当有人要求为网络研讨会添加字幕或剪辑产品演示时，智能体会像编辑网页一样进行编辑。其 CLI 基本上就是智能体的编辑套件：检查合成、拉取一帧进行核对、渲染剪辑。我们还安装了 HeyGen 的官方技能，这样智能体就能从构建该格式的人那里学习这种格式。
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 则提供做好这项工作所需的背景信息和参考资料。它涵盖从品牌 token、图形语言和语调，到平台、营销活动和产品信息的一切内容。一个专门的 motion wiki 涵盖执导、工艺、声音和评审，并附有 70 部参考影片的拆解分析。
我们不会在各技能中重复这些信息，而是直接链接到 wiki。这样可以把共享知识集中在一处，也更容易更新。当字体规则之类的内容发生变化时，我们只需更新一次，每个技能都能引用最新版本。
知道我们如何工作，并不一定能让动态设计变得更便宜。一个错误的创意决策仍然可能耗费数小时的渲染时间。
规范驱动设计
动作设计一旦出错，代价尤其高昂，无论是渲染时间还是 token 消耗。一个故事板帧的渲染大约需要 50 毫秒，而一秒成片则需要 8 到 40 秒。由于子智能体会为每一幕撰写、渲染并评审，这些成本会迅速累积。因此，智能体先在故事板中构思创意，在这里它可以低成本地探索不同方向，待某个方向获批后再进入完整制作。
为支持这种探索，我们给智能体提供了一个参考影片库，供其从中汲取灵感，就像设计师借助情绪板工作一样。当它找不到合适的视觉风格时，它会使用图像模型生成新的参考，先快速起草，再对最有希望的选项进行细化。这些图像有助于确立视觉方向，而故事板和最终影片仍然使用真实字体和品牌资产在代码中构建。
一旦我们选定方向，获批的故事板就会成为整部影片其余部分赖以构建的规范。随后，项目会经历三个阶段：
- 一个故事板，用于就视觉创意、文案和镜头达成一致。
- 动态分镜，即按音频节奏剪辑的粗剪版本，用来检查静帧无法呈现的节奏感。
- 制作阶段，由子智能体构建、检查并渲染已批准的镜头。
我们最初在技能说明中描述了这个顺序，而智能体有时为了节省时间会跳过评审。现在流水线在代码中强制执行这一顺序，因此组装会等到每一幕都通过评审后才开始，而说明仍然指导创意决策。必须始终遵守的顺序存在于代码中，而判断则留在提示词里。
指出来，而不是提示
在这些方向之间做选择是团队的决定。Slack 很适合用来请求工作和接收工作，但线程是线性文本，而故事板是空间性的，所以反馈最终变成描述某个东西在哪里，而不是直接指向它；而且每一次改动，哪怕只是改一个词，都必须作为新的提示词重新经过智能体。
Paper 为我们解决了这个问题。它是一个专为智能体设计的画布，配备了一个 MCP 服务器，让智能体可以直接控制该文件。人们可以在同一个文件中工作，并排比较不同方向，在特定画框上留下评论，或者自己进行编辑。由于画布是共享的，智能体可以回到该文件，并利用这些评论和编辑来指导它的下一次迭代。
挑战在于，Paper 的智能体工具只能在它的桌面应用内运行，而我们的智能体则在云端沙箱中运行。为了弥合这一差距，我们在一个常驻运行的 Linux worker 上以无头模式运行 Paper Desktop，使用虚拟显示和一个经过身份验证的桥接来连接两者。一次配置即可支持整个团队。
即使获得批准，把故事板变成成片也可能需要数小时。到那时，这项工作已经像一个小型项目，多个部分并行构建，最后还需要整合到一起。协调这一切已经超出了一次智能体交互所能处理的范围。
智能体作为幕僚长
以之前提到的鹦鹉影片为例，制作进行到一半时，大家在 Slack 上协作。一个人分享了一个参考，另一个人建议换一个开场，第三个人对第四帧留下反馈，而这一切发生时智能体仍在构建中。这就像一场头脑风暴，而负责记录的人同时也负责制作这部影片。同步子智能体在这里行不通，因为主智能体必须等待它们完成，期间人们无法与它交互。
为了解决这个问题，我们将子智能体改为异步运行，并把主智能体的角色从执行者转变为幕僚长。它把复杂项目拆解为更小、相互隔离的任务，分配给子智能体并并行执行。同时，它会在情况变化时让团队保持知情，使人们能够继续提供反馈并引导项目。
对于每个任务，主智能体会创建一个子智能体配置，其中包含明确的简报，涵盖其角色、相关上下文、文件归属以及如何验证工作。它还会根据任务的复杂程度选择模型和投入级别。
我们还添加了一小组工具，供主智能体协调工作：
start_task在后台把一部分任务交给子智能体check_tasks展示正在运行的内容，并读取已完成的报告cancel_task，resume_task停止那些不再符合任务简报的工作，或者从上次中断的地方继续report_progress让子智能体在任务进行中发送更新schedule_wakeup为主智能体提供一个定时器，以触发另一次运行并继续执行任务
在底层，每个子智能体都是普通的 Deep Agents task 工具作为后台任务运行。当它完成时，我们的代码会将携带结果的主智能体新一次运行排入队列。人们也可以在运行中途引导主智能体，因为在其工作期间到达的消息会被插入到下一次模型调用之前。子智能体通过项目文件夹进行协调，每个子智能体只写入自己拥有的文件，并将进度保存在磁盘上。
在任务于后台运行的同时，线程必须展示正在发生的情况。主智能体会通过计划与预计完成时间、包含运行中子智能体的实时状态行、渲染进度与花费、对每次编辑的确认，以及在任何内容公开发布前的审批卡片，来让线程保持最新状态。
这种方法最清晰的检验之一，来自一项通宵任务：为一份52页的演示文稿更换视觉风格。智能体先制作了三张示例幻灯片，并检查了自己的工作，然后按编号分批处理其余幻灯片以供审批。它还在过程中新增了两张幻灯片。整个通宵期间，主智能体运行了约一个小时，而它的子智能体们累计工作了六个多小时，全程都没有阻塞对话。
自我改进的 harness
快速循环：当有人分享一条规则或偏好时，智能体会在同一轮对话中将其保存下来。Managed Deep Agents 将记忆以纯文件形式存储在两个层级中，一层在整个团队内共享，另一层则专属于每个人。个人偏好会跨线程延续，但共享标准优先，而为公司频道创建的任何内容都遵循公司语气。每个层级都有一个文件，在每次模型调用时加载。在早期版本出现……之后，我们现在将这些文件限制为 200 行的索引。
快速循环： 当有人分享一条规则或偏好时，智能体会在同一轮对话中将其保存下来。 Managed Deep Agents 将记忆以纯文件形式存储在两个层级中，一层在整个团队内共享，另一层则专属于每个人。
文件，在每次模型调用时加载。在早期版本增长到 50 万 token 之后，我们现在将这些文件限制为 200 行的索引。 AGENTS.md 在早期版本增长到 50 万 token 之后，我们现在将这些文件限制为 200 行的索引。
慢循环： 每项任务完成后，我们的 learn_from_job 工具会启动一个轻量级子智能体，由它最多捕获五条有证据支撑的经验教训，并将这些经验教训与所使用的技能关联起来。后续任务会读取并评价这些经验教训，并且每周由后台智能体将其中被证明有用的部分整合进技能和 wiki 中。
接下来
还记得早期的那些评审吗？最大的改进来自把设计师的判断沉淀到一个智能体可以学习的共享环境中，而不是让这些判断散落在各个评审线程里。在这个过程中，我们让更多人能够参与设计工作。
接下来，我们希望让智能体管理整个营销活动的生命周期，其中一部分已经可以正常工作。一旦获得授权审批人的批准，它就会通过 Buffer 发布公司社交帖子，为员工起草可在自己账号上分享的帖子，并运行定时例程，包括每天一次评审，推荐值得引用的帖子。
我们的目标是更进一步，让一个获批的创意方向就能从单个线程贯穿整个营销活动。智能体会撰写简报、为每个渠道创建素材、安排发布、帮助团队扩大传播，并利用效果数据为下一次营销活动提供参考。在一切公开发布之前，人们仍会进行审核和批准。
搭建你自己的设计智能体： 开源仓库包含本文所述的整套 harness：沙箱计算机、技能、wiki 与记忆、异步子智能体以及 Slack 用户体验。Fork 它，加入你的品牌 token、字体和技能，然后用 Managed Deep Agents 部署到你团队的 Slack 中。然后请在 10 月 28 日参加我们的 GTM Engineering Live。我们将深入讲解这套 harness 和用户体验的内部机制，并展示本文未能容纳的工作。 开源仓库 包含本文所述的整套 harness：沙箱计算机、技能、wiki 与记忆、异步子智能体以及 Slack 用户体验。Fork 它，加入你的品牌 token、字体和技能，然后用 Managed Deep Agents.
然后请在 GTM Engineering Live 10 月 28 日。我们将深入讲解这套 harness 和用户体验的内部机制，并展示本文未能容纳的工作。