IT资源栈互联网海量AI资源栈

前沿哨所

• 开发者开源 Vite 插件，让 AI Agent 自主调试前端代码

  一位开发者在 Linux.do 论坛发布了开源 Vite 插件 vite-plugin-pilot，其核心功能是让 AI Agent 能够在浏览器页面中通过 eval 执行 JavaScript 代码，从而自主检查、测试和调试自己编写的前端程序。作者称其效果基本可以媲美 Chrome DevTools MCP，且具备独特优势：当开发运行在特殊环境中的前端程序时，例如浏览器插件、嵌入式 Webview 或定制化客户端，Chrome DevTools MCP 等常规工具往往无法运行，而该插件依然可以工作，还能帮助 Agent 探索这些陌生运行时环境下的功能实现方式。该项目的开发过程也颇具特色：作者使用 glm5-turbo 模型配合 Claude Code 进行迭代，项目最初只是某个工程中的一个 vite-plugin.ts 文件，作者发现仅提供页面执行 JS 的能力，就能大幅提升 Agent 的开发、测试与调试水平。更有意思的是，迭代过程中 Agent 借助插件自带的 playground，利用该插件自身来测试使用手感并持续完善，即整个工具完全由 Agent 使用工具自身迭代而成。作者表示，在实际工作中，该插件已在浏览器插件开发场景中表现良好，Agent 能够自行实现功能并测试直至正确完成，因此将其独立成项目发布，希望帮助前端开发者提升 AI 辅助开发效率。

  事件分析

  技术层面，该插件瞄准的是 AI 编程中的反馈闭环问题：传统模式下 Agent 只能生成代码而无法观察运行结果，需人工转述报错信息；赋予页面内执行 JS 的能力后，Agent 可自主验证逻辑、定位缺陷，显著降低人工介入成本。与 Chrome DevTools MCP 相比，该方案更轻量，不依赖特定调试协议，可覆盖浏览器插件、嵌入式 Webview 等长尾场景。产业视角看，这反映了 Agent 工具链正从通用编辑器辅助向运行时调试环节延伸，而 Agent 亲手打造自用工具的开发模式，也验证了 AI 自举迭代的可行性。后续值得关注其与主流 Agent 框架的集成情况，以及社区是否会在标准调试协议中补齐特殊环境支持。

  核心观点：让 Agent 自造自用调试工具，补齐了运行时反馈闭环，AI 编程正从会写代码迈向会验证代码。

  原文链接：Linux.do

  刚刚

• 开源中间件Toolify：用提示词让任意大模型API支持函数调用

  Toolify是一个开源中间件项目，通过提示词工程让任何语言模型API都能支持函数调用（Function Calling），旨在解决部分LLM接口原生不支持该能力的痛点。项目自动处理提示词构造、响应解析与多轮调用，实现方式类似Open WebUI的代码解释器功能，通过XML标签引导AI调用函数。相比社区已有的类似实现，Toolify具备多项改进：允许模型在输出任意位置调用函数、兼容思维链标签、支持一次性多函数调用、支持多上游渠道配置、模型可回溯上次调用的具体函数与参数，并提供Docker Compose快速部署方案。项目近期更新了模型映射功能。作者表示该项目已在公益站测试一段时间并稳定运行后才发布，同时说明了两点限制：为兼容流式响应，系统需逐个扫描模型输出内容，传入tools参数会导致流式输出变慢；由于基于提示词实现，效果不及原生支持Function Calling的接口，但性能较好的模型使用起来问题不大。项目代码托管在GitHub，作者呼吁有需要的用户给予star支持。

  事件分析

  从技术路径看，Toolify代表了用提示词工程弥补API能力缺口的轻量方案，其核心挑战在于流式场景下的输出扫描开销与解析稳定性。此类项目的出现折射出当前LLM服务生态的碎片化现状：函数调用虽已成为Agent应用的基础能力，但开源模型、第三方中转渠道的支持程度参差不齐。短期来看，这类中间件能显著降低代理站点和自部署模型接入工具生态的门槛，尤其利好依赖OpenAI兼容接口转发服务的开发者；长期来看，随着函数调用逐渐成为OpenAI兼容接口的事实标准，提示词模拟方案的生存空间可能收窄，但在私有化部署、微调模型等场景仍有持续需求。该项目与站内既有方案的迭代竞争，也体现了开源社区在LLM基础设施层的快速演化节奏。

  核心观点：提示词模拟函数调用是生态碎片化下的过渡方案，却切中了开源模型与中转渠道工具能力参差的真痛点。

  原文链接：Linux.do

  刚刚

• OpenAI 发布 GPT-6 Astra 系统卡，安全评估详情公开

  据 Linux.do 论坛消息，OpenAI 已发布 GPT-6 Astra 模型的系统卡（System Card），文档托管于 OpenAI Deployment Safety Hub（部署安全中心）。该平台是 OpenAI 面向公众的站点，用于集中展示安全评估报告、系统卡及相关公告，方便外界查阅模型安全测试情况。系统卡是大模型发布流程中的重要文档，通常记录模型的能力边界、安全测试结果、危险能力风险评估（如网络攻击、生物化学滥用测试）及相应缓解措施。此前 GPT-4、GPT-4o、GPT-5 等模型发布时，OpenAI 均以系统卡形式向监管机构和公众披露评估细节。此次 GPT-6 Astra 的系统卡中包含完整的评测比分说明，外界可通过文档了解新模型在各基准测试与安全评估中的具体表现。该消息最初由论坛用户通过 ChatGPT 的定时任务功能获得推送提醒，随后在社区引发关注。系统卡的上线通常被视为模型正式开放使用前的信号，意味着 GPT-6 Astra 可能已进入或临近部署阶段。目前 OpenAI 尚未发布详细的产品公告，系统卡具体评测数据、能力提升幅度及开放时间等信息仍有待确认。对关注大模型进展的开发者和研究者而言，该文档是第一手的官方安全评估资料。

  事件分析

  从发布节奏看，系统卡先于正式产品公告出现，通常表明 GPT-6 Astra 已完成内部安全评估流程，进入部署准备阶段。系统卡中的评测比分是判断模型代际提升幅度的重要依据，尤其在推理、编程、Agent 任务等前沿能力维度，GPT-6 的表现将直接影响其与 Claude、Gemini 等竞品的竞争格局。此外，系统卡中的危险能力评估（CBRN 风险、自主能力、越狱抗性等）是各国监管机构关注的重点。在 AI 法规日趋严格的背景下，OpenAI 通过 Deployment Safety Hub 持续公开评估细节，可视为对透明度要求的主动回应。后续值得关注的节点包括：API 开放时间、ChatGPT 端内的推送节奏，以及第三方安全机构对系统卡数据的独立复核结论。

  核心观点：系统卡抢跑正式公告，安全评估已从前置流程变为大模型竞争中的公开战场与信任货币。

  原文链接：Linux.do

  8分钟前

• OpenAI 官网意外曝光神秘新品 Astra，两篇博客上线即被撤下

  据 Linux.do 论坛用户发现，OpenAI 官网短暂上线了两篇未正式发布的产品博客，均指向一个名为 Astra 的新产品。其中一篇介绍游戏公司 PlayCo 如何利用 Astra 进行游戏原型开发，另一篇则讲述法律科技公司 Legora 借助 Astra 完成财务报表审查工作。发帖者推测，此次意外曝光可能是网站部署环节出现问题，导致原本定时发布的多篇文章被提前推送上线。值得注意的是，就在帖子发出后不久，这两篇博客即被官方下架，页面已无法访问。从仅存的 URL 和标题信息判断，Astra 大概率是 OpenAI 正在筹备中的一款新产品，其披露的两个应用场景——游戏原型制作与财务报表分析——均属于需要多步骤推理与执行的复杂工作流，指向智能体类产品的可能性较高。此次泄露事件虽然持续时间短暂，但首次证实了 OpenAI 内部存在这一尚未公布的产品线，也侧面反映其发布节奏可能已临近。目前 OpenAI 官方尚未对此次意外曝光作出任何回应，Astra 的正式发布时间、产品形态与具体功能仍有待官方进一步披露。

  事件分析

  从技术层面看，定时文章被批量误发通常源于内容管理系统在部署或缓存刷新时的状态同步故障，此类事故在大型网站改版期间并不罕见，但此次泄露的核心价值在于内容本身。Astra 的两个案例分别来自游戏与法律科技领域，均为 B 端专业场景，暗示该产品可能面向生产力工作流，采取与行业客户共创案例后再正式发布的推广策略。值得注意的是，Google DeepMind 此前已推出同名项目 Project Astra，若 OpenAI 沿用该名称，或将引发商标与品牌认知层面的交锋。后续可关注 OpenAI 是否在近期活动中正式推出 Astra，以及其与现有 ChatGPT 产品线的整合方式。此外，案例型博客先行备好，通常意味着发布窗口已经临近，各家媒体与开发者社区的追踪或将倒逼官方提前官宣。

  核心观点：乌龙发布往往是最真实的预告片：Astra 的意外曝光表明 OpenAI 正加速抢滩智能体生产力赛道。

  原文链接：Linux.do

  1小时前

• 1100美元的400GbE交换机：MikroTik CRS804成AI集群组网性价比之选

  MikroTik推出CRS804-4DDQ-HRM桌面型400GbE交换机，主打高性价比路线。该设备配备四个QSFP56-DD接口，总交换带宽达1.6Tbps，官方定价1295美元，市场实际售价约1100美元，折合每Gbps成本不足0.7美元，相当于以5.5美元购得8口千兆交换机的单价水平，在新型交换机中价格优势显著。评测方已将其用于8台NVIDIA GB10集群的RDMA后端网络数月，另一台则承载NVIDIA GB300 Station集群，使用DR4光模块。硬件方面，该交换机为半宽设计，宽218毫米、深387毫米，较大深度对小型机柜部署构成一定挑战。四个400GbE端口可拆分为2个200GbE QSFP56端口，灵活适配不同速率需求。设备另配两个10GBASE-T管理口，连接管理处理器而非交换芯片，并提供串口控制台与复位键。供电采用两块Gospower 350W冗余电源，实际运行功耗预计远低于额定值；双风扇支持热插拔。随机附送半宽与标准19英寸机架安装支架。该产品内部采用Marvell Annapurna Labs芯片方案，目前市场需求旺盛，常处于供不应求状态，可通过B&H等渠道购买。

  事件分析

  技术层面，接口代际差异值得关注：GB300等新一代AI工作站已转向QSFP112和OSFP接口，而CRS804采用上一代QSFP56-DD，用户采购DAC线缆和光模块时需注意兼容匹配。产业层面，400GbE网络长期由NVIDIA Spectrum-X、Arista等高端方案主导，MikroTik借助Marvell Annapurna Labs白盒芯片将门槛拉至1100美元区间，对小规模AI实验室和开发者自建GB10/GB300集群具有实际意义。RDMA后端网络是AI训练与推理的关键基础设施，低成本方案的成熟降低了个人和小团队参与大模型基建的准入门槛。后续可关注MikroTik是否会跟进推出支持QSFP112或800G的新品，以及此类桌面级白盒交换机在长期高负载AI集群场景下的稳定性与散热表现。

  核心观点：400GbE单价击穿0.7美元/Gbps，白盒硬件正快速瓦解AI集群组网的高成本壁垒，算力民主化从GPU蔓延到网络层。

  原文链接：Hacker News

  2小时前

• ChatGPT Work 让普通人也能搭一套个人 AI 工作系统

  

  很多人打开 ChatGPT Work，仍然只在输入框里问一个问题。答案也许更长，产品的用法却和普通聊天没有多少区别。

  Jeff Su 这段 19 分钟的视频给了一个很具体的解释：ChatGPT Work 的价值来自工作文件夹、规则文件和工具连接。它会读取长期规则，再替你操作文件或应用。原视频：Learn 95% of ChatGPT Work in Under 20 Minutes。

  
  

  Chat 和 Work 的分界线

  视频一开始用生日提醒演示两者的差别。Jeff 先让 ChatGPT Work 在 Google Calendar 里创建生日事件。接着补了两条规则：标题加蛋糕 emoji，描述里写上购买礼物的提醒，并要求以后所有生日事件都沿用。

  他随后打开一个全新会话，只说：“为 Sam Altman 创建 4 月 22 日的生日提醒。”新事件仍然带着蛋糕图标和礼物提醒。新会话没有复述旧指令，规则却继续生效。

  普通 ChatGPT 处理眼前的一问一答。Work 把工具和挂载目录接进会话，教过一次的习惯能写进文件，下一次任务继续用。

  视频把产品线分成三段：ChatGPT Chat 负责对话，Codex 面向程序员，ChatGPT Work 处在中间。Work 又有网页端和桌面端，Jeff 推荐非技术用户使用能力更完整的桌面端。产品命名确实有点绕，但选择标准很简单：需要让 AI 处理本地文件并按固定规则反复做事，就用桌面端 Work。

  一个文件夹加一份 AGENTS.md

  Jeff 给出的最小配置很朴素：准备一个工作文件夹，再放入一份规则文件。规则文件用普通英文编写，下载后必须准确命名为 agents.md，然后在 ChatGPT 桌面应用里选择 Work，并挂载这个目录。

  这份文件可以分成几类内容：

  • Purpose 说明文件如何使用；
  • Global rules 保存所有任务都要遵守的规则；
  • Voice principles 约束写作口吻；
  • Maintenance 规定文件怎样整理；
  • Routing map 决定不同任务去哪个子目录找资料。

  目录挂载后，Work 会在任务开始前读取 agents.md。视频中的一句判断很实在：没有挂载工作文件夹，Work 基本上仍是普通 ChatGPT；有了规则入口，它才开始稳定地按个人习惯工作。

  图片重命名的例子很能说明问题。Jeff 直接告诉 Work：“以后重命名图片时，用简短但有描述性的文件名，让人不用打开图片也知道内容。”Work 把这条约定写进规则文件。之后他丢进一批照片，在新会话里只要求重命名，系统就会按同一套风格处理。

  AI 早就会看图和改文件名，麻烦在于每次改法都可能不一样。把命名习惯写进文件后，同类任务才会得到同一套结果。

  工具接上以后，还要教它使用习惯

  ChatGPT Work 的 plugins 可以连接 Google Calendar、Gmail、Notion 和 Slack。Claude 把类似能力叫 connectors，Gemini 称为 connected apps。名字不同，作用相近：给 AI 一条操作外部应用的通道。

  授权只能解决“能不能访问”。真正影响结果的是“应该怎样操作”。Jeff 给 Google Calendar 写了两条约定：会议默认 45 分钟；事件描述先写 bottom line up front，也就是把结论放在最前面，再跟三条简短背景。

  他随后上传公寓租约，只要求创建次日上午 10 点与房地产经纪人的通话事件。新事件自动采用 45 分钟时长，描述也套用了约定格式。这次任务没有重新解释规则，插件只是执行通道，agents.md 才负责把个人习惯带进任务。

  视频还给了三条可直接借鉴的约定：

  • Gmail 回复不写落款，因为账号已有默认签名；
  • Notion 使用数据库里的现成模板，不另建空白页面；
  • Slack 线程摘要分为决策、行动项和待定问题。

  规则不长，省掉的都是反复纠正。好规则还得能验收：会议时长、重复签名、摘要分栏，打开结果就能核对。

  AGENTS.md 要薄，工具规则另存

  工具越接越多，所有约定都堆进 agents.md 会很快失控。Calendar、Gmail、Notion、Teams、Granola 和 Spotify 各自都有细节，但多数任务只会用到其中一两个。

  Jeff 的处理方式是让 Work 新建 tool-conventions.md，把插件和工具专属规则迁过去，再在 agents.md 留一个链接。主文件每次都会读取，因此只保留全局约束和路由；具体工具的说明等真正用到时再加载。

  可以把它理解成软件入口文件：只告诉系统去哪里找，不把全部实现塞进来。旧笔记把这种做法称为 Resolver，也就是“遇到某类任务，就加载对应文件”的路由表。

  本地知识库里有一份关于 AGENTS.md 的实测笔记，结论更严格：主文件保持在约 100–150 行较稳，继续膨胀容易让关键规则埋在中间。这个数字会随模型变化，但方向很明确。规则文件的价值取决于注意力，越长并不会自动越可靠。

  侧栏其实是三种不同工具

  视频花了较多篇幅演示桌面端侧栏，因为那里不只是文件预览器。

  第一种用途是预览和局部编辑文件。打开 tool-conventions.md 后，可以选中 Calendar 章节，让 Work 按同样结构补出 Gmail、Notion 和 Slack 小节。改错了还能 undo 或 redo。文件和目录链接也可以右键跳到 Finder，方便直接整理工作区。

  第二种用途是内置浏览器。按 Command + Control + T 打开网页后，可以用标注工具点中页面上的某个区域，再用自然语言描述修改。Jeff 选中个人网站的一块内容，让 Work 生成深色模式预览。预览任何公开网页都能做；真正把改动上线，还需要连接网站所在的平台。

  他还让 Work 检查课程说明里的每一个链接，确认没有死链，并验证链接会在新标签页打开。这类任务很适合浏览器执行，因为上下文就在网页里，无需反复截图和粘贴地址。

  登录账号则有清楚的隐私代价。内置浏览器可以继承登录态，便利性更高，也等于把更多操作能力交给 AI。适合先从公开页面、低风险账号和可撤销动作开始，不必一次开放全部权限。

  第三种用途是 side chat。输入 /side 可以开启一个临时对话。它能看到主任务的上下文，却不会打断主任务，里面的新内容也不会回流。Jeff 在主线程处理一份密集 PDF 时，用 side chat 询问术语的白话解释。

  这个边界很重要：side chat 适合问岔题，关闭后内容会消失。需要保留的结论要手动带回主任务或写入文件，不能把临时窗口当长期记忆。

  Skill 应该从真实修改里长出来

  视频后半段的例子，是整段内容里最有价值的一部分。Work 先生成一份 newsletter 初稿，Jeff 修改后贴回最终版本，再要求系统比较两版差异，只提取可重复的写作习惯。

  这次输入同时包含 V1 初稿和人工终稿。系统从 diff 里识别稳定变化，忽略与口吻无关的修改，生成一个名为 improve 的 Skill，并提出七条候选写作规则。规则先展示，得到批准后才写入 agents.md 的 voice principles。

  一句“记住我的风格”，每个模型都可能理解成不同意思。初稿和终稿的差异更可靠：哪些句子缩短了，哪些客套话被删掉，标题如何收紧，都有现成证据。

  旧知识库把 Skill 定义为“怎么做”的程序记忆。它可以包含步骤、模板、脚本和校验，按任务触发。视频补上了一个适合普通用户的形成路径：日常本来就会修改 AI 输出，把修改前后交给系统比较，再挑出值得长期保留的部分。

  这里仍要留一道人工门。一次修改可能只是当期内容的特例，不能自动升级成永久规则。重复出现、边界明确、未来能验收的差异，才适合进入 Skill。

  Routing map 把工作区变成系统

  最后一个例子是旅行目录。Jeff 把装有旅行偏好的文件夹拖进 Work OS，再让系统把旅行任务登记到 routing map。之后打开新会话询问冰岛行程，Work 已经知道该去 travel folder 查 Marriott 会员信息、航班座位偏好和过去旅行经验。

  路由图解决了规模问题。个人工作区不可能永远只有一个目录。项目、写作、旅行和财务各有资料，也各有规则。如果把所有文件摊在同一层，AI 需要扫描更多无关内容，人也很难维护。

  视频里 Jeff 的实际工作区有 30 多个 area 或 workstation。他还同时放置 agents.md 与 claude.md，让 ChatGPT Work 和 Claude CoWork 挂载同一个目录。资料和目录结构可以共用，各平台只读取自己的入口文件。

  这套结构可以压缩成四层：

  层	放什么	视频里的例子
  入口规则	全局习惯与路由	agents.md
  领域规则	某类工具或任务的约定	tool-conventions.md、travel folder
  执行能力	可重复的步骤和检查	improve Skill
  外部通道	真正读写应用	Calendar、Gmail、Notion、Slack、Ghost

  只接外部通道，AI 会做事但不一定按习惯做。只写规则，不接工具，它能给建议却没法完成动作。四层配齐，Work 才从聊天界面变成个人工作系统。

  我的补充：长期可用还差两道门

  视频强调“越教越有用”，方向没问题。长期运行时还要处理规则腐败。旧规则可能已经过期，新规则也可能和旧规则冲突。agents.md、工具约定和 Skill 都需要定期清理，确保它们描述的是当前做法。

  第二道门是验证与权限。创建日历事件可以回读标题、时长和描述；修改网站应先出预览，再确认上线结果；涉及邮件、发布和删除时，还要保留人工确认。连接成功只说明 AI 拿到了能力，验收证据才能说明任务完成。

  如果准备试 ChatGPT Work，可以从一个很小的闭环开始：挂载一个目录，写三条经常重复的规则，连接一个低风险工具，再用新会话验证规则是否真的沿用。稳定后再拆领域文件、增加 Skill 和 routing map。这样搭出来的系统慢一点，却更容易维护。

  6小时前