把 agent 跑成产品，要拼出五块独立基础设施：
- 一个地方跑 agent loop
- 一个 sandbox provider 去操作上下文
- 一条路把上下文「拷进」sandbox
- 一个 trigger 系统去 kick 整件事
- 一套 idle shutdown 避免空跑烧钱
Archil 的 Hunter Leath 在这条 thread 里主张：这五件事在企业 AI 落地时撑不住。硅谷团队靠「爱造新 box」扛得住；普通企业团队不想为了一个能用的 agent 缝一堆基础设施。终极答案一直是 managed、serverless 的解。
同一件事的两个动作：extract + edit
Leath 先回到「agent 是什么」这一层。
造一个 agent 做的第一件事是铺 agent 能访问的 context——S3 桶、Salesforce、系统记录。Agent 是第一种需要横跨多种数据源才能把洞察合出来的应用。
Sandbox 这个原语在这一层是做什么的？manipulate 上下文。一个 Linux 容器让你能两件事：extract（用代码切片切块然后看）和 edit（比如 sed）。驱动 sandbox 去操纵 context 的是 agent loop——反复问 LLM「下一步改什么」。
但即使这三层——context、sandbox、agent loop——还差一格。谁 trigger agent loop？ 答案通常是某种用户或系统事件：网页聊天界面的一条消息、iMessage、定时器、webhook。
Leath 团队的判断是：用户驱动事件（Slack 消息那种）在 agent 的全量 trigger 里是少数。系统事件（Datadog 告警、收邮件、LinkedIn 推送、别的 agent 的 handoff）在数量上会大幅压过用户能发出来的流量。
文件系统的角色：从「硬盘组织方式」变「agent 工具」
回到文件系统。Leath 的预测：文件系统不再被当成「整理硬盘数据的存储库」（XFS/ZFS 那种心智模型），而更接近**「作为服务被卖给 agent 用的工具」**。
一个文件系统只要 export 一组 API——getFile / writeFile / searchFiles / runContainer——agent 直接当 tool 调，sandbox 就可以消失：文件系统本身已经内含跑 untrusted code 的原语，并且能在 web UI 上一致地显示同一份数据。
「sandbox provider 作为独立 stack 一部分」的根本问题有两个：
- 变成要显式管理的资源（对话里什么时候起、什么时候停）
- 变成新数据孤岛（你要操心数据怎么进、怎么出）
Archil 的解：三件事坍缩到同一层
Leath 描绘了一个理想 serverless agent 长什么样：
- Context 层不变——把 agent 能访问的东西定义成一个 workspace 让它迭代发现。这本来就是文件系统在做的事。
- Sandbox 不再是独立服务——Serverless execution 让 agent harness 能 spin up 大量并发容器，不污染 harness 本身。
- Harness 本身也不需要 long-running server。只要 agent service 给你一条 networked webhook 到 agent，harness 可以定义成 serverless function（跑一个 turn 就退）或「fluid compute」（持续到 idle 自动关）。
为什么这就解锁了？因为 context 本身是持久的——用它存对话历史和 prompt，harness「重启」时能从用户上次停下的地方接上，不用单独管 state。
文件即 agent：四件东西都只是 data
Leath 的关键观察是：
「The deep unlock for generic computation was that the 'executables' that you run are just data, no different than the other data stored on your computer.」
同样的解法在 agent 这层在发生——harness 本身就是 data，可以存在文件系统里、存在 context 里。对话历史是 data。到系统记录的连接是 data。 唯一需要独立提供的原语就是一个 storage 层，能力上必须做到三件事：
- 接得住海量的 agent 交互
- 自己能跑代码、不需要外部 service
- 透明地同步到系统记录
Leath 的判断是：基础设施层会快速坍缩到同一张架构图里。团队不会从 10 个不同供应商买 10 个点状解决方案来跑 agent stack 的不同部分，他们会坍缩到一项服务跑整个 stack。这从「持久存储层」往下流——也就是一个你的 agent 真的能跑在上面的文件系统。
为什么这条值得单独追
这条 thread 不是工具评测或产品发布，是一次基础设施层的范式宣言。如果 Leath 的判断对，2026-2027 年 agent 栈会从「harness 工具 + sandbox 工具 + trigger 工具 + storage 工具」合并成一项服务。决策者关心的问题是：
- 你的 agent 团队现在每周花多少时间在「把 context 拷进 sandbox」和「决定什么时候起停」上？
- 你愿意为「harness 也能作为 file system 上的数据存」这种抽象付钱吗？
- 你愿不愿意为「10 个供应商变成 1 个」付溢价？
- 还是说你团队就是硅谷型的「爱造新 box」——多 box 缝出来的灵活性比单 box 的简洁更值钱？
Archil 提供了「文件系统本身就是 agent 跑的地方」这个抽象的实现样本。19.3K star 量级的 opik 处理「trace 之后的右半边」，Archil 处理「harness 跑在哪里的左下角」。两个产品不重叠——它们在坍缩的栈上占着不同象限。
如果你正在选 agent 运行时基础设施，「filesystem 即 agent」是 2026 年最值得认真评估的范式之一。但也记住 Leath 自己承认：这一层在硅谷之外的接受度还要再观察。