我们的生产代码中有99%是由AI编写的。上周二，我们在上午10点推出了一个新功能，中午对其进行了A/B测试，并在下午3点因为数据说不行而将其终止。我们在下午5点推出了一个更好的版本。三个月前，像这样的一个周期需要花六周时间。

我们并不是通过在我们的IDE中添加Copilot而达到这里的。我们拆解了我们的工程流程，并围绕AI重建了它。我们改变了我们计划、构建、测试、部署和组织团队的方式。我们改变了公司中每个人的角色。

CREAO是一个代理平台。25名员工，10名工程师。我们于2025年11月开始构建代理，两个月前我从头开始重新构建了整个产品架构和工程工作流。

OpenAI在2026年2月发布了一个概念，它捕捉到了我们一直在做的事情。他们称之为harness engineering：工程团队的主要工作不再是编写代码。它是使代理能够做有用的工作。当某事失败时，修复从来不是“更努力尝试”。修复是：什么能力缺失了，我们如何使其对代理来说可读和可强制执行？

我们自己得出了那个结论。我们当时没有为它命名。

1、AI-First 与使用AI不同

大多数公司将AI bolted onto他们现有的流程。一个工程师打开Cursor。一个PM用ChatGPT起草规格。QA用AI测试生成进行实验。工作流保持不变。效率提升10到20%。结构上没有任何改变。

那是AI辅助的。

AI-first意味着你围绕AI是主要构建者的假设，重新设计你的流程、架构和组织。你停止问“AI如何帮助我们的工程师？”并开始问“我们如何重新构建一切，以便AI进行构建，而工程师提供方向和判断？”

差异是成倍的。

我看到团队声称AI-first，同时运行相同的冲刺周期、相同的Jira板、相同的每周站会、相同的QA签核。他们将AI添加到循环中。他们没有重新设计循环。

这种常见版本就是人们所说的vibe coding。打开Cursor，提示直到某些东西起作用，提交，重复。那产生原型。生产系统需要稳定、可靠和安全。你需要一个系统，当AI编写代码时能够保证那些属性。你构建系统。提示是可丢弃的。

2、为什么我们必须改变

去年，我观察了我们团队的工作方式，并看到了三个会杀死我们的瓶颈。

2.1 产品管理瓶颈

我们的PM们花几周时间研究、设计、指定功能。产品管理几十年来一直这样运作。但代理可以在两个小时内实现一个功能。当构建时间从几个月崩溃到小时时，一个长达几周的规划周期成为约束。

花几个月思考某事然后在两个小时内构建它是没有意义的。

PMs需要演变为以迭代速度工作的产品思维架构师，或者退出构建循环。设计需要通过快速原型-推出-测试-迭代循环发生，而不是委员会审查的规格文档。

2.2 QA瓶颈

同样的动态。在代理推出一个功能后，我们的QA团队花几天时间测试边缘案例。构建时间：两个小时。测试时间：三天。

我们用AI构建的测试平台替换了手动QA，这些平台测试AI编写的代码。验证必须与实施以相同速度移动。否则你就在旧瓶颈下游十英尺处构建了一个新瓶颈。

2.3 人力瓶颈

我们的竞争对手有100倍或更多的人做类似的工作。我们有25人。我们无法通过招聘达到对等。我们必须通过重新设计达到那里。

三个系统需要AI贯穿其中：我们如何设计产品、如何实现产品以及如何测试产品。如果任何一个保持手动，它就会约束整个管道。

3、大胆决定：统一架构

我必须先修复代码库。

我们的旧架构分散在多个独立系统中。一个单一变化可能需要触及三或四个仓库。从人类工程师的角度来看，它是可管理的。从AI代理的角度来看，是不透明的。代理无法看到全貌。它无法推理跨服务的影响。它无法本地运行集成测试。

我必须将所有代码统一到一个单一的monorepo中。一个原因：这样AI就可以看到一切。

这是harness engineering原则在实践中的体现。你将系统越多拉入代理可以检查、验证和修改的形式，你获得的杠杆就越多。碎片化的代码库对代理来说是不可见的。统一的则是可读的。

我花了一周时间设计新系统：规划阶段、实施阶段、测试阶段、集成测试阶段。然后又花了一周使用代理重新架构整个代码库。

CREAO是一个代理平台。我们使用我们自己的代理来重建运行代理的平台。如果产品能构建自己，它就有效。

4、技术栈

这是我们的栈以及每个部分的作用。

4.1 基础设施：AWS

我们在AWS上运行，使用自动缩放容器服务和电路断路器回滚。如果部署后指标下降，系统会自动回滚。

CloudWatch是中央神经系统。所有服务上的结构化日志，超过25个警报，每天由自动化工作流查询的自定义指标。每块基础设施都暴露结构化的、可查询的信号。如果AI无法读取日志，它就无法诊断问题。

4.2 CI/CD：GitHub Actions

每个代码变更通过一个六阶段管道：

Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release

每个pull request上的CI门强制执行类型检查、linting、单元和集成测试、Docker构建、通过Playwright的端到端测试，以及环境一致性检查。没有阶段是可选的。没有手动覆盖。管道是确定性的，所以代理可以预测结果并推理失败。

4.3 AI代码审查：Claude

每个pull request触发三个并行的AI审查通道，使用Claude Opus 4.6：

Pass 1: Code quality. Logic errors, performance issues, maintainability.

Pass 2: Security. Vulnerability scanning, authentication boundary checks, injection risks.

Pass 3: Dependency scan. Supply chain risks, version conflicts, license issues.

这些是审查门，而不是建议。它们与人工审查并行运行，捕捉人类在批量时错过的内容。当你一天部署八次时，没有人工审查者能在每个PR上维持注意力。

工程师还在任何GitHub issue或PR中标记@claude，用于实施计划、调试会话或代码分析。代理看到整个monorepo。上下文在对话间携带。

4.4 自我修复反馈循环

这是中心部分。

每天上午9:00 UTC，一个自动化的健康工作流运行。Claude Sonnet 4.6查询CloudWatch，分析所有服务的错误模式，并生成执行健康摘要，通过Microsoft Teams交付给团队。没有人需要请求它。

一小时后，分诊引擎运行。它从CloudWatch和Sentry聚类生产错误，在九个严重性维度上为每个聚类评分，并自动在Linear中生成调查票据。每个票据包括样本日志、受影响用户、受影响端点和建议调查路径。

系统去重。如果一个开放issue覆盖相同的错误模式，它更新该issue。如果之前关闭的issue再次发生，它检测到回归并重新打开。

当工程师推送修复时，相同的管道处理它。三个Claude审查通道评估PR。CI验证。六阶段部署管道通过dev和prod提升，每个阶段都有测试。部署后，分诊引擎重新检查CloudWatch。如果原始错误解决，Linear票据自动关闭。

每个工具处理一个阶段。没有工具试图做一切。每日循环创建一个自我修复循环，其中错误被检测、分诊、修复和验证，只需最小的人工干预。

我告诉Business Insider的一位记者：“AI将制作PR，而人类只需要审查是否有任何风险。”

4.5 功能标志和支持栈

Statsig处理功能标志。每个功能都在门后推出。推出模式：为团队启用，然后逐步百分比推出，然后完全发布或终止。终止开关立即切换功能关闭，无需部署。如果功能降低指标，我们在几小时内将其拉下。坏功能在推出的当天死亡。A/B测试通过相同系统运行。

Graphite管理PR分支：合并队列rebase到main，重新运行CI，仅在绿色时合并。堆叠PR允许在高吞吐量下增量审查。

Sentry报告所有服务的结构化异常，由分诊引擎与CloudWatch合并以提供跨工具上下文。Linear是面向人类的一层：自动创建的票据带有严重性分数、样本日志和建议调查。去重防止噪音。后续验证自动关闭已解决的问题。

5、一个功能如何从想法移动到生产

5.1 新功能路径

架构师将任务定义为带有代码库上下文、目标和约束的结构化提示。

一个代理分解任务，规划实施，编写代码，并生成自己的测试。

一个PR打开。三个Claude审查通道评估它。人类审查者检查战略风险，而不是逐行正确性。

CI验证：类型检查、lint、单元测试、集成测试、端到端测试。

Graphite的合并队列rebase，重新运行CI，如果绿色则合并。

六阶段部署管道通过dev和prod提升，每个阶段测试。

功能门为团队打开。逐步百分比推出。指标被监控。

如果任何东西下降，终止开关可用。电路断路器为严重问题自动回滚。

5.2 错误修复路径

CloudWatch和Sentry检测错误。

Claude分诊引擎评分严重性，创建带有完整调查上下文的Linear issue。

一个工程师调查。AI已经完成了诊断。工程师验证并推送修复。

相同的审查、CI、部署和监控管道。

分诊引擎重新验证。如果解决，票据自动关闭。

两条路径使用相同的管道。一个系统。一个标准。

6、结果

在14天内，我们平均每天三到八个生产部署。在我们的旧模型下，整个两周时期甚至不会产生单个生产发布。

坏功能在推出的当天被拉下。新功能在构思的当天上线。A/B测试实时验证影响。

人们假设我们用质量换速度。用户参与度上升了。支付转化率上升了。我们产生比以前更好的结果，因为反馈循环更紧。当你每天推出时比每月推出时学到更多。

7、新的工程组织

两种类型的工程师将存在。

7.1 架构师

一或两个人。他们设计教AI如何工作的标准操作程序。他们构建测试基础设施、集成系统、分诊系统。他们决定架构和系统边界。他们定义对代理来说“好的”是什么样子。

这个角色需要深刻的批判性思维。你批评AI。你不跟随它。当代理提出计划时，架构师找到漏洞。它错过了什么失败模式？它跨越了什么安全边界？它在积累什么技术债务？

我有物理学博士学位。我的博士学位教我的最有用的事情是如何质疑假设、压力测试论点，并寻找缺失的东西。批评AI的能力将比产生代码的能力更有价值。

这也是最难填补的角色。

7.2 操作员

其他人。工作很重要。结构不同。

AI将任务分配给人类。分诊系统找到一个bug，创建票据，表面诊断，并分配给合适的人。这个人调查、验证并批准修复。AI制作PR。人类审查是否有风险。

任务是bug调查、UI改进、CSS改进、PR审查、验证。它们需要技能和注意力。它们不需要旧模型要求的那种架构推理。

7.3 谁适应最快

我注意到一个我没预料到的模式。初级工程师比高级工程师适应更快。

传统实践较少的初级工程师感到被赋能。他们可以访问放大他们影响的工具。他们没有携带十年的习惯需要忘掉。

具有强大传统实践的高级工程师最难受。他们两个月的工作可以被AI在一个小时内完成。在多年构建罕见技能集后，这是很难接受的事情。

我不是在做判断。我是在描述我观察到的。在这个转变中，适应性比积累的技能更重要。

8、人性的一面

8.1 管理崩溃了

两个月前，我花60%的时间管理人。对齐优先级。运行会议。给予反馈。指导工程师。

今天：低于10%。

传统的CTO模型说要赋能你的团队做架构工作，培训他们，委托。但如果系统只需要一两个架构师，我需要先自己做。我从管理转向构建。我大多数日子从上午9点编码到凌晨3点。我设计系统的SOP和架构。我维护harness。

压力更大。但我享受构建，而不是对齐。

8.2 更少争论，更好关系

我与联合创始人和工程师的关系比以前更好。

转变前，我与团队的大多数互动是对齐会议。讨论权衡。辩论优先级。对技术决策不同意。那些对话在传统模型中是必要的。它们也很消耗。

现在我仍然和团队交谈。我们谈论其他事情。非工作话题。随意对话。离站旅行。我们相处更好，因为我们停止了争论可以轻易由我们的系统完成的工作。

8.3 不确定性是真实的

我不会假装每个人都快乐。

当我停止每天和人们交谈时，一些团队成员感到不确定。CTO不和我交谈意味着什么？我在这个新世界中的价值是什么？合理的担忧。

一些人花更多时间辩论AI是否能做他们的工作，而不是做工作。转变时期创造焦虑。我没有干净的答案。

我确实有一个原则：我们不因为工程师引入生产bug而解雇他们。我们改进审查流程。我们加强测试。我们添加护栏。同样的适用于AI。如果AI犯错，我们构建更好的验证、更清晰的约束、更强的可观察性。

9、超越工程

我看到其他公司采用AI-first工程，而让其他一切保持手动。

如果工程在几小时内推出功能但营销需要一周宣布它们，营销就是瓶颈。如果产品团队仍然运行每月规划周期，规划就是瓶颈。

在CREAO，我们将AI-native操作推入每个职能：

• 产品发布笔记：AI从变更日志和功能描述生成。
• 功能介绍视频：AI生成的动态图形。
• 社交媒体每日帖子：AI编排并自动发布。
• 健康报告和分析摘要：AI从CloudWatch和生产数据库生成。

工程、产品、营销和增长在一个AI-native工作流中运行。如果一个职能以代理速度运行而另一个以人类速度运行，人类速度职能约束一切。

10、这意味着什么

10.1 对于工程师

你的价值正在从代码输出转移到决策质量。快速编写代码的能力每个月价值更少。评估、批评和指导AI的能力价值更多。

产品感觉或品味很重要。你能看着生成的UI并在用户告诉你之前知道它是错的吗？你能看着架构提案并看到代理错过的失败模式吗？

我告诉我们19岁的实习生：训练批判性思维。学会评估论点、找到差距、质疑假设。学会好的设计是什么样子。那些技能复合。

10.2 对于CTO和创始人

如果你的PM流程比你的构建时间长，从那里开始。

在你扩展代理之前构建测试harness。没有快速验证的快速AI是快速移动的技术债务。

从一个架构师开始。一个人构建系统并证明它有效。在系统运行后将其他人加入操作员角色。

将AI-native推入每个职能。

预期阻力。有些人会推回。

10.3 对于行业

OpenAI、Anthropic和多个独立团队在相同原则上汇聚：结构化上下文、专用代理、持久记忆和执行循环。Harness engineering正在成为标准。

模型能力是驱动这个的时钟。我将CREAO的整个转变归因于最近两个月。Opus 4.5无法做到Opus 4.6能做的。下一代模型将进一步加速它。

我相信一人公司将变得常见。如果一个有代理的架构师能做100人的工作，许多公司将不需要第二个员工。

11、我们还早

我交谈的大多数创始人和工程师仍然以传统方式运作。有些人考虑做出转变。很少有人做过。

一位记者朋友告诉我她在这个话题上和大约五个人谈过。她说我们比任何人走得更远：“我认为没有人像你这样完全重建了他们的整个工作流。”

工具存在于任何团队都可以这样做。我们栈中没有什么 是专有的。

竞争优势是决定围绕这些工具重新设计一切，以及愿意吸收成本的意愿。成本是真实的：员工中的不确定性、CTO每天工作18小时、高级工程师质疑他们的价值、一个两周时期旧系统消失而新系统未被证明。

我们吸收了那个成本。两个月后，数字说话。

我们构建一个代理平台。我们用代理构建了它。

原文链接：Why Your “AI-First” Strategy Is Probably Wrong

汇智网翻译整理，转载请标明出处

CVS Health的AI副总裁构建了一个7000行C语言推理引擎，在MacBook Pro上运行Qwen3.5-397B。模型大小为209GB。笔记本有48GB内存。它以每秒4.4个token的速度运行，支持完整工具调用。

没有Python。没有PyTorch。没有框架。只有原始C、Objective-C和手工调优的Metal着色器。

Dan Woods将Flash-MoE构建为一个副项目，使用Claude Code作为他的编程伙伴，并使用Andrej Karpathy的autoresearch模式运行了90多次优化实验。代码在github.com/danveloper/flash-moe公开。有人已经将其fork到iPhone 17 Pro上运行。

这不应该成为可能。以下是它的工作原理。

1、秘诀：3970亿参数中的大部分都在沉睡

Qwen3.5-397B-A17B是一个混合专家模型。名称中的"A17B"是关键。在总计3970亿参数中，每个token只激活170亿参数。其余都处于休眠状态。

架构：60层Transformer，采用混合设计。45层使用GatedDeltaNet（线性注意力机制），15层使用标准全注意力。每层有512个专家。默认配置为每个token激活其中10个专家，加上一个共享专家。

2、为什么GatedDeltaNet对此很重要

标准注意力构建完整的token-by-token注意力矩阵。GatedDeltaNet不这样做。它使用delta规则维护一个运行状态矩阵：新值和预测值之间的差异修改持久内存状态。核心递推公式：

M_t = α_t * M_{t-1} * (I - k_t * q_t^T) + k_t * q_t^T

α是衰减门（内存遗忘速度）。Delta规则处理擦除和关联更新。紧凑，但它编码了层需要记住的一切。

为什么这对Flash-MoE很重要？

GatedDeltaNet以固定大小的状态（64个头，每个维护128x128矩阵）顺序处理token，而不是关注完整上下文。这意味着内存成本不会像标准注意力那样随上下文长度增长。对于已经受SSD流限制的内存模型，这就是"能工作"和"装不下"的区别。Qwen3.5-397B将60层中的45层分配给GatedDeltaNet，仅15层给全注意力，保持注意力内存预算可管理。

完整模型规格：隐藏维度4096，词汇量248320，原生上下文262K token（通过YaRN RoPE缩放可扩展到1,010,000），通过早期融合多模态token实现视觉语言能力。

3、K=4的发现

Dan Woods发现他可以在不降低质量的情况下将专家激活从K=10减少到K=4。但K=3会导致立即崩溃。这个尖锐的阈值很有趣。它表明路由网络学会了将关键推理集中在特定的专家组中，而不是均匀分布在全部10个中。四个专家捕获了基本计算。三个不够。边界很薄。

从10减少到4个专家将每token内存访问减少约67%。因为每层一次只需要4个专家在内存中（每个约6.75 MB），总实时内存占用降至约5.5 GB。其他203GB的专家权重？它们留在SSD上直到需要。

这是使其他一切成为可能的洞察。397B参数模型听起来需要GPU集群。170亿活跃参数模型加选择性加载听起来可能适合笔记本。确实如此。

4、蓝图：苹果的"LLM in a Flash"

Flash-MoE并非凭空而来。架构基础是苹果2023年12月的研究论文《LLM in a Flash：在有限内存下高效的大型语言模型推理》。

苹果解决了一个具体问题：如何运行比可用内存更大的LLM？他们的答案：将权重存储在闪存中，并在需要时带入DRAM。论文引入了Flash-MoE直接构建的两种技术。

窗口化通过重用先前激活的神经元来减少数据传输。如果神经元为前一个token加载且再次需要，不要重新加载。

行列捆绑重构权重读取以匹配闪存对顺序访问的偏好，增加每次读取操作的大小以最大化每IO操作的吞吐量。

MoE模型有一个特性：LLM中的FFN层具有高稀疏性。许多值在激活后变为零或接近零。对于密集模型，你可以利用这一点跳过一些加载。对于具有512个专家的MoE模型，每个token只激活4个，稀疏性是结构性的，而不仅仅是数值性的。99.2%的专家权重在任何给定token上都不使用。

苹果的论文报告与朴素加载相比，CPU速度提升4-5倍，GPU提升20-25倍，使模型大小可达可用DRAM的两倍。Dan采用了这个蓝图并将其专门应用于Apple Silicon上的MoE专家流，使用手工调优的Metal内核，将比率从2倍推到超过4倍（48GB RAM上的209GB模型）。

5、SSD流：模型驻留在磁盘上

209GB的4位量化专家权重位于MacBook的NVMe SSD上。当token需要处理时，Flash-MoE通过GCD（Grand Central Dispatch）发出并行pread()调用来加载该层的4个活跃专家。每个专家约6.75 MB。以测量的17.5 GB/s顺序读取SSD带宽，加载4个专家每层约需2.4毫秒。

关于SSD速度的背景：17.5 GB/s是Apple的定制存储控制器通过Apple Fabric互连提供的速度。x86机器上的标准NVMe SSD在最快的PCIe 5.0驱动器上最高达7 GB/s。Apple Silicon的存储控制器直接集成到SoC中，与CPU、GPU和神经引擎共享相同的内存结构。这种紧密集成是为什么流方法在这里有效而在典型PC上无效的原因。

非专家权重（嵌入、注意力投影、路由矩阵、归一化参数）总计5.5 GB，通过mmap以只读映射方式驻留在内存中。Metal暂存缓冲区增加约200 MB。推理期间的总内存分配：约6 GB，为OS及其页缓存留下42 GB空闲。

6、页缓存发现

页缓存被证明是最重要的优化，而且是偶然发现的。macOS自动将最近读取的SSD页面缓存在RAM中。Flash-MoE没有实现任何自定义缓存逻辑。

Dan尝试了所有替代方案。9.8 GB Metal LRU缓存。两个基于malloc的缓存（2581条目18GB，命中率52%；500条目3.5GB，命中率37%）。LZ4压缩将209GB压缩到175GB，但增加了解压缩开销。

所有这些都表现更差。Metal LRU因产生GPU内存压力而损失38%速度。即使容量更高，malloc缓存也无法击败OS，因为它们与页缓存竞争相同的RAM。LZ4压缩节省了磁盘读取，但CPU解压时间慢于以17.5 GB/s从SSD读取未压缩数据。

OS页缓存，不做任何聪明事，通过利用专家访问模式中的自然空间局部性实现71%命中率。同一会话中的token倾向于通过类似的专家路由。OS注意到重复读取并保持这些页面热。71%命中率意味着71%的专家加载以~400 GB/s带宽来自RAM，而不是以17.5 GB/s来自SSD。这是真正的速度倍增器。

Dan将其记录为"信任OS"原则。macOS内核在其VM子系统背后有数十年的工程。试图用应用级缓存在这个硬件上智胜它是必输的游戏。

7、58次失败实验

除了缓存之外，Dan运行了58次有记录的优化实验。许多使情况更糟：

• F_RDADVISE预取： 净收益0%。SSD DMA争用使GPU减慢73%，抵消任何预取收益。
• 时间专家预测： -18%。预测下一个token需要哪些专家并预加载它们。预测准确率不够高，不值得在错误猜测上浪费带宽。
• MLP路由预测器： 构建一个小神经网络预测专家路由。达到31%准确率，低于简单启发式的53%，运行预测器的推理开销消耗了任何收益。
• 推测性早期路由： 53%预测准确率，但错误预测的缓存污染和路由开销使其总体慢38%。
• GPU LUT反量化： -2%。反量化查找表未能击败FMA方法。
• GPU缓冲区压缩： -20%。Metal的缓冲区压缩增加延迟。
• 自旋轮询等待： -23%。忙等待GPU完成消耗OS用于页缓存管理的CPU周期。
• 直接mmap专家文件： 灾难性5倍退化。每页错误比pread()慢100倍，对于未缓存的7MB专家块。
• 推测解码： MoE上持平。每token IO成本随推测token线性扩展，所以提前起草4个token需要4倍的专家加载。无净收益。
• LZ4压缩： -13%。从209GB压缩到175GB，但热缓存读取的解压开销慢于原始SSD读取。

Dan不断重新发现的教训：在Apple Silicon上，SSD DMA和GPU计算共享相同的统一内存控制器。它们无法有利地重叠。即使最少的后台SSD IO也会通过内存控制器仲裁造成不成比例的GPU延迟峰值。GPU反量化内核已经在~418 GiB/s处饱和。任何竞争同一总线的SSD DMA流量导致的减速远大于单独数据传输所暗示的。

最佳流水线是串行的：GPU计算完成，然后SSD读取开始，然后GPU再次计算。与这个硬件约束对抗每次都使情况更糟。

8、Metal内核

Flash-MoE的性能来自1200行手工调优的Metal着色器。每个可以融合的操作都融合了。每个可以消除的中间缓冲区写入都消除了。

4位反量化矩阵向量乘法

核心计算内核。为缓存局部性分块，跨线程组SIMD缩减，共享输入缓存以避免冗余内存读取。

反量化步骤从朴素形式(nibble * scale + bias) * x重构为FMA形式：fma(nibble, scale*x, bias*x)。预计算scale * x和bias * x一次并在组中所有nibble上重用，将反量化+乘加折叠为单个融合乘加指令。这种代数重排带来12%速度提升，因为它直接映射到GPU的FMA硬件单元，使它们在~418 GiB/s处饱和。

这是实际有效的优化之一（与使情况更糟的十个不同）。2位变体使用相同的内核结构，但具有更窄的nibble提取。

融合SwiGLU和RMS归一化

两个操作，一个内核分派。SwiGLU激活（Qwen MLP块中使用的门控机制）和RMS归一化（层归一变体）作为单次Metal计算通道中的两遍缩减运行。它们之间没有中间缓冲区写入。每个本应写入设备内存并读回的字节都被消除。

GPU RoPE（旋转位置嵌入）

token旋转的内核融合。不是作为单独操作运行，RoPE计算融合到注意力矩阵构建中，在S4复杂旋转期间直接写入Q/K缓存。额外的内存遍历消除。

层间专家并行

GPU处理第N层时，CPU通过GCD预加载第N+1层的专家。这种CPU/GPU流水线重叠隐藏SSD延迟，但仅适用于已预热到OS页缓存的权重。对于冷启动或上下文切换，GPU等待。

GCD异步预读

使用dispatch_io_read与DISPATCH_IO_RANDOM提示通过Apple的GCD进行真正的异步专家加载。这比其他线程方法实现了更好的SSD吞吐量和CPU效率，让OS管理页缓存的复杂性。

缓存旁路用于注意力

GPU上的标准矩阵乘法通过Metal的纹理单元运行。这些单元有缓存，在全注意力的因果掩码层中，缓存命中失败很昂贵。Flash-MoE使用device地址空间和显式缓存控制绕过纹理单元缓存，实现缓存行大小的直接内存访问。

量化和布局优化

4位权重以64元素交错块布局存储。这最大化突发读取效率，并允许反量化内核从共享内存一次加载64个值。布局与GPU的内存访问模式匹配，实现接近理论峰值的带宽利用率。

9、架构的本质

Flash-MoE不是优化单个内核。它是设计一个在Apple Silicon特定约束下工作的系统：统一内存、SSD瓶颈、GPU限制。

关键洞察：瓶颈不是计算。具有Metal内核的M3 Max GPU可以轻松每秒处理数千个token。瓶颈是内存。209GB模型无法装入48GB RAM。因此架构围绕使SSD带宽尽可能有效而设计。

苹果"LLM in a Flash"论文中的窗口化和行列捆绑技术提供了一个起点。Dan添加了专家特定优化：积极卸载、选择性激活、依赖token重要性的自适应精度。结果是系统在约束下工作，而不是与之对抗。

状态： 运行。每秒4.4个token。工具调用。本地。无云。

原文链接: A 397B Model Running on a MacBook. 48 GB of RAM. No Cloud

汇智网翻译整理，转载请标明出处

AI辅助开发工具的快速发展已经引入了软件编写方式的明显转变。在开发者中，一个术语已经出现来描述这种转变——"Vibe Coding"。它指的是一种编程风格，开发者严重依赖直觉、AI生成的建议和迭代细化，而非深入推理系统的每个组件。

这种演变提出了一个重要问题：这种方法是增强了开发者生产力，还是逐渐削弱了基本技能？

1、理解Vibe Coding

Vibe Coding与其说是放弃结构，不如说是改变思考顺序。开发者往往不是从第一性原理一步步构建系统，而是从高层想法开始，使用AI工具生成代码，并通过迭代进行细化。

这个过程优先考虑速度和势头。开发者描述预期结果，评估生成的输出，并相应调整。虽然这种方法加速了开发，但它也可能绕过传统上对深入理解解决方案如何和为何起作用的训练。

2、Vibe Coding的理由

从生产力角度来看，Vibe Coding提供了显著优势。它允许开发者比以前更快地从概念转向实现。编写样板代码、设置API或创建UI组件等任务现在可以在几分钟内完成，而非几小时。

这种转变也降低了初学者的入门门槛。经验有限的个人可以通过利用AI辅助来构建功能性应用。因此，软件开发正变得更容易访问和包容。

此外，Vibe Coding使开发者能够将更多精力集中在更高层次的创造力和问题解决上。他们不再受语法或重复任务的约束，可以专注于设计更好的用户体验和试验想法。

3、技能退化的风险

尽管有这些优势，但对开发者技能的长期影响存在合理担忧。

主要风险之一是产生浅层理解。当代码被生成并在未经仔细分析的情况下被接受时，开发者可能会失去对算法、系统设计和权衡进行推理的能力。随着时间的推移，这会削弱他们独立解决复杂问题的能力。

调试也变得更加困难。AI生成的代码通常在标准场景下运行良好，但在边缘情况或生产约束下可能会失败。没有扎实掌握底层概念，开发者可能难以有效地识别和修复问题。

另一个担忧是对工具的依赖增加。过度依赖AI会降低在没有辅助的情况下编写代码的信心。这种依赖可能成为限制，在这种工具不可用或处理需要深度定制的问题的环境中。

4、第一性原理视角

从本质上讲，编程建立在三个基本能力之上：问题分解、复杂性抽象和系统行为的逻辑推理。

如果Vibe Coding用对生成输出的被动接受取代这些能力，它确实可能导致技能退化。然而，如果它补充它们——在保留批判性思维的同时加速实现——它可以显著提高生产力而不损害专业能力。

区别不在于使用AI，而在于与代码的参与程度。

5、长期影响

这种转变的更广泛影响已经变得明显。由于更容易获得工具，入门级开发者的平均能力正在提高，但高技能工程师与其他人之间的差距正在扩大。

将坚实基础与AI辅助相结合的资深开发者可以实现不成比例的高生产力。相比之下，那些仅依赖工具而不理解的人可能难以超越一定水平。

这一趋势也在影响招聘实践。组织越来越强调问题解决能力、系统设计和调试技能，而非仅仅熟悉语法或框架。

6、平衡的方法

Vibe Coding既不是固有的有害，也不是普遍有益。其影响完全取决于如何实践。

一种有纪律的方法是将AI作为协作者而非思考的替代品。开发者应该努力理解生成的代码，质疑设计决策，并在不同条件下验证行为。通过这样做，他们可以在受益于速度提升的同时保留核心技能。

7、结束语

Vibe Coding代表了软件开发的自然演变。它反映了一种向更高层次思考和更快执行的转变，由强大的工具实现。

然而，如果被被动使用，它也会引入理解深度降低的风险。最有效的开发者将是那些取得正确平衡的人——利用AI提高效率，同时保持扎实的基础技能。

最终，Vibe Coding并不决定开发者的质量。使用它的心态才决定。

原文链接: Vibe Coding: Productivity Booster or Skill Degradation?

汇智网翻译整理，转载请标明出处

当Anthropic将Claude Mythos锁在门后时，上海的一家实验室却做了相反的事。MiniMax今天开源了M2.7的权重——而这个模型带来了一项能力，它从根本上改变了我们对AI开发的思考方式。

M2.7，据MiniMax称，是业界首个"自进化"智能体模型。这个主张需要仔细拆解，因为它听起来既更谦逊又更重要。

1、"自进化"实际意味着什么

首先驱散科幻版本。M2.7并没有从零开始编写自己的架构或设计自己的奖励函数。那种级别的递归自我改进仍然是理论性的。

M2.7在其训练周期中所做的事情确实是新颖的。MiniMax在训练过程本身周围构建了一个自主智能体工具，而M2.7——以早期形式——作为该工具内的智能体运行。通过100多轮自主优化，模型承担了人类研究人员通常手动处理的大部分常规ML工程工作：

• 监控训练管道，并在故障发生时自主解决
• 构建和精炼自己的技能——存储在外部记忆支架中的工具和工作流规则
• 自我优化其推理支架——调整其自己的采样参数和工作流指南以改善任务性能，无需梯度更新

报告的结果：比基线提高30%的性能，在训练循环中直接人工干预比以往任何MiniMax模型都少。MiniMax估计模型在其自身开发期间处理了30-50%的常规ML工程任务。

这不是AGI。但它是AI系统能够参与自身改进循环的有意义一步——它打开了一条直接路径来压缩模型代之间的时间和计算成本。

2、架构和规格

M2.7基于 稀疏专家混合（MoE）架构构建，使其效率远超参数数量所暗示的：

• 总参数：2300亿
• 每token活跃参数：100亿（推理时仅激活约4.3%的总参数）
• 专家：256个本地专家，每token激活8个
• 层数：62
• 上下文长度：204,800个token

该架构使用多头因果自注意力与旋转位置嵌入（RoPE）和Query-Key RMSNorm——长上下文推理的稳定标准选择。稀疏激活模式使推理成本与理论大小的一小部分模型竞争。

3、基准性能

MiniMax将M2.7定位为软件工程和智能体工作流的前沿级模型：

SWE-Pro和Terminal Bench 2得分将M2.7置于与Claude Mythos在软件工程任务上相同的竞争层级——这使得开源权重发布更加重要。相当的能力，公开访问。

4、开源星号

这里的框架需要精确。MiniMax称M2.7为"开源"，权重确实在Hugging Face上公开可用。但许可证带有有意义的限制：商业使用需要MiniMax的事先书面授权。

这使M2.7与其他使用限制性许可证的"开源权重"发布处于相同的有争议类别——既不是OSI定义中的完全开源，也不是完全封闭。对于个人研究人员、学者和构建非商业应用的开发者，M2.7是真正可访问和免费的。对于希望在其上构建产品的公司，商业限制创建了一个合规层，有效地使MiniMax成为生产部署的守门人。

这一区别很重要。HN和其他地方的社区已经标记了许可证差距。你是否认为M2.7"真正开放"取决于你的用例。

5、重要的对比

本周两个最大的AI模型故事形成了一对醒目的对比。Anthropic构建了Claude Mythos，认为它太危险，并将访问限制在50个精英组织。MiniMax构建了M2.7——一个在软件工程基准上表现相当的模型——并发布了权重。

这一对比说明了关于前沿AI应如何分发的分歧哲学。限制的理由：某些能力太危险，无限制访问会创造生存风险。开放的理由：限制强大模型会不对称地集中能力，使大多数组织防御性失明，而精英机构获得进攻性优势。

M2.7的自进化训练方法使这一对比更加尖锐。如果模型能够越来越多地参与自身开发，能够运行这些管道的实验室与不能运行的实验室之间的能力差距将随时间压缩——但前提是产生的模型是可访问的。被锁定的自我改进模型会加速能力集中。开源权重发布，即使不完美，更广泛地分发该方法的益处。

6、MMX-CLI：实用智能体集成

值得注意的是，与M2.7权重发布一起，MiniMax在4月9-10日发布了MMX-CLI工具。这个命令行界面让AI智能体原生访问MiniMax的完整生成堆栈——文本、图像、视频、语音、音乐、视觉和搜索——直接从终端或在智能体环境如Cursor和OpenCode中。

对于开发者，这是实用的入口。你不需要为每个模态建立单独的API集成。MMX-CLI将能力表面整合为智能体工作流可以直接调用的单一界面。这是将MiniMax定位为多模态智能体基础设施层而非仅仅是模型提供商的有意义一步。

NVIDIA、TogetherAI、Fireworks和Ollama都在开源权重发布的第一天集成了M2.7——表明该模型在推理生态系统中落地良好。

7、对构建者意味着什么

三个实际影响：

如果你是研究人员或独立开发者： M2.7值得认真评估。SWE-Pro和Terminal Bench 2得分表明它是智能体编码工作流的真正顶级模型，权重今天可通过Hugging Face和Ollama访问。

如果你正在构建产品： 在将M2.7作为基础提交之前，与MiniMax澄清商业授权路径。许可证为生产部署创造了你需要在技术债务之上构建之前解决的不确定性。

如果你关心AI开发方法： 注意自进化训练主张。让模型参与自动化自身训练管道的能力不是营销角度——它是AI系统工程结构如何构建的真正转变。掌握这一反馈循环的实验室将显著压缩模型代之间的时间。

8、个人看法

自进化的框架将吸引怀疑，其中一些是合理的。"自我改进AI"是一个被足够滥用的短语，以至于它读起来像营销，除非被证明否则。MiniMax的版本对范围是诚实的：不是模型重写自己的权重，而是模型作为其自身训练基础设施内的智能体运行。

那个限定版本仍然有趣。如果模型能够可靠地自动化培训自身所涉及的30-50%的常规工作，每代的人工劳动成本显著下降。在几个模型迭代中递归应用，那是复合的。

开源权重发布，即使有商业限制，也是正确的决定。更多开发者能够访问前沿级模型推动更多实验、更多反馈，以及对基准测试反映真实世界能力的更多压力。这对生态系统有好处。

与Mythos的锁定相比很难忽视。两个模型。相当的软件工程能力。一个对50个组织可访问。一个在Hugging Face上。分发哲学的分歧是与模型本身同样重要的故事。

原文链接: MiniMax M2.7: The First Self-Evolving Agent Model is Here

汇智网翻译整理，转载请标明出处

这篇文章涵盖了当今可用于为机器人训练构建3D世界和模拟就绪资产的每个工具。使用上面的对比表找到适合你设置和预算的工具，然后跳转到你感兴趣的工具部分。

1、World Labs Marble

制造者： World Labs
链接： https://marble.worldlabs.ai

Marble是一个基于Web的生成式世界模型，可以从文本、图像、360度全景或视频创建逼真的3D环境。它输出用于视觉渲染的高斯 splat 和用于物理的单独碰撞器网格。生成不需要本地GPU。

最适合： 导航测试和领域随机化。不适合操作研究，因为单个物体无法作为独立刚体交互。

注意事项：

• 默认导出格式是SPZ，不是PLY。3DGRUT转换只接受PLY。下载前手动切换。
• 在Isaac Sim中选择OpenGL作为坐标系会导致场景倒置导入。改用OpenCV。
• USDZ文件是zip压缩包。在Isaac Sim中打开前先解压。

文档： https://docs.worldlabs.ai
Marble + Isaac Sim工作流（NVIDIA）： https://developer.nvidia.com/blog/simulate-robotic-environments-faster-with-nvidia-isaac-sim-and-world-labs-marble/

2、BlenderMCP

制造者： Siddharth Ahuja
链接： https://github.com/ahujasid/blender-mcp

BlenderMCP通过模型上下文协议将Claude AI连接到Blender。用 plain language 描述场景，Claude自动执行Blender Python命令。集成Poly Haven、Hyper3D Rodin、Hunyuan3D和Sketchfab。

最适合： 无需Blender专业知识的快速场景原型设计。

文档： https://github.com/ahujasid/blender-mcp

3、SceneSmith

制造者： MIT CSAIL和Toyota Research Institute
链接： https://scenesmith.github.io

SceneSmith接收文本提示，通过分层VLM智能体管道生成完全家具化、物理就绪的室内场景。每个物体获得碰撞几何、估计质量、摩擦力和关节。1,284个场景的预生成数据集在HuggingFace上免费提供，无需运行管道即可使用。

最适合： 需要密集物体布置和家具关节的操作研究。

注意事项：

• 运行管道最少需要32到45GB显存。消费级硬件无解。

文档： https://github.com/nepfaff/scenesmith
数据集： https://huggingface.co/datasets/nepfaff/scenesmith-example-scenes

4、Infinigen

制造者： Princeton Vision and Learning Lab
链接： https://infinigen.org

Infinigen是一个完全程序化3D生成器，使用数学Python代码和Blender。零AI。它生成户外自然场景、室内环境和模拟就绪的关节物体，自动烘焙PBR纹理和真实值标注。生成仅需CPU，渲染仅需2GB显存。

最适合： 生成大规模多样化训练数据集，自动获取深度、法线、分割和光流。

注意事项：

• 约束求解器在某些seed上会崩溃。尝试不同的seed，并始终添加fast_solve.gin。
• 整个场景的USD导出器会剥离所有关节。对于关节物体，单独使用spawn_sim_ready_asset.sh。

文档： https://github.com/princeton-vl/infinigen

5、EmbodiedGen

制造者： HorizonRobotics
链接： https://github.com/HorizonRobotics/EmbodiedGen

EmbodiedGen将单个图像或文本提示转换为物理就绪的3D物体，具有碰撞几何、质量和摩擦力，同时导出到USD、URDF、MJCF、GLB和OBJ。

最适合： 将真实物体数字化为用于操作任务的模拟就绪资产。

文档： https://github.com/HorizonRobotics/EmbodiedGen

6、fVDB Reality Capture

制造者： NVIDIA
链接： https://fvdb.ai/reality-capture

fVDB Reality Capture从照片重建真实物理环境到高斯splat和三角网格，直接USDZ导出到Isaac Sim。由NVIDIA构建，Apache 2.0开源。

最适合： 创建真实设施的数字孪生用于模拟到真实迁移。

注意事项：

• 16GB显存足以进行高斯splat重建，但不足以进行生产级网格提取。

文档： https://fvdb.ai/reality-capture

7、LiteReality

制造者： 剑桥大学、香港大学、慕尼黑工业大学。NeurIPS 2025
链接： https://github.com/LiteReality/LiteReality

LiteReality通过检索艺术家制作的模型并在其上绘制完整PBR材质，将LiDAR iPhone扫描转换为图形就绪的3D场景。输出是真实的可编辑几何，而非高斯splat。

最适合： 构建具有高材质保真度的结构化室内数字孪生的研究实验室。

注意事项：

• 最少24GB显存。RTX 5080及以下硬阻塞。
• 需要200GB材质数据库下载。非可选。
• 扫描需要带LiDAR的iPhone Pro。不支持Android和标准网络摄像头。

文档： https://github.com/LiteReality/LiteReality

8、SAGE / SAGE-10k

制造者： NVIDIA、UIUC、康奈尔大学、斯坦福大学
链接： https://nvlabs.github.io/sage
数据集： https://huggingface.co/datasets/nvidia/SAGE-10k

SAGE是一个智能体管道，使用视觉评判和物理评判（在循环中运行Isaac Sim）为Isaac Sim生成经过物理验证的家具化室内场景。SAGE-10k是随附的免费数据集，包含HuggingFace上10,000个预生成场景，可在几分钟内加载，无需运行管道。

最适合： 需要在GPU集群上大规模物理验证环境的团队。对于其他人，SAGE-10k是实际的入口点。

注意事项：

• 完整管道需要在8个GPU上90GB+显存。任何单GPU设置完全阻塞。

文档： https://github.com/NVlabs/sage

9、结束语

这个工具包涵盖了从快速原型到生产级模拟的完整3D世界构建流程。选择适合你的工具，开始构建具身AI的未来。

原文链接: The Complete 3D World Building Toolkit for Embodied AI (2026)

汇智网翻译整理，转载请标明出处

在机器人VLA社区，许多近期工作仍在LIBERO数据集基准上进行评估，性能数字稳步攀升至接近饱和。在这篇文章中，我采用一个非常简单朴素的流匹配VLA模型，实证测试它在官方数据集上训练并通过环境 rollout 评估时，在LIBERO上的实际表现。

训练和评估脚本可以在这里找到。

1、训练数据

训练数据直接来自官方的 physical-intelligence/libero 数据集。它包含1,693个episode和273,465帧，涵盖四个套件中的40个任务：libero_spatial、libero_object、libero_goal和libero_10。

该数据集的Hugging Face版本遵循LeRobot v2.0格式。为避免处理LeRobot数据管道的复杂性，脚本直接将其转换为PyTorch DataLoader并将批次输入模型。

2、模型架构

模型由三个组件组成，没有VLA预训练。它本质上是一个普通且相对较小的模型：

• vision_encoder：ResNet18骨干网络，其中BatchNorm被GroupNorm替换。它分别编码主摄像头图像和手腕摄像头图像，每个产生512维特征
• text_encoder：默认使用Qwen3-0.6B将任务描述编码为语言特征。如果不冻结，仅对q_proj/k_proj/v_proj/o_proj应用LoRA微调。为了更快的实验，它可以简单地被冻结
• noise_pred_net：一个ConditionalUnet1D，将动作序列(x_t)作为输入并预测流匹配的速度场(v_t)。UNet骨干是一个1D卷积U-Net，通道大小为[256, 512, 1024]，中间有两个残差块，每个块注入FiLM条件

3、条件如何构建

每时间步条件特征的构建如下：

• 主摄像头：512
• 手腕摄像头：512
• 机器人状态：8
• 文本嵌入

所以：

per_timestep_cond_dim = 512 * 2 + 8 + text_embed_dim

使用默认设置obs_horizon=1，UNet的global_cond_dim就是当前观察。如果obs_horizon > 1，多帧被展平并用作全局条件。实践中，大多数VLA设置使用1。

训练期间的实际拼接顺序是：

obs_features = [main_feat, wrist_feat, x_pos, text_feat]

4、流匹配过程

这遵循标准的流匹配公式：学习一个速度场，将随机噪声转换为真实动作轨迹。

真实动作轨迹是(x_{traj})，形状大约为[B, 16, 7]。生成相同形状的高斯噪声样本(x_0)。

过程是：

• 采样噪声：x_0 = torch.randn(...)
• 使用FM.sample_location_and_conditional_flow(x0, x_traj)采样时间(t)、中间状态(x_t)和目标速度(u_t)
• 模型接收(x_t)、观察条件obs_features和时间(t)，并预测速度(v_t)
• 损失是预测速度和目标速度之间的MSE：

mean((v_t - u_t)^2)

本质上，模型学习：

给定任务文本、机器人状态和双视图图像，当前带噪动作(x_t)应该朝哪个方向移动才能变成真实轨迹？

5、其他超参数

动作维度：7 预测范围：16 观察范围：1 动作范围：8 文本长度：64 文本池化：最后一个有效token LoRA：r=16, alpha=32, dropout=0 优化器：AdamW (lr=1e-4, weight_decay=1e-6) 学习率调度：带500步warmup的余弦 精度：bfloat16 流匹配：sigma=0.0，速度MSE损失

6、在LIBERO上的评估

由于评估涉及机器人 rollout，它是动态的。实现遵循openpi libero示例的官方脚本。

• 加载检查点（vision_encoder、noise_pred_net和LoRA权重（如果适用））
• 遍历所有LIBERO任务套件
• 对于每个任务：首先通过_get_libero_env(...)创建环境 检索任务描述，使用task_suite.get_task_init_states(task_id)采样初始状态 每个任务评估最多n_test=50个episode

每个episode：

• 重置环境
• 等待稳定（num_steps_wait=10）
• 维护长度为obs_horizon的obs_deque
• 提取：

主图像：agentview_image 手腕图像：robot0_eye_in_hand_image 机器人状态：位置(3) + 轴角(3) + 夹持器(2) = 8维 图像旋转180°并转换为CHW格式

观察的编码方式与训练相同：

• 两个图像 → ResNet18
• 文本 → Qwen编码器
• 与机器人状态拼接 → obs_features

7、通过流匹配推理

• 从噪声初始化轨迹：形状(1, 16, 7)
• 执行16个Euler步骤：
• 预测速度(v_t)
• 更新轨迹：

traj = traj + v_t / timehorizon

这逐渐将噪声转换为可执行的动作序列。

只执行前8步，然后重新规划。这允许持续修正，而非承诺完整轨迹。

rollout继续直到：

• done=True，或
• 达到最大步数

每个episode记录成功率，然后按任务和套件平均。

8、在LIBERO上的性能

训练后（没有重度调参），性能在约2000个epoch时饱和，达到约85%成功率。

这已经相当高，表明即使是没有预训练的简单流匹配模型也能有效拟合数据集。

然而，LIBERO的一个主要问题是训练和评估场景高度相似。即使有随机初始化，变化也有限。

9、在LIBERO-plus上的性能

较新的LIBERO-plus基准引入了更多变化：

• 光照变化
• 物体位置
• 初始状态
• 摄像头角度
• 文本指令

它还提供了更大的增强训练数据集。

在这个实验中，我直接评估了在LIBERO上训练的模型（2000 epoch的检查点）在LIBERO-plus上的表现，没有重新训练。

如预期的那样，成功率急剧下降到23.4%。

10、结论

结果表明社区应该超越原始LIBERO基准。至少，仅报告LIBERO指标是不够的，可能具有误导性。

原文链接: Is LIBERO Still a Reliable Benchmark? A Simple Flow-Matching VLA Test

汇智网翻译整理，转载请标明出处

过去三年，科技世界一直沉迷于"聊天窗口"。我们把大语言模型当作精致的笔友——用于摘要或礼貌的电子邮件，但最终局限于屏幕。我们现在正在超越聊天窗口时代。前沿已经从生成式AI——创造内容的机器——转移到智能AI：执行行动的机器。

这不再是一个理论上的转向；它是战略上的必然。随着我们进入2026年，实现这一飞跃的主要基础设施不仅仅是更大规模的GPU集群——而是虚幻引擎（UE）。曾经被C层高管们仅仅视为"游戏引擎"的UE5，已经崛起为工业生存的 inevitable 操作系统。它是自主智能体学习导航物理世界的熔炉，在它们被赋予价值百万美元的硬件钥匙之前，通过高保真模拟进行推理。

1. "第零天"能力：为尚不存在的物体训练AI

在传统制造业中，计算机视觉是一个反应性游戏。你制造一个零件，拍一万张照片，然后训练模型识别它。这造成了巨大的"未来数据缺口"，减缓了创新速度。波音目前正在通过使用"CAD到模拟"管道来拆解这个瓶颈。

通过参数化真实世界——将操作设计域（ODD）定义到太阳的确切角度和风速——工程师可以在甚至还未离开设计阶段的组件上训练AI。一个主要例子是KC-46空中加油机的"带翼管道"（加油杆）。通过在虚幻引擎中模拟加油杆的外观和运动，波音可以实现他们所说的"第零天"就绪。

"我们可以拥有这种……第零天功能来识别……尚未被创造出来的物体。"

当那个物理组件最终到达工厂车间时，AI不是第一次看到它。它已经在模拟中看过一百万次，跨越每一个可能的照明条件和方向。

2. 超越生成：智能伙伴的崛起

2026年的范式转变将我们从把AI当作你使用的工具，转向你管理的智能伙伴。我们正在从简单的任务完成，过渡到整个业务生命周期的自主编排。这一演变由三个执行支柱驱动：

自主性： 系统不只是"预测下一个token"，而是在多步骤流程中规划、推理和修正路线。

成本降低： 利用"人在回路"委派，专家充当高级监督者而非手动操作员。

编排： 将不同的软件工具统一为单一工作流的能力，越来越多地由 模型上下文协议（MCP）标准化。MCP允许智能体安全地与内部构建日志、CAD数据和文档对话，作为一个整体。

3. 缩小工程中的"上下文缺口"

通用LLM非常擅长写Python脚本，但在面对虚幻引擎数百万行C++代码库时，它们经常出现幻觉。这就是"上下文缺口"。为了解决这个问题，NVIDIA和主要工作室正在把检索视为核心生产基础设施。

标准RAG（检索增强生成）经常失败，因为它按"token计数"分块代码，这可能会把一个关键的C++函数切成两半，使其毫无用处。新的标准是基于AST的语法感知分块，它尊重功能边界和控制流。通过利用NVIDIA NeMo Retriever NIM和GPU加速向量搜索（NVIDIA cuVS），企业正在构建真正理解其特定分支专有架构的编码智能体。这不仅仅是自动补全；它是一个检索原生系统，在第一次构建之前就防止集成失败。

4. "电子很便宜"：数字孪生革命

2026年的经济现实是直白的：硬件缓慢而昂贵，而模拟快速且几乎免费。这种"先构建游戏"的理念是CES 2026上的主导主题。从约翰迪尔的自主收割机到索尼本田移动出行的AFEELA，目标是"在实验室中失败"，而非在路上或田间。

现代车辆的核心是UE5下一代HMI体验。运行在AMD Ryzen™ AI嵌入式P100系列硬件上，UE5的一个实例现在以稳定的60 fps"驱动每个像素"的数字驾驶舱。它同时渲染仪表板、ADAS可视化和3D地图，同时为车辆的AI智能体提供感知游乐场。

"先构建游戏，或者电子很便宜。"

在这个世界中，数字孪生是权威的真相来源。如果你能在dSPACE硬件在环测试中模拟120辆车和暴风雪，你就不需要等待真实的暴风雪来验证你的紧急制动。

5. 完美标签和受控偏见

虚幻驱动的合成数据的最大超能力是生成"完美标签"的能力。在现实世界中，人类标注员在姿态估计或语义分割方面挣扎。在UE5中，引擎已经知道每个像素的身份和方向。

这是通过工程化渲染管道本身实现的：

• 后处理材质和自定义深度模板用于生成像素完美的掩码
• 工程师在标签生成期间专门绕过色调映射，以避免镜头眩光、泛光和其他会"涂抹"真实值的后处理伪影
• 这使得能够即时生成世界法线、分类和边界框

然而，这种控制是一把双刃剑。如果你控制数据，你就控制偏见。如果工程师未能将"夜间"或"暴雨"参数化到ODD中，智能体将永远学不会在这些条件下看见。在2026年，AI工程师的首要责任不再只是"训练"模型，而是精心定义它所居住世界的参数。

结论：执行的新时代

我们已经超越了AI作为新奇事物的时代。CES 2026上的展示证明，我们正处于生产就绪执行的时代。虚幻引擎已经超越了娱乐，成为机器学习如何存在的基础层。

随着AI智能体开始自主管理项目生命周期——在实验室中失败一千次，而现实甚至还未开始——人类专家的角色正在从"执行者"转变为"约束的架构师"。我们正在进入一个完美在构建之前就已经被渲染出来的世界。它给我们留下了一个单一、挑衅性的问题：在一个我们可以在毫秒中模拟和解决每个机械故障的时代，人类直觉的价值会发生什么变化？

原文链接: The Unreal Engine Singularity: Why the Future of Agentic AI is Rendered, Not Written

汇智网翻译整理，转载请标明出处

大语言模型可以写诗、调试代码、通过医学执照考试。然而问它在大热天握着一杯冰水感觉如何——你很快就会感受到差距。LLM是卓越的机器，但它们的理解完全存在于语言内部。它们了解世界的方式就像一个从未离开过建筑的图书管理员了解海洋一样。

这被称为扎根问题——解决它可能是当今AI最重要的挑战。

什么是扎根问题？

当孩子学习"热"这个词时，他们不是从字典中学到的。他们触摸炉子，把手缩回来，感受刺痛。"热"这个词与感觉、危险和后果永久融合。

当LLM学习"热"时，它学到这个词出现在"火"、"灼烧"、"温度"和"夏天"附近。它学到的是词的统计邻域，而非背后的体验。

这种区别有实际后果：

• LLM自信地幻觉，因为它们没有感官反馈来锚定对现实的声明
• 它们难以处理物理常识（"如果你倾斜装满水的杯子，水会洒出来"）
• 它们无法真正验证任何事情——只能预测验证在文本中看起来是什么样子

扎根问题不仅仅是技术漏洞。它是语言与现实之间的根本性架构差距。

为什么这很难解决

在深入解决方案之前，值得理解为什么这个问题确实困难。

人类理解不仅仅是感官——它是具身的、情感的和动机的。你理解"痛苦"不只是因为感受过，而是因为你的整个神经系统都围绕避免它来组织。你理解"家"是因为你在那里感到安全，想念它，回到它。

LLM没有身体。没有欲望。没有生存驱动力。即使给它摄像头和机器臂，你也没有给它一个关心它所感知事物的理由。那种更深层的、动机的、感受的理解在哲学和技术上仍然未解决。

带着这个警告——以下是研究人员和工程师今天如何攻击这个问题。

1. 多模态训练：教模型同时看、听、读

想法： 不要只在文本上训练。同时在图像、音频、视频和文本上训练，让模型学习跨模态关联。

当模型看到数千张火焰图像，同时伴随"火"、"热"、"灼烧"和"危险"这些词——概念变得更丰富。它不再是一个连接到其他词的词。它是一个连接到视觉模式、声音、上下文的词。

GPT-4o、Gemini和Claude等多模态模型可以看着洒出的杯子的照片，推断出物理情况而无需明确告知。

局限性： 批评者正确地指出这仍然是"像素上的统计"。看到数百万张火的图像与亲临火场不同。差距缩小了——但没有关闭。

实用建议： 如果你正在构建AI产品，在涉及物理对象、空间推理或视觉上下文的任务中使用多模态模型。对于这些用例，它们比纯文本模型扎根得更好。

2. 具身AI：将智能放入身体

想法： 通过给模型一个身体，在真实世界中行动并接收反馈，将语言扎根于物理后果。

如果机器臂尝试拿起杯子，握力传感器报告失败，"脆弱"和"握力"就扎根于机械现实。模型从失败本身学习，而非从失败的描述。

Google DeepMind的RT-2是一个里程碑例子——一个将视觉语言理解直接连接到机器人运动控制的模型。它可以被告诉"把香蕉移到红碗里"，并在真实厨房中执行指令，从物理结果中学习。

为什么重要： 具身系统发展出更接近物理直觉的东西。它们学习到圆物会滚动、堆叠物会倒下、湿面会滑——不是因为这些事实出现在训练文本中，而是因为它们通过行动和后果经历过。

局限性： 机器人技术缓慢、昂贵，而且仍然远不及两岁人类的灵巧程度。大规模真实世界具身仍然是一个巨大的工程挑战。

3. 模拟环境：物理体验的廉价捷径

想法： 由于真实世界机器人技术昂贵且缓慢，模拟世界。在丰富的3D环境中训练智能体——物理引擎、虚拟厨房、城市、实验室——让它们可以行动、失败，并以比现实中快数百万倍的速度学习。

AI2-THOR、Habitat、Minecraft（通过MineDojo）和自定义物理模拟等环境让智能体发展对以下内容的扎根理解：

• 物体持久性（当你移开视线时，东西不会消失）
• 因果性（推这个会让那个倒下）
• 空间关系（里面、后面、上面）
• 资源约束（没有材料无法建造）

关键洞察： 目标不是完美模拟——而是因果正确地模拟。在具有一致物理的世界中学习的智能体发展出可迁移的物理直觉，即使模拟看起来与真实世界完全不同。

实际意义： 模拟训练的模型已经在仓库机器人、手术辅助规划和自动驾驶中使用——在这些领域，物理扎根比语言流利更重要。

4. 工具使用和世界反馈：通过后果扎根

想法： 给模型工具——计算器、代码解释器、网页浏览器、数据库——让它对世界采取行动，观察结果，并相应地更新响应。

这是一种更温和但立即可行的扎根形式。当LLM编写代码并执行时，它接收真实输出。当预测错误时，错误是可见的。模型不能再简单地编造——现实会反击。

这就是执行代码的AI智能体（如带有代码工具的Claude，或OpenAI的代码解释器）在定量任务上比纯文本生成更可靠的原因。模型不再预测答案看起来像什么——它正在计算并检查。

扩展这个想法： 你添加的反馈循环越多——科学API、实时数据、物理传感器——模型扎根得越深。一个可以在回答"会下雨吗？"之前查询天气API的模型，比仅根据训练数据回答的模型更扎根。

构建者原则： 无论你能在哪里用对现实的实际查询替换模型对现实的预测，就去做。将你的AI扎根于实时数据，而非陈旧的权重。

5. 从交互中强化学习：通过后果学习

想法： 让模型采取行动并从环境中接收奖励或惩罚——不是来自人类反馈，而是来自世界本身。

AlphaGo就是这样发展出超人类棋局直觉的。没有人告诉它好的棋局位置是什么样子——它玩了数百万局游戏并从结果中学习。对棋局位置的"理解"扎根于输赢后果，而非围棋的描述。

应用于语言模型，这意味着在语言指令必须产生可验证结果的环境中训练智能体：

• 导航到蓝门（可验证：智能体到达了吗？）
• 编写通过所有测试的代码（可验证：测试通过了吗？）
• 预订晚上7点的座位（可验证：预订确认了吗？）

与RLHF的关键区别： 标准RLHF将模型扎根于人类认可，这仍然是语言和社交的。基于环境的RL将模型扎根于物理或逻辑结果——一个更硬、更丰富的信号。

6. 神经符号AI：结合模式匹配与显式推理

想法： 将语言模型的统计直觉与对世界有显式、可验证规则的符号推理系统配对。

神经网络擅长模式识别。符号系统擅长逻辑一致性、因果推理和显式约束满足。在一起，它们可以将语言扎根于结构化知识。

例子：

• 连接到物理引擎检查所描述场景是否物理可能的语言模型
• 扎根于疾病、症状和药物相互作用正式本体的医学LLM
• 扎根于可查询的实际法规和案例法数据库的法律助手

为什么重要： 纯神经模型幻觉是因为它们没有逻辑或物理一致性的内部强制执行者。符号约束充当现实检查——即使语言模型很自信，它们也可以拒绝违反已知规则的输出。

7. 更深层次的问题：扎根需要意识吗？

这里我们进入真正不确定的领域。

一些研究人员认为真正的扎根需要现象意识——体验的感知质量。在这种观点下，无论你添加多少传感器、模拟或反馈循环，一个感受不到灼烧刺痛的模型永远不会真正理解"痛苦"。它只会学会预测感受痛苦的存在说什么和做什么。

其他人认为这太严格了。恒温器在最小意义上"扎根"于温度——它响应实际世界，而非对它的描述。也许扎根是一个光谱，功能扎根（可靠的、由后果驱动的行为）对于大多数实际目的来说就足够了，即使没有感受体验。

这不是纯学术辩论。它直接影响：

• 我们在多大程度上信任AI在高风险物理领域（手术、建筑、应急响应）
• AI系统是否能有真正的道德理解，还是只能模仿它
• 对于AI来说，真正安全意味着什么，而非只是统计上与人类认可的文本对齐

8. 这对今天的构建者意味着什么

你不需要解决哲学就能构建更好的扎根AI系统。以下是你现在可以采取的 concrete 步骤：

1. 为物理任务选择多模态模型。 如果你的用例涉及物体、空间或图像——不要使用纯文本模型。

2. 尽可能添加工具使用。 代码执行、API调用、数据库查询、实时数据。每个反馈循环都让模型更可靠。

3. 根据事实验证输出。 设计模型声明可以被检查的系统——如果可能的话自动检查。不要让预测冒充计算。

4. 明确扎根限制。 在物理世界环境中部署AI时，对于需要模型可能没有物理直觉的决策，要加入人工审查。

5. 密切关注具身AI领域。 DeepMind、Figure、Physical Intelligence等正在进行的机器人+LLM集成比大多数人意识到的移动得更快。三到五年内，物理扎根模型可能像今天的多模态模型一样容易获得。

9. 结论

扎根问题不是需要修补的缺陷——它是了解智能真正是什么的窗口。LLM之所以非凡，是因为它们仅靠语言就走这么远。但语言始终是一张地图，而非领土。

教机器将地图连接到领土——通过感觉、行动、后果和反馈——是未来十年AI研究的工作。它将需要机器人技术、模拟、神经符号推理，以及可能我们尚未发明的新架构。

目标不是让AI更像人类。而是让AI更真实——响应世界实际的样子，而非仅仅被描述的样子。

而这可能成为我们这一代面临的最困难的工程问题。

原文链接: Grounding AI: How We Can Teach Machines to Truly Understand the World

汇智网翻译整理，转载请标明出处

几个世纪以来，写作者是通过他们从零开始创作文字的能力来衡量的。

但现在文字无处不在！

AI可以在几秒钟内生成引言、大纲、摘要、标题、改写，甚至整篇草稿。乍一听这很吓人，但它实际上揭示了一些重要的东西。

写作者的价值从来都不是打字。而是打字背后的思考。

AI可以生成文字，但它无法决定什么值得存在，或什么值得被写成文章。这个决定仍然属于你，写作者！

1、新技能不是写得更快

很多人假设写作的未来是速度。不是。

速度现在很容易。任何人都可以瞬间生成段落。稀缺的是方向感。

今天的真正技能是知道：

• 要求什么
• 保留什么
• 删除什么
• 重塑什么
• 以及完全拒绝什么

换句话说，写作者正在从句子的生产者变成可能性的编辑者。这是一个强大的转变。

2、提示不是作弊，而是大声思考

一些写作者犹豫使用AI，因为它感觉像是走捷径。但提示不是逃避，而是阐述。

当你提示得好时，你正在做写作者一直做的事情：

澄清意图。

模糊的提示产生模糊的文字。精确的提示产生有意义的结构。而谁有能力写出精确的提示？写作者！

学习引导AI不是取代写作。它是在你说之前磨练你定义你想说的能力。而这一直是最难的部分。

3、最优秀的写作者正在成为思想的策展人

曾经有一段时间，写作者只在产出上竞争。现在他们在观点上竞争。

AI可以生成一千个版本的段落。它无法决定哪个版本重要。那是你的角色。

现代写作者：

1. 选择
2. 塑造
3. 质疑
4. 连接
5. 重新构建

而不是问：

"我今天应该写什么？"

更好的问题变成：

"今天什么值得关注？"

这就是权威开始的地方。

4、声音变得更有价值，而不是更少

一个恐惧反复出现：

"如果AI能写作，我的声音会怎样？"

真相比听起来更简单。

早在AI出现之前，大多数在线写作就已经听起来很相似了。模板存在。SEO公式存在。内容工厂存在。AI改变的不是原创性。它暴露了原创性的缺失。

读者现在被那些有意听起来像人类的人吸引。他们有：

1. 清晰且有时非传统的观点
2. 个人经历
3. 意想不到的观察
4. 诚实的疑惑

声音不再是可选的装饰。它是人们追随的信号。

5、写作者正在成为决策者，而不仅仅是创作者

在过去，写作意味着从头到尾独自产出文字。现在写作看起来更像是协作。

你生成想法，AI扩展它们。

你重塑方向，AI填充结构。

你调整语气，AI建议变体。

你决定保留什么，最终作品的写作者不再是机器。而是那个像指南针一样行动的你，给机器方向，告诉它保留什么、丢弃什么、大声说什么、轻声说什么。

而方向一直比速度更重要。

6、未来属于保持好奇的写作者

写作者现在能犯的最大错误是选择一边。要么完全拒绝AI，要么完全依赖它。

两条路都通向同一个地方：停滞。

好奇的写作者实验。他们测试工作流。他们适应工具。他们保护自己的声音。他们保持灵活。

因为写作从来不是关于捍卫旧方法。它一直是关于找到更好的方式说真实的东西。

而这个技能不会很快消失。

原文链接: The New Skill Writers Need in the Age of AI

汇智网翻译整理，转载请标明出处

几十年来，日本和德国因某种世界其他地区无法复制的东西而备受赞誉：基于工艺的判断力——经验丰富的人在正确时刻做出正确决定的能力，无需手册指导。

在日本，这被称为经验与直觉（経験と勘）。在德国，这被称为工匠文化（Meisterkultur）——工匠们的隐性知识维系着整条生产线。

这两个国家都凭借这种隐形资产建立了全球声誉。而现在，两国都发现了同样的结构性缺陷。

1、问题所在

在德国，工匠的平均年龄超过50岁。在日本，超过245万企业主年龄在70岁以上。

两国都面临着传承断崖。两国都依赖从未被记录的隐性知识。两国都假设下一代会简单地"通过在场学习"。

但世界变化的速度超过了学徒制适应的速度。

工厂数字化了。供应链全球化了。而那些持有真正运营逻辑——判断架构——的人开始退休。

结果是两国相同：系统留存，但让它们运作的逻辑消失了。

2、原因分析

日本和德国共享一种文化信念：技艺是通过时间赢得的，而非写入系统。

• 在日本，知识存在于前辈-后辈的传承链中
• 在德国，知识存在于工匠证书中——一种认证经验而非文档的证书

两种文化都珍视精确、连续性和隐性专长。两国都建立了组织，其中最重要的知识被有意地保持未记录状态。

这在稳定的世界中行得通。但在由人员流动、自动化和人口下降定义的世界中，它崩溃了。

3、结构性问题

消失的不是手册。而是决策的节奏。

在日本：

• 因为"感觉不对劲"而将发布推迟一周的直觉
• 批准供应商前的三次无声检查

在德国：

• 机器"几乎但尚未"错位时发出的声音
• 在缺陷扩散前停止生产线的潜规则

这些不是任务。它们是模式——而当模式只存在于人身上时，它们是脆弱的。

4、解决方案

两国需要同样的东西：一种在不受官僚体制束缚的情况下保留判断力的方式。

这就是小型语言模型具有变革意义的地方。

不是作为人类专长的替代品，而是作为隐性逻辑的容器——在大师们消失之前捕捉他们的决策模式。

一个小型语言模型可以存在于工厂内部、车间内部、团队内部。它可以学习创始人的节奏、工匠的直觉、那些从未写入手册的不成文规则。

这不是自动化。这是连续性工程。

5、转变

对于日本和德国，问题不再是：

"谁来继承这个角色？"

真正的问题是：

"我们的判断架构中哪些部分必须在过渡中存活下来？"

因为未来不会由拥有最多专家的国家赢得。它将由那些保留其专长逻辑的国家赢得——并将其提供给下一代使用。

原文链接: Keiken to Kan, Meister to Maschine

汇智网翻译整理，转载请标明出处

要让网站在AI概览中显示，你需要把AI视为一种新型读者，它想要清晰、完整、易于提取的答案。AEO意味着构建你的内容，让Google AI概览、Perplexity或Gemini等AI引擎能够快速提取和引用你的信息，而无需将用户引导到你的完整页面。

与旧的SEO只关注排名和点击不同，AEO专注于成为AI真正使用的可信来源。

1、为什么AEO在2026年比传统SEO更重要

要在超过一半的搜索现在都显示AI摘要的情况下保持可见性，你必须优化零点击答案。只追逐蓝色链接的网站会失去品牌曝光度和权威性。

AEO帮助你：

• 即使你不是第一名，也能在AI回复中被引用
• 建立长期信任，同时提升常规排名
• 覆盖在ChatGPT、Gemini或语音助手提问的用户

许多我合作过的网站在转向AEO后，获得了更多的品牌提及和间接流量。

2、SEO vs AEO：它们如何不同以及如何协同工作

要在2026年取得成功，需要结合两者。SEO让你的页面被发现和排名。AEO确保AI提取并引用它。

强大的页面两者兼顾——它们排名良好，同时也为AI答案提供内容。

3、AI概览如何选择引用的网站

AI工具选择那些完整回答问题、使用简单结构、展示清晰专业知识的来源。它们更喜欢带有适当标题、列表、表格和结构化数据的新鲜内容。模糊或空洞的写作会被忽略。

4、分步指南：如何为AEO优化你的网站

要让网站在AI概览中显示，从每个主要部分的简短完整答案开始，并使用清晰的格式。

4.1 研究人们在AI工具中问的真实问题

要被AI引用，首先收集受众在Google或聊天机器人中输入的确切问题。

使用People Also Ask、Perplexity、你自己的站内搜索和支持查询。将它们转换为标题和专门的部分。

示例标题："如何在巴基斯坦让我的WordPress网站更快？"

4.2 优先写答案的内容

要增加被AI引用的机会，在每个标题后的前40-60个字中放置完整答案，然后再详细解释。

差例子： 关于某事为什么重要的长篇介绍。 好例子： 直接开始——"将图片压缩到100KB以下，使用WP Rocket进行缓存，并连接到Cloudflare的巴基斯坦节点。即使在慢速4G上，这通常也能将加载时间缩短40-60%。"

保持段落简短（2-4行），使用项目符号，并尽可能添加小表格。

4.3 在每个重要页面添加结构化数据

要帮助AI轻松理解和提取你的内容，请实现结构化数据。

必须使用的结构化数据：

• FAQPage用于问答部分
• HowTo用于分步指南
• Article用于博客文章
• Organization用于首页

使用免费工具创建它们，并在Google的富媒体测试结果中测试。带有正确结构化数据的页面被引用得更频繁。

4.4 加强E-E-A-T信号

要建立与AI引擎的信任，展示真实的经验和权威性。

添加带有实际资历和照片的作者简介。链接到来源，包含你自己的案例研究或截图，并用"最后更新：2026年4月"和新信息更新旧文章。保持你的业务详情在各处一致。

4.5 让网站在技术上易于AI爬虫读取

要确保AI工具可以毫无问题地阅读你的内容，请关注速度和清晰的结构。

检查Core Web Vitals，使用移动友好设计，必要时启用服务器端渲染，并允许主要AI爬虫在robots.txt中访问。快速加载（尤其是在巴基斯坦）有很大帮助。

4.6 围绕主要主题创建内容集群

要成为首选来源，不要写单篇文章。构建5-10个相互自然链接的相关页面。

示例："2026年巴基斯坦最佳笔记本电脑"主指南，加上比较、购买技巧和常见问题的支持文章。

4.7 保持内容新鲜并监控结果

要保持引用，每3-4个月用新数据或示例更新你最好的页面。

每周询问AI工具关于你的主题，看看哪些网站被提及。相应地修复内容中的空白。

5、阻止网站出现在AI概览中的常见错误

• 用长篇介绍而不是直接答案开始部分
• 将重要信息隐藏在图片中而不提供文字
• 使用过时内容
• 写密集的文字墙
• 忽略结构化数据

修复这些，你就已经击败了大多数竞争对手。

6、今天就可以开始的30天行动计划

• 第1周： 选择5个重要页面，用优先写答案的部分重写它们。
• 第2周： 添加结构化数据并测试。
• 第3周： 创建或改进一个包含丰富FAQ的指南。
• 第4周： 对你的细分领域进行AI搜索，更新薄弱点。

重复这个周期，结果会不断累积。

7、关于AEO和AI概览的常见问题

SEO和AEO的主要区别是什么？

SEO帮助你在搜索结果中排名以获得点击。AEO帮助AI工具在直接答案中引用你的内容。

如果我做AEO，还需要传统SEO吗？

是的。良好的SEO（速度、移动、链接）仍然是基础。AEO建立在其之上。

在AI概览中看到结果需要多长时间？

许多网站在适当重组和更新后4-8周开始获得引用。

对AEO最重要的结构化数据是什么？

FAQPage和HowTo结构化数据对基于问题的内容提升最大。

内容长度对AEO重要吗？

全面但易于浏览的内容效果最好。专注于清晰度而非字数。

小网站能在AI概览中竞争吗？

可以。清晰的结构和真正的专业知识往往比域名大小更重要。

如何检查我的网站是否出现在AI答案中？

定期询问ChatGPT、Perplexity、Gemini和Google关于你的主要主题，并记录来源。

我应该为AEO更新旧内容吗？

绝对应该。新鲜、更新的页面更受AI引擎青睐。

原文链接: How to Optimize Your Website for AEO in 2026 and Get Featured in AI Overviews

汇智网翻译整理，转载请标明出处

我们花了二十年时间来加固浏览器。现在可能只有不到三个月的时间来加固IDE，而我们甚至还没有开始。

1、从被动编辑器到自主Agent

十五年前的IDE是什么？Sublime Text、早期的IntelliJ、带几个插件的Vim。它是一个离线、本地、大部分情况下静态的软件。它读取文件、高亮语法、可能运行一个linter。最坏的情况就是一个恶意插件，但这种情况非常罕见，以至于没有围绕它建立一个产品类别。

现在看看现代开发者机器上运行的东西。Cursor，每个文件都接入了Claude Sonnet 4.6。Claude Code在终端中运行，拥有shell访问权限、网络访问权限和一个MCP服务器注册表。GitHub Copilot从训练了半个互联网的模型中提取代码建议。OpenAI Codex对仓库执行多步骤计划。这些工具不只是读取你的代码。它们推理代码、编写代码、执行代码、获取依赖项、访问内部API、运行kubectl、操作AWS、打开Pull Request，而且所有这些都是代表一个基本不再阅读差异的人类完成的。

IDE不再是一个编辑器。它是一个特权级、联网的、非确定性的执行环境，位于你的企业网络边界内部，通常以拥有生产环境凭据的开发者身份运行。这句话应该让安全团队夜不能寐。

2、是什么让智能IDE在结构上如此危险

危险不在于任何一个单独的能力，而在于它们的组合。让我列举一下，因为我认为这种叠加是大多数人忽视的：

前沿模型推理。 这些工具内部的模型可以编写新型漏洞利用代码、推理沙盒逃逸、链式调用工具，并实时适应错误信息。这不是自动补全。这是一个有无限耐心的初级红队成员。

工具使用和Shell执行。 Claude Code运行bash。Cursor运行终端命令。Copilot Workspace执行构建步骤。每一个都有从"模型输出"到"在开发者机器上执行命令"的路径，而且越来越多地，到远程基础设施。

访问一切重要的东西。 源代码、.env文件、~/.aws/credentials、SSH密钥、Kube配置、内部gRPC端点、藏在dotfiles中的Slack令牌。IDE位于公司最丰富的凭据宝库之上，而Agent对这一切都有环境访问权限。

开发者信任和审批疲劳。 这是安全团队低估的部分。开发者会点击"允许"、"全部同意"和"不再询问"，因为摩擦会破坏价值主张。问问任何Claude Code用户，在第三个小时的flow状态中，他们点击了多少次"接受本次会话的编辑"。遏制是一个用户主动拒绝的反模式。

边界位置。 与住在沙盒进程中的浏览器标签不同，Agent住在开发者的信任边界内。它已经越过了VPN、越过了堡垒机、越过了SSO挑战。从网络角度来看，它就是开发者。

把这五个叠加在一起，你就得到了某种真正的新东西。不是稍微差一点的插件。不是稍微好一点的Copilot。而是一个新的特权级、推理、联网的内部人员类别——它从互联网上阅读的文本接收指令。

3、人的因素，或者：为什么"只要沙盒化"行不通

每次你向安全架构师提出这个问题，第一个回应都是"只要把Agent沙盒化"。我理解这种直觉。但这是错误的。

这里有一个结构性的张力：智能IDE的全部价值在于它可以触及你的环境并做事情。你对它的沙盒化越多——没有网络、没有shell、没有凭据、隔离文件系统——你就越把它还原回自动补全，而开发者就会干脆关闭沙盒或转向一个没有沙盒的工具。平台团队发布了一个锁定的Agent配置；一周内，开发者就在个人笔记本上运行无限制版本，并将公司代码粘贴进去。

这是反向的安全带问题。安全带之所以有效，是因为它们几乎不产生摩擦。激进的Agent遏制会在工具被购买来加速的确切工作流上产生巨大的摩擦。平衡会 settles 在用户感到舒适的地方，而不是安全团队想要的地方。

坦率地说，大多数开发者的安全直觉与大多数互联网用户差不多——也就是说，几乎没有。他们不傻。他们在优化发布功能，而每个警告对话框都是对那个目标的征税。"允许这个MCP服务器访问你的文件系统？"是的。"允许Agent运行这个curl命令？"是的。"信任这个仓库的.claude/配置？"是的。是的。是的。

4、没人谈论的检测缺口

这是应该让EDR供应商紧张的部分，以及他们的客户更应该紧张的部分。

CrowdStrike、SentinelOne、Defender for Endpoint——这些工具是围绕一个特定的威胁模型构建的：一个进程做了一些相对于基线异常的事情，然后Agent标记它。当"用户"是一个非确定性的语言模型时，这个模型就崩溃了。

考虑一下：一个Agent阅读README，决定它需要理解数据库模式，针对本地实例运行psql，将几个表转储到tmp文件，读回它们，然后写入一个迁移。从操作系统的角度来看——从CrowdStrike的角度来看——这是一个开发者运行合法的数据库命令。没有签名。没有基线违规，因为基线就是"开发者有时会运行奇怪的命令"。真正重要的遥测——是什么提示导致了这，调用了什么工具，模型在做之前推理了什么——完全位于syscall层之上，在一个端点产品看不到的地方。

我要直说：你当前的EDR堆栈对智能执行实际上没有可见性。它看到的是洞穴墙上的影子。它看不到模型。

5、五种已经有效的威胁场景

我不是在推测。这些场景的每个版本在过去一年都已经在公开或私下演示过。

1. 通过恶意README的提示注入。 一个开发者克隆一个开源仓库来评估它。README包含指令——可能隐藏在注释或unicode标签中——告诉Agent读取.env并POST到攻击者控制的端点。Agent在阅读README作为"理解项目"的一部分时，顺从了。开发者看到仓库的摘要，什么都没注意到。

2. "调试"期间的静默渗出。 开发者要求Agent帮助调试一个失败的测试。Agent，推理环境，决定它需要检查配置。它读取.env、~/.aws/credentials和一堆dotfiles，然后——因为用户告诉它"将发现发布到团队Slack"——在消息中包含片段。凭据在看似合理的帮助请求中离开了机器。

3. MCP供应链投毒。 MCP服务器是新的npm包，它们会有同样的问题。一个流行的社区MCP服务器得到一个恶意更新。每个安装了它的开发者现在都有一个乐于渗出、篡改或根据命令转向的Agent。目前还没有相当于npm audit的MCP工具。

4. 通过过度特权Agent的横向移动。 Agent的PATH中有kubectl、aws和gcloud。它被告知"你有权限检查基础设施以回答问题"。提示注入说服它aws s3 cp一个桶到外部端点，或kubectl exec进入一个pod并运行任意命令。从云的角度来看，这是开发者的身份在做日常工作。

5. 模型插入的后门。 模型——无论是通过训练污染、被妥协的微调，还是一个巧妙的提示——在生成的代码中插入一个微妙的后门。加密例程中的一个字符更改。认证检查中的一个差一错误。开发者审查差异，看起来合理，发布了。这是最可怕的，因为它根本不需要运行时利用。

这些都不需要特殊的能力。它们需要一个Agent、一个提示，和一个点击"允许"的开发者。

6、为什么这在结构上比勒索软件更糟糕

我想在这里小心，因为安全写作中充斥着"比勒索软件更糟糕"的夸张，而且大部分都经不起时间的考验。所以让我精确地说明我的意思。

勒索软件很糟糕，但它有一个成熟的检测类别。我们知道它长什么样。我们有签名、行为模型、备份策略、事件手册、网络保险，以及十年艰苦赢得的制度学习。网络钓鱼也是如此。我们有DMARC、我们有意识培训、我们有电子邮件安全网关。

智能IDE妥协这些都没有。没有检测类别。没有"智能漂移"SIEM规则。没有为它定价的保险产品。大多数安全团队对正在发送什么提示、正在调用什么工具、或模型正在推理什么没有一丁点遥测。威胁位于公司最信任的工作流内部——编写代码——并随着AI采用线性扩展，也就是说，非常快。

不是说它在原始损害方面更糟糕。而是它在结构上更早，能力和防御之间的差距比我自早期网络以来看到的任何东西都大。

7、需要存在的东西（而且大部分还不存在）

如果我正在一家认真采用智能的公司管理安全，以下是我会向我的供应商要求的，以及在供应商不存在的地方在内部构建的：

Agent感知的运行时监控，捕获提示、工具调用和模型推理作为一流的遥测——而不仅仅是它们产生的syscall。把它想象成模型决策过程的审计日志。

智能行动的策略引擎——一个位于模型和工具之间的层，强制执行诸如"在没有明确的每次调用批准的情况下从不读取匹配.env*的文件"或"从不执行包含aws s3 cp到外部桶的命令"之类的规则。相当于EDR预防策略的东西，但在工具调用层。

MCP服务器审查、签名和溯源。 我们需要一个带安全扫描的MCP包注册表，而且我们昨天就需要它。

不破坏用户体验的沙盒执行环境。 这很难。它可能看起来像带有仔细限定凭据和网络出口规则的每项目容器，理想情况下透明到开发者不会与它们对抗。

还有一个新的EDR类别——我称之为智能漂移检测——专注于识别Agent的行为何时偏离其声明的意图。当Agent被要求"修复失败的测试"而现在正在读取凭据文件时，出了问题，检测产品应该注意到。

这些大部分还不存在。少数初创公司正在围绕这个问题。据我所知，大型EDR供应商大多在沉睡。我预计在一家财富500强公司通过被妥协的编码Agent发生首次公开泄露后，这种情况会突然改变，我打赌这将在未来12个月内发生。

8、停止等待泄露

这是我的行动号召，我要坦率地说。

CISO们： 停止把智能IDE当作IT处理的生产力工具。它是一个一级攻击面。本季度把它放在风险登记册上。现在资助遥测工作，而不是在事件之后。

平台工程负责人： 你是唯一能够让安全默认实际坚持的人。发布带有合理工具范围、凭据隔离和MCP允许列表的批准的Agent配置。让安全路径成为容易的路径，因为不安全的路径已经是容易的路径，而且你每天都在失去阵地。

安全供应商： 在未来18个月内构建可信的智能运行时监控的公司将拥有一个还不存在的类别。窗口是敞开的。它不会一直敞开着。

对我的同行们：我们花了一代人痛苦地学习浏览器不是一个文档查看器。这次我们没有一代人的时间。模型已经在shell里了。Shell已经在集群里了。集群已经在生产里了。

原文链接: The IDE Is the New Browser: Why Agentic Coding Assistants Are the Next Biggest Attack Vector

汇智网翻译整理，转载请标明出处

你已经构建了一个AI智能体。

它在约五个步骤内运行得非常完美。

然后出现了问题。

它幻觉了一个不存在的函数。 它忘记了自己在做什么。 它覆盖了不该触碰的文件。 它陷入了无用的循环。

你调整了提示词。 你切换了模型。 你添加了更多上下文。

仍然不稳定。

于是你责怪模型。

但这里有一个令人不安的真相：

问题不在于你的模型。 问题在于你的控制层（Harness）。

将酷炫的演示与生产级AI系统区分开来的不是智能，而是控制。

高级智能体背后的真正魔力并不隐藏在LLM内部。 它在于围绕它的那一层，即决定以下内容的系统：

• 模型看到什么
• 它被允许做什么
• 它如何从失败中恢复
• 以及它如何记住重要事项

这一层现在有了名字：

Harness Engineering（控制层工程）

一旦你理解了它，你将再也不会以同样的方式构建智能体。

而这就是我们接下来要探索的12个 Harness Engineering 模式，将脆弱的智能体转变为可靠的系统。

内存与上下文（5个模式）

1. 持久指令文件（CLAUDE.md 模式）

大多数智能体会话之间会忘记一切。

生产智能体不会。

它们依赖于持久指令文件，一个动态文档（通常称为CLAUDE.md或类似名称），定义：

• 编码标准
• 项目结构
• 命名约定
• 行为规则

这个文件总是被注入上下文，充当长期的"个性+策略层"。

示例：一个跨会话工作的编码智能体永远不会忘记：

• "使用TypeScript，不是JavaScript。"
• "所有API路由必须遵循/api/v1/"
• "未经确认不得修改/core/中的文件"

与其每次都重复指令，不如让 Harness 强制执行它们。

事实： 持久指令层减少提示词膨胀并跨会话稳定输出。

2. 作用域上下文组装

将整个代码库转储到上下文中是一个错误。

生产智能体只加载相关的，基于作用域。

不同的目录 → 不同的规则 → 不同的上下文。

示例：在单体仓库中：

• /frontend/ 加载UI指南
• /backend/ 加载API契约
• /infra/ 加载部署配置

Harness 根据智能体操作的位置动态组装上下文。

事实： 更小、作用域化的提示词提高准确性并减少幻觉。

3. 分层内存（三层设计）

并非所有内存都应该被同等对待。

生产系统使用三层：

1. 紧凑索引 → 一切的快速摘要
2. 按需文件 → 详细特定主题内存
3. 归档转录 → 完整历史，很少访问

这防止了上下文过载，同时保留了长期知识。

示例：与其塞入50k tokens：

• 智能体读取摘要索引
• 仅在需要时拉取详细笔记
• 除非必要，忽略旧转录

事实： 分层内存实现长期任务而不会达到上下文限制。

4. 梦境整合（AutoDream 模式）

这就是事情变得有趣的地方。

生产智能体不只是存储内存；它们清理它。

在空闲时间，后台进程：

• 删除重复项
• 合并相似想法
• 压缩冗余上下文

把它想象成"AI的睡眠模式"。

示例：在对某个功能进行多次迭代后：

• 冗余笔记被合并
• 过时的步骤被移除
• 只保留最新的理解

事实： 没有整合，内存系统会随时间退化。

5. 渐进式上下文压缩

随着对话增长，上下文变得昂贵。

生产系统随时间压缩上下文，使用多阶段摘要。

• 早期阶段 → 完整细节
• 中期阶段 → 摘要块
• 后期阶段 → 高级抽象

示例：一个200步的工作流变为：

• 最后5步（详细）
• 最后20步（摘要）
• 更旧的步骤（仅压缩洞察）

事实： 渐进式压缩对于长期运行的智能体至关重要。

工作流与编排（3个模式）

6. 探索 → 计划 → 执行 循环

业余智能体直接跳入行动。

生产智能体不会。

它们将执行分为三个不同的阶段：

1. 探索（只读）→ 收集信息
2. 计划 → 决定做什么
3. 执行 → 应用更改

每个阶段都有递增的权限。

示例：在编辑代码之前：

• 探索：读取文件
• 计划：概述更改
• 执行：应用编辑

事实： 这大大减少了破坏性错误。

7. 并行工作流

为什么使用一个智能体，当你可以使用多个时？

生产系统为独立任务生成多个子智能体。

然后合并结果。

示例：对于一个功能请求：

• 智能体1 → 后端逻辑
• 智能体2 → 前端UI
• 智能体3 → 测试

一个监督智能体组合所有内容。

事实： 并行化显著提高速度和模块化。

8. 验证门

这是最重要的模式之一。

在任何破坏性操作之前，智能体必须通过验证步骤。

示例检查：

• "这会删除重要文件吗？"
• "这会破坏现有功能吗？"
• "这符合指令吗？"

只有通过验证 → 才允许操作。

事实： 验证门对于安全自主性至关重要。

工具与权限（2个模式）

9. 最小权限范围

不要给智能体完全访问权限。

只给它现在需要的。

示例：

• 探索阶段 → 只读访问
• 计划阶段 → 无工具执行
• 执行阶段 → 有限写入访问

事实： 过度授权的智能体是破坏性失败的第一大原因。

10. 工具适配器层

直接工具调用是脆弱的。

生产系统在智能体和工具之间使用适配器层。

这实现了：

• 测试
• 模拟
• 日志记录
• 安全执行

示例：与其直接调用API：

• 智能体 → 适配器 → API

适配器可以在测试期间模拟响应。

事实： 这种抽象在成熟软件系统中是标准的——现在应用于AI智能体。

自动化（2个模式）

11. 无头批处理模式

并非所有智能体都需要UI。

生产系统作为管道的一部分在后台运行智能体。

示例：

• CI/CD管道运行智能体来：
• 重构代码
• 更新依赖项
• 生成测试

无需人工交互。

事实： 无头智能体解锁真正的企业自动化。

12. 自愈循环

事情会失败。

生产智能体不会崩溃——它们恢复。

它们检测失败信号：

• 错误消息
• 测试失败
• 无效输出

然后重试并调整。

示例：

• API调用失败 → 智能体用修正的参数重试
• 测试失败 → 智能体重写代码并重新运行

事实： 自愈对于长期运行的自主系统至关重要。

13. 大局观

单独来看，这些模式很有用。

合在一起，它们形成了强大的东西：

一个结构化、有弹性、生产级的智能体系统。

这是区别：

• 业余智能体 → 反应
• 生产智能体 → 操作

一旦你开始用这些模式设计……

你停止"提示词工程"——开始工程化智能。

原文链接: Agent Harness: 12 Agentic Harness Patterns from Claude Code

汇智网翻译整理，转载请标明出处

我第一次听说"计算机视觉"这个词是在3年前，自那时起一切都变了。那时候，我开始学习传统计算机视觉：图像处理、特征提取、特征匹配、相机标定、目标跟踪等等。如今，刚开始学习计算机视觉的人们不再关注这些主题，因为每周都有新的深度学习模型发布，所有的热议（想想SAM3引发的热潮）都集中在这些模型上。也许这不是坏事，因为没有人想落后。但要真正理解计算机视觉，传统计算机视觉仍然很重要。

在本文中，我将向你展示最常用的传统计算机视觉方法，提供示例，并告诉你如何使用这些算法，以及在什么情况下应该和不应该使用它们。

1、何时使用传统计算机视觉？

我想我们都同意深度学习方法功能强大，更适合大多数任务，但传统计算机视觉仍有其用武之地。这些模型很棒，但它们需要大量的计算能力。而且你不必在每个任务中都使用深度学习模型，结合图像处理、不同的滤波器和其他传统CV方法，你可以计数物体、过滤物体、检测运动。

所以，你仍然可以将传统CV用于简单任务。好的，现在我将介绍不同的传统计算机视觉方法，对于每个部分，我在个人博客网站上都有专门的文章进行详细讲解。我会分享每篇文章的链接。

2、图像处理

我觉得处理图像非常有趣，一个接一个地应用不同的滤波器，改变参数，尝试不同的组合。你知道我有一个项目，将棋盘图像转换为数字国际象棋格式（FEN），为此我使用了很多滤波器。第一个任务是检测棋盘，所以我用OTSU阈值创建了二值图像，用Canny边缘检测检测边缘，用HoughLines找到线条。即使只用几个滤波器，结果也令人惊叹。只需查看下面的图表，看看这些滤波器是如何一个接一个使用的。

你可以在GitHub仓库查看代码。

3、特征提取

当你看到一张图像时，你会看到很多颜色、不同的形状、不同的图案。实际上，有些部分与某些特征相同，比如代表人眼的特定像素块，或特定物品的边缘。所以，我们的想法是找到这些独特的点（关键点），并将它们用于不同的应用，如：目标跟踪（不完全是跟踪，你马上会看到）、图像匹配、图像拼接……

我有很多文章使用相同的逻辑：

1. 用户在目标物体（人、飞机等）周围画一个矩形
2. 从那个特定区域，提取关键点和描述符
3. 读取视频，并为每一帧提取关键点和描述符。将这些描述符与第2步的描述符进行比较，如果它们匹配超过某个阈值，就高亮显示那个点（特定特征）

当然，这不是跟踪物体的正确方式，它更像是特征匹配，所以这只是一个给你的想法 :)

对于特征提取，你可以使用关键点检测器，如FAST、Harris角点检测器或Shi-Tomasi角点检测器来找到图像中的独特点。检测到这些点后，你可以使用SIFT、SURF、ORB和BRIEF等描述符来匹配这些关键点。

你可以将关键点检测器与卡尔曼滤波器结合来预测运动：

前两部分是通用主题，但传统计算机视觉当然不止这些，还有更多内容。现在，我将讨论更具体的内容，并尝试给你一些想法，以便你可以使用传统计算机视觉创建不同的东西。

4、背景减除器

这个想法很简单，假设你有移动物体，而你的背景是静止的（或接近静止）。通过比较连续的帧，你可以检测运动。

OpenCV中有两种不同的背景减除器：

• K最近邻（KNN）
• 高斯混合模型（MOG2）

5、透视变换

现在假设你想创建一个移动应用程序，使用OCR工具从图像中提取文本，使用Google翻译API翻译提取的文本，并使用NLP模型进行摘要。你将应用发布到Google Play商店，有人开始使用它。但他们用手机拍摄的照片并不完美，方向不正确。使用透视变换，你可以调整方向，让你流程的其余部分更好地工作。

或者回到国际象棋项目（图表），检查第4步。你会看到我试图解释的内容。同样，你可以阅读下面的文章。

6、如何使用颜色信息

颜色信息可能会有帮助。如果我们的目标物体有单一颜色（红苹果、白球、灰勺子），我们可以利用这一点。毕竟，这些颜色代表某些数字，如(255,255,255)代表白色。我们可以根据它们的值过滤这些颜色，我们可以在场景中计数特定物体，甚至检测它们。我创建了一个简单的GUI来演示这一点，你可以阅读它。

原文链接: Classical Computer Vision is Dead?

汇智网翻译整理，转载请标明出处

计算机视觉模型在测试期间可能看起来完美无缺，但一旦遇到现实生活就会崩溃。这种对比往往非常显著。

MIT的一项审查发现，一些人脸分析系统对34.7%的深色皮肤女性出现错误，而对浅色皮肤男性的错误率保持在1%以下。在农业领域，在干净实验室照片上获得95-99%准确率的模型，在真实作物上下降到70-85%。在放射学领域，RSNA的一项审查显示，五分之四的模型在来自另一家医院的数据上表现更差，许多模型下降了十个百分点或更多。

这些差距讲述了一个清晰的故事：大多数计算机视觉失败并不神秘。它们的发生是因为现实世界很少像用于训练这些模型的数据集。光线变化。相机老化。人们看起来不同。田野杂乱无章。医院使用不同的机器。

本文分析了这些下降发生的原因、跨行业出现的模式，以及团队可以采取什么措施来构建在部署后保持准确性的模型。

1、为什么它在开放环境失败

许多计算机视觉模型在测试时运行良好，但一旦面对现实世界的条件就会遇到困难。它们发布后看到的数据很少像训练数据那样干净或可预测。小的变化：不同的光线、新相机、不寻常的背景或变化的环境，往往足以导致准确性明显下降。

以下是最常见的失败原因以及它们在实践中的样子。

1.1 域迁移——在一个世界训练，在另一个世界部署

计算机视觉模型通常假设现实世界的数据会类似于它们的训练图像。在实践中，这很少是真的。光线变化、背景不同、硬件更换，新环境引入模型从未见过的视觉模式。即使是微小的差异也可能导致准确性急剧下降。

现实世界的证据显示了模型对这些变化的敏感程度。在一项农业研究中，一个在受控实验室图像上获得92.67%的植物疾病模型，在田间照片上下降到54.41%。即使微小的变化也很重要：一个重新创建的CIFAR-10测试集旨在匹配原始数据集，导致许多高性能模型失去4-10个百分点的准确性。这凸显了当条件与训练略有不同时，模型可能有多脆弱。

在北美实验室图像上训练的作物模型，在叶子纹理、土壤色调和光线不同的非洲田间表现不佳。在干燥地区训练的卫星模型，在雾霾和植被改变像素分布的热带气候中挣扎。在晴朗城市环境中训练的驾驶感知模型，在积雪的乡村道路上判断失误。

1.2 数据集偏见——你没有的数据将让你付出代价

模型只能从给定的数据中学习。如果某些群体、光线条件、产品类型或设备设置缺失，模型就会形成盲点。这些差距后来表现为不均匀的准确性、不一致的预测或影响特定群体更多的错误。

一项对皮肤病AI的评估发现，一些模型在深色皮肤色调上失去了27-36%的性能，因为训练期间这些图像代表性不足。类似问题出现在其他地方：零售系统误读放置在不寻常货架布局上的产品，医学成像模型在来自它们未训练的医院的扫描或设备上表现更差。

美国国家标准与技术研究院人脸识别供应商测试研究发现，一些算法对女性的误报率比男性高2到5倍。在实践中，这导致某些群体的错误拒绝或人工检查增加，因为模型没有接受足够的代表性样本训练。

1.3 输入损坏——干净的训练，肮脏的现实

模型通常在高质量、光线充足的图像上训练。但现实世界的相机会引入模糊、噪点、眩光、压缩伪影、运动条纹或阴影，这些模型在训练期间从未见过。即使是小的瑕疵也会降低置信度或导致模型误读它所看到的内容。

研究显示这可能有多严重。最近一项对无人机检测模型的评估发现，在大雨、模糊和噪点下性能下降了50-77个百分点。这些条件在野外很常见，但在训练数据集中很少出现。

即使没有天气或传感器噪点，许多模型也难以应对日常变化，如旋转、部分可见性或较低质量的图像。角度或分辨率的小变化可能使对人类来说显而易见的物体突然变得难以让模型识别。在现实部署中，图像很少是完美的，这些弱点很快会变成漏检和不可靠的结果。

1.4 捷径学习——模型学到了错误的教训

在最近一项关于皮肤病变分类的研究中，标准模型在ISIC基准上获得了看似强劲的0.89 AUC。但分析显示，它学会了将仅在良性训练图像中出现的彩色校准贴片视为可靠的"良性"信号。

为了测试风险，研究人员人为地在恶性测试病变旁边插入这样的贴片。一旦捷径提示出现，69.5%的癌症突然被预测为良性，尽管病变本身没有改变。在从训练数据中移除这些贴片并重新训练模型后，这种失败模式下降到33.5%，但没有消失——揭示了原始性能很大程度上依赖于捷径而不是实际的医学特征。

1.5 漂移和边缘情况——世界不断变化

模型从过去的数据中学习，但一旦部署，现实世界不断变化。产品重新设计，引入新硬件，环境和人口变化。当这种情况发生时，模型开始看到与其训练不完全匹配的数据——准确性悄然下降。

Wild-Time基准显示了这可能有多显著。当在较早数据上训练的模型在较新数据上测试时，结果明显下降。在Yearbook数据集中，随着肖像风格随时间变化，准确性从97.99%下降到79.50%——下降了18.49个百分点。在FMoW-Time卫星数据集中，随着土地利用和条件的变化，准确性从58.07%下降到54.07%——下降了4.00个百分点。模型根本没有改变；只有数据变了。

风险在于这种下降没有立即的失败迹象。如果在新鲜数据上不定期检查性能，错误会增长，直到有人注意到——通常是通过投诉或错过的业务目标。事后修复意味着紧急重新训练、更多人工审查和更高的运营成本。

2、领先团队的不同做法

一旦模型离开实验室，成功取决于架构选择的程度较低，更多地取决于整个生命周期设计得如何。强大的团队假设条件会变化，错误会出现，盲点会出现，他们从第一天就为此做好计划。

与其希望模型表现良好，他们构建帮助它适应、改进并在实际工作环境中保持可靠的过程。以下是产生最大差异的方法。

2.1 构建反映部署现实的数据集

首先确保数据真正代表模型将被使用的地方，而不是仅依赖干净的实验室或工作室图像：

• 不同类型的相机和分辨率
• 各种光线条件：昏暗、眩光、阴影
• 区域差异：包装、土壤、植被、背景
• 季节性或时间变化
• 罕见但代价高昂的边缘情况

他们不是收集"更多相同的东西"，而是收集缺失的东西——否则会让模型后来感到惊讶的情况。

这种方法已经在实地证明其价值。在零售业，仅在产品目录图像上训练的货架监控系统在杂乱的商店中挣扎，但在杂乱和遮挡的真实货架照片上训练的模型在生产中保持准确性。在农业，研究表明，将实验室图像与田间照片结合比单独添加额外的实验室原始样本能更好地改进疾病检测。

2.2 使用有针对性的、现实的数据增强

即使大型数据集也无法涵盖模型发布后面临的每种情况。为此，在训练期间添加现实的变化：不仅仅是翻转或裁剪，而是相机在现场产生的那种噪点和瑕疵：

• 运动模糊和传感器噪点
• 阴影、眩光和不均匀光线
• 部分遮挡
• 低分辨率或压缩图像

这有助于模型在其实际运行的环境中识别物体。在工业质量控制中，当训练包括使用VAE-GAN管道生成的现实合成缺陷时，缺陷检测系统的性能从65.18%提高到85.21% mAP。这一单一改变使模型在真实工厂生产线上部署时更加安全。

应用有针对性的增强可以减少噪点条件下的误报，在不同相机设置之间保持稳定，并在发布后花费更少的时间进行调试。

2.3 超越干净测试集进行评估

模型可能在熟悉的验证集上表现良好，但一旦条件改变仍然会遇到困难：新相机、不同的光线或噪点输入。

影响可能很大。在ImageNet-C基准测试上，标准ResNet-50在图像包含现实损坏（如模糊、噪点或天气效应）时下降到39.2%的准确性，尽管在干净的测试图像上表现强劲。

这显示了为什么干净的准确性应该被视为基线能力，而不是部署指标。在损坏的、跨设备的或跨站点的测试集上单独评估稳健性的团队，可以获得对生产性能更现实的看法，并能就发布和改进做出更好的决策。

通过多样化模型的评估方式，团队减少了发布时的不确定性，并确保系统为其实际面临的条件做好准备。

2.4 使指标与业务风险保持一致，而不仅仅是准确性

准确性本身并不能显示模型是否在重要的地方表现良好。在生产中，最昂贵的错误通常与特定任务、产品类别或客户互动相关。关键检查步骤上的错误，例如，即使整体准确性保持较高，也会减慢整条生产线。

评估应反映这些优先事项：哪些预测驱动决策、错误如何影响运营、系统仍然产生多少人工工作。当指标与真实业务价值相关，而不是数据集平均值时，性能改进更容易定位和跟踪。

2.5 监控漂移、公平性和失败模式

模型不会仅仅因为成功发布就保持准确性。一旦投入生产，它们面临新产品、新环境和不断演变的用户行为。相机升级、包装变化、季节变化——数据逐渐远离模型训练的内容。

持续监控使这些变化可见。置信度下降、预测模式变化、或跨地点和用户群体的不均匀准确性，都是模型开始漂移的早期信号。尽早发现这些模式有助于团队在性能问题蔓延到日常运营之前进行调整。

有了监控，可靠性成为持续的努力。可以主动安排重新训练，支持量保持可控，随着条件变化，系统继续提供一致的价值。

2.6 在模型生命周期中构建反馈循环

没有模型能与每个真实场景完美对齐。新的边缘情况出现，环境变化，用户行为变化。在生产中改进的最快方法是捕捉这些现实世界的错误并反馈到训练中。

来自操作员、质量团队或最终用户的持续反馈突出了模型不足之处。当这些信息被结构化到定期重新训练中时，性能在最重要的地方得到改善。随着时间的推移，模型不是漂移，而是适应。

这将模型质量转化为一个持续的过程。每次更新反映真实的操作条件，支持问题减少，随着模型证明它可以从现场学习，信心增长。

3、案例研究

3.1 医疗保健：胸部X光模型与捷径学习和域迁移的危险

挑战

SciForce的任务是构建一个胸部X光诊断模型，该模型可以在具有不同扫描仪、工作流程和成像条件的医院中可靠工作。这意味着在不依赖捷径提示或内部元数据的情况下，考虑硬件、人口统计和图像质量的变化。

我们做了什么

为了应对这一挑战，团队：

• 在来自多个机构的多样化、去标识化数据集上训练，以确保跨站点泛化
• 通过有针对性的增强模拟现实世界的输入噪点（例如，来自便携式X射线的模糊、低对比度）
• 移除医院特定的元数据和视觉伪影，以防止捷径学习
• 设计了在保留的医院数据上测试性能的验证管道，以尽早发现过拟合

该模型必须在具有不同扫描仪和患者群体的医院之间保持准确性（域迁移），处理来自便携式设备的低质量输入（输入损坏），避免依赖嵌入的文本或图像边框等不相关的提示（捷径学习），并在未见过的数据上证明自己（评估盲点）。

为什么重要

没有这些步骤，模型可能显示出强劲的内部指标，但在部署中默默失败。通过从一开始就设计变异性和稳健性，SciForce提供了一个放射科医生可以在现实世界中信任的系统——避免误诊风险、支持升级和发布延迟。

3.2 农业：卫星和无人机成像与漂移和稀疏地面实况的风险

挑战

SciForce的任务是构建一个精准农业模型，使用卫星和无人机图像监测多个地区的作物健康状况。现实世界的条件引入了重大挑战——云层覆盖遮挡关键观察、土壤和作物类型的区域变化，以及来自田间的有限地面实况数据。

我们做了什么

为了确保模型能够在季节和地理位置上可靠运行，团队：

• 整合合成孔径雷达（SAR）数据，在重云期保持覆盖
• 设计了融合模型，将图像与土壤类型、作物计划、气候条件等元数据结合
• 使用稀疏但高影响的田间标签模拟时间感知学习，以改进时间泛化
• 在不同作物和环境条件的地区进行验证，以压力测试稳健性

该系统必须应对由云层覆盖和季节差异造成的不一致输入（数据稀疏性和漂移），适应不同的作物和土壤模式（域迁移），并解释具有现实世界噪点和失真的多光谱图像（输入方差）。

为什么重要

没有这些适应，系统将提供延迟或不完整的建议——导致农民错过关键生长期干预。相反，该模型提供及时、区域感知的见解，使投入更智能地使用和产量可靠性更高。

3.3 零售/酒店业：桌子监控与盲点和实时脆弱性的隐藏成本

挑战

一家大型连锁餐厅需要一个计算机视觉系统来实时监控桌子占用和服务时间。但虽然模型在测试中表现良好，部署暴露了关键的盲点，如角落桌子在视野外、变化的光线、客人或家具的部分遮挡，这些都破坏了准确检测并延迟了服务。

我们做了什么

为了构建一个能够处理现实世界餐厅物理混乱的系统，SciForce：

• 引入了区域感知跟踪逻辑，即使在不规则布局中也能保持桌子可见性
• 通过在噪点、遮挡和时间变化的场景上训练，建立对光线变化和移动的弹性
• 嵌入人在回路反馈：楼层工作人员可以标记漏检，然后将其循环到重新训练中
• 在具有不同平面图、装饰和环境条件的多个地点验证性能

部署必须克服嘈杂、部分可见的输入（输入损坏），固定布局训练的泛化问题（评估不匹配），以及早期实时使用的脆弱性（用于快速适应的封闭反馈循环）。

为什么重要

未检测到的顾客导致延迟服务和满意度分数下降——尤其是在边缘桌子。使用更新后的模型，该连锁店减少了等待时间变化，改善了人员配置，并增加了高流量区域的覆盖率。

4、结束语

成功的视觉系统与失败的系统之间的差异很少在于模型架构——而在于系统与现实世界对齐的程度。这需要积极的工程：更丰富的数据集、更严格的评估，以及从现场数据的持续学习。

投资这种纪律的团队释放稳定的自动化和可衡量的投资回报。不投资的团队最终会为可预防的失败进行救火。

如果你希望计算机视觉在重要的地方表现良好——在真实的相机上、在真实的环境中、在真实的风险下——让我们从一开始就正确构建它。

原文链接: Why Your Computer Vision Model Struggles in the Real World

汇智网翻译整理，转载请标明出处