AI Agent 时代静态网页托管与本地服务发布实战指南：从 Cloudflare Drop 到花生壳 Drop 与 CLI 的完整踩坑记录

本文由 莫潇羽@无忆研习社（www.wuyi.wiki） 撰写，转载请注明出处。

快速摘要

先给只想看结论的朋友一段速览： 当你用 AI Agent 生成好一个静态网页，或者本地跑起来一个 Node.js/Python 小服务，想第一时间发给微信里的甲方、朋友、粉丝看效果，Cloudflare Drop 是一个非常聪明的思路,但落到国内环境上,workers.dev 这个默认域名在很多网络下打不开,分享链接经常被"链路"卡住。真正把这条工作流补齐的,是花生壳这家老牌国产厂商刚推出的一对组合拳:花生壳 Drop(静态网页托管,已备案域名,国内直开,微信可直接分享,当前完全免费)和 花生壳 CLI(适配任意 AI Agent 的技能能力,一句自然语言就能把本地服务映射到公网,不必手动装客户端、不必手动配隧道)。前者对应"已经做好的成品",后者对应"还在本地跑着的服务"。两者叠加,基本覆盖了从"AI 生成完"到"分享给别人"之间的所有场景。想看完整拆解、原理讲解、实测过程和选型建议,往下翻。

一、AI 生成网页遍地开花,可"最后一公里"卡住了大多数人

这两年做内容和写代码,我(莫潇羽@无忆研习社)最直观的感受是,"做一个网页"这件事已经不再是一道技术门槛了。以前要打开编辑器、写 HTML、写 CSS、调 JS、然后想办法把它挂到公网上,前前后后能耗掉半天。现在,一段自然语言丢给 AI Agent,几分钟就能拿到一个功能齐全、样式还算漂亮的单文件网页。

我随手翻了翻自己最近一个月开的会话,单是"帮我做一个 XXX 展示页/汇报页/落地页"这种指令,就出现了几十次。有的是给客户做方案演示的一页纸产品介绍,有的是给团队做的项目进度看板,还有就是纯粹好玩,想给孩子做个九九乘法表的互动小工具。AI Agent 现在的能力,让"想到→做到"这条链路缩短到了让人有点上头的程度。

但真正开始把这些页面发出去用的时候,新的痛点跳出来了:

• 网页做好了,存在本地,只能自己看。
• 想发给甲方,得先"部署"。传统方案要么买服务器,要么买域名,要么走一遍托管平台的注册和认证流程。
• AI 生成的页面,大概率还要迭代好几轮才定稿。每改一版就重新走一遍上线流程,消耗太夸张。
• 分享出去之后,对方点开如果因为网络原因打不开,一切都白搭。

这就是我今天想聊的核心问题:AI Agent 帮我们省掉了"做网页"这一步,但"把网页交到别人手里"这一步反而变得更显眼、更值得单独讨论了。

我把这个环节叫做"最后一公里"。它不是新问题,做 Web 开发的老朋友对它一定不陌生,只是在 AI Agent 大规模生成内容的今天,这一公里被无数创作者、运营、产品、甚至纯小白同时踩了一遍,才显得如此扎眼。

要跨过这一公里,大致有几条不同思路,行业里已经出现过好几拨尝试。有的走 Serverless,把网页部署到某个函数计算平台;有的走对象存储,直接把 HTML 丢到 OSS 桶里开静态托管;还有的走"网页发布服务",让你拖拽上传,几秒钟给一个链接。每一条思路都有自己的适用场景,也都有自己的坑。

作为一个每天都在写文章、写代码、录素材的自媒体作者,我对这条最后一公里的要求很朴素:

• 越快越好。 拖进去就能拿到链接,不要让我先注册、先实名、先绑卡。
• 国内能打开。 微信、抖音、小红书、朋友圈,分享出去必须能直接点开,不要弹安全提示。
• 能长期保留。 我不希望链接是 60 分钟就自动回收的一次性玩具,尤其是那些我打算沉淀下来的作品。
• 能兼容 AI Agent 生成结果。 不管 Agent 吐出来的是一个单文件 HTML,还是一整个包含 JS/CSS/图片的文件夹,都得能一把发布。
• 能延伸到本地服务。 我总有一些跑在 NAS、开发机、树莓派上的小服务想临时给别人看,不是所有需求都是静态网页。

抱着这套朴素诉求,我一路试了很多工具。今天要聊的这一对组合,是我目前用下来最贴合国内实际环境的方案。

二、Cloudflare Drop 抛了个好开头,但国内环境卡了脖子

聊国产方案之前,得先说说触发我写这篇文章的直接原因:Cloudflare 推出的 Drop 应用。

Cloudflare 的这个新功能思路非常纯粹,一句话概括就是:把 HTML、CSS、JavaScript、图片这些静态文件直接扔给它,它把内容托管到全球网络,再返给你一个可访问的链接。 不用注册账号就能用,链接默认有效期一小时,如果觉得网页值得留下,再登录 Cloudflare 账号"认领",页面就能长期挂在你自己的账号名下。

这个思路对创作者来说太友好了。 尤其是配合近两年遍地开花的 AI 编程助手和 Agent 工具这类能直接生成前端页面的能力,链条大概是这样的:

输入自然语言需求
      ↓
AI Agent 生成完整前端页面(HTML + CSS + JS)
      ↓
把生成的静态文件夹拖进 Drop
      ↓
拿到公网链接,分享

从写代码到有一个可访问的公网页面,可能整个过程连十分钟都用不到。这在过去是不可想象的,以前光是买域名、备案、配 HTTPS 就能耗掉几天。

我一开始试 Drop 的时候,还准备验证一个"隐藏玩法":我想看看这种前端托管环境,是不是可以把网页里的 fetch 请求当成一种"隧道",借用户浏览器去访问一些接口。为此我特意做了一个测试页面,里面写了几段 JavaScript,分别发起对不同网络服务的请求。

结果没测几步我就意识到:这个思路本身就是错的。 Drop 的技术边界很清楚,它是"静态网页托管",不是"前端代理"。网页里的 JavaScript 跑在访问者的浏览器里,发起请求的是访问者自己的电脑。你打开这个网页,是你的浏览器在请求;别人打开这个网页,是别人的浏览器在请求。 页面本身并没有一个"服务端"帮你转发。

这是很多前端小白容易踩的一个概念坑,可以顺便科普一下。用一张简单的对比图会更清楚:

Drop 属于第一种,它只是把网页文件放到公网,不代替访问者去请求任何内容。 明白了这一点,再回头看 Drop,它作为一个轻量网页发布工具,真的挺好用。作为一个把"AI 生成结果"变成"一个链接"的中转站,它的定位相当精准。

但!在国内环境的实际工作中,问题也暴露得非常直接。

Cloudflare Drop 默认给出的公网链接是 xxx.workers.dev 这种域名。技术圈都很熟悉的一个事实是,workers.dev 这个域名在国内很多网络下打不开。技术层面的原因是它在国内被 SNI 层拦截了,并不是完全被屏蔽,但也就意味着没有稳定的国内直接访问路径。

再退一步,即便你的网络碰巧能打开,想在微信里分享出去也是麻烦事:境外托管域名在微信里经常会弹安全提示、拦截跳转,或者直接被折叠。对普通接收者(比如甲方老板、家里长辈、同事群里的旁观者)来说,他们不会去研究"为什么这个链接打不开",他们只会得到一个结论:这个东西不好使。

这就构成了一个非常尴尬的错配:

• Drop 在技术侧和体验侧做得很棒。
• 但它的公网出口对国内接收者不友好。
• 分享者(创作者)有交付需求,接收者(甲方/朋友)有打开需求。
• 链路中间断了,再好的工具都被削掉了一半价值。

一个分享工具,归根到底还是要看链接交到别人手里之后好不好用。 这一点我在过去几年做自媒体的过程中深有体会:我做一个 H5 也好,做一个交互面板也好,只要接收方打开时卡了、慢了、被拦了,后面的所有创意都被打折扣。

也正因为这样,我在看到花生壳 Drop 这个国产同类方案时,专门抽了个下午做了一整套对照测试,决定把它拉出来单独讲讲。如果它能把国内可访问、可分享、可长期保留这几件事做到位,那这套工作流对国内创作者的意义会比想象中更大。

三、跨过"最后一公里":花生壳 Drop 登场

顺着上面的诉求往下找,我把目光聚焦到了国产内网穿透老兵——花生壳身上。

花生壳这家产品其实很多老技术人都不陌生,做内网映射、动态域名解析已经二十多年,是国内最早一批帮个人和企业解决"没有公网 IP 也能对外提供服务"这类问题的工具。这次它的新动作,是在传统内网穿透业务之外,推出了一个和 Cloudflare Drop 定位非常接近的静态托管功能——花生壳 Drop。

我第一次打开花生壳 Drop 的页面时,最大的感受是"熟悉":整个交互和 Cloudflare Drop 几乎如出一辙,把 HTML、ZIP 压缩包或者整个网页文件夹拖进去,平台完成内容检测之后,就会生成一个公网预览地址。如果不看语言,你会以为进的是同一个工具。

但在实际用起来之后,几个细节上的差异开始浮出水面,这些差异恰好都踩在国内创作者最在意的点上。

第一个差异是上传的最小单元不同。

Cloudflare Drop 只接受文件夹或者压缩包,如果你手里就是一个孤零零的 index.html,你还得先给它建个空文件夹或者压成 zip 才能上传。这个动作看起来不大,但对非技术用户来说是心智负担。花生壳 Drop 直接允许上传单个 .html 文件,把这一步的心理成本抹平了。

对创作者来说,这是一个很实际的改进:AI Agent 现在生成的绝大多数轻量网页,都是"单文件 HTML"结构——所有 CSS 和 JS 内联在同一个 HTML 里,方便传播。这种成品拖进 Drop 里就能用,不需要额外操作。

第二个差异是分享链接的域名归属。

Cloudflare Drop 给的公网地址挂在 workers.dev 下面。前面已经聊过,这个域名在国内网络下体验不稳定。花生壳 Drop 给出的是它自己旗下的域名,而且这些域名都是已经在国内完成 ICP 备案的静态路径。备案这件事看似只是一个手续,但它带来的连锁反应非常直接:

• 国内浏览器可以直接访问,不需要绕任何弯路。
• 微信内可以正常分享,链接不会被判为不安全跳转。
• 各大自媒体平台的富文本编辑器基本都能识别,复制粘贴不会掉。

用一张表把两者的关键差异摆出来会更直观:

说白了,两者是同一个思路的两种实现,只不过一个更适配全球场景,一个更适配国内场景。 对我们这些主战场在国内的创作者来说,后者的实际体验会顺得多。

第三个差异藏在流程细节里,我要单独说一下。

花生壳 Drop 的整个上传过程里,有一步是合法性检测。上传完成之后,平台会对内容做一次审核判断,通过之后才生成公网访问地址。这个检测环节对内容创作者是双刃剑:

• 好的一面是,它把一些不合规内容拦在了平台之外,平台的整体信誉不会被少数用户拉低,备案域名才能长期稳定。
• 需要留意的一面是,如果你的页面里包含大量爬虫脚本、代理逻辑,或者引用了一些容易被误判的关键词,就有可能不通过。

在我的实际测试里,普通展示类页面、产品介绍页、导航面板、可视化图表、H5 交互页,全部一次通过。只要不是明显违规内容,基本感受不到这一步的存在。

上传完成后,页面预览链接就出来了。这时候你有两个选择:一是就当一次性预览,不做任何账号操作;二是登录花生壳账号,把这个链接"认领"到自己名下,让它长期保存。只要认领一次,后续不再需要重复上传,链接固定,方便沉淀作品集。

我个人比较喜欢的用法是:所有临时预览页面都不登录,直接一次性用;正式作品全部认领,归档到账号里,方便日后复用。这套用法基本还原了 Cloudflare Drop 的原始设计意图,又保留了国内环境下的可用性。

至于费用,截至我写这篇文章的时候,花生壳 Drop 的静态托管功能是完全免费的,认领之后也是免费长期保存。这一点和 Cloudflare 的产品策略非常一致:基础能力免费,增值能力(比如更大流量、更多存储、自定义域名等)走付费,让愿意深度使用的用户自然过渡到付费方案。对我们绝大多数轻量使用场景来说,免费额度已经够用。

四、花生壳 Drop 使用流程与关键差异

聊完定位,我们直接进入实操。光看介绍是没意义的,得把每一步都过一遍,才能判断这个工具在你的实际工作流里能占几分。

我把整个流程拆成六步,你可以对照着走一遍。

4.1 第一步:打开花生壳 Drop 首页

浏览器直接搜索"花生壳 Drop",进入官方页面。界面非常干净,中间就是一个大大的拖拽上传区。这里不需要提前注册账号,可以先上传、后认领,和 Cloudflare Drop 的策略一致。

4.2 第二步:准备好要上传的内容

上传内容支持三种形态:

• 单个 HTML 文件,适合 AI Agent 生成的单文件成品。
• 整个网页文件夹,里面可以包含 index.html 加各种 CSS、JS、图片、字体等静态资源。
• ZIP 压缩包,把整个项目打包上传,平台会自动解压。

一个新手容易踩的坑是:如果上传文件夹,入口文件必须叫 index.html。这是绝大多数静态托管平台的通用约定,和 Cloudflare Drop、GitHub Pages、Vercel 都是一致的。如果 Agent 给你生成的文件叫 home.html 或者 main.html,记得改名。

4.3 第三步:拖拽上传 + 合法性检测

把文件或文件夹拖进上传区,页面会显示一个上传进度条。上传完成后,平台会做一次内容检测,一般几秒到十几秒就结束。检测通过后,你会看到预览链接和"认领"按钮。

我建议第一次使用时,先上传一个非常简单的测试页面,比如就一句"Hello World",走一遍完整流程,把整个链路的体验感受清楚。这样正式发布重要作品的时候,心里有底。

4.4 第四步:认领链接

如果你只是想临时预览,可以到这一步就停下,把链接直接发给对方看。如果这个页面你打算长期保留,就点击"认领"按钮,登录花生壳账号(没有的话现场注册,过程和绝大多数国内平台一样,手机号 + 验证码)。认领之后,链接就永久归属到你的账号名下,不会被平台自动清理。

4.5 第五步:分享出去

拿到公网链接后,就可以在任何地方分享了:

• 粘贴到微信聊天窗口,发给个人或者群。
• 粘贴到公众号后台的超链接编辑器里,做外部跳转。
• 粘贴到自媒体文章,作为参考资料附录。
• 贴在小红书 / 微博 / 知乎 / 抖音 bio 里,给关注者看。

在我实测中,花生壳 Drop 给出的域名在微信内可以直接打开,不弹拦截。这一点对绝大多数国内创作者来说是刚需级的体验。

4.6 第六步:后续管理

登录花生壳账号后台,可以看到自己所有认领过的 Drop 页面,支持删除、替换内容(重新上传新版本)、查看访问情况等基础管理功能。对轻量用户来说这些够了,不需要专门去学个后台。

4.7 需要提前知道的几个边界

有几个真实边界要提前和你说清楚,免得你踩坑:

• 它是静态托管,不能跑后端。 如果你的页面里有需要连数据库、调 Node/Python 后端、需要长期保持连接的 WebSocket 服务,这些都跑不了。想解决这个问题,得走后面第八章要讲的花生壳 CLI 方案。
• 文件大小和数量有默认上限。 免费额度足够绝大多数静态网页项目,但如果你要上传一个几百 MB 的巨型 SPA 应用,建议先看看官方的额度说明。
• 公网带宽在免费档下有共享上限。 高并发场景不建议直接用免费档,可以考虑升级付费,或者搭配 CDN 使用。
• 合法性检测偶尔会误判。 如果检测未通过,可以调整页面文案或者去官方渠道申诉。

理解清楚这几条边界,你在选型的时候就不会走弯路。 静态托管永远只是整个交付链条中的一环,不是万能钥匙。

五、实测一:AI 生成的 NAS 服务导航面板

第一个实测,我想复现绝大多数用户最真实的使用场景:用 AI Agent 生成一个静态网页,然后手动拖到花生壳 Drop 里发布。

选题上,我挑了一个自己家里常用的场景——NAS 服务导航面板。凡是家里有 NAS、软路由、树莓派的朋友,一定都遇到过一个小问题:内网跑了七八个服务,每次要用还得去记 IP 和端口。做一个统一的导航页面,把常用服务都收进去,是最典型的家用需求之一。

5.1 我给 Agent 的完整需求

我给 AI Agent 的自然语言 prompt 大致是这样的:

帮我制作一个 NAS 服务导航网页。页面使用单文件 HTML,
包含 HTML、CSS 和 JavaScript,不依赖外部组件。
页面展示 Jellyfin、Home Assistant、思源笔记、
相册和文件管理五个服务。
每个服务使用卡片展示名称、说明、运行状态和访问按钮。
增加深色模式切换、当前时间显示和服务搜索功能。
完成后把网页保存到本地文件夹,不要启动服务器。

这段 prompt 有几个刻意设计的细节,值得单独说一下:

• 单文件 HTML:让 Agent 输出的 CSS 和 JS 都内联,方便一次性拖上传。
• 不依赖外部组件:排除对 CDN 的依赖,避免因为境外 CDN 访问不稳定影响体验。
• 不要启动服务器:Agent 有时候会顺手起一个本地开发服务器,这里我明确要求不启动,只生成静态文件。
• 明确列出五个服务和三个交互功能:给 Agent 划一条足够具体的边界,避免它自由发挥。

5.2 Agent 的生成结果

几分钟之后,Agent 给出了一个完整的单文件 HTML。里面包含:

• 五张服务卡片(Jellyfin、Home Assistant、思源笔记、相册、文件管理)。
• 顶部有当前时间显示。
• 右上角有深色模式切换按钮。
• 中部有搜索框,支持按服务名过滤。
• 每张卡片上有一个"运行状态"指示点,用不同颜色标记。

样式方面,Agent 默认给的是一个偏"极简 Dashboard"的风格,配色朴素,布局清晰。对一个用来自用的导航页来说,已经完全够用。

5.3 拖进花生壳 Drop

拿到生成的 index.html 文件后,直接拖进花生壳 Drop 的上传区。上传条走完,合法性检测过关,预览链接立刻出现。点开链接,页面在浏览器里干净利落地渲染出来,深色模式、搜索、时间显示,全部正常工作。这一步没有任何额外配置,拖拽即上线。

我登录了自己的花生壳账号,点了"认领",这个链接就归属到我账号名下了。从"AI 生成完"到"公网可访问",总时长大约五分钟,其中至少一半的时间是我在检查 Agent 的输出。

5.4 把链接发到微信

我把这个链接直接发到自己的微信小号,再在小号里点开。链接没有任何拦截提示,浏览器直接加载页面,响应速度很快。 这一步在我用境外托管方案时,是最容易翻车的环节。

我还顺手测了一下手机上的响应式效果。因为 Agent 默认已经写了移动端适配,页面在手机上排版正常,深色模式切换、时间显示、卡片布局都没有问题。从桌面到手机、从浏览器到微信,一整套体验没有割裂。

5.5 这个场景的实际价值

有朋友可能会说,这不就是一个自娱自乐的小工具吗?对,但它折射出的工作流意义远比工具本身大。

在过去,如果我想给别人展示一个小 demo,流程大概是这样的:

flowchart LR
    A[想法] --> B[打开编辑器写代码]
    B --> C[本地调试]
    C --> D[找服务器 / 搭环境]
    D --> E[部署上线]
    E --> F[分享链接]
    F --> G[对方打开可能失败]

现在的流程被压扁成了:

flowchart LR
    A[想法] --> B[自然语言描述给 Agent]
    B --> C[拿到静态文件]
    C --> D[拖进花生壳 Drop]
    D --> E[分享链接]
    E --> F[对方直接打开]

中间那些环境、部署、访问故障,全部被替代掉了。 这不是省一点时间的问题,是把"想到就能给别人看"从一个概念变成了一个日常动作。

六、实测二:3D 前端动画页面完整发布

第二个测试,我特意选一个"复杂度更高"的场景,看看花生壳 Drop 到底能承载多重的静态资源。

我让 Agent 做了一个"高设计感产品展示页"的模仿——带 3D 元素、滚动响应动画、动态背景切换的那种前端页面,包含大量交互效果。这次不再是一个孤零零的 HTML,而是一整套包含:

• index.html(主入口)
• styles.css(独立样式表)
• main.js(主脚本)
• assets/ 目录里的图片和字体文件
• 用到了 Three.js 之类的 3D 库

这已经不是"一页 H5"的量级,而是一个具备完整前端项目结构的静态站点。

6.1 上传流程与第一次差异

因为这次是文件夹结构,我用的是"上传整个文件夹"的方式。把项目根目录拖到花生壳 Drop 上传区,进度条走完,平台自动识别到 index.html 作为入口,生成预览链接。这里和 Cloudflare Drop 的机制完全一致——只要项目里有 index.html,平台就会自动把它当作首页。

有一个细节要单独提一下:上传含 3D 资源的项目时,总体积会比单文件 HTML 大不少。花生壳 Drop 的上传速度还挺稳定,在我家里的百兆宽带下,几十 MB 的项目在几秒钟之内就传完了。这个体验和境外服务的最大差别就在这里——回国的链路稳,不会因为节点抖动导致上传中断。

6.2 页面效果实测

预览链接打开后,页面上的 3D 元素旋转、滚动响应、背景切换,全部按 Agent 生成时的设计正常工作。说明花生壳 Drop 完整保留了整个项目的资源引用关系,静态托管这一层的"零改造"做得很到位。

我特意用几个不同设备做了对照测试:

结论很明确:桌面和移动端表现都合格,微信里也没有任何弹窗警告。

6.3 一个特别值得说的点:JS 环境的"沙盒感"

前面在聊 Cloudflare Drop 的时候我说过,网页里的 JavaScript 环境实质上是访问者自己的,不是托管平台的。这一点在花生壳 Drop 上同样成立。

举个例子,如果你的页面里有一段脚本去请求某个境内 API,那么这段脚本会通过访问者自己的网络发起请求,和托管平台无关。这意味着:

• 你写的静态页面里如果有前端接口调用,得考虑访问者所在网络的可达性。
• 静态托管平台不会,也不应该,承担"前端代理"的角色。
• 如果你想让页面同时对国内外用户都能用,得在设计时考虑接口的兼容性。

这是一个基础但非常关键的认知,搞不清楚这一点,静态托管就会被误用。

6.4 我把链接发到了微信群

最后一步,我把这个 3D 动画页面的链接发到了一个内部创作交流群里。几个朋友现场点开,反馈基本一致:打开速度快,动画流畅,没弹广告和安全提示。 有个朋友还专门问我"这是自己搭的服务器吗",我告诉他这是拖了个文件夹上去的静态托管,他显然被这个流程震到了。

对比过去我们要写代码、买服务器、买域名、配 HTTPS、绑证书才能对外提供一个 3D 页面的年代,今天这个流程简直像开了倍速。 这也是我为什么愿意专门花一篇长文来聊这套工具——它把很多老创作者的经验壁垒抹平了,让新人也能第一天上手就能做出可分享的东西。

七、真正的分水岭:从静态托管到本地服务发布

聊到这里,静态托管这条线基本讲透了。但很快你会遇到下一类需求:如果我要发布的不是一个静态页面,而是一个正在本地运行的服务,该怎么办?

举几个非常常见的例子:

• 我用 Node.js + Express 写了一个后端 API,想让远程同事临时调用几次。
• 我在家里跑了一个 Flask 应用,里面连着 SQLite 数据库,想给客户看一版效果。
• 我的树莓派上装了 Home Assistant,想让在外面出差的家人短暂控制一下。
• 我用 FastAPI 起了一个 AI 模型 Demo,想在直播间做一次实时演示。

这些场景的共同点是:服务在本地运行,依赖本地环境,不是一个"打包上传"能解决的问题。

7.1 静态托管的天花板

前面聊的花生壳 Drop 和 Cloudflare Drop,本质都是"静态托管",它们的运行原理是把你上传的文件放到公网服务器上,由服务器直接返回文件内容。这一层不涉及任何"运行时",也就是说:

• 不能跑 Node.js。
• 不能跑 Python。
• 不能连数据库。
• 不能持久化用户上传的数据。
• 不能保持长连接。

这个天花板不是缺点,而是"静态托管"这个概念自带的边界。 想突破这个边界,必须走另一条路——把本地服务通过某种方式"暴露"到公网。

7.2 传统解决方案的痛点

在花生壳 CLI 之前,常见做法大概有几种,每种都有自己的问题:

• 买云服务器:成本高,配置复杂,对新手不友好。
• 用一些内网穿透工具(比如 frp):需要一台公网服务器做中转,还得手动配置隧道文件。
• 用境外的隧道服务:速度和稳定性受限,而且不适合国内环境。
• 手动搭反向代理:门槛高,不适合非专业开发者。

这几条路的共同问题是:都需要你"提前准备"。你得先有服务器,先装好客户端,先注册好账号,先写好配置文件,才能在需要发布本地服务的时候一键搞定。对偶尔需要一次的用户来说,这个前置成本太重。

7.3 一条新思路:让 Agent 自己搞定

近两年 AI Agent 的爆发,给这条老路开了一个新窗口:如果 Agent 能理解自然语言、能上网检索、能自己安装工具、能自动调用命令行,那"发布本地服务"这件事,能不能也让 Agent 一句话搞定?

这就是花生壳这次发布的另一款配套产品——花生壳 CLI 想要回答的问题。它不是一款给人用的图形化工具,而是一款专门为 AI Agent 设计的命令行工具,让 Agent 在完成本地开发任务的最后一步,顺手把服务映射到公网。

这是从"人操作工具"到"Agent 操作工具"的一次跃迁。 值得单独用一整章聊清楚。

八、花生壳 CLI:让 Agent 一句话完成"本地→公网"

这一章我要讲的是整篇文章里最有意思的部分。如果你现在还在手动配置内网穿透,看完这一段可能会觉得世界变了。

8.1 花生壳 CLI 是什么

花生壳 CLI 是一款命令行工具,核心能力有两块:

• 静态文件托管:通过命令把本地某个文件夹发布到公网,和 Drop 定位一致,但更适合 Agent 调用。
• 内网映射:把本地端口(比如你 Node 服务监听的 3000 端口)映射到公网,拿到一个可访问的公网地址。

它的关键特点不在于功能本身,而在于设计目标——它是给 AI Agent 用的,不是给人用的。 传统命令行工具的用户是开发者,交互模式是"人敲命令+看输出";花生壳 CLI 的用户是 Agent,交互模式是"Agent 阅读文档+自动调用+把结果转述给人"。

这个设计思路和一波新兴的 AI 原生 CLI 工具是一脉相承的。整个行业最近一两年都在讨论:随着 AI Agent 成为主流,工具应该优先提供 CLI 接口,而不是只提供图形界面,因为CLI 天然适合 Agent 调用,组合成本低、Token 效率高、复用性强。

8.2 Agent 时代的 Skill 概念

要理解花生壳 CLI 为什么有意思,得先说一个 AI 领域最近很火的概念——Skill(技能能力)。

Skill 简单说就是一份"过程化说明书",告诉 Agent "遇到某类任务时,该怎么一步步做"。它通常以 Markdown 文件的形式存在,包含:

• 任务描述
• 所需工具
• 执行步骤
• 边界与注意事项

Agent 在遇到具体任务时,会自动检索有没有相关 Skill,如果有,就按 Skill 的指引一步步执行。这套模式让"给 Agent 教工具"变成了一件轻量的事,不需要写复杂的插件或者协议,一份 Markdown 就够了。

花生壳 CLI 的一个巧妙之处是,它把自己的用法沉淀成了 Skill 内容,让主流 Agent 可以直接检索到、直接执行。用户不需要自己去研究文档、不需要自己去安装工具、甚至不需要提前知道"花生壳 CLI"是什么。只要在合适的地方对 Agent 说一句"帮我把这个服务发布到公网",Agent 就会自己找到花生壳 CLI 这个工具,自己完成安装、调用、返回结果。

这是一个非常大的体验飞跃。

8.3 完整实操:让 Agent 起一个 Node.js 服务并公网发布

我用一段完整的自然语言 prompt,让 Agent 做了一次端到端的演示:

在当前目录创建一个简单的 Node.js 服务状态面板。
要求使用 Express,监听 3000 端口。
页面显示当前主机名、系统运行时间、
内存使用率、CPU 信息和当前时间。
完成后安装依赖并启动服务。
确认 http://127.0.0.1:3000 可以正常访问后,
使用花生壳 CLI 创建匿名内网映射,
把本地 3000 端口发布到公网。
最后返回本地地址和公网地址。

这段 prompt 的核心思路是:一句话覆盖"生成代码 → 安装依赖 → 启动服务 → 验证本地可用 → 发布到公网"整条链路。 我要观察的是,Agent 是不是能在没有任何额外提示的情况下,一步步把这些事全做完。

8.4 Agent 的执行过程

Agent 的执行过程分成了几个阶段:

阶段一:代码生成

Agent 快速生成了一个 Express 项目的最小结构,包括 package.json、index.js,以及一个用来展示系统信息的模板。

阶段二:依赖安装

Agent 自动调用 npm install 安装 Express、system-information 等依赖包。

阶段三:启动服务

服务在本地 3000 端口起来,Agent 自己用 curl 或者内置的 HTTP 请求工具验证了本地可访问性,拿到了预期的 JSON 响应。

阶段四:遇到"花生壳 CLI"这一步

这是最有意思的地方——Agent 一开始的系统里并没有安装花生壳 CLI 这个命令。它会怎么做?它自动去互联网检索了"花生壳 CLI"这个关键词,找到官方安装说明,自动执行安装命令,然后阅读工具的帮助文档,理解了怎么创建匿名内网映射。

这一步在过去是我最担心 Agent 会翻车的环节,因为很多小众工具的文档结构不规范,Agent 可能读了半天读不懂,或者读懂了执行错了。但这次 Agent 全流程走下来,没有让我人工干预。

阶段五:创建映射

Agent 调用了 hsk 命令(花生壳 CLI 的可执行文件名),创建了一个把本地 3000 端口映射到公网的临时隧道,拿到了一个可访问的公网地址。

阶段六:返回结果

Agent 把本地地址和公网地址一并返回给我,并且提醒我"公网访问需要保持本地服务运行"。

8.5 认领与授权

创建映射后,一些 Agent 的侧边栏会自动弹出花生壳的认领界面,提示我扫码或者输入账号登录。这个设计和 Cloudflare Tunnel 的授权流程是一样的——匿名创建是临时的,认领后可以长期归属到你的账号名下。

我用花生壳账号完成认领,公网地址就稳定下来了。这时候,我在浏览器里打开公网链接,页面正确显示了我本地机器的主机名、系统运行时间、内存使用率、CPU 信息、当前时间——一个完全跑在我本地的服务,几秒钟就出现在公网上了。

8.6 这条工作流的意义

这不是"多了一个功能"的问题,而是"整个部署流程被 Agent 化"的问题。

在过去,即便你有花生壳客户端、有内网穿透账号,你也需要:

• 手动打开客户端。
• 手动配置内网映射规则。
• 手动记下端口和公网地址。
• 手动去测试链路是否通。

现在,这些操作全都在 Agent 内部完成,你只需要用自然语言说清楚"我要发布什么、