SpaceX的Lee Robinson揭示了AI代理正从被动响应向“全天候待命”进化，而在这个万亿级的新赛道中，任何未能掌握Agent入口的产品，终将彻底沦为其他AI系统的数据“养料”
“不做 Agent 入口，就沦为其他 Agent 的数据”，这句话抓住了软件公司对用户关系流失的焦虑。但我读完这篇演讲，更关注一个变化：当 AI 能够持续接手任务，软件的交互、运行方式和价值分配都会随之改变。
按文中介绍，Lee Robinson 在斯坦福的演讲讨论了全天候代理的构建方式，其中一些能力仍在研发。他描绘的方向很清楚：人交代目标、随时纠偏，代理在后台推进工作，只在必要时回来沟通。
全天候待命，改变的是任务关系
Robinson 把开发者使用 AI 的过程分成四个阶段：复制粘贴代码、终端调用工具、使用专门的代理应用，再到拥有独立计算机和记忆的持续运行代理。
我认为，关键变化发生在人与任务之间。过去，人要守着每一步，批准命令、等待结果、补充下一条指令。现在，人开始承担指导者的角色：安排目标、调整优先级、处理中途变化。
这要求代理能够接住连续的沟通。用户补充“日期改到周四”，系统就要理解它与当前工作的关系，并优先处理这次调整。邮件、群消息、定时任务也可以成为工作的触发器。
能否保持沉默，同样决定产品体验。每完成一步就汇报，只会把执行负担换成阅读负担。我期待的数字同事，应当自己推进常规工作，把需要判断的问题和重要结果带回来。
演讲提到，独立模型可以审核执行命令，Robinson 称其在多数盲测情况下优于人工。但素材没有给出测试方法和数据，我不会据此认定安全问题已经解决。他也提到，发送邮件等不可撤销操作仍可能需要用户编辑、批准，安全框架和防攻击能力还有工作要做。
持续工作的底座，是可恢复的状态
“始终在线”容易让人想到一台永不关机的电脑。演讲中的设计更实际：代理和计算资源可以休眠，任务状态、对话和记忆被保存，事件到来时再唤醒。
我看重的是这里对连续性的定义。机器可以关闭或重建，工作进度仍然保留，才有条件长期承担任务。
这套架构把代理循环放在服务器上，将执行命令、操作浏览器的计算机作为独立资源。云端虚拟机可以通过快照恢复，也可以在更新时重建，避免一次机器维护中断整个代理流程。
持久工作流解决另一个问题：任务做到第三步时崩溃，恢复后应当接着推进，避免把前两步全部重做。Robinson 提到使用 Temporal 承担这部分基础能力。
对产品而言，这些机制最终都应当表现为一件简单的事：用户合上电脑之后，交代的工作依然有人接着做。
上下文管理决定长任务的质量和成本
持续工作的代理，迟早会遇到上下文上限。对话、工具说明、截图和执行记录不断累积，把所有内容一直塞给模型，既昂贵，也容易干扰判断。
演讲给出的办法是分工。主代理保留目标、进度和必要结论，把繁重的执行交给拥有独立上下文的子代理。子代理完成工作后返回结果，大量过程细节留在自己的工作空间。
我把它理解为团队协作中的信息管理：负责人需要知道任务是否完成、结论是否可靠，不必随时背着每个成员的全部操作记录。所谓“无限上下文”的体验，依靠的正是这种组织方式，模型本身的窗口限制依然存在。
工具也需要按需加载。先让模型知道有哪些工具，需要使用时再读取详细说明。长输出保存到文件，历史信息通过检索取回，都可以减少当前对话的负担。
另一项关键能力是缓存。稳定的系统提示、工具定义和排列顺序，有利于复用已经处理过的内容。Robinson 甚至把缓存未命中视作需要排查的系统缺陷，并提出在缓存仍有效时及时压缩长对话，降低后续成本。
这里最难的仍然是信息取舍。摘要有损，省下 Token 的同时，也可能丢掉决定任务成败的细节。我认为，长期代理的竞争力，很大程度上取决于它知道什么必须保留、什么可以暂时放下、什么需要时能够找回来。
组织经验要变成代理能使用的知识
演讲对记忆的处理很朴素：核心偏好放进常用上下文，历史对话带着日期保存，临时笔记按需要清理，其他信息进入可检索的文件。
技能则把完成某项任务的步骤、经验和关键判断写成 Markdown 文档。代理可以反复调用，也可以配合插件、外部服务和定时例程使用。
这让我想到企业部署 AI 的一个实际门槛：很多组织拥有大量经验，却没有把经验表达清楚。流程藏在人的脑子里，判断标准散落在聊天记录中，遇到例外情况依靠口头协调。
我的判断是，让代理真正承担工作，组织也要学会交接工作。目标、步骤、验收标准和例外处理越清楚，通用模型越容易转化为可重复使用的能力。
这项积累会随着使用继续增长。一次失败可以变成评估案例，一次有效处理可以沉淀成技能。组织需要建立让经验持续进入系统的机制。
软件价值会沿着任务入口重新分配
原文关于“无头数据”的说法，指向一个现实风险：用户把任务交给代理之后，代理可能直接调用其他软件的数据和功能，也可能通过浏览器操作它们。原有软件界面的存在感会下降。
我认为，真正值得争取的是用户交付任务的位置。谁接收目标、组织工具、保留工作记忆并交付结果，谁就更有机会维持用户关系。仅仅增加一个聊天框，并不能自动获得这种位置。
但“成为数据就失去价值”也说得过满。按这套逻辑推演，独特数据、可靠执行能力和关键业务连接仍然可能有价值，只是需要重新考虑面向谁提供服务、如何收费。
演讲列出的机会覆盖持久工作流、沙箱、云端计算机、记忆、技能、支付、身份验证、评估和可观测性。我更愿意把它们看成新产品所需的基础组件。至于数十亿乃至数万亿美元的空间，是演讲者对机会的判断，不能当成已经得到验证的市场规模。
为更强的模型留下空间
Robinson 提出的“删除产品”原则，我理解为避免过度固化今天的模型局限。模型能力变化很快，为了弥补当前不足搭建的复杂界面和流程，几个月后可能就需要重做。
这对产品团队提出了更难的要求：界面尽量简单，底层的状态管理、恢复能力和评估机制却要扎实。用户看到的步骤越少，系统需要吸收的复杂性越多。
他预测，从演讲时点往后六到十二个月，代理可能连续工作数周甚至数月。这仍是预测。演讲也提出了尚未解决的问题：如果一个任务运行一个月，而模型每月更新一次，如何充分评估新版本，再决定是否交给它继续执行？
我更看重他描述的两个改进循环：产品团队把日常失败变成评估，修复框架、提示和工具；模型迭代再从这些问题中获得能力提升。长期可靠性，需要两边一起推进。
对我而言，这篇演讲最有价值的提醒是：应当围绕一项工作如何被持续、可靠地完成来设计产品。入口、记忆、工具和界面，都要回到这个目标上。