在刚刚过去的这一年里，人工智能的发展轨迹正在发生一次深刻的范式转移：从仅仅停留在对话框里生成文本的大语言模型（LLM），大步迈向能够自主规划、调用工具、甚至操作计算机界面的自主智能体。当我们赋予 AI 操纵浏览器的权限去预订机票，或者赋予它终端权限去编写和调试代码时，一个严峻的基础设施挑战随之浮出水面——我们如何安全地运行它们，又如何实时地“看”到它们在干什么？在现代云原生架构下，为每个 Agent 分配一个短暂、隔离的 Kubernetes 容器沙箱（Sandbox）是运行安全的基础；而通过 Web VNC（Virtual Network Computing）技术将沙箱内的图形化桌面流式传输到前端浏览器，则是实现可观测性的最佳手段。
在 AI 驱动的数据应用场景中，企业越来越需要一套同时支撑实时消费、历史沉淀与多引擎复用的数据底座。Kafka、Iceberg 开放表格式与对象存储的组合，正成为流数据入湖的重要方向。但传统依赖 Flink、Spark 等外部 ETL 作业的方式，也带来了链路长、系统边界多、运维复杂等问题。本文围绕“零 ETL”这一趋势，讨论流数据入湖为什么需要做架构减法，并结合 Kafka × Table Bucket 的实践，分析一种将通用入湖能力前移到消息与表存储链路中的方案，如何在降低复杂度的同时，兼顾实时性、一致性、Schema 演进、CDC 语义与开放生态兼容。
此前已有不少文章围绕 Agent 自进化这个主题展开过讨论，内容涵盖了 Hermes Agent 等自进化框架，以及 Skill 自进化等具体技术方向。而最近，AI 领域又出现一个新的概念，叫做 Loop（循环）或者叫 Loop Engineering（中文翻译一般叫“循环工程”）。因此，本文将重点聊聊这个话题，尽量系统化地介绍一下 Loop 与 Loop Engineering 究竟是什么，以及它们背后有哪些思考。
