打开 Manus，在输入框里敲下一行任务：调研最近一个月生成式视频模型的评测基准，整理成一份带对比表格的分析报告，然后按下回车。屏幕前很安静，只有实时展开的思考日志和不断更新的草稿文本。但在屏幕背后的机房里，一整套系统机械正在迅速啮合运转。
把任务丢给 Manus，接下来发生的事情，拆开看每一步都不陌生。根据 Manus 官方博客《Understanding Manus sandbox - your cloud computer》（访问日期：2026-09-20）披露的机制，系统接收到指令后，就会为这次任务单独创建一台隔离的云端虚拟机 Sandbox。这是一台拥有专属算力、独立网络栈、独立文件系统、浏览器与通用工具链的云端计算机。任务彼此在虚拟机环境中保持隔离，互不干扰，各自独立并行推进。
在这台刚拉起的虚拟机内部，模型随即进入一个严密运转的核心循环。按照 Manus 团队在官方技术博客《Context Engineering for AI Agents: Lessons from Building Manus》（访问日期：2026-09-20）里的复盘，这个 agent 循环的逻辑十分紧凑：拿到用户输入之后，模型在每一轮迭代中，根据当前上下文从预设动作空间挑选一个动作。这个动作在虚拟机的沙箱环境里跑出观察结果，动作与观察结果再追加回上下文末尾，喂给下一轮模型决策，如此循环往复，直到系统判定任务达成。
这个循环在真实世界里跑起来非常沉重。按照 Manus
官方口径，一个典型的复杂任务平均需要消耗约 50
次工具调用。在长达数十轮的循环拉扯中，大模型容易随着上下文长度增加而注意力发散，慢慢忘掉最初的目标，甚至在局部死胡同里打转。为了对冲这种注意力衰退，Manus
在沙箱里采用了一种操纵注意力的工程办法。它在虚拟机的磁盘上维护一份
todo.md
文件，在执行过程中反复核对并改写这份清单，划掉已经跑完的步骤。团队把这种机制称为背诵
recitation，通过把全局目标持续复述到上下文最末端，强行把总计划推进模型当下的注意力热区，避免在超长文本里迷路。
伴随这 50 次工具调用的，还有海量异构数据的高频吞吐。抓取网页吐出的冗长 DOM 树、下载的几十页 PDF 研报，以及终端命令喷出来的报错堆栈，如果全量塞进上下文窗口，哪怕是 256K 乃至更长的窗口也会迅速告罄，带来昂贵的推理成本与漫长的等待延迟。Manus 把文件系统当作终极上下文，看中的就是磁盘容量近乎无限、天生持久而且 agent 自己能直接读写的物理特性。模型学会把中间产物沉淀到磁盘文件里，留在上下文里的只有文件路径或源 URL。这种压缩策略保障了信息的可恢复性，让模型在大幅削减上下文体积的同时，不会丢失关键事实。
执行一旦撞上意外、命令行抛出错误或网页加载超时，系统会把错误的执行记录与报错信息完整留在上下文里，不做抹除，也不依赖采样随机性去盲目重试。在 Manus 团队看来，面对现实世界的粗糙状况并展现出自愈能力，恰恰是区分真实 agent 行为与死板脚本的核心标尺。
抽离出产品外壳，支撑这样一个任务运转的底层工程，可以归纳为一份清晰的采购单：
这五项需求直接落在了现代分布式系统最难啃的几块硬骨头上。在 2024 年，市面上几乎没有现成的云服务能打包解决这些问题；到了 2026 年，情况正在发生实质性变化。
回头看第一代通用自主 agent 产品的开拓之路，先锋团队为这套底座付出了沉重代价。Manus 团队在官方技术博客里坦承，仅仅为了摸索出合理的上下文排布方式与调度逻辑，他们就将自己的 agent 框架推倒重建了整整四次。他们给这种在未知空间里反复摸索架构、微调提示词和调试工程的过程起了个自嘲的名字，直译过来是随机研究生下降，意思是像研究生做实验一样靠试错碰运气。
框架层面的推倒重来还只是代码逻辑，底层沙箱的生命周期治理更是一场硬仗。根据 Manus 官方博客的记录，团队必须管理一套复杂的云端虚拟机调度体系。沙箱必须支持按需创建；用户中途离开时自动休眠节省资源，返回操作时自动唤醒；持续闲置的沙箱由系统自动回收，免费用户的保留期是 7 天，专业版用户是 21 天。
在沙箱回收之后，如果用户重新访问历史任务，后台调度系统又必须拉起新的沙箱，选择性恢复最终成果、用户上传的附件以及制作的网页或幻灯片，至于执行过程中生成的中间抓取脚本和临时日志则不予恢复。要是虚拟机在任务进行中遭遇了不可修复的系统故障，后台还得能够自动创建一台新的沙箱来接管任务。
从 2025 年 3 月 Manus 正式发布，到同年 12 月 29 日 Meta 完成收购（公开报道金额超 20 亿美元），再到 2026 年 8 月官方博客《A Note to Our Users》（访问日期：2026-09-20）宣布即将剥离回归独立运营并按监管要求清理部分历史数据，第一代开拓者的轨迹留下了清晰的印记。当时云厂商的货架上空空如也，开发者只能把整套系统从最底层的虚拟机生命周期编排、网络隔离、存储状态机，一路手搓到最上层的用户界面。
转折发生在 2026 年。经过两年的生产摸爬滚打，这套原本属于先锋团队的定制底座，公有云厂商开始将其标准化并推上货架。
在这些商业化产物中，AWS 推出的 Amazon Bedrock AgentCore 是把整份采购单凑得最齐的一份典型工业样本。根据 AWS 官方文档《What is Amazon Bedrock AgentCore》（访问日期：2026-09-20），该平台推出了涵盖 Runtime、Memory、Gateway、Identity、Code Interpreter、Browser、Observability 等组件的托管矩阵。
在此必须明确限定：讨论 AgentCore，不代表 Manus 在实际生产中使用了 AWS 的服务，目前没有任何公开信息证明两者存在直接关联。我们之所以把 AgentCore 拿来当作切片样本，是因为它提供了一面镜子。当公有云厂商试图把构建一个 Manus 所需的基础设施封装成标准化产品时，我们能从中观察到它们是如何对这些碎片化需求进行归类、抽象与商业定价的。
在对照之前，先厘清一个容易混淆的心智模型。很多开发者会问，云厂商早就有了运行代码的 Lambda 函数，也有了跑安全分析的容器沙箱，为什么还要单独做一个 AgentCore Runtime？这两者的分水岭，在于牢房与公寓楼这两种截然不同的系统设计哲学。
传统的代码执行沙盒扮演着牢房的角色，典型的例子是各类 Code Interpreter 和临时 Lambda。系统默认运行在其中的代码来自不可信的第三方或者由大模型临场生成，可能潜藏恶意攻击、死循环或资源滥用。沙箱的核心任务是严密看管、剥夺外部网络权限，执行完几秒钟的简单计算就立刻销毁。承载主体逻辑的 AgentCore Runtime 则是另一回事，它更像一座用来接待访客的公寓楼。住在公寓房间里的，是开发者自己写的、高度可信的 agent 主体进程。这个进程需要安稳的长住环境，能够维持长达数小时的长连接，能够自如访问外部网络，能够稳妥持有用户授权的敏感凭据，并在属于自己的专属空间里从容指挥外部各种工具协同作业。
从公寓楼这种长期、粘性、受信的定位出发，云基础设施开始逐项回应 agent 的采购单。接下来的五项能力，正是沿着这条主线依次展开。
拿稳前面梳理出的五项采购单，逐一检视 AgentCore 用哪些标准化云组件来满足它们。在这张云上货架里，既有开箱即用的直接替代，也有与垂直产品截然不同的架构取舍。
自主 agent 的首要需求，是一个能够执行 Python 逻辑、读写文件并对外发起调用的独立计算环境。没有这样一个专属空间，多步骤的工具编排就失去了物理承载。
在 AgentCore 体系里，承接这一核心需求的是 AgentCore Runtime。官方文档《Runtime how-it-works (microVMs)》（访问日期：2026-09-20）将其定位为托管计算层 managed compute layer。它本身不是模型，也不包含具体的提示词或决策逻辑，专为动态 AI agent 及其工具提供安全、无服务器的运行环境。
开发者接入 Runtime 的方式非常干净：交付一个存放在 ECR 中的 arm64
架构标准容器镜像，或者上传一个包含依赖的 zip
压缩包。你的程序只需要在容器内监听 8080 端口，对外暴露两个标准 HTTP
端点：一个用来处理业务调用的
POST /invocations，另一个用于健康检查的
GET /ping。
在底层物理实现上，每一个传入的会话都会独占一台轻量 microVM，在 CPU、内存和根文件系统层面做到资源隔离。尽管 AWS 官方文档在产品说明中未直接点出底层虚拟化引擎的具体名称，但 AWS Firecracker 团队工程师 Marc Brooker 在其技术专栏中曾详细剖析过这种基于专用 MicroVM 的会话架构；结合社区技术圈的多方印证，作者推断（高置信度）其底层正是基于驱动 AWS 现代化无服务器架构的轻量虚拟化引擎 Firecracker。
在资源上限方面，单个 microVM 会话目前支持最高 2 个 vCPU 与 8GB 内存配置，容器镜像体积上限为 2GB，能够支撑单次长达 8 小时的长任务稳定运行。这直接省去了开发者自己去云上开 EC2、挂载 Docker 守护进程并编写宿主机隔离脚本的繁琐工作。
一个包含 50 次工具调用的长任务，经不起这样的断裂：第一次调用的中间文件留在机器 A，第二次调用的请求却路由到了机器 B，整个 agent 的上下文感知会立刻失联。
AgentCore 的解法是在调用规范中引入了 runtimeSessionId
参数，要求字符串长度不小于 33 个字符，并在官方文档《Runtime
sessions》（访问日期：2026-09-20）中明确了粘性路由规则。只要会话尚未终止且客户端在后续调用中持续携带相同的会话标识符，网关就会稳稳将流量导向同一台专属
microVM。
正是在处理任务内状态与存储这一维度上，公有云厂商与垂直产品团队展现出了截然不同的设计哲学。回顾 Manus Sandbox 的生命周期，Manus 是把沙箱当作用户的个人云端电脑来经营的。沙箱不仅支持长时间休眠与再次唤醒，而且在长达数天甚至数周的回收重建机制里，系统会识别哪些是最终产出的成果并自动恢复。
AgentCore Runtime 则遵循公有云追求无状态与临时性的哲学。官方文档明确写明：microVM 内部的进程内存与本地文件系统默认是临时的 ephemeral，千万不要当作持久存储来依赖。微虚拟机的默认空闲超时只有 15 分钟（可根据需要配置在 60 秒到 8 小时之间），一旦任务显式终止或达到空闲时限，系统会立即销毁整台 microVM 并清空内存。即便后续客户端带着相同的会话标识再次发起调用，系统也只会为你重新拉起一台全新的空白环境。
为了在无状态与持久化之间寻求平衡，AgentCore
在存储层面做了分层演进。它在预览版中提供了可配置挂载路径的
session storage，支持在会话暂停与恢复之间保留文件系统数据，并在闲置
14 天后过期，更新 agent
版本时清空。若需要永久存储跨任务共享的大文件，则要求开发者通过 VPC
接入外部的 S3 Files 或 EFS
网络文件系统。云厂商把计算环境看成用完即走的流水席，垂直产品则努力把环境做成有记忆的个人书房，两者面对的是截然不同的闲置成本与信任边界。
一个成熟的 agent 不能在每次用户开启新会话时都像得了失忆症一样重新发问。用户在过去任务中表现出的排版习惯、偏好的数据格式、个人身份背景，需要作为长期资产沉淀下来。
AgentCore 没有把这种跨任务的记忆塞在计算沙盒的文件系统里，而是将其剥离为一个独立的云服务：AgentCore Memory。根据架构设计，短期的会话交互摘要与长期的用户画像转化为结构化的向量记录，交由独立的存储引擎统一托管。
这种解耦带来的直接收益，是释放了昂贵的计算资源。计算 microVM 可以在任务结束后毫不留恋地立即销毁，而用户的长期偏好在独立的低成本存储层中持续沉淀。下一次新会话在另一台全新的 microVM 中启动，程序只需通过 API 从 Memory 服务中提取相关的记忆切片注入上下文，算力与记忆各自独立伸缩。
在 Manus 类的产品中，用户经常需要让 agent 访问自己的 GitHub 私有仓库、Google Drive，甚至是企业内部的私有数据库，Manus Sandbox 因此支持用户直接配置个人的敏感 API 令牌。如何安全保管这些凭据，直接决定了系统的安全水位。
在企业级场景下，把高权限密钥以明文环境变量的形式直接打进不可控的容器环境，具有巨大的外泄风险。AgentCore 对此设计了一套双向出入站鉴权与网关体系。
在入站方向，Runtime 原生对接了 AWS IAM SigV4 签名机制，并支持通过 OAuth 2.0 协议与主流外部身份提供商无缝认证，例如 Amazon Cognito、Okta、Microsoft Entra ID。这保证了每一次调用的来源合法性。
在出站方向，AgentCore 提供了专用的 Identity 凭据管理组件。agent 需要代表最终用户去操作外部系统时，底层的 API 密钥与 OAuth 刷新令牌全部由 Identity 服务安全代持，运行时环境只能获取受控的临时操作权限，消除了长期凭据遗留在临时容器文件系统中的隐患。配合 AgentCore Gateway 工具网关，系统能够将零散的外部工具、企业微服务以及当下主流的 Model Context Protocol 端点统一挂载注册，由网关负责工具元数据的发现与流量转发。
采购单上的最后一项，是可观测性与破坏性动作隔离。一个包含 50 步工具调用的长链条中，任何一环的模型幻觉或工具超时都可能让整个系统陷入僵局，运维人员必须能够看清现场。
AgentCore Observability 深度依托于 AWS 的 CloudWatch 与 X-Ray 监控底座，能够为每一次复杂的 agent 执行生成端到端的分布式追踪链路。每一个工具调用的入参、耗时、模型消耗的 token 数量以及异常堆栈，都会精准打上会话标签并记录归档。
针对高风险的特定执行动作，AgentCore 专门配套了开箱即用的托管 Browser 与 Code Interpreter。这呼应了前面提到的牢房与公寓楼的分工：开发者编写的核心调度常驻在 Runtime 公寓里，而当模型需要去互联网上访问一个未知的外部网址，或者执行一段大模型刚生成的复杂数学脚本时，它只需将这些粗活指派给外挂的 Browser 或 Code Interpreter 去处理，确保即便外围执行环境发生内存溢出或恶意挂起，核心 agent 宿主也不受波及。
架构图勾勒出的是系统的理想骨架，而每个月的实际结算账单，则是对 agent 真实负载形状最诚实的自白。透过账单的计费口径，我们可以反推云厂商对这种新型工作负载的全部工程预设。
查阅 AWS 官方发布的定价页面《Amazon Bedrock AgentCore Pricing》（访问日期：2026-09-20），AgentCore Runtime 制定了四条基础计费法则：
这份账单比功能列表诚实，因为它替 AWS 说出了他们对 agent 负载形状的假设。两个核心计费规则分别对应着两组截然不同的物理现实。
AWS 为什么免除 I/O 等待期间的 CPU 费用？因为与传统计算密集型应用不同，agent 的物理时钟绝大多数都耗费在漫长的等待之中。前文引用的 Manus 官方技术博客明确指出，Manus 系统内的平均输入输出 token 比例高达 100:1。在整个任务周期中，极高比例的时间是在等待基础大模型进行超长上下文的预填充 prefill 推理，或者等待外部网页加载与接口返回。如果按传统虚拟机的核数全量按时计费，开发者将为大量无意义的等待状态买单。
内存又为什么必须全程按秒结算？因为只要那台分配给你的 microVM 处于唤醒状态，它所持有的容器进程、上下文缓存与中间磁盘映射，就必须实打实地霸占宿主物理机的一块内存区域，底层调度器无法移作他用。内存的物理锁定决定了这笔开销必须持续产生。
AWS 在官方定价页面上给出了一个极具代表性的百万级会话基准算例：假设一个生产级系统在一个月内处理 100 万次 agent 会话，平均每次会话持续 10 分钟，其中 90% 的时间处于 I/O 空闲等待状态，实际消耗 1 个 vCPU 的计算时间仅为 60 秒。在 V2 运行时的按需计费标准下，整月的最终总账单为 6,703 美元，摊薄到单次会话的运行成本约为 0.006703 美元。
仔细拆开这 0.0067 美元的成本构成，会看到一个反差强烈的比例。单个会话消耗的 CPU 费用仅为 0.002127 美元，而支付的内存费用却高达 0.004576 美元。内存开销是计算开销的两倍以上。在 agent 驱动的新型架构里，内存驻留成本正式反客为主，取代 CPU 算力成为了基础设施账单的大头。
这种因独特负载形态带来的经济学扭曲，在 AgentCore Runtime 的第一代 V1 架构中催生了两个显要的工程痛点。查阅 AWS 官方发布博客《The new AgentCore runtime: Elastic, optimized, and consistently fast starts》（访问日期：2026-09-20），其一是高水位内存计费，账单按截至当时的会话内存高水位结算，释放内存也不会降低后续计费；其二是冷启动延迟随镜像体积恶化，从 200MB 镜像的约 5.4 秒暴涨到 2GB 镜像的近 30 秒。
AWS 推出的 AgentCore Runtime V2 针对冷启动与内存经济学进行了重构，核心机制包含三项：内存按需装入与闲置冷却回收、部署预热期为就绪容器拍摄精简快照，以及新会话到达时直接从快照瞬时恢复执行环境。
测试采用纯净 echo agent 作为基准环境，不调用模型或工具。AWS 发布博客的测试由 EC2 客户端发起，计时包含跨区公网往返，每个 agent 发起 5000 次冷调用；下表来自 AWS 官方样例仓库的另一组自测，客户端在 AWS 外，计时包含公网往返，每个容器镜像测试点为 500 个会话，zip 测试点为 5000 个会话，仅呈现 P75 分位数：
| 容器镜像体积 | V1 运行时冷启动耗时 (P75，AWS 自测) | V2 运行时冷启动耗时 (P75，AWS 自测) |
|---|---|---|
| 200MB 镜像 | 5.37 秒 | 1.94 秒 |
| 500MB 镜像 | 7.41 秒 | 2.13 秒 |
| 750MB 镜像 | 11.46 秒 | 2.11 秒 |
| 1GB 镜像 | 15.48 秒 | 2.13 秒 |
| 2GB 镜像 | 29.72 秒 | 2.16 秒 |
这套快照机制对开发者的代码习惯提出了明确约束，参见 AWS 官方优化文档《Optimize
runtime V2
performance》（访问日期：2026-09-20）。从快照恢复出的容器内部主机名均为
localhost，主进程 PID 均为
1，因此随机数种子、系统时间、动态凭据与实例网络标识必须在请求级动态现取，不能在快照拍摄前的全局初始化阶段提前固化。
V2 并不保证所有场景都能节省开销。使用轻量 zip 代码包部署的精简应用缺少按需分页空间，AWS 自测的 P75 冷启动耗时仅为 V1 2.85 秒与 V2 1.96 秒，叠加 V2 更高的单价，升级未必省钱。最后需要做出清晰划界：快照恢复目前只作用于新实例启动的初始化加速，运行中长任务的内存快照暂停与恢复，官方标记为 suspend/resume 能力，当下尚未正式交付。
将 AgentCore 这套工业拼图拼齐之后，横亘在产品与基础设施之间的分界线，清晰地显现了出来。两者各自负责的疆域由此划清。
看一看云厂商通过 AgentCore 递到我们手里的东西：轻量 microVM 的生命周期调度、AWS 自测 P75 拉平到两秒左右的冷启动快照引擎、会话内的粘性路由网关、按秒结算且免除 I/O 等待期间 CPU 费用的计费管道、企业级出入站安全凭据代理。这些是重工业级的地基工程，是耗费海量基础设施工程师数年光阴浇筑出的水泥钢筋。
即便把这套地基原封不动地全部采购到位，开发者依然无法直接获得一个具备竞争力的 Manus。基础设施承接了底层的运维脏活，但决定 agent 智能上限的核心资产，依然留存扎根在分界线之上的上下文工程与模型决策层。
在这层地基之上，AgentCore 并不提供那些真正决定 agent
表现的关键机制。它没有给你在 50
次工具调用中精密运转的核心循环；没有给你通过反复改写
todo.md
对抗注意力衰减的背诵机制；没有给你严密控制前缀稳定性的 KV-cache
上下文排版；它更没有给你面对网页抓取失败与命令行报错时的自愈策略，以及跨越复杂业务场景的提示词调优、评估基准与最终交付给用户的产品体验。Manus
团队在 2025 年 7
月的官方博客中自述推倒重来四次所沉淀下来的核心机密，全部完整地留存在这一层。
放眼 2026 年的整个行业生态，AgentCore 也不是孤立的存在。根据我们在 2026 年 7 月完成的专项技术调研，整个软件工程界对 agent 执行隔离这一命题的探索已经全面走向商业化阶段。从专为自主智能体提供轻量 Python 代码沙盒的 E2B，到微软在 Azure 体系下推出的 Azure Dynamic Sessions 动态会话池；从 Cloudflare 依托边缘节点构建的 Cloudflare Sandbox，到 GitHub Copilot 托管在云端的完整开发智能体环境，各类基础设施厂商都在争相圈地。AgentCore 的代表性意义，在于它背靠公有云生态，第一次将隔离计算、长效状态、长期记忆、工具网关与安全身份这一整张采购单，打包成了一份能够端到端交付的工业级托管组合。
同一道题有两类答案。面向信任度高、规模固定、状态需要跨越数月维护的小圈子，合理的解是长租公寓：状态常驻、按月付费、用户彼此可信。而 AgentCore 所瞄准的，是公有云上成千上万、陌生突发、互不信任、用完即走的多租户场景，它的底色更接近快捷酒店：重视无状态弹性，坚持严苛的身份校验，对闲置资源锱铢必较，以及果断的超时清退。两类参数没有高下，服务的人群不同而已。
坦率地讲，正在阅读这篇文章的多数一线工程师与开发者，眼下并不需要真的亲手去造一台复杂的全功能 Manus，也大可不必火急火燎地把自己的工作流向沉重的公有云全家桶上做盲目迁移。自主 agent 的工程重心因场景而异，盲目上云只会徒增认知负担。
但理解这一切依然具备坚实的现实价值。当大语言模型的应用范式从简单的一次性问答，大步迈向持续数十分钟、跨越数十个步骤的自主代理实体时，软件工程的重力法则正在迅速向底层基础设施发生转移。
这篇文章最终希望交付给你的，是一张能够随身携带的五项采购单，以及一张清晰勾勒出能力边界的工程地图。在接下来的日子里，当你再次看到某家新兴初创公司宣布获得融资并推出所谓的全新 Agent 云平台，或者看到某家主流云厂商开了一场声势浩大的发布会推介其全新 agent 组件时，你大可不必为那些玄妙的时髦辞藻所迷惑。
你可以从容不迫地掏出这张采购单：它到底覆盖了隔离计算、会话粘性、长期记忆、凭据管理还是可观测性？它的底层虚拟化模型是在构建一间看管不可信代码的牢房，还是在运营一座容纳可信进程的公寓楼？它的计费模型对系统的空闲状态做出了怎样的假设？而在基础设施那条清晰可见的分界线之上，真正属于你自己的产品灵魂与上下文设计，又究竟打下了多深的根基？这些问题会为你提供稳定的判断支点。