2025-09-03 17:16:04
在实际使用 Manus、Genspark、ChatGPT Agent 和 GitHub Spark 等 AI Agent 时，我常常思考这些智能体背后是如何创建和管理运行环境的——它们采用的是容器技术，还是有其他专门的基础设施？带着这个疑问，我调研了当前主流的云端 Agent 运行方案，发现 E2B 和 Browserbase 是业内较为突出的代表。两者分别在“代码沙盒”和“浏览器自动化”领域提供了创新的 Agent 基础设施，值得深入分析其技术架构和应用模式，以便理解 AI Agent 运行环境的最新发展趋势。
E2B（Enterprise to Bot） 由 Václav Mlejnský（花名 Vasek）和 Tomáš Valenta 于 2023 年创立。两位创始人是从捷克数学物理学院毕业的挚友，曾在计算机视觉等领域合作，后因 GPT-3.5 的出现萌生灵感，转向打造 AI Agent 基础设施。E2B 在创立之初即定位于构建开放源代码的 AI Agent 云端运行平台，让每个 AI Agent 都拥有自己的云端“小电脑”。公司早期获得 300 万美元起步（pre-seed）投资，由 Kaya VC 和 Sunflower Capital 领投，并有 Vercel CEO Guillermo Rauch 等知名创业者参与。不到一年内又于 2024 年宣布 1,150 万美元的种子轮融资（由 Decibel Partners 合伙人 Alessio Fanelli 领投）。最新的 A 轮融资 2,100 万美元 则在 2025 年 7 月完成，由 Insight Partners 领投，使公司总融资额达到约 3,200 万美元。E2B 总部设于旧金山，并在快速扩张团队，以满足全球日益增长的需求。
Browserbase 则是一家总部位于旧金山的创业公司，由 Paul Klein IV 于 2024 年初创立。Klein 曾是 Twilio 工程师，后创业直播软件并成功出售，对大规模浏览器自动化有深刻经验。Browserbase 专注于提供云端无头浏览器基础设施，帮助开发者和 AI Agent 自动化执行复杂的网页任务。公司在 2024 年 6 月推出开放注册平台并宣布获得 650 万美元种子融资，由 Kleiner Perkins 领投。仅 9 个月后，Browserbase 于 2024 年 11 月完成 2,100 万美元 A 轮（由 CRV 和 Kleiner Perkins 共同领投，Okta 等参投）。2025 年 6 月，公司再获 4,000 万美元 B 轮融资，领投方为 Notable Capital，投后估值达到 3 亿美元，比 A 轮估值翻了近四倍。截至 2025 年中，Browserbase 成立仅约 16 个月，团队规模已达 30 人，拥有超过 1,000 家付费客户。下表列出两家公司关键发展节点：
E2B 的核心产品是一个为 AI Agents 提供云端沙盒环境的平台。这一平台以开放架构为基础，允许每个 AI Agent 即时获取一个隔离、安全的小型虚拟计算机，内置真实世界的开发工具和操作系统环境。通过这些沙盒，Agent 可以安全地执行代码、访问文件系统、调用终端指令，甚至联网等，从而完成复杂的多步骤任务。E2B 强调高安全性和可扩展性：沙盒采用从底层强化的隔离技术，支持在公有云或企业自有基础设施上弹性启停数以万计的实例。开发者可以通过 E2B 提供的 JavaScript/TypeScript 或 Python SDK 调用 API 来启动和控制沙盒。E2B 的方案让企业可以“赋予每个 AI Agent 一台自己的云电脑”，典型功能和场景包括：
E2B 沙盒支持任意编程语言和框架，即插即用。例如，开发者可在几行代码内调用 Sandbox，对 Agent 给出的代码片段进行执行并返回结果。沙盒的启动延迟极低（接近即时开启），可长时间保持运行，并提供监控和日志工具，方便追踪 Agent 行为。E2B 正积极将其打造成 Agent 领域的开放标准和接口，未来不仅支持 Linux 容器，也将扩展到 Windows VM、Chrome 无头浏览器等多种环境，并兼容 Kubernetes、AWS、Azure 等多云部署。正因功能完备且开源开放，E2B 平台已成为企业级 Agent 工作流事实标准之一。
Browserbase 的核心产品是一个可大规模运行无头浏览器的云平台。它为 AI 应用和自动化脚本提供“Web 浏览器 as a Service”，让 AI Agent 能像人一样使用浏览器与网页交互，但无需真实图形界面。Browserbase 平台的主要特点包括：
Browserbase 的定位是充当 AI 软件栈中的关键组件，被形容为 AI 应用的“眼睛和耳朵”，为上层的 LLM“大脑”提供与互联网交互的能力。其平台让 AI Agent 能像真人用户那样使用网页：例如，一个 Agent 可以借助 Browserbase，在航旅网站搜索航班并自动完成预订；或在企业内部网页系统中填写报表数据。由于这些自动化需求随着 AI 普及正变得非常广泛，Browserbase 还开发了“Director”产品，一款面向非开发者的零代码Web 自动化工具。Director 基于 AI 自动生成浏览器脚本，让业务人员通过简单的提示词就能构建并运行跨网站的自动化流程，从而将 Browserbase 的强大功能拓展到更广泛的企业用户和场景。
总的来说，E2B 偏重于通用的代码执行沙盒，赋予 AI Agent 计算和编程能力；Browserbase 则专注网页交互领域，让 AI Agent 获取互联网“前端操作”能力。两者都属于 Agent Infra（Agent 基础设施） 的重要组成，为下一代智能体应用提供底层支持。
E2B 的商业模式可以概括为“开源核心 + 云服务增值”。其核心技术开放源码，开发者可免费试用和自建，但 E2B 同时提供托管的沙盒云服务。官方云平台采用 SaaS 订阅 + 按用量计费的方式：基本的“Hobby”计划免费（赠送价值 100 美元的计算额度，无需信用卡）；高级的“Pro”计划每月订阅费 $150 美元，享受更高并发和更长会话时长等扩展能力，并同样按实际沙盒用量收费。使用费用基于 CPU 秒和内存占用计量，如默认 2 核 CPU 沙盒费用 $0.000028/s，内存每 GiB 每秒 $0.0000045。大型企业客户可以选择“Ultimate”方案，由 E2B 提供定制化部署和支持，价格按需洽谈。此外，E2B 提供自部署选项，企业可按照开源项目提供的 Terraform 脚本将沙盒基础设施部署在自有云环境（支持 AWS、GCP、Azure 等）。这一开放 + 商用模式既吸引了开发者社区参与，又通过企业服务实现盈利。E2B 的主要客户包括对 AI Agent 有强烈需求的科技公司与大企业：例如 Hugging Face 和 LMArena 用 E2B 来安全地扩展 AI 实验；问答搜索创业公司 Perplexity 通过 E2B 一周内上线了面向付费用户的代码分析功能；芯片创业公司 Groq 利用 E2B 获得高速安全的代码执行环境。官方披露已有 88% 的财富 100 强企业注册试用 E2B 平台，这显示出传统大型企业也在积极探索将 Agent 引入自身流程。E2B 帮助这些企业以更低的开发成本实现 AI 自动化场景，同时保证安全合规，因此获得高度认可。
Browserbase 的商业模式是典型的云端 API 服务。开发者通过付费获得 Browserbase 平台的 API 访问权限，按实际使用的浏览器实例数量和时长付费。这种 usage-based 模式使客户初期可以小规模按需使用，随着应用扩展再逐步增加支出。据报道，2025 年 Browserbase 已实现年度经常性收入超过 300 万美元，主要来自现有团队不断扩大的使用量，而不仅仅是新客户增长。可见其客户在尝试平台后往往会加大投入，将更多业务交给 Browserbase 自动化。为吸引开发者，Browserbase 也提供一定的免费额度或试用机制，并在 2024 年开放了自助注册，使任何开发者都能方便上手平台。除了基础的按量计费，Browserbase 也非常重视企业客户需求，尤其在安全合规方面：A 轮融资公告时，公司即启动了 SOC2 Type1 审计和 HIPAA 合规，以便更好服务医疗、金融等对数据安全要求极高的行业客户。另外，Browserbase 新推出的 Director 零代码工具，预示着其商业模式可能拓展到高级订阅或按席位授权等形式，对非技术用户提供友好的界面和支持。这将吸引那些没有开发团队但有自动化需求的中小企业，扩大全球客户基础。当前，Browserbase 的客户群涵盖各类规模的科技公司：从专注 AI Agent 的初创企业、B2B 软件公司、专业服务机构，到需要网页数据采集的风控/营销团队，以及 web UI 自动化测试的开发团队。已知用户包括医疗数据平台 Commure、新一代搜索公司 Perplexity、前端云平台 Vercel 等超过 1000 家公司。随着 Director 等产品降低使用门槛，Browserbase 有望进一步渗透非互联网行业的长尾市场，为更广泛的业务场景提供 AI 驱动的浏览器自动化解决方案。
综上，E2B 和 Browserbase 都采用了“以开发者为中心”的增长策略：前期提供免费/开源工具聚拢人气，证明技术价值后，再通过企业级功能和服务实现商业变现。一者围绕代码执行沙盒，一者专注浏览器自动化，各自找到了明确的客户痛点并验证了付费需求。在人工智能助力传统行业的大趋势下，他们的商业模式都具备良好的可扩张性和可持续性。
两家公司都非常注重开源社区，积极推出开源项目以扩大开发者影响力，同时通过社区反馈完善自身产品。
E2B 的核心代码以 Apache 2.0 协议开源，GitHub 仓库名为 E2B（e2b-dev/E2B）。该项目提供启动和控制云沙盒的 SDK，以及自托管部署指南。目前该仓库拥有约 9.4k 个星标（stars）、650+ 个派生（forks），社区活跃度较高。开发者可以自由查看、修改源码，并通过提交 PR 参与共建。除了核心 Sandbox SDK，E2B 团队还开源了 E2B Desktop 项目。E2B Desktop 是一个让 LLM 连接图形桌面的沙盒方案，支持屏幕流式传输、远程鼠标键盘控制等功能，为 Agent 提供类似人类使用电脑的能力。该仓库星标数约1.1k，体现了一定的社区关注度。E2B 的开源技术栈主要为 TypeScript/Node.js（后端沙盒管理和 SDK）和 Python（提供 Python 绑定），底层通过 Terraform 等实现云厂商无关的部署。E2B 社区还维护了 Cookbook 知识库，汇集不同 LLM 和框架结合沙盒的示例代码，方便开发者学习。整体来看，E2B 通过开源树立了技术透明和可靠形象，大量开发者每月从 npm 和 PyPI 下载其 SDK 超过百万次。社区用户也在 Discord 频道（超过数千成员）分享经验、反馈问题，使 E2B 开发迭代能够快速响应实际需求。
Browserbase 将部分重要工具以开源方式释放出来，最大程度拥抱开发者生态。首先是旗舰项目 Stagehand——一个 AI 驱动的浏览器自动化框架。Stagehand 由 Browserbase 开发并在 2024 年底开源推出，旨在将自然语言指令转化为浏览器操作代码。它允许开发者按需选择代码或 AI 来实现网页操作：熟悉流程的部分用 Playwright 等代码实现，不确定的部分让 AI 模型自动生成操作步骤。Stagehand 提供了预览和缓存机制，以及内置集成 OpenAI 和 Anthropic 的“Computer Use”大模型，极大降低了构建可靠浏览器 Agent 的难度。该项目采用 MIT 开源许可证，目前在 GitHub 上已累积约 16.6k 个星标，超过 1k forks，显示出爆炸性的人气。除了 TypeScript 实现，官方也提供了Python 版本的 Stagehand 以满足不同语言开发者需求。另一重要开源组件是 Browserbase MCP Server。MCP 代表“Model Context Protocol”，它是一个开放协议，用于标准化 LLM 应用与外部工具/数据源的对接。Browserbase 提供的 MCP Server 模块让 LLM 可以通过 MCP 协议调用 Browserbase 的云浏览器功能，实现截图、表单填写、数据提取等操作。该仓库也获得2.5k+ 星标，成为 Agent 开发者常用的桥接工具。此外，Browserbase 官方还发布了一些示例工程和模板，如 Open Operator 项目，演示如何结合 Next.js、React、Browserbase 和 Stagehand 快速构建 Web Agent 应用。Browserbase 的 SDK 客户端（Node.js 和 Python）同样开源，便于开发者查阅其实现和自行定制。Browserbase 开源项目多采用 TypeScript/JavaScript 编写，充分利用现代前端和云原生技术栈，其社区交流主要在 Slack 上进行。Paul Klein 等创始团队成员也活跃在开源社区，直接解答问题、征求改进意见。可以说，Browserbase 通过开源牢牢抓住了开发者的心：Stagehand 等项目已成为业内事实标准之一，有开发者评价其为浏览器自动化的“自然选择”。这种繁荣的开源生态也反哺了 Browserbase 商业产品，不断有优秀社区创意融入商业功能，增强了平台的竞争力。
注：以上数据截止至 2025 年 9 月。
在深入了解 E2B 与 Browserbase 的技术架构和生态后，下面将从核心定位、主要功能、目标用户、商业模式及开源生态等维度对两者进行系统性对比。通过表格形式，帮助读者快速把握两款云端智能体基础设施的异同与各自优势。
| 对比维度 | E2B（AI 沙盒云） | Browserbase（云浏览器平台） |
|---|---|---|
| 核心定位 | 开源的云端安全沙盒，赋予 AI Agent 代码执行与计算环境；被誉为“AI 代理的云电脑” | 托管的浏览器基础设施，提供高性能无头浏览器集群供 AI 使用；可视作“AI 的互联网接口” |
| 主要功能 | ⚡即时沙盒：秒级启动隔离的 Linux VM/容器，内置sudo权限和丰富开发工具; ⚡ 安全执行：让 Agent 安全跑任意代码、脚本，支持文件 I/O、网络请求等; ⚡ 持续会话：沙盒可长时间保持，支持状态保存和多步骤任务; ⚡ 多云兼容：可在公有云或本地部署，自由扩展 | ⚡浏览器自动化：云端运行 Chrome/Firefox 等无头浏览器，兼容 Puppeteer/Playwright 脚本; ⚡ 网页交互：Agent 能模拟用户操作，如点击、填表、截屏和抓取数据; ⚡ 抗干扰：提供防检测机制、全球代理网络，确保脚本稳健运行; ⚡ 可视编排：Director 工具用自然语言生成自动化脚本，降低使用门槛 |
| 目标用户 | AI 应用开发者、数据科学家、创新团队；对让 LLM 执行代码、有自动化能力有需求的科技公司和研究机构；已延伸至部分财富百强传统企业 | 首批为 AI Agent 创业公司、Web 自动化开发者服务；逐步拓展到非编程用户（运营、市场等）借助 AI 实现业务自动化；覆盖全球各行业中小企业 |
| 商业模式 | 开源社区 + 云服务收费：核心代码免费开放；提供官方 SaaS 按订阅及用量收费；为大型企业提供定制部署和支持服务 | 在线 API 服务：提供免费试用吸引开发者，按浏览器实例用量计费；通过高级功能（如全球区域部署、企业认证）及 No-Code 工具拓展付费点；投资机构、云厂商（如 Okta）亦为其生态合作伙伴 |
| 开源生态 | 核心 Sandbox SDK 开源 (9k+⭐)；附属桌面 GUI 沙盒开源 (1k+⭐)；社区在 Discord 活跃，贡献插件与教程 | 开源 AI 浏览器框架 Stagehand (16k+⭐)；MCP 接入模块 (2.5k⭐)；官方提供 Node/Python SDK 源码；Slack 社区维护者众多，联合创新频繁 |
从上表可见，E2B 和 Browserbase 都专注于垂直领域并积极拥抱开源社区。E2B 专注于“运行时/沙盒”环节，为 AI Agent 提供安全、隔离的代码执行环境，并通过开放接口与记忆、规划等其他模块集成。Browserbase 则深耕浏览器交互场景，通过极致优化和开源框架在云端浏览器自动化领域占据领先地位。技术生态方面，E2B 支持在 AWS、Azure 等主流云平台部署，兼容各种 LLM；Browserbase 支持 OpenAI、Anthropic 等主流模型作为 Agent driver，并为开发者提供丰富的开源工具和 SDK。商业模式上，E2B 和 Browserbase 均以开发者为中心，采用灵活的 SaaS 收费策略，主要面向欧美市场的创新公司和企业客户。两者通过持续技术迭代和社区共建，巩固了在 AI Agent 基础设施领域的领先地位。
在全球范围内，AI Agent 基础设施正成为人工智能领域新的热点赛道。欧美市场方面，E2B 和 Browserbase 作为先行者，已取得显著影响力：
值得一提的是，开源在此领域扮演了关键角色。开源是 AI 时代基础设施的核心策略。E2B 和 Browserbase 凭借开源先发，已聚拢了大量开发者共创生态。这预示着未来全球将出现开放合作的格局，各参与者在一定程度上通过标准和协议互联互通，共同做大市场蛋糕。
AI Agent 基础设施在全球正呈现蓬勃发展和加速演进的态势。E2B 联合创始人曾比喻：“就像 iPhone 应用需要 iOS，每个智能代理都将依赖自己的安全计算环境”。可以想见，在未来五到十年，赋予 AI Agent“身体”和“工具”的基础设施将像今日的云计算一样无处不在，成为数字经济的新型底座。欧美市场的创新动能与亚洲市场的规模实践相互作用，必将推动这一领域不断成熟。从当前看，E2B 与 Browserbase 已奠定先机，占据了技术和社区的高地。在这个“Agent 元年”开启之际，全球技术生态正围绕如何让 AI 更好地为人类工作而迅跑。可以预期，在多方力量推动下，AI Agent 基础设施将迎来快速迭代与标准化浪潮，成为下一代人工智能落地的关键加速器。
2025-09-03 11:15:27
随着 AI 技术的爆发式发展，基础设施被提出了前所未有的高要求。Kubernetes 作为 Cloud Native（云原生）时代的事实标准，在 AI Native 时代正面临全新的挑战：更高级的算力调度、异构资源管理、数据安全与合规，以及更加自动化和智能化的运维等。传统的云原生实践已无法完全满足 AI 工作负载的需求，Kubernetes 若想保持自身的相关性，就必须与时俱进地演化。这对于已经走过近十年发展的 Kubernetes 来说是一个重要命题——笔者自 2015 年 Kubernetes 开源伊始就开始关注并在社区布道 Kubernetes，转眼间它已经成为基础设施领域的“常青树”，如今在 AI 浪潮下是时候重新审视它的角色与前景了。
Kubernetes 在 AI Native 时代的角色正在发生转变。从前它是微服务时代的明星，被誉为“云端的操作系统”，负责在多样环境中可靠地编排容器化工作负载。但 AI 原生的工作负载（尤其是生成式 AI 时代之后）有着本质的不同，可能让 Kubernetes 退居幕后成为“隐形的基础设施”——重要但不再是显性创新发生的舞台。具体而言，大型 AI 模型的训练和托管常常发生在超大规模云厂商（Hyperscaler）的专有基础设施上，很少离开那些深度集成的环境；模型推理服务则越来越多地通过 API 形式对外提供，而不是作为传统应用容器部署。此外，训练任务的调度对 GPU 感知、高吞吐的需求远超以往，往往需要借助 Kubernetes 之外的专门框架来实现。因此，AI Native 软件栈的分层方式也与云原生时代有所不同：在新的架构中，最上层是 AI Agent 和 AI 应用，其下是上下文数据管道和向量数据库等数据层，再下层是模型及其推理 API 接口，底层则是加速计算基础设施。在这样分层的体系中，如果不做出改变，Kubernetes 可能沦为背后的“底层支撑”——依然重要，但不再是创新的前台舞台。
即使在 AI 时代，Kubernetes 仍不可或缺，尤其在混合部署（本地数据中心 + 云）、统一运维以及 AI 与传统应用混合工作负载等场景下，Kubernetes 依然是理想的控制平面。然而，要避免退居幕后，Kubernetes 必须正视并解决 AI 工作负载带来的特殊挑战，包括：
Run:ai 之类框架的功能。AI 模型训练常涉及大量 GPU 任务调度，Kubernetes 需要更智能地分配这些昂贵资源，以提高利用率。上述这些正是 Kubernetes 在 AI 原生时代必须直面的课题。如果不能在这些方面有所突破，Kubernetes 的地位可能会从战略核心变为背景中的基础设施管道——有用但不再举足轻重。
云原生技术栈主要围绕微服务架构、容器化部署和持续交付来构建，核心包括容器、Kubernetes 编排、服务网格、CI/CD 流水线等，重视应用的快速迭代部署、弹性伸缩和可观测性。而 AI 原生技术栈在此基础上向更深层次扩展，侧重于异构算力调度、分布式训练以及高效推理优化等方面。换言之，在云原生的基础设施之上，AI 原生场景引入了许多专门针对 AI 工作负载的组件：包括分布式训练框架（如 PyTorch DDP、TensorFlow MultiWorker）、模型服务化框架（如 KServe、Seldon）、高速数据管道和消息系统（如 Kafka、Pulsar）、新的数据库类型如向量数据库（Milvus、Chroma 等）以及用于追踪模型性能的观测工具等。CNCF 于 2024 年发布的云原生 AI 白皮书中给出了一张技术景观图，清晰地展示了 AI Native 如何扩展了 Cloud Native 的边界，在原有技术栈上叠加了诸多 AI 特定的工具和框架。
下面我们按照领域列举云原生/Kubernetes 生态中与 AI 密切相关的一些典型开源项目，来体现 Cloud Native 与 AI Native 技术栈的异同。
Kubernetes 本身依然是底座，但为更好地支持 AI 任务，出现了诸多在 Kubernetes 之上增强调度能力的项目。例如，Volcano 提供面向批处理和机器学习作业的调度优化，支持任务依赖和公平调度；KubeRay 则通过 Kubernetes 原生控制器来部署和管理 Ray 集群，使大规模分布式计算框架 Ray 可以在 Kubernetes 上弹性伸缩。这些工具强化了 Kubernetes 对 AI 工作负载（尤其是需要占用大量 GPU 的任务）的调度治理能力。
针对大规模模型的分布式训练，社区也提供了成熟的解决方案。Kubeflow 的 Training Operator 就是典型代表，它为 Kubernetes 提供自定义资源来定义训练作业（如 TensorFlow Job、PyTorch Job），自动创建相应的 Master/Worker 容器以在集群中并行训练模型。此外，像 Horovod、DeepSpeed、Megatron 等分布式训练框架也能在 Kubernetes 环境下运行，通过 Kubernetes 来管理跨节点的训练进程和资源配置，以实现线性扩展的模型训练能力。
在模型训练完成后，如何将模型部署为在线服务也是 AI Native 技术栈的重要组成部分。在 Kubernetes 生态中，KServe（前身为 KFServing）和 Seldon Core 是两大常用的模型服务框架，提供了将训练后的模型打包成容器并部署为可自动扩缩的服务的能力。它们支持流量路由、滚动升级和多模型管理，方便地在 Kubernetes 上实现 AB 测试和 Canary 发布等。近年兴起的 vLLM 则是专注于大语言模型（LLM）高性能推理的开源引擎，采用高效的键值缓存架构以提升吞吐，并支持在 Kubernetes 集群上横向扩展部署。例如，vLLM 项目已经从单机版发展出面向集群的“vLLM production-stack”方案，可以在多 GPU 节点上无缝运行，通过共享缓存和智能路由实现比传统推理服务高数量级的性能提升。
在模型从开发到部署的生命周期中，涉及数据准备、特征工程、模型训练、模型评估到上线部署的一系列步骤。Kubeflow Pipelines 等工具在 Kubernetes 上提供了端到端的机器学习工作流编排机制，允许将上述步骤定义为流水线并运行在容器之中，实现一键式的训练到部署流程。同时，诸如 MLflow 等工具与这些流水线集成，用于追踪实验指标、管理模型版本和注册模型，结合 BentoML 等模型打包工具，可以方便地将模型以一致的方式打包部署到 Kubernetes 集群。
数据科学家常用的 Jupyter Notebook 等交互式开发环境也可以通过 Kubernetes 来提供。像 Kubeflow Notebooks 或 JupyterHub on Kubernetes 让每位用户在集群中获得独立的容器化开发环境，既方便调用大规模数据集和 GPU 资源，又保证不同用户/团队的隔离。这实质上将云原生的多租户能力应用到数据科学场景，使 AI 研发能够在共享的基础设施上进行而不彼此干扰。
在 AI 场景下，系统监控和性能追踪同样不可或缺。云原生领域成熟的监控工具如 Prometheus 和 Grafana 仍然大显身手，可以收集 GPU 利用率、模型响应延迟等指标，为 AI 工作负载提供监控报警。同时，OpenTelemetry 等开放标准为分布式跟踪提供了基础，使跨服务的调用链路分析也适用于模型推理请求的诊断。另外，Weights & Biases（W&B）等机器学习实验跟踪平台在模型训练阶段广泛应用，用于记录模型指标、超参数和评估结果。而面对大语言模型的新挑战，一些新兴工具（如 Langfuse、OpenLLMetry 等）开始专注于模型层面的观测，提供对生成内容质量、模型行为的监控手段。这些工具与 Kubernetes 的集成，使运维团队能够像监控传统微服务那样监控 AI 模型的表现。
为提高模型开发效率，许多团队会使用超参数调优和自动机器学习工具来自动搜索模型的最佳配置。Kubeflow Katib 是一个 Kubernetes 原生的 AutoML 工具，它通过在集群中并行运行大量实验（每个实验跑一个模型训练作业）来试验不同的超参数组合，最终找到最优解。Katib 将每个实验封装为 Kubernetes Pod 并由 Kubernetes 调度，从而充分利用集群空闲资源。类似的还有微软的 NNI (Neural Network Intelligence) 等，也支持在 Kubernetes 上运行实验以进行自动调参和模型结构搜索。
AI 应用对数据的需求促使传统的大数据技术与云原生结合得更加紧密。一方面，像 Apache Spark、Flink 这类批处理和流处理引擎已经可以在 Kubernetes 上运行，通过 Kubernetes 来管理它们的分布式执行和资源分配。同时，Kafka 和 Pulsar 等消息队列、HDFS、Alluxio 等分布式存储也都可以以 Operator 形式部署在 Kubernetes 集群中，为 AI 工作负载提供弹性的数据管道和存储服务。另一方面，新兴的向量数据库（如 Milvus、Chroma、Weaviate 等）成为 AI 技术栈中特有的组件，用于存储和检索向量化的特征表示，在实现相似度搜索、语义检索等功能时不可或缺。这些向量数据库同样能够部署在 Kubernetes 上运行，有些还提供 Operator 来简化部署管理。通过 Kubernetes 来托管这些数据基础设施，团队可以在同一套集群上同时管理计算（模型推理/训练）和数据服务，实现计算与数据的一体化调度。
在 AI Native 场景中，服务网格不仅仅是传统的东西南北流量治理工具，还逐渐演化为 AI 流量网关。例如：
这些项目的出现表明，Service Mesh 技术正从 “微服务的流量治理” 扩展为 “AI 应用的智能流量与 Agent 协作底座”。在 AI Native 架构中，服务网关 + 网格化治理将成为连接 LLM、Agent 与传统微服务的重要桥梁。
通过以上概览可以看出，Cloud Native 生态正在快速扩展以拥抱 AI 场景，各类开源项目让 Kubernetes 成为了承载 AI 工作负载的平台底座。Kubernetes 社区和周边生态正积极将云原生领域的成熟经验（如可扩展的控制平面、声明式 API 管理等）应用到 AI 领域，从而在 Cloud Native 与 AI Native 之间架起桥梁。这种融合既帮助 AI 基础设施继承了云原生的优良基因（弹性、可移植、标准化），也让 Kubernetes 通过扩展和集成保持在 AI 浪潮中的生命力。
需要注意的是，Kubernetes 本身的易用性和抽象层次也在受到新的审视。随着 Kubernetes 成为“底座”，开发者希望与之交互的方式变得更简单高效。社区中不乏关于“Kubernetes 2.0”的探讨，有观点认为当前繁琐的 YAML 配置已经成为生产实践中的痛点：据报道称多达 79% 的 Kubernetes 生产故障可追溯到 YAML 配置错误（例如缩进、冒号错漏等）。“YAML 疲劳”引发了对更高级别、更智能的操作界面的呼声，一些人畅想未来的 Kubernetes 将弱化对手工编写 YAML 的依赖，转而采用更自动化、声明意图更简洁的方式来部署应用。例如，有传闻中的“Kubernetes 2.0”雏形展示了不再需要 Helm Chart 和成百上千行 YAML，仅用一条类似 k8s2 deploy --predict-traffic=5m 的指令即可完成部署的设想。尽管这些还停留在设想或早期尝试阶段，但折射出业界对 Kubernetes 易用性的期待：即在保证强大灵活的同时，尽量降低认知和操作负担。这对于支持复杂的 AI 工作负载尤为重要，因为用户更关心模型本身的迭代，而不希望被底层繁琐的配置细节绊住手脚。
最后，正如 Kubernetes 项目主席（名誉）Kelsey Hightower 所言，如果基础设施的演进符合预期，那么 Kubernetes 终将“消失”在前台，变成像今天的 Linux 一样稳定而无处不在的底层支撑。这并不是说 Kubernetes 会被弃用，而是说当 Kubernetes 足够成熟并被更高层的抽象所封装后，开发者无需感知其中细节，但它依然默默地提供核心能力。这种“淡出视野”恰恰意味着技术的进一步进化。面对 AI 原生时代，Kubernetes 也许不会以原来的样子出现于每个开发者面前，但它很可能以内嵌于各种 AI 平台和工具的形式继续发挥作用——从云到边缘，无处不在地提供统一的资源调度与运行时支持。Kubernetes 一方面需要保持内核的稳定与通用性，另一方面也应该鼓励在其之上构建面向特定领域的上层平台，就如同早期云原生生态中出现的 Heroku、Cloud Foundry 那样，在 Kubernetes 之上为不同场景提供更简化的用户体验。
综上所述，Kubernetes 在 AI Native 时代既面临挑战又充满机遇。只要社区能够顺应潮流，不断演进 Kubernetes 的能力边界并改进易用性，我们有理由相信 Kubernetes 会成为 AI 时代混合计算基础设施的核心支柱，继续在新的十年里发挥不可替代的作用。
在 Cloud Native 时代，Kubernetes 等基础设施工具的开源不仅意味着源代码开放，更意味着开发者可以在本地完整编译、重构、定制和运行这些工具。社区拥有高度的可控性和创新空间，任何人都能基于开源项目进行深度二次开发，推动生态繁荣。
而在 AI Native 时代，虽然许多大模型（如 Llama、Qwen 等）以“开源”名义发布，甚至开放了模型权重和部分代码，但实际可重构性和可复现性远低于 Cloud Native 工具。主要原因包括：
这种差异导致 AI Native 时代的“开源”更多是一种有限开放：开发者可以使用和微调模型，但很难像重构 Kubernetes 那样深度定制和创新。真正的开源 AI 仍在探索阶段，未来需要解决数据开放、工具链标准化和法律治理等多重挑战，才能实现 Cloud Native 式的开放协作。
在云原生领域，CNCF（Cloud Native Computing Foundation）等基金会通过统一治理、项目孵化和社区协作，极大推动了 Kubernetes 及相关生态的繁荣。然而，AI 领域至今尚未出现类似 CNCF 的统一开源基金会来统筹 AI 基础设施和生态发展。究其原因，主要有以下几点：
目前，AI 领域的开源基金会主要以“项目孵化 + 社区支持”为主，例如 LF AI & Data 支持 ONNX、PyTorch、Milvus 等项目，但尚未形成 CNCF 式的统一技术景观和治理体系。未来，随着 AI 技术标准化和生态成熟，或许会出现类似 CNCF 的统一基金会，但短期内仍以分散治理和多元协作为主。
这一现状也反映在 Kubernetes 与 AI 的融合路径上：Kubernetes 作为云原生的底座，依赖 CNCF 的治理和生态推动，而 AI 领域则更多依靠各自项目和社区的自发协作。只有当 AI 技术栈趋于标准化、行业需求趋同，才有可能诞生类似 CNCF 的统一基金会，推动 AI 基础设施的开放创新。
Kubernetes 在 AI Native 时代正从云原生的“明星”转型为 AI 应用背后的基础平台。面对异构算力、海量数据和智能运维等新需求，Kubernetes 需主动与 AI 生态深度融合，通过插件扩展和框架集成，成为统一承载传统应用与 AI 系统的混合算力底座。无论在混合云还是企业数据中心，Kubernetes 依然是 AI 工作负载不可或缺的核心基础设施，只要持续演进，其在 AI 时代的关键地位将得以巩固。
2025-09-02 14:59:30
“Vibe Coding”是由 Andrej Karpathy 提出的概念，指的是—— “一种新的编程方式……你完全融入氛围，忘记代码本身的存在” 。
Vibe Coding（氛围编程）强调“通过自然语言／语境驱动开发”、“人机协作胜于纯手写代码”，定位在原型、创意、轻量化开发场景。与之相关的“Agentic Coding”则更进一步—不仅生成代码，还能计划、执行、循环验证。本文作为《AI 编程与氛围编程工具研究》的姊妹篇，全面补充当前市面上主流与新兴的氛围编程工具对比，包括独立 IDE、IDE 插件以及终端/CLI 工具，分析其开源程度、Agent 能力、模型接入方式与典型应用场景。
下面将从工具结构的角度，系统梳理当前氛围编程领域的主流解决方案，帮助你快速了解不同类型工具的优势与适用场景。
| 工具 | 公司/组织 | 开源 | 特色能力 |
|---|---|---|---|
| Cursor | Cursor | 否 | Tab 代码补全 + Agent |
| Windsurf | Windsurf | 否 | Navigator/Composer 流程 |
| Zed + ACP | Zed Industries | 部分 | 支持外部 Agent |
| Kiro | Amazon | 否 | Agent + Spec/Vibe Mode |
| Replit (Agent) | Replit | 否 | 浏览器 IDE + Agent |
| Qoder | 阿里巴巴 | 否 | Agent + Quest Mode + Repo Wiki |
| Trae | 字节跳动 | 否 | Agent + Solo Mode |
| VS Code | Microsoft | 是 | GitHub Copilot + 支持插件扩展/Agent |
| CodeBuddy | 腾讯 | 否 | 智能代码助手/Agent |
笔者日常主要使用 VS Code 和 Qoder（一经推出我就开始试用了）。不过 VS Code 的代码补全能力没有 Cursor 那么强，Qoder 目前试用期每月有 2000 次调用次数，未来如何收费还有待观察。
| 插件名称 | 平台 | 开源 | Agent 能力 | 模型接入方式 | 代表特性 |
|---|---|---|---|---|---|
| GitHub Copilot | VSCode 等 | 否 | 模式对话 + 文件操作 | OpenAI/GitHub 模型等 | 全方位生态插件，Agent 模式已发布 |
| Cline / Roo / Kilo | VSCode | 是 | 文件、终端、浏览器 | BYOK（OpenRouter/本地） | 社区 Agent 插件，功能全面 |
| Continue.dev | VSCode/Jet | 是 | Chat/编辑/Agent | OpenAI、Anthropic、Gemini、Ollama | 强 BYOK 和本地推理支持 |
| Gemini Code Assist | VSCode/Jet | 否 | 多文件生成/调试 | Gemini 托管 | Google 原生支持 |
| JetBrains AI Ass’t | JetBrains | 否 | Chat/Refactor/Testing | JetBrains 模型 | IDE 原生 Agent 功能 |
| 通义灵码 / 文心快码 等 | 国内 IDE | 否 | 代码生成/问答/etc. | 本土大模型（Qwen / 文心） | 面向中国开发者的本地化工具 |
| Tabnine, Supermaven, Blackbox | 多 IDE | 否 | 补全 + Chat | 托管 / 企业自建 | 补全驱动型 AI 助手 |
| OpenRouter 插件 | VSCode | 第三方 | Chat / 补全 | 聚合 >100 模型 | 模型自由选择工具 |
| Ollama 本地插件 | VSCode | 是 | 补全 / Chat | 本地 Ollama 模型 | 私有本地运行，数据安全可靠 |
| Verdant 插件 | VSCode | 否 | Agent | 未知 | Subagent 验证 |
| AugmentCode | VSCode | 是 | Agent / 代码增强 | OpenAI / 本地模型 / BYOK | 支持代码自动增强与上下文感知 |
当前我用的最多的 GitHub Copilot，因为有 GitHub 赠送的 Pro 套餐，而且我对于 VS Code IDE 最熟悉，所以在日常开发中使用频率很高，还可以使用 Claude 4 Sonnet 模型。在这些 IDE 插里 AugmentCode 给我的体验最好，不过订阅价格太高。
| 工具名称 | 开源 | 功能 | 特点 |
|---|---|---|---|
| Warp AI | 否 | 自然语言命令驱动 | 现代 AI 终端环境 |
| Gemini CLI | 是 | Agent 控制交互 | 可跟 IDE 集成 |
| Aider | 是 | Git diffs driven | 开源 agent 编程辅助 |
| OpenHands | 是 | 文件/终端/浏览器 | 全能自托管 Agent |
| Claude Code | 是 | 代码生成与编辑 | Claude 模型驱动，支持多平台 |
| Codex | 是 | 代码生成与命令执行 | OpenAI Codex 模型，支持 CLI/IDE |
| Qwen Coder | 是 | 终端 AI 助手 | 支持中文大模型，适配本地化场景 |
对于终端命令行编程工具给我体验最好的是 Warp，我体验过 $40/月的 Turbo 版本，内置了 gpt-5, claude 4 等模型，可以直接用自然语言执行命令、生成脚本、解释代码等，日常使用非常流畅。Codex 以前需要 API Key 才能使用，上周才开放 ChatGPT 订阅用户使用，目前我偶尔用用，它最的优是可以云端和本地协同，但是响应速度太慢。至于很多人推荐的 Claude Code，笔者无力折腾 🫠。
氛围编程工具的一大关键在于模型接入的自由度，目前呈现以下几种形式：
在编程场景，我觉得 Claude 4 Sonnet 是撰写本文时最好用的模型之一。其次是 Gemini 2.5 pro 还有 Qwen3 coder plus。
目前笔者的编程工具情况是：VS Code（Claude 4 Sonnet 模型）、Gemini CLI/Qwen Coder、Codex，这些额度都已经足够满足日常开发需求。
本篇作为“姊妹篇”，在工具全景、模型接入方式、应用场景推荐和风险提醒等方面，对此前博客调研内容进行了系统补充。文章不仅扩展了工具维度，涵盖了 Codex 风格插件、Qwen 插件及更多本地化方案，还细化了模型接入的类型，包括本地、自建、厂商托管和 MCP 协议生态。同时，针对不同开发需求，给出了更具针对性的应用建议，区分了原型开发、企业生产、国内本地化和自由实验等场景，帮助开发者在实际选择和使用氛围编程工具时有更清晰的参考和思考。
2025-09-01 19:27:39
在日常技术写作和内容创作过程中，手动编写 Hugo 博客的 front matter、目录结构和初稿不仅繁琐，而且容易出错。尤其是多语言、多类型内容管理时，格式规范和字段完整性要求极高。为此，我开发了 Website MCP Server，目标是：
你可在 rootsongjc/hugo-website-mcp-server 查看完整代码。
Website MCP Server 的核心功能包括：
index.md 文件，保证内容结构与 Hugo 规范一致。在 Hugo 项目根目录下：
cd tools/mcp
npm install
npx ts-node website-mcp-server.ts
# 或 node website-mcp-server.js
只需输入类似如下提示词：
写一篇关于 Hugo MCP Server 的博客，主题是 AI 内容生成与自动化脚手架
Copilot agent 会自动调用 MCP Server，生成如下内容：
content/zh/blog/hugo-mcp-server-ai/index.md
生成的 Markdown 文件示例：
---
title: "Hugo MCP Server：AI 驱动的内容生成脚手架"
date: 2025-09-01T10:00:00+08:00
tags:
- Hugo
- MCP
- AI
categories:
- 工具
banner_image: "https://assets.jimmysong.io/images/blog/hugo-mcp-server-ai/banner.webp"
slug: hugo-mcp-server-ai
description: "介绍如何用 MCP Server 实现博客内容自动生成，提升写作效率。"
draft: true
lastmod: 2025-09-01T10:00:00+08:00
---
正文自动生成：
## 项目背景
随着技术博客内容日益丰富，手动创建 front matter 和目录结构变得低效。MCP Server 通过 AI 自动生成内容脚手架，极大提升了写作体验。
## 功能介绍
- 一键生成博客 front matter
- 自动推断 slug、banner、摘要
- 支持多语言和多类型内容
- VS Code/Copilot agent 集成
## 使用方法
1. 启动 MCP Server
2. 在 VS Code/Copilot agent 输入内容描述
3. 自动生成博客草稿和目录结构
## 总结
MCP Server 让内容创作变得高效、智能，是技术写作者的理想工具。
Website MCP Server 基于 Model Context Protocol（MCP）规范实现，提供了完整的工具注册、调用和内容生成流程。
MCP Server 遵循标准的 MCP 协议，通过 stdio 传输与客户端（如 VS Code）进行通信：
// 核心 MCP Server 初始化
const server = new Server(
{
name: "website-mcp",
version: "0.1.0",
},
{
capabilities: {
tools: {},
},
}
);
// 使用 stdio 传输
const transport = new StdioServerTransport();
server.connect(transport);
MCP Server 采用工具注册表模式，每个工具都有规范的描述、输入模式和执行函数：
const tools: Record<string, {
description: string;
inputSchema: Record<string, any>;
execute: ToolExec;
}> = {
create_content: {
description: "Plan or create new content with an SEO-friendly slug",
inputSchema: {
type: "object",
properties: {
type: { type: "string", enum: ["blog", "book", "podcast", "notice", "trans", "ai", "slide", "publication"] },
title: { type: "string", minLength: 2 },
lang: { type: "string", enum: ["zh", "en"] },
// ... 更多参数
},
required: ["type", "title", "lang"],
},
execute: async (args) => {
// 具体实现逻辑
},
},
// 其他工具...
};
工具列表通过 ListToolsRequestSchema 暴露给客户端：
server.setRequestHandler(ListToolsRequestSchema, async (_req) => {
return {
tools: Object.entries(tools).map(([name, t]) => ({
name,
description: t.description,
inputSchema: t.inputSchema,
})),
};
});
当 VS Code/Copilot 需要调用工具时，流程如下：
tools/list，获取可用工具清单inputSchema 验证传入参数execute 函数server.setRequestHandler(CallToolRequestSchema, async (req) => {
const name = req.params.name;
const args = (req.params.arguments as any) ?? {};
const tool = tools[name];
if (!tool) {
return {
content: [{ type: "text", text: JSON.stringify({ ok: false, error: `Unknown tool: ${name}` }) }],
};
}
try {
const result = await tool.execute(args);
return result;
} catch (err: any) {
return {
content: [{ type: "text", text: JSON.stringify({ ok: false, error: String(err?.message || err) }) }],
};
}
});
MCP Server 中的内容创建逻辑基于 Hugo 的 archetype 系统。虽然当前实现没有直接读取 archetype 文件，但遵循相同的字段规范：
Archetype 文件示例：
# archetypes/blog.md
---
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
lastmod: {{ .Date }}
draft: true
slug: "{{ .Name }}"
categories:
- 技术观察
tags:
- 示例标签
comment: true
banner_image: "https://assets.jimmysong.io/images/blog/{{ .Name }}/banner.webp"
description: ""
---
内容类型自动识别：
async function createContent(args) {
const { type, title, lang, parent, slug, write = false, content, description } = args;
// 1. 生成唯一 slug
const manual = ensureKebabSlug(slug);
const slugRaw = manual || (await toSeoSlug(title, description));
const uniqueSlug = await ensureUniquePath(baseDir, slugRaw);
// 2. 构建目录路径
const relDir = path.join("content", lang, type, parent ?? "", uniqueSlug);
const relPath = path.join(relDir, "index.md");
const absPath = path.join(REPO_ROOT, relPath);
// 3. 生成 front matter（根据内容类型）
const date = beijingNowIso();
const fm: Record<string, unknown> = {
title,
date,
lastmod: date,
draft: false,
slug: uniqueSlug,
};
// 4. 特定类型的字段补充
if (type === "blog") {
fm.categories = ["技术"];
fm.tags = ["示例"];
fm.comment = true;
fm.banner_image = `https://assets.jimmysong.io/images/blog/${uniqueSlug}/banner.webp`;
fm.description = "";
}
// 5. 生成内容并写入文件
const yaml = generateYAML(fm);
const bodyTemplate = generateBodyTemplate(lang, type);
const fullContent = yaml + bodyTemplate;
if (write) {
await fs.mkdir(path.dirname(absPath), { recursive: true });
await fs.writeFile(absPath, content ?? fullContent, "utf8");
}
return { relPath, absPath, url: toSiteUrl(relPath) };
}
Slug 生成包含中英文处理、语义理解和唯一性保证：
// 中文到英文术语映射（部分示例）
const EN_TERM_MAP: Record<string, string> = {
"云原生": "cloud-native",
"容器": "containers",
"微服务": "microservices",
"服务网格": "service-mesh",
"人工智能": "artificial-intelligence",
"机器学习": "machine-learning",
"深度学习": "deep-learning",
"Kubernetes": "kubernetes",
"Docker": "docker",
"Istio": "istio",
// ... 500+ 术语映射
};
async function toSeoSlug(title: string, description?: string) {
if (hasCJK(title)) {
// 使用术语字典进行语义翻译
let slug = toEnglishSlugFromDict(title + " " + (description || ""));
// 保留 ASCII 字符串（如 K8s, AI, GPU）
slug = mergeAsciiRunsFromTitleIntoSlug(title, slug);
// 确保唯一性
return slug || ("post-" + Date.now());
}
// 英文标题直接转 kebab-case
return kebab(title);
}
// 确保路径唯一性
async function ensureUniquePath(baseDir: string, slug: string) {
let candidate = slug;
let i = 1;
while (true) {
const dir = path.join(baseDir, candidate);
try {
await fs.access(dir);
i += 1;
candidate = `${slug}-${i}`;
} catch {
return candidate; // 路径不存在，可以使用
}
}
}
在本系统中，用户请求的处理流程如下：
用户在 VS Code 编辑器中通过 Copilot 插件发起请求，经过 MCP Client 和 MCP Server 的处理后，在 Hugo 项目中创建文件并执行相关工具，最终将结果以 JSON 格式返回，用户可继续在编辑器中进行内容编辑。具体流程如下图所示：
实际调用示例：
用户在 VS Code 中输入："创建一个关于 Kubernetes 服务网格的博客"
Copilot 解析后调用 MCP：
{
"method": "tools/call",
"params": {
"name": "create_content",
"arguments": {
"type": "blog",
"title": "Kubernetes 服务网格实践指南",
"lang": "zh",
"description": "深入探讨 Kubernetes 环境下的服务网格架构",
"write": true
}
}
}
MCP Server 返回：
{
"content": [{
"type": "text",
"text": "{\"ok\": true, \"relPath\": \"content/zh/blog/kubernetes-service-mesh-guide/index.md\", \"url\": \"/zh/blog/kubernetes-service-mesh-guide/\"}"
}]
}
MCP Server 提供以下核心工具：
| 工具名称 | 功能描述 | 主要用途 |
|---|---|---|
list_content |
列出内容页面和元数据 | 内容索引和浏览 |
search_content |
全文搜索内容 | 查找相关文章和信息 |
get_page |
获取特定页面内容 | 读取现有文章 |
create_content |
创建新内容（核心功能） | 生成博客、书籍等 |
plan_new_content |
规划内容结构（不写入文件） | 预览生成效果 |
suggest_slug |
智能生成 slug | URL 友好化处理 |
page_url |
计算页面 URL | 生成访问链接 |
run_task |
执行项目任务（分析、图片处理等） | 维护和优化 |
open_in_editor_link |
生成编辑器链接 | 快速编辑跳转 |
MCP Server 严格遵循 Model Context Protocol 标准，主要接口包括：
初始化握手：
{
"jsonrpc": "2.0",
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {
"tools": {}
},
"clientInfo": {
"name": "vscode",
"version": "1.0.0"
}
}
}
工具列表查询：
{
"jsonrpc": "2.0",
"method": "tools/list",
"params": {}
}
工具调用：
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "create_content",
"arguments": {
"type": "blog",
"title": "示例文章",
"lang": "zh"
}
}
}
通过这套完整的 MCP 架构，实现了从用户意图到内容生成的全自动化流程，同时保证了内容结构的规范性和一致性。
在 Hugo 项目根目录下：
cd tools/mcp
npm install
npx ts-node website-mcp-server.ts
在 VS Code 的 MCP 配置文件中添加：
{
"mcpServers": {
"website": {
"command": "npx",
"args": ["ts-node", "tools/mcp/website-mcp-server.ts"],
"cwd": "/path/to/your/hugo/project"
}
}
}
"创建一篇关于云原生服务网格的博客"
create_content 工具Website MCP Server 通过实现完整的 MCP 协议栈，提供了从工具注册到内容生成的全流程自动化解决方案。其核心特性包括：
通过这套架构，技术写作者可以专注于内容创作本身，而将繁琐的格式化、结构化工作交给 AI 自动完成，真正实现了智能化的内容生产流水线。
2025-09-01 11:35:09
近年来，云原生领域不断涌现面向 AI 应用的新型开源项目。笔者长期关注 Kubernetes 与 AI 结合方向，一直在探索哪些开源工具能够帮助企业更好地落地 LLM 推理服务、Agentic AI 自动化运维等场景。恰好 Solo.io 团队在这方面开源了不少项目，比如 kgateway、kagent、agentgateway 和 kmcp，这些项目在我关注的技术方向上表现活跃，功能也很有特色。因此，本篇文章就以 Solo.io 的相关项目为例，系统梳理这类“AI + Kubernetes”开源工具的设计理念、关键能力和企业实战价值，并结合自身调研体验，分析它们与传统方案的差异，最后给出适用建议。
本文将讨论的以下四个 Solo.io 开源项目，下面是总体介绍：
接下来我们将分别想写介绍下这几个项目。
kgateway 是 Solo.io 提供的开源 Kubernetes Gateway API 实现，前身是 2018 年推出的 Gloo 网关。它基于 Envoy Proxy 构建数据面，并拥有高度可扩展的控制面，用于统一管理集群的南北向流量。2025 年随 AI 工作负载的兴起，kgateway 在延续成熟网关能力的基础上新增了对 LLM 服务调用 和 Agent 场景 的支持，是面向未来的下一代云原生网关。作为 Kubernetes Ingress/API Gateway，kgateway 完全遵循 Gateway API 标准，通过自定义资源（GatewayClass、Gateway、HTTPRoute 等）配置路由和策略，并以 Envoy 作为 L7 数据平面提供高性能转发。
kgateway 采用控制平面 + 数据平面的架构模型。控制平面通过 Kubernetes CRD 监听 Gateway API 资源变化，高效地产生 Envoy 配置更新，官方数据显示其控制面反应速度快、资源占用低。数据平面由 Envoy Proxy 进程组成，负责根据配置执行路由、流量控制和策略 enforcement。开发者可以像使用标准 Ingress/Egress 网关一样使用 kgateway，同时获得许多增强特性。下图展示了 kgateway 作为 AI 网关处理请求的流程，其中引入了提示词防护机制和对接后端 LLM 服务的能力：
作为“AI Gateway”，kgateway 提供了一系列面向生成式 AI 应用的增强功能：
InferencePool 等自定义资源用于管理后端模型服务池。运维人员可以创建 InferencePool 将一组同类模型部署实例作为后端，并为其指定端点选择插件（Endpoint Selection Extension, ESE）。当用户请求通过 HTTPRoute 路由至 InferencePool 时，kgateway 不使用默认的简单负载均衡，而是由 ESE 根据实时指标智能挑选具体的模型实例。例如，ESE 会解析请求中指定的 modelName，匹配相应的 InferenceModel 配置，然后综合请求重要级别（Critical 或 Sheddable）、各实例队列积压、GPU 缓存利用率、LoRA 适配器加载情况等因素，按顺序执行过滤决策，选出最优的实例来处理该请求。如果请求重要且有低排队的实例具备所需的 LoRA，则定向其处理；对于非关键请求则倾向选择负载较低的实例，必要时会直接丢弃过载环境下的低优先级请求。这一推理流量编排能力极大提高了 GPU 资源利用率和服务性能，为多模型部署和故障自动切换提供了基础。kgateway 提供 Helm Chart 等多种安装方式，很容易在 Kubernetes 集群中部署其控制面和数据面组件。默认安装即可作为通用的 Gateway API 控制器使用；若要启用 AI 扩展功能，只需在配置中开启相应功能开关（如启用 AI Extension）。然后，运维人员通过定义标准的 Gateway/HTTPRoute 资源以及带有 ai 字段的 TrafficPolicy 等即可配置上述 AI 网关能力。例如，下方给出一个 TrafficPolicy 片段，针对名为“openai”的 HTTPRoute，配置了请求内容正则检查和自定义拒绝响应，实现基础的 Prompt Guard 功能：
apiVersion: gateway.kgateway.dev/v1alpha1
kind: TrafficPolicy
metadata:
name: openai-prompt-guard
namespace: kgateway-system
spec:
targetRefs:
- kind: HTTPRoute
name: openai
group: gateway.networking.k8s.io
ai:
promptGuard:
request:
customResponse:
message: "请求因不当内容被拒绝"
regex:
action: REJECT
matches:
- pattern: "credit card"
部署完成后，开发者即可使用 kubectl 提交 Gateway 和 Route 定义，将指定路径的流量转发到 LLM 或 InferencePool 后端。在推理服务编排场景下，kgateway 充当集群入口的 AI 流量网关，统一提供模型调用的路由、控制与安全防护能力。
kagent 是首个面向 Kubernetes 环境的开源 自主 Agent 框架，致力于帮助平台和 DevOps 工程师构建并运行 AI 智能体，实现云原生场景下的自动化运维和智能决策。2025 年 3 月，Solo.io 宣布开源 kagent 项目，并于当年 KubeCon Europe 表示将其捐献给 CNCF 开源基金会，以在社区推动其发展。kagent 被称为“agentic AI for K8s”，所谓 agentic AI 指的是超越简单问答的智能代理技术，让 AI 系统具备高级推理和递归规划能力，能够自主完成复杂多步骤任务，将洞察转化为具体行动。kagent 正是将这一理念引入云原生领域的先行者，为 Kubernetes 提供一个运行 AI Agent 的基础平台。
kagent 架构分为三个关键层次：
下图展示了 kagent 在 Kubernetes 中的架构简图和执行流程：
kagent 将 LangChain 类的Agent 执行模式与 Kubernetes 基础设施相结合，使 AI Agent 能直接感知和操作云原生系统：
开发者使用 kagent 构建 Agent 十分简单。官方提供了 kagent CLI 工具及 Helm 部署方式，可一键将 kagent 控制器安装到集群中。在安装前，需要配置好 LLM 接口的凭证（如将 OpenAI API 密钥写入环境变量）。安装完成后，可以按照如下流程创建并运行第一个 Agent：
kagent CLI 进入 Agent REPL，选择刚创建的 Agent，之后就能以对话形式向其提交任务。例如输入「查询 kagent 命名空间下运行的 Pod」。Agent 接到指令后，会调用自身工具 GetResources 列出命名空间下 Pod 列表，并以 Markdown 格式给出回答。需要注意的是，由于 Agent 的决策高度依赖 LLM 非确定性的输出，在生产使用时应充分测试和设定保护措施（例如限定可调用的工具范围、对关键操作加确认步骤等）。kagent 项目也在探索引入更多反馈机制（如轨迹回放与调试、结果评估等）来提高 Agent 行为的可控性和可靠性。
agentgateway 是 Solo.io 近期开源并捐赠给 Linux 基金会的全新项目，定位为首个 “AI 原生”代理通信网关。它并非传统 API 网关的简单修改，而是专门针对自主智能体的网络通信设计的数据面代理。从功能上看，agentgateway 为 Agent-to-Agent (A2A) 和 Agent-to-Tool 交互提供了开箱即用的安全、可观测和治理能力，支持业界新兴的 A2A 协议和 MCP 协议 等标准。简单来说，如果把各种 AI Agent 比作微服务，那么 agentgateway 扮演的就是它们之间通信的“服务网格”角色——但它比传统服务网格更进一步，能理解和处理 AI 场景特有的协议和模式。
缘起与设计：在构思 agentgateway 之前，Solo.io 曾考虑直接基于 Envoy 等成熟代理扩展支持 A2A/MCP。但很快发现这些新协议对代理的架构提出了全新的要求，如果强行在 Envoy 上改造成本很高。借鉴 Istio Ambient Mesh 模式下轻量级隧道代理 (ztunnel) 的经验，Solo.io 决定从零开始构建一个专用的数据面代理。agentgateway 因此天生具备针对 AI 场景优化的基因，成为目前业界首个也是唯一从头打造的 AI Agent 通信平面。它体积小巧、无额外不必要功能，并发性能和安全性经过了 Ambient Mesh 生产验证的考验，同时能快速跟进行业涌现的新 AI 协议。正如 Solo.io CEO 所言：“传统 API 网关无法跟上 Agent 架构快速演进的需求，我们打造 agentgateway 来适配 AI 时代的协议、模式和规模，它将成为下一代智能系统的连接枢纽”。
agentgateway 本质上是一个七层代理，部署方式灵活：既可作为集群内的独立网关服务，亦可作为 Sidecar/DaemonSet 为 Agent 或工具提供就近代理。其配置既支持传统的静态配置文件，也计划与 Kubernetes Gateway API 集成以声明式管理。核心功能模块包括：
下图展示了 agentgateway 在多 Agent 与多工具环境中的作用：
agentgateway 的诞生正是为了解决企业在落地 Agentic AI 时遇到的“看不见、管不着、不安全”困境。以下是几个典型使用场景：
当前 agentgateway 提供了独立的可执行程序，用户可以通过一条脚本命令下载安装。随后使用 YAML 配置文件定义监听端口、后端工具地址等，即可启动代理服务。针对 Kubernetes 环境，agentgateway 也支持与 kgateway 集成：例如可将 agentgateway 注册为 kgateway 的一个自定义后端，从而利用 Gateway API 来动态配置 agentgateway 的路由。未来，agentgateway 作为 CNCF 沙箱项目，将完善 Kubernetes 原生部署支持，可能以 Operator 形式提供。实际上，agentgateway 的设计初衷之一就是能与 kagent、kmcp 等周边组件无缝协作：kagent 产生的 Agent 调用若经过 agentgateway，就能立即获得安全和治理加持；kmcp 部署的工具如果通过 agentgateway 发布，就立刻拥有统一鉴权入口等。可以预见，一个完善的 “AI 代理通信网” 将由 agentgateway 充当核心枢纽，将所有 Agent、工具和模型连接起来，发挥出 1+1>2 的协同效应。
kmcp 全称“Kubernetes Model Context Protocol”工具集，是 Solo.io 开源的一套围绕 MCP 生态的 轻量开发运维工具。在 AI 应用中，MCP 工具服务器（提供特定功能供 Agent 调用）如雨后春笋般出现，但从原型代码演进到可生产部署并非易事。kmcp 正是为了解决这一痛点而生：它为开发者提供从代码脚手架、镜像构建到集群部署、发布管理的一站式支持，加速 MCP 工具服务从开发到上线的全过程。
kmcp 工具链聚焦于提高 MCP Server 开发部署效率，提供以下主要能力：
kmcp init 命令，开发者可以快速生成一个预置模版的 MCP 服务工程。kmcp 内置多种语言和框架模板（当前支持 Python FastAPI、Go-kit 等，规划支持 TypeScript、Java 等）。脚手架会搭建好项目目录、依赖配置、测试样例、Dockerfile 等，让开发者专注于实现具体工具逻辑。这样可确保不同开发者创建的 MCP 服务在结构上遵循统一最佳实践，便于后续维护。kmcp build 命令即可打包容器镜像，并支持跨架构构建。然后使用 kmcp deploy 将镜像部署到 Kubernetes 集群。deploy 支持两种传输模式：stdio（标准输入输出）模式和 HTTP Streamable 模式。前者用于 Agent 本地直接调用进程，后者用于将服务作为远程 API 提供多 Agent 共同调用。通过参数，用户可以选择部署命名空间、服务端口、环境变量等，甚至可以使用 --dry-run 输出 Kubernetes 清单文件以纳入 GitOps 流程。值得一提的是，kmcp deploy 会自动打开一个“MCP Inspector”调试界面，方便开发者测试新部署服务的功能。kmcp install 会在集群中部署一个 kmcp 控制器，并注册 MCPServer 自定义资源定义（CRD）。之后每次 kmcp deploy，都会创建对应的 MCPServer 资源来表示该服务，并由控制器负责维护其生命周期和配置。例如控制器可根据 CR 自动创建 Deployment、Service 等，实现服务自愈和滚动升级。借助 Kubernetes 的机制，企业可以像管理其他工作负载一样管理 MCP 工具服务，实现声明式部署和监控。下图展示了 kmcp 从开发到部署的流程：
使用示例：假设我们需要开发一个天气查询工具，让 Agent 可以获取实时天气。使用 kmcp，只需几步：
kmcp init python my-weather-server --author "Your Name" --email "[email protected]"。kmcp 将生成一个名为 my-weather-server 的 Python FastAPI 项目，内含基本的查询接口实现和测试用例。kmcp build --tag my-weather:v1.0 生成容器镜像。确认无误后，运行 kmcp deploy --image my-weather:v1.0 --namespace tools --port 3000 将服务部署到 Kubernetes 集群。首次部署前别忘了运行一次 kmcp install 安装控制器和 CRD。使用 kmcp 开发 MCP 服务时，应尽量遵循无状态、快速启动的原则，以适应按需扩展和弹性调度。同时，由于 MCP 工具通常会被 Agent 频繁并发调用，要确保实现中适当缓存或限流，避免后端 API 配额耗尽。kmcp 本身提供了一些参数用于设置副本数、资源请求等，可根据工具的性能要求进行调整。在安全方面，如果工具需要调用外部 API，切记不要将密钥硬编码在镜像中，最好通过 Kubernetes Secret 挂载并在 kmcp 部署时以环境变量注入。在企业实际落地中，通过 kmcp 打造的 “工具即服务” 生态，可以让不同团队协作开发各类能力模块，并由平台团队通过统一网关（agentgateway）进行治理，实现 AI 功能的模块化和可组合。
Solo.io 这一系列项目在理念和功能上都有创新之处，那么它们与传统方案如 Apache APISIX、Kong Gateway 以及 Kubernetes Gateway API 原生实现相比有什么差异呢？以下从几个角度进行对比：
综上，Solo.io 的 kgateway、kagent、agentgateway 等在 AI 应用落地方面提供了传统方案所不具备的新能力，适合有前瞻性地布局 AI 基础设施的团队。当然，对于仅需要经典 API 网关功能且追求成熟稳定的场景，APISIX/Kong 等依然是可靠选择。但可以预见，随着企业从“调 API”转向“用 Agent”的范式转变，加上开源社区对 A2A、MCP 等标准的推动，Solo.io 这套新兴方案有望引领下一代云原生架构的发展方向。
Solo.io 开源的这四大项目从不同层面完善了 “Kubernetes + AI” 应用的基础设施版图：kgateway 提供统一入口的 AI 流量网关，强化了对 LLM 调用的治理和优化；kagent 将智能 Agent 引入集群，赋能自动化运维和复杂任务执行；agentgateway 打造了面向 Agent 交互的新型网络平面，解决了安全与治理难题；kmcp 则填补了工具服务开发运维的链路，让 AI 能力模块化交付成为可能。它们相辅相成，共同构建出一个面向 AI 原生应用的云原生技术栈。
这套方案推荐给以下人群和场景使用：
需要强调的是，目前这些项目大多仍处于快速迭代阶段（kagent、agentgateway 刚捐赠社区不久），在生产落地前建议充分测试评估，关注官方更新路线。但可以肯定的是，随着 AI 技术与云原生的进一步融合，“AI 即服务”的基础设施需求会日益增长。Solo.io 的开源探索为业界提供了宝贵的思路和工具。对于希望站在技术前沿的团队，不妨尝试引入这些项目，在实践中总结经验、反馈社区，共同完善这一生态。未来，借助这些开源利器，让 Kubernetes 更智能、更自动化 将不再是遥远的愿景。正如 CNCF 专家所指出：“未来的软件将是 Agent 驱动的”，现在就是参与构建这一未来的好时机。
2025-09-01 09:00:00
过去，我常用 https://md.doocs.org/ 这类在线工具，将 Markdown 文档粘贴进去，渲染后再复制到公众号后台。每次还要手动填写标题、作者、封面图和摘要等信息，流程繁琐且重复。其实这些元数据早已配置在 Hugo 博客的 front matter 里，手动操作不仅低效，还容易出错。随着内容量增加，这种方式越来越难以满足高效分发的需求。
因此我就想自己开发一个工具，来将我的博客一键发布到微信公众草稿。微信公众号开发接口也提供草稿发布功能，只需要配置开发者 ID(AppID) 和开发者密码 (AppSecret)，另外再开启 IP 白名单即可。
你可以在 Bilibili查看一键发布的工具演示。
不过最让人头疼的还是微信公众号后台对 HTML 支持有很多特殊限制，比如：
这些痛点促使我开发了自己的内部工具 wechat-markdown-exporter，实现了博客内容一键发布到公众号草稿箱的自动化流程。这样不仅节省了大量手动操作时间，也让内容格式和样式更加统一、专业。
需要特别说明的是，这个工具目前并未开源，原因是其中耦合了很多我个人的内容处理流程和样式定制。例如，针对我的博客系统、图片引用、代码块高亮、表格滑动、内容合规检测等，都做了高度定制化，直接开源并不适合通用场景。如果你有类似需求，建议根据自己的实际情况做定制开发。
整体流程分为三步：
这些问题如果靠手动处理，效率极低，体验很差。自动化工具可以统一样式、自动适配、批量推送，大幅提升内容分发效率。
开发这个工具的最大收获，是彻底解决了内容分发的效率和一致性问题。下面是一些心得分享给大家：
从最初的手动粘贴、反复调整，到现在一键自动发布，整个内容分发流程变得高效、可靠，也让技术文章在公众号上的呈现更加专业。如果你也有类似需求，建议优先考虑自动化方案，结合自己的实际场景做定制开发。
希望这些经验能帮到更多内容创作者，有问题欢迎留言交流。
