标签：Intel架构

前沿哨所

• 开源AI Agent「Polox」发布新版：LLM定位图片文字坐标，序号式精准编辑

  开发者Sai近日发布开源项目Polox AI的新版本，这是一个面向图像与视频处理方向的AI Agent工具。本次更新的核心是优化图像内文字编辑能力：项目引入大语言模型（LLM）自动检测图片中的文字坐标，并在画布上以序号标记，与对应的文本编辑框绑定显示。用户可直接通过序号定位需要修改的文字内容，无需手动框选文字区域。这一交互设计对于文字较多的图片（如海报、截图、设计稿等）尤为实用，可显著降低逐个查找和编辑文字的操作成本。项目代码托管在GitHub平台，以开源方式发布，开发者可直接访问仓库获取代码并参与迭代。作者Sai在V2EX开发者社区分享了此次版本更新信息，并向社区用户征求使用反馈。从产品形态看，Polox AI属于AI Agent在图像编辑垂直场景的具体落地，尝试将LLM的语义理解能力与画布交互相结合。以往修改图片内文字通常依赖Photoshop等专业软件手动操作，或借助通用AI绘图工具整体重绘，而该项目聚焦文字精准编辑这一细分痛点，以坐标检测加序号映射的方式提供了解决方案。

  事件分析

  技术看点方面，利用LLM进行文字坐标检测是多模态能力在图像编辑场景的典型应用，序号映射的交互方式降低了精准编辑的使用门槛，与Gemini图像编辑、Canva Magic Edit等产品在文本级编辑思路上有相通之处。产业层面，AI图像编辑正从整体生成走向局部精准控制，文字编辑长期是扩散模型的薄弱环节，LLM辅助定位提供了互补的技术路径。作为个人开发者的开源项目，其优势在于快速验证垂直场景需求，但后续能否与主流绘图模型生态整合、社区活跃度与维护的持续性，将决定项目能否长期存活。若该交互模式被验证有效，可能被更大的图像编辑产品借鉴吸收。

  核心观点：AI图像编辑正从整体重绘走向精准控制：让LLM负责找字、人类专注改字，垂直分工可能比端到端生成更实用。

  原文链接：V2EX 分享发现

  刚刚

• new-api发布v1.0.0-rc.38：支持WebSocket与集中式请求策略

  开源大模型API网关项目new-api发布v1.0.0-rc.38版本，本次更新引入Responses WebSocket支持与请求策略两大核心功能。在系统设置层面，新版本新增请求策略模块，支持集中配置请求检查、会话管理、重试机制与渠道健康监测，并在使用日志中记录策略决策详情，便于管理员排查与审计。渠道管理方面，渠道创建与编辑界面补充了快捷选项和透传说明，新增模型重定向工作台；高级自定义渠道可按路径单独开启透传功能。同时，该版本新增vLLM与SGLang两种推理引擎渠道，Ollama渠道则支持按渠道粒度开启OpenAI兼容对话接口。new-api是从One API发展而来的开源项目，为多种大模型服务提供统一的API接入、分发与管理能力，在个人开发者与企业私有化部署场景中被广泛使用。此次更新后，用户可通过WebSocket长连接调用支持实时交互的模型接口，并借助策略系统实现更精细的流量治理与渠道调度。该版本已在GitHub发布，完整更新说明可前往项目仓库查看。

  事件分析

  本次更新的技术看点在于WebSocket支持，使Responses API可通过长连接实现低延迟实时流式交互，与OpenAI等主流接口向双向实时通信演进的方向一致。请求策略的引入则标志着此类网关工具从单纯的密钥分发转向精细化流量治理，策略决策日志对生产环境的可观测性与问题追溯有实际价值。新增vLLM与SGLang渠道侧面反映了本地自托管推理的普及趋势，开源推理引擎与API网关生态正在加速打通，Ollama的OpenAI兼容开关也降低了混合部署门槛。后续值得关注策略引擎的规则表达能力、渠道故障转移的成熟度，以及对更多推理后端的兼容适配进展。

  核心观点：API网关正从密钥分发走向策略化治理，开源社区在补齐大模型自托管基础设施的关键一环。

  原文链接：Linux.do

  刚刚

• 冰箱黄瓜烂了三个月，开发者vibe出一套AI Agent家庭仓储系统

  一位开发者在发现冰箱里有一根放置了三个月的黄瓜后，开发了一套面向AI Agent的家庭仓储管理系统AL1S-WMS，并将项目开源至GitHub。该系统将全部功能封装为MCP tools，用户只需拍摄购物小票，Agent即可自动识别并完成入库。库存管理方面，系统支持按批次入库、条形码扫描，可记录保质期、存放位置、分类等属性；预警功能覆盖临期、过期、临界、库存不足、缺货等多种状态；采购模块提供购物清单、购物日历、购买后入库以及缺货物资自动生成购物清单；财务模块则包含当月预算规划、支出统计和简易记账。作者明确说明该项目不适用于企业、门店等专业商用场景，不具备银行账户同步、多币种换算、ERP级批量作业等能力，定位为个人自用工具。目前系统已支持多家庭切换，但尚未实现多用户功能。为解决已有物品批量录入的难题，作者将Agent接入QQ，在家中走动时通过语音消息播报物品位置和数量，即可完成信息录入，实现边走边管的库存维护体验。

  事件分析

  该项目体现了AI应用开发范式的转变：传统软件以人机交互界面为中心，而这套WMS将所有能力封装为MCP tools，让Agent成为操作主体，人类只需提供小票照片、语音播报等自然输入。这种Agent-first架构显著降低了日常数据录入门槛，为个人自动化工具提供了新思路。技术层面，多模态输入与MCP协议的结合，展示了标准化协议如何让Agent快速对接垂直生活场景。产业层面，这也是Vibe Coding从’生成代码’向’构建个人基础设施’延伸的典型案例，个人开发者借助AI能以极低成本实现以往需要小团队才能完成的软件项目。后续可关注多模态识别的准确率表现、库存数据与生鲜电商采购链路的打通可能，以及同类Agent原生工具生态的扩展速度。

  核心观点：当Agent成为操作主体、人只需开口说话，个人软件的开发逻辑与使用方式正被AI重新定义。

  原文链接：V2EX 分享发现

  刚刚

• 开源 Everything 搜索技能：AI Agent 文件检索速度简单翻倍

  一位开发者在 GitHub 上开源了 everything-search-skill 项目，这是一个面向 AI Agent 的文件搜索技能，核心思路是让 Agent 调用经典 Windows 搜索工具 Everything 来完成文件检索，替代 Agent 默认的 glob 等模式匹配方案，从而将搜索速度提升约一倍。Everything 是知名的 Windows 全盘文件搜索工具，基于 NTFS 文件系统的主文件表（MFT）建立索引，能够在海量文件中实现即时定位，长期被视为 Windows 平台近乎必装的效率软件。项目作者认为，当前大模型的推理速度虽然在持续提升，但 Agent 在执行文件搜索这类系统级操作时，仍依赖低效的遍历式方案，搜索环节往往成为整个任务流程的性能瓶颈，而接入 Everything 后这一短板可被显著弥补。该项目实现并不复杂，通过封装 Everything 的命令行接口，让支持技能（Skill）机制的 Agent（如 Claude Code）可以直接调用。作者表示此类技能用户完全可以自行编写，开源此项目旨在提供现成方案，并希望获得社区 star 支持。该内容来自 V2EX 分享发现板块，属于开发者工具类项目分享，原文行文风格较为随意，但所指项目具备一定实用价值。

  事件分析

  从技术角度看，该项目的价值在于打通了经典桌面工具与 AI Agent 之间的能力通道。Everything 凭借 NTFS MFT 索引机制实现毫秒级全盘检索，效率远超 Agent 内置的递归遍历式搜索，将其封装为技能是对现有工具链的低成本增强。从产业层面看，这一项目折射出 Agent 技能生态的活跃：围绕 Claude Code 等支持技能扩展的 Agent，社区正快速产出大量垂直场景工具，文件搜索、浏览器操作、办公自动化等能力正被逐一补齐。后续走向方面，类似的经典软件封装潮可能持续，Everything、Listary 等老牌工具或将以新形态重回开发者视野；同时 Agent 的工具选择策略也可能演化，模型需学会在不同操作系统与环境下自动选用最优检索方式。

  核心观点：Agent 的效率瓶颈常在工具链而非模型本身，经典桌面软件与 AI 技能结合是低成本高回报的增强路径。

  原文链接：V2EX 分享发现

  刚刚

• 实测：给 AI 编程 Agent 接 LSP 语义检索，不一定比 grep 好用

  一项针对 Coding Agent 代码检索方式的实测研究显示，为 Agent 接入基于 LSP 的语义导航（查引用、跳定义、列符号）并不一定优于传统的 grep 搜索。研究使用 Opus 4.8、Sonnet 4.6、Haiku 4.5 三个 Claude 模型，在多个 Python 和 TypeScript 仓库上测试了定位代码、查找全部引用、多文件重命名三类任务，且仅统计两种方法均成功的情况以公平对比 token 消耗。结果显示：在简单定位代码的任务中，模型几乎不主动选择 LSP（主动选择率 0% 至 6%），强制使用 LSP 反而使成功率从 100% 降至 89%；在查找全部调用方的任务中，模型主动选择 LSP 的比例为 45% 至 57%，精确率从 grep 的 0.76 提升至 1.00，但两者的召回率均只有约 0.66。实验还发现，代码库中同名文本越多，LSP 的收益越明显：hono 仓库的 grep 精确率仅 0.51，改用 LSP 后 F1 提升 0.246 且节省 12% token；而在代码命名干净的 remeda 仓库中，LSP 基本无效，token 反而多消耗 16%。影响最大的改动与检索后端无关：将 LSP 返回内容从文件路径和行号改为直接附带上下文源码后，多文件重命名 pass@1 从 0.67 升至 0.83，多余文件读取从 15.2 次降至 3.2 次，低于纯 grep 的 4.3 次。研究的结论是，LSP 的效果取决于任务类型和代码库特征，而工具返回内容的格式，有时比检索后端本身对结果的影响更大。

  事件分析

  这项研究用量化数据揭示了 Agent 工具生态中容易被忽视的问题。模型在简单任务中自发绕开 LSP，说明其已具备一定的工具成本判断能力；而两种方法的召回率几乎持平，暗示语义级检索并未解决遗漏调用的根因。返回格式改动带来的提升幅度超过更换检索后端，对 MCP 等工具协议的设计具有直接参考意义——工具接口应尽量减少 Agent 的后续操作步骤，一次返回足够上下文。产业层面，随着 AI 编程工具竞争加剧，’给 Agent 配什么工具、怎么配’正在成为与模型能力同等重要的工程问题。相应的评估体系也需要从单一检索精度，转向端到端任务完成率、模型主动选择率与 token 成本的综合衡量，这对工具开发者的产品设计思路是一种纠偏。

  核心观点：给 Agent 配工具，返回格式与任务场景的匹配度，比检索后端的精确度更决定成败。

  原文链接：V2EX 分享发现

  刚刚

• DeepSeek官宣：法定节假日及调休周末API全天按谷时计价

  DeepSeek官方宣布了一项面向开发者的API计价新政：在法定节假日期间，以及因调休安排而变为休息日的周末，通过DeepSeek官方API调用模型服务可全天享受谷时价格。根据DeepSeek现行的分时定价机制，其API服务区分峰时与谷时两个档位，谷时通常为北京时间凌晨00:30至08:30，该时段平台计算资源相对空闲，价格明显低于常规时段。此次新政意味着在上述假期内，全天24小时均可按谷时优惠价调用，包括DeepSeek-V3、R1等模型在内的推理服务成本将显著下降。对开发者而言，这是一项实打实的成本利好：批量数据处理、离线任务、大规模文本生成、模型评测等原本需要卡准凌晨谷时窗口的工作负载，可以在节假日全天灵活执行，既降低调用费用，也提升了任务排期的自由度。据了解，DeepSeek此前曾在春节期间试行全天谷时计价并获得开发者好评，此次将优惠范围明确扩展至全部法定节假日及调休周末，表明该策略已从临时性活动转为常态化机制，持续向开发者让利。

  事件分析

  从算力运营角度看，节假日期间API调用量通常明显回落，GPU集群存在闲置窗口，全天谷时计价实质是削峰填谷的调度策略：以价格杠杆引导推理需求向闲置时段集中，让边际成本近乎为零的空闲算力变现，提升整体硬件利用率。从产业层面看，DeepSeek一贯以极致低价著称，此番再度加码价格让利，进一步强化其高性价比定位，对国内其他大模型服务商的定价体系构成压力；低价策略也有助于吸引中小开发者与初创团队沉淀调用习惯，扩大生态基本盘，为后续模型迭代铺路。后续走向上，分时计价有望成为国内大模型API服务的标配，类似云计算行业的竞价实例模式；节假日让利是否会引发同行跟进，以及新模型发布后的价格策略调整，值得关注。

  核心观点：节假日全天谷时计价既是闲置算力的削峰填谷，也是DeepSeek用低价护城河持续巩固开发者生态的既定打法。

  原文链接：Linux.do

  刚刚