圈内内参｜这期聊 HashAgent。它刚冒出来，是个开源代理分享项目。结论先放一句：零托管成本这个说法，模型层和推理层基本成立，工具层破了个口，那个口是被浏览器 CORS 逼出来的一个第三方网关。信源说明一下：这篇没有匿名内部信源，全是公开可查的仓库、README 和 HN 讨论。所以下面标记只有两档——（确认）和（据评论者说），少数地方我标（分析）。
先看公开层。（确认）项目 MIT 许可证，代码在 github.com/mason131928/hashagent。核心卖点一句话：零托管成本，用户设备就是服务器。README 说得更具体：代理定义信息——名称、系统提示、问候语、生成配置——全部压成 base64url JSON，塞进 URL 的哈希片段里。哈希片段在 HTTP 语义里不会发给服务器，所以链接打开时，代理定义只在本地被解析。这个设计下，项目方根本不需要数据库去存“每个代理是什么”。不是把注册表丢 CDN 上装零托管，是真没有服务端账本。
据我了解到的情况，这套架构里最干净的一层是：分享链接就等于分享代理。点开一个 hashagent 链接，浏览器从哈希里取出 base64 那串，解出一个 JSON，里面是名称、系统提示、问候语、生成配置，再交给浏览器里的推理运行时。中间没有任何一次请求把这段 JSON 发给项目方服务器。附带效果也来了：本地改了系统提示，URL 就变；没有服务端记账，谁打开过你的链接、用过多少轮，你也不知道。要我说（分析），这才是零托管真正显形的地方——不省什么流程，直接把“服务端能替你看”这个能力整个不要了。这个项目有没有人自发拿它当内网工具用，我还没交叉核实，先不写。
推理层不复杂。两条线：WebLLM 跑 Llama 3.2、Phi、Mistral、Qwen 这条线；Transformers.js 跑 Gemma 4 E2B、LFM2 1.2B 这类较新的 ONNX 模型。权重首次加载时现下，之后进浏览器缓存，断网也能用；首次下载量 700MB 到 2GB，看你选哪个。（确认）这段是公开文档里写明的，我核对过 README 描述和代码里模型注册表范围，大致对得上。WebGL 和 WebGPU 这层没什么好拆的，就是浏览器调本地 GPU，权重留设备上，不请求模型服务端。但有一句容易漏过去：WebGPU 能把推理留在本地，不代表模型能力能跟云端比。这里从来不是“等价替换”，是“本地跑得起来的模型能做哪类事”。
工具层就是那个口子。HashAgent 把工具切成两层。本地层四件：计算器、时间、维基百科、天气——直接 CORS 调公开接口，不碰项目方服务器。网关层两件：网络搜索、页面阅读；搜索引擎不给浏览器 CORS 白名单，浏览器直接调会卡死，所以项目借了一个开源的 Cloudflare Pages Functions 当中转。网关默认开着。设置里能关，关掉之后所有请求都不接触任何服务器，代价是搜索和页面阅读这两个工具没了。
我管它叫口子，不是质疑网关默认开这件事。搜索引擎拒绝浏览器直接跨域调用，是平台规则；Cloudflare Pages Functions 是 Web 平台上最常见的中转方案之一。这都不是这个项目自己造成的。有意思的是，这里把“零托管”的可信度分层暴露得很清楚：关不关网关，模型权重、推理、本地工具，都是本地行为；网络工具不是，从设计上就无法在浏览器里直接成立，只能借道一个用户自己没部署的第三方函数。默认配置下，搜索请求确实离开用户设备。不落地到项目方自己的服务端，但落在 Cloudflare 的边缘函数上。这个细节必须写透，因为“零托管”听起来像个开关，一拆开就是一层。
规划步骤这段我本来没打算当重点，拆到这儿绕不过去，还是写。1B 级模型的一个大问题不是回答笨，是会在回答中途幻觉出工具调用。HashAgent 不让模型自由发挥，每一轮先跑一个 temperature=0 的规划步骤，只允许输出白名单格式的 JSON 工具调用；这轮确定了要不要调、调哪个，才进回答步骤。工具调用从“生成的一部分”变成“先解析再放行”。这个设计和“1B 模型在浏览器里跑”是绑在一起的——不先锁死规划那步，后面所有本地工具都不可信。我的解读（分析）：这个边界没什么可讨论的，它决定这套东西能稳定工作的下限。
模型上限这块最没争议，但也很少被认真读。文档写的是：16GB 以上内存的台式机，可跑大概 8B 量化级别；手机现实上限在 1B 级别，比如 LFM2 1.2B 和 Llama 3.2 1B。这个量级能干嘛，用过的同行都知道：单任务、单轮勾兑能跑，但谁拿它去替代云端 GPT-4 的大规模多步 agent，都会直接撞墙。真正值得拎出来说的是 iOS。WebKit 给单个标签页的内存限制大概 1.5GB，导致 iPhone 在这里只能用最小的几个模型，不少中端 Android 反而跑得比最新 iPhone 利索。原因不在 Apple Silicon 不够强，是 WebKit 对浏览器标签页的资源限制，很多时候比 Android 侧更硬。平台限制本身不新鲜，放到“浏览器里跑 AI agent”这个场景下，它变成了体验优劣的直接分水岭。
我对这个项目的判断（分析）：它在“零托管”这个口号上，比大多数示范项目扎实。模型推理和代理定义都不经过服务端，这三点没有水分。但网络工具这套是被平台 CORS 推着走，最后落到第三方函数上，这个口子和模型层的零托管不是一个性质。要求默认关掉的开关，和真正留在本地的权重，不能混为一谈。
HN 上有点动静。有条评论说，自己几个月前也做过类似的事：浏览器里跑 LLM 并不难，但能装下的模型较小；这个项目把这种能力变得容易获取，是好事。这看法和可核验的技术现实一致——跑这件事门槛不高，瓶颈不在任何人的工程能力，在浏览器能给多大上下文、多少内存。还有条评论指出底层用了 @mlc 库。我核过（确认）：推理这层不是从零写的，WebLLM 本身就是 @mlc 生态的项目，HashAgent 在运行时上是站在这个库上的。这个细节能让你看清它从哪一层开始不奇怪。另外有个反讽评论：一键在浏览器里运行代理、不可能出问题。这句话单独看没什么，放进上下文有点意思——项目花了一个规划步骤去堵 1B 模型的幻觉口子，公共讨论里更常见的反应是先默认这种轻量方案会失控。
有人问实际上能跑哪些模型。这个问题不随便。WebLLM 和 Transformers.js 两条线，意味着模型注册表不是单一生态；能跑什么，取决于浏览器端 GPU 能力、量化、模型架构有没有 ONNX/浏览器兼容版本。这也部分印证了硬件限制那节：它跑的是“浏览器端能顺利挂上运行时的小模型”，不是“用户想跑什么就能跑什么”。
几个值得盯的信号，不下注，只列观察点。一，这个仓库后续是否真有人提交自定义工具层，特别是绕过 Cloudflare 那段的 PR——那会直接测试“零托管”口子能被补到什么程度。二，WebKit 对 WebGPU 内存策略有没有松动的迹象，这直接决定 iOS 上能不能跑超过 1B 的浏览器代理。三，是否有人 fork 出默认关网关、或者接自托管网关的版本。四，这些 1B 级模型后续有没有针对“白名单工具调用”的微调版本发布。都是公开可查的，到时候对着看。本期到这，有更准信源的同学欢迎补充。