从终端脚本到常驻同事：Agent 的演进与交互范式
我是 Lee，今天我们将深入探讨新一代 常驻 Agent（Resident Agents） 的工作机制。与早期在终端中运行、依赖用户持续输入的简单循环框架不同，这类 Agent 始终在线，具备主动执行任务的能力，并能在云端持续运行。其核心架构包含一个拥有独立 Linux 环境（包括桌面、文件系统和浏览器）的虚拟机，使得 Agent 能够像同事一样工作：它不会在每次微小进展时都打扰用户，而是懂得保持安静，仅在关键节点汇报。触发其工作的不仅是终端指令，还包括 Slack 消息、邮件或定时任务等外部事件。理想状态下，这类 Agent 能持续工作数周甚至数月。
回顾开发者使用 AI 的历史，大致经历了四个阶段：从最初在 ChatGPT 中复制代码粘贴到编辑器；到模型配合简化版运行框架，能在终端编辑文件并执行 Shell 命令；再到将编程 Agent 封装进专门应用并行运行，但此时用户仍是瓶颈，需逐条审核命令；最后进入当前的 常驻 Agent 阶段。这一阶段的特征是用户不再需要每天手动发送 Prompt，而是可以调整工作方向。例如，用户可以随意打断并下达新指令（如“先看看这个讨论串”紧接着说“周四再做吧”），现代模型能像朋友聊天一样理解这种非线性的指令关联。此外，系统引入了 自动审核机制（由另一个 AI 模型检查命令），这在盲测中往往比人类逐条批准更安全且高效，极大地简化了交互界面。
这种常驻 agent 更像一个同事，不会总是立刻给你发消息，他知道什么时候该保持安静。
如果做个盲测对比 AI 模型和人对命令的检查，大多数时候模型其实做得更好。
核心能力跃迁：长时程记忆、子代理与计算机操作
常驻 Agent 的可行性得益于模型本身的六项关键变化。首先，长时程指令遵循能力显著提升，通过上下文压缩与精简，模型能可靠地连续运行数小时至数天。其次，子 Agent（Sub-agents） 机制解决了工作记忆有限的问题：主 Agent 可将高 Token 消耗或需大量工具调用的任务委派给拥有全新上下文的子 Agent，从而获得近乎无限的上下文处理能力。
第三项变化是 工具调用与计算机操作（Computer Use） 的成熟。早期模型常产生幻觉且不善用工具，如今不仅能稳定调用 Shell 命令和处理文件，还能像人类一样操作屏幕（点击、输入）。这意味着任何缺乏 API 或 MCP 接口的 SaaS 产品均可被 Agent 自主使用。此外，Agent 具备将信息存入文件的能力，利用 Linux Shell（如 grep）高效检索历史数据。最后，Agent 能将演示过的任务转化为 技能（Skills）、记忆或例行程序，这些内容以 Markdown 形式存储，形成了包含邮件撰写、API 构建等最佳实践的生态体系。
子 agent 之所以有用，是因为模型在处理任务时有一份工作记忆，而这份记忆迟早会被填满。所以，如果能把工作交给这些帮手就很好。
基本上这意味着任何没有提供 API 或者 MCP 服务器的 SaaS 产品或网站都可以在无人值守的情况下使用。
幕后架构：休眠唤醒机制、Firecracker 虚拟机与分布式一致性
在底层实现上，常驻 Agent 采用 休眠-唤醒机制以优化成本。服务器和虚拟机平时处于休眠状态，当触发事件（如 Slack 消息、电话或会议记录需求）发生时，系统加载 Agent 的全部状态并启动。Agent 内部包含一个 路由器，负责去重并根据经验规则判断是否需要打扰用户（例如将每日多次进展汇总为一次汇报）。Agent 运行的虚拟机基于 Firecracker技术，支持快速快照、重启及实时画面查看。该环境经过安全防护与权限限制，允许运行 Shell 命令和 Chrome浏览器，甚至支持多 Agent共享基础设施。
架构上采用 客户端轻量、服务器重量的设计。Agent 循环运行在服务器上，便于快速发布代码更新（无需 App Store审核）、处理高算力任务（如语音转文字）以及应对流量波动。最关键的是，这种设计允许在保持 Agent 逻辑状态（保存在数据库）的同时重建虚拟机，从而安全地处理 Linux 零日漏洞更新而不中断服务。在数据一致性方面，系统通过客户端订阅服务器通知、获取最新状态以及巧妙的去重逻辑，确保在分布式环境下消息列表的准确性与实时性。
如果给每个人的电脑都一直开着，成本会很高……所以这些状态可以持久保存到数据库里。
如果你把 Agent 循环放在虚拟机上，就没法在保持 Agent 的服务器运行的情况下，单独关闭虚拟机。
分布式基础设施：从任务队列到持久化工作流
在构建 Agent 系统时，底层基础设施的核心在于区分任务队列（Task Queue）与工作流（Workflow）。虽然两者都用于处理异步操作，但在故障恢复机制上存在本质差异。如果使用普通的任务队列，当 Agent 执行复杂的多步任务（如第一步、第二步、第三步）时，一旦基础设施发生故障并重启，系统往往需要从第一步重新执行。这种“全量重试”机制不仅效率低下，还可能导致不可逆操作的重复执行。
相比之下，持久化工作流引擎能够保存执行的中间状态。这意味着当系统崩溃后重启时，Agent 可以直接从故障发生前的最后一步（例如第三步）继续执行，从而实现安全的断点续传。目前业界已有成熟的解决方案来解决这一分布式系统难题，例如开源工具 Temporal。采用此类现成的基础设施组件，可以避免从零开始重新实现复杂的分布式逻辑，让开发者能更专注于业务层面的创新。
你真正需要的是能持久保存执行进度的工作流，这样你就可以安全的重试，失败以后再重试，会直接从第三步接着做。
架构设计与动态上下文工程
Grok Bot 的 Agent 运行框架采用了“轻客户端、重服务端”的架构模式。在这种设计下，客户端与服务端之间仅通过一个核心工具进行通信——即向用户发送消息。这种极简的接口设计使得架构非常清晰：无论客户端是手机应用、桌面软件还是 Slack 机器人，它们都只负责接收服务端的指令并决定如何以丰富、可交互的方式展示给用户（例如渲染登录表单或支付链接）。而所有重量级的操作，如执行 Shell 命令、读取文件或调用云端服务，均集中在服务端完成。
为了应对模型有限的上下文窗口（Context Window）限制，框架引入了动态工具加载机制。传统做法是将所有可用工具的详细定义（名称、参数结构等）一次性塞入上下文，这会迅速耗尽 Token 空间。而动态机制仅向模型暴露工具名称列表，当模型决定使用某项功能时，再按需从文件系统读取该工具的详细定义。这种上下文工程（Context Engineering）技巧显著节省了 Token 消耗，降低了成本。
此外，信息获取遵循“从低成本到高成本”的层级原则：首先利用对话历史中已有的知识；其次尝试调用 API 或 MCP 服务器获取数据（如银行信息）；若失败则进行网页搜索；最后才考虑操作浏览器或桌面环境。只有在所有自动化手段均失效时，才会打扰用户请求人工介入。
基本上就是每次发给模型的消息里只放工具名称，然后模型可以自己决定。啊，我现在想用这个工具，我可以去文件里读取相关信息。
最简单的就是用 agent 或机器人根据对话历史已经知道的信息，如果当前上下文里没有，也许有一个插件 MCP 服务器或者某种 API 可以去获取信息。
主从协作、安全隔离与缓存优化
为了维持长对话的性能，系统采用“主 Agent + 子 Agent”的协作模式。主 Agent 负责统筹协调，保持对话上下文的精简；而耗时的任务（如运行大量 Shell 命令或处理高开销工具调用）则委派给独立的子 Agent。子 Agent拥有独立的工作流和上下文，完成后仅将最终结果返回主 Agent。这种设计让用户感觉模型拥有“无限上下文”，实际上是通过隔离高噪声任务来保护主对话的质量。
在安全性方面，系统实施严格的输入审查机制。对于来自不可信来源（如邮件、回调请求）的内容，模型会先进行自动审查以防范 Prompt 注入攻击，防止恶意指令被当作用户命令执行。对于不可撤销的操作（如发送邮件），系统会强制要求用户批准草稿，确保操作的安全性与可控性。
最后，Prompt 缓存（Prompt Caching）是降低长期运行成本的关键。由于模型提供商对缓存 Token提供大幅折扣，工程上需确保 Prompt 结构（系统提示、工具定义等）在多次调用间保持固定顺序，以避免缓存失效。通过哈希值排序确保内容稳定性，并在用户输入前进行预热；同时，在缓存有效期内（如 10-60 分钟）主动触发上下文压缩摘要。这种策略使得即使对话超过十万 Token，用户返回时也能基于低成本的摘要继续高效交互。
理想情况下用掉的大部分 token 其实都是缓存的 token，因为你先把一段对话发进去，然后做个改动，多加一条消息，接着基本上又把整段对话重新发了一遍。
上下文压缩与记忆分层策略
处理长对话时，缓存有效期是一个关键约束。模型提供商通常设定 10 到 60 分钟的缓存窗口，在此期间上下文保持“热”状态。一个高效的技巧是趁缓存还热时立即执行上下文压缩。由于长对话的 token 数量巨大（可能超过十万），此时进行摘要生成的成本远低于后续重新加载。当用户过一段时间回来时，可以直接基于这份高质量摘要继续对话，从而显著降低后续交互的成本。这要求摘要算法具备极高的质量以保留关键信息。
在构建 Agent 的记忆系统时，可以将信息划分为几个不同的层次： 1. 核心用户偏好：这是每次交互都必须携带的信息。例如，如果用户要求所有文字必须小写，或者希望模仿特定人物（如 Sam Altman）的风格，这些约束条件必须嵌入每一条消息中。否则，模型可能会在后续回复中出现风格不一致（如突然使用大写字母），导致体验割裂。 2. 事实性记忆与垃圾回收：系统需要保留重要的事实信息，但必须引入类似人类大脑的“垃圾回收”机制。就像人脑会保留当前对话相关的信息，同时遗忘无关细节（如昨天的足球比赛）一样，Agent 也需要算法来判断哪些事实当前最重要并予以保留，其余的则暂时搁置或清除。 3. 带日期的日志与临时笔记：除了核心事实，Agent 还应维护带有时间戳的历史对话记录（日志）。此外，还需要临时笔记机制来存储当前任务中的短期细节。这些笔记设计为短生命周期（如 30 分钟至 1 小时），用于辅助当前工作流，之后会被自动清理。 4. 文件作为外部记忆：所有其他非核心信息应存储在文件中。利用模型擅长执行命令和读取文件的能力，Agent 可以随时检索所需数据。文件的妙处在于其无限扩展性，使得 Agent 能够随时查询历史或外部知识，而不受上下文窗口限制。
“我们的大脑其实也差不多是这样工作的……你的大脑很擅长把眼下相关的信息留在当前的思路里，同时也记住其他信息，留着以后再用。”
模型训练飞轮与产品迭代原则
Agent 产品的演进依赖于一个持续改进的飞轮机制。回顾大语言模型的训练阶段：首先是基于海量数据的预训练，建立对世界的总体认知；其次是监督微调（SFT），教导模型如何作为助手或 Agent 行动，例如学会在特定运行框架中使用工具；最后是强化学习（RL），通过奖励机制让模型更好地遵循指令，如在数百个技能中做出正确选择或精准操作浏览器。
这个飞轮包含两个循环： * 内循环（日常迭代）：当 Agent 在产品中犯错时，团队将其转化为评测案例。随后修复运行框架、Bug 或 Prompt。通过回归测试确认问题已解决后发布更新。开发团队每天都在执行这一过程，确保产品稳定性的持续提升。 * 外循环（模型更新）：每隔几个月或更长时间，训练新的基础模型。新模型会从历史 Bug 和失败案例中学习，在评测中表现更好。新模型的发布往往带来能力的跃升，使得产品能够支持全新的用法（例如在多 Agent 群聊中表现得当）。因此，产品团队需要持续推动这两个循环。
在产品开发策略上，有一条核心原则：“删掉产品”（Delete the Product）。这意味着要接受一个残酷的事实：今天的模型水平就是未来六个月内的最差基准线。随着新模型的推出，现有的用户界面和交互逻辑可能需要彻底重做。面向下一代模型设计产品是关键策略：尽量简化当前实现，保持界面极简，让模型承担更多的思考和行动职责。这样当更强力的新模型到来时，产品能更平滑地适应变化。
“我们的意思是你得把这个想法真正接受下来，假定今天的模型就是他们今后最差的水平。”
未来趋势、挑战与工程建议
展望未来六到十二个月，Agent 的工作时长将从几小时延长至连续运行几周甚至几个月。这带来了新的评估挑战：如果模型每月发布一次，如何充分评估一个运行一个月的 Agent？行业必须解决长周期任务的评估方法问题。同时，记忆算法（如使用图结构或文件表示数据）和安全基础设施的建设也至关重要，以防止 Agent 被恶意控制。
在交互层面，语音接口可能会变得更加普及。用户可能通过类似 Johnny Ive 设计的设备与 Agent 进行全天候语音对话，而模型将更擅长在工作过程中学习技能并将其写入文件或指令中。此外，Token 消耗量预计将大幅增长，因此优化推理效率、降低 Token 用量将成为核心竞争点。
尽管目前许多应用看起来相似（都有侧边栏、聊天框和 Agent），但这类似于 2005 年 Web 应用都有数据库和 CRUD 界面的阶段。Agent 功能将成为新产品的标配，要么集成 Agent，要么作为无 UI 的数据源供其他 Agent 调用。持久工作流、沙箱环境、记忆技能等模块背后是数十亿美元的投资机会。
给工程师的最后几点建议： 1. 重视系统设计与架构：在 AI 时代，代码决策的影响会累积放大。即使使用生成式工具，仍需深入理解最终交付的架构。 2. 动手实践：尝试构建自己的 Agent 版本，利用开源代码（如 GitHub 上的 Grok Bot 变体）配置沙箱和虚拟机，深入理解组件工作原理。 3. 学习 LM 原理：不需要成为 ML 专家，但建立对模型工作机制的直觉至关重要。就像理解数据库原理有助于 Web 开发一样，理解 LLM 的特性将帮助你在产品层做出更优决策。
“有人说，哎，现在每个应用看起来都一样……而实际情况是，这已经成了新的常态。”