copilot在wsl中无法工作

copilot在wsl中无法工作

copilot 在 wsl 中无法工作——vscode remote develop 代理设置

通过本文,你可以了解:

  1. 如何解决 copilot 在 wsl 中无法使用的问题
  2. wsl和宿主机之间的网络通信
  3. vscode 的 remote develop 代理设置

问题表现

如果你有以下问题之一:

image-20251023112557124
  1. 对话没有输出
image-20251023112627748
  1. 显示 fetch failed
image-20251023112927595
  1. 模型名称不显示
image-20251023113136431

问题分析

查看 copilot chat 的 output 显示:

image-20251023115601077
image-20251023113051902

如果显示 proxies 相关问题,可以确定是 WSL 中运行的 vscode 调用了宿主机的 proxy 设置的问题。

image-20251023113614436

**这个选项似乎是默认开启的,会在 vscode 远程连接 wsl 开发中继承宿主机的 proxy 本地设置。**问题就出在这里,如果你使用的是宿主机本机运行的代理程序,那么proxy的ip就会设置为 127.0.0.1,但是在 wsl 中想要访问宿主机的代理端口,ip并不是 127.0.0.1(这会访问到 wsl 自己),而是需要通过如下方式查询宿主机 ip,然后访问到宿主机上的代理端口:

hostip=$(ip route show |grep -i default |awk'{ print $3}')echo$hostip

我的输出:

172.25.48.1 

因此 wsl 中要通过 172.25.48.1 ip 来访问宿主机上的端口。

WSL 2 / VS Code RemoteWindows Host (宿主机)Listens on Port XListens on Port XReturns 172.25.48.1Default Proxy: 127.0.0.1X Connection Refused (Self)✅ Correct Proxy: 172.25.48.1:Port XTraffic ForwardedWSL ApplicationLoopback: 127.0.0.1Query: ip route show | awk '{ print $3}'Proxy AppHost IP: 172.25.48.1Loopback: 127.0.0.1

问题解决

  1. 如果可以通过网络直连,直接关闭 http: Use Local Proxy Configuration.
  2. 如果依然需要设置代理,完成1后,修改如下设置:
image-20251023122228413
你可能见过这个方案:github - Copilot is not working is WSL remote connection? - Stack Overflow

这个方案确实可以成功,但是带来的副作用是 copilot 无法修改 WSL 中的文件,agent模式将称为摆设,因为你设置 copilot 完全工作在宿主机上(即设置的 "GitHub.copilot": [ "ui" ]

WSL和宿主机网络互访

上面已经说明了如何在WSL命令行中访问宿主机程序,那么我们可以将之应用到代理设置上,以下脚本解决了一个问题——在 wsl 命令行中如何利用宿主机代理软件?

#!/bin/shhostip=$(ip route show |grep -i default |awk'{ print $3}')wslip=$(hostname -I |awk'{print $1}')port=7890PROXY_HTTP="http://${hostip}:${port}"PROXY_SOCKS5="socks5://${hostip}:${port}"set_proxy(){exporthttp_proxy="${PROXY_HTTP}"exportHTTP_PROXY="${PROXY_HTTP}"exporthttps_proxy="${PROXY_HTTP}"exportHTTPS_proxy="${PROXY_HTTP}"exportALL_PROXY="${PROXY_SOCKS5}"exportall_proxy=${PROXY_SOCKS5}git config --global http.https://github.com.proxy ${PROXY_HTTP}git config --global https.https://github.com.proxy ${PROXY_HTTP}echo"Proxy has been opened."}unset_proxy(){unset http_proxy unset HTTP_PROXY unset https_proxy unset HTTPS_PROXY unset ALL_PROXY unset all_proxy git config --global --unset http.https://github.com.proxy git config --global --unset https.https://github.com.proxy echo"Proxy has been closed."}test_setting(){echo"Host IP:"${hostip}echo"WSL IP:"${wslip}echo"Try to connect to Google..."resp=$(curl -I -s --connect-timeout 5 -m 5 -w "%{http_code}" -o /dev/null www.google.com)if[${resp}=200];thenecho"Proxy setup succeeded!"elseecho"Proxy setup failed!"fi}if["$1"="set"]then set_proxy elif["$1"="unset"]then unset_proxy elif["$1"="test"]then test_setting elseecho"Unsupported arguments."fi

这个脚本自动获取宿主机的 ip,并利用宿主机上的本地代理软件来代理wsl中的网络请求,可以通过参数控制行为:

source proxy.sh set# 开启代理,设置代理变量source proxy.sh set# 用 google.com 测试代理是否成功source proxy.sh unset# 关闭代理,清楚代理变量设置

参考

WSL2与Windows间的网络互访 - 简书

WSL2 访问 Clash 网络代理 | 极客开发

Read more

通义灵码VS Copilot:阿里云AI编程助手在企业开发环境下的实战对比

通义灵码与Copilot:企业级AI编程助手选型深度实战解析 在技术决策者的日常工作中,工具选型从来不是一道简单的选择题,而是一场关于团队效率、技术债务、安全合规与长期成本的综合权衡。当AI编程助手从极客玩具演变为生产力标配,摆在CTO和技术负责人面前的,不再是“要不要用”,而是“用哪一个,以及如何用好”。GitHub Copilot凭借先发优势,几乎定义了“AI结对编程”的范式;而阿里云推出的通义灵码,则带着对云原生和企业级场景的深度理解强势入场。这场对决,远不止是功能列表的对比,更是两种技术哲学、两种服务模式在企业真实战场上的较量。本文将抛开浮于表面的参数罗列,深入代码生成质量、团队协作适配、私有化部署成本、以及与企业现有研发流程的融合度等核心维度,为你提供一份基于实战的深度选型指南。 1. 核心能力与代码生成质量:超越“补全”的智能较量 许多评测停留在“谁能生成更多代码行”的层面,但这对于企业级应用是远远不够的。我们更应关注的是:生成的代码是否安全、可维护、符合团队规范,以及在复杂业务上下文中的“理解力”。 代码生成的准确性与上下文感知是首要分水岭。Copilot基于G

WhisperX语音识别工具:为什么它比传统方案更值得选择?

WhisperX语音识别工具:为什么它比传统方案更值得选择? 【免费下载链接】whisperXm-bain/whisperX: 是一个用于实现语音识别和语音合成的 JavaScript 库。适合在需要进行语音识别和语音合成的网页中使用。特点是提供了一种简单、易用的 API,支持多种语音识别和语音合成引擎,并且能够自定义语音识别和语音合成的行为。 项目地址: https://gitcode.com/gh_mirrors/wh/whisperX 在当今数字化时代,语音识别技术正迅速改变着我们处理信息的方式。WhisperX作为基于OpenAI Whisper的增强版本,不仅在识别准确率上有所突破,更在处理效率上实现了质的飞跃。本文将深入探讨这款工具的核心价值及其在实际应用中的独特优势。 为什么需要更智能的语音识别? 传统的语音识别系统往往面临多个挑战:处理速度慢、时间戳精度不足、多说话人识别困难等。WhisperX通过创新的技术架构,有效解决了这些问题,为用户提供了前所未有的语音转写体验。 WhisperX语音识别完整流程:从音频输入到精准时间戳输出 核心功能深度解析 批

[awesome]最新最全机器人Robotics顶会“灵巧手”(dexterous hand)的paper集合

[awesome]最新最全机器人Robotics顶会“灵巧手”(dexterous hand)的paper集合

前言 “灵巧手”(dexterous hand)通常指具有类人手结构、多自由度的末端执行器,能够进行精细的抓取与操作,而不仅仅局限于平行夹紧(如下图)。它们模仿人类手指关节和肌腱驱动,使机器人能够执行转动、重定位、穿插等复杂操作。根据结构和材料不同,灵巧手大致可分为刚性型、柔性型和混合型:刚性型采用金属或坚硬塑料结构,关节通过电机或舵机驱动,优点是定位精度高、力矩大;柔性型主要用硅胶、橡胶等软材料,可通过气动驱动或形变实现自适应抓取,天生适合对柔软或不规则物体的抓取;混合型结合刚柔两者,例如刚性骨架包裹柔性层,兼顾承力和安全性。近年来,随着增材制造和传感技术进步,灵巧手的设计趋势是结构更轻便、可拓展(如3D打印一体化设计)且集成丰富传感器,使其在保持精细操作能力的同时降低成本和复杂度。总体来看,从并联双爪等简单夹具到今天的多指柔刚结合的灵巧手,已经形成多条发展脉络,各种创新不断涌现。 在机器人学中,“灵巧手”是把感知—决策—执行闭环落实到接触尺度的关键枢纽,其重要性体现在方法论与系统层两个层面:在方法论上,灵巧手将原本“抓取—位移”的低维任务,提升为包含滚动、

Llama 3-8B-Instruct 在昇腾 NPU 上的 SGLang 性能实测

Llama 3-8B-Instruct 在昇腾 NPU 上的 SGLang 性能实测

1.引言 随着大模型在各类智能应用中的广泛应用,高效的推理硬件成为关键瓶颈。昇腾 NPU(Ascend Neural Processing Unit)凭借其高算力、低能耗以及对 SGLang 的深度优化,能够显著提升大模型推理性能。本文以 Llama 3-8B-Instruct 为例,通过在昇腾 NPU 上的实测,展示其在吞吐量、延迟和资源利用方面的优势,并探索可行的优化策略,为开发者在今后的开发中提供可参考的案例。 在本篇文章中我们会使用到Gitcode的Notebook来进行实战,GitCode Notebook 提供了开箱即用的云端开发环境,支持 Python、SGLang 及昇腾 NPU 相关依赖,无需本地复杂环境配置即可直接运行代码和进行实验。对于没有硬件平台的小伙伴来说是非常便利的。 GitCode Notebook使用链接:https://gitcode.com/user/m0_49476241/notebook。 2.实验环境与准备 2.