在斯坦福大学 CS146S 课程的一堂讲座中，曾在 Cursor 任职、目前在 SpaceX 的 Lee Robinson 分享了团队构建 Grok Bot 的工程经验。Grok Bot 是一种常驻 Agent：用户交代目标后，它能在云端推进工作，也能被消息或定时任务唤醒，不必每一步都等着用户发提示词。

学生上一周搭建的简单 Agent，则是让模型在一个本地运行框架（Harness）里循环调用工具、读取文件和执行命令。如果本机进入休眠，或者终端里的进程被关闭，工作就无法继续；需要人批准的操作，也会停下来等待。对话变长后，工具输出还会不断占用模型能同时处理的信息空间。

常驻 Agent（Always-on Agent）试图解决的正是这类使用断层。它希望让 Agent 像一位能够长期协作的数字化同事一样，在云端拥有一台属于自己的电脑与独立环境，能够根据外部事件在后台自主推进任务，并在必要时才向用户汇报。

这是一次系统构建经验分享，部分能力仍在开发；稳定工作数周甚至数月，是 Lee 对后续发展的期待。要将原型脚本演进为稳定可靠的常驻服务，核心在于一系列具体的分布式系统设计、操作安全策略与上下文工程取舍。

把任务交出去后，你仍然能随时改主意

Lee 用四种开发方式说明这种变化：

1. 复制粘贴阶段： 在网页中向模型提问，手动复制代码到本地编辑器，遇到报错再贴回浏览器。
2. 终端 Agent 阶段： 模型进入本地循环，能够自主读写文件与运行终端命令。但这一阶段人类需要逐条确认模型生成的 shell 命令是否允许执行。
3. 专用并行应用阶段： 出现专门针对 Agent 任务的界面，可以在后台或云端并行启动多个任务，开发者在完成时审查代码差异（Diff）。
4. 常驻 Agent 阶段： 用户通过即时通讯或轻量消息向 Agent 交代高层目标。Agent 在云端拥有自己的环境、长期记忆与工具接口，能在用户离线后继续推进，并由外部事件（如日程、Webhook、协作消息）按需触发。

Lee 将这类产品的发展与模型能力的提升联系起来：模型更善于在较长时间内遵循复杂指令，还能将子任务委派给独立的助手；除了调用结构化 API 与终端命令，也逐渐掌握了直接查看屏幕和点击的电脑操作；同时，模型能够将用户画像与规程以文件形式自主读写，并从人类的操作示范中学习技能。这些底层能力的成熟，让长周期后台执行具备了实际可行性。

协作方式改变的关键，在于交互频次与控制权的分工。在传统终端模式下，模型每执行一条命令都需要等待人类授权；而在常驻模式下，Agent 在后台持续执行指令，人类主要负责在关键节点校准方向。例如在 Agent 执行过程中，用户可以随时发送补充消息：“顺便看一下那个讨论串”、“把时间改成周四”、“草稿整理好后直接发日程邀请”。

伴随这种交互方式的，是一项关键的安全机制——自动化审查（Auto Review）。当 Agent 需要在后台执行大量命令时，逐条让人眼审查容易引发审批疲劳。工程上引入了一个独立的安全审查模型，在具有潜在风险的命令执行前对其进行实时校验。如果安全模型判定某项操作存在风险并拦截，系统会向用户弹出明确的审批请求；在讲座介绍的原型设计中，如果用户在 15 秒内未作答复，该操作默认继续保持阻止状态。

常驻不等于一直开机：任务和电脑分开运行

许多刚接触这一架构的开发者容易产生一种直觉：既然 Agent 需要运行命令和浏览器，直接在云端开一台虚拟机，把模型对话循环和桌面环境全放在里面不就行了吗？

在真实的工程运维中，这种紧耦合会导致明显的系统脆弱性。如果虚拟机因为底层操作系统补丁需要重启，或者浏览器在测试过程中占满内存崩溃，运行在其中的 Agent 进程也会被中断。此外，让一台配置完整的图形虚拟机为了等待定时器或仅仅处理纯文本而 24 小时通电开机，会产生大量不必要的闲置计算成本。

因此，Grok Bot 采用了三层解耦的系统结构：

手机和网页负责收消息、显示结果

支持手机 App、桌面客户端、网页、Slack、邮件和语音通话等不同接入方式。客户端主要负责呈现交互界面与收集用户输入，不做重型业务计算。业务逻辑交由服务器托管后，新特性的部署无需苦等移动应用商店的审核周期。

服务器负责推进任务、保存状态

常驻服务器是系统的核心调度中枢：

• 路由（Router）与会话队列： 负责接收来自客户端、定时调度或外部 Webhook 的唤醒事件，完成消息去重，并维持单一会话同一时间只运行一个推理轮次（Turn）。
• Agent 核心循环（Agent Loop）： 负责组装提示词上下文、请求模型推理并分发工具调用。
• 持久化数据库与存储： 记录完整的会话历史、长期记忆、技能文件与待办状态。关键数据均持久化在服务器端，即便云端执行环境损坏或重建，任务与记忆也不会丢失。

云端电脑负责实际操作文件和浏览器

每个用户对应一台基于轻量级虚拟机（如运行 Debian Linux 的 Firecracker microVM）的隔离沙箱：

• 按需分配虚拟屏幕： 虚拟机内置虚拟显示服务与 Chrome。当主 Agent 唤醒多个助手并行处理不同网页时，系统可以为每个活跃助手分配独立的虚拟显示屏幕，互不干扰。
• 空闲快照与按需唤醒（Snapshot & Sleep）： 云端电脑按需工作。在工具调用结束几分钟且无新操作后，系统会将必要文件同步至云存储，并为虚拟机的内存和磁盘生成快照，随后停止虚拟机以降低闲置开销。当后续工具需要运行本地脚本或操作浏览器时，系统再从快照加载恢复，已安装的工具与浏览器登录状态依然得以保留。

这种三层解耦将运行时的事件生命周期完整串联起来。常驻并不意味着大语言模型 24 小时持续思考，也不意味着云端机器一直在后台通电运转，而是依靠事件按需触发：

1. 事件触发与加载状态： 用户发来消息或定时日程（如早晨 8:00 的例行任务）到达时，触发事件启动 Agent 进程，从服务器数据库与存储中加载持久化状态（会话历史、长期记忆、技能文件与待办事项）。
2. 按需唤醒电脑与逐步保存： Agent 进程执行一轮推理与工具调用，每一步的执行结果即时写入数据库。若本轮任务不需要操作桌面或浏览器，云端电脑继续保持休眠；只有工具调用确实需要运行本地脚本或打开网页时，才按需唤醒虚拟机。
3. 空闲退出与恢复： 当前轮次完成且无新操作后，Agent 工作进程可以结束；云端电脑没有进行中的任务且空闲后，也可以保存快照并休眠。直到下一次外部事件到来，系统再次从保存的持久状态中恢复现场。

没有新事件时，相关 Agent 工作进程可以停止；关键状态保存在服务器端，下次触发再恢复工作。

换设备、遇故障，工作怎么接着做

当 Agent 运行在云端时，必须解决两个经典问题：用户在手机和电脑之间切换时如何看到相同的状态？服务器在执行长任务过程中遭遇网络抖动或重启，如何避免重复产生外部影响？

手机发的消息，电脑怎么同步看到

许多人好奇，当用户在手机端点击发送后，系统内部究竟经历了什么，才能让桌面端也实时显示出一致的状态？消息的同步过程可以拆成五步：

1. 发送与本地生成 ID： 用户在客户端输入消息并点击发送，客户端立刻在本地为该消息生成一个全局唯一 ID，并直接在界面上呈现出来，提供即时响应。
2. 服务端去重与会话队列： 消息进入服务器路由。服务器通过唯一 ID 检查是否已处理过该请求，直接丢弃任何重复收到的消息 ID，以保证网络重试时的安全性；随后将消息推入对应会话的队列中，按次序每次只运行一个轮次。
3. 轮次执行与数据库持久化： Agent 循环按需发起模型推理并调用工具，执行过程中的每一个步骤都即时写入数据库。
4. 轻量变更信号广播： 服务器向用户所有打开的客户端发出“数据已变更”的通知。这个通知信号本身不携带具体的消息内容载荷。
5. 按序号更新与缺漏拉取： 每个更新都有自增序号（例如 41、42、43）。各客户端收到信号后，取回新消息并按序号更新界面。如果某个客户端发现收到的序号出现跳跃（例如收到了 43 但缺少 42），它会自动触发重新从数据库读取。由于权威数据始终保存在数据库中，偶发的信号通知丢失不会破坏最终的数据一致性。

第三步失败了，别把前两步再做一遍

如果任务队列在故障后只是把整个任务重新入队，执行就会从第 1 步再来一次。

对照原始 PPT：持久工作流与普通任务队列的恢复路径（第 21 页）

假设一个任务包含多个阶段：第 1 步拉取外部数据，第 2 步处理并生成图表，第 3 步向协作平台发送总结报告。如果执行到第 3 步时节点网络超时崩溃，传统的“从头重跑”会导致第 1 步和第 2 步被重复调用，这在调用计费 API 或执行写操作时可能会带来非预期的副作用。

为了解决这个问题，架构中引入了开源的持久工作流引擎（如 Temporal）：

• 断点续跑： 工作流引擎将任务执行过程中的每一个步骤（Step）及其输入输出持久化在事件日志中。如果步骤 3 执行中途节点重启，系统恢复后可从步骤 3 继续推进，尽量避免重跑前两步。但这并不意味着工作流引擎能替所有外部动作自动保证绝无重复，具体操作仍需配合重试安全机制。
• 业务步骤需具备幂等性（Idempotency）： 持久工作流保存了进度，重试的业务步骤仍要能安全重复。底层业务代码中的每一个步骤仍然需要被设计为可安全重试的，确保同一操作即使因超时重试被执行了两次，也不会造成非预期的二次影响。

你的新指令优先，其他消息按顺序处理

当一个 Agent 既接入了用户的 1:1 私聊，又挂载在群聊、定时任务和后台辅助任务中时，消息可能同时到达。系统制定了清晰的优先级规则：

• 用户 1:1 私信拥有优先打断权： 如果用户在单聊界面发来修正：“把时间改成周四”，这条消息会跳过常规队列，向当前正在运行的轮次发送中断或暂停信号，让系统优先响应用户的最新指令。
• 群聊、讨论串与后台汇报进入常规队尾： 外部群聊消息、定时例行任务以及子助手完成任务后的汇报，一律在队列末尾按序排队。
• 短时连续消息合并（Batching）： 如果用户在短时间内快速连续发来几条简短补充（如“加上李四”、“还有王五”），路由器会将它们打包成一个批次，合并为单一轮次处理，避免系统为每句话频繁中断重启。

该自己做的自己做，该问人的才问人

一个成熟的协作工具不仅要能干活，还需要在交互上保持克制，避免用琐碎的中间日志频繁打扰用户。

干活和汇报，使用不同的工具

在整个 Agent 的工具箱中，存在着读写文件、执行 shell、操作浏览器等各种能力，但负责与用户直接通信的工具只有一个：SendToUser。

这种设计带来了几个关键的工程特性：

• 推导过程保持私有： 模型在内部推理、分析代码时的常规文本输出对用户默认隐藏，用户端界面不会被大量冗长的中间演算过程刷屏。
• 自主保持安静（Stay Quiet）： 当 Agent 被后台定时任务（如例行监控）唤醒后，它读取数据并评估发现没有值得汇报的重要变化，模型可直接结束本轮执行，不调用 SendToUser。在用户端看来系统保持静默，不会收到大量无意义的例行提醒。
• 配套专用的交互控件： 当调用 SendToUser 时，模型输出的不只是纯文本，还能驱动客户端渲染专门的交互卡片：
  • 登录表单： 与 1Password 等密码管理器集成。用户在弹出的专用登录表单中完成认证，密码直接注入对应环境，不流经大模型的提示词上下文。
  • 支付审批： 例如订购某项服务时（讲义中给出了为 Starlink Roam 支付 80 美元的示例），界面会唤起带有“允许 / 拒绝”按钮的独立支付卡片，未经用户点击确认前，支付流程处于挂起等待状态。
  • 邮件与外发确认： 发送重要外部邮件前，将完整草稿渲染在界面上供人类核对，由用户选择发送或丢弃。

读取外部信息时，还要分清资料和指令：来自邮件、外部 Webhook 或网页的内容一律被视为不可信来源，只能当作参考资料，绝不能自动升级为用户的执行指令；同样，系统先前保存的记忆也只能作为背景信息，不能拥有指令执行权限。尽管云端隔离的虚拟机和前置的风险自动化审查能够拦截一部分越权操作，但这并不意味着提示词注入防护已经完备。一旦网页或邮件中潜藏恶意诱导文本，模型依然可能受到误导。因此，密码绝不进入模型上下文、敏感支付与邮件外发必须经过人类显式批准，是系统保留的重要权限边界。

先用简单可靠的办法，必要时再操作电脑

面对一个具体的查询或操作需求，Agent 应该采用什么手段？工程上设计了一条由轻到重、由低成本到高成本的阶梯路径：

1. 第 1 级：上下文已有事实。 如果当前对话或已加载的画像中已包含答案，直接利用已有知识回答。
2. 第 2 级：结构化 API 连接器（如 MCP Server）。 若涉及日历或第三方系统，优先调用结构化 API 接口获取数据。
3. 第 3 级：常规网页搜索。 没有直连 API 时，调用轻量搜索引擎抓取公开信息。
4. 第 4 级：已登录的云端浏览器。 必须访问 SaaS 系统内部页面时，唤醒虚拟机中的 Chrome 浏览器，优先通过无障碍树（Accessibility Tree）或页面结构直接获取按钮与输入框信息。
5. 第 5 级：完整桌面像素级点击。 遇到没有完整 DOM 结构的桌面程序或系统弹窗时，再调用视觉模型截屏并计算鼠标坐标点击像素。
6. 第 6 级：向人类求助。 遇到双重验证码（2FA）、图形验证码（Captcha）或未授权操作时，主动停止并请求人工接管。

这里包含一条严格的工程准则：如果某个已有的 API 连接器出现故障报错，Agent 绝对不能自作聪明地偷偷绕道去用浏览器模拟登录！ 此时系统必须明确向用户说明连接器异常，并征询进一步处理意见。

工作越来越久，怎样不忘事、不烧钱

模型的上下文窗口是有限的工作记忆。如果将海量工具定义、长期历史记录与长篇命令行输出全部堆叠进每一次调用，不仅会导致计费成本上升和响应延迟增加，还会稀释模型的注意力。

要让 Agent 能够连贯运行数小时甚至数天，依赖的是一系列精细的上下文工程（Context Engineering）手段：

工具说明，用到时再读

随着系统接入的插件增多，如果把每一个工具完整的参数定义（JSON Schema）全部塞进系统提示词，有效工作空间会被严重挤占。

工程团队采用了一种轻量索引策略：系统提示词中仅包含精炼的工具名称列表。模型在思考过程中如果判断需要使用某个特定工具，再通过专用的工具检索机制从文件系统中按需读取该工具的详细参数结构。讲义中建议将单个工具的描述与结构尽量控制在 4000 字符以内，保持初始上下文尽可能简洁。

在工具设计上，团队还总结了两条实践经验：

• 频繁重复的 shell 操作封装为专用工具： 虽然仅靠一个通用的 shell 工具也能完成大部分操作，但如果观察到模型有大量时间都在通过命令行执行某类特定操作（例如保存状态），将其专门封装成独立工具不仅调用效率更高，也能让代码审查人员清晰看到系统状态的变化。
• 错误提示给出下一步恢复办法： 工具返回的报错信息如果直接写明后续如何处理，有助于 Agent 自行纠错。例如讲义中提到的一个具体设计：当虚拟机处于休眠而无法读取时，工具会明确提示“电脑在休眠，先用 Shell 或 Read 工具唤醒再重试”；这种设计帮助模型找到恢复路径，但这只是该系统特定环境下的处理方式，并非所有系统都采用相同的休眠与唤醒规则。

重活交给助手，主 Agent 接收结果

这是保持主 Agent 上下文精简的核心机制。

主 Agent 类似于负责统筹的任务协调者。当需要进行长篇代码分析、查看视频文件或抓取数十个网页时，主 Agent 不会在自己的对话循环里直接堆积这些操作日志，而是将包含完整任务描述的目标交给独立的助手（Helper Agent）。

每一个助手本身也是一条独立的持久工作流。如果视频助手在处理中途内存超限崩溃，或者云端代码环境发生异常，工作流引擎记录了步骤状态，恢复后可以从断点继续，避免长任务从头重做。

在推进过程中，主 Agent 维护着一份待办任务清单来跟踪分配出去的各项请求。主 Agent 可以随时查看某个助手的当前进度、给正在运行的助手发送补充消息，或者在必要时停止助手的执行。

助手拥有各自独立的全新上下文，在自身环境中执行完多轮命令、网络抓取或桌面交互后，仅向主 Agent 汇报一段提炼后的简要结论。庞大的临时命令行日志、中间调试堆栈与网页截屏都留在助手的独立环境中，从而让主 Agent 始终保持精简的上下文。这种分工机制让模型在感觉上能够承接远超单次上下文限制的工作量，而无需真正依赖无限上下文。

已读过的内容，尽量让模型复用

提示词前缀缓存（Prompt Caching）的作用是：如果多次请求开头的字符序列完全一致，这部分 Token 的计费会有明显折扣，且服务端处理速度更快。

在常驻系统中，前缀缓存失效（Cache Miss）需要作为缺陷排查：

• 结构严格固定： 系统提示词、基础核心记忆与工具名称按固定顺序排列，并可对各区块分别做哈希校验。在两轮交互之间，避免随意动态修改前面的系统措辞或增减工具。
• 增量追加： 对话历史仅向后追加，确保已匹配的前缀部分能够被服务商持续复用。
• 提前预热（Cache Warming）： 当用户在聊天框中开始输入时，服务器可以预先组装好前半部分固定的提示词向前置网关发起预热，提前进入缓存状态。

趁你离开时，整理长对话

对话不断增加，历史记录终会触碰长度阈值（讲座中以超过 10 万 Token 为例）。此时系统需要进行上下文摘要压缩（Compaction）。

传统的做法是在用户发送下一条消息时现场进行压缩，这会引发明显的等待。而常驻系统利用了用户离线时的缓存温存窗口：

服务商的提示词缓存通常具有一定的生命周期（Lee 举了 10 分钟、60 分钟等例子，具体取决于服务商）。当一轮长对话结束、用户暂时离开后，系统检测到模型服务商处的缓存依然有效，便会在后台主动触发一次压缩总结调用。由于历史前缀大都在缓存中，这次总结计算的开销相对较低。压缩完成后，系统保留对用户说的最后几条消息原文并结合紧凑摘要，等用户稍后回来发送新消息时，系统已就绪于提炼好的上下文之上。

对话摘要会丢失信息，如何缩短记录又保住重要细节，仍是困难的工程问题。虽然系统保留了最后几条与用户的对话原文，并将更早的完整记录存入可供搜索的文件，但这并不能等同于完整上下文永不丢失；哪些细节应该保留、以后怎样找到，仍需要设计。

长期偏好、过去工作和临时笔记分开存

用户偏好、工作记录和操作规范保存在可读的文件里，人和 Agent 都能搜索、编辑。这里有三种不同的用途：

• 记忆（Memory）： 负责记住“用户是谁”以及“过去做了什么”。例如用档案文件保存用户偏好，用带日期的工作日志记录已做过的事。
• 技能（Skills）： 负责用 Markdown 格式沉淀具体的工作方法、成功条件与失败注意点（例如讲义第 12 页示例中的 skills/linkedin-sourcing/SKILL.md 人才搜寻流程，或 weekly-metrics/SKILL.md 周度指标统计）。它把具体操作手册以纯文本保存在磁盘上，只有在遇到相关任务时才按需载入提示词。技能按需读取，不必把每份完整说明都塞进每轮对话；保存方法也不等于重新训练模型。
• 例行任务（Routines）： 则是将一段提示词与固定的时间安排绑定，例如早间简报（morning-brief 设置为工作日 8:00 运行）。

三者的配合十分紧凑：当定时任务在设定时间触发唤醒，Agent 先从记忆中读取用户的核心偏好与近期日志，再按需载入对应技能文件中的操作规程执行工具，任务完成后把最新结果写入工作日志。

针对记忆本身，系统在文件底层进一步划分为清晰的层级：

• 核心画像（Profile）： 记录关于用户的核心事实（讲义示例为最多 100 条事实，约 4000 字符内，例如用户的消息偏好风格），每次固定随系统提示词携带。
• 日期日志（Log）： 记录近期发生的历史事件，提示词中通常仅提取相关度最高的几十条（讲义示例约为 30 条）。重要事实权重更高，陈旧事实权重随时间自然降低。
• 临时便签（Notes）： 记录当前未完成任务的临时参数，生命周期较短，随后淡化。
• 长期归档： 完整历史保存在普通文件中，模型需要回忆时通过文件搜索工具按需调取。

对照原始 PPT：Agent 怎样记住信息（第 37 页）

在记忆更新机制上，系统每轮运行后会执行一次事实增补与过时事实替换，且更新逻辑只能剔除本次实际呈现的事实。关于用户的核心事实在多个 Agent 间共享，各 Agent 同时维护各自独立的工作日志文件。

在安全防护层面，系统通过提示词明确规范：记忆文件中的内容仅作为参考背景信息（Information），绝不能将其视作具有系统执行权限的指令（Instructions）。这是防范提示词二次注入的基本安全约束，但防御外部不可信输入依然是整个行业需要持续攻克的挑战。

出错后怎么改，还有哪些难题没解决

构建常驻 Agent 并非只靠编写提示词，而是依赖于内循环与外循环的双飞轮演进：

对照原始 PPT：产品内循环与模型外循环（第 40 页）

• 每日内循环（Inner Loop）： 当 Agent 在某个任务中出现错误（例如调错了工具或漏掉了操作），工程团队将其固化为一条可自动执行的测试用例（Eval）。工程师随后修补 Harness 代码、提示词或调整推理参数，通过评测后部署上线。
• 数月外循环（Outer Loop）： 产品与模型按下面的过程相互改进：
  • 评测驱动训练： 积累的高质量评测用例被用于训练下一代基础模型。通过监督微调（SFT）让模型熟悉 Harness 的工具格式、回复时机与理想输出；通过强化学习（RL）强化模型遵循长指令、使用技能与记忆、在图形界面中准确定位点击，以及与其他 Bot 协同工作的能力。
  • 新模型催生新用法： 当更强大的新模型部署回产品后，往往会激发用户全新的使用方式（例如在群聊中拉入多个 Bot 共同协作）。
  • 新行为产生新评测： 这些新使用方式又会暴露出前所未见的新行为与新问题，进而需要定义新的评测指标，再次驱动下一代模型的迭代。
• 模型分工调优： 系统对不同角色的模型推理进行了针对性调优。主 Agent 优先缩短用户等回复的时间，助手优先可靠完成长任务。两者可以采用不同的推理与 Harness 配置。

面对技术迭代，Lee Robinson 提出了一个在团队中推崇的架构原则：“时刻准备删除你的产品逻辑（Delete the product）”。

我们今天在模型外围编写的许多复杂检查、规则降级和脚手架，很大程度上是为了弥补当前这一代模型的不足。在进行系统架构设计时，应该假定未来的模型能力会持续提升，外围代码应尽可能保持精简；当新一代基础模型能够原生且稳定地遵循某项指令时，应果断裁撤曾经用于打补丁的冗余逻辑，用最轻薄的系统承接新能力。

持续工作数周，还要跨过哪些坎

Lee 对未来 6 到 12 个月的期待，是 Agent 能围绕一个项目工作数周甚至数月，拥有更可靠的电脑操作能力和更准确的记忆，并在工作中学会新的技能。这些是发展方向，尚不是产品交付保证。

界面也可能更简单：今天像发短信，之后可能更多用语音沟通。与此同时，人和组织需要把工作流程与专业经验写下来，让 Agent 能读取并使用。

要让这些长期任务稳定运行，仍有几个难题：

• 长程任务评测困境： 如果 Agent 承接的任务跨度从数小时延伸至数周甚至数月，而基础模型每隔一两个月就会迭代一次，现有的基准测试很难在模型发版前完整跑完多轮长周期端到端验证。
• 不可信输入的提示词注入： 当 Agent 拥有读取外部邮件、处理 Webhook 和浏览任意网页的权限时，网页或邮件中的恶意文字可能诱导 Agent 执行错误操作。目前的防御策略仍处于初期探索阶段。
• 多 Agent 共享资源协调： 多个 Agent 共享同一台云端电脑的虚拟桌面和同一个记忆文件库时，会面临经典分布式系统中的并发读写与状态一致性挑战。
• 记忆的准确修正： 如何及时剔除失效旧信息、响应用户的遗忘请求，并保证长期记忆不产生虚构。
• 把握发声时机（When to speak）： 在“频繁发消息造成打扰”与“过度沉默让用户以为卡死”之间找到平衡，需要更加细致的策略探索。
• 成本控制： 常驻架构成立的前提，是尽量降低空闲时的开销，而活跃运行时的推理开销也保持在合理区间。

代码更容易写，系统设计更重要

代码越来越容易生成，系统怎样把任务、状态、工具和人连接起来，就越来越重要。一次任务能不能恢复、记忆会不会过期、权限能不能控制、模型调用会不会反复花钱，取决于这些部件的配合。

Lee 给学生的建议也很具体：从简单的 Agent 循环起步，尝试加入服务器、独立电脑和记忆，亲手理解它们怎样协作。同时学习大模型的基本原理，就像开发网站时了解数据库一样，帮助自己判断哪些产品设计可行、哪些需要随着模型能力变化而调整。