之前在 V2EX 发过一次帖子，感谢不少 V 友帮忙测试和反馈。 这段时间主要做了： 优化模型稳定性 增加自动故障切换 完善监控告警 优化响应速度 调整计费系统 修复部分兼容性问题 目前准备开启第二期公测，希望邀请更多开发者参与体验和压力测试。 支持模型 GPT-5.5 GPT-5.4 公测福利 🎁 新用户注册并完成微信认证 赠送 5 美元体验金 💰 邀请用户充值返利 用户充值金额返利 10% 例如： 用户充值 100 刀返利 10 刀 用户充值 500 刀返利 50 刀 用户充值 1000 刀返利 100 刀 官网 https://tokenwork.app QQ：4229101 希望大家帮忙测试 GPT-5.5 稳定性 Codex 兼容性 API 响应速度 高峰期可用性 计费准确性 遇到任何问题欢迎群内反馈，我会尽快处理。 这个平台目前主要是自己长期使用，因此更关注稳定性和体验，而不是单纯追求低价。 欢迎大家体验并提出建议。
之前在 V2EX 发过一次帖子，感谢不少 V 友帮忙测试和反馈。 这段时间主要做了： 优化模型稳定性 增加自动故障切换 完善监控告警 优化响应速度 调整计费系统 修复部分兼容性问题 目前准备开启第二期公测，希望邀请更多开发者参与体验和压力测试。 支持模型 GPT-5.5 GPT-5.4 公测福利 🎁 新用户注册并完成微信认证 赠送 5 美元体验金 💰 邀请用户充值返利 用户充值金额返利 10% 例如： 用户充值 100 刀返利 10 刀 用户充值 500 刀返利 50 刀 用户充值 1000 刀返利 100 刀 官网 https://tokenwork.app QQ：4229101 希望大家帮忙测试 GPT-5.5 稳定性 Codex 兼容性 API 响应速度 高峰期可用性 计费准确性 遇到任何问题欢迎群内反馈，我会尽快处理。 这个平台目前主要是自己长期使用，因此更关注稳定性和体验，而不是单纯追求低价。 欢迎大家体验并提出建议。
之前在 V2EX 发过一次帖子，感谢不少 V 友帮忙测试和反馈。 这段时间主要做了： 优化模型稳定性 增加自动故障切换 完善监控告警 优化响应速度 调整计费系统 修复部分兼容性问题 目前准备开启第二期公测，希望邀请更多开发者参与体验和压力测试。 支持模型 GPT-5.5 GPT-5.4 公测福利 🎁 新用户注册并完成微信认证 赠送 5 美元体验金 💰 邀请用户充值返利 用户充值金额返利 10% 例如： 用户充值 100 刀返利 10 刀 用户充值 500 刀返利 50 刀 用户充值 1000 刀返利 100 刀 官网 https://tokenwork.app QQ：4229101 希望大家帮忙测试 GPT-5.5 稳定性 Codex 兼容性 API 响应速度 高峰期可用性 计费准确性 遇到任何问题欢迎群内反馈，我会尽快处理。 这个平台目前主要是自己长期使用，因此更关注稳定性和体验，而不是单纯追求低价。 欢迎大家体验并提出建议。
之前在 V2EX 发过一次帖子，感谢不少 V 友帮忙测试和反馈。 这段时间主要做了： 优化模型稳定性 增加自动故障切换 完善监控告警 优化响应速度 调整计费系统 修复部分兼容性问题 目前准备开启第二期公测，希望邀请更多开发者参与体验和压力测试。 支持模型 GPT-5.5 GPT-5.4 公测福利 🎁 新用户注册并完成微信认证 赠送 5 美元体验金 💰 邀请用户充值返利 用户充值金额返利 10% 例如： 用户充值 100 刀返利 10 刀 用户充值 500 刀返利 50 刀 用户充值 1000 刀返利 100 刀 官网 https://tokenwork.app QQ：4229101 希望大家帮忙测试 GPT-5.5 稳定性 Codex 兼容性 API 响应速度 高峰期可用性 计费准确性 遇到任何问题欢迎群内反馈，我会尽快处理。 这个平台目前主要是自己长期使用，因此更关注稳定性和体验，而不是单纯追求低价。 欢迎大家体验并提出建议。
MJJ你们好，欢迎来到热门机器横评第二期，在这个系列中，我们将直接横评热门地区的热门机器套餐，让MJJ最直观的了解到机器差异，尽管这个测试肯定无法反映机器的完整状态，但可以从测试结果中窥见某些机器的缺陷和优点，希望给迷惑的MJJ呈现一个相对直观的测试结果。 本期我们横评的是欧洲的线路机，包含德国、荷兰、英国、俄罗斯四个地区，共计15台服务器，服务商包含 AKKOCloud 、 SaltyFish咸鱼云 、 搬瓦工BWH 、 CloudSilk白丝云 、 Misaka 、 Geelinx 、 NOSLA家人云 、 V.PS小秘书 、 Nube 、 MoeCloud 。 此板块第一次发布时不会进行完整评价(因为很多机器的体验并不是测试数据能完全说明的，商家的运营策略/稳定性都会影响机器的体验)，会在归档后会收集MJJ的热门评价并附在下方，方便大家看到更多元的信息。本文无AFF，更多相关产品可见 原文 同时也再次感谢众多MJJ提供家宽测速点和众多机器的评价，你们才是最好的MJJ~ 基本信息 我们对机器的硬件进行了测试，值得说明的是：对于组网/反代等不太需要性能的应用而言，这些机器完全够用，我们希望不需要性能的用户在考虑机器时不用太参考性能，因为对于这些场景而言，性能强弱并不重要，更应该关注网络状况。 硬件配置 我们收集了受测机器的常见配置，方便大家快速根据预算来选择机器。部分机器厂商并没有标记机器的带宽，我们便采用SpeedTest和常见对端多线程速度作为 推测带宽 来计入，这类机器的带宽后面会看到 ? ；机器价格的选取其实比较“暧昧”，我们选择的并不是最新厂商的官网定价，而是选择的是 持有量较大的套餐 的定价，更加接近用户使用成本，也可以更真实的对比机器价格；部分服务商采用美元、欧元计价，为了方便大家查看我们将价格按照 1USD = 6.76635CNY 和 1 EUR = 7.88049 CNY 转换为了CNY作为统一计价单位。 我们需要特别说明：咸鱼云-NL的产品我们只看到了月付和季付价格，没找到年付价格，所以按照其DE产品的定价逻辑推断出了其年付价格，实际以厂商为准；Geelinx的是单向500GB流量(only-out)，我们简单的将其翻倍作为1T流量计入，实际上会根据使用场景的不同而产生较大偏差；Nube的产品是流量计费的，用多少付多少，我们按照100GB(单向)的价格来推断出的年费价格 服务商 CPU 内存(GB) 硬盘(GB) 双向流量(GB/月) 带宽(Mbps) 价格(年/¥) IPV6 Nube-DE 1 1 10 200 10000? 135.06 有 NOSLA-DE 1 1 20 550 500 179.25 有 Geelinx-UK 2 2 20 1000 200 183.75 有 BWH-NL 1 1 20 1000 2500 246.02 无 AKKO-DE 1 1 10 500 1000 299 无 AKKO-UK 1 1 10 500 1000 299 无 CloudSilk-DE 1 1 10 500 500 299.99 无 MoeCloud-UK 1 1 10 500 1000 349 无 咸鱼云-NL 1 1 10 1000 2500 487.18 无 V.PS-DE 2 1 20 1000 1000? 551.24 有 V.PS-NL 2 1 20 1000 1000? 551.24 有 咸鱼云DE-Pre 1 1 15 1000 2500 580.55 无 咸鱼云DE-Elite 1 1 15 1000 2500 583.60 无 Misaka-DE 1 0.5 10 512 3000? 781.51 无 Misaka-RU 1 0.5 10 512 1000? 1042.02 无 CPU性能测试 我们统计了常见机器的CPU型号、Sysbench单核分数和GB5单核分数。我们是按照GB5的分数来进行排序的，这样更加接近我们的实际体验。我们没有记录多核分数，一个是因为 我们的测试机并不统一，有的是2核，有的是4核，测试结果无法对比，另一个则是因为大部分场景都是单核场景，所以我们只记录了单核分数。 我们尝试在Misaka-RU上进行了多次GB5测试均失败，故只展示Sysbench单核分数，可以作为一个参照。 服务商 CPU型号 Sysbench单核分数 GB5单核分数 咸鱼云-NL AMD EPYC-Genoa 5882.42 1928 CloudSilk-DE AMD EPYC-Milan 4495.20 1027 BWH-NL AMD EPYC-Genoa 3351.04 988 NOSLA-DE AMD EPYC 7V13 3239.78 974 咸鱼云DE-Pre AMD EPYC 3197.83 919 咸鱼云DE-Elite AMD EPYC 3213.14 913 AKKO-DE AMD EPYC 3008.13 841 Misaka-DE AMD EPYC-Milan 2976.61 705 MoeCloud-UK Intel Core 799.30 628 Geelinx-UK Intel Xeon Platinum 8272CL 723.24 563 V.PS-DE Intel Xeon Gold 6133 866.33 498 AKKO-UK Intel Core 610.02 383 Nube-DE AMD EPYC 7C13 1896.20 369 V.PS-NL Intel Xeon Gold 6133 530.23 312 Misaka-RU AMD EPYC-Rome 1495.87 fail 磁盘性能测试(单位为IOPS) 磁盘性能测试的维度很多，我们VPS日常建站、数据库等工作更依赖4K随机性能，顺序读写主要影响大文件传输，所以我们按照 4K随机读×25% + 4K随机写×25% + 高队列随机读×15% + 高队列随机写×15% + 顺序读×10% + 顺序写×10% 的权重来简单计算一个综合分数来进行排序(这并不严谨，但我们觉得可以给完全不懂磁盘性能的小白一个大致的参考，对于有明确的需求的MJJ而言，自行查看具体数据即可，排序你可以当娱乐来看) 服务商 4K随机读 4K随机写 高队列随机读 高队列随机写 顺序读 顺序写 Misaka-DE 7.7k 20k 100k 80k 2.1k 1.3k NOSLA-DE 7.8k 14k 99k 70k 8.0k 4.2k BWH-NL 5.0k 8.5k 88k 85k 7.7k 5.4k V.PS-DE 11k 8.8k 90k 69k 1.2k 1.3k Misaka-RU 2.1k 1.6k 64k 49k 7.3k 4.0k V.PS-NL 9.0k 8.5k 44k 46k 1.2k 1.3k 咸鱼云-NL 11k 11k 11k 11k 1.0k 1.1k CloudSilk-DE 9.5k 11k 11k 11k 1.0k 1.1k AKKO-DE 5.3k 11k 11k 11k 1.0k 1.1k AKKO-UK 5.8k 8.6k 11k 11k 1.0k 1.1k 咸鱼云DE-Pre 4.1k 7.7k 11k 11k 938 1.1k 咸鱼云DE-Elite 3.7k 7.8k 11k 11k 1.0k 1.1k MoeCloud-UK 768 1.5k 10k 9.7k 895 397 Geelinx-UK 2.2k 1.9k 2.1k 1.8k 311 163 Nube-DE 630 391 3.0k 3.0k 201 201 内存性能测试 服务商 Sysbench读取 Sysbench写入 延迟 HQ内存分数 V.PS-DE 19457.6 MB/s 15311.9 MB/s 286 ns 14716 咸鱼云-NL 79808.9 MB/s 46325.7 MB/s 93 ns 14390 咸鱼云DE-Pre 40222.2 MB/s 23980.1 MB/s 168 ns 10540 CloudSilk-DE 55124.4 MB/s 30187.6 MB/s 135 ns 10464 AKKO-DE 37907.5 MB/s 22675.7 MB/s 182 ns 10012 Geelinx-UK 15773.4 MB/s 13252.1 MB/s 223 ns 9628 BWH-NL 42147.9 MB/s 25022.0 MB/s 171 ns 9244 咸鱼云DE-Elite 42328.6 MB/s 24391.0 MB/s 167 ns 8599 NOSLA-DE 42579.2 MB/s 24661.5 MB/s 171 ns 8419 Nube-DE 26681.8 MB/s 12782.8 MB/s 261 ns 5289 Misaka-DE 43208.5 MB/s 15106.8 MB/s 165 ns 4842 Misaka-RU 40407.1 MB/s 17218.5 MB/s 182 ns 4764 V.PS-NL 11606.0 MB/s 10793.4 MB/s 404 ns 4759 MoeCloud-UK 11147.0 MB/s 8854.1 MB/s 257 ns 4104 AKKO-UK 16570.6 MB/s 7133.4 MB/s 310 ns 3256 网络质量 我们希望您在参考时不要将Misaka RU的机器的和其他的做对比，因为俄罗斯的机器延时和速度肯定会优于德国/英国/荷兰这些地区的机器，俄罗斯到德国等欧洲区域还要40-50ms，我们之所以将这个机器放在欧洲里一块横评的原因是俄罗斯机器比较特殊稀有，我们希望能和传统欧洲机器做一个对比，方便大家熟悉这款机器的网络 IPV4双程路由表 测试基于广州电信、广州联通、广州移动，不同地区有细微差距，例如部分机器的部分地区联通回程会变成10099 服务商 电信去程 电信回程 联通去程 联通回程 移动去程 移动回程 AKKO-DE CN2 CN2 10099 CN2 CMIN2 CMIN2 AKKO-UK CN2 CN2 10099 CN2 CMIN2 CMIN2 BWH-NL CN2 CN2 10099 9929 CMIN2 CMIN2 CloudSilk-DE CN2 NULL 10099 NULL CMI NULL Geelinx-UK 163 9929 10099 9929 CMIN2 CMIN2 Misaka-RU CN2 CN2 4837 CN2 CMI CN2 Misaka-DE CN2 CN2 10099 CN2 CMIN2 CN2 MoeCloud-UK CN2 CN2 10099 CN2 CMI CMIN2 NOSLA-DE CN2 CN2 10099 9929 CMIN2 CMIN2 Nube-DE 163 9929 10099 9929 CMIN2 CMIN2 V.PS-DE CN2 CN2 10099 9929 CMIN2 CMIN2 V.PS-NL CN2 CN2 10099 9929 CMIN2 CMIN2 咸鱼云DE-Elite CN2 9929 10099 9929 CMIN2 CMIN2 咸鱼云DE-Pre CN2 CN2 10099 CN2 CMIN2 CMIN2 咸鱼云-NL CN2 NULL 10099 NULL CMIN2 NULL 去程路由测试 我们在广州电信、广州联通、广州移动三台机器上对受测机器进行了去程路由测试，我们简单的记录了路由的方向，你可以在这些结果中很明显德看到：上海和北京是主要去往欧洲方向的出海口，靠近这两个地区的用户往往可以享受到更好的网络延时，，出海后大部分机器都是前往德国中转，所以对于大部分用户而言，线路机可以优先选德国的，更容易得到优质体验。 简写说明：沪：上海、京：北京、德：德国、英：英国、荷：荷兰、美：美国 服务商 电信 联通 移动 AKKO-DE 沪-德 京-德 京-德 AKKO-UK 沪-德-英 京-德-英 京-德-英 BWH-NL 沪-德-荷 京-德-荷 京-德-荷 CloudSilk-DE 沪-德 京-德 英-法-德 Geelinx-UK 美-英 京-德-英 京-德-英 Misaka-RU 京-俄 京-俄 德-英-俄 Misaka-DE 沪-德 京-德 京-德 MoeCloud-UK 沪-德-英 京-德-英 荷-德-英 NOSLA-DE 沪-德 京-德-英-德 京-德 Nube-DE 荷-英-德 京-德 京-德 V.PS-DE 沪-德 京-德-英-德 京-德 V.PS-NL 京-德-荷 京-德-英-荷 京-德-荷 咸鱼云DE-Elite 沪-德 京-德 京-德 咸鱼云DE-Pre 沪-德 京-德 京-德 咸鱼云-NL 京-德-荷 沪-德-荷 京-德-荷 回程延时测试 我们对这些所有的测试机器进行了TCP大包的回程延时测试和ICMP回程波动监控。可以通过观察TCP大包的延时来看出三网最低延时的机器，并且根据自己所处北方/南方地区来进行进一步筛选，而每台机器的ICMP回程波动监控数据可以在 探针 里看到，我们推荐你自行前往探针选择感兴趣的机器，还可以自由组合来对比机器的延时情况，下面就按照地区和运营商截取一些具有代表性的作为延时回程延时图 电信TCP大包延时测试 商家 京 沪 粤 最低延时 北方均值 南方均值 全国均值 Misaka RU 114 130 147 113（津） 128.3 139.8 134.2 Misaka DE 139 157 171 137（津） 155.1 164.4 159.9 咸鱼云 DE-Elite 157 155 176 149（苏） 171.9 167.6 169.7 CloudSilk DE 162 160 179 154（津） 180.5 176.0 178.2 咸鱼云 DE-Premium 175 162 185 161（津） 182.7 179.5 181.1 NOSLA DE 162 161 178 161（沪） 188.3 177.6 182.7 BWH NL 166 167 183 166（京/津） 182.3 184.8 183.6 咸鱼云 NL 175 169 184 168（津） 182.9 184.3 183.6 AKKO DE 181 164 179 160（津） 184.7 188.8 186.8 V.PS DE 202 161 237 161（沪） 193.7 180.4 186.8 AKKO UK 173 174 189 167（津） 190.3 189.8 190.0 MoeCloud UK 179 183 194 174（津） 191.5 193.8 192.6 Nube DE 155 184 192 155（京） 196.9 190.9 193.8 V.PS NL 169 207 190 168（津） 209.3 202.8 206.0 Geelinx UK 213 219 235 213（京） 247.8 233.6 240.5 联通TCP大包延时测试 商家 京 沪 粤 最低延时 北方均值 南方均值 全国均值 Misaka RU 118 132 146 110（津） 139.1 147.7 143.5 咸鱼云 DE-Elite 125 146 156 125（京） 149.4 153.4 151.5 Nube DE 136 151 164 133（豫） 156.7 158.8 157.8 CloudSilk DE 133 150 165 125（津） 162.0 162.2 162.1 咸鱼云 DE-Premium 139 154 163 131（豫） 159.7 166.1 163.0 Geelinx UK 140 159 171 140（京） 158.3 169.1 163.8 AKKO DE 123 170 165 123（京） 158.0 171.0 164.7 BWH NL 143 158 169 143（京） 164.5 166.6 165.6 咸鱼云 NL 138 160 173 134（蒙） 163.9 175.1 169.6 AKKO UK 139 167 176 139（京） 166.4 183.3 175.1 MoeCloud UK 154 175 176 149（冀） 175.5 182.6 179.2 NOSLA DE 151 173 188 151（京） 181.4 185.6 183.5 V.PS DE 163 174 188 162（津） 186.0 186.6 186.3 V.PS NL 143 165 175 142（津） 197.1 213.3 205.5 Misaka DE 239 255 268 239（京） 258.9 271.9 265.6 移动TCP大包延时测试 商家 京 沪 粤 最低延时 北方均值 南方均值 全国均值 NOSLA DE 118 143 182 118（京） 149.0 155.1 152.1 咸鱼云 DE-Elite 118 142 186 118（京） 149.1 155.6 152.5 AKKO DE 126 141 175 126（京） 148.8 156.2 152.6 咸鱼云 DE-Premium 116 162 172 116（京） 150.2 155.8 153.1 Nube DE 129 148 172 129（京） 149.9 158.2 154.2 咸鱼云 NL 132 149 190 132（京） 145.3 163.2 154.5 V.PS DE 126 142 173 126（京） 145.4 163.9 155.2 BWH NL 123 150 176 123（京） 154.1 161.2 157.7 Geelinx UK 131 155 185 131（京） 151.4 167.4 159.6 AKKO UK 139 157 193 139（京） 161.1 167.9 164.6 V.PS NL 146 152 171 139（豫） 157.7 183.7 171.6 Misaka DE 142 196 207 142（京） 173.3 200.1 187.1 Misaka RU 132 197 210 132（京） 179.5 202.8 191.5 CloudSilk DE 152 211 216 152（京） 187.9 201.8 195.0 MoeCloud UK 173 201 230 162（津） 183.9 211.1 198.4 英国地区回程波动 电信方向Geelinx延时明显高于AKKO和MoeCloud，联通移动方向Geelinx则延时明显低于AKKO和MoeCloud。Moecloud波动明显大于Geelinx和AKKO啊，延时曲线毛刺很多轻微抖动，部分地区MoeCloud丢包严重。 英国三地电信回程 英国三地联通回程 英国三地移动回程 荷兰地区回程波动 荷兰三地电信回程 荷兰三地联通回程 荷兰三地移动回程 德国地区回程波动 德国地区的机器太多，组合在一个图中展示会显得非常混乱，我们推荐您直接前往 探针 来自行组合查看，每次选择2-3个节点，这样更加清晰，对比起来更加明显。 俄罗斯地区回程波动 多地区单线程下行速度测试 我们利用手上已有的多个国内家宽和机房作为测速点，对所有机器进行 单线程 测试，希望大家着重观察家宽的表现情况，因为这些测试结果会很接近大家的实际体验情况，而IDC的结果则是更偏向于表现一款产品的上限。我们在8:00、8:30、9:00、9:00、10:00、10:30进行了多次测试，并选择其中可以稳定复现的结果，作为这款产品在此测试点的数据。 我们没有进行多线程测试，因为单线程场景才是最常用的，所谓“单线程快才是真的快”，但大家仍要考虑多线程的影响，很多产品的带宽峰值会很大程度的影响多线程速度，例如300Mbps和1Gbps的产品在单线程测试中差距可能不大，但在多线程场景下差异会很明显。我们也没有进行上行速度的测试，因为国内家宽的上行本来就很低，而且大部分场景下影响体验的都是下行速度。 你会发现部分数字前带有"!"符号，这个意思是这台机器在这次测试中出现了明显的断流或者严重的降速 我们测试下来觉得 单线程速度 表现比较好的机器： 电信：Misaka-DE、AKKO-DE、 咸鱼云-DE-Elite 联通：咸鱼云-DE-Elite、AKKO-DE 移动：咸鱼云-NL、咸鱼云-DE-Elite 大家可以着重查看这些产品的数据 湖南电信家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) Misaka RU 781 836 830 804 873 816 823.3 咸鱼云 NL 654 702 708 634 676 747 686.8 咸鱼云 DE Elite 674 700 696 653 665 658 674.3 AKKO UK 616 681 648 683 618 682 654.7 CloudSilk 686 624 627 570 626 622 625.8 MoeCloud 632 621 602 665 683 633 639.3 AKKO DE 662 570 698 613 709 625 646.2 Misaka DE 480 480 480 480 482 481 480.5 Geelinx 192 190 190 192 189 190 190.5 咸鱼云 DE Premium 144 144 157 157 156 148 151.0 BWH NL 126 135 132 157 132 135 136.2 Nube DE 118 22 13 7 72 125 59.5 NOSLA 30 27 28 52 45 15 32.8 V.PS DE 4 34 7 42 7 37 21.8 V.PS NL 21 9 16 18 22 16 17.0 广州电信机房 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) Misaka RU 172 175 166 176 173 174 172.7 Misaka DE 148 148 152 149 151 149 149.5 AKKO DE 137 148 137 143 145 136 141.0 咸鱼云 DE Elite 141 144 136 147 136 139 140.5 咸鱼云 DE Premium 141 141 135 145 136 136 139.0 咸鱼云 NL 142 134 139 132 142 133 137.0 CloudSilk 137 130 131 134 135 138 134.2 AKKO UK 137 134 131 131 129 138 133.3 BWH NL 132 132 128 129 136 134 131.8 MoeCloud 126 121 109 125 112 117 118.3 Geelinx 108 112 108 108 112 112 110.0 Nube DE 45 55 66 63 35 43 51.2 NOSLA 57 41 29 78 33 32 45.0 V.PS NL 53 41 !53 22 23 35 37.8 V.PS DE 66 !35 19 26 !40 21 34.5 江西电信家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) Misaka RU 231 234 242 242 224 222 232.5 Misaka DE 217 199 198 210 212 202 206.3 咸鱼云 NL 176 174 176 171 190 187 179.0 AKKO DE 173 178 188 169 186 169 177.2 咸鱼云 DE Elite 187 167 170 182 176 165 174.5 CloudSilk 169 176 169 185 178 170 174.5 AKKO UK 165 155 163 157 153 167 160.0 咸鱼云 DE Premium 157 152 157 159 156 154 155.8 BWH NL 152 154 148 154 155 152 152.5 MoeCloud 139 156 141 153 157 164 151.7 Geelinx 143 146 !33 142 !76 152 115.3 V.PS DE !108 34 !70 115 35 36 66.3 NOSLA 70 61 38 73 62 56 60.0 Nube DE 14 55 39 67 68 60 50.5 V.PS NL 64 29 81 58 35 33 50.0 杭州电信家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) Misaka RU 176 174 181 178 177 185 178.5 Misaka DE 157 159 157 158 155 154 156.7 咸鱼云 DE Premium 138 137 148 130 135 136 137.3 AKKO DE 133 140 140 141 144 132 138.3 咸鱼云 NL 129 127 135 137 138 151 136.2 CloudSilk 126 144 126 134 136 128 132.3 咸鱼云 DE Elite 132 131 136 131 157 132 136.5 AKKO UK 124 126 133 123 122 134 127.0 BWH NL 126 122 131 142 122 124 127.8 MoeCloud 118 123 125 130 124 112 122.0 Geelinx 112 112 112 113 112 113 112.3 Nube DE 55 42 41 30 39 26 38.8 NOSLA 33 55 58 25 22 26 36.5 V.PS DE 30 61 30 !20 !4 !2 24.5 V.PS NL 37 23 20 19 14 19 22.0 湛江电信家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) Misaka RU 199 188 101 195 203 203 181.5 咸鱼云 DE Elite 141 190 196 173 211 178 181.5 AKKO UK 172 167 160 190 175 219 180.5 CloudSilk 160 174 167 188 167 183 173.2 AKKO DE 241 166 139 199 151 117 168.8 Misaka DE 179 176 89 184 175 177 163.3 咸鱼云 NL 151 144 103 153 152 206 151.5 Geelinx 127 134 140 138 137 132 134.7 V.PS DE 155 146 148 102 107 130 131.3 MoeCloud 135 68 155 68 184 149 126.5 BWH NL 90 123 115 140 126 110 117.3 NOSLA 114 115 124 101 107 97 109.7 咸鱼云 DE Premium 88 102 95 119 127 116 107.8 V.PS NL 82 81 74 152 116 72 96.2 Nube DE 68 19 61 29 65 21 43.8 广州联通机房 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) Misaka RU 167 165 176 179 162 160 168.2 咸鱼云 DE Elite 161 172 160 154 160 162 161.5 咸鱼云 DE Premium 164 157 157 156 157 163 159.0 AKKO DE 162 152 162 169 158 143 157.7 咸鱼云 NL 143 153 162 153 156 154 153.5 CloudSilk 141 150 162 143 146 151 148.8 AKKO UK 151 142 127 156 156 147 146.5 Geelinx 150 140 144 141 150 151 146.0 BWH NL 148 147 139 146 138 142 143.3 V.PS NL 131 138 136 138 147 138 138.0 MoeCloud 122 139 140 137 119 133 131.7 NOSLA 128 126 132 127 132 128 128.8 Misaka DE 110 145 148 111 144 111 128.2 V.PS DE 134 126 124 130 117 132 127.2 Nube DE !46 82 70 60 73 !18 58.2 杭州联通家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) Misaka RU 188 178 180 170 164 172 175.3 咸鱼云 DE Elite 166 172 164 153 170 176 166.8 AKKO DE 166 155 178 168 158 152 162.8 咸鱼云 DE Premium 170 152 157 164 160 148 158.5 咸鱼云 NL 150 153 150 163 156 158 155.0 AKKO UK 156 152 155 164 156 144 154.5 CloudSilk 158 158 151 145 156 148 152.7 BWH NL 156 143 156 148 146 144 148.8 Geelinx 145 150 146 148 146 154 148.2 V.PS NL 138 139 138 137 144 147 140.5 NOSLA 130 132 136 126 132 136 132.0 V.PS DE 133 126 124 136 136 124 129.8 MoeCloud 126 133 125 137 113 146 130.0 Misaka DE 98 99 91 100 100 93 96.8 Nube DE 73 20 77 69 53 58 58.3 湛江联通家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) 咸鱼云 DE Elite 226 213 99 214 178 240 195.0 AKKO DE 188 169 129 169 150 190 165.8 Misaka RU 171 88 104 208 214 194 163.2 CloudSilk 176 159 148 164 126 191 160.7 V.PS NL 172 156 123 190 150 134 154.2 MoeCloud 159 131 147 212 186 75 151.7 咸鱼云 DE Premium 146 161 122 153 145 135 143.7 咸鱼云 NL 92 123 134 192 89 164 132.3 Geelinx 168 168 92 186 !49 92 125.8 BWH NL 142 147 113 86 130 136 125.7 NOSLA 116 111 133 129 112 134 122.5 AKKO UK 74 199 86 198 73 90 120.0 Misaka DE 82 76 127 112 121 123 106.8 V.PS DE 75 82 26 76 75 75 68.2 Nube DE 50 46 81 66 71 38 58.7 云南移动家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) 咸鱼云 DE Elite 202 182 196 194 178 206 193.0 咸鱼云 NL 190 174 174 198 189 191 186.0 V.PS NL 178 199 173 184 173 187 182.3 AKKO DE 207 140 202 188 190 144 178.5 AKKO UK 167 178 166 178 177 180 174.3 NOSLA 168 172 157 168 168 171 167.3 Geelinx 185 187 !60 166 185 182 160.8 咸鱼云 DE Premium 136 150 158 171 157 158 155.0 V.PS DE 157 156 156 157 !100 157 147.2 CloudSilk 145 134 156 132 149 154 145.0 Nube DE 155 143 159 164 92 122 139.2 MoeCloud 120 150 136 140 126 120 132.0 BWH NL 93 114 164 124 143 142 130.0 Misaka DE !23 24 32 25 25 21 25.0 Misaka RU 24 !3 !3 25 14 26 15.8 广州移动家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) 咸鱼云 NL 778 1004 1034 722 628 602 794.7 咸鱼云 DE Elite 633 896 542 563 574 507 619.2 CloudSilk 628 580 616 604 598 454 580.0 V.PS NL 555 508 512 500 488 516 513.2 AKKO UK 492 551 541 567 480 487 519.7 AKKO DE 595 406 482 484 457 587 501.8 Nube DE 402 284 478 400 382 250 366.0 MoeCloud 316 270 332 292 269 306 297.5 Geelinx 189 191 191 190 191 190 190.3 V.PS DE 183 158 171 184 181 170 174.5 NOSLA 168 180 178 168 157 177 171.3 咸鱼云 DE Premium 167 178 181 168 158 !10 143.7 BWH NL 147 156 114 139 142 132 138.3 Misaka DE 126 !4 166 92 110 124 103.7 Misaka RU 136 122 120 140 !4 68 98.3 广州移动机房 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) 咸鱼云 DE Elite 162 151 154 163 147 165 157.0 AKKO DE 154 161 155 156 148 158 155.3 咸鱼云 NL 144 156 149 146 150 146 148.5 咸鱼云 DE Premium 151 140 151 150 139 147 146.3 AKKO UK 140 151 139 145 141 144 143.3 NOSLA 140 145 142 111 157 151 141.0 V.PS NL 122 148 142 136 138 146 138.7 Geelinx 140 137 136 148 139 124 137.3 V.PS DE 142 153 122 125 123 144 134.8 BWH NL 136 105 137 120 127 118 123.8 CloudSilk 131 122 120 120 123 119 122.5 MoeCloud 99 101 106 99 86 99 98.3 Nube DE 58 76 71 60 84 70 69.8 Misaka RU 32 22 25 27 26 17 24.8 Misaka DE 6 26 25 25 31 6 19.8 湛江移动家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) AKKO DE 93 93 91 89 92 93 91.8 AKKO UK 93 93 92 91 91 91 91.8 CloudSilk 93 90 91 92 93 83 90.3 NOSLA 91 91 91 90 91 92 91.0 V.PS DE 91 84 90 90 92 89 89.3 BWH NL 92 89 85 88 85 91 88.3 咸鱼云 DE Elite 74 93 92 92 90 93 89.0 咸鱼云 DE Premium 89 83 86 88 89 87 87.0 Geelinx 84 !13 92 90 88 88 75.8 MoeCloud 92 73 76 72 73 70 76.0 Nube DE 58 73 70 59 57 78 65.8 咸鱼云 NL 28 90 93 93 85 86 79.2 Misaka DE 24 24 16 21 24 27 22.7 Misaka RU 21 7 21 22 28 20 19.8 湖南移动家宽 服务商 测试1 测试2 测试3 测试4 测试5 测试6 平均速度(Mbps) V.PS NL 197 202 200 200 182 150 188.5 NOSLA 169 168 170 168 178 166 169.8 V.PS DE 188 184 186 173 178 !110 169.8 咸鱼云 DE Premium 169 161 166 164 162 168 165.0 Misaka DE 161 146 154 150 162 154 154.5 Misaka RU 148 144 148 174 152 152 153.0 Geelinx 174 94 80 109 144 190 131.8 AKKO UK 92 100 200 100 98 196 131.0 咸鱼云 DE Elite 99 216 101 106 102 107 121.8 咸鱼云 NL 103 104 208 105 104 105 121.5 AKKO DE 106 98 106 104 161 105 113.3 BWH NL 122 !88 122 158 84 106 113.3 CloudSilk 78 150 136 75 81 81 100.2 Nube DE 84 75 69 60 71 80 73.2 MoeCloud 69 74 58 65 66 67 66.5 IP质量 我们选取了当前拥有机器的IP质量作为IP质量的数据参考标准，我们仅记录原生IP和部分常见流媒体的解锁情况，如有详细流媒体解锁需求的可以去 常见测试结果速览 中详细查看 值得注意的是：同一款机器的不同IP段的IP质量通常不同甚至大相径庭，并且这些机器都是线路机器，我们不认为IP质量是一个很重要的参考依据，仅仅只是一个锦上添花的点而已。 服务商 原生IP TikTok Disney+ Netflix Youtube AmazonPV Reddit ChatGPT Geelinx-UK √ √ √ √ √ √ √ √ V.PS-NL √ √ √ √ √ √ √ √ AKKO-UK √ √ √ √ √ √ √ √ 咸鱼云DE-Pre × √ √ √ √ √ √ √ Nube-DE × √ √ √ √ √ √ √ Misaka-DE × √ √ √ √ √ √ √ CloudSilk-DE √ √ × √ √ √ × √ BWH-NL × √ × √ √ √ √ √ V.PS-DE √ √ × √ 送中 √ × √ NOSLA-DE √ √ × √ × √ × √ 咸鱼云-NL × √ × √ √ √ × √ AKKO-DE × √ × √ √ √ × √ 咸鱼云DE-Elite × √ × √ √ √ × √ MoeCloud-UK × √ × √ √ √ × √ Misaka-RU × √ × × × √ √ × That is all，各位，再次感谢所有商家和MJJ们的支持，我们下期再见哦~ 6 个帖子 - 6 位参与者 阅读完整话题
前两期回顾： 【超详细】手机搭建服务器 · 第 一 期 【超详细】手机搭建服务器 · 第 二 期 前言 第一期讲了必备条件；第二期讲了如何实现旁路供电，解决供电问题； 本期要实现的是：如何让手机的wifi永不断连： 不管是手机意外重启，还是重新开关机； 不管是开启了飞行模式； 不管是不是主动关闭wifi。 [!warning]建议 在开始之前，建议先把手机的这两个开关关闭，不是必须，但是建议，减少干扰： 系统设置 - 开发者选项 - WLAN扫描调节 - 关闭 系统设置 - WLAN - WLAN助理 - 智能选网和网速模式 - 关闭 补充说明： · 机型不同，打开开发者选项的方式也不同，这个自己百度 · 不是所有手机都有【WLAN助理】这个选项，我是MIUI 11，所有有，其他手机可能是其他名字，或者没有这个功能，自己看自己系统的功能开关。 主要是把能影响WIFI稳定的开关关闭，不管是信号调节还是省电方面的设置。 教程开始 1.新建开机自启脚本 1.1 打开MT管理器，进入 /data/adb/service.d/ 文件夹，新建 99-phone-server.sh 文件 1.2 打开文件，在文件中输入以下代码并保存： #!/system/bin/sh # ============================================================ # Phone Server 启动器 # 放在 Magisk service.d 中 # 注意： # 这个脚本不写其他的复杂业务逻辑，只负责启动真正的脚本。 # 以后 IPv6、DDNS、Debian、SSH 等脚本，也会这么做。 # ============================================================ WIFI_KEEPER="/data/local/phone-server/wifi-keeper/wifi-keeper.sh" WIFI_LOG="/data/local/phone-server/wifi-keeper/wifi-keeper.log" mkdir -p /data/local/phone-server/wifi-keeper echo "$(date '+%Y-%m-%d %H:%M:%S') [INFO] [启动器] 99-phone-server.sh 开始执行" >> "$WIFI_LOG" if [ -x "$WIFI_KEEPER" ]; then nohup "$WIFI_KEEPER" >/dev/null 2>&1 & echo "$(date '+%Y-%m-%d %H:%M:%S') [OK] [启动器] 已后台启动 Wi-Fi Keeper" >> "$WIFI_LOG" else echo "$(date '+%Y-%m-%d %H:%M:%S') [ERROR] [启动器] Wi-Fi Keeper 不存在或没有执行权限：$WIFI_KEEPER" >> "$WIFI_LOG" fi 1.3给脚本设置权限 2.新建wifi核心脚本 2.1 打开MT管理器，进入 /data/local/ 文件夹，新建 phone-server 文件夹，然后进入 phone-server 文件夹再新建 wifi-keeper 文件夹； 2.2 在 /data/local/phone-server/wifi-keeper/ 文件夹下面新建 wifi-keeper.sh 文件，并且输入下面的代码进行保存： #!/system/bin/sh # ============================================================ # Wi-Fi Keeper # ============================================================ # 功能： # 1. 开机后自动检查 wifi 开关 # 2. 如果 wifi 关闭，自动打开 wifi # 3. 等待系统自动连接“已保存”的 wifi # 4. 如果系统没有自动连上，则按 WIFI_LIST 优先级选择已保存 wifi # 5. wifi 断开后，自动重新连接 # 6. 输出详细日志，方便排查 # # 适用环境： # Android Root + Magisk service.d # # 重要说明： # 1. 需要提前手动连接一次 wifi，让系统保存 wifi。 # 2. WIFI_LIST 里只写 Wi-Fi 名称，不用写密码、不用写验证方式。 # 3. 如果一个WI-FI没连接成功，系统会连接下一个wifi # 4. 这是常驻守护脚本，不是执行一次就退出的脚本。 # ============================================================ # ============================================================ # 基础路径配置 # ============================================================ BASE_DIR="/data/local/phone-server/wifi-keeper" LOG_FILE="$BASE_DIR/wifi-keeper.log" # 临时锁目录，放在 /dev，重启后自动消失 # 作用：防止同一个 wifi-keeper 被重复启动 LOCK_DIR="/dev/phone-server-wifi-keeper.lock" WIFI_IFACE="wlan0" # ============================================================ # Wi-Fi 列表配置 # ============================================================ # 格式： # 一行一个 Wi-Fi 名称。 # # 顺序就是优先级： # 第一行优先级最高，连接失败才尝试下一行。 # ============================================================ WIFI_LIST=" CMCC-Semmering " # ============================================================ # 行为参数 # ============================================================ # 开机后等待系统完全启动，最多等待多少秒，单位：秒 BOOT_WAIT_MAX=60 # 系统启动完成后，额外等待多少秒，单位：秒 # 有些 MIUI 设备 sys.boot_completed=1 后，Wi-Fi 服务还没完全准备好。 AFTER_BOOT_EXTRA_WAIT=10 # 打开 Wi-Fi 后，最多等待多久确认 Wi-Fi 进入可连接状态，单位：秒 ENABLE_WIFI_WAIT=10 # 打开 Wi-Fi 后，等待系统自动连接已保存 Wi-Fi 的时间，单位：秒 AUTO_CONNECT_WAIT=10 # 使用 wpa_cli 选择已保存 Wi-Fi 后，最多等待多久拿到 IP，单位：秒 SELECT_WIFI_WAIT=30 # 正常情况下，每隔多少秒检查一次 Wi-Fi，单位：秒 CHECK_INTERVAL=60 # 本轮修复失败后，等待多少秒再重试，单位：秒 FAIL_COOLDOWN=30 # 日志最大大小，单位：字节 # 1048576 字节 = 1MB # 超过后只保留最后 300 行，避免日志无限增长 MAX_LOG_SIZE=1048576 # ============================================================ # 全局变量 # ============================================================ WPA_CLI_BIN="" WPA_CTRL_DIR="" WPA_LAST_OUT="" # ============================================================ # 日志函数 # ============================================================ now() { date '+%Y-%m-%d %H:%M:%S' } # 避免日志里输出 MAC 地址 / BSSID mask_mac() { echo "$1" | sed -E 's/([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}/[MAC已隐藏]/g' } # 取 WIFI_LIST 中第一个有效 wifi名称，用于“尚未解析到当前 SSID”时的日志提示。 # 这样日志不会把 MIUI 的 BSSID / state 状态误当成 Wi-Fi 名称。 get_first_wifi_name_from_list() { printf '%s\n' "$WIFI_LIST" | while IFS= read -r line; do [ -z "$line" ] && continue case "$line" in \#*) continue ;; esac echo "$line" return 0 done } # 清洗从 dumpsys / wpa_cli 解析出来的 SSID。 clean_ssid_value() { raw="$1" ssid="$(echo "$raw" | sed 's/^ *//;s/ *$//')" case "$ssid" in ""|"<unknown ssid>"|"unknown"|"null"|"0x"|"WifiSsid.NONE"|"none"|"<none>") echo "" return 0 ;; esac echo "$ssid" | grep -Eiq '([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}|(^|[[:space:]])nid:|(^|[[:space:]])state:|bssid|scanning|associating|disconnected|completed' && { echo "" return 0 } echo "$ssid" } rotate_log_if_needed() { [ -f "$LOG_FILE" ] || return 0 size="$(wc -c < "$LOG_FILE" 2>/dev/null)" [ -n "$size" ] || return 0 if [ "$size" -gt "$MAX_LOG_SIZE" ]; then tail -n 300 "$LOG_FILE" > "$LOG_FILE.tmp" 2>/dev/null mv "$LOG_FILE.tmp" "$LOG_FILE" 2>/dev/null fi } log() { level="$1" action="$2" msg="$(mask_mac "$3")" mkdir -p "$BASE_DIR" rotate_log_if_needed echo "$(now) [$level] [$action] $msg" >> "$LOG_FILE" } log_info() { log "INFO" "$1" "$2" } log_ok() { log "OK" "$1" "$2" } log_error() { log "ERROR" "$1" "$2" } # ============================================================ # 防止重复运行 # ============================================================ acquire_lock() { if mkdir "$LOCK_DIR" 2>/dev/null; then trap 'rm -rf "$LOCK_DIR"; log_info "退出脚本" "Wi-Fi Keeper 已退出，释放 lock"' EXIT log_ok "启动脚本" "获取 lock 成功，当前实例开始运行" return 0 fi log_error "启动脚本" "检测到已有 Wi-Fi Keeper 正在运行，当前实例退出" exit 0 } # ============================================================ # 环境检查 # ============================================================ check_env() { mkdir -p "$BASE_DIR" if ! command -v svc >/dev/null 2>&1; then log_error "检查环境" "系统不支持 svc 命令，无法打开 Wi-Fi" exit 1 fi if ! command -v ip >/dev/null 2>&1; then log_error "检查环境" "系统不支持 ip 命令，无法检测 wlan0 地址" exit 1 fi log_ok "检查环境" "环境检查完成" } wait_boot_completed() { log_info "等待系统启动" "开始等待 sys.boot_completed=1" i=0 while [ "$i" -lt "$BOOT_WAIT_MAX" ]; do boot_completed="$(getprop sys.boot_completed 2>/dev/null)" if [ "$boot_completed" = "1" ]; then log_ok "等待系统启动" "系统启动完成" return 0 fi sleep 2 i=$((i + 2)) done log_error "等待系统启动" "等待系统启动完成超时，继续执行后续逻辑" return 1 } # ============================================================ # Wi-Fi 状态判断 # ============================================================ wifi_on_value() { settings get global wifi_on 2>/dev/null } wifi_on_text() { v="$(wifi_on_value)" case "$v" in 0) echo "关闭" ;; 1) echo "已开启" ;; 2) echo "正在开启" ;; 3) echo "正在关闭" ;; *) echo "未知状态:$v" ;; esac } has_wifi_ip() { ip -4 addr show dev "$WIFI_IFACE" 2>/dev/null | grep -q "inet " && return 0 ip -6 addr show dev "$WIFI_IFACE" scope global 2>/dev/null | grep -q "inet6 " && return 0 return 1 } wifi_iface_up() { ip link show "$WIFI_IFACE" 2>/dev/null | grep -q "UP" } wifi_ready_for_connect() { # 已经拿到 IP，说明 Wi-Fi 已连接 has_wifi_ip && return 0 # settings 显示已开启 [ "$(wifi_on_value)" = "1" ] && return 0 # wlan0 已经 UP，也说明可以等待系统自动连接或尝试选择已保存网络 wifi_iface_up && return 0 return 1 } # ============================================================ # 当前 Wi-Fi 名称解析 # ============================================================ find_wpa_cli_bin_quiet() { [ -n "$WPA_CLI_BIN" ] && [ -x "$WPA_CLI_BIN" ] && return 0 for b in \ "$(command -v wpa_cli 2>/dev/null)" \ "/system/bin/wpa_cli" \ "/vendor/bin/wpa_cli" \ "/system/xbin/wpa_cli" \ "/system_ext/bin/wpa_cli" do [ -z "$b" ] && continue if [ -x "$b" ]; then WPA_CLI_BIN="$b" return 0 fi done return 1 } wpa_cli_raw() { if [ -z "$WPA_CTRL_DIR" ]; then "$WPA_CLI_BIN" -i "$WIFI_IFACE" "$@" 2>&1 else "$WPA_CLI_BIN" -p "$WPA_CTRL_DIR" -i "$WIFI_IFACE" "$@" 2>&1 fi } get_current_ssid_from_wpa() { find_wpa_cli_bin_quiet || return 0 # 如果已经检测过控制目录，就直接用 if [ -n "$WPA_CTRL_DIR" ]; then out="$(wpa_cli_raw status 2>/dev/null)" ssid="$(echo "$out" | sed -n 's/^ssid=//p' | head -n 1)" ssid="$(clean_ssid_value "$ssid")" [ -n "$ssid" ] && echo "$ssid" return 0 fi # 尝试几个常见控制目录 for p in \ "" \ "/data/vendor/wifi/wpa/sockets" \ "/data/misc/wifi/sockets" \ "/dev/socket" do WPA_CTRL_DIR="$p" out="$(wpa_cli_raw status 2>/dev/null)" echo "$out" | grep -q "wpa_state" || continue ssid="$(echo "$out" | sed -n 's/^ssid=//p' | head -n 1)" ssid="$(clean_ssid_value "$ssid")" if [ -n "$ssid" ]; then echo "$ssid" return 0 fi done WPA_CTRL_DIR="" return 0 } get_current_ssid_from_dumpsys() { # 只提取 SSID，避免输出 BSSID/MAC。 line="$(dumpsys wifi 2>/dev/null | grep -m 1 "SSID:" 2>/dev/null)" [ -z "$line" ] && return 0 ssid="$(echo "$line" | sed -n 's/.*SSID: *"\([^"]*\)".*/\1/p')" if [ -z "$ssid" ]; then ssid="$(echo "$line" | sed -n 's/.*SSID: *\([^,]*\).*/\1/p')" fi ssid="$(clean_ssid_value "$ssid")" [ -n "$ssid" ] && echo "$ssid" } get_current_ssid() { ssid="$(get_current_ssid_from_wpa)" if [ -n "$ssid" ]; then echo "$ssid" return 0 fi ssid="$(get_current_ssid_from_dumpsys)" if [ -n "$ssid" ]; then echo "$ssid" return 0 fi echo "" } # 获取日志里应该显示的 Wi-Fi 名称。 # 说明： # MIUI 11 / Android 10 有时不允许从 wpa_cli / dumpsys 稳定解析当前 SSID。 # 如果已经拿到 Wi-Fi IP，但解析不到 SSID，并且 WIFI_LIST 里配置了目标 Wi-Fi， # 就在日志中显示“目标 WiFi + 推断说明”，避免反复出现“未解析到当前WiFi名称”。 get_display_wifi_name() { real_ssid="$(get_current_ssid)" if [ -n "$real_ssid" ]; then echo "$real_ssid" return 0 fi target_ssid="$(get_first_wifi_name_from_list)" if has_wifi_ip && [ -n "$target_ssid" ]; then echo "$target_ssid（根据WIFI_LIST推断）" return 0 fi if [ -n "$target_ssid" ]; then echo "未连接；目标WiFi=$target_ssid" else echo "未连接" fi } log_wifi_basic_status() { wifi_value="$(wifi_on_value)" wifi_text="$(wifi_on_text)" ssid="$(get_display_wifi_name)" ip_info="$(ip addr show dev "$WIFI_IFACE" 2>/dev/null | grep -E 'inet |inet6 ' | tr '\n' ' ')" [ -z "$ip_info" ] && ip_info="未拿到IP" log_info "WiFi状态" "WiFi开关=$wifi_value($wifi_text)；当前WiFi=$ssid；IP=$ip_info" } enable_wifi() { if wifi_ready_for_connect; then log_ok "打开WiFi开关" "Wi-Fi 已经处于可用或可连接状态，无需重复打开" log_wifi_basic_status return 0 fi log_info "打开WiFi开关" "检测到 Wi-Fi 关闭，开始打开 Wi-Fi" out="$(svc wifi enable 2>&1)" rc="$?" if [ "$rc" -ne 0 ]; then log_error "打开WiFi开关" "svc wifi enable 执行失败，rc=$rc，输出：$out" return 1 fi log_info "打开WiFi开关" "svc wifi enable 执行成功，开始等待 Wi-Fi 进入可连接状态" i=0 while [ "$i" -lt "$ENABLE_WIFI_WAIT" ]; do if wifi_ready_for_connect; then log_ok "打开WiFi开关" "Wi-Fi 已进入可用或可连接状态" log_wifi_basic_status return 0 fi if [ $((i % 10)) -eq 0 ]; then log_info "打开WiFi开关" "等待 Wi-Fi 开启中，已等待 ${i} 秒" log_wifi_basic_status fi sleep 2 i=$((i + 2)) done log_error "打开WiFi开关" "已执行打开 Wi-Fi，但 ${ENABLE_WIFI_WAIT} 秒内没有确认进入可连接状态" log_wifi_basic_status return 1 } wifi_connected_ok() { if ! has_wifi_ip; then return 1 fi ssid="$(get_display_wifi_name)" log_ok "检查WiFi状态" "Wi-Fi 已连接，当前WiFi=$ssid，已拿到 IP" return 0 } wait_wifi_connected() { action="$1" max_wait="$2" i=0 while [ "$i" -lt "$max_wait" ]; do if wifi_connected_ok; then log_ok "$action" "连接判断成功" return 0 fi if [ $((i % 10)) -eq 0 ]; then log_info "$action" "等待 Wi-Fi 获取 IP，已等待 ${i} 秒" log_wifi_basic_status fi sleep 2 i=$((i + 2)) done log_error "$action" "等待 ${max_wait} 秒后仍未拿到 Wi-Fi IP" log_wifi_basic_status return 1 } wait_auto_connect() { log_info "自动连接WIFI" "等待系统自动连接已保存 Wi-Fi，最长等待 ${AUTO_CONNECT_WAIT} 秒" if wait_wifi_connected "自动连接WIFI" "$AUTO_CONNECT_WAIT"; then return 0 fi log_error "自动连接WIFI" "系统自动连接超时，准备按 Wi-Fi 名称选择已保存网络" return 1 } # ============================================================ # 使用 wpa_cli 选择已保存 wifi # 注意：这里只选择已保存网络，不写入密码，不创建新网络 # ============================================================ find_wpa_cli_bin() { if find_wpa_cli_bin_quiet; then log_ok "查找wpa_cli" "找到 wpa_cli：$WPA_CLI_BIN" return 0 fi log_error "查找wpa_cli" "没有找到 wpa_cli，无法主动选择已保存 Wi-Fi，只能依赖系统自动连接" return 1 } wpa_exec() { action="$1" shift WPA_LAST_OUT="$(wpa_cli_raw "$@")" rc="$?" safe_out="$(mask_mac "$WPA_LAST_OUT")" log_info "$action" "执行：$WPA_CLI_BIN ${WPA_CTRL_DIR:+-p $WPA_CTRL_DIR} -i $WIFI_IFACE $*；rc=$rc；输出：$safe_out" return "$rc" } find_wpa_cli_control() { if ! find_wpa_cli_bin; then return 1 fi for p in \ "" \ "/data/vendor/wifi/wpa/sockets" \ "/data/misc/wifi/sockets" \ "/dev/socket" do WPA_CTRL_DIR="$p" out="$(wpa_cli_raw status 2>&1)" rc="$?" safe_out="$(mask_mac "$out")" log_info "检测wpa_cli" "尝试控制目录='${p:-默认}'，rc=$rc，输出：$safe_out" echo "$out" | grep -q "wpa_state" && { log_ok "检测wpa_cli" "wpa_cli 可用，控制目录='${p:-默认}'" return 0 } done WPA_CTRL_DIR="" log_error "检测wpa_cli" "wpa_cli 存在，但无法连接到 Wi-Fi 控制接口，只能依赖系统自动连接" return 1 } find_saved_network_id_by_ssid() { target_ssid="$1" wpa_exec "查找已保存WIFI" list_networks network_id="$(printf '%s\n' "$WPA_LAST_OUT" \ | awk -F '\t' -v target="$target_ssid" 'NR > 1 && $2 == target {print $1; exit}')" if [ -z "$network_id" ]; then log_error "查找已保存WIFI" "没有找到已保存的 Wi-Fi：$target_ssid。请先手动连接一次并保存" return 1 fi log_ok "查找已保存WIFI" "找到已保存 Wi-Fi：$target_ssid，network_id=$network_id" echo "$network_id" return 0 } select_saved_wifi_by_ssid() { ssid="$1" log_info "选择WIFI" "准备选择已保存 Wi-Fi：$ssid" if ! find_wpa_cli_control; then return 1 fi network_id="$(find_saved_network_id_by_ssid "$ssid")" if [ -z "$network_id" ]; then return 1 fi wpa_exec "启用WIFI" enable_network "$network_id" wpa_exec "选择WIFI" select_network "$network_id" wpa_exec "重连WIFI" reconnect if wait_wifi_connected "选择WIFI" "$SELECT_WIFI_WAIT"; then current_ssid="$(get_display_wifi_name)" log_ok "选择WIFI" "已连接 Wi-Fi：$current_ssid" return 0 fi log_error "选择WIFI" "已尝试选择 Wi-Fi：$ssid，但最终没有拿到 IP" return 1 } connect_by_priority() { log_info "连接WIFI" "开始按 WIFI_LIST 顺序选择已保存 Wi-Fi" tmp_list="/dev/phone-server-wifi-list.tmp" printf '%s\n' "$WIFI_LIST" > "$tmp_list" while IFS= read -r ssid; do [ -z "$ssid" ] && continue case "$ssid" in \#*) continue ;; esac log_info "连接WIFI" "按优先级尝试选择 Wi-Fi：$ssid" if select_saved_wifi_by_ssid "$ssid"; then rm -f "$tmp_list" 2>/dev/null return 0 fi log_error "连接WIFI" "Wi-Fi=$ssid 连接失败，继续尝试下一个" done < "$tmp_list" rm -f "$tmp_list" 2>/dev/null log_error "连接WIFI" "WIFI_LIST 中的已保存 Wi-Fi 都没有连接成功" return 1 } # ============================================================ # 主循环 # ============================================================ main_loop() { log_info "启动脚本" "Wi-Fi Keeper 启动" wait_boot_completed if [ "$AFTER_BOOT_EXTRA_WAIT" -gt 0 ]; then log_info "等待系统服务" "系统已启动，额外等待 ${AFTER_BOOT_EXTRA_WAIT} 秒，让 Wi-Fi 服务准备完成" sleep "$AFTER_BOOT_EXTRA_WAIT" fi log_wifi_basic_status enable_wifi if wait_auto_connect; then log_ok "启动连接" "系统自动连接 Wi-Fi 成功" else connect_by_priority fi while true; do if wifi_connected_ok; then sleep "$CHECK_INTERVAL" continue fi log_error "守护检测" "检测到 Wi-Fi 不可用，开始自动修复" enable_wifi if wait_auto_connect; then log_ok "守护检测" "系统自动恢复 Wi-Fi 成功" else if connect_by_priority; then log_ok "守护检测" "按 Wi-Fi 名称选择已保存网络成功" else log_error "守护检测" "本轮 Wi-Fi 修复失败，${FAIL_COOLDOWN} 秒后重试" sleep "$FAIL_COOLDOWN" fi fi done } # ============================================================ # 程序入口 # ============================================================ acquire_lock check_env main_loop 2.3 按照1.3的过程给脚本设置权限。 [!question] 如何验证脚本是否成功 1. 手机先正常连接上你选择Wi-Fi，建议选择一个即可，避免手机因为某些原因在多个wifi之间来回切换，这个对后面的ipv6的解析影响非常大，然后关闭wifi的 自动连接 开关。 2. 正常连接上一个wifi以后，关闭wifi开关，把手机重启。 3.验证手机重启wifi是否能正常连接： 重启以后，等几秒钟（具体看配置你写的是几秒），然后看看wifi开关是否会自动打开，并且wifi是否会自动连接上。 4.验证手动断开wifi是否能正常连接： 如果wifi能自动连接上，可以手动关闭wifi开关，看看wifi是否能过几秒（具体还是要看配置你写的是几秒）后自动打开并且连接上wifi。 我用的脚本在米8SE上多轮测试没问题，如果你们有问题，记得联系我，我到时候拍查一下 [!question] 如何关闭脚本 方法一： 取消/data/adb/service.d/99-phone-server.sh脚本的执行权限 方法二： 删除/data/adb/service.d/99-phone-server.sh脚本 [!success]结束语 不得不说，AI是真的好用。不仅可以优化脚本，还能把注释写的清清楚楚。按照它的逻辑和日志，就算出问题了也能很好的定位和解决，这一次确实是省了不少时间。可惜两天撸的business 2个月翻车了。 另外，给佬友们送上一份可直接食用的prompt： 我现在正在把一台 Android 手机改造成 7×24 小时运行的家庭小服务器。 目前我已经完成了 ACC 充电控制，解决了长期插电和旁路供电相关的问题。下一步我要解决的是：手机与 Wi-Fi 之间的连接稳定性。 我的目标是： 手机开机后，或者 Wi-Fi 因为路由器重启、信号波动、系统休眠、网络异常等原因断开后，脚本能够自动恢复 Wi-Fi 连接，让手机尽可能长期稳定在线。 我的手机环境大概如下： - Android 手机，已 Root； - 使用 Magisk； - 开机自启动脚本可以通过 Magisk 的 `/data/adb/service.d/` 实现； - 手机会长期作为服务器运行； - 后续还会继续做 IPv6 公网地址检测、DDNS 同步、Debian/SSH 服务守护等脚本； - 所以我不希望所有业务脚本都直接堆在 `/data/adb/service.d/` 里。 --- # 我希望你帮我实现的事情 请你作为一名专业的 Android / Linux / Shell 脚本开发人员，帮我设计并编写一套 Wi-Fi 连接守护方案。 我希望它能实现这些能力： ## 1. 开机自动执行 手机开机后，Magisk 自动执行启动脚本。 但是我不希望把真正复杂的 Wi-Fi 守护逻辑直接写在 `/data/adb/service.d/` 里面。 我希望 `/data/adb/service.d/` 里只放一个“启动器脚本”，比如： ```text /data/adb/service.d/99-phone-server.sh ``` 这个启动器只负责启动真正的 Wi-Fi 守护脚本。 真正的 Wi-Fi 守护脚本和日志文件，请你帮我设计一个合理的目录，比如放在： ```text /data/local/phone-server/wifi-keeper/ ``` 或者你认为更合理的目录也可以，但请你说明为什么这样设计。 --- ## 2. 自动打开 Wi-Fi 脚本启动后，需要检查 Wi-Fi 开关状态。 如果 Wi-Fi 是关闭状态，就自动打开 Wi-Fi。 如果 Wi-Fi 已经打开，就不要重复操作。 注意： 不同 Android 版本、不同 ROM 对 Wi-Fi 命令支持可能不一样，所以请你不要想当然地只使用某一种命令。 请你先分析有哪些可能的实现方式，比如： * `svc wifi enable` * `settings get global wifi_on` * `ip link show wlan0` * `ip addr show wlan0` * `wpa_cli` * `cmd wifi` * `dumpsys wifi` 然后根据兼容性和稳定性，选择更适合 Magisk Root 环境的实现方式。 如果某些命令在部分系统上可能不可用，请在脚本里做好兼容、兜底和日志记录，而不是让脚本直接崩溃。 --- ## 3. Wi-Fi 列表和优先级 我希望脚本支持提前配置一个 Wi-Fi 列表。 比如： ```text 主 Wi-Fi 备用 Wi-Fi 手机热点 ``` 列表顺序就是优先级。 脚本应该优先连接列表中靠前的 Wi-Fi。 如果当前 Wi-Fi 可用，就不要频繁切换，避免影响 SSH、网页服务、IPv6、DDNS 等后续服务。 只有当当前 Wi-Fi 不可用、断开、没有拿到 IP，或者长时间无法恢复时，才尝试切换到下一个可用 Wi-Fi。 --- ## 4. 已保存 Wi-Fi 和新 Wi-Fi 的处理 请你根据 Android 实际情况，设计合理逻辑： * 如果 Wi-Fi 已经在系统中保存过，优先让系统自动连接； * 如果系统自动连接失败，再尝试根据 Wi-Fi 名称选择已保存网络； * 如果脚本能够可靠地支持“通过密码添加新 Wi-Fi”，可以设计为可选能力； * 如果某些 Android 版本或 ROM 不适合脚本直接写入 Wi-Fi 密码，也请你明确说明原因，并给出更稳定的替代方案。 我不希望脚本为了追求“看起来功能完整”，强行使用不可靠的命令。 请你优先保证稳定性。 --- ## 5. 不要频繁扫描和切换 手机是作为服务器使用的，所以稳定性比“永远连接最高优先级 Wi-Fi”更重要。 请你设计逻辑时注意： * 如果当前 Wi-Fi 已经连接成功，并且已经拿到 IP，就不要乱动； * 不要频繁扫描 Wi-Fi； * 不要频繁断开当前 Wi-Fi 再切换； * 不要在信号短暂波动时马上切换； * 需要有合理的重试间隔和冷却时间； * 避免脚本疯狂循环导致耗电、发热、刷屏日志。 --- ## 6. Wi-Fi 是否连接成功的判断 我希望脚本不要只看 Wi-Fi 开关是否打开。 真正有意义的是： ```text 手机是否已经通过 wlan0 拿到了 IP 地址 ``` 请你设计连接成功判断逻辑。 比如： * wlan0 拿到 IPv4； * 或者 wlan0 拿到全局 IPv6； * 或者两者都可以。 暂时不需要做外网连通性检测，比如 ping 某个公网 IP。 因为公网 ping 可能受 DNS、运营商、防火墙、网络环境影响，不适合作为 Wi-Fi 是否连接成功的唯一依据。 --- ## 7. 日志要求 脚本必须输出清晰日志，方便我排查问题。 日志中需要包含： * 时间，格式为 `YYYY-MM-DD HH:mm:ss`； * 日志级别，比如 `INFO`、`OK`、`ERROR`； * 当前操作名称，比如： * 启动脚本 * 等待系统启动 * 打开 Wi-Fi 开关 * 检查 Wi-Fi 状态 * 等待系统自动连接 * 选择已保存 Wi-Fi * 重连 Wi-Fi * 进入守护循环 * 错误原因； * 关键命令的返回值和输出，方便排查。 日志示例可以类似： ```text 2026-05-15 22:01:23 [OK] [启动脚本] 获取 lock 成功，当前实例开始运行 2026-05-15 22:01:40 [OK] [等待系统启动] 系统启动完成 2026-05-15 22:01:52 [INFO] [打开WiFi开关] 检测到 Wi-Fi 关闭，开始打开 Wi-Fi 2026-05-15 22:01:55 [OK] [打开WiFi开关] Wi-Fi 已进入可连接状态 2026-05-15 22:02:36 [OK] [检查WiFi状态] Wi-Fi 已连接，当前WiFi=xxx，已拿到 IP ``` 日志文件也要限制大小，避免长期运行后日志无限变大。 请你在脚本里设计日志轮转，例如超过 1MB 后只保留最后若干行，并且在注释中写清楚单位。 --- ## 8. 日志中的 Wi-Fi 名称和隐私 如果能解析当前 Wi-Fi 名称，日志中应该显示 Wi-Fi 名称，而不是 MAC 地址。 如果某些系统状态中出现 BSSID / MAC 地址，请隐藏或过滤掉。 例如不要输出： ```text 00:00:00:00:00:00 nid: 0 state: ASSOCIATING ``` 这不是 Wi-Fi 名称，而是系统连接状态。 如果暂时解析不到当前 Wi-Fi 名称，但已经拿到 wlan0 的 IP，请不要误判为失败。 这种情况下可以写： ```text Wi-Fi 已连接，已拿到 IP，但当前 Wi-Fi 名称暂时无法解析 ``` 或者如果配置列表里只有一个目标 Wi-Fi，也可以说明是根据配置推断的名称。 --- ## 9. 防止重复运行 这个脚本是常驻守护脚本，不是一次性脚本。 所以请你加入 lock 机制，防止多个相同脚本同时运行。 我希望你使用适合 Android / Magisk 环境的方式，比如： * 使用目录锁； * lock 放在 `/dev` 这种重启后会自动清理的临时目录； * 不要用容易残留的持久 PID 文件； * 如果脚本正常退出，要自动释放 lock； * 如果检测到已有实例运行，当前脚本应该退出，并写入日志。 请你解释一下 lock 的作用和为什么这样设计。 --- ## 10. 守护循环 脚本不应该只在开机时执行一次。 它应该是常驻守护脚本。 大概逻辑应该是： ```text 等待系统启动完成 ↓ 打开 Wi-Fi ↓ 等待系统自动连接已保存 Wi-Fi ↓ 如果连接成功，进入守护循环 ↓ 每隔一段时间检查 Wi-Fi 是否仍然连接 ↓ 如果 Wi-Fi 正常，什么都不做 ↓ 如果 Wi-Fi 不正常，开始自动修复 ↓ 重新打开 Wi-Fi / 等待自动连接 / 必要时选择已保存 Wi-Fi ↓ 失败则等待冷却时间后重试 ``` --- # 请你特别注意 我上面的想法可能并不成熟，所以请你不要只是机械照着我的描述写。 请你先站在专业 Android 开发人员和 Linux 运维人员的角度，帮我完善整体逻辑。 在正式给代码之前，请你先做一次简短但准确的设计分析，包括： 1. 推荐目录结构； 2. 为什么 service.d 里只放启动器； 3. Wi-Fi 守护脚本应该承担哪些职责； 4. 哪些事情不应该放在 Wi-Fi 守护脚本里，比如 IPv6 检测、DDNS 同步； 5. 如何判断 Wi-Fi 是否真的可用； 6. 如何避免重复运行； 7. 哪些命令在 Android 上可能存在兼容性问题，脚本应该如何处理。 然后再给我完整代码。 --- # 输出要求 请输出： ## 第一部分：设计说明 用通俗易懂的话解释整体方案。 ## 第二部分：目录结构 给出推荐目录结构，并说明每个文件的作用。 ## 第三部分：Magisk 启动器脚本 给出完整代码，可以直接复制使用。 ## 第四部分：Wi-Fi 守护脚本 给出完整代码，可以直接复制使用。 ## 第五部分：安装和测试命令 包括： * 创建目录； * 写入脚本； * 添加执行权限； * 手动启动测试； * 查看日志； * 停止脚本； * 清理 lock； * 如何确认脚本是否正在运行。 --- # 我的最终目标 我希望得到的是一套适合 Android Root + Magisk + 手机服务器场景的 Wi-Fi 稳定连接方案。 重点是： * 稳定； * 易排查； * 日志清晰； * 不重复运行； * 不乱切 Wi-Fi； * 不把所有功能写成一个超级大脚本； * 后续方便扩展 IPv6 检测、DDNS 更新、Debian / SSH 守护等功能。 请你根据这些目标，帮我设计并实现一个更专业、更稳定、更容易维护的版本。 1 个帖子 - 1 位参与者 阅读完整话题
没想到上次刚发没多久就被Google收录到了 目前已经上架了表情包，但是不知道是不是搜索的问题，暂时可能是搜不到 前几个系列有点少了，下一个上架的表情包会做的更多一点 表情包 （点击了解更多详细信息） 往期表情包 我要开始起号了佬友们，那么第一件事是... 搞七捻三 如标题所示，我觉得写文起号太慢了，所以我打算今天出道为虚拟偶像 原设，image2还是太权威了 [白芸汐-原设] 现在用的是布偶的头像 [白芸汐-布偶] 做了一些表情包和头像 系列一 还有一些其他的九宫格，大家有需要可以自取~ 九宫格 我知道你们想要什么，特地做了一下（千万不要@哈雷酱） … [表情包] 分享一下自设的表情包——第一期 搞七捻三 抽了很多次卡，GPT image 2只能单次生图比较厉害，修改就差的比较多，可自取 有什么需要我来做的表情包佬友们可以贡献一下，我会收集一下，下一期发出来。 我剑也未尝不利 [表情包-我剑也未尝不利] 欲言又止 [表情包-欲言又止] 看来是旧病复发也 [表情包-看来是旧病复发也] 嘲笑 [表情包-嘲笑] 这家伙在说什么呢 [表情包-这家伙在说什么呢] 快做啊哈雷 [表情包… 1 个帖子 - 1 位参与者 阅读完整话题
从 【Agent笔记】我们一起来学习Agent！（第1期） 继续讨论；我第一期的时候就是想记录一下，因为我在开发agent项目。没想到佬们那么欢迎，我真的诚惶诚恐。 然后这个月实在太忙了：上半月一直在做自己的项目，希望拿到一些投资。前两天刚郴州旅游回来，然后手上两个团队项目在做，而gpt plus眼看着过期了，我就想是时候提高自己的提示词技术和相关知识了————所以也很忙。 今天本来打算写多点的，但是我想还是留到下一期————**我保证这会很快的！就这个星期！**因为今晚有小姐姐叫我打游戏了，休息一波 佬我准备买个coding plan了，50左右推荐一个呗，就那种玩具的，我经常需要写一个玩具项目，要求有GLM5左右的水平就可以，主要是周量够，业余开发。没有的话我打算买kimi那个80的了，老板还给我配了gpt plus就不用在自己项目了。 正文开始： 我们一起学Agent！（第二期） Context（上下文） 定义：Agent在每次执行任务时能够获得的外部信息。一个agent的质量很大程度上取决于它能访问到的上下文——即使系统提示写得再完美，缺少正确的上下文（背景，语境，解决问题需要的信息）也会导致结果不佳。 在agno中，提供了三种原生方式进行context的提供 Knowledge（知识库） 我们需要预先做两个事情，第一建立对象绑定数据库，第二建好知识库 创建一个 Knowledge 对象，绑定一个向量数据库（如 PgVector）。 将内容从本地文件、URL 等添加到知识库中（自动分块、生成 embedding）。 调用方式如下： from agno.agent import Agent from agno.knowledge import Knowledge from agno.vector_db.pgvector import PgVector agent = Agent( model=..., knowledge=Knowledge( vector_db=PgVector(table_name="my_kb", db_url="postgresql://...") ), search_knowledge=True, # 提供工具 add_knowledge_to_context=True, # 自动注入 ) agent.knowledge.add_content_from_path("docs/") 可以看到，Agent 通过两种方式使用知识库： add_knowledge_to_context=True ：每次运行前自动搜索相关知识，并注入到提示词中（传统 RAG）。 search_knowledge=True ：为 Agent 提供一个 search_knowledge_base(query) 工具，由 Agent 自主决定何时搜索（Agentic RAG）。 后者是目前我认为比较好的方向，前者是几年前流行的；因为模型的agent能力已经大幅上升，query的多，query的好。 Dependencies（依赖项） 看到这个词我双眼一黑，不过其实也还好； 定义：短暂、请求级别的动态值，不适合放在知识库中：如特性开关、租户 ID、每个请求的数据库连接、调用方专属的 API Key 等。 简单的说，就是“程序运行时动态捕捉的数据，主动注入给 Agent”。 你在写代码时，可以“捕捉”到很多东西： Web 框架中，从请求头捕捉 user_id 浏览器插件中，捕捉当前选中的文字 window.getSelection() 调试工具中，捕捉你设置的 --debug 命令行参数 定时任务中，捕捉当前时间 datetime.now() 比如说你写了一个浏览器插件agent，其中有程序可以捕捉用户在浏览器中的历史选中，程序发现用户在浏览中选中了`英伟达` `微软`这些词汇，那么当用户和你的agent对话时候，它们就会被注入；agent就会意识到用户似乎对这两个公司感兴趣； 同样的，那些用户的ip地址，ID，APIKEY，也是程序捕捉，注入到agent之中。 实现方式 在创建 Agent 时传入一个 dependencies 字典，可包含任意结构的数据。 设置 add_dependencies_to_context=True 后，这些依赖会被自动注入到系统提示词中。 工具函数如果需要访问依赖，可以声明一个 RunContext 参数，通过 run_context.dependencies 读取。 代码如下： from agno.agent import Agent from agno.run import RunContext from agno.tools import tool @tool def get_config(run_context: RunContext, key: str) -> str: return str(run_context.dependencies["config"].get(key)) agent = Agent( model=..., dependencies={ "config": {"region": "us-east-1", "max_retries": 3}, "feature_flags": {"beta_search": True}, }, add_dependencies_to_context=True, tools=[get_config], ) # 也可以在单次运行时覆盖依赖 agent.run("我的区域是哪里？", dependencies={"region": "eu-west-1"}) 讲完了这些，我们就了解了两种常见的上下文注入，其实这两者都很简单。一个就是用知识库的方式，一个就是用程序自动注入的方式。 那如果我们需要的上下文比较复杂，不能通过简单查询，就马上得到。比如你需要agent知道今天公司的工作某个任务的进度情况，得同时操作 Slack、GitHub、Google Drive、公司数据库才能得到“这个任务进行到什么程度了”这个上下文。（注意，上下文不是你的目的，你的目的可能更大，需要决策明天的公司加班与否） 而当你定义工具，接入查询工具和其他工具，可能每个系统有 8~15 个 API（发送消息、搜索频道、创建 PR、列出文件、执行 SQL…） 如果你把所有工具直接塞给主 Agent，系统提示词里会塞满 50+ 个工具的描述和参数。 后果：模型会混乱、选错工具、调用参数错误、甚至“幻觉”出不存在的工具。 所以必须引入子agent来做上下文的查询，我们不需要主agent知道那么多细节，只需要子agent去根据问题调查得到上下文，。对于这种子agent，agno提供了context provider来管理。 Context Provider 定义：Context Provider 是一个“子 Agent 包装器”，它把整个外部系统（如 Slack、GitHub、数据库）封装成一个只有两个工具的接口： query_<id> 和 update_<id> ，供主 Agent 调用。 它就是子agent创建。 不着急实现，我们理解一下原理: 现在主agent希望获取上下文，需要查询两个地方的信息，还有更新数据库（更新在这里也视为一种信息），流程就会如下： 主 Agent │ ┌──────────────┼──────────────┐ │ │ │ query_slack query_github update_database │ │ │ ┌────▼────┐ ┌─────▼─────┐ ┌────▼────┐ │Slack │ │GitHub │ │Database│ │子 Agent │ │子 Agent │ │子 Agent│ └────┬────┘ └─────┬─────┘ └────┬────┘ ┌────▼────┐ ┌─────▼─────┐ ┌────▼────┐ │Slack API│ │GitHub API │ │SQL DB │ └─────────┘ └───────────┘ └─────────┘ agno提供了一些内置的provider，直接拥有一些工具 Provider 能力 读写分离 FilesystemContextProvider 读取本地目录的文件 只读 WebContextProvider 网络搜索（Exa 或 Parallel 后端） 只读 DatabaseContextProvider 执行 SQL（读/写） 支持只读和写入两个子引擎 SlackContextProvider 查询 Slack 历史、发送消息 读写 GDriveContextProvider 读取 Google Drive 文档 只读 GitHubContextProvider 读取仓库、创建 PR 读写（PR 隔离） MCPContextProvider 连接任意 MCP 服务器（模型上下文协议） 取决于 MCP 最简单的例子：让 Agent 读取你电脑上的本地文件 from agno.agent import Agent from agno.context.filesystem import FilesystemContextProvider # 创建一个 Provider，指定要暴露的根目录 fs = FilesystemContextProvider(id="docs", root="./my_documents") agent = Agent( model=..., tools=fs.get_tools(), # 只有一个工具：query_docs ) agent.run("帮我找一下 ./my_documents 里有没有关于预算的文档") Agent 内部会调用 query_docs ，传给子 Agent，子 Agent 会遍历目录、读取文件、回答。 基本实现： from agno.agent import Agent from agno.context.slack import SlackContextProvider from agno.context.web import WebContextProvider, ExaBackend # 1. 创建 Provider 实例 slack = SlackContextProvider(id="team_chat") # id 会成为工具名的一部分 web = WebContextProvider(backend=ExaBackend(), id="web") # 2. 将工具合并给主 Agent agent = Agent( model=..., tools=[*slack.get_tools(), *web.get_tools()], # 还可以把 Provider 自带的 instructions 合并进去 instructions="\n".join([slack.instructions(), web.instructions()]), ) # 3. 运行 agent.run("最近 Slack 里有人问过 Web 搜索吗？") # 主 Agent 会调用 query_team_chat 获取 Slack 内容，然后可能再调用 query_web 补充信息。 子agent我们自己也可以写，为什么要用provider 是的，子agent我们分分钟也可以写，不同的是，provider需要遵守contextprovider这个类的写法： 方面 自定义 ContextProvider 手写子 Agent + 工具 继承 必须继承 ContextProvider 无（或者继承 Agent ，但通常直接实例化） 必须实现的方法 astatus , aquery （以及可选的 aupdate ） 无 返回值类型 必须包装成 Answer / Status 任意（通常返回 str ） 工具命名 自动变成 query_<id> 自己取名（可能冲突） 指令注入 可提供 instructions() 方法 需要手动拼接提示词 生命周期 自带 asetup / aclose 钩子 需要自己管理资源 我认为最大的好处还是统一，这个子agent的工具会自动命名，如`query_<provider_name>`，后续导出文档也很简单。劣势在于不自由，如果你的子agent很灵活，实现的功能不附属于主agent，那么就自便。 实现 暂时没有灵感，有灵感补上，或者评论来个佬友梦想一个小agent需求呗，我们来试试。 我现在学了这些东西，但是我觉得很多东西对我好像没有用武之地，所以我也经常在现实中思考，到底我们怎么做才能把agent落到我们生活的困难解决中去。 3 个帖子 - 3 位参与者 阅读完整话题
依旧是一句话让AI出题，本次出题模型为GPT-5.4 比赛奖池：高达 20元 现金奖励 奖品规则： 首位解答 额外独享10元现金奖励（手动发放） 成功解答题目随机瓜分10元红包，仅有10个名额（自行领取） 补充协议： 答题成功排序以网站排名为准，提交正确的口令后会自动记录 本次红包口令码在挑战成功后会在返回中展示，请佬友领取到红包后不要分发或私下给别人，防止其他佬友无法领取。 如果你真解出来了，欢迎回来报喜。如果你在解题过程中发现了什么离谱漏洞、逆天逻辑，或者 AI 才能想出来的神奇写法，也欢迎一起交流讨论。 祝各位玩得开心。 最后解题地址：( https://ctf.io724.fun/ ) 1 个帖子 - 1 位参与者 阅读完整话题
gpt模型为主；手里两张Key，先扔出第一张Key，直接用，目测有500刀+： 额度不多，请留给有用的佬们 剧透 避免机器人，有个解码很简单，或者使用all-api-deck导入（偷偷推荐一下我的开源工具）： ALL-API-DECK 步骤 （点击了解更多详细信息） 好了，第二个自用KEY，大概也有500刀；此车不挤 佬友们使用工具之后原帖反馈或者建议一波 ，我将私信发给你第二个Key； 5 个帖子 - 5 位参与者 阅读完整话题
“妨碍真理发现过程的，不是谎言，而是极其精辟的错误见解。”德国物理学家兼讽刺作家利希滕贝格在面对启蒙运动中的种种愚昧时，戏谑式地写下了这一句名言。 许多误判之所以危险，恰恰因为它们看上去过于正确。它们能在一个短周期里解释世界，也容易在世界已经变化之后，继续以“共识”的面貌停留在原地。 AI也曾经历类似的混沌阶段。 过去两年，人们习惯用一些简单指标理解这场变化：谁拥有更多GPU，谁训练了更大参数的模型，谁的团队烧掉了更多Token。以至于硅谷一度流行“Token消耗量”的隐形竞赛，以证明到底谁是最AI Native的公司。 但现实是，Token消耗量可以衡量投入的程度，却无法衡量投入的方向——方向错了，消耗本身就是一种浪费。这也是Token最容易被误读的地方。 5月29日晚上， 36氪联合光源资本在北京举办“离线聚会第二期· TokenAge” 。这次我们不过多关注消耗量，更关注AI生产力带来了什么，一个判断、一次迭代、一场创业……当AI成为“生产力”本身，我们如何跃向未来？ 我们请来了4位身处AI创业一线的嘉宾： 黄一，萝博派对RoboParty创始人 ，做全开源双足人形机器人； 郑嘉熙，Eup Robotics创始人 ，聚焦离岸能源平台的水下巡检机器人； 金若凡，科学机智创始人 ，想用Agent产品探索AI for Science的“AGI时刻”； 黄欣欣，光源资本3i产业创新孵化器负责人 ，曾是移动互联网时代的创业者，如今专注于从0到1挖掘和陪跑AI前沿科技创业者。 事实上，萝博派对、Eup Robotics和科学机智，也都是光源资本参与孵化的企业。 这应该是36氪过往所有沙龙里，台上创始人00后含量最高的一次。 但年轻在这里不构成特权。今天的年轻创业者，正在被更严苛地审视。他们既被期待更懂AI，也被要求更快交付产品、更早证明商业化、更清楚回答自己为什么值得被下注。 与之对应的，相比宏大的替代叙事，台下的几十位创业者、投资人和正在各自组织里推动AI化的人，也更关心贴近现实的问题： “AI时代公司要怎么重新组织自己？”“为什么AI没有带来组织效率的飞升？” 工业革命以来，每一次通用技术的普及都会带来类似追问：机器出现之后，工厂怎样重组劳动？互联网出现之后，企业如何重组信息？移动互联网出现之后，平台如何重组交易…… 一个时代有一个时代的答案。而现在，不妨先从我们选取的几个切片里，看看AI时代的创业路径、组织迭代和自我进化。 想要获取完整版分享内容，可以收听文末播客音频；更真实的碰撞，欢迎你来现场亲身体验（ 二维码在文末 ）。 从AI出发，探索解决真实世界问题的路径 光源资本创始人、CEO郑烜乐曾提到过一个判断，他认为移动互联网通过连接万物创造价值，AI则是生产力本身，更像“电”，当它经过软件工程导入到各种机器人硬件后，就会形成端到端的解决方案，创造价值。 台上三位创始人的经历，恰好从不同方向给出了具体的注脚。当AI成为驱动这一轮创业的底层技术变革，老问题开始有了新的解法。 金若凡最早感受到这种变化，是在2022年看到ChatGPT早期版本时。“它在少样本、零样本的泛化任务上，怎么能做到这么好？但它为什么没有去切到工具调用？为什么没有那些专业的知识库去支撑更复杂的科研过程？”她看到了AI能够解决更多科学问题的可能性，从2022年就开始尝试多智能体。 到2025年7月，科学机智团队做出了全球首个自进化生物医药多智能体，论文上线后迅速获得大量引用，开源代码也被同行拿去做benchmark。 效果的反馈是超预期的，她有一位做病毒研究的朋友，因为安全和保密顾虑，只用非常简单的文字“浅浅说了一点点”。但将模糊的信息输入后， 模型不仅猜到了他在做什么，还提出了一个真实的科学假设，跑通了科学发现的闭环。 “这是非常酷的一个事情。这也是为什么我今天站出来说要创业。” 这个例子真正有价值的地方在于，它喻示了一种科研范式的变革。过去，科学家要在论文、数据库、代码、工具软件和实验平台之间来回切换，大量知识散落在人的经验和未被结构化的数据及过程中。而金若凡想做的，是让Agent成为入口，构建贯通“AI—工具—实验—反馈”的统一科研环境，实现AI-Native的科研执行与协作闭环。 做机器人的黄一，选择了一条从硬件出发的机器人AGI 之路。他可能是国内最年轻的人形机器人公司创始人，2023年考入哈工大，大一期间就在宿舍“手搓”出一台成本不到2万元的双足机器人AlexBot，2025年创业。 他说做Robotics的人有个“毛病”，“特别喜欢机器人是自己亲生的”。 黄一在实习阶段调试机器人，调着调着就想动手改，但反馈周期太长。而硬件的迭代最怕反馈慢，一慢就跟不上时代，“miss掉整个大的浪潮”。所以他放弃了大厂的邀请，大三提前毕业创办萝博派对。 黄一主张的全栈开源，不是简单的代码开放，其核心产品包括Atom系列人形机器人和Roboto开源生态平台，主打硬件图纸、控制代码等全栈开源，通过降低硬件、软件、供应链的开发门槛，让更多开发者参与生态共建。 尽管这是一条颇具争议的路线，但黄一也在现场提到， “全开源并不代表没有商业化”。 事实上萝博派对第一代全开源产品发布后，就拿到了超过120台订单，“机构和大厂往往会选择继续复购二三十台，而不是说基于开源自己做制造和生产。” 他将其理解为产品的“微笑曲线”，认为“设计和品牌最贵，制造环节利润最薄。” 开源的价值，不是让所有人都能造出同一台机器人，而是让更多高校、开发者和科研机构以萝博派对为入口进入生态。 郑嘉熙同样身处机器人创业赛道，但他所面对的是一个看起来更“重”的领域，Eup Robotics做的是离岸能源平台水下巡检机器人，属于典型的To B 硬科技方向，应用场景是复杂、苛刻的真实海洋环境。 他希望用AI技术去重塑传统方案，解决产业问题，这种技术和产品偏好某种程度上也决定了Eup Robotics的路径选择。“ 我对可能很通用的东西，其实并不是特别有兴趣。反而对这种能工业落地、能够真的稳定进入行业、产生价值的方向感到兴奋。 真实的海洋场景对安全作业要求极高，（过去）哪怕1%的事故率，都会造成非常难以控制的代价。” Eup Robotics的产品聚焦IMR领域，想用更智能的水下机器人替代传统潜水员及ROV，把被动巡检变成主动维护，为海上风电、油气平台、港口码头等应用场景提供高性价比、自主化、可驻留的水下检测与轻干预服务，其第一代产品正在加速研发中。 三家公司，三个年轻的创始团队，都以AI为源点向不同方向出发，大胆创新，给行业提供新的解决方案、创造价值。 黄欣欣提到，今天的AI创业者面临双重挑战：技术迭代周期急剧缩短、大厂竞争边界彻底模糊，不再有移动互联网时代的避风港，创业者也不能再靠信息差或模式创新存活，而在这种环境下，“大胆本身就是生存的可能性之一”。 光源资本做早期孵化，看重年轻创业者身上的大胆和闯劲儿，但也更早看到了从互联网到AI，两代创业浪潮中不同的范式变化，才决定在早期重注技术驱动型创业。 在这个阶段，光源的核心打法分三步： 一是“follow最优秀的人”，从大厂和学术圈挖掘有共识的顶尖年轻人；二是基于行业洞察主动收敛方向，在机会点出现前就锁定对应领域的潜力团队；三是将十年的FA与投资经验转化为创业常识，帮年轻创始人在战略选择、团队搭建、融资节奏上少踩坑。 “所有方向判断并非独断，而是通过与资本市场反复碰撞形成共识。”黄欣欣提到，这一代年轻人物欲感低、技术起点高，创业动机更纯粹——“所学的东西撞上时代机遇，不干就白碰上了”，而这也正是光源敢于重注这一批00后创业者的底层信心。 AI Native的组织，到底长什么样？ 除了创业路径的选择，这场聚会大家最核心的问题之一，是组织形态。 所谓AI Native公司，到底长什么样？年轻的创业团队，是否就是标准？ 很多公司以为，买了AI工具、装了Copilot、开了Agent账号、鼓励员工使用大模型，就算完成了AI化。但现实没那么简单。 一位负责硬件研发流程改革的项目经理，在现场互动环节，阐述的困境非常具体。在硬件研发流程里，模型已经能参与决策、生成方案，甚至在某些具体任务上比人更强。但组织制度、岗位价值和流程并没有同步变化。行业核心know-how掌握在经验丰富的老工程师手里，可这些人未必愿意接受AI；自上而下推改革，跳过了中间层，在最细的颗粒度上不断起冲突。 他最后的追问是， “为什么单点的AI智能已经实现了十倍、百倍的提升，组织的智能却没有达到十倍、百倍的水平？” 金若凡认为，这是因为很多公司只有单点智能，还没有形成组织智能。以AI制药为例，过去已经有大量垂类模型，但带来的价值仍然有限，“大部分情况还是以人工主导”。而科学机智想做的，是 把实验、人机交互和动态反馈连成闭环，让每一步环节背后的判断被系统吸收、复用和进化，才是科研组织AI Native要解决的问题。 “只有当组织能足够理解和掌控Agent带来的创新能力，才可能进入组织智能这个级别。那个时候你才能真正看到百倍、十倍的增长。” 从个体来说，郑嘉熙本人的工作方式本身就是AI Native的样本。他现在已经不再一行行写代码，而是用vibe coding完成整个架构和code base。把清晰的思路和判断交给AI，让AI以代码形式输出，自己上移到产品定义和技术方向层。 “对于一支只有十几个人的团队来说，这种产品驱动的组织方式，比任何流程设计都更重要。” 在他看来，“一个组织真正有价值的地方，在于能不能调动每个人的主观能动性。”对深海机器人来说，AI当然重要，但它不能悬浮在数字世界里。最终客户看的不是模型多新，而是机器人能不能在海底复杂环境里稳定运行，能不能真的替代高风险作业。 黄一不太相信靠口号改造组织，更相信人才密度和资源配置。为此，他把萝博派对拆成了两套组织，管理方式不同。他坦言，自己参考了Anthropic的“蜂巢思维”，每个人根据自己的位置获得边界，不断向外探索，最后形成一个更大的球体。 人形机器人主线更像传统硬件组织，依靠流程、节点和IPD体系推进，每个人有明确任务和交付时间，目标是保证产品不延期。另一边，他在北京单独建了lab，由一位高校教授带队，做前沿探索。后者不设任何KPI，避免设限。 在他看来，lab的一个核心价值，是提前预判行业走向。“一篇论文从idea产生到发布，可能有六个月的时间差，如果我们能在种子阶段就介入，就能提前知道行业会发生什么，反推今天产品怎么定义。”也正因此，他认为很多公司现在做出来的硬件构型已经“过时了”。 显然，AI Native企业不是全员都用AI，而是从结构上承认，技术变化速度已经快到需要专门给“不确定性”留出组织空间。 在具体的人和组织形态之外，可能还有代际认知在底层逻辑上的差异。 黄欣欣提到，不同背景的投资人对AI的理解深度差异很大。 “从不同的认知起点出发，要让他们果断做出重注AI、推动组织变革的决策，确实需要一个过程。”这是光源愿意把更重的筹码压在年轻人身上的原因，同时也印证了“年轻”在这场活动里的真正含义——它不是传播标签，也不是天然优势。年轻只意味着，他们从一开始就生活在AI已经存在的世界里，不需要先完成一次观念迁移再升级旧组织，而是可以直接在新的生产力地面上搭房子。 AI时代，组织和个体如何持续进化？ 当AI越来越像基础设施，人的问题反而变得更锋利。 因为AI不会平均地放大所有人的价值，也不会让每一个岗位都变得更重要。现场的互动，来自具体岗位、具体公司、具体焦虑。在AI时代，组织和个体如何持续进化？ 第一个关键词是taste。 “AI for Science不是做人工智能就能进来的，它首先要对科学有taste。我们是要踩在浪尖上做冲浪的那个人，而不是追着浪跑的人。”在金若凡看来，如果没有Science taste，加入一家AI for Science公司是为了什么？ 黄一强调了两遍“非常认同”。在他看来，research本质上也可以被归类成taste，尤其是“一个好的研究者，重要的不只是追最新模型，而是知道什么方向值得押注，什么问题值得被问，什么论文还只是苗头时就值得提前介入。” 在AI时代，执行不再稀缺，判断才稀缺，taste是一种更难被外包的能力。 模型可以生成大量方案，却不会天然知道哪个方案值得相信；Agent可以执行任务，却不会自动判断任务本身是否有意义。 AI越是普及，越需要人来定义方向。 这个方向，可以是正面的进步，也可以是负面的毁灭。金若凡举了个例子，去年年底，他们牵头办了全球首届“生成式AI与生物安全”研讨会，邀请了图灵奖得主Yoshua Bengio和美国科学院院士George Church。为了搞清楚防线在哪，他们去攻击了自己的模型，也攻击了业内某个DNA大模型（该模型声称训练时从未碰过病毒数据）。 他们给这个模型一段病毒序列的前10%，让它逐段续写。续写完成后拿去比对，发现产物是HIV。他们不信，又做蛋白翻译和结构比对，仍然是HIV。随后如法炮制，这个“从未见过病毒”的模型又生成出了高危型HPV和传染性极强的SARS-CoV-2，甚至把变异的演化路径都补齐了。 在AI越来越强大的时代，清楚它能做什么、不能做什么、该在哪里划线，既是一种稀缺的taste，也是一种责任。 第二个关键词是bet，敢于下注。 黄一说自己“赌性很强，go big or go home”，面对大厂动辄数十亿计的资金，创业公司必须选择All In。郑嘉熙的下注，务实又笃定，深海基础设施巡检这个方向，客户链条重、验证周期长，但传统痛点真实存在，已然能看到技术重构后能带来的巨大价值空间。 光源资本选择从0到1做孵化，也是一种bet，这是一项“高风险、高不确定性、但同样高回报”的业务，用更早期的投入换取后续的增长空间。 但敢于下注，靠的不是凭空判断，用黄欣欣的话来说，是把自己放在资本市场共识的涌现节点上，先嗅到趋势并迅速执行，在见每个机构、每个产业方的过程中不断碰撞和打磨故事线，直到方向收敛——市场苗头出现与自身判断互相验证，让大胆的决定有了现实根基。 第三个关键词是自我迭代、或者说自我蒸馏的能力。 现场有人问，AI时代的人才画像到底是什么？郑嘉熙给了一个定义：一个会用AI的人，“能让AI把以前的自己取代掉，甚至基于自己的taste产生一个更好的自己”。 尤其是在科研场景，在AI冲击下，研究者剩下的核心价值“就是他的想象力和他Science taste的创造力”。 工具可以替代执行，但不能替代提出问题的能力。自我蒸馏，本质上是一次主动的自我淘汰。把过去自己依赖的技能提炼、压缩、剥离，留下那些AI无法从数据里凭空长出来���东西——对问题的嗅觉、对方向的校准、对一个假设是否值得投入的判断。 这种能力不仅关乎个体进化，也关乎组织。萝博派对想要营造的那个高浓度的自由探索空间，本身就是一种组织级的自我迭代—— 允许噪音存在，允许短期看不到产出，因为这些“不经济”的尝试往往是下一个突破的种子。 继续出发，留下一个信号 分享的最后一个环节，我们让每位嘉宾给自己定一个年度的目标，希望明年今日，还能聚在一起回望。 金若凡希望能把公司估值翻100倍。 “一年前我们已经做到了闭环验证，就在上周，Nature顶刊连续发表了三篇相关报道，全球Top 10药企都在进入AI Scientist方向。” 郑嘉熙希望第一款水下机器人产品尽快推出，团队快速scale up。 “再往后两三年，希望自己的机器人能部署到各个能源平台上，看到这些机器在不断工作运行，保护我们整个能源结构”。 黄一希望萝博派对今年能新增1000个真实开发者。 “这是我给团队定的OKR。而就自己而言，希望具身模型能跑到5B、10B的小规模参数，甚至幻想今年能替代9万个快递分拣工人。” 黄欣欣希望光源资本3i产业创新孵化器今年能再帮助10位年轻创业者把创业做成功。 “在这个过程中，互相笃定方向的正确，人的正确，以及始终能够从陪伴的角度去帮助他们解决实际的问题。” 在这个没有PPT的晚上，“TokenAge”最终没有停留在Token上。从创业路径、组织迭代到自我进化，它更像一次AI时代价值尺度的重新校准。而在真诚沟通面前，三个小时也并不显得漫长。 完整版分享内容，欢迎扫码收听音频播客： 离线聚会还会继续，我们希望，更多的交流和有价值的沟通在台下发声，在现场发生。 下一期离线聚会，欢迎加入。
今天，财政部将在香港特别行政区发行2026年第二期人民币国债，发行规模为155亿元，具体发行安排将在香港金融管理局债务工具中央结算系统公布。（央视新闻）