汪汪简报

全部新闻

1. 

   行业动态 · Interconnects

   为什么我仍未接受真正的RSI

   质疑RSI的依据仍未公开，做前沿模型的人可据此对照自家路线盲区。

   对前沿实验室的算力预算会，这篇把“万级并行智能体提升研发”与“真正RSI”拆开：在IPO审视下，把推理算力投向内部R&D的边际回报要按可陈述问题计价，不能默认能力跃迁会兜底。

   展开全文收起

   依据

   Nathan Lambert 在 Interconnects 说，他仍未买入“真正递归自我改进”（RSI，指模型能自动改进自身并加速研发）的叙事，提出“有损自我改进”：可自动化的研究太窄，面对 scaling laws（缩放定律）的指数成本，不足以带来巨大净加速；并行增加AI智能体的边际收益递减；资源瓶颈与政治也拖慢强LLM（大语言模型）。Richard Ngo 的判断是，安全社群押注几年内智能爆炸，但他预期方向大致对、事实会错——未来8年不会有超智能，只是变化快到“感觉”短时间线赢了。Noam Brown 的播客让 Lambert 更重视大规模推理算力的短期加速：实验室会把数千个智能体投向可测量问题；但总计算量上升时，他怀疑实验室能否持续把固定比例算力留给内部研发，尤其IPO后要面对基本经济学的审视。技术三人播客的共识是，现有技术能解决已知如何表述的问题，却不能在多数部分可验证领域神奇泛化到未知难题（数学是例外）。三人给的落地时间线是：Charlie O’Neill 称程序化接入职场工具约1年、必须走浏览器约2年；Beren Millidge 称完全通用约3年、80–90%覆盖更早；John Schulman 称“还行”版本约1年。因此取舍是：把算力押给可测的智能体产出，还是为不确定的研发突破留额度；前者可预测但不是RSI，后者才可能改变时间线。

   • Charlie O’Neill：程序化工具~1 年
   • Charlie O’Neill：浏览器~2 年
   • Beren Millidge：完全通用~3 年
   • Beren Millidge：覆盖度80–90%

   没写清 材料没说这些实验室是否已看到未公开的、具体到可复现的研发突破；因此不能替它补上“RSI已经发生”或“纯属焦虑”的判断。

   下一步 下一步可核对：这些实验室在IPO文件或财报里披露的内部研发算力占比是否随总算力上升而下降；若披露缺失，就看作者是否更新RSI时间线。

   原文 →

   剪报
2. 

   机构与应用 · Decrypt

   Visa采取行动堵住Meme币信用卡奖励漏洞

   持卡人撸meme币返现的路被Visa堵死，银行则借此收紧风险敞口。

   Crossmint 这类结账服务现在得决定：是自掏腰包补回返现留住冲量用户，还是承认这条刷卡入金通道已失去卖点；Visa 用一次类目调整，把成本推给了它。

   展开全文收起

   依据

   Visa 这次改的不是交易本身，而是 Crossmint 结账通道里 meme 币购买挂靠的商户类目。商户类目码（MCC，Merchant Category Code，决定一笔刷卡被算作什么消费）是返现规则的开关：同一笔买币只要挂在「数字媒体」名下，奖励系统就当它是订阅或内容消费，照发返现。Visa 把识别口径收回去之后，卡照样能刷，但返现消失、持卡人成本上升，同时发卡行把币价波动与商户合规风险移出信用卡体系。这里的取舍是：Visa 换来消费口径的干净，代价由 Crossmint 这类靠该类目冲量的结账服务承担——它要么补贴返现，要么失去卖点；靠积分摊薄买币成本的人被推回直接入金，而打算长期持币的人本来就不走这条口子。

   1. Crossmint 归入数字媒体
      ↓→触发
   2. 持卡人拿返现
      ↓→风险转移
   3. 发卡行担币价波动
      ↓→倒逼
   4. Visa 收紧类目
      ↓→结果
   5. 返现激励消失

   没写清 材料没给 Crossmint 通道的交易量与返现比例，无法判断这条口径对它是主要流量还是边缘业务。

   下一步 下一步看 Crossmint 是否公告对 meme 币购买停计返现——这决定冲量用户是走是留。

   原文 →

   剪报
3. 

   机构与应用 · 吴说区块链

   每周项目动态：Hyperliquid推出借贷功能，World推出金融应用，Polygon永久销毁1亿枚POL等

   借贷是Hyperliquid补齐链上金融闭环的关键一步，但其风控尚未经压力测试。

   打算把闲置稳定币存进 Hyperliquid 借贷池吃息的人，这笔钱现在要先问组合保证金账户扛不扛得住一次集中去杠杆——$269 million 的存量意味着这条链上金融闭环已不再是试验额度。

   展开全文收起

   依据

   Hyperliquid 联合创始人 Jeff Yan 说，平台走模块化路线：先在 HyperCore 上搭一个独立借贷协议，再通过组合保证金（portfolio margin，让多个仓位共享同一个保证金账户、盈亏互抵的机制）与永续合约、现货交易打通。机制上，借入 USDC/USDT 的一方按资金利用率（utilization，即池中资产被借出的比例）付息，出借方赚这笔息；因为借贷与永续共用 HyperCore 基础设施，抵押品价格波动会同时作用在两个市场上。Yan 称这套设计让借贷风险单独管理、闲置稳定币抵押品能生息、整体系统风险可分析。材料给出的当日借贷资产规模是 $269 million。

   1. 独立借贷协议先上 HyperCore
      ↓→整合
   2. 组合保证金接入永续与现货
      ↓→共享保证金账户
   3. 借贷风险单独管理

   没写清 材料没给借贷池的抵押率、清算阈值，也没说 HYPE 或 BTC 急跌触发清算时，坏账由保险基金还是出借方承担。

   下一步 看 Hyperliquid 是否公开借贷模块的抵押率与清算参数，以及首次大额清算后的实际处置记录。

   原文 →

   剪报

4. 行业动态 · AWS Machine Learning Blog

   将多模型AI Agent迁移到Amazon Bedrock AgentCore运行时

   多模型Agent迁到AgentCore后仍需自管知识检索，运维减负但灵活性收窄。

   已经在自建运行时上跑多模型 Agent 的团队要重算一笔账：把运行时托管出去划算，但检索质量这条链路的责任和成本仍留在自己这边，别跟着一起打包。

   展开全文收起

   依据

   AWS Machine Learning Blog 这篇《Migrating multi-model AI agents to Amazon Bedrock AgentCore runtime》主张把多模型 Agent 迁到 AgentCore 托管运行时；抓取到的页面正文未获得，只有标题和站点导航。按标题给出的机制推：托管运行时替团队接掉部署、扩缩容这类日常运维，代价是运行时行为由平台定义，而知识检索（给模型喂外部资料的检索层）不在托管范围内，仍需自建自管。所以这次迁移的取舍是拿架构自由度换运维减负——多模型路由和检索策略一旦要改，改动面从平台弹回自建这一侧，省下的是值班人力，不是集成工作量。

   没写清 材料没给迁移前后的延迟、成本或检索召回率任何一项对照数字，所以不能替它量化减负幅度。

   下一步 等 AWS 放出这次迁移的参考架构或迁移前后基准对比，确认检索层是否仍由客户自管。

   原文 →

   剪报

5. AI工具 · AWS Machine Learning Blog

   全新的AgentCore运行时：弹性、优化且始终保持快速启动

   AgentCore官方称冷启动不受镜像大小影响，生产环境省成本还需实测。

   这改变的是平台选型者排除候选运行时的依据：镜像体积不再能否决一个 agent 运行时，但也不能因此就当选它的理由——省不省成本得由你自己的调用曲线说话。

   展开全文收起

   依据

   AWS 官方博客的标题称，新的 AgentCore runtime 是「Elastic, optimized, and consistently fast starts」，即弹性、优化、启动一致地快；官方另称 cold start（冷启动，指实例从零到能响应请求之前的那段准备时间）不受镜像大小影响。这句话要成立，机制上只能是把镜像拉取与解压从每次启动的关键路径上挪走——托管缓存、预热池，或两者兼有。代价会落在别处：镜像被提前驻留，就占着常驻资源或缓存空间，也就有人为闲置容量付费。材料没有给出任何延迟或成本数字，也没说明测试时的镜像体积区间、并发规模与区域，所以「生产环境省成本」在这里仍是官方的宣称，不是可核对的结论。

   没写清 材料没说是多大的镜像、多大的并发下做的对照，也没给单次启动的延迟或费用数字，所以无法替你算出在哪个负载区间才省钱。

   下一步 等 AWS 公布该 runtime 启动延迟的基准测试方法、镜像体积分档与并发规模，或用自己的固定负载复跑一次再下结论。

   原文 →

   剪报

6. AI工具 · AWS Machine Learning Blog

   使用编码Agent在Amazon SageMaker AI上部署Hugging Face模型

   想省掉SageMaker部署样板活的人可看，但六项技能仅覆盖开箱路径。

   决定把 SageMaker 部署样板活外包给编码助手的人，先要判自家模型离默认路径有多近；不走开箱路径的话，省下的是写脚本的时间，赔进去的是私有依赖排查。

   展开全文收起

   依据

   这篇是 AWS Machine Learning Blog 自己发的教程，讲用编码智能体（coding agent，指能读写代码、调用工具自主完成多步任务的模型代理）把 Hugging Face 模型部署到 Amazon SageMaker AI（AWS 的模型训练与部署托管服务）上，替掉手写部署样板。机制上省下的量在固定动作：拉模型、写推理配置、建端点这一串交给助手生成，人不再逐行对着文档抄。代价则被推到路径外——按策展点评，给出的六项技能只覆盖开箱路径，自定义容器、私有依赖、网络与权限这些偏离默认的环节仍要人自己收尾，而教程本身没写这些环节失败时怎么办。所以这套东西对谁的收益最大，取决于你自己的模型离默认路径有多近：越近越划算，越远越像只帮你写了个开头。

   没写清 材料给到的是博客页与站点导航文本，没有那六项技能的具体清单，也没有自定义镜像或私有依赖安装失败时的样例，失败边界不能替它补上。

   下一步 下一步可去核对那六项技能的清单里是否包含自定义容器或私有依赖安装，若不含，就按自家环境补一条并实际跑通一次端点创建。

   原文 →

   剪报