yorkyoung

@wu67 对的 我就是指的这种场景 不是 大哥我标题第一个字就是 macOS 呀

@wu67 这里边可能是有啥误会，我没有加同时为联系人，他们是陌生人，但是就会出现在我的隔空投送列表中

你在办公室打开试一试就知道了
@wu67

多谢 看到了
还要成为 PRO 用户才有置顶功能

有网友问于 LiteLLM 的区别是啥，孤陋寡闻了，我之前还没听说过这个项目。
学习了一下这可是个大项目，可以碰个瓷。

回答一下：
项目定位和面向的用户都不一样

litellm 没有代理功能，如果在国内或者 vps 上装 openclaw 所使用的 IP 地址大概率不能直接访问官方的 API 。

AKDN 的策略更加个性化和自主性，如果倾向于高质量回应优先那就使用「优先级排序」策略，如果有相同水平的多个 API ，每个的可用量都差不多希望均匀消耗就使用「轮询」策略。而 litellm 是针对不同任务随时切换最合适的模型，由它自己决定使用谁。对每个智能体的 API 需求，你自己应该更了解，策略不应该交给 litellm 决定。

更多不同查看：与 LiteLLM 的对比（碰瓷版）
https://yorkian.notion.site/litellm-pengci

应该叫转租吧

@Cert
@love4taylor
学习了 学习了

@fstab 我觉得 AT&T 的用户能有什么样的访问权限，这个就应该有相同的权限。不然这份美帝建国 250 周年的献礼工程就成了笑话了。

自己先来：

1 、可能沿用 1.1.1.1 的 Warp 、iCloud Private Relay 这些所使用的 Wireguard 作为底层，使用 anycast 接入。
2 、传输层用 QUIC/HTTP/3 ，天然抗 TCP 阻断，流量特征伪装成普通 HTTPS 。
3 、混淆层大概率借鉴或直接集成 Shadowsocks-2022 等 ss 系列 或 VLESS + REALITY 的思路，把代理流量完全伪装成合法 TLS 1.3 握手，连 TLS 指纹都对齐主流浏览器。
4 、仅技术可能不太可能真是实现，分发网络不走传统单点 VPN ，而会借道 AWS/Azure/Google 的 CDN ，换脸成正常云服务流量，或者干脆走 CDN over WebSocket ，把隧道藏进 CDN 节点。要封就得把 AWS 一众全封，大的云商应该不愿意染指政治意味这么浓的项目。
5 、IP 纯净度可能会较高，即便只做落地也是不错。
6 、最后猜测，这个项目可能虎头蛇尾。