Architecture 2.0架构 2.0
Designing AI-Assisted Loops for Computing Systems为计算系统设计 AI 辅助循环
Preface前言
Computer architecture has a new question. For decades the field asked what machines should be built for new kinds of computation. Capable AI systems now pose the reverse question of what those systems can do for the practice of architecture itself. The reversal changes the scarce engineering act. When plausible artifacts become cheap to generate, the hard problem is no longer only producing a candidate accelerator, kernel, floorplan, or design report. It is deciding which artifact-backed claim deserves belief, comparison, rejection, escalation, or commitment. This book is about that shift from artifact scarcity to commitment scarcity. The destination is to make AI-assisted architecture claims credible, comparable, and reviewable. The mechanism is to treat the design loop as a first-class architectural object alongside the artifact. The loop is becoming part of the contribution, which means it must expose visible state, allowed actions, evidence, rejection authority, and commitment boundaries. The artifact still matters. The loop matters because it determines how that artifact is produced, evaluated, rejected, and justified. The goal is that a reader can specify, run, audit, and improve an AI-assisted architecture design loop without confusing a generated artifact for a commitment-ready result.计算机架构领域迎来了一个新问题。几十年来，该领域一直在探讨应为新型计算构建什么样的机器。如今，功能强大的 AI 系统提出了一个反向问题：这些系统能为架构实践本身做些什么？这种反转改变了稀缺的工程行为。当合理的制品变得易于生成时，难题不再仅仅是产出一个候选加速器、内核、平面布局或设计报告。真正的难题在于：决定哪项基于制品的声明值得信任、比较、拒绝、升级或承诺。本书旨在探讨从“制品稀缺”向“承诺稀缺”的转变。其目标是使 AI 辅助的架构声明变得可信、可比且可审查。其机制是将设计循环视为与制品同等重要的“一等”架构对象。循环正在成为贡献的一部分，这意味着它必须暴露可见的状态、允许的操作、证据、拒绝权限以及承诺边界。制品依然重要，但循环之所以重要，是因为它决定了该制品是如何被产生、评估、拒绝和论证的。本书的目标是让读者能够定义、运行、审计和改进 AI 辅助的架构设计循环，而不会将生成的制品误认为是已准备好承诺的结果。
Architecture 2.0 governs the design loop so that an AI-produced claim carries the evidence, boundaries, and rejection conditions a human needs before commitment.架构 2.0 对设计循环进行治理，从而确保 AI 生成的声明能够携带人类在做出承诺前所需的证据、边界和拒绝条件。
The book tests that discipline through two recurring objects. The lighthouse prompt carries the aspiration, a compact request for a low-power RISC-V subsystem for mobile extended reality (XR) that sounds like it should be answerable by a future AI design system. The AlphaChip war story is the grounded reality, a real, celebrated, contested AI-assisted chip-placement result (Mirhoseini et al. 2021) whose public record exposed what the field could not yet replay, share, or adjudicate. One shows the reach. The other shows the debt.本书通过两个反复出现的对象来检验这一准则。灯塔提示（lighthouse prompt）承载了愿景，即针对移动扩展现实（XR）的低功耗 RISC-V 子系统发出的简洁请求，这听起来像是未来的 AI 设计系统应该能够回答的问题。AlphaChip 的故事则是基于现实的案例，这是一个真实、著名且存在争议的 AI 辅助芯片布局成果（Mirhoseini 等人，2021 年），其公开记录揭示了该领域尚无法重现、共享或裁决的内容。前者展示了愿景的广度，后者展示了现实的缺口。
The shortest diagnosis is that architecture loops are becoming rejection-bound, not generation-bound. AI can increase the number of plausible candidates much faster than it increases the number of candidates a team can trust, reject, or commit to. Architecture 2.0 begins where that imbalance becomes the design problem. The question is not only how to propose more systems. It is how to build loops that can say no cheaply, independently, and early enough that any later yes carries architectural weight.最简短的诊断是：架构循环正变得受制于“拒绝”，而非受制于“生成”。AI 增加合理候选方案的速度，远超团队能够信任、拒绝或承诺这些方案的速度。架构 2.0 正是在这种失衡成为设计难题时开始的。问题不仅在于如何提出更多的系统，更在于如何构建能够廉价、独立且尽早“说不”的循环，从而使随后的任何“说是”都具备架构上的分量。
The broader shift is already underway. A recent Architecture 2.0 foundations article by Reddi and Yazdanbakhsh argues why AI agents belong in modern system design and sets out the vision, history, and capability horizons that follow (Janapa Reddi and Yazdanbakhsh 2025). This book takes up the next question and treats it on its own terms. Suppose an AI-assisted loop proposes a faster accelerator configuration, a lower-energy kernel, or a plausible physical-design move. What state did it inspect, what actions could change that state, and what evidence could reject the result before anyone commits? Those questions are the practical core of Architecture 2.0.更广泛的转变已经在进行中。Reddi 和 Yazdanbakhsh 在一篇关于架构 2.0 基础的文章中论述了 AI 代理为何应纳入现代系统设计，并阐述了随之而来的愿景、历史和能力前景（Janapa Reddi 和 Yazdanbakhsh 2025）。本书承接这一问题并独立探讨：假设一个 AI 辅助循环提出了一种更快的加速器配置、一个低能耗内核或一个合理的物理设计方案，它检查了什么状态？哪些操作可以改变该状态？在任何人做出承诺之前，有什么证据可以拒绝该结果？这些问题正是架构 2.0 的实践核心。
That credibility question is familiar from a different field. Machine learning systems faced the same problem a decade ago. Claims were everywhere and comparison was hard. The answer was not a better model. It was measurement discipline, requiring shared workloads, defined scenarios, provenance, and rules that made a performance claim mean the same thing across systems. Benchmarking efforts mattered because they turned enthusiasm into evidence. Architecture 2.0 needs the same move one level up. The task is to make AI-assisted architecture claims as credible, comparable, and reviewable as the community learned to make AI-systems claims. One caveat travels with the analogy. Benchmarks earn comparability by fixing tasks, metrics, and submission rules, so two loop claims are directly comparable only when those match; when they do not, the design-loop card this book develops, a compact record of the loop behind a claim, still makes a claim reviewable and contrastable, which is often the achievable goal at the loop level.这种可信度问题在其他领域也曾出现。十年前，机器学习系统面临着同样的问题：声明随处可见，但难以比较。答案并非更好的模型，而是测量准则，即要求共享工作负载、定义场景、溯源以及制定规则，使性能声明在不同系统间具有相同的含义。基准测试（Benchmarking）之所以重要，是因为它们将热情转化为了证据。架构 2.0 需要在更高维度上采取同样的举措。任务是使 AI 辅助的架构声明像社区在 AI 系统声明方面所做的那样，变得可信、可比且可审查。该类比有一个注意事项：基准测试通过固定任务、指标和提交规则来获得可比性，因此只有在这些条件匹配时，两个循环声明才具有直接可比性；如果不匹配，本书开发的“设计循环卡”（一种记录循环背后信息的简洁记录）仍能使声明变得可审查和可对比，这往往是循环层面能够实现的目标。
AI methods are powerful, but architecture progress depends on hardware and software interfaces, workload definitions, toolchains, evidence standards, and human judgment, which is why the unit of analysis here is the design loop, not the isolated model.AI 方法虽然强大，但架构的进步依赖于硬件和软件接口、工作负载定义、工具链、证据标准和人类判断，这就是为什么此处的分析单元是“设计循环”，而非孤立的模型。
That position also explains why the book sits between electronic design automation (EDA) and software rather than inside either one. EDA teaches architecture the discipline of executable artifacts, constraints, tool feedback, and signoff. Software teaches architecture the discipline of continuous testing, observability, rollback, and operational drift. Architecture 2.0 needs both, but it cannot collapse into either. Its object is the architecture-level loop that decides what should be built before a design has the formal closure of EDA or the cheap reversibility of software. The middle discipline in Table 1 names what the loop must borrow from each neighbor, and what it must refuse to inherit unchanged.这一立场也解释了为什么本书位于电子设计自动化（EDA）和软件领域之间，而不是属于其中任何一个。EDA 教会了架构关于可执行制品、约束、工具反馈和签核的准则。软件教会了架构关于持续测试、可观测性、回滚和操作漂移的准则。架构 2.0 需要两者，但不能沦为其中任何一个。其研究对象是架构层面的循环，它在设计尚未获得 EDA 的形式化闭环或软件的廉价可逆性之前，决定了应该构建什么。表 1 中的中间学科列出了循环必须从每个邻近领域借鉴的内容，以及必须拒绝原封不动继承的内容。
| Neighboring practice | What it makes explicit | What Architecture 2.0 needs from it |
|---|---|---|
| Software and systems operations | Tests, traces, deployment telemetry, rollback, versioning, and drift. | Continuous evidence and operating discipline, without pretending hardware commitments are as reversible as software changes. |
| Computer architecture | Workload intent, abstraction, design spaces, hardware/software contracts, and quantitative tradeoffs. | A represented loop that connects intent to evidence before the artifact deserves commitment. |
| EDA and silicon signoff | Constraints, tool stages, violations, waivers, and high-commitment evidence. | Strong rejection authority and fidelity ladders, without waiting until every question has become a late physical-design problem. |
The point is not to relabel Architecture 2.0 as a hybrid of EDA and software. It is to preserve what architecture must own while borrowing EDA’s discipline and software’s feedback culture.重点不在于将架构 2.0 重新贴上 EDA 与软件混合体的标签，而在于保留架构必须拥有的核心，同时借鉴 EDA 的准则和软件的反馈文化。
The argument is therefore data-centric in a specific sense. The limiting question is not only which model or agent is used. It is which parts of architecture work are made observable, including workload traces, design artifacts, tool outputs, constraints, rejected candidates, failed runs, and the provenance that ties feedback to a decision. Data-driven methods become credible only when the data records the design loop, not just its successful endpoints.因此，这一论点在特定意义上是以数据为中心的。限制性问题不仅在于使用了哪种模型或代理，还在于架构工作的哪些部分变得可观测，包括工作负载跟踪、设计制品、工具输出、约束、被拒绝的候选方案、失败的运行，以及将反馈与决策联系起来的溯源信息。只有当数据记录了设计循环（而不仅仅是其成功的终点）时，数据驱动的方法才变得可信。
What follows is an operating framework, not a catalog. The field is moving quickly, and a catalog of today’s agents, tools, and benchmarks would age before it was useful. The durable contribution is a way to describe an architecture design loop, judge its evidence, and decide what the architect still owns. Architecture 2.0 is therefore not primarily a survey of current AI agents for computer architecture. Agents are the forcing function. The foundation is a set of durable principles for making architecture design loops representable, governable, evidence-bearing, rejectable, and improvable as methods become more capable. The faster-moving record of who is doing what belongs with the community now forming around this topic, tracked in the living resource list of Appendix C — Architecture 2.0 Resource Roles and Missing Infrastructure. The book keeps the parts meant to last.以下内容是一套操作框架，而非目录。该领域发展迅速，当下的代理、工具和基准测试目录在变得有用之前就会过时。本书的持久贡献在于提供了一种描述架构设计循环、判断其证据并决定架构师仍需负责哪些事项的方法。因此，架构 2.0 主要不是对当前计算机架构 AI 代理的调研。代理是驱动力，而基础是一套持久的原则，旨在随着方法能力的提升，使架构设计循环变得可表示、可治理、有证据支撑、可拒绝且可改进。关于谁在做什么的快速变化记录，属于围绕该主题形成的社区，详见附录 C“架构 2.0 资源角色与缺失的基础设施”中的实时资源列表。本书保留的是那些经久不衰的部分。
The recurring artifact is the design-loop card. Much like a model card in machine learning records the intended use of a model, a design-loop card records the intended use and boundaries of an AI-assisted architecture loop. The card is not a substitute for a paper, benchmark, simulator, or design review. It is the compact record that names the loop behind a claim, specifying the task, representation, environment, method role, feedback budget, evidence, negative traces, rejection authority, and human decision. The book develops those fields chapter by chapter, then collects the card and review rubric in Appendix B — Design-Loop Card and Review Rubric.反复出现的制品是“设计循环卡”。正如机器学习中的模型卡（model card）记录了模型的使用意图一样，设计循环卡记录了 AI 辅助架构循环的意图和边界。该卡片不能替代论文、基准测试、模拟器或设计评审。它是一份简洁的记录，指明了声明背后的循环，明确了任务、表示、环境、方法角色、反馈预算、证据、负面追踪、拒绝权限、承诺边界和人类决策。本书逐章展开这些字段，最后在附录 B“设计循环卡与评审准则”中汇总了卡片和评审准则。
Think of the card as a living document: before the loop runs, it acts as a loop contract; during the run, it collects an evidence ledger; and when finished, it defines the commitment boundary about what the evidence allows. The point of the vocabulary is not to multiply forms. It is to make one review object useful before, during, and after a loop turn.将该卡片视为一份动态文档：在循环运行前，它充当循环契约；在运行期间，它收集证据账本；完成后，它定义了证据所允许的承诺边界。这一词汇体系的目的不是增加形式，而是使同一个评审对象在循环周期的前、中、后期都能发挥作用。
The book’s central act is computing-system synthesis: turning architectural intent into defensible computing-system designs for chips, accelerators, memory systems, and the toolchains and workloads around them. Inside the book, system synthesis is shorthand for this architecture-level computing-system synthesis. Logic synthesis turns logic into circuits. High-level synthesis turns behavior into hardware. Program synthesis turns specifications into programs. System synthesis operates at the architecture level, where intent, constraints, representations, tools, feedback, evidence, and human judgment have to be coordinated before a design deserves commitment. The framework keeps returning to the same three questions, about state, action, and evidence, and later chapters give them reusable names, such as loop contracts, architecture environments, method roles, evidence ledgers, rejection authority, commitment boundaries, and design-loop cards.本书的核心行为是计算系统综合：将架构意图转化为可辩护的计算系统设计，涵盖芯片、加速器、存储系统以及围绕它们的工具链和工作负载。在本书中，“系统综合”是这种“架构级计算系统综合”的简称。逻辑综合将逻辑转化为电路；高级综合将行为转化为硬件；程序综合将规范转化为程序。系统综合在架构层面运行，在设计值得承诺之前，必须协调意图、约束、表示、工具、反馈、证据和人类判断。该框架不断回归到关于状态、动作和证据的三个相同问题，后续章节为它们赋予了可重用的名称，如循环契约、架构环境、方法角色、证据账本、拒绝权限、承诺边界和设计循环卡。
This boundary is deliberate. The book is not a proposal to replace EDA, verification, compiler and toolchain engineering, or systems operations with a general AI layer. It is also not a claim that a model owns an architecture decision once it emits a plausible artifact. Those practices supply the instruments, constraints, tests, reports, and deployment evidence that make rejection possible. The architectural question is how to represent those sources early enough that an AI-assisted loop can be inspected before a human accepts the commitment.这一边界是刻意设定的。本书并非提议用通用的 AI 层来取代 EDA、验证、编译器和工具链工程或系统运维。它也不是声称模型一旦输出合理的制品就拥有了架构决策权。这些实践提供了使拒绝成为可能的工具、约束、测试、报告和部署证据。架构问题在于如何尽早表示这些来源，以便在人类接受承诺之前可以检查 AI 辅助循环。
Book Structure书籍结构
The book is organized into ten chapters that build the Architecture 2.0 framework in a high-low-high arc, opening with framing, descending into mechanism, and returning to what the architect owns.本书分为十章，以“高-低-高”的弧线构建了架构 2.0 框架：从框架开始，深入到机制，最后回归到架构师的职责。
- 1 The Architecture 2.0 Moonshot frames the paradigm shift1. AI-assisted architecture is not a generic generation demo, but a new review problem around loop state, evidence, rejected alternatives, and human-owned commitment.1. 架构 2.0 的登月计划（The Architecture 2.0 Moonshot）构筑了范式转移。AI 辅助架构不是通用的生成演示，而是围绕循环状态、证据、被拒绝的替代方案以及人类拥有的承诺这一新的评审问题。
- 2 Why Classical Architecture Loops Strain diagnoses the scissors gap that can justify bounded AI assistance. Specialization, chiplets, software velocity, physical constraints, engineering cost, and verification make choices and evidence demands grow faster than the loop can evaluate, reject, revise, and commit.2. 为什么经典架构循环会吃力（Why Classical Architecture Loops Strain）诊断了可以证明有界 AI 辅助合理性的“剪刀差”。专业化、芯粒（chiplet）、软件速度、物理约束、工程成本和验证使得选择和证据需求增长的速度，超过了循环评估、拒绝、修订和承诺的能力。
- 3 Architectural Claims and Design Loops defines the reviewable architectural claim and design-loop ontology, then turns them into the design-loop card. Its fields include workload, baseline, design space, objective, constraints, evidence, rejection authority, commitment boundary, and human decision.3. 架构声明与设计循环（Architectural Claims and Design Loops）定义了可审查的架构声明和设计循环本体，并将其转化为设计循环卡。其字段包括工作负载、基准、设计空间、目标、约束、证据、拒绝权限、承诺边界和人类决策。
- 4 Representations and World Models asks what loop state can be recorded, replayed, and acted on, including representations, world models, sample cost, provenance, coverage, and negative traces.4. 表示与世界模型（Representations and World Models）探讨了哪些循环状态可以被记录、重现和操作，包括表示、世界模型、样本成本、溯源、覆盖率和负面追踪。
- 5 Tools as Architecture Environments asks where the loop can act, turning tool interfaces into environments with explicit legal actions, observations, feedback costs, invalid-action semantics, provenance, rejection paths, and commitment boundaries.5. 作为架构环境的工具（Tools as Architecture Environments）探讨了循环可以在何处操作，将工具接口转化为具有明确合法操作、观察、反馈成本、无效操作语义、溯源、拒绝路径和承诺边界的环境。
- 6 Method Roles: Generate, Predict, Optimize assigns AI methods to loop roles under feedback budgets, separating generation, prediction, optimization, critique, repair, verification, explanation, and coordination from architect-owned commitment.6. 方法角色：生成、预测、优化（Method Roles: Generate, Predict, Optimize）在反馈预算下为循环角色分配 AI 方法，将生成、预测、优化、批判、修复、验证、解释和协调与架构师拥有的承诺分离开来。
- 7 Feedback, Evidence, and Trust asks when a loop result has earned trust, tying feedback budgets, fidelity ladders, evidence ledgers, commitment levels, independent rejection, proxy-mismatch checks, and security, IP, license, export-control, and disclosure boundaries to the authority that can overturn a claim.7. 反馈、证据与信任（Feedback, Evidence, and Trust）探讨了循环结果何时获得信任，将反馈预算、保真度阶梯、证据账本、承诺级别、独立拒绝、代理失配检查以及安全、知识产权、许可、出口管制和披露边界，与可以推翻声明的权威机构挂钩。
- 8 Running the Lighthouse Loop runs one bounded turn of the lighthouse loop and records the receipt, including the surviving candidate, rejected alternatives, evidence boundary, commitment boundary, and next evidence required.8. 运行灯塔循环（Running the Lighthouse Loop）运行了一次灯塔循环的有界轮次并记录了接收情况，包括留存的候选方案、被拒绝的替代方案、证据边界、承诺边界以及所需的后续证据。
- 9 Loop Patterns Across the Stack compares loop patterns across the stack and makes the rejection-bound principle explicit, showing how method posture changes as feedback gets more expensive and commitments become harder to reverse.9. 跨栈循环模式（Loop Patterns Across the Stack）比较了跨栈的循环模式，并明确了“拒绝约束”原则，展示了随着反馈成本增加和承诺变得难以撤销，方法姿态如何变化。
- 10 What the Architect Owns returns to human ownership and field infrastructure, showing how commitment boundaries, tacit knowledge, rejection authority, redacted evidence, shared negative traces, standards, and accountability checks make AI-assisted loops comparable.10. 架构师拥有什么（What the Architect Owns）回归到人类所有权和领域基础设施，展示了承诺边界、隐性知识、拒绝权限、脱敏证据、共享负面追踪、标准和问责检查如何使 AI 辅助循环具有可比性。
1 The term is Thomas Kuhn’s, from The Structure of Scientific Revolutions (Kuhn 1962), where a paradigm shift replaces a field’s foundational assumptions rather than extending them incrementally. Here the claim is narrower. Architecture 2.0 changes the unit of work, who can act inside it, and how a result earns trust, rather than treating AI as a way to run the same manual loop faster.1. 该术语源自托马斯·库恩的《科学革命的结构》（Kuhn 1962），其中范式转移取代了领域的根本假设，而不是增量地扩展它们。在此，该声明的范围更窄。架构 2.0 改变了工作单元、谁可以在其中行动以及结果如何获得信任，而不是将 AI 视为一种更快运行相同手动循环的方式。
The book does not collect those pressure points in a final catch-all chapter. It distributes them across the arc, because each one tests the same discipline at a different loop boundary. Proprietary tool interfaces, adversarial evidence, field telemetry, feedback cost, model-side compute and energy use, organizational incentives, legal, IP, and export-control boundaries, and the training of new architects all ask whether the loop can expose enough evidence for a human commitment to remain accountable.本书并没有在最后一章全面汇总这些压力点，而是将它们分布在整个弧线中，因为每一个压力点都在不同的循环边界上测试相同的准则。专有工具接口、对抗性证据、现场遥测、反馈成本、模型端计算和能源使用、组织激励、法律、知识产权和出口管制边界，以及新架构师的培训，都在询问循环是否能暴露足够的证据，以使人类的承诺保持可问责性。
Who This Book Is For本书适合谁阅读
This is a compact synthesis for readers who already know computer architecture and want a framework for AI-native architectural practice. It assumes fluency in architecture and does not re-teach it. Here, fluency means being able to read a simulator, workload, or architecture paper, follow performance, energy, area, and software-contract tradeoffs, and recognize evidence from instruction-set interfaces, register-transfer-level artifacts, and EDA reports without needing the book to teach those foundations. It does not assume a machine-learning or reinforcement-learning background; the ML and RL ideas it borrows are glossed in margin footnotes at first use, so an architect can follow the argument without prior AI training. It is not a survey of today’s agents and tools, not a tutorial on building them, and not a forecast of future automation. It is an operating discipline for governing the design loops those tools run inside.这是一本为已经了解计算机架构并希望获得 AI 原生架构实践框架的读者准备的精简综述。它假设读者具备架构流利度，不会重新教授基础知识。在这里，流利度意味着能够阅读模拟器、工作负载或架构论文，理解性能、能耗、面积和软件契约权衡，并识别来自指令集接口、寄存器传输级（RTL）制品和 EDA 报告的证据，而无需本书教授这些基础。它不假设读者具备机器学习或强化学习背景；书中借鉴的 ML 和 RL 概念在首次使用时通过页边脚注进行了注释，因此架构师无需先前的 AI 培训即可跟上论点。它不是当前代理和工具的调研，不是构建它们的教程，也不是对未来自动化的预测。它是治理这些工具运行所在的设计循环的操作准则。
Within that scope, the book serves several readers. A graduate student entering the area should find the vocabulary and the lay of the land. A reviewer should find a way to ask what a project exposes and what could reject its result, not only what result it reports. A paper or project author should find a way to state the architectural claim so its evidence, missing fields, rejection conditions, and commitment boundary are visible. A practitioner should find a way to reason about where an agent may act and where the architect must still decide. If the book succeeds, each of these readers should be able to do something afterward that was harder before. They will be able to name a loop, judge its evidence, and state what remains an architect-owned commitment.在这一范围内，本书为多类读者服务。进入该领域的应届研究生可以找到词汇表和领域概览。评审人员可以找到一种方式来询问项目暴露了什么以及什么可以拒绝其结果，而不仅仅是询问它报告了什么结果。论文或项目作者可以找到一种方式来陈述架构声明，使其证据、缺失字段、拒绝条件和承诺边界可见。从业者可以找到一种方式来推理代理可以在哪里行动，以及架构师在哪些地方必须做出决策。如果本书成功，每一位读者在阅读后都应能完成一些以前更难做到的事情。他们将能够命名一个循环、判断其证据，并陈述什么是架构师拥有的承诺。
How to Read This Book如何阅读本书
Each chapter is framed by a guiding question and a short What this chapter gives you list of the moves you will be able to make. One running example, the lighthouse prompt of 1 The Architecture 2.0 Moonshot, a compact design request for a mobile XR subsystem, travels through the book as a shared example. Treat it as the book’s small mental simulator. Each return to the prompt activates a different slice of the loop, workload, ISA and software contract, compute organization, physical envelope, environment, method role, evidence, rejection, or human decision, so the framework stays attached to one concrete architecture obligation.每一章都由一个指导性问题和一个简短的“本章为你提供”列表组成，列出了你将能够采取的行动。一个贯穿始终的示例——第 1 章“架构 2.0 的登月计划”中的灯塔提示（一个针对移动 XR 子系统的简洁设计请求）——作为共享示例贯穿全书。将其视为本书的小型思维模拟器。每次回到该提示时，都会激活循环、工作负载、ISA 和软件契约、计算组织、物理包络、环境、方法角色、证据、拒绝或人类决策的不同切片，从而使框架始终与一个具体的架构义务挂钩。
That lighthouse is the ideal. To keep it honest, the book pairs it with a real counterpart that returns at key checkpoints. That counterpart is a war story drawn from AlphaChip, the most visible attempt at AI-designed hardware, and 1 The Architecture 2.0 Moonshot sets it up. The thread is a stress test, not a takedown. The lighthouse shows the architecture we could have, a represented loop aimed at an ambitious design. The war story shows the public reality the field is still learning to handle, where a landmark result can be useful, deployed, contested, and hard to adjudicate from the outside.灯塔是理想状态。为了保持诚实，本书将其与一个在关键检查点返回的真实对应物配对。该对应物是一个取自 AlphaChip 的故事，这是目前最引人注目的 AI 设计硬件尝试，第 1 章“架构 2.0 的登月计划”对其进行了铺垫。这条线索是一次压力测试，而非否定。灯塔展示了我们可以拥有的架构，即一个针对雄心勃勃的设计的表示循环。故事展示了该领域仍在学习处理的公共现实，其中一个里程碑式的成果可能是有用的、已部署的、存在争议的，且从外部难以裁决。
When the text or a figure draws a single agent, read it as a participant in the loop, not a claim about implementation. That participant might be one model, one tool-using agent, a workflow of models and scripts, or several specialized agents. The same test applies in every case. Each participant needs visible state, legal actions, evidence obligations, a rejection path, and an architect-owned commitment boundary.当文本或图表绘制单个代理时，请将其理解为循环中的参与者，而不是关于实现的声明。该参与者可能是一个模型、一个使用工具的代理、模型和脚本的工作流，或多个专业代理。同样的测试适用于每种情况。每个参与者都需要可见的状态、合法的操作、证据义务、拒绝路径和架构师拥有的承诺边界。
For a quick pass, read the Preface and 1 The Architecture 2.0 Moonshot, then skim the design-loop card in Appendix B — Design-Loop Card and Review Rubric. For a one-hour pass, read 2 Why Classical Architecture Loops Strain, 3 Architectural Claims and Design Loops, and 9 Loop Patterns Across the Stack to see why the loop becomes a first-class object of design alongside the artifact. For a first project pass, use Appendix A — Bootstrapping an Architecture 2.0 Loop to bound one loop before building a platform. For research review, read the chapters in order; the loop-role resource catalog and living link list in Appendix C — Architecture 2.0 Resource Roles and Missing Infrastructure show where the framework most needs better examples, tools, and evidence.若想快速通读，请阅读前言和第 1 章“架构 2.0 的登月计划”，然后浏览附录 B“设计循环卡与评审准则”中的设计循环卡。若想进行一小时的快速阅读，请阅读第 2 章“为什么经典架构循环会吃力”、第 3 章“架构声明与设计循环”和第 9 章“跨栈循环模式”，以了解为什么循环会成为与制品并列的一等设计对象。对于首次项目尝试，请使用附录 A“引导架构 2.0 循环”在构建平台之前限定一个循环。对于研究评审，请按顺序阅读各章节；附录 C“架构 2.0 资源角色与缺失的基础设施”中的循环角色资源目录和实时链接列表，展示了该框架最需要更好示例、工具和证据的地方。
For graduate students and new researchers, the practical advice is to start smaller than the tool wave suggests. Do not begin by choosing the newest agent and looking for a hardware target. Start with a claim a reviewer could reject, then name the workload slice, baseline, legal actions, feedback budget, negative traces, and human decision. A strong first contribution may be a better loop record, environment contract, workload packet, or rejection test, not only a better generator. In that sense, the first ownership milestone is a completed bootstrap loop and design-loop card, not a survey of every tool that might eventually act inside it.对于研究生和新研究人员，实用的建议是：从比工具浪潮所暗示的更小的规模开始。不要从选择最新的代理并寻找硬件目标开始。从评审人员可能拒绝的声明开始，然后命名工作负载切片、基准、合法操作、反馈预算、负面追踪和人类决策。一个强有力的首次贡献可能是一个更好的循环记录、环境契约、工作负载包或拒绝测试，而不仅仅是一个更好的生成器。从这个意义上说，第一个所有权里程碑是一个完成的引导循环和设计循环卡，而不是对最终可能在其中运行的每一个工具的调研。
Read the open research questions as paper and project frames, not as chapter summaries. A question leans toward ISCA, MICRO, HPCA, or ASPLOS when the artifact is an architecture method, evidence standard, workload, or design-loop result. It leans toward DAC, ICCAD, or DATE when the artifact changes an EDA flow, tool contract, or verification path. It leans toward MLSys, NeurIPS, or similar venues when the contribution is a learning method, benchmark, or evaluation protocol for AI-assisted design. The venue signal is secondary; the primary test is whether the work leaves behind a claim, evidence, rejection condition, and reusable artifact that another architect can inspect.将开放研究问题视为论文和项目框架，而不是章节总结。当制品是架构方法、证据标准、工作负载或设计循环结果时，问题倾向于 ISCA、MICRO、HPCA 或 ASPLOS。当制品改变 EDA 流程、工具契约或验证路径时，问题倾向于 DAC、ICCAD 或 DATE。当贡献是 AI 辅助设计的学习方法、基准测试或评估协议时，问题倾向于 MLSys、NeurIPS 或类似场所。场所信号是次要的；首要测试是该工作是否留下了另一个架构师可以检查的声明、证据、拒绝条件和可重用制品。
AI systems do not remove the architect. They raise what the architect must be good at. The work moves upward, toward intent, representation, evidence standards, rejection authority, and accountability for the final decision. The opportunity is not to wait for a system that designs a computer from a single sentence. It is to make the represented, instrumented, evidence-bearing design loop a first-class part of architectural practice, alongside the artifact it produces, and to build loops worthy of an architect’s judgment.AI 系统不会取代架构师，它们提升了架构师必须擅长的领域。工作向上移动，向意图、表示、证据标准、拒绝权限和最终决策的问责制移动。机会不在于等待一个能从一句话设计出计算机的系统，而在于使表示清晰、具备工具支持、承载证据的设计循环成为架构实践的一等部分（与它产生的制品并列），并构建值得架构师判断的循环。
Vijay Janapa ReddiVijay Janapa Reddi