00:00:00感谢 HubSpot 对本视频的赞助。
00:00:03其实在 2025 年 12 月发生了一件非常重大的事情。
00:00:07而大多数人甚至都没有意识到这一点。
00:00:09Andrew Cupsey 上周在推特上提到了这件事。
00:00:10“很难用言语表达过去两个月里，AI 让编程发生了多么巨大的变化，”
00:00:15“特别是自去年 12 月以来。”
00:00:17OpenAI 的 Greg 也谈到了这一点。
00:00:20自 12 月以来，模型和工具的能力出现了阶梯式的提升。
00:00:24几位工程师告诉他，自 2025 年 12 月以来，
00:00:28他们的工作已经发生了根本性的改变。
00:00:29那么，2025 年 12 月究竟发生了什么？
00:00:32简单来说，当时推出的最新模型终于可以胜任
00:00:37完全自主的长期任务了。
00:00:38对于 AI，我们的终极梦想始终是：当我们睡觉时，
00:00:43AI 可以 24/7 全天候自主工作。
00:00:46甚至在 2023 年，最热门的项目（如果你还记得的话）叫作 AutoGPT。
00:00:50那是这种完全自主代理系统的首次亮相。
00:00:54它们的架构相当基础简单：使用 GPT-4 作为模型，
00:00:59根据用户目标自主拆解任务清单，
00:01:03并配备简单的内存存储来记录结果。
00:01:04当时人们在尝试一些疯狂的事，比如设定“赚 10 万美元”的目标，
00:01:08让它无限循环执行任务直到完成。
00:01:11但在那时，由于模型尚未准备好，系统往往会崩溃并以失败告终。
00:01:15但自去年 12 月以来，情况发生了翻天覆地的变化。
00:01:18模型拥有了显著更高的质量和长期连贯性，
00:01:22能够处理规模更大、耗时更长的任务。
00:01:24我们看到业界涌现出了各种不同的实验尝试。
00:01:28首先，从 1 月开始，我们迎来了一个超火的概念，叫作“粗循环”（rough loop），
00:01:33这是一种最基础、最简单的代理迭代循环，旨在强制模型工作更久，
00:01:37从而处理更复杂的任务。
00:01:38我们只是让模型在一些简单的条件检查下循环运行，
00:01:42但已经开始看到显著的差异了。
00:01:43一周后，Cursor 也发布了他们的实验，利用 GPT-5.2
00:01:49从零开始自主构建了一个拥有 300 万行代码的浏览器。
00:01:52Anthropic 也发布了一项实验，他们让一组 Claude 编程助手
00:01:57连续两周从零开始自主开发一个 C 语言编译器。
00:02:01最终，它在零人工干预的情况下交付了一个功能完备的版本。
00:02:05它甚至可以在这个编译器里运行《毁灭战士》（Doom）。
00:02:08与此同时，OpenClaw 开始受到关注，
00:02:13并经历了前所未有的爆发式增长。
00:02:14当时很难理解 OpenClaw 到底是怎么回事，因为从外部看，
00:02:18很容易将 OpenClaw 归类为又一个运行在电脑里的代理，
00:02:23而且还可以通过 Telegram 访问。
00:02:27大家都在想，为什么它会这么受欢迎？
00:02:29直到后来深入使用后我才意识到，真正的区别在于 OpenClaw 代表了
00:02:35这种“始终在线、长期运行、完全自主”的代理类型，
00:02:40这与我们之前使用的、需要人类作为主驱动力
00:02:45通过提示词引导下一步操作的代理系统截然不同。
00:02:46OpenClaw 是始终在线且具有主动性的。
00:02:49这种自主感是由一个相当简单的架构创造的：它拥有内存上下文层、
00:02:53用于自动采取行动的触发器和定时任务（cron job），
00:02:58并拥有完整的电脑访问权限，这是一个极其强大的操作环境。
00:03:02我相信 OpenClaw 是第一个真正开启了 2026 年重大范式转移的项目，
00:03:06即我们正从“副驾驶型”简单任务代理系统，转向那些长期运行的完全自主代理。
00:03:13这种始终在线、随时待命、能够自主交付极其复杂且协调性工作的系统。
00:03:15这是一个你必须理解的关键转变。
00:03:20只要你设计出正确的系统来解锁它的潜力，
00:03:22现在的模型实际上比你想象的要强大得多。
00:03:27这就是我今天想讨论的核心。
00:03:28如何通过“外壳工程”（Harness Engineering）来实现长期运行的自主系统。
00:03:30如果你是第一次听说“外壳工程”，可以把它看作是
00:03:34我们之前讨论过的“上下文工程”或“提示词工程”的进化版。
00:03:38以前，我们真正关注的是如何在有限的上下文窗口内优化提示词，
00:03:41以让模型在单次代理循环对话中表现最佳。
00:03:46但“外壳工程”真正关注的是那些长期运行的任务，
00:03:49也就是说，你如何设计一个可以跨越不同对话、
00:03:53涉及多个不同代理协作的系统。
00:03:57以及如何设计正确的工作流，确保每次对话都能检索到相关的上下文，
00:04:01并配备正确的工具集以榨取模型的最大潜力。
00:04:05这是一个相当新的概念，好消息是业界已经
00:04:09在 Anthropic、Vercel、LangChain 等公司中形成了一些最佳实践。
00:04:14我会逐一讲解，这样你就能看到其中的模式。
00:04:16但在深入探讨之前，随着完全自主代理的范式转移，
00:04:21未来 6 到 12 个月最大的机遇之一，就是为特定垂直领域构建“OpenClaw”。
00:04:25这意味着你需要深入调查并理解某个行业的端到端工作流，
00:04:29并构建一个具备正确环境和工具的自主代理来完成整个流程。
00:04:34这就是为什么我想向你介绍 HubSpot 进行的一项精彩研究，
00:04:39即《AI 在邮件营销中的应用报告》。
00:04:40这份报告非常引人入胜，能帮你了解像邮件营销这样的垂直领域，
00:04:44人们现在究竟是如何使用 AI 的，以及还存在哪些差距。
00:04:47因为这份报告展示了邮件营销中清晰的工作流，
00:04:51以及你可能实现的自动化机会。
00:04:52他们调查了来自顶尖公司的数百名邮件营销人员，
00:04:57以准确了解 AI 如何重塑他们的工作流。
00:04:58他们探讨了为什么营销人员仍然需要进行大量的重度编辑，原因何在，
00:05:03以及他们在邮件营销中应用 AI 时面临的最大挑战。
00:05:06其中的每一个挑战对你来说都是构建完全自主代理的绝佳机会。
00:05:07他们甚至深入研究了营销人员最关心的特定 KPI，
00:05:11以及 AI 在哪些方面已经展现出了显著成果。
00:05:15此外，还有邮件营销人员真正希望从 AI 身上得到什么。
00:05:16所以，如果你是一个正在思考下一个大动作的代理产品开发者，
00:05:20我强烈建议你去看看这个资源。
00:05:24我已经把免费下载链接放在了下方的描述栏中。
00:05:27再次感谢 HubSpot 赞助本视频。
00:05:30现在让我们回到长期运行代理系统的“外壳工程”。
00:05:32从宏观层面来看，我从中总结出了三点核心心得。
00:05:36第一，对于长期任务代理，系统设计的关键在于创建一个“易读的环境”，
00:05:39让每个子代理或每次对话都能清晰地理解当前的进度。
00:05:44通常可以通过一些工作流来强制执行环境的可读性。
00:05:49稍后我会详细解释。
00:05:50第二，验证至关重要。
00:05:54通过允许系统通过更快的反馈循环有效验证其工作，
00:05:56可以显著提高系统的输出质量。
00:05:58第三，我们需要给模型更多的信任，
00:06:03而不是过早地构建那些封装了大量推理和逻辑的专用工具。
00:06:04我们应该给模型最大的上下文和它们原生理解的通用工具，
00:06:08让它们像人类一样去探索。
00:06:11接下来我会结合具体的案例逐一拆解这三点。
00:06:16首先是 Anthropic 关于长期运行代理有效外壳的博客。
00:06:17他们尝试使用 Claude Code SDK 构建一个专门处理超长任务的代理，
00:06:20比如克隆一个 Claude.ai 网站。
00:06:24他们观察到的第一个失败点是：代理往往一次想做太多事情。
00:06:29基本上，它总是试图“毕其功于一役”，一次性搞定整个应用。
00:06:32这导致模型在开发中途就耗尽了上下文，
00:06:37使得下一个会话开始时，功能只实现了一半或文档不全。
00:06:40然后代理就不得不靠猜测来搞清楚发生了什么，
00:06:45花费大量时间试图让基础应用重新跑起来。
00:06:49第二个失败点是：代理倾向于过早宣布任务完成。
00:06:52你可能自己也经历过几次这种情况。
00:06:55Claude Code 或 Cursor 会宣称项目或功能已完成，
00:07:00但一旦你测试，就会发现根本跑不通。
00:07:02他们解决这种模型默认失败行为的方法是：首先，设置初始环境，
00:07:05为提示词要求的核心功能奠定基础，
00:07:07引导代理一步步、一个功能一个功能地工作。
00:07:12这类似于我们通常采用的“计划”或“产品需求文档”（PRD）方法。
00:07:16其次，开始提示每个代理朝着目标取得增量进展，
00:07:20同时在每个会话结束时让环境保持整洁状态。
00:07:23他们设计了一个由两部分组成的解决方案。
00:07:27他们会有一个“初始化代理”，使用专门的提示词要求模型
00:07:32通过 init.sh 脚本设置初始环境，比如配置开发服务器，
00:07:35这样下一个模型就不需要担心这些琐事了。
00:07:40还会生成一个 Claude_progress.txt 文件来记录代理已完成的操作，
00:07:45以及显示新增文件的初始 Git 提交。
00:07:48然后，后续每个会话都会有一个“编码代理”，要求模型取得增量进展，
00:07:53并留下结构化的更新。
00:07:55所有这些努力实际上都是为了一个目的：如何定义一个环境，
00:08:01让代理在开启全新上下文窗口时，能迅速理解工作状态。
00:08:02具体工作流是：初始化代理首先尝试建立一个环境
00:08:07或一套文档系统，用来追踪和维护整体计划。
00:08:11他们设计的环境首先包含一个“功能列表文档”，
00:08:13以防止代理一次性处理过多功能或过早认为项目已完成。
00:08:17他们会让初始化代理将项目拆解成 200 多个功能，
00:08:21并记录在一个类似于这样的本地 JSON 文件中，
00:08:25每个任务都有详细规格说明以及“通过”或“失败”的状态。
00:08:30默认情况下，所有任务都标记为“失败”。
00:08:34这迫使模型始终关注项目总目标和进度，挑选优先级最高的任务并执行下一步。
00:08:39但为了让这个工作流奏效，他们还需要一种方法来强制模型
00:08:41在修改代码后保持环境整洁。在实验中，他们发现最好的方法
00:08:43是要求模型将进度提交到 Git，并附带描述性的注释信息，
00:08:49并在进度文件中写下进度总结。
00:08:50但光有文档和上下文环境是不够的，
00:08:55因为模型默认倾向于在没有经过适当测试的情况下就标记为“已完成”。
00:08:59起初，他们只是提示词要求 Claude Code 在修改代码后始终进行测试，
00:09:05比如在开发服务器上运行单元测试或 API 测试。
00:09:08但这些测试往往无法识别某个功能在端到端流程中是否真的跑通。
00:09:13当他们赋予模型适当的工具来进行自主端到端测试时，情况发生了质变，
00:09:17比如 Puppeteer MCP 或 Chrome 开发工具，代理能够由此
00:09:22发现并修复那些从代码层面看并不明显的 Bug。
00:09:23基本上，他们建立了一套结构：由初始化代理将用户目标拆解为功能列表，
00:09:27同时配套 init.sh 以运行开发服务器，并生成进度文件。
00:09:30这样，下一个编码代理就可以直接阅读功能列表来了解整体项目计划，
00:09:35挑选高优先级任务，并通过进度文件和日志了解当前进度。
00:09:39然后立即运行 init.sh 启动开发服务器，并进行端到端测试以验证环境是否整洁，
00:09:43从而在每次新会话和上下文窗口切换时，获得全局视野和更快的反馈循环。
00:09:47在 OpenAI 的博客中，他们也谈到了非常类似的事情。
00:09:49你必须确保你的应用环境是“易读”的。
00:09:53他们将整个代码仓库作为“系统知识库”或“记录系统”。
00:09:57最初，他们放入了一个巨大的 agents.md 文件，但由于信息量过大，
00:09:59任何代理都难以管理和维护，最终导致了可预见的失败。
00:10:04于是他们设计了一套得当的文档环境结构，将 agents.md 视为“目录”。
00:10:09他们建立了一套文档系统，涵盖了架构、设计文档、执行计划、
00:10:10数据库 Schema、产品规格、前端设计、安全性等等，
00:10:13并将这些目录放入 agents.md 文件中，以便代理在需要时
00:10:16能够准确检索到相关信息。
00:10:19这实现了“渐进式披露”，而 OpenAI 甚至做得更彻底。
00:10:23他们不仅推送代码知识，还将 Google 文档、Slack 消息等
00:10:27各类碎片化信息喂入仓库，作为仓库本地版本的资产。
00:10:32这样代理也能检索到这些信息，因为从代理的角度来看，
00:10:33如果在环境中无法访问，那它在实际上就不存在。
00:10:37但同样，光有文档并不能让代理生成的代码库保持完全连贯。
00:10:42他们还引入了特定的编程工作流来强制执行“不变性”（Invariants）。
00:10:47例如，他们为领域架构分层，设定了明确的跨领域边界，
00:10:49这允许他们通过自定义检查、Linter 和结构化测试来强制执行规则，
00:10:53并在每次 Git 预提交（pre-commit）时自动触发和注入。
00:10:58这类架构在传统软件公司通常要到拥有数百名工程师时才会考虑，
00:11:03但对于编程代理来说，这是早期就必须具备的前提条件。
00:11:04在这些边界内，你可以给予团队和代理充分的自由来表达解决方案，
00:11:09而无需进行微观管理，也不必担心架构会偏离轨道。
00:11:11同时，他们也对代码库做了大量改进。
00:11:16例如，他们让应用可以通过 Git 工作树（worktrees）启动，
00:11:20这样编程助手就可以同时启动并驱动多个不同的实例。
00:11:25他们还将 Chrome 开发工具协议接入了代理运行时，
00:11:29使代理能够通过 DOM 快照、截图和导航来复现 Bug 并验证修复效果。
00:11:33有了这些环境和工作流的设置，仓库终于跨越了一个最低门槛，
00:11:37让编程助手能够端到端地开发一个新功能。
00:11:41现在，每当编程助手收到一条提示词，它就会开始验证当前代码状态、
00:11:46复现报告的 Bug、录制视频演示失败过程、实施修复、
00:11:49通过驱动应用来验证修复、录制第二段视频展示解决效果，并最终合并更改。
00:11:52这两个案例展示了非常宝贵的心得，以及构建完全自主系统所需的必要外壳系统。
00:11:55与此同时，还有一些其他的感悟。
00:11:57通常我们在构建代理，特别是垂直领域代理时，
00:12:01倾向于构建专门的工具来处理特定领域的任务。
00:12:05但学习目标是：大语言模型在使用它们原生理解的通用工具时，
00:12:09表现几乎总是更好。
00:12:13Vercel 发布了一篇精彩的文章，讲述了他们如何重新设计“任务转 SQL”代理。
00:12:17他们曾花费数月构建了一个极其复杂的内部“任务转 SQL”代理 D0，
00:12:21包含了专门的工具、重度的提示词工程和精细的上下文管理。
00:12:25但正如我们许多人经历过的那样，这类系统虽能运作，
00:12:29但非常脆弱、缓慢，且需要持续维护。
00:12:32因为每当出现新的边缘情况，你就得给代理注入新的提示词。
00:12:34但后来他们尝试了一件事，彻底改变了轨迹。
00:12:36他们删除了代理中绝大多数的专用工具，只保留了一个简单的批处理命令工具。
00:12:40凭借这种极其简单的架构，代理的执行速度提高了 3.5 倍，
00:12:43节省了 37% 的 Token，且成功率从 80% 提升到了 100%。
00:12:47Anthropic 团队也分享了类似的经验，他们谈到，
00:12:49与其使用专门的搜索或执行工具，不如只提供一个批处理工具，
00:12:53让它们可以运行 grep、tail、npm、npm run lint 等常用命令。
00:12:58从根本上说，我认为这是因为大语言模型对这些代码原生工具更熟悉，
00:13:02因为它们在训练中接触过数以十亿计的相关 Token，
00:13:06而相比之下，它还需要临时去学习如何生成定制化的工具调用 JSON。
00:13:09我在上周发布的编程工具调用视频中也谈到了这一点。
00:13:12我相信这背后的基本原理是相似的：这种简单架构的基础
00:13:15依然是良好的上下文和文档环境，让模型能利用通用工具
00:13:20来逐步检索上下文。
00:13:25OpenClaw 的情况也是如此。
00:13:30OpenClaw 如此引人注目的原因之一，就在于它们拥有一个出奇简单但极其有效的上下文环境。
00:13:34它们有一系列文档来存储核心信息。有了这个基础，
00:13:38它们只需最基础的工具，如读取、写入、编辑文件、运行批处理命令和发送消息。
00:13:41剩下的能力提升则来自于赋予代理检索相关上下文的环境，
00:13:45加上庞大的技能库来扩展其能力。
00:13:49以上就是关于如何为长期运行的复杂代理进行“外壳工程”的三个实用心得。
00:13:51通过建立易读的上下文环境，让每次会话都能高效获取背景信息；
00:13:55通过正确的工作流和工具，让模型能有效验证其工作并实现快速反馈循环；
00:13:59以及信任代理，给予它们原生理解的通用工具。
00:14:05如果你感兴趣，我将进一步深入分享如何将这些心得
00:14:06转化为具体的开发生命周期流程。
00:14:09在 AI Builder Club 中，我们有关于“氛围编程”（vibe coding）和构建生产级代理的课程与实操。
00:14:13每周，我和行业专家都会分享最新的实践心得。
00:14:15所以，如果你想了解我每天学到的新知识，可以点击下方链接加入我们的社区。
00:14:18希望你喜欢这个视频。
00:14:23谢谢大家，我们下次再见。
00:14:24Tout le risque provient du fait de donner à l'agent un environnement pour extraire le contexte pertinent ainsi que de vastes bibliothèques
00:14:29de compétences pour étendre ses capacités.
00:14:31Ce sont donc trois enseignements pratiques sur la manière de maîtriser l'ingénierie pour des agents
00:14:35complexes à exécution longue.
00:14:36En mettant en place un environnement de contexte lisible pour permettre à chaque session de saisir le contexte efficacement,
00:14:41et en concevant le flux de travail et les outils pour que le modèle puisse vérifier son travail efficacement, favoriser une boucle de rétroaction plus rapide
00:14:46et faire confiance à l'agent avec des outils génériques qu'il comprend nativement.
00:14:50Si cela vous intéresse, je partagerai plus en détail comment je prends ces enseignements
00:14:54pour les transformer en un processus de cycle de vie de développement.
00:14:58Dans l'AI Builder Club, nous proposons des cours et des ateliers sur le 'vibe coding' et la construction d'agents
00:15:02de production.
00:15:03Et chaque semaine, moi-même et des experts du secteur partageons les derniers enseignements pratiques.
00:15:08Donc, si vous souhaitez apprendre ce que j'apprends chaque jour, vous pouvez cliquer sur le lien
00:15:12ci-dessous pour rejoindre la communauté.
00:15:13J'espère que vous avez apprécié cette vidéo.
00:15:14Merci et à la prochaine.