各位 RTE 开发者社区的小伙伴们，这一年，我们聊 ASR、TTS、LLM，在 TEN Framework 的各种模块里反复跳跃。在代码世界里，我们习惯了将 ASR、TTS、LLM 像积木一样拼装成强大的 Voice Agent。

最近，社区偷偷搞了一件大事，我们把这些「模块」给实体化做成了新春周边盲盒大礼包（你就说这些够不够 Physical 吧？），这不只是一份新年礼包，更是一次 Voice Agent 社区内部的暗号对接。

快来猜猜里面都有些什么吧～只要你的脑洞够大或者直觉够准，这整套诚意满满的新春周边大礼包，我们就包邮送到家！

礼包贺卡写着一段开发者会秒懂的真诚祝愿。

🚨深度剧透：这盒子里到底装了啥？

看到这个充满科技感的「九宫格」了吗？每一个缩写方盒里，都藏着一件根据「技术梗」定制的实体物件。

在这里：

• TTS 不负责合成，只负责让你入睡。
• VAD 不检测语音，只负责让你清静。
• S2S 依然是全场最贵，贵到我们只能送你一个～。

为了让大家更好地发挥脑洞，我们先来打个样！

WebSocket➡WebSockets

盒内真身： 袜子（socks）

TTS ➡ Time to Sleep 语音合成再忙，也要准时入眠

盒内真身： 睡眠真丝眼罩

零丢包包 ➡ 不仅是致敬「沈阳站站」的趣味梗，更是对 Voice Agent 稳定交互的终极祝福

真身：镭射透明包

剩下的 7 个盒子，就看大家的「梗力值」了！

👇请听题，猜猜都是什么东西？（谜面在此）：

1. RTC： Roast the Coffee（会有什么好物？)
2. TEN： Take a SIP（它是 TEN 的拓展能力，也是某种闲适状态？)
3. VAD： Very Anti Dialogue（如果想屏蔽一切对话，你需要什么？)
4. S2S： 某样「太贵了简直买不起」的神秘之物
5. STT： Stick to Task（来自獭獭的职场叮嘱）
6. TTD： Time to Drink（除了酒，还能是什么？)
7. LLM： Long Last Mint（这个提示够明显了吧？)

🎁怎么玩？（奖品超厚！)

1-7 号分别都代表什么物品？ 请在公众号【RTE开发者社区】本文下方评论区留下你的脑洞，我们将送出 9 套 价值不菲的新春周边盲盒大礼包！

• 【神算奖 x 3】 猜得最准、最快的技术锦鲤。
• 【脑洞奖 x 3】 虽然你猜错了，但我觉得你说的比我们做的更有趣！
• 【阳光普照奖 x 3】 不想动脑子？只要留言送上纯粹的新年祝福，我们随机抽人「送福气」！

⏳活动须知

• 活动时间： 即日起至春节假期结束。
• 揭晓方式： 年后返工第一天（2 月 24 日）置顶评论区见！
• 参与方式： 关注【RTE开发者社区】公众号，在本文下方评论区留言即可。

新的一年，愿大家的 Agent 永远不丢包。快去评论区开猜吧！👇

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

麒麟桌面系统老v10和v10-sp1两个系统版本的连接有些不一样，下面分别对这两个系统进行说明

一、V10-SP1版本

1. 打开“加入其他网络”
   
   或者从“开始” - “设置” - “无线局域网”进入也可以
   
   
2. 在弹出的“查找并加入无线局域网络”窗口，配置好ssid和密钥，点击加入。(这两个必须输入，密码必须大于等于8位)
   

二、老V10版本

1. 鼠标点击桌面任务栏右下角网络连接图标，再点击“编辑连接”，进入网络连接页面。
   
2. 在网络连接页面，点击“增加”按钮。
   
3. 再选择连接类型，选择“Wi-Fi”，然后点击“新建”按钮。
   
4. 在正在编辑Wi-Fi连接1->Wi-Fi页面，在连接名称处和SSID处输入隐藏无线网络的名称，设备处选择对应的无线网卡硬件设备。
   例如：此处的无线网络名称为“ChinaNet-8312”，无线网卡硬件设备为“wlp6s0”。
   
5. 在正在编辑Wi-Fi连接1（此处是正在编辑ChinaNet-8312）->Wi-Fi安全性页面，在安全处选择“WPA及WPA2个人”选项，在密码处输入无线网络的密码，然后点击“保存”按钮，即可连接无线网络。
   

6. 如果点击“保存”按钮后，无法正常使用无线网络，则在桌面空白处鼠标右键，选择“在终端中打开”选项，打开终端，执行以下操作。

   1. 在终端输入nmcil connection show命令后回车查看所以网卡的连接信息。

   
   从上图可知，刚才添加的无线网络“ChinNet-8312”没有连接激活。

   2. 再在终端输入nmcli connection up [无线网络名称]，即此处是nmcli connection up ChinNet-8312命令后回车激活无线网络连接，会显示连接已成功激活。

   

   3. 无线网络连接激活成功后，再输入nmcli connection show命令后回车查看所有网卡的连接信息。正常使用的网卡，连接信息显示为绿色。

   

三、命令行连接隐藏wifi

1. 打开终端：win + T

2. 查看网卡，我这里是wlp2s0，后面连接需要用到

   nmcli  device

   

3. 查看可用的wifi设备

   nmcli device wifi list

   

4. 连接隐藏 Wi-Fi

   nmcli connection add \
    type wifi \
    con-name "kylintest" \
    ifname wlan0 \
    ssid "HiddenSSID" \
    wifi-sec.key-mgmt wpa-psk \
    wifi-sec.psk "YourPassword"

   上面命令的参数说明：

5. con-name：连接名称（自定义，如 MyHiddenWiFi）。
6. ifname：无线网卡接口（如 wlan0，可用 ip a 查看）。
7. ssid：隐藏 Wi-Fi 的 SSID（必须正确）。
8. wifi-sec.key-mgmt wpa-psk：使用 WPA-PSK 加密方式。
9. wifi-sec.psk：Wi-Fi 密码。

四、查询系统之前连接过的WiFi密码

打开终端执行以下命令：

sudo  grep  -r  "psk="  /etc/NetworkManager/system-connections/

如下图所示：

本文由mdnice多平台发布

一、现象

麒麟V10桌面系统，开机重启之后，发现系统时间不对，与实际时间相差较大。而且单位里多台电脑出现了同样的情况，但是每一台电脑的时间都是不一样的。

二、处理方法

方法1：手动修改时间

sudo date -s "2025-05-30 10:20:32"

方法2：修改默认的可访问的NTP服务器

执行以下命令，修改NTP服务器为ntp2.aliyun.com，也可以根据需要修改成单位内部的NTP服务器的域名或者ip地址。

sudo  sed  -i  's|#*NTP=.*|NTP=ntp2.aliyun.com|g'   /etc/systemd/timesyncd.conf

重启一下时间同步服务systemd-timesyncd

systemctl  restart systemd-timesyncd.service

方法3：安装补丁包

(原理同方法2，修改默认的NTP服务器为阿里云服务器)

1. 下载补丁包 [点击以下图片下载]
   <img src="https://gxxc.wiki/wp-content/uploads/2025/05/image-1748580746389.png" alt="描述文字">
   如果以上无法下载，可以访问这里下载https://gxxc.wiki/kd/6642.html

2. 安装补丁包
   解压补丁包后，进入deb包所在目录，双击deb包安装，或者使用以下命令安装：

   sudo  dpkg  -i  fix-timesync_1.0.0_all.deb

3. 安装完补丁包后，再查看一下时间
   

4. 建议将当前对的时间，同步到硬件RTC

   sudo  hwclock  -w

三、原因分析

日志显示无法连接到ntp服务器，读取硬件RTC时间

所以显示出不同的时间。而systemd-timesyncd 这个服务本身不会将当前系统时间时间写入硬件RTC，所以时间过去越久，硬件时间与实际时间相差越多，当系统无法从默认的ntp服务器获取到正确时间的时候，就会用硬件时间，从而时间有差异。

四、其他

systemd-timesyncd 这个服务本身不会将当前系统时间时间写入硬件RTC。所以，建议用户每过一段时间后手动将当前时间同步到硬件上，可以执行命令timedatectl查看当前硬件时间

如果硬件时间和当前系统时间相差较大，可以先将系统时间设置正确后，执行以下命令将当前时间同步到硬件RTC

sudo  hwclock  -w

本文由mdnice多平台发布

问题描述

将 U 盘插入电脑后，系统没有自动挂载，并且在文件管理器中看不到该 U 盘设备。经常在用ventoy做了系统启动盘的U盘上，常常遇到这个问题，请看以下解决方法。

解决办法

方法1

将U盘格式化成ext4格式后使用，注意格式化前备份U盘里的重要数据。

方法2

系统默认无法识别到exfat格式的硬盘，需要安装fuse-exfat这个软件包解决对exfat格式u盘的支持，安装命令如下：

yum  install  -y  fuse-exfat

如果服务器不联外网，可以下载安装包后，拷贝到系统上离线安装，下面是x86架构下的路径(arm的把x86_64修改成aarch64即可)：

V10-SP1: https://update.cs2c.com.cn/NS/V10/V10SP1/os/adv/lic/base/x86_...
V10-SP2: https://update.cs2c.com.cn/NS/V10/V10SP2/os/adv/lic/base/x86_...
V10-SP3: https://update.cs2c.com.cn/NS/V10/V10SP3/os/adv/lic/base/x86_...

`有客户又说了，我的U盘都读不出来，下载后，怎么拷贝到服务器里？
这里咱们建议可以格式化U盘成其他格式拷贝，也可以通过刻录进CD盘再拷贝到服务器，或者也可以挂iso配置本地源进行安装`
 

方法3

执行 “lsblk” 命令查看是否能检测到 U 盘设备，

如果能检测到但未挂载，如上图所示，可以执行以下命令，将u盘挂载到/mnt目录下，用命令访问/mnt看看是否能够访问。

sudo  mount  /dev/sdb1  /mnt

这里假设 U 盘设备名为 sdb1，请根据实际情况修改；

如果以上方法还是检测不到，可能是 U 盘故障或者其他原因，可尝试更换其他 U 盘。

本文由mdnice多平台发布

麒麟桌面操作系统，如何通过命令查看笔记本电池使用情况，我们可以通过upower命令，默认安装有，如果没有该命令，可以通过以下命令安装

sudo  apt  install  upower

查看命令：

upower -i `upower -e | grep 'BAT'`

输出如下：

本文由mdnice多平台发布

大家好，我是 Java陈序员。

在如今数字化运营时代，服务的稳定性直接决定用户体验。但搭建一套完善的服务监控体系往往门槛不低：要么是专业监控工具配置复杂、学习成本高，要么是轻量工具功能单一，难以覆盖全场景需求。

今天，给大家推荐一款高颜值的监控系统工具，轻量易部署！

关注微信公众号：【Java陈序员】，获取开源项目分享、AI副业分享、超200本经典计算机电子书籍等。

项目介绍

coolmonitor —— 酷监控，一个高颜值的监控工具，支持网站监控、接口监控、HTTPS 证书监控等多种监控类型，帮助开发者及运维人员实时掌握网站、接口运行状态。

功能特色：

• 多维度监控覆盖：支持 HTTP、HTTPS 网站、API 接口、HTTPS 证书过期、TCP 端口、MySQL、Redis 数据库等多种监控
• 多渠道通知配置：支持邮件、Webhook、微信、钉钉、企业微信等多类型通知渠道
• 便捷的操作体验：响应式布局，适配桌面、平板、移动端，支持深色、浅色主题切换
• 数据可视化：监控数据支持可视化展示，通过 ECharts 生成响应时间趋势图，支持按小时、天维度查看
• 持久化存储：采用 SQLite 轻量数据库，监控配置、运行数据持久化存储，轻量级部署无需额外依赖

快速上手

coolmonitor 支持 Docker 部署，可通过 Docker 快速部署。

1、拉取镜像

docker pull star7th/coolmonitor:latest

2、创建挂载目录

mkdir -p /data/software/coolmonitor

3、运行容器

docker run -d \
    --name coolmonitor \
    -p 3333:3333 \
    -v /data/software/coolmonitor:/app/data \
    star7th/coolmonitor:latest

4、容器运行成功后，浏览器访问

http://{IP/域名}:3333

5、根据引导，设置管理员账号密码，完成系统初始化

功能体验

• 主面板

• 监控详情页

• 添加监控项

• 添加通知方式

• 状态页

coolmonitor 没有复杂的配置项，能覆盖日常监控的核心需求，颜值高、易部署、易维护，不管是个人开发者监控自己的小网站，还是中小企业监控内部服务，都非常适用。快去部署体验吧~

项目地址：https://github.com/star7th/coolmonitor

最后

推荐的开源项目已经收录到 GitHub 项目，欢迎 Star：

https://github.com/chenyl8848/great-open-source-project

或者访问网站，进行在线浏览：

https://chencoding.top:8090/#/

我创建了一个开源项目交流群，方便大家在群里交流、讨论开源项目。

但是任何人在群里打任何广告，都会被 T 掉。

如果你对这个交流群感兴趣或者在使用开源项目中遇到问题，可以通过如下方式进群：

关注微信公众号：【Java陈序员】，回复【开源项目交流群】进群，或者通过公众号下方的菜单添加个人微信，并备注【开源项目交流群】，通过后拉你进群。

大家的点赞、收藏和评论都是对作者的支持，如文章对你有帮助还请点赞转发支持下，谢谢！

题⽬描述

给定单向链表的头指针和⼀个要删除的节点的值，定义⼀个函数删除该节点。返回删除后的链表的头节点。

1. 此题对⽐原题有改动
2. 题⽬保证链表中节点的值互不相同
3. 该题只会输出返回的链表和结果做对⽐，所以若使⽤ C 或 C++ 语⾔，你不需要 free 或 delete 被删除的节点

数据范围:

• 0<=链表节点值<=10000
• 0<=链表⻓度<=10000

示例1

输⼊：{2,5,1,9},5
返回值：{2,1,9}
说明：给定你链表中值为 5 的第⼆个节点，那么在调⽤了你的函数之后，该链表应变为 2 -> 1 -> 9

示例2

输⼊：{2,5,1,9},1
返回值：{2,5,9}
说明：给定你链表中值为 1 的第三个节点，那么在调⽤了你的函数之后，该链表应变为 2 -> 5 -> 9

思路及解答

虚拟头节点

如果要删除链表⾥⾯的⼀个节点，其实就是将前置节点的next 直接指向当前节点的后置节点，这样在链表中再也找不到该节点了，也就是相当于删除了。

假设有⼀个链表，我们需要删除⾥⾯的 5 :

⾸先需要判断链表头结点是不是为空，如果为空，那么就直接返回NULL ，如果等于我们要找的，那么直接返回下⼀个节点引⽤即可。

如果不符合以上说的，那么我们需要新建⼀个前置节点pre ,与现在的链表连接在⼀起：

然后初始化⼀个 cur 节点表示当前节点，指向 head 节点：

cur 不为空， cur 和 pre 后移：

发现 cur 正是我们需要查找的 5 ，那么记录下 5 的下⼀个节点 1 ,也就是next :

cur 的 next 指向 NULL ,使⽤ pre 的 next 指向刚刚记录的 next :

简化链表也就是：

取之前虚拟的头结点的后⼀个节点，就是删除掉之后的新链表：

class ListNode {
    int val;
    ListNode next = null;
    public ListNode(int val) {
        this.val = val;
    }
}

public class Solution13 {
    public ListNode deleteNode(ListNode head, int val) {
        if (head == null) {
            return null;
        }
        
        if (head.val == val) {
            return head.next;
        }
        
        // ⽤⼀个节点将头结点链接起来
        ListNode pre = new ListNode(-1);
        pre.next = head;
        ListNode cur = head;
        ListNode next = null;
        while (cur != null) {
            if (cur.val == val) {
                // 将前置节点直接连接后⼀个节点，相当于删除掉了该节点
                pre.next = cur.next;
                break;
            }
            cur = cur.next;
            pre = pre.next;
        }
        return head;
    }
}

迭代

通过遍历链表找到目标节点并修改指针，维护前驱指针，当找到目标节点时修改指针跳过该节点

public class Solution {
    public ListNode deleteNode(ListNode head, int val) {
        // 处理头节点就是要删除的节点的情况
        if (head != null && head.val == val) {
            return head.next;
        }
        
        ListNode prev = null;
        ListNode curr = head;
        
        // 遍历查找目标节点
        while (curr != null && curr.val != val) {
            prev = curr;
            curr = curr.next;
        }
        
        // 找到目标节点后跳过它
        if (curr != null) {
            prev.next = curr.next;
        }
        
        return head;
    }
}

• 时间复杂度：O(n)，最坏情况下需要遍历整个链表
• 空间复杂度：O(1)，只使用常数空间

递归

当前节点是要删除的节点则返回next，否则递归处理剩余链表

public class Solution {
    public ListNode deleteNode(ListNode head, int val) {
        // 递归终止条件
        if (head == null) {
            return null;
        }
        
        // 当前节点是要删除的节点
        if (head.val == val) {
            return head.next;
        }
        
        // 递归处理剩余链表
        head.next = deleteNode(head.next, val);
        return head;
    }
}

• 时间复杂度：O(n)，需要处理每个节点
• 空间复杂度：O(n)，递归调用栈的深度

做零售的都懂，供应商管理往往是企业运营中最繁杂、最耗时间的那一块——品类多、供应商多、对账频繁，还得实时盯供货节奏。尤其在当前线上线下融合加速的趋势下，靠 Excel 表格管供应商管理早已跟不上节奏。为了帮助零售企业快速建立科学、高效的供应商管理体系，本文整理了一份2026年适配零售行业的 SRM 系统推荐榜单，为企业选型提供实用参考。

一、什么是 SRM 系统？为何对零售如此关键

在进入推荐之前，先明确一个核心概念：SRM 系统是用来管理供应商全生命周期的一套软件解决方案。它的目标是帮助企业从供应商准入、绩效管理、风险监控，到日常协同、合同与对账等业务流程，实现数字化、标准化和可视化管理。

在零售行业，这类系统尤为重要，因为：

（1）零售企业的采购品类极其杂乱，SKU 数量庞大，供应商类型多样，从品牌方、大型经销商到小型供应商与加工厂，管理复杂度高；

（2）线上线下库存变动快，促销、季节性业务强，供货节奏必须准确把握；

（3）对账频率高、数据核对工作量巨大，若没有系统支持，很难避免账目不清、对账延迟等问题；

（4）供应商绩效评估和风险预警体系不足会直接影响供货稳定性。

SRM 系统的价值不仅是“管数据”，更是帮助企业提升供应链协同效率、降低风险、提升供应商价值贡献、实现战略采购的长期平台。

二、零售行业 SRM 系统推荐榜单

在众多 SRM 平台中，我们结合零售行业的典型需求（如多门店协同、库存节奏与采购链路紧密联动、促销物资临时采购、大宗物料管理等）进行了评估，推荐了以下几款系统：

1 正远科技 —零售全场景低代码定制 SRM 方案

推荐指数：★★★★★
适用规模：大型连锁 / 区域连锁 / 新零售集团

正远科技 SRM 的最大特色是低代码可编排架构，支持业务人员通过拖拽可视化方式快速调整流程，而无需 IT 二次开发，适合零售企业业务变化频繁的特性。

在零售行业的典型场景中：

（1）促销临时采购流程、临时物料变更、赠品采购等审批流可快速调整；

（2）多区域采购需求与多门店执行协同无缝衔接；

（3）门店数据、仓储、ERP、对账系统之间实现实时协同。

在供应商生命周期管理上，它支持从供应商准入、评级、评级调整到淘汰全流程闭环控制，同时具备实时风险监控能力，有助于减少因供应商突发状况导致的断货风险。在订单与执行层面，系统支持 VMI 库存管理和条码收货，这对门店稀散、收货点多的零售企业尤为重要。真正实现采购订单、物流路径、对账流水在一个协同大平台中的柔性联动。

亮点功能：

（1）低代码可视化流程自定义；

（2）支持类电商化采购商城；

（3）与 ERP、OA、企业微信、工作流无缝集成；

（4）提供实时供货节奏监控与预警。

该系统在实际落地案例中，能有效缩短采购周期、提升对账效率，在部分零售企业中采购周期平均缩短约 40% 以上，供应链协同效率显著提高。

2 甄云科技 —AI 驱动智能采购 SRM

推荐指数：★★★★☆
适用规模：大型 / 规模化零售企业

甄云科技的 SRM 最大亮点在于AI 与大数据的深度嵌入。在零售行业常见的“品类杂，价格波动快”的场景下，甄云的智能比价和风控引擎能够帮助企业在采购阶段快速筛选、比价与评估供应商。

例如，它的 AI 比价工具能在几秒内完成多平台的价格比对，并提供趋势分析，这对于价格敏感的零售采购极具价值，同时还能直接提升成本控制能力。系统还能对接大量外部监控数据，进行供应商风险预警。

优势特点：

（1）跨平台智能比价与采购成本预警；

（2）实时风险监测与供应商健康得分；

（3）支持多语言、多币种，适合跨境采购；

（4）与 ERP/WMS 等多生态系统集成。

甄云科技 SRM 的标准化程度较高，对于流程规范、企业规模较大的零售集团尤为适合。但对于需要深度业务定制的场景，其灵活度略逊与更开放的低代码平台。

3 鲸采云 —中小零售轻量化 SaaS 优选方案

推荐指数：★★★★☆
适用规模：中小零售 / 区域连锁

鲸采云定位轻量化 SaaS SRM，其操作门槛低、部署迅速，非常适合中小型零售企业。系统覆盖了从供应商准入、绩效评估到采购执行的基本 SRM 模块，同时内置了标准的供应商数据管理能力，支持扫码收货、智能补货、分门店采购协同等功能。

针对中小企业常见的“预算有限、没有 IT 团队”的情况，该系统提供了丰富的第三方插件接口，可以与金蝶、用友等主流财务系统无缝对接，并支持与钉钉、企业微信等移动办公系统联动。

适配亮点：

（1）快速上手、低门槛 SaaS 方案；

（2）支持采购商城式下单体验；

（3）集成主流办公和财务系统插件；

（4）门店与总部协同集中管理功能完整。

对于采购流程相对稳定、供应商数量适中、对高级定制需求不高的中小零售企业，这款系统性价比较高。

4 用友采购云 —ERP 生态深度联动 SRM

推荐指数：★★★★☆
适用规模：已部署用友 ERP 的零售企业

用友采购云的优势在于与其 ERP 大生态产品深度集成，能将采购流程、生意账务和库存管理紧密联动，从而避免信息孤岛和重复录入工作。通过自动化审批与财务联动，可显著提升合规性与对账效率。

特别是在跨区域、跨业务单元的零售企业，用友采购云对不同业务模式的支持能力很强，例如多税制处理、合同自动生成、应付账款自动管理等。

主要优势：

（1）深度 ERP / 财务系统集成；

（2）自动化审批与合规管理；

（3）支持全球采购与跨币种场景；

（4）对账流程全链路自动化。

对于已经在用友系统中的零售企业来说，该系统可以最大限度减少 ERP 与 SRM 之间的数据不一致情况。

5 企企通 —SRM + 供应链金融结合的特定场景解决方案

推荐指数：★★★☆☆
适用规模：资金链压力大的中小企业

企企通的特色在于其 SRM 平台与供应链金融服务的结合，可以为合作供应商提供融资支持，从而在一定程度上稳定供应链。对于一些资金压力较大、对现金流敏感的中小零售企业，这种功能尤其有价值。

该系统在供应商管理、订单协同、物流跟踪等基础功能之外，加强了资金服务联动，例如供应商融资额度展示、资金通道对接等。对于希望通过供应链金融提升供货稳定性和合作紧密度的企业是一大加分项。

但在行业专属功能方面，例如临时促销物资管理、多门店库存节奏优化等方面不如前几款完善，因此更适合采购流程相对简单、希望补贴供应链现金流的中小企业。

五、选型小贴士与实施建议

（1）先从业务优先级出发，不要盲目追求花哨功能：比如对账自动化、风险预警、门店端补货支持，这些是零售企业最基础的痛点。

（2）试用是必须的：任何系统的卖点再好，若实际操作繁琐、不贴合业务流程，那么 ROI 很难体现。

（3）数据迁移与集成成本要提前评估：老系统迁移、新系统上线与现有库存、财务数据的集成成本往往被低估。

（4）长期战略要考虑扩展性：是否支持未来供应链升级，这是构建企业竞争力的关键。

六、结语

供应商管理是零售企业运营效率的核心组成部分，也是企业实现精细化运营和供应链协同的战略基础。选对 SRM 系统等于为企业供应链打下坚实的数字化基础。
本文整理的榜单结合了国内 SRM 供应商和国际通行的优秀方案，同时结合零售行业具体特征，为不同规模和发展阶段的零售企业提供实用选型参考。

Agent 搭建起来之后怎么让它真正变得越来越好？搭建完成后的优化就很少有人认真说过。

Agent Lightning 号称能把任何 AI Agent 变成"可优化的猛兽"，而且几乎不用改代码。那问题来了，市面上 Agent 框架满天飞这个凭什么就不一样呢？

training gap

做过 Agent 部署的人大概都有同感：把 Agent 跑起来其实没那么难，真正难的是让它持续进步。

OpenAI 的 Agent SDK、LangChain 这类编排框架，原型设计和快速部署确实很拿手。几个小时就能让一个能用的 Agent 上线。但到了优化这一步，用真实场景的反馈去训练 Agent、提升它的表现基本就只能靠自己摸索了。

微软的研究人员给这个问题起了个名字叫"training gap"。开发环境里跑得好好的 Agent一碰到真实用户、边缘场景和领域特有的问题性能就打折扣。传统框架能给你的帮助很有限：手动调 prompt，手动改参数，然后顺带祈祷别有问题。

而Agent Lightning 的切入点就在这里，它把 Agent 框架和优化基础设施做了解耦。微软的说法是这套方案"可以无缝地为任何现有 Agent 启用模型训练，无需对 Agent 代码做任何修改。"

Agent Lightning 的工作原理

Agent Lightning 在现有 Agent 代码和微软的 verl 训练基础设施之间插入了一层客户端-服务器架构。可以理解为一个翻译层：把 Agent 的交互记录转化成训练数据，优化完参数再塞回去。

具体流程是：Agent 照常运行，什么都不用改，但每一次交互都会被 Lightning 客户端截获。数据会传到 Lightning 服务器，服务器端跑强化学习、自动 prompt 优化、监督微调这些手段，再把改进后的参数推回到 Agent 里。

特别值得说的是框架的兼容性：LangChain、AutoGen、CrewAI、微软自家的 Agent Framework都能接。团队管它叫"Lightning AI Agent 的终极训练器"。

安装也是直接一个pip命令：

pip install agentlightning

。

实际应用和用例

最有说服力的场景是 Agent 需要适配私有数据或者特定行业需求的情况。通用预训练模型处理常规任务还行，碰到公司内部流程、行业“黑话”、独特的业务逻辑，就容易出问题。

拿客服 Agent 举例：它得学会你公司特有的工单升级流程、产品的各种坑、跟客户打交道的语气和方式。传统做法是手写 prompt 然后盼着它能泛化到各种情况。换成 Agent Lightning系统能直接从真实客户对话中学习，拿解决率、满意度评分、各项业务指标来自动优化响应策略。

代码生成也是个很适合的场景：Agent 在跟你的代码库、编码规范、开发流程不断交互的过程中，Agent Lightning 能持续微调模型，让它越来越贴合团队的具体要求。

搜索和检索类应用也一样，Agent 需要弄清楚哪些信息源对哪类查询最有价值、怎么按用户偏好排序结果、什么时候该转人工，这些都可以在实际使用中不断优化。

竞争格局

Agent Lightning 进入的赛道已经很拥挤了，但定位上有明确的差异化。别人在卷 Agent 编排和模型服务，而微软选择切入的是一个几乎没人认真做过的方向：优化。

Agent 优化可以说是平台策略的自然延伸，通过解决那些单纯做模型或做编排的玩家解决不了的问题，把开发者留在微软的生态里。

而且Agent Lightning 没有被包装成 Azure 的专属服务而是直接开源，这既展现了微软对自身平台能力的信心，也说明他们对推动这个领域发展有诚意。

总结

AI Agent 行业一直在解决"怎么搭"，却没认真回答"搭完之后怎么办"。而Agent Lightning 把开发和优化解耦这个思路填补了从 LangChain 到 AutoGen 这一批框架都没覆盖到的空白。

但是从版本能看得出来，0.1.2 版离生产级还有距离。但方向本身没问题，当 AI Agent 越来越多地承担关键业务，能持续从真实反馈中学习的 Agent 和不能的之间差距只会越拉越大。谁先跑通这条优化闭环，谁就拿到了下一阶段的门票。

https://avoid.overfit.cn/post/eea592726e5940c29d80fadf9908b2e6

by Mandar Karhade

本文共 5200 字，阅读预计需要 6 分钟。

编程 IDE 赛道卷成红海，Cursor、Claude Code、Google AI Studio 各有拥趸。但 Copilot 在 2026 年依然稳坐月活第一的位置，它凭什么？

这篇文章，从我个人深度使用的体验出发，拆解 Copilot 的三个核心优势、三个明显劣势、以及六个核心特性的实战用法——帮你判断，它到底适不适合你。

一次 Cursor 账单，让我彻底想明白了

先说一件真事。

前几天，我在 Cursor Max 模式下，开了 Plan 模式，用 Claude Opus 4.6 重构一个项目的页面样式。

一次 Plan 制定，一次 Plan 修改，再加上按照 Plan 执行工作。

三个步骤，花掉了十几刀的 token 费用。

然后我算了一下，这三个步骤如果在 Copilot 里做，就是三次独立的调用。再乘以 Copilot 对 Opus 4.6 设置的系数 3，也就是消耗 9 次 premium request。

而 Copilot 每月 10 美金的订阅套餐里，有 300 次这样的调用额度。

换句话说，Cursor 里花十几刀干的活，Copilot 只扣了 9 次调用——连月度额度的 3% 都不到。

这个差距，让我彻底想明白了一件事：在长期、复杂项目使用的场景下，成本结构比单次能力更重要。

说实在的，我不是说 Cursor 不好。Cursor 在很多方面确实更强，后面会讲到。但作为一个每天都要写代码、调研资料、做内容创作的人，我需要一个成本可控的主力工具，而不是每次点「执行」后都要关注token用量。

三个让我留下来的理由

按次计费：O(1) 复杂度的成本控制

Copilot 最核心的竞争力，就是它的按次计费逻辑。

每月 10 美金的 Pro 套餐，包含 300 次 premium request。即使超额，每次也只收 4 美分。

这意味着什么？

它不会因为你用了最贵的 Claude Opus 4.6，就让你反复盯着 token 用量看。它只是出于成本考虑，让一次调用消耗 3 次 premium request 的额度——但费用不会随 token 用量上涨而上涨。

我喜欢用一个程序员都懂的类比：这就像 O(1) 复杂度的算法。

不管你输入多大，成本是固定的。

相比之下，Cursor 的计费更接近 O(n)——输入越大，token 越多，费用越高。Cursor Pro 每月 20 刀，Pro+ 每月 60 刀，Ultra 每月 200 刀，而且这些套餐背后还是基于用量的逻辑。

在大型项目的重构修改、大量资料调研，或者长上下文的内容创作中，Copilot 的开销可能只有按 token 计费的几十分之一。

对于经常要调用强模型做大型任务的开发者来说，这个差距是实打实的。

新模型第一时间支持 + 无限 Tab 补全

Copilot 对新模型的支持速度一直很快——只要厂商开放了 API，基本第一时间就能用上。

而且 GPT-5 mini 、Gpt-4o等的调用和 Tab 代码补全，在 Pro 套餐里都是无限次数的。

这个"无限"很重要。Tab 补全可能是你写代码时每分钟都在用的功能，随手做点修改，增添个函数，如果这个也限次数，那体验会非常割裂。Copilot 在这一点上没有扣扣搜搜。

当然也有例外。比如 GPT-5.3 Codex并没有支持，但是这个的原因是 OpenAI 延迟开放 API 的老传统，现在三方 IDE 都用不了。

GitHub 生态的原生力量

这一点经常被忽略，但其实很关键。

Copilot 背靠微软和 GitHub，如果你平常接触开源比较多，它的生态整合是相当完整的。GitHub 的 issue、PR、仓库索引，都是原生集成的，不需要任何额外配置。

Copilot 的 coding agent 在上线后的前 5 个月里，开发者用它合并了超过 100 万个 Pull Request。这个数字本身就说明了生态粘性。

另外，Copilot 对 Plan 模式和 Skills 的支持也做得不错。Plan 模式可以让模型先规划再执行，Skills 则是一个可扩展的工具提示词集合——比如 Anthropic 官方出的前端设计 Skill，可以显著提升 Copilot 做前端的效果。这些在后面的特性拆解里会详细讲。

三个不可忽视的缺点

说完优势，聊聊让我不太舒服的地方。

前端样式：Copilot 的"审美盲区"

这是最明显的短板。

Copilot 在前端样式、UI 设计这些方面，和 Cursor、Google AI Studio 的差距比较大。尤其是用 GPT 系列模型的时候，尤其是Codex，出来的页面效果。。。说实在的特别难评。

以下是我在copilot里，用GPT-5.1-Codex-Max，做的火柴人小游戏：

这个页面的设计审美真的有点过分了。。。

后来我接了 Anthropic 官方发的前端设计 Skill 之后，效果能好一些，但如果你真的要用 Copilot 做前端样式类的工作，最好还是切到 Claude Opus 来搞。包括写作，我个人体感更好的也是Claude的模型。

超大型任务：和 Cursor Max 的差距

Copilot 的 Agent 模式在超大型任务上的执行力，和 Cursor 有一点差距。

虽然我个人体感这个差距很小，日常使用几乎感觉不到，但是，Cursor 开启 Max 模式后，是能感觉出来的——同样的任务，同样的模型，Cursor 对复杂项目、复杂任务的精确执行和精确理解做得要好一些。

而且，除了Gpt-5.2 Codex，copilot对其他模型的上下文limit基本都是128K，这也是限制它超长任务执行能力的关键。

甚至 Cursor 还有多 Agent 竞赛的功能，可以让多个 Agent 同时尝试不同方案，然后你选最好的那个。

这个"更强"的代价，也许是几十倍的成本，但在一些场景下是真的有对应的收益的。

所以这事得看你怎么算账：是为了 5% 的精度提升花数倍甚至数十倍的钱，还是用 Copilot 把 90% 的活先干了，剩下多去迭代几轮或者自己上？

自定义规则和记忆：灵活度不够

Cursor 有 rules 这样的系统，能做到项目级的规则配置，还有记忆功能来记住用户的编程偏好——比如你喜欢用什么命名规范、偏好什么代码风格，它都能记住。基本接一个cursor-memory-bank，就能很方便的实现。

Copilot 虽然也有 .github/copilot-instructions.md，但说实话，灵活度和粒度上差不少。

这就好比一个能记住你口味的老厨师，和一个每次都要重新告诉他"少盐少油"的新厨师。做出来的菜可能差不多，但沟通成本差很多。

六个核心特性实战手册

说了这么多宏观的优劣势，我们来看看 Copilot 各个核心特性的具体用法。这部分比较实操，建议收藏。

1. Tab 补全：最成熟，也最容易被低估

Tab 补全是 Copilot 最早出名、也是最成熟的功能。订阅 Pro 之后无限次使用。

你在写代码的时候，它会实时预测你接下来要写的内容，按 Tab 就能接受建议。对于逻辑简单的函数，你甚至可以只写一行注释，然后靠 Tab 补全快速把代码写完。

这个功能有几个小技巧，很多人不知道：

第一，写好注释再写代码。 注释越清晰，补全质量越高。这其实就是在给模型做上下文工程——你的注释就是 prompt。

第二，打开相关文件放在旁边的 Tab 里。 Copilot 会自动把打开的文件当作上下文来参考。所以如果你在写一个调用其他模块的函数，把那个模块文件打开放旁边就行。

第三，Ctrl+右箭头逐词接受。 如果补全的内容只对了一半，不用全盘接受或全盘拒绝，按 Ctrl+右箭头可以一个词一个词地接受。这个技巧能省很多手动修改的时间。

2. Inline Chat：小范围精修利器

在代码里按 Ctrl+I（Mac 上是 Cmd+I），可以直接在当前位置发起一次对话。

适合小范围的修改，比如"给这个函数加上错误处理"、"把这段逻辑重构成异步的"之类的。

它的好处是改完直接有 diff 预览，你可以逐行审查，不满意就撤销。比在聊天窗口里来回复制粘贴高效得多。

很多人常用 Chat 面板做小修改，但其实微调切到 Inline Chat 效率更高也更精准。

3. Ask 模式：纯对话，不动代码

Ask 模式就是侧边栏的对话窗口。在这里可以选模型、问问题、讨论方案。

它的特点是"纯对话，不动代码"——不会帮你直接改文件，但你可以引用工作区的文件给它。

我的习惯是，把需要的文件直接选中后，鼠标拖到对话框里，省掉复制粘贴。

不过，Copilot 对工作区的文件都有访问权限，显式引用只是提醒模型重点关注。多个项目的话，从左上角把文件夹添加到工作区即可。

4. Agent 模式：核心中的核心

Agent 模式是各个编程 IDE 最核心的功能，也是 Copilot 用得最多的模式。

在 Agent 模式下，Copilot 可以自主地读文件、写文件、跑终端命令、分析报错，然后迭代修复，直到任务完成。

按次计费的爽感就体现在这里：即使迭代了特别多轮，它还是只收一次的费用。

另外一个很实用的细节：Agent 模式里可以控制模型可用的工具。

比如你只想让它帮你解决部署问题但不修改任何文件，可以把文件编辑的工具禁用掉。

这在生产环境排查问题的时候特别有用，相当于强制禁止文件修改。

5. Plan 模式：复杂任务专属

Plan 模式是专门用来做复杂任务的。

它会强制模型输出完整的执行计划，并且从执行来看会启动一些子 agent 来做信息收集，防止主 Agent 的上下文过长。

关键是：在你点击「Start Implementation」之前，你可以和模型反复对话来修改计划。

即使你告诉它"现在开始执行任务"，只要还在 Plan 模式下，它还是只做计划生成。

所以，「Start Implementation」本质上就是点击后，

1、帮你切换到了 Agent 模式，

2、把「Start Implementation」输入到输入框中

因此如果你读计划读得差不多了，自己手动切到 Agent 模式让它执行，效果是一样的。

我的习惯是：涉及复杂的、大量文件改动的任务，都先让它出 Plan，确认没问题了再放手让它跑。

6. Skills：各IDE的“杀手级”功能

Skills 是近两个月，copilot刚支持的功能。

在设置中打开 userAgentSkills 的开关，把 Skills 文件下载到指定路径下，模型就能读取和使用这些 Skills 了。

比如 Anthropic 官方出的前端设计 Skill，能显著提升 Copilot 生成前端代码的质量。这其实就是一套精心设计的系统提示词，告诉模型在做前端任务时应该遵循哪些设计原则和最佳实践。

写在最后：适合你的，才是最好的

总结一下这一期的内容。

Copilot 的三个核心优势：按次计费成本可控、新模型支持快、GitHub 生态整合强。

三个主要劣势：前端样式效果不好、超大型任务的执行力略逊、自定义规则和记忆能力不够灵活。

六个核心功能的使用方法：Tab 补全、Inline Chat、Chat 面板里的 Ask、Agent 和 Plan 三种模式，以及 Skills。

这些优缺点都很明显，没有哪个工具是完美的。关键是匹配你的场景。

我个人的建议是这样的：

1、如果你经常做大型的后端项目，且频繁调用比较强的模型来做重构、修改之类的工作 → Copilot 的按次计费逻辑会帮你省非常多的钱。这是它最核心的优势。

2、如果你追求极致的执行精度，不太在乎 token 开销 → Cursor 开 Max 模式确实体感更强，甚至可以开启多 Agent 竞赛的功能。但月均开支要做好心理准备。

3、如果你更多是做小的演示 demo 或者 UI 设计 → Google AI Studio 也许更适合你。免费额度够用，从想法到可运行的小项目特别快。

**总之，我的建议是组合着用。**Copilot 当主力省成本，Cursor Max 当精度补刀，Google AI Studio 做快速验证。

这套组合拳打下来，性价比是最高的。

既然看到这了，如果觉得不错，随手点个赞、收藏、转发三连吧～

我是Carl，大厂研发裸辞的AI创业者，只讲能落地的AI干货。

关注我，更多AI趋势与实战，我们下期再见！