刚才也介绍过了，我是 Lee，今天我们来聊聊这类新的 agent 是怎么工作的。他们一直在线，会主动做事，还能持续运行，也会带大家了解一下搭建他们需要哪些基本组件。这里先放个有意思的说明，我们要聊的一些东西还在开发中，是我们在 SpaceX
正在做的。第一周你们都搭了一个很简单的运行框架，帮助你们理解核心思路，就是有一个模型它能在循环里调用工具，而这其实非常强大，这给模型带来了很多新能力，但也有一些缺点，尤其是你一合上笔记本电脑，进程就停了，不再运行了。
我想聊聊怎么把这个简单的思路扩展成一种新的 agent，也就是常驻 agent。这个思路很强大，能让模型发挥出更多能力。它不只是能在你的终端里运行，也可以在服务器上运行，它可以在云端运行。比如，你可以合上电脑，它可以重新启动，崩溃了也能恢复运行。这个 agent
有自己的电脑，不只是你的笔记本电脑，而是云端的一台 Linux 电脑，有自己的桌面、文件、浏览器，还有其他东西，也许还有一些 3D 应用。
它可以把文件保存在那台电脑上，随着时间推移，它能更多的了解你的进展，并逐渐记住你是怎么和它一起工作的。终端里的运行框架会回应你发来的每条消息，而这种常驻 agent
更像一个同事，不会总是立刻给你发消息，他知道什么时候该保持安静。有时候他可能只想先在后台坐一会儿，等有重要进展时再来找你。而且触发他的方式不只是你打字，不只是你在终端里给他发 prompt，也许是一条 slack 消息、一封邮件或者其他事件，把这个 agents 唤醒，让他去干活。
理想情况下，我们希望这类常驻 agent 能持续工作很长时间，不只是几个小时或几天，甚至可能是几周或几个月。这就需要稍微不同的架构，我们后面会讲到。我们会比较深入的聊聊这个架构是怎么搭出来的，运行框架是怎么搭的，我们怎么走到了今天以及未来要往哪儿走。我们也会讲一些具体的工程设计，看看我们怎么让这个系统主动做事儿，持续运行，并且很好的遵循指令。
当然，最后也会留时间提问，你们可以问今天讲到的内容，也可以问没讲到的其他事情。首先，我们是怎么走到这一步的？我觉得到目前为止，开发者使用 AI 大致经历了四个阶段。第一个阶段就是从 ChatGPT
里复制代码，再粘贴到自己喜欢的编辑器里。现在感觉像是几十年前的事儿，但其实也就几年前。后来模型越来越能配合上一讲提到的那种简化版运行框架，他们就能编辑文件、运行 shell 命令，让你通过一个很简单的界面在终端里跟他们一起工作。
这一下就流行起来了，因为模型突然有了这种新能力，能更主动地帮你做事，也能完成更多工作。接着第三个阶段就是把一开始比较简单的编程 agent 放进专门为他们做的应用里，到了这个阶段，大家开始并行运行很多 agent。可能还会把它们放在云端运行，不只是在自己的电脑上。但这时候你还是有点像个瓶颈，因为他们运行的每条命令你都要审核，你希望确保每条需要命令都恰当，你得一直盯着他们，每个环节都要参与。
现在随着模型运行框架和产品的改进，我们进入了一个新阶段，开始有了这些常驻 agent。他们可以在后台持续运行，有自己的电脑、自己的记忆，在工作中学会新技能。你去睡觉或者去做其他工作了，他们还会继续干活。一个很好的例子是，我们已经逐渐不需要每天都给 agent 发 prompt 了。虽然有时还是会这么做，但你可以把 agent 设置成直接在后台运行。
以前可能是你给 agent 发个 prompt，然后等着再发一个，再等着。如果他要运行一条 shell 命令，你就得批准或者拒绝这条命令。而现在，你可以随时调整 agent 的工作方向，不用把命令一条条排进队列。比如你说：“嘿，去看看这个讨论串。”然后紧接着又说：“哦，对了，还是周四再去做吧。”以前几代模型，在你立刻打断它，再给它另一条指令时，可能会有点搞不清楚。
但现在他们能理解，就像你跟朋友聊天时想到哪儿说到哪儿一样，他们能分辨出这两件事是有关联的。现在模型和运行框架都能处理这种情况了。如果你说嘿，去发这封邮件，去发这条 Slack 消息，系统还会做额外的安全检查。很多公司把它叫做自动审核，本质上就是另一个 AI 模型检查所有要运行的命令。说来也挺有意思，这其实比让你疲惫地盯着几百条需要命令逐条批准更安全。
我们差不多已经到了这样一个阶段。如果做个盲测对比 AI 模型和人对命令的检查，大多数时候模型其实做得更好。这有点反直觉，但随着模型越来越好，交互界面其实变简单了不少。我们把这种常驻 agent 叫做机器人，但你们会注意到现在这类新产品其实已经冒出来不少了，而且越来越受欢迎。我觉得主要原因是我们都知道怎么发消息，大家都知道怎么发消息，也都挺熟悉手机操作。
我们把跟 AI 一起工作的方式简化到了像给朋友发消息一样，但它真的能替你干活。它已经不只是用一问一答的方式回答问题了，而是真的会去做耗时更长的任务，比如你会交给同事的那种任务。模型本身有几项变化，让这一切成为了可能。我会讲六项，不过其实还有不少。第一项是，就在过去这一年、两年里，模型在较长时间内遵循指令的能力真的提升了很多，不容易搞混或者出错。
现在只要做好压缩和上下文精简，模型就能比较可靠的连续运行几个小时或者几天。这个我们一会儿会讲。第二项，现在模型基本上可以把工作交给帮手，这些帮手叫做子 agent。子 agent 之所以有用，是因为模型在处理任务时有一份工作记忆，而这份记忆迟早会被填满。所以，如果能把工作交给这些帮手就很好，他们有一份全新的工作记忆，这实际上相当于给了他无限的上下文。
子agent 可以去做那些可能消耗很多 token 或者需要大量调用工具的工作，再回来向主 agent 汇报进展。我后面会用一些图来说明。现在的模型不只是更擅长调用工具了。要知道，就在几年前，他们基本上还不太会调用工具，而且经常产生幻觉。挺有意思的，现在已经不怎么听到大家讨论幻觉了，因为这个问题算是解决了，大部分已经解决了。
不过，他们不只是能调用工具，你还可以给他们非常强大的工具，就像你给团队里的新同事配好工作所需的工具一样，当然包括运行 shell 命令和处理文件，但你还可以给他们一整台电脑，一整台 Linux 电脑，让他们制作演示视频之类的东西。他们能像人一样在屏幕上点来点去，而且越来越擅长这么做，这也叫做电脑操作。
基本上这意味着任何没有提供 API 或者 MCP 服务器的 SaaS 产品或网站都可以在无人值守的情况下使用。也就是说，这些模型和机器人可以通过操作电脑，自主使用它们。你可以把所有信息都存进文件里。之所以能这么做，是因为这样一来，模型其实很容易就能重新查到、搜索到这些信息。这个我们也会讲。最后，你只要给机器人示范一下某项工作怎么做，它就能把这变成技能、记忆、例行任务或者其他以后可以重复使用的东西。
关于文件，举个例子，这个例子比较简化，不过你可以想象跟机器人一起工作时，底层可能就是这个样子。你逐渐建立起一份用户资料，或者说对用户的了解，而这些内容会放进每一个 prompt
里。比如，你可能喜欢那种像发短信一样全用小写字母的消息风格，那每条消息都应该用这种风格。另外，随着你和这些机器人一起工作的时间越来越长，会逐渐积累一份工作日志，就像你和一个同事一起工作，他每天都会记下自己做了什么一样，这些内容都会存进文件里。
之后，模型可以决定要不要搜索或使用它们。你要是说嘿，我上周都做了什么，它就可以去查。而且，模型很擅长用 Linux 命令运行 shell 命令，用 grep 去搜索、查看这些文件。技能也是一样，本质上就是把你做某项具体任务的经验写进一个 Markdown 文件，包括具体要走哪些步骤，以及你认为哪些因素会让这件事儿成功或失败。
而且这不只是你自己的技能，现在已经形成了一个完整的生态，很多公司和开发者都在编写这些技能，比如怎么写好一封邮件，怎么做好一个 API，还有各种各样的事情。比如 Grok Bot 就有一整套插件系统，基本上你想用的任何工具都有可以安装的插件，里面会用到技能或者服务器，还有定时任务。如果你熟悉克隆定时任务，就知道这基本上是按某种时间安排运行一个 prompt，也很有用。
基本上一切都在电脑上。第三部分，我们再深入一点，看看这个始终在线的 agent 脑子里是怎么运转的，也就是看看幕后发生了什么。A 阵始终在线到底是什么意思？这张图可以从左往右看，一开始服务器处于休眠状态，A 阵可以使用的那台电脑也处于休眠状态。所以，不管是你给他发了条消息，还是某种触发机制让
agent 启动，具体的触发机制我们一会儿再讲，本质上都是加载这个 agent 的全部状态，让它启动起来，在服务器上运行。
如果它判断需要用电脑，比如要用电脑上的浏览器，或者在电脑上点击操作，它也可以把电脑启动起来。等你用完了，它也能让服务器和电脑进入休眠。为什么这很重要？如果给每个人的电脑都一直开着，成本会很高，而且全世界也没有那么多电脑，这还会占用大量服务器资源。所以这些状态可以持久保存到数据库里，包括对话记录、记忆、定时任务，所有这些。
那 agent 是怎么被唤醒的呢？当然，你可以直接给它发 prompt，但我觉得越来越有意思的是，让其他东西在后台运行，由他们来判断什么时候需要联系你的机器人。比如有人在 Slack 上给你发了消息，而你的机器人也可以待在 Slack 里，也可能是一次电话，或者你让机器人参加了一场会议。现在在
Space 机器人替员工参加会议越来越常见，有些员工没法参会，但想让自己的机器人去做个记录，再回来向自己汇报，还挺有意思的。
也可能是你有个定时任务，或者某项后台工作要花几个小时甚至几天，你希望它完成以后回来给你做个总结。这些事情发生以后，我们会用一个路由器去重，再判断怎么把这些内容放进对话里。它还会根据一些经验规则来判断这件事儿需要打扰用户吗？因为并不是每件事儿都重要，就像你的同事在做一件事儿，如果每次有点进展，他都跑来打扰你说：“嘿，快看，我这件事又有进展了。
”那会挺烦的。你其实可能只需要每天听一次进度汇报吧。我也说不准，具体得看任务。我前面说过，agent有一台电脑，也就是一台Linux机器。这台机器运行的是Firecracker虚拟机，它很有用，因为你可以很方便的给机器的状态做个快照，然后把它关掉，再重新启动。这台机器上当然有文件，但你也可以连接进去，实时查看它的画面。
如果你愿意，还可以亲自控制它。这台机器当然也能运行命令。如果你要运行一些 shell 命令，这就很好用。你可能不想在自己的笔记本上运行，而是想放到这个做了安全防护、限制了权限的独立环境里。另外还有一点很有意思，它当然装了 Chrome 可以用浏览器，但你也可以让它拥有虚拟桌面。所以，如果你运行了五个、十个机器人，每个都需要自己的浏览器，你就可以让他们各自使用不同的屏幕。
同样，这些都是机器人之间共享的基础设施，他们可以调用这些电脑。我们讲过唤醒 agent 的触发机制，就是图左边那部分，比如不同的应用 Slack 消息或者邮件，中间这部分是服务器，右边是刚才说的电脑，可以在上面运行文件、命令以及其他东西。我们再多聊一点服务器，我已经提过命令进来以后会被放进这个队列，然后调用紫色的方框，也就是 agent 循环，这个我们上周讲过。
就是模型在循环里调用工具，等你把它关闭时，可以把状态保存到数据库或者存储系统里。我觉得有意思的是，看着这张图，你会发现，就这么一个小组件，只要给它配上这些有用的工具，连接到各种不同的服务，就能在上面搭起各种抽象层，做出一个非常强大的产品。Agent 之所以在服务器上运行，是因为我们采用了计算机领域很常见的做法，让客户端轻一些，服务器重一些。
这些年来，计算机领域一直在这两种方向之间来回变化。这么做有几个很好的理由，比如，假设你要更新 Agent 的代码。如果只是为了发布这些代码，就得在 App Store 上发布一次应用更新，那会挺麻烦的。相比之下，直接在服务器上快速发布一批更新就方便多了。还有，有时你需要做计算量很大的工作，比如语音转文字、生成图片之类的，放在服务器上大概会比放在设备上快。
当然，也得看是什么设备。而且，服务器怎么扩容？我们已经有很成熟的方法了，尤其是面对不断变化的流量和增长。但这里最关键的是，如果你把 Agent 循环放在虚拟机上，就没法在保持 Agent
的服务器运行的情况下，单独关闭虚拟机。你希望把所有东西都保存到服务器上，这样随时都能重建那台虚拟机。比如，假设你需要给虚拟机做一次重要的 Linux 零日漏洞更新，如果能重建虚拟机，同时保留整个 Agent 循环，也不让应用停机，那就很好。
你点击发送以后，这里可能有点太细了，我就大致带一下。如果你想深入了解分布式系统，思考强一致性和最终一致性的区别，这些都是很有意思的话题。基本上，你发出一条消息，会希望客户端立刻识别到并确认收到。接着进入这一轮处理，你当然会让模型在循环里调用这些工具，并把相关内容保存到数据库里。客户端则会订阅各个服务器的通知，这样就知道有没有变化，并持续监听这些信号。
收到信号以后，客户端就可以去服务器获取最新信息。你还可以做一些比较巧妙的去重处理，确保发生重试时消息列表里不会出现重复的消息。这里要考虑的底层基础设施的基本组件是工作流和任务队列，两者主要的区别是，如果用任务队列，假设你让 agent
去做一项复杂任务，它按步骤往前走，从第一步到第二步再到第三步，但因为某种原因基础设施出了故障，遇到了问题，用普通队列的话，一旦崩溃再重新启动时就得重新执行第一、第二、第三步，这显然可能会带来很大的问题。
所以，你真正需要的是能持久保存执行进度的工作流，这样你就可以安全的重试，失败以后再重试，会直接从第三步接着做。从某种程度上说，这在分布式系统和基础设施领域已经是个解决了的问题。我们用的是一个叫 Temporal 的开源工具，如果你好奇，可以去了解一下，还挺有意思的。这样我们就不用从零开始重新实现很多非常复杂的东西。
当然，你还是得运行它所需的基础设施。不过这里有些部分需要组合起来。假设一条新消息进来了。优先级会有所不同，比如是我直接给自己的 agent 自己的机器人发消息，还是群聊 Slack 讨论串里的消息，或者某个后台定时任务。所以如果我说哦，其实把这个活动的日期改一下，我们就希望 agent 循环停下来，让我的消息优先于正在发生的其他所有事情，这也挺合理的。
其他人发来的消息就排到队列后面。如果 agent 在很短的时间里收到三四条消息，它能把这些消息合在一起，只处理一轮，具体采用什么经验规则，你可以自己决定。然后它就一轮一轮的处理。我们来聊聊 agent 运行框架本身，这是在上周讲过的基础框架上，再加入一些新工具和新概念。Grok Bot 的
Agent 运行框架，可能还有市面上一些类似工具，最大的区别在于我们采用了轻客户端、重服务端的架构，客户端和服务端之间只有一个工具负责通信，就是向用户发送消息。
这样做的好处是架构其实很简单。从某种意义上说，客户端只是在给服务端发消息，而很多比较重的工具都放在服务端。这样的工具有很多，比如运行 shell 命令、读取文件，也可以调用云端 agent 录制屏幕或者做演示。我觉得这样效果挺好，因为现在无论你在哪里启动一个新客户端，不管是手机应用、服务器、桌面应用、电子邮件，还是 Slack，都只通过这一个工具跟服务端来回通信。
不过，在客户端这边，虽然只有这一个工具，但收到工具调用时，它可以决定怎么以丰富、可交互的方式来展示，让用户用起来最合适。比如，服务端传回的信息说用户正在尝试登录某个服务，客户端就可以显示相应的登录表单，并连接 ePassword 这样的工具。它还可以调用 Stripe Link 这样的服务，或者使用 X Money 和其他服务让用户支付服务费用。
如果你要做的是没法撤销的事儿，比如发邮件或者发 Slack 消息，它可能会先回来让你编辑并批准草稿，再发送出去。有时候，如果其实不需要发消息，你也可以只用一个表情来回应。回到我刚才说的动态工具，发现每个模型都有上下文窗口，可以把它理解成模型的工作记忆，容量有一个 token 数量上限。如果你把所有能用的工具都塞进上下文窗口，剩下的空间就不多了。
工具的工作方式是，你要提供工具名称、参数结构，还有各种细节。如果你开始安装谷歌云盘连接器、Gmail 连接器、YouTube 连接器以及各种使用 MCP 服务器的服务，而它们全都有自己的工具，那就会变成上面那张图的样子，很多格子已经被填满了。问题是这样留给模型处理对话里实际任务的空间就少了。现在很多流行的 A 轨运行框架都会用一种上下文工程技巧，叫动态上下文。
我记得也有人把它叫做工具搜索工具，这名字挺有意思。基本上就是每次发给模型的消息里只放工具名称，然后模型可以自己决定。啊，我现在想用这个工具，我可以去文件里读取相关信息。这些东西说到底都可以是文件系统里的文件，这样能省下上下文空间，也就能节省费用，减少用量，对大家都有好处。总的来说，这里的原则就是先是成本最低或者最可靠的选项，再沿着这个顺序逐步往上走。
最简单的就是用 agent 或机器人根据对话历史已经知道的信息，如果当前上下文里没有，也许有一个插件 MCP 服务器或者某种 API 可以去获取信息，比如从 Plaid 获取你的银行信息。也许这条路行不通，他就需要搜索网页，看看昨晚小熊队的比赛比分是多少。也许他没有这样的工具，那就得到电脑上打开浏览器，在里面搜索。
最后，也许他需要操作整个桌面，在那台 Linux 电脑上运行脚本、运行命令或者构建一些东西。只有这些办法全都失败了，才去打扰用户，请用户提供信息或者批准某个操作。这就很像跟同事一起工作，他们不会什么事儿都来打扰你。理想情况下，他们会先试一试其中的很多办法，在 Agent 能使用的那台 Linux 电脑上，它大致有三种获取信息的方式。
当然，它可以直接截屏，但还有更高效的方式。它也可以查看网页的 HTML 或者查看无障碍树。查看无障碍树可以减少很多 token 用量，也能帮你找到想让浏览器点击的按钮、链接或其他元素。当然，如果这些都不行，你也可以直接点击屏幕上的像素位置。比如有些网站会弹出需要点击的模态窗口或对话框，所以你的 agent 也得具备这个功能。
再往下，也就是这个顺序里最没办法的时候，就回去找用户说，哦，这里需要双重验证的验证码，或者遇到了某种人机验证之类的东西。把这些拼在一起，思路就是，你有一个主 agent，它负责统筹协调。对于主 agent，你希望对话内容尽量精简，因为它现在可以调用各种不同的助手，而这些助手就是子
agent。这样很有用，因为如果你把工作交给一个助手，让它运行一堆 shell 命令或者做很多成本很高的工具调用，这些工作最终会产出某个问题的答案或者完成某项任务，但整个过程都不会让主 agent 的对话和上下文变得臃肿。
它只把结果传回来，这样做出的产品就会让人感觉它有无限的上下文。当然，无限上下文并不真的存在，每个模型都有上下文上限。但通过这些技巧和变通办法，尤其是训练模型，让它更擅长做这些事，就能让你感觉不到自己碰到了上下文窗口的限制。随着对话不断往下进行，你也不会感觉模型的表现变差了。我们有这些不同的助手，每个助手都有不同的技能，每个助手都有自己独立的持久工作流。
回到刚才队列和工作流的区别，这就意味着，如果出了故障，比如视频助手崩溃了，或者某个操作占用了太多内存，它可以重新启动继续工作，不会丢失之前的进度。而主agent就像一个同事在管理一份代办清单，你可以做几件事儿，比如你可以查看它的进展，给他发消息，也可以让助手停止工作。所以，这里面很多设计都是在借鉴一种理想的方式，看看一支处理复杂问题的工程师团队应该怎么扩大规模。
再分享几个我们团队在开发过程中发现的有意思的小细节。我想接下来会再多讲一点 prompt 缓存。不过理想情况下，你不要在一轮运行过程中添加或移除工具。就像我在那张有很多格子的幻灯片里说的，如果工具描述或者参数结构特别长，就会占用上下文窗口里的大量空间，这会增加费用，也会增加用量。理想情况下，你要尽量减少这部分内容。
工程上有很多可以优化的地方，能把这些内容精简下来。还有一个有意思的点，你可能会听到有人说：“哦，我们可以做一个只有一个工具的 agent 运行框架，这个工具就是运行 shell 命令。”这确实可以，很多事情都能用这种方式来做。但如果你发现模型为了做某一件事儿，百分之九十的时间都在运行 shell 命令，那么把其中一些操作做成专用工具，其实可能更高效。
对于那些要检查产品实际运行情况的人来说，这样也更容易看明白。最后一个也挺有意思。显然，如果你在给人写错误信息，把情况描述清楚会很有帮助。比如，好，这个操作失败了，请点击这个链接，或者接下来你需要这样做。事实证明，这对 agent 也很有帮助，所以，给 agent 设计好的错误信息，也涉及开发者体验。
当你把工作交给机器人，让它长时间持续处理时，很重要的一点是，你得相信它能保护好你的信息，也能以安全的方式执行操作。所以，就算它在自己独立的电脑上工作，不会影响你电脑上的东西，你还是会希望每条是要命令执行前，都有一个模型先审查一下。也就是自动审查对于不可信的输入，比如收件箱里的一封邮件，它可能是钓鱼邮件或者某个收到的回调请求。
如果能处理好就很理想。你不希望把这些内容发给模型，让他把这些当成用户指令。为了确保能妥善防范 prompt 注入，整个行业还有很多工作要做。对于发邮件这类不可撤销的操作，确实应该先问用户。你也可以在产品里设计一些工作流，让密码和其他这类信息不进入模型的对话。好，上下文工程也叫 agent 运行框架工程，我觉得它们差不多是一回事儿。
它们随着时间一直在演变。不过说到底，我们能用哪些技巧和办法尽量减少这些 agent 运行框架使用的上下文呢？这样做有助于提高效率、降低成本，也有其他好处。我刚才讲过 prompt 缓存，这就是个很好的例子，说明它为什么这么重要。想想你用编程 agent 或任何 agent
时的情况，理想情况下用掉的大部分 token 其实都是缓存的 token，因为你先把一段对话发进去，然后做个改动，多加一条消息，接着基本上又把整段对话重新发了一遍。
所以你看模型的定价就会发现，缓存的 token 当然有很大的折扣，你要尽量让他们一直处在缓存有效期内。一个办法就是在不同的调用之间尽量保持工具定义、系统 prompt，还有这些信息不变，这样就不会让缓存失效。也不用每次都按每缓存的 token 来付费，所以如果你把固定的部分放在最前面，到了最后只有新进来的那条消息是新增的，那你就只需要为这部分新增内容按每缓存的 token 付费。
这里面也有很多讲究，既有经验技巧，也有科学方法。基本上最理想的情况下，你会跟主 agent 进行很长、很长、很长的对话，他会一遍又一遍的压缩上下文，也就是做摘要。有时候你甚至都没注意到，我们后面会展示一个例子，所以你确实要尽量让这段上下文保持精简。有一些办法可以做到这一点，只要输出特别长，就可以把它放进文件里，不用全塞进上下文。
Agent 很擅长读文件，所以这招其实挺好用的，就像读取一个 skill 或者读取一条记忆一样。如果你要给模型一张截图，或者让它做其他开销很大的工作，就把这件事儿交给一个助手，还是一样，任务交给子 agent 就不会影响主 agent 的上下文。另外，理想情况下，你要像打理花园一样，边进行对话边不断修剪，从对话从上下文窗口里清掉不必要的东西。
这既是为了降低成本，也是为了让模型能回想起相关信息，确保它表现良好。所以缓存没命中，其实就有点像系统里的一个 bug。回头看今年一月那时候，OpenCL 开始火起来，大家通过模型提供商的订阅套餐来用它，这是一种很新的使用方式。模型提供商以前没怎么见过，运行框架也还没针对这种工作流做优化，所以经常出现缓存没命中的情况。
像这样让 agent 一直运行，显然就会出问题。所以后来做了很多修复，让系统能更稳定的尽量保持 prompt 缓存有效。这里有个挺有意思的小技巧，就是尽量让 prompt 里的所有内容保持固定顺序。这样，即使你部署了新的改动，想测试系统 prompt 的某项新改动，或者加一个新工具，你也可以给每个部分算个哈希值，始终保持固定的顺序。
比如说，你正在做 A/B 测试，想往 prompt 里加一段新内容，你肯定不希望这把其他所有人的 prompt 顺序都搞乱，否则缓存就失效了，那就有麻烦了。还有一个有意思的技巧是，你打开聊天窗口开始打字的时候，服务器就可以提前准备 prompt 给缓存预热，这有点像你在网站上把鼠标移到一个链接上，它就可以提前获取下一页的内容。
像这样的小工程优化非常多，积累起来就能让这些模型在 token 使用上走得更远，也能让它们在长时间使用时表现得更聪明。关键是，当你要长时间工作时，就必须非常擅长压缩上下文或者做摘要。比如，模型的上下文窗口是二十万 token，你一直用，一直用，一直用，最终总会到需要做摘要的时候，而所有压缩都会损失信息。
所以，你得找到最好的压缩算法，避免丢掉重要细节。我相信，光这个问题就足够让人做完整个博士研究了。要做好，真的非常非常难。不过我们来看个例子，假设你跟机器人来回聊，已经聊了超过十万 token，然后你去做别的事儿了。模型提供商会设定一个缓存有效期，在这段时间里缓存仍然是热的，可能是十分钟，也可能是六十分钟。
我们用的一个技巧，我觉得很有帮助，就是趁缓存还热着，现在就把上下文压缩一下，因为这段对话很长，这时候做压缩会便宜得多。所以直接把上下文压缩好，这样用户过三十分钟或者过一段时间回来时，就可以从这份摘要接着聊。基于这份摘要继续添加消息，成本也会低得多。要把摘要算法做的质量很高，这里还有很多工作要做。说到上下文压缩以及选择把哪些信息放进 agent 的记忆，我会把它分成几个不同的层次来看。
第一层是关于用户的重要信息，每次都必须带上。回到我前面说的那个例子，用户总是希望文字全部用小写，这可能就需要放进每一条消息里。否则，如果你想完全照着山姆奥特曼的风格来，结果某条消息里突然出现了大写字母，那就很奇怪了。然后，你可能还有一些想放进去的事实信息，算法有很多种设计方式，可以用来判断哪些事实最重要，应该保留。
所以，理想情况下，要对这些事实做某种垃圾回收。想想看，我们的大脑其实也差不多是这样工作的，就像是这条信息现在很重要，得保留，它跟今天这段对话有关。你现在大概没在想某场足球比赛，你的大脑很擅长把眼下相关的信息留在当前的思路里，同时也记住其他信息，留着以后再用。我们在这里尝试模拟其中的一些机制运行框架里，当然会有这些核心事实。
它也有带日期的日志，基本上就是你过去的对话记录。另外还有一些临时笔记，记的是你眼下正在做的事情里的一些小事。这些笔记本来就设计成临时的，之后会被清掉，但可能在接下来的三十分钟或者一小时里有用。其他所有东西都可以通过文件找到，这就是文件的妙处，也是模型擅长运行命令的妙处。它们随时都可以去查东西，而且真的很擅长这么做。
接下来会怎么发展呢？这里有一个飞轮，通过训练让模型在产品中的表现越来越好。先简单回顾一下大语言模型训练的几个阶段，首先是预训练模型，通过大量互联网文本或者其他私有数据形成对世界的总体认识。然后是监督微调，你教模型按照某种方式行动，比如当一个聊天助手或者当一个 agent，最后是强化学习，有点像教模型玩游戏，让他把这些游戏玩的越来越好。
对于这些始终在线的 agent，比如在监督微调时，让模型看到运行框架的使用示例，学会在框架里工作就很有帮助，这样它就能理解有哪些工具可用。在强化学习时，训练模型更好的遵循指令也很有帮助，比如有几百个 skill 时，怎么判断该调用哪一个？又比如让它在浏览器里操作，到处点击时怎么点对位置？而且不只是训练本身，还有你怎么提供模型服务，怎么做推理。
你正在对话的主 agent，理想情况下，你希望它的延迟非常低，你希望它马上回应你，回复的很快。你可以调整运行框架和推理过程来做到这一点。但如果你把任务交给一个助手，让他去做一项耗时很长很长的工作，那到了这个时候，十分钟和十二分钟的差别就基本可以忽略了。这样，你就可以决定该怎么做优化。这个飞轮的运转方式是，比如你的 agent 做错了一件事儿，理想情况下就把这件事儿变成一个评测案例。
模型不小心调用了这个工具，但它本来不该调用。然后在后端你可以修运行框架、修 bug、修 prompt，也可能是推理出了问题。你可以通过评测检查，确保问题确实修好了，然后发布这个改动。开发这些产品的团队基本上每天都在做这些事儿。他们发现 bug 修复 bug，再用评测来衡量效果，这就是那个不断改进的内循环。
然后还有一个外循环，就是每隔几个月，或者每个月，或者隔一段时间，你会训练新的模型。理想情况下，新模型会从所有这些 bug 和失败中学习，评测成绩不断提高，在你关心的事情上做得越来越好。你就可以把新版本放进产品里，确认他们在这些不同的事情上都有进步。有意思的是，新模型推出时能力又会有新的跃升，这就让你能用新的方式使用产品。
比如说，关于在群聊里使用机器人的训练数据，其实还没有多少。这算是个新出现的用法，大家还在摸索。做好这件事儿很重要。显然，如果你看过 Mobile 或者 Hugging Face 那次事件，就知道这事儿也有可能出问题。所以，训练模型在多 Agent 系统里表现得当很重要。比如在不同机器人互相交流的情况下。
所以，理想情况下，你们作为产品团队，在一家做AI的公司里一起搭建这类运行框架，就应该一直推进这些内循环和外循环。我们在Cursor时有一条原则，现在在SpaceX也是，就是删掉产品。我们的意思是你得把这个想法真正接受下来，假定今天的模型就是他们今后最差的水平。这意味着六个月后，你可能需要把用户界面彻底重做。
今天我讲的大部分内容，跟我在六个月前讲这场演讲时会讲的内容相比，已经有了很大的更新。跟一年前比就更是如此，因为我们学到了很多搭建运行框架和做上下文工程的新方法，都是实际能用上的。所以，一个好的策略就是尽量面向下一代模型来做产品。怎么才能尽可能少做一些东西，又够用，同时做出一个非常、非常简单的界面，让你能使用这些模型，让他们替你思考和行动呢？
接下来六到十二个月，我觉得有些事情可能会发生，我们拭目以待。我觉得这些预测还算稳妥。不过现在假设你的 agent 或机器人替你干活，可能持续几个小时，也可能持续一天，具体取决于任务有多难。我觉得很有可能用不了多久，你的 agent 就能连续工作几周，甚至几个月。这也确实会带来一些有意思的问题，比如我们该怎么训练和评估这些模型？
我觉得模型回忆对话中以往信息的能力会越来越好。这方面的研究有很多不同的思路，包括用什么算法，以及底层的数据用什么形式来表示，可能是图，也可能是文件或者别的东西。我觉得理想情况下，如果你有这么一个数字同事，你就该把真人同事入职时你会提供的所有工具全都给他。当然，我觉得各个组织还在慢慢接受这个想法，所以这方面还有更多事情要做。
我觉得交互界面也许还会变得更简单。我觉得有些人会更愿意直接用语音跟自己的机器人或 agent 对话，双方都用语音。也许他们会有一台 Johnny Ive 做的设备，希望它真的很酷，然后他们就能整天跟他说话。我觉得模型和产品会变得很擅长在工作中学习技能，再把学到的东西写进文件、指令和技能里，把模型本身的智能真正用到你交给它的各种任务上。
我觉得个人和公司也会更擅长把各种专门设计的流程怎么运作写下来，让 agent 能看懂并使用。我觉得有一些有意思的问题可能会给大家一些灵感，去做研究或者深入了解。第一个问题还是回到刚才那个想法，让 agent 连续运行一个月。如果你需要评估一个运行一个月的 agent，可模型每个月就发布一次，你该怎么办？
这样一来，你就没法充分评估确认模型的表现是不是足够符合预期。所以你要么想办法把评估做得更好，要么就别那么快发布模型。我觉得这是整个行业接下来六个月必须解决的一个问题。还有记忆，刚才我们已经聊过这方面的不同算法。我觉得安全方面还有很多事情要做，比如怎么构建安全的运行框架，怎么让这些 agent 周围的基础设施足够安全，防止他们被恶意攻击者控制。
还有一点，我们刚才没怎么展开，就是用什么经验规则来决定 agent 什么时候保持安静，什么时候来打扰你。我觉得我们还没把这件事儿做得很完善，还在努力拿捏主动帮忙的分寸。比如他会说，嘿，我看到你昨天没来上课，我录了音也做了笔记给你，这样也许很有帮助，也许会有点烦人，我们还得找到合适的平衡。我还觉得一个相当稳妥的判断是，到明年这个时候，全世界流转的 token 会多得多，多得多。
这意味着优化推理、优化模型、优化运行框架，设法降低 token 用量，提高效率，我觉得也会非常重要。现在有了这些新的基础组件，值得我们想一想。我记得我在 X 上看到的应该是 OpenRouter 的 Alex，他对这件事儿有个很好的看法。有人说，哎，现在每个应用看起来都一样，都有侧边栏，都有 agent，都有聊天框，大家都在做同样的东西。
他就说，对啊，这就像你在 2005 年说，大家都在做同样的东西，都有服务器，都有数据库，都有个增删改查的界面，用来更新和删除东西。而实际情况是，这已经成了新的常态。每个新产品都得有某种 agent 功能，要么把 agent 集成进来，要么就成为一份没有用户界面的数据，供另一个 agent
使用。所以今天我们聊了很多这类产品：持久工作流、沙箱、云端电脑、记忆技能、连接其他服务、语音支付、身份评估，还有可观测性。
这里每一个模块都对应着几十亿美元的风投资金，可能有数万亿美元。每个领域都有二十家初创公司，每个领域里都有很多不同的东西可以探索，因为它们算是下一代公司、下一代产品的新基础组件，而且都得集成起来成为运行框架的一部分。这方面肯定还有很多事情可做。最后有几点想让大家记住，然后我们还有时间提问。显然大家都是工程师，你们在思考怎么写软件。
现在比以往任何时候都更需要考虑整体的系统设计以及你正在写的代码的架构，因为你在这些方面做的决定，影响会不断累积。我还是赞成看代码的，我还是会看自己正在写的代码。有些人已经不看代码了，我还是觉得看代码有帮助，尤其是能让你理解自己最终交付的架构。才短短几年，这件事儿就变了这么多，真是不可思议。第二点，听起来大家上周已经在尝试做自己的版本，或者了解运行框架是怎么工作的。
我鼓励大家想想我今天做的这些事情，试着用起来，再想想怎么给自己做一个版本。我很确定 GitHub 上某个地方有个开放版的 Grok Bot，有人把我们的代码复制过去，粗糙的改出了一个版本。你们大概可以给它配上图形界面，再找个地方配个沙箱、虚拟机，还有各种别的东西。所以如果你想多了解一点这些组件怎么工作，这可能会很有意思。
最后，我建议大家也别回避，多学一点 LM 的工作原理。我们在这里简单概括了一下他们是怎么训练的，但还有很多东西可以继续了解，不一定非得深入机器学习或者深入其中的科学原理。但我觉得理解这些很有帮助，就像你在做网易应用时了解数据库怎么工作会有帮助一样，因为在产品和运行框架层面，你做的越来越多的决定都会受到模型本身的影响。
我觉得对他们的工作方式有一些直觉，不管你做什么岗位，都会让你更有优势。今天我要讲的就这些，谢谢大家。