xiaohack's Blog - Serverless
type: channel
link: https://blog.xiaohack.org/tag/serverless/
items: 三大核心趋势引领变革：2026数据治理平台TOP榜单与选型实战指南
items: 从算力规模到系统级竞争：智算竞争核心已变，金山云战略升级曝行业“隐形拐点”
items: 进阶指南：BrowserUse + AgentRun Sandbox 最佳实践
items: 是微服务架构不香还是云不香？
items: VPS 入门：为什么独立开发者需要一台 VPS？（2026 深度版,图片 AI 生成，欢迎拍砖）
items: 探秘 AgentRun｜基于 Serverless 的 AI Agent 沙箱工程化之路
items: 探秘 AgentRun丨为什么应该把 LangChain 等框架部署到函数计算 AgentRun
items: 腾讯云 EdgeOne Pages 边缘函数的踩坑体验
items: serverless 搭建 memos 简略教程

三大核心趋势引领变革：2026数据治理平台TOP榜单与选型实战指南
type: item
date: 2026-02-05T10:16:33+08:00
description: 当 “数字中国”战略迈入深水区，数据治理平台不再是单纯满足监管要求的辅助工具，而是成为企业数字化转型的核心引擎，撬动业务增长的关键资产。Gartner近日发布的《2026年数据与分析治理平台魔力象限》报告指出，生成式AI的爆发式应用正以前所未有的力量重塑数据治理市场。传统的、以人工操作为主的治理模式难以为继，市场正迅速转向由AI智能体和主动元数据驱动的智能、自动化治理。到2027年，60%的数据治理团队将优先治理非结构化数据，以交付GenAI应用并提升决策质量。IDC最新预测显示，2026年中国数据治理平台市场规模将冲破860亿元大关，年复合增长率维持在29.7%的高位，行业发展潜力巨大。行业三大核心趋势，定义治理新方向当前数据治理行业的演进路径清晰明确，三大趋势成为发展主流：• 智能升级提速：AI技术全面渗透治理全流程，自然语言处理与机器学习能力实现数据质量自动监控、异常智能修复，让非技术人员也能轻松操作，大幅降低应用门槛；• 信创适配深化：国产软硬件生态在关键行业加速落地，信创适配从 “可选” 变为 “必选”，本土厂商凭借对国内政策、行业场景的深刻理解，以及快速响应的服务能力，逐渐占据市场主导地位；• 资产价值凸显：数据治理从 “管理导向” 转向 “资产导向”，治理平台不仅承担数据清洗、整合等基础工作，更成为数据价值发现、资产登记入表、服务化输出的核心载体，推动数据资源转化为可增值的经济资产。科学选型框架：四大维度锁定优质平台选择适配的治理平台，核心在于构建贴合企业需求的评估体系。目前权威机构已形成差异化评估标准：IDC聚焦技术底座的稳定性与AI融合深度；赛迪顾问重点关注信创生态兼容性与合规体系完备性；Gartner推崇自动化水平与全生命周期管理能力；中国软件评测中心则从八大功能模块出发，提供可量化的性能评估指标。对企业而言，选型需立足自身实际，围绕四大核心维度综合考量：技术适配性（是否匹配现有IT架构、支持国产化部署）、场景贴合度（能否满足行业特定业务需求）、安全可控性（数据加密、权限管控等安全机制是否完善）、价值转化力（能否助力数据资产化、支撑业务创新），最终筛选出真正符合长期发展战略的治理解决方案。主流厂商核心竞争力全景解析百分点科技百思数据治理平台（AI-DG）百分点科技作为数据智能领域的领先企业，通过创新的百思数据治理平台（AI-DG）和百思数据治理大模型成功将理念落地，助力众多政企客户激活数据要素潜能，在数字化竞争中构建核心优势。基于对行业场景的深度理解，百分点科技将AI与大模型深度融合，构建了全栈国产化适配、场景驱动的数据治理架构，实现从“治理数据”到“智能数据”的跃迁：百思数据治理平台（AI-DG）是百分点科技面向AI时代的新一代智能治理平台，以自研的百思数据治理大模型为核心引擎，实现三大核心突破：基于领域专家知识的智能决策体系，实现从数据标准到数据应用的端到端智能治理；创新的对话式交互模式，通过自然语言驱动多智能体协同，完成从业务需求到技术实现的全链路、全流程自动化开发；具备多模态数据治理能力，深度融合文本、图像、音视频等异构数据的理解与分析能力。平台致力于构建智能、高效、可信的数据资产体系，成为推动政企智能化转型的战略级数字基础设施。字节跳动数据治理与开发平台字节跳动凭借其超大规模数据实践与前沿技术积累，推出了企业级数据治理与开发平台 DataLeap。该平台植根于字节内部日均百万级任务调度、EB级数据处理的实际场景，具备高并发、高可靠、高弹性的平台特性。其核心亮点包括全链路数据治理与开发一体化、智能血缘与影响分析、云原生与多引擎兼容、数据安全与合规增强和协作与知识沉淀。DataLeap 已服务于字节内部及多个外部行业客户，尤其在应对高并发数据处理、复杂数据链路治理与敏捷数据开发场景中表现突出，适用于中大型企业、互联网公司及正在进行数据中台建设的组织。腾讯云数据治理平台整合元数据管理、数据质量监控、数据安全管控等核心功能，与腾讯云 TDSQL、COS 等产品深度适配。核心优势在于 “数据安全”，支持细粒度权限管控与数据脱敏，弹性扩展能力强。在互联网服务、游戏、政务等腾讯生态辐射领域具备天然优势，适合需要兼顾安全合规与弹性扩展的企业，尤其适配云上混合部署场景。年数据治理的竞争维度已全面升级，单纯的功能堆砌不再是核心竞争力，“技术适配性、场景贴合度、价值转化力” 成为企业选型的关键考量。企业唯有立足自身技术架构、业务需求与长期发展战略，精准匹配平台特色，才能让数据治理真正脱离 “成本中心” 属性，成为驱动业务增长的核心资产。华为云数据治理中心华为云数据治理中心最大的特色在于其 "安全优先" 的设计理念，从芯片到应用层构建了全栈可信体系。支持国密三级加密、数据脱敏等 23 项安全功能，通过了等保 2.0、IS…

从算力规模到系统级竞争：智算竞争核心已变，金山云战略升级曝行业“隐形拐点”
type: item
date: 2026-01-27T12:08:49+08:00
description: 从训练到推理：智算需求正在经历一场结构性转向过去一年，如果仅从“算力需求增长”来理解中国智算产业的变化，显然是不够的。 在 2026 年 1 月 21 日举办的金山云年度 Tech Talk 上，金山云对其过去一年智算业务的演进进行了系统性回顾。从公开财报数据到客户侧真实使用情况，这些信息拼凑出了一幅更清晰的图景：智算需求并非简单放量，而是在训练、推理、应用形态和工程方式等多个层面同时发生结构性变化。 这场变化的核心，不再只是“谁拥有更大规模算力”，而是围绕模型如何被使用、Token 如何被消耗、算力如何被组织展开。 变化首先体现在财务数据上。 根据金山云披露的公开财报，其智算云业务在过去一年实现了高速增长。以 2025 年第三季度为例，智算云账单收入达到 7.8 亿元人民币，同比增长接近 120%。这一数据并非孤立，而是延续了此前多个季度的增长趋势，显示智算已成为金山云收入结构中的重要组成部分。 金山云高级副总裁刘涛在分享中提到了金山云对这一趋势的判断：智算需求的增长重心，正在从训练侧逐步向推理侧转移。 从训练视角看，过去几年国内智算需求的主要推动力，来自少数对算力高度敏感的行业。 自动驾驶与具身智能，是其中最典型的代表。这些行业往往需要长期训练模型，并处理视频、点云、传感器等海量多模态数据。在早期阶段，它们对算力的需求更多集中在训练规模本身。 但与通用大模型不同，这类行业模型并不一味追求参数规模最大化。刘涛在分享中指出，自动驾驶和具身智能模型在训练阶段，对算力密度的要求并不极端，但对显存容量和数据处理能力要求更高。 这意味着，它们对算力平台的诉求，正在从“算力数量”转向“系统能力”——包括数据接入、预处理、多模态调度以及训练全流程的工程化效率。 推理侧的变化更加显著。 如果说训练侧的变化仍然是渐进的，那么推理侧的变化则更为直接和激烈。 一个被反复引用的数据，来自火山引擎在其公开发布会上的披露：平台每日 Token 调用量已达到 50 万亿级别。这是当前国内少数被明确对外公布的 Token 规模数据之一，也成为行业理解推理负载的重要参考。 与此同时，多个面向大众或企业的模型产品正在持续扩大推理需求。例如豆包、通义千问以及近期加大投入的腾讯元宝，都在不同程度上推动 Token 消耗快速增长。 这些产品并不完全运行在同一云平台上，但它们共同指向一个事实：推理阶段正在成为智算需求增长的主要来源，且这种增长具备明显的外溢性。 在所有推理场景中，编程类应用被反复强调。 刘涛指出，2025 年一个尤为显著的变化在于：编程相关请求正在成为 Token 消耗的主力场景之一。这一判断并非孤立，而是与海外模型使用结构的统计结果高度一致。 “Vibe Coding”成为一个关键词。一个广为流传的事实是，Claude Code 的大量代码本身，正是由 Claude Code 参与生成的。这意味着模型不再只是辅助工具，而是深度介入软件生产过程。 从全球 Token 调用结构来看，编程类请求在多家模型服务商中长期占据最高比例。金山云也观察到了同样的趋势：代码生成、重构和理解能力的提升，正在显著改变程序员的工作方式，并直接放大推理侧算力需求。 在具体应用层面，互联网客户仍然是智算需求的重要来源，但其需求形态已经发生变化。刘涛提到，当前互联网场景呈现出三个明显特征： 其一，多模态需求显著增长。视频生成、视频理解以及复杂推理任务，带动了训练与推理负载的持续上升；其二，模型参数规模不再单向膨胀，而是围绕具体任务进行结构性调整；其三，Vibe Coding 在头部互联网公司中已较为普及，使用更强的商用模型进行代码开发，正在成为常态。 这些变化意味着，互联网客户对智算平台的期待，已经从“算力服务”升级为对模型生命周期管理和工程体系的整体依赖。 为了满足更多元化的需求，刘涛表示，2025 年，智算平台金山云星流已完成从资源管理平台向一站式 AI 训推全流程平台的战略升级。从训推平台、机器人平台到模型 API 服务，升级后的金山云星流平台构建了从异构资源调度、训练任务故障自愈到机器人行业应用支撑、模型 API 服务商业化落地的全链路闭环。实现三维进阶，智算云 AI 势能全释放 尽管各行各业大规模应用 AI 还处于早期探索阶段，但定位行业助力者的金山云，多年来持续打磨全栈 AI 能力。从 2023 年的智算网基础设施，到 2024 年智算云的平台化和 Serverless 化，再到 2025 年的一站式 AI 训推全流程平台，通过提升平台效率、突破行业边界、加速推理布局，金山云为迎接 AI 应用爆发做好了充分准备。 在平台效率方面，金山云星流训推平台提供从模型开发、训练到推理的完整生命周期管理，具备开发、训练、推理和数据处理四大模块能力，通过降低多模块协同复杂度，能实现…

进阶指南：BrowserUse + AgentRun Sandbox 最佳实践
type: item
date: 2026-01-26T15:07:57+08:00
description: 作者：辰泉提示：本文是 AgentRun Browser Sandbox 快速上手实践指南的姊妹篇，专注于高级集成方案、生产环境的最佳实践、性能优化和部署策略。如果您还没有完成基础学习，请先阅读《快速上手：LangChain + AgentRun 浏览器沙箱极简集成指南》。前言在完成了 Browser Sandbox 的基础集成之后，本文将介绍高级集成方案（如 BrowserUse 框架）以及生产环境部署需要考虑的因素：如何管理 Sandbox 生命周期？如何优化性能和成本？如何保证系统的安全性和可观测性？本文将为您提供全面的高级应用和生产环境最佳实践指南。基于 BrowserUse 集成 Browser Sandbox效果截图BrowserUse 是一个专门为 AI Agent 设计的浏览器自动化框架，支持视觉理解和智能决策。通过 AgentRun Browser Sandbox，您可以让 BrowserUse 在云端运行，享受 Serverless 架构的优势。BrowserUse 架构概览下图展示了 BrowserUse 与 Browser Sandbox 的集成架构：架构特点：智能决策循环： Agent 通过 LLM 分析页面截图，基于视觉理解生成操作指令，执行操作后继续循环，直到任务完成无头浏览器控制： 通过 CDP 协议远程控制云端浏览器，Playwright 作为底层驱动，所有操作在云端执行实时可视化： VNC 提供实时画面监控，方便调试和验证 Agent 行为快速开始安装依赖pip install browser-use python-dotenv agentrun-sdk[playwright,server]主要依赖说明：browser-use：BrowserUse 核心库，支持多模态 LLMagentrun-sdk[playwright,server]：AgentRun SDK，用于创建 Sandboxpython-dotenv：环境变量管理配置环境变量创建 .env 文件：# DashScope API Key（用于 Qwen 模型） DASHSCOPE_API_KEY=sk-your-dashscope-api-key # AgentRun 认证信息 AGENTRUN_ACCOUNT_ID=your-account-id ALIBABA_CLOUD_ACCESS_KEY_ID=your-access-key-id ALIBABA_CLOUD_ACCESS_KEY_SECRET=your-access-key-secret # Browser Sandbox 模板名称 BROWSER_TEMPLATE_NAME=sandbox-browser-demo创建 Sandbox 并使用 BrowserUseimport asyncio import os from agentrun.sandbox import Sandbox, TemplateType from browser_use import Agent, BrowserSession, ChatOpenAI from browser_use.browser import BrowserProfile from dotenv import load_dotenv load_dotenv() async def main(): # 创建 Browser Sandbox sandbox = Sandbox.create( template_type=TemplateType.BROWSER, template_name=os.getenv("BROWSER_TEMPLATE_NAME"), sandbox_idle_timeout_seconds=3000 ) # 配置 Qwen 多模态模型 llm = ChatOpenAI( model='qwen-vl-max', api_key=os.getenv("DASHSCOPE_API_KEY"), base_url="https://dashscope.aliyuncs.com/compatible-mode/v1" ) # 创建浏览器会话 browser_session = BrowserSession( cdp_url=sandbox.get_cdp_url(), browser_profile=BrowserProfile( headless=False, timeout=3000000, keep_alive=True ) ) # 创建 Agent 并执行任务 agent = Agent( task="访问阿里云官网并总结主要产品分类", llm=llm, browser_session=brows…

是微服务架构不香还是云不香？
type: item
date: 2026-01-24T18:17:57+08:00
description: 这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。今天上午有好几个朋友在微信里转了三篇文章给我，如下所示： 《微服务是不是个蠢主意？》 《单体回归？亚马逊放弃用于视频监控的微服务 》 《从微服务转为单体架构、成本降低 90%，亚马逊内部案例引发轰动》 看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 Prime Video 就是 Amazon 的全部么？然后，再看看这些文章后面的跟风评论，我觉得有 80%的人只看标题，而且是连原文都不看的。所以，我想我得写篇文章了……原文解读要认清这个问题首先是要认认真真读一读原文，Amazon Prime Video 技术团队的这篇文章并不难读，也没有太多的技术细节，但核心意思如下：1）这个系统是一个监控系统，用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果（比如：视频损坏或是音频不同步等问题），这个监控主要是处理视频帧，所以，他们有一个微服务主要是用来把视频拆分成帧，并临时存在 S3 上，就是下图中的 Media Conversion 服务。2）为了快速搭建系统，Prime Video团队使用了Serverless 架构，也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关，Step Function 用来做监控（探测器），有问题后，就发 SNS 上，Step Function 从 S3 获取 Media Conversion 的数据，然后把运行结果再汇总给一个后置的 Lambda ，并存在 S3 上。整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）： 需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。 AWS Step Function 按状态转换收费，所以，贵得受不了了。 注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。然后，Prime Video 的团队开始解决问题，下面是解决的手段：1） 把 Media Conversion 和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因： 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。 独立思考好了，原文解读完了，你有自己的独立思考了吗？下面是我的独立思考，供你参考：1）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。2）这篇文章中的这个例子中的业…

VPS 入门：为什么独立开发者需要一台 VPS？（2026 深度版,图片 AI 生成，欢迎拍砖）
type: item
date: 2026-01-24T01:09:27+08:00
description: “我的笔记本是 16G 内存的 M3 Pro ，为什么我还需要一台只有 4 核 8G 的服务器？”在 Reddit 的 r/indiehackers 板块，这是新手最常问的问题之一。在 Serverless （如 Vercel ）和 PaaS （如 Supabase ）横行的今天，VPS （ Virtual Private Server ，虚拟专用服务器）似乎显得有些“老派”。但现实是：真正能跑通商业闭环、实现长期盈利的独立开发者，手里一定攥着几台 VPS 。本文将从独立开发的 7 个核心痛点出发，深度解析为什么 VPS 是你迈向专业化、摆脱“代码玩具”的必经之路。1. 摆脱“本地焦虑”：解决 node_modules 与 Docker 的空间黑洞独立开发者最昂贵的资产是笔记本，而最廉价的则是笔记本硬盘。这波 AI 编程大部分都是 NextJS ，这也就带来了 node_modules 灾难。其实还有 cc 居然也喜欢拉 bb 。如果观察 cc 的执行过程，会发现它一直要写东西去 /tmp 目录 痛点：硬盘与性能的双重榨干 node_modules 爆炸：同时维护 10 个项目，node_modules 能吃掉 50GB 以上的 SSD 。 Docker 镜像堆积：在本地运行容器会让系统响应迟滞，风扇咆哮。 计算占用：本地运行 PostgreSQL 或 Redis 等中间件会显著拖慢 IDE 的响应速度。 解决方案：VPS 作为“重型计算中心” 你只需在本地保留一个轻量的 VS Code + Cursor，通过 Remote SSH 连接 VPS 。所有的重型依赖和环境都在云端运行，笔记本只负责显示 UI 。 2. 拒绝“SaaS 账单勒索”：从商业逻辑看成本控制独立开发最怕的不是没用户，而是用户还没付钱，SaaS 账单先爆了。最近几年做 AI 编程，难免会接触到 supabase ，clerk 等工具，其实包括 vercel 也一样，用下来会发现一开始很爽，然后爽着爽着，账单就爆炸了。vercel 有个很有意思的坑，就是 Image 组件，编译的时候会提示最好用 <Image 组件，听起来很贴心对吧？但这个组件默认走 Vercel 的图片优化服务——每优化一张图就计费一次。流量大的站点，光图片优化费用就能超过主机费用。Vercel 的 Hobby 免费套餐非常诱人——部署、CDN 、SSL 全包。但一旦你的项目有了流量，噩梦就开始了。超额收费一览： 资源 Pro 套餐包含 超出后收费 带宽 1 TB/月 $0.15/GB（即 $150/TB ） Edge Requests 1000 万/月 $2/百万 Serverless 执行时间 40 小时/月 $5/小时 图片优化 5000 张/月 $5/1000 张 痛点：被绑架的扩展成本 PaaS 陷阱：Firebase 的免费额度诱人，但一旦涉及复杂备份或高并发，价格呈指数级增长。 身份验证收费：Clerk 等按月活用户收费，对高频低客单价应用是噩梦。 解决方案：全栈自建（ Self-hosting ） 在 $5/月 的 VPS 上，你可以利用 Docker 跑满性能，同时运行：数据库（ PostgreSQL ）、验证系统（ PocketBase ）和统计系统（ Umami ）。 💡 公平地说：自建服务确实需要一定的运维能力。但最近很多海外开发者分享了自己维护 PostgreSQL 的经验——比想象中简单得多，尤其是有了 Docker 和自动备份脚本之后。后面我会详细讲怎么做。3. 真正的 CI/CD：构建“一人 IT 部门”的自动化流水线独立开发者的核心竞争力在于迭代速度。部署到 vercel 、cloudflare 、Netfily 等 servless 平台在早期验证需求的时候，是非常好的，但是这些平台的问题是，它们的 node 实现是不完备的，一些长时间的任务就没法跑。以前本地打包机器就开始呼啸，通过 github 的 action ，这个事不用操心了，弄好就是 docker 镜像，然后，起飞了。 执行时间限制：Serverless 函数通常有 10-60 秒的超时限制，一般默认是 10s 无持久进程：WebSocket 、长连接、后台任务都很别扭 冷启动延迟：首次请求可能需要等待数秒 痛点：手动部署的低效与错误 如果你还在用手动执行 git pull，你不仅在浪费生命，还在增加生产事故的概率。 解决方案：基于 VPS 的轻量自动化 利用 VPS 运行 GitHub Actions Runner： Git Push 触发流水线。 VPS 自动拉取代码并构建 Docker 镜像。 Docker Compose 自动重启容器，实现零停机更新。 不知道是不是这个原因，现在 cl…

探秘 AgentRun｜基于 Serverless 的 AI Agent 沙箱工程化之路
type: item
date: 2026-01-22T17:42:07+08:00
description: 阿里云函数计算 AgentRun 全新发布后，我们整理了“探秘 AgentRun”系列文章，本系列将梳理企业落地Agent 常见难题，给出具体解法，助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流，钉钉群号：134570017218。AI Agent 时代的沙箱需求从 Copilot 到 Agent：执行能力的质变在生成式 AI 的早期阶段，应用主要以“Copilot”形式存在，AI 仅作为辅助生成建议。然而，随着 AutoGPT、BabyAGI 以及 OpenAI Code Interpreter（现为 Advanced Data Analysis）的出现，AI 开始扮演“Agent”的角色。Agent 被赋予了目标，并能自主规划步骤、使用工具来达成目标。这种质变的核心在于代码执行（Code Execution）。为了回答“分析这层楼的销售数据并绘制趋势图”这样的请求，LLM 不再只是生成一段 Python 代码文本，而是需要在一个真实的 Python 环境中运行这段代码，并获取绘图结果。同样，为了“帮我预订一张去东京的机票”，Agent 可能需要在一个无头浏览器（Headless Browser）中模拟用户点击。不可信代码的安全隐患当 LLM 生成代码并执行时，这段代码在本质上是不可信的（Untrusted）。如果直接在应用服务器或用户的本地设备上运行，将面临灾难性的安全风险：系统破坏：AI 生成的代码可能无意或恶意地包含 rm -rf / 等破坏性指令，或者修改关键系统配置文件。数据泄露：代码可能尝试读取环境变量中的 API Key，或者扫描内网数据库，将敏感数据发送到外部服务器。资源耗尽：死循环或内存泄漏代码可能导致宿主机崩溃，影响其他租户的服务。网络攻击：恶意 Prompt 注入（Prompt Injection）可能诱导 AI 将执行环境作为跳板（Jump Box），对内部网络发起 DDoS 攻击或端口扫描。Agent 场景面临的独特挑战除了基础的安全性，AI Agent 的交互特性还给沙箱环境带来了前所未有的工程挑战，这也是传统沙箱（如简单的 Docker 容器或虚拟机）难以应对的：状态保持：与传统的“请求-响应”模式不同，Agent 往往需要进行多轮对话。上一轮定义的变量（如 df = load_data()）需要在下一轮（df.plot()）中继续可用。这就要求沙箱环境必须具备上下文记忆能力，而非每次请求都重置环境。极速启动：用户无法忍受每次交互都等待数秒甚至数十秒的虚拟机启动时间。为了保证流畅的对话体验（Time to First Token），沙箱必须具备毫秒级的冷启动能力。环境依赖多样性：不同的 Agent 任务可能需要完全不同的依赖库（如 Pandas、Scipy 用于数据分析，Puppeteer 用于网页操作）。沙箱需要支持灵活的自定义镜像或动态依赖加载，同时不能影响启动速度。资源成本控制：Agent 的调用往往具有稀疏性和突发性（例如一天只用几次，但一次用很久）。长期运行独占的虚拟机（VM）成本高昂且资源利用率低，而传统的 FaaS 虽然便宜但往往缺乏状态保持能力。如何在低成本和高性能之间找到平衡点，是一个巨大的挑战。因此，构建一个沙箱（Sandbox）——一个与宿主机、内网以及其他用户数据严格隔离，同时具备高性能、低成本、有状态的封闭执行环境——成为了 AI Agent 沙箱落地的前提条件。AgentRun Sandbox：专为 Agent 设计的工程化方案为了解决上述挑战，我们推出了 AgentRun Sandbox。这是一个以高代码为核心，开放生态、灵活组装的一站式 Agentic AI 基础设施平台。AgentRun 并非从零构建传统的虚拟机集群，而是基于阿里云函数计算（FC）这一强大的 Serverless 底座构建。通过充分利用 Serverless 的按需付费、极致弹性以及免运维（NoOps） 特性，AgentRun 解决了一直困扰沙箱领域的成本与效率难题，并在此基础上通过工程化封装，提供了面向 Agent 场景的专业能力。为什么选择函数计算作为 Sandbox Infra在构建 Agent 沙箱时，我们坚定地选择了函数计算（FC）作为底层基础设施，这主要基于以下核心优势的考量：强安全隔离： 沙箱的核心诉求是安全。函数计算底层采用神龙裸金属与 RunD 安全容器技术，每个执行环境都运行在独立的 MicroVM 中。这种基于虚拟化技术的内核级隔离，相比传统的 Docker 容器隔离具有更高的安全性，能有效防止恶意代码逃逸，为不可信代码执行提供了坚实屏障。极致弹性与冷启动优化： Agent 的调用往往具有突发性。函数计算具备毫秒级的…

探秘 AgentRun丨为什么应该把 LangChain 等框架部署到函数计算 AgentRun
type: item
date: 2026-01-22T17:41:17+08:00
description: 作者：江昱阿里云函数计算 AgentRun 全新发布后，我们整理了“探秘 AgentRun”系列文章，本系列将梳理企业落地 Agent 常见难题，给出具体解法，助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流，钉钉群号： 134570017218 。当你已经用 LangChain、AgentScope、LangGraph 等框架开发了 Agent 应用，如何让它们享受函数计算 AgentRun 提供的 Serverless 运行时、企业级 Sandbox、模型高可用、全链路可观测等能力？好消息是，你几乎不需要改动现有代码，只需要简单的适配就可以迁移到函数计算 AgentRun。这篇文章将通过真实的代码示例，展示如何将不同框架的 Agent 应用部署到函数计算 AgentRun 上，以及如何充分利用函数计算 AgentRun 的各种能力。为什么要部署到函数计算 AgentRun？在讨论具体的集成方案前，让我们先明确一个问题：如果你的 Agent 应用已经在本地或自建服务器上运行良好，为什么还要迁移到函数计算 AgentRun？答案很简单：从开发环境到生产环境，有一道巨大的鸿沟。 本地运行只需要考虑功能实现，但生产环境需要考虑性能、稳定性、成本、安全、可观测等一系列问题。函数计算 AgentRun 提供的不是又一个 Agent 框架，而是让你的 Agent 能够以企业级标准运行的完整基础设施。具体来说，部署到函数计算 AgentRun 后，你能获得：零运维的 Serverless 运行时（自动扩缩容、按量付费），企业级的 Sandbox 环境（高性能、安全隔离），模型高可用保障（自动熔断、多模型 Fallback），全链路可观测（完整的 Trace、成本归因），以及统一的工具和 MCP 管理。快速上手：5 分钟部署你的第一个 LangChain Agent让我们从最流行的 LangChain 框架开始，通过一个完整的例子展示如何将 LangChain Agent 部署到函数计算 AgentRun。第一步：安装 Serverless Devs函数计算 AgentRun 使用 Serverless Devs 作为部署工具。如果你有 Node.js 环境，一行命令即可安装：npm i -g @serverless-devs/s第二步：创建项目使用脚手架快速创建项目（注意：需要 Python 3.10 及以上版本）：# 初始化模板 s init agentrun-quick-start-langchain # 进入代码目录 cd agentrun-quick-start-langchain/code # 初始化虚拟环境并安装依赖 uv venv && uv pip install -r requirements.txt第三步：配置认证信息通过环境变量（建议使用 .env 文件）配置你的 AgentRun 访问凭证：export AGENTRUN_ACCESS_KEY_ID="your-access-key-id" export AGENTRUN_ACCESS_KEY_SECRET="your-access-key-secret" export AGENTRUN_ACCOUNT_ID="your-account-id" export AGENTRUN_REGION="cn-hangzhou"第四步：理解集成方式这是最关键的部分。打开生成的代码，你会看到集成非常简单：from agentrun.integration.langchain import model, sandbox_toolset from agentrun.server import AgentRunServer # 使用 AgentRun 的模型（自动享受高可用、熔断等能力） llm = model("<your-model-name>") # 使用 AgentRun 的 Sandbox 工具 tools = sandbox_toolset( template_name="<your-sandbox-name>", template_type=TemplateType.CODE_INTERPRETER, sandbox_idle_timeout_seconds=300, ) # 创建 LangChain Agent（和原来的代码完全一样） agent = create_agent( model=llm, tools=tools, system_prompt="你是一个智能助手" ) # 定义调用函数 def invoke_agent(request): result = agent.invoke({"messages"…

腾讯云 EdgeOne Pages 边缘函数的踩坑体验
type: item
date: 2026-01-20T11:00:06+08:00
description: 起因前些时间整了个备案域名，就想着把一些自建服务迁移回国内，原本我的 Bark 服务器是放在 Cloudflare Workers 上的，于是就想着看看能不能迁移到国内公有云的 Serverless 平台上。选择 EdgeOne Pages 的原因也很简单，想着也许能够免费用，于是就遇到第一个问题：问题问题 1：文档没有描述 KV 的计费规则我打开腾讯云的文档竟然发现完全没有描述 Pages KV 的计费规则，于是我提出售前工单询问计费规则，客服回复让我加微信群问技术支持……所以这个工单系统的作用是什么，电话总机吗？无奈还是加群问了下，技术支持表示是免费的。就算免费也得写一下吧……那好吧就用这个了，毕竟好像找不到第二个免费的……问题 2: CLI 中环境变量不能设置为 0设置环境变量为 0 表示禁用应该是挺常见的用法，一开始设置为 0 不行觉得可能是 JavaScript 0 == '' 的问题（后面一想那参数肯定是字符串啊），于是就试着设置成 "0"，还是不行。在网页试了下可以设置，不过难道把环境变量设置为空字符串又是什么禁忌吗？> npx edgeone pages env set EXAMPLE_KEY 0 [cli][✘] Variable name and value cannot be empty. > npx edgeone pages env set EXAMPLE_KEY "" [cli][✘] Variable name and value cannot be empty. > npx edgeone pages env set EXAMPLE_KEY "0" [cli][✘] Variable name and value cannot be empty. 问题 3：启动开发环境次数有日限这个文档里写了，但是没写能开多少次，我这边大概不到 20 次就触发日限额了（热重载不算，但是 Debug 的时候发现热重载不是很即时就反复开了下），只能等第二天。这个开发环境似乎是远程在腾讯云那边起了三个 Worker ，而且对 KV 的读写会影响到生产环境（这要是真有人在重要生产环境用了怕不是会炸掉）……问题 4：fetch() 不支持 HTTP/2最后的推送代码写好的时候，发现请求 APNs 服务器的时候连接会被断开，研究半天发现是 EdgeOne Pages Edge Functions Runtime 的 fetch() 不支持 HTTP/2 ，而 api.push.apple.com 是强制使用 HTTP/2 的。我问了下腾讯的员工，说是在规划中，本来我想着可能我是第一个发现的文档没有提示也不奇怪，后面发现似乎我不是第一个问这个的……本来觉得又白干一天了，突然想起这个 Edge Pages 还有个 Node Functions 用的是 Node.js Runtime ，于是拿 Node Functions 写了个代理就勉强能用了。开发的过程中发现 Edge Functions 的 Catch-all 路由优先级是高于 Node Functions 所有路由的，只好把 Edge Functions 移动到了一个单独的目录下，当然这文档也没说明。总结总而言之，头疼的体验主要来自文档不清晰，其次交流严重依赖 IM 而不是工单系统，最后是非常草台的设计。

是微服务架构不香还是云不香？
type: item
date: 2026-01-19T16:17:18+08:00
description: 这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。今天上午有好几个朋友在微信里转了三篇文章给我，如下所示： 《微服务是不是个蠢主意？》 《单体回归？亚马逊放弃用于视频监控的微服务 》 《从微服务转为单体架构、成本降低 90%，亚马逊内部案例引发轰动》 看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 Prime Video 就是 Amazon 的全部么？然后，再看看这些文章后面的跟风评论，我觉得有 80%的人只看标题，而且是连原文都不看的。所以，我想我得写篇文章了……原文解读要认清这个问题首先是要认认真真读一读原文，Amazon Prime Video 技术团队的这篇文章并不难读，也没有太多的技术细节，但核心意思如下：1）这个系统是一个监控系统，用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果（比如：视频损坏或是音频不同步等问题），这个监控主要是处理视频帧，所以，他们有一个微服务主要是用来把视频拆分成帧，并临时存在 S3 上，就是下图中的 Media Conversion 服务。2）为了快速搭建系统，Prime Video团队使用了Serverless 架构，也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关，Step Function 用来做监控（探测器），有问题后，就发 SNS 上，Step Function 从 S3 获取 Media Conversion 的数据，然后把运行结果再汇总给一个后置的 Lambda ，并存在 S3 上。整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）： 需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。 AWS Step Function 按状态转换收费，所以，贵得受不了了。 注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。然后，Prime Video 的团队开始解决问题，下面是解决的手段：1） 把 Media Conversion 和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因： 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。 独立思考好了，原文解读完了，你有自己的独立思考了吗？下面是我的独立思考，供你参考：1）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。2）这篇文章中的这个例子中的业…

serverless 搭建 memos 简略教程
type: item
date: 2026-01-15T14:10:24+08:00
description: 缘起只用服务器搭建 memos 未免太大材小用了，而且也浪费钱。所以就想尽量用无服务器部署 memos。renderrender 由于免费存储空间过低，不是优选。使用 render 创建 Web ServiceImage：填写为 neosmemo/memos:stableEnvironment Variables 分别填入: Key、portValue、5230保活方式： https://github.com/hoochanlon/keep-alivezeaburmemos 官方镜像按照如图所示填写相关参数🖼️ 图片加载失败打开图片链接使用 hu3rror/memos-litestream （该项目解决了备份换机迁移数据的痛点）项目镜像的填写方式S3 配置如图及相关解答（建议看完该 issue 链接内容）： https://github.com/hu3rror/memos-litestream/issues/67b2memosCF 代理 B2 配置见（适用于图床、文件管理免流服务）： https://github.com/hoochanlon/CF-Proxy-B2