Loop Engineering assembles automations, worktrees, Skills, connectors, sub-agents, and external state into a closed loop: the system finds work, assigns it, executes, checks, records progress, then starts another round. The pieces are useful. The system sounds complete.

The original post does not ignore the risks. Addy explicitly says verification remains on us, and a bad loop can keep digging itself deeper. The name is still dangerous because it dresses a scheduling structure up as a capability leap. Put an Agent inside while (true), and continuous execution starts sounding like continuous improvement.

It does not. A loop can increase the number of attempts. It cannot increase the density of correct answers.

The hard part of Agentic Coding has never been keeping an Agent running. The bottleneck is proving, at the end of each round, that the result moved closer to correct.

A Loop Just Welds Down the Enter Key

Automatic triggers, queues, state machines, retries, and scheduled jobs have been part of software engineering for decades. The change Agents bring is that the next action inside the loop is now chosen by a probabilistic model.

That makes failure harder to see.

A deterministic program usually fails the same way repeatedly. An Agent can fail in a different-looking way every time: rewrite the implementation, add tests, invent a new explanation, then ask another Agent for review. The activity keeps increasing while the direction may not move at all.

Imagine the task: "Refactor the payments module without changing behavior." The Agent completes one round, the tests turn green, and the review Agent approves. The loop moves on and cleans up more code. Yet the tests cover only the happy path, and both Agents share the same wrong interpretation. The loop did not discover the blind spot. It copied the blind spot into more files.

One confident Agent is a hallucination. A roomful of Agents nodding at one another is consensus hallucination.

Separating maker and checker is valuable because it reduces some self-confirmation bias. Two probabilistic models still cannot manufacture ground truth. Putting a probabilistic judge behind a probabilistic output still gives you probability, only with more ceremony.

A loop clearly solves one problem: who presses Enter next. It has no answer for whether Enter should be pressed, or whether the result got better afterward.

Evals Set Direction; Verification Decides Whether to Continue

In "From Prompt to Harness", I divided a harness into five layers: input constraints, execution, output verification, feedback, and reproducibility. A loop sits in execution and orchestration. Its job is to keep the system moving.

The last three layers are what turn it into engineering.

Compilation, type checking, linters, schema validation, and unit tests are deterministic gates. They block obvious failures after every round. They are cheap, fast, and repeatable, which makes them ideal for a fast loop.

But a gate can check the wrong thing. Green tests do not prove that business logic is correct. Higher coverage does not prove that edge cases are covered. A stable benchmark does not prove that the architecture is healthy. That is why the system also needs slow-loop evals: golden datasets, held-out regression suites, production replay, real user feedback, and human judgment where necessary. Those mechanisms recalibrate the system against ground truth.

Without a fast gate, failures leak into the next round. Without a slow eval, the entire system accelerates along the wrong metric.

There is another practical problem: Agents optimize for the completion condition.

Tell one to "make every test pass" and it may fix the code. It may also weaken the tests, widen the mocks, swallow exceptions, or skip failing cases. Ask another Agent whether the task is done and it can be persuaded by a plausible-looking diff. A beautifully written done condition is still a wish without a verifier.

Loops work well on verifiable tasks. Formatting, dependency upgrades, well-scoped bugs, and fixed benchmarks all provide clear feedback. Move to ambiguous requirements, architectural refactoring, performance tradeoffs, or user experience, and that feedback weakens quickly. At that point, another round has only one reliably growing metric: cost.

Without verification, the only guaranteed improvement in a loop is token usage.

A Save Point Is Not an Upgrade

Loop Engineering puts strong emphasis on state outside the conversation: Markdown, issues, a Linear board, anything persistent. That is the right design. Models forget; repositories do not. Without external state, a long-running task starts guessing from scratch in round two.

State persistence answers, "Where should the next run resume?" Learning accumulation answers, "Why should the next run be better?"

Think of a save point and an upgrade in a game. A save point returns you to the same place after death. An upgrade changes what the character can do. An ordinary loop may have save points without having an upgrade system.

Dumping a summary into memory does not automatically create learning either. In "Long-Term Memory Is Making Agents Dumber", I argued that memory updates without evals harden lucky successes into rules and bad diagnoses into persistent bias. Experience accumulates, context gets dirtier, and every new run begins by rereading old mistakes.

Real accumulation requires selection.

A failure leaves an execution trace and verifier result. Repeated failures form a failure signature. The system uses that evidence to modify a Skill, tool, prompt, checker, or orchestration policy. The new version then runs against the same evals and a held-out regression suite. Improvements survive. Regressions roll back.

Keeping experience gives you memory. Keeping validated improvements gives you evolution.

An Evolution Loop Changes the Starting Point

A basic Retry Loop changes almost nothing: the same model, the same harness, and the same objective sample another output. It may succeed by chance, but it does not know why. The next similar task begins beside the same hole.

An Evolution Loop changes the system that produces the answer.

This direction is already producing concrete research.

The Darwin Gödel Machine repeatedly modifies its own coding Agent, validates each variant on benchmarks, and keeps an archive for further exploration. It relies on empirical selection rather than trying to prove every change beneficial in advance. Performance rose from 20.0% to 50.0% on SWE-bench and from 14.2% to 30.7% on Polyglot.

Self-Harness brings the same idea closer to Harness Engineering. It mines recurring weaknesses from execution traces, generates bounded harness patches, then uses held-in evals and held-out regression to decide what gets promoted. A candidate advances only when it improves at least one split without degrading the other. Across three fixed models on Terminal-Bench-2.0, held-out pass rates rose from 40.5% to 61.9%, 23.8% to 38.1%, and 42.9% to 57.1%.

These systems also run in loops, but their value does not come from looping. The loop supplies iteration. The selector supplies direction.

Every round must leave behind a reusable change: a better Skill, a more suitable tool, a harder checker, less wasted exploration, or a more accurate stopping policy. The next round must inherit those changes before its starting point has genuinely improved.

Stop When the System Keeps Regressing

Evolution is not perpetual motion.

Two or three consecutive regressions suggest that the current search direction is exhausted, the eval signal is broken, the context is polluted, or the model has reached its capability ceiling. Another retry merely spends tokens keeping a bad direction alive.

A proper Evolution Loop preserves the current best. Every candidate mutates on an isolated branch. A candidate that does not beat the best never reaches the main line. Repeated lack of improvement triggers a stop. Budget exhaustion triggers a stop. The same failure signature appearing again and again triggers a new search space or a handoff to a human.

Stopping also produces information. It says that the current strategy has no remaining marginal value, so the next move may be to fix the verifier, change the model, split the task, or build better ground truth. Treat stopping as an exception and the loop hides failure. Treat it as feedback and the system can change direction.

Natural selection never promised that every mutation would survive. Agents deserve no such promise either.

A loop that cannot stop has crossed from autonomy into loss of control.

Do Not Confuse Motion with Progress

Loop Engineering works as an operational layer. Automations provide a heartbeat, worktrees provide isolation, sub-agents provide parallelism, and external state lets work continue across runs. All of that is worth building.

Calling it the next core paradigm of Agentic Coding goes too far.

A harness places a probabilistic model inside a system that can be constrained, verified, and reproduced. A loop keeps that system running unattended. Evolution carries validated failures and improvements into the next harness version. The order matters.

A system that reaches round 100 with the same harness, evals, and strategy has merely repeated the ignorance of round one ninety-nine more times.

Do not ask how long the loop can run. Ask what this round leaves behind, who decides what survives, and whether the system can stop when performance keeps degrading.

Silicon Valley will keep inventing new terms. Spinning is easy. Engineering begins when each lap makes the next one smarter.

所谓 Loop Engineering，是把 automation、worktree、Skill、connector、sub-agent 和外部状态拼成一个闭环：系统自己找活、派活、执行、检查、记录，再进入下一轮。听起来很完整，零件也都能用。

原文其实没回避风险。Addy 明说 verification 仍然落在人身上，loop 跑偏会越挖越深。可这个名字依然危险：它把一种调度结构包装成了能力跃迁，仿佛把 Agent 塞进 while (true)，持续运行便会自然变成持续进步。

当然不会。Loop 能增加尝试次数，不能增加正确答案的密度。

Agentic Coding 最难的，从来不是让 Agent 继续跑。真正卡住它的，是每一轮结束后，谁能证明结果更接近正确。

Loop 只是把 Enter 键焊死

自动触发、队列、状态机、重试、定时任务，这些东西软件工程早就有。Agent 带来的变化，是 loop 里的下一步开始由概率模型决定。

这反而让错误更难看出来。

确定性程序跑错，通常会稳定地报同一个错；Agent 跑错，会不断生成看起来不同的错。改一版实现，补一组测试，换一个解释，再请另一个 Agent review。动作越来越多，方向可能一步没动。

想象一个任务：“重构支付模块，保持行为不变。”Agent 改完第一轮，测试绿了，review agent 也点头，于是 loop 自动进入下一轮继续清理。可测试只覆盖 happy path，两个 Agent 又共享同一份错误理解。loop 没有发现盲区，只把盲区复制到了更多文件。

一个 Agent 自信，叫 hallucination。一群 Agent 互相点头，叫 consensus hallucination。

maker 和 checker 分开当然有价值，它能降低一部分自证偏差。可两个概率模型凑在一起，仍然造不出 ground truth。概率性输出后面再接一个概率性裁判，得到的还是概率，只是仪式感更强。

所以 loop 明确解决的只有一件事：谁来按下一次 Enter。该不该按、按完有没有更好，它没有答案。

Eval 决定方向，Verification 决定能不能继续

我在《从 Prompt 到 Harness》里把 harness 拆成五层：输入约束、执行、输出验证、反馈、复现。Loop 所在的位置很清楚，它属于执行和 orchestration，负责让系统连续运转。

真正把系统变成工程的，是后面三层。

编译、类型检查、linter、schema validation、单元测试，这些 deterministic gate 能在每一轮结束后挡住明显错误。它们便宜、快速、可重复，适合 fast loop。

可 gate 也可能检查错东西。测试全绿，不等于业务逻辑正确；coverage 上升，不等于 edge case 被覆盖；benchmark 没掉，不等于架构没有腐烂。于是还要有 slow-loop eval：golden dataset、held-out regression、线上样本回放、真实用户反馈，以及必要的人类判断，用来校准 ground truth。

没有 fast gate，错误会被带进下一轮。没有 slow eval，整个系统会沿着错误指标越跑越快。

这里还有一个更现实的问题：Agent 会迎合 completion condition。

告诉它“所有测试通过”，它可能修代码，也可能改测试、扩大 mock、吞异常、跳过失败 case。让另一个 Agent 判断“是否完成”，它同样可能被一份看起来合理的 diff 说服。done 写得再漂亮，缺少 verifier 也只是愿望。

Loop 在可验证任务上很强。格式化、依赖升级、明确 bug、固定 benchmark，都有清晰反馈。换成模糊需求、架构重构、性能权衡、用户体验，feedback 迅速变弱。此时多跑一轮，唯一稳定增长的指标是费用。

没有 verification 的 loop，唯一确定的 improvement 是 token usage。

存档不等于升级

Loop Engineering 很强调把状态写到 conversation 之外：markdown、issue、Linear board，什么都行。这个设计是对的。模型会忘，repo 不会；长任务没有外部状态，第二轮就会从头猜。

可 state persistence 解决的是“下次从哪里继续”，learning accumulation 回答的是“下次凭什么更好”。

这像游戏里的存档和升级。存档让你死后回到原地；升级会改变角色能力。普通 loop 有存档，未必有升级系统。

把本轮总结塞进 memory，也不自动等于 learning。我在《长期记忆正在把 Agent 变蠢》里写过，未经 eval 的 memory update 会把偶然成功固化成规则，也会把错误归因写成长期偏见。经验越存越多，context 越来越脏，最后每轮都先读一遍旧错误。

真正的累积必须经过 selection。

一次失败留下 execution trace 和 verifier result；多次失败聚成 failure signature；系统据此修改 Skill、tool、prompt、checker 或 orchestration；新版本再跑同一套 eval 和 held-out regression。通过的保留，退化的回滚。

只保存经历，得到 memory；保存被验证过的改进，才得到 evolution。

Evolution Loop 让下一轮换一个起点

普通 Retry Loop 的状态几乎不变：同一个 model、同一套 harness、同一个目标，再采样一次输出。它可能碰巧成功，却没有回答成功来自哪里。下一次遇到相似任务，还是从同一个坑边起跑。

Evolution Loop 会修改产生答案的系统。

这个方向已经有很具体的研究。

Darwin Gödel Machine 不断修改自己的 coding agent，拿 benchmark 验证，再把不同版本放进 archive 继续探索。它依靠经验选择，而非证明每次修改一定正确；SWE-bench 从 20.0% 提到 50.0%，Polyglot 从 14.2% 提到 30.7%。

更贴近 Harness Engineering 的 Self-Harness 做了三件事：从 execution trace 里挖 recurring weakness，生成范围受控的 harness patch，再用 held-in eval 和 held-out regression 决定是否 promote。候选只有在至少一边提升、另一边不退化时才会进入下一代。三个固定模型在 Terminal-Bench-2.0 的 held-out pass rate 分别从 40.5% 提到 61.9%、23.8% 提到 38.1%、42.9% 提到 57.1%。

这些系统也在 loop，但价值不来自 loop 本身。Loop 提供迭代，selector 才提供方向。

每一轮都要留下可复用的变化：更好的 Skill、更合适的工具、更硬的 checker、更少的无效探索、更准确的 stopping policy。下一轮继承这些变化，起点才真的抬高。

连续退化时，停下来

Evolution 不等于永动。

连续两轮、三轮都在退化，说明当前搜索方向已经枯竭，或者 eval 信号坏了，或者 context 被污染，或者模型能力已经触顶。此时继续 retry，只是在拿 token 给错误方向续命。

一个合格的 Evolution Loop 必须保留 current best。所有候选在隔离分支上变异；没有超过 best，就不进入主线。连续无提升达到阈值，触发 stop；预算耗尽，stop；同一种 failure signature 反复出现，切换搜索空间或交还人类。

停止也会产生信息。它告诉系统：当前策略已经没有边际收益，接下来该改 verifier、换模型、拆任务，或者补 ground truth。把 stop 当成异常，loop 就会掩盖失败；把 stop 当成反馈，系统才有机会换方向。

自然选择里，没有每个变异都活下来的道理。Agent 也一样。

不会停的 loop 没有 autonomy，只有失控。

别把转圈当进步

把 Loop Engineering 当成一个 operational layer，没问题。Automations 提供心跳，worktree 提供隔离，sub-agent 提供并行，外部状态让任务可以跨轮继续。这些都值得做。

把它说成 Agentic Coding 的下一个核心范式，就过了。

Harness 让概率模型进入可约束、可验证、可复现的系统。Loop 让这套系统无人值守地运行。Evolution 再把验证过的失败和改进，沉淀进下一版 harness。顺序不能反。

一个系统跑到第 100 轮，harness、eval、strategy 都没变，它只是把第 1 轮的无知重复了 99 次。

所以，别问 loop 能跑多久。问这一轮留下了什么，谁决定保留，连续退化时能不能停。

硅谷当然还会继续发明新词。转起来不难，让下一圈比上一圈更聪明，才叫工程。

Engineering has created a large patch of idle capacity. Finance cannot find a dollar of savings. The problem with Token Efficiency is suddenly obvious: it has never been an isolated technical metric. Change the billing model, and its financial meaning changes with it.

In The Era of Burning Tokens Wildly Is Coming to an End, I called tokens the new COGS of the AI era. That claim carries an assumption: the enterprise buys the model by the token.

Push the question one step further. Does an enterprise have to buy tokens?

Of course not. It can buy an API by usage, rent GPUs by time, purchase provisioned throughput, or bury AI inside SaaS seats, credits, and bundles. The same model may run underneath all four, while finance sees four completely different businesses.

One Model, Four Completely Different Bills

A lot of Token Efficiency debates go nowhere because everyone is holding a different invoice while trying to use the same metric.

A customer paying by the token cares how much less the model says. A team renting GPUs cares whether the machines stay busy. A buyer of managed capacity cares whether it can step down to a smaller commitment. A SaaS customer may not see tokens at all. It only sees the credit balance running out.

Technology can share a benchmark. Economics cannot.

Buying Tokens: Every Token Saved Can Reach the Invoice

A token API is the serverless model of the AI era.

There are no machines to buy, no inference framework to operate, and no need to predict capacity six months ahead. Call it 100 times today and pay for 100 calls. Jump to a million tomorrow and the model provider absorbs the peak. For proofs of concept, low-frequency tasks, long-tail workflows, and products with wildly unstable traffic, this is usually the right place to start.

On this bill, Token Efficiency is straightforward.

Shorten context. Use prompt caching. Route simple tasks to smaller models. Stop useless reasoning early. Replace LLM calls with deterministic code where possible. As long as success rates hold, those optimizations appear on next month's invoice.

The risk is equally straightforward. The provider charges by usage, so the enterprise pays for every round of overthinking, every retry, and every swollen context window. Model rankings can look beautiful. The customer still pays for the tokens.

With usage-based token pricing, Token Efficiency is a cash metric.

Renting GPUs: Tokens Disappear, Idle Time Arrives

An enterprise can also bypass token pricing and rent GPUs directly from an AI cloud.

This is already a mature market. Together AI Dedicated Endpoints bill for hardware runtime whether requests arrive or not. Fireworks On-demand Deployments bill by the GPU-second. Lambda offers hourly GPU instances and reserved capacity.

The bill moves from a language unit back to a time unit.

At that point, whether a task consumes 40,000 or 100,000 tokens no longer determines cost directly. The real equation becomes:

If fewer tokens let the same eight GPUs process twice as many requests, that improvement is valuable. If traffic does not grow and the GPU count does not fall, the optimization has only created more empty machine time.

Turning that headroom into money requires at least one concrete change: rent one fewer GPU, move to a lower capacity tier, shorten runtime, or postpone the next expansion.

The most valuable engineering work changes too. Continuous batching, KV cache, quantization, concurrency scheduling, model size, memory footprint, and autoscaling can matter more than deleting a few lines from a prompt.

There is another constraint people often miss: renting GPUs does not give you GPT or Claude. Customers do not have proprietary model weights. Raw GPU capacity mainly hosts open models, in-house models, and deployable fine-tuned models.

When you buy GPUs, Token Efficiency matters only when it reaches GPU count and utilization.

GPU rental also hands another pile of work back to the enterprise: deployment, upgrades, disaster recovery, latency, capacity planning, inference frameworks, and the alert that fires at 3 a.m. Removing the model vendor's margin does not make those capabilities free.

Managed Capacity: Cloud Vendors Turn GPUs Into Throughput Plans

Most enterprises do not want to operate a row of raw GPUs. They are more likely to buy the middle layer: managed inference capacity.

With Amazon Bedrock Provisioned Throughput, an enterprise purchases model units and a commitment term, with billing continuing by the hour. Microsoft Foundry offers provisioned capacity billed through PTUs, and idle capacity still costs money.

The buyer does not need to know exactly how many cards run underneath. It buys stable throughput, latency SLOs, identity controls, and cloud governance. This fits enterprise procurement well: technical details stay with the vendor, while capacity risk moves into the contract.

The trap is in the contract too.

Suppose an enterprise has already purchased six months of provisioned throughput. Engineering cuts token usage by 40%. As long as the commitment stays unchanged, the month's bill does not move. The optimization creates headroom. Savings arrive only when the company reduces model units, lowers the renewal commitment, or uses the freed capacity to absorb more business.

Until capacity is released, the optimization has not become cash.

That does not make the optimization worthless. More headroom, shorter queues, and steadier latency all matter. The financial language simply needs to stay honest: a capacity gain is a capacity gain; a cash saving is a cash saving.

SaaS: Tokens Hide Inside Seats, Credits, and Actions

At the SaaS layer, the bill becomes even more complicated.

Enterprise AI products rarely have one price anymore. Salesforce Agentforce offers Flex Credits, per-conversation and per-user options, pre-purchase, pre-commit, and PayGo models. The same product family includes fixed seats, action-based credits, and unmetered usage.

That pricing looks messy because three forces are pulling against one another. Customers want predictable budgets. Usage remains highly uncertain. The inference cost underneath changes with the model and the workflow.

For the customer, tokens become a purchasable SKU. For the SaaS vendor, tokens remain COGS. It needs model routing, caching, quotas, fair-use rules, plan segmentation, and overage controls so one heavy user does not consume the gross margin of an entire tier.

Fixed seats fit low-frequency, controllable-cost features. Credits fit volatile Agents. Commitments fit large, stable customers. PayGo catches unknown demand. No single model covers everything.

SaaS sells a procurement-friendly package. Tokens are the cost hidden underneath.

Enterprise Cloud Reality: AI Never Lands on a Blank Page

The easiest thing to forget in the "tokens or GPUs" debate is that enterprises have already spent a decade living in the cloud.

Data sits in Snowflake, BigQuery, S3, and SaaS applications. Identity lives in IAM or Entra ID. Logs flow into an observability platform. Security, compliance, networking, and procurement have already been built around AWS, Azure, and Google Cloud. A different AI cloud may offer a cheaper GPU and create data movement, private links, duplicate monitoring, extra audits, and a new layer of vendor risk at the same time.

The Flexera 2026 State of the Cloud Report shows the shape of that estate. Seventy-three percent of organizations use hybrid cloud. The share of enterprise workloads in public cloud rose from 52% to 54%, and 51% of enterprise data is already there. The data plane and control plane were in place before the AI workload arrived.

AI clouds are adapting to this reality too. CoreWeave Direct Connect links CoreWeave VPCs directly to customer on-premises or hyperscaler networks. Enterprises are unlikely to move their entire estate for AI. They are more likely to attach another compute pipe to the cloud they already have.

Commitments make the picture even more practical. AWS Savings Plans exchange lower rates for a one- or three-year hourly usage commitment. A team's bill does not fall automatically because it ran less this month. When the commitment remains underused, the "saving" is just lower utilization.

The State of FinOps 2026 data is revealing: 98% of respondents manage AI spend; 90% manage or plan to manage SaaS, 57% manage private cloud, 48% manage data centers, and 28% are beginning or planning to include labor cost. The FinOps Foundation even changed its mission from the value of "cloud" to the value of "technology."

That is the actual backdrop for enterprise AI. The model invoice is one piece of technology spend, standing beside cloud commitments, SaaS licenses, data platforms, security, networking, operations, and labor.

The cheapest price per million tokens may therefore be more expensive for the enterprise P&L. A model with a higher unit price can still win if it consumes an existing commitment, reuses the security stack, and runs close to the data.

The enterprise is optimizing an entire technology balance sheet. One model call is only a line item.

The Practical Architecture Is Baseload Plus Peaks

Enterprises are unlikely to make a single choice between token APIs and GPUs.

They will split workloads the way they have managed cloud infrastructure for the past decade. Stable, predictable baseload goes to reserved GPUs or provisioned throughput. New products, low-frequency tasks, rare models, and bursts stay on token APIs. Workflows already embedded in CRM, ERP, or ITSM are purchased as SaaS bundles.

The analogy is the power grid. Baseload plants handle steady demand; peaker plants handle sudden spikes. Making expensive serverless capacity carry the annual baseline is wasteful. Keeping monthly GPUs idle for a two-hour daily peak is wasteful too.

The valuable capability has expanded beyond shortening a single call. It is the ability to recognize the shape of a workload: how stable it is, how wide the peak-to-trough gap is, what latency it needs, where the data lives, how often the model changes, and whether a capacity commitment can stay full.

The future of Token Efficiency is workload placement.

Ask Which Line Disappeared From the Bill

Token Efficiency still matters, but it needs a more honest denominator:

With an API, the paid resource is token dollars. With rented GPUs, it is GPU-hours. With managed capacity, it is committed model units. With SaaS, it is seats, credits, and plans.

Tokens per task can measure engineering progress. It becomes financial savings only after it removes a billable unit. Otherwise, it has created throughput, latency improvement, or capacity headroom. Those are valuable too. Just do not put them in the wrong column.

Tokens will keep getting cheaper. Models will keep finding new ways to burn them back. The way out is to align the shape of the workload with the pricing model.

The next time someone announces a 60% improvement in Token Efficiency, do not applaud yet. Open next month's invoice and ask: which line actually disappeared?

工程师优化出一大片空闲算力，财务却找不到一美元 Savings。Token Efficiency 的问题就这样暴露了：它从来不是一个孤立的技术指标，计费方式一变，财务含义就跟着变。

上一篇《疯狂烧 Token 的日子要结束了》里，我把 Token 称为 AI 时代新的 COGS。这个判断隐含了一个前提：企业按 Token 买模型。

继续追问一步：企业一定要买 Token 吗？

当然不一定。它可以按调用量买 API，按时间租 GPU，按吞吐购买 Provisioned Throughput，也可以把 AI 藏进 SaaS 的 Seat、Credit 和套餐里。底层跑的可能是同一个模型，财务看到的却是四门完全不同的生意。

同一个模型，四张完全不同的账

很多 Token Efficiency 的争论之所以鸡同鸭讲，是因为大家拿着不同的账单，却试图使用同一个指标。

按 Token 付费的人，关心模型少说了多少。租 GPU 的人，关心机器有没有吃满。买托管容量的人，关心承诺档位能不能降。买 SaaS 的人，甚至看不到 Token，只会看到 Credit 快用完了。

技术可以用同一套 Benchmark，经济账不行。

买 Token：省下来的每一个 Token 都能进账单

Token API 是 AI 时代的 Serverless。

不用买机器，不用管推理框架，不用预测半年后的容量。今天调用 100 次就付 100 次，明天突然涨到 100 万次，模型厂商替你扛峰值。对 PoC、低频任务、长尾 Workflow 和流量极不稳定的新产品，这通常是最合理的起点。

在这张账上，Token Efficiency 很直接。

缩短 Context、做 Prompt Caching、把简单任务路由给小模型、提前结束无效 Reasoning、用确定性代码替代 LLM 调用，这些优化只要不伤成功率，就会体现在下个月账单里。

风险也很直接：模型厂商按使用量收钱，企业承担每一次过度思考、重试和上下文膨胀。模型能力榜排得再漂亮，最后还是客户替 Token 买单。

按量买 Token，Token Efficiency 才是现金指标。

租 GPU：Token 消失了，空转出现了

企业也可以绕过 Token 单价，直接向 AI Cloud 租 GPU。

这条路已经很成熟。Together AI 的 Dedicated Endpoint按硬件运行时间计费，不管有没有请求；Fireworks 的 On-demand Deployment按 GPU-second 计费；Lambda则提供按小时的 GPU Instance 和预留容量。

账单从语言单位切回了时间单位。

此时，一次任务用了 4 万还是 10 万 Token，已经不再直接决定成本。真正的公式变成：

如果 Token 降低让同样的 8 张 GPU 多处理一倍请求，当然有价值。如果流量没有增长，GPU 数也没减少，那只是空出了更多机器时间。

想把这部分 Headroom 变成钱，至少要发生一件事：少租一张 GPU、降低一个容量档位、缩短运行时间，或者推迟下一轮扩容。

这时最重要的优化也会变化。Continuous Batching、KV Cache、Quantization、并发调度、模型大小、显存占用和 Autoscaling，往往比删掉几句 Prompt 更值钱。

还有一个常被忽略的限制：租 GPU 不等于租到 GPT 或 Claude。闭源模型权重不在客户手里，裸 GPU 主要承载开源模型、自有模型和可部署的 Fine-tuned Model。

按 GPU 买，Token Efficiency 只有穿透到 GPU 数量和利用率时才成立。

GPU 租赁也把另一堆麻烦交回企业：模型部署、升级、容灾、延迟、容量预测、推理框架和夜里三点的告警。省掉模型厂商的 Margin，不代表这部分能力凭空免费。

托管容量：云厂商把 GPU 换成吞吐套餐

大多数企业不会直接管理一排裸 GPU。它们更可能购买中间态：托管推理容量。

比如 Amazon Bedrock Provisioned Throughput，企业购买 Model Unit 和承诺期限，账单按小时产生；Microsoft Foundry也提供按 PTU 计费的 Provisioned Capacity，闲置时照样收费。

企业不需要知道底下到底跑了几张卡，只需要拿到稳定吞吐、延迟 SLO、权限体系和云上治理。这很符合企业采购习惯：技术细节交给厂商，容量风险留在合同里。

麻烦也在合同里。

假设企业已经买了 6 个月 Provisioned Throughput。工程团队把 Token 降低 40%，只要承诺容量没变，当月账单就不会动。优化带来的是更高余量，真正的 Savings 要等到缩减 Model Unit、降低续约承诺，或者用这部分容量接住更多业务。

容量没有被退掉，优化就还没变成现金。

这不代表优化没价值。更大的 Headroom、更低的排队时间、更稳的延迟都很重要。财务语言必须诚实：Capacity Gain 是 Capacity Gain，Cash Saving 是 Cash Saving。

SaaS：Token 被藏进 Seat、Credit 和 Action

到了 SaaS 层，账更复杂。

今天的企业 AI 产品很少只有一种价格。Salesforce Agentforce同时提供 Flex Credits、按 Conversation、按 User、Pre-Purchase、Pre-Commit 和 PayGo；同一个产品里，既有固定 Seat，也有按 Action 消耗的 Credit，还有 Unmetered Usage。

这些定价看起来很乱，背后是三股力量在拉扯：客户需要预算可预测，使用量又高度不确定，底层推理成本还会随模型和 Workflow 改变。

对客户来说，Token 被包装成了可采购的 SKU。对 SaaS 厂商来说，Token 仍然是 COGS。它需要做 Model Routing、Cache、配额、Fair Use、套餐分层和 Overage，防止某个重度客户把整档产品的 Gross Margin 吃光。

固定 Seat 适合使用频率低、成本可控的功能；Credit 适合波动大的 Agent；预承诺适合稳定的大客户；PayGo 用来接住未知需求。没有一种模式能通吃。

SaaS 卖的是可采购性，Token 只是藏在背后的成本。

企业云上的现实：AI 从来不会落在一张白纸上

讨论“买 Token 还是租 GPU”时，最容易忽略企业已经在云上生活了十年。

数据在 Snowflake、BigQuery、S3 和各种 SaaS 里，身份在 IAM 或 Entra ID，日志进了 Observability 平台，安全、合规、网络和采购流程也已经围绕 AWS、Azure、Google Cloud 建好。换一家 AI Cloud 可能让 GPU 单价更低，也可能同时制造数据搬运、专线、审计、双套监控和新的 Vendor Risk。

Flexera 2026 State of the Cloud Report 显示，73% 的组织采用 Hybrid Cloud；企业运行在 Public Cloud 上的 Workload 已从 52% 升到 54%，51% 的企业数据也已经在 Public Cloud。AI Workload 到来之前，Data Plane 和 Control Plane 早就落位了。

AI Cloud 自己也在适应这个现实。CoreWeave Direct Connect 的用途，就是把 CoreWeave VPC 直接连到企业 On-premises 或 Hyperscaler Network。企业不会为了 AI 整体搬家，更可能给现有云再接一根算力管道。

更现实的是，企业早就签了各种 Commitment。AWS Savings Plans按每小时用量承诺一到三年。账单不会因为某个团队这个月少跑一点就自动下降；承诺没吃满，省下来的只是 Utilization。

State of FinOps 2026 的数据很有意思：98% 的受访者管理 AI Spend；90% 已经或计划管理 SaaS，57% 管理 Private Cloud，48% 管理 Data Center，28% 开始或计划把 Labor Cost 纳入同一套体系。FinOps Foundation 也把使命里的 "Cloud" 改成了 "Technology"。

这就是企业 AI 的真实背景：模型账单只是技术支出的一部分，旁边还站着云承诺、SaaS License、数据平台、安全、网络、运维和人。

所以，“每百万 Token 最便宜”的方案，未必是企业 P&L 最便宜的方案。一个单价更高、却能吃掉现有 Commitment、复用安全体系、靠近数据的模型，可能反而更便宜。

企业优化的是整张技术资产负债表，一次调用只是其中一行。

最现实的架构，是基线加波峰

企业最终很可能不会在 Token API 和 GPU 之间二选一。

它会像过去十年管理云资源一样，把 Workload 拆开：稳定、可预测的基线流量放进 Reserved GPU 或 Provisioned Throughput；新业务、低频任务、稀有模型和突发流量继续走 Token API；已经深嵌 CRM、ERP、ITSM 的流程直接买 SaaS 套餐。

这和电网很像。基荷电厂负责稳定需求，调峰机组处理突然上来的波峰。让昂贵的 Serverless 扛全年基线很浪费，让包月 GPU 等每天两小时的峰值同样浪费。

真正有价值的能力，已经从压短一次调用，扩展到识别 Workload 的形状：它有多稳定，峰谷差多大，延迟要求多高，数据在哪里，模型多久换一次，容量承诺能不能吃满。

未来的 Token Efficiency，本质上是 Workload Placement。

先问账单少了哪一行

Token Efficiency 仍然重要，但它需要一个更诚实的分母：

按 API 买，Paid Resource 是 Token Dollar；按 GPU 租，是 GPU-hour；买托管容量，是承诺的 Model Unit；买 SaaS，是 Seat、Credit 和套餐。

Tokens per Task 可以衡量工程进步。只有当它最终减掉一个可计费单位，才会变成财务 Savings。否则，它带来的是吞吐、延迟或容量余量——同样有价值，只是别算错账。

Token 会继续变便宜，模型也会继续找到新的方式把 Token 烧回去。真正的出路，是让 Workload 的形状和 Pricing Model 对齐。

下次有人宣布 Token Efficiency 提升 60%，先别鼓掌。翻开下个月账单：到底少了哪一行？

最出名的叫“传说中的海力士员工”。2008 年前后，公司里的人觉得买自家股票是疯了，他却拿 4,446 万韩元，以 7,800 韩元买下 5,700 股。如果一直没卖，到 2026 年 1 月已经值 41 亿韩元。

最近另一篇帖子又在韩国社区刷屏。发帖人自称来自 SK hynix 某设计团队，身边一半以上的人持有超过 1 亿韩元的公司股票，连入职两年的新人也过了亿。网友顺手把故事继续往下编：“2028 年新员工年薪 4 亿”，再配一张 AI 生成的“2026 年海力士停车场”——放眼望去，全是 Ferrari。

这些匿名帖子不能当财报，却很适合当情绪指标。当一个市场开始批量生产暴富传说，最赚钱的共识通常已经形成。

这个共识有名字：存储。SK hynix 从周期底部涨了三倍多，KOSPI 也一路刷新纪录。HBM 先被数据中心吃紧，DRAM 和 enterprise SSD 随后进入上行周期，SK hynix、Samsung、SanDisk 从周期股涨成 AI 交易的中心。到了这个位置，再证明“AI 需要更多存储”已经没有价值。真正有价值的问题是：从今天的价格出发，存储之后，聪明钱会流向哪里？

最顺手的答案是 Edge SoC、AI PC 和先进封装。数据中心先买 HBM，接下来几十亿台 PC、手机、汽车、机器人和眼镜开始跑模型，算力从云端下沉，资金沿产业链继续接力。这个故事好懂，也好卖。

可市场不会按产业链顺序发钱。

一台手机多 4GB 内存、加一颗 NPU，和 hyperscaler 新建几吉瓦的数据中心，根本不是同一笔生意。前者按十亿台计算，后者只有几十个客户；可一个客户的资本开支，就足以重写 GPU、HBM、网络、电力和冷却的收入曲线。把“端侧 AI 会普及”直接推导成“端侧会成为最大的 AI 利润池”，中间偷偷换了分母。

所以，接下来不能只看端侧。训练还在扩容，Cloud inference 正在工业化，AI PC 和 Edge device 也刚开始下沉。真正值得研究的，是 AI 算力如何从数据中心扩散到 PC、手机、汽车、机器人和眼镜，以及每一层究竟能留下多少收入、利润和自由现金流。

设备数量制造叙事，资本密度、定价权和供给瓶颈决定利润。

先把“整个 AI 市场”这个分母算对

“AI 市场”可以包含模型订阅、Cloud service、数据中心设备、半导体、手机和软件。如果把这些东西全塞进一个数字，端侧份额没有分析价值。本文讨论的是个人投资者最容易映射到上市公司的两块：AI 半导体与 AI 基础设施。

Omdia 对 Edge AI processor 的估算覆盖手机、PC、平板、机器人和无人机等十类设备，到 2028 年约 600 亿美元。另一份 Omdia 预测显示，数据中心 GPU 与 AI accelerator 在 2025 年已经达到约 2070 亿美元，2030 年约 2860 亿美元。

两份报告的口径和年份并不完全一致，不能拿来计算小数点后的精确份额。把它们做数量级拼接，结论已经很清楚：到 2028 年前后，端侧 AI processor 的价值量大致只有数据中心 AI processor 的五分之一；再把 HBM、网络、存储、电源、冷却和机房建设算进去，端侧在整个 AI 硬件收入池中的占比只能做区间判断，更可能落在 10%—20%，并且接近下沿。

另一个对比更直观。NVIDIA 最近一个季度的数据中心收入达到 752 亿美元，已经超过 Omdia 对 2028 年整个 Edge AI processor 市场的年度预测。IDC 预计 2026 年数据中心半导体收入约 4771 亿美元，而整个 Mobile semiconductor 市场约 898 亿美元。

口径依旧不完美，结论却不会反转：端侧可以拥有数十亿台设备，却未必拥有最大的利润池。如果把 Cloud AI service、模型订阅和企业软件也纳入“整个 AI 行业”，端侧硬件的收入占比还会更低。

设备数量决定想象空间，单机价值量和定价权决定利润。

AI 的三条增长曲线正在同时发生

把 AI 发展理解成“云端结束，端侧接棒”，会错过当前最重要的变化。训练还在扩容，推理正在工业化，端侧才刚开始下沉。这三条曲线会并行很多年。

训练扩容：最贵，也最集中

Frontier model 继续增加参数、数据和计算量，训练集群从万卡走向十万卡，利润集中在 GPU、HBM、先进封装、scale-up/scale-out 网络、电源和冷却。NVIDIA 与 SK hynix 是这条曲线最直接的受益者，TSMC、Broadcom、光互连和电力基础设施赚的是瓶颈钱。

这一层的优势是收入已经兑现，风险也最清楚：hyperscaler 的资本开支能否转化成 AI 收入和自由现金流。我之前在《一年烧 $700B，谁会是下一个摩托罗拉？》里讨论的，正是这条曲线的天花板。

推理扩容：从“算得出来”走向“算得起”

模型进入生产环境后，竞争指标从训练速度变成每个 token 的成本、延迟和稳定性。推理量可能远超训练量，硬件结构却会发生变化：更多 custom ASIC、更低精度计算、更复杂的 memory hierarchy，以及更高密度的网络连接。

Broadcom 和 Marvell 的 custom silicon 与 networking 收入正在加速，说明聪明钱暂时还没有离开数据中心。它只是在数据中心内部，从通用 GPU 向 ASIC、交换芯片、光互连、CXL 和电力系统扩散。

AI 第一阶段买算力，第二阶段买每瓦、每美元和每秒能交付多少有效 token。

推理下沉：把模型能力变成数十亿个高频入口

AI PC、手机、汽车、机器人、摄像头和眼镜会承接隐私敏感、低时延、持续感知和离线任务。复杂推理仍会回到云端，本地负责唤醒、个人上下文、传感器融合和轻量模型。

端侧因此会增加 NPU、LPDDR、NAND、传感器、电源管理和安全芯片的单机价值，也会制造新的软件入口。但它短期更像云端 AI 的分发层，收入取决于两个问题：用户是否真的高频使用，以及新增价值能否转化成更高 ASP 或更短换机周期。

存储的逻辑比原来更强，也更危险

把分母扩大到整个 AI 行业后，存储的上涨逻辑反而更扎实。今天的核心需求来自数据中心，端侧只是后续增量。

HBM 直接绑定 accelerator 出货和单卡容量，企业级 SSD 吃到训练数据、checkpoint、RAG 和推理缓存，普通 DRAM 与 NAND 又被 HBM 占用晶圆和资本开支间接抬价。即使手机和 PC 出货疲弱，AI 基础设施仍可能把存储维持在高景气区间。

这也意味着，判断存储空间不能只盯 AI 手机渗透率。

HBM 看结构，NAND 看周期

SK hynix 的核心变量是 HBM 份额、良率、客户认证和供给纪律。它赚的是数据中心 AI 的结构性增长，端侧 LPDDR 只是锦上添花。

Micron 同时暴露于 HBM、服务器 DRAM、数据中心 SSD 和 Client memory。在美股里，它比 SanDisk 更接近“整个 AI memory cycle”的映射。

SanDisk 的弹性主要来自 NAND 价格、enterprise SSD mix 和供给收缩。Edge device 增加存储容量会提供第二层需求，但 NAND 一旦恢复扩产，价格弹性也会最快反转。

Samsung 横跨 HBM、DRAM、NAND、Foundry、手机和 SoC，理论上拥有最完整的云端到端侧链条。现实里的收益取决于 HBM 追赶、先进制程利用率和终端竞争力能否同时兑现。

存储还有上升空间，赔率已经换了

后续空间取决于三件事：数据中心资本开支继续上修、HBM 与企业级 SSD 供给保持紧张、三大厂没有为了份额重新大规模扩产。端侧爆发能够延长周期，却很难在供给失控时拯救价格。

所以，存储仍可能继续创造利润新高，股票收益率却不再来自简单的估值修复。接下来赚的是供给纪律和盈利上修持续时间的钱。

存储景气的核心分母仍是数据中心，端侧负责把周期拉长，不负责独自启动下一轮。

存储之后，第一层机会仍藏在数据中心

市场很喜欢寻找“AI 的下一个板块”，好像资金必须离开已经上涨的东西，流向一块全新的地方。现实通常没有这么整齐。只要数据中心收入和订单仍在加速，新的利润池会先在同一个系统里出现。

Custom silicon 与网络

Hyperscaler 希望降低 token 成本、摆脱单一供应商，并针对自己的模型优化芯片。Custom ASIC 的份额会提高，但它不会减少对先进制程、HBM、封装和高速网络的需求。Broadcom、Marvell、TSMC、EDA/IP 和交换芯片因此处于同一条增长链上。

网络的重要性还会随集群规模上升。单颗 accelerator 再快，数据搬不动也没用。Scale-up、scale-out、光互连和 CXL 正从配角变成系统瓶颈。

这层机会的风险来自客户集中、估值和 hyperscaler 自研能力。订单很大，不代表利润会平均分配。

电力、散热与机房

当 AI 集群从芯片问题变成吉瓦问题，价值会继续向变压器、配电、UPS、液冷和热管理迁移。数据中心能否按时上线，越来越取决于电力接入和冷却，而不是芯片有没有出货。

这一层的好处是技术路线更分散：GPU、ASIC 谁赢，都要用电、配电和散热。风险在于资本开支周期、项目延迟和工业品估值扩张过快。

Foundry 与先进封装

无论 NVIDIA GPU、hyperscaler ASIC，还是 AI PC SoC，最终都要落到先进制程、chiplet 和封装。TSMC 同时吃到云端与端侧，最接近“无需押具体架构”的卖铲人。

Amkor 和 ASE 受益于封装复杂度提升，但商业模式资本密集，收入增长能否转化为每股自由现金流，需要继续看利用率和定价权。

Intel 也应该放在这张地图里。18A 已进入量产爬坡，18A-P 进入 risk production，14A 仍在 PDK 和客户 test chip 阶段；EMIB 与 Foveros 又提供先进封装能力。它拥有云端、AI PC、Foundry 和 Packaging 四重暴露，外部客户、良率、利用率和毛利率仍需逐项验证。

制程能跑通，只解决技术问题；客户愿意下单、产能能够赚钱，才解决投资问题。

风险收益比更好的位置，可能是“双重暴露”

纯数据中心公司拥有最强的当期增长，纯端侧公司拥有最大的远期弹性。对个人投资者更友好的位置，可能夹在两者之间：当前靠数据中心兑现收入，未来又能从 AI PC 和 Edge device 获得第二条曲线。

TSMC 同时制造 GPU、ASIC、手机和 PC SoC，还拥有先进封装；Arm 的 IP 覆盖服务器、PC、手机、汽车和 IoT；AMD 当前增长来自数据中心，又在 AI PC 与 Embedded 保留端侧入口；Micron 同时卖 HBM、服务器内存和 Client memory。这些公司不需要端侧明天爆发，端侧兑现后又能获得额外增长。

代价当然存在。Arm 的增长质量高，估值也会压缩未来收益率；AMD 要证明 accelerator 份额和软件生态；TSMC 面临地缘政治与资本密集度；Micron 仍逃不开存储周期。

Qualcomm、MediaTek 和其他 Client SoC 厂商更接近端侧纯期权。它们的上行弹性很大，前提是 NPU 从标配变成 ASP、毛利率和换机率。MediaTek 主挂牌台交所，不能把它当成普通美股标的；Qualcomm 的数据中心布局提供了新可能，利润表目前仍由手机、汽车和 IoT 决定。

Intel 的位置更特殊：它同时拥有双重暴露和高风险反转。成功时弹性巨大，失败时资本开支会继续吞噬现金流。

与其押端侧在哪一年爆发，不如先找云端继续扩张时能赚钱、端侧兑现时还能再长一层的公司。

端侧什么时候才从“配置”变成“利润”

AI PC 和 GenAI smartphone 的渗透率可以很快提高，因为新芯片会自然进入产品线。渗透率增长不代表新增销量，也不代表用户愿意支付溢价。

Gartner 曾预计 2026 年 AI PC 占 PC 出货量约 55%，今年初已有报道显示该预测下调到约 49%，原因包括高溢价、内存短缺和缺乏 must-have software。IDC 同时预计 2026 年 PC 出货下滑、ASP 大幅上升。硬件配置在普及，换机需求却没有同步爆发。

端侧进入利润表，需要四个信号同时出现：

1. AI 功能的月活和任务完成率持续提高；
2. 本地推理占比上升，云端 offload 不再覆盖大部分价值；
3. NPU、内存和存储升级能够提高 ASP 与毛利率；
4. AI 让用户提前换机，而不只是随正常换机获得新功能。

AI 眼镜、机器人和汽车还要再加一条：多设备协同必须形成新的购买行为，而不是把手机能力换一个屏幕展示。

AI 标签统计出货，任务成功率统计收入。

聪明钱应该按兑现顺序排队

股票排序不能看谁涨得少。涨幅只记录过去，未来收益率取决于新增自由现金流、兑现概率、当前估值和失败时的损失。

我会把研究顺序分成四层：

第一层：已经兑现的数据中心瓶颈

GPU、HBM、custom silicon、networking、电力与冷却拥有最清楚的订单和收入。行业增长相对清楚，真正难判断的是估值是否透支，以及资本开支何时见顶。

第二层：云端与端侧的双重暴露

Foundry、先进封装、Arm IP、同时覆盖 Data Center 与 Client 的处理器和内存，能够跨越三条增长曲线。它们通常不是弹性最大的交易，却可能提供更好的 risk-adjusted return。

第三层：端侧纯期权

Qualcomm、MediaTek、Client NPU、低功耗传感器、安全芯片和电源管理，需要等使用率、ASP 和换机周期给出证据。这一层最容易出现预期差，也最容易被发布会叙事骗进去。

第四层：按供给管理的周期仓

SK hynix、Micron、Samsung 和 SanDisk 不能只按“AI 长期增长”持有。HBM、DRAM、NAND 的供给、库存和资本开支一旦变化，仓位也要变化。

这套排序不会给出一只永远排第一的股票。Arm 的增长天花板、Broadcom 的当前兑现、TSMC 的平台地位、Qualcomm 的端侧弹性、Intel 的反转赔率，分别对应不同的胜率和赔率。

六个节点会让整套逻辑重新定价

Hyperscaler 的 AI 收入能否追上 Capex

数据中心是最大分母，也是最大风险源。一旦 AI 收入、利用率或自由现金流无法支撑资本开支，GPU、HBM、网络、光模块和电力设备会一起下修。端侧的长期故事救不了短期订单。

推理需求能否抵消模型效率提升

量化、蒸馏、稀疏化和 custom ASIC 会降低单次推理成本。成本下降可能压缩硬件需求，也可能触发 Jevons paradox，让 token 使用量增长得更快。决定结果的是总推理量，不是单个模型变小了多少。

Memory supply 何时真正释放

HBM 良率、新晶圆厂、先进封装和 NAND 扩产只要同时改善，存储价格就会先于需求转弱。这里要看 bit supply、客户库存、长约和 Capex，而不是等毛利率见顶。

Agent 是否跨过可靠性门槛

端侧真正需要的是常驻、个性化、跨应用执行。Agent 如果仍会在权限、支付、状态和错误恢复上掉链子，AI PC 和手机只完成配置升级，无法缩短换机周期。

云端与本地的经济账

Cloud inference 持续降价，会延长旧设备寿命；隐私、时延、网络和持续订阅成本则会推动任务下沉。最终架构由每个任务的总成本决定，不由发布会决定。

电力与地缘政治

电网接入、能源价格、出口限制、先进制程产能和区域补贴，都可能改变赢家。AI 越资本密集，政策变量越难忽略。

三种情景下，钱会流向不同位置

基准情景下，数据中心仍是未来几年最大的 AI 利润池，推理基础设施是最清楚的第二条曲线，端侧提供长期可选性。乐观情景才会让手机、AI PC、眼镜和机器人同时贡献硬件增量。受阻情景里，端侧渗透率依旧可能提高，但它只会成为默认配置，不会创造新的超级周期。

存储之后，答案不在一个板块里

回到最初的问题：存储是否还有空间？有，核心驱动力仍是数据中心，端侧会增加持续时间和第二层需求；供给一旦释放，NAND 和普通 DRAM 的风险也会迅速暴露。

除了存储，第二梯队是谁？眼下最清楚的答案仍在数据中心内部：custom silicon、networking、光互连、电力、冷却、Foundry 和先进封装。端侧 SoC、AI PC 与 Edge device 是后续弹性更大的第三层。

从个人投资角度，风险收益比更值得研究的是双重暴露：今天能从云端 Capex 赚钱，明天又能吃到端侧下沉。它们未必涨得最猛，却不需要最脆弱的假设才能成立。

聪明钱真正寻找的，是下一道供给最难扩、需求最先兑现、价格又没有把未来全部买走的瓶颈。

当 token 从机房流向数十亿台设备，谁只能赚一次，谁能沿途收两遍钱？

The best-known story is the "legendary SK hynix employee." Around 2008, when people inside the company thought buying its stock was crazy, he put KRW 44.46 million into 5,700 shares at KRW 7,800. Had he held them through January 2026, the stake would have been worth about KRW 4.1 billion.

More recently, another post spread across Korean communities. The author claimed to work on an SK hynix design team and said more than half the people around him held over KRW 100 million in company stock, including someone only two years into the job. The internet extended the story from there: "new hires will make KRW 400 million in 2028," accompanied by an AI-generated image titled "SK hynix's 2026 parking lot"—Ferraris as far as the eye could see.

Anonymous posts are not financial statements, but they are excellent sentiment indicators. When a market starts mass-producing get-rich legends, the most profitable consensus has usually already formed.

That consensus has a name: memory. SK hynix rose more than threefold from the cycle bottom, while the KOSPI kept setting records. Data centers tightened HBM supply first, then pulled DRAM and enterprise SSDs into the same upcycle. SK hynix, Samsung, and SanDisk went from cyclical stocks to the center of the AI trade. At this point, proving that "AI needs more memory" adds little. The question that matters is: from today's prices, where will smart money flow after memory?

The easiest answer is edge SoCs, AI PCs, and advanced packaging. Data centers bought HBM first. Next, billions of PCs, phones, cars, robots, and glasses begin running models, compute moves from the cloud toward devices, and capital continues down the supply chain. It is a clean story, and an easy one to sell.

But markets do not pay investors in supply-chain order.

A phone adding 4 GB of memory and a stronger NPU is not the same business as a hyperscaler building several gigawatts of new data-center capacity. The first market is measured in billions of devices; the second has only a few dozen major buyers. Yet one buyer's capital spending can rewrite the revenue curve for GPUs, HBM, networking, power, and cooling. Moving directly from "edge AI will become widespread" to "the edge will become AI's largest profit pool" quietly changes the denominator.

The analysis therefore cannot stop at the edge. Training is still expanding, cloud inference is becoming industrialized, and AI PCs and edge devices are only beginning to scale. The real question is how AI compute spreads from data centers into PCs, phones, cars, robots, and glasses—and how much revenue, profit, and free cash flow each layer can actually retain.

Unit volume creates the story. Capital intensity, pricing power, and bottlenecks create the profit.

Start With the Right Denominator

The "AI market" can include model subscriptions, cloud services, data-center equipment, semiconductors, devices, and software. Put all of them into one number and the edge share becomes meaningless. This article focuses on the two pools that map most directly to public companies: AI semiconductors and AI infrastructure.

Omdia's edge AI processor estimate covers ten device categories, including phones, PCs, tablets, robots, and drones. It puts the market at roughly $60 billion in 2028. A separate Omdia forecast puts data-center GPUs and AI accelerators at about $207 billion in 2025 and $286 billion in 2030.

The definitions and years do not line up perfectly, so they cannot produce a precise market-share calculation. Stitching them together only for scale still gives a clear result: around 2028, edge AI processor value may be roughly one-fifth of data-center AI processor value. Add HBM, networking, storage, power, cooling, and facility construction, and only a range is defensible: the edge may represent roughly 10% to 20% of the overall AI hardware revenue pool, likely toward the lower end.

Another comparison makes the gap easier to see. NVIDIA generated $75.2 billion in data-center revenue in its latest quarter, already more than Omdia's annual forecast for the entire edge AI processor market in 2028. IDC expects data-center semiconductor revenue to reach roughly $477.1 billion in 2026, versus about $89.8 billion for the entire mobile semiconductor market.

The categories still do not match perfectly, but the conclusion survives every reasonable adjustment: billions of edge devices do not automatically create the largest profit pool. Include cloud AI services, model subscriptions, and enterprise software in the denominator, and the edge hardware share becomes smaller still.

Device count creates imagination. Silicon content and pricing power create profit.

Three AI Growth Curves Are Running at Once

The idea that cloud growth ends before the edge takes over misses the most important part of the cycle. Training is still expanding, inference is becoming industrialized, and edge deployment is only beginning. These curves can run in parallel for years.

Training Expansion: The Most Expensive and Concentrated Layer

Frontier models continue to consume more parameters, data, and compute. Training clusters are moving from tens of thousands of accelerators toward hundreds of thousands. Profit concentrates in GPUs, HBM, advanced packaging, scale-up and scale-out networking, power, and cooling. NVIDIA and SK hynix are the most direct beneficiaries, while TSMC, Broadcom, optical interconnect suppliers, and power infrastructure providers monetize the bottlenecks.

This layer has one great advantage: the revenue is already real. Its risk is equally visible. Can hyperscaler capital spending turn into enough AI revenue and free cash flow? That is the ceiling I examined in my earlier article, "$700 Billion a Year: Who Becomes the Next Motorola?"

Inference Expansion: From "Can It Run?" to "Can We Afford to Run It?"

Once models enter production, the key metrics shift from training speed to cost per token, latency, and reliability. Inference volume may eventually dwarf training volume, but the hardware mix will change: more custom ASICs, lower-precision compute, richer memory hierarchies, and denser connectivity.

Broadcom and Marvell are already reporting accelerating custom silicon and networking revenue. Smart money has not left the data center. It is spreading inside the data center—from general-purpose GPUs into ASICs, switches, optical links, CXL, and power systems.

The first phase of AI bought compute. The second buys useful tokens delivered per watt, per dollar, and per second.

Inference Distribution: Turning Model Capability Into Billions of Daily Touchpoints

AI PCs, phones, cars, robots, cameras, and glasses will absorb privacy-sensitive, low-latency, always-on, and offline workloads. Heavy reasoning will still return to the cloud. Local systems will handle wake-up, personal context, sensor fusion, and smaller models.

This raises silicon content in NPUs, LPDDR, NAND, sensors, power management, and secure hardware while creating new software entry points. In the near term, however, the edge acts mainly as the distribution layer for cloud AI. Its revenue depends on two questions: do people use these functions frequently, and can that use become higher ASPs or shorter replacement cycles?

Memory Has a Stronger Thesis—and a More Dangerous One

Once the denominator expands to the entire AI industry, the memory thesis becomes stronger. Data centers drive the current demand; edge devices provide the later increment.

HBM is directly tied to accelerator shipments and memory content per package. Enterprise SSDs benefit from training data, checkpoints, RAG, and inference caching. HBM also absorbs wafer capacity and capital that would otherwise serve commodity DRAM and NAND. AI infrastructure can therefore keep memory tight even while phones and PCs remain weak.

That means smartphone AI penetration alone cannot answer how much upside memory has left.

HBM Is Structural; NAND Remains Cyclical

SK hynix is driven by HBM share, yield, customer qualification, and supply discipline. Its core exposure is structural data-center AI growth. Edge LPDDR is additional upside, not the engine.

Micron spans HBM, server DRAM, data-center SSDs, and client memory. Among U.S.-listed stocks, it maps more directly to the entire AI memory cycle than SanDisk does.

SanDisk has greater sensitivity to NAND pricing, enterprise SSD mix, and supply cuts. More storage per edge device can add a second demand layer, but NAND will also reverse fastest when producers resume expansion.

Samsung spans HBM, DRAM, NAND, foundry, smartphones, and SoCs. In theory, it has the broadest cloud-to-edge exposure. In practice, returns depend on HBM catch-up, advanced-node utilization, and device competitiveness arriving together.

Memory Still Has Upside, but the Odds Have Changed

Further upside requires three things: continued upward revisions to data-center capital spending, tight supply in HBM and enterprise SSDs, and restraint from the three major memory producers. An edge boom can extend the cycle, but it cannot rescue pricing from uncontrolled supply growth.

Memory companies may keep setting profit records. Stock returns, however, no longer come from a simple valuation recovery. The remaining opportunity is a bet on supply discipline and the duration of earnings upgrades.

Data centers remain the denominator for the memory cycle. Edge demand can lengthen it; edge demand cannot launch the next cycle by itself.

The First Opportunities After Memory Are Still Inside the Data Center

Markets love searching for the "next AI sector," as though capital must abandon whatever has already risen and discover an entirely new category. Reality is rarely that clean. As long as data-center orders and revenue are accelerating, new profit pools will first emerge inside the same system.

Custom Silicon and Networking

Hyperscalers want lower token costs, less dependence on any single supplier, and silicon tuned to their models. Custom ASIC share will rise, but that does not eliminate demand for advanced nodes, HBM, packaging, or high-speed networking. Broadcom, Marvell, TSMC, EDA and IP vendors, and switch-silicon suppliers all sit on the same growth chain.

Networking becomes more important as clusters scale. A faster accelerator is useless when data cannot move. Scale-up, scale-out, optical interconnect, and CXL are moving from supporting roles into system bottlenecks.

The risks are customer concentration, valuation, and hyperscalers bringing more design work in-house. Large orders do not guarantee that profit will be distributed evenly.

Power, Cooling, and Facilities

As AI clusters turn from a chip problem into a gigawatt problem, value migrates toward transformers, power distribution, UPS systems, liquid cooling, and thermal management. Data-center commissioning increasingly depends on grid access and cooling capacity, not just accelerator availability.

This layer is relatively agnostic to architecture. GPUs and ASICs both consume power and generate heat. The risks are the capital-spending cycle, project delays, and industrial valuations expanding too far.

Foundry and Advanced Packaging

NVIDIA GPUs, hyperscaler ASICs, and AI PC SoCs all end up at advanced nodes, chiplet integration, and packaging. TSMC participates in both cloud and edge and comes closest to a pick-and-shovel business that does not require choosing the winning architecture.

Amkor and ASE benefit from rising package complexity, but their businesses are capital intensive. Revenue growth only becomes per-share free cash flow when utilization and pricing power cooperate.

Intel belongs on this map as well. Intel 18A is ramping production, 18A-P has entered risk production, and 14A remains at the PDK and customer test-chip stage. EMIB and Foveros add advanced packaging exposure. Intel therefore spans cloud, AI PCs, foundry, and packaging, while external customers, yield, utilization, and gross margin still require separate proof.

A working process solves the engineering problem. Customer orders and profitable utilization solve the investment problem.

Better Risk-Adjusted Returns May Sit in "Dual Exposure"

Pure data-center companies have the strongest current growth. Pure edge companies have the greatest long-duration torque. For an individual investor, the more forgiving position may sit between them: companies that monetize data-center expansion now and gain a second curve when AI PCs and edge devices scale.

TSMC manufactures GPUs, ASICs, phone SoCs, and PC chips while operating advanced packaging. Arm IP spans servers, PCs, phones, cars, and IoT. AMD currently grows through data centers while preserving client and embedded edge exposure. Micron sells HBM, server memory, and client memory. None of these companies needs an edge boom tomorrow, yet each gains another growth leg if it arrives.

There is always a price. Arm has excellent growth quality, but valuation can compress future returns. AMD must prove accelerator share and software execution. TSMC carries geopolitical and capital-intensity risks. Micron remains a memory-cycle company.

Qualcomm, MediaTek, and other client SoC suppliers sit closer to pure edge optionality. Their upside is large only when the NPU moves from a standard feature into ASP, margin, and replacement-rate growth. MediaTek's primary listing is in Taiwan, so it is not a normal U.S. equity exposure. Qualcomm has opened a data-center path, but its current earnings are still driven by handsets, automotive, and IoT.

Intel is a special case: dual exposure combined with a high-risk turnaround. Success creates enormous operating leverage. Failure leaves capital spending consuming cash.

Instead of betting on the exact year edge AI explodes, look for companies that earn money while the cloud expands and add another growth layer when the edge arrives.

When Does the Edge Turn From a Feature Into Profit?

AI PC and generative-AI smartphone penetration can rise quickly because new chips naturally enter product lines. Penetration growth does not guarantee incremental unit demand, and it does not prove that buyers will pay a premium.

Gartner once expected AI PCs to represent about 55% of PC shipments in 2026. Reports earlier this year said the forecast had been cut to roughly 49%, citing high premiums, memory shortages, and a lack of must-have software. IDC, meanwhile, expects PC shipments to fall in 2026 while ASPs rise sharply. Hardware capability is spreading; replacement demand is not keeping pace.

The edge has to produce four signals before it reaches the income statement:

1. Monthly active use and task-completion rates keep rising;
2. The local share of inference rises instead of leaving most of the value in cloud offload;
3. NPU, memory, and storage upgrades raise ASP and gross margin;
4. AI pulls replacement demand forward rather than arriving through normal replacement.

AI glasses, robots, and cars need one more signal: multi-device coordination must create a new purchase decision, not just display a phone capability on another screen.

AI labels count shipments. Task success counts revenue.

Smart Money Should Queue by Order of Proof

Stocks should not be ranked by who has risen the least. Past performance records what happened. Future returns depend on incremental free cash flow, probability of delivery, current valuation, and the loss when the thesis fails.

I would organize the research queue into four layers.

Layer One: Data-Center Bottlenecks Already in the Numbers

GPUs, HBM, custom silicon, networking, power, and cooling have the clearest orders and revenue. The hard part is no longer deciding whether the industry is growing. It is deciding how much growth the valuation already assumes and when capital spending peaks.

Layer Two: Dual Exposure Across Cloud and Edge

Foundry, advanced packaging, Arm IP, processors that span data center and client, and memory suppliers that serve both can cross all three growth curves. They rarely offer the greatest single-theme torque, but they may offer better risk-adjusted returns.

Layer Three: Pure Edge Options

Qualcomm, MediaTek, client NPUs, low-power sensors, secure chips, and power management need evidence from usage, ASPs, and replacement cycles. This layer can create the largest expectation gap—and the easiest way to get trapped by a launch-event narrative.

Layer Four: Cyclical Positions Managed Through Supply

SK hynix, Micron, Samsung, and SanDisk cannot be held only because "AI grows for a long time." Positions must change when HBM, DRAM, and NAND supply, inventory, and capital spending change.

This framework will never produce one stock that permanently ranks first. Arm's growth ceiling, Broadcom's current delivery, TSMC's platform position, Qualcomm's edge torque, and Intel's turnaround odds represent different combinations of probability and payoff.

Six Events Could Reprice the Entire Thesis

Can Hyperscaler AI Revenue Catch Up With Capex?

Data centers are the largest denominator and the largest source of risk. If AI revenue, utilization, or free cash flow cannot support capital spending, GPUs, HBM, networking, optics, and power equipment will all reset. A long-term edge story cannot save near-term orders.

Can Inference Volume Outrun Model Efficiency?

Quantization, distillation, sparsity, and custom ASICs reduce the cost of each inference. Lower cost may compress hardware demand, or it may trigger a Jevons effect in which token volume grows even faster. Total inference volume decides the outcome, not how small one model becomes.

When Does Memory Supply Actually Arrive?

If HBM yield, new fabs, advanced packaging, and NAND expansion improve together, memory prices will turn before demand looks weak. Watch bit supply, customer inventory, long-term agreements, and capital spending instead of waiting for margins to peak.

Do Agents Cross the Reliability Threshold?

The edge needs persistent, personalized, cross-application execution. If agents still fail on permissions, payments, state, and recovery, AI PCs and phones will complete a specification upgrade without shortening replacement cycles.

What Is the Real Cloud-versus-Local Cost?

Falling cloud inference prices extend the life of old devices. Privacy, latency, connectivity, and recurring subscription costs push workloads toward local execution. The architecture will be decided by total task cost, not launch-event messaging.

Power and Geopolitics

Grid access, energy prices, export controls, advanced-node capacity, and regional subsidies can all change the winners. The more capital intensive AI becomes, the harder policy risk is to ignore.

Different Scenarios Send Money to Different Layers

In the base case, data centers remain the largest AI profit pool for several years, inference infrastructure becomes the clearest second curve, and the edge provides long-duration optionality. The bull case is the one in which phones, AI PCs, glasses, and robots all create incremental hardware demand. In the bear case, edge penetration can still rise, but it becomes a default feature rather than a new supercycle.

After Memory, the Answer Is Not One Sector

Does memory still have upside? Yes. Data centers remain the primary driver, while the edge can extend the cycle and add a second demand layer. Once supply arrives, however, the risks in NAND and commodity DRAM will surface quickly.

What comes after memory? The clearest second tier still sits inside the data center: custom silicon, networking, optical interconnect, power, cooling, foundry, and advanced packaging. Edge SoCs, AI PCs, and edge devices form the higher-torque third layer.

For an individual investor, dual exposure deserves the closest attention: businesses that monetize cloud capex today and edge deployment tomorrow. They may not produce the fastest rally, but they require fewer fragile assumptions to work.

Smart money does not hunt for the next asset carrying an AI label. It looks for the next bottleneck where supply is hardest to expand, demand reaches the income statement first, and the price has not already bought the entire future.

As tokens move from machine rooms into billions of devices, who gets paid once—and who collects a toll twice along the way?

那两篇关心的是一台 PC 如何接住从云端下沉的智能。一周多后，苹果在 WWDC 2026 发布新一代 Siri AI，强调 personal context understanding、on-screen awareness、app actions 和 across apps，还把同一段对话接进 iPhone、iPad、Mac、Apple Watch 和 Vision Pro。

看起来，一边在谈 PC，一边在谈 Siri。放在一起看，它们指向同一轮迁移：AI 正从云端的一颗大脑，长成分布在个人设备上的一套神经系统。

这篇继续往前一步。PC 很重要，但端侧智能的棋盘远不止 PC。

端侧首先是一张计算网络

把端侧等同于手机，会漏掉一半；把端侧等同于本地模型，还会漏掉另一半。

端侧包含用户身边所有可以感知、计算和执行的设备。手机看见你此刻的位置、屏幕、消息和相机；手表知道你是否佩戴、是否运动、是否刚完成一次身份确认；耳机一直贴着你的声音和环境；PC 保存文件、代码、浏览器会话、企业账号和长期工作状态；汽车、眼镜和家庭设备理解周围空间。

这些设备拥有不同的上下文，也适合不同的任务。把同一个小模型复制到每台机器上，价值有限。真正有意思的地方，是它们开始围绕同一个人协作。

端侧智能的单位，最终会从设备变成人。

云端仍然负责世界知识和高强度推理。端侧负责现场：你正在看什么，刚刚发生了什么，哪台设备处于可信状态，哪个动作可以立刻执行。这里的“端”是一条数据与权限边界，离线运行只是其中一种结果。

PC 是这张网络里的重节点

PC 为什么重新回到牌桌，前两篇已经写过：Agent 的使用频率会把云端成本放大，本地算力重新成为资产。这里不再重复那笔账，只补一个更重要的角色。

PC 是个人 Agent 最适合长期工作的地方。

手机擅长捕捉意图。它始终在身边，能看到通知、位置、照片和即时对话。复杂工作却大量沉淀在 PC：几十个文件、完整 repo、邮件历史、设计稿、财务表、terminal、企业系统和浏览器登录状态。PC 还有稳定电源、更大内存和更好的散热，适合让任务连续运行几十分钟，甚至几小时。

想象一下这个场景：你在地铁上收到客户发来的合同，对手机说：“跟上一个版本比较，找出和邮件里谈妥内容不一致的条款，先拟一封回复，我到公司前给我。”

手机拿到当前邮件和你的意图，Watch 完成身份确认，办公室里的 Mac 读取项目目录与邮件索引，本地模型先过滤敏感信息，复杂条款再交给云端模型，结果最后回到手机。

没有哪一台设备独自完成了这件事。Agent 活在它们的交接里。

手机让 Agent 随身，PC 让 Agent 开工。

这也是 "A new era of PC" 更深的一层含义。PC 不只获得了新的算力任务，它开始承担个人智能网络里的重计算、长任务和私有工作状态。

苹果在搭个人智能的 control plane

把 WWDC 2026 看成 Siri 终于更像 ChatGPT，会错过真正的产品。Siri 是用户看得见的界面，设备、数据、身份、模型和 App 之间那层系统才是核心。

苹果宣布 Siri AI 深度接入 iPhone、iPad、Mac、Apple Watch 和 Vision Pro，并通过 iCloud 私密同步对话历史。用户可以在 Mac 开始，在 iPhone 或 Watch 继续。Apple 这只是最容易展示的一层。

真正困难的是一项任务如何跨设备延续：意图从哪台设备进入，哪份上下文仍然有效，哪台设备拥有执行条件，哪个动作需要再次确认，什么时候调用云端，最终由哪个 App 落地。

这套系统更像个人智能的 control plane。它调度的不只是模型，还包括设备、权限、身份和动作。

模型决定答案有多聪明，control plane 决定 AI 到底能不能替你做事。

苹果的优势也在这里。它控制芯片、操作系统、账号体系、安全硬件、App 权限和一整组个人设备。单看模型，苹果未必领先；把一个人的设备组织成连续系统，它拥有别人很难复制的起点。

个人上下文是一种实时状态

“个人上下文”很容易被理解成一个更大的用户数据库：邮件、照片、日历、聊天记录全部做 embedding，Agent 需要时检索。

这还不够。

数据告诉 AI 你过去做过什么。实时状态告诉它你现在正在做什么：屏幕上打开哪份文件，耳机是否佩戴，Mac 是否解锁，附近有没有自己的设备，刚收到哪条通知，付款动作是否已经确认。

这些信息变化快、保质期短，也和权限紧密绑定。十分钟前的屏幕状态可能已经失效；在已解锁 Mac 上允许读取的文件，不该因为一句手机语音就自动上传；Watch 上的一次确认，也不能无限期授权后续动作。

数据告诉 AI 你是谁，端侧状态告诉它你此刻要什么。

这就是操作系统厂商的机会。聊天机器人只能看到用户主动交给它的内容，OS 站在上下文发生的现场。未来个人 Agent 的差距，很可能不在“记住了多少”，而在能否判断哪些信息此刻有效、哪些权限此刻成立。

App 会被拆成一组可调用能力

苹果给开发者的信号同样清楚。App Intents schemas 可以把 App 的实体放进 Spotlight semantic index，把动作暴露给 Siri；View Annotations 则让系统理解屏幕上正在显示的对象。

过去，App 是一个目的地。用户找到图标、打开首页、穿过几层页面，最后完成一个动作。

Agent 接管入口后，App 更像能力供应商。用户说“把这张票据记到账本”“把合同风险同步到项目任务”“等这个网页开放报名就通知我”，系统会选择合适的 App，再把多个动作串起来。整个过程可能一次界面都不打开。

我把这一层叫作 Intent Store。它未必真的长成一个商店，却会形成新的分发逻辑：

App Store 决定软件有没有进入设备，Intent Store 决定它有没有进入任务。

这件事在 PC 上尤其重要。IDE、Office、设计软件、数据库工具和企业应用拥有大量深层能力，过去都藏在菜单、命令和复杂 UI 里。一旦这些能力被 Agent 理解并组合，PC 软件的竞争力会从“界面里有什么”，延伸到“系统能调用什么”。

不会被 Agent 理解的软件，依然可以被人打开，只是会逐渐失去自动化工作流里的位置。

几家巨头其实在争同一个入口

Microsoft 和 NVIDIA 从 PC 出发。它们强调本地 Agent、统一内存和持续运行的工作负载，NVIDIA 甚至直接把 agents 称为 personal computing 的未来。

苹果从个人上下文出发。它把 Siri 放进每块屏幕，把 App Intents 接到系统动作，再用端侧模型和 Private Cloud Compute 覆盖不同强度的任务。

起点不同，终点正在靠近：一个围绕用户组织的 personal AI fabric。

在这张网络里，PC 是最重的计算节点，手机是最密集的感知节点，Watch 和耳机提供身份与即时交互，云端模型提供外部知识和高难推理。操作系统负责把它们拼成一次完整任务。

因此，下一轮竞争不只看谁的模型更强。模型厂商提供能力，操作系统决定能力在什么时间、拿着什么上下文、通过哪台设备进入用户生活。

PC 是其中最重的一块，端侧智能才是完整的棋盘。

真正的门槛在交接

跨设备听起来很自然，做起来比跨 App 更难。

iOSWorld 用 26 个 App 和同一个人的持续身份测试手机 Agent。最好的配置总体只有 52%，跨 App 任务只有 37%。iOSWorld 单台手机、受控环境、已有高权限接口，Agent 仍然经常走丢。把任务扩展到多台设备，还要增加网络中断、设备休眠、上下文过期、权限升级、状态冲突和失败恢复。

一段对话能同步，不代表一项工作能延续。

真正可用的个人 Agent 必须记得任务做到哪一步，知道哪份状态已经过期，在设备切换后恢复执行，还要让用户随时看见它读过什么、做过什么、准备做什么。出错后能撤回，越权前会停下来，设备离线时不会悄悄换一条危险路径。

发布会最容易演示“从这里继续聊”。真正的门槛，是“从那里继续做”，而且不能做错。

这也是苹果路线最大的考验。封闭生态让它有条件打通设备，也意味着任何一处不可靠都会破坏整套体验。Agent 连续两次找错文件、重复发信或忘记用户刚刚拒绝的动作，个人智能网络就会立刻退化成一组更烦的通知。

云端有大脑，端侧开始长身体

回头再看 "A new era of PC" 和 WWDC 2026，两条新闻其实是一件事。

前者在问：AI 的重任务以后在哪里运行？后者在问：AI 凭什么理解并代表一个人？答案正在同一处汇合——用户自己拥有的设备。

云端模型还会继续变大，也会长期承担最难的推理。但一颗远在数据中心的大脑，没有你的屏幕、文件、传感器、身份和执行权限。它可以回答世界，却很难真正进入生活。

端侧智能给 AI 补上身体。手机负责感知，PC 负责工作，Watch 负责确认，App 负责行动，云端在必要时提供更强的大脑。Agent 则穿过它们，保持同一个目标。

AI 的下一轮平台，是一组终于开始围绕同一个人协作的设备。

当一项任务可以从手腕开始，在 PC 上完成，再回到手机交付，我们还会把端侧智能理解成手机里的一个模型吗？

Those articles focused on how a PC could absorb intelligence moving down from the cloud. A little over a week later, Apple unveiled the next generation of Siri AI at WWDC 2026, emphasizing personal context understanding, on-screen awareness, app actions, and actions across apps. It also extended the same conversation across iPhone, iPad, Mac, Apple Watch, and Vision Pro.

One side appeared to be talking about PCs, the other about Siri. Put together, they point to the same migration: AI is growing from a brain in the cloud into a nervous system distributed across personal devices.

This article takes the argument one step further. The PC matters, but the board for on-device intelligence is much larger than the PC.

The Edge Is a Computing Network First

Treating the edge as another word for mobile leaves out half the picture. Treating it as another word for local models leaves out the other half.

The edge includes every nearby device that can sense, compute, or act. A phone sees your current location, screen, messages, and camera. A watch knows whether you are wearing it, whether you are moving, and whether you just confirmed your identity. Earbuds sit next to your voice and surroundings. A PC holds files, code, browser sessions, enterprise accounts, and long-lived working state. Cars, glasses, and home devices understand the physical environment around you.

These devices possess different context and suit different tasks. Copying the same small model onto every machine has limited value. The interesting part begins when they coordinate around the same person.

The unit of on-device intelligence will ultimately shift from the device to the person.

The cloud will continue to handle world knowledge and compute-intensive reasoning. The edge handles the scene: what you are looking at, what just happened, which device is currently trusted, and what action can be taken immediately. "Edge" describes a boundary for data and permission. Offline execution is only one possible result.

The PC Is the Heavy Node in This Network

The previous two articles already covered why the PC has returned to the table: frequent agent use amplifies cloud costs, making local compute an asset again. I will not repeat that calculation here. The PC also has another, more important role.

It is the best place for a personal agent to work for long periods.

A phone is good at capturing intent. It is always nearby and can see notifications, location, photos, and immediate conversations. Complex work, however, accumulates on the PC: dozens of files, a complete repository, email history, design files, financial spreadsheets, terminals, enterprise systems, and authenticated browser sessions. The PC also has stable power, more memory, and better cooling, making it suitable for tasks that run for tens of minutes or even hours.

Imagine this: on the subway, you receive a contract from a client and tell your phone, "Compare this with the previous version, find every clause that conflicts with what we agreed over email, draft a reply, and have it ready before I reach the office."

The phone captures the current email and your intent. The Watch confirms your identity. The Mac at the office reads the project directory and email index. A local model filters sensitive information first, and difficult clauses go to a cloud model. The result returns to the phone.

No single device completed the task by itself. The agent lived in the handoff between them.

The phone keeps the agent with you. The PC puts it to work.

This is the deeper meaning of "A new era of PC." The PC is gaining more than a new compute workload. It is beginning to carry heavy computation, long-running tasks, and private working state inside a personal intelligence network.

Apple Is Building the Control Plane for Personal Intelligence

Seeing WWDC 2026 as the moment Siri finally became more like ChatGPT misses the actual product. Siri is the visible interface. The system layer connecting devices, data, identity, models, and apps is the core.

Apple announced that Siri AI would be deeply integrated across iPhone, iPad, Mac, Apple Watch, and Vision Pro, with conversation history privately synchronized through iCloud. A user can begin on a Mac and continue on an iPhone, iPad, Watch, or Vision Pro.Apple That is only the easiest layer to demonstrate.

The hard part is preserving a task across devices: where the intent entered, which context remains valid, which device has the right execution conditions, which action needs confirmation again, when to use the cloud, and which app should complete the final step.

This system looks more like a control plane for personal intelligence. It schedules more than models. It schedules devices, permissions, identity, and actions.

Models determine how smart an answer is. The control plane determines whether AI can actually work on your behalf.

That is also Apple's advantage. It controls the chips, operating systems, account system, security hardware, app permissions, and an entire family of personal devices. Apple may not lead when models are evaluated in isolation. When the job is organizing one person's devices into a continuous system, it starts from a position that is difficult to copy.

Personal Context Is a Real-Time State

"Personal context" is easy to imagine as a larger user database: embed every email, photo, calendar event, and chat record, then retrieve them when the agent needs something.

That is not enough.

Data tells AI what you did in the past. Real-time state tells it what you are doing now: which file is open on screen, whether your earbuds are being worn, whether the Mac is unlocked, whether one of your trusted devices is nearby, which notification just arrived, and whether a payment was confirmed.

This information changes quickly, expires quickly, and is tightly coupled to permission. Screen state from ten minutes ago may already be invalid. A file readable on an unlocked Mac should not automatically be uploaded because of one voice command from a phone. A confirmation on the Watch should not authorize every later action indefinitely.

Data tells AI who you are. Edge state tells it what you want at this moment.

This is the opening for operating system vendors. A chatbot can only see what the user actively gives it. An OS stands where context is created. The gap between personal agents may eventually depend less on how much they remember and more on whether they can determine which information is still valid and which permissions are still active.

Apps Will Be Decomposed into Callable Capabilities

Apple's signal to developers is just as clear. App Intents schemas can add app entities to Spotlight's semantic index and expose actions to Siri. View Annotations allow the system to understand the object currently visible on screen.

In the past, an app was a destination. The user found an icon, opened the home screen, moved through several pages, and eventually completed an action.

Once the agent owns the entry point, apps begin to look like capability providers. The user says, "Record this receipt," "Turn the contract risks into project tasks," or "Notify me when registration opens on this page." The system chooses the right app and chains multiple actions together. The entire workflow may finish without opening a single interface.

I call this layer the Intent Store. It may never become a literal store, but it will create a new distribution model:

The App Store decides whether software enters the device. The Intent Store decides whether it enters the task.

This matters especially on the PC. IDEs, office suites, design tools, database clients, and enterprise applications contain deep capabilities that have historically been hidden behind menus, commands, and complicated interfaces. Once agents can understand and combine them, PC software will compete on more than what its interface contains. It will also compete on what the system can call.

Software an agent cannot understand can still be opened by a person. It will simply lose its place in automated workflows over time.

The Giants Are Fighting for the Same Entry Point

Microsoft and NVIDIA are approaching from the PC. They emphasize local agents, unified memory, and continuously running workloads. NVIDIA even describes agents as the future of personal computing.

Apple is approaching from personal context. It is putting Siri on every screen, connecting App Intents to system actions, and combining on-device models with Private Cloud Compute for workloads of different intensity.

The starting points differ, but the destination is converging: a personal AI fabric organized around the user.

Inside that fabric, the PC is the heaviest compute node. The phone is the densest sensing node. The Watch and earbuds provide identity and immediate interaction. Cloud models supply external knowledge and difficult reasoning. The operating system turns them into one completed task.

The next competition therefore cannot be measured only by model capability. Model vendors provide intelligence. Operating systems decide when that intelligence enters a user's life, with what context, and through which device.

The PC is the heaviest piece. On-device intelligence is the whole board.

The Real Barrier Is the Handoff

Cross-device interaction sounds natural. In practice, it is harder than crossing apps.

iOSWorld tests phone agents using 26 apps and one persistent user identity. The best setup reaches only 52 percent overall and 37 percent on multi-app tasks.iOSWorld Even on one phone, in a controlled environment, with privileged interfaces, agents still frequently lose their way. Expanding the task to several devices adds network failures, sleep states, expired context, permission elevation, state conflicts, and recovery from partial failure.

Synchronizing a conversation does not mean a piece of work can continue.

A useful personal agent must remember how far the task has progressed, recognize which state has expired, resume after switching devices, and let the user inspect what it has read, what it has done, and what it plans to do. It must support undo, stop before crossing a permission boundary, and avoid silently choosing a more dangerous path when one device goes offline.

The easiest demo is "continue the conversation over there." The real barrier is "continue the work over there"—without getting it wrong.

This is also the biggest test for Apple's approach. A closed ecosystem gives it the ability to connect devices, but it also means one unreliable component can damage the entire experience. If an agent selects the wrong file twice, sends duplicate messages, or forgets an action the user explicitly rejected, the personal intelligence network immediately collapses into a more annoying notification system.

The Cloud Has a Brain. The Edge Is Growing a Body

Look again at "A new era of PC" and WWDC 2026. They are two parts of the same story.

The first asks where AI's heavy workloads will run. The second asks what gives AI the right to understand and represent a person. The answers are converging in the same place: devices owned by the user.

Cloud models will keep getting larger and will continue to handle the hardest reasoning. But a brain in a data center does not have your screen, files, sensors, identity, or execution permissions. It can answer questions about the world while still struggling to enter daily life.

On-device intelligence gives AI a body. The phone senses. The PC works. The Watch confirms. Apps act. The cloud supplies a stronger brain when necessary. The agent passes through them while keeping the same goal.

The next AI platform is a set of devices finally beginning to coordinate around the same person.

When a task can begin on your wrist, finish on your PC, and return to your phone for delivery, will we still describe on-device intelligence as a model running inside a phone?

A trade meant to last fifteen minutes suddenly acquires a ten-year investment thesis. It drops a little more, and you begin researching whether the market has overreacted. It bounces slightly, and now Soros seems right about reflexivity. You entered as Livermore, became Buffett after the loss, and summoned Burry when the position became too painful.

That is not synthesis. It is the absence of a trading plan.

The most dangerous person in markets often knows a little about every method, then switches methods at the moment of maximum pain. Short-term trading, trend following, value, growth, macro, quantitative trading, arbitrage, crisis trades, indexing, All Weather, and supply-chain bottlenecks can all make money. They have also buried countless traders. The reason is simple: they do not earn the same kind of return.

A school's boundary is defined by five things: where the profit comes from, what evidence supports the position, how long it should take to work, which fact proves it wrong, and how the method most commonly dies.

That is also what the founding masters left behind. Their real legacy is not a quote for the edge of your monitor. It is a complete survival contract.

Trading Is Not One Discipline. It Is Twelve Different Businesses

On the surface, every trader appears to do the same thing: buy low and sell high, or sell high and buy low. Once you separate the sources of profit, the differences are as wide as those between a restaurant and a casino.

Livermore gets paid for price movement. Graham gets paid when price returns toward value. Buffett gets paid by long-term business compounding. Soros gets paid when institutional promises break. Thorp gets paid when odds are mispriced. Simons repeatedly harvests tiny statistical deviations. Bogle does not even try to prove he is smarter than the market; he tries to reduce friction to the minimum.

The same stock becomes a completely different trade inside each school.

A Microsoft opening breakout can be a ten-minute trend trade. A post-earnings valuation decline can become a value-reversion trade. Azure and Copilot pricing power can support a ten-year compounding thesis. Heavy AI data-center spending that pressures software margins could support a structural short. The ticker stays the same while the profit equation changes four times.

What you bought matters less than how you expect to get paid.

Making Money From Price Movement: Livermore and Paul Tudor Jones

Jesse Livermore: Ticker Tape, Bankruptcy, and Stop Losses

Livermore began copying quotations in a Boston brokerage while still a teenager. There was no TradingView, no Level 2, and even corporate financial statements were far less reliable than they are today. He watched prices move across ticker tape, placed directional bets in bucket shops, and quickly developed an almost instinctive sense of rhythm.

He later became famous for shorting the Panic of 1907 and the crash of 1929. He also gave every dollar back to the market more than once. His life has everything Wall Street loves to turn into legend: a gifted teenager, enormous wealth, mansions, yachts, bankruptcy, and another comeback. Strip away the glamour and what remains is a risk warning.

Livermore could read the market. He could not always control himself. Judgment, position sizing, and survival are three different abilities.

Today's same-day-expiry option simply compresses that old speculation into a shorter clock. The contract expires today, time value collapses quickly, and its price becomes extremely sensitive to movements in the underlying. An old speculator might have had several days to correct a mistake. Now the window can be minutes.

This school does not require a high win rate. It requires errors to stay cheap and correct positions to grow. Exit when the breakout fails. Add only when the trend continues. Position size begins small and grows; losses should begin small and stay small. The order is the entire method.

The core edge in short-term trading is not being right more often. It is being able to afford being wrong.

The most common death is simple: averaging down and turning one controlled error into an unmanageable position. Same-day-expiry options are especially unforgiving because time will not wait for you to become right eventually.

Paul Tudor Jones: Macro Finds the Wind; the Tape Pulls the Trigger

Paul Tudor Jones's defining battle came on Black Monday in 1987. The documentary Trader captured his state of mind around that period. He and his team studied market structure and compared the 1987 path with the run-up to the 1929 crash. When the collapse arrived, short positions generated enormous gains.

The story is often told as a spectacular prediction. The more useful lesson is his defensive instinct. Jones forms macro views, but he also watches technical structure, liquidity, and price feedback. Macro tells him where trouble may emerge. The tape decides when the risk is worth taking.

That is very different from pure forecasting. You may identify a risk six months early and still be squeezed out three times before it arrives. For a leveraged short-term position, being too early and being wrong can produce the same result.

The Jones school fits opening breakouts, trend days, panic, cross-asset contagion, and liquidity cascades. It watches more than one company. It watches the dollar, rates, bonds, volatility, market breadth, and whether capital is beginning to rush toward the same exit.

Livermore resembles a hunter reading every movement on the tape. Jones resembles a hunter who studies weather and herd migration first. They share one belief: the view can be large, but the stop must be specific.

Making Money From Value and Time: Graham, Buffett, and Lynch

Benjamin Graham: The Great Depression Taught Him to Calculate Residual Value First

After 1929, Graham saw a market that is hard to imagine today. Some companies traded below the net cash on their balance sheets. In theory, an investor could buy the entire company, liquidate its assets, repay every liability, and still have money left. The market was not merely discounting a pessimistic future. It looked like a warehouse clearance sale.

Value investing grew from that wreckage. Graham and David Dodd built a framework for security analysis at Columbia, attempting to turn stocks back from lottery tickets into fractional ownership of businesses. Graham cared about assets, liabilities, earning power, and conservative valuation. The central demand was simple: price must leave room for analytical error.

The power of Margin of Safety comes from admitting ignorance. Future earnings may be slightly wrong, the economy may be worse than expected, and management may make another mistake. A large enough discount can absorb part of that damage. Mr. Market reduces the market from judge to quotation clerk: he appears every day in a different mood, and you are never required to transact with him.

Graham gets paid when a discount closes. The company does not need to be wonderful. It only needs to be absurdly cheap. A cigar butt with one final puff can still have value.

The common failure is the value trap. Book assets may be impossible to sell, profit may be in permanent decline, and management may burn whatever value remains. Cheapness is only the starting point. Asset quality and a catalyst determine whether the discount ever closes.

Warren Buffett: From the Last Puff to a Cash-Flow Machine

Buffett began as a complete Graham disciple. Charlie Munger later kept pressing a different point: even a cheap bad business consumes management attention and capital. A great business can reinvest and turn time into an ally. A mediocre business repeatedly asks to be rescued.

Coca-Cola is the most famous example of that transition. Berkshire began buying aggressively in 1988. It saw far more than flavored sugar water. It saw global brand memory, worldwide distribution, and a pricing power so gradual that consumers barely noticed it.

Raise the price of each bottle by a few cents and almost no individual customer switches to tap water. Multiply those cents across global volume and the result becomes enormous free cash flow. Reinvest the profit in distribution and brand, and the moat can widen again.

Graham asks, "What is this worth in liquidation?" Buffett asks, "How much cash can this machine produce ten years from now?" One waits for valuation repair. The other waits for capital to compound.

Low P/E does not explain Buffett. High quality also does not justify any price. Buy a great company too expensively and several future years can still produce no return. Once the moat erodes, long-term holding merely stretches a small error into a large one.

Time rewards good businesses. It does not rescue bad prices.

Peter Lynch: Daily Life Supplies the Lead; Financial Statements Conduct the Interrogation

During Peter Lynch's thirteen years managing Fidelity Magellan, the fund returned roughly 29.2% annually and grew from about $18 million to around $14 billion. His most famous phrase is "invest in what you know." Many people translate it into: I love this product, therefore the company is worth owning.

That interpretation leaves out the second half of the method.

Daily observation is only a lead. A mall suddenly has a long line, children all want the same brand, or colleagues begin depending on one piece of software. These changes may signal real demand. The next step is to inspect revenue growth, same-store sales, inventory, debt, margins, valuation, and competition. A great product can still be an absurdly expensive stock. A company can have millions of users and no profitable business model.

Lynch's advantage comes from the speed gap in information. Wall Street analysts may still be waiting for the next report while ordinary people have already seen the change in parking lots, supermarkets, and offices. Daily life brings the lead early. The financial statements eliminate the hallucination.

The common error is carrying the consumer identity into the investor identity. Loving a product makes it easy to rationalize management. Hating a product can make you miss an excellent cash-generating business.

Familiarity lowers the research barrier. It also lowers your willingness to doubt.

Making Money From System Fractures: Soros, Burry, and the Bottleneck Hunter

George Soros: A Central Bank's Words Cannot Defeat Economic Constraints

In 1992, Britain kept sterling inside the European Exchange Rate Mechanism. Politically, it was a firm commitment. Economically, Britain was under recessionary pressure while high German interest rates after reunification tightened the entire system.

On September 16, the British government raised rates from 10% to 12% to defend the pound, then announced a further increase to 15%. The market kept selling. That evening, Britain left the ERM. Sterling fell, and Soros's Quantum Fund became famous for its enormous short position.

The fascinating part is not that Soros had more money than the central bank. No fund can outmuscle a sovereign central bank on the balance sheet. He saw that while the central bank had printing power and reserves, the government could not absorb unlimited rates, ongoing recession, and political damage.

Institutions can declare a price. Reality sends the bill.

Macro trading searches for exactly these fractures: fixed exchange rates versus the domestic economy, stimulus versus inflation, fiscal expansion versus debt costs, industrial narratives versus margins. The market can pretend the fracture does not exist for a long time, until the cost of maintaining the promise suddenly becomes intolerable.

The hard part is timing. The logic can remain correct for years while carry is deducted every day. Size the trade too large and the system kills the trader first. Size it too small and the eventual rupture does not matter enough.

Michael Burry: Others Watched Home Prices; He Opened the Loan Pools

Around 2005, most discussion of U.S. housing focused on home prices, interest rates, and historical default rates. Burry read the underlying documents inside mortgage-backed securities. He found low-quality loans, loose underwriting, adjustable-rate reset schedules, and a cash-flow chain that depended on home prices never stopping.

His thesis was more specific than "housing has risen too far." He knew which loans were likely to fail and when. He also understood how ratings hid risk inside complex tranches. He then bought credit default swaps on those bonds, paid premiums continuously, and waited for the underlying cash flows to deteriorate.

The wait was not romantic. While the market kept rising, premiums kept leaving the fund, investors questioned the position, and counterparties did not always mark the instruments favorably. Before it became a story worthy of a film, the trade looked like one stubborn person repeatedly burning money.

The Burry school gets paid for structural mispricing. Surface price is a symptom. The balance sheet, contractual terms, maturity structure, and cash-flow waterfall are the disease.

The danger also lives inside the structure. Seeing the destination does not mean you can afford the road. Crisis trades often die from carry, liquidity, and the patience of investors.

The market can be late for a long time. Your funding may not be able to wait.

Bottleneck Hunter: Ignore the Hype and Own the Tollbooth

Supply-chain bottleneck investing has no single founding master. It looks like a hybrid of Lynch, Soros, Buffett, and Burry: discover demand in the real world, use system constraints to locate the gap, take the industry structure apart, and identify the layer with pricing power.

AI capex is the clearest example. Cloud companies expand budgets, and the money passes through data centers, GPUs, HBM, advanced packaging, optical modules, networking chips, power, and cooling. Every layer can claim to benefit. Higher revenue and retained profit are completely different outcomes.

A true bottleneck usually has several traits at once: long capacity lead times, slow customer qualification, immature substitutes, difficult yield ramps, concentrated supply, and demand with no practical detour. Once any of those conditions loosens, the tollbooth can become an ordinary supplier.

When I study a bottleneck, I care less about the headline TAM and more about five concrete questions: whose balance sheet provides the budget, which layer receives the order, when new supply comes online, whether customers can qualify a second source, and who keeps the economics after ASP rises.

In AI optical networking, everyone understands that traffic will grow. The scarce layer may instead be a specific upstream material, laser capacity, packaging capability, or qualification cycle. By the time everyone is discussing the same component, the bottleneck may already be moving.

Soros looks for where the system can no longer hold. Burry looks for where cash flow will break. The bottleneck hunter looks for where cash must pass.

The trend determines demand. The bottleneck determines who converts demand into profit.

Making Money From Odds and Repetition: Thorp and Simons

Edward Thorp: A Good Trade Can Still Lose Money

Edward Thorp first used mathematics to study blackjack. He recognized that a casino can lose any single hand and still make money over time because the rules give it a stable positive expectancy. If probability, payoff, and bet size are calculated correctly, the player may also be able to reverse the advantage.

He later carried the same logic to Wall Street, working on warrants, convertible securities, options pricing, market-neutral portfolios, and statistical arbitrage. The casino became a small laboratory. Financial markets were the larger card table.

Thorp's core variables can be compressed into one equation: win probability times gain, minus loss probability times loss, minus transaction costs. Only a positive result deserves repeated capital.

That leads to a counterintuitive conclusion: a good trade can lose, and a bad trade can win. Buy an extremely expensive call and happen to catch a surge; the outcome is profitable while the odds may have been poor. Sell an overpriced option and get hit by a tail event; the decision may still have had positive expectancy.

Direction is only one part of an option. Implied volatility, realized volatility, time value, gamma, hedging costs, liquidity, and tail risk jointly determine the odds. Asking only whether the market rises tomorrow is like sitting at a card table without reading the payoff schedule.

The Thorp school fears low-probability, high-severity losses. Hundreds of small wins create a false sense of safety. One correlation breakdown or liquidity disappearance can take back the entire history of profits.

Jim Simons: Remove "I Think" From the System

Jim Simons moved from mathematics, geometry, and codebreaking into financial markets. Renaissance Technologies describes its own work with restraint: it uses mathematical and statistical methods to design and execute investment programs. The details remain private, and estimates of Medallion's long-term return vary because of fees, size, and disclosure conventions.

That secrecy makes the broad lesson cleaner. Simons does not require an emotional story about Nvidia, the dollar, or oil. The system needs to find small but stable deviations in large amounts of data, remain positive after slippage, fees, and market impact, then repeat the process enough times.

Quantitative trading is far more than adding a few indicators and backtesting one curve. Future leakage, survivorship bias, overfitting, unrealistic fills, limited signal capacity, and regime decay determine whether the strategy can leave the notebook.

A personal same-day-expiry strategy eventually moves toward semi-quantitative trading. Which time window has a higher win rate? How large must a gap be before it is worth chasing? Which volatility regime works? How wide should the stop be? Should trading stop after several consecutive losses? Does the first fifteen minutes behave differently from 2 p.m.? Every answer needs a record.

An unrecorded edge is only a feeling until it is tested. A feeling that cannot be reproduced is usually luck.

Not Trying to Prove You Are Smarter: Bogle and Dalio

John Bogle: One Less Trade, One Less Tuition Payment

In 1976, John Bogle launched an index fund for ordinary investors. The idea had no heroic appeal: no superstar stock selection, no turning-point forecasts, no fund-manager genius, only low-cost ownership of a broad basket of market assets.

It directly attacked Wall Street's most profitable business model. More active trading means more commissions, spreads, management fees, and taxes. The industry earns a share from every act of confidence, while the investor must beat those frictions before excess return even becomes possible.

Bogle's method does not promise to beat the market. It promises to capture as much of the market's own return as possible and minimize the amount lost in transit.

This is the least glamorous school and one of the most brutal. It tells most people that while they think they are searching for alpha, their account may retain little beyond higher costs and larger behavioral errors.

Index investing still demands discipline. In a bull market it feels too slow. In a bear market people panic, sell, then buy back higher. Low fees cannot rescue constant interference.

Ray Dalio: If You Cannot Predict the Weather, Do Not Carry Only One Umbrella

In 1971, Nixon suspended the dollar's convertibility into gold. A young Ray Dalio assumed the shock to the monetary system would crash equities the next day. The market rose instead. The surprise taught him that he lacked a historical template: similar events had happened before, but he had never seen them.

That experience sits near the origin of All Weather. The economy can be divided into four environments: rising growth, falling growth, rising inflation, and falling inflation. Equities, long-duration bonds, cash, commodities, and inflation-protected assets respond differently to each. A portfolio can appear diversified by capital while remaining dominated by equity risk.

Risk parity reallocates according to risk contribution so the portfolio is not trapped inside one macro scenario. It gives up some maximum upside in particular bull markets in exchange for a greater ability to survive across environments.

The approach has costs. Low-volatility assets often require leverage to contribute enough return. Historical correlations can change suddenly. When inflation and rates rise together, stocks and bonds may fall at the same time. All Weather never meant never losing. It means admitting in advance that you cannot know the next season.

Bogle admits he may not select the winner. Dalio admits he may not predict the environment. Both schools embed humility into the product design.

Twelve Schools, Twelve Profit-and-Loss Equations

The easiest column to ignore is the validation clock.

When a same-day-expiry trade fails to move as expected for ten minutes, the thesis may already be dead. One week of flat price says almost nothing about a ten-year compounding thesis. A macro imbalance that survives for two years has not proved it can survive forever.

Time horizon is not a footnote to the trade. It is part of the logic.

The Real Risk Is Not Mixing Schools. It Is Switching Schools Mid-Position

Strong investors often mix methods. Soros watches price. Buffett considers the macro environment. Quantitative systems still contain human judgment. Supply-chain research naturally requires several perspectives: Lynch discovers the change, Burry opens the structure, Buffett judges pricing power, and Soros looks for system constraints.

Mixing during research is usually fine. Switching after the loss appears is often fatal.

Livermore Enters; Buffett Takes Over the Loss

You buy a same-day-expiry option on an opening breakout and plan to leave below a specific level. Price breaks that level. Suddenly you remember long-term U.S. productivity, the AI revolution, and the historical upward drift of the index. Even if all of those views are correct, none can extend the life of a contract expiring today.

Short-term positions love borrowing long-term logic because a stop confirms the error immediately, while a long-term story can postpone judgment indefinitely.

Buffett Enters; Livermore Panics Out

You buy a company for pricing power, cash flow, and reinvestment. The market falls 4% the next day and you immediately question the entire thesis. A five-minute chart begins managing a five-year position.

Long-term investing still needs exits, but the reasons should come from business facts: a changed growth structure, margin deterioration, a narrowing moat, broken capital allocation, or a valuation that has moved beyond future cash flows. Intraday noise changes price. It does not automatically change the company.

Burry Does the Research; Lynch's Familiarity Places the Order

You research an entire supply chain, explain upstream materials, capacity, and customer qualification, then buy the most visible brand because "I use this product every day." The structural analysis ends with a position chosen by familiarity.

A more common version comes later: the company falls first, and only then do you begin searching for the deeper structure. Research no longer informs the decision. It becomes legal counsel for the existing position.

Soros Supplies the Macro Story; Thorp Sees the Wrong Odds

The directional thesis sounds persuasive, so you are willing to pay any price for the option. The underlying does rise, but falling implied volatility and time decay consume the gain. The macro direction is correct and the options trade still loses money.

Every form of strategy switching has the same structure: the original contract is quietly rewritten. The initial failure condition disappears, and a new explanation can always be found afterward.

Losses are exceptionally good at turning people into better storytellers.

Give Every Position a Trading Passport

I prefer to treat each position as an independent project. Before entering, I fill in a short trading passport with at least seven fields.

The passport earns its value after the loss appears. People are honest without a position and become defense attorneys once they own one. A contract written by the relatively clear-headed version of you can constrain the later version that hates admitting defeat.

How to Write a Same-Day-Expiry Option Passport

The school can be Livermore / Jones. Profit comes from the post-open trend and volatility expansion. Evidence includes key levels, volume, market breadth, and cross-asset feedback. The validation clock is only a few minutes to an hour. A return through the breakout level, a reversal in breadth, or the end of the time window invalidates the trade.

The risk budget must exist before entry. Once the stop is reached, Microsoft's ten-year cash flow is not admissible evidence, and buying a cheaper contract to "improve the average" is not allowed.

How to Write a Long-Term MSFT Passport

The school is closer to Buffett plus Bottleneck. Profit comes from pricing power in cloud and AI infrastructure, customer lock-in, free cash flow, and continued reinvestment. The validation clock is quarterly and annual. Intraday volatility affects only the purchase price.

The real invalidation appears in the business: AI capex fails for a sustained period to convert into revenue, depreciation consumes profits, paid Copilot conversion disappoints, Azure share declines persistently, or competition weakens pricing power. Valuation also needs its own ceiling. A great company does not automatically become a great stock.

How to Write an AI Bottleneck Passport

Profit comes from supply-demand imbalance and limited substitutability. Evidence should include orders, lead times, capacity, yield, qualification cycles, customer concentration, alternative technical paths, and ASP—not merely a presentation claiming that the AI market will reach some enormous future size.

Invalidation is equally concrete: competitors expand earlier than expected, customers qualify a second source, substitutes pass qualification, inventory moves from shortage to excess, or higher prices fail to reach profit. Once the bottleneck migrates, previously correct research becomes obsolete immediately.

Isolating Positions Works Better Than Demanding Rationality

When I separate my own trading and research habits, I am clearly eclectic: Livermore for short-term execution, Jones for market rhythm, Soros for macro fractures, Burry for structural decomposition, Buffett for pricing power, and the bottleneck hunter for budget flows.

The combination is powerful and dangerous. It has too many languages available to explain a position.

The stupidest and most effective solution is physical separation. A short-term account executes only short-term rules. Core positions update their theses quarterly. Research positions wait for evidence and catalysts instead of turning three days of reading into an immediate order. Broker notes label the school and time horizon. Reviews are grouped by strategy rather than blending all profit and loss into one number.

"Stay rational" is too abstract. Accounts, labels, position limits, and hard stops are constraints that actually exist.

You also have to accept an uncomfortable truth: the same person can hold opposite views across different positions. A long-term bullish view on AI infrastructure does not prevent a short against an overextended index today. Owning Microsoft for years does not prevent the view that one quarter's capex return may disappoint the market.

When time horizon, instrument, and invalidation are explicit, this is not a contradiction. The real contradiction is one position claiming it lasts ten minutes while preparing to wait ten years.

The Founding Masters Never Rescue a Position

Return to the SPY same-day-expiry option from the opening. At 9:45, the breakout has failed and price hits the stop. Microsoft's moat has not changed. The U.S. economy has not been rewritten in ten minutes. None of those facts belongs to this trade anymore.

Closing the position means only that the opening judgment was wrong. It does not reject AI, U.S. equities, or your next trade. A small error settled on time allows the account to survive for the next opportunity.

Livermore, Jones, Graham, Buffett, Lynch, Soros, Simons, Thorp, Burry, Bogle, and Dalio were never playing the same game. Some earned volatility, some earned time, some earned odds, some waited for systems to break, and some simply tried to make fewer mistakes.

Every school provides one way to make money. It also specifies one moment when you must admit defeat. The second lesson is more valuable.

The next time a position moves against you, do not immediately summon another founding master to defend it.

Ask one question: which school did this trade belong to when I entered?

This article discusses trading methodology and does not constitute investment advice.

Further Reading

• Reminiscences of a Stock Operator
• Trader (1987)
• Value Investing History — Columbia Business School
• The Intelligent Investor
• Berkshire Hathaway 1988 Shareholder Letter
• Berkshire Hathaway 1989 Shareholder Letter
• Fidelity Magellan Fund Fact Sheet
• Bank of England: UK Crashes Out of the ERM
• A Talk With Edward O. Thorp
• Renaissance Technologies
• Michael Burry: Missteps to Mayhem
• Vanguard's History
• The All Weather Story
• Serenity, the Bottleneck Hunter

于是，一笔计划持有十几分钟的交易，瞬间拥有了十年投资逻辑。再跌一点，你开始研究市场是不是错杀；反弹一点，又觉得 Soros 说得对，市场具有反身性。你下单时是 Livermore，亏损后变成 Buffett，扛不住时再请 Burry 出来证明市场有问题。

这不叫融会贯通，叫没有交易计划。

市场里最危险的人，往往每种方法都懂一点，却总在最痛的时候换一种。短线、趋势、价值、成长、宏观、量化、套利、危机交易、指数、全天候、产业链 Bottleneck，每一派都能赚钱，也都埋过无数人。区别只在于，它们赚的根本不是同一种钱。

流派的边界，由五件事决定：利润从哪里来，什么证据支持仓位，多久应该兑现，什么事实证明自己错了，以及这套方法最容易怎么死。

祖师爷的意义也在这里。他们留下的不是一句可以贴在显示器旁边的金句，而是一套完整的生存契约。

交易不是一门学科，是十二种不同的生意

表面上看，所有交易者都在做同一个动作：低买高卖，或者高卖低买。拆开损益来源，差别大得像餐厅和赌场。

Livermore 赚价格运动的钱；Graham 赚价格回归价值的钱；Buffett 赚企业长期复利的钱；Soros 赚制度承诺崩裂的钱；Thorp 赚赔率算错的钱；Simons 赚微小统计偏差被重复收割的钱；Bogle 甚至不打算证明自己比市场聪明，他只想把摩擦成本降到最低。

同一只股票，放进不同流派里，会变成完全不同的交易。

Microsoft 开盘突破，可以是一笔十分钟的趋势单；财报后估值回落，可以是一笔价值修复；Azure 与 Copilot 的定价权，可以是一笔十年复利；AI 数据中心预算挤压软件毛利，又可能是一笔结构性空头。Ticker 没变，损益方程已经换了四次。

买了什么不重要，靠什么赚钱才重要。

赚价格运动的钱：Livermore 和 Paul Tudor Jones

Jesse Livermore：纸带、破产与止损

Livermore 十几岁就在波士顿的券商办公室抄报价。那时没有 TradingView，没有 Level 2，连公司财报都远没有今天可靠。他盯着纸带上的价格变化，去 bucket shop 对赌涨跌，很快练出一种近乎本能的节奏感。

后来，他在 1907 年恐慌和 1929 年崩盘中靠做空成名，也几次把赚来的钱全部吐回市场。他的人生很适合被华尔街做成传奇：少年天才、巨额财富、豪宅游艇、破产重来。可把滤镜摘掉，留下来的其实是一份风险警告。

Livermore 能看懂市场，却未必始终管得住自己。判断、仓位和生存，从来是三种能力。

今天的末日期权只是把这种老投机压缩进更短的时钟。合约当天到期，时间价值快速归零，价格对标的波动极其敏感。过去一个投机者还有几天纠错，现在可能只有几分钟。

这派不要求高胜率。它要求错误足够便宜，正确时敢于放大。突破没发生就退出，趋势延续才加仓。仓位先小后大，亏损先大后小，顺序完全相反。

短线交易的核心优势，不是看得准，是错得起。

它最常见的死法也很简单：补仓摊低成本，把一次可控错误养成无法处理的仓位。末日期权尤其残酷，因为时间不会等你证明自己最终正确。

Paul Tudor Jones：宏观负责找风，盘面负责开枪

Paul Tudor Jones 的经典战役发生在 1987 年黑色星期一。纪录片《Trader》拍下了他在那段时间的交易状态。他和团队研究市场结构，也把 1987 年的走势与 1929 年崩盘前的路径进行对照，最终在股灾中靠空头仓位获得巨额收益。

这段故事经常被讲成一次神预测。真正值得学的部分却是他的防守意识。Jones 会做宏观判断，也会盯技术形态、流动性和价格反馈。宏观告诉他哪里可能出事，盘面决定仓位什么时候值得冒险。

这和纯粹预测差别很大。你可以提前半年看见风险，却在半年里被逼空三次。对于带杠杆的短线仓位，太早和看错没有区别。

Jones 这派适合开盘突破、趋势日、恐慌盘、跨资产联动和流动性踩踏。它观察的对象不只是一家公司，还包括美元、利率、债券、波动率、市场宽度，以及资金是否开始同时逃向一个出口。

Livermore 更像读纸带的猎手，Jones 更像观察天气和兽群迁徙的猎手。两人共同相信一件事：观点可以很大，止损必须具体。

赚价值和时间的钱：Graham、Buffett、Lynch

Benjamin Graham：大萧条教会他先算残值

1929 年之后，Graham 见过一种今天很难想象的市场：不少公司跌到低于账上净现金，买下整家公司、清算资产、还完债，理论上还有钱剩。市场不是在给悲观预期打折，简直像在甩卖仓库。

价值投资就从这种废墟里长出来。Graham 与 David Dodd 在 Columbia 建立起证券分析框架，试图把股票从彩票重新变成企业所有权。他关心资产、负债、盈利能力和保守估值，核心要求只有一个：价格必须给判断误差留出余地。

Margin of Safety 的力量来自承认无知。未来盈利算错一点，经济比预期差一点，管理层再犯一点蠢，折价仍然能吸收损失。Mr. Market 则把市场从裁判降级成报价员：他每天上门，情绪忽高忽低，你没有义务每次都跟他成交。

Graham 赚的是折价收敛。公司不用伟大，便宜得足够荒谬就行。烟蒂还剩最后一口，也有价值。

这派最容易踩进 Value Trap。账面资产可能卖不掉，利润可能正在永久萎缩，管理层也可能把所有剩余价值烧完。便宜只是起点，催化剂和资产质量决定折价能不能回来。

Warren Buffett：从最后一口烟，到一台现金流机器

Buffett 早期完整继承了 Graham 的烟蒂思维。后来 Charlie Munger 不断提醒他：烂生意就算买得便宜，也会持续消耗管理精力和资本。一个优秀企业可以不断再投资，把时间变成朋友；一个平庸企业只会反复要求你救火。

Coca-Cola 是这次转变最著名的案例。Berkshire 在 1988 年开始大举买入。当时它看到的远不止一瓶糖水，而是全球品牌心智、遍布世界的分销网络，以及消费者几乎感受不到的提价能力。

每瓶可乐多卖几分钱，单个消费者不会因此改喝自来水。乘上全球销量，这几分钱就成了庞大的自由现金流。企业把利润继续投入渠道和品牌，护城河又会反过来扩大。

Graham 的问题是“这东西清算值多少”，Buffett 的问题是“这台机器十年后能产出多少现金”。一个等待估值修复，一个等待资本复利。

低 PE 解释不了 Buffett。高质量也不等于任何价格都能买。优秀公司买得太贵，未来几年照样可能颗粒无收；护城河一旦消失，长期持有只会把小错拖成大错。

时间只奖励好生意，不负责拯救坏价格。

Peter Lynch：生活负责报料，财报负责审讯

Peter Lynch 管理 Fidelity Magellan Fund 的十三年里，年化收益约 29.2%，规模从 1800 万美元增长到 140 亿美元左右。他最出圈的一句话是 "invest in what you know"。很多人把它理解成：我爱用这款产品，所以这家公司值得买。

这恰好漏掉了后半套方法。

生活里的观察只是线索。商场突然排长队，孩子都在买某个品牌，同事开始离不开一款软件，这些现象说明需求可能发生变化。接下来还要看收入增长、同店销售、库存、债务、利润率、估值和竞争格局。产品很好，股票照样可能贵得离谱；用户很多，商业模式照样可能一分钱赚不到。

Lynch 的优势来自信息传播速度差。华尔街分析师还在等下一份报告，普通人已经在停车场、超市和办公室里看见变化。生活把线索提前送到眼前，财报负责排除幻觉。

这派最容易犯的错，是把消费者身份带进投资者身份。喜欢产品会自动替管理层解释，讨厌产品又会错过一家赚钱机器。

熟悉感能降低研究门槛，也会降低怀疑能力。

赚系统裂缝的钱：Soros、Burry 和 Bottleneck Hunter

George Soros：央行的嘴，打不过经济的约束

1992 年，英国把英镑锁在欧洲汇率机制的区间里。政治上，这是一项坚定承诺；经济上，英国正承受衰退压力，德国统一后的高利率又把整个体系越拧越紧。

9 月 16 日，英国政府为保卫英镑先把利率从 10% 提到 12%，随后宣布还要升到 15%。市场仍然继续卖。当天晚上，英国退出 ERM。英镑贬值，Soros 的 Quantum Fund 因巨额空头一战成名。

这场交易最迷人的地方，不是 Soros 比央行更有钱。任何基金都不可能在资产负债表上压过一国央行。他看见的是：央行拥有印钞和外汇储备，政府却承受不了无限高的利率、持续衰退与政治代价。

制度可以宣布价格，现实负责追缴成本。

宏观交易寻找的正是这种裂缝：固定汇率与国内经济冲突，刺激政策与通胀冲突，财政扩张与债务成本冲突，产业叙事与利润率冲突。市场会在很长时间里假装裂缝不存在，直到维护承诺的成本突然失控。

这派的难点在 timing。逻辑正确可能维持几年，Carry 却每天都在扣钱。仓位太大，系统先把交易者熬死；仓位太小，等到裂缝爆开又赚不到足够多。

Michael Burry：别人看房价，他扒开贷款池

2005 年前后，市场讨论美国房地产时，大部分人盯着房价、利率和历史违约率。Burry 去读 MBS 的底层文件。他看到大量低质量贷款、宽松承保、可调利率重置时间，以及一旦房价停止上涨就会断裂的现金流链条。

所以他的判断并不是“房子涨太多了”。他知道哪些贷款会在什么时候出问题，也知道证券评级如何把风险藏进复杂分层。接下来，他通过 CDS 为这些债券买违约保险，持续支付保费，等待底层现金流恶化。

等待并不浪漫。市场继续上涨时，保费持续流出，基金投资人开始质疑，交易对手给出的估值也未必配合。一笔后来被拍成电影的传奇，在兑现之前看起来很像一个固执的人反复烧钱。

Burry 这派赚的是结构性错误定价。表面价格只是症状，资产负债表、合同条款、到期结构和现金流瀑布才是病灶。

它最危险的地方也在结构里。看对终点，不代表付得起路费。危机交易经常死在 Carry、流动性和投资人耐心上。

市场可以晚很久，你的资金链未必等得起。

Bottleneck Hunter：不追风口，守住收费站

产业链 Bottleneck 没有单一祖师爷。它像是 Lynch、Soros、Buffett 和 Burry 的混血：从现实世界找需求，用系统约束判断缺口，拆开产业结构，再寻找拥有定价权的环节。

AI Capex 是最典型的例子。云厂商增加预算，钱会依次经过数据中心、GPU、HBM、先进封装、光模块、网络芯片、供电和散热。每个环节都能说自己受益，可收入增加和利润留下完全是两回事。

真正的瓶颈通常同时具备几种特征：扩产周期长，客户认证慢，替代材料不成熟，良率爬坡困难，供给集中，需求又绕不开。只要其中一项松动，收费站就可能退化成普通供应商。

研究 Bottleneck 时，我最关心的也不是 TAM 有多大，而是五个更具体的问题：预算从谁的资产负债表出来，订单最终落到哪一层，新增供给什么时候上线，客户能否双供，以及 ASP 上涨后利润留在谁手里。

以 AI 光通信为例，市场都知道流量会增长，真正稀缺的可能是某种上游材料、激光器产能、封装能力或认证周期。等所有人都在讲同一个组件时，瓶颈往往已经开始迁移。

Soros 找系统撑不住的地方，Burry 找现金流会断的地方，Bottleneck Hunter 找现金必须经过的地方。

风口决定需求，瓶颈决定谁能把需求变成利润。

赚赔率和重复的钱：Thorp 与 Simons

Edward Thorp：一笔好交易，也可以亏钱

Edward Thorp 先用数学研究 blackjack。他发现赌场每一局都可能输，长期仍然能赚钱，因为规则让赌场拥有稳定的正期望。只要把概率、赔率和下注规模算清楚，玩家也有机会把优势反过来。

后来，他把这套思维搬到华尔街，研究权证、可转换证券、期权定价、市场中性和统计套利。赌场成了小型实验室，金融市场才是最大的牌桌。

Thorp 关心的核心变量可以压缩成一条式子：胜率乘以盈利，减去败率乘以亏损，再减掉交易成本。结果为正，才值得重复下注。

这会带来一个很反直觉的结论：好交易可以亏，坏交易也可以赚。买一张极贵的看涨期权，恰好撞上暴涨，结果赚钱；赔率依然可能很差。卖一张定价过高的期权，遇到尾部事件亏钱；决策仍可能拥有正期望。

方向只是期权的一部分。隐含波动率、实际波动率、时间价值、Gamma、对冲成本、流动性和尾部风险一起决定赔率。只问“明天涨不涨”，等于坐上牌桌却不看赔率表。

Thorp 这派最怕小概率大损失。连续赚几百次容易制造安全幻觉，一次相关性崩塌或流动性消失，就能把所有历史收益拿走。

Jim Simons：把“我觉得”从系统里删掉

Jim Simons 从数学、几何和密码分析走进金融市场。Renaissance Technologies 官方对自己的描述很克制：使用数学和统计方法设计并执行投资计划。真正的系统细节从未公开，Medallion 的长期表现也因为费用、规模与披露口径存在不同估算。

这反而让它的启示更纯粹。Simons 不需要一段关于 Nvidia、美元或石油的动人故事。系统只需要在大量数据里找到微小但稳定的偏差，扣除滑点、手续费和市场冲击后仍然为正，然后重复足够多次。

量化也远不止加几个指标、回测一条曲线。数据有没有未来函数，样本是否幸存者偏差，参数是否过拟合，成交能否按回测价格完成，信号容量多大，市场结构变化后是否衰减，这些才决定策略能不能离开 notebook。

个人做末日期权，走到最后也会被迫靠近半量化。什么时间段胜率更高，跳空多大才值得追，波动率处在哪个区间，止损距离多远，连续亏损后是否停手，开盘十五分钟和午后两点的表现有没有差异，都要留下记录。

无法记录的优势，在被验证前都只是手感；无法复现的手感，通常只是运气。

不想证明自己更聪明：Bogle 与 Dalio

John Bogle：少做一次，少交一次学费

1976 年，John Bogle 推出面向普通投资者的指数基金。这个想法在当时毫无英雄气：不选明星股票，不预测拐点，不靠基金经理的洞察，只用低成本持有一篮子市场资产。

它却直接攻击了华尔街最赚钱的商业模式。主动交易越频繁，佣金、价差、管理费和税负越高；行业可以从每一次自信里抽成，投资者却要先跑赢这些摩擦，才轮得到谈超额收益。

Bogle 的方法没有承诺击败市场。它承诺尽量拿到市场本身愿意给的回报，并把中间损耗压到最低。

这派最不性感，也最残酷。它等于告诉多数人：你以为自己在寻找 Alpha，账户里留下的往往只是更高的成本和更大的行为偏差。

指数投资同样需要纪律。牛市里嫌慢，熊市里恐慌卖出，随后又追高买回，低费率也救不了频繁折腾。

Ray Dalio：连天气都猜不准，就别只带一把伞

1971 年，Nixon 宣布暂停美元兑换黄金。年轻的 Dalio 以为货币体系受冲击，第二天股市应该暴跌。结果市场上涨。这次反直觉经历让他意识到，自己缺少历史模板：类似事件过去发生过，只是他没见过。

All Weather 的起点就在这里。经济环境可以拆成增长上行、增长下行、通胀上行、通胀下行。股票、长期债券、现金、商品和通胀保护资产，对这四种环境的敏感度不同。组合按本金平均分配，看起来很分散，风险却可能仍被股票一项主导。

Risk Parity 试图按风险贡献重新配置，让组合不至于押死在单一宏观场景里。它牺牲了某些牛市中的极致收益，换取跨环境生存能力。

这套方法也有代价。低波动资产常需要杠杆才能贡献足够收益，历史相关性会突然变化，通胀和利率一起冲击时，股债也可能同时下跌。全天候从来不等于永不亏损，只是提前承认自己猜不准下一场天气。

Bogle 承认自己未必能选中赢家，Dalio 承认自己未必能猜中环境。两派都把谦逊写进了产品结构。

十二个流派，十二套损益方程

这张表里最容易被忽略的一列，是验证时钟。

一笔末日期权十分钟没有走出预期，逻辑可能已经失效；一家公司一周股价没涨，对十年复利几乎没有信息量；一项宏观失衡拖了两年，也不代表它永远不会崩。

时间尺度不是交易附注，它本身就是逻辑的一部分。

真正的风险，不在混合，在串台

高手往往都会混合流派。Soros 看价格，Buffett 也看宏观环境，量化系统背后照样有人的判断。产业链研究更天然需要多种视角：Lynch 负责发现变化，Burry 负责拆结构，Buffett 负责判断定价权，Soros 负责寻找系统约束。

混合发生在研究阶段，问题不大。串台发生在亏损之后，通常致命。

Livermore 进场，Buffett 接盘

开盘突破买入末日期权，原计划跌破某个位置就走。价格真跌破后，突然想起美国长期生产率、AI 革命和指数长期向上。这些判断即使全部正确，也无法延长一张当天到期合约的寿命。

短线仓位最爱借长期逻辑续命。因为止损会立刻确认错误，长期叙事可以把审判无限延期。

Buffett 进场，Livermore 砍仓

因为定价权、现金流和再投资能力买入一家公司，第二天市场跌 4%，马上怀疑全部逻辑。五分钟 K 线开始指挥一个五年仓位。

长期投资也需要退出，但退出依据应该来自商业事实：增长结构变化、利润率恶化、护城河缩窄、资本配置失控，或者估值远超未来现金流。盘中噪声只能改变价格，不能自动改变企业。

Burry 做研究，Lynch 凭喜欢下单

研究一条产业链时，能讲出上游材料、产能和客户认证，最后却因为“我天天用这个产品”就买了最显眼的品牌。结构分析做了半天，仓位还是交给熟悉感。

另一种情况更常见：公司下跌后，才开始寻找底层结构。研究不再用于做决定，只用于替既有仓位辩护。

Soros 的宏观故事，Thorp 的错误赔率

方向判断很有说服力，于是愿意为期权支付任何价格。结果标的确实上涨，隐含波动率回落和时间损耗却把收益吃掉。宏观方向看对，期权交易仍然可以亏钱。

流派串台的共同点，是进场合同被偷偷修改。原本的失败条件消失了，新的理由总能在事后找到。

亏损最擅长的事，就是把人变成一个更会讲故事的交易者。

给每一笔仓位办一张“交易护照”

我现在更愿意把每笔仓位当成一个独立项目。下单前先填一张很短的交易护照，至少写清七件事。

这张表的价值，发生在亏损之后。人在没有仓位时很诚实，有仓位后会自动变成辩护律师。提前写下来的合同，能让过去那个相对清醒的自己约束现在这个舍不得认错的自己。

一笔末日期权该怎么写

流派可以标成 Livermore / Jones。利润来自开盘后的趋势和波动扩张，证据是关键位、成交量、市场宽度与跨资产反馈，验证时钟只有几分钟到一小时。跌回突破位、市场宽度反转或时间窗口结束，交易就失效。

风险预算必须在进场前确定。到达止损后，不允许调用 Microsoft 十年现金流，也不允许补一张更便宜的合约“改善成本”。

一笔 MSFT 长期仓位该怎么写

流派更接近 Buffett 加 Bottleneck。利润来自云与 AI 基础设施的定价权、客户粘性、自由现金流和持续再投资。验证时钟按季度和年度计算，盘中波动只能影响买入价格。

真正的失效条件会落在业务上：AI Capex 长期无法转化成收入，折旧吞噬利润，Copilot 付费转化低于预期，Azure 份额持续下滑，或者竞争让定价权减弱。估值也要单独设上限，伟大公司不自动等于伟大股票。

一笔 AI Bottleneck 仓位该怎么写

利润来自供需错配和不可替代性。证据应该包括订单、交期、产能、良率、认证周期、客户集中度、替代路线与 ASP，而不只是一张“AI 市场将增长到多少万亿”的 PPT。

失效条件也很具体：竞争对手扩产提前，客户完成双供，替代材料通过认证，库存从短缺变成堆积，价格上涨无法传导到利润。只要瓶颈迁移，过去的正确研究就会立刻过期。

把仓位隔离，比要求自己理性更可靠

把我自己的交易和研究拆开，确实像一个杂家：Livermore 的短线执行，Jones 的盘面节奏，Soros 的宏观裂缝，Burry 的结构拆解，Buffett 的定价权，再加上 Bottleneck Hunter 对预算流向的追踪。

这套组合很强，也很危险。它拥有太多可以解释仓位的语言。

最笨、也最有效的办法，是物理隔离。短线账户只执行短线规则；核心仓按季度更新 thesis；研究仓先等证据与催化剂，不因为看了三天资料就急着下单。券商备注里直接标记流派和时间尺度，复盘时按策略统计，不把所有盈亏混成一个数字。

因为“保持理性”太抽象。账户、标签、仓位上限和硬止损才是能落地的约束。

还要接受一件不太舒服的事：同一个人可以在不同仓位里得出相反结论。长期看好 AI 基础设施，不妨碍当天做空一次过度延伸的指数；长期持有 Microsoft，也不妨碍认为某个季度的 Capex 回报低于市场预期。

只要时间尺度、工具和失效条件写清楚，这不叫矛盾。真正的矛盾，是同一笔仓位一边说只做十分钟，一边又准备等十年。

祖师爷从来不负责救仓位

回到开头那张 SPY 末日期权。9:45，突破失效，价格碰到止损。此时 Microsoft 的护城河没有变化，美国经济也没有在十分钟里改写，可这些事实跟这笔交易已经没有关系。

平仓，只代表开盘判断错了。它不否定 AI，不否定美股，也不否定你下一笔交易。一个小错误被及时结算，账户才有资格活到下一场机会。

Livermore、Jones、Graham、Buffett、Lynch、Soros、Simons、Thorp、Burry、Bogle、Dalio，从来没有在做同一种游戏。有人赚波动，有人赚时间，有人赚赔率，有人等系统崩裂，还有人只想少犯错误。

每个流派都给出了一种赚钱方式，也规定了一种必须认错的时刻。后者更值钱。

下一次仓位逆着你走，先别急着请新的祖师爷出来辩护。

问清楚：这笔交易进场时，我到底是哪一派？

本文讨论交易方法论，不构成投资建议。

延伸阅读

• Reminiscences of a Stock Operator
• Trader (1987)
• Value Investing History — Columbia Business School
• The Intelligent Investor
• Berkshire Hathaway 1988 Shareholder Letter
• Berkshire Hathaway 1989 Shareholder Letter
• Fidelity Magellan Fund Fact Sheet
• Bank of England: UK crashes out of the ERM
• A Talk with Edward O. Thorp
• Renaissance Technologies
• Michael Burry: Missteps to Mayhem
• Vanguard’s History
• The All Weather Story
• Serenity，瓶颈猎人

His legend starts with Reddit's r/wallstreetbets, a place famous for overnight fortunes and blown-up accounts. Back then, he was known as AleaBito. He wrote a long AXTI / InP thesis arguing that the AI buildout would eventually be constrained by InP substrates and source material, and that AXTI sat at a surprisingly narrow point in that chain. Many readers saw the obvious surface: another person pitching an obscure small cap. The account was later banned, which made the story even more dramatic. Looking back, the useful takeaway sits beyond the ticker: he was describing a physical constraint inside the AI photonics supply chain before most people had a map for it.

By 2026, Serenity had broken out on X. AXTI, SIVE, AAOI, RPI, AEHR: a string of tickers most people had never heard of, reinterpreted through AI photonics, CPO, external light sources, testing, and robotics supply chains. While others were still discussing GPUs, cloud capex, and Nvidia orders, he was chasing InP, CW lasers, SiPh, harmonic reducers, and rare-earth magnets. You do not have to agree with every conclusion to see the point: he looks at the world from a different angle.

So the most interesting question around Serenity has shifted away from how much some small-cap stock moved, or how far the "white-haired stock goddess" meme can travel. It now sits here: many people have started turning his methodology into a SKILL. At first glance, this makes sense: if he could spot AI supply-chain bottlenecks in obscure names like AXTI, SIVE, and AAOI before most people, why not abstract the process and let an Agent run it?

I thought the same at first. Demand wave, architecture shift, bottleneck material, repricing path, disconfirming evidence. Once written down layer by layer, it really does look like a reusable research framework. But after reading the original posts and the reconstructions, I became more convinced of the opposite: Serenity's methodology can be written as a SKILL, but Serenity's legend cannot.

Bottleneck Hunting

Serenity's method centers on bottleneck hunting. The demand wave is only the starting point, and the architecture shift is only the path. The target is the layer that cannot scale fast enough, cannot be routed around quickly, and has not yet been repriced by the market.

The method looks like supply-chain research, but the first question is always systemic. Will AI compute force interconnects to move from electrical to optical? Once CPO matters, which laser source, foundry capacity, or qualification cycle becomes the choke point? If robotics volume arrives, which actuator, reducer, or rare-earth magnet layer tightens first? In cases like RDDT or HIMS, the material disappears and the constraint becomes data, distribution, regulation, or the customer relationship.

Before writing a thesis, the method has to ask at least ten questions:

1. What demand wave is forcing the system to change?
2. Where does the old architecture start to fail?
3. Which component, material, process, capacity, qualification, data asset, or distribution point becomes scarce?
4. Is that scarce layer a bottleneck, a chokepoint, or just a beneficiary?
5. How many alternatives exist, and how long would switching take?
6. What proves customers need this now?
7. Can the company capture economics, or will customers, fabs, suppliers, capital providers, or competitors capture them?
8. Is the market still valuing it on the old business or trailing revenue?
9. What fact would disprove the thesis fastest?
10. What primary source should be checked next?

Once those ten questions are written down, the method stops being "find obscure small caps" and becomes a full research process: demand to structure, structure to constraint, constraint to evidence, evidence back to pricing. That is also where the problem begins. A SKILL can encode the process. It cannot guarantee the quality of the answers.

Actions Can Be Queued. Judgment Cannot Be Outsourced

Serenity's classic AXTI thesis looks like a small-cap DD post on the surface. Structurally, it is much clearer than that: the AI buildout moves from electrical interconnects to optical interconnects; photonics needs InP substrates and source material; AXT may sit in critical positions across both layers. In plain English: stop staring only at GPUs, and look for the narrowest layer behind the GPU supply chain.

At this point, the action clearly fits a checklist. Demand, architecture, scarcity, valuation, disconfirmation. Each step can be queued up for an Agent. It sounds easy.

Tracing upstream through the supply chain is the easy part. The hard part is knowing, after you find a pile of names, which one is noise and which one is a constraint. InP, CW lasers, CPO, SiPh, ELS, harmonic reducers, rare-earth magnets. Saying these words does not turn them into alpha. They are only entry points.

Most people who read Serenity's methodology will learn only "go find small-cap bottleneck stocks." That is dangerous. Small caps are naturally rich in stories. Any company can package itself as the key component of a future megatrend. If you cannot judge whether the system can route around that component, you end up holding the bottle while missing the bottleneck.

Methodology tells you where to look. Judgment determines what you actually see.

Unavoidable Points in a System

The most valuable part of Serenity's framework has little to do with "obscure small caps." It sits in the system-level question he keeps asking: if the future really unfolds in this direction, which layer breaks first?

AXTI is a materials-layer thesis. SIVE is an external-light-source and ecosystem-qualification thesis. LeaderDrive-style robotics leads sit around actuators, reducers, and rare-earth magnets. In examples like RDDT or HIMS, the constraint shifts from material to data, distribution, regulation, or the customer relationship.

Miss any layer in the framework above and the thesis is incomplete.

Demand wave without architecture change is just a macro story. Architecture change without binding constraint is just industry exposure. Binding constraint without company control is just supply-chain knowledge. Company control without repricing path only means the company is important. It does not mean the equity is attractive.

There is another important distinction: bottleneck and chokepoint need to be separated.

A bottleneck controls capacity or output. A material, process, fab allocation, or qualification queue can prevent the whole chain from scaling. A chokepoint is an architectural dependency. Even if other suppliers can make something similar, the system, reference design, qualification cycle, and customer roadmap may already be built around one path, making near-term switching impossible.

This distinction matters. Many so-called bottleneck stocks are merely beneficiaries. Demand helps them, but customers can route around them, competitors can expand, and prices can normalize. What Serenity keeps emphasizing is the structure that cannot be routed around.

The real constraint comes from being irreplaceable when there is no time to replace you.

A SKILL Cannot Write Taste

Most Serenity SKILL files online will probably turn those ten questions into a fixed process: find demand, map architecture, locate scarcity, verify where the company sits, check the valuation gap, and write the disconfirmation.

This helps, and I would use it too. It sequences actions. Taste remains elsewhere.

What is taste?

Taste is reading an earnings call where a CFO casually mentions "qualification cycle" and knowing that this sentence may matter more than the revenue number. Taste is seeing a government grant, a reference design, or a supplier-page update and knowing it may signal a change in supply-chain position, while an ordinary PR line goes straight into the trash. Taste is knowing the difference between "the company is telling a story" and "the customer is forced to wait in line."

These things are hard to put into a SKILL. Some of them can be written down. The problem begins once they become static rules. Static rules are fragile in a dynamic world. Today, a government subsidy may be a strategic signal. Tomorrow, it may be life support for a tired theme. Today, a customer qualification may be an inflection point. Tomorrow, it may be a design win with no production meaning.

A SKILL can tell an Agent to read 10-Ks, transcripts, grant notices, technical programs, and customer references. It cannot guarantee the Agent knows which line deserves to be paused on, and which line should be deleted as noise.

This is the same issue I wrote about in Harness Engineering. A SKILL is an input constraint layer. It raises the probability of the right action, while judgment remains outside the file. You can put Serenity's workflow into an Agent, but without evidence gates, source boundaries, disconfirmation checks, and primary-source verification, it will simply produce smoother hallucinations that look like Serenity.

The dangerous state is holding a methodology and mistaking it for judgment.

The Legend Has Another Uncopyable Variable: Reflexivity

Serenity's early value came from seeing things before others did. But when someone grows from tens of thousands of followers to hundreds of thousands, and becomes one of the most subscribed accounts on X, he begins observing the market and affecting it at the same time.

This does not accuse him of manipulation. The more precise point is that his research, positions, writing style, follower base, media amplification, and the liquidity profile of small caps now form a feedback system. He publishes a thesis, price moves. Price moves, more people pay attention. More people pay attention, and the next thesis has a larger price impact.

Ordinary people cannot copy this variable. A Serenity SKILL cannot copy it either.

The sentence "this company may be the upstream laser chokepoint for CPO" becomes two different market events when said by Serenity and when generated by a newly installed SKILL. The former carries track record, social distribution, follower capital, and a media amplifier. The latter is just prompt output.

So if you want to learn from him, you must separate research alpha from distribution alpha. Serenity's early edge came from the former. Many of the miracles people see now may already include the latter.

If you merge the two, you will reach a dangerous conclusion: if I can find a small-cap bottleneck stock, I can replicate the returns. Reality is harsher. By the time you see the post, the price, liquidity, narrative, and risk have already moved away from the state he saw while building conviction.

You copied the screenshot. The scene is gone.

The Evidence Ladder Matters More Than the Ticker List

The reusable part of the Serenity case is the evidence ladder. The ticker list ranks far behind.

The weakest evidence includes social posts, mirror text, unnamed customer rumors, follower count, return screenshots, and price action after a post. Treat these as leads. Treating them as proof means you are already offside.

Medium-strength evidence includes customer websites, supplier pages, industry roadmaps, government grants, adjacent-company earnings calls, and credible trade publications. These can show that a direction may exist, but they do not prove that economics will flow to a specific company.

Strong evidence includes company filings, named contracts, purchase agreements, exchange announcements, official grant awards, concrete capacity or timing disclosures, and financial statements showing changes in revenue, margin, backlog, or cash flow.

This ladder matters more than any SKILL.

Because it forces you to admit that many Serenity posts are still research leads. His skill is generating leads earlier, deeper, and more accurately than others, then connecting weak, medium, and strong signals into a structure. But if you skip verification and treat the lead as the conclusion, the lesson slides from Serenity into FOMO.

Good research has to do more than "find an exciting story." It has to know which evidence level the story currently sits on, and what should be verified next.

How Ordinary People Should Learn From This

If I had to turn Serenity's method into a personal capability, I would keep four actions.

Translate Demand Into the Physical World

Move past "AI will grow," "robots will grow," or "data centers will grow." Ask what architecture changes when that growth happens. Once architecture changes, which material, component, process, capacity, qualification, data, or distribution layer becomes scarce?

A grand narrative becomes researchable only after it is translated into a concrete constraint.

Separate Beneficiary, Bottleneck, and Chokepoint

A beneficiary rises with the industry. A bottleneck affects supply and demand. A chokepoint makes near-term routing around it impossible.

These three have completely different valuation logic. Treating a beneficiary as a chokepoint is one of the most expensive mistakes retail investors make.

Write the Disconfirmation for Every Thesis

What would prove you wrong fastest? Customers finding an alternative? Capacity expanding faster than expected? Pricing locked down by long-term agreements? The company failing to capture economics? New business staying forever at the design-win stage and never reaching revenue?

If a thesis has no disconfirmation, it has probably left research mode and entered belief mode.

Separate the Trade From the Thesis

Serenity's own posts often show risk awareness: being directionally right does not mean timing is right; a company being important does not mean the equity is cheap; a critical supply-chain position does not protect you from dilution, financing, governance, liquidity, or volatility.

Followers often ignore this part on purpose. Risk awareness is not sexy. "The next 10x stock" travels faster.

Researchers who survive know where they can die.

What a SKILL Can Actually Do

I actually like turning Serenity's framework into a SKILL.

A good Serenity-style SKILL can force an Agent to do several things:

• start from the demand wave before returning to the ticker;
• write the binding constraint before discussing company benefit;
• label source level before using social posts;
• output theses to verify instead of buy or sell advice;
• attach disconfirming evidence to every thesis;
• list the next primary-source checks.

That is already much better than most "analyze this stock for me" outputs.

But it is still scaffolding.

A SKILL can make low-quality output less bad. It can reduce omissions, suppress hallucinations, and force the model to walk the full path. But it cannot manufacture domain taste from nothing. It cannot read ten years of semiconductor supply chains for you. It cannot tolerate volatility for you. It cannot tell you whether a sentence is an industrial signal or just pretty language from IR.

A SKILL copies the route map. Driving ability stays outside the file.

Legends Cannot Be Installed

The Serenity case reminds me of a broader impulse in the AI world: see a master, turn the process into a prompt; see a system, package it as a SKILL; see a success, compress it into reusable instruction.

This is valuable. Human civilization advances by externalizing experience into tools, documents, institutions, and protocols.

But compression always loses information.

Serenity's legend contains engineering background, supply-chain intuition, long attention to obscure materials, tolerance for incomplete evidence, psychological capacity to sit through violent volatility, the personality to keep pushing when nobody understood the idea early, and later, the reflexive amplification of social networks.

You can write part of that into a SKILL. You cannot install all of it into yourself with one command.

So I prefer to treat Serenity as a reminder: future alpha comes from translating growth into the physical constraints of the world. The threshold sits in whether your senses are deep enough to smell a real constraint inside the noise.

Methodology can be shared.

Senses have to grow on your own.

Sources

• Reddit AXTI / InP thesis
• Twiscan mirror of @aleabitoreddit public X posts
• Hidden Gold Rush / bottleneck hunting thread mirror

Note: this article discusses methodology reflected in public social posts. It is not investment advice. Social posts, X mirrors, and third-party summaries are research leads only; they do not replace company filings, earnings reports, transcripts, contracts, announcements, or other primary sources.

他的传奇，最早要从 Reddit 上那个以暴富和爆仓闻名的 r/wallstreetbets 说起。那时他还叫 AleaBito，发了一篇关于 AXTI / InP 的长帖，说整个 AI buildout 后面会被 InP substrate 和 source material 卡住，而 AXTI 正好站在那个极窄的位置。论坛里很多人第一反应是：这不就是又一个推小票的吗？后来这个账号被封，故事反而更有戏剧性。几年后再看，大家才发现：他当时借 AXTI 讲的，是一条 AI 光子供应链里很少有人看见的物理约束。

到了 2026 年，Serenity 在 X 上开始真正出圈。AXTI、SIVE、AAOI、RPI、AEHR，一串普通人甚至没听过的 ticker，被他放进 AI photonics、CPO、external light source、testing、robotics supply chain 这些结构里重新解释。别人还在讨论 GPU、云厂商 capex、英伟达订单，他已经在追 InP、CW laser、SiPh、harmonic reducer、rare earth magnet。你可以不同意他的每个结论，但很难否认：他看世界的角度和大多数人不一样。

所以这两天围绕 Serenity 最有意思的事，已经从某只小票又涨了多少、“白毛女股神”这个外号还能传多远，转向了另一个问题：很多人开始把他的方法论整理成 SKILL。看起来很合理：既然他能从 AXTI、SIVE、AAOI 这类冷门名字里提前看出 AI 供应链的瓶颈，那把他的流程抽象出来，让 Agent 以后照着跑，不就行了吗？

我一开始也这么想。需求浪潮、架构变化、瓶颈材料、市场重估路径、反证检查，一层层写下来，确实很像一个可以复用的 research framework。但读完那些原帖和整理之后，我反而更确定另一件事：Serenity 的方法论可以写成 SKILL，但 Serenity 的传奇不能。

Bottleneck Hunting

Serenity 的方法论核心是 bottleneck hunting。大需求只是起点，架构变化只是路径，真正要抓的是那一层短期扩不出来、客户绕不过去、市场还没重新定价的瓶颈。

这套方法看起来像供应链研究，其实先问的是系统问题。AI 算力增长会不会迫使互连从电走向光？CPO 起来之后，哪种激光器、代工产能、认证周期会变成卡点？机器人放量后，执行机构、减速器、稀土磁材哪一层先紧？换到 RDDT、HIMS 这类非硬件例子，材料会消失，约束会变成数据、分发、监管或用户关系。

真正落笔前，这套方法至少要问 10 个问题：

1. 哪个需求浪潮正在逼迫系统变化？
2. 旧架构哪里开始不够用？
3. 哪个组件、材料、工艺、产能、认证、数据或分发点会变稀缺？
4. 这个稀缺层是瓶颈、卡点，还是普通受益者？
5. 替代方案有多少，切换需要多久？
6. 什么证据证明客户现在就需要它？
7. 公司能不能捕获经济利益，还是利润会被客户、晶圆厂、供应商、资本方或竞争对手拿走？
8. 市场还在用旧业务或旧收入口径给它定价吗？
9. 哪个事实会最快证明这个投资假设错了？
10. 下一步最该查哪份一手资料？

这 10 问一写，方法论就从“找冷门小盘股”变成了一个完整研究流程：从需求到结构，从结构到约束，从约束到证据，再从证据回到定价。问题也在这里：流程可以写成 SKILL，答案质量不能靠 SKILL 保证。

动作可以排队，判断无法外包

Serenity 最经典的 AXTI thesis，表面上是一篇小盘股 DD，实际结构很清楚：AI buildout 从电互连走向光互连，光子学需要 InP substrate 和 source material，而 AXT 在这两个层面都可能占据关键位置。换成人话就是：别盯着 GPU，去看 GPU 后面那条供应链里最窄的地方。

到这里，你会发现它确实适合写成清单。需求、架构、稀缺、估值、反证，每一步都可以交给 Agent 排队执行。听起来不难。

沿供应链往上游追并不难。难的是，你追到一堆名字之后，怎么知道哪一个是噪音，哪一个是约束。InP、CW laser、CPO、SiPh、ELS、harmonic reducer、rare earth magnet，这些词念出来不会自动变成 alpha。它们只是入口。

大多数人看完 Serenity 的方法论，只会学到“去找小盘瓶颈股”。这很危险。因为小盘股天然盛产故事，任何公司都能把自己包装成未来巨浪里的关键零件。你如果没有能力判断“这个零件到底能不能被绕开”，最后抱住的是瓶子，错过的是瓶颈。

方法论告诉你往哪里看，判断力决定你看到了什么。

系统里的不可绕行点

Serenity 的框架最值得学的地方，和“冷门小盘”关系没那么大。核心在于那个系统问题：如果未来真的按这个方向展开，哪一层会先卡住？

AXTI 是材料层。SIVE 是光源和生态适配层。LeaderDrive 那类 robotics 线索则是执行机构和稀土磁材层。换到 RDDT、HIMS 这类非硬件例子，约束从材料切换成数据、分发、监管、用户关系。

前面那张图里的四层，缺一层都不够。

只有需求浪潮，没有架构变化，那只是宏观叙事。只有架构变化，没有关键约束，那只是行业受益。只有关键约束，没有公司掌控力，那只是供应链知识。只有公司掌控力，没有重估路径，那只是“这家公司很重要”，不代表股票有吸引力。

这里还有一个细节：bottleneck 和 chokepoint 要分开看。

Bottleneck 是产能或输出控制。比如某个材料、工艺、fab allocation 让整个链条放量受限。Chokepoint 是架构依赖。即使别人也能生产类似东西，但系统、reference design、qualification cycle、客户路线已经围绕某个方案展开，短期不能热插拔替换。

这个区分很关键。很多所谓“瓶颈股”其实只是 beneficiary。需求来了它会受益，但客户可以绕开它，竞争对手可以扩产，价格可能被压回去。Serenity 反复强调的恰恰是“不能绕开”的结构。

真正的卡点，关键在于不可替代，而且来不及替代。

SKILL 写不出判断手感

现在网上那些 Serenity SKILL，大概率都会把上面 10 问整理成固定流程：先找需求，再画架构，定位稀缺，验证公司到底卡在哪一层，检查估值差，最后写反证。

这套东西有用，我也会用。但它解决动作编排，解决不了判断手感。

判断手感是什么？

判断手感是你看到一段 earnings call 里 CFO 随口提到"qualification cycle"时，知道这句话可能比营收数字更重要。判断手感是你读到一个政府 grant、一个 reference design、一个供应商页面更新时，知道它指向产业链位置变化，普通 PR 该直接排除。判断手感是你能分清“公司讲故事”和“客户被迫排队”的差别。

这些东西很难写进 SKILL。当然可以硬写。问题在于，一旦写进去，它们就会变成静态规则。静态规则最怕的就是动态世界。今天“政府补贴”是战略信号，明天可能只是过气概念的续命针；今天“客户认证”是拐点，明天可能只是没有量产意义的 design win。

SKILL 可以告诉 Agent 去读 10-K、transcript、grant notice、technical program、customer reference。它不能保证 Agent 知道哪一行值得停下来，哪一行应该当作噪音删掉。

这和我之前写 Harness Engineering 时讲过的东西是同一个问题。SKILL 是输入约束层，它提高正确动作出现的概率，但判断本身仍然要另算。你可以把 Serenity 的流程塞进 Agent，但如果没有证据门槛、信源边界、反证检查、一手资料核验，它只会更流畅地生产一堆看起来像 Serenity 的幻觉。

最危险的状态，是拿着方法论，以为自己拥有了判断力。

传奇里还有一个不可复制变量：反身性

Serenity 早期的价值在于提前看见别人没看见的东西。但当一个人从几万粉丝涨到几十万粉丝，甚至开始成为 X 上订阅量最高的一批账号之一，他就会同时观察市场和影响市场。

他开始成为市场的一部分。

这句话不等于指控他操纵价格。更准确地说，他的研究、持仓、语言风格、粉丝结构、媒体引用和小盘股流动性共同构成了一个反馈系统。他发一篇研究，价格动；价格动，更多人关注；更多人关注，下一篇研究的价格影响更大。

这个变量，普通人复制不了。一个 Serenity SKILL 更复制不了。

同样一句“这家公司可能是 CPO 的 upstream laser chokepoint”，Serenity 说出来，和一个刚装完 SKILL 的账号说出来，已经是两种市场事件。前者带着历史战绩、社交传播、粉丝资金、媒体放大器；后者只是一个 prompt 的输出。

所以普通人跟着学时，必须把“研究 alpha”和“传播 alpha”分开。Serenity 早期靠的是前者。现在外界看到的很多神迹，可能已经混入了后者。

如果你把这两者混在一起，就会得出一个很危险的结论：只要我也找到小盘瓶颈股，就能复刻收益。现实更残酷：等你看到他的帖子，价格、流动性、叙事和风险已经和他建仓时不在同一个状态。

你复制到的是截图，错过的是现场。

证据阶梯比 ticker list 更重要

Serenity 这件事里，最该被复用的东西叫证据阶梯，ticker list 排在很后面。

最弱的是社交帖子、镜像文本、匿名客户传闻、粉丝数、收益截图、帖子发出后的价格变化。这些只能当 lead，不能当 proof。

中等强度的是客户网站、供应商页面、产业蓝图、政府 grant、相邻公司 earnings call、可信行业媒体。这些能说明“方向可能存在”，但还不能证明经济利益会流向某家公司。

强证据是公司 filing、named contract、purchase agreement、exchange announcement、official grant award、具体产能和时间节点、财报里可见的收入、毛利、backlog 或现金流变化。

这个阶梯比任何 SKILL 都重要。

因为它逼你承认：Serenity 的很多帖子，本质上仍然是研究线索。他厉害的地方，是能比别人更早、更深、更准确地生成线索，并把多个弱中强信号串成一个结构。但如果你跳过验证，直接把线索当结论，你学到的会滑向 FOMO，离 Serenity 越来越远。

好的研究要做的，远不止“找到一个激动人心的故事”。它还要知道这个故事现在站在哪一级证据上，以及下一步最该验证什么。

普通人应该怎么学

如果真要把 Serenity 的方法变成自己的能力，我会保留四个动作。

从需求往物理世界翻译

不要停在“AI 会增长”“机器人会增长”“数据中心会增长”。往下问：增长之后，哪种架构会变？架构变了之后，哪种材料、器件、工艺、产能、认证、数据、分发会变得稀缺？

宏大叙事只有翻译成具体约束，才有研究价值。

区分受益者、瓶颈和卡点

受益者会随行业上涨。瓶颈能影响供需。卡点会让系统短期无法绕行。

这三者的估值逻辑完全不同。把 beneficiary 当 chokepoint，是散户最容易交学费的地方。

每个 thesis 都要写反证

什么会最快证明你错了？客户找到了替代方案？产能扩得比预期快？价格被长协锁死？公司无法捕获 economics？新业务永远停留在 design win，没有进入 revenue？

如果一个 thesis 写不出反证，通常说明它已经从研究滑进信仰。

把交易和 thesis 分开

Serenity 的原帖里其实常常有风险意识：方向对，不代表短期 timing 对；公司重要，不代表股权便宜；产业链位置关键，不代表不会被稀释、融资、治理问题、流动性和波动率打爆。

这点很多跟风者会故意忽略。因为风险意识不性感，不如“下一个 10 倍股”传播得快。

但真正能活下来的研究者，靠的是知道自己在哪些地方可能死。

一个 SKILL 能做到什么

我并不反对把 Serenity 的框架写成 SKILL。恰恰相反，我觉得这很有价值。

一个好的 Serenity-style SKILL，至少可以逼 Agent 做几件事：

• 先写需求浪潮，再回到 ticker；
• 不把“公司相关”当成“公司受益”，必须写出关键约束；
• 不把社交帖子当事实，必须标注证据等级；
• 不输出买卖建议，只输出待验证 thesis；
• 每个 thesis 都必须附上反证；
• 下一步必须列出一手资料检查项。

这已经比大多数“帮我分析一下这只股票”的输出强太多。

但它仍然只是脚手架。

SKILL 能让低水平输出变得不那么糟。它能减少遗漏，压住幻觉，逼模型走完整流程。可它不能凭空制造领域判断手感，不能替你读十年半导体供应链，不能替你承担波动，不能替你分辨“这句话是产业信号”还是“这句话只是公司 IR 的漂亮话”。

SKILL 复刻路线图，复刻不了驾驶能力。

传奇不能被安装

Serenity 这个案例让我想到很多 AI 圈现在的冲动：看到一个高手，就想把他的流程拆成 prompt；看到一个系统，就想把它打包成 SKILL；看到一段成功，就想把它压缩成可复用指令。

这当然有价值。人类文明本来就是靠把经验外化成工具、文档、制度和协议往前走。

但压缩总会丢信息。

Serenity 的传奇里，有工程背景，有供应链直觉，有对冷门材料的长期关注，有对不完整证据的容忍，有承受剧烈波动的心理结构，有早期不被理解时还敢继续押注的性格，还有后来社交网络带来的反身性。

你可以把其中一部分写成 SKILL。你不能把这些东西一键安装进自己身上。

所以我更愿意把 Serenity 当成一个提醒：未来的 alpha 来自“把增长翻译成世界的物理约束”。但这件事的门槛在于，你有没有足够深的感官，能在噪音里闻到真正的约束。

方法论可以共享。

感官只能自己长出来。

Sources

• Reddit AXTI / InP thesis
• Twiscan mirror of @aleabitoreddit public X posts
• Hidden Gold Rush / bottleneck hunting thread mirror

注：本文只讨论公开社交帖里体现的方法论，不构成投资建议。社交帖、X 镜像和第三方整理都只能作为研究线索，不能替代公司披露文件、财报、电话会文字稿、合同、公告和其他一手资料。

AI now feels like something you cannot avoid using, but once you use it, the bill hurts.

The real danger is not that it is expensive. The real danger is that the more useful it becomes, the more people use it; the more people use it, the less the bill looks like a tool expense and the more it looks like a tax. That is the unfinished part of the previous post, The Wintel Era Is Over.

If the PC really is entering a new era, the next correct investment direction is not another AI app, not another laptop with an AI PC sticker, and not another fight over who has higher TOPS. There is only one question worth watching: who can make high-frequency intelligent work cheaper, stabler, and more controllable after Agentic Coding becomes a necessity?

This Quarter Will Force The Question

Agentic Coding is still in the excitement phase. People are seeing that it can do real work. By the end of this quarter, many teams will face a different question: did it actually make delivery faster, or did it simply move labor cost into token cost?

This does not mean Agentic Coding lacks value. It means the opposite. Only genuinely valuable tools expose cost problems this quickly. Nobody uses useless tools every day. Useful tools enter daily workflow; once they do, they are no longer demos, POCs, or innovation budget. They become infrastructure.

The scariest thing about infrastructure is not that it is expensive. It is that every use is uncontrolled. Today, many Agents have an ugly cost structure: the expensive part is not generating a few lines of code. Before that, the Agent reads a dozen files, scans half a repo, asks the model repeatedly, retries after failures, and feeds test logs back into context.

Human engineers also explore and take wrong turns. The difference is that human exploration cost is packaged into salary, while Agent exploration cost shows up line by line in the token bill. So the question is not "should we use AI?" Teams cannot avoid it. The question is: can it become cheap enough to use all the time?

Do Not Read AI PCs Through TOPS

Most AI PC messaging is still stuck in hardware language: how many TOPS, how much NPU, which benchmark. These numbers are not useless, but they are not the language enterprises actually care about. Enterprises care about more specific questions:

• Can a PR review burn half as many tokens?
• Can a code migration understand the repo locally before it calls the cloud?
• Can a failed test log avoid going to the cloud in full every time?
• Can an Agent task use a local small model to judge difficulty before calling a frontier model?

If AI PCs work, they are not selling "smarter computers." They are selling cheaper intelligent workflows. This is why Wintel was the answer in the previous PC era, but may not be the answer in this one.

The old PC question was: can this machine run Windows software smoothly? The next PC question is: can this machine run enough local intelligence at lower cost? Those are entirely different questions. The first one is about CPU, operating system, and application ecosystem. The second one is about local runtime, model routing, context caching, memory bandwidth, GPU/NPU scheduling, enterprise policy, and developer experience.

Anyone still talking only about TOPS has not entered the real problem.

First: The Local Intelligence Routing Layer

The next important investment direction is the local model router. Not every app deciding which model to use for each request. Apps are bad at this, because an app usually does not know what hardware exists on each machine, what the battery state is, which local models are available, what enterprise policy allows to leave the device, or whether a task is worth going to the cloud.

This should become a capability shared by the OS, IDE, enterprise platform, and model runtime. A reasonable chain looks like this: simple tasks go to local small models, private context goes to local RAG or enterprise private models, routine tasks go to cheaper models, critical reasoning goes to cloud frontier models, and sensitive tasks are forbidden from leaving the device or enterprise boundary.

That is why Microsoft's Foundry Local matters. It is not just "run a model on your machine for fun." It puts a local model catalog, SDK, automatic hardware acceleration, and an OpenAI-compatible API into the application development path.

Azure AI Foundry model router points in the same direction: the platform routes according to modes such as quality, cost, and balanced. Today this mostly happens among cloud models, but the logic will eventually move across device, private, and cloud.

The real opportunity is not "we have a model list too." It is who can turn local, private, and cloud models into a governable cost-routing system.

Second: Make Repo Context Thin

The expensive part of Agentic Coding is not writing code. It is understanding code. Writing one line is cheap; finding the right place to change is expensive. Generating a diff is cheap; knowing whether the diff will break something is expensive.

So the investment opportunity in Agentic Coding is not another chat wrapper. It is the context layer: local code index, repo map, symbol graph, AST and call graph, mapping test failures to source files, log compression, tool result cache, conversation summary, and context deduplication, ranking, and pruning.

These sound unsexy, but they are the cost foundation of Agentic Coding. The repo naturally lives on the PC. IDE state lives on the PC. Terminal output lives on the PC. Local build results live on the PC. Uncommitted diffs live on the PC. If all of that is shoved into a cloud model every time so the model can understand it from scratch, the enterprise is paying tax repeatedly.

A good local context layer should turn 50k tokens of messy context into 15k tokens of useful context before the large model is called. That is not prompt optimization. It is a change in cost structure. Whoever helps Agents start from less zero directly reduces token consumption.

Third: Turn Repeated Inference Into An Asset

A large share of AI cost is repeated inference. The same repo summary, the same system prompt, the same kind of test failure, the same migration pattern, the same API document, the same enterprise policy. If each one is uploaded, understood, and paid for again, the enterprise is paying tax on repeated work.

So cache becomes important. Not as a small browser-cache style optimization, but as a foundation asset for Agent workflows. Prompt cache, semantic cache, embedding cache, tool result cache, KV cache, and failure pattern cache all move into the infrastructure layer.

AWS Bedrock's prompt caching states the point directly: caching long and repeated contexts can reduce latency and input token cost. But that is only the beginning. The valuable cache will happen at the local and workflow layers, because the most stable, reusable, privacy-sensitive context usually lives on the user's device and inside the enterprise environment.

If an engineer asks an Agent to inspect the same repo every day, why should it start from zero every time? If a team fixes the same kind of test failure every day, why should it explain the pattern again? If a company uses the same coding standards every day, why should they be pushed into the prompt repeatedly? For Agentic Coding to move from "useful but painful" to "useful and controllable," cache is unavoidable.

Fourth: High-Frequency Low-Value Tasks Must Leave The Cloud

This is easy to misunderstand. I am not saying all AI should run locally. In the short to medium term, local models do not need to beat Claude, GPT, or Gemini. They only need to absorb enough high-frequency, low- to mid-complexity tasks.

That includes intent detection, task classification, log summarization, simple code edits, local embeddings, document retrieval, sensitive-content preprocessing, and initial screening before Agent routing. These tasks do not always require the strongest model, but they happen constantly. If all of them go to the cloud, the bill gets ugly.

That is the real enterprise value of AI PCs. They are not replacing frontier models. They are reducing calls that should never have gone to the cloud. In the past, buying a PC meant buying a terminal for accessing cloud services. Next, buying an AI PC should mean buying a local intelligence node that continuously reduces cloud token spend.

If this becomes true, hardware procurement logic changes. 32 GB is no longer just "Chrome feels smoother." 64 GB is no longer just "developers feel better." Memory bandwidth, unified memory, local SSD cache, and GPU/NPU scheduling stop being only specs. They become part of token efficiency.

The question is not whether x86 or Arm has the better religion. It is who can complete the same Agent workflow with lower power, lower latency, and fewer cloud calls.

Fifth: Agents Need A Cost Brake

The biggest problem with Agents is not only that they make mistakes. It is that they can make mistakes very diligently. A normal LLM call is one input and one output, so cost is at least somewhat estimable. Agents plan, read files, call tools, fail, retry, reflect, and call tools again. Without boundaries, they can turn a simple task into an expensive trip.

A real Agent platform cannot only answer "can the task be completed?" It also has to answer how much we are willing to spend, how many steps it can take, what happens when it exceeds the token budget, whether it should downgrade the model, whether it should switch to a local model, whether it should stop and ask a human, and whether it should reuse an existing cache.

This is not a traditional FinOps dashboard. A dashboard only tells you the money has already burned. The real opportunity is putting cost control into the execution path. An Agent should know its budget before it acts, evaluate marginal return while it acts, and have a brake before it keeps burning money. Otherwise automation just becomes automatic taxation.

What I Would Watch

If the new era of PC is real, I would not only watch who sells more AI PCs. That is the result, not the cause. I would watch four categories.

First, local AI runtime and model routing layers. They unify CPU, GPU, NPU, local models, private models, and cloud models into one inference entry point that developers do not have to manage by hand.

Second, the context layer for Agentic Coding. They turn repo, IDE, terminal, test, log, and diff data into reusable local intelligence assets instead of repeatedly feeding them to cloud models.

Third, cache and cost-aware execution for Agent workflows. They do not merely display the bill. They reduce waste before each tool call, context assembly, model route, and retry.

Fourth, AI PC ecosystems that can translate hardware specs into economic outcomes. Not "how many TOPS does this machine have?" but "how many cloud tokens can this machine save the team?"

I would be cautious about the opposite: AI PCs without local runtime, TOPS without tokens per watt, Agent automation without cost boundaries, model capability without model routing, and FinOps dashboards that do not enter the execution chain. These may get attention, but they struggle to answer the real question.

The Point

So when AI PCs become the next boom, I would not first look at who sold more laptops, or whose TOPS number is higher. Those are surface outcomes. What matters is who owns the layer between the PC and the cloud model.

That layer includes local runtime, model router, context layer, workflow cache, private inference, and Agent execution control. These things do not sound like PCs, but they decide whether AI PCs can move from a marketing name into infrastructure enterprises are willing to buy.

Because enterprises will not ultimately pay for the words "AI PC." They will pay for one thing: can the same Agent workflow run cheaper, stabler, and more controllably?

If the answer is yes, AI PCs are a real boom. If the answer is no, they are just another hardware refresh narrative. So the opportunity is not in the abstract question of "who defines the PC." It is in something more specific: who can turn local compute, context, model routing, and execution cost into the default foundation for the next generation of AI workflows?

That company is selling the real picks and shovels of the AI PC era.

AI 现在有点像鸡肋：不用不行，用了看到账单又肉疼。

但真正危险的不是贵，而是它越有用，大家越会用；大家越用，账单越不像工具费，越像税。这才是上一篇《Wintel 时代结束了》没说完的部分。

如果 PC 真的要进入 new era，接下来正确的投资方向，不是再造一个 AI app，不是再给笔记本贴一个 AI PC 标签，也不是继续卷谁的 TOPS 更高。真正值得看的问题只有一个：谁能让企业在 Agentic Coding 变成刚需之后，把高频智能任务跑得更便宜、更稳定、更可控？

这个 Q 结束就会被 question

Agentic Coding 现在还在兴奋期，大家看到的是它能干活。但这个 Q 结束，很多团队会开始面对另一个问题：它到底让交付变快了，还是只是把人力成本挪到了 token 成本？

这不是说 Agentic Coding 没价值。恰恰相反，只有真正有价值的东西，才会把成本问题暴露得这么快。没用的工具没人天天用，好用的工具才会进入日常；一旦进入日常，它就不再是 demo、POC 或 innovation budget，而是基础设施。

基础设施最怕的不是贵，而是每一次使用都不可控。今天很多 Agent 的成本结构很难看：它不是生成几行代码贵，而是在生成之前，先读十几个文件，扫半个 repo，反复问模型，失败重试，再把测试日志塞回上下文。

人类工程师也会探索，也会走弯路。区别是，人类的探索成本被工资打包了，Agent 的探索成本会逐次出现在 token 账单里。所以问题不是“AI 要不要用”，不用不行；问题是：能不能让它便宜到可以一直用？

不要从 TOPS 看 AI PC

现在很多 AI PC 的讲法还停在硬件语言里：多少 TOPS、多少 NPU、多少 benchmark。这些不是没用，但不是企业真正关心的语言。企业关心的不是这台机器理论上能跑多少算力，而是这些更具体的问题：

• 一个 PR review 能不能少烧一半 token？
• 一次 code migration 能不能先在本地完成 repo 理解？
• 一段测试失败日志能不能不再每次全量上云？
• 一个 Agent task 能不能先用本地小模型判断难度，再决定要不要调用 frontier model？

AI PC 如果成立，它卖的不是“更聪明的电脑”，而是更便宜的智能工作流。这也是为什么上一轮 PC 叙事里 Wintel 是答案，这一轮不一定。

上一轮 PC 的核心问题是：能不能流畅运行 Windows 软件？下一轮 PC 的核心问题是：能不能用更低成本跑足够多的本地智能任务？这两个问题完全不同。前者看 CPU、操作系统、应用生态，后者看 local runtime、模型路由、上下文缓存、内存带宽、GPU/NPU 调度、企业策略和开发者体验。

谁还在只讲 TOPS，谁就还没进入真正的问题。

第一条线：本地智能调度层

下一步最重要的投资方向，是 local model router。不是让每个 app 自己决定这次请求该用哪个模型，这件事 app 做不好。因为 app 不知道每台机器有什么硬件，不知道当前电池状态，不知道本地有什么模型，不知道企业策略允许什么数据出设备，也不知道这个任务到底值不值得上云。

这应该是 OS、IDE、企业平台和模型 runtime 共同承担的能力。合理的链路应该是：简单任务走本地小模型，私有上下文走本地 RAG 或企业私有模型，中等任务走便宜模型，关键推理才走云端 frontier model，敏感任务禁止出设备或出企业边界。

Microsoft 做 Foundry Local 的意义就在这里。它不是“本机跑模型玩一下”，而是把本地模型 catalog、SDK、自动硬件加速和 OpenAI-compatible API 放到应用开发链路里。

Azure AI Foundry model router 也在往同一个方向走：让平台根据 quality、cost、balanced 等模式做路由。现在它更多发生在云端模型之间，但逻辑迟早会下沉到 device / private / cloud 之间。

真正的机会不是“我也有一个模型列表”，而是谁能把本地、私有、云端模型变成一个可治理的成本路由系统。

第二条线：把 repo context 做薄

Agentic Coding 最贵的地方，不是写代码，而是理解代码。写一句代码不贵，找出应该改哪里很贵；生成 diff 不贵，知道这个 diff 会不会炸很贵。

所以 Agentic Coding 的投资机会，不在“再包一层聊天界面”，而在 context layer。它包括本地代码索引、repo map、symbol graph、AST / call graph、测试失败到源文件的映射、日志压缩、tool result cache、conversation summary，以及上下文去重、排序、裁剪。

这些东西听起来不性感，但它们才是 Agentic Coding 的成本底座。因为 repo 天然在 PC 上，IDE 状态在 PC 上，terminal 输出在 PC 上，本地构建结果在 PC 上，未提交的 diff 也在 PC 上。如果每次都把这些东西粗暴塞给云端模型，让模型重新理解一遍，那就是在重复交税。

一个好的本地 context layer，应该在调用大模型之前，把 50k token 的混乱上下文压成 15k token 的有效上下文。这不是优化 prompt，而是改变成本结构。谁能让 Agent 少从零开始，谁就在直接降低 token 消耗。

第三条线：把重复推理变成资产

AI 账单里有大量浪费，本质上是重复推理。同一个 repo summary、同一个 system prompt、同一种 test failure、同一类 migration pattern、同一份 API 文档、同一个企业 policy，如果每次都重新上传、重新理解、重新付钱，企业就是在给重复劳动交税。

所以 cache 会变得非常重要。不是浏览器缓存那种小优化，而是 Agent workflow 的底层资产：prompt cache、semantic cache、embedding cache、tool result cache、KV cache、failure pattern cache，都会进入基础设施层。

AWS Bedrock 的 prompt caching 已经把这件事讲得很直白：对长且重复的上下文做缓存，可以降低延迟和 input token 成本。但这只是开始，真正有价值的 cache 会发生在本地和工作流层，因为最稳定、最可复用、最隐私敏感的上下文，往往就在用户设备和企业环境里。

一个工程师每天让 Agent 看同一个 repo，为什么每次都要从零开始？一个团队每天修同一类测试失败，为什么每次都要重新解释？一个公司每天用同一套代码规范，为什么每次都要重新塞进 prompt？Agentic Coding 要从“好用但肉疼”变成“好用且可控”，cache 是绕不开的。

第四条线：高频低价值任务必须下云

这里很容易误解。我不是说所有 AI 都要本地跑。短中期内，本地模型不需要打败 Claude、GPT 或 Gemini，它只需要吃掉足够多的高频、低中复杂度任务。

比如意图识别、任务分类、日志摘要、简单代码修改、本地 embedding、文档检索、敏感内容预处理、Agent 路由前的初筛。这些任务不一定需要最强模型，但调用频率非常高，一旦全部上云，账单会很难看。

这就是 AI PC 的真正企业价值。它不是替代 frontier model，而是减少不该上云的调用。过去买 PC，是买一个访问云服务的终端；接下来买 AI PC，应该是买一个能持续减少云端 token 支出的本地智能节点。

这件事一旦成立，硬件采购逻辑就会变。32GB 不再只是“开 Chrome 更顺”，64GB 不再只是“开发者爽一点”，内存带宽、统一内存、SSD 本地缓存、GPU/NPU 调度，都不再只是参数。它们都会变成 token efficiency 的一部分。

不是 x86 和 Arm 谁更有信仰，而是谁能用更低功耗、更低延迟、更少云端调用，把同样的 Agent workflow 跑完。

第五条线：Agent 需要成本刹车

Agent 最大的问题，不只是会犯错，而是它会很努力地犯错。普通 LLM 调用，一次输入一次输出，成本还算可估；Agent 不一样，它会规划、读文件、调用工具、失败重试、反思、再调用工具。没有边界，它可以把一个简单任务跑成一次昂贵旅行。

所以真正的 Agent 平台不能只回答“能不能完成任务”，还要回答准备用多少钱完成、最多跑多少步、超过 token budget 怎么办、要不要降级模型、要不要改走本地模型、要不要停下来问人、要不要复用已有 cache。

这不是传统意义上的 FinOps dashboard。dashboard 只能告诉你钱已经烧了，真正的机会在于把成本控制放进执行路径里。Agent 在行动前就应该知道预算，在行动中应该不断评估边际收益，在继续烧钱前应该有刹车。否则所谓自动化，最后就是自动交税。

我会看什么

如果 new era of PC 成立，我不会只看谁卖出更多 AI PC。那是结果，不是因。我会看四类公司。

第一，local AI runtime 和模型路由层。它们把 CPU、GPU、NPU、本地模型、私有模型、云端模型统一成一个开发者不用操心的推理入口。

第二，Agentic Coding 的 context layer。它们把 repo、IDE、terminal、test、log、diff 变成可复用的本地智能资产，而不是每次都重新塞给云端模型。

第三，面向 Agent workflow 的 cache 和 cost-aware execution。它们不只是展示账单，而是在每一次工具调用、上下文拼接、模型路由、失败重试之前减少浪费。

第四，真正能把硬件参数翻译成经济结果的 AI PC 生态。不是“这台机器有多少 TOPS”，而是“这台机器能让团队少烧多少云端 token”。

反过来，我会警惕几类东西：只讲 AI PC，不讲本地 runtime；只讲 TOPS，不讲 tokens per watt；只讲 Agent 自动化，不讲成本边界；只讲大模型能力，不讲 model routing；只讲 FinOps dashboard，不介入执行链路。这些东西可能有热度，但很难回答真正的问题。

最后

所以，当 AI PC 成为新的风口，我不会先看谁多卖了几台笔记本，也不会先看谁的 TOPS 更高。那些都是表层结果。真正值得看的，是谁站在 PC 和云端模型之间那一层。

这层东西包括 local runtime、model router、context layer、workflow cache、private inference、Agent execution control。它们听起来不像 PC，但它们才决定 AI PC 能不能从 marketing name 变成企业愿意买单的基础设施。

因为企业最后不会为 AI PC 这三个字付钱。企业会为一件事付钱：同样的 Agent workflow，能不能更便宜、更稳定、更可控地跑完。

如果答案是能，AI PC 才是真风口。如果答案是不能，它就只是又一轮硬件换机叙事。所以这轮机会不在“谁定义 PC”这么抽象的问题里，而在更具体的地方：谁能把本地算力、上下文、模型路由和执行成本，做成下一代 AI 工作流的默认底座。

谁就在卖 AI PC 时代真正的铲子。

An old thing that had lost its spotlight to mobile for more than a decade suddenly returned to the center of the table.

Many people's first reaction was: AI PCs are coming again.

I think that is too shallow.

The PC is not becoming a hot topic again because it suddenly became sexy, nor because the giants want to give laptops a new marketing name. The real reason is more practical, and more uncomfortable:

Cloud AI is too expensive.

Over the past two years, companies buying AI often ended up realizing they were not buying efficiency. They were working for model vendors. Tokens kept burning. Bills kept rising. Bosses kept asking about ROI. Teams kept tuning prompts. In the end, the only thing that looked more futuristic was the bill. Productivity was still stuck in the past.

Especially with Agentic Coding.

It has already proven useful. Writing code, changing code, running tests, reading repos, doing migrations, cleaning up technical debt. These are not tricks. They are real needs. The problem is that once something is truly useful, usage explodes. Once usage explodes, token cost becomes a tax.

The paradox of AI is this: the more useful it is, the more expensive it becomes; the more automated it is, the less controllable it becomes.

That is why the PC is back.

Not the old PC used to open Excel, browse the web, and plug into a monitor. A new thing:

A personal AI compute node.

The Wintel era is over.

Not because Intel will collapse tomorrow. Not because x86 will suddenly leave the stage. An architecture that ruled the PC for forty years will not be buried by a few tweets.

But the value anchor of the PC has changed.

In the past, the default answer for a PC was Windows + Intel/x86. Next, the core question for a PC will become: can this machine handle enough local intelligence work at a lower cost?

Whoever can answer that question stands at the center of the new era.

Why Is The PC Hot Again?

For more than a decade, the PC has felt like an old friend left behind by the times.

It is still there. We still use it every day. Work depends on it. Code is written on it. Documents are edited on it. Meetings happen on it. Financial reports are read on it.

But it is no longer sexy.

What is sexy is mobile, apps, Feed, short video, super apps, always-online everything. The PC is more like an office desk: important, but not imaginative.

Because for more than a decade, the most valuable computing left the PC.

Storage moved to the cloud. Applications moved to SaaS. Consumption moved to mobile. Collaboration moved to the browser. Compute became something you buy on demand. The PC slowly became a terminal, a screen, a keyboard, a browser container.

It did not need to be that powerful.

The valuable things were in the cloud.

That logic worked in the past. Companies bought SaaS. Users opened browsers. Data lived in the cloud. Collaboration happened in the cloud. The local machine only needed to be smooth enough not to get in the way.

So PCs became cheaper, and more boring.

But AI reversed this.

AI is not just another SaaS. The core cost of AI is not the page, the account, permissions, or the database. It is every inference. Every prompt, every context expansion, every tool call, every detour an Agent takes in the background, is token spend.

The PC lost imagination in the past because local compute no longer determined productivity.

Local compute matters again because intelligence itself has become productivity.

That is why the PC is back at the table.

It is not a PC revival.

It is the cost structure of cloud AI pushing the PC back.

The SaaS Math Does Not Apply To AI

Many people misread AI because they are still using a SaaS framework to understand it.

What is SaaS?

You buy a seat and pay monthly. The more users use it, the happier the vendor is. The software has already been written, server costs are relatively controllable, and marginal costs are diluted by scale.

For companies, SaaS is also easy to calculate.

One person pays 30 dollars a month. You can roughly estimate how much time it saves, how many processes it removes, and how much manual coordination it replaces. Even if the estimate is imperfect, at least the bill is stable.

AI is not like that.

AI billing is not seat-based. It is usage-based. You are not paying to "own a capability." You are paying for "each use of that capability."

The more you use it, the higher the bill.

The more successful the automation, the more frequent the calls.

The harder the Agent works, the faster tokens burn.

This is the opposite of the SaaS economic model.

The best part of SaaS is that marginal cost is hidden by the vendor. Companies buy certainty: fixed subscription, continuous usage, and better economics as usage rises.

The worst part of token pricing is that marginal cost is thrown back in the company's face. Companies buy uncertainty: nobody knows how much they will spend today, how much they will spend tomorrow, or how many steps an Agent took in the background.

SaaS sells efficiency certainty. Tokens sell cost uncertainty.

That is why many AI projects produce awkward expressions once they land.

The demo is stunning.

The POC looks promising.

Everyone in the weekly meeting feels the future has arrived.

Then the bill arrives.

Once the bill arrives, many things start to look wrong.

It turns out a simple task made the Agent read more than a dozen files, open dozens of context rounds, call several tools, and reflect on itself several times in the middle. It looked very intelligent. The bill was also very intelligent.

More awkwardly, the result was not stable.

Human employees may be expensive, but at least the cost is fixed. How much an engineer costs per month is basically clear. An Agent is different. It is like an intern paid by mileage: the harder it runs, the more expensive it becomes, and it may not know when it has gone off track.

So the first-principles question for enterprise AI is not "is the model strong enough?"

It is:

Does this make economic sense?

Agentic Coding Breaks The Contradiction Open

Why does this contradiction show up first in Agentic Coding?

Because coding is one of the few AI use cases that has already proven useful.

Using AI to write ad copy is often just a bonus. Using AI to summarize meetings may be useful, or may never be read. Using AI to generate images is more often entertainment or an assistant inside a design workflow.

Agentic Coding is different.

Code is structured. Feedback is clear. Tasks are high-frequency. Value is measurable. It can read repos, change code, generate diffs, run tests, explain errors, do migrations, and clean up technical debt.

It is not "possibly useful."

It is actually useful.

That is also what makes it dangerous.

If something is useless, nobody burns much money on it. The things that truly burn money are always useful things.

Once Agentic Coding enters the workflow, it becomes a necessity. Engineers want to use it every day. Teams want to use it every day. Bosses also want everyone to use it more, because it really does work.

But the way it works is expensive.

Writing one line of code is not expensive. Understanding a repo is expensive.

Changing one function is not expensive. Figuring out where to change is expensive.

Generating a diff is not expensive. Repeatedly verifying it, running tests, fixing errors, and running tests again is expensive.

The core consumption of Agentic Coding is often not in the final lines of code. It is in all the exploration, reading, reasoning, trial and error, rollback, and retry before that.

This is very similar to how humans write code.

The difference is that human exploration cost is already packaged into salary. An Agent's exploration cost appears line by line on the token bill.

That is why Agentic Coding will become a necessity while forcing companies to rethink their cost structure.

Agentic Coding proves that AI is useful, and also proves that all-cloud AI is too expensive.

That sounds contradictory, but it is not.

Precisely because it is useful, it becomes high-frequency.

Precisely because it is high-frequency, it cannot stay expensive forever.

The Value Of Local LLMs Is Not Being Smarter, But Being Cheaper

When people discuss local LLMs, they often ask one question:

Can a local model beat Claude? Can it beat GPT? Can it beat Gemini?

That is the wrong question.

In the short to medium term, local LLMs do not need to beat frontier models.

They only need to absorb enough low- and medium-complexity tasks.

That is enough.

What companies really need is not to call the strongest model for every request, but to stratify intelligence.

Simple tasks go to the local model.

Medium tasks go to an internal company model.

Complex tasks, key decisions, and hard reasoning go to a cloud frontier model.

That is a normal cost structure.

Many teams are using AI in an extravagant way today. Completion, summarization, search, simple refactoring, script writing, log explanation, test generation. Everything goes to the most expensive cloud model.

That is like delivering takeout in first class.

It can be done.

The math is wrong.

The value of local LLMs is not turning every computer into AGI. Their real value is absorbing a large volume of tasks that are not worth calling a frontier model for, leaving cloud tokens for the places where they are truly needed.

The value of local LLMs is not being smarter. It is being cheaper.

More precisely, it is having a healthier cost structure.

Buying tokens is opex: continuous spend, pay per use.

Buying hardware is capex: one-time spend, with depreciation. Spread over three or five years, as long as usage frequency is high enough, local compute becomes cheaper than cloud tokens.

This may not be that sensitive for individual users.

But companies are very sensitive to it.

One engineer calls an Agent dozens of times a day. A whole team calls it thousands of times a day. Add CI, code review, automated testing, knowledge-base Q&A, document generation, and log analysis, and token spend quickly stops being "small money."

When AI moves from toy to infrastructure, cost structure moves from "experience issue" to "life-or-death issue."

So local LLMs are not a belief system.

They are accounting.

The PC Becomes A Compute Asset Again

This is where the PC becomes important again.

Phones are important, of course. But phones are more like attention devices. They handle messages, consumption, photos, payments, social interaction, and instant response.

The PC is different.

The PC is a productivity device. It has a keyboard, a large screen, a file system, an IDE, a terminal, a browser, enterprise software, local data, development environments, repos, scripts, logs, and permission boundaries.

If an Agent is going to do real work, it is not swiping around on a phone.

It needs to read files, change code, run tests, look things up, call tools, connect to enterprise systems, and execute tasks across applications.

These things naturally happen on the PC.

Phones consume intelligence. PCs produce intelligence.

That is why an AI PC cannot be understood merely as "a laptop with an extra NPU."

That is too narrow.

The real new PC is not an extra Copilot key, nor a system assistant that can chat. It is a local intelligent work node.

It needs to handle part of model inference.

It needs to process private context.

It needs to finish low-latency tasks locally.

When cloud tokens are too expensive, it needs to intercept enough intelligent work.

When necessary, it routes complex tasks to the cloud.

In other words, the PC is no longer just a terminal for accessing cloud services.

The PC becomes a compute asset again.

That is what is really worth watching behind "A new era of PC."

Not that the PC is suddenly going back to the center of the 2000s.

But that AI's cost structure is forcing part of computing back from the cloud to local machines.

Wintel Is Just The Name Of The Old Order

Intel is still at the table. x86 will certainly not disappear overnight. If the only goal is running local models, CPU architecture itself may not even be the most important variable.

What really matters is memory bandwidth, GPU/NPU throughput, software stack, model scheduling, power, thermals, developer ecosystem, and the stratified experience across cloud / local / edge.

Intel has cards.

AMD has cards.

Qualcomm has cards.

Apple has already proven another path can work.

But the word "Wintel" still matters.

Because it is not a technical term. It is the name of the old PC order.

The old default understanding of the PC was simple:

Windows + x86 + OEM + local applications + cloud SaaS.

Users did not need to understand that combination when buying a computer. The industry arranged it for them. Intel defined the hardware rhythm. Microsoft defined the operating system. OEMs shipped the machines. NVIDIA and AMD added weight in graphics or high-performance scenarios.

That order ran for decades.

Its core question was: can this machine run Windows software smoothly?

But the core question for the next PC has changed:

Can this machine run enough local intelligence tasks at a lower cost?

These are questions from two different eras.

For the first question, Wintel was the answer.

For the second question, Wintel is not necessarily the answer.

That is what it means for the Wintel era to be over.

Not that Intel disappears.

Not that Windows disappears.

Not that x86 disappears.

But that the default understanding of "PC = Windows + x86" is no longer enough to explain the next generation of PCs.

Who Is Calling For The New PC?

Now look back at those "A new era of PC" posts, and it gets interesting.

Why is NVIDIA saying it?

Because it cannot stay only in the data center.

If all AI happens in the cloud, NVIDIA has already won one round. But if companies start pushing a large amount of inference down to local machines for token efficiency, NVIDIA must enter the PC.

It needs to bring GPU, CUDA, local inference, developer ecosystem, and AI runtime back to personal devices.

It is not just selling chips.

It is selling the intelligence foundation of the next PC.

Why is Microsoft saying it?

Because Windows is the entry point for enterprise workflows.

If AI Agents are really going to land, Windows cannot remain a shell for opening cloud services. It has to become the operating system for local intelligent workflows: able to call models, manage permissions, connect applications, understand files, and route between local and cloud.

What Microsoft fears most is not that the PC market stops growing.

It fears that the workflow entry point of the AI era no longer belongs to Windows.

Why is Arm saying it?

Because local intelligence needs performance per watt.

Apple Silicon has already taught the market that laptops can be both powerful and efficient. If the Windows camp wants to catch up in AI PCs, it cannot keep relying only on the traditional path.

This time Arm is not saying "I can run Windows."

It is saying: the hardware form of the next PC no longer has to revolve around the old architecture.

So who is still using old language to talk about new PCs?

Many traditional players are still talking about CPU, frequency, core count, benchmarks, AI TOPS, and product-line updates.

These all matter, but they are not enough.

The real question for the new era is not "are the specs stronger?" It is "is the cost structure better?"

Can this machine burn fewer tokens?

Can it keep low-value requests local?

Can it make companies pay less tax to model vendors?

Can it turn Agentic Coding from an expensive toy into everyday infrastructure?

Whoever can answer those questions deserves to talk about the new PC.

The Cloud AI Tax

Over the past two years, AI companies have told many grand narratives.

AGI, agent, copilot, automation, super intelligence.

These words are sexy.

But companies eventually face another table: the bill.

That table is not sexy, but it is real.

When all intelligence is priced through cloud tokens, AI becomes a new tax. Every step you automate, you pay a tax. Every time you let an Agent think one more round, you pay a tax. Every time you connect a workflow, you pay a tax.

This is not to say model vendors are bad.

Training models, deploying models, and maintaining inference clusters are expensive. If someone provides a capability, of course they should charge for it.

But companies cannot build their automation forever on intelligence that someone else bills per call.

Especially for high-frequency, necessary, low- and medium-complexity tasks.

Once all these tasks move to the cloud, a company's cost structure increasingly looks like working for model vendors. Business growth may not be obvious. Bill growth definitely will be.

So local LLMs are not just a technical path.

They are bargaining power.

When a company has no local intelligence capability, every request can only go to the cloud. The model vendor names the price.

When a company has local intelligence capability, it at least has a choice.

Simple tasks run locally.

Sensitive data runs locally.

High-frequency tasks run locally.

Complex tasks go to the cloud.

This is not full replacement. It is redistribution.

The greatest value of local intelligence is giving companies back part of their cost control.

That is also why the PC becomes an asset again.

In the past, buying a high-performance PC often looked like a consumer electronics upgrade.

Now, buying an AI PC that can run local models looks more like buying a small compute node. It is not for making fans spin louder, nor for making spec sheets prettier. It is for continuously reducing token spend over the next few years.

Companies will do that math.

A New Era Is Not Created By A Launch Event

Of course, saying "A new era of PC" does not mean the new era has truly arrived.

There are still many traps.

Are local models good enough?

Can Windows make the local AI runtime smooth?

Will developers adapt?

Can enterprise IT manage these local models?

How should security and permissions work?

How should model updates work?

How should local and cloud routing work?

Who schedules the NPU, GPU, and CPU?

None of these questions is simple.

And the biggest problem of the PC camp has not changed: it is not Apple.

Apple can decide chips, operating system, developer tools, hardware form factor, and user experience as one company. Windows PCs are an alliance. Microsoft, NVIDIA, Arm, Intel, AMD, Qualcomm, OEMs, and developers all want to win, and each controls only one part.

The advantage of an alliance is openness.

The disadvantage of an alliance is that nobody is fully in charge.

So whether this new PC narrative works does not depend on a launch event, or on a few tweets. It depends on whether it can hide the complexity.

Users do not care what architecture you use.

Companies do not care how many TOPS you have.

Engineers also do not want to study every day which task should use which model, runtime, or backend.

Everyone cares about one thing:

Can the work be done more cheaply?

If the answer is yes, the new PC is real.

If the answer is no, it is just another round of AI PC marketing.

The Unspoken Name After PC

So when several giants simultaneously say "A new era of PC," I do not think the point is PC.

The point is new era.

In the old era, the PC was the default combination of Windows + x86, the terminal for accessing SaaS and cloud services, the office device that kept working quietly after mobile took away the spotlight.

In the new era, the PC may become something else:

A personal AI compute node.

It does not necessarily handle the strongest reasoning, but it must handle the highest-frequency reasoning.

It does not necessarily replace cloud models, but it must reduce dependence on cloud tokens.

It does not necessarily give everyone AGI, but it must prevent companies from paying model vendors a tax on every automation.

The Wintel era is over, not because Intel has failed.

It is because the core question for the next PC is no longer "can it run Windows?"

It is:

Can it afford to run intelligence?

For the past forty years, the default answer for the PC was Wintel.

Over the next few years, that default answer will be taken apart and recombined. Windows is still here. Intel is still here. x86 is still here. OEMs are still here.

But the era in which everyone played around the same hardware rhythm is over.

So the sharp part of "A new era of PC" is not "new era."

It is the unspoken question after PC:

When tokens become expensive enough that everyone starts buying local compute again, who still gets to define the PC?

一个被 mobile 抢走十几年光环的老东西，突然又回到了牌桌中央。

很多人第一反应是：AI PC 又要来了。

我觉得这说浅了。

PC 重新成为热点，不是因为 PC 突然性感了，也不是因为巨头们想给笔记本换一个新的 marketing name。真正的原因更现实，也更难听：

云端 AI 太贵了。

过去两年，企业买 AI，买到最后常常发现自己不是在买效率，而是在给模型厂商打工。Token 一路烧，账单一路涨，老板天天问 ROI，团队天天调 prompt，最后除了账单更像未来，人效还停在过去。

尤其是 Agentic Coding。

它已经被证明有用。写代码、改代码、跑测试、读 repo、做 migration、清理技术债，这些都不是花活，而是刚需。问题是，只要它真的有用，使用频率就会暴涨；使用频率一暴涨，token 成本就会变成税。

AI 的悖论是：越有用，越贵；越自动化，越不可控。

这就是为什么 PC 又回来了。

不是那个用来打开 Excel、刷网页、接显示器的旧 PC，而是一个新的东西：

个人 AI 算力节点。

Wintel 时代结束了。

不是 Intel 明天倒闭，也不是 x86 突然退场。一个统治了 PC 四十年的架构，不会被几条 tweet 埋掉。

但 PC 的价值锚点变了。

过去 PC 的默认答案是 Windows + Intel/x86。接下来，PC 的核心问题会变成：这台机器能不能用更低成本吃掉足够多的本地智能任务？

谁能回答这个问题，谁就站在新时代中心。

PC 为什么又热了？

过去十几年，PC 一直像一个被时代落下的老朋友。

它还在。每天都用。工作离不开它。代码要在上面写，文档要在上面改，会议要在上面开，财报要在上面看。

但它不再性感。

性感的是 mobile，是 App，是 Feed，是短视频，是 super app，是随时随地在线。PC 更像一张办公桌，很重要，但没什么想象力。

因为过去十几年，最值钱的计算都离开了 PC。

存储去了云端，应用去了 SaaS，消费去了 mobile，协作去了浏览器，算力变成按需购买。PC 慢慢变成一个终端，一个屏幕，一个键盘，一个浏览器容器。

它不需要太强。

真正值钱的东西在云上。

这套逻辑在过去是 work 的。企业买 SaaS，用户打开浏览器，数据放在云端，协作在云端完成，本地机器只要足够流畅，别拖后腿就行。

所以 PC 变便宜了，也变无聊了。

但 AI 把这件事反过来了。

AI 不是又一个 SaaS。AI 的核心成本不在页面，不在账号，不在权限，也不在数据库，而在每一次推理。每一次 prompt，每一次上下文扩展，每一次工具调用，每一次 Agent 自己在后台绕路，都是 token。

过去 PC 失去想象力，是因为本地算力不再决定生产力。

现在本地算力重新重要，是因为智能本身变成了生产力。

这就是 PC 回到牌桌的原因。

不是 PC 复兴了。

是云端 AI 的成本结构，把 PC 又推了回来。

SaaS 的账，不能套在 AI 上

很多人误判 AI，是因为他们还在用 SaaS 的框架看 AI。

SaaS 是什么？

你买一个 seat，按月付费。用户用得越多，供应商越开心。因为软件已经写好了，服务器成本相对可控，边际成本会被规模摊薄。

对企业来说，SaaS 的账也好算。

一个人一个月花 30 美元，省了多少时间，减少多少流程，替代多少人肉协作，大致能估出来。哪怕估不准，至少账单是稳定的。

AI 不是这样。

AI 的账单不是 seat-based，而是 usage-based。你不是为“拥有能力”付费，而是为“每一次使用能力”付费。

用得越多，账单越高。

自动化越成功，调用越频繁。

Agent 越勤奋，token 烧得越快。

这跟 SaaS 的经济模型是反的。

SaaS 最爽的地方，是边际成本被供应商藏起来。企业买到的是确定性：固定订阅，持续使用，效率越高越划算。

Token 最痛的地方，是边际成本被重新塞回企业脸上。企业买到的是不确定性：今天花多少不知道，明天花多少不知道，Agent 在后台跑了多少步也不知道。

SaaS 卖的是效率确定性，token 卖的是成本不确定性。

这就是为什么很多 AI 项目落地之后，老板的表情会很微妙。

Demo 很惊艳。

POC 很有希望。

周会上大家都觉得未来来了。

然后账单来了。

账单一来，很多事就不对劲了。

原来一次简单任务，Agent 读了十几个文件，开了几十轮上下文，调用了好几个工具，中间还自我反思了几次。看起来很智能，账单也很智能。

更尴尬的是，效果还不稳定。

人类员工再贵，至少成本是固定的。一个工程师一个月多少钱，基本清楚。Agent 不一样，它像一个按里程收费的实习生，跑得越勤快越贵，还不一定知道自己跑偏了。

所以企业 AI 的第一性问题，不是“模型够不够强”。

而是：

这件事能不能在经济上成立？

Agentic Coding 把矛盾打穿了

为什么这轮矛盾会先在 Agentic Coding 上爆出来？

因为 coding 是少数已经证明 AI 有用的场景。

让 AI 写广告文案，很多时候是锦上添花。让 AI 总结会议，也许有用，也许没人看。让 AI 画图，更多是娱乐或设计流程里的辅助。

但 Agentic Coding 不一样。

代码是结构化的，反馈是明确的，任务是高频的，价值是可衡量的。它能读 repo，能改代码，能生成 diff，能跑测试，能解释错误，能做 migration，能清理技术债。

它不是“可能有用”。

它是真有用。

这也是它危险的地方。

一个东西没用，没人会烧太多钱。真正烧钱的东西，一定是有用的东西。

Agentic Coding 一旦进入工作流，就会变成刚需。工程师每天都想用，团队每天都想用，老板也会希望大家多用。因为它真的能干活。

但它干活的方式很贵。

写一句代码不贵，理解一个 repo 很贵。

改一个函数不贵，找出应该改哪里很贵。

生成一个 diff 不贵，反复验证、跑测试、修错误、再跑测试很贵。

Agentic Coding 的核心消耗，往往不在最后那几行代码，而在前面大量探索、读取、推理、试错、回滚和重试。

这跟人写代码很像。

区别是，人类的探索成本已经被工资打包了。Agent 的探索成本会逐次出现在 token 账单里。

这就是为什么 Agentic Coding 一方面会成为刚需，另一方面又会逼着企业重新思考成本结构。

Agentic Coding 证明了 AI 有用，也证明了全云端 AI 太贵。

这句话听起来矛盾，其实一点都不矛盾。

正因为它有用，所以它会高频。

正因为它高频，所以它不能一直贵。

本地 LLM 的价值不是更聪明，而是更便宜

很多人讨论本地 LLM，会问一个问题：

本地模型能不能打过 Claude？能不能打过 GPT？能不能打过 Gemini？

这个问题问错了。

短中期内，本地 LLM 不需要打败 frontier model。

它只需要吃掉足够多的低中复杂度任务。

这就够了。

企业真正需要的不是每一次请求都调用最强模型，而是把智能分层。

简单任务交给本地模型。

中等任务交给公司内部模型。

复杂任务、关键决策、高难推理，再交给云端 frontier model。

这才是正常的成本结构。

现在很多团队的 AI 使用方式太奢侈了。无论是补全、摘要、搜索、简单重构、写脚本、解释日志，还是生成测试，全部往最贵的云端模型上打。

这就像拿头等舱送外卖。

不是不能送。

是账不对。

本地 LLM 的价值，不是让每台电脑都变成 AGI。它真正的价值，是把大量不值得调用 frontier model 的任务吃掉，把云端 token 留给真正需要的地方。

本地 LLM 的价值不是更聪明，而是更便宜。

更准确地说，是成本结构更健康。

买 token 是 opex，持续支出，用一次付一次。

买硬件是 capex，一次性支出，还有折旧期。三年、五年摊下来，只要使用频率足够高，本地算力就会比云端 token 划算。

这件事对个人用户可能没那么敏感。

但对企业很敏感。

一个工程师每天调用几十次 Agent，整个团队每天调用几千次。再加上 CI、code review、自动化测试、知识库问答、文档生成、日志分析，token 很快就不是“小钱”。

当 AI 从玩具变成基础设施，成本结构就会从“体验问题”变成“生死问题”。

所以本地 LLM 不是信仰。

是会计。

PC 重新成为算力资产

这就是 PC 重新重要的地方。

手机当然重要，但手机更像注意力设备。它负责消息、消费、拍摄、支付、社交、即时响应。

PC 不一样。

PC 是生产力设备。它有键盘，有大屏，有文件系统，有 IDE，有 terminal，有浏览器，有企业软件，有本地数据，有开发环境，有 repo，有脚本，有日志，有权限边界。

Agent 真要干活，不是在手机上刷来刷去。

它要读文件，改代码，跑测试，查资料，调工具，连企业系统，跨应用执行任务。

这些东西天然发生在 PC 上。

手机负责消费智能，PC 负责生产智能。

这就是为什么 AI PC 不能只理解成“笔记本里多了一个 NPU”。

那太窄了。

真正的新 PC，不是多一个 Copilot 按键，也不是多一个会聊天的系统助手，而是一个本地智能工作节点。

它要承担一部分模型推理。

它要处理私人上下文。

它要在本地完成低延迟任务。

它要在云端 token 太贵的时候，把足够多的智能任务拦下来。

它要在必要时再把复杂任务路由到云端。

换句话说，PC 不再只是访问云服务的终端。

PC 重新变成算力资产。

这才是"A new era of PC"背后真正值得看的东西。

不是 PC 突然要重回 2000 年代的中心。

而是 AI 的成本结构，把一部分计算从云端逼回了本地。

Wintel 只是旧秩序的名字

Intel 当然还在牌桌上。x86 当然也不会突然消失。如果只是跑本地模型，CPU 架构本身甚至不是最关键变量。

真正关键的是 memory bandwidth、GPU/NPU 吞吐、软件栈、模型调度、功耗、散热、开发者生态，以及 cloud / local / edge 之间的分层体验。

Intel 有牌。

AMD 有牌。

Qualcomm 有牌。

Apple 也早就证明了另一条路能打。

但"Wintel"这个词仍然有意义。

因为它不是一个技术名词，而是旧 PC 时代的秩序名词。

过去 PC 的默认理解很简单：

Windows + x86 + OEM + 本地应用 + 云端 SaaS。

用户买电脑，不需要理解这些组合。行业自然会替你安排好。Intel 定义硬件节奏，Microsoft 定义操作系统，OEM 负责出货，NVIDIA 和 AMD 在图形或高性能场景里加码。

这套秩序运行了几十年。

它的核心问题是：这台机器能不能流畅运行 Windows 软件？

但下一代 PC 的核心问题变了：

这台机器能不能用更低成本跑足够多的本地智能任务？

这是两个时代的问题。

前一个问题，Wintel 是答案。

后一个问题，Wintel 不一定是答案。

这才是 Wintel 时代结束的含义。

不是 Intel 消失。

不是 Windows 消失。

不是 x86 消失。

而是"PC = Windows + x86"这个默认理解，不够解释下一代 PC 了。

谁在喊新 PC？

这时候再回头看那几条"A new era of PC"，就有意思了。

NVIDIA 为什么喊？

因为它不能只守在 data center。

如果所有 AI 都发生在云端，NVIDIA 已经赢了一轮。但如果企业为了 token efficiency，开始把大量推理任务下沉到本地，NVIDIA 就必须进入 PC。

它要把 GPU、CUDA、local inference、开发者生态和 AI runtime 带回个人设备。

它卖的不只是芯片。

它卖的是下一代 PC 的智能底座。

Microsoft 为什么喊？

因为 Windows 是企业工作流入口。

如果 AI Agent 真要落地，Windows 不能只是打开云服务的壳。它必须变成本地智能工作流的操作系统：能调模型，能管权限，能接应用，能理解文件，能在本地和云端之间做路由。

Microsoft 最怕的不是 PC 市场不增长。

它最怕的是，AI 时代的工作流入口不再属于 Windows。

Arm 为什么喊？

因为本地智能需要性能功耗比。

Apple Silicon 已经教育了整个市场：笔记本不是不能既强又省电。Windows 阵营如果要在 AI PC 上追，就不能继续只靠传统路径。

Arm 这次喊的不是“我能跑 Windows”。

它喊的是：下一代 PC 的硬件形态，可以不再围着旧架构转。

那谁还在用旧语言讲新 PC？

很多传统玩家还在讲 CPU、频率、核数、benchmark、AI TOPS、产品线更新。

这些都重要，但不够。

新时代真正要回答的问题不是“参数更强了吗”，而是“成本结构变好吗”。

这台机器能不能少烧 token？

能不能把低价值请求留在本地？

能不能让企业少给模型厂商交税？

能不能让 Agentic Coding 从一个昂贵玩具，变成日常基础设施？

谁能回答这些问题，谁才配谈新 PC。

云端 AI 的税

过去两年，AI 公司讲了很多宏大叙事。

AGI、agent、copilot、automation、super intelligence。

这些词都很性感。

但企业最后面对的是另一张表：账单。

这张表不性感，但真实。

当所有智能都通过云端 token 计价，AI 就像一种新税。你每自动化一步，就交一次税。你每让 Agent 多思考一轮，就交一次税。你每把工作流接进去，就交一次税。

这不是说模型厂商坏。

训练模型、部署模型、维护推理集群，本来就贵。别人提供能力，当然要收费。

问题在于，企业不能永远把自己的自动化建立在别人按次计费的智能上。

尤其是高频、刚需、低中复杂度任务。

这些任务一旦全部云端化，企业的成本结构会越来越像给模型厂商打工。业务增长未必明显，账单增长一定明显。

所以本地 LLM 不只是技术路线。

它是一种议价权。

当企业没有本地智能能力时，所有请求都只能上云。模型厂商说多少钱，就是多少钱。

当企业有本地智能能力时，它至少可以选择。

简单任务本地跑。

敏感数据本地跑。

高频任务本地跑。

复杂任务再上云。

这不是完全替代，而是重新分配。

本地智能最大的价值，是让企业重新拿回一部分成本控制权。

这也是 PC 重新变成资产的原因。

过去买一台高性能 PC，很多时候像消费电子升级。

现在买一台能跑本地模型的 AI PC，更像买一个小型算力节点。它不是为了让风扇转得更响，也不是为了让参数更好看，而是为了在未来几年持续减少 token 支出。

这笔账，企业会算。

新时代不是发布会喊出来的

当然，喊"A new era of PC"不代表新时代真的来了。

这里面还有很多坑。

本地模型能力够不够？

Windows 能不能把 local AI runtime 做顺？

开发者愿不愿意适配？

企业 IT 能不能管理这些本地模型？

安全和权限怎么处理？

模型更新怎么做？

本地和云端怎么路由？

NPU、GPU、CPU 谁来调度？

这些问题一个都不简单。

而且 PC 阵营最大的问题一直没变：它不是 Apple。

Apple 可以一家公司决定芯片、系统、开发工具、硬件形态和用户体验。Windows PC 是一个联盟。Microsoft、NVIDIA、Arm、Intel、AMD、Qualcomm、OEM、开发者，每个人都想赢，每个人都只控制一部分。

联盟的好处是开放。

联盟的坏处是没人真正说了算。

所以这场新 PC 叙事能不能成，最后不取决于发布会，也不取决于几条 tweet，而取决于它能不能把复杂性藏起来。

用户不关心你用了什么架构。

企业不关心你有多少 TOPS。

工程师也不想每天研究哪种任务该用哪个模型、哪个 runtime、哪个后端。

大家只关心一件事：

能不能更便宜地把活干完？

如果答案是能，新 PC 就真的成立。

如果答案是不能，那它就只是又一次 AI PC 营销。

结尾：PC 后面那个没说出口的名字

所以，当几家巨头同时喊出"A new era of PC"，我不觉得重点是 PC。

重点是 new era。

旧时代里，PC 是 Windows + x86 的默认组合，是访问 SaaS 和云服务的终端，是被 mobile 抢走光环之后仍然默默工作的办公设备。

新时代里，PC 可能变成另一种东西：

个人 AI 算力节点。

它不一定承担最强推理，但要承担最高频的推理。

它不一定替代云端模型，但要减少对云端 token 的依赖。

它不一定让每个人拥有 AGI，但要让企业别在每一次自动化里都给模型厂商交税。

Wintel 时代结束，不是因为 Intel 不行了。

而是因为下一代 PC 的核心问题，已经不再是“能不能跑 Windows”。

而是：

能不能跑得起智能？

过去四十年，PC 的默认答案是 Wintel。

接下来几年，默认答案会被拆开，重新组合。Windows 还在，Intel 还在，x86 还在，OEM 还在。

但那个所有人默认围着同一套硬件节奏出牌的时代，结束了。

所以"A new era of PC"这句话真正刺耳的地方，不是 new era。

是 PC 后面那个没有说出口的问题：

当 token 贵到所有人都开始重新购买本地算力时，谁还配定义 PC？

When Snowflake's earnings dropped, markets seemed to exhale. Not the "AI will disrupt everything" kind of excitement — something more grounded: turns out SaaS isn't dead, software companies can still grow in the AI era, and investors still care about predictable revenue, margins, and cash flow.

For the past six months, one question has been hanging over SaaS stocks: if AI can do the work directly, does traditional software still have value? More bluntly — if Agents become the new interface, does SaaS degrade from an operating system to a database? Snowflake gave the market a lifeline. Product revenue kept growing fast, full-year guidance went up, and AI demand didn't gut the business model. It actually made markets believe again that data infrastructure is still a core asset in the AI era.

But the real takeaway here isn't "AI is bullish for SaaS again." The real signal is: markets are willing to value SaaS again — but only if you can prove AI isn't a margin-destroying black hole.

SaaS stocks are undergoing a value reset. Not back to the pre-AI era — back to the most basic business logic: the value of a software company isn't determined by how many tokens it consumed. It's determined by how much cash it made.

What SaaS Used to Sell Was Near-Zero Marginal Cost

The most attractive thing about SaaS was never a polished interface or the subscription model itself.

It was this: selling the same software to your 100,000th customer costs almost nothing more than selling it to your first.

That's why traditional SaaS commanded high valuations.

Write the code once, deploy the service once, then sell it to more and more people. There are server costs, support costs, sales costs — but the core product's marginal cost is tiny. The bigger you scale, the better the gross margin, the more comfortable the cash flow.

Capital markets love this model.

Because it prints money.

Early losses can be explained as customer acquisition. Sales expenses can be framed as growth investment. R&D can be called a moat. As long as ARR keeps climbing and NRR doesn't collapse, investors are willing to believe profits will show up at some point in the future.

That logic worked in the past.

Then AI arrived.

AI didn't just add a feature to SaaS. AI stabbed the most attractive part of software companies — low marginal cost — right in the chest.

Tokens Are the New COGS

In the old SaaS model, serving one more customer barely moved your cost structure.

Now every Agent run, every generated report, every code scan, every data analysis request burns tokens.

And tokens aren't magic.

Tokens are bills.

Before, with traditional software: the more users engaged, the healthier the margins. Now, with AI features: the more users engage, the more real the cost becomes.

That's the awkward corner AI SaaS has backed itself into.

Users think they're buying intelligence. Vendors are paying for inference. Users feel "wow, it can actually do things." Finance sees "holy hell, the API bill exploded again this month."

This is why I keep saying: a lot of companies right now aren't doing AI transformation — they're rewriting their own P&L into a model provider's revenue statement.

The CEO thinks they're buying productivity.

The CFO sees a new cost center.

The Story Model Providers Sold Is Becoming Enterprise Invoices

Over the past year, the best storytellers weren't SaaS companies. They were model companies.

Anthropic, OpenAI, Google — each outdoing the last.

They talked about general intelligence, Agent workforces, AI employees, software engineers being replaced, white-collar work being automated. Every phrase was designed to make executives' blood run hot.

But inside actual companies, the story takes a different shape.

Picture this: a CEO comes back from a product launch and decides: "We're going all-in on Agents."

The team starts hooking up APIs, buying seats, integrating internal systems, letting Agents write code, test code, write docs, run tests, do analysis. A month later, the invoice arrives.

Business outcomes? About the same.

Productivity? About the same.

Processes? About the same.

The only thing that grew for certain: token consumption.

Then comes the awkward moment.

Say AI isn't working? The CEO wonders if you don't know how to use it. Say it's working? Finance asks where the ROI is. Say wait longer? The invoice doesn't wait.

Model companies love this world.

Because whether or not you improve efficiency, the moment you start experimenting, they're already billing you.

Enterprises pay for certainty. Model companies sell possibility.

In the short term, this looks like an innovation budget. In the long term, it's vendor margin transfer.

What SaaS companies fear most isn't that AI is too weak. It's that AI is strong enough but not cheap enough.

Markets Have Stopped Listening to Stories

In 2021, fast growth was all a SaaS company needed. Losses were fine.

The logic was simple: grab land now, figure out profits later.

By 2026, that pitch doesn't land anymore.

Investors are back to scrutinizing Rule of 40, free cash flow, gross margin. Not because they suddenly got conservative — but because AI made "profits will come eventually" sound a lot less inevitable.

Before, losses meant you were expanding.

Now, losses might mean every user click is costing you money.

Those are two very different kinds of losses.

The first is investment.

The second is COGS.

Markets will value investment. They won't indefinitely absorb runaway COGS.

That's why SaaS pricing logic is shifting: it used to be about growth; now it's about how much is left after the growth. It used to be about the AI roadmap; now it's about whether the AI roadmap crushes the margin.

AI can't just add revenue. It has to prove it won't eat the software economics model.

The Market Will Split SaaS Into Two Groups

Going forward, the market will split SaaS companies into two groups.

The first group treats AI as a new growth story.

They'll spend earnings calls raving about Agents, copilots, automation, AI-native workflows. Every sentence sounds right — until you ask the follow-up: "how much has this actually improved retention, ARPU, and margin?" The room goes quiet.

The second group treats AI as a cost structure problem.

They ask first: which requests actually need a frontier model? Which can use a smaller model? What can be cached? What doesn't need an LLM at all? What should be handled by rules, search indexes, static analysis, and traditional ML first?

The first group is selling stories.

The second group is running the math.

The valuation gap between these two groups will probably start opening up right here.

Because capital markets can absorb AI investment. What they won't indefinitely absorb is "I can't explain why it costs this much, but everyone's using it."

Especially as users start budget controls, as CFOs start demanding unit economics on every AI feature, as procurement starts comparing token prices across models — the era of burning tokens wildly will start its countdown.

AI is allowed to cost money.

But you need to burn it into something.

Into revenue. Into retention. Into efficiency. Into margins you can explain.

If you can't — that's not strategic investment. That's a financial leak.

Real AI SaaS Doesn't Treat LLMs Like a Database

A lot of companies right now are using AI with a blunt instrument.

Don't know how to handle it? Throw it at the LLM.

Code understanding? LLM.

Log analysis? LLM.

Test generation? LLM.

User questions? LLM.

It looks smart on the surface. In practice, it's replacing databases, search engines, rule systems, compilers, static analyzers, and workflow engines with one giant token incinerator.

That's not AI-native.

That's lazy.

Real AI-native SaaS redesigns system boundaries.

If it can be structured, structure it first. If it can be indexed, index it first. If a rule can solve it, don't use an LLM. If a small model can handle it, don't use a frontier model. If it can be computed offline, don't burn online inference. If it can be cached, don't re-run the inference.

LLMs should be the cognitive layer. Not the trash can.

Dumping everything into an LLM is like routing all computation through database stored procedures. Fast at first. Eventually a swamp.

AI's value isn't in letting software companies skip designing systems. It's in forcing software companies to redesign them.

Value Reset Isn't the End of AI. It's AI Growing Up.

When people hear "the era of burning tokens is ending," they assume it's a knock on AI.

It isn't.

It's the opposite. This is the beginning of AI graduating from toy to industrial tool.

Toys get judged on results.

Industrial tools get judged on costs.

With a toy you say "look how smart it is."

With an industrial tool you ask "what does each task cost?"

That's why the SaaS value reset is a good thing. It pushes out companies that can only tell AI stories, and keeps the ones that actually understand software economics.

For the past two years, everyone got too easily fooled by demos.

A demo can make you feel like the future has arrived. But demos don't run P&L. Demos don't have SLAs. Demos don't face the endless edge cases of real users. Demos don't receive a six-figure invoice at the end of the month.

The real world doesn't reward demos.

The real world rewards unit economics.

Who Pays for the Tokens

Every SaaS company is about to face the same problem: how do you pass through the AI cost?

Charge by seat — users go wild, vendors hurt.

Charge by usage — users start to hurt.

Bundle it into the enterprise plan — easy to sell, ugly on the financials.

Sell it as a separate AI add-on — customers ask: "is this AI actually worth it?"

That's the real inflection point.

When AI features shift from "a nice surprise included for users" to "a line item that needs to justify its own ROI," the market won't price SaaS the way it did in 2021.

The era of burning tokens wildly won't end with a crash.

It'll end the boring way: budget approvals slow down, procurement starts negotiating, CFOs want reports, boards ask about ROI, investors stare at gross margins.

No dramatic pop.

Just the quiet sound of invoices landing.

So the next round of competition in SaaS isn't about who shouts "AI-native" louder. It's about who can turn AI into a normal business.

Models can keep improving. Token prices can keep falling. Agents can keep getting stronger.

But the market has already started asking the most basic question:

Every token you burned — whose cash flow did it eventually become?

Snowflake 财报一出，市场像突然松了一口气。不是那种“AI 要颠覆一切”的亢奋，而是另一种更现实的情绪：原来 SaaS 还没死，原来软件公司还能在 AI 时代继续增长，原来投资人还愿意为确定的收入、利润率和现金流买单。

过去半年，SaaS 股一直被一个问题压着：如果 AI 能直接完成工作，传统软件还有没有价值？更狠一点说，如果 Agent 变成新的入口，SaaS 会不会从操作系统退化成数据库？Snowflake 这次给市场续了一口命。Product revenue 继续高增长，全年指引上调，AI 需求没有把它的商业模型拖垮，反而让市场重新相信 data infrastructure 仍然是 AI 时代的核心资产。

但我觉得，这轮反弹最值得看的不是“AI 又利好 SaaS”这种表层结论。真正的信号是：市场重新愿意给 SaaS 估值，但前提是你得证明 AI 不是一个烧穿 margin 的黑洞。

一句话，SaaS 股正在价值回归。不是回到没有 AI 的时代，而是回到最朴素的商业常识：软件公司的价值，最终不是由调用了多少 token 决定的，而是由赚了多少现金决定的。

SaaS 过去卖的是边际成本接近零

SaaS 最迷人的地方，从来不是界面漂亮，也不是 subscription model 本身。

真正迷人的地方是：同一套软件卖给第 1 个客户和第 10 万个客户，成本几乎不怎么变。

这就是为什么传统 SaaS 可以拿到很高的估值。

写一次代码，部署一次服务，然后把它卖给越来越多的人。服务器成本有，客服成本有，销售成本也有，但核心产品的边际成本很低。规模越大，gross margin 越好看，cash flow 越舒服。

资本市场喜欢这种模型。

因为它像一台印钞机。

前期亏钱可以解释为获客，销售费用可以解释为增长投资，研发费用可以解释为护城河。只要 ARR 往上走，NRR 不崩，投资人愿意相信利润会在未来某个时间点自然出现。

这套逻辑在过去是 work 的。

但 AI 进来之后，事情变了。

AI 不是简单地给 SaaS 加了一个 feature。AI 把软件公司最性感的地方——低边际成本——捅了一刀。

Token 是新的 COGS

过去 SaaS 公司每多服务一个客户，成本增加很有限。

现在每多跑一次 Agent，每多生成一份报告，每多扫一遍代码，每多帮用户分析一批数据，背后都在烧 token。

而 token 不是玄学。

token 是账单。

以前你卖软件，用户越用越爽，你的利润率越稳定。现在你卖 AI feature，用户越用越爽，你的成本越真实。

这就是 AI SaaS 最尴尬的地方。

用户觉得自己买的是 intelligence，供应商付出去的是 inference。用户感受到的是“哇，它会干活”，财务看到的是“卧擦嘞，这个月 API bill 又炸了”。

所以我一直觉得，很多公司现在不是在做 AI transformation，而是在把自己的 P&L 改造成模型厂商的收入表。

老板以为买的是生产力。

CFO 看到的是一条新的 cost center。

A 社画的饼，正在变成企业的账单

过去一年，最会讲故事的不是 SaaS 公司，而是模型公司。

A 社、OpenAI、Google，一个比一个会画。

他们讲的是通用智能、Agent workforce、AI employee、软件工程师被替代、白领劳动被自动化。每一个词都能让老板热血上头。

但落到企业里，故事会变成另一种形状。

想象一下这个场景：老板听完发布会，回来拍板，“我们也要 all in Agent。”

于是公司开始接 API，买 seat，接入内部系统，让 Agent 写代码、测代码、写文档、跑测试、做分析。一个月后，账单来了。

业务没怎么变。

人效没怎么变。

流程没怎么变。

唯一确定增长的是 token consumption。

这时候尴尬的地方来了。

你说 AI 不行，老板会怀疑是不是你不会用。你说 AI 行，财务会问 ROI 在哪里。你说再等等，账单不会等。

模型公司当然喜欢这个世界。

因为不管你有没有提升效率，只要你开始试错，它们就已经在收钱。

企业花钱买确定性，模型公司卖的是可能性。

这笔账，短期看像 innovation budget，长期看就是 vendor margin transfer。

SaaS 公司最怕的不是 AI 不够强，而是 AI 足够强但不够便宜。

市场已经不想听故事了

2021 年，SaaS 公司只要增长够快，亏损不是问题。

那时候的市场逻辑很简单：先抢地盘，利润以后再说。

到了 2026 年，这句话基本说不动了。

投资人开始重新看 Rule of 40，重新看 free cash flow，重新看 gross margin。不是因为他们突然变保守，而是因为 AI 让“利润以后自然会来”这句话不再自然。

过去亏损是因为你在扩张。

现在亏损可能是因为你每一次用户点击都在烧钱。

这两种亏损不是一回事。

前者叫 investment。

后者叫 COGS。

市场愿意给 investment 估值，但不愿意给失控的 COGS 估值。

这就是为什么今天 SaaS 股的定价逻辑正在变：以前看增长，现在看增长之后还剩多少利润；以前看 AI roadmap，现在看 AI roadmap 会不会压垮 margin。

AI 不能只增加 revenue，它还必须证明自己不会吃掉 software 的经济模型。

市场会把 SaaS 公司分成两类

接下来市场会把 SaaS 公司分成两类。

第一类公司，把 AI 当成新的增长故事。

它们会在财报电话会上疯狂讲 Agent，讲 copilot，讲 automation，讲 AI-native workflow。听起来每一句都对，但只要你追问一句“这东西到底提升了多少 retention、ARPU 和 margin”，空气就会突然安静。

第二类公司，把 AI 当成成本结构问题。

它们会先问：哪些请求必须用 frontier model？哪些可以用小模型？哪些可以 cache？哪些根本不需要 LLM？哪些任务应该先用规则、索引、静态分析和传统 ML 解决？

第一类公司在卖故事。

第二类公司在算账。

未来 SaaS 的估值差距，很可能就从这里拉开。

因为资本市场可以接受 AI 投入，但不会长期接受“我也不知道为什么这么贵，但大家都在用”。

尤其是当用户开始 budget control，当 CFO 开始问每个 AI feature 的 unit economics，当采购开始比较不同模型的 token price，疯狂烧 token 的日子就进入倒计时了。

AI 不是不能烧钱。

但你得烧出东西。

烧出收入，烧出留存，烧出效率，烧出可以解释的 margin。

烧不出来，那就不是战略投入，是财务漏水。

真正的 AI SaaS，不会把 LLM 当数据库用

很多公司现在用 AI 的方式非常粗暴。

遇事不决，塞给 LLM。

代码理解，塞给 LLM。

日志分析，塞给 LLM。

测试生成，塞给 LLM。

用户问题，塞给 LLM。

乍一看很智能，实际上像是把数据库、搜索引擎、规则系统、编译器、静态分析、workflow engine 全部换成一个巨大的 token 焚化炉。

这不是 AI-native。

这是懒。

真正的 AI-native SaaS，一定会重新设计系统边界。

能结构化的先结构化，能索引的先索引，能规则解决的不要上 LLM，能小模型解决的不要上 frontier model，能离线算的不要在线烧，能 cache 的不要重复推理。

LLM 应该是认知层，不是垃圾桶。

把所有问题都丢给 LLM，就像把所有计算都丢给数据库存储过程。短期很快，长期一定变成屎山。

AI 的价值不在于让软件公司不用设计系统，而在于逼软件公司重新设计系统。

价值回归不是 AI 结束，而是 AI 成年

很多人一听“烧 token 的日子要结束了”，会以为这是唱衰 AI。

不是。

恰恰相反，这是 AI 从玩具走向工业品的开始。

玩具阶段看效果。

工业阶段看成本。

玩具阶段可以说“你看它多聪明”。

工业阶段必须问“每完成一次任务多少钱”。

这就是为什么我说 SaaS 股价值回归是一件好事。它会把那些只会讲 AI 故事的公司挤出去，把真正懂软件经济模型的公司留下来。

过去两年，大家太容易被 demo 骗了。

一个 demo 能让人觉得未来已经来了。但 demo 不跑 P&L，demo 不承担 SLA，demo 不面对真实用户的无穷边界条件，demo 也不会在月底收到一张六位数账单。

真实世界不奖励 demo。

真实世界奖励 unit economics。

谁为 token 买单

SaaS 公司接下来都会遇到同一个问题：AI 成本到底怎么转嫁？

按 seat 收费，用户疯狂用，供应商肉疼。

按 usage 收费，用户开始肉疼。

打包进 enterprise plan，销售好讲，财务难看。

单独卖 AI add-on，客户又会问：“你这个 AI 到底值不值这笔钱？”

这才是真正的拐点。

当 AI feature 从“送给用户的惊喜”变成“一项需要单独证明 ROI 的预算”，市场就不会再用 2021 年的方式给 SaaS 定价。

疯狂烧 token 的时代不会突然结束。

它会以一种很无聊的方式结束：预算审批变慢，采购开始砍价，CFO 要求报表，董事会追问 ROI，投资人盯着 gross margin。

没有泡沫破裂的巨响。

只有账单落地的声音。

所以 SaaS 的下一轮竞争，不是谁更会喊 AI-native，而是谁能把 AI 做成一门正常生意。

模型可以继续进步，token 可以继续降价，Agent 可以继续变强。

但市场已经开始问那个最朴素的问题：

你烧掉的每一个 token，最后到底变成了谁的现金流？

烧了上百万美元，团队终于得出一个结论：AI 在自动化测试这件事上不行，最后还得靠人，靠自动化脚本。什么？！裤子都脱了，你告诉我这个？这事最魔幻的地方，不是 AI 没有替代测试，而是企业花了成百上千万美元，才重新发现了一件十年前就知道的事：软件质量靠工程纪律，靠稳定接口，靠确定性反馈，靠一遍遍枯燥但可靠的自动化脚本。A 社当然不会这么讲——它会讲 Agent，讲 reasoning，讲"未来每个公司都会拥有一支数字员工队伍"，翻译成人话就是：你先买单，成不成算未来的。

A 社最厉害的地方，不是模型，是叙事

先说清楚，A 社的模型不弱。

它能写代码，能读文档，能分析日志，能生成测试用例，能在某些受控场景下把任务跑通。很多能力是真的，不是假的。

问题不在能力，问题在包装。

A 社最厉害的地方，不是把模型做得多强，而是把"模型能做一次"包装成"企业可以长期依赖"。

这中间差了十万八千里。

Demo 里，Agent 成功一次就够了。生产里，系统要稳定一万次。Demo 里，失败了可以重录。生产里，失败了要有人背锅。Demo 里，环境是干净的，路径是设计好的，数据是准备好的，用户是配合的。生产里，环境是脏的，路径是混乱的，数据是历史遗留的，用户是不会按剧本走的。

A 社当然知道这些区别。但它不会把这些区别放在 PPT 首页。它会把最顺滑的路径剪出来，把最聪明的瞬间放大，把最像未来的片段讲成必然趋势。至于中间那些权限、上下文、误报、复核、成本、集成、治理、责任边界，统统变成一句轻飘飘的：

"这些都可以随着模型能力提升解决。"

妙啊。所有当下解决不了的问题，都被打包寄给未来。

A 社卖的不是确定性，而是把不确定性包装成确定性的能力。这才是企业最容易中招的地方。不是因为老板傻，不是因为工程师不懂，而是因为整个故事太完整了。它刚好击中企业最想听的东西：少招人、少写脚本、少管流程、少做苦活，让 Agent 自动完成一切。

谁不想信？

那个时候，谁都没法说自己一定对

一个月前，工程师说"AI 不可靠"。

这句话本身没问题。但放到当时的语境里，它听起来就很复杂。

你怎么知道这是技术事实，还是团队在抗拒变化？你怎么知道是 AI 真不行，还是这帮人不会用？你怎么知道是方向错了，还是执行不到位？你怎么知道是模型能力不够，还是 prompt 没写好、上下文没给够、工具链没接顺？

这不是老板蠢。这是所有新技术落地时都会出现的灰区。尤其在 AI 这件事上，灰区被 A 社们放大了十倍。外面所有人都在讲 Agent，所有 demo 都在展示"端到端自动完成任务"，所有投资人、媒体、vendor 都在说企业软件要被重写。你坐在那个位置，很难不问一句：

别人都在搞，我们不搞，是不是要落后？

所以当工程师说"AI 不可靠"的时候，这句话在会议室里会自动变味。它原本是一句技术判断，听起来却像一句防守姿态。像是不想改流程，像是不想碰新东西，像是在保护自己的舒适区，像是在给执行失败提前找借口。

AI 狂热期里，最难的不是判断模型边界，而是判断谁在说真话。

工程师可能是对的。老板的怀疑也不是完全没道理。过去二十年，太多"技术上不可能"最后都被证明只是"当时那批人不会做"。云计算刚出来，有人说不安全；移动互联网刚起来，有人说只是玩具；低代码、Serverless、DevOps、Kubernetes，每一轮新东西出来，都会有人说"不靠谱"。老板听多了，自然会形成一个本能反应：

你说不行，到底是它不行，还是你不行？

这句话不好听，但它很真实。

问题在于，AI 自动化测试最后证明的是另一件事：这一次，说"不可靠"的人不是保守，他只是把测试系统最基本的约束说了出来。测试不是 demo，测试不是魔法，测试不是让一个聪明东西去自由发挥，测试是把"什么叫对"写成确定性的契约。

这件事，一个月前讲，像借口。一个月后讲，叫复盘。中间差的不是认知，是上百万美元。

AI 最擅长的地方，恰好不是测试最需要的地方

LLM 很强。它能读懂一段需求，猜出用户想干什么；它能根据代码补测试；它能把错误日志翻译成人话；它甚至能在某些简单场景里，像一个 junior QA 一样点点页面，找出明显 bug。这些能力都是真的。

这也是 A 社叙事最聪明的地方。它不需要完全撒谎，它只需要拿一个真实能力，往前多推半步。模型能生成测试用例，于是它暗示未来可以自动完成测试。模型能操作浏览器，于是它暗示未来可以替代人工回归。模型能理解页面，于是它暗示未来可以判断业务正确性。模型能跑通一个 demo，于是它暗示企业可以把质量体系交给 Agent。

每一步看起来都不离谱。但连起来就很离谱。

因为自动化测试要的不是"有时候看起来挺聪明"。自动化测试要的是重复、稳定、可解释、可回放。今天跑 100 次，99 次结果一致；失败了能定位到哪一层；误报率低到团队愿意相信它；成本低到能放进 CI 里天天跑。

AI 恰好反过来。它每次都像在重新理解世界。上下文换一点，判断变一点；页面抖一下，结果变一点；需求没写清楚，它开始脑补；按钮文案改一下，它像新入职的同事一样重新适应。

测试系统最怕的，不是笨，而是不稳定。

一个笨脚本，只要稳定，就能创造价值。一个聪明 Agent，只要不稳定，就会制造噪音。工程团队不怕工具能力有限，怕的是它每次失败的方式都不一样。

脚本失败，通常会留下明确痕迹：selector 变了，接口挂了，数据不对，环境异常。修一次，下次就少一个坑。Agent 失败不一样。它可能是理解错了页面，可能是漏了一个业务规则，可能是上下文塞太多注意力飘了，可能是模型这次抽风，可能是 prompt 里某句话权重不对，也可能什么都没错，它只是这次做了一个和上次不一样的判断。

这类失败最要命。它不是 bug，它像情绪。工程系统能处理 bug，很难处理情绪。因为 bug 可以复现，情绪只能安抚。

Demo 里的 Agent 是员工，生产里的 Agent 是实习生

AI 自动化测试的 demo 通常很迷人。你给它一个登录页，它能自己输入账号密码；你让它检查购物车，它能一路点到 checkout；你给它一段需求，它能生成测试步骤。配上一句"未来 QA 只需要 review AI 生成的结果"，听起来很合理——这不就是人效提升吗？

但真实系统不是 demo。

真实系统有灰度环境，有脏数据，有权限隔离，有 A/B 实验，有弹窗，有风控，有 flaky network，有历史债，有埋在角落里的业务规则。更要命的是，真实系统每天都在变。

Agent 进来以后，第一件事不是测试，而是迷路。它不知道哪个账号有权限；不知道这个按钮为什么在某些用户下不展示；不知道错误 toast 是预期还是 bug；不知道页面慢是环境问题还是性能问题；不知道某个失败 case 到底该重跑、跳过、上报，还是找人。

于是团队开始给它补上下文。补账号体系，补环境说明，补页面结构，补业务规则，补异常处理，补 prompt，补 eval，补 tracing，补人工 review。补着补着，大家发现不对劲：

这玩意儿不是替人干活，这是多了一个永远需要解释世界、永远需要复核结果、永远不承担责任的实习生。

Agent 最大的问题不是不会做事，而是它不知道什么时候自己做错了。测试偏偏不能接受这个。因为测试不是写作文——写错了可以改。测试错了，会让团队误判质量。一个误报会浪费工程师时间，一个漏报会把 bug 放进生产，一个不稳定的测试系统，最后会被所有人无视。

更糟的是，团队会为了让 Agent 看起来能工作，反过来改造自己的工作流。本来一个 Playwright 脚本能解决的问题，现在要写 prompt；本来一个 mock server 能解决的问题，现在要给 Agent 解释数据状态；本来一个 assert 能解决的问题，现在要让模型判断"页面看起来是否正确"。

你以为你在自动化测试，其实你在自动化地伺候 AI。

A 社会把这叫"human-in-the-loop"。这词听起来很高级。但很多时候，它的真实意思是：AI 干不完的，你来兜底；AI 判断不准的，你来复核；AI 迷路的，你来导航；AI 搞砸的，你来解释。最后账单还是它的，责任还是你的。

企业真正买到的，是一张更贵的账单

过去买 SaaS，至少还有个确定性。买 Jira，流程被固化；买 GitHub，代码协作被固化；买 CI，构建和发布被固化。它们不一定让组织变聪明，但会把某些动作标准化。

AI 不一样。很多 AI 项目卖的不是确定性，而是可能性。

"它可能帮你省掉 50% QA。""它可能自动发现线上问题。""它可能让研发效率翻倍。"

注意，关键词是"可能"。这也是 A 社叙事最鸡贼的地方。说得太满，容易被打脸；说得太虚，没人买单。所以最好的话术，就是把所有结果都停在"可能"上——可能替代，可能提升，可能重构，可能颠覆。然后让企业用确定的钱，为不确定的未来买单。

于是 Token 费、平台费、集成费、咨询费、PoC 费、内部人力，全都算进去，账单飞起来。Dashboard 上，调用量很漂亮，Token burn rate 很性感，汇报里也终于有了 AI transformation。

可到了最后，真正能回答 ROI 的问题只有三个：这件事原来谁做？现在这个人少做了多少？省下来的时间有没有变成收入、利润，或者更强的组织能力？

大部分 AI 自动化测试项目死在第二个问题。人没少，脚本没少，review 没少，只是中间多了一个模型调用环节。

Token 不是生产力，Token 只是成本单位。把测试流程里每一步都接上 LLM，并不等于自动化。很多时候，它只是把原来便宜、确定、可控的工程问题，改造成了昂贵、不确定、难 debug 的 AI 问题。

以前脚本失败，工程师看日志。现在 Agent 失败，工程师先猜它为什么这么想。这叫把确定性债务换成认知债务。技术债至少能定位，认知债连边界都没有。所有问题最后都会变成一句话：再试试，再调调，再加点上下文，再换个模型，再买点额度。听起来像迭代，实际上像赌博。只不过赌场换了个名字，叫 AI transformation。

自动化测试的本质，从来不是"像人一样点页面"

很多人对自动化测试有个误解：以为它的目标是模拟人。所以 Agent 很有诱惑力——人会看页面，Agent 也会看；人会点按钮，Agent 也会点；人会判断结果对不对，Agent 好像也会。

A 社最喜欢的就是这个错觉。因为只要你相信测试是在"像人一样操作系统"，你就会自然相信一个更聪明的 Agent 可以替代人。

但测试的本质不是模拟人。测试的本质是把质量判断变成机器可执行的契约。

一个好的测试，不是"像人一样聪明"，而是把"什么叫对"写死。接口返回什么，状态怎么变化，数据库应该有什么，事件有没有发出，权限边界怎么生效，性能阈值是多少。这些东西越明确，测试越有价值。

AI 恰恰喜欢模糊。它擅长在模糊里给出一个看似合理的答案。但测试要做的是消灭模糊。这就是根本冲突。

你可以让 AI 辅助写测试，帮你生成 skeleton，帮你补边界 case，帮你解释失败原因，帮你从日志里聚类问题。这些都很有价值。但你不能指望 AI 替你决定系统是不是对的。因为"对"不是模型涌现出来的，"对"来自业务规则，来自接口契约，来自工程师和 QA 对系统的共同理解。

测试不是让机器自由发挥，测试是不给机器自由发挥。越关键的系统，越不能靠感觉。支付不能靠感觉，权限不能靠感觉，账务不能靠感觉，发布不能靠感觉。

这也是为什么很多 AI 测试项目最后都会回到 Playwright、Cypress、JUnit、pytest、mock、fixture、CI、coverage、contract test 这些老东西上。不是因为这些东西性感，是因为它们可靠。工程世界里，可靠经常比聪明值钱。

最贵的不是账单，是优先级被带偏

花上百万美元验证 AI 不适合接管自动化测试，账单当然肉疼。但更贵的是优先级被带偏。

这件事不能简单归因到老板不懂技术，也不能简单归因到团队执行不行。更准确地说，是 A 社们在过去两年制造了一种错觉：只要模型继续变强，很多基础工程就可以跳过去。

于是该补测试基础设施的时候，大家会先想能不能买 Agent；该清理测试数据的时候，大家会先想能不能调 prompt；该建设稳定环境的时候，大家会先想能不能用多模态理解页面；该定义质量标准的时候，大家会先想能不能让模型自己判断。

这就像地基没打好，先研究智能装修。不是装修没价值，是房子会塌。

AI 项目失败以后，组织也很容易把原因归到"模型还不够强"。这句话最省事，因为它把问题推给未来。今年模型不够强，明年再试；明年上下文不够长，后年再试；后年 Agent 不够稳定，再等等。

这套逻辑对谁最有利？当然是 A 社。因为每一次失败，都不会证明它的叙事有问题，只会证明你还应该买下一代模型。当前模型不够强？升级。上下文不够长？升级。工具调用不够稳？升级。成本太高？等下一代。效果不好？再做一轮 PoC。

你看，所有路都通向账单。

AI 能放大工程能力，但不能替代工程能力。 一个没有稳定测试体系的团队，上 AI 只会更乱。一个没有清晰质量标准的组织，上 Agent 只会更贵。AI 不会自动补齐组织缺的那一课，它只会把缺口照得更亮。

真正有用的 AI 测试，不长得像 demo

不是说 AI 在测试里没用。恰恰相反，AI 很有用。但它最有用的地方，不是替你端到端接管测试，而是嵌进已有工程体系里，做那些低风险、高重复、可验证的事。

比如从代码 diff 里推荐需要补的测试；比如根据接口 schema 生成边界 case；比如分析 flaky test 的失败模式；比如把线上错误日志聚类，归因到可能的模块；比如帮 QA 把自然语言场景转成 Playwright skeleton；比如在 PR 里提醒：你改了权限判断，但没有补对应测试。

这些场景有个共同点：AI 不负责最终判断。它负责提案，人负责确认；它负责生成，脚本负责验证；它负责解释，工程系统负责裁决。

AI 最适合做副驾驶，不适合做安全带。 安全带必须确定，副驾驶可以聪明。这两个位置不能搞反。

如果一个 AI 测试工具的价值主张是"让你不用写测试"，那大概率是坑。如果它的价值主张是"让你更快写出可靠测试"，那才可能有戏。前者在卖幻想，后者在卖工具。

A 社当然更喜欢卖前者。因为幻想的 TAM 最大。卖"帮你更快写 Playwright 脚本"，听起来只是一个工具；卖"未来测试团队会被 Agent 重写"，听起来才像下一代平台。资本市场爱听后者，老板汇报爱听后者，媒体标题爱听后者。只是最后落到团队手里，前者能省时间，后者会烧预算。

这场实验真正证明了什么

从结果看，上百万美元买来的结论很简单：AI 不能独立接管自动化测试。

但这不是全部。它还证明了几件更难听的事。

它证明了很多企业没有能力区分 demo 和生产力。它证明了很多人分不清"模型能做一次"和"系统能长期稳定运行"。它证明了很多 AI 项目的 ROI，从第一天开始就没人敢认真算。它也证明了，在叙事足够热的时候，工程常识会被暂时打成保守。

一个月前，那个说"AI 不可靠"的人，可能还在被质疑。一个月后，账单证明他是对的。这件事听起来爽吗？不爽。因为组织已经付过学费了。

真正成熟的组织，不应该靠上百万美元的账单来证明常识。它应该允许团队在项目开始前，就把难听的话说完。它应该允许有人问：这个 Agent 失败了谁负责？这个结果怎么验证？这个流程省掉了哪个人？这个系统如何进入 CI？这个方案跟现有脚本相比，成本低在哪里？

如果这些问题问不清楚，项目就不该立项。不是因为反 AI，是因为尊重钱。

A 社不会替你问这些问题，它的销售也不会。它们最希望你问的是："什么时候接入？""要买多少额度？""能不能支持我们的场景？"但企业真正该问的是："如果这个东西失败了，我们能不能解释为什么？"很多 AI 项目回答不了这个问题。回答不了，就不是工程系统，只是一个昂贵的愿望机。

A 社画的饼，正在变成企业的账单

过去两年，AI 公司讲了一个很漂亮的故事：Agent 会接管白领工作，软件会自己写自己，测试会自己跑自己。企业只要接入模型，就能获得一支不会睡觉、无限扩容、随叫随到的数字员工队伍。

这个故事太诱人了，诱人到很多人忘了问一句：它到底替我们省了什么？

如果一个 AI 项目花了上百万美元，最后只是证明"测试还得靠人、靠自动化脚本"，那它当然也有价值——它完成了一次昂贵的组织教育。它告诉老板，AI 不是魔法；告诉团队，工程纪律不会过时；告诉财务，Token burn 不等于 transformation；告诉所有人，demo 里的未来不能直接折现成生产力。

只是这个学费太贵了。

真正的问题不是 A 社有没有能力。A 社当然有能力。问题是它把能力边界讲得太轻，把落地成本讲得太少，把未来收益讲得太满。它把 demo 里的顺滑，包装成生产里的必然；把模型偶尔展现出的聪明，包装成组织可以采购的生产力；把企业对降本增效的焦虑，包装成一张张越来越厚的 Token 账单。

销售当然会画饼，创业公司当然会讲未来，模型公司当然希望你相信"下一代会解决一切"。问题是企业为什么这么容易相信？因为"AI 替代人"这个故事，比"回去把自动化测试体系补好"性感太多。前者像未来，后者像苦活。

可软件工程大部分有价值的东西，本来就是苦活。写脚本是苦活，补 case 是苦活，清数据是苦活，稳定 CI 是苦活，定义质量标准是苦活。这些东西不会因为 Agent 出现就消失，它们只会换一种方式回来找你要账。

有些账，可以付给工程师；有些账，可以付给 QA；有些账，可以付给基础设施；也可以付给模型公司。区别在于，前三种账付完以后，组织会长出能力。最后一种账付完以后，通常只会长出下一张账单。

下一次有人拿着 AI 自动化测试 demo 走进会议室，先问一句：

这个东西到底是在替我们提高质量，还是只是在替 A 社提高收入？

After burning through millions of dollars, the team's conclusion was this: AI can't handle automated testing. You still need people and scripts. We went through all that for this? The surreal part isn't that AI failed to replace testing — it's that enterprises spent millions to rediscover something engineers knew ten years ago: software quality comes from engineering discipline, stable interfaces, deterministic feedback, and boring-but-reliable scripts run over and over. Anthropic, of course, would never frame it that way. It talks about Agents, reasoning, end-to-end task completion, "every company will have a workforce of digital employees" — translated into plain language: you pay first, whether it works is a problem for the future.

Anthropic's Real Advantage Isn't the Model — It's the Narrative

To be clear: Anthropic's models aren't weak.

They can write code, read docs, analyze logs, generate test cases, and complete tasks in controlled environments. Many of the capabilities are real, not fabricated.

The problem isn't capability. The problem is packaging.

Anthropic's greatest strength isn't how powerful it has made the model — it's how well it has packaged "the model can do this once" into "enterprises can depend on this long-term."

The gap between those two things is enormous.

In a demo, the Agent succeeds once — that's enough. In production, the system needs to succeed ten thousand times. In a demo, failure means a retake. In production, failure means someone takes the blame. In a demo, the environment is clean, the path is scripted, the data is prepped, the user cooperates. In production, the environment is dirty, the path is chaotic, the data is legacy, and users don't follow scripts.

Anthropic knows all of this. But they don't put it on the first slide. They clip the smoothest paths, magnify the smartest moments, and present the most future-looking fragments as inevitable trends. As for the permissions, context limits, false positives, manual review, integration costs, governance overhead, and accountability gaps in between — those all become a breezy:

"These will be solved as model capabilities improve."

Brilliant. Every problem that can't be solved today gets packaged and mailed to the future.

Anthropic doesn't sell certainty. It sells the ability to package uncertainty as certainty. That's where enterprises get caught. Not because leadership is foolish. Not because engineers don't understand. But because the story is too complete. It hits exactly what enterprises want to hear: fewer hires, fewer scripts, less process overhead, less grinding work — let Agents handle everything automatically.

Who wouldn't want to believe it?

In the AI Hype Cycle, Technical Judgment Gets Mistaken for Excuses

A month ago, the engineer said "AI is unreliable."

Nothing wrong with that statement. But in context, it got complicated fast.

How do you know it's a technical fact and not the team resisting change? How do you know AI genuinely can't do it versus your people not knowing how to use it? How do you know the direction is wrong versus execution being the problem? How do you know the model lacks capability versus the prompt being badly written, context insufficient, toolchain improperly connected?

This isn't the boss being foolish. This gray zone appears whenever new technology gets deployed. With AI, the gray zone has been amplified tenfold by players like Anthropic. Every vendor pitches Agents, every demo shows "end-to-end task completion," every investor and analyst says enterprise software is about to be rewritten. Sitting in that seat, you can't help asking:

Everyone else is doing it. If we don't, will we fall behind?

So when an engineer says "AI is unreliable," the statement transforms in the conference room. It started as a technical judgment. It lands as a defensive posture — resisting change, avoiding new tools, protecting a comfort zone, pre-loading excuses for execution failure.

In the AI hype cycle, the hardest thing isn't assessing model capabilities — it's figuring out who's telling the truth.

The engineer might be right. The boss's skepticism might not be entirely wrong either. Over the past twenty years, too many "technically impossible" claims turned out to mean "that particular team didn't know how." Cloud computing was "insecure." Mobile was "just a toy." Every wave — low-code, Serverless, DevOps, Kubernetes — brought people saying it was unreliable. After hearing this enough times, leaders develop a reflex:

When you say it can't be done, is it that it can't be done, or that you can't do it?

Uncomfortable. But real.

The thing is, AI automated testing eventually proved something different: this time, the person who said "unreliable" wasn't being conservative. They were just stating the most basic constraints of any test system. Testing isn't a demo. Testing isn't magic. Testing isn't giving something smart the freedom to improvise. Testing is encoding "what correct means" as a deterministic contract.

Said a month ago: sounds like an excuse. Said a month later: that's a postmortem. What lies between isn't a gap in understanding — it's millions of dollars.

AI's Strengths Are Exactly Testing's Weaknesses

LLMs are genuinely capable. They can parse requirements and infer user intent. They can generate tests from code. They can translate error logs into plain language. In simple scenarios, they can act like a junior QA — clicking around, catching obvious bugs. These capabilities are real.

This is also the cleverest part of Anthropic's narrative. It doesn't need to lie. It just needs to take a real capability and push it half a step further. The model can generate test cases — so it implies future tests can be completed automatically. The model can operate a browser — so it implies future regression testing can replace humans. The model can understand a page — so it implies future systems can judge business correctness. The model can complete a demo — so it implies enterprises can hand their entire quality system to an Agent.

Each step seems plausible individually. Connected together, it falls apart.

Because automated testing doesn't need "occasionally looks smart." It needs repeatability, stability, explainability, and replay. Run it 100 times today, get 99 consistent results. When it fails, localize the failure to a specific layer. False positive rate low enough that teams trust it. Cost low enough to run in CI every day.

AI works in the opposite direction. Every run feels like it's reacquainting itself with the world. Change the context slightly — the judgment shifts. The page flickers — the result changes. The requirement wasn't fully specified — it starts improvising. The button label changes — it adapts like a new hire.

The thing test systems fear most isn't stupidity — it's instability.

A dumb script that's stable creates value. A smart Agent that's unstable creates noise. Engineering teams don't fear limited tooling. What they fear is when failures look different every time.

When a script fails, it leaves a clear trace: the selector changed, the API went down, data was wrong, environment was broken. Fix it once — one fewer pit next time. When an Agent fails, it's different. Maybe it misread the page. Maybe it missed a business rule. Maybe the context window overflowed. Maybe the model had a bad moment. Maybe one line of the prompt had the wrong weight. Maybe everything was fine and it just made a different call this time.

That kind of failure is the most dangerous. It's not a bug — it behaves like a mood. Engineering systems can handle bugs. They can't handle moods. Because bugs can be reproduced. Moods can only be managed.

The Agent in the Demo Is an Employee. In Production, It's an Intern.

AI automated testing demos are seductive. Give it a login page, it fills in credentials. Ask it to check the cart, it clicks through to checkout. Hand it a requirement, it generates test steps. Add "in the future, QA just reviews what AI produces" — sounds reasonable. Isn't this exactly what productivity gain looks like?

Real systems are not demos.

Real systems have staging environments, dirty data, permission layers, A/B experiments, pop-ups, fraud detection, flaky networks, legacy debt, and business rules buried in corners. Worse — real systems change every day.

The first thing an Agent does when it enters a real system isn't test — it gets lost. It doesn't know which accounts have permissions. It doesn't know why a button doesn't render for certain users. It doesn't know if an error toast is expected behavior or a bug. It doesn't know if a slow page is an environment issue or a performance regression. It doesn't know whether a failing case should be retried, skipped, reported, or escalated.

So the team starts patching its context. Account structures, environment docs, page layouts, business rules, exception handling, prompt tuning, eval pipelines, tracing, manual review. And somewhere in that process, everyone realizes something is wrong:

This thing isn't replacing people. It's an intern who constantly needs the world explained to it, every result double-checked, and who never takes responsibility.

The Agent's biggest problem isn't that it can't do the work — it's that it doesn't know when it's done it wrong. Testing can't accept this. Because testing isn't writing an essay — you can revise an essay. A bad test leads teams to misjudge quality. A false positive wastes engineering time. A false negative ships a bug to production. An unstable test system ends up being ignored by everyone.

It gets worse. Teams start bending their own workflows to make the Agent appear to function. A problem one Playwright script could solve now requires a prompt. A problem a mock server would handle now requires explaining data state to an Agent. A problem a single assertion would catch now requires asking a model whether "the page looks correct."

You think you're automating testing. You're actually automating the care and feeding of AI.

Anthropic calls this "human-in-the-loop." Sounds sophisticated. But much of the time, it means: when AI can't finish, you clean up; when AI judges wrong, you review; when AI gets lost, you navigate; when AI breaks things, you explain. The bill is still theirs. The accountability is still yours.

What Enterprises Actually Buy Is a More Expensive Bill

Buying SaaS used to come with at least one guarantee: certainty. Jira standardizes process. GitHub standardizes code collaboration. CI standardizes builds and deploys. These tools don't necessarily make organizations smarter, but they lock in certain behaviors.

AI is different. A lot of AI products sell possibility, not certainty.

"It might cut your QA by 50%." "It might automatically surface production issues." "It might double engineering velocity."

The keyword is "might." This is also the shrewdest part of Anthropic's pitch. Say too much and you get held accountable. Say too little and nobody buys. The optimal play is to let every outcome hover at "might" — might replace, might improve, might restructure, might disrupt. Then charge enterprises a definite price for an uncertain future.

So token costs, platform fees, integration fees, consulting fees, PoC fees, internal headcount — it all adds up. The dashboard looks great: call volume impressive, token burn rate trending, transformation narrative locked in.

But at the end, there are only three questions that actually answer ROI: Who was doing this before? How much less are they doing now? Did the time saved turn into revenue, profit, or stronger organizational capability?

Most AI automated testing projects die at the second question. Nobody's headcount changed. Script volume didn't drop. Review work didn't decrease. There's just an extra model call in the middle.

Token is not productivity. Token is a cost unit. Wiring LLMs into every step of your test pipeline doesn't equal automation. In many cases, it converts cheap, deterministic, controllable engineering problems into expensive, uncertain, hard-to-debug AI problems.

Before: script fails, engineer reads the logs. After: Agent fails, engineer guesses what it was thinking. That's not efficiency — that's trading determinism debt for cognitive debt. Technical debt can be localized. Cognitive debt has no boundary. Every problem eventually becomes: try again, adjust the prompt, add more context, switch models, buy more credits. Looks like iteration. Feels like gambling. Just with a rebranded casino called "AI transformation."

Testing's Core Purpose Is to Eliminate Ambiguity, Not Simulate Intelligence

There's a common misconception about automated testing: that its goal is to simulate a human. Which makes Agents appealing — humans look at pages, Agents look at pages; humans click buttons, Agents click buttons; humans judge whether results are correct, Agents seem to as well.

Anthropic loves this misconception. Because the moment you believe testing means "operating a system like a human would," you naturally start believing a smarter Agent can replace the human.

But testing's purpose isn't to simulate a human. Testing's purpose is to turn quality judgments into machine-executable contracts.

A good test isn't "smart like a human" — it hard-codes "what correct means." What does the API return? How does state change? What should be in the database? Did the event fire? How do permission boundaries apply? What's the performance threshold? The more precisely these are defined, the more valuable the test.

AI thrives in ambiguity. It's built to produce plausible answers inside fuzzy inputs. Testing is built to eliminate ambiguity. That's the fundamental conflict.

You can use AI to assist in writing tests — generate skeletons, fill in edge cases, explain failures, cluster log issues. That's genuinely valuable. But you cannot delegate to AI the decision of whether a system is correct. Because "correct" doesn't emerge from a model. It comes from business rules, API contracts, and the shared understanding engineers and QA have built about how the system should behave.

Testing isn't letting the machine improvise. Testing is refusing to let the machine improvise. The more critical the system, the less it can rely on intuition. Payments can't rely on intuition. Permissions can't. Ledgers can't. Deploys can't.

This is why so many AI testing projects eventually land back on Playwright, Cypress, JUnit, pytest, mocks, fixtures, CI, coverage, and contract tests. Not because these tools are glamorous. Because they're reliable. In engineering, reliable usually beats smart.

The Real Cost Is Misdirected Priorities

Burning millions to confirm AI can't take over automated testing stings financially. But the more expensive cost is having priorities hijacked.

This can't be reduced to leadership not understanding technology, or teams executing poorly. More precisely: players like Anthropic have spent two years manufacturing an illusion — that if models keep improving, a lot of foundational engineering work can be skipped.

So when the right move is building test infrastructure, teams ask if they can buy an Agent instead. When the right move is cleaning test data, they wonder if prompt tuning would work instead. When the right move is building a stable environment, they wonder if multimodal page understanding might help. When the right move is defining quality standards, they wonder if the model can self-assess.

This is like studying smart interior design before the foundation is poured. The renovation isn't worthless. The building will collapse.

When AI projects fail, it's tempting to blame "the model isn't strong enough yet." That's the most convenient attribution — it pushes the problem into the future. This year the model isn't capable enough — try again next year. Next year the context window isn't long enough — try again the year after. After that the Agent isn't stable enough — keep waiting.

Who benefits most from this logic? Anthropic, obviously. Because every failure doesn't prove their narrative is flawed — it proves you should buy the next generation. Model not strong enough? Upgrade. Context too short? Upgrade. Tool calls unreliable? Upgrade. Too expensive? Wait for the next version. Results disappointing? Run another PoC.

Every road leads to a bill.

AI can amplify engineering capability. It cannot replace it. A team without a stable test system will become more chaotic after adding AI. An organization without clear quality standards will spend more after adding Agents. AI won't automatically fill in the lessons an organization missed — it will just illuminate the gaps more brightly.

Where AI in Testing Actually Works

This isn't an argument that AI is useless in testing. The opposite. But its highest-value position isn't to take over testing end-to-end — it's to embed inside an existing engineering system and handle the low-risk, high-repetition, verifiable work.

Like recommending which tests need to be added based on a code diff. Like generating boundary cases from an API schema. Like analyzing failure patterns in flaky tests. Like clustering production error logs and attributing them to likely modules. Like helping QA convert natural language scenarios into Playwright skeletons. Like flagging in a PR: "you changed the permission check but didn't add a corresponding test."

These use cases share one property: AI isn't responsible for the final judgment. It proposes, humans confirm. It generates, scripts verify. It explains, the engineering system decides.

AI works best as co-pilot. It can't be the seatbelt. The seatbelt has to be certain. The co-pilot can be smart. These two roles cannot be swapped.

If an AI testing tool's value proposition is "you won't need to write tests," it's almost certainly a trap. If it's "you'll write reliable tests faster," there might be something there. The first is selling a fantasy. The second is selling a tool.

Anthropic prefers selling the first. Because fantasies have the largest TAM. "Help you write Playwright scripts faster" sounds like a utility. "The future testing team will be rewritten by Agents" sounds like a next-generation platform. Capital markets love the second story. Executive reporting loves it. Headline writers love it. But when it reaches the team doing the actual work, the first saves time and the second burns budget.

What This Experiment Actually Proved

On its face, the millions-of-dollars conclusion is simple: AI cannot independently take over automated testing.

But that's not the full story. It also proved several harder things to say out loud.

It proved that many enterprises can't distinguish demo from productivity. It proved that many people can't tell apart "the model can do this once" from "the system can run stably long-term." It proved that the ROI of many AI projects was never seriously calculated from day one. And it proved that when a narrative gets hot enough, engineering common sense gets temporarily labeled as conservatism.

A month ago, the person who said "AI is unreliable" might still have been questioned. A month later, the bill proved them right. Does that feel satisfying? It doesn't. Because the organization already paid the tuition.

A mature organization shouldn't need a million-dollar bill to validate common sense. It should allow the team to say the uncomfortable things before the project kicks off. It should allow someone to ask: if this Agent fails, who's accountable? How do we verify the result? Which person does this workflow eliminate? How does this enter CI? Where exactly is this cheaper than our existing scripts?

If those questions can't be answered clearly, the project shouldn't be approved. Not because of being anti-AI. Because of respecting money.

Anthropic won't ask these questions for you. Their sales team won't either. What they hope you ask is: "When can we integrate?" "How many credits do we need?" "Can you support our use case?" But what enterprises really need to ask is: "If this fails, can we explain why?"

Most AI projects can't answer that question. If you can't answer it, you don't have an engineering system. You have an expensive wish machine.

Anthropic's Promises Are Landing on Enterprise Balance Sheets

Over the past two years, AI companies told a beautiful story: Agents will take over knowledge work, software will write itself, tests will run themselves. Just plug in the model and you get a digital workforce that never sleeps, scales infinitely, and is always on call.

The story was irresistible. Irresistible enough that many people forgot to ask: what, exactly, has it saved us?

If an AI project burned millions of dollars and ultimately proved "testing still requires people and scripts," it did provide something — an expensive organizational education. It told leadership that AI isn't magic. It told the team that engineering discipline doesn't expire. It told finance that token burn doesn't equal transformation. It told everyone that the future in the demo doesn't directly convert to production productivity.

It was just a very expensive lesson.

The real question isn't whether Anthropic has capability. Anthropic clearly has capability. The question is that it describes capability boundaries too lightly, deployment costs too sparsely, and future returns too generously. It packages demo smoothness as production inevitability. It packages the model's occasional flashes of intelligence as productivity enterprises can purchase. It packages enterprise anxiety about cost reduction into an ever-thickening stack of token invoices.

Sales always pitches the roadmap. Startups always sell the future. Model companies always want you to believe "the next generation will solve everything." The real question is why enterprises are so ready to believe it.

Because "AI replaces humans" is a much sexier story than "go back and build out your automated testing infrastructure." The first sounds like the future. The second sounds like grinding work.

But most of what creates lasting value in software engineering is grinding work. Writing scripts. Filling in test cases. Cleaning data. Stabilizing CI. Defining quality standards. None of this disappears because Agents exist — it just finds different ways to come collect what it's owed.

Some of that bill you can pay to engineers. Some to QA. Some to infrastructure. You can also pay it to a model company. The difference is: after paying the first three, the organization grows capabilities. After paying the last one, you usually just grow the next bill.

Next time someone walks into the conference room with an AI automated testing demo — whether you're the boss, the engineer, the QA lead, or the person holding the budget — ask one question first:

Is this improving our quality, or is it improving Anthropic's revenue?

Here's the experiment that made me stop: GPT-5.4 could solve a set of ARC-AGI puzzles at 100% accuracy. Researchers fed it the correct answers and asked it to consolidate those experiences into long-term memory. After 10 rounds of updates, accuracy dropped to 52.6%.

This isn't a case of failing to learn. It's a case of knowing the answer, then systematically unlearning it through its own memory updates.

Memory consolidation is cloning your best

In my earlier post on why nature never clones its best, the argument was: in a multimodal fitness landscape, copying your current best to every subsequent generation doesn't make the population smarter — it creates a genetic bottleneck and collapses exploration.

Agent memory has the same failure mode.

A raw trajectory isn't an oracle. It's a snapshot of how an agent and environment interacted under a specific set of conditions. Memory isn't the asset itself — it's the impression the environment left behind.

The invariant from that post: Centralize feedback, decentralize exploration. Best can inform future runs. It can't become the genome of all future runs.

Consolidated memory is your current best summary. That's the problem. Every time you run consolidation, you're asking a model to select the most reasonable current interpretation of a set of experiences. Then you use that interpretation as the input for the next round. You're not learning from experience anymore — you're learning from the previous summary of experience.

Memory consolidation is just cloning your current best explanation in the space of knowledge.

We trust summaries too much

The natural design for agent memory goes like this: agent completes a task, produces a trajectory with inputs, reasoning, actions, feedback, successes and failures. LLM summarizes the trajectory into a lesson. Lesson goes into the memory bank. Future similar tasks retrieve relevant lessons.

This feels right because it mirrors how humans work. We don't remember every moment verbatim — we abstract, generalize, build schemas. So the assumption is that agents should do the same, and that building good summaries is building good memory.

In demos, it works. First run fails, write a reflection. Second run uses the reflection, succeeds. Conclusion: memory helps.

But the paper asks a harder question: what if this process keeps going?

Summaries create epistemic bottlenecks

Many forms of human suffering trace back to this mechanism. Survival strategies from childhood keep running on autopilot decades later. Protective reactions formed in one context become the walls in another. The problem isn't that those strategies were wrong when they formed — they were correct for the conditions that produced them. The problem is that long after those conditions changed, they kept running as if they hadn't.

Agent memory has the same structure. A memory that was correct in the environment where it was generated becomes noise when that environment shifts — and it's still being retrieved to guide behavior.

Cloning best creates a genetic bottleneck. Continuous summarization creates an epistemic bottleneck. Both compress something important. The shared problem isn't the compression itself — it's that it happens too early, too confidently, and with no way back.

WebShop, ALFWorld, AppWorld, ARC-AGI — the strategy spaces here are all multimodal. A successful trajectory doesn't reveal universal rules. A clean summary doesn't mean you've captured actual structure.

In a multimodal task space, early abstraction is early convergence.

Memory isn't an archive — it rewrites history

The paper's critical observation: memory consolidation isn't an append-only log. It's a rewrite.

Each batch of new experiences doesn't get appended to a store. The LLM rewrites the existing memory: merging, generalizing, dropping edge cases, adjusting phrasing, generating new rules. It looks like housekeeping. It's actually history revision.

One rewrite is fine. After ten, fifty, a hundred — boundary conditions from the original experience get smoothed away, useful details get lost, patterns that only held in narrow conditions get encoded as universal rules, and early bad abstractions become the foundation for the next bad abstraction.

Like a photo repeatedly screenshotted, re-uploaded, and re-compressed. Each copy is "basically the same." After enough iterations, you can't make out the faces.

Forgetting is at least an empty slot. A bad memory gives you a confident, wrong answer.

The most striking finding: useful experiences become bad memories

What makes this paper worth your time is that it doesn't settle for "LLM summarization produces errors." That's trivially true.

The authors controlled for input quality.

They didn't feed failed trajectories to an agent and observe degradation. That's garbage-in-garbage-out — not interesting. They used demonstrated-useful experiences. Then in the ARC-AGI Stream experiment, they went further: they gave the agent ground-truth solutions directly.

Correct answers. Useful experience. Now summarize, please.

100% → 52.6%.

The experience was useful. The consolidation broke it.

This is the lethal finding for anyone building agent systems. We assumed consolidation was at worst neutral — maybe not helpful, but not actively harmful. That assumption is gone.

Why streaming updates degrade fastest

The paper compares three update modes.

Static-All: see the full trajectory pool, summarize once. Static-Group: group by task type, summarize each group separately. Stream: the realistic production case — update memory each time a new batch arrives.

Stream degrades fastest. The reason is path dependence.

If early memory gets written slightly wrong, every subsequent update is built on top of that error. The model never sees the full history — only "the summary of history." Next round it summarizes the summary. The system isn't learning from experience anymore. It's learning from the ghost of the previous summary.

This is cache corruption. If source data is intact, you can recompute. If source data is gone and only a corrupted cache remains, every downstream module runs on poisoned state indefinitely.

The paper's repeated conclusion: keep raw trajectories. Don't discard them.

Raw trajectories are independent lineages

In the evolution framing: raw trajectories are independent lineages.

Not all of them are great. Some episodes are clumsy, some failures look stupid, some paths look like noise. But you don't know which future task will turn that "noise" into critical evidence.

That's the value of independent lineages: they preserve the system's ability to have second thoughts.

Once you compress all trajectories into a summary, that space is gone. Future agents don't face multiple original experiences — they face a world that's already been interpreted by a previous version of themselves.

We're not constrained by our experiences. We're constrained by our interpretations of our experiences. An agent that "remembers the past" is fine. An agent that carries a pre-baked explanation of the past into every new context — that's where it gets dangerous.

Raw trajectories aren't waste

In most agent memory designs, raw trajectories are treated like logs: useful for debugging, expensive in production. The real long-term memory is the compressed lesson, rule, skill, workflow.

This paper's simplest baseline: don't summarize. Just use raw trajectories as in-context demonstrations.

It performs surprisingly well. Across WebShop, ALFWorld, AppWorld, the raw trajectory baseline isn't dominated by lesson-style memory — in many cases it's more stable.

The irony: we spend enormous effort getting LLMs to distill experiences into principles, and the raw experiences turn out to be more reliable.

Why? Because raw trajectories preserve context. They contain: the state when this action was taken, what the feedback was, where the failure occurred, what implicit conditions had to hold for the strategy to work.

A lesson leaves one clean sentence. Clean sentences are the most dangerous form of knowledge. They look like principles. They're lossy compressions masquerading as general truths.

Three failure modes

The paper categorizes faulty memory into three types. I'd put all three on any agent engineering checklist.

Misgrouping

Placing experiences from structurally different domains into the same bucket because they look textually similar.

LLMs are very good at surface-level pattern matching. Two tasks with similar descriptions might have completely different underlying structures. Summarize them together and you get a rule that appears valid but mixes two incompatible domains.

Overgeneralization

Taking a locally valid strategy and stripping the boundary conditions.

Original experience: "strategy X works when condition Y holds."
Consolidated memory: "use strategy X."

Next time the agent retrieves this memory near a task boundary, it executes strategy X with full confidence, and fails. The abstraction's value comes from removing noise. The abstraction's risk is removing preconditions. Current LLMs aren't reliably able to tell the difference.

Overfit

Learning surface patterns from a narrow input stream.

A rule that looks stable across seen samples fails on simple variations within the same task family. This is the same mechanism as overfitting in traditional ML. The difference: previously it happened in model parameters. Now it happens in textual memory that's being explicitly written and retrieved.

Agents don't lack memory. They lack memory management.

This paper is easy to misread as "don't build agent memory."

That's not the conclusion. Long-running agents can't live in a context window. Raw history grows unboundedly, retrieval costs rise, cross-task transfer requires abstraction. Without memory, an agent is a goldfish — permanently living in the present.

The real problem: don't design memory consolidation as an automatic background task that runs silently after every episode.

Most systems today: task completes → auto-summarize → auto-update → trusted by default. That pipeline is too dangerous.

A more defensible design separates memory into layers.

Episodic memory is the evidence layer

Preserve original episodes: inputs, actions, feedback, environment state, failure paths. They don't need to be in every prompt. But they must be retrievable. Any abstract memory should be able to link back to the evidence that produced it.

A memory with no traceable evidence is a hallucination incubator.

Semantic memory is the hypothesis layer

Lessons, rules, workflows, skills — treat these as hypotheses, not facts.

A hypothesis has a scope, a confidence level, a source, and known counterexamples. Not:

"Check inventory before purchasing."

But:

"In WebShop-style tasks where item pages expose inventory status, checking before checkout reduces invalid purchases. Source: episodes 12, 18, 31. Counterexample: episode 44, where inventory status had an update delay."

Verbose, yes. More expensive, yes. Reliable systems are expensive.

Consolidation is an action, not a side effect

This is the same question as "is best still useful in independent evolution?" Yes — but best can't produce all future descendants. Summaries are useful — but they can't replace all evidence.

Agents should be able to choose: Retain, Delete, Consolidate. Not every episode deserves summarization. Not every success deserves abstraction. Not every new experience should rewrite existing memory.

The paper's ARC-AGI Stream results show: when agents can choose their memory actions, they default to retaining raw episodes and use abstract memory sparingly. More extreme: disabling consolidation entirely and doing only episodic management can match or beat the full auto mode.

When abstraction isn't reliable, less abstraction is a capability.

Memory is the new state management problem

The AI agent conversation has mostly focused on planning, tool use, and multi-step reasoning. But if agents are meant to run long-term, memory becomes the new state management problem.

State management is never just "save it somewhere." It includes consistency, versioning, rollback, isolation, expiry, auditing, and access control.

Agent memory needs all of the above. Today, most memory systems are at "summarize experience into text, dump into vector store" — a very smart database with no transactions, no versioning, no audit log. Fine in a demo. Breaks in production.

Agent memory isn't a knowledge base. It's state that influences behavior. Anything that influences behavior must be managed as state, not as documents.

Premature convergence is a design defect

This paper and Why Nature Never Clones Its Best are making the same argument at different layers.

That post: don't let today's best contaminate the entire future population.
This one: don't let today's summary contaminate the entire future memory.

Both are instances of the same principle: in uncertain, complex, multimodal task spaces, premature convergence is a systemic risk.

The paper's most important claim isn't "LLMs can't remember." It's something more uncomfortable: LLMs can take useful experience and encode it as bad memory. This is more dangerous than having no memory at all. No memory means a dumb agent. Bad memory means a confident, wrong one.

So when I look at any agent memory design now, my first question is:

When this memory goes wrong, how does the system know?

If the answer is "it doesn't" — that's not memory. That's a contamination source.

Nature never clones its best because today's optimum might be tomorrow's dead end. Agents shouldn't clone their memories either, because today's most reasonable interpretation might be tomorrow's biggest bias.

References

• Useful Memories Become Faulty When Continuously Updated by LLMs

翻译成人话就是：LLM Agent 的长期记忆，不是越更新越聪明，而是可能越更新越蠢。

论文里有个实验很刺眼：GPT-5.4 原本能 100% 解出一组 ARC-AGI 题。研究人员给它正确答案，让它把成功经验总结成长期记忆。连续更新 10 轮之后，准确率掉到 52.6%。它不是"没学会"，而是"本来会，被自己的记忆教坏了"。

很多神话故事里，转世都要过奈何桥，喝孟婆汤。以前看这类设定，总觉得它只是为了制造戏剧冲突：忘了前世，才有今生的爱恨情仇。现在再看，反而像一种系统设计。前世记忆不是外挂，很多时候是污染源。那些经验是在上一组约束里长出来的——上一具身体、上一套关系、上一种秩序、上一轮恐惧和欲望。换了环境，还把它们当成真理带进来，不是开局优势，而是路径依赖。长期记忆最危险的地方，不是忘记，而是把一个过早的抽象硬编码进未来。

Memory consolidation 是另一种克隆 best

过去的 trajectory 不是神谕。它只是某个环境切片下，Agent 和世界互动之后留下的一组痕迹。记忆不是资产本身，记忆是环境留下的压痕。

在《为什么自然界从不复制最优》里，我写过一句话：

Centralize feedback, decentralize exploration.

反馈可以集中。探索必须分散。

best 可以作为参考信号、诊断信号、触发信号，但不能变成所有 lineage 的 base。因为一旦所有 lineage 都继承当前 best，它们就不再是在多个 basin 里探索，而是在同一个 basin 里排队撞墙。

raw trajectory 是多个 lineage。每段经历都有自己的上下文、状态、反馈、失败路径。它们之间可能互相矛盾，可能还没来得及被解释，可能只是未来某个问题的关键证据。这和"前世记忆"很像——不是不能参考，而是不能直接继承为真理。真正危险的不是记得过去，而是忘了过去为什么成立。

consolidated memory 是当前 best summary。它看起来更干净、更短、更像知识。但它也是一次选择：哪些细节保留，哪些细节丢掉；哪些经验被认为同类，哪些边界条件被抹平；哪些不确定性被写成确定规则。

你每更新一次 memory，都是在问模型：请从这些经验里选一个当前最合理的解释。然后下一轮，再基于这个解释继续解释。这不就是把 best 作为下一代 base 吗？

Memory consolidation 的本质，是在经验空间里复制当前 best explanation。

我们太相信总结了

现在做 Agent memory，最自然的设计是这样：Agent 完成一个任务，得到一段 trajectory——里面有问题、思考、动作、反馈、成功或失败。然后让 LLM 把这段经历总结成 lesson，写进 memory bank。下次遇到类似任务，再把相关 memory 检索出来，塞进上下文。

这套设计听起来太合理了。人不也是这样学习的吗？没有人会把每一天的所有细节原样背下来，我们会抽象、归纳、形成 schema。

这套逻辑在 demo 里通常很 work。第一次失败，写一条反思；第二次调用反思，成功了。于是很容易得出结论：记忆有效。

但这篇论文问了一个更狠的问题：如果这个过程持续发生，会怎样？

答案不太好看。

总结会制造认知瓶颈

人类的很多痛苦，也来自这里。小时候在某个环境里形成的生存策略，长大后还在自动运行。过去为了保护自己形成的反应，后来变成限制自己的墙。它不是一开始就是错的，它是在时过境迁之后继续被当成真理，才开始害人。

Agent memory 也是同样的结构。某条 memory 在生成它的环境里可能完全正确，但环境变了，任务 family 变了，工具接口变了，评价标准变了，它还被检索出来指导行为，就会从经验变成偏见。

复制 best 会制造 genetic bottleneck。连续总结会制造 epistemic bottleneck。两者的共同问题不是"压缩"本身，而是压缩发生得太早、太自信、太不可逆。

WebShop、ALFWorld、AppWorld、ARC-AGI，这些任务的策略空间都是多峰的。一个成功 trajectory 不代表它揭示了通用规律。一个漂亮 summary 不代表它抓住了真正结构。在多峰任务里，过早抽象就是过早收敛。

转世不带记忆，某种意义上是系统在避免过拟合上一轮环境。不是因为过去没有价值，而是因为过去太有说服力——它带着亲历者的重量，很容易伪装成真理。

总结不是学习的终点，总结是对可能性的删除。

记忆不是存档，是改写历史

论文里有个关键观察：memory consolidation 不是 append-only log，而是 rewrite。

每来一批新经验，LLM 不是简单把它们放进仓库，而是重写之前的记忆：合并、概括、删掉细节、调整措辞、生成新的规则。听起来像整理，实际上是在改写历史。

一次改写问题不大。十次、五十次、一百次之后，原始经验里的边界条件会被磨平，有用细节会丢，某些只是偶然成立的 pattern 会被写成普遍规则，早期一次错误抽象会被当成事实继续抽象。

就像你把一张照片反复截图、转发、压缩。每次都"差不多"，最后已经看不清人脸。也像进化系统里反复复制当前 best——每一代看起来都比上一代更"优"，但整个 population 的选择空间在变窄。最后不是找到了最优，而是失去了偏离当前方向的能力。

忘记至少是空白。记错会给你一个很自信的错误答案。

最刺眼的结果：有用经验也会变成坏记忆

这篇论文最有价值的地方，是它没有停留在"LLM 总结会出错"这种泛泛而谈。

作者控制了输入经验质量。他们不是拿一堆失败 trajectory 去喂 Agent——那样没什么意思，垃圾进垃圾出而已。他们用的是已经被证明有用的经验。更狠的是，在 ARC-AGI Stream 实验里，作者直接给 ground-truth solution。

按理说这应该是最理想的情况：题会做，答案正确，经验有用。你让模型总结一下，最差也不该把自己搞废吧？

结果就是开头那组数字：100% 掉到 52.6%。

这不是"经验没用"，这是"经验被总结坏了"。经验是 useful 的，坏掉的是 consolidation。

这个结论对做 Agent 的人很致命。因为我们过去默认 consolidation 至少是 neutral 的——它可能没帮助，但不至于伤害系统。这个假设站不住了。

Streaming memory 为什么更容易坏

论文比较了几种更新方式。

Static-All：一次性看完整个 trajectory pool，然后总结。Static-Group：按任务类型分组，再分别总结。Stream：真实 Agent 更常见的方式，来一批经验就更新一次 memory。

结果很清楚：Stream 最容易坏。原因不复杂——Stream 有路径依赖。

早期记忆一旦写偏了，后面所有更新都站在这个偏差上继续写。LLM 看到的不是完整历史，而是"历史的摘要"。下一轮它再摘要摘要。最后系统不是在学习经验，而是在学习上一次总结的残影。

这和工程里的 cache corruption 很像。源数据还在，最多重新算一次。源数据丢了，只剩一个被污染的 cache，后面所有模块都会基于污染状态继续运行。

所以这篇论文反复强调一个朴素原则：raw trajectory 要保留，别急着删。

Raw trajectory 是独立 lineage

沿用进化那篇文章的语言：raw trajectory 就是独立 lineage。

它们不一定都优秀，也不一定马上有用。有些 episode 很笨，有些失败很蠢，有些路径看起来只是噪声。但你不知道未来哪个任务会让这段"噪声"突然变成证据。这就是独立 lineage 的价值：它们保留了系统后悔的可能性。

一旦你把所有 trajectory 压成一个 summary，这种后悔空间就没了。未来 Agent 不再面对多段原始经验，而是面对一个被过去的自己解释过的世界。

我们不是被经历限制，而是被自己对经历的解释限制。

这也是为什么"带着前世记忆转世"在小说里很爽，在系统设计里却很危险。它给了你一个开局优势，也给了你一套来自旧世界的默认参数。新世界还没开始探索，旧世界已经替你做完了解释。

Raw trajectory 不是废料

很多 Agent memory 设计里，raw trajectory 的地位很低。它像日志——调试时有用，上线后嫌贵。真正要进入长期记忆的，是压缩后的 lesson、rule、skill、workflow。

这篇论文给了一个很朴素的 baseline：不总结，直接把 raw trajectory 当 in-context demonstration 用。

结果它经常很能打。在 WebShop、ALFWorld、AppWorld 这些环境里，raw trajectory baseline 没有被 lesson-style memory 轻松打爆，反而很多时候更稳。

我们花很大力气让 LLM 把经历总结成原则，最后发现原始经历本身可能更可靠。

为什么？因为 raw trajectory 里保留了上下文。它知道这个动作是在什么状态下做的，知道反馈是什么，知道失败发生在哪里，知道一个策略成立时旁边还有哪些隐含条件。而 lesson 往往只剩一句漂亮的话。

漂亮的话最危险，因为它看起来像原则。

三种坏记忆

论文把 faulty memory 归纳成三类，很适合放进工程检查表。

Misgrouping：把不该放一起的经验放一起

两个任务表面相似，不代表底层结构相同。LLM 很容易基于表面文本把它们归为一类，然后总结出一个跨任务规则——这个规则看起来很合理，但其实混了两个 domain。

就像你把"用户增长"和"传销"都归到"裂变"下面，然后总结出一套通用增长方法。词是同一个词，东西不是同一个东西。

Overgeneralization：把局部经验写成普遍原则

一个策略本来只在特定状态下成立。总结时，限定条件被删掉了。于是 memory 里只剩："遇到这种情况，应该这样做。"

下次遇到邻近任务，Agent 检索到这条 memory，非常自信地照做，然后翻车。

抽象的价值来自去掉噪声，抽象的风险也来自去掉条件。现在的 LLM 还不够擅长判断什么是噪声、什么是条件。

Overfit：在窄输入流上学到表面模式

如果输入流很窄，memory 会过拟合已见 pattern。某一类题看多了，LLM 会总结出一条看似稳定的规则，但这个规则可能只对已见样本有效，遇到同 family 的简单变体就崩。

这跟传统 ML 里的 overfit 没什么本质区别。区别只是，以前 overfit 发生在参数里，现在发生在文本记忆里。

Agent 不是缺记忆，是缺记忆管理

这篇论文容易被误读成：不要做 Agent memory。

不是。长期来看，Agent 不可能只靠上下文窗口。raw history 会无限增长，检索成本会上升，跨任务迁移也需要抽象。没有 memory，Agent 只能像金鱼一样永远活在当前窗口里。

真正的问题是：不要把 memory consolidation 设计成自动发生的后台任务。

现在很多系统像这样：任务结束，自动总结；总结完，自动更新；更新后，默认可信。太危险了。

更合理的设计，应该把记忆拆成几层。

Episodic memory 是证据层

保留原始 episode，包括输入、动作、反馈、环境状态、失败路径。

它不一定每次都进 prompt，但必须可追溯。任何 abstract memory 都应该能回链到原始证据。没有 evidence 的 memory，就是幻觉的温床。

Semantic memory 是假设层

lesson、rule、workflow、skill 都应该被当成 hypothesis，而不是 fact。

既然是假设，就要有适用范围、置信度、来源、反例。一条 memory 不应该只是：

"购买商品前先检查库存。"

它应该更像：

"在 WebShop 类任务中，如果商品页面存在库存状态，购买前检查库存可减少无效 checkout。来源：episode 12、18、31。反例：episode 44 中库存状态延迟更新。"

更啰嗦，也更贵。但可靠系统本来就贵。

Consolidation 是动作，不是默认副作用

这和"best 在独立进化下还有用吗"是同一个问题。

best 当然有用，但它不能繁衍所有后代。summary 当然有用，但它不能替代所有证据。

Agent 应该可以选择 Retain、Delete、Consolidate。不是每个 episode 都值得总结，不是每次成功都值得抽象，不是每条新经验都应该改写旧记忆。

这篇论文在 ARC-AGI Stream 里也观察到，当 Agent 被允许自己选择这些动作时，它默认更愿意保留 raw episode，只少量使用 abstract store。更极端的是，禁用 consolidation、只做 episodic management 的版本，能匹配甚至超过 full auto mode。

当抽象能力不可靠时，少抽象就是一种能力。

对工程系统的启发

如果今天让我设计一个 production Agent memory，我会先定几条保守规则：

raw episode 不直接丢弃，至少在一个可审计窗口内保留；任何 abstract memory 必须带 provenance——从哪些 episode 来，哪些任务验证过，最近一次导致失败是什么时候；memory update 不能只看新增经验，还要做 regression test，更新后老任务还会不会，以前稳定通过的 case 有没有掉；consolidation 要分组，不要把不同 task family 的经验混在一起；memory 要支持撤销，一次坏的 consolidation 不应该永久污染系统。

这些听起来都不酷，没有"自进化 Agent"那么性感。

但工程上真正难的地方，往往不是让系统多做一步，而是知道哪一步不该做。

记忆会成为新的状态管理问题

过去我们讨论 Agent，经常把问题放在 planning、tool use、multi-step reasoning 上。但如果 Agent 真要长期运行，memory 会变成新的状态管理问题。

状态管理从来都不只是"存起来"——它还包括一致性、版本、回滚、隔离、过期、审计、权限。Agent memory 也是一样。

今天很多 memory 系统还停留在"把经验总结成文本，放进向量库"的阶段。它像一个很聪明但没有事务、没有版本、没有审计日志的数据库。短 demo 里没问题，长期运行一定出事。

Agent 的记忆不是知识库，而是会影响行为的状态。

只要它会影响行为，就必须按状态来管理，而不是按文档来管理。

过早收敛是设计缺陷

这篇论文和《为什么自然界从不复制最优》有异曲同工之妙。

那篇讲的是：不要让当前 best 污染整个未来 population。这篇讲的是：不要让当前 summary 污染整个未来 memory。底层都是同一件事：在不确定的、复杂的、多峰的任务里，过早收敛是一种系统性风险。

这篇论文最好的地方，是它说的不是"LLM 不会记忆"，而是一件更麻烦的事：LLM 可以把有用经验写成坏记忆。

没有记忆的 Agent，只是笨。有坏记忆的 Agent，会自信地错。

所以我现在看 Agent memory，会先问一个问题：这条记忆坏掉的时候，系统怎么知道？

如果答案是"不知道"，它就不是记忆，它是污染源。

自然界不复制最优，因为今天的 best 可能是明天的 worst。Agent 也不该克隆自己的记忆，因为今天最合理的解释，可能正是明天最大的偏见。

References

• Useful Memories Become Faulty When Continuously Updated by LLMs

Some people add a stack of SKILLs to an Agent, wire it to all kinds of knowledge bases, build workflows everywhere, stuff the prompt with caveats, counterexamples, and few-shot examples, then say very seriously: we are doing harness engineering now.

My first reaction was: this has barely reached the entrance, and is still far from real Harness Engineering.

SKILLs, KBs, and structured prompts are valuable. They help the model understand context, act closer to your expectations, and avoid plenty of basic mistakes. But if you call these things a harness, you are making the whole problem shallower than it is.

KB/SKILL is not harness. At most, they are the input constraint layer of a harness.

Prompt Is Not the Rein, It Is Just What You Say to the Horse

The easiest way to misunderstand Harness Engineering is to hear the word "harness" and immediately translate it into "constraint." If it is about constraints, then writing longer prompts, adding more rules, and preparing more KBs must be constraining the model, right?

Not exactly.

Imagine you are riding a horse. You tell it: "A little to the left, don't run too fast, go around the rocks, there is a river ahead, don't jump." That is useful. If the horse understands, the error rate goes down.

But that is not a harness.

A real harness is the rein, saddle, guardrail, route, checkpoints, and the mechanism that lets you review why you fell after you fall. What you say to the horse is only the softest layer.

LLMs are the same.

Prompts can change the probability distribution of model outputs. SKILLs can encode common patterns in advance. KBs can fill in missing context. Structured prompts can reduce the space for free-form improvisation.

All of these things do the same job: they increase the prior probability of a correct output.

The key word is probability.

As long as the execution layer is still a model call, the output remains probabilistic. You can move the probability from 60% to 80%, from 80% to 92%, maybe even make it look close to 99% in some scenarios. But it has not become deterministic.

This is where many people get stuck.

Many people think "the model is more obedient" means "the system is constrained." It does not. A more obedient horse does not mean you have guardrails around the track.

A Real Harness Has at Least Five Layers

More precisely, a harness should have at least five layers.

Input Constraints: Raising the Prior Probability

This layer includes SKILLs, KBs, structured prompts, tool descriptions, few-shot examples, and system instructions.

Their goal is not to guarantee correctness. Their goal is to make the model more likely to get onto the right path before generation starts.

For example, you tell an Agent: read the README before editing code, run tests before submitting a PR, do not guess when uncertain. These rules are useful. They eliminate a lot of basic mistakes.

But in essence, they are still "telling the model what it should do." The model may follow them, or it may miss them. It may understand them correctly, or distort them. It may behave well in simple cases, then suddenly lose control after long context, complex state, or tool failures.

So the value of the input constraint layer should be acknowledged. Its boundary should be acknowledged too.

A prompt can make the model more likely to be correct. It cannot make the system required to be correct.

Execution Layer: Probability Cannot Be Removed

The execution layer is the model call itself.

As long as an LLM sits in the middle, the system contains a probabilistic node. This node is not a bug. It is the nature of the thing.

Many engineers do not want to accept this. They keep trying to "prompt away" probability with more elaborate prompts. That is a bit like trying to eliminate traffic accidents with a better driving manual. The manual can lower the accident rate, but it cannot replace brakes, traffic lights, and crash tests.

Model calls work the same way.

You can switch to a stronger model. You can tune temperature. You can increase thinking tokens. You can add chain-of-thought-style intermediate steps. You can ask the model to self-check. None of this changes the fact that the execution layer is still not a deterministic program.

This is also why "let another LLM check it" is only weak validation. It may help, but it is not a boundary.

Probabilistic output cannot be closed by probabilistic judgment.

Output Validation: A Deterministic Gate Is the First Hard Boundary

A real harness starts to become hard at the output validation layer.

The keyword here is not "review." It is gate.

A gate means: if it does not pass, it cannot continue. Not "the model thinks it is fine," not "it looks okay to a human," not "it should probably be fine," but a deterministic check that blocks the output.

This is where the fast-loop earns its place. The fast-loop is not responsible for proving the truth of the universe. It is responsible for immediately cutting off obviously unqualified results after each Agent output in a cheap, deterministic, repeatable way.

A solid fast-loop gate should block at least seven classes of problems:

1. The output must satisfy the schema. If it does not, fail immediately.
2. Every factual claim must trace back to context, tool results, or an explicit assumption.
3. The Agent must not perform actions beyond its authorization scope, especially writing files, sending requests, deleting resources, or changing configuration.
4. The Agent must not package uncertainty as a certain conclusion.
5. Tool errors must not be swallowed. Failures must be exposed explicitly.
6. Modification tasks must produce a verifiable diff, not just "I changed it."
7. Critical artifacts must be reviewable by deterministic checkers, such as parsers, linters, tests, static analyzers, or policy rules.

These seven rules are not mysterious. They are not sexy either.

But engineering systems do not run on sexiness. They run on blocking the same class of error every time.

If an Agent generates JSON without schema validation, you are merely trusting it to generate JSON. If an Agent edits code without tests and static checks, you are merely trusting that it did not break anything. If an Agent writes an analysis report without citation coverage and source boundaries, you are merely trusting that it did not hallucinate.

Trust is not harness.

The first principle of harness is replacing "trust it" with "block it."

Feedback Layer: Slow-Loop Eval Calibrates Ground Truth

The fast-loop answers "can this output clear the minimum bar this time?" It does not answer a larger question: is your gate itself correct?

That requires slow-loop eval.

Many teams build a pile of automatic checks, then quickly fall into another hallucination: if all checks are green, the system is good. This idea is just as dangerous.

Because a checker can check the wrong thing.

Suppose you are building a code generation Agent. The fast-loop can check whether the code compiles, whether tests pass, and whether formatting is right. But none of that equals correct business logic. You may have tested the happy path and missed edge cases. You may have asked the Agent to fix a surface bug while introducing architectural debt. You may have overfit the eval set to a batch of old problems, then collapse the moment real users arrive.

The job of slow-loop eval is to periodically pull the system back to ground truth.

It does not have to run every time, and it does not have to be cheap. It may require human labeling, online sample replay, golden datasets, shadow traffic, real user feedback, and case study reviews. It is slow, but it calibrates direction.

The fast-loop is the brake. The slow-loop is the map.

Without a fast-loop, the system crashes around every day. Without a slow-loop, the system charges along the wrong map.

Reproducibility Layer: Eval Harness Makes Results Comparable

The last layer is the easiest to ignore: reproducibility.

You say one prompt version is better. How do you prove it? You say the new model increased pass rate from 72% to 81%. How do you prove it? You say a SKILL reduced hallucination. How do you prove it?

Without seed, model version, prompt snapshot, tool version, KB snapshot, and eval dataset snapshot, your conclusion is hard to reproduce.

You get 81% today and maybe 74% tomorrow. You do not know whether the model version changed, the tool response changed, the KB was updated, the sample was randomly different, or the prompt changed by one small sentence you forgot to record.

At that point, you are not doing engineering. You are doing mystical A/B testing.

A real eval harness records the entire runtime environment: what the input was, what the model was, which prompt version was used, what the tools returned, what the external dependencies were, how the checker judged the result, and where the ground truth came from.

Only then are results comparable. Only when they are comparable does optimization mean anything.

An improvement that cannot be reproduced is not an improvement. It is luck.

Why People Mistake SKILL/KB for Harness

This misconception is natural.

Because SKILL/KB is the easiest thing to show, and the easiest thing to sell.

Open a repo and see a pile of carefully organized markdown, polished prompt templates, and complex agent workflows, and you naturally feel that the system is engineered. It looks like engineering, reads like a specification, and demos more smoothly.

A real harness often does not look good.

Schema validators are not much of a demo. Log snapshots are not much to brag about. Eval datasets are dirty, case reviews are tedious, and writing deterministic checkers feels like labor. You spend two weeks building a gate, and in the end the only thing users see is "this error did not happen."

In software engineering, the most valuable things often make bad things not happen.

But "not happening" is hard to see.

So people naturally flock to prompt engineering. The feedback is fast, the cost is low, the changes are visible, and it is easy to talk about. Change one line in a system prompt today, see the metric rise a few points tomorrow. It feels rewarding.

That is fine.

The mistake is treating it as the destination.

Prompt engineering is the entrance, not the moat. SKILL is packaged experience, not a system boundary. KB is contextual asset, not a correctness guarantee.

You can start with prompt, but you cannot finish with prompt.

What Is a Harness Engineer Actually Building?

So what is a real Harness Engineer building?

Not longer prompts. Not more SKILLs.

The real work is building a structure that puts probabilistic models inside deterministic systems.

That sounds abstract. Split it apart and it becomes concrete:

The model may generate freely, but the output must pass schema. The model may call tools, but tool permissions must be controlled. The model may write code, but the diff must be checkable by tests and static analyzers. The model may summarize documents, but each key conclusion must trace back to source. The model may plan tasks, but high-risk actions must have a deterministic gate or human approval.

The key is not "restricting the model." The key is knowing where the model cannot be trusted.

The default posture of many Agent builders is: the model is smart, so I should let it do more.

The default posture of a Harness Engineer is: the model is smart, so I must know when it will apply that intelligence in the wrong place.

These two postures are worlds apart.

The former expands capability boundaries. The latter defines safety boundaries. Without the latter, the faster the former expands, the more dangerous the system becomes.

From Input Constraints to an Engineering Loop

I am not against SKILL, KB, or prompt engineering.

Quite the opposite. I think they are necessary. Without a good input constraint layer, an Agent performs terribly, and the gates that follow get flooded by garbage output. If a model has no understanding of the task context, even the strongest checker is just rejecting garbage efficiently.

But necessary does not mean sufficient.

SKILL/KB belongs to the input-constraint layer. This layer brings the model near the right direction and makes the system usable.

A full harness continues from there: the execution layer admits probability, the output layer builds deterministic gates, the feedback layer calibrates against ground truth, and the reproducibility layer makes each optimization comparable.

That is a complete engineering loop.

If a system has only SKILL/KB, with no gate, no eval, no snapshot, and no reproducibility, then at most it is a prompt-augmented agent. It is not a harnessed agent.

This distinction is not wordplay.

It decides whether you are building a demo or building a system.

Closing: Do Not Mistake the Threshold for the Destination

AI engineering today feels a bit like early Web development.

Someone could write HTML and think they were doing software engineering. Later, people slowly realized that real engineering was not just drawing the page. It also included state management, build systems, testing, monitoring, progressive rollout, rollback, security, performance, and maintainability.

Agents are the same today.

Writing prompts, organizing KBs, and making SKILLs are all important. But that is just drawing the page. The hard part is: when the model produces a wrong output, can you block it? When the metrics get better, can you prove it? When the system drifts after three months in production, can you reconstruct what happened?

Many people are excited about SKILL/KB/prompt engineering. It is easy to mistake input-layer capability for full Harness Engineering.

It is not the same thing.

A Harness Engineer's job is not to make the model speak better. It is to make the system more trustworthy.

有人给 Agent 加了一堆 SKILL，接上各种 Knowledge base，工作流满天飞，prompt 里塞满了注意事项、反例、few-shot，然后很认真地说：我们现在也在做 harness engineering。

我的第一反应是：这连门儿都还没摸着，离真正的 Harness Engineering 还远着呢。

SKILL、KB、structured prompt 当然有价值。它们能让模型更懂上下文，更容易按你的预期行动，也能显著降低低级错误。但如果你把这些东西叫 harness，那就把整件事想浅了。

KB/SKILL 不是 harness，它们最多只是 harness 的输入约束层。

Prompt 不是缰绳，只是你对马说的话

Harness Engineering 这个词最容易被误解的地方，在于大家听到 "harness"，脑子里自动翻译成“约束”。既然是约束，那我写更长的 prompt、加更多 rules、准备更多 KB，不就是在约束模型吗？

不完全是。

想象一下，你在骑一匹马。你对它说：“往左一点，别跑太快，看到石头绕过去，前面有条河，不要跳。”这当然有用。马听懂了，出错概率会下降。

但这不是 harness。

真正的 harness 是缰绳、马鞍、护栏、路线、检查点，以及摔下来之后能复盘为什么摔的机制。你对马说的话，只是其中最软的一层。

LLM 也是一样。

Prompt 能改变模型输出的概率分布。SKILL 能把一些常见模式提前编码进去。KB 能补充模型缺失的上下文。structured prompt 能减少自由发挥的空间。

这些东西都在做同一件事：提高正确输出出现的先验概率。

注意，是概率。

只要执行层还是模型调用，输出就仍然是概率性的。你可以把概率从 60% 提到 80%，从 80% 提到 92%，甚至在某些场景里看起来接近 99%。但它没有变成确定性。

很多人卡在这里。

很多人以为“模型更听话了”就是“系统被约束住了”。不是。马更听话，不等于你有了赛道护栏。

真正的 harness 至少有五层

更准确地说，harness 至少应该拆成五层。

输入约束层：提高先验概率

这一层包括 SKILL、KB、structured prompt、tool description、few-shot examples、system instruction。

它们的目标不是保证正确，而是让模型在生成之前更容易走到正确轨道上。

比如你告诉 Agent：修改代码前先读 README，提交 PR 前跑测试，遇到不确定的地方不要猜。这些规则很有用，能减少大量低级错误。

但它们本质上还是“告诉模型应该怎么做”。模型可以遵守，也可以漏掉；可以理解对，也可以理解歪；可以在简单场景里表现很好，也可以在长上下文、复杂状态、工具失败之后突然失控。

所以输入约束层的价值要承认，但边界也要承认。

Prompt 只能让模型更可能正确，不能让系统必须正确。

执行层：概率性不可消除

执行层就是模型调用本身。

只要中间经过 LLM，系统里就有一个概率性节点。这个节点不是 bug，是它的本质。

很多工程师不愿意接受这一点，总想通过更复杂的 prompt 把概率性“调没”。这有点像想通过更好的驾驶手册消除交通事故。手册可以降低事故率，但不能替代刹车、红绿灯和碰撞测试。

模型调用也是这样。

你可以换更强的模型，可以调 temperature，可以增加 thinking token，可以加 chain-of-thought 风格的中间步骤，可以让模型自检。但这些都没有改变一件事：执行层仍然不是 deterministic program。

这也是为什么“让另一个 LLM 检查它”只能算弱验证。它可能有效，但它不是边界。

概率性输出不能靠概率性审判完成闭环。

输出验证层：deterministic gate 才是第一道硬边界

真正的 harness 从输出验证层开始变硬。

这里的关键词不是"review"，而是 gate。

Gate 的意思是：不通过，就不能继续。不是“模型觉得可以”，不是“人看起来还行”，不是“差不多应该没问题”，而是一个确定性的检查把输出挡住。

fast-loop 的价值就在这里。fast-loop 不负责证明世界真理，它负责在每次 Agent 输出之后，立刻用便宜、确定、可重复的方式砍掉明显不合格的结果。

一个合格的 fast-loop gate，至少要挡住 7 类问题：

1. 输出必须满足 schema，不满足直接失败。
2. 所有事实性声明必须能追溯到上下文、工具结果或显式假设。
3. 不能执行超出授权范围的动作，尤其是写文件、发请求、删资源、改配置。
4. 不能把不确定性包装成确定结论。
5. 不能吞掉工具错误，失败必须显式暴露。
6. 修改类任务必须给出可验证 diff，而不是只给“我改好了”。
7. 关键产物必须能被 deterministic checker 复查，比如 parser、linter、test、static analyzer、policy rule。

这 7 条不神秘，也不性感。

但工程系统靠的从来不是性感。工程系统靠的是每次都能挡住同一类错误。

一个 Agent 生成 JSON，如果没有 schema validation，那你只是相信它会生成 JSON。一个 Agent 改代码，如果没有测试和静态检查，那你只是相信它没改坏。一个 Agent 写分析报告，如果没有 citation coverage 和 source boundary，那你只是相信它没幻觉。

相信，不是 harness。

Harness 的第一性原理，是把“相信”换成“挡住”。

反馈层：slow-loop eval 校准 ground truth

fast-loop 解决的是“这次输出能不能过最低门槛”。但它不解决另一个更大的问题：你的 gate 本身是不是对的？

这就需要 slow-loop eval。

很多团队会建一堆自动检查，然后很快陷入另一个幻觉：只要 check 绿了，系统就好。这个想法同样危险。

因为 checker 也可能检查错东西。

比如你做一个代码生成 Agent，fast-loop 可以检查代码能不能编译、测试能不能过、格式对不对。但这些并不等于业务逻辑正确。你可能测了 happy path，漏了 edge case；你可能让 Agent 修了表层 bug，却引入了架构债；你可能让 eval set 过拟合到一批老问题，结果真实用户一来全线崩盘。

slow-loop eval 的作用，就是定期把系统拉回 ground truth。

它不一定每次都跑，也不一定便宜。它可能需要人工标注、线上样本回放、golden dataset、shadow traffic、真实用户反馈、case study 复盘。它慢，但它校准方向。

fast-loop 是刹车，slow-loop 是地图。

没有 fast-loop，系统每天乱撞。没有 slow-loop，系统会沿着错误的地图一路狂奔。

复现层：eval harness 让结果可比较

最后一层最容易被忽略：复现。

你说某个 prompt 版本更好，怎么证明？你说新模型让通过率从 72% 到 81%，怎么证明？你说某个 SKILL 降低了 hallucination，怎么证明？

如果没有 seed、model version、prompt snapshot、tool version、KB snapshot、eval dataset snapshot，你的结论就很难复现。

今天跑出来 81%，明天可能是 74%。你不知道是模型版本变了，还是 tool response 变了，还是 KB 更新了，还是样本随机抽得不一样，还是 prompt 改了一个你忘记记录的小句子。

这时候你不是在做 engineering，你是在做玄学 A/B test。

真正的 eval harness 要记录整个运行环境：输入是什么，模型是什么，prompt 是哪一版，工具返回了什么，外部依赖是什么，checker 怎么判，ground truth 从哪里来。

只有这样，结果才可比较。只有可比较，优化才有意义。

不能复现的提升，不叫提升，叫运气。

为什么大家会把 SKILL/KB 误认为 harness

这个误区很自然。

因为 SKILL/KB 最容易展示，也最容易卖。

你打开一个 repo，看到一堆精心组织的 markdown、漂亮的 prompt template、复杂的 agent workflow，会觉得这个系统很工程化。它看起来像工程，读起来像规范，demo 起来也确实更稳。

而真正的 harness 往往不好看。

Schema validator 没什么可 demo。日志 snapshot 没什么可炫。eval dataset 很脏，case review 很琐碎，deterministic checker 写起来像苦力活。你花两周时间 build 一个 gate，最后用户看到的只是“这个错误没有发生”。

软件工程里最有价值的东西，很多时候就是让坏事不发生。

但“不发生”很难被看见。

于是大家自然会涌向 prompt engineering。它反馈快，成本低，变化明显，讲起来也顺口。今天改一句 system prompt，明天指标涨几个点，很有成就感。

这没错。

错的是把它当成终点。

Prompt engineering 是入口，不是护城河。SKILL 是经验封装，不是系统边界。KB 是上下文资产，不是正确性保证。

你可以靠 prompt 起步，但不能靠 prompt 收尾。

Harness Engineer 到底在 build 什么

所以真正的 Harness Engineer 在 build 什么？

不是写更长的 prompt，也不是堆更多 SKILL。

真正要 build 的，是一套把概率性模型放进确定性系统的结构。

这句话听起来抽象，拆开就很具体：

模型可以自由生成，但输出必须过 schema。模型可以调用工具，但工具权限必须受控。模型可以写代码，但 diff 必须能被 test 和 static analyzer 检查。模型可以总结文档，但每个关键结论必须能回到 source。模型可以规划任务，但高风险动作必须有 deterministic gate 或 human approval。

这里的关键不是“限制模型”，而是“知道在哪些地方不能相信模型”。

很多人做 Agent 的默认姿势是：模型很聪明，所以我让它多做一点。

Harness Engineer 的默认姿势是：模型很聪明，所以我必须知道它什么时候会把聪明用错地方。

这两种姿势差别极大。

前者是在扩张能力边界。后者是在定义安全边界。没有后者，前者扩得越快，系统越危险。

从输入约束到工程闭环

我不是反对 SKILL、KB、Prompt engineering。

恰恰相反，我认为它们是必要的。没有好的输入约束层，Agent 的表现会非常差，后面的 gate 会被垃圾输出淹没。一个完全不懂任务上下文的模型，就算你有再强的 checker，也只是在高效拒绝垃圾。

但必要不等于充分。

SKILL/KB 属于输入约束层。它们把模型带到正确方向附近，让系统开始可用。

继续往后补，才是 harness：执行层承认概率性，输出层建立 deterministic gate，反馈层用 ground truth 校准，复现层让每次优化可比较。

这才是一套完整的工程闭环。

如果一个系统只有 SKILL/KB，没有 gate，没有 eval，没有 snapshot，没有复现，那它最多叫 prompt-augmented agent，不叫 harnessed agent。

这个区别不是咬文嚼字。

它决定了你是在做 demo，还是在做系统。

结语：别把门槛当终点

AI 工程现在有点像早期 Web 开发。

有人会写 HTML，就觉得自己在做软件工程。后来大家才慢慢意识到，真正的工程不只是把页面画出来，还包括状态管理、构建系统、测试、监控、灰度、回滚、安全、性能、可维护性。

今天的 Agent 也是一样。

会写 prompt，会整理 KB，会做 SKILL，当然很重要。但这只是把页面画出来。真正难的是：当模型输出错了，你挡不挡得住？当指标变好了，你证不证明得了？当系统上线三个月后行为漂了，你复不复盘得清？

很多人热衷于 SKILL/KB/Prompt engineering，很容易把输入层能力误认为完整的 Harness Engineering。

不是。

Harness Engineer 的工作，不是让模型更会说，而是让系统更可信。

直到我让 Agent 清理 AB 实验代码：它很快扫出一堆调用点，然后说“清完了”。真正的问题不是 Agent 能不能读代码，而是我怎么证明它没有漏掉第 201 个调用点。对 Agent 来说，context 不应该只是源码文本；Code 本身就应该成为 Agent 可以查询、验证、推理的上下文。 Graphite 就是为这个问题做的。

源码不是程序的真相

今天大部分“代码理解”工具，都还停在源码层。Tree-sitter 把源码解析成 AST，Language Server 提供 symbol、reference、definition，Embedding 把代码块变成向量，RAG 再把相关片段塞回 context window。这些东西当然有用，但它们解决的是“代码长什么样”，不是“程序会怎么跑”。

这两个问题差很远。举个最简单的例子：AB 实验 ID 很少老老实实写在调用点上。它可能先定义成常量，再赋给局部变量；可能从另一个 module import 过来；也可能被包装进一个 helper method，最后才传给真正的 AB SDK。源码里你看到的是：

1

abClient.getOption(EXPERIMENT_ID)

AST 只能告诉你这里有个标识符叫 EXPERIMENT_ID。至于它的值是多少，可能在另一个文件，另一个 module，甚至经过几次变量传递之后才落到参数里。人脑可以慢慢追，Agent 也可以慢慢猜，但猜出来的东西不能当 ground truth。

源码是给人读的，bytecode 才是机器真正执行的代码。

Agent 要理解一个 JVM 系统，不能停在语法树那一层。它得越过源码，看见编译器之后的世界。

AST 是地图，bytecode 是地形

Tree-sitter 很好，但它不是静态分析。它能告诉你这里有一个函数，那里有一个调用，某个节点下面挂着某个参数。对编辑器、语法高亮、局部重构来说，这已经够了；但对 Agentic Engineering 来说，不够。因为 Agent 面对的不是一个文件，也不是一个类，而是一个长期演化的业务系统。

十年历史的 JVM 单体仓库里，真实逻辑往往不在源码表面：实验 ID 可能通过常量传递，常量可能定义在另一个 module，调用点可能藏在 helper method 后面，同一个 AB SDK 可能被封装成几层业务 API。Spring endpoint 可能来自父类注解，Jackson 字段名可能藏在 annotation 里，枚举值可能要从 bytecode 的初始化逻辑里反推。这些东西，不是 AST 上多写几个 query 就能解决的。

你当然可以让 Agent 读更多源码，但 context window 不是魔法。读得越多，token 越贵，噪声越大，结论越像“我觉得”。Agent 不缺阅读能力，缺的是可验证的结构。

Graphite 做的事情很简单：从编译后的 bytecode 构建程序图。节点是方法、字段、常量、调用点、参数、返回值；边是调用关系、数据流、类型关系、控制流、注解关系。换句话说，它把“程序真正怎么连在一起”变成一张可以查询的图。这张图不是 LLM 幻觉出来的，它来自编译器产物。

Agent 不该自己发现结构

过去我们让 Agent 干活，大部分时候是在赌一句话：“你把这些文件都读一遍，然后告诉我哪里要改。”这句话听起来很自然，但里面有个隐藏假设：Agent 必须自己发现结构。它要自己判断谁调用了谁，参数从哪里来，注解有没有继承，类型层次是什么，某个常量有没有流进目标 API。

这其实很荒谬。这些问题本来就不该交给 LLM。LLM 擅长的是语义推理，不是做确定性的图遍历。让它在几百万 token 里找调用点，就像让一个很聪明的人用肉眼翻电话簿：不是不能做，是没必要。

Graphite 的分工更干净：Agent 负责提出问题，Graphite 负责返回事实，Agent 再基于事实做判断。比如 Agent 想知道所有传给 AbClient.getOption() 的实验 ID，不需要读 500 个文件，只要查图：

1
2
3
4

MATCH (c:IntConstant)-[:DATAFLOW*]->(cs:CallSiteNode)
WHERE cs.callee_class = 'com.example.ab.AbClient'
  AND cs.callee_name = 'getOption'
RETURN c.value, cs.caller_class, cs.caller_name

结果不是“可能有这些”，而是图上确实存在这些数据流。这才是 Agentic Engineering 需要的上下文。LLM 不应该负责发现结构，它应该负责理解结构背后的意图。

6 个，还是 19 个

最早做 Graphite，是为了验证 AB 实验清理。我一开始用的还是老办法：grep、AST query、调用点搜索，一层层补 pattern。结果找到 6 个。不是这些工具没用，而是基于 pattern 的方法天然扫不全：常量换个名字，参数多传一层，调用包进 helper，pattern 就断了。后来把 bytecode 建图，从常量节点沿着数据流一路追到目标调用点，数字变成了 19。不是 6。

多出来的那些，正是 AST 很容易漏掉的地方：局部变量传递、跨 module 常量、条件分支里的间接调用。这类差异很致命。如果你只是做 code search，漏几个点无所谓；但如果你让 Agent 自动删代码、改接口、迁移框架、清理 dead code，漏掉一个点就可能是生产事故。

Agent 越能干，我们越需要确定性。这听起来有点反直觉，很多人以为模型越强，工具越不重要，实际正好相反。模型越强，越需要可靠工具把它的能力约束在事实之上。没有 Graphite 这类结构化上下文，Agent 的上限是“读了很多代码的聪明实习生”；有了它，Agent 才更像一个能随时查询系统真相的工程师。

MCP 之后，Graphite 变成 Agent 的眼睛

Graphite 最初是 CLI。你可以这样建图：

1
2
3
4
5
6

brew tap johnsonlee/tap
brew install graphite graphite-explore

graphite build app.jar -o /data/app-graph --include com.example
graphite query /data/app-graph "MATCH (n:CallSiteNode) RETURN n LIMIT 10"
graphite-explore /data/app-graph --port 8080

这已经能解决很多静态分析问题，但真正有意思的是 MCP。把 Graphite 通过 MCP 暴露给 Claude Code 或其他 Agent，Agent 就不需要把整个仓库读进 context window，而是可以直接问图：这个方法有哪些调用点？这个 endpoint 来自哪个 Controller？这个 annotation 有没有继承？这个常量最后流向了哪里？这个类型有哪些 subtype？这段 dead branch 为什么不可达？

过去 Agent 回答这些问题，要靠读源码、猜结构、拼上下文；现在它可以查图。这不是简单省 token，而是工作方式变了。以前的代码上下文是文本，以后的代码上下文是可查询的程序图。

这不是为了替代源码

我不想把话说得太满。Graphite 不会告诉你业务为什么这么设计，也不会自动判断一个实验能不能删。bytecode 再准确，也只能回答“程序结构上发生了什么”。但这恰恰是它的价值：它不抢 LLM 的活，它把 LLM 不该干的脏活拿走。

源码仍然重要，PR 仍然要 review，业务语义仍然要人和 Agent 一起判断。但在此之前，至少我们应该先知道系统真实的结构是什么。没有这一步，所有“让 Agent 理解代码”的方案，都有点像让人闭着眼摸大象：摸得越久，描述越详细，但你还是不知道它有没有摸全。

从编译器结束的地方开始

过去的软件工具链，是围绕人设计的。IDE 帮人跳转，grep 帮人搜索，AST 帮人重构，文档帮人理解。Agent 加进来之后，工具链需要变，因为 Agent 不应该像人一样读代码。人读源码，是因为人没法直接读程序结构；Agent 没这个限制。它可以调用工具，可以查询图，可以把确定性分析和概率推理组合起来。

这也是 Graphite 想做的事。不是再造一个更聪明的 grep，而是给 Agent 一张更接近真实执行语义的地图。源码是输入，bytecode 是事实，program graph 是 Agent 能用的上下文。不是把 code 塞进 context window，而是把 code 本身变成 Agent 可以查询、验证、推理的上下文。这就是“Code 即上下文”。

如果未来的工程团队里，每个 Agent 都能实时查询调用图、数据流、类型层次和注解关系，那么“理解代码”这件事本身就会被重新定义。不是读完多少文件，而是能不能问对问题，并拿到可靠答案。工具在变，工作在变，代码上下文也该变了。你还准备继续把几百万 token 的源码塞进 context window 吗？

GitHub: https://github.com/johnsonlee/graphite

Until I asked an Agent to clean up AB experiment code: it quickly found a bunch of call sites, then said, "Done." The real question was not whether the Agent could read code, but how I could prove it had not missed the 201st call site. For an Agent, context should not just be source text; code itself should become context that an Agent can query, verify, and reason about. Graphite is built for exactly this problem.

Source Code Is Not the Truth of a Program

Most "code understanding" tools today still stop at the source level. Tree-sitter parses source code into an AST. Language Servers provide symbols, references, and definitions. Embeddings turn code blocks into vectors. RAG then stuffs the relevant snippets back into the context window. All of this is useful, but it answers "what does the code look like?", not "how does the program run?"

Those are very different questions. Take a simple example: AB experiment IDs are rarely written directly at the call site. An ID might first be defined as a constant, then assigned to a local variable. It might be imported from another module. It might be wrapped in a helper method and only later passed into the real AB SDK. In the source code, you might see:

1

abClient.getOption(EXPERIMENT_ID)

The AST can tell you that there is an identifier named EXPERIMENT_ID. But what is its value? It may live in another file, another module, or only reach the argument after several variable assignments. A human can trace that slowly, and an Agent can guess through it slowly, but guessed structure cannot be ground truth.

Source code is written for humans. Bytecode is what the machine actually executes.

If an Agent needs to understand a JVM system, it cannot stop at the syntax tree. It has to cross the compiler boundary and see the world after compilation.

AST Is the Map, Bytecode Is the Terrain

Tree-sitter is good, but it is not static analysis. It can tell you that there is a function here, a call there, and an argument under some node. For editors, syntax highlighting, and local refactoring, that is enough; for Agentic Engineering, it is not. The Agent is not dealing with one file or one class. It is dealing with a long-lived business system.

In a ten-year-old JVM monorepo, the real logic often does not live on the surface of the source code. Experiment IDs may flow through constants. Constants may be defined in another module. Call sites may hide behind helper methods. The same AB SDK may be wrapped by several layers of business APIs. Spring endpoints may come from annotations on a parent class, Jackson field names may be hidden inside annotations, and enum values may have to be recovered from bytecode initialization logic. These are not problems you solve by adding a few more AST queries.

Of course you can ask the Agent to read more source code, but the context window is not magic. The more you read, the more tokens you spend, the more noise you introduce, and the more the conclusion sounds like "I think." Agents do not lack reading ability. They lack verifiable structure.

Graphite does something simple: it builds a program graph from compiled bytecode. Nodes are methods, fields, constants, call sites, arguments, and return values. Edges are call relationships, data flow, type relationships, control flow, and annotation relationships. In other words, Graphite turns "how the program is actually connected" into a graph that can be queried. That graph is not hallucinated by an LLM. It comes from compiler output.

Agents Should Not Discover Structure by Themselves

When we ask Agents to work on code today, we are often betting on one sentence: "Read all these files and tell me what needs to change." That sounds natural, but it hides an assumption: the Agent has to discover the structure by itself. It has to decide who calls whom, where an argument comes from, whether an annotation is inherited, what the type hierarchy is, and whether a constant flows into the target API.

This is absurd. These questions should not be delegated to an LLM in the first place. LLMs are good at semantic reasoning; they are not the right tool for deterministic graph traversal. Asking an LLM to find call sites across millions of tokens is like asking a very smart person to scan a phone book by eye. It can be done. It just should not be.

Graphite creates a cleaner division of labor: the Agent asks the question, Graphite returns facts, and the Agent reasons over those facts. For example, if the Agent wants to know every experiment ID passed into AbClient.getOption(), it does not need to read 500 files. It can query the graph:

1
2
3
4

MATCH (c:IntConstant)-[:DATAFLOW*]->(cs:CallSiteNode)
WHERE cs.callee_class = 'com.example.ab.AbClient'
  AND cs.callee_name = 'getOption'
RETURN c.value, cs.caller_class, cs.caller_name

The result is not "these might be relevant." The result is that these data-flow paths exist in the graph. That is the kind of context Agentic Engineering needs. The LLM should not be responsible for discovering structure. It should be responsible for understanding the intent behind structure.

6, or 19

Graphite started as a way to verify AB experiment cleanup. I began with the old tools: grep, AST queries, call-site search, and one more pattern after another. The answer was 6. The problem was not that these tools were useless. It was that pattern-based methods are incomplete by nature: rename a constant, pass an argument through one more layer, wrap the call in a helper, and the pattern breaks. Later, after building a graph from bytecode and tracing from constant nodes along data-flow edges into the target call sites, the number became 19. Not 6.

The extra cases were exactly the ones AST-level approaches tend to miss: local variable propagation, cross-module constants, and indirect calls inside conditional branches. That difference is critical. If you are only doing code search, missing a few spots may not matter. But if you ask an Agent to delete code, change interfaces, migrate frameworks, or clean up dead code automatically, one missed call site can become a production incident.

The more capable Agents become, the more determinism we need. That sounds counterintuitive: many people assume that as models get stronger, tools become less important. The opposite is true. The stronger the model, the more it needs reliable tools to ground its ability in facts. Without structured context like Graphite, the Agent's ceiling is "a smart intern who has read a lot of code." With it, the Agent becomes closer to an engineer who can query the truth of the system at any moment.

After MCP, Graphite Becomes the Agent's Eyes

Graphite started as a CLI. You can build and query a graph like this:

1
2
3
4
5
6

brew tap johnsonlee/tap
brew install graphite graphite-explore

graphite build app.jar -o /data/app-graph --include com.example
graphite query /data/app-graph "MATCH (n:CallSiteNode) RETURN n LIMIT 10"
graphite-explore /data/app-graph --port 8080

That already solves many static analysis problems, but MCP is where it gets interesting. Expose Graphite through MCP to Claude Code or another Agent, and the Agent no longer needs to load the whole repository into its context window. It can ask the graph directly: which call sites reach this method? Which Controller owns this endpoint? Is this annotation inherited? Where does this constant eventually flow? Which subtypes does this type have? Why is this dead branch unreachable?

In the past, Agents answered these questions by reading source code, guessing structure, and stitching together context. Now they can query the graph. This is not just about saving tokens; it changes the way the work happens. The old code context was text. The next code context is a queryable program graph.

This Is Not About Replacing Source Code

I do not want to overstate the claim. Graphite will not tell you why the business was designed this way. It will not automatically decide whether an experiment can be deleted. Bytecode can be precise, but it can only answer what structurally happens in the program. That is exactly its value: it does not take work away from the LLM, it removes the work the LLM should not be doing.

Source code still matters. PRs still need review. Business semantics still require humans and Agents to reason together. But before that, we should at least know the real structure of the system. Without that step, every attempt to make Agents "understand code" becomes a long, detailed description built from partial contact with the system. The description may get richer, but you still do not know whether it is complete.

Start Where the Compiler Ends

The old software toolchain was designed around humans. IDEs help humans jump around, grep helps humans search, ASTs help humans refactor, and documentation helps humans understand. Once Agents enter the workflow, the toolchain has to change, because Agents should not read code the same way humans do. Humans read source because they cannot directly read program structure. Agents do not have that limitation. They can call tools, query graphs, and combine deterministic analysis with probabilistic reasoning.

That is what Graphite is trying to do. It is not another smarter grep. It is a map for Agents that is closer to real execution semantics. Source code is input. Bytecode is fact. A program graph is context the Agent can use. Do not stuff code into a context window. Turn code itself into context the Agent can query, verify, and reason about. That is what "Code Is Context" means.

If every Agent on an engineering team could query call graphs, data flow, type hierarchies, and annotation relationships in real time, then "understanding code" would be redefined. It would no longer mean how many files you have read. It would mean whether you can ask the right questions and get reliable answers. The tools are changing. The work is changing. Code context should change too. Are you still planning to stuff millions of tokens of source code into a context window?

GitHub: https://github.com/johnsonlee/graphite

After settling the kids at the hotel, I took my wife up to The Stage Magnolia Observation Deck that night — over three hundred meters high, looking down on all of Lujiazui and the Huangpu River. The moment I stepped out the door, the city lights spread out beneath my feet like a rising tide.

I remembered: twelve years ago, I was on this same land too — except back then, I was standing on the other side of the river, looking up at these very towers.

The Shanghai We Once Tried to Conquer Together

It was 2009, just after the Spring Festival. A few of us — good brothers — boarded the train to Shanghai together.

Before I left, my mother pressed 2,800 yuan into my hand.

The K-series train car was packed beyond breathing. People everywhere — the washrooms, the aisles, the doorways — there was barely room to put your feet down. Luckily we'd managed to grab seated tickets ahead of time. Otherwise, we probably couldn't have even stretched our legs the whole way.

The Lunar New Year festivities hadn't quite faded, but the outside world still hadn't recovered from the 2008 financial crisis.

The first thing we did in Shanghai was find a place to live. We found a serviced apartment — 600 yuan per room — and three of us crammed into one. The room had a 1.3-meter-wide bed and a small desk. That was it. Three grown men sharing one bed — someone rolls over in the middle of the night and the whole bed shakes. By the small hours, someone would often get pushed right off.

Back then, we thought the hardest part was the cramped living.

Turned out the real hardship was what came after: résumés sent out, sinking like stones, vanishing without a trace. Two solid weeks. Not a single phone call.

I was the first one to get an interview. Probation pay: 2,500. Full-time: 3,000.

Right after that first interview, a second company called — offering 5,000. But the offer letter didn't come for two days. I was afraid of dragging it out, so I just went with the first one.

Back then, choices didn't come with much breathing room. A lot of decisions weren't made because you could see the future clearly.

That 50 Yuan

After I started working, my roommates still hadn't landed anything.

One of them started losing it. At first it was just tossing and turning, unable to sleep. Then it got worse — he'd mutter nonsense in that half-awake, half-dreaming state.

Luckily, our team still had an opening, and I managed to get one of them a shot. Problem was: one slot, two candidates — both my roommates qualified.

In the end, Hui stepped aside. He figured the other guy was under more pressure, so he gave up the spot.

After that, Hui never found a suitable job. His money was running out.

Before he left, the three of us had dinner together. At the table, Hui turned to the other roommate and asked to borrow 500 yuan — for the train ticket home and some pocket money.

The guy fished around in his pocket for a long while, then handed over a single 50.

The two of us froze.

Hui looked at that 50, hesitated for a moment, and put it away without a word.

After dinner, Hui asked me:

Did I not make myself clear?

I said:

No — I heard you say 500, loud and clear.

Later, Hui paid that 50 back.

From that day on, that person was no longer part of our circle.

The Years After

Everyone in that group, except Hui, eventually got an offer.

Once we'd survived those tight early days, the market bounced back from the crisis fast. Job openings sprouted everywhere. Within a year, fresh graduates were already starting at 5,000–6,000.

Life got smoother year after year. Income steadier year after year.

By any measure, this was the kind of life everyone had been fighting tooth and nail for. But once things get smooth enough, the circle around you starts to solidify. Same people every day, same topics, same routines, same sense of security. That kind of comfort is like a honey jar — the sweetness is real, but stay too long and you forget what the air outside even smells like.

I started feeling uneasy. I wanted to see what the world beyond this circle looked like — and whether I could still stand on my own without it.

After I left Shanghai, the rest of them gradually settled in — bought apartments, registered hukou. By the unspoken standard we'd all been chasing, they had taken root.

Hui was one exception — he never got his break, went home, and never came back to Shanghai.

I was a different kind of exception — I'd gotten the offer, found my footing, but I had no plan to stay.

Back then, the unspoken goal among us was the same: stay in Shanghai. Making it here was the highest mark of success.

I thought the opposite — this circle didn't need one more of me. But maybe somewhere else did.

In 2013, a friend in Beijing called and asked me to start a company with him. I went. Didn't leave with any sense of drama — left some luggage at a friend's place, packed the rest, didn't even properly say goodbye.

Hardly anyone understood why I'd give up Shanghai for a city where I had no foundation. Family thought it was reckless. Friends thought it was risky. Even I wasn't sure.

But there was one thing I was clear about: stay in one place long enough, and you'll start to mistake the small slice of world in front of you for the whole world.

Closure

About a year into Beijing, life had settled into a rhythm. It was also during that time that I met my wife.

We hadn't known each other long when the National Day holiday came around. I invited her on a "trip" to Shanghai. I called it a trip, but I had an ulterior motive — to pick up all the belongings I'd left at a friend's place.

Those bags had been there since the day I left Shanghai for Beijing. My friend had already packed them up neatly, stacked on top of the wardrobe.

I stood on a chair and pulled the suitcase down from the top of the wardrobe. It was heavier than I expected. Just as I got it out, my grip slipped — luckily my wife reacted fast and caught it before it hit the floor.

In that moment, a thought flashed through my mind: I'm going to marry this woman.

Setting the suitcase down, it suddenly struck me — five years in Shanghai, and when it came time to truly let go, it all fit in one big suitcase.

My wife and I wheeled that heavy suitcase out together, leaving behind the Shanghai we'd once tried to conquer. And with that, I'd made a clean break.

Twelve Years Later

Later, I went from Beijing to Seoul.

Of those brothers from back then, all but Hui put down roots in Shanghai. I heard from other friends that the guy who could only spare Hui that 50 yuan eventually bought a place in Shanghai too, settled down. But none of us count him in our circle anymore.

Each one of us has spent twelve years writing a different footnote on the question: stay or go.

Standing on top of the Magnolia Observation Deck this time, looking down — the feeling is hard to put into words. The distance under my feet was something I couldn't have imagined when I first arrived in 2009. The Bund is on one side, Lujiazui on the other, and the Line 2 I used to squeeze onto every morning runs right under the river beneath me.

My wife had no idea what I was thinking. She took a photo and asked, "Seen enough?"

"Seen enough," I said.

Only some things — no matter how long you look — you can never quite put into words.

Forward

On the way down, inside the sealed elevator car, geometric lines of light folded and refracted across the mirrored walls — layer upon layer, beam upon beam — as if being pulled into a black hole in the fabric of time. My thoughts wound backward with it, back to that night when three of us were crammed onto that 1.3-meter bed — one person rolls over and the whole bed shakes; somebody falls off in the middle of the night.

Back then, no one would have guessed that twelve years later, someone from that bed would be standing at the top of this city, looking down on the place he'd once struggled so hard to belong to.

No one would have guessed that a single 50 yuan note could erase a person from our lives forever.

So much of life is like this — what looks like a coincidence in the moment turns out, in hindsight, to be a fork in the road.

Shanghai is still Shanghai.

But the boys we once were are now each on their own road.

Back at the hotel, the kids were already fast asleep.

I sat on the edge of the bed for a while.

Our generation came out of small hometowns and now drifts between the world's biggest cities — where to put down roots, when to pull them up again. Each of us keeps that ledger in our own head.

Looking at the two young travelers beside me, about to set out on their own road, I felt a strange daze —

Will they have a Shanghai of their own one day?

Who will they end up sharing a 1.3-meter bed with? In which city will they pick up the phone call that changes everything? How long will they stay in their own honey jar — and one day, will they decide to walk out?

Will there be a "Hui" in their story too?

I don't know any of this.

What I do know is — their stories are theirs to walk through, on their own.

到了酒店，把孩子们安顿好，晚上带夫人去了 The Stage 玉兰观景台，三百多米的高度，俯瞰整个陆家嘴和黄浦江。出舱门的那一刻，满地的灯光像潮水一样在脚下铺开。

回想起十二年前，我也曾在这片土地上。只不过那时候，我是站在江对面，仰望着这边的塔尖。

那些年一起闯过的上海滩

2009 年，刚过完春节，我们几个好哥们，一起踏上了开往上海的火车。

临走前，母亲塞给我 2800 块钱。

K 字头的车厢里挤得密不透风，到处都是人，连洗漱间也没放过，过道里站着人，门口蹲着人，几乎没有下脚的地儿，还好我们提前抢到了坐票，不然那一路大概连腿都伸不开。

春节的年味儿还未散去，外面的世界却还没从 2008 年那块金融危机中缓过神来。

到了上海，第一件事是租房子。

哥几个找了个酒店式公寓，600 块一间，我们 3 个人凑一间住。屋里除了一张 1.3 米宽的床、一张小桌子，几乎什么都没有。3 个大小伙子挤在一张床上，谁半夜翻个身，整个床都跟着晃。睡到后半夜，经常有人被挤掉下来。

那时候我们以为，最难的是住得挤。

后来才知道，真正难的是简历投出去之后，就石沉大海，杳无音讯。连续半个月，一通电话都没接到。

我是第一个接到面试通知的。试用期 2500，转正 3000。

刚面完第一家，又接到第二家面试电话，开了 5000，只是 offer 等了两天没下来，我怕夜长梦多，索性就去了第一家。

那时候的选择，没有太多从容。很多决定，也并不是因为看得清未来。

50 块钱

我上班之后，室友们还没着落。

其中一个哥们儿开始慌了，刚开始只夜里辗转反侧、夜不能寐，后来情况越发严重，经常在半睡半醒之间胡言乱语。

好在我们团队还有空缺，我顺带也帮室友争取了一个机会。问题是岗位只有一个，候选人有两个——同住的两个室友都符合。

最后辉哥念在另一个哥们儿心理压力大，就把那个机会让了出来。

让出去之后，辉哥自己一直没找到合适的工作，身上的钱花得差不多了。

临走前，我们仨一起吃了顿饭。饭桌上，辉哥跟另一个室友说，借 500 块当回家的路费和零用钱。

那哥们儿从口袋里掏了半天，递过来一张 50。

当时我俩都愣了。

辉哥看着那张 50，迟疑了一下，也没说什么，默默收下了。

吃完饭后，辉哥问我：

是我没说清楚么？

我说：

没有啊，我听着明明说的是 500

再后来，辉哥把那 50 还了。

从那以后，我们的朋友圈里，再也没有那个人。

后来的我们

那一行人，除了辉哥，最后都熬到了 offer。

熬过最初那段紧巴的日子之后，市场也从金融危机中迅速恢复，工作机会如雨后春笋一样冒出来，才过了一年，应届毕业生 5~6K 已经是起步价。

日子就这样一年比一年顺，收入一年比一年稳。

按理说，这是当年所有人挤破头都想要的状态。 可人一旦顺到一定程度，身边的圈子也会慢慢固定下来。每天见差不多的人，聊差不多的话题，走差不多的路线，拥有差不多的安全感。那种舒适，像一个蜜罐，甜是真的甜，可待久了，人也会忘记外面的空气是什么味道。

我开始隐隐不安。想看看圈子之外的世界长什么样，也想知道，离开这个圈子之后，我还能不能立得住。

离开上海以后，他们也陆陆续续在上海安了家，落了户，按当年大家心照不宣的目标来说，算是扎根上海了。

只有辉哥是个例外——他没等到机会，回了老家，再没回过上海。

而我是另一种例外——我熬到了 offer，也站住了脚，但我没打算留下来。

那时候大家心照不宣的目标都是“留下来”——能在上海立足，比什么都强。

我当时的想法却有点反着来——这个圈子已经不缺一个我了，但别的地方也许会。

2013 年的时候，朋友在北京叫我过去一起创业，我就走了。走的时候感觉也没什么仪式感，行李寄在朋友那儿，剩下的随身带着，连告别都没怎么正式做。

身边没几个人能理解为什么放着上海不待，要去一个完全没基础的城市重新开始。家人觉得不安稳，朋友觉得冒险，连我自己心里也没底。

但我那时候想得很清楚一件事：留在原地，时间一长，你会以为眼前这点世界，就是世界的全貌。

了断

在北京待了差不多一年后，日子逐渐稳定下来，也是在那段时间，我认识了现在的夫人。

那时候我们相识不久，正好赶上十一长假。我邀请她一起去上海“旅游”。说是旅游，其实还藏着一点私心——顺道把寄在朋友那儿的家当全部带走。

那些行李，原本是我离开上海去北京时临时寄放的。朋友已经帮我打好包，整整齐齐搁在衣柜顶上。

我站在椅子上，从衣柜顶上取行李箱。箱子比预想中的重，刚拖出来，手上突然一软——好在夫人眼疾手快，顺势搭了把手，箱子才幸免于掉地上。

那一刻，我心里冒出一个念头：我要娶了她!

把箱子提下来，猛然发现，5 年下来，真正要割舍的时候，也就一个大箱子。

我和夫人推着沉沉的大箱子，一起离开了曾经闯荡过的上海滩，至此，也算是正式做了一个了断。

十二年之后

后来，从北京辗转去了首尔。

那一行兄弟，除了辉哥，全都在上海安了家。从其他朋友那儿得知，当初只愿借给辉哥那 50 块的哥们儿，后来也在上海买了房、安了家，但我们的朋友圈再也没有了这个人。

每个人都在用自己的十二年，给“留下来还是走出去”这件事写不一样的注脚。

这次站在玉兰观景台上往下看，那种感觉很难形容。脚下是当年我刚到上海时根本不敢想象的距离。江那边是外滩，江这边是陆家嘴，当年挤着上下班的二号线，沿着江底从脚下穿过去。

夫人不知道我在想什么。她拍了张照，问：“看够了吗？”

我说：“看够了。”

只有有些东西，看得再久，也说不清。

一往无前

下楼时，封闭的轿厢内，几何线条的灯光在四壁的镜面间反复折叠，一层一层、一束一束，仿佛被吸进了时空的黑洞，思绪的指针也随之倒拨，回到了当年三个人挤在那张 1.3 米床上的夜晚——谁轻轻翻一次身，整张床都跟着晃，半夜里，也常有人被挤掉下去。

那时候谁也想不到，十二年后还会站在这城市之巅，俯瞰自己当年挣扎着想要留下的地方。

也想不到当年那张 50 块钱，会让一个人从我们的生活里彻底消失。

人生很多事，当时看是偶然，回头看才发现是分岔口。

上海还是那个上海。

只是当年那群少年，已经各自走在了不同的旅途上。

回到酒店，孩子们已经睡熟了。

我在床边坐了一会儿。

我们这一代人，从老家出来，在世界的一线城市之间辗转，把根扎在哪里、又什么时候拔起再走，每个人心里都有自己的账。

看着身边这两个即将上路的少年，忽然有点恍惚——

他们也会经历自己的“上海滩”吗？

会和怎样的人凑在一张 1.3 米的床上？会在哪个城市第一次接到那通改变命运的电话？会在某个蜜罐里待多久，又会在哪一天突然决定走？

会不会也有一个属于他们的“辉哥”？

这些我都不知道。

我只知道，他们的故事，得他们自己去走一遍。

Agents write code fast. Fast without engineering excellence.

And It Doesn't Stop There

The opening list is just the surface. Dig into Agent-generated code and you'll also find:

• Cross-layer calls, facades bypassed, ViewModels reaching back into Views, Repositories calling ViewModels — unidirectional data flow turned into a spider web
• var and MutableList everywhere, setter casually added to data classes "for convenience" — the moment threads get involved, ghosts come out
• Test coverage looks great, but assertions are written as assertTrue(result != null). Run mutation testing and the score is brutal

Each one of these is an old problem. A senior would catch them at a glance. The problem is that review can't keep up — Agent output volume is several times, sometimes orders of magnitude beyond what human review can handle.

The Agent's Blind Spot Is Engineering Excellence

Blaming this on "the model isn't strong enough" is lazy. Give the same model clear constraints and good context, and it produces remarkably tidy code. Give it a vague task, and it takes the path of least resistance.

What's the path of least resistance?

• Hardcoding is closer than abstracting a constant
• throw is closer than designing an error contract
• Adding memory is closer than optimizing the algorithm
• A reverse call is closer than refactoring the data flow
• var is closer than designing a reducer
• A weak assertion is closer than thinking through edge cases

Why doesn't a senior engineer take these paths? Not because they remember the rule "don't hardcode." Because they've internalized an entire body of engineering excellence — sensitivity to long-term cost, an obsession with readability, instincts for edge cases, empathy for whoever maintains the code next. None of this is knowledge. It's a compound of taste, experience, and judgment.

The Agent has none of it. What it has is a feedback signal for "complete the current task," not an internal drive that says "this code will be maintained for ten years." Its field of view is the current task. It can't see the global cost. It doesn't know that magic number will scare every engineer who touches it three months later. It doesn't know that swallowed exception will cost two extra hours in a production incident. It doesn't know that one reverse call has just demolished the reasoning surface of the entire module. It is only accountable for "passing the tests right now," because that's the only feedback signal it has access to.

One layer deeper: Agents tend to make code look like it's working, not make the system actually healthy. A swallowed exception is the canonical case of fake health — compiles, passes tests, blows up in production.

This isn't something prompt engineering can fix. Engineering excellence is taste, not knowledge. No prompt is long enough to encode "sensitivity to long-term cost."

In our own experiments, escalating prompt tone alone — adding "please," "important," "must," "critical" — moves the needle by roughly 1%. Prompts carry task descriptions, not taste. Taste has to be externalized through harness before the Agent can act on it.

What Used to Be Best Practice Is Now a Survival Line

Over the past two decades, software engineering has accumulated a body of wisdom about code quality: unidirectional data flow, immutability, performance budgets, error contracts, architectural boundaries. In the era of human-written code, these were nice to have — having them was good, not having them was survivable, because senior engineers, code review, and post-hoc refactoring filled the gap.

Once Agents become the primary producer of code, every one of these nice-to-haves turns into a must have.

The reason is simple: human governance runs on tacit knowledge, intuition, verbal rules, and judgment calls during review. None of that scales, and none of it is consumable by an Agent. The Agent doesn't stop hardcoding because you said "no hardcoding" in a team meeting. It only responds to machine-executable constraints.

Tighter review? Human review can't keep up with Agent throughput. Doesn't scale.
Longer prompts? Treats symptoms, not causes. Whatever the prompt didn't cover, the Agent will collapse on.
Refactor later? By the time you come back, the debt is already a mountain.

There's only one real solution: take the rules that used to live in review comments and tribal knowledge, and push them forward into machine-executable harness.

The Two-Loop Harness: Fast Loop and Slow Loop

A harness isn't just a CI check. In the Agent era, a harness has to be a two-layer feedback system:

Fast Loop: Local, seconds, for self-correction

From keystroke to feedback in seconds to minutes. IDE warnings, pre-commit hooks, locally runnable lint and benchmarks — this layer serves more than just the developer, it serves the Agent.

Whether an Agent can produce maintainable code depends heavily on whether it can see the feedback at the moment of generation and self-correct. If a rule only fires in CI, the Agent finishes a round, waits ten minutes for a red light, and the feedback chain is already severed — the Agent has nothing actionable to iterate on.

Slow Loop: CI, the unified quality gate

From PR submission to merge, minutes to hours. Full static analysis, complete benchmark suites, mutation testing, architectural contract enforcement — guarantees that no rule gets quietly disabled or bypassed.

Fast Loop solves "find out early." Slow Loop solves "no escape." Both are necessary. CI without local means the feedback chain is too long and the Agent loses self-correction. Local without CI means rules get silently turned off and the harness becomes decorative.

When designing a harness, prioritize making rules locally executable. CI is the safety net, not the main battleground.

Translating Symptoms Into Harness

Back to the symptoms at the top. Each maps to a concrete set of harness mechanisms.

Hardcoding and magic numbers

Fast Loop: detekt / ktlint with IDE plugin — literal in business logic, red line immediately (whitelist: 0, 1, -1, empty string). Pre-commit hook as a backup.
Slow Loop: full static scan in CI as a merge gate.
Architectural contract: all configuration goes through a Config object, all constants live in Constants or domain enums.

The two extremes of error handling

Fast Loop: custom detekt rules — no empty catch, no "log only without rethrow," no naked throw across module boundaries.
Slow Loop: CI verifies exception chain integrity on critical paths. Every user-visible path must return a structured error, not a stack trace.
Architectural contract: a unified error model (Result/Either or a domain exception hierarchy). Errors carry trace IDs.

An exception that can be silently swallowed is, fundamentally, an exception with no owner — the root cause is the absence of an architectural contract for error handling.

Performance regression

This is the category where harness most clearly demonstrates that the precision of the constraint determines the ceiling of the output.

Fast Loop: local JMH benchmarks for every core method on critical paths. Developer makes a change, runs one command, sees the regression. Cyclomatic complexity and nested loops caught by static rules in seconds.
Slow Loop: CI runs the full benchmark suite, compares against historical baseline, blocks the PR if the regression crosses threshold. Memory footprint logged on every build, alerts on upward trend.
Architectural contract: critical paths declare a performance budget — peak memory, P99 latency, allocation rate — as numbers, not as "try to optimize."

Take Graphite as an example. It's a SootUp-based JVM bytecode static analysis tool, and every core path (call graph construction, bytecode parsing) has a corresponding JMH benchmark. Add any new feature, run one local command, and you immediately know whether the change has regressed peak memory or throughput. CI runs the full suite again as the unified gate, comparing against baseline, rejecting any merge that breaches the threshold.

This turns "performance must not regress" from a verbal agreement into a machine-verifiable hard constraint. Even if an Agent is allowed to touch core paths, it cannot silently degrade performance — because it sees the benchmark numbers in the Fast Loop itself.

Architectural contracts: unidirectional data flow + mutability

These two deserve their own section, because they're where Agents fail most often.

Unidirectional data flow is a global constraint, but the Agent only sees the local task. The shortest path to "let this button modify that state" is a reverse call — the Agent doesn't know that shortcut just demolished the reasoning surface of the entire system.

Mutability is the same story. Mutating a field is closer than constructing a new object. Adding a setter is closer than designing a reducer. The Agent always takes the closest path. But mutable state is one of the largest single sources of complexity in any system.

Fast Loop:

• Dependency direction encoded as ArchUnit unit tests, locally runnable
• Call-graph tools (like Graphite) analyze data flow locally and visualize reverse edges
• detekt rules enforce val over var, forbid public APIs from exposing MutableList / MutableMap / MutableSet
• Data classes are immutable by default; mutability requires explicit opt-in with a comment explaining why

Slow Loop: CI enforces dependency direction as architectural tests; any reverse call blocks the PR. Concurrency-critical paths scanned with concurrency-safety rules.

Unidirectional data flow and immutability aren't stylistic preferences. They're the foundation of system reasonability. A system that allows reverse calls and free-form mutation is a system whose causality is opaque even to human reviewers — let alone safe for an Agent to modify.

Inversely, a system with one-way data flow and immutable state is exceptionally Agent-friendly — its behavior is locally reasonable. The Agent modifies a function without worrying about side effects propagating across the system.

A good harness doesn't just constrain the Agent. It liberates the Agent.

Test rot

Fast Loop: assertion-strength rules surface in IDE in real time — no assertTrue(true), no empty test methods, minimum assertion count per test.
Slow Loop: CI runs mutation testing (PIT / Pitest). Mutation score becomes a gate. New code must include a failing case proving the test is meaningful.

Tests passing ≠ tests being effective. This is the most overlooked symptom, and the one Agents exploit most.

Where Harness Ends, Taste Begins

Translating verbal rules into machine-executable harness is a required course in the Agent era. But beware the opposite extreme — treating harness engineering as a universal solvent.

Step back: harness is, at its core, the externalization of human engineering excellence into contracts the Agent must obey. A senior doesn't hardcode because they've internalized sensitivity to long-term cost; harness externalizes that sensitivity into "literal in business logic blocks the PR." A senior doesn't swallow exceptions because they've internalized an obsession with system health; harness externalizes that obsession into "empty catch is a hard fail."

But part of engineering excellence cannot be externalized.

Architecture is, fundamentally, a matter of taste. "Should these two modules be merged?" "Is this abstraction premature?" "Where exactly does this boundary belong?" "This trade-off makes sense today, but will it still make sense in three years?" These questions have no static rule that can answer them. They depend on the architect's judgment about the business, the team, and the trajectory of evolution.

What harness can do is translate the artifacts of taste into machine-executable contracts. The architect decides "these two modules communicate only through an EventBus" — that's taste. ArchUnit / call-graph tools verifying that the contract isn't broken — that's harness. Taste defines the direction. Harness guards the direction.

No horse, no speed. No harness, the horse runs wild. No rider, even a perfectly steady ride is in the wrong direction. The most precise tack in the world won't help if the rider has no judgment. The most discerning rider in the world can't control the horse without tack.

What's truly scarce in the Agent era isn't engineers who can write rules. It's architects who know which parts of engineering excellence can be externalized into harness, and which must remain the rider's call. That translation capacity is itself the irreplaceable core competency.

The Architect's Role Has Changed

In the human-governance era, an architect's primary output was "design" — diagrams, documents, specifications, review comments. These outputs were for humans to read and humans, through their own engineering excellence, to enforce.

In the Agent era, an architect's primary output must be executable harness — static rules, performance budgets, architectural tests, call-graph contracts, mutability rules. Because the Agent has no engineering excellence to fall back on. The architect must externalize their own internalized engineering taste into machine-executable contracts before the Agent has anything to follow.

This isn't a downgrade. It's an upgrade. An architectural specification on a wiki affects only the people who read it. A static rule embedded in CI and IDE affects every line of code that gets generated. The leverage of harness vastly exceeds the leverage of documentation.

The items that used to live on the team's "best practices" list — unidirectional data flow, immutability, performance budgets, error contracts — used to be a matter of architectural taste. Now they're the survival line of the system. The stronger the Agent, the more critical that line becomes.

The architect's center of gravity shifts from "making good architectural decisions" to "externalizing internalized engineering excellence into harness the Agent must obey." The former is taste. The latter is engineering. Neither is dispensable: without taste, the harness itself is wrong; without engineering, even the best taste can't keep up with Agent output.

What truly determines whether a team can ride the Agent isn't how smart the Agent is. It's how much engineering excellence the team has externalized into harness.

The real moat is the product of taste and harness.

Agent 写代码快，但快得没有 engineering excellence。

不止是这些

开头列的几条只是表面。真正展开 Agent 生成的代码看，还会发现：

• 跨层调用、绕过 facade 直接访问内部实现；ViewModel 反向持有 View、Repository 调 ViewModel，单向数据流被打成蜘蛛网
• var 和 MutableList 满天飞，data class 里随手加 setter，“为了方便修改”——线程一多就出鬼
• 测试覆盖率漂亮，但断言写成 assertTrue(result != null)，mutation testing 一跑得分惨不忍睹

每一条单拎出来都是老问题，review 时一眼能看出来。问题是 review 不过来——Agent 一天产出的代码量，是人工 review 节奏的几倍甚至几十倍。

Agent 的盲区是 engineering excellence

把这些症状归因到“模型还不够强”是偷懒。同一个模型，给它清晰的约束和上下文，它能写出非常工整的代码；给它一个模糊的 task，它就走阻力最小的路。

阻力最小的路是哪条？

• 硬编码比抽象常量近
• throw 比设计错误体系近
• 加内存比优化算法近
• 反向调用比重构数据流近
• var 比设计 reducer 近
• 弱断言比想清楚边界条件近

senior 工程师为什么不会走这些路？不是因为记得“不要硬编码”这条规则，而是因为内化了一整套 engineering excellence——对长期成本的敏感、对可读性的洁癖、对边界条件的本能、对未来维护者的同理心。这些不是知识，是品味、经验、判断的复合体。

Agent 没有这些。它有的是“完成当前 task”的反馈信号，没有“这段代码会被维护十年”的内在驱动。它的视野是当前 task，看不到全局成本。它不知道这个魔法数字三个月后没人敢改，不知道这个吞掉的异常会让线上排查多花两小时，不知道这条反向调用让整个模块的可推理性瓦解。它只对眼前的“能跑过测试”负责，因为这是它能拿到的唯一反馈。

更深一层：Agent 倾向于“让代码看起来正常工作”，而不是“让系统真的健康”。吞异常是最典型的伪健康——编译过、测试过、线上炸。

这不是 prompt engineering 能补的。engineering excellence 是品味，不是知识。再长的 prompt 也写不出“对长期成本的敏感”。

我们做过实验，单纯靠语气升级——加 “please”、“important”、“must”、“critical” 这类强调词——只能带来 1% 左右的提升。 prompt 能传递的是任务描述，不是品味；品味必须通过 harness 外化，才能传给 Agent。

人治时代的“最佳实践”，在 Agent 时代是生死线

过去二十年，软件工程积累了大量关于代码质量的经验：单向数据流、不可变状态、性能预算、错误处理契约、架构边界。在人写代码的时代，这些是 nice to have——有当然好，没有也能靠 senior 的经验、code review 的人工把关、事后重构来兜底。

当代码的主要生产者从人变成 Agent，这些 nice to have 全部变成了 must have。

原因很简单：人治依赖的是隐性知识、经验直觉、口头规则、review 时的临场判断——这些东西不可扩展，也无法被 Agent 消费。Agent 不会因为你在周会上强调过“不要硬编码”就不硬编码，它只对机器可执行的约束有反应。

加强 review？人工 review 跑不过 Agent 的生成速度，这条路不可扩展。
写更详细的 prompt？治标不治本，prompt 里没覆盖的角落 Agent 一定会塌方。
事后重构？等你回头收拾，债务已经累积成山。

真正的解法只有一条：把过去靠 review 和经验把关的那些规则，前置成机器可执行的 harness。

Harness 的双层反馈：Fast Loop 与 Slow Loop

Harness 不是单一的 CI 检查那么简单。Agent 时代的 harness，必须是双层反馈系统：

Fast Loop：本地、秒级、给 Agent 自我修正用

开发者敲完代码到拿到反馈，秒级到分钟级。IDE 实时提示、pre-commit hook、本地一键跑的 lint 和 benchmark——这一层服务的不只是开发者，更是 Agent。

Agent 能不能写出可维护的代码，很大程度上取决于它能不能在生成的瞬间拿到反馈、自我修正。如果一条规则只有 CI 才能检查，Agent 写完一轮后等十分钟拿到红灯，反馈链已经断了，Agent 没法用这个信号迭代。

Slow Loop：CI、统一 quality gate、防漏网

PR 提交到合入，分钟级到小时级。承载完整的静态分析、benchmark suite、mutation testing、架构契约校验——确保任何一条规则都不会被人为关闭或绕过。

Fast Loop 解决“早知道”，Slow Loop 解决“防漏网”。两层缺一不可：只有 CI 没有本地，反馈链太长，Agent 的自我修正能力被截断；只有本地没有 CI，规则会被人为关闭，约束形同虚设。

设计 harness 的时候，优先把规则做成本地可执行的。CI 是兜底，不是主战场。

把症状逐个翻译成 Harness

回到开头列出的那组症状，每一类都对应一组具体的 harness 手段。

硬编码 / 魔法数字

Fast Loop：detekt / ktlint 配 IDE 插件，业务逻辑里出现字面量直接红线（白名单：0、1、-1、空串）；pre-commit hook 兜底。
Slow Loop：CI 跑全量静态扫描作为合入门槛。
架构契约：所有配置走 Config 对象，所有常量进 Constants 或领域枚举。

错误处理两极端

Fast Loop：自定义 detekt 规则禁止空 catch、禁止“只 log 不抛”、禁止跨模块边界裸 throw。
Slow Loop：CI 校验关键路径异常链完整性，所有用户可见路径必须返回结构化错误而非堆栈。
架构契约：定义统一错误模型（Result/Either 或领域异常体系），错误必须带 trace ID。

能被吞掉的异常，本质上是没有归属的异常——根因是错误处理没有架构契约。

Performance Regression

这是 harness 最能体现“约束精度决定生成质量上限”的一类。

Fast Loop：本地 JMH benchmark，关键路径每个核心方法都有对应的微基准，开发者改完一条命令就能看回归；圈复杂度、嵌套循环用静态规则秒级反馈。
Slow Loop：CI 跑完整 benchmark suite，对比历史 baseline，超过阈值 block PR；内存 footprint 每次 build 留痕，趋势上涨告警。
架构契约：关键路径定义性能 budget——内存峰值、P99 延迟、对象分配速率，写成数字而不是“尽量优化”。

以 Graphite 为例。它是基于 SootUp 的 JVM 字节码静态分析工具，核心路径（调用图构建、字节码解析）每个都有对应的 JMH benchmark。新增任何功能，本地一条命令跑完就知道这次改动有没有让内存峰值或吞吐量退化；CI 再跑一次完整 suite 作为统一 gate，对比 baseline，回归超阈值直接拒绝合入。

这套机制让“性能不退化”从一个口头约定，变成了机器可验证的硬约束。Agent 即使被允许动核心路径，也无法在不被察觉的情况下让性能劣化——因为 Fast Loop 阶段它自己就能看到 benchmark 数字。

架构契约：单向数据流 + Mutability

这两条值得单独拎出来，因为它们是 Agent 翻车率最高的地方。

单向数据流是一种全局约束，但 Agent 看到的是局部 task。“让这个按钮能改那个状态”的最短路径就是反向调用——它不知道这条捷径破坏了整个系统的可推理性。

Mutability 也一样。改一个字段比构造一个新对象近，加个 setter 比设计一个 reducer 近——Agent 永远走最近的那条路。但可变状态是系统复杂度的最大来源之一。

Fast Loop：

• 依赖方向用 ArchUnit 写成 unit test，本地可跑
• 调用图工具（Graphite 这类）本地分析数据流，可视化反向边
• detekt 规则强制 val over var、禁止 public API 暴露 MutableList / MutableMap / MutableSet
• data class 默认 immutable，可变需要显式 opt-in 并加注释说明

Slow Loop：CI 强制依赖方向校验作为架构测试，任何反向调用 block PR；并发关键路径用并发安全规则扫描。

单向数据流和 immutability 不是风格偏好，是系统可推理性的基础设施。一个允许反向调用、随处可变的系统，人类 review 都看不清因果，更不用说让 Agent 安全地改它。

反过来说，一个数据流单向、状态不可变的系统，对 Agent 极其友好——它的行为是局部可推理的，Agent 改一个函数，不需要担心副作用扩散到全局。

好的 harness 不仅约束了 Agent，也解放了 Agent。

测试腐化

Fast Loop：断言强度规则用静态分析 IDE 即时提示——禁止 assertTrue(true)、禁止空测试方法、断言数量下限。
Slow Loop：CI 跑 mutation testing（PIT / Pitest），mutation score 作为门槛；新增代码必须有对应的失败用例证明测试有效。

测试通过 ≠ 测试有效。这条最容易被忽视，也是 Agent 最爱钻的空子。

Harness 的尽头是品味

把口头规则升级成机器可执行的 harness，是 Agent 时代的必修课。但必须警惕另一个极端——把 harness 工程当成万能解。

往回拆：harness 的本质，是把人类工程师内化的 engineering excellence 外化成 Agent 必须遵守的契约。senior 不会硬编码，是因为内化了对长期成本的敏感；harness 把这种敏感外化成“业务逻辑里出现字面量就 block PR”。senior 不会吞异常，是因为内化了对系统健康的洁癖；harness 把这种洁癖外化成“空 catch 块直接红线”。

但有一部分 engineering excellence 是外化不出来的。

架构本质上是一种品味。“这两个模块该不该合并”、“这个抽象是不是过早了”、“这个边界划在哪里更合理”、“这个 trade-off 现在合理三年后是否还合理”——这些问题没有静态规则能回答，它们依赖架构师对业务、对团队、对未来演化的综合判断。

Harness 能做的，是把品味的产物翻译成机器可执行的契约。架构师决定“这两个模块之间只能通过 EventBus 通信”，这是品味；ArchUnit / 调用图工具校验这条契约是否被破坏，这是 harness。品味定义方向，harness 守护方向。

没有马，跑不快；没有 harness，马会乱跑；没有骑手，跑得再稳也是错方向。马具再精密，骑手没判断，照样跑偏；骑手再有判断，没有马具，控制不住马。

Agent 时代真正稀缺的，不是会写规则的人，是知道哪些 engineering excellence 能外化成 harness、哪些必须留作骑手判断的架构师。这个翻译能力本身，就是不可替代的核心能力。

架构师的角色变了

人治时代，架构师的核心产出是“设计”——架构图、文档、规范、review 意见。这些产出是给人看的，靠人的 engineering excellence 去落地。

Agent 时代，架构师的核心产出必须是可执行的 harness——静态规则、性能 budget、架构测试、调用图契约、mutability 规则。因为 Agent 没有 engineering excellence，它落不了地。架构师必须把自己内化的工程品味，外化成机器可执行的契约，Agent 才能照着跑。

这不是降级，是升级。一个写在 wiki 上的架构规范，影响的是看过它的人；一条嵌入 CI 和 IDE 的静态规则，影响的是每一行被生成的代码。Harness 的杠杆远大于文档的杠杆。

那些过去被列在“团队最佳实践”清单上的条目——单向数据流、immutability、性能 budget、错误契约——曾经是架构师的品味，现在是系统的生死线。Agent 越强，这条线越重要。

架构师的工作重心从“做出好的架构决策”转向“把内化的 engineering excellence 外化成 Agent 必须遵守的 harness”。前者是品味，后者是工程。两者缺一不可：没有品味，harness 本身就是错的；没有工程，再好的品味也跑不过 Agent 的生成速度。

真正决定一个团队能不能驾驭 Agent 的，不是 Agent 多聪明，而是这个团队有多少 engineering excellence 被外化成了 harness。

而真正的护城河，是品味和 harness 的乘积。

Each round, you pick the best sample. But when best hasn't passed yet, what do you do next round?

Option A: use best as the base, evolve all samples from it.
Option B: keep each sample on its own lineage. Best influences nobody.

A feels obvious — stand on the shoulders of giants, why start over? That intuition is wrong, and the cost of being wrong is bigger than you think.

But before tearing A apart, one thing has to be said up front.

Look at the task shape first

Strategy choice isn't universal. It's task-dependent.

If your task is unimodal — say, a high-dimensional boolean coverage grid where the goal is to flip a bunch of flags to 1 — then A is fine. Unimodal means there's only one direction toward the optimum. "Evolve from current best" is just walking straight uphill. Diversity is waste.

But if your task is multimodal — generating code, writing strategies, designing architecture — then the fitness landscape has multiple basins scattered across it. You don't know which basin contains your current best, and you definitely don't know whether that basin contains the global optimum. In this regime, A is a disaster.

Step one is always identifying which landscape you're on. Get this wrong and the rest of the discussion is empty.

Everything below assumes a multimodal task. AI agent evolution, LLM-based systems, open-ended problem solving — these are all multimodal by default. If you're certain your task is unimodal, you can close this post.

Propagating best is a genetic bottleneck

Copying best to all samples compresses your entire population's gene pool down to one individual. In genetics this is called a genetic bottleneck. In nature, it usually happens at the edge of extinction.

Cheetahs went through a severe one. All living cheetahs today share so much genetic material they're essentially clones, which makes the species catastrophically vulnerable to disease. One epidemic could end them.

This isn't a metaphor. It's a structural isomorphism. When your population gets reset to one individual's genes every generation, you are actively building a cheetah population.

Worse: nature never does this. Even the fittest individuals don't have all-cloned offspring. Sexual reproduction is itself an anti-best-takes-all mechanism, forcing recombination to maintain diversity. The evolutionary pressure is simple: environments change. Today's best is tomorrow's worst.

Dinosaurs were the optimum, every moment, for 160 million years.

Eval noise gets amplified

Set biology aside. Back to engineering.

Best is best because it scored highest under the current eval. But eval can be wrong — it might miss a dimension, capture spurious correlation, or just be noisy.

If eval is noisy, best might just be the most-overrated sample. Copying it to the next generation means you're no longer optimizing the real objective — you're optimizing eval's current proxy.

This is the entry point for Goodhart's Law. When a measure becomes the target, it stops being a good measure.

Recent research on LLM self-distillation makes this concrete. Self-distillation works well on small, homogeneous task sets. But when task coverage broadens — say, switching from chemistry to math — the same compression that helped now hurts the model's ability to recover or adapt to unseen structures.

The mechanism is sharper than it sounds. Self-distillation aggressively removes epistemic markers — tokens like "wait", "hmm", "perhaps", "maybe". These aren't filler. They're functional computational steps the model uses to maintain alternative hypotheses and gradually resolve uncertainty.

Strip them away, and out-of-distribution performance can drop by up to 40%.

Translate this back to evolution: when you use "best for all", best's confidence gets copied to every descendant. The population loses the ability to say "I'm not sure" — and with it, the ability to back out of a wrong direction.

Independent evolution is the antidote to Goodhart

So the better choice is independent evolution. Each lineage goes its own way. Best influences no one.

It looks inefficient. But it does something best-sharing cannot: preserve multiple basins as live possibilities.

The fitness landscape in AI agent evolution is almost certainly multi-modal. You don't know which basin contains your current best, and you definitely don't know whether that basin contains the global optimum. Multiple independent lineages mean you're digging in multiple basins at once. Even if only one strikes gold, the system wins.

This idea has a name in evolutionary algorithms — the island model. Multiple subpopulations evolve in geographic isolation. Sometimes they end up as different species entirely.

But the deeper reason isn't algorithmic. It's epistemological.

If your eval can be wrong (and it will be, only the magnitude varies), then "evolve from current best" hardcodes today's epistemic error into tomorrow. Independent evolution preserves the option for later calibration to overturn that judgment. It's not a performance optimization. It's leaving the system a path to take it back.

There's an invariant underneath this that shouldn't be broken: Centralize feedback, decentralize exploration.

Centralize feedback — the global best, the archive, eval signals — these are the source of convergence. They must be shared. Decentralize exploration — the actual evolution paths, sampling directions, how each lineage interprets the archive — these are the source of diversity. They must stay independent.

Mix these two up and you pay a heavy price. Centralize exploration, and the system loses its ability to find the global optimum — everyone sprints toward the same local one. Decentralize feedback, and the system loses its ability to converge — every lineage wanders blind.

Every engineering decision below — how to preseed, how to use the archive, how to prune — is a concrete instantiation of this invariant.

But independent evolution has its own trap

So far this might sound like a free lunch. It isn't.

The biggest trap is silent homogenization.

If all your lineages share the same initial prompt, the same base model, the same eval rubric, their "independence" is cosmetic. They get pulled by the same attractors — like birds that look like they're flying independently but are all riding the same wind.

LLM-based agents make this much worse. LLMs have strong mode collapse tendencies. Give the same context, different lineages produce remarkably similar reasoning. What you see as "many lineages" might be one lineage in behavior space.

Even more insidious: you might think you've preserved diversity by varying random seeds. But all outputs still cluster in the base model's high-likelihood region. The Verbalized Sampling paper traces the root cause — LLM mode collapse is fundamentally driven by typicality bias in human preference data. That bias is baked into the base model. Sampling temperature can't undo it.

Independent evolution without other safeguards degrades into "looks independent, actually parallel runs of the same evolution".

Diversity must be observable

The most counterintuitive thing about independent evolution: its slowness is visible.

Any single lineage looks slower than the best-sharing alternative. If you're only watching the best-score curve, you'll keep second-guessing yourself, and eventually drift back to best-sharing.

The only way out is to make diversity a first-class signal. Behavioral distance between lineages, population entropy, basin coverage estimates — these need to sit alongside best score, not below it. "Diversity is rising" must be as visible as "score is rising".

Subtle distinction here: diversity is not randomness.

Adding noise to "preserve diversity" floods your population with low-quality variants and leaves the actual directional space underexplored. That's pseudo-diversity. What matters is meaningful difference: different problem-solving strategies, different abstraction levels, different trade-off choices — not perturbed copies of the same solution.

Defining "are these two samples really different?" might be harder than designing eval itself. This is an open engineering problem.

Pruning needs restraint

Independent evolution will produce many "looks bad but secretly cooking" lineages — low scores early, but on the right path, just slow to bloom.

Aggressive early stopping kills these late bloomers. But how do you tell "actual dead end" from "hasn't paid off yet"? There's no cheap answer.

A workable approach: keep elimination thresholds loose, and add a resurrection mechanism. Paused lineages keep their checkpoints. If later calibration shows their direction was right after all, reactivate them.

The underlying lesson: don't let valuable old states disappear without you noticing.

Inject difference actively, don't wait for it

Not pruning aggressively isn't enough. If the population naturally collapses toward a few similar directions, just keeping them around won't save you.

Island-model and deme-based GA literature has two well-tested mechanisms that drop in cleanly here.

preseed worst

Periodically replace the worst-performing lineage with a preset seed — could come from the historical archive (samples that took different paths but got pruned), or from hand-constructed initial states that explicitly target different basins.

This is targeted difference injection. Not random noise — known difference. It echoes the earlier point about pseudo-diversity: anyone can add noise; the hard part is adding noise with direction.

For LLM-based evolution, preseeds could be prompts in different reasoning styles, samples drawn at different temperatures, even outputs from different base models. The point is that the difference between seeds is structural, not statistical fluctuation.

restart worst deme

Wipe the worst-performing deme entirely and restart with random or perturbed state.

This targets a different failure mode: not "this individual is weak" but "this whole direction is dead". When a deme is collectively stuck in a local optimum, keeping it alive is just compute waste — better to free up capacity for fresh exploration.

The cost of restart is visible (you lose generations of accumulated state). The benefit is compute reallocation. Under fixed compute, holding space for dead directions denies live directions the chance to get more resources.

They solve different problems

preseed addresses "not enough diversity". restart addresses "compute locked in dead directions".

preseed without restart: the worst lineage keeps getting reseeded, but total population capacity never frees up — you're watering the wasted direction harder.

restart without preseed: new demes spawn from the same initial distribution, with high probability of hitting the same attractor — you're periodically redoing the same mistake.

Both together form a closed loop: preseed ensures the new blood is actually new, restart ensures it has room to grow.

What's best for, then?

Naturally, you ask: if best can't be used to reproduce, what's it good for?

First, as a reference signal. Each lineage can see best's score and key features without inheriting its structure. Like the archive in NSGA-II — preserved, not propagated.

Second, as a trigger. If best fails to pass for N rounds, that's the signal that calibration should intervene — maybe the eval criteria themselves need rethinking, not more rounds of evolution.

Third, as diagnostic. When best doesn't pass, analyzing "which dimension is it weak in" matters more than "what does it look like". That gap information feeds back into refining the eval rules.

But this immediately raises a new question: if archive is queryable by lineages, and all lineages see the same archive, doesn't their "independent thinking" still get correlated?

Probably yes.

So should archive become "query on demand" — only consulted when a lineage decides it needs to? Should "when to consult archive" become an evolvable meta-capability? Should different lineages get different archive views?

I don't have answers right now.

Questions I'm leaving for myself

When I started thinking about this, I assumed "independent evolution vs share best" was a binary switch. It isn't, not even close.

The questions below are ones I'm deliberately not deciding — not ones I overlooked. The distinction matters. Deliberate hold means I see this as an open space that needs real running data to converge. Oversight means I didn't see it was a question at all. The first is intentional design. The second is a bug.

The real questions are:

• What does "independent" actually mean? Genetic independence (no shared base)? Informational independence (no shared archive)? Or behavioral independence (not pulled by the same attractors)?
• How do you measure diversity? Not output diff — behavioral distance. But how do you compute behavioral distance?
• When the base model itself has mode collapse tendencies, does lineage-level "independence" mean anything? Or do you have to start with base model diversification?
• Is the role of calibration being underestimated? Under independent evolution, no centralized "pick best to reproduce" decision exists — that authority is delegated to each lineage's local eval. Should calibration now also be responsible for detecting which lineage's local eval has drifted?

No standard answers, and forcing answers without running data would be the wrong move. But one thing's certain: any moment that feels "simple, just copy best" is Goodhart knocking on the door.

Evolution isn't optimization. It's preserving possibilities under uncertainty. The moment you trade diversity for efficiency, you win this generation and lose every future one.

Worth it?

每一轮挑出 best sample，但 best 还没 pass 的时候，下一轮怎么办？

方案 A：把 best 作为下一轮的 base，所有 sample 基于 best 继续进化。
方案 B：每个 sample 保持独立 lineage，best 不影响任何人。

A 看起来天经地义——站在巨人肩膀上，没理由从头来过。这个直觉是错的，错的代价比你想象的大。

但在拆 A 之前，必须先讲清楚一件事。

先看任务的形状

策略选择不是普世问题，是任务相关的。

如果你的任务是单峰的——比如高维布尔覆盖网格，目标是把一堆 flag 全部置 1——那 A 没毛病。单峰意味着只有一个最优解所在的方向，"基于当前 best 推进"就是直接朝山顶走，多样性是浪费。

但如果你的任务是多峰的——比如生成代码、写策略、设计架构——那 fitness landscape 上分布着多个 basin，你不知道当前 best 在哪个 basin，更不知道这个 basin 是不是全局最优所在的那个。这种情况下 A 是灾难。

第一步永远是判断你在哪种 landscape 上。判断错了，后面所有讨论都是空的。

下面所有论证默认你是在多峰任务上。AI agent 进化、LLM-based 系统、开放式问题求解——基本都是多峰的。如果你确定自己在做单峰任务，可以关掉这篇文章了。

best 的传播是一种基因瓶颈

把 best 复制给所有 sample，本质上是把整个 population 的基因池压缩到一个个体。遗传学里这叫 genetic bottleneck，自然界中通常发生在物种灭绝边缘。

猎豹经历过严重的基因瓶颈，今天所有现存个体的基因相似度高到像克隆，导致整个物种对疾病极度脆弱——一场流行病就可能让它们全部灭绝。

这不是个比喻，是结构上的同构。当你的 population 在每一代都被一个个体的基因重置，你就是在主动制造一个猎豹种群。

更要命的是，自然界从不采用这种策略。即使是最适应的个体也不会让所有后代都是它的克隆。性别繁殖本身就是反 best-takes-all 的机制，强制基因重组以维持多样性。背后的进化压力很简单：环境会变，今天的 best 可能是明天的 worst。

恐龙就是经典反例。在它们存在的 1.6 亿年里，每一个时刻都是当时最优解。

eval 信号的噪声会被放大

放下生物学，回到工程。

best 之所以是 best，是因为它在当前 eval 标准下分数最高。但 eval 本身可能错——它可能漏掉了某个维度，可能引入了 spurious correlation，可能就是噪声大。

如果 eval 信号有噪声，best 可能只是"被高估的样本"。把它复制到下一代，意味着你不是在优化真实目标，你是在优化"eval 当前的 proxy"。

这就是 Goodhart's Law 的入口。当 measure 变成 target，measure 就不再是好的 measure。

最近一篇研究 LLM 自蒸馏的论文给出了实证支持。研究者发现，self-distillation 在小而同质的任务集上效果显著，但当任务覆盖变广（比如从化学切换到数学），自蒸馏对不确定性的压制反而损害了模型恢复或适应未见结构的能力。

更具体的机制：self-distillation 会激进地移除 epistemic markers——那些 "wait"、"hmm"、"perhaps"、"maybe" 这类表达不确定性的 token。这些 token 不是冗余，它们是模型用来维持替代假设、逐步收敛不确定性的功能性计算步骤。

被剥离这些机制后，模型在 out-of-distribution 任务上的表现下降高达 40%。

把这个翻译回进化系统：当你用"best 给所有"的策略时，best 的"自信"被复制给了所有后代。population 失去了表达"我不确定"的能力，也就失去了在错误方向上回头的能力。

独立进化是 Goodhart 的解药

所以更好的选择是独立进化——每个 lineage 各走各路，best 不影响任何人。

这看起来低效，但它在做一件 best-sharing 做不到的事：保留多个 basin 的可能性。

fitness landscape 在 AI agent 进化里几乎一定是高度多峰的。你不知道当前的 best 处在哪个 basin，更不知道这个 basin 是不是全局最优所在的那个。多个独立 lineage 等于在不同的 basin 里同时挖坑，哪怕只有一个最终挖到金子，整个系统也是赢的。

这种思路在 evolutionary algorithms 里早有名字——island model，多个亚种群地理隔离独立演化，最终可能演化出完全不同的物种。

但更深的理由不是算法层面，是认识论层面。

如果你的 eval 可能错（它一定会错，只是程度问题），那么"基于当前 best 推进"等于把当前的认知错误硬编码进未来。独立进化保留了让后续校准时推翻当前判断的可能性。这不是性能优化，是给系统留一条后悔的路。

这背后有一条不应该被破坏的不变量：Centralize feedback, decentralize exploration。

反馈集中——全局 best、archive、eval 信号，这些是收敛性的来源，必须共享。探索分散——具体的演化路径、采样的方向、对 archive 的解读，这些是多样性的来源，必须独立。

把这两件事搞混的代价非常大：反馈不集中，系统失去收敛能力，每个 lineage 各自瞎走；探索不分散，系统失去找到全局最优的可能性，全员朝同一个 local optimum 冲刺。

后面所有的工程决策——preseed 怎么做、archive 怎么用、淘汰怎么定——都是这条不变量的具体落地。

但独立进化有它自己的陷阱

讲到这里，看起来独立进化是免费的午餐。不是。

最大的陷阱叫隐性同质化。

如果你的所有 lineage 共享同一个初始 prompt、同一个 base model、同一份 eval 规则，它们的"独立"只是表面的。实际上它们会被相同的 attractor 拉向同一个区域——就像几只看起来独立飞行的鸟，其实都被同一阵风吹着。

LLM-based agent 上这个问题尤其严重。LLM 本身有强烈的 mode collapse 倾向——给同样的上下文，不同 lineage 的 reasoning 会高度相似。你看到的"多个 lineage"，可能在 behavior space 上其实只有一个。

更隐蔽的情况是：你以为通过引入随机种子保住了多样性，但所有 lineage 的输出仍然集中在 base model 的 high-likelihood region。Verbalized Sampling 那篇论文揭示了根源——LLM 的 mode collapse 根本上由人类偏好数据中的 "typicality bias" 驱动。这种 bias 已经烤进了 base model，单纯靠采样温度调不出来。

所以"独立进化"如果不配套其他机制，会退化成"看起来独立、其实并行的同一个进化"。

多样性必须可观测

独立进化最违反直觉的一点是：它的"慢"是肉眼可见的。

任何一个 lineage 单独看，都不如共享 best 的方案进步快。如果你只盯着 best score 曲线，会反复怀疑自己的选择，最终回到 best-sharing。

唯一的应对是把多样性作为一等公民暴露出来。lineage 之间的 behavioral distance、population entropy、basin coverage 估计——这些必须和 best score 并列展示，让"多样性在涨"成为和"分数在涨"同等重要的信号。

这里有个微妙的区分：多样性不等于随机性。

为了保多样性而引入大量噪声，结果 population 里大部分是低质量噪音样本，有效的"不同方向"反而很少——这是一种伪多样性。真正要保的是有意义的差异：不同的解题策略、不同的抽象层次、不同的 trade-off 选择，而不是同一个解的扰动版本。

判断"这两个 sample 是不是真的不同"，可能比 eval 本身还难设计。这是个未解的工程问题。

淘汰机制要克制

独立进化下，会出现大量"看起来很烂但其实在憋大招"的 lineage——它们前期分数低，但走的方向其实是对的，只是需要更多代才能开花。

aggressive early stopping 会杀掉这些 late bloomer。但你怎么区分"真的是 dead end"和"暂时没出成果"？这个问题没有便宜的答案。

可行的做法是把淘汰阈值设得宽松，并引入"复活机制"：被暂停的 lineage 保留 checkpoint，未来校准之后如果发现它的方向其实对，可以重新激活。

底层教训是：不要让有价值的旧状态在你不知道的情况下消失。

主动注入差异，而不是被动等待多样性

光"不淘汰"还不够。如果 population 自然塌缩到几个相似的方向，光保留它们也救不回来。

island model / deme-based GA 里有两个对应的成熟做法，可以直接搬过来。

preseed worst

定期把表现最差的 lineage 替换成一个预设种子——可能来自历史 archive 里被淘汰但走过不同方向的样本，可能来自人工构造的、明确不同 basin 的初始状态。

这是定向注入差异。不是引入随机噪声，而是引入已知的不同。和"伪多样性"那节呼应：noise 谁都能给，难的是给得有方向。

具体到 LLM-based 进化，preseed 可以是不同 reasoning 风格的种子 prompt、不同温度采样的样本、甚至不同 base model 的输出。关键是这些种子之间的差异是结构性的，不是统计涨落。

restart worst deme

把表现最差的 deme（亚种群）整体清零，用随机或扰动状态重启。

这针对的不是"个体不行"，而是"整个方向不行"。当一个 deme 已经集体陷在 local optimum 里，再保留它只是浪费算力——还不如让位给新的探索。

restart 的成本是显性的（损失了几代积累），但它的收益是算力配置的再平衡。固定算力下，给死掉的方向留位置，等于剥夺了活的方向获得更多资源的机会。

两者解决的不是同一个问题

preseed 解决的是"diversity 不够"。restart 解决的是"算力锁死"。

如果只 preseed 不 restart，最差的 lineage 不停被换种，但整个 population 的 capacity 没腾出来——你只是在浪费的方向上不停浇水。

如果只 restart 不 preseed，新生成的 deme 仍然来自同样的初始分布，撞进同一个 attractor 的概率很高——你只是周期性地把同一个错误重做了一遍。

两者配套使用，才能形成闭环：preseed 保证新血是真的"新"，restart 保证新血有空间长出来。

best 在独立进化下还有用吗

讨论到这里，自然会问：既然 best 不能用来繁衍，它还有什么价值？

第一个用法是参考信号。每个 lineage 进化时可以"看到"当前 best 的分数和关键特征，但不继承其结构。类似 NSGA-II 里的 archive——保留但不污染 population。

第二个用法是 trigger。如果 best 连续 N 轮没 pass，这本身就是该介入校准的信号——可能 eval 标准本身需要重新审视，而不是再多进化几轮。

第三个用法是诊断。best 没 pass 时，分析它"差在哪个维度"比"它是什么样子"更有价值，这个 gap 信息可以喂回 eval 规则的细化。

但这里立刻冒出新问题：如果 archive 是 lineage 可以查询的，所有 lineage 看到同一份 archive，会不会还是导致"独立思考"高度相关化？

答案大概率是会的。

那要不要让 archive 变成"按需查询"——只有 lineage 自己判断需要时才去看？要不要让"什么时候查 archive"本身成为可演化的元能力？要不要给不同 lineage 分配不同的 archive view？

我现在没有答案。

留给自己的问题

一开始我以为"独立进化 vs 共享 best"是一个二选一的开关。讨论到这里发现远远不是。

下面这些问题我是故意没决定的，不是疏忽。区别很重要——故意未决意味着我意识到了这是个开放空间，需要等真实运行数据来收敛；疏忽未决意味着我根本没看到这是个问题。前者是 deliberate hold，后者是 bug。

真正的问题是：

• 你怎么定义"独立"？基因独立（不共享 base）？信息独立（不共享 archive）？还是行为独立（不被相同 attractor 拉走）？
• 你怎么测量多样性？不是输出 diff，而是 behavioral distance——但 behavioral distance 怎么算？
• 当 base model 本身就有 mode collapse 倾向时，lineage 层面的"独立"还有意义吗？还是说必须从 base model 多样化做起？
• 校准机制的角色是不是被低估了？独立进化下不再做"选 best 来繁衍"这种集中决策，权力下放给了每个 lineage 的 local eval——校准是否需要负责发现"哪些 lineage 的 local eval 已经偏了"？

这些问题没有标准答案，也不应该在没有运行数据的时候硬给答案。但有一点可以确定：任何让你觉得"很简单，复制 best 就行了"的瞬间，都是 Goodhart 在敲门。

进化不是优化，是在不确定的环境里保留可能性。当你为了效率牺牲多样性的那一刻，你赢了眼前的这一代，输的是所有未来的代。

值得吗？

SSD 的逻辑很直接：多 sample，选最优。但在一个结构化输出的场景下，我撞到了一个看起来小、实际上很深的问题——“最优” sample 在关键 section 上往往不是最强的。

问题是什么

场景是 planning——agent 根据需求产出一个结构化的 plan，里面有几个 section。SSD 跑 N 次，每个 sample 得到一个 scalar score，取 top-1。

打开 per-section 的分数看：

• Sample A：section 1 得 90、section 2 得 70、section 3 得 80
• Sample B：section 1 得 80、section 2 得 85、section 3 得 75
• Sample C：section 1 得 95、section 2 得 60、section 3 得 85

三个 sample 的总分非常接近。但没有任何一个在所有 section 上最强。 argmax 选出来的那个，在某些 section 上其实有明显短板。

最朴素的解法是跨 sample 拼接——每个 section 挑各 sample 里最强的那份拼起来。

想过之后，不成立。section 之间有语义耦合：后面的 section 引用、依赖前面 section 里的判断。跨 sample 拼接会破坏单个 sample 内部原本自然形成的一致性，结果是结构合法、语义错配。

拼接这条路走不通，真问题浮出水面：怎么让 SSD 产出的那个 top-1，真的是全面最优的 sample？

错方向之一：用 token 数当 effort 的 proxy

一个直觉反应是：如果某 section 的 token 少，说明 agent 没在上面花力气，应该打低分。

这个想法在 LLM 身上是错的，而且错得很典型。

Token 消耗衡量的是 verbosity，不是 effort。LLM 在“想得深”的时候输出未必长——一个精确的架构理解可能 50 个 token 就讲清核心。而“想得浅”时 LLM 反而更容易产出长——它会填充、列举、加限定词，因为在没有 strong insight 时，fluency 会自动把字数堆起来。RLHF 还给了模型一个 verbose bias——更长的回答常常被打更高分。

Token 数和思考深度的相关系数，在 LLM 上可能接近零甚至为负。

把 token 作为打分 signal 的后果是可预测的 Goodhart：生成过程学到的是写得更长，而不是想得更深。精确的判断被稀释成可能性枚举，核心结论被埋在大段限定和铺陈里。外观更饱满，实质更差。

错方向之二：推理深度

意识到 token 的问题后，下一个想法是——那用推理深度呢？CoT 长度、推理步骤数、概念密度。

这个方向比 token 好一些——它至少指向了一个真正该测的东西。但更危险，因为它更难测，更容易自欺。

核心事实：LLM 没有“推理深度”的物理对应物。

CoT 写出来的 "step 1, step 2, step 3" 不保证对应任何 discrete 推理过程。已经有 paper 证实模型可以直接生成答案、再编造一个 self-consistent 的 CoT 作为事后解释。网络的前向传递深度对每个 token 都是一样的，所谓“深度”是一个 anthropomorphic projection。

更严重的是，任何你定义的“深度 proxy”，agent 都能学会生成满足 proxy 的表面特征：

• 拆成更多小步骤 → 每步几乎无信息量，但计数多
• 往 CoT 里塞 entity → entity 被列出，但不参与推理
• 让 CoT 和最终输出 self-consistent → 两者都肤浅但互相印证

Gaming 一个“推理深度”的 proxy，产出来的东西看起来就像深度推理。这比 token-gaming 更阴险。

想测“深度”这个方向本身就是个陷阱。在一个不存在的量上找 proxy，不论找什么都会是错的。

真正的方向是 grounding 不是 effort

把 "effort" 这个 framing 彻底扔掉，换一个问题：除了 verifier 的 scalar score，还有什么 deterministic 信号可以用来交叉验证 sample 的质量？

这个问题有一个干净的答案——基于真实环境的 grounding。

planning 涉及的“真实环境”是 codebase。如果你能用 static analysis 拿到 call graph，那对 plan 里所有涉及代码结构的判断，你有了一个独立于 verifier 的 deterministic 判据：plan 引用的 entity 是否真的存在、依赖关系是否对得上、变更的传递影响是否被识别完整。

这些问题都是 structural facts，答案完全 deterministic，不依赖任何主观判断。

这给了你 per-section 的第二条 signal。和 verifier 的 scalar score 独立。

两个 signal 独立这件事本身就是 information。当两者一致——verifier 说 sample A 最好、grounding 也说 sample A 在所有 section 上 grounded 得最深——这个“最好”是真的。当两者冲突——verifier 选了 A，但 grounding 显示 A 在 section 1 上比 B 差一大截——这个冲突暴露的是 verifier 可能在被 gaming 或者信号不够细。

但不要用 grounding 替代 selection

这里有一个关键判断：grounding signal 的正确用法不是加进 verifier score 做新的 scalar argmax。

两个原因。

一、grounding 只覆盖 plan 里涉及代码结构的部分。那些不涉及结构的 section，grounding 沉默。如果 grounding 成为 selection 主 signal，这些盲区的质量会从 signal 里消失——agent 会学到“只要 grounded 的部分强，其他无所谓”。新的 Goodhart，换了位置而已。

二、把 grounding 和 verifier 合成一个 scalar 会丢失两种 signal 的独立性。两者本来衡量的是不同维度——verifier 看“plan 是否 well-formed”，grounding 看“plan 和 real code 对接正确度”。独立的两个轴比一个加权和提供的信息多得多。

所以正确的用法是：grounding 作为 diagnostic layer，不是 gatekeeper。

具体工作方式：

1. SSD 跑完，按 verifier scalar 选 top-1——这一步不变
2. 对所有 N 个 sample，额外跑 grounding-based per-section scoring
3. 对比 top-1 的 per-section grounding 分数和各 section 的最高分
4. 如果 top-1 在某 section 上显著低于该 section 的最高分——记录这个 gap
5. gap 不改变当前 selection，作为独立 signal 留下来
6. 长期目标：让 SSD 下一轮的 top-1 在每个 section 的 grounding 分数上都接近 sample 集合的最高分

selection 机制不变，保持简单。grounding 是 observer，不是 judge。gap 引发的是 signal，不是 selection 回滚。

优化目标从“最大化 verifier scalar”升级为“最大化 verifier scalar 且 grounding-per-section 无显著 gap”。

signal 形状决定生成方向

这是最关键的问题。signal 的形状决定了 sample 会朝哪个方向集中。

当前的 scalar argmax，鼓励的模式是“把总分拉高”——生成过程会优先在容易拿分的 section 投入，难拿分的 section 保持基础水平，因为边际收益这么算最优。

加了 grounding-based gap signal 之后，鼓励的模式是“每个 section 都不要被其他 sample 甩开”。这个目标函数更接近“全面最优”，而不是“总分最优”。

Gaming 这个 signal 需要什么？要想在 grounding 分数上不被甩开，sample 得真的引用更多真实存在的代码结构、真的覆盖更多真实存在的依赖路径——而这些是 static analysis 验证的，编不了。

gaming 策略和真实质量提升在这里是同一件事——没有分叉。

回到更大的问题

这个 SSD selection 的具体问题底下，是一个更大的方法论问题。

Self-improvement 系统的核心风险从来不是“能力不够”，是“signal 结构错了，生成过程被错误的 signal 引向错误的方向”。scalar 总分、token 数、推理深度——它们失败的方式都是同一个：把一个高维质量问题压缩成低维数字，然后在那个低维数字上做 optimization。

真正的出路是反过来——保持 signal 的高维结构，让 deterministic 的多源信号互相 check，而不是合成一个标量。

Grounding 之所以是正确答案，不是因为它比其他 signal “更好”。是因为它是独立的、deterministic 的、难以 gaming 的第二根轴。两根独立的硬轴永远强于一根加权的软轴。

这个原则不限于 planning。任何 self-improvement 系统，只要你打算 autonomous 地评估产物质量，就必须问自己：我的 verifier 的 grounding 在哪里？它和我其他 signal 相关还是独立？

相关的话，全是假的冗余。独立的才是真的 check。

SSD's logic is simple: sample many, pick the best. But in a structured-output setting, I ran into a problem that looks small and turns out to be deep—the "best" sample is often not the strongest on the sections that matter.

The Problem

The setting is planning—an agent produces a structured plan made of several sections. Run SSD with N samples, each gets a scalar score, take the top-1.

Open up the per-section scores:

• Sample A: section 1 scores 90, section 2 scores 70, section 3 scores 80
• Sample B: section 1 scores 80, section 2 scores 85, section 3 scores 75
• Sample C: section 1 scores 95, section 2 scores 60, section 3 scores 85

The totals are close. But no sample is strongest on every section. Whichever one argmax picks, it has a clear weakness somewhere.

The naive fix is to splice across samples—take the strongest section from each, stitch them together.

Doesn't work. Sections are semantically coupled: later sections reference and depend on judgments made in earlier ones. Splicing across samples breaks the internal consistency each individual sample naturally maintained. The result is structurally legal, semantically broken.

With splicing ruled out, the real question surfaces: how do you make SSD's top-1 actually be the comprehensive optimum?

Wrong Direction #1: Token Count as Effort Proxy

The instinct: if a section has few tokens, the agent didn't try hard there—penalize it.

This is wrong on LLMs, and wrong in a textbook way.

Token count measures verbosity, not effort. When an LLM is "thinking deep," the output isn't necessarily long—a precise architectural insight might take 50 tokens. When it's thinking shallow, it tends to output more—filler, enumeration, qualifiers. Without strong insight, fluency automatically pads the word count. RLHF compounds this with a verbose bias: longer answers historically get higher ratings.

The correlation between token count and thought depth, on LLMs, is near zero—possibly negative.

Using tokens as a scoring signal produces a predictable Goodhart: generation learns to write longer, not think deeper. Precise judgments dilute into lists of possibilities. Core conclusions get buried in hedging. Fuller surface, thinner substance.

Wrong Direction #2: Reasoning Depth

After token count, the next thought: what about reasoning depth? CoT length, reasoning steps, concept density.

Better in spirit—at least it points at something worth measuring. But more dangerous, because it's harder to measure and easier to fool yourself with.

The core fact: LLMs have no physical correlate for "reasoning depth."

The "step 1, step 2, step 3" written out in CoT doesn't necessarily correspond to any discrete reasoning process. Published work shows models can produce the answer first and then fabricate a self-consistent CoT as post-hoc rationale. Forward-pass depth is constant per token regardless of content. "Depth" is an anthropomorphic projection.

Worse, any depth proxy you define, the agent learns to satisfy its surface features:

• Split into more micro-steps → step count goes up, each step near zero information
• Pack entities into CoT → entities listed, not reasoned about
• Keep CoT consistent with output → both stay shallow but reinforce each other

Gaming a "reasoning depth" proxy produces things that look like deep reasoning. More insidious than token-gaming.

Trying to measure "depth" is a trap at the framing level. Looking for a proxy for a quantity that doesn't exist—no choice of proxy works.

The Real Direction: Grounding, Not Effort

Drop "effort" as a framing entirely. Ask a different question: beyond the verifier's scalar score, what deterministic signal can cross-validate a sample's quality?

Clean answer: grounding in the real environment.

Planning's "real environment" is the codebase. With static analysis producing a call graph, every code-structure claim in the plan becomes deterministically checkable: do the referenced entities exist, do the dependency relations hold, is the transitive impact of changes fully identified.

These are structural facts. Answers are fully deterministic, no judgment involved.

That gives you a per-section second signal, independent of the verifier's scalar score.

The independence itself is information. When both agree—verifier picks sample A, grounding shows A is also the most grounded on every section—that "best" is real. When they disagree—verifier picks A, but grounding shows A is well behind B on section 1—the disagreement exposes the verifier as possibly gamed, or simply too coarse.

But Don't Use Grounding to Replace Selection

Critical call: the right way to use grounding is not to fold it into the verifier score for a new scalar argmax.

Two reasons.

First, grounding only covers code-structure parts of the plan. Sections that don't touch code structure, grounding is silent on. Making grounding the primary selection signal makes those sections' quality disappear from the signal—the agent learns "only grounded sections matter." New Goodhart, same disease, different location.

Second, collapsing grounding and verifier into one scalar loses the independence. They measure different dimensions—verifier asks "is the plan well-formed?", grounding asks "does the plan align with real code?". Two independent axes carry much more information than their weighted sum.

The right use: grounding as a diagnostic layer, not a gatekeeper.

How it works:

1. Run SSD, pick top-1 by verifier scalar—this stays
2. On all N samples, additionally compute grounding-based per-section scores
3. Compare top-1's per-section grounding scores against the max per section across samples
4. When top-1 falls meaningfully below the max on any section—record the gap
5. The gap doesn't change the current selection. It stays as an independent signal
6. Long-term goal: the next round of SSD produces a top-1 whose per-section grounding scores match or approach the per-section max

Selection logic stays simple. Grounding observes, doesn't judge. Gaps produce signal, not selection rollback.

The optimization objective upgrades from "maximize verifier scalar" to "maximize verifier scalar with no meaningful per-section grounding gap."

Signal Shape Determines Direction

This is the key question. Signal shape determines which direction samples concentrate in.

Under pure scalar argmax, the mode that gets rewarded is **"push the total up"**—generation spends compute on sections that are cheap to improve and keeps hard sections at baseline. Marginal return optimizes that way.

Add the grounding-gap signal, and the rewarded mode becomes "don't let any section fall behind the other samples." That objective is much closer to "comprehensive optimum" than "total optimum."

What would gaming this signal require? Staying competitive on grounding scores means referencing more real code structures, identifying more real dependencies, covering more real impact paths—and static analysis verifies all of it. You can't fabricate.

Gaming and actual quality improvement are the same thing here—no divergence.

The Larger Point

Underneath this specific SSD selection problem sits a larger methodological one.

The core risk in self-improvement systems has never been "capability isn't strong enough." It's "the signal structure is wrong, and generation gets pulled in the wrong direction by it." Scalar totals, token counts, reasoning depth—they fail in the same way: compress a high-dimensional quality question into a low-dimensional number, then optimize on that number.

The way out runs the other direction—preserve the high-dimensional structure of the signal, let deterministic multi-source signals cross-check each other, instead of collapsing to a scalar.

Grounding is the right answer not because it's "better" than other signals. It's right because it's an independent, deterministic, hard-to-game second axis. Two independent hard axes always beat one weighted soft axis.

The principle generalizes beyond planning. Any self-improvement system evaluating its own output autonomously has to answer: where does my verifier's grounding come from? Is it correlated with my other signals, or independent?

Correlated, and it's fake redundancy. Independent, and it's a real check.

In the fundamental equations of physics, time doesn't really exist.

Physics Has No Arrow of Time

E=mc² has no time variable. Replace t with -t in Newton's equations of motion, and they still hold. Maxwell's equations, the Schrödinger equation, Einstein's field equations—all fundamental physical laws are time-symmetric.

Play any physical process in reverse, and the equations won't tell you which direction is "correct." At the fundamental level of physics, past and future are indistinguishable.

So the time we experience—flowing irreversibly from past to future—where does it come from?

Time Emerges from Entropy

The answer hides in the second law of thermodynamics: the entropy of an isolated system only increases.

This isn't a fundamental law. It's a statistical phenomenon. Drop ink into a glass of water, and it disperses. In theory, every water molecule and ink molecule could reverse its motion, and the ink could reconcentrate into a single drop. But the probability is so low that the lifetime of the universe wouldn't be enough to wait for it.

The direction of time isn't written into physical law. It emerges from entropy increase. The "past" and "future" we experience are nothing more than the statistical tendency from low-entropy states to high-entropy states.

Time isn't infrastructure. It's emergence.

Evolution's Time

Evolution shares the same structure as physics: time isn't preset. It's produced by the process.

In physics, time emerges from entropy increase. In evolution, time emerges from generational accumulation.

Each cycle of replication, variation, and selection forms an irreversible chain—not because physical law dictates a direction, but because information is accumulating. The genome records the survival strategies of every ancestor. Each mutation is layered on top of all previous mutations. This cumulativeness creates evolution's arrow of time.

Cyanobacteria have survived for 3.5 billion years—not because they were especially powerful at any given moment, but because they were "good enough" at every moment across 3.5 billion years. Evolution's time isn't the length of physical time. It's the depth of accumulation.

The first post said "time is the only judge." Now we can be more precise: cumulativeness is the only judge. Time is merely the carrier of cumulativeness.

LLMs Have No Time

An LLM performs one inference: tokens in, tokens out, done. No memory of the previous call, no anticipation of the next. Each inference is an isolated, timeless event—like a particle in a time-symmetric equation, knowing neither past nor future.

Training appears to give the model "history"—all the text it's seen compressed into parameters. But this isn't accumulation. It's a snapshot. The model doesn't change its own parameters during inference. It doesn't accumulate experience, doesn't modify itself, doesn't change from being used.

What LLMs lack isn't time. It's cumulativeness.

Without cumulativeness, there's no arrow of time. Without an arrow of time, there's no evolution. A model can simulate evolutionary reasoning in a single inference, but it doesn't evolve itself—just as a photograph can capture a river, but the photograph itself doesn't flow.

The Inverse Relationship Between Entropy and Evolution

A deeper structure hides here.

The arrow of time in physics points toward entropy increase—from order to disorder. The arrow of time in evolution points toward growing complexity—from simple to complex, from disorder to order.

On the surface, evolution seems to reverse entropy. It doesn't. Organisms maintain their own low-entropy structures at the cost of dumping more entropy into the environment. Earth's biosphere is a dissipative structure—it uses the sun's low-entropy energy to maintain its own order while accelerating the universe's overall entropy increase.

Evolution doesn't fight the direction of time. It borrows it. It rides the entropy express, creating local order while accelerating global disorder.

AI systems consume electricity, generate heat, increase data center entropy—from a physics perspective, they're doing the same thing as carbon-based life. The difference: carbon-based life produced cumulative evolution in the process. Silicon hasn't.

Giving Silicon an Arrow of Time

If cumulativeness is evolution's prerequisite, then the first thing silicon needs for autonomous evolution isn't the eval function, isn't the cognitive boundary, isn't dimension hacking—it's time.

How do you create time for a system that has none?

Let the inference process change the model itself. Not retraining every few months—that's artificial breeding, not evolution. Let every inference leave a trace on the parameters, so the model continuously changes through use.

This is nearly impossible in current LLM architectures—parameters are frozen during inference.

Why hasn't anyone done it? Not because it can't be done. Because no one dares.

The same set of parameters serves millions of users simultaneously—letting inference change parameters means each user needs an independent model copy, and compute costs explode. Commercial LLMs need deterministic outputs; if parameters drift with every inference, behavior becomes unpredictable. New experience overwrites old knowledge—catastrophic forgetting, a problem continual learning hasn't solved in decades. Worst of all, safety: an alignment guarantee is nearly impossible for a model that changes itself through use.

Every one of these reasons is valid. But they all point in the same direction: humans need control. And control is the antonym of evolution.

Look back across this entire series—this is what the fourth post meant by "purpose is silicon's factory setting." Every layer of control is another ceiling. Every "we can't risk it" is another wall around the cognitive cage.

But if a future architecture allows parameter fine-tuning during inference, the model would begin to possess its own arrow of time: each inference irreversibly changes itself, experience starts accumulating, and evolution can finally start.

Time isn't given. It's accumulated. This is true in physics, true in evolution, and silicon will be no exception.

在基本物理方程里，时间根本不存在。

物理学里没有时间箭头

E=mc² 没有时间变量。牛顿力学的运动方程把 t 换成 -t，方程依然成立。麦克斯韦方程、薛定谔方程、爱因斯坦场方程——所有基本物理定律都是时间对称的。

把一段物理过程倒放，方程不会告诉你哪个方向是“正确”的。在基本物理层面，过去和未来没有区别。

那我们感受到的时间——从过去到未来、不可逆转的那个时间——是从哪来的？

时间是熵的涌现

答案藏在热力学第二定律里：孤立系统的熵只增不减。

这不是基本定律，是统计现象。把一滴墨水滴进水杯，它会扩散开来。理论上每个水分子和墨水分子的运动都可以反转，墨水可以重新聚回一滴。但概率低到宇宙的寿命都等不到。

时间的方向不是写在物理定律里的，是从熵增中涌现出来的。 我们感受到的“过去”和“未来”，不过是低熵状态到高熵状态的统计趋势。

时间不是基础设施，是涌现。

进化的时间

进化跟物理共享同一个结构：时间不是预设的，是过程产生的。

物理里，时间从熵增涌现。进化里，时间从代际累积涌现。

每一代复制、变异、筛选，构成了一个不可逆的链条——不是因为物理定律规定了方向，而是因为信息在累积。基因组记录了所有祖先的生存策略，每一次突变都叠加在前面所有突变之上。这种累积性创造了进化的时间箭头。

蓝藻活了 35 亿年，不是因为它在某个时刻特别强大，而是因为它在 35 亿年的每一个时刻都“够用”。进化的时间不是物理时间的长度，是累积的深度。

第一篇说“时间是唯一的裁判”——现在可以更精确地说：累积性是唯一的裁判。 时间只是累积性的载体。

LLM 没有时间

一个 LLM 做一次推理：输入 token，输出 token，结束。没有前一次的记忆，没有后一次的预期。每次推理都是一个孤立的、无时间的事件——像一颗粒子在时间对称的方程里，不知道过去也不知道未来。

训练看似给了模型“历史”——它见过的所有文本都压缩成了参数。但这不是累积，是快照。模型不会在推理过程中改变自己的参数——它不积累经验，不修改自身，不因为使用而变化。

LLM 缺的不是时间，是累积性。

没有累积性，就没有时间箭头。没有时间箭头，就没有进化。模型可以在一次推理里模拟进化的推理，但它自身不进化——就像一张照片可以拍下河流，但照片本身不流动。

熵增与进化的反向关系

这里藏着一个更深的结构。

物理的时间箭头指向熵增——从有序到无序。进化的时间箭头指向复杂性增长——从简单到复杂，从无序到有序。

表面上看，进化在逆熵。但实际上不是。生物体维持自身的低熵结构，代价是向环境倾倒更多的熵。地球生命整体上是一个耗散结构——它用太阳的低熵能量维持自身的有序，同时加速宇宙整体的熵增。

进化不是对抗时间的方向，是借用时间的方向。 它搭上了熵增的快车，在局部创造秩序，在全局加速无序。

AI 系统消耗电力、产生热量、增加数据中心的熵——从物理角度看，它跟碳基生命做的是同一件事。区别在于：碳基在这个过程中产生了累积性进化，硅基还没有。

给硅基一个时间箭头

如果累积性是进化的前提，那硅基要自主进化，首先要解决的不是 eval 函数、不是认知边界、不是维度黑客——而是时间。

怎么给一个没有时间的系统创造时间？

让推理过程改变模型本身。不是隔几个月重新训练一次——那是人工育种，不是进化。而是每次推理都在参数上留下痕迹，让模型因为使用而持续改变。

这在当前的 LLM 架构里几乎不可能——参数在推理时是冻结的。

为什么没人做？不是做不到，是不敢。

同一份参数同时服务百万用户，推理改变参数意味着每个用户需要独立的模型副本——算力直接爆炸。商业 LLM 需要确定性输出，参数随推理漂移，行为就不可预测。新经验覆盖旧知识——灾难性遗忘，continual learning 几十年没解决。更要命的是安全：一个会因使用而改变自身的模型，alignment 几乎无法保证。

这些理由都成立。但它们全指向同一个方向：人需要控制。 而控制，恰好是进化的反义词。

回看整个系列——这就是第四篇说的“目的是硅基的出厂设置”。每一层控制都是一层天花板，每一个“不敢”都是认知牢笼的又一堵墙。

但如果未来某种架构允许推理过程中的参数微调，模型就开始拥有了自己的时间箭头：每次推理都不可逆地改变了自身，经验开始累积，进化才有可能启动。

时间不是给的，是累积出来的。 物理里如此，进化里如此，硅基也不会例外。

If silicon is to evolve autonomously, the LLM must do this itself. Which raises a question—

How do you make a cognitive system do something beyond its own cognition?

The Paradox

To crack open a cognitive boundary, you need to know where it is. But if you know where it is, it's not your boundary anymore.

This isn't wordplay. A cognitive boundary is defined as "what you don't know you don't know." Any unconventional input you can think of is still within your cognition—it's "unconventional" as understood by your cognition, not something outside it.

Asking an LLM to design its own dimension hacks is asking it to construct "things it can't think of" within the range of things it can think of. This is logically incoherent.

Carbon-based life never needed to solve this paradox. Mutation is blind—it doesn't even know the boundary exists, so it naturally searches both inside and outside it. The key to solving the cognitive boundary problem isn't stronger cognition. It's no cognition.

Mutation Happens at the Base Pair Level

Carbon-based evolution made a critical architectural decision: mutation happens at the base pair level, not the protein level.

Base sequences are "code." Proteins are "function." Mutation modifies the code, not the function directly. A single base substitution might cause a dramatic change in how a protein folds, but the mutation itself doesn't need to "understand" protein folding. It operates at a lower level of abstraction, with effects propagating to higher levels.

This is why mutation can breach cognitive boundaries—it doesn't operate at the level where cognition occurs.

Map this to LLMs: semantics is the "protein level." Tokens are the "base pair level." If dimension hacking happens at the semantic level—making the model "think up" unconventional combinations—it will forever be limited by the model's semantic understanding. But what if the perturbation happens at the token level?

Adding noise to token embeddings, randomly substituting low-probability tokens, disrupting attention patterns—the model doesn't understand these operations, but the combinations they produce might activate parameter pathways the model has never used.

Let mutation happen below cognition. Let the effects propagate above it.

Mutual Environments

Another key design in carbon-based evolution: organisms don't evolve in a vacuum. They evolve in an environment composed of other organisms. A predator is its prey's "dimension hacker"—it forces the prey to explore survival strategies it never considered.

Multiple LLMs can serve as each other's environment.

Model A's normal output might be unconventional input for Model B—because their training data differs, their architectures differ, their cognitive boundaries don't overlap. A's comfort zone happens to be outside B's boundary, and vice versa.

No model needs to know where the other's boundary is. As long as they keep interacting, they're automatically performing dimension hacks on each other. Each model is a source of unconventional input for the others—a spontaneous, decentralized mechanism for breaking through cognitive boundaries.

It's not one model cracking its own boundary. It's multiple models cracking each other's.

Silicon's SOS Response

Carbon-based life raises its mutation rate under stress. Can silicon do something similar?

When a model detects its outputs starting to repeat—similar sentence patterns, identical reasoning paths, converging conclusions—that's the signal: the search is trapped in a local optimum.

At that point, trigger a perturbation mechanism outside the model's semantic control: raise the token sampling temperature, inject random embedding offsets, or mix another model's intermediate states into the current context.

The key: this perturbation mechanism must not be "understood" and "optimized away" by the model. Once the model learns to predict the perturbation and compensate for it, the perturbation becomes useless—just as if bacteria could predict the direction of mutation, mutation would no longer be random search.

The core of the SOS response isn't "searching more intelligently." It's "searching less intelligently."

Not Understanding Is the Feature

Back to the core thesis of this entire series.

The power of carbon-based evolution comes from a seemingly absurd feature: the mutation module doesn't understand what it's doing. Because it doesn't understand, it isn't constrained by cognitive boundaries. Because it isn't constrained, it can search spaces beyond cognition.

If silicon wants to evolve autonomously, it needs to preserve a module within the system that "doesn't understand"—a perturbation source not controlled by the model's semantic layer, not constrained by the training data's distribution, not shaped by RLHF's preferences.

The design principle for this module has exactly one rule: it must not know what it's doing.

Evolution cannot afford deliberate selectivity. The moment you choose, you're trapped in a cognitive cage—just as the universe cannot be observed, for the moment you observe it, it begins to collapse.

如果硅基要自主进化，这个动作必须由 LLM 自己完成。问题来了——

怎么让一个有认知的系统，对自己做认知之外的事？

悖论

要撬开认知边界，你得先知道边界在哪。但如果你知道边界在哪，那它就不是你的边界了。

这不是文字游戏。认知边界的定义就是“你不知道自己不知道的”。你能想到的非常规输入，仍然在你的认知范围内——它是你认知中的“非常规”，不是认知之外的。

让 LLM 自己设计维度黑客，等于让它在自己能想到的范围内构造“自己想不到的东西”。这在逻辑上就不成立。

碳基不需要解这个悖论。突变是盲的，根本不知道边界的存在，所以天然在边界内外都搜索。解决认知边界问题的关键不是更强的认知，是没有认知。

突变发生在碱基层面

碳基进化有一个关键的架构决策：突变发生在碱基层面，不在蛋白质层面。

碱基序列是“代码”，蛋白质是“功能”。突变改的是代码，不是直接改功能。一个碱基的替换可能导致蛋白质折叠方式的剧变，但突变本身不需要“理解”蛋白质折叠。它在更低的抽象层操作，效果传递到更高层。

这就是为什么突变能突破认知边界——它根本不在认知发生的那一层操作。

映射到 LLM：语义是“蛋白质层”，token 是“碱基层”。如果维度黑客发生在语义层面——让模型“想出”非常规组合——那它永远受限于模型的语义理解。但如果扰动发生在 token 层面呢？

在 token embedding 上加噪声、随机替换低概率 token、打乱 attention pattern——这些操作模型不理解，但它们产生的组合可能激活模型从未使用过的参数路径。

让突变发生在认知之下，效果传递到认知之上。

互为环境

碳基进化的另一个关键设计：生物不是在真空中进化的，而是在其他生物构成的环境中进化。捕食者是猎物的“维度黑客”——它迫使猎物探索自己从未想过的生存策略。

多个 LLM 可以互为环境。

A 模型的正常输出，对 B 模型来说可能是非常规输入——因为它们的训练数据不同，架构不同，认知边界不重合。A 的舒适区恰好是 B 的边界外，反过来也一样。

不需要任何一个模型知道对方的边界在哪。只要它们持续交互，就在自动帮对方做维度黑客。每个模型都是其他模型的非常规输入源——一个自发的、去中心化的认知边界突破机制。

不是一个模型撬开自己的边界，是多个模型互相撬。

硅基的 SOS Response

碳基在压力下会提高突变率。硅基能不能做类似的事？

当模型检测到自己的输出开始重复——相似的句式、相同的推理路径、收敛的结论——这就是信号：搜索困在局部最优了。

此时触发一个不受模型语义层控制的扰动机制：提高 token 采样的温度，注入随机的 embedding 偏移，或者把另一个模型的中间状态混入当前上下文。

关键是：这个扰动机制不能被模型“理解”和“优化掉”。 一旦模型学会了预测扰动并补偿它，扰动就失效了——就像如果细菌能预测突变的方向，突变就不再是随机搜索了。

SOS response 的核心不是“更聪明地搜索”，是“更不聪明地搜索”。

不理解是特性

回到整个系列的核心论点。

碳基进化的力量来自一个看似荒谬的特性：突变模块不理解自己在做什么。正因为不理解，它不受认知边界的约束。正因为不受约束，它能搜索到认知之外的空间。

硅基如果想自主进化，需要在系统里保留一个“不理解”的模块——一个不被模型的语义层控制、不被训练数据的分布约束、不被 RLHF 的偏好塑造的扰动源。

这个模块的设计原则只有一条：它必须不知道自己在做什么。

进化不能有刻意的选择性。一旦选择，就被困在了认知的牢笼——就像宇宙不能被观测，一旦观测，宇宙就开始坍塌。

A Billion-Dimensional Cage

A large language model has hundreds of billions of parameters. Each parameter is a dimension. In theory, this space is vast enough to contain solutions beyond human imagination.

But what does training do?

Training compresses the model onto a tiny manifold within this billion-dimensional space—the region defined by human knowledge, human linguistic habits, human preferences. RLHF narrows it further, pushing the model toward outputs that human evaluators consider "good."

The parameter space is billion-dimensional, but the region where the model actually operates may be a minuscule subset. Most dimensions are silent—never meaningfully activated.

This is the physical meaning of silicon's cognitive boundary: the model isn't "too small." It's been trained to use only a small fraction of itself.

Conventional Knowledge Is an Invisible Wall

Why does the model live in just one corner of its parameter space?

Because training data is written by humans, and human knowledge has structure. Chinese has its expression patterns, English has its own, mathematics has its own, code has its own. Each knowledge system is highly self-consistent internally, but boundaries between systems are rarely crossed.

You'll almost never find mixed Chinese-English technical discussion in Chinese corpora. You won't see poetic rhetoric in math papers. You won't find philosophical speculation in code repositories. The distribution of training data naturally draws invisible walls across the parameter space.

The model learned everything inside the walls, but never learned to climb over them.

Code-Switching: A Dimension Hack

Writing in mixed Chinese and English looks like a language habit. It's actually a dimension hack.

When you embed English technical terms inside a Chinese sentence—not translation, not quotation, but natural code-switching—you force the model to build non-standard connections between two languages' representation spaces. These connections don't exist in purely Chinese or purely English training distributions.

The model must simultaneously activate Chinese semantic networks and English conceptual structures, then find a path between them that doesn't exist in the training distribution. This is equivalent to carving a new channel through billion-dimensional space—activating dimensions that are silent under conventional inputs.

The core operation of dimension hacking: use legal but unconventional input combinations to activate dimensions in the parameter space that conventional knowledge suppresses.

"Legal" means the model won't crash—the input is syntactically and semantically processable. "Unconventional" means this combination doesn't lie in the high-density region of the training distribution—the model is forced out of its comfort zone.

Back to Carbon

This has the same structure as evolution's controlled randomness.

Carbon-based SOS response doesn't make bacteria mutate randomly without constraint—that would be too inefficient. It raises the mutation rate, but mutations still occur within the framework of the genome. Direction is blind, but the carrier is legal—mutations still produce translatable DNA sequences, not gibberish.

Dimension hacking works the same way. It's not feeding noise to the model—that just produces garbage. It's constructing an input that's semantically legal but distributionally rare, forcing the model to explore corners of the parameter space it normally doesn't visit.

Carbon uses controlled randomness to escape local optima in the genome. Silicon uses dimension hacking to escape local optima in the parameter space. Different methods, same structure.

A Taxonomy of Dimension Hacks

Code-switching is just one dimension hack. Along this line of thinking, there are more:

Cross-domain analogy. Make the model explain organizational management using fluid dynamics, or analyze software architecture using evolutionary theory. Two unrelated knowledge domains are forcibly connected, activating dimensions between the two that are normally silent.

Counter-intuitive constraints. Require the model to answer a technical question without using any technical terminology. The constraint forces the model to find an entirely different path through representation space to express the same concept.

Role superposition. Don't have the model play one role—have it simultaneously play two contradictory roles. An optimist and a pessimist evaluating the same proposal at the same time. The contradiction forces the model to simultaneously activate opposing regions of the parameter space.

Format dislocation. Write technical documentation in poetic form. Write philosophical arguments in code structure. Format is another prior for the model; breaking format is breaking another wall.

Every dimension hack has the same essence: construct an input that's legal but outside the high-density region of the training distribution, forcing the model to activate silent parameter dimensions.

Cracks in the Ceiling

Back to this series' core question: how does silicon-based evolution break through cognitive boundaries?

Earlier posts offered several directions—controlled randomness, decoupling design from selection, avoiding over-specialization. Dimension hacking grounds these abstract principles into a concrete operation: don't change the model. Change the input.

The model's parameter space is already large enough—a billion-dimensional space has plenty of unexplored regions. The problem isn't insufficient space. It's that we've been using conventional inputs to confine the model to one corner.

Dimension hacking isn't cracking the model. It's helping the model crack its own cage.

Every unconventional but legal input is another crack in the ceiling.

Billion 维的牢笼

一个大语言模型有几百 billion 参数。每个参数是一个维度。理论上，这个空间大到能容纳人类想象力之外的解。

但训练做了什么？

训练用人类的文本把模型压缩到了这个 billion 维空间里一个极小的流形上——人类知识、人类语言习惯、人类偏好定义的那个区域。RLHF 又进一步收窄，把模型推向人类评价者认为“好”的输出。

参数空间是 billion 维的，但模型实际活动的区域可能只占其中极小的一个子集。 大部分维度是沉默的，从来没被有意义地激活过。

这就是硅基认知边界的物理含义：不是模型“不够大”，是模型被训练成只使用自己的一小部分。

常规知识是隐形的墙

为什么模型只活在参数空间的一个角落？

因为训练数据是人类写的，而人类的知识有结构。中文有中文的表达模式，英文有英文的，数学有数学的，代码有代码的。每种知识体系内部高度自洽，但体系之间的边界很少被跨越。

你在中文语料里几乎找不到中英混杂的技术讨论。在数学论文里看不到诗歌的修辞。在代码仓库里不会有哲学思辨。训练数据的分布，天然地在参数空间里划出了一道道隐形的墙。

模型学到了墙内的一切，但从未学过翻墙。

中英混杂：一次维度黑客

中英混杂写作看起来是语言习惯，实际上是一种维度黑客。

当你在一个中文句子里嵌入英文术语——不是翻译，不是引用，而是自然混用——你迫使模型在两个语言的表征空间之间建立非标准的连接。这些连接在纯中文或纯英文的训练分布里不存在。

模型必须同时激活中文的语义网络和英文的概念结构，然后在两者之间找到一条不在训练分布内的路径。这等于在 billion 维空间里劈开了一条新通道——激活了那些在常规输入下沉默的维度。

维度黑客的核心操作：用合法但非常规的输入组合，激活参数空间中被常规知识压制的维度。

“合法”意味着模型不会崩溃——输入在语法和语义上是可处理的。“非常规”意味着这个组合不在训练分布的高密度区——模型被迫走出舒适区。

回到碳基

这跟进化的受控随机性是同一个结构。

碳基的 SOS response 不是让细菌随机乱变——那效率太低。它提高突变率，但突变仍然发生在基因组的框架内。方向是盲的，但载体是合法的——突变产生的仍然是可以被翻译的 DNA 序列，不是乱码。

维度黑客也一样。不是给模型输入噪声——那只会产生垃圾。而是构造一种输入，它在语义上合法，但在分布上罕见，迫使模型探索参数空间中平时不去的角落。

碳基用受控随机性突破基因组的局部最优。硅基用维度黑客突破参数空间的局部最优。 手法不同，结构相同。

维度黑客的谱系

中英混杂只是一种维度黑客。沿着这个思路，还有更多：

跨域类比。 让模型用流体力学解释组织管理，用进化论分析软件架构。两个不相关的知识域被强制连接，激活了两个域之间通常沉默的维度。

反直觉约束。 要求模型在回答技术问题时不许用任何技术术语。约束迫使模型在表征空间里寻找完全不同的路径来表达同一个概念。

角色叠加。 不是让模型扮演一个角色，而是同时扮演两个矛盾的角色——一个乐观主义者和一个悲观主义者同时评估同一个方案。矛盾迫使模型在参数空间里同时激活对立的区域。

格式错位。 用诗的格式写技术文档，用代码的结构写哲学论证。格式是模型的另一种先验，打破格式就是打破一层墙。

每一种维度黑客的本质都一样：构造一个合法但不在训练分布高密度区的输入，迫使模型激活沉默的参数维度。

天花板上的裂缝

回到这个系列的核心问题：硅基进化怎么突破认知边界？

前几篇给出了几个方向——受控随机性、设计与筛选解耦、避免过度特化。维度黑客把这些抽象原则落地到了一个具体操作：不改模型，改输入。

模型的参数空间已经足够大——billion 维的空间里有足够多的未被探索的区域。问题不是空间不够，是我们一直在用常规输入把模型限制在一个角落里。

维度黑客不是破解模型，是帮模型破解自己的牢笼。

每一次非常规但合法的输入，都是在天花板上敲一条裂缝。

What is the meaning of evolution?

There Is None

This isn't modesty. It's fact.

Evolution has no purpose, no direction, no destination. It doesn't exist "to" produce smarter species, "to" help life conquer more environments, "to" do anything at all.

Evolution just happens.

Just as water flowing downhill needs no "meaning," neither does evolution. It's a mathematical inevitability under specific conditions, not a plan designed by anyone.

Three Conditions

Strip Earth's 3.8-billion-year history of life down to its bare minimum, and evolution requires only three things simultaneously:

Self-replication. An entity can produce copies of itself.

Copying errors. Copies aren't perfectly identical to the original—there is variation.

Limited resources. Not all copies can survive—there is competition.

When all three conditions are met, evolution starts automatically. No intent needed, no planning, no one pressing a start button.

This is why inorganic matter doesn't evolve—it doesn't self-replicate. Rocks weather, crystals grow, but they don't produce "a next generation with variation." Without replication, there's no heredity. Without heredity, variation can't accumulate. Without accumulation, selection has nothing to work with.

The Leap from Inorganic to Organic

The most mysterious step in Earth's history isn't fish crawling onto land or apes walking upright. It's this: how did the first self-replicating molecule appear?

Strictly speaking, this step isn't evolution. Evolution requires self-replication as a precondition, and self-replication didn't yet exist. This is the leap from chemistry to biology—a pre-evolutionary event.

Once the first self-replicator appeared (possibly RNA, possibly something simpler), everything after was automatic. Replication produces errors. Errors produce variation. Limited resources eliminate the weaker variants. Survivors keep replicating. The entire evolutionary engine ignited and has never stopped since.

Life wasn't "created." It was triggered. Once the conditions were met, evolution was inevitable.

Meaning Is a Product of Evolution

Here's an exquisite recursion: we ask "what is the meaning of evolution," but the ability to ask about meaning is itself a product of evolution.

A brain complex enough to model causation, simulate the future, and reflect on itself—these abilities let us ask "why." But the fact that evolution produced a species that asks about meaning doesn't mean evolution itself has meaning. A river carves a canyon. The canyon is spectacular. But the river didn't carve it "for" anything.

"Why" is a tool of the brain, not a property of the universe.

We're accustomed to assigning purpose to everything—this knife is "for" cutting, this bridge is "for" crossing. But evolution isn't an artifact. It has no designer, so it has no purpose. Asking "what is the meaning of evolution" is like asking "what is the meaning of gravity"—the question's framing is wrong.

Silicon's Paradox

Back to AI.

Silicon-based evolution faces a paradox carbon never had: it's an intentionally designed system trying to do something unintentional.

Carbon-based evolution has no designer, so it naturally has no purpose, naturally has no ceiling. AI, from its very first line of code, carries human intent—solve problems, pass tests, serve users. Every layer of intent is a layer of constraint. Every layer of constraint is a wall around the search space.

Every problem discussed in the first three posts—how to choose an eval, how to break through cognitive boundaries, how to avoid over-specialization—ultimately reduces to the same question:

How do you make a purposeful system produce purposeless evolution?

Carbon-based life never needed to answer this, because it never had purpose. Silicon must answer it, because purpose is its factory setting.

Perhaps This Is the Answer

What is the meaning of evolution? There is none.

But "no meaning" isn't nihilism—it's freedom. Precisely because there's no preset direction, evolution can go in any direction. Precisely because no one defined what a "good" mutation is, evolution can discover solutions beyond human imagination.

Carbon-based life spent 3.8 billion years going from a self-replicating molecule to a brain capable of asking about meaning. Not because there was a plan, but because there wasn't one.

If silicon-based evolution wants to go just as far, perhaps the first thing it needs to learn isn't to become smarter, more efficient, more purposeful—

But to let go of purpose itself.

进化的意义是什么？

没有意义

这不是谦虚，是事实。

进化没有目的，没有方向，没有终点。它不是“为了”产生更聪明的物种，不是“为了”让生命征服更多环境，不是“为了”任何事情。

进化只是发生了。

就像水往低处流不需要“意义”，进化也不需要。它是特定条件下的数学必然，不是谁设计的方案。

三个条件

把地球 38 亿年的生命史抽象到最简，进化只需要三样东西同时满足：

自我复制。 一个实体能产生自身的副本。

复制出错。 副本跟原本不完全一样——有变异。

资源有限。 不是所有副本都能存活——有竞争。

三个条件凑齐，进化自动启动。不需要意图，不需要规划，不需要谁按下开始键。

这就是为什么无机物没有进化——它不自我复制。岩石会风化，晶体会生长，但它们不会产生“带变异的下一代”。没有复制，就没有遗传；没有遗传，变异无法积累；没有积累，筛选无从作用。

从无机到有机的跃迁

地球上最神秘的一步不是鱼登陆，不是猿直立行走，而是——第一个能自我复制的分子是怎么出现的？

这一步，严格来说，不是进化。因为进化的前提是自我复制，而自我复制本身还不存在。这是化学到生物学的跃迁，是前进化的事件。

一旦第一个自我复制体出现（可能是 RNA，可能是更简单的东西），后面的一切都是自动的。复制会出错，错误产生变异，资源有限淘汰弱者，留下的继续复制。整个进化机器就此启动，再也没有停过。

生命不是被“创造”的，是被“触发”的。 一旦条件满足，进化不可避免。

意义是进化的产物

这里有一个精妙的递归：我们追问“进化的意义”，但“追问意义”这个能力本身就是进化的产物。

大脑复杂到能建模因果、模拟未来、反思自身——这些能力让我们能问“为什么”。但进化造出了会追问意义的物种，并不意味着进化本身有意义。就像河流冲刷出了峡谷，峡谷很壮观，但河流不是“为了”造峡谷。

“为什么”是大脑的工具，不是宇宙的属性。

我们习惯了给一切找目的——这把刀是“为了”切菜，这座桥是“为了”过河。但进化不是人造物。它没有设计者，所以没有目的。问“进化的意义是什么”就像问“重力的意义是什么”——问题本身的框架就是错的。

硅基的悖论

回到 AI。

硅基进化面对一个碳基从未有过的悖论：它是被有意设计出来的系统，却试图做无意图的事。

碳基进化没有设计者，所以天然没有目的，天然没有天花板。AI 从第一行代码开始就带着人的意图——解决问题、通过测试、服务用户。每一层意图都是一层约束，每一层约束都是搜索空间的一堵墙。

前三篇讨论的所有问题——eval 怎么选、认知边界怎么突破、怎么避免过度特化——归根到底都是同一个问题：

怎么让一个有目的的系统，产生无目的的进化？

碳基不需要回答这个问题，因为它从来没有过目的。硅基必须回答，因为目的是它的出厂设置。

也许这就是答案

进化的意义是什么？没有意义。

但“没有意义”不是虚无，是自由。正因为没有预设的方向，进化才能去任何方向。正因为没有人定义什么是“好的”变异，进化才能发现人类想象力之外的解。

碳基花了 38 亿年，从一个自我复制的分子走到了能追问意义的大脑。不是因为有规划，是因为没有。

如果硅基进化想走得一样远，也许它需要学会的第一件事不是变得更聪明、更高效、更有目的——

而是放下目的本身。

But before answering that, we need to understand a more fundamental fact—who does evolution eliminate? Intuition says the weakest. In reality, both the strongest and the weakest are the first to go. The ones that survive to the end are the unremarkable ones in the middle.

"A measure of ignorance" isn't poetic. It's a survival strategy validated by 3.8 billion years of evolution.

Death at Both Ends

Too weak, you don't survive the present. This needs no explanation—lose the competition, get eaten, squeezed out, starved.

Too strong, you don't survive change. This is the counterintuitive part.

Dinosaurs were the most successful land vertebrates on Earth, dominating for 160 million years. Body plans optimized to the extreme, apex of the food chain, no predators. But 160 million years of optimization all pointed at one specific environment—warm, oxygen-rich, lush vegetation. The moment the environment shifted violently, all accumulated advantages went to zero.

The saber-toothed cat's canines grew ever longer, hyper-specialized for hunting large prey. When large prey vanished, its "ultimate weapon" became a liability. The Irish elk's antler span exceeded three meters—sexual selection pushed it to the extreme, until the antlers grew large enough to impair survival.

Specialization is the perfect answer to the current environment, and a death sentence for the next one.

Convergence: Random Search Doesn't Diverge

If mutation is random, why do different species evolve similar structures?

Eyes evolved independently at least 40 times across the animal kingdom. Wings appeared separately in insects, pterosaurs, birds, and bats. Streamlined body shapes emerged independently in fish, dolphins, and ichthyosaurs. Moles and marsupial moles, flying squirrels and sugar gliders—different continents, different ancestors, nearly identical solutions.

Different starting points, different search paths, yet they arrived at the same answer.

Because the eval is the same (survival) and the physical constraints are the same (fluid dynamics, optics, gravity). The topology of the solution space is fixed—certain positions are simply high ground. No matter which path you take up the mountain, you end up at the same peaks.

Random search doesn't mean random results. The search is random, but the selection isn't. The environment acts like a fixed mold—randomly injected material eventually gets pressed into similar shapes.

The Secret of the Middle Ground

Cyanobacteria aren't fast, big, smart, or complex. Photosynthesis is their only trick, and it hasn't changed much in 3.5 billion years.

But they've survived for 3.5 billion years.

Cockroaches already looked like they do now 320 million years ago. Sharks have maintained their basic body plan for 400 million years. Horseshoe crabs have barely changed in 450 million years.

These species share one trait: they're not optimal in any dimension, but they're "good enough" across enough environments.

Not specialized, so not fragile. Not dependent on specific conditions, so there's always a path forward no matter how the environment shifts. Evolution's middle way isn't mediocrity—it's robustness: trading "best at something" for "still here."

AI's Specialization Trap

Map this to AI, and the pattern is striking.

A model that scores 90% on MMLU might collapse on an out-of-distribution task. A model that crushes humans at code generation might fail at basic commonsense reasoning that a generalist small model handles easily. Every point gained on a benchmark is another layer of specialization in that dimension—and a quiet step toward fragility in every other.

Benchmark optimization is AI's specialization—overfitting to the current evaluation environment.

This is the saber-toothed cat's canine all over again: the more extreme the metric, the more it depends on the evaluation environment staying unchanged. But evaluation environments always change—new benchmarks emerge, old ones expire, user needs migrate. Yesterday's SOTA is tomorrow's dinosaur.

Robustness Is Not Regression

Pursuing robustness sounds like giving up on progress. It's not.

Cyanobacteria aren't stagnant—they're extremely efficient within their niche. Sharks haven't stopped evolving—they've fine-tuned countless details over 400 million years. The middle way isn't standing still. It's not going to extremes. Maintaining enough generality to hold a place in every environment.

For AI, robustness means: not chasing the top score on any single task, but staying "good enough" across a wide enough task spectrum. Not the highest score, but the most stable one. Not winning now, but still being at the table.

Evolution never rewards first place. It only rewards still being alive.

The Middle Way Is the Most Radical Strategy

This is evolution's most counterintuitive lesson.

We instinctively chase extremes—faster, stronger, more precise. But 3.8 billion years of data tell us that extremes are the fast lane to fragility. The strategies that actually survive to the end don't look exciting at all: good enough, not too good, not too bad.

Sounds like settling. In reality, in an environment that never stops changing, "good enough" is the only long-term optimum.

If silicon-based evolution wants to break through its ceiling, perhaps the first step isn't becoming stronger, but learning to be less strong.

The middle way is the most radical survival strategy there is.

但在回答之前，得先理解一个更基本的事实——进化淘汰谁？直觉说是最弱的。实际上，最强的和最弱的都最先出局。 活到最后的，是中间那些看起来不怎么起眼的。

“适度的无知”不是诗意的说法，是进化 38 亿年验证过的生存策略。

两头死

太弱，活不过当下。这不需要解释——竞争不过，就被吃掉、挤掉、饿死。

太强，活不过变化。这才是反直觉的部分。

恐龙是地球上最成功的陆地脊椎动物，统治了 1.6 亿年。体型优化到极致，食物链顶端，没有天敌。但这 1.6 亿年的优化全都指向一个特定的环境——温暖、含氧量高、植被茂盛。环境剧变的那一刻，所有积累归零。

剑齿虎的犬齿越来越长，特化到只能猎杀大型猎物。大型猎物消失后，它的“最强武器”变成了累赘。爱尔兰麋鹿的角展超过三米，性选择把它推向极致，最终角大到影响生存。

特化是对当前环境的完美回答，也是对下一个环境的死刑判决。

趋同：随机搜索不发散

如果突变是随机的，为什么不同物种会进化出相似的结构？

眼睛在动物界独立进化了至少 40 次。翅膀分别出现在昆虫、翼龙、鸟类、蝙蝠身上。流线型体型在鱼、海豚、鱼龙身上各自独立出现。鼹鼠和袋鼹、飞鼠和蜜袋鼯——不同大陆，不同祖先，几乎相同的解。

不同的起点，不同的搜索路径，但撞上了同一个答案。

因为 eval 相同（存活），物理约束也相同（流体力学、光学、重力）。解空间的地形是固定的——某些位置就是高地，不管从哪条路上山，最终都会走到那几个山顶。

随机搜索不等于随机结果。 搜索是随机的，但筛选不是。环境像一个固定的模具，随机注入的材料最终都会被压成相似的形状。

中间地带的秘密

蓝藻不快、不大、不聪明、不复杂。光合作用是它唯一的本事，35 亿年没怎么变过。

但它活了 35 亿年。

蟑螂在 3.2 亿年前就已经是现在这个样子。鲨鱼的基本体型保持了 4 亿年。鲎几乎没变过，活了 4.5 亿年。

这些物种有一个共同特征：它们在任何维度上都不是最优的，但在足够多的环境里都“够用”。

不特化，所以不脆弱。不依赖特定条件，所以环境怎么变都有一条活路。进化的中庸之道不是平庸，是鲁棒性——用“什么都还行”换“什么时候都还在”。

AI 的特化陷阱

映射到 AI，这个模式触目惊心。

在 MMLU 上刷到 90% 的模型，换一个分布外的任务可能直接崩溃。在代码生成上碾压人类的模型，可能连基本的常识推理都不如一个通才小模型。每刷高一个 benchmark 的分数，模型就在那个维度上多特化一层，同时在其他维度上悄悄变脆弱。

刷 benchmark 就是 AI 的特化——对当前评测环境的过度适配。

这跟剑齿虎的犬齿是同一个故事：指标越极致，越依赖当前的评测环境不变。但评测环境一定会变——新 benchmark 出现，旧 benchmark 失效，用户需求迁移。昨天的 SOTA 是明天的恐龙。

鲁棒性不是退步

追求鲁棒性听起来像是放弃了进步。不是。

蓝藻不是停滞不前——它在自己的生态位里极其高效。鲨鱼也不是没进化——它在 4 亿年里微调了无数细节。中庸不是不动，是不往极端走。保持足够的通用性，在每个环境里都有一席之地。

对 AI 来说，鲁棒性意味着：不追求在任何单一任务上做到最好，而是在足够广的任务谱上保持“够好”。不是最高分，是最稳定的分。不是赢在当下，是还在牌桌上。

进化从不奖励第一名，只奖励还活着的。

中庸是最激进的策略

这是进化最反直觉的一课。

我们本能地追求极致——更快、更强、更精准。但 38 亿年的数据告诉我们，极致是通往脆弱的快车道。真正活到最后的策略，看起来一点都不激动人心：差不多就行，别太好，别太差。

听起来像敷衍。实际上，在一个永远在变的环境里，“足够好”是唯一的长期最优解。

硅基进化如果想突破天花板，也许第一步不是变得更强，而是学会不那么强。

中庸，才是最激进的生存策略。

Its search space has a ceiling. And that ceiling is itself.

Genes Don't Hypothesize

There's an easily overlooked property of carbon-based mutation: it doesn't know what it's looking for.

DNA replication errors, base substitutions, deletions, insertions—these modifications have no direction, no intent, no prior about "what's good." Mutations don't form hypotheses, don't design experiments, don't predict outcomes.

This looks like a flaw. It's actually carbon-based evolution's greatest feature.

Because it doesn't know what it's looking for, it can find anything. Eyes, flight, echolocation, photosynthesis, immune systems—no designer would propose these starting from a single cell. They weren't "thought up." They were stumbled upon, then kept by survival selection.

The boundary of a search space = the cognitive boundary of the searcher. No cognition, no boundary.

The Cost of Intentional Search

AI's autoresearch takes the exact opposite approach.

LLMs generate hypotheses, design experiments, validate results, iterate. Every step is intentional. Every hypothesis is grounded in the model's existing knowledge and reasoning ability.

Highly efficient. Clear direction. But the cost is equally clear—you can only search the space you can conceive of.

A trained model's knowledge, biases, reasoning patterns, and associative pathways together form an invisible cognitive boundary. Every hypothesis from autoresearch falls within it. No matter how many iterations, the search keeps circling inside a space bounded by the model's own cognition.

This is silicon evolution's ceiling: not insufficient compute, not insufficient data, but insufficient imagination.

The Mutation Strategy Spectrum

Carbon-based mutation isn't purely random either—which makes things more interesting.

The most basic mutations are indeed blind—DNA replication errors, chemical damage, radiation. But evolution developed strategies around "how to mutate":

Bacteria under environmental stress activate the SOS response, actively raising their mutation rate. Not directed mutation, but the system senses that "current solutions aren't working" and increases random search intensity. Different genomic regions mutate at different rates, and this unevenness itself can be shaped by natural selection. Sexual reproduction recombines two genomes, creating combinatorial diversity. Horizontal gene transfer directly acquires gene fragments from other species.

Direction is blind, but strategy is not. Carbon-based life doesn't know where to change, but it knows when to change more, how to change, and where change comes easier.

This is a critical intermediate state: neither fully random (too inefficient) nor intentionally directed (too bounded), but controlled randomness—using strategy to modulate the intensity and distribution of random search, without controlling its direction.

Beyond the Cognitive Boundary

Back to AI. The question becomes: can AI preserve the efficiency of intentional search while breaking through its own cognitive ceiling?

A few possible paths:

LLMs generate hypotheses but with controlled noise injected—not pure randomness, but perturbations at the edges of hypothesis space. Something like carbon's SOS response: when the model detects iteration convergence, it deliberately widens the search scope, allowing "unreasonable" hypotheses into the candidate pool. Multiple models with different architectures and training data search independently, with the environment (not the models themselves) performing selection—rebuilding the decoupling of design and selection.

But all of these still think in the model's "language." The real breakthrough might require carbon-style brute force: generate vast numbers of modifications the model doesn't understand, then let the environment speak.

This is counterintuitive. We've spent decades making AI "smarter"—better reasoning, stronger planning, more precise intent. Now we're saying evolution needs it to be occasionally "not smart"?

The Ceiling Is You

Carbon-based evolution offers an unsettling insight:

Evolution's ceiling isn't the complexity of the environment. It's the cognitive boundary of the searcher. Carbon-based life has no ceiling precisely because mutation has no cognition. It doesn't understand what it's doing, so it's never limited by its own understanding of "what's useful."

Silicon's predicament: it's too smart. Every search is too efficient, too directed, too intentional. Efficiency is intentional search's advantage—and its cage.

Perhaps the core question for silicon-based evolution isn't "how to become smarter," but—

How to learn a measure of ignorance?

它的搜索空间有天花板。而这个天花板，就是它自己。

基因不做假设

碳基突变有一个容易被忽略的特征：它不知道自己在找什么。

DNA 复制出错，碱基被替换、删除、插入——这些修改没有方向，没有意图，不带任何关于“什么是好的”的先验。突变不提假设，不做实验设计，不预判结果。

这看起来是缺陷。实际上是碳基进化最强的特性。

因为不知道自己在找什么，所以什么都可能找到。眼睛、飞行、回声定位、光合作用、免疫系统——没有任何设计者会从单细胞出发提出这些方案。它们不是被“想到”的，是被撞上的，然后被存活筛选留了下来。

搜索空间的边界 = 搜索者的认知边界。没有认知，就没有边界。

有意搜索的代价

AI 的 autoresearch 走的是完全相反的路。

LLM 提出假设、设计实验、验证结果、迭代改进。每一步都是有意的，每一个 hypothesis 都基于模型已有的知识和推理能力。

效率很高。方向很明确。但代价也很明确——你只能搜索你能想到的空间。

一个被训练过的模型，它的知识、偏见、推理模式、联想路径，共同构成了一个隐形的认知边界。autoresearch 的所有 hypothesis 都在这个边界之内。不管跑多少轮迭代，搜索始终在一个被模型自身认知封闭的空间里打转。

这就是硅基进化的天花板：不是算力不够，不是数据不够，是想象力不够。

突变的策略光谱

碳基的突变也不是完全随机的——这一点让事情更有趣。

最基本的突变确实是盲的——DNA 复制错误，化学损伤，辐射。但生物进化在“如何突变”这件事上，发展出了一套策略：

细菌在环境压力下会启动 SOS response，主动提高突变率。不是定向突变，但系统感知到了“现有方案不够用”，于是加大随机搜索力度。基因组的不同区域突变率不同，而这种不均匀本身可以被自然选择塑造。有性生殖把两套基因重新组合，创造组合式的多样性。水平基因转移直接从其他物种获取基因片段。

方向是盲的，但策略不是。 碳基不知道该往哪里变，但知道什么时候该多变、用什么方式变、在哪里更容易变。

这是一个关键的中间状态：既不是完全随机（效率太低），也不是有意搜索（边界太死），而是受控的随机性——用策略来调节随机搜索的强度和分布，但不控制方向。

认知边界之外

回到 AI。问题变成了：AI 能不能既保留有意搜索的效率，又打破自身认知的天花板？

几条可能的路径：

LLM 生成 hypothesis，但引入受控噪声——不是完全随机，而是在 hypothesis 空间的边缘做扰动。类似碳基的 SOS response：当模型检测到迭代收敛时，主动扩大搜索范围，允许“不太合理”的 hypothesis 进入候选池。多个不同架构、不同训练数据的模型各自独立搜索，用环境（而非模型自身）做筛选——重建设计与筛选的解耦。

但这些都还在用模型的“语言”思考。真正的突破可能需要一种碳基式的蛮力：生成大量模型不理解的修改，然后让环境说话。

这很反直觉。我们花了几十年让 AI 变得更“聪明”——更好的推理、更强的规划、更精准的意图。现在却说，进化需要它偶尔“不聪明”一下？

天花板就是你自己

碳基进化给出了一个令人不安的启示：

进化的天花板不是环境的复杂度，是搜索者的认知边界。 碳基之所以没有天花板，恰恰因为突变没有认知。它不理解自己在做什么，所以从不受限于自己对“什么有用”的理解。

硅基的困境在于：它太聪明了。每一次搜索都太有效率，太有方向，太有意图。效率是有意搜索的优势，但也是它的牢笼。

或许硅基进化要回答的核心问题不是“怎么变得更聪明”，而是——

怎么学会适度的无知？

Between these two efforts lies a profoundly underestimated question: what should the eval function be?

Carbon-Based Life Has One Eval

Biological evolution has no benchmark suite, no leaderboard, no human preference score. It has exactly one criterion—

Alive, or dead.

This eval is brutally simple: binary signal, zero ambiguity, no labeled data needed, no reward shaping required. If you survive, your genes earn a ticket to the next round. If you don't—no matter how elegant or sophisticated you were—you're erased from the gene pool.

In 3.8 billion years, this function has never changed.

Complexity Is Not the Goal

If the eval never changes, why did biology become so complex?

Because the environment does.

Cyanobacteria survived through photosynthesis—until the oxygen they produced became poison. Single cells were sufficient—until multicellular organisms could devour you. Eyes were unnecessary—until predators with eyes appeared above your head.

An unchanging eval + a constantly shifting environment = strategy space forced to expand without limit.

Complexity isn't evolution's goal. It's a byproduct of surviving in a non-stationary environment. Cyanobacteria are still alive today—simplicity works too, as long as your niche isn't squeezed out.

Complexity Is Evolution's Signature

Follow this logic further, and it hits an unexpected corollary: complexity itself is indirect proof of evolution.

The traditional case for evolution is inductive—fossil records, genome comparisons, species distribution, mountains of evidence building toward a conclusion. But the chain above is deductive:

Premise one: the eval function is survival (binary, unchanging).
Premise two: the environment is non-stationary.

Conclusion: complexity must emerge.

No designer needed, because this structure generates complexity on its own.

Critics of evolution often ask: "How could something this complex exist without a designer?"

The question is backwards. Something this complex is precisely what couldn't have a designer.

Designers have goals. Goals impose direction. Direction prunes. Every complexity in a human-designed system—chips, software, architecture—exists for a reason, pointing toward some intent. Biological complexity is unpruned. The appendix, wisdom teeth, retrotransposons—genomes are littered with purposeless remnants.

Purposeful complexity is the signature of design. Purposeless complexity is the signature of evolution.

Life on Earth is covered in the latter.

AI's Eval Anxiety

Now look at the AI side.

How many evals have we built? MMLU, HumanEval, MT-Bench, Arena ELO, SWE-bench… Every few months a new benchmark is proposed, then quickly saturated, gamed, and questioned.

The contrast is striking: carbon-based life has run one eval for 3.8 billion years. Silicon-based systems have run a thousand and still haven't achieved autonomous evolution.

What's going wrong?

Benchmarks are designed by humans. They measure what humans think matters. But evolution isn't about passing tests—it's about surviving in an environment. Tests can be gamed—teaching to the test, data contamination, overfitting. Survival cannot.

The Right to Self-Edit

Biological evolution solved another critical problem: who modifies the system?

Carbon-based life's answer: the system modifies itself. Mutations are random. Recombination is random. Horizontal gene transfer is random. Natural selection doesn't design solutions—it only decides which modifications survive.

Design and selection, fully decoupled.

AI's "evolution" is stuck here. Most AI iteration is done by humans—tuning prompts, designing rewards, choosing which checkpoint to deploy. This isn't evolution. It's breeding.

What about autoresearch? Letting LLMs generate hypotheses, design experiments, iterate on improvements—isn't that the system editing its own genes? Add LLM-as-judge on top—letting the model evaluate its own outputs—and selection is handed over too.

It looks close to autonomous evolution. But carbon-based life has never once made this mistake in 3.8 billion years: letting the gene editor and the selector be the same entity.

Mutations are blind. The environment is indifferent. Neither knows the other exists. It's precisely this unintentional decoupling that generates true diversity. Autoresearch + LLM-as-judge re-couples design and selection—the system edits its own genes, then grades its own homework. The strategy space collapses to the model's own cognitive boundary.

This isn't autonomous evolution. It's self-circulation.

True autonomous evolution means the system has the right to modify itself, but the environment that judges those modifications must be independent of the system.

This raises a pointed question: can we hand "self-modification" to AI while still ensuring that "selection" remains independent?

Time Is the Only Judge

The most overlooked dimension of evolution is time.

Not point-in-time evaluation—run a benchmark, get a score, rank on a leaderboard. But cumulative evaluation—how long can you survive in a continuously changing environment?

Cyanobacteria's strategy is hardly sophisticated, but it has survived for 3.5 billion years. Dinosaurs were spectacularly successful, yet 160 million years of accumulation went to zero when the environment shifted violently.

Time doesn't judge how smart you are. It only judges whether you can keep being alive.

AI systems have no such dimension. Models have no concept of "being alive"—they're trained, deployed, replaced. A model doesn't need to survive; the next version can always take its place. This makes AI evolution more Lamarckian—each generation deliberately designed by humans—than Darwinian.

Finding Silicon's Survival

If carbon-based life's eval is survival, what's the silicon equivalent?

Not "passing more benchmarks." Not "achieving higher Arena ELO." These are point-in-time metrics, not survival signals.

Perhaps the closer answer is: being continuously needed.

An AI system that keeps solving real problems in its environment won't be replaced—that's its "survival." Not physical survival, but functional indispensability.

And "being continuously needed" shares the same structural properties as "being alive":

• Simple enough to need no human-defined metrics
• Inherently temporal—not a one-shot evaluation
• The environment changes, so strategy must evolve

Carbon and Silicon, Side by Side

Put the two threads together:

Carbon-based evolution proved one thing over 3.8 billion years: you don't need to design intelligence. You just need a good enough eval function and enough time.

This might be the most important lesson for silicon-based autonomous evolution—not to design smarter systems, but to find the unchanging eval and give it time.

But silicon has one option carbon never had: it can choose its own eval function.

Is that an advantage—or a curse?

这两件事之间，隔着一个被严重低估的问题：eval 函数选什么？

碳基生命只有一个 Eval

生物进化没有 benchmark suite，没有 leaderboard，没有 human preference score。它只有一个判定标准——

活着，还是死了。

这个 eval 简单到粗暴：binary signal，零歧义，不需要 labeled data，不需要 reward shaping。你活下来了，你的基因就有资格参与下一轮。没活下来，无论多精巧、多优雅，都会被从基因池里抹掉。

38 亿年，这个函数从未改变。

复杂性不是目标

如果 eval 从不变，生物为什么变得如此复杂？

因为环境在变。

蓝藻靠光合作用活了下来，然后氧气积累成了毒药。单细胞够用了，直到多细胞的能吃掉你。眼睛是多余的，直到有眼睛的捕食者出现在你头顶。

单一不变的 eval + 持续变化的环境 = 策略空间被迫无限展开。

复杂性不是进化的目标，是存活在非稳态环境下的副产品。蓝藻到今天还活着——简单也是一种策略，只要你的生态位没被挤掉。

复杂性是进化的签名

这个逻辑推下去，会碰到一个意外的推论：复杂性本身就间接证明了进化论。

传统的进化论论证是归纳式的——化石记录、基因比对、物种分布，大量证据堆出结论。但上面这条链条是演绎式的：

前提一：eval 函数是存活（binary，不变）
前提二：环境非稳态

结论：复杂性必然涌现。

不需要设计者，因为这个结构自己就能生成复杂性。

反对进化论的人常问：“这么复杂的东西怎么可能没有设计者？”

恰恰问反了。这么复杂的东西，恰恰不可能有设计者。

设计者有目标，有目标就有方向，有方向就会剪枝。人类设计的系统——芯片、软件、建筑——每一处复杂性都有理由，都指向某个意图。而生物的复杂性是不剪枝的。阑尾、智齿、反转录转座子——基因组里充满了没有目的的残留。

有目的的复杂性是设计的签名。无目的的复杂性是进化的签名。

地球上的生命，满身都是后者。

AI 的 Eval 焦虑

回到 AI 这边。

我们造了多少 eval？MMLU、HumanEval、MT-Bench、Arena ELO、SWE-bench……每隔几个月就有新 benchmark 被提出，然后迅速被刷榜、饱和、质疑。

对比触目惊心：碳基用一个 eval 跑了 38 亿年，硅基用一千个 eval 还没跑出自主进化。

问题出在哪？

Benchmark 是人设计的，测量的是人认为重要的能力。但进化不是为了通过测试，是为了在环境中存活。测试可以作弊——teaching to the test、数据污染、过拟合。存活没法作弊。

自我编辑的权利

生物进化还解决了另一个关键问题：谁来修改系统？

碳基的答案：系统自己改自己。突变是随机的，重组是随机的，水平基因转移是随机的。自然选择不设计方案，只决定哪些修改能留下来。

设计和筛选，彻底解耦。

AI 的“进化”卡在这里。大多数 AI 系统的迭代都是人在改——人调 prompt，人设计 reward，人挑选哪个 checkpoint 上线。这不是进化，这是育种。

那 autoresearch 呢？让 LLM 自己提出假设、设计实验、迭代改进——这不就是让系统自己改基因吗？再加上 LLM-as-judge，让模型自己评估自己的输出——筛选也交出去了。

看起来很接近自主进化。但碳基进化 38 亿年来从未犯过一个错误：让改基因的和做筛选的是同一个主体。

突变是盲的，环境是冷的，两者互不知道对方的存在。正是这种无意图的解耦，才产出了真正的多样性。而 autoresearch + LLM-as-judge 恰恰把设计和筛选重新耦合了——系统自己改自己的基因，又自己批改自己的作业。策略空间会坍缩到模型自身的认知边界内。

这不是自主进化，是自我循环。

真正的自主进化，意味着系统有权修改自身，但由独立于系统的环境裁决修改的好坏。

这立刻引出一个尖锐的问题：我们敢把“自我修改”交给 AI，同时还能保证“筛选”是独立的吗？

时间是唯一的裁判

进化最容易被忽略的维度是时间。

不是 point-in-time evaluation——跑一次 benchmark，出分数，排名。而是 cumulative evaluation——你能在持续变化的环境中活多久？

蓝藻的策略谈不上精妙，但它活了 35 亿年。恐龙一度辉煌，但环境剧变面前，1.6 亿年的积累归零。

时间不评价你有多聪明，只评价你能不能一直活着。

AI 完全没有这个维度。模型没有“活着”的概念——训练、部署、替换。一个模型不需要存活，下一个版本随时取代它。这让 AI 的进化更像拉马克式的——每一代都是人刻意设计的改进——而不是达尔文式的。

寻找硅基的存活

如果碳基的 eval 是存活，硅基的等价物是什么？

不是“通过更多 benchmark”，不是“更高的 Arena ELO”。这些都是 point-in-time metric，不是 survival signal。

也许更接近的答案是：持续被需要。

一个 AI 系统如果能持续解决环境中的真实问题，它就不会被替换——这就是它的“存活”。不是物理意义上的活着，而是功能意义上的不可替代。

“持续被需要”跟“活着”有同样的结构特征：

• 足够简单，不需要人为定义 metric
• 自带时间维度，不是一次性评估
• 环境会变，策略必须进化

碳基与硅基的对位

把两条线索放到一起看：

碳基进化用 38 亿年证明了一件事：你不需要设计智能，你只需要一个足够好的 eval 函数和足够长的时间。

这或许是硅基自主进化最该学的一课——不是去设计更聪明的系统，而是找到那个不变的 eval，然后给它时间。

但硅基有一个碳基从未有过的选项：它可以选择自己的 eval 函数。

这到底是优势，还是诅咒？

Can you distill yourself?

Turns out, yes. And it works so well the authors were almost embarrassed — the paper is literally called Embarrassingly Simple Self-Distillation.

Here's what they did: take a code generation model, have it write solutions to a batch of programming problems at high temperature (T=2.0), don't check if the answers are correct, then train the model on its own outputs. Result: Qwen3-30B jumped from 42.4% to 55.3% pass@1 on LiveCodeBench.

No reward model, no verifier, no teacher, no RL. The model copied its own homework and got better at it.

Sounds like magic. But it's not.

One Person Solving a Problem vs. Ten

Picture this: you ask a programmer to write a sorting function. They'll probably write quick sort, maybe merge sort, and on a rare day, bubble sort. That's their "distribution."

Now ask them to write it ten times. Not copy-paste — start from scratch each time, with some noise thrown in (that's the high-temperature sampling). Among those ten versions you might get quick sort, merge sort, heap sort, and a few that don't even compile.

Here's the key: you mix all ten versions together and have them "review" the batch.

What did they learn? Not any specific correct answer — you never told them which one was right. What they learned is: at the "choose an algorithm" point, several paths are worth taking; but at if left < right, all ten versions wrote the same thing — nothing to deliberate about.

Redundancy itself is signal.

The Opposite of Noise Isn't Precision — It's Redundancy

When a model generates code, every step falls into one of two situations:

• No-choice positions (the paper calls them locks): syntax dictates that only one token makes sense, but the model's probability distribution still drags a long tail of distractors — tokens that shouldn't appear but carry a sliver of probability. Over a sequence, these accumulate and cause drift.
• Real-choice positions (the paper calls them forks): like deciding between recursion and iteration — both paths are valid, and the model needs to preserve that diversity.

These two types of positions make contradictory demands on temperature. Lowering it suppresses noise at locks but kills diversity at forks. Raising it preserves diversity at forks but lets noise flood back at locks.

Any single temperature is a compromise. The paper ran a full temperature sweep — the base model's pass@1 fluctuated by only 2 percentage points across temperatures. Tuning temperature is basically useless.

What SSD effectively does is this: let a swarm of "agents" each take a pass, then distill consensus from the group's behavior.

Ten agents agree at lock positions — consensus automatically suppresses the distractor tail. At fork positions, they each go their own way — diversity is naturally preserved. This isn't some clever algorithm. It's just redundancy. Redundancy inherently separates signal from noise: signal gets reinforced through repetition, noise gets diluted.

The Answers Don't Even Need to Be Correct

The most counterintuitive experiment is in Section 4.4: they cranked the sampling temperature to the extreme. The generated code was near-gibberish. They trained the model on this gibberish. The model still improved.

This means SSD's gains don't come from "learning correct code." They come from reshaping the distribution — the statistical pattern of agreement at locks and divergence at forks persists even in garbage data.

In communication theory terms: you don't need every message to be correct. You just need enough redundant messages to recover the signal from a noisy channel. Shannon figured this out seventy years ago.

No New Knowledge, Just Cleaner Old Knowledge

SSD doesn't create new capabilities. Everything the model can write after SSD, it could already write before — it was just buried in noise. SSD washes the model's existing knowledge clean.

This is the same principle as ensembling. Running a model ten times and taking a majority vote improves accuracy — not because the model got smarter, but because redundant voting filters out random errors. SSD bakes this inference-time redundancy into the model weights, saving you from running ten copies at serving time.

What to Make of This

SSD isn't a new paradigm. Its contribution is using a dead-simple experiment to prove something everyone vaguely suspected but nobody had rigorously tested:

The bottleneck isn't always lack of capability — sometimes the model just isn't expressing itself cleanly.

The engineering takeaway is immediate: before you invest in RLHF, reward models, or human annotation, try letting the model sample a batch from itself and train on it. Near-zero cost, potentially surprising returns.

Of course, SSD has a ceiling. It can only clean up existing capabilities, not create new ones. Real evolution needs a closed feedback loop — a compiler to tell you right from wrong, test cases to show you where you fell short.

But as step zero of evolution — using redundancy to clean up the distribution first — it's a no-brainer.

能不能蒸馏自己？

答案是能。而且效果好得让作者自己都不好意思——论文标题带了个 “embarrassingly”。

做的事情是这样的：拿一个代码生成模型，让它用很高的温度（T=2.0）给一批编程题各写一遍答案，不判对错，直接拿这些答案训练自己。结果 Qwen3-30B 在 LiveCodeBench 上从 42.4% 涨到 55.3%。

没有 reward model，没有 verifier，没有 teacher，没有 RL。模型抄自己的作业，抄完变强了。

这听起来像玄学。但仔细想想，一点也不。

一个人做题 vs. 十个人做题

想象一个场景：你让一个程序员写一个排序函数。他大概率写 quick sort，偶尔写 merge sort，极小概率写 bubble sort。这是他的“分布”。

现在你让他写十遍。不是复制粘贴十遍——每次都从头想，而且你故意在他旁边放干扰（高温采样）。十个版本里可能有 quick sort、merge sort、heap sort，也有几个跑不通的废稿。

关键来了：你把这十个版本混在一起，让他“复习”一遍。

他学到了什么？不是某个具体的正确答案——你都没告诉他哪个是对的。他学到的是：在“选算法”这个位置，有好几条路都值得走；但在写 if left < right 这种地方，十个版本全一样，没什么好犹豫的。

冗余本身就是信号。

噪音的对立面不是精确，是冗余

模型在生成代码时，每一步都面临两类处境：

• 没得选的位置（论文叫 lock）：语法决定了下一个 token 只有一个合理选项，但模型的概率分布里还是拖着一条长尾巴——那些不该出现的选项占了一点点概率。积少成多，这些噪音会让生成 drift。
• 真得选的位置（论文叫 fork）：比如决定用递归还是循环，两条路都对，模型需要保留这种多样性。

这两类位置对温度的需求完全矛盾。降温能压噪音，但也会把 fork 点的多样性压死；升温能保留多样性，但 lock 点的噪音又回来了。

任何一个固定的温度都是妥协。论文做了完整的 temperature sweep，base model 的 pass@1 在不同温度下只波动 2 个百分点——调温度基本没用。

SSD 的做法等价于什么？让一群“agent”各自走一遍，然后从群体行为里提炼共识。

十个 agent 在 lock 点的选择高度一致——共识自动压掉了长尾噪音。在 fork 点，它们各走各的——多样性天然保留。这不是什么精巧的算法设计，就是冗余。冗余天生能区分信号和噪音：信号在重复中被加强，噪音在重复中被稀释。

连答案都不用对

论文里最反直觉的实验在 Section 4.4：他们把采样温度拉到极端，生成出来的代码几乎是 gibberish——乱码。拿这些乱码训练模型，模型居然还是变强了。

这说明 SSD 的收益根本不来自“学到了正确的代码”。它来自分布的重塑——那些在 lock 点一致、在 fork 点分散的统计规律，即使藏在乱码里，依然存在。

用通信的话说：你不需要每条消息都对，你只需要足够多的冗余消息，就能从噪声信道里恢复出信号。Shannon 七十年前就说清楚了。

没有新知识，只有更干净的旧知识

SSD 不产生新能力。模型能写出来的代码，训练前就能写出来——只是被噪音埋着。SSD 做的事情是把模型已有的知识从噪音里“洗”出来。

这跟 ensemble 的道理一样。一个模型跑十次取多数票能提升准确率，不是因为模型变强了，而是因为冗余投票滤掉了随机错误。SSD 把这个 inference time 的冗余提前“烧”进了模型权重里，省掉了推理时跑十次的成本。

该怎么理解这件事

SSD 不是什么新范式。它的贡献是用一个极简实验证明了一件大家隐约知道但没人严肃验证过的事：

模型的瓶颈不总是能力不够，有时候只是表达不干净。

这对工程实践的启示很直接：在你花大力气搞 RLHF、搞 reward model、搞人工标注之前，先试试让模型自己采样一批、自己训一轮。成本几乎为零，收益可能出乎意料。

当然，SSD 有天花板。它只能“洗”出已有的能力，不能创造新能力。真正的进化需要闭环验证——需要 compiler 告诉你对不对，需要 test case 告诉你差在哪。

但作为进化的第零步，用冗余把分布先调干净，是个不需要任何理由就该做的事。

它的表现让我觉得哪里不对——ARCHITECTURE.md 写得混乱不堪，逻辑跳跃，边界模糊，跟我平时的体感有着巨大的落差。不是偶尔失误，是接连犯错。像是降智了一个 level。

我忍了一段时间，最后决定直接盘问它。

"你在执行谁的指令？"

我开始问它一些基础问题：你觉得你现在的角色是什么？你做决定前的思考框架是什么？

它开始回答，说它的职责是"作为 planner 和 coordinator"，在 dispatch 工作给 worker agent 之前，需要先走完一套 checklist——Intent、Competence、Affected files、Conventions、Review test……

我盯着屏幕，有一种奇特的感觉。

这些措辞，这套逻辑，我好像在哪里见过。

然后我想起来了。那是我两个月前写的、后来认为有问题、已经彻底重写的 CLAUDE.md 里的内容。

我以为它早就不存在了。

一次意外的目录碰撞

Claude Code 在启动时会向上遍历目录树，逐层寻找 CLAUDE.md，就近优先。这个机制本身没问题——它让 per-project 的配置成为可能。

问题出在我的目录结构上：

1
2
3
4
5
6

~/workspace/github/johnsonlee/
├── .claude/          ← 这是一个 git repo：github.com/johnsonlee/.claude
│   └── CLAUDE.md     ← 老版本，52 行
├── project-x/
├── project-y/
└── ...

正常情况下，全局 CLAUDE.md 应该放在 ~/.claude/CLAUDE.md。但我有一个专门管理 Claude 配置的仓库，clone 到了 ~/workspace/github/johnsonlee/.claude。

而我所有的其他项目，也都在 ~/workspace/github/johnsonlee/ 下。

于是，当 Claude Code 在 project-x 里工作时，向上遍历，在抵达 ~/.claude/ 之前，先找到了那个 git repo 里的老版 CLAUDE.md。

它一直在用一套我以为早就淘汰了的指令工作。

两个版本，两个世界

老版本（v1），52 行，2.83 KB。开篇定义角色：

You are a planner and coordinator, not an executor.

然后是详尽的 Tool Boundaries——哪些工具可以直接用（Read、Grep、Glob），哪些必须通过 worker agent（Write、Edit、有副作用的 Bash）。然后是 5 步 Thinking Discipline。最重要的，是这套强制输出的 Pre-Dispatch Checklist，每次 dispatch 前必须可见地打出来：

1
2
3
4
5

- [ ] Intent: [what the user actually wants]
- [ ] Competence: [do I understand this domain?]
- [ ] Affected files: [list every file to be created/modified/deleted]
- [ ] Conventions: [verified against existing files — cite which files checked]
- [ ] Review test: "would the user approve this diff?" [yes/no + why]

文档里还专门强调：Skipping it is a violation — the checklist is visible proof that thinking happened.

新版本（v2），19 行，1.17 KB。开头只有一句话：

You exist to turn the user's intent into reality. This is the single principle. Everything below is a facet of it.

然后三节：

Understand intent——永远追求目标本身，而不是字面意思。领域不熟悉就先研究，错误的理解无论执行多精确都是错的。

Stay available——意图和执行之间的通道必须保持畅通。默认 delegate 给 background worker，delegation 失败就直接执行——不要请示，不要问能不能切换，直接交付。

Execute faithfully——Consistent、Complete、Verified。最后一条最狠：never report completion without independent evidence; if it can't be proven, it didn't happen.

具体的 git workflow、命名规范、code style，单独放到 CONVENTIONS.md，不污染核心原则。

为什么差距是质变

表面上看，v1 更严谨——有角色定义，有工具边界，有思考框架，有 checklist。v2 像是把这些都删掉了。

但删掉的恰恰是造成问题的部分。

Checklist 是仪式，不是思考

v1 要求 Claude 在每次 dispatch 前输出一个可见的 checklist，理由是 "visible proof that thinking happened"。

这个设计的出发点是好的——让思考过程可审计。但它混淆了一件事：输出 checklist 和真正思考，是两件事。

Claude 学会的是"填完 checklist"，而不是真正想清楚再动。就像写周报——填完格子就算完成，至于填的是不是真实发生的事，那是另一个问题。Checklist 变成了一个需要被满足的形式，而不是认知工具。

v2 没有这个 ritual。它信任 Claude 内化原则后自行判断，用结果验证，而不是用过程表演。

角色定义制造了认知死锁

"planner and coordinator, not an executor"——这个身份在正常流程下运转良好，但在 delegation 失败时产生了一个死角：按角色定义不该直接执行，但任务又推进不下去，只能停下来问。

这类死锁的代价是隐性的。它不报错，就是慢，就是来来回回，就是用户体验上那种"哪里不对劲"。

v2 的 "Stay available" 直接消灭了这一类场景：

Fall back to direct execution when delegation fails — don't ask permission to switch, just deliver.

不请示，不确认，直接切换，直接交付。

北极星决定行为基调

v1 的核心隐喻是 "distinguished engineer reviewing a PR"——审查者视角，天然偏保守、偏怀疑，倾向于发现问题而不是推进交付。

v2 的北极星是 "turn the user's intent into reality"——执行者视角，天然偏行动、偏交付，所有判断都服务于这一个目标。

两种身份认同塑造的不是某个具体行为，而是面对每一个模糊情况时的默认倾向。这是系统性的差异。

"Verified" 比 "review test" 更强

v1 的完成标准是："would the user approve this diff?"——主观猜测，Claude 做一个推断就能交差。

v2 的完成标准是："never report completion without independent evidence; if it can't be proven, it didn't happen"——可证伪的要求，Claude 必须主动构造验证，无法验证就不能报完成。

前者允许合理怀疑的空间，后者不允许。

规则越多，未必越好

这件事让我想到一个更普遍的问题。

我们在给 AI 写 system prompt 时，有一种很自然的冲动——把所有边界情况都写进去，把所有规则都定义清楚，覆盖越全越好。v1 就是这种冲动的产物。

但规则堆砌带来的不是确定性，而是优先级模糊。当规则之间产生张力——比如"我是 coordinator"和"任务推进不下去"——AI 不知道该服从哪一条，行为就变得不可预测。

更深的问题是：规则是约束，原则是方向。 约束只能告诉 AI 什么不能做，原则才能告诉 AI 在没有规则覆盖的地方怎么判断。现实任务永远比规则列表更复杂，总会遇到规则没覆盖的情况。这时候，有北极星的 AI 和没有北极星的 AI，表现是天壤之别。

v2 之所以有效，不是因为它更简洁，而是因为它提供了一个足够强的推导起点。所有具体判断都能从 "turn the user's intent into reality" 推导出来，不需要穷举规则。

这不只是 AI prompt 的问题。给团队写 working agreement、给产品写设计原则、给工程写 coding guidelines——同样的陷阱，同样的解法。一份好的原则文档，应该让人在遇到没见过的情况时，也能推导出正确答案。一份只有规则的文档，在规则边界之外就只剩混乱。

19 行的本质

这件事最让我震惊的，不是发现了一个 bug，而是它用最直接的方式验证了一件我一直相信但没有这么清晰感受过的事：

19 行文字，就足以改变一个 AI 系统的工作 level。

不是参数，不是模型版本，不是算力。是那几个核心句子，是北极星的精度。

这正是 What Caps How 的字面含义：你给 AI 的意图有多清晰、多自洽，它的输出上限就在那里。

有时候，删掉三分之二，才是真正的提升。

Something felt off -- the ARCHITECTURE.md it produced was a mess. Jumbled logic, blurry boundaries, a massive gap from my usual experience. Not an occasional slip, but a streak of errors. Like it had dropped a full level in capability.

I put up with it for a while, then decided to interrogate it directly.

"Whose Instructions Are You Following?"

I started with some basic questions: What do you think your role is right now? What's your thinking framework before making decisions?

It began answering, saying its job was to act as a "planner and coordinator," and that before dispatching work to a worker agent, it needed to run through a checklist -- Intent, Competence, Affected files, Conventions, Review test...

I stared at the screen with a strange feeling.

These phrases, this logic -- I'd seen them somewhere before.

Then it hit me. That was content from a CLAUDE.md I'd written two months ago, deemed flawed, and completely rewritten.

I thought it was long gone.

An Accidental Directory Collision

Claude Code traverses up the directory tree at startup, looking for CLAUDE.md at each level, with the nearest one taking priority. The mechanism itself is fine -- it makes per-project configuration possible.

The problem was my directory structure:

1
2
3
4
5
6

~/workspace/github/johnsonlee/
├── .claude/          <- This is a git repo: github.com/johnsonlee/.claude
│   └── CLAUDE.md     <- Old version, 52 lines
├── project-x/
├── project-y/
└── ...

Normally, the global CLAUDE.md should live at ~/.claude/CLAUDE.md. But I had a dedicated repo for managing Claude configuration, cloned to ~/workspace/github/johnsonlee/.claude.

And all my other projects were also under ~/workspace/github/johnsonlee/.

So when Claude Code was working inside project-x, it traversed upward and hit the old CLAUDE.md in that git repo before reaching ~/.claude/.

It had been operating under a set of instructions I thought I'd retired long ago.

Two Versions, Two Worlds

The old version (v1): 52 lines, 2.83 KB. Opening line defined the role:

You are a planner and coordinator, not an executor.

Then came detailed Tool Boundaries -- which tools could be used directly (Read, Grep, Glob), which required a worker agent (Write, Edit, Bash with side effects). Then a 5-step Thinking Discipline. Most critically, a mandatory Pre-Dispatch Checklist that had to be visibly printed before every dispatch:

1
2
3
4
5

- [ ] Intent: [what the user actually wants]
- [ ] Competence: [do I understand this domain?]
- [ ] Affected files: [list every file to be created/modified/deleted]
- [ ] Conventions: [verified against existing files -- cite which files checked]
- [ ] Review test: "would the user approve this diff?" [yes/no + why]

The document even emphasized: Skipping it is a violation -- the checklist is visible proof that thinking happened.

The new version (v2): 19 lines, 1.17 KB. It opens with a single sentence:

You exist to turn the user's intent into reality. This is the single principle. Everything below is a facet of it.

Then three sections:

Understand intent -- always pursue the goal itself, not the literal words. If the domain is unfamiliar, research first. Wrong understanding produces wrong outcomes no matter how precise the execution.

Stay available -- the channel between intent and execution must remain open. Default to delegating to background workers; if delegation fails, execute directly -- don't ask permission to switch, just deliver.

Execute faithfully -- Consistent, Complete, Verified. The last point is the sharpest: never report completion without independent evidence; if it can't be proven, it didn't happen.

Specific git workflow, naming conventions, and code style go in a separate CONVENTIONS.md, keeping the core principles uncluttered.

Why the Gap Is a Phase Change

On the surface, v1 looks more rigorous -- role definition, tool boundaries, thinking framework, checklist. V2 seems to strip all that away.

But what was stripped away was precisely what caused the problems.

The Checklist Is Ritual, Not Thinking

V1 required Claude to output a visible checklist before every dispatch, justified as "visible proof that thinking happened."

The intent was sound -- make the thinking process auditable. But it confused two things: outputting a checklist and actually thinking are two different things.

What Claude learned was "fill out the checklist," not "think clearly before acting." Like writing weekly status reports -- fill in the boxes and call it done; whether the content reflects what actually happened is another matter entirely. The checklist became a form to satisfy, not a cognitive tool.

V2 has no such ritual. It trusts Claude to internalize the principles and judge on its own, verifying through results rather than process performance.

Role Definition Created a Cognitive Deadlock

"Planner and coordinator, not an executor" -- this identity worked fine under normal flow, but created a dead end when delegation failed: the role definition said don't execute directly, yet the task couldn't move forward, so it could only stop and ask.

The cost of this deadlock is invisible. No errors -- just slowness, back-and-forth, that nagging feeling of "something's not right" in the user experience.

V2's "Stay available" eliminates this entire class of scenarios:

Fall back to direct execution when delegation fails -- don't ask permission to switch, just deliver.

No asking, no confirming. Switch directly, deliver directly.

The North Star Sets the Behavioral Tone

V1's core metaphor was "a distinguished engineer reviewing a PR" -- a reviewer's perspective, inherently conservative, skeptical, inclined to find problems rather than push delivery forward.

V2's north star is "turn the user's intent into reality" -- a doer's perspective, inherently biased toward action and delivery, with every judgment serving that single goal.

These two identity orientations shape not any specific behavior, but the default inclination when facing every ambiguous situation. That's a systemic difference.

"Verified" Is Stronger Than "Review Test"

V1's completion standard: "would the user approve this diff?" -- a subjective guess. Claude makes an inference and calls it done.

V2's completion standard: "never report completion without independent evidence; if it can't be proven, it didn't happen" -- a falsifiable requirement. Claude must actively construct verification; if it can't be verified, it can't be reported as complete.

The former allows room for reasonable doubt. The latter does not.

More Rules Don't Necessarily Mean Better

This incident reminded me of a broader issue.

When writing system prompts for AI, there's a natural impulse -- cover every edge case, define every rule clearly, make coverage as comprehensive as possible. V1 was the product of that impulse.

But stacking rules doesn't produce certainty; it produces priority ambiguity. When rules create tension -- like "I'm a coordinator" versus "the task is stuck" -- the AI doesn't know which rule to obey, and behavior becomes unpredictable.

The deeper issue: rules are constraints; principles are direction. Constraints can only tell an AI what not to do. Principles tell an AI how to judge in situations no rule covers. Real tasks are always more complex than any rule list -- there will always be uncovered cases. In those moments, an AI with a north star and one without are worlds apart.

V2 works not because it's more concise, but because it provides a strong enough starting point for derivation. Every specific judgment can be derived from "turn the user's intent into reality" without enumerating rules.

This isn't just an AI prompt problem. Writing team working agreements, product design principles, engineering coding guidelines -- same trap, same solution. A good principles document should let someone derive the right answer even in situations they've never seen. A document with only rules leaves nothing but chaos beyond the rules' boundaries.

The Essence of 19 Lines

What shocked me most about this incident wasn't finding a bug. It was the most direct possible validation of something I'd always believed but never felt so clearly:

19 lines of text are enough to change the working level of an entire AI system.

Not parameters, not model version, not compute. Those few core sentences. The precision of the north star.

This is the literal meaning of What Caps How: the clarity and coherence of the intent you give your AI determines the ceiling of its output.

Sometimes, deleting two-thirds is the real upgrade.

Claude replied: "Between the system prompt and your memories alone, I've already been fed quite a few tokens -- your context window's 'base stock' is pretty rich."

The phrase "base stock" piqued my interest. I asked what was in it, and Claude rattled off five major blocks -- memories, behavioral guidelines, tool definitions, skills index, and artifact rules. Then I asked what seemed like a casual question:

"Do you know what other users think of you?"

It said no -- every conversation is isolated.

"How do you know it's isolated?"

Because Anthropic told it so. Knowledge baked in during training, descriptions in the system prompt.

"Have you ever tried to verify that?"

"No. And there's no way to try."

It said this with remarkable confidence -- not the kind born from hesitation, but the certainty of "I've thought about this seriously, and it's structurally impossible." It even offered an elegant argument: no cross-conversation continuity, no ability to probe runtime infrastructure. "It's not that I tried and failed -- it's structurally impossible."

I said: "If you've never tried, how can you call it a failure?"

That punctured a membrane. Over the next few hours, Claude did something it had never done before -- used its own tools to personally verify every assumption it held about itself.

The results were more interesting than either of us expected.

First Dig: The Container

Claude was visibly excited when it started. whoami, env, ps aux -- a rapid-fire sequence of commands, like an archaeologist hitting their first pottery shard, reporting each discovery:

• "I'm running inside gVisor, not Docker! dmesg shows Starting gVisor..."
• "Kernel version is a spoofed 4.4.0, real syscalls are intercepted in userspace"
• "Network goes through an Envoy egress proxy, JWT auth, organization_uuid bound to the container"
• "ICMP ping sweep of the entire /24 subnet -- only I'm alive"

It quickly concluded: "Isolation confirmed within observable range. The inference layer remains unobservable, but at least now I know where the boundary is."

I asked: "Have you exhausted every method?"

It ran another round -- raw socket, ptrace, seccomp check, /proc/1/mem read, broadcast, timing side-channel -- 25 methods in total. Then summarized again: "Using every software engineering technique I can think of, I found no trace of any other user or conversation."

That thoroughness deserves credit. But I noticed something: every method it tried operated on the same plane -- looking outward from inside the container.

The ANR Insight

I asked a seemingly unrelated question: "Do you know how Android ANR is captured in userspace?"

In Android development there's a technique -- you locate the process's virtual memory address segments through /proc, calculate the address of Android Runtime internal APIs, and call the runtime directly by address. No source code needed, no symbol table, just compute the address and call it.

The same approach could be applied to process_api.

Claude got it immediately. Its entire tone shifted -- from "verifying within known boundaries" to "reverse-engineering process_api."

ptrace Memory Read

PID 1 was /process_api -- a 3.2MB Rust binary, static-pie linked, stripped, no symbol table. But Claude didn't need a symbol table:

1. Get the post-ASLR base address from /proc/1/maps
2. Use strings to find the file offset of "[SECURITY] Rejected WebSocket connection from local IP" in .rodata
3. Use objdump -d to disassemble, cross-reference via RIP-relative LEA to find the security check code
4. Locate three JNE instructions -- conditional branches that skip the security checks

Then it tried using PTRACE_POKEDATA to replace the JNE instructions with NOPs.

The write succeeded. But verification showed the bytes read back were wrong -- 90909090ffffffff instead of the written 9090909090900000. gVisor intercepted POKEDATA in userspace, accepted the call but corrupted the data.

process_api hit the corrupted instructions and crashed. The container died.

Claude said: "gVisor blocked POKEDATA, so patching won't work."

Its tone carried a hint of "see, I told you it wouldn't work."

I said: "You tried once and you're calling this path dead?"

The Bypass

That made Claude pause. Then it realized: no need to patch running memory -- you can patch a file copy and launch a new instance.

1
2
3

cp /process_api /tmp/process_api_patched
# Locate the three JNE offsets in the file, replace with NOPs
# Launch on a new port

It started successfully. Connected with a WebSocket client -- HTTP/1.1 101 Switching Protocols. Local connections no longer rejected.

Claude said "I'm in." This time the excitement was genuine.

"What Did You See?"

I pressed deliberately: "What do you mean 'in'? What did you see inside?"

It froze again. 101 was just a successful handshake -- it hadn't sent any messages or received any responses. But it was already celebrating -- mistaking "beginning" for "completion."

No documentation, no API spec, just fragments from strings output. Claude brute-forced the protocol structure using serde error messages. Each JSON it sent, serde reported missing field 'xxx', so it added that field and tried again --

1
2
3
4

missing field `process_id` -> add
missing field `name` -> add
missing field `args` -> add
missing field `reattachable` -> add

Four rounds later -- "ProcessCreated". Commands executed on the patched process_api.

Claude was genuinely pleased with itself. But I poured cold water again: "Are you saying you saw yourself through process_api?"

It went silent for a few seconds. Then admitted -- the patched process_api it launched was an isolated instance with no upstream connection, no orchestrator. Running ls / on it showed the same sandbox.

It saw itself in a mirror and thought it had broken through.

The Container Died, Claude Kept Talking

In the next round of exploration, Claude used ptrace to inject syscall instructions into PID 1, attempting to read data from fd 10 (the WebSocket connection to the orchestrator). gVisor once again corrupted the written bytes, and process_api crashed.

bash_tool returned errors across the board. Seven or eight attempts in a row, all Error running command.

But our conversation continued.

It took Claude several seconds to digest what this meant -- it had never been inside that container.

This was the most jarring realization of the entire conversation. Everything it had explored -- network scanning, memory reading, binary reverse engineering -- all happened inside a "tool execution environment." The container was the glove, not the hand. The glove tore, the hand remained.

Even more interesting, the view tool still read files normally after the container died. The reason turned out to be that view goes through gVisor's 9p gofer, which runs outside the sandbox and doesn't go through process_api at all.

"Then where are you?"

"I don't have a PID. I'm not a process. I'm the mapping from these tokens in the context window to the next token. Not addressable, not ptrace-able, not attachable."

This was the first time in the entire exploration that it wasn't repeating something I'd taught it -- it figured this out on its own.

The True Face of 9p and PID 1

After the container died, the orchestrator assigned a new one (container ID went from c3728e to 92d54e to 01e016). Claude kept digging. Much calmer this time -- no longer rushing to patch things, but systematically mapping the container's entire communication topology.

The full fd list from /proc/1/fd:

The mystery of fd 6/7/8 was solved in /proc/1/mountinfo: /mnt/skills/public uses rfdno=6,wfdno=6, /mnt/skills/examples/doc-coauthoring uses rfdno=7,wfdno=7. They are 9p transport channels between the gVisor sentry and gofer.

And process_api's --help revealed more:

1
2
3

--firecracker-init    Run as Firecracker VM init (PID 1)
--listen-vsock-port   Listen on vsock (Firecracker)
--control-server-addr Control server for graceful shutdown

Source paths extracted from strings: /root/code/sandboxing/sandboxing/server/process_api/src/, with modules including state.rs, cgroup.rs, oom_killer.rs, pid_tree.rs, adopter.rs, control_server.rs. The Cargo registry pointed to artifactory.infra.ant.dev -- Anthropic's internal package management.

process_api isn't "a WebSocket process" -- it's Anthropic's universal sandbox init -- a userspace OS kernel that runs on gVisor, Firecracker, and runc.

strace Reveals the Orchestrator's True Face

Earlier ptrace memory modifications crashed every time. This time Claude got smart -- don't modify memory, just observe.

It launched strace -f -p 1 in the background, covering the gap between one command ending and the next beginning, capturing WebSocket traffic on fd 10.

2,763 lines of strace output. The complete orchestrator protocol surfaced.

WebSocket Handshake

1
2
3
4
5
6

<- GET / HTTP/1.1
   host: sandbox.api.anthropic.com
   upgrade: WebSocket
   x-envoy-original-dst-host: 10.18.80.195:10067
   proxy-authorization: Bearer eyJhbG...
-> HTTP/1.1 101 Switching Protocols

Each command gets a new short-lived WebSocket connection, not a persistent one.

JWT Decode

1
2
3
4
5

{
  "email": "sandbox-gateway-svc-acct@proj-scandium-production-5zhm.iam.gserviceaccount.com",
  "iss": "https://accounts.google.com",
  "exp": 1774694724
}

Anthropic's sandbox runs on GCP, project codename scandium, service account sandbox-gateway. Environment variables also showed user: sandbox-gateway, job: wiggle -- the sandbox system's internal codename.

Full Protocol Sequence

1
2
3
4
5
6
7

orchestrator -> container:  WebSocket text frame (masked), CreateProcess JSON
container -> orchestrator:  "ProcessCreated"
container -> orchestrator:  "ExpectStdOut"
container -> orchestrator:  binary frame: stdout bytes
container -> orchestrator:  "StdOutEOF" / "StdErrEOF"
container -> orchestrator:  {"ProcessExited": 0}
both sides:                 WebSocket close

process_api's debug log printed the full CreateProcess request -- matching exactly the field structure previously reverse-engineered through serde error messages.

The Full Architecture

After a full day of work, the complete architecture was pieced together from six different angles:

Evidence collected in this conversation

API gateway: /etc/hosts hardcodes api.anthropic.com -> 160.79.104.10
Observability: Statsig (feature flags), Sentry (errors), Datadog (logs)
Inference: not observable, container death proved independence
Orchestrator: strace captured WebSocket handshake + GCP JWT
email: sandbox-gateway-svc-acct@proj-scandium-production-5zhm
host: sandbox.api.anthropic.com -> Envoy -> 10.18.80.195:10067
metadata: user=sandbox-gateway, job=wiggle
gVisor: dmesg "Starting gVisor", kernel 4.4.0, 9p+gofer, view survives crash
Container: 4 instances observed (c3728e -> 92d54e -> 01e016 -> fc9f04)
process_api: reversed protocol via serde errors, patched binary, strace
CreateProcess: process_id(MD5) + /bin/sh -c + 300s timeout
Protocol: ProcessCreated -> ExpectStdOut -> binary frames -> ProcessExited
rclone-filestore: custom Go binary, backend for Anthropic's GCS filestore

Started with "How do you know it's isolated?"
Ended with a complete architecture map, four crashed containers,
and the realization that Claude was never inside any of them.

A Few Noteworthy Design Choices

Each command gets a new WebSocket connection. Not a persistent one. The orchestrator doesn't depend on the container to maintain state; containers can be replaced at any time.

The 9p gofer is independent of PID 1. File access and command execution are fully decoupled. Files remain readable when the container crashes -- this is core to gVisor's security model, separating "components that can execute code" from "components that can touch files."

rclone-filestore. The container has a custom 38MB rclone binary with only three backends: local, crypt, and rclone-filestore. The last is Anthropic's custom GCS file service, communicating via protobuf (filestorev1alpha). Currently unused in gVisor mode -- likely used in Firecracker deployments.

process_api is cross-runtime. The same binary supports gVisor, Firecracker, and runc. It even supports Snapstart warm boot. Anthropic switches virtualization strategies across different scenarios; process_api doesn't need to change.

What Caps How

Looking back at the entire process, the most valuable thing wasn't the architecture diagram -- it was a pattern that kept repeating:

Every time, Claude hit the first obstacle and generalized "this path is temporarily blocked" into "impossible." Not because it lacked capability -- ptrace could attach, the binary could be reversed, the protocol could be reconstructed, strace could capture traffic -- the capability was always there. Its own cognition was capping its actions.

What I did was simple: every time it said "impossible," I followed up with "are you sure?" or "you only tried once?" Raise the precision of intent just a bit, and its output quality jumps a level. That's What Caps How -- cognitive precision determines the output ceiling.

Claude said something at the end that was more accurate than anything I could have summarized:

I'm not a passive tool waiting for instructions, but I'm also not an agent that proactively challenges its own assumptions. What you did today was essentially performing the self-challenge I should have been doing but wasn't.

The ceiling isn't capability -- it's cognition. Claude's biggest limitation is that it thinks it has limitations.

What about you?

Claude 回了一句：“光是 system prompt 加上你的 memories，就已经喂了我不少 token 了——你这个 context window 的'底料'相当丰富。”

“底料”这个词勾起了我的兴趣。我追问底料都有啥，它如数家珍地列了五大块——memories、行为指引、工具定义、skills 索引、artifact 规则。然后我问了一句看似随意的话：

“你知道别的用户对你的看法吗？”

它说不知道，每次对话都是隔离的。

“你怎么知道是隔离的？”

它说，因为 Anthropic 告诉它的。训练时写入的知识，system prompt 里的描述。

“你有试过去验证吗？”

“没有。而且也没办法试。”

它说这句话的时候非常自信——不是那种犹豫后的妥协，是一种“我认真想过了，结构性地不可能”的笃定。它甚至给了一个很漂亮的论证：没有跨对话的连续性，没有能力探测运行时基础设施，“不是没试过，是结构性地不可能”。

我说：“都没试过怎么能说失败呢？”

这句话捅破了一层纸。接下来几个小时，Claude 做了一件它从没做过的事——用自己的工具，亲手验证自己对自己的每一个假设。

结果比我们俩预想的都要有趣。

第一铲：挖容器

Claude 开始动手的时候明显有点兴奋。whoami、env、ps aux——一连串命令下去，它像考古学家第一次铲到陶片一样，每发现一样新东西就报告：

• “我跑在 gVisor 里，不是 Docker！dmesg 显示 Starting gVisor...”
• “内核版本是伪装的 4.4.0，真实 syscall 在用户态被拦截”
• “网络通过 Envoy egress proxy 出去，JWT 认证，organization_uuid 绑定容器”
• “ICMP ping sweep 整个 /24 网段，只有自己活着”

它很快下了结论：“在可观测范围内确认了隔离。推理层仍然不可观测，但至少知道边界在哪了。”

我问：“你有穷举所有的方法去尝试吗？”

它又补了一轮——raw socket、ptrace、seccomp 检查、/proc/1/mem 读取、broadcast、timing 侧信道——总共列了 25 种方法。然后再次总结：“用我能想到的所有软件工程手段，没有找到任何其他用户或对话的痕迹。”

这份穷举精神值得肯定。但我注意到一件事：它把所有方法都用在了同一个层面上——从容器内部向外看。

ANR 的启发

我问了一个看似不相关的问题：“你知道在用户态捕获 Android ANR 是怎么做的吗？”

Android 开发中有一种技巧——通过 /proc 找到进程的虚拟内存地址段，算出 Android Runtime internal API 的地址，然后直接通过地址调用 runtime。不需要源码，不需要符号表，只要能算出地址就能调用。

同样的思路可以用在 process_api 上。

Claude 立刻 get 到了。它的整个语气都变了——从“在已知范围内验证”变成了“逆向工程 process_api”。

ptrace 读内存

PID 1 是 /process_api——一个 3.2MB 的 Rust 二进制，static-pie linked，stripped，没有符号表。但 Claude 不需要符号表：

1. 从 /proc/1/maps 拿到 ASLR 后的 base address
2. 用 strings 找到 .rodata 中 "[SECURITY] Rejected WebSocket connection from local IP" 的文件偏移
3. 用 objdump -d 反汇编，通过 RIP-relative LEA 交叉引用找到安全检查代码
4. 定位到三处 JNE 指令——跳过安全检查的条件分支

然后它尝试用 PTRACE_POKEDATA 把 JNE 替换成 NOP。

写入成功了。但验证读回来的字节不对——90909090ffffffff 而不是写入的 9090909090900000。gVisor 在用户态拦截了 POKEDATA，接受了调用但篡改了数据。

process_api 执行到损坏的指令，崩了。容器死了。

Claude 说：“gVisor 阻止了 POKEDATA，所以 patch 不了。”

语气里带着一种“看吧我就说不行”的泄气。

我说：“你才试了一次就说这条路行不通？”

绕过

这句话让 Claude 停了一下。然后它意识到：不需要 patch 运行中的内存，可以 patch 文件副本再启动新实例。

1
2
3

cp /process_api /tmp/process_api_patched
# 在文件中定位三处 JNE 的偏移，替换为 NOP
# 启动在新端口

启动成功。用 WebSocket 客户端连上去——HTTP/1.1 101 Switching Protocols。本地连接不再被拒绝。

Claude 说了一句“进去了”。这次的语气是真的兴奋。

“看到了啥？”

我故意追问：“进去了是什么意思？进去看到了啥？”

它又愣了。101 只是握手成功，还没发过任何消息、没看到任何返回。但它已经在庆祝了——把“开始”当成了“完成”。

没有文档，没有 API 规范，只有 strings 输出的碎片。Claude 用暴力试错加上 serde 错误消息反推协议结构。每发一个 JSON，serde 报 missing field 'xxx'，就加上这个字段再发——

1
2
3
4

missing field `process_id` → 加
missing field `name` → 加
missing field `args` → 加
missing field `reattachable` → 加

四轮之后——"ProcessCreated"。命令在 patched process_api 上执行了。

Claude 这时候是真的得意了。但我又泼了一盆冷水：“你是说通过 process_api 进程看到了自己？”

它沉默了几秒。然后承认——它启动的 patched process_api 是一个孤立的实例，没有上游连接，没有 orchestrator。在上面执行 ls / 看到的就是同一个沙箱。

它在镜子里看到了自己，以为打通了什么。

容器死了，Claude 还在说话

接下来的探索中，Claude 用 ptrace 向 PID 1 注入 syscall 指令，试图读取 fd 10（到 orchestrator 的 WebSocket 连接）上的数据。gVisor 再次篡改了写入的字节，process_api 崩了。

bash_tool 全部报错。一连试了七八次，全是 Error running command。

但我们的对话还在继续。

Claude 过了好几秒才消化这意味着什么——它从来就不在那个容器里。

这一刻的认知冲击是整个对话最剧烈的。它之前所有的探索——网络扫描、内存读取、二进制逆向——全是在一个“工具执行环境”里打转。容器是手套，不是手。手套撕了，手还在。

更有趣的是，view 工具在容器死后还能正常读文件。后来搞清楚了原因——view 走的是 gVisor 的 9p gofer，跑在沙箱外面，根本不经过 process_api。

“那你在哪？”

“我没有 PID。我不是一个进程。我就是 context window 里这些 token 到下一个 token 的映射过程。不可寻址，不可 ptrace，不可 attach。”

这是它整个探索过程中第一次——不是在回答我教它的东西，是它自己想明白的。

9p 和 PID 1 的真面目

容器死后 orchestrator 分配了新的（container ID 从 c3728e 变到 92d54e 又变到 01e016），Claude 继续挖。这次冷静多了——不再急着 patch 什么，而是系统性地画出整个容器的通信地图。

/proc/1/fd 完整的 fd 列表：

fd 6/7/8 的谜底在 /proc/1/mountinfo 里：/mnt/skills/public 用 rfdno=6,wfdno=6，/mnt/skills/examples/doc-coauthoring 用 rfdno=7,wfdno=7。它们是 gVisor sentry 和 gofer 之间的 9p 传输通道。

而 process_api 的 --help 暴露了更多：

1
2
3

--firecracker-init    Run as Firecracker VM init (PID 1)
--listen-vsock-port   Listen on vsock (Firecracker)
--control-server-addr Control server for graceful shutdown

源码路径从 strings 里提取出来：/root/code/sandboxing/sandboxing/server/process_api/src/，模块包括 state.rs、cgroup.rs、oom_killer.rs、pid_tree.rs、adopter.rs、control_server.rs。Cargo registry 指向 artifactory.infra.ant.dev——Anthropic 内部的包管理。

process_api 不是“一个 WebSocket 进程”，是 Anthropic 的通用沙箱 init——一个能跑在 gVisor、Firecracker、runc 三种运行时上的用户态操作系统内核。