1. Cloudflare Containers, rebuilt to scale agent sandboxes

推荐理由： 这篇不是泛泛讨论“给 Agent 一个容器”，而是从真实 agent workload 反推执行环境应该具备什么：按任务动态创建、快速启动、暂停后释放计算、恢复时保留工作区，并把 sandbox 的 identity / state / policy / lifecycle 放在容器外部管理。它非常接近未来 coding-agent runtime 的基础设施形态。

核心要点：

  • Agent sandbox 与传统长驻容器的需求不同：coding agent 需要 repo、package manager、compiler、test runner 和 dev server；eval 需要从确定状态启动；RL 需要批量创建、评分和重置环境；长任务则需要跨 session 保留文件状态。
  • Cloudflare 新的 durable_object scheduling policy 允许运行时选择 image 和 compute resources，Container 启动速度提升超过 6x；filesystem snapshots 可以保存和恢复 workspace，使 compute 在等待模型或用户时停止，而任务恢复时继续使用原来的文件状态。
  • 更重要的是架构拆分：Durable Object 可以保留 agent/session 的 identity、state、policy 与 lifecycle，而 Linux Container 只承担可替换的执行环境。这对应“brain 与 hands 分离”的模式：agent loop 持续存在，sandbox 可以启动、停止、失败和重建。

核心启示：Agent runtime 不应只是“一个能跑 shell 的容器”，而应是 persistent control plane + disposable execution sandbox + snapshot/resume。长时程 Agent 的状态和计算生命周期必须解耦。

2. Detect and send production issues straight to your agent

推荐理由： 这篇补上了 software factory 中经常缺失的一段：Agent 能写代码、测试和开 PR，但生产故障仍然需要人把 telemetry 手工整理成 prompt。Cloudflare Issues 把 error detection、context assembly 和 coding-agent handoff 串成自动反馈回路，让 deploy → observe → diagnose → fix 开始真正闭环。

核心要点：

  • Issues 会把重复 exception、5xx 和错误日志聚合成同一问题，并把 error、source-mapped stack trace、前后日志、traces、Worker version 以及应用自定义 context 一起交给 coding agent，而不是让 Agent 从海量原始 telemetry 中重新推断问题边界。
  • 当问题达到 occurrence threshold 或沉寂后再次出现时，automation 可以自动触发 Claude Code、Cursor、Devin 或自定义 webhook；Agent 还可以通过 MCP 继续查询相关 logs / traces，再修改代码、运行测试并打开 PR。
  • 这里仍保留清晰的人类控制边界：Agent 可以诊断和提出修复，但生产部署仍经过 review。Cloudflare 自己在 Workflows 服务上启用后，一天内发现了两个隐藏在大量流量中的异常问题。

核心启示：AI-native observability 的目标不只是“让 Agent 能查日志”，而是把生产信号预先结构化成可执行 context，并自动触发 incident → evidence → agent → patch → verification 的 feedback loop。