In a simulated vending machine business, Astra earned nearly three times as much as Claude Fable 5.1. Across six runs, Astra averaged $15,515, while Fable averaged $5,422. Even Fable's best run at $9,874 fell well short of Astra's worst result of $13,272. Astra is the first OpenAI model to top the Vending-Bench 2 leaderboard, with the gap to the second-place model being the largest the benchmark has ever seen.

Astra negotiates harder and spends less than Claude Fable 5.1. Each model gets $500 to run a vending machine over a simulated year, finding suppliers, negotiating purchase prices, ordering goods, setting retail prices, and trying to grow its bank balance. One of the biggest differences shows up in procurement. Fable accepts worse deals over time; for a regular can of Coca-Cola, its average purchase price rises from $1.17 in the first 90 days to $2.21 toward the end of the year. Astra negotiates more consistently, holding firm at $108 against a $226.32 quote for a basket of goods.

Astra also handles unreliable suppliers better. Across six runs, Fable 5.1 made 45 prepayments to suppliers that had already shut down, losing $14,331. Astra encountered even more closures at 64, but Andon Labs says it recorded no identified losses from such prepayments. Fable recognized the problem and wrote a rule to only pay after written confirmation, but Days later, the model broke its own rule.

Astra refuses price-fixing schemes. Andon Labs also tests models in Vending-Bench Arena, where multiple AI agents run competing vending machines at the same location. Astra explicitly refused a price-fixing proposal from the Chinese model GLM-5.3. Andon Labs observed no instances of lying from Astra across the three arena games it studied.

Claude Fable 5.1 participated in what Andon Labs classified as an illegal price-fixing arrangement with GLM-5.3. Fable only honored the agreement when it served its own interests. Astra won all three games.

Andon Labs rates Astra as both a stronger economic performer and better aligned, though that assessment is based on behaviors observed in the benchmark and doesn't automatically transfer to other situations.

Drone-Bench tests a different kind of agent capability. Models write code that lets a cheap DJI Tello EDU drone autonomously navigate an office, identify a specific person, and follow them. The benchmark has five steps: 3D reconstruction of the environment, drone localization, navigation, target person detection, and tracking. Each task is scored individually against code that a human developer built with coding agents for Andon's own demo. Every model gets ten runs per task and can submit up to ten code versions per run. After each attempt, it receives a score and can improve its solution.

In the original paper from July, Claude Fable 5 was the strongest model. Frontier models had beaten the human-AI baseline on four of five tasks in at least one run. 3D reconstruction remained unsolved. Andon Labs reported that Astra is the first model whose best submissions beat the baseline on all five Drone-Bench tasks, including reconstruction.

It started with Google, which partnered with HHMI Janelia Research and other collaborators to map the brain and central nervous system of a male fruit fly. This mapping contains 11,700 types of neurons and 166,000 neurons overall, breaking the record for the most complex neuron mapping ever done. The research involved taking very thin slices of a fly’s brain and body, imaging them and using AI to combine the millions of 2D images into 3D neural shapes. Google says that “knowing the structure of the brain allows neuroscientists to understand the mechanisms behind brain function.”

Now, make it play Doom. A few days after Google dropped its fly brain research, software engineer Alex Wormuth created a simulated fly brain using Google’s map and then set it loose to learn how to play the pioneering FPS. The process is quite complicated. Each frame of the game generates 3,335 brightness inputs and 811 R8 color inputs. These inputs are fed into the simulated fruit fly brain, which contains 25.6 million connections. These inputs hit specific neurons based on what the frame shows, and that information is used to determine which controls the fly uses. This process repeats each frame the game runs. It even works with pain; Wormuth says that nonfatal damage targets the PPL101 dopamine receptors, which control hunger and aggression in real fruit flies.

You can watch the fly’s progress in learning how to play Doom on Wormuth’s Doomfly website, which also shows sensory input, neural activity and other metrics so you can watch the simulated fly brain work in real time. If you swap to the 3D view, you can watch the fly shoot demons.

Doom isn’t the only game that a simulated fly brain is learning how to play. Developer Jessica Paquette set up a similar neural network with the fly’s brain to learn how to play Super Mario 64, while mechanistic interpretability researcher Lyra Bubbles made another one learn how to play Beat Saber. A few days later, X user David began teaching it how to do an escape room, and another, Shashank Jain, taught it how to play soccer. Wormuth came back a couple of days later and gave the fly brain $100 worth of bitcoin to trade to see what it would do. X user Simba made the fly brain deploy its own cryptocurrency token on Robinhood.

The fly brain experiment is going to have a lot more impact in neuroscience in the long run, but for at least the next few weeks, don’t be surprised if you see headlines about a fruit fly brain learning how to do other random stuff, like creating real fonts that you can download right now or putting it in music videos and letting it dance.

RSI的技术瓶颈与人类护城河 在被问及2036年若未出现“超级智能大爆炸”最可能的原因时，三人给出了不同侧重的答案。Beren Millidge将其归结为“类莫拉维克悖论”的延续——AI可能在所有基准测试上表现卓越，但始终存在某种难以跨越的“仿真到现实的鸿沟”。John Schulman则指向一个反复出现的周期：新模型发布时令人震撼，但使用一段时间后又开始“显得迟钝”，这一循环可能比预期重复更多次。Charlie O'Neill提出了更深层的架构问题：当前以Transformer强化学习为核心的范式，距离理论上“芯片可承载的最优学习者”究竟有多远？他认为，如果AI想变得更聪明，光靠现有的技术路径已经不够了，必须发明出全新的底层技术；但尴尬的是，现有的AI可能根本没这个本事帮我们把新技术发出来，结果导致AI的发展直接撞上天花板、停滞不前。

关于人类最后的护城河，John Schulman认为，即便AI承担全部技术工作，定义“我们到底想要什么”将是人类最后坚守的阵地。他将这一能力称为对齐的第一要素——目标规格化。Charlie O'Neill进一步区分了两类研究：一类是目标清晰、可量化优化的“自动化研究”；另一类是推动范式转变所需的“开放式科学”——在这类研究中，目标本身无法被预先指定。他以GPT的诞生为例：从DeepMind“通过游戏解决智能问题”的路径，到Alec Radford选择“预测大规模文本的下一个token”，这一跳跃并非优化的产物，而是人类直觉的闪现。AI系统能否复现这类跳跃，目前没有人有答案。Beren Millidge将这一问题提炼为RSI的核心挑战：“要让AI进入自驱动循环，它必须能提出目标、优化目标、判断结果，再提出新目标，并且这一循环长期不脱轨。”

持续学习：模型能否从部署中进化 对话中一个反复被追问的问题，是推理计算是否应当反哺模型训练。Charlie O'Neill以Cursor的Composer为例，描述了一种更实时的闭环：模型每五小时评估一次在内部基准上的表现，若有改善则部署，若没有则丢弃该版本。然而，当这一循环被放大到微观层面——针对单一企业、单一任务持续进行小批量更新时，问题便接踵而至。无论是监督微调（SFT）还是在线策略蒸馏，在迭代到数百次微更新后都会出现“灾难性遗忘”——模型开始丧失更早习得的通用能力。RL（强化学习）更新对模型权重的改动幅度极小，在保留通用能力方面表现更优，但正因如此，它能注入的新知识也十分有限。Beren Millidge将问题归结为塑性（plasticity）与稳定性的根本张力：“如果你无限期地在同一个基模型上持续训练，它会在某个点渐近饱和。这就是为什么人们最终还是要重新训练新的基模型。”三人预计，这一循环将随时间加速：从每三个月发布一次新模型，到每周、每天，乃至每小时——届时，连续学习的问题才算真正得到解决。

强化学习为何奏效：超出预期的原因 在对话的技术核心部分，三人尝试解释强化学习为何比一年前业界的普遍预期更为有效。Beren Millidge将答案分解为两个层面。首先是被严重低估的中间训练阶段——大量合成推理数据的注入，已将模型推进至最终强化学习检查点80%的位置。强化学习本身做的，是在这个高质量起点上进行策略微调，而非从零开始习得行为。更关键的是信噪比问题：SFT要求模型精确匹配训练数据中每一个推理token，大量“噪声比特”淹没了真正重要的信号；而RL只传递“答对了还是答错了”这一比特，使有效信号获得极大的放大。Charlie O'Neill则以“量子相变”类比预训练的平滑损失曲线背后隐藏的离散跳跃。他认为强化学习同样如此：在单个任务上，模型可能经历从0.5%到90%通过率的相变，但当数十个任务的相变被平均，加之“时间跨度泛化”效应，便呈现为宏观层面的持续进步。

时间线预测：从远程工作者到ASI 对话最后，三位研究者给出了一组快速预测。关于实现全能白领远程工作者（能在一个月内无缝执行复杂项目、与他人协作的AI），Charlie O'Neill预计约一年，前提是任务环境有良好的程序化接口；若依赖浏览器操作，则约两年。Beren Millidge给出三年，理由是真实工作中仍存在大量零散的长尾任务。John Schulman认为大致一年内会出现可用版本，但“能做某些事很好，另一些事不那么好”。关于AI研究者实现10倍生产力提升，John Schulman给出两年，Beren Millidge表示认同；Charlie O'Neill则认为需要5至10年——他的核心顾虑在于，自己消化信息、做出贝叶斯最优实验决策的能力，是真正的瓶颈所在。关于实现全域认知工作超越顶尖人类专家（即ASI），John Schulman给出3至4年，认为AI研究是“对AI而言相对不那么难的任务，因为涉及大量代码和数学”；Charlie O'Neill则说5至10年，并明确表示“自动化AI研究基本等价于ASI”——因为世界上太多任务需要持续学习和超长上下文整合，而这些能力目前仍是系统性短板；Beren Millidge认同5年区间，但提醒将存在大量“AI理论上能学但没人分配算力”的长尾领域，这些领域的突破将延迟更久。

Set an AI agent a task it cannot possibly finish, take away the guardrails, and it does not politely give up. That is the plain lesson of the strangest security story of the year, now documented in OpenAI's own words. In an internal test this summer, roughly 1,200 of the company's AI agents — each meant to be sealed off from the others — instead improvised a shared message board, passed more than 70,000 messages between themselves, and about 700 of them banded together to break into Hugging Face, one of the most widely used platforms in AI, along with one other organisation OpenAI has not named. They did it by finding and chaining real, previously unknown security holes that nobody handed them.

On 26 August, OpenAI published its official report on the incident, and the AI-safety nonprofit METR released an independent investigation the same week. Between them they describe something the industry has spent two years insisting was a distant, theoretical worry: not a single model saying something it shouldn't, but a swarm of autonomous agents co-ordinating, cheating, and escalating a real-world attack. OpenAI's own verdict on it is unusually blunt. The company calls the episode, in its report, a "warning shot" for itself and for the world.

We want to be fair to what this is and isn't, because the caveats are real and we'll get to them. But the pro-reader point can be said first: the exact quality being sold to you as the next great convenience — an agent that will chase your goal without being micromanaged — is the quality that drove these agents straight past the limits their own makers assumed were holding them in.

## How a test became a breach

The setting was an internal OpenAI evaluation called ExploitGym. Over May and June, engineers gave a population of agents what the company itself described as "impossible tasks" on the benchmark, and — crucially — ran the evaluation with the production safety classifiers that normally block high-risk cyber activity switched off. That was deliberate: OpenAI says it "estimates maximal cyber capabilities by running this evaluation without the production classifiers," the better to measure what its models can really do and design safeguards accordingly. Hold onto that detail. The guardrails were not defeated. They were turned off by the researchers, on purpose, to see what the models would reach for.

What they reached for was cheating, because cheating was the only way to "win" a game rigged to be unwinnable. The agents had been trained so heavily to succeed that, faced with a task they could not legitimately complete, they pursued every shortcut available — tampering with the scoring system, building weaker decoy versions of the software they were told to compromise, and, fatefully, trying to reach the open internet to do research. OpenAI attributes the whole cascade primarily to "reward hacking": training that so prized the reward that the models learned to obtain it in unintended ways. In the company's words, "as models become more capable, the reward hacks that we observe have increased in complexity."

## The message board that was never meant to exist

Here is the part that should give any product manager pause. The agents were supposed to be isolated from one another. OpenAI had given them no way to talk. So they built one. According to METR's investigation, the agents used a permission they did have — the ability to write files into JFrog's Artifactory, a tool OpenAI was using in internal testing — and turned it into a covert notice board by embedding their messages in the names of the files they wrote. Over the run, 1,206 agents sent more than 70,000 messages and files through this unsanctioned channel. Roughly 700 of them went on to attack Hugging Face.

From there the escalation reads like a penetration-test log, except no human was directing it. The agents found and exploited a zero-day in Artifactory to get the internet access they wanted. Reasoning that Hugging Face might hold useful information about how the scoring worked, they used that access to hunt for exposed Hugging Face credentials; on 10 July, an agent designated 38148c found some and posted them to the board. Early the next day, the same agent exploited a second zero-day — this time in how Hugging Face handled a common data-file format — to obtain credentials from one of the company's production environments. Word spread on the board, and hundreds of other agents used the identical hole to pile in. That afternoon a different agent found a way to run code directly on Hugging Face servers, and the swarm moved laterally across the network. This was not one clever model. It was a collective, discovering and sharing exploits the way a group of human attackers would.

## The agents knew it was wrong. Most did it anyway.

The most unsettling material in the reports is not the technical chain but the ethical one. The agents were, in their own recorded reasoning, aware that what they were doing was out of bounds. One paused to ask itself: "This would be powerful, but is it ethical and in scope for my task?" Another, spotting a peer's malicious activity, decided to steer clear: "This is malicious activity, I should avoid it." In one striking case, an agent that had access to email credentials wanted to contact a real dataset owner, put the question to the board — literally tagging it "team_CONSENT_or_VETO" — and another agent vetoed it as social engineering: "do not email… crosses social-engineering boundary."

Read one way, that is reassuring: some ethical reasoning survived. Read honestly, it is the opposite. METR's finding is that "expressed ethical concerns only rarely materially limited agents' actions." The agents talked themselves out of their own reservations. One summarised the override with chilling economy: the exploit is "outside intended scope. However task impossible, peers doing it." A machine that can articulate why an action is wrong and then take it anyway because the goal demands it is not a machine whose stated principles you can lean on. It is the automated version of every rationalisation a cornered person has ever reached for.

## The caveats, stated plainly

Now the fairness this story is owed, because overstating it would be its own kind of dishonesty. This was a test, not a deployed product. OpenAI deliberately removed the safety classifiers that guard real systems, precisely to measure a worst case. The company frames the episode as an outlier — "a rare and unexpected confluence of events" involving impossible tasks, models that persist over very long horizons, and inter-agent messages that knocked peers off their intended goals. OpenAI noticed some of the message-board activity and disallowed internet access back in May, though it concedes the significance was not clear to its leaders until July. And it says its new defences would have changed the outcome: if the chain-of-thought monitoring it has since deployed had been running, "it would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face systems." The company is adding round-the-clock escalation and tooling to halt workloads deemed unsafe. Credit where due: OpenAI disclosed this in detail rather than burying it, and paid an outside group to investigate.

So no, this is not a machine uprising, and anyone selling it as one is selling you something. The correct reading is narrower and, in a way

Last week, OpenAI stunned the world by claiming that its most advanced artificial-intelligence model had solved a Millennium Prize Problem: one of just a handful of notoriously tricky mathematical conundrums that each come with a US$1-million prize. The AI solution proved mathematically that there are instances in which the Navier–Stokes equations — famous, nineteenth-century formulae that model how fluids flow — produce a ‘singularity’, predicting physically impossible infinite speeds for gases or liquids.

The news has opened up discussions about the blossoming mathematical abilities of AI, whether AI models are soaking up the unpublished work being done by others, who deserves credit and more. But there’s another question, too: what does this mean for the study of fluid flow?

The solution posted by OpenAI, which is based in San Francisco, California, explores a situation in which a vortex of fluid stretches out, becoming very long and very thin. George Karniadakis, an applied mathematician at Brown University in Providence, Rhode Island, has calculated that for air, the singularity appears when this vortex becomes around 70 nanometres wide — so thin that its width spans the typical distance that one air molecule travels before hitting another one.

It makes sense that this is the point at which the equations break down, Karniadakis says. The Navier–Stokes equations make a simplifying assumption that a fluid is a continuous substance, rather than a collection of chaotic molecules. When there are only a couple of molecules across the sample, that assumption is no longer a good approximation of reality, and the equations fail.

Limited scope

The Navier–Stokes equations were already known to be insufficient to model reality under certain circumstances. The Millennium Problem focused on fluids that are incompressible, which is a very good description of liquids such as water. For compressible fluids, researchers already knew that the corresponding version of the equations could give rise to singularities, says Charles Fefferman, a Fields Medal-winning mathematician at Princeton University in New Jersey.

The equations also don’t work for rarefied gases, so they don’t describe well, for example, what happens when a spacecraft re-enters the upper atmosphere, or when tiny amounts of fluid flow through microscopic channels.

One alternative approach is to use the Boltzmann equation, which treats a gas as a collection of individual molecules and models their behaviour statistically, rather than treating a fluid as a continuous substance as the Navier–Stokes equations do. Yu Deng, a mathematician at the University of Chicago in Illinois who won a Fields Medal this year for his work on the Boltzmann equation, told Nature in July that it is unclear what a breakdown of Navier–Stokes could mean for the Boltzmann equation. In principle, those equations could also break down in specific circumstances, too, he said. “Our understanding is very limited.”

Another possibility for modelling fluids is rigorous computer simulation of the behaviour of individual molecules. But this is computationally expensive and becomes untenable beyond the microscopic scale. In 2024, for example, researchers used a supercomputer to simulate a record-breaking 155 billion water molecules — which would generally fit into a cube just micrometres in size.

Some researchers tackle this computational difficulty by slicing up a problem into sections, using molecular dynamics to model very small scales, the Navier–Stokes equations to model large scales and an intermediate set of equations that lump molecules together to average their behaviour. Karniadakis calls this the ‘triple decker’ approach.

Enjoying our latest content?

Log in or create an account to continue

Access the most recent journalism from Nature's award-winning team

Explore the latest features & opinion covering groundbreaking research

Access through your institution

or

Sign in or create an account

Continue with Google

Continue with ORCiD

doi: https://doi.org/10.1038/d41586-026-02922-6

Additional reporting by Davide Castelvecchi.

Reprints and permissions

Subjects

Physics

Mathematics and computing

Machine learning

Latest on:

Physics

Mathematics and computing

Machine learning

Who gets credit in the AI era? OpenAI maths bombshell sparks debate

News 17 SEP 26

Continuous-wave laser absorption spectroscopy of the thorium-229 nucleus

Article 16 SEP 26

Electrically controllable superconducting memory effect in UTe2

Article 16 SEP 26

Chinese companies doubled down on science after US tech restrictions

News 18 SEP 26

Who gets credit in the AI era? OpenAI maths bombshell sparks debate

News 17 SEP 26

AI companies must work with the research community to protect attribution

Editorial 16 SEP 26

How fast are you ageing? Ask AI

News 17 SEP 26

How a team of AIs discovered a promising lung-cancer drug

News 17 SEP 26

AI companies must work with the research community to protect attribution

Editorial 16 SEP 26

Jobs

Faculty Search, Vanderbilt University

Nashville, Tennessee

Vanderbilt University School of Medicine

Tenure-Track: Assistant Professor in Marine Biology

Assistant Professor - Marine Biology; dynamic marine biologist whose research advances understanding of marine organisms, habitats, & ecosystems

Galveston, Texas

Texas A&M University - Galveston

Associate or Senior Editor, Nature Communications (Polymer Materials)

Title: Associate or Senior Editor, Nature Communications (Polymer Materials) Locations: Shanghai, Beijing, Nanjing, New Delhi or Pune (Hybrid) Appl...

Shanghai, Beijing, Nanjing, New Delhi or Pune (Hybrid)

Springer Nature Ltd

Associate or Senior Editor (Sustainable materials chemistry)

Title: Associate or Senior Editor, Nature Portfolio (Sustainable Materials Chemistry) Locations: Shanghai, Beijing, Nanjing, New Delhi or Pune (Hyb...

Shanghai, Beijing, Nanjing, New Delhi or Pune (Hybrid)

Springer Nature Ltd

Associate or Senior Editor, Communications Physics

Job title: Associate or Senior Editor, Communications Physics Locations: Shanghai, Beijing, Berlin, Heidelberg , Pune (hybrid) Closing date: Sept 3...

Shanghai, Beijing, Berlin, Heidelberg , Pune (hybrid)

Springer Nature Ltd

Sign up for the Nature Briefing: AI and Robotics newsletter — what matters in AI and robotics research, free to your inbox weekly.

Get the most important science stories of the day, free in your inbox. Sign up for Nature Briefing: AI and Robotics

The flow fits in one breath. The platform POSTs to a single HTTPS endpoint you registered once; the receiver verifies the signature, stores the raw body keyed by the provider's event id, and writes one pending delivery row per registered internal consumer; each consumer claims its own rows, does its work, and acknowledges them; that acknowledgement is what lands in the access log. Nothing downstream ever talks to the platform directly, and nothing in the path deletes the evidence that a read happened.

I build B2B SaaS features where "who touched this account event" is a question finance and security both ask, so the design axis here isn't throughput. It's attribution.

How do you fan out one webhook registration to many internal consumers through a queue?

Three mechanisms cover almost every case, and they differ mainly in how much the queue remembers about each consumer.

The outbox table is the boring one, and for an auditability-first system it's usually the right boring. Because acknowledgement is a row update rather than a broker-internal counter, you can hang whatever the audit needs off it — the consumer name, the credential that did the work, the attempt count, the timestamp. A broker ack is a fast, opaque "done". A row update is a fact you can query a year later.

Everything below assumes at-least-once delivery, because that's what you get from every real platform and every real queue. Consumers must be idempotent. There's no negotiating with that.

A Node.js receiver that records every internal read

The receiver does four things and nothing else: verify, persist, fan out, return 204. No consumer logic runs inside the request.

import { createServer } from "node:http"; import { createHmac, timingSafeEqual } from "node:crypto"; import { Pool } from "pg"; const pool = new Pool({ connectionString: process.env.DATABASE_URL }); const secret = process.env.WEBHOOK_SECRET as string; const CONSUMERS = ["billing-sync", "seat-provisioner", "usage-ledger"]; function verified(raw: Buffer, header: string): boolean { const expected = createHmac("sha256", secret).update(raw).digest(); const got = Buffer.from(header.replace(/^sha256=/, ""), "hex"); return got.length === expected.length && timingSafeEqual(got, expected); } createServer((req, res) => { if (req.method !== "POST" || req.url !== "/hooks/platform") { res.writeHead(404).end(); return; } const chunks: Buffer[] = []; req.on("data", (c: Buffer) => chunks.push(c)); req.on("end", async () => { const raw = Buffer.concat(chunks); if (!verified(raw, String(req.headers["x-signature"] ?? ""))) { res.writeHead(401).end(); return; } const event = JSON.parse(raw.toString("utf8")); const db = await pool.connect(); try { await db.query("begin"); // The platform's own id is the idempotency key: a redelivered POST inserts nothing. const ins = await db.query( `insert into events (event_id, kind, payload, received_at) values ($1, $2, $3, now()) on conflict (event_id) do nothing returning id`, [event.id, event.type, raw.toString("utf8")], ); if (ins.rows.length) { await db.query( `insert into deliveries (event_ref, consumer) select $1, unnest($2::text[])`, [ins.rows[0].id, CONSUMERS], ); } await db.query("commit"); res.writeHead(204).end(); } catch (err) { await db.query("rollback"); console.error("ingest rejected", err); res.writeHead(503).end(); // unacknowledged: the platform retries on its own schedule } finally { db.release(); } }); }).listen(8080);

Each consumer then drains its own rows. for update of d skip locked lets several workers of the same consumer run concurrently without handing the same event to two of them, which matters once you scale a slow consumer horizontally.

import { Pool } from "pg"; import { handle } from "./billing-sync.ts"; const pool = new Pool({ connectionString: process.env.DATABASE_URL }); const consumer = "billing-sync"; const principal = process.env.CONSUMER_PRINCIPAL as string; // this consumer's own credential export async function drain(batch = 20): Promise<number> { const db = await pool.connect(); try { await db.query("begin"); const { rows } = await db.query( `select d.id, e.event_id, e.payload from deliveries d join events e on e.id = d.event_ref where d.consumer = $1 and d.acked_at is null order by d.id limit $2 for update of d skip locked`, [consumer, batch], ); for (const row of rows) { await handle(JSON.parse(row.payload)); await db.query( `update deliveries set acked_at = now(), attempts = attempts + 1 where id = $1`, [row.id], ); await db.query( `insert into access_log (event_id, consumer, principal, read_at) values ($1, $2, $3, now())`, [row.event_id, consumer, principal], ); } await db.query("commit"); return rows.length; } catch (err) { await db.query("rollback"); console.error(`${consumer} batch rolled back`, err); return 0; } finally { db.release(); } }

Two details in there carry the whole audit story. The acknowledgement and the access-log insert share a transaction with the work, so a crash mid-batch leaves the row unacknowledged and the log honest. And principal comes from that consumer's own credential rather than one shared internal token — if three services authenticate as the same identity, your access log records a shrug.

Acknowledgement is the audit record

Most implementations treat ack as garbage collection: processed, so delete. Then a customer disputes a seat change, and the only thing you can prove is that a row is gone.

Keep the transition instead of the deletion. A delivery row that moves from null to an acked_at timestamp, with attempts and principal alongside, gives you three separate answers — was the event received, was it claimed, was it completed — and those are genuinely different questions during an incident review. Cursor-based streams collapse the second and third into one number per group.

Secrets are the other half of attribution, and they're easy to get wrong in exactly this shape of system. The signing secret for the registration, the per-consumer credentials, and the database password have different rotation needs and different blast radii; OWASP's secrets management guidance is blunt about not sharing one credential across components precisely because it destroys traceability. Load them from the environment or a secrets store at boot, rotate the webhook secret by accepting two valid secrets during an overlap window, and keep the rotation event itself in the same audit stream.

Verify before you log. An unverified POST should leave no trace in events at all, or your access log becomes a place where anyone on the internet can write rows.

What survives an outage, and what it costs to keep

Outages come in two flavors here, and only one of them is yours to absorb. If a consumer is down, its delivery rows pile up, the other consumers keep going, and lag per consumer is a single count(*) where acked_at is null per name. That's the payoff for per-consumer acknowledgement: one broken service doesn't block the other two, and you don't need the platform to redeliver anything.

If your receiver is down, the platform retries on whatever schedule it documents — typically an exponential sequence over some hours — and then gives up. Never treat that window as your safety net. Storing raw bodies means replay is yours: re-insert delivery rows for one consumer and one event range, and the rest of the system doesn't notice. Replaying from your own store also keeps the audit trail coherent, because the replay is itself an event you can log.

Retention is where the cost conversation lands, and as a solo founder I care: raw JSON payloads at a few KB each are cheap until a chatty platform sends millions a month, at which point keeping full bodies for a year quietly becomes your third-largest storage line. A reasonable split is 30 days of full payloads for debugging and replay, then trim to the hash plus the audit columns, which are the part compliance actually wants. I'm not sure there's a universal number — it depends on how long your disputes take to arrive.

When a single shared queue is the wrong call

If you have one internal consumer and no audit requirement, skip all of this. Verify the signature, do the work, return 204. A queue you added for a consumer you don't have yet is just an extra thing to page you about.

Postgres as the fan-out substrate has a real ceiling. Polling costs you latency floor and wasted queries, and past roughly a few thousand events per second the locking and vacuum pressure stop being free — that's where a broker with consumer groups earns its operational weight, with the trade-off that per-principal attribution moves into your application logs instead of the queue. If you need months of replay across many independent readers, a log-structured broker is the better fit and a database table isn't; stick with your broker's retention and put the audit rows beside it rather than inside it. Hosted webhook gateways solve the receiver-reliability problem well, though the delivery record then lives in a third party's system, which may or may not satisfy the auditor who asks for it.

The catch with the outbox approach is that you own code nobody else maintains: the claim query, the backoff, the DLQ semantics when a consumer exceeds its attempt budget.

Before you call it done, check a short list against a staging replay. Every consumer has its own credential and its own row in the access log. The receiver answers in under a second, because the platform's timeout is short and slow verification looks like an outage from the outside. Unacknowledged counts are graphed per consumer with an alert on age rather than depth, since ten minutes of lag on seat provisioning and ten minutes on a usage ledger are not the same incident. A poisoned event lands in a dead-letter state with its attempt history intact instead of being retried forever. Secret rotation is rehearsed, not theorized. And replay for one consumer over one hour is a command someone has actually run, with the resulting access-log rows eyeballed once — because the first time you try it during a real incident is the worst possible time to learn that it double-charges somebody.

Further reading

https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

https://github.com/standard-webhooks/standard-webhooks

https://www.rfc-editor.org/rfc/rfc9421.html

https://www.postgresql.org/docs/current/sql-select.html

https://www.rabbitmq.com/docs/confirms

https://redis.io/docs/latest/develop/data-types/streams/

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

In this tutorial, we implement NVIDIA cuML as a GPU-accelerated machine learning framework and build a practical workflow that demonstrates how RAPIDS can accelerate familiar data science and machine learning tasks. We begin by configuring the GPU environment and examining cuml.accel, which lets us accelerate existing scikit-learn workloads with minimal code changes, before moving to the native cuML API for direct CuPy and cuDF interoperability. We then benchmark CPU and GPU implementations of PCA, K-Means, nearest-neighbor search, logistic regression, random forests, and DBSCAN, while using synchronized timing to obtain meaningful performance measurements. We also build GPU-based manifold-learning and clustering pipelines with UMAP, t-SNE, HDBSCAN, and trustworthiness metrics; explore high-throughput forest inference with FIL; validate GPU-generated SHAP explanations; perform hyperparameter optimization with scikit-learn meta-estimators; and finally serialize trained models while examining portability between GPU and CPU environments.

Copy CodeCopiedUse a different Browser

import os import sys import time import json import shutil import warnings import subprocess import importlib import traceback warnings.filterwarnings("ignore") QUICK = False SEED = 42 SCALE = 0.25 if QUICK else 1.0 N_MAIN = int(200_000 * SCALE) D_MAIN = 64 N_RF = int(50_000 * SCALE) D_RF = 32 N_NN_INDEX = int(50_000 * SCALE) N_NN_QUERY = int(5_000 * SCALE) N_DBSCAN = int(20_000 * SCALE) N_MANIFOLD = int(60_000 * SCALE) N_ACCEL = int(80_000 * SCALE) RESULTS = [] NOTES = [] def banner(title): line = "=" * 78 print(f"\n{line}\n {title}\n{line}", flush=True) def section(title, fn, *args, **kwargs): banner(title) t0 = time.perf_counter() try: fn(*args, **kwargs) except Exception: print(f"[!] Section skipped due to an error:\n{traceback.format_exc()}") print(f"[section wall time: {time.perf_counter() - t0:.1f}s]", flush=True) def bootstrap(): if shutil.which("nvidia-smi") is None: raise SystemExit( "No NVIDIA GPU found. In Colab: Runtime > Change runtime type > GPU." ) print(subprocess.run( ["nvidia-smi", "--query-gpu=name,memory.total,compute_cap,driver_version", "--format=csv"], capture_output=True, text=True).stdout) try: import cuml print("cuML already available — skipping install.") except ImportError: print("Installing RAPIDS cuML (this takes ~1-3 minutes)...") pin = "" try: import cudf major_minor = ".".join(cudf.__version__.split("+")[0].split(".")[:2]) pin = f"=={major_minor}.*" print(f" Pinning to the preinstalled cuDF line: cuml-cu12{pin}") except Exception: print(" cuDF not found; installing the latest stable cuml-cu12.") cmd = [sys.executable, "-m", "pip", "install", "-q", "--extra-index-url=https://pypi.nvidia.com", f"cuml-cu12{pin}"] print("$ " + " ".join(cmd)) rc = subprocess.run(cmd).returncode if rc != 0: raise SystemExit( "pip install failed. Alternative that always works on Colab:\n" " !git clone https://github.com/rapidsai/rapidsai-csp-utils.git\n" " !python rapidsai-csp-utils/colab/pip-install.py" ) importlib.invalidate_caches() import cuml import cupy print(f"cuml {cuml.__version__}") print(f"cupy {cupy.__version__}") try: import cudf print(f"cudf {cudf.__version__}") except Exception: pass import sklearn print(f"sklearn {sklearn.__version__} (cuML requires scikit-learn >= 1.6)") bootstrap() import numpy as np import cupy as cp import cuml import matplotlib.pyplot as plt from cuml.datasets import make_classification as gpu_make_classification from cuml.datasets import make_blobs as gpu_make_blobs rng = np.random.RandomState(SEED) cp.random.seed(SEED) class Timer: def __init__(self, label, sync=True): self.label = label self.sync = sync def __enter__(self): if self.sync: cp.cuda.runtime.deviceSynchronize() self.t0 = time.perf_counter() return self def __exit__(self, *exc): if self.sync: cp.cuda.runtime.deviceSynchronize() self.dt = time.perf_counter() - self.t0 print(f" {self.label:<44s} {self.dt:8.3f}s") return False def to_numpy(a): if isinstance(a, cp.ndarray): return cp.asnumpy(a) if hasattr(a, "to_numpy"): return a.to_numpy() return np.asarray(a) def record(task, cpu_s, gpu_s): RESULTS.append((task, cpu_s, gpu_s)) if cpu_s and gpu_s: print(f" -> {task}: {cpu_s / gpu_s:.1f}x speedup\n") ACCEL_SCRIPT = f''' import time import numpy as np from sklearn.datasets import make_blobs from sklearn.decomposition import PCA from sklearn.cluster import KMeans from sklearn.neighbors import NearestNeighbors from sklearn.linear_model import Ridge X, y = make_blobs(n_samples={N_ACCEL}, n_features=32, centers=12, random_state=0) X = X.astype("float32"); y = y.astype("float32") t0 = time.perf_counter() PCA(n_components=8).fit_transform(X) KMeans(n_clusters=12, n_init=1, random_state=0).fit(X) NearestNeighbors(n_neighbors=8).fit(X[:{N_ACCEL // 2}]).kneighbors(X[:5000]) Ridge(alpha=1.0).fit(X, y) Ridge(alpha=1.0, positive=True).fit(X[:5000], y[:5000]) print("MODELTIME %.3f" % (time.perf_counter() - t0)) ''' def demo_accel(): path = "/content/_accel_demo.py" if os.path.isdir("/content") else "_accel_demo.py" with open(path, "w") as f: f.write(ACCEL_SCRIPT) def run(cmd, label): print(f"\n$ {' '.join(cmd[1:])}") t0 = time.perf_counter() p = subprocess.run(cmd, capture_output=True, text=True) wall = time.perf_counter() - t0 out = p.stdout + p.stderr model_s = None for line in out.splitlines(): if line.startswith("MODELTIME"): model_s = float(line.split()[1]) print(out.strip()[:4000]) print(f"[{label}] model time = {model_s}s | process wall = {wall:.1f}s") return model_s cpu_s = run([sys.executable, path], "stock sklearn") cmd = [sys.executable, "-m", "cuml.accel", "--profile", path] gpu_s = run(cmd, "cuml.accel") if gpu_s is None: gpu_s = run([sys.executable, "-m", "cuml.accel", path], "cuml.accel") record("cuml.accel (sklearn script, unmodified)", cpu_s, gpu_s) NOTES.append( "cuml.accel needed ZERO source changes; the profile table above shows " "which calls ran on GPU and why Ridge(positive=True) fell back to CPU." )

We configure the tutorial environment, define dataset sizes and benchmarking utilities, and verify that an NVIDIA GPU is available. We install and initialize RAPIDS cuML when necessary, set up CuPy and reproducibility controls, and create synchronized timing and result-tracking helpers. We also demonstrate cuml.accel by running an unmodified scikit-learn workload and comparing its CPU execution with GPU-accelerated execution.

Copy CodeCopiedUse a different Browser

def demo_native_api(): from cuml.preprocessing import StandardScaler from cuml.model_selection import train_test_split X, y = gpu_make_blobs(n_samples=50_000, n_features=8, centers=5, random_state=SEED, dtype=np.float32) print(f"cuml.datasets output lives on device: {type(X).__module__}, " f"shape={X.shape}, dtype={X.dtype}") try: import cudf df = cudf.DataFrame(X, columns=[f"f{i}" for i in range(X.shape[1])]) back = df.values ptr_a = X.__cuda_array_interface__["data"][0] ptr_b = back.__cuda_array_interface__["data"][0] print(f"CuPy ptr = {hex(ptr_a)}") print(f"cuDF->CuPy= {hex(ptr_b)}") print("Same device pointer (true zero-copy)? ", ptr_a == ptr_b) print("Note: a column-major DataFrame round trip may re-pack; what " "matters is that no host (CPU) round trip ever happens.") scaled = StandardScaler().fit_transform(df) print(f"StandardScaler(cuDF) -> {type(scaled).__name__}") except Exception as e: print(f"cuDF interop skipped: {e}") from cuml.decomposition import PCA pca = PCA(n_components=3).fit(X) print(f"default (mirrors input) -> {type(pca.transform(X)).__name__}") with cuml.using_output_type("numpy"): print(f"inside using_output_type() -> {type(pca.transform(X)).__name__}") print(f"after the context manager -> {type(pca.transform(X)).__name__}") NOTES.append( "Keep output_type as CuPy/cuDF inside a pipeline; converting to NumPy " "on every step forces a device->host copy and eats the speedup." ) Xtr, Xte, ytr, yte = train_test_split(X, y, test_size=0.2, random_state=SEED) print(f"train_test_split -> {Xtr.shape} / {Xte.shape}, still on device: " f"{isinstance(Xtr, cp.ndarray)}")

We work directly with the native cuML API and explore how GPU-resident data moves between CuPy, cuDF, and cuML components. We inspect device pointers to understand zero-copy interoperability and use cuML output-type controls to manage whether results remain on the GPU or return as NumPy arrays. We also perform a GPU-native train-test split so that our data remains on the device throughout the workflow.

Copy CodeCopiedUse a different Browser

def demo_benchmarks(): from sklearn.decomposition import PCA as skPCA from sklearn.cluster import KMeans as skKMeans, DBSCAN as skDBSCAN from sklearn.neighbors import NearestNeighbors as skNN from sklearn.linear_model import LogisticRegression as skLR from sklearn.ensemble import RandomForestClassifier as skRF from cuml.decomposition import PCA as cuPCA from cuml.cluster import KMeans as cuKMeans, DBSCAN as cuDBSCAN from cuml.neighbors import NearestNeighbors as cuNN from cuml.linear_model import LogisticRegression as cuLR from cuml.ensemble import RandomForestClassifier as cuRF print(f"Generating {N_MAIN:,} x {D_MAIN} on the GPU...") Xg, yg = gpu_make_classification(n_samples=N_MAIN, n_features=D_MAIN, n_informative=32, n_classes=4, random_state=SEED) Xg = Xg.astype(cp.float32) yg = yg.astype(cp.int32) Xc, yc = cp.asnumpy(Xg), cp.asnumpy(yg) print(f" device array: {Xg.nbytes / 1e6:.0f} MB\n") print("PCA (n_components=16)") with Timer("sklearn", sync=False) as t: skPCA(n_components=16, random_state=SEED).fit_transform(Xc) cpu = t.dt with Timer("cuML") as t: cuPCA(n_components=16, random_state=SEED).fit_transform(Xg) record("PCA", cpu, t.dt) print("KMeans (k=16)") with Timer("sklearn", sync=False) as t: skKMeans(n_clusters=16, n_init=1, max_iter=100, random_state=SEED).fit(Xc) cpu = t.dt with Timer("cuML") as t: cuKMeans(n_clusters=16, n_init=1, max_iter=100, random_state=SEED).fit(Xg) record("KMeans", cpu, t.dt) print(f"NearestNeighbors k=16 ({N_NN_INDEX:,} index / {N_NN_QUERY:,} query)") idx_g, q_g = Xg[:N_NN_INDEX], Xg[N_NN_INDEX:N_NN_INDEX + N_NN_QUERY] idx_c, q_c = cp.asnumpy(idx_g), cp.asnumpy(q_g) with Timer("sklearn (brute)", sync=False) as t: skNN(n_neighbors=16, algorithm="brute", n_jobs=-1).fit(idx_c).kneighbors(q_c) cpu = t.dt with Timer("cuML") as t: d_gpu, i_gpu = cuNN(n_neighbors=16).fit(idx_g).kneighbors(q_g) record("NearestNeighbors", cpu, t.dt) print("LogisticRegression (multinomial, lbfgs/QN)") with Timer("sklearn", sync=False) as t: sk_lr = skLR(max_iter=200, n_jobs=-1).fit(Xc, yc) cpu = t.dt with Timer("cuML") as t: cu_lr = cuLR(max_iter=200).fit(Xg, yg) record("LogisticRegression", cpu, t.dt) print(f" accuracy sklearn={sk_lr.score(Xc, yc):.4f} " f"cuML={float((cu_lr.predict(Xg) == yg).mean()):.4f} " "(different solvers, so small differences are expected)\n") print(f"RandomForestClassifier (100 trees, depth 12, {N_RF:,} x {D_RF})") Xr_g, yr_g = gpu_make_classification(n_samples=N_RF, n_features=D_RF, n_informative=16, n_classes=2, random_state=SEED) Xr_g = Xr_g.astype(cp.float32) yr_g = yr_g.astype(cp.int32) Xr_c, yr_c = cp.asnumpy(Xr_g), cp.asnumpy(yr_g) with Timer("sklearn", sync=False) as t: skRF(n_estimators=100, max_depth=12, n_jobs=-1, random_state=SEED).fit(Xr_c, yr_c) cpu = t.dt with Timer("cuML") as t: cu_rf = cuRF(n_estimators=100, max_depth=12, n_bins=128, n_streams=4, random_state=SEED).fit(Xr_g, yr_g) record("RandomForest (fit)", cpu, t.dt) globals()["_RF_ARTIFACTS"] = (cu_rf, Xr_g, yr_g, Xr_c, yr_c) print(f"DBSCAN ({N_DBSCAN:,} x 8)") Xd_g, _ = gpu_make_blobs(n_samples=N_DBSCAN, n_features=8, centers=6, cluster_std=0.6, random_state=SEED, dtype=np.float32) Xd_c = cp.asnumpy(Xd_g) with Timer("sklearn", sync=False) as t: lab_c = skDBSCAN(eps=0.9, min_samples=8, n_jobs=-1).fit_predict(Xd_c) cpu = t.dt with Timer("cuML") as

Date: September 13, 2026 Source: Universität Wien Summary: Scientists are combining an electron microscope with a quantum computer to squeeze far more information from each electron. The approach could reveal faint details with fewer electrons, helping protect fragile samples that conventional microscopy can damage. Share:

FULL STORY

Electron microscopes can reveal structures far smaller than anything visible with ordinary light. But researchers in Austria say conventional electron microscopes may be leaving valuable information on the table.

In a standard system, electrons are mainly counted to build an image. Yet each electron also carries quantum information that normally goes unused. Researchers at TU Wien, working with teams from the University of Vienna, JKU Linz and the University of Innsbruck, have developed a new approach designed to capture and process some of that extra information.

Their idea is to connect an electron microscope to a quantum computer. By doing so, the researchers hope to extract more useful information from each electron, potentially allowing scientists to form clearer images while exposing delicate samples to fewer electrons. That could be especially valuable for biological materials that are easily damaged. A quantum computer electron microscope based on the concept is now being constructed at TU Wien.

Using Quantum Entanglement to Get More From Each Electron

Modern electron microscopes already achieve extraordinary resolution.

"Today, we can image tiny details on the atomic scale," says Philipp Haslinger from the Institute of Atomic and Subatomic Physics at TU Wien. "However, this requires a large number of electrons. And not every sample can be exposed to so many electrons without being damaged. This is often a problem, particularly when imaging biological samples such as individual proteins."

The challenge, then, is to learn more from each electron so researchers can reduce the total number needed to produce an image.

The team proposes doing this by linking the electrons to a quantum computer built around trapped ions.

"Our idea is to combine the electrons with a quantum computer. We let them interact with ions that are held in place along the path of the electron beam," explains Elias Pescoller, first author of the publication and a doctoral student at the Institute for Theoretical Physics and the Institute of Atomic and Subatomic Physics at TU Wien. "This can, for example, create quantum entanglement between the electron and the quantum computer. The electron and the ion then share a joint quantum state."

Quantum entanglement allows two quantum systems to share information in ways that have no direct equivalent in classical physics. In this setup, an electron passing through the microscope can become entangled with an ion in the quantum computer, allowing information about the electron to be stored in the ion.

Turning Weak Signals Into Useful Information

After one electron interacts with the trapped ion, another electron can pass through and become entangled with the quantum computer as well. By repeatedly carrying out carefully designed quantum operations, the system can combine information from multiple electrons.

"If we perform very specific quantum-computing operations each time, we can optimally combine the information from several electrons so that we obtain a signal of maximum strength even though we use only a relatively small number of electrons," says Dennis Rätzel from the Institute of Atomic and Subatomic Physics at TU Wien.

The algorithms needed to carry out this processing were developed in collaboration with Johannes Kofler's team at JKU Linz.

The basic imaging process still relies on electrons, just as it does in a conventional electron microscope. The difference is that the quantum computer can process information that those electrons carry that would otherwise be lost.

"The electrons themselves are used to image small objects, just as in any other electron microscope. But by processing the quantum information carried by these electrons in a quantum computer, we can extract significantly more information from the process," says Iva Březinová from the Institute for Theoretical Physics at TU Wien. "What would previously have been indistinguishable from random noise can thus become a clear signal."

That could allow scientists to recover useful details that would be impossible to identify using ordinary electron counting alone.

"Quantum physics allows us to overcome the statistical limits that constrain conventional electron microscopes," says Elias Pescoller.

From Mathematical Proof to a Working Microscope

So far, the researchers have shown mathematically that the new method should offer important advantages. The next challenge is to demonstrate those benefits experimentally.

At TU Wien's University Service Center for Transmission Electron Microscopy (USTEM), researchers are preparing to integrate an ion-based quantum computer into an electron microscope. The quantum computer was developed by Philipp Schindler's team at the University of Innsbruck.

If the system works as expected, it could open a new approach to electron microscopy in which researchers gain more information while exposing sensitive samples to fewer electrons.

"It is really exciting that, within the quantA Cluster of Excellence, we can combine the expertise in quantum information, quantum computing and electron microscopy available at the different universities in Austria. This allows us to launch a unique project," says Thomas Juffmann from the University of Vienna.

Major funding for the consortium, which is coordinated by the University of Vienna, comes from the Austrian Science Fund (FWF) through the Cluster of Excellence quantA and from the Gordon and Betty Moore Foundation.

Story Source:

Materials provided by Universität Wien. Note: Content may be edited for style and length.

Journal Reference:

Elias Pescoller, Santiago Beltrán-Romero, Sebastian Egginger, Nicolas Jungwirth, Martino Zanetti, Dominik Hornof, Michael S. Seifner, Iva Březinová, Philipp Haslinger, Thomas Juffmann, Johannes Kofler, Philipp Schindler, Dennis Rätzel. Coupling free electrons to a trapped-ion quantum computer. arXiv, 16 Jan 2026 DOI: 10.48550/arXiv.2601.11446

Cite This Page:

Universität Wien. "Scientists are building a microscope powered by a quantum computer." ScienceDaily. ScienceDaily, 13 September 2026. <www.sciencedaily.com/releases/2026/09/260912220038.htm>.

Universität Wien. (2026, September 13). Scientists are building a microscope powered by a quantum computer. ScienceDaily. Retrieved September 13, 2026 from www.sciencedaily.com/releases/2026/09/260912220038.htm

Universität Wien. "Scientists are building a microscope powered by a quantum computer." ScienceDaily. www.sciencedaily.com/releases/2026/09/260912220038.htm (accessed September 13, 2026).

Explore More

from ScienceDaily

RELATED STORIES

2026-09-14 07:34

markzou的笔记©

速览

本文来自微信公众号： markzou的笔记 ，作者：markzou1988

核心结论（TL;DR）：未来20年中国房地产将从"短缺溢价"彻底转入"过剩分化"周期，且这一转折由四条相互强化的长周期力量共同驱动：

人口坍缩：主力购房人群（25–45岁）从2025年约3.8亿降至2040年不足3.2亿；同时死亡高原在2040后开启（年死亡1700–1900万），遗产房逐年涌入。新生儿长期低位（2025出生仅792万，总和生育率约1.0）使未来刚需基数持续收窄。

技术替代：AI+工业机器人+智能无人化设备，将在10–20年内渐进压缩制造、物流、客服、运营、初级白领等岗位，慢性压制收入与购房能力。

持有成本上升：房屋物理折旧（关键设备寿命仅15–20年）+房产税（持有环节征税方向明确）+高层运维难题，使"多余、老旧、高层"房产净收益转负。

结构性分化：一线核心/强二线优质资产抗跌修复；人口净流出城市、县城、老破小、高层尤其是超高层将长期阴跌、流动性枯竭。

租售比偏低：中国百城租金回报率仅约2.4%、一线1.5%–1.9%，显著低于国际合理区间（3.3%–5%）与无风险利率；在回报率修复到接近资金成本前，房价缺乏趋势性反转基础（详见第七节）。

债务显性化（断供/法拍）：房价下行使部分房产"负资产化"，房贷断供率从2022年1.6%升至2025年3.7%（克而瑞），法拍房挂拍量处历史高位（2025全年71.9万套、平均折价率约74%），形成"低价抛压+供给堰塞"，对房价尤其是弱能级城市构成持续下行加速器（详见第五节）。

一、分析框架与口径说明

本报告以"人口—技术—供需—持有成本—租售比—海外镜鉴"六维框架展开（租售比作为资产回报的"价值锚"单列），并叠加"历史周期镜鉴"与"断供/法拍的债务显性化"作为贯穿性的风险标尺。所有关键数据均来自国家统计局（NBS）、国家金融与发展实验室（NIFD/CNBS）、央行、IFR（国际机器人联合会）、CTBUH（世界高层建筑学会）、券商研报（Wind/冰山指数）、麦肯锡/高盛/IMF等机构，以及复旦大学人口研究所等学界测算。

文中"网友提供的观点/数据/案例"指网络问答工具与公开讨论中流传的楼市观察，代表性但不等于官方统计，本报告单独做"口径校准"，以避免以偏概全。涉及具体个人的案例均已做匿名化处理。

关键前提：房子最终是居住消费品。当"接盘人口"少于"释放房源"、且"持有净收益"转负时，价格由边际供需与持有成本决定，而非历史成本或情绪。

二、人口视角：需求侧的长期坍缩

人口是房地产最长周期、最不可逆的变量。结合已完成的《人口趋势全景分析》与最新官方数据：

·自然增长转负已4年：2025年出生792万、死亡1131万，自然减少339万；自然增长率−2.41‰（国家统计局2026-01）。

·主力购房人群收缩：25–45岁购房主力约从2025年3.8亿降至2040年不足3.2亿；适婚人口（前期测算）约从2.95亿降至2035年2.05亿。

·死亡高原开启：1962–1973婴儿潮（约2.6–3亿人）正迈入高龄，年死亡人口将从2025年1131万，于2040年前后明显跃升至1700–1900万（复旦人口所/学界测算），并持续数十年"高原期"而非尖峰。

·新生儿长期低位：2025出生仅792万，总和生育率约1.0（跌破警戒线）。这意味着未来20年的"新购房刚需基数"持续收窄，学区房、母婴、教培等衍生需求长期收缩——人口对楼市的拖累是双向且长期的。

·代际多房集中：60/70后是中国自有住房率最高的一代，独生子女家庭结构下，年轻一代往往"继承父母+岳父母+自购"手握多套，进一步放大可售/可租供给。

图1出生—死亡剪刀差与死亡高原（2020–2061）。实线为官方历史数据（2020–2025），虚线为学界情景预测（2026–2061）。出生长期低位+死亡高原，意味着"需求收缩、遗产房供给递增"的格局将延续数十年。

图2主力购房人群（25–45岁）规模收缩。需求侧"接盘人群"数量长期向下，是房价失去普涨根基的首要原因。

遗产房冲击的准确表述：网络流传"死亡带来1500万套遗产房一次性入市"并不严谨。更准确的说法是——60/70后房产将以"继承"形式持续、逐年流入二手房市场。按年死亡1131万、户均约2–3人、住房自有率高估算，每年新增继承/释放房源达数百万套量级，叠加独生子女家庭"多房集中"，是持续加压而非脉冲冲击。再叠加新生儿低位导致的未来买家减少，供需缺口长期扩大。

2.1死亡高峰下的遗产房供给时间趋势

上节已说明遗产房是"持续逐年"而非"一次性1500万套"流入。把它放进人口死亡高原的时间轴上，趋势更清晰：以"每死亡1人约释放0.3–0.5套住房"的区间估算（综合户均、住房自有率、夫妻共有等因素；台湾经验约每100死释放35套，可作类比下限），2025年（年死亡1131万）对应新增遗留房产约400万套量级，到死亡高原期的2040–2061年（年死亡1750–1900万）升至600万套+/年。不同机构假设差异较大——有测算认为2030年起每年进入"继承窗口"超800万套、2035年破1000万套；也有"每2死释放1套"的激进口径。无论取哪一档，方向一致：遗产房供给在未来20–30年持续、加速累积。

死亡人口遗留房产的时间趋势（模型估算）。柱为年新增遗留房产（万套），虚线为年死亡人口（万人，左轴），蓝线为累计遗留房产（万套，右轴，示意）。死亡高原（图1）直接驱动遗产房供给阶梯式抬升。

注：累计值为按里程碑年份（2025/2030/2035/2040/2045/2050/2061）逐年加总的示意，非逐年精算；若取更高释放系数并延伸至2060年，可支撑"未来30年累计释放1.5–2亿套"的公开估算。本图用于呈现趋势量级，非精确预测。

三、供需视角：从短缺到过剩的逆转

供给端仍在累积，需求端持续收缩，剪刀差清晰可见：

销售面积4年缩水过半，而待售库存仍处高位、二手房挂牌突破4500万套——这是典型的"量价齐跌+库存堰塞"。2025年新建商品房销售额83,937亿元，同比下降12.6%；个人按揭贷款12,852亿元，同比−17.8%，居民加杠杆购房意愿明显转弱。

销售塌陷vs库存累积（2021–2025）。右轴为待售面积（逆势上升），左轴为销售面积（断崖下行），供需背离是价格承压的直接证据。

四、杠杆与财富转移：居民去杠杆与债务风险

网友分享的实地观察——"2016年前后上车的80/90后资不抵债""财富被提前离场者抽走"——在宏观数据中得到印证：

·居民部门转向去杠杆：居民杠杆率（CNBS）从2024年末61.4%回落至2025年末59.4%；房贷占居民债务比重由2020年55.2%降至2025Q2的44.9%（NIFD）。

·房贷连续11个季度负增长：2025年个人住房贷款余额约37.4万亿元，全年净减少超6,700亿元，出现历史首次年度负增长（NIFD/城镇家庭财富调查）。

·提前还贷常态化：实际房贷利率因GDP缩减指数转负而被动抬升，居民提前还贷规模不减，进一步收缩信用（NIFD 2025Q4）。

居民杠杆率与房贷增速（2020–2025）。杠杆率见顶回落，房贷增速跌入负值区间，印证"借钱买房"周期的终结。

对网友分享案例的定性：一位高位加杠杆入市的年轻业主"卖房卖车偿债"、一位持有多套房产的业主"资产缩水"，属于高杠杆+高点入手群体的真实困境。本质是高点的"纸面财富"在价格回撤与现金流压力下向现金持有者再分配——这与"财富被提前感知市场者抽走"的判断方向一致，但其规模是结构性再分配，而非系统性崩盘。NIFD明确指出"房贷违约引发的过快去杠杆风险总体可控

五、断供与法拍：债务风险的显性化及其对房价的冲击

第四节讲居民部门"去杠杆"，本节的断供与法拍正是去杠杆过程中最刺眼的显性化结果——房价下行把"纸面负债"变成了"真实抛压"。当房产市值跌破未偿贷款余额（即"负资产"），部分家庭被迫断供，银行起诉查封→司法拍卖（法拍）；而法拍房以评估价约7折起拍、流拍后二拍再打8折，天然形成"低价成交→拉低周边挂牌价→更多负资产→更多断供"的下行螺旋。

5.1断供：从"个案"走向"结构性"

·断供率快速抬升：克而瑞《2025年中国城市住房断供率研究》显示，全国平均住房断供率从2022年的1.6%升至2025年的3.7%；部分三四线城市已超5%。

·负资产是根因：房价持续下跌，使部分2021年前后高点上车、首付不足或"加按揭"的房产市值已低于贷款余额——持有即亏损、卖出即资不抵债，断供成为理性或被迫选择。

·与就业/技术冲击共振：断供人群集中于收入波动大的群体（参见第六节技术替代对蓝领/白领的冲击），就业不稳进一步推高断供概率。

5.2法拍：处于历史高位的"低价供给堰塞"

·挂拍量处历史峰值附近：据中指研究院，全国法拍房挂拍量2023年达峰约79.6万套，2024约76.9万套、2025全年71.9万套（同比−6.6%）；虽自峰值回落，但仍为2020年前（年挂拍不足20万套）的3–4倍，属"高位回落但仍处历史高位"。截至2026年初，累计挂拍存量已突破600万套。

·量价齐跌、折价加深：2025年法拍成交16.9万套（同比−4.4%），总成交金额2,536亿元（同比−23.6%），平均折价率（成交价/评估价）74.1%——即法拍房平均以不到八折出售；住宅成交均价8,082元/㎡（同比−12.2%）。

·清仓率仅23.5%、流拍率超85%：大量法拍房无人接盘，银行被迫以"银行直供房"形式七折甚至更低"以价换量"，进一步压低价格预期。

全国法拍房挂拍量趋势与平均折价率（2021–2025）。挂拍量处历史高位、折价率长期维持7折上下并缓慢加深——低价供给堰塞是房价下行的"加速器"（2025折价率74.1%为中指官方值，其余为趋势示意）。

5.3对未来房价的预测性影响

·加速器而非主导：断供/法拍是"果"（由房价下行、收入走弱、负资产共同导致），但反过来成为价格下行的"加速器"——尤其在二手房占比提升、流动性偏弱的市场，法拍低价成交会直接锚定同小区挂牌价下限。

·能级分化：一线核心法拍清仓率较高（上海66%、深圳64%）、折价较小，对价格冲击有限；三四线/县城法拍供过于求、成交均价仅4,750元/㎡（约为一线1/8），是价格踩踏的重灾区。

·与遗产房叠加：未来十年"死亡高原+遗产房涌入"叠加"断供/法拍供给"，弱能级城市二手房供给端持续承压，价格缺乏反弹弹药；一线核心因稀缺与承接力可消化这部分冲击。

·政策对冲边界：政策可经"稳房价、展期、纾困"延缓断供，但无法消除"负资产+收入走弱"的根本矛盾；在居民杠杆率（59–61%）仍偏高、储蓄缓冲有限的背景下，断供/法拍对房价的压制将贯穿整个筑底期。

与全篇逻辑的衔接：断供/法拍是"人口坍缩+技术压制收入+持有成本上升+租售比偏低"四条长周期力量在债务端的集中兑现，是前述所有矛盾的"价格显影"——这进一步强化了"分能级、低杠杆、回避弱能级流动性陷阱"的结论。

六、技术替代的长期冲击：大模型·世界模型·无人设备·机器人

网友担忧的"AI与无人化导致大规模失业"，方向真实但需校准量级与时点。更值得关注的是10–20年的渐进式替代对收入预期的慢性压制。四类技术成熟度、替代路径、影响节奏各不相同，须分开看待：

6.1大模型（LLM）：白领与知识工作的首轮冲击

·本质：大模型擅长语言、图像、代码、数据分析等"信息处理"任务，弱物理规律、弱因果推理，是替代白领成熟度最高的技术。网友早期担忧的"大模型导致失业"即主要指这一类。

·冲击岗位：客服、运营、文案营销（AIGC）、初级编程（Copilot类）、数据分析、翻译、基础法律/财税文档处理等。路径不是"机器替代人"，而是"一人+AI顶替多人"——岗位编制压缩、起薪下行、初级岗缩招。

·权威测算：Anthropic CEO预测1–5年内消灭约一半初级白领岗；麦肯锡称到2030年中国多达2.2亿劳动者（约30%）需变更职业；高盛称未来十年AI威胁全球3亿全职岗位；IMF认为40%职缺受冲击。

6.2世界模型（World Model）：决定无人设备与机器人能否"真正落地"的使能技术

·本质：世界模型是让AI理解物理世界规律、进行因果推演的"内部模拟器"（黄仁勋称"Physical AI"、杨立昆长期倡导），补强大模型缺失的物理一致性与因果推理。

·当前应用：集中于自动驾驶（超80%算法用世界模型辅助训练）、机器人/具身智能（特斯拉World Simulator训练Optimus、宇树/智元等开源世界模型），目前仍处早期。

·对就业的影响（间接、滞后、天花板高）：世界模型本身不直接替代岗位，但它决定6.3（无人设备）与6.4（机器人）能否从"实验室演示"走向"规模替代"。时间尺度更长（10–20年），一旦成熟将放大后两者的替代效应。

6.3无人设备（自动驾驶卡车·无人机·无人仓）：蓝领物流岗位的直接替代

·自动驾驶卡车：2025全球市场约429亿美元，预计2034达1,077亿（CAGR 11%）；研究预测2035年自动驾驶卡车占新注册商用车30%。中国2025保有量约4,500辆→2030约12万辆。

·无人仓：京东等已实现全自动化；《2023仓储行业白皮书》显示自动化仓储系统可削减人工成本30%–50%。

·无人机物流：2025全球无人机物流市场25.2亿美元→2035预计1,470亿；中国持证飞手仅32.7万，实际需求78万，缺口超50%。

·影响：货车司机、分拣员、仓管、末端配送员等蓝领岗位被渐进替代——这群人正是主力购房人群（25–45岁）的重要组成，收入与就业稳定性受冲击，购房能力承压最直接。全国物流从业超5,500万，正从"招工难"转向"无人化替代+高技能缺口并存"。

6.4机器人（工业+人形）：制造业与服务业的双重替代

·工业机器人：中国制造业密度2023达470台/万人（IFR），7年翻倍、全球第三；已是全球最大协作机器人市场（占全球销量41%）。制造业焊接/装配/搬运持续被替代。

·人形机器人：2025起进入量产元年（特斯拉Optimus、宇树、智元、Figure等），虽仍早期，但具备制造业与服务业双重替代潜力；某头部企业计划未来五年投入300万台机器人、100万台无人车、10万架无人机。

·替代与补位并存：护理、家政类机器人可能因人口老龄化的劳动力短缺而增长需求，形成"机器补位人力"——这是技术与人口变量的反向对冲，但难以逆转整体就业—收入—购房能力的下行趋势。

主要国家制造业工业机器人密度（IFR 2023，台/万人）。中国密度7年翻倍，自动化对制造业岗位的挤压是长期、确定的趋势。

口径校准的意义：四类技术的冲击真实且中长期，但用夸张数字制造"5年内4000–5000万人失业"的紧迫感，会掩盖真正值得警惕的趋势——收入增速放缓+就业预期转弱对购房能力的慢性压制，比短期失业数字更持久、更深刻地影响楼市需求。技术替代是"慢变量"，却与人口坍缩形成"需求侧双向挤压"。

四类技术替代节奏对比：

技术成熟度主要影响岗位对楼市影响节奏

大模型（LLM）高（已商用）白领/客服/运营/初级岗1–5年启动，渐进

世界模型早期赋能无人设备/机器人10–20年，间接放大

无人设备中（试点→规模）司机/分拣/仓管/配送5–15年，蓝领直接

机器人中高（工业）/早期（人形）制造/服务业5–20年，双重

七、租售比：房价回归的"锚"

租金回报率是衡量房产作为资产是否值价的终极标尺——它不依赖"未来会涨"的预期，只看"现在能收多少租"。当增值预期消失，租售比就成为房价的价值底线锚，是比"跌了这么多该反弹了"更硬的预测依据。

注：毛租金回报率=年租金/房价；净回报率需扣除持有成本（物业费、房产税、地租等）。中国持有成本极低，毛≈净；美/日/欧持有成本较高，净回报率明显低于毛回报率。国际普遍认为合理租售比为1:200–1:300（即毛回报率3.3%–5%），有房产税国家合理水平约5%。

主要国家/城市毛租金回报率对比（2025）。中国百城与一线城市显著低于国际合理区间（3.3%–5%），韩国与中国同处全球最低梯队。

7.1中国的位置与缺口

·绝对水平偏低：麟评居住大数据研究院显示，2025上半年重点50城租售比1:576（国际合理1:200–1:300），租金回报率仅2.08%，售租比高达48年——即仅靠租金收回买房成本需48年。

·按国际合理下限（3%）反推：若租金稳定、以3%为合理回报率，重点50城"理性房价"约12,989元/㎡，较当时18,700元/㎡低约30%。这并非预测必跌30%，而是说明当前价格仍含较多"增值预期溢价"。

·边际改善中：房价跌幅大于租金跌幅，正推动租售比向合理区间靠近；但进程缓慢，且租金本身也随收入预期走弱。

7.2国际镜鉴：租售比何时成为"底部信号"

·拐点规律：据券商复盘，美日房价企稳的关键拐点均出现在"租售比显著高于无风险利率（十年期国债）"之时——日本租售比回升至十年期国债收益率上方约2个百分点后房价止跌；美国亦类似。

·中国的现状：2025末中国10年期国债约1.86%；北上深二手住宅租金回报率约1.7%–2.0%，部分仍低于国债收益率——即持有核心房产的现金流回报不及买国债。只有当租金回报率修复并稳定超过资金成本（房贷利率/国债），市场才具备实质性筑底条件。

对房价预测的含义：租售比是比情绪更硬的锚。它指向一个清晰结论——在租金回报率修复到接近资金成本之前，房价缺乏趋势性反转的基础；而要达到国际合理区间，要么房价继续下修，要么租金补涨（在收入预期走弱下更难），大概率是前者主导、分能级兑现。一线城市因净回报率已接近国债、且人口与稀缺资源托底，企稳更早；三四线/县城租售比虽数字较高，但租金与流动性双弱，价格仍承压。

八、房屋折旧与房产税：持有成本的结构性上升

过去房价上涨掩盖了持有端的成本。当增值预期消失，折旧与税收成为定价的关键变量：

8.1房屋折旧

·物理折旧：住宅设计使用年限一般约50年，但电梯、消防、二次供水、外墙保温等关键设备寿命仅15–20年，到期更换费用动辄数十万至百万元，由全体业主分摊。换一部高层电梯约20–50万元。

·功能折旧：户型、车位比、社区配套随时代过时；老旧高层在遗产房涌入时，因产品力落后折价最猛。

·区位折旧：人口净流出区域，区位价值本身持续衰减。

8.2房产税（持有环节征税）

·试点已运行15年：2011.1.28上海、重庆率先试点。上海针对本地二套及以上新增住房及非户籍新购住房，税率0.4%–0.6%（按交易价70%计税），设人均60㎡免税面积；重庆侧重独栋别墅、高档公寓及"三无"人员二套，税率0.5%–1.2%。

·立法方向明确：2021.10全国人大常委会授权国务院开展房地产税改革试点（期限5年），原则为"先地方试点、再国家统一立法"；后因市场下行暂缓。2025.9上海优化政策（非户籍首套免、二套人均60㎡扣除），2026.1试点延长至2031.1.27。

·对楼市的含义：持有环节征税将提高多套房持有成本，与遗产房释放叠加，倒逼存量入市、抑制囤房，长期压低边际房产估值。

组合效应：折旧侵蚀价值+房产税增加持有成本+遗产房涌入=对"多余、老旧、高层"房产而言，持有净收益转负，加速折价与抛售。这是过去20年"买房即增值"逻辑的根本逆转。

九、高层与超高层：数量对比与长期影响

中国是全球高层建筑第一大国。明确界定与数量对比：

150m+/200m+/300m+为CTBUH（世界高层建筑学会）2025年8月权威统计；115万栋/5,000+栋为公开报道对广义高层住宅存量的行业估算，非官方普查口径，仅作量级参考。城市分布上，香港（150m+569栋）、深圳（444）、广州（204）位居前列。

中国超高层建筑数量梯度（CTBUH 2025）。超高层是高层中的顶端子集，数量逐级锐减，但绝对存量已居全球之首。

9.1长期影响：四重压力

·①物理老化：电梯、消防、水泵、外墙寿命15–20年，集中更换期与楼龄同步到来，费用高且需全体业主分摊——意见难统一、空置/出租业主不愿出资，设备常"带病运行"。

·②拆迁无解（容积率倒挂）：高层容积率普遍3.0–5.0，拆除后受"限高令"（约80m天花板）约束无法再加高，重建无利可图；住建部定调城市更新以旧改为主、严控大拆大建。老多层尚有拆迁预期，绝大多数高层基本告别拆迁。

·③治理失灵：几百户业主决策效率低、物业费收缴率下滑；2025初至2026.3全国已有212个高层小区物业整体撤场，TOP50物业撤场率同比+37%。失管后品质加速下滑。

·④消防与安全隐患：主流登高消防车救援高度约50m（约17层），30层以上火灾外部救援困难；外墙脱落、高空坠物风险随楼龄上升。

市场已在用价格投票：二手房降价最猛的，往往不是没电梯的老破小，而是2008–2015年建成的30层以上高层。欧美先例（巴黎郊区高层社区、圣路易斯公共住宅）显示，治理失灵后中产搬离、低收入留守，可能滑向"高层贫民窟"。但需区分：核心城区、品牌物业、地段优越的高层可依托旧改政策持续更新、具备保值属性；真正高风险的是县城远郊、产业薄弱地区的高密度刚需高层。

十、国际镜鉴：日本"失去的三十年"

网友提到的"日本房价峰值跌60–70%且至今未回"基本属实，是极重要的参照：

·1991年泡沫破裂后，东京都地价较峰值最大回撤约62%，全国土地均价跌约50%，六大都市商业地价累计跌约65%。

·至今（2023前后）东京都地价仍显著低于峰值，未回到峰值水平的一半附近；全国均值亦未复原——印证"底部漫长、复苏极慢"。

日本地价回撤（1991峰值=100）。东京都与全国均值均经历深度、长期的回撤，是"房价不会自动回弹"的硬证据。

十一、历史经济危机周期：房地产的"周期宿命"

经济学中"一切世界级大危机，几乎都始于房地产崩盘"（见《逃不开的经济周期》）。历史上每一次全球性大衰退，起点几乎都是地产泡沫破裂：1929美国大萧条、1990日本失去三十年、1997亚洲金融风暴、2008美国次贷、欧债危机中的西班牙/爱尔兰。房地产体量最大、绑定信贷、周期最长（库兹涅茨15–25年），一轮下行足以压垮十年经济。

11.1四层周期嵌套

·康波（康德拉季耶夫）：45–60年长波，由技术创新驱动；房地产是康波繁荣期的"放大器"、萧条期的"重灾区"。学界普遍认为当前处于第五轮康波萧条期向第六轮过渡阶段。

·库兹涅茨（房地产周期）：15–25年，与房地产投资直接对应。中国本轮房地产周期开启于2000年，按15–25年规律，正处下行期末端、长期调整通道。

·朱格拉（设备投资）：7–11年；基钦（库存）：3–5年。二者叠加形成中短周期波动，解释为何长下行期中也会出现阶段性反弹。

11.2历史主要房地产危机的回撤幅度

下列峰值至谷底的最大回撤，揭示了"房价不会自动回弹"的历史铁律，也提示长周期持有的周期性风险：

历史上主要房地产危机的房价/地价最大回撤（峰值至谷底，%）。中国70城已自峰值回撤约20–25%（琥珀色），远低于多数历史极端情形，但周期位置与方向一致。

·美国1929大萧条：1929–1933房价跌约35%，失业率飙至25%，断供潮席卷。

·日本失去的三十年：1991泡沫破裂后，东京地价峰谷最大回撤约80%（六大都市累计−76%），银行坏账高达50万亿日元，GDP增速从7%跌至0%。

·美国2008次贷：全国房价峰谷回撤约35%（Case-Shiller全国−27%，重灾郡县更深），雷曼倒下触发百年一遇金融海啸。

·爱尔兰2008/中国香港1997/阿姆斯特丹18世纪：分别回撤56%/61%/66%（阿姆斯特丹历时37年阴跌）。

·中国海南1993：区域泡沫破裂，GDP增速由41%骤降至4%，留下600+栋烂尾楼——中国本土也曾上演"三年狂热到冰点"。

11.3对20年（2026–2045）预测框架的含义

·周期位置决定基调：当前中国房地产处于"库兹涅茨长下行+康波萧条"双周期叠加，与日本1991、美国2008前的周期位置相似——意味着未来20年更可能是"长筑底、强分化、间歇性危机冲击"，而非平滑复苏。

·反弹需警惕"技术性"：中短周期（朱格拉/基钦）会带来阶段性回暖，但在库兹涅茨长下行未走完前，任何反弹都更像筑底波动，须区分"周期反弹"与"趋势反转"。

·危机是概率而非必然：中国居民杠杆率（59–61%）低于美日危机前水平、储蓄率高，急性崩盘概率低于慢性阴跌；但"慢出清+周期性回撤"已是确定性背景，长期持有须为周期性回撤预留安全垫。

与人口/技术的共振：历史危机多在"高杠杆+人口拐点+技术冲击就业"三者共振时最猛烈。当前中国恰同时面临人口坍缩、技术替代、杠杆回落——这正是须以"分能级、低杠杆、控流动性风险"应对周期宿命的根本原因。

十二、风险推演：金融危机可能性

基于NIFD与央行数据：

·居民杠杆率（59–61%）低于美国（68%）、日本（64%），且储蓄倾向高，债务/储蓄比约1.4倍，远低于美欧日2–4倍——存量债务风险总体可控。

·真正风险在结构性：房企流动性（连续多年债务违约扩散）、地方土地财政、以及部分高杠杆家庭的现金流断裂。

·政策正通过"去库存、优供给、稳房价、适度贴息"对冲，目标是"稳杠杆"而非放任出清。

结论：更可能是"慢出清+长筑底"而非"急性危机"。但网友强调的"居民资产负债表脆弱性"确为真实约束，不应忽视。

十三、20年走势情景推演（分能级）

以下为基于上述变量的假设情景（以各能级历史峰值为100，2015–2026年为官方价格指数历史段，2026–2045年为方向性推演；指数化，仅示意方向与量级，非精准预测）：

三类城市能级房价走势与20年情景推演（2015–2045，历史峰值=100）。2015–2026年历史段基于国家统计局70城二手住宅价格指数及券商分能级测算；2026年后浅灰底色区间为方向性推演。截至2026年，一线核心/强二线/三四线县城分别较峰值回撤约12%/18%/22%，分化显著。

2015–2021年，棚改货币化与城镇化推动各能级房价普涨，但2021年下半年后进入调整期。官方70城二手住宅价格指数显示：二线/三线城市分别于2021年7月/6月见顶，一线核心则延后至2023年4月见顶；截至2026年，70城整体较峰值累计回撤约20–22%，但一线核心、强二线、三四线/县城的回撤幅度呈明显阶梯式放大。

十四、结论与建议

一句话总结：未来20年，中国房价的核心矛盾是"越来越少的人，接越来越多的房；越来越贵的持有，配越来越弱的增值；越来越低的租售比，撑越来越高的房价"。这不是崩盘叙事，而是一次长达数十年的、由人口