Fly.
这种做法解决了目前 AI Agent 最头疼的“幻觉执行”问题。如果你让 LLM 写一段 Python 代码去处理数据，传统的做法是在一个受限的 Sandbox 里跑，或者干脆让 LLM 告诉你代码怎么写，然后由你手动运行。而 Fly.io 的逻辑是直接给 Agent 一个 MicroVM，让它在里面执行 apt-get install，安装依赖，运行脚本，如果报错了，Agent 能直接看到标准错误输出（stderr），然后自己原地 Debug。
我实测过类似这种基于 VM 的 Agent 部署，最大的痛点在于冷启动时间和资源开销。但 Fly.io 用的是 Firecracker 这种轻量级虚拟化技术，启动速度能压到秒级。
这里分享一个典型的 Agent 运行链路逻辑，如果你想在自己的环境里模拟这种“计算机化”Agent，可以参考这个配置思路：
# 这是一个简化的 Agent 环境定义示例
agent_environment:
vm_type: firecracker-microvm
os: ubuntu-22.04
capabilities:
- network_access: true
- shell_execution: true
- filesystem_read_write: true
resource_limits:
cpu: 1
memory: 2GiB
disk: 10GiB
runtime_hooks:
- on_start: "pip install pandas requests"
- on_error: "capture_logs_and_retry"在实际操作中，最容易踩坑的地方是权限管理。如果你给 Agent 开放了完整的 Shell 权限，它可能会在尝试安装某个包时把整个系统环境搞崩，或者在循环调用中把 CPU 跑满。解决办法是必须给 Agent 设置一个强力的 timeout 机制和资源配额（Quota）。比如在执行命令时，强制加上 timeout 30s，防止 Agent 陷入死循环。
具体到实操，一个能够自我修复的 Agent 工作流应该是这样的：
1. Agent 接收任务 → 编写 Shell 命令。
2. 在 VM 中执行 bash -c "command"。
3. 捕获返回值：如果 exit code != 0 → 将报错信息反馈给 LLM。
4. LLM 分析报错 → 修改命令 → 重新执行。
这种“尝试-报错-修正”的闭环，比单纯地在 Prompt 里告诉它“请确保代码正确”要高效得多。
- 执行环境： 从共享的容器（Container）升级到独立的 MicroVM，彻底隔离了不同任务的依赖冲突。
- 反馈机制： 实时获取 OS 级别的 stderr，让 Agent 具备了真正的“感知”能力。
- 部署成本： 虽然比纯 Serverless 贵，但换来的是一个完整的 Linux 运行时，这意味着 Agent 可以运行任何二进制文件，而不仅仅是 Python 脚本。
说白了，AI Agent 如果没有一个能掌控的“物理空间”（哪怕是虚拟的），它永远只是个会说话的翻译机。给它一台电脑，它才真正变成了能干活的员工。这种从“对话式 AI”转向“计算机式 AI”的趋势，应该是接下来的一个关键转折点。
