阅读

中国能源科技公司远景能源（Envision Energy）宣布，已在内蒙古乌兰察布的银河AI数据中心（Galaxy AI Data Center）完成全球首个集成800伏直流（DC）供电系统的商业部署。该系统基于其Dubhe控制器和Dubhe能源基础模型，自今年8月起开始测试，现已投入运营。

传统数据中心依赖多级功率转换从电网获取可用电力，而远景能源的Dubhe技术直接将10kV中压交流电转换为800V直流母线。这一架构简化了功率转换设备，显著减小了占地面积，并提高了转换效率。系统集成了固态变压器（SST）、电池储能以及毫秒级的协调控制，以吸收GPU负载波动并提供备用电源。

据公司称，该方案支持更高密度的AI机架，使同一区域能容纳更多算力，并减少了对铜缆等布线的需求。银河园区计划扩展至3GW容量，最终“支持多达一百万个AI加速器”。此外，远景能源还打算将此800V直流技术推广至其“戈壁使命”（Mission Gobi）项目，目标是在2030年前于沙漠地区建立5GW的绿色AI数据中心容量。

微软.NET团队公布了一项实验成果，展示如何将AI代理技能（Agent Skills）封装进NuGet软件包中。这一做法旨在让函数库开发者在发布新版本时，能够一并附带针对该版本的使用指引，从而帮助AI编程代理更准确地掌握新版API的调用方式，减少因依赖模型过时的训练数据而产生的错误。

Agent Skills是一种通过SKILL.md文件向AI代理提供操作指令的机制，文件中记载了适用场景、执行步骤及相关知识。过去，这些技能主要通过Git仓库或专门的技能市场进行分发。微软此次尝试利用NuGet作为载体，使得不同版本的函数库能够自带各自适用的文档。当.NET项目执行dotnet restore命令时，NuGet会将依赖包下载至本地缓存，其中包含的SKILL.md文件也随之被获取。

然而，下载软件包并不意味着AI代理会自动使用其中的技能。代理仍需自行发现并读取这些文件，或者通过配套工具进行查找和导入。微软展示了两个辅助工具：dotnet-inspect用于检查NuGet包或项目依赖中包含的技能，列出名称、位置及说明；dotnet-package-skills则扫描项目使用的包，将技能复制到.agents/skills目录，以便开发团队将其纳入版本控制。

微软以Markout函数库为例进行了演示，该库包含了五个涵盖输出格式和内容组合等场景的技能。测试结果显示，技能对不同能力水平的AI模型影响各异：对于原本就能完成多数开发任务的强大模型，加入技能后的表现改善有限；而对于较弱的模型，它们可能无法稳定遵循技能指引。此外，若技能内容设计不当，反而可能增加词元消耗，因此维护者需要评估实际效益。

目前，NuGet MCP尚未整合技能支持，微软计划后续添加相关功能。由于AI代理可能依据SKILL.md的内容采取行动，微软也提醒开发者注意软件包来源，防止恶意指令成为新的供应链攻击途径。

据德国科技媒体t3n.de报道，谷歌“Suncatcher”项目的原型卫星在发射约三周后，成功完成了首次数据生成与回传。该卫星搭载DeepMind的Gemma 4模型，根据地面指令生成了一首关于太空的三行诗（Haiku）并发送至地球。这标志着谷歌探索太空作为可扩展机器学习基础设施的实验进入实际运行阶段。

尽管实现了端到端通信，但硬件限制揭示了当前太空算力的瓶颈。该卫星配备四块张量处理单元（TPU），其太阳能板最大输出功率约为1千瓦。由于芯片能耗较高，系统无法同时驱动所有TPU，只能轮流启用其中一块。此外，为避免过载供电和冷却系统，计算任务仅能以约15分钟的短间隔间歇性执行，无法实现持续运行。

谷歌表示，如果这些TPU在轨表现符合预期，计划于2027年再发射两颗具备更高发电能力的卫星，以构建更强大的轨道计算网络。这一进展也呼应了SpaceX等公司提出的将数据中心送入轨道的愿景，支持者认为太空环境有助于解决地面数据中心面临的电力和水冷压力，但批评者指出需考虑制造、发射及废弃带来的碳足迹问题。

当企业试图将AI代理投入实际业务时，最先撞上的墙往往不是模型不够聪明，而是无法回答一个基本问题：谁在用这个代理访问什么文档和工具，在什么条件下？스켈터랩스 CTO 서종훈将这一困境概括为：AI代理引入的瓶颈不是模型性能，而是控制。

他给出了一个具体的失败场景：如果每个团队各自直接调用不同的大语言模型，公司层面就难以追踪成本发生在哪里，各团队的防护栏也各不相同，整个组织的控制水平无法保持一致。这不是假设性问题，而是生成式AI在企业中扩散后，实际部署AI代理时面临的权限管控难题。

서종훈的论点建立在一个判断之上：过去AI市场专注于训练更好的基础模型，但在代理时代，OpenAI、Claude等开放模型已经过验证，企业真正需要的不是自己造一个更强的模型，而是能在自己的环境中灵活、安全地管控这些现成模型。

为了将这一论点落地，스켈터랩스设计了BELLA平台，其核心思路是把AI代理的全部生命周期——创建、部署、协作——放在一个统一的控制基础之上运行。平台分为四个层级：身份层负责识别当前登录的最终用户，并将这一信息无中断地传递到代理执行的最后一步，即搜索和工具调用；政策层基于身份层传递的用户信息，对特定文档、工具和代理逐一判定访问权限，从源头阻断越权访问；AI网关层是所有大模型调用和代理间调用的唯一通道，在此集中执行按用户和部门的成本统计、预算上限、模型路由和安全防护栏；资产层则管理文档索引、MCP工具、工作流、提示词和技能等全部AI资产，按企业、团队、个人三级划分共享与隔离范围。

在防御层面，BELLA设置了四道关卡：数据和检索增强生成的完整性保护防止文档块被篡改，并在注册时过滤提示注入和隐藏字符；输入输出防护栏拦截注入攻击，并对韩国格式的个人信息、API密钥、内部IP和域名进行掩码处理；代理行为控制按风险等级强制人工审批，在隔离沙箱中执行代码，防止无限循环或越权工具调用；网关资源保护按用户和密钥限制令牌配额和请求频率，检测异常消耗模式。

서종훈进一步强调，平台不应是阻止变化的层，而应是吸收变化的层。模型和工具在快速更替，平台如果绑定某一款模型或某一个云，就会在技术迭代时成为负担。BELLA基于Kubernetes构建，支持本地部署和私有云，不依赖特定模型或云厂商。

这一论点有明确的商业语境：스켈터랩스正在销售BELLA平台，其合作伙伴메타넷集团提供从战略咨询到基础设施的端到端服务。平台架构描述来自厂商自述，尚未见独立验证。但서종훈指出的问题——多团队各自调用模型导致成本和防护不可控——是企业AI代理项目中常见的现实障碍。

AI Agent 回答错误时，开发者面对一个难以诊断的问题：这个错误是因为 Agent 根本没有保存那条信息，还是保存了但没有在需要时检索出来？Salesforce AI Research 研究总监 Erik Nijkamp 在博客中指出，仅凭 Agent 的最终回答无法区分这两种失败，因为基于旧事实生成的回复和基于当前事实生成的回复读起来完全一样。

为了解决这个诊断盲区，Salesforce AI Research 构建了一套评估框架：生成跨越多个会话的长对话，在对话中植入特定事实，将完整对话输入运行中的 Agentforce 系统，然后提出依赖那些事实的问题，检验 Agent 的回答是否正确。这套方法的关键在于测试从'客户说出信息'到'Agent 依据信息行动'的整条路径，而非只检查存储层或只检查检索层。评估所用的对话数据来自 ConvoMem——该团队 2025 年发布的一个公开基准。

基于这套全路径评估，团队发现改进不需要动架构。Agentforce Memory 的底层架构从上线至今没有变化，真正改变的是记忆策略——即决定 Agent 保留客户哪些信息、以及当信息发生变化时如何处理的规则。旧策略将客户的更新视为一条新事实，与旧事实并列存储；新策略将更新视为对已有事实的纠正，覆盖旧值。

在自家系统上运行的评估结果显示：新策略对明确陈述事实的召回是旧策略的 1.8 倍，对随时间变化的事实的召回是旧策略的 2.2 倍。Salesforce 将此概括为端到端对话记忆质量'本质上翻倍'。

需要明确的是，以上全部数字均为厂商在自家产品上、使用自家发布的基准进行的自测结果，尚无第三方独立复现。评估中未披露绝对召回率、对话样本量或统计置信区间，因此 1.8x 和 2.2x 的倍数关系能说明策略调整的方向性效果，但不足以判断在客户实际部署场景中的绝对表现水平。

尽管如此，这套方法论本身具有可迁移价值：当 Agent 记忆表现不佳时，先建立全路径评估以区分存储失败和检索失败，再针对性地修改对应层的策略，往往比重建架构更高效。Salesforce 首席科学家 Silvio Savarese 将这一思路概括为产品组织与实验室的区别——问题已经在运行、客户已经在上面，纪律是在改动之前先诚实测量。

OpenAI于11月2日发表工程文章《Scaling Git at OpenAI》，公开其自研的Git兼容后端Pando。此前，由于AI编码代理Codex大幅增加了并行工作负载，OpenAI内部单一代码库的可靠性有时低于90%，抓取和推送缓慢，合并失败频发。Pando保留了标准的Git客户端和协议，仅替换了服务器端。据OpenAI报告，引入Pando后，推送的中位延迟降低了近80%（约5倍），每天传输给客户端的Git数据量接近1 PB，峰值一小时超过57 TB。该系统由一名工程师设计核心，并由Codex代理团队在10周内用Rust语言实现，自2026年4月起承接正式流量。

Anthropic则在10月13日的工程部落格中说明，已将其内部代码库从Git完全迁移到自研系统Scion。与OpenAI保留Git客户端不同，Scion采用独立的客户端与服务器架构，假设用户永远在线，这与为离线开发设计的Git不同。Anthropic表示，其每日合并次数从5月的约2,500次增加到9月的超过30,000次。主干历史接近100 GB，持续整合（CI）系统每天约有2,500万次检出，因此先前需要数百个Git镜像。换成Scion后，基础设施的CPU与内存需求降至原本的1/200，CI与研究用的检出时间从分钟级缩短到秒级。这套系统由7人团队在Claude协助下，耗时5个月建成。

两家公司面对的核心问题是AI代理写程式与提交的速度已让传统版本管理成为瓶颈。OpenAI的Pando通过放弃仓库范围的一致性要求，改用因果一致性，允许无关分支独立更新，从而消除写入争用；同时将每个推送的包文件存储为不可变对象以供复用。Anthropic的Scion则直接替换了Git架构，针对高并发场景优化。目前，这两套系统都属内部使用，未对外开源或提供服务。这一趋势表明，随着AI代理在软件开发中的渗透率提高，大型科技公司正在重新构建底层开发工具链以应对前所未有的吞吐量压力。

碳化硅功率半导体行业正在经历从150mm向200mm衬底的过渡。据Resonac开发负责人介绍，有观点认为200mm品成为主流大约在2030年前后，而300mm的全面过渡则要到那之后。在这个背景下，日本材料公司Resonac于2026年9月宣布成功生长并加工出直径300mm的SiC单晶基板，并在同月于横滨举办的国际碳化硅会议（ICSCRM 2026）上首次公开展示。乍看之下，这似乎是在为下一代量产做准备。但Resonac开发负责人的回答出人意料：没有销售300mm SiC外延晶圆的计划，开发目的纯粹是提高现有150mm和200mm产品的竞争力。

这一逻辑建立在一个具体的材料科学事实上。SiC单晶生长过程中，口径越大，结品生长时的温度分布等条件就越难控制。Resonac的策略是主动选择最难的300mm条件去攻克这些控制难题，然后将获得的温度场设计等经验回灌到已经在量产的较小口径产品上。换句话说，300mm在这里不是产品，而是一把尺子——用来校准自身在更实际尺寸上的工艺极限。

Resonac对竞争对手的300mm展示也给出了类似解读。中国的SICC和美国的Wolfspeed近期都公布了300mm SiC开发成果，外界容易将其理解为量产竞赛的提前布局。但Resonac认为，这些展示未必都指向早期量产，可能同样包含通过证明大口径能力来为中小尺寸产品背书品质信心的意味。当然，这是Resonac方面的判断，各公司的实际商业计划并未公开。

真正决定SiC衬底何时从200mm过渡到300mm的，不是衬底厂商能否做出样品，而是器件制造商那边的设备环境。Resonac举了一个历史先例来说明这一逻辑：据其介绍，当前正在推进的SiC基板200mm化，与硅半导体完成300mm过渡后腾出大量200mm兼容产线有关。硅和碳化硅并非使用完全相同的设备，但评估装置等部分设备可以共用，这为器件厂降低200mm SiC的切换成本创造了条件。同理，SiC的300mm化需要器件厂愿意将300mm产线资源分配给SiC，这取决于AI数据中心、电动车等终端市场对SiC器件的需求是否增长到足以证明这种分配合理。

成本是另一道门槛。大口径的核心优势是单片晶圆产出更多芯片从而摊薄成本，但如果300mm衬底本身的售价或器件厂的设备改造投入过高，总成本未必下降。Resonac明确表示，300mm要成为现实产品，必须达到器件厂愿意采用的价格水平。目前这个价格尚未形成。

这篇访谈拆解了一个常被简化的叙事：晶圆尺寸越大就意味着量产时代即将到来。实际上，衬底厂商做出300mm样品只是必要条件之一，器件厂的设备意愿、衬底的价格竞争力和终端需求的规模增长缺一不可。Resonac自身也表明，300mm的商用化将取决于客户器件厂的主动需求，而非衬底厂商单方面推动。

11月2日，Rikiya Takehi、Jayden Teoh、Alex Zhang和Omar Khattab发表了一篇题为《Sparks of Weight-Space Programming》的文章（作者自称为博客，但Willison认为它"论文形状"），提出"权重空间编程"概念——即大语言模型分析并修改神经网络权重。文章声称前沿模型GPT-6 Astra仅凭原始权重中的浮点数就能判断一个策略网络被训练来玩哪款游戏，无需任何工具或代码执行。

Willison用LM Studio加载Qwen 3.8 27B（Q4_K_M量化，约17GB），将默认8192上下文窗口调长（默认设置会报错），并通过环境变量将超时提升到900秒。他依次运行了论文提供的四个游戏权重解读任务。结果：Pac-Man在46分12秒、43506个推理token后正确识别，置信度72%；Pong在1小时4分54秒后正确识别，置信度75%；Breakout在52分25秒后正确识别，置信度88%。但Freeway失败了——模型将其误判为"一个简化的吃豆人式网格游戏：智能体四方向移动"。

推理过程本身比结果更值得关注。Willison摘录了Qwen的推理轨迹片段，其中模型在尝试理解权重数值时逐行列出输入编号、行列坐标和通道值，试图从数字中推断智能体位置，最终猜测"Agent position could be near bottom-right?"Willison形容这些推理轨迹"读起来有趣，但几乎不可理解"，并补充说一个足够有经验的人拿着纸笔花足够时间也能做到同样的事。

Willison也引用了两条外部批评。spaCy作者Matthew Honnibal认为原论文将"无工具解读权重"和"用代码修改权重"两个话题混为一谈，具有误导性；Sean Goedecke则拆解了论文中Astra修改Qwen3.5-0.8B权重的例子，指出其步骤与人类机器学习研究者的做法无异。Willison自己的判断是克制的：他认为这是一篇有趣的论文，但围绕它的许多评论"感觉并不合理"，他还没准备好宣布"源代码时代已经结束，未来将由不可理解的机器以不可理解的方式编辑自己的模型权重"。

据科技媒体 The Decoder 报道，斯坦福大学研究人员 Owen Queen 和 James Zou 对 50 个被广泛引用的大型语言模型（LLM）论断进行了测试，将其与 20 个当前主流模型进行对比。结果显示，44% 的论断已经“失效”，另有 34% 显著减弱，只有 16% 仍然成立。在估算了失效日期的 22 项发现中，其平均寿命仅为 15.7 个月。

研究发现，关于模型“不能做什么”的能力限制类论断过期速度最快。例如，此前被广泛讨论的数草莓字母、处理陌生数字系统算术、长上下文中间信息丢失等弱点，在当前模型中大多已消失。相比之下，涉及模型偏好和行为倾向的论断更具持久性，如谄媚行为、政治偏见以及作为评估者时的自我偏好等，这些特征在多个模型中依然显著。

该研究强调，随着AI开发速度的加快，针对LLM的经验性发现应被视为特定时间点下特定模型的观察结果，而非普遍真理。这一结论提醒读者和研究者，过去关于AI能力的许多经典结论可能已不再适用于当前的技术现实。

Collinear AI于2026年11月3日发布了CWE-bench v2，这是一个用于评估人工智能代理发现和修复开源软件中安全漏洞能力的基准测试。新版本开放了100个公共任务，覆盖了91种不同的常见弱点枚举（CWE），涵盖了广泛的漏洞类别。该基准要求代理在获取真实开源仓库的代码检出和简短指令后，在不破坏现有功能的前提下定位并修复安全缺陷。评分完全通过程序化检查实现，确保结果具有确定性且可复现。

根据Collinear AI公布的初步结果，在评估的11个模型中，Google的Gemini 4 Argon以67.8%的pass@1准确率和81.0%的pass@4准确率位居榜首，略高于Anthropic的Claude Opus 5.5（67.3% pass@1）。尽管有95个任务被至少一个模型解决，证明任务本身是可解的，但即使是表现最好的模型也在每次尝试中未能解决约19%的任务集，显示长尾漏洞修复能力仍有显著差距。在成本效率方面，DeepSeek V4.1 Flash、Claude Opus 5.5和Gemini 4 Argon构成了帕累托前沿，其中DeepSeek以每轮0.04美元的成本达到57.0%的pass@1，而Gemini则以3.92美元的成本获得微弱优势。

该基准测试的数据集和验证器已在Hugging Face上开源，支持通过Harbor框架直接运行。所有程序化检查均经过LLM评审小组的校准，以确保难度和公平性。此外，Collinear AI还维护了一个保留测试集，用于追踪模型在未见过任务上的进展。这一发布为开发者和安全研究人员提供了一个标准化的工具，以量化评估前沿模型在网络安全防御领域的实际能力边界。

Airbnb 工程团队在 2026 年 11 月发布了一份生产环境分类基准，核心发现是：用数十万条领域标注数据微调 Gemma4-E2B（20 亿有效参数）后，其 F1 从未微调的 0.563 升至 0.902，中位延迟仅 35ms，与 GPT-6.1 Sol 和 Claude Sonnet 5.5 等前沿模型质量持平，而成本约为后者的百分之一。测试基于 10,000 条加权样本的留出集，评估 Airbnb 定价与支付透明度政策违规检测这一真实任务，模型每分钟被调用数千次，分数须在 200ms 内返回。

作者将这一结果概括为

微调移动了质量-延迟前沿，而非沿前沿做取舍

即微调不是用质量换速度或用速度换质量，而是同时改善两者。对比之下，前沿生成模型即使开启低思考模式，中位延迟仍约 900ms、p99 达数秒；开源模型虽快但质量明显低于微调结果；TypeSafe Jev 在 100ms 以内表现最好的现成模型，但仍不及微调 E2B。详细提示词（2,700 词）可让专有模型提升一到三个百分点，但对延迟预算内的模型差距依然显著，且进一步增加成本。

文章给出四个判断条件：流量高于约 30 RPM 时自托管 GPU 成本低于前沿 API；延迟预算紧张时微调模型 p99 约 85ms 而前沿 API 中位即 900ms；需要可调阈值而非固定判定结果时，分数输出允许不重写提示词即调整精确率-召回率取舍；拥有标注数据时，示例能教会模型指令难以穷举的细微区分。作者同时承认，低频或每周变化的任务仍适合用前沿模型加良好提示词解决。这是 Airbnb 第一方自报基准，使用公开标价和 71% 缓存命中率（高于其实际观测值，有利于托管模型），未经第三方独立复现。

Meta的广告排序模型每次请求需要提取超过20,000个特征。这些特征并非计算独立的：一个七天点击计数和一个七天展示计数可能读取相同的事件源、应用相同的时间窗口过滤器，而点击率特征则复用两者的结果。Facebook特征框架F3的做法是把所有特征编译成一张有向无环图，编译器将重复节点合并，共享计算只执行一次。这大幅降低了执行成本，但代价是：合并图同时也是发布单元。一个特征定义出错，整张图无法上线，所有其他特征被迫等待。

随着特征数量从最初几百增长到两万，这个问题越来越严重。F3团队做过几轮改进来恢复发布速度，但每次收益都被新落地的特征侵蚀，因为所有特征仍然在合并图中一起发布。F3 Lightning的目标很明确：让每个特征独立发布，同时不丢失F3的计算效率。

最直接的方案是只拆发布。每个特征编译为独立配置，各自验证、各自上线、各自回滚。但早期原型暴露了预期之外的代价：独立配置到达服务进程后各自执行，F3合并图消除的重复读取、过滤和聚合又全部回来了，CPU用量显著上升。问题不是发布粒度而是执行粒度——拆开发布的同时也拆开了共享计算。

F3 Lightning的核心思路是：把共享执行带回来，但不把合并图带回来。具体做法是在服务启动时，将当前所有活跃特征配置中共享的工作整合到一个执行顺序中，而不是在编译时就把所有特征合并成一张图。这分四步完成。

第一步是稳定标识符。要识别两个独立编译的配置中包含相同计算，运行时必须能匹配它们。节点编号做不到，因为编号是各特征图内部的局部序号，同一个七天过滤器在一个配置中可能是节点2，在另一个中是节点7，插入一个节点还会导致后续全部重新编号。F3 Lightning让编译器从计算本身派生标识符：操作类型、参数、以及所有输入的标识符。因为输入的标识符已经反映了它上游的全部工作，这个标识符捕获了产生该结果的整条计算链。相同操作作用于相同输入的特征，即使编译和发布时间相隔数周，也会得到相同的标识符。

第二步是单一执行计划。服务启动时，F3 Lightning对所有活跃特征做拓扑排序，将每个节点放在其依赖节点之后。当多个特征包含相同标识符的节点时，计划只保留一份，所有消费者指向它。这保证了每个计算只执行一次。但计划仍然是图结构，执行器需要逐指针遍历。同一次启动处理将其展平为有序列表，每次请求变成沿列表的单次前向扫描，而不是遍历图。

到这一步，计算已经不再重复，但CPU仍然高于传统F3。团队定位到剩余成本来自内存布局：每个配置仍携带自己的请求时数据容器，中间结果分散在独立内存分配中。按顺序执行计划意味着在不同容器之间跳转，每次跳转都是一次缓存未命中。

第三步是共享内存缓冲。F3 Lightning用每请求一个缓冲替代了各特征独立容器。启动时，每个特征的引用被重绑定到该缓冲中的槽位。这带来三个改善：相邻计划步骤触碰相邻内存，恢复了合并图一直拥有的顺序访问模式；一个独立的就绪向量替代了逐特征的状态追踪，执行器可以检查值是否就绪而无需读取值本身；消费者不再获得自己的副本，共享槽位持有生产者结果的引用，一个被20个特征使用的计算只存储一次。标量值仍然复制，因为复制小值比跟随指针更便宜。

第四步是稠密索引映射。值虽然集中了，但找到它们仍然昂贵：每次访问需要解析标识符——哈希一个键、探测桶、跟随指针。在Meta的服务量级下，这种查找不高效。最终修复将标识符在初始化时映射为连续整数槽位，并重写所有配置中的引用指向这些槽位。读取结果变成对共享缓冲的直接数组索引，请求路径上没有哈希，没有查找表。

四步完成后，F3 Lightning实现了与F3可比的计算效率，同时每个特征可以独立发布。团队报告，同等提取特征到达生产环境的速度约为传统F3的3.6倍，基础设施计算成本没有增加。

但这个项目最反直觉的结论不是加速数字，而是第三步的发现。团队已经消除了所有重复计算，CPU仍然偏高。原因不是执行了多少次计算，而是结果存在哪里、存在多少份。两个设计可以执行完全相同的操作、以完全相同的顺序，但一个把结果分散在多个独立容器中，另一个集中在一个连续缓冲里——后者在缓存行为上完全不同。在现代CPU上，数据的物理位置和副本数量，与计算次数同等重要。这个认识比任何单步优化都更具迁移性：它意味着去重只是效率工程的一层，内存布局是另一层，而后者往往在去重完成之后才暴露出来。