搜索到
7
篇与
的结果
-
Agent Skill 踩坑记录 | SpringBoot 打包后 Skill 加载失败问题排查与解决 在之前的开发中，我使用 ClasspathSkillRegistry 作为 Agent Skill 的查找策略，本地开发环境下调试、运行都一切正常，没有出现任何异常。感兴趣的小伙伴可以回顾上一篇相关内容：https://www.lucaju.cn/index.php/archives/168/一、问题出现：上线后频繁报「Skill not found」本以为本地测试无误后，上线就能顺利运行，结果程序部署到服务器后，日志中频繁出现 Skill not found: 错误，导致相关功能完全无法使用。二、问题排查：排除常见误区遇到问题后，首先排查了最容易出现问题的两个点，均排除异常：确认 Skill 已成功打包：检查部署的 jar 包，解压后确认 skill 相关文件已正常包含在内，不存在打包遗漏的情况；确认 Skill Name 无误：核对代码中调用 Skill 的名称与配置文件中的名称，完全一致，排除拼写错误、大小写错误等问题。三、问题根源：找到官方 Issue排除上述常见问题后，推测可能是框架本身的兼容性问题，于是去 GitHub 上搜索相关问题，果然发现已有其他开发者遇到过相同情况，并且提交了 Issue：https://github.com/alibaba/spring-ai-alibaba/issues/4426从 Issue 中得知，问题根源在于 SpringBoot 项目打包成 jar 包后，路径机制发生变化，导致 ClasspathSkillRegistry 无法正常加载 resources 下的 Skill 目录，这是目前 spring-ai-alibaba 框架的一个已知 bug。四、临时解决方案：改用 FileSystemSkillRegistry由于官方尚未修复该 bug，为了不影响线上功能正常使用，我采用了临时解决方案：将 Skill 目录存放在服务器的文件系统中，通过指定真实路径获取 Skill，对应的查找策略改用 FileSystemSkillRegistry。修改后的核心代码如下：/** * 获取技能智能体钩子。 */ private static SkillsAgentHook getSkillsAgentHook() { // 注释掉原有的ClasspathSkillRegistry方式（本地可用，打包后失效） // SkillRegistry registry = ClasspathSkillRegistry.builder() // .classpathPath("skills") // .build(); /* 临时解决方案说明： spring ai alibaba 目前使用 ClasspathSkillRegistry 打包后，无法获取 Resource 下的目录 因此修改为使用 FileSystemSkillRegistry，从文件系统真实路径获取 Skill 相关 Issue：https://github.com/alibaba/spring-ai-alibaba/issues/4426 */ String skillPath = SpringUtils.getProperty("doc.skills-path"); log.info("skillPath: {}",skillPath); FileSystemSkillRegistry registry = FileSystemSkillRegistry.builder() .projectSkillsDirectory(skillPath) .build(); return SkillsAgentHook.builder() .skillRegistry(registry) .build(); }五、后续需要说明的是，这只是一个临时解决方案——使用该方案后，需要手动将 Skill 配置文件同步到服务器的指定路径（即配置项 doc.skills-path 对应的路径），增加了少量部署成本。后续会持续关注官方 Issue 的修复进度，待 bug 修复后，再切换回 ClasspathSkillRegistry 方式，减少部署环节的手动操作。也希望遇到相同问题的小伙伴，能通过这篇踩坑记录少走弯路～ -
大模型“无脑复读”？3分钟搞懂原因+解决办法 最近在调用大模型时，遇到了一个十分棘手的怪象——模型输出陷入“死循环”，不停重复相同内容，像一台复读机，如下图所示。为了解决这个问题，我查阅了相关资料，梳理出大模型重复输出的现象分级、核心原因以及可解决办法，整理成文分享给大家，帮大家快速摆脱“复读机”困扰。一、现象分级：大模型“复读”分3种大模型的重复输出并非单一情况，根据重复的范围和程度，可分为以下3个级别，大家可以对照判断自己遇到的情况：词汇/短语级重复：最基础的重复形式，模型生成的文本中，同一个词语、短语或短句反复出现，比如一句话在同一段落中被多次复制粘贴，阅读起来十分冗余。段落级重复：当生成较长文本（如文章、方案）时，模型可能生成重复的句子群或完整段落，甚至出现与前文几乎完全一致的内容段，严重影响内容的完整性和可读性。内容结构级重复：针对结构化回答需求（如分点解析、步骤说明），模型可能多次使用相似的结构、句式进行解释，虽然核心内容略有差异，但整体框架重复，显得拖沓且缺乏新意。二、核心原因：3大因素导致模型“卡壳复读”1. 提示词问题（最常见，占比最高）需求提示不清晰：如果给模型的提示过于模糊、笼统，没有明确回答方向、范围或要求，模型无法精准捕捉需求，就会通过重复内容“凑数”，形成冗余输出。上下文缺失：模型的回答依赖上下文信息，如果提问时没有提供足够的背景、前提，或对话过程中上下文断裂，模型无法理解需求的核心，就容易陷入重复循环。2. 模型参数设置不合理温度（temperature）设置过低：温度值控制模型输出的随机性，当温度设置过低（如0），模型会生成保守、确定的内容，倾向于重复高概率词汇和句式，进而出现重复。Top-k/Top-p采样策略不当：这两个参数用于控制模型选择词汇的范围，若设置不合理，会导致模型只能选择少数高概率词汇，无法生成多样化内容，最终陷入重复。3. 模型本身的局限性最终的输出内容由大模型的核心算法、参数配置和训练数据决定。如果模型本身存在训练不充分、参数优化不足等问题，也可能导致其在生成内容时，容易出现重复输出的情况。三、解决办法：对症施策，快速解决“复读”问题针对上述原因，整理了可直接落地的解决办法，从易到难，大家可以按需尝试，基本能解决80%以上的重复输出问题：1. 优化提示词明确禁止重复：在提示词中直接添加“禁止输出重复信息”“避免重复句式和内容”等要求，直接约束模型的输出行为。丰富上下文：补充足够的背景信息、前提条件，或在对话中逐步递进提问，让模型清晰理解需求，避免因信息不足导致重复。细化需求+拆分问题：将模糊的需求拆解成更小的子问题，明确每个问题的回答方向（如“从3个不同角度解析XX”“分步骤说明XX”），引导模型生成多样化内容。2. 调整模型参数调整temperature：将温度值设置在0.7-0.9之间，这个区间既能保证输出内容的准确性，又能增加随机性，鼓励模型生成更多不同的内容，避免重复。优化Top-p采样：适当调整Top-p的值（通常设置在0.9左右），扩大模型选择词汇的范围，让模型有更多创作空间，减少重复概率。
-
解决 Mac 版 PicGo 无法打开问题：“已损坏，无法打开” 报错处理指南 作为一名经常需要处理图片上传的创作者或开发者，PicGo 这款图片管理工具无疑是提高效率的好帮手。它简洁的界面和便捷的图片上传功能，让我们能够轻松管理图片资源，无论是用于博客创作、文档编写还是日常工作，都能带来极大的便利。然而，在 Mac 电脑上安装好 PicGo 后，不少用户可能会遇到一个令人困扰的问题：双击运行 PicGo 时，系统会弹出报错窗口，提示 “PicGo.app” 已损坏，无法打开。你应该将它移到废纸篓，就像下图所示这样：这个问题并非是 PicGo 应用真的损坏了，而是 Mac 系统的安全机制在作祟。macOS 为了保护用户安全，会对从非 App Store 下载的应用进行严格的安全验证，当系统认为应用可能存在风险时，就会阻止其运行，从而出现上述报错。不过别担心，我们可以通过简单的操作来解决这个问题，让 PicGo 顺利运行。具体解决方案步骤一：打开终端在 Mac 电脑上，我们可以通过 Spotlight 搜索来快速打开终端。按下键盘上的Command + 空格组合键，调出 Spotlight 搜索框，然后输入 “终端” 并按下回车键，即可打开终端应用。步骤二：执行终端命令在打开的终端窗口中，输入以下命令：sudo xattr -d com.apple.quarantine "/Applications/PicGo.app"这里的sudo表示以管理员权限执行命令，xattr是用于操作文件扩展属性的命令，-d参数表示删除指定的扩展属性，com.apple.quarantine就是我们要删除的那个导致应用无法打开的扩展属性，而"/Applications/PicGo.app"则是 PicGo 应用在 Mac 上的安装路径。步骤三：输入密码并确认输入完上述命令后，按下回车键，终端会提示你输入密码。这里需要注意的是，在输入密码的过程中，终端不会显示任何字符，这是 Mac 系统的安全保护机制，你只需要正常输入你的电脑开机密码，然后按下回车键即可。输入密码并确认后，命令就会开始执行，执行完成后终端不会有特别的提示，就像下图这样：**步骤四：再次运行 PicGo完成以上操作后，回到 Applications（应用程序）文件夹，找到 PicGo 应用，双击它。这时候，你会发现 PicGo 能够正常打开了，再也不会出现之前的 “已损坏，无法打开” 报错了，就像下图所示：**注意事项确保 PicGo 应用的安装路径正确。上述命令中使用的是默认的安装路径/Applications/PicGo.app，如果你将 PicGo 安装在了其他路径下，需要将命令中的路径替换为实际的安装路径。输入密码时要仔细，确保输入正确。如果密码输入错误，终端会提示 “密码错误”，这时候你需要重新输入密码。执行命令时要保证网络连接正常，虽然这个操作本身不需要联网，但如果在操作过程中出现其他意外情况，联网状态可能有助于排查问题。总结通过以上几个简单的步骤，我们成功解决了 Mac 电脑上 PicGo 无法打开的问题。这个问题主要是由于 Mac 系统的安全机制导致的，并非应用本身真的损坏。只要我们按照上述方法，删除掉应用的 quarantine 扩展属性，就能让 PicGo 正常运行。希望这篇指南能够帮助到遇到同样问题的朋友，让大家能够顺利使用 PicGo 这款优秀的图片管理工具，提高工作和创作效率。
-
服务器遭遇 XMRig 挖矿程序入侵排查与清理全记录 一、异常察觉我的服务器配置本就不高，仅用于博客搭建，日常访问量也不大。但某天明显感觉服务器异常卡顿，通过 top 命令查看，发现 CPU 长期高负载，xmrig 进程疯狂占用资源，初步判断遭遇挖矿程序入侵。二、XMRig是什么 XMRig 是专为门罗币（XMR）设计的 高性能 CPU 挖矿软件 ，基于 cpuminer-m 开发，还优化了容器环境运行能力，会疯狂榨取系统资源挖取加密货币，属于典型的 “资源小偷”。三、挖矿进程追踪1、进程定位用 ps -ef | grep xmrig 命令一查，果然！xmrig 进程正以 root 高权限运行，肆无忌惮占用系统资源搞挖矿运算。2、自启动溯源1. 系统服务检查执行 systemctl list-unit-files --state=enabled 排查开机自启服务，未直接找到 xmrig 相关服务，但后续发现恶意创建的 c3pool_miner.service 服务，配置文件中明确 ExecStart=/usr/workspace/xmrig --config=/usr/workspace/config.json ，用于实现挖矿程序自启动。2. 定时任务挖掘检查 /etc/crontab 、 /etc/cron.d/ 等定时任务目录。发现/etc/cronta最后一项每分钟都执行的任务，比较可疑，删除掉3. 启动脚本排查查看 ~/.bashrc 、 /etc/rc.local 等文件，确认是否存在恶意启动 xmrig 命令，防止挖矿程序通过用户登录脚本或系统启动脚本自启。四、清理与修复过程1、紧急终止进程使用 sudo kill -9 <PID> （ <PID> 为 xmrig 进程 ID ）强制终止挖矿进程，暂时缓解 CPU 高负载问题。2、删除恶意服务与程序文件1. 服务清理：对 c3pool_miner.service ，依次执行：sudo systemctl stop c3pool_miner.service # 停服务 sudo systemctl disable c3pool_miner.service # 禁用自启 sudo rm /etc/systemd/system/c3pool_miner.service # 删配置文件 sudo systemctl daemon-reload # 重载系统服务配置 2. 删光程序文件根据服务配置路径，找到 /usr/workspace/ 下的 xmrig 程序和 config.json ，执行：sudo rm -rf /usr/workspace/xmrig sudo rm -rf /usr/workspace/config.json 3、预防复发措施密码重置：改 root、sudo 用户及数据库密码，提升账号安全性，让攻击者 “进不来”。端口收紧：只开放必要端口（如 Web 服务的 80、443 ），用防火墙限制无关连接，减少入侵入口。系统更新：定期 sudo apt update、sudo apt upgrade ，及时打补丁、修漏洞，让系统 “无懈可击”。五、总结与反思这服务器遭遇 xmrig 挖矿程序入侵，暴露出系统安全防护存在不足。后续需加强服务器安全管理，定期进行安全检查与漏洞扫描，及时更新系统和软件，严格管控端口与服务，提升服务器整体安全性，避免再次遭受类似恶意程序攻击。
-
java使用POI导出Excel单元格为数字类型 第一版开发的时候，所有的单元格都是文本类型，由于需求方需要导出Excel可以直接使用函数计算，所以需要改动一下，将导出的Excel设置为数值类型。创建XSSFCellStyle// 此处设置数据格式 XSSFDataFormat df = wb.createDataFormat(); // 创建单元格样式 XSSFCellStyle numberStyle = wb.createCellStyle(); numberStyle.setFillForegroundColor((short) 1); //设置要添加表背景颜色 numberStyle.setFillPattern(FillPatternType.SOLID_FOREGROUND); //solid 填充 numberStyle.setAlignment(XSSFCellStyle.ALIGN_CENTER); //文字水平居中 numberStyle.setVerticalAlignment(XSSFCellStyle.VERTICAL_CENTER);//文字垂直居中 numberStyle.setBorderBottom(BorderStyle.THIN); //底边框加黑 numberStyle.setBorderLeft(BorderStyle.THIN); //左边框加黑 numberStyle.setBorderRight(BorderStyle.THIN); // 有边框加黑 numberStyle.setBorderTop(BorderStyle.THIN); //上边框加黑 // 注意#,##0.00_ 后面有一个空格 numberStyle.setDataFormat(df.getFormat("#,##0.00_ ")); //为单元格添加背景样式 sheet=setTitleStyle(sheet,rowNum,colNum,style1);创建单元格，并且设置XSSFCellStyle。private static XSSFSheet setTitleStyle(XSSFSheet sheet,int rowNum,int colNum,XSSFCellStyle style){ for (int i = 0; i < rowNum; i++) { //需要行表格 Row row = sheet.createRow(i); //创建行 row.setHeight((short)600); for (int j = 0; j < colNum; j++) {//需要列 row.createCell(j).setCellStyle(style); } } return sheet; }在为单元格赋值的时候，将数据转换为Double类型。
