本文整理自 Lee Robinson 在斯坦福 CS146S 课程中的讲座《How Always-On Agents Work》（常驻智能体如何工作）。他目前在 SpaceX 负责模型行为实践，曾长期参与 Cursor Agent 团队的工作。
这场讲座讨论的是 Agent 设计中一个很实际、也很常见的问题：你合上电脑之后，Agent 怎样继续处理任务？它需要怎样的云端架构，怎样使用工具、保存记忆，又怎样在成本和安全之间做出合理的取舍？
斯坦福的教育资源确实让人羡慕：学生可以当面听一线研发人员讲他们正在解决的问题。
本场讲者 Lee Robinson 是负责 SpaceX 模型行为的实践者。今年的课表还安排了 Anthropic 的 Claude Code 创建者 Boris Cherny、Cognition 研究高级副总裁 Silas Alberti，以及 Cloudflare 高级总监 Rajesh Bhatia 等嘉宾。
能把这些来自头部 AI 公司和大型技术公司的专家请进课堂，让学生接触正在发生的工程实践，是 CS146S 这门课很值得关注的地方。
如果你对 AI、软件开发和智能体感兴趣，这段视频值得一看。它把模型能力、运行框架、云端电脑、上下文和记忆这些经常被分开讨论的概念，放进了同一个系统里解释。也可以先看原视频，再对照下面的中文整理和幻灯片截图阅读，会更容易理解这些组件为什么需要配合。
- 视频来源：Lee Robinson 在 X 发布的原始讲座视频[1]，演讲日期为 2026 年 10 月 8 日。
- 课程背景：Stanford CS146S — The Modern Software Developer（现代软件开发者），2026 年秋季课程，结合讲授、动手作业、项目和行业嘉宾分享，讨论 AI 时代的软件开发方法。
- 课程与学习资料：课程网站与公开课表[2]；斯坦福课程目录中的 CS146S[3]。
以下为 Lee Robinson 的演讲文稿中文整理（约 8500 字）。
今天我们来讨论一类新的智能体（Agent）：它们能够长期存在，主动处理任务，并在你离开之后继续工作。我想解释，构建这样的智能体需要哪些基本组件，以及模型、运行框架和产品怎样配合。今天讲到的一些内容，是我们在 SpaceX 仍在开发中的工作。
笔者注：Lee 提到的新智能体，其实指 Grok Bot、Meta 的 Muse、OpenAI 的 Dot 这类云端 Agent。
课程第一周，你们已经搭建过一个简单的运行框架，也就是 harness。它的核心很容易理解：模型在一个循环里调用工具，读取结果，再决定下一步做什么。
CS146S 在前一周的课程，就是让学生实现一个简易版 Coding Agent。
这个循环很强大，但如果它只运行在你的终端里，就会遇到一个直接的问题：你合上笔记本电脑，进程就停止了。
常驻智能体把这个思路扩展到了服务器和云端。你关上电脑，它仍然可以继续工作；进程遇到故障，系统可以恢复。它还可以拥有一台云端 Linux 电脑，在上面使用文件、浏览器和桌面应用，逐渐积累对你的了解。
它与你协作的方式，也更接近一位同事（Coworker）。有时它只需要在后台做事，等到有重要进展，再来告诉你。唤醒它的可以是你的消息，也可以是一封邮件、一条 Slack 消息，或一项定时任务。
这里的“常驻”，说的是状态能够保留下来、任务能够继续、系统随时可以被唤醒。空闲时，相关进程和电脑可以休眠。 我们希望这类智能体最终能持续处理几周甚至几个月的工作，而这需要一套不同的架构。
终端智能体与常驻智能体的区别。
一、开发者与 AI 协作，怎样走到常驻智能体
到目前为止，开发者与 AI 协作大致经历了四个阶段。
最早，我们把 ChatGPT 生成的代码复制出来，粘贴进编辑器。现在回头看已经过去很久，其实也就是几年前。
后来，模型开始能够配合简单运行框架，自己编辑文件、执行 shell 命令。开发者可以直接在终端里与它协作，让它完成更多实际工作，比如 Cursor 的 Tab AI 补全。
再往后，编程智能体有了专门的应用。人们开始并行运行多个智能体，有些放在云端。但用户仍然是整个过程的瓶颈：你要检查它们执行的命令，逐条批准，始终参与每一步。
现在，随着模型、运行框架和产品的改进，我们进入了第四个阶段。智能体拥有自己的电脑、记忆和技能，可以在后台工作，在你睡觉或处理其他事情时继续推进任务。
AI 辅助开发的 4 个阶段。
这种变化也改变了人的角色。以前，你输入提示词，等智能体完成；再输入下一条，再等。如果它想执行命令，你还要批准或拒绝。
现在，你可以在它工作的过程中持续引导它。比如先说：“去看看这个讨论。”随后又补一句：“哦，其实周四再做这件事。”
过去的模型可能会被这种中途插入的指令弄糊涂。现在，模型和运行框架越来越能理解这些消息之间的关系，就像朋友能理解你聊天时临时改变主意一样。
不过，把更多工作交给智能体，仍然需要检查。比如它要发送邮件、发送 Slack 消息，或者执行 shell 命令时，可以由另一个独立模型审查这些操作，这就是自动审查。
我认为，对着几百条命令逐条审批的人很容易疲惫，而模型在这类检查中往往能表现得更好。这是我对自动审查能力的判断，也正是我们把它放进运行框架的原因。
智能体持续工作，用户在过程中调整方向。
这里有个看起来有些反直觉的变化：模型越强，产品界面反而可以越简单。我们对这种常驻智能体的实现叫作 Bot。
与它协作的感觉，越来越像给朋友或同事发消息，但它会实际执行任务，而不只是回答问题。
二、模型发生了哪些变化
让这种产品成立的，不只有模型变得更聪明，还有一些更具体的能力变化。我想介绍其中六项。
第一，模型更能长时间遵循指令。 过去一两年，模型在这方面进步很大。配合合适的上下文压缩，它们已经可以连续运行几个小时，甚至几天。上下文压缩，就是对越来越长的对话做摘要，尽量保留后续工作需要的信息。
第二，模型可以把工作交给助手。 这些助手也叫子智能体。主智能体的上下文窗口，可以理解为它当前的工作记忆，空间总有上限。子智能体拥有新的上下文，可以去处理大量工具调用，再把结果带回来。这让产品能够承接更长的任务，但模型本身的上下文窗口仍然有上限。
第三，模型更擅长使用实际工具。 几年前，模型调用工具时常常出错，甚至会编造一些不存在的东西。在我看来，这类工具调用中的幻觉问题已经大体上得到解决。现在，我们不仅能让它执行命令、处理文件，还能给它更强的工具。
第四，模型能够使用一整台电脑。 它可以在 Linux 电脑上打开浏览器、点击屏幕，像人一样使用应用。这就是 computer use。对于没有 API 或 MCP 接口的网站，这提供了另一条完成任务的路径。
第五，模型可以把知识保存在文件里。 它们很擅长读取文件、搜索文件，之后可以再把需要的信息找回来。
第六，模型可以从演示中学习。 你向它展示一项工作怎么做，它可以把过程整理成技能、记忆或例行任务，供以后复用。
模型为常驻智能体带来的六项新能力。
把知识和工作方法写进文件
文件这一点，值得再展开一下。
我们可以逐渐形成一份用户资料，记录与这个用户协作时需要知道的事实。比如用户喜欢用全小写的文字发消息，这个偏好就可以放进每一次提示词里。
我们也可以保存带日期的工作日志。就像一位同事每天记下自己做了什么，这些日志能够在以后被搜索。如果你问：“我上周都做了些什么？”智能体就去查相关记录。
技能也是文件。你把完成某项任务的方法写进一个 Markdown 文件，说明具体步骤，以及什么会让任务成功、什么会让它失败。比如怎样写一封好邮件，或者怎样设计一个 API。
现在已经有公司和开发者在分享这样的技能。比如，GrokBot 有插件系统，可以通过插件接入工具、技能或服务器。
另外还有例行任务。如果你熟悉 cron 定时任务，可以把它理解成：按照某个时间安排，运行一段提示词。
这样，用户资料、日志、技能和例行任务都能用文件表达。模型既能读取，也能搜索和更新；需要什么，就去取什么。
智能体的知识和工作方法可以存放在文件中。
三、一个常驻智能体的内部是什么样的
空闲时休眠，有事件时唤醒
先看智能体的一次工作过程。
空闲时，智能体的计算进程可以停止，它所使用的电脑也可以休眠。你发来一条消息，或者某个事件触发任务，系统就加载保存的状态，启动智能体。
如果这次任务需要用浏览器、点击桌面，才把那台云端电脑启动起来。工作完成后，它们又可以休眠。对话记录、记忆、例行任务等状态保存在数据库和存储系统里，下次继续使用。
这样做有一个很实际的原因：给每个人分配一台始终开着的电脑，成本太高，也会消耗大量服务器资源。
笔者注：这也是为什么现在 Agent Sandbox 成为最火热的投资领域。财大气粗的 Meta Muse 确实给每个用户 Agent 分配了一台规格不错的电脑。
触发器（Trigger）、智能体进程、云端电脑和持久化状态。
唤醒智能体的，不只有用户直接发来的消息。有人在 Slack 上 @ 你、一通电话、一场会议、后台任务完成，或者定时任务到点，都可以成为触发条件。
在 SpaceX，我们看到越来越多员工让自己的 Bot 代为参加会议。员工并非没有时间参会，只是希望 Bot 负责记笔记，然后回来汇报。
这些事件会先经过路由，进行去重，进入合适的对话，再由规则判断“现在需要告诉用户吗？”
假设一位同事每取得一点进展，就跑来找你说“快看，我又做完了一点”，你可能会觉得很烦。有些任务一天汇报一次就够了。智能体也需要判断哪些进展值得打扰你。
运行智能体的服务器，和执行操作的电脑
我们为智能体提供的 Linux 电脑，运行在 Firecracker 虚拟机上。它很适合这种场景，因为可以保存快照、关闭机器，再恢复。
这台电脑可以处理文件、执行命令，也可以运行 Chrome 和虚拟桌面。你能够连接进去，实时查看，必要时亲自操作。如果同时运行五个或十个 Bot，每个都需要浏览器，还可以为它们安排不同的屏幕。
文件、命令、浏览器和虚拟屏幕，以及休眠与恢复。
把系统拆开看，大致有三个部分：左边是应用和消息入口，中间是运行智能体的服务器，右边是供智能体操作的电脑。
服务器上的核心仍然很小：接收消息，把消息放进队列，让模型循环调用工具，随后保存状态。但把它接到不同的服务上，提供文件、浏览器等工具，就能构成一个很强的产品。
应用入口、智能体服务器（Agent Loop Server）和操作电脑（Agent Computer）分别承担不同职责。
这是一种“瘦客户端、厚服务器”的架构。客户端主要负责与用户交互，较重的计算和智能体逻辑放在服务器上。
服务器代码可以快速更新，不必每次都等应用商店发布。语音转写、图像生成等计算，也可能更适合放在服务器上，当然还要看具体设备。面对增长和流量波动，我们也已经比较熟悉怎样扩展服务器。
更关键的是，智能体循环（Agent Loop）与它操作的虚拟机（Agent Computer/Sandbox）要分开。 如果把循环也放进那台虚拟机，就很难关掉电脑，同时让智能体继续运行。
比如，需要给虚拟机安装一个 Linux 零日漏洞补丁时，我们希望能够 reboot 虚拟机，同时保留智能体的循环和状态。把状态保存在服务器和存储系统中，就为这种重建提供了基础。
为什么需要持久工作流
用户点击发送之后，客户端先确认消息，服务器开始一轮处理，让模型调用工具，并把结果存进数据库。客户端订阅变化信号，有更新时再获取新信息。系统还需要去重，避免重试让同一条消息出现多次。
如果进一步深入，就会涉及强一致性、最终一致性，以及任务队列与持久工作流的区别。
举个例子：智能体处理一项复杂任务，做完第一步、第二步，进行到第三步时，基础设施出了故障。普通队列重新启动后，可能要从前面的步骤重新执行。
持久工作流则保存了执行进度，让任务能够从第三步继续。
我们使用了 Temporal 这个开源工具，复用它在这类问题上的能力，而不是从头重建所有机制。当然，相关基础设施仍然需要自己运行。
笔者注：Temporal 是一个开源的工作流编排平台和持久化执行引擎。最近 Pi 引入 Durable，也是为了让 Agent 运行更加稳定和可恢复。
发生故障后，持久工作流可以利用已保存的进度继续。
消息进入系统时，还要考虑优先级。
用户直接对自己的智能体说“其实，把这个活动的日期改一下”，我们希望先处理这条修正，必要时暂停当前循环。而其他人的群聊消息、Slack 消息或后台例行任务，可以先排队。
短时间内连续收到三四条消息时，也可以把它们合并成一轮处理。具体采用什么规则，需要根据产品决定。
四、运行框架怎样组织工具和助手
用一个接口向用户传递信息
在这套架构里，客户端与服务器之间用于传递信息的工具，只有一个，叫 SendToUser。
这里说的“一个工具”，指的是与用户交互的通信接口。服务器上仍然有很多工具，可以执行 shell 命令、读取文件、调用云端智能体、录制屏幕或制作演示。
手机应用、桌面应用、邮件和 Slack，都可以使用同一套通信方式。这样，我们不必为每一种客户端重建一整套复杂的工具逻辑。
客户端收到信息后，可以选择合适的交互界面。如果用户需要登录服务，就显示登录表单，并接入 1Password 这样的工具；如果需要支付，可以使用 Stripe Link、X Money 等服务。
如果智能体准备发送一封邮件或一条 Slack 消息，可以先呈现草稿，让用户编辑并批准。有时，只用一个表情回应就够了，不一定要再发送一条消息。
服务器上的工具通过 SendToUser，把合适的信息交给不同客户端。
工具详情只在需要时加载
每个工具都有名称、参数格式，也就是 schema，以及描述和使用细节。它们都会占用上下文。
如果安装了 Google Drive、Gmail、YouTube 等连接器，把对应 MCP 服务器提供的所有工具定义一次性塞进提示词，就会占掉大量空间，留给实际任务和对话的空间反而变少。
所以，现在很多运行框架使用动态工具发现，也有人把它叫作“工具搜索工具”（Tool Discovery Tool）。先让模型知道有哪些工具名称，需要调用某个工具时，再读取相关定义和说明。
这些说明也可以保存在文件里。模型知道自己需要什么，再去取什么，减少不必要的上下文占用。
先提供工具名称，按需加载详细定义，为实际任务留下更多上下文。
选择工具时，可以先尝试成本较低、较可靠的办法，再逐级向上：
- 先看对话中已有的信息，能不能直接完成任务。
- 再看插件、MCP 或 API 能不能提供信息，比如通过 Plaid 获取银行信息。
- 如果还不够，就进行网页搜索，比如查昨晚小熊队的比赛比分。
- 必要时进入电脑，使用浏览器。
- 再进一步使用整个桌面，运行脚本、命令，或构建需要的东西。
- 如果这些办法仍无法解决，再请求用户提供帮助。
图中还提醒：连接器失效时，应告知用户并询问，不要绕过连接器改用浏览器。
从已有信息、API 和搜索，逐步走向浏览器、桌面和用户协助。
使用浏览器时，也可以选择更省资源的方式。模型不一定每次都需要看截图；读取 HTML 或无障碍树，往往就能找到按钮、链接和输入框，减少 token 消耗。
如果页面结构不够用，它仍然需要具备看截图、按像素点击的能力。遇到双重验证或人机验证等障碍，则可能需要用户介入。
这个阶梯描述的是怎样获取信息、完成任务。对于需要授权的操作，仍然要遵守审批要求。
让主智能体保持轻量
主智能体负责与你对话、协调工作，它的上下文应尽量精简。
如果一项任务需要大量 shell 命令、昂贵的工具调用，或大量截图，可以交给一个助手（helper，也可以理解为 subagent）去做。
助手完成工作后，把结果带回来，而不是把全部中间过程塞进主智能体的对话。这样，用户会觉得产品能够承接很长的对话与复杂任务。
但“无限上下文”并不真的存在，每个模型的窗口都有上限。我们是通过任务分工和上下文管理，减少用户频繁碰到这个上限的情况。
不同助手可以有不同的能力，也可以分别运行在自己的持久工作流中。比如视频助手崩溃了，或者内存耗尽，它可以恢复并继续之前的工作。
主智能体则像一个管理待办清单的同事。你可以查看助手的进度、发消息调整任务，也可以停止它们。很多设计都借鉴了一个工程师团队怎样分工解决复杂问题。
助手承担具体工作，主智能体接收结果并协调进度。
设计工具时，我们还发现了一些小细节。
首先，尽量不要在一轮执行过程中随意新增或删除工具；工具描述和 schema 也应尽可能精简。
其次，虽然一个执行 shell 命令的工具可以完成很多事，但如果模型 90% 的时间都在用 shell 做同一种操作，专门为这项操作提供工具，可能更高效，也更方便人检查。
最后，错误提示要告诉智能体下一步怎么办。就像写给人的错误信息一样，“哪里失败了”、“接下来该做什么”，比只有一句“发生错误”更有帮助。智能体工具同样需要考虑开发者体验。
隔离电脑之外，还要有安全机制
把智能体放在一台独立电脑上，不会直接影响你的笔记本，但这并没有解决所有安全问题。
执行 shell 命令之前，仍然可以用独立模型做自动审查。邮件、网页或 webhook 里的内容，也需要保留来源边界。比如一封钓鱼邮件不能因为被模型读到了，就自动变成用户的指令。
提示注入防护还有很多工作需要做。对于发邮件等不可撤销的操作，应先询问用户。密码也可以通过专门的产品流程处理，不进入模型的对话。
智能体要长期替你工作，用户必须能够信任它怎样处理信息、怎样采取行动。
自动审查、输入来源、用户批准，以及对秘密信息的隔离。
五、上下文工程怎样降低成本并保留记忆
上下文（Context）工程，也有人叫 Harness 工程，讨论的是同一个基本问题：怎样让模型拿到完成任务所需的信息，同时尽量减少不必要的上下文占用。
尽量保持提示词的开头不变
使用智能体时，每增加一条消息，通常都要把此前的对话再次发给模型。如果这些重复内容能够命中缓存，价格通常会比未缓存的 token 便宜很多。
因此，我们希望工具定义、系统提示词等稳定内容，在不同调用之间尽量保持不变。把稳定部分放在前面，新的消息放在后面。如果稳定前缀持续命中缓存，重复内容享受缓存价格，只有新增消息需要按未缓存 token 的价格计费。
稳定前缀、不断追加的历史，以及最新消息。
主智能体承担与你长期交流的任务，因此更需要保持上下文精简。
特别长的工具输出可以写进文件，让模型需要时再读取。截图和其他开销大的工作，可以交给助手，只把结果带回来。
对话不断推进时，也要整理、修剪不必要的内容。这既影响成本，也影响模型能否找到真正需要的信息。
长输出进文件，重任务交给助手，主对话保留必要信息。
对于这种长期运行的产品，我会把不必要的缓存未命中（cache miss），视为值得排查的缺陷。
今年一月，OpenClaw 开始受到大量关注，人们通过模型提供商的订阅套餐使用它。这是一种新的使用方式，提供商和运行框架此前还没有充分为它优化，因此出现了很多缓存未命中。对持续工作的智能体来说，这会带来明显影响，需要工程修复。
有几个小技巧可以帮助排查和改善。
让提示词中各部分的顺序尽量固定；做系统提示词修改或 A/B 测试时，避免把其他本来稳定的内容也打乱。可以为各个部分计算哈希，用它检查哪一段发生了变化。这里的哈希可以理解为内容的指纹，便于定位变化。
当用户打开聊天窗口，或开始输入时，服务器还可以提前准备提示词，给缓存预热。这有点像网站在你把鼠标悬停到链接上时，就预先获取下一页。
笔者注：这里的工程小技巧确实不错，Lee Robinson 也提到了 Agent 就是各种工程上的优化。
很多这样的细节叠加起来，会影响 token 消耗，也会影响模型长时间工作时的表现。
稳定顺序、分段检查变化，以及提前准备提示词。
趁缓存仍然有效时做摘要
对话再怎么精简，也总会变长。比如模型有 20 万 token 的上下文窗口，一直聊下去，最终仍然需要做摘要。
这里的上下文摘要是有损的，会丢失一些信息。怎样压缩，又不丢掉重要细节，是一个很难的问题。我甚至觉得，它足够成为一项完整的博士研究课题。
举个例子：你与 Bot 已经交流了十多万 token，然后离开去做别的事。模型提供商会有一个缓存有效的窗口，可能是 10 分钟，也可能是 60 分钟。
一个有用的技巧，是在缓存还有效时就进行摘要。由于这时长对话仍然命中缓存，做这件事会便宜得多。等你 30 分钟后回来，再从摘要继续对话。
这不是说每隔固定时间就必须压缩，而是利用提供商的缓存窗口，在合适的时机处理长对话。与此同时，摘要的质量仍然必须做好。
趁缓存还有效时总结，下一次从摘要继续。
把记忆分成不同层次
智能体的记忆可以分成几层。
有些是每次都需要带上的核心事实。比如用户喜欢全小写文字，智能体就应该持续遵循这个偏好。否则，大多数消息都用小写，突然有一条出现大写，会显得很奇怪。
其他事实，则要根据当前相关性和重要性取舍。这个过程有点像垃圾回收，也有点像我们的大脑：眼下重要的信息留在工作记忆里，其他信息并非忘掉了，而是等需要时再找回来。
此外，还有带日期的日志，记录过去做过什么；以及一些临时笔记，只与接下来半小时或一小时的工作有关。
剩下的内容放在文件中，需要时检索。模型擅长运行命令、读取和搜索文件，这让它不必把全部历史都塞进每一条提示词。
核心资料、日志、临时笔记，以及按需查找的信息。
六、模型和产品接下来怎样一起进步
训练模型，让它更会使用产品
先简单回顾一下大语言模型的训练过程。
预训练让模型从大量文本和其他数据中，形成对世界的一般理解。监督微调，也就是 SFT，教模型按某种方式行动，比如成为聊天助手或智能体。强化学习，则让模型在具体任务中不断改进表现。
对于常驻智能体，SFT 阶段可以让模型看到运行框架的实例，学习有哪些工具，以及怎样在这个框架中工作。
强化学习可以进一步训练它遵循指令，从数百项技能中选择合适的一项，或者在浏览器里判断该点击哪里。
产品中的不同角色，也需要不同的优化目标。主智能体与你对话，最好能快速回应，因此要优化延迟。但一个助手要执行很长的任务时，花 10 分钟还是 12 分钟，差别可能没有那么重要。我们可以根据这种差异，调整模型服务和运行框架。
预训练、监督微调和强化学习，以及主智能体与助手的不同优化目标。
产品与模型之间，有两个改进循环。
内循环发生得很频繁。假设智能体调用了一个不该调用的工具，我们就把这个错误变成一项评测。接着修复运行框架、提示词、程序缺陷，或者模型推理方面的问题，再通过评测确认修复有效，最后发布改动。开发这些产品的团队，几乎每天都在进行这样的工作。
外循环则涉及新模型。每隔一个月、几个月，或者一段时间，我们训练新的模型。理想情况下，它们会从此前的错误和失败中学习。把新模型放进产品后，还要检查，它是否真的在我们关心的任务上变得更好。
当新模型带来新的能力，产品也可以出现新的使用方式。比如，让多个 Bot 在群聊里协作，就是一种正在探索的用法。它也可能出问题，需要训练模型在多智能体环境中采取合适的行动。
产品团队和模型团队，就是在这些内循环与外循环中不断合作。
日常修复产品的内循环，与训练新模型的外循环。
随着模型进步，移除不再需要的产品结构
在 Cursor 工作时，以及现在在 SpaceX，我们有一个原则，叫“删掉产品”。
我的意思是，我们要以这样的假设来构建：今天的模型，是未来这些版本中最差的一代。随着模型进步，六个月以后，你可能需要重做用户界面，把过去为了弥补模型能力而添加的结构移除。
今天讲的很多设计，如果放到六个月前，甚至一年前，都可能很不一样。因为我们已经学到了新的运行框架设计和上下文工程方法。
因此，一个值得考虑的策略，是为下一代模型构建产品：怎样尽可能少做一些东西，仍然让产品有效运行？怎样给模型一个简单的交互方式，让它能替用户思考和行动？
对于演讲之后的六到十二个月，我有几个判断，但仍然需要观察。
我认为，智能体持续工作的时间，有可能从几个小时或一天，延长到几周甚至几个月。它们也会更擅长从过去的对话里找到需要的信息。记忆的底层表示，可能是文件，也可能是图，或其他形式，这里仍有很多研究空间。
它们可能拿到更多工具，就像给一位真正的新同事配置工作环境一样。组织也需要逐渐适应这种方式。
交互界面可能会继续简化。有些人会更喜欢直接与智能体进行语音对话。也许会有像 Jony Ive 参与设计的设备那样的新入口，但这是我对未来交互的设想。
我还认为，模型和产品会越来越擅长在工作中学习技能，再把技能保存为文件和指令。人和公司，也会越来越善于把自己的工作方法写下来，让智能体读懂并使用。
更长的任务、更好的记忆、更多工具、更简单的界面，以及在工作中学习技能。
还有哪些问题没有解决
其中一个很难的问题，是长期任务的评测。如果智能体需要运行一个月，模型却每个月发布一次新版本，那么在下一个版本出现之前，你怎样完整评测这一代模型？
你要么找到更好的评测方法，要么就不能这么快发布。这是我认为整个行业需要面对的问题。
记忆和安全也还有很多工作：怎样记住正确的信息，怎样保护运行框架和周围的基础设施，怎样防止恶意输入接管智能体。
还有一个产品问题，是智能体什么时候保持安静，什么时候来打扰你。我们尚未把这件事做得很完美。
比如它主动告诉你：“我发现你昨天没有来上课，我有录音，也做了笔记，这是整理好的内容。”这可能非常有帮助，也可能让人觉得烦。产品要找到合适的分寸。
幻灯片中还列出了多个智能体共享电脑和记忆时的协调，以及长期运行的成本。随着越来越多智能体持续工作，我认为，未来世界里流动的 token 数量会显著增加。优化模型、推理和运行框架，让 token 使用得更高效，也会越来越重要。
长期任务评测、记忆、安全、打扰时机、协调与成本。
新产品需要的基础组件
有人说，现在很多应用看起来都一样：有一个侧边栏、一个智能体、一个聊天框。
我在 X 上看到过一个很好的回应，如果没记错，是 OpenRouter 的 Alex 提出的：这有点像 2005 年，很多网页应用也都有服务器、数据库和用于增删改查的界面。相似的组件，并不意味着产品只能做同一件事。
在我看来，今天讲到的这些东西正在变成新一代产品的基础组件：持久工作流、沙箱、云端电脑、记忆、技能、服务连接器，以及语音、支付、身份、评测和可观测性。
在我看来，每个新产品都将需要某种智能体能力：要么把它整合进去，要么成为供其他智能体使用的数据，不再需要独立的操作界面。这些组件怎样组合，仍然有大量可以探索的空间。
从传统网页应用的组件，走向智能体产品的更多基础组件。
最后，我想留下三个建议。
第一，作为工程师，仍然要认真理解系统架构。 代码越来越容易写出来，但架构决策的影响会不断累积。我自己仍然会读代码，尤其是为了理解最终发布出去的系统到底怎样工作。
第二，亲手做一个版本。 你们已经在课程中搭建过基础运行框架，可以尝试把今天讲到的方法加进去：服务器、沙箱、虚拟机、记忆、助手，以及适合自己的交互界面。亲自组合这些组件，会帮助你理解它们。
第三，不要回避学习大语言模型的工作原理。 并不一定要深入所有机器学习研究，但就像开发网页应用时，了解数据库很有帮助一样，理解模型也会影响你的产品和运行框架决策。
对模型怎样工作形成一些直觉，会让你更清楚自己能够构建什么，也更清楚哪些问题还需要解决。
谢谢。
引用链接
发表于 昨天 20:42
|
查看: 10|
回复: 0
