从ReAct到工程闭环：AI Agent底层架构拆解与EDA场景的落地约束

一、一个被跳过的问题：Agent到底怎么跑起来

2026年，AI Agent成了EDA行业最热的关键词。Cadence的ChipStack、Synopsys的AgentEngineer、Siemens的Fuse，三家在GTC上集体站台。

技术社区里讨论最多的是"哪家模型更强""谁先做到L4"。但如果你真的动手搭过一个Agent系统，会发现一个更底层的问题被跳过了：Agent的架构，到底怎么支撑一个真实工程任务从开始到结束？

这个问题不解决，讨论"谁在画饼"没有意义。因为画饼的根源往往不在模型，而在架构。

本文从Agent底层技术架构切入，拆解ReAct、Plan-and-Execute、多Agent编排等主流范式的工程约束，然后看EDA场景为什么需要"工程闭环"架构，以及EDA365·AI在这个方向上的实践。不吹不黑，尽量讲清楚技术逻辑。

二、主流Agent架构范式：各自的工程约束

2.1 ReAct：最简范式，也最容易失控

ReAct（Reasoning + Acting）是当前最普遍的Agent架构。核心逻辑是一个循环：

erlang 复制代码

Thought → Action → Observation → Thought → ...

LLM先"想"一步，调用一个工具，观察结果，再想下一步。代码层面大致是这样：

python 复制代码

while not done:
    thought = llm.reason(context)
    action = llm.select_action(thought, tools)
    observation = execute(action)
    context.append(observation)

这个架构的优点是简单、灵活、不需要预先定义完整工作流。但它有三个硬约束：

第一，上下文窗口是有限的。 每一步的Thought、Action、Observation都要塞进context。一个复杂任务跑几十步，context就爆了。Anthropic在工程博客里提到，给Agent暴露过多细粒度工具反而会降低性能------不是因为模型不行，是因为context被工具定义占满了。

第二，没有全局规划。 ReAct是贪心的，每一步只看当前最优。在需要多步协调的任务里，它容易走进死胡同。

第三，错误会累积。 一步观察错了，后面全错。没有验证机制的话，Agent会在错误路径上越走越远。

2.2 Plan-and-Execute：先规划，再执行

Plan-and-Execute把架构拆成两个阶段：Planner先拆解任务，Executor逐步执行。

python 复制代码

plan = planner.decompose(task)
for step in plan:
    result = executor.run(step)
    if not verify(result):
        plan = planner.replan(task, step, result)

这个架构解决了ReAct的"没有全局规划"问题，但引入了新约束：

Planner的规划质量决定上限。 如果任务领域知识太深，Planner拆不对，后面全白搭。
Replan的成本高。 每次重规划都要重新推理，延迟和token消耗都上去了。
验证环节是瓶颈。 没有可靠的verify函数，整个架构就是空中楼阁。

2.3 多Agent编排：能力解耦，但协调成本高

多Agent架构把不同职责拆给不同Agent：一个负责规划，一个负责执行，一个负责验证，一个负责检索。

python 复制代码

orchestrator = Orchestrator(agents=[planner, executor, verifier, retriever])
result = orchestrator.run(task)

这种架构在复杂任务上表现更好，因为每个Agent的context更聚焦。但它引入了新的工程问题：

通信开销。 Agent之间传递信息需要序列化/反序列化，延迟叠加。
状态一致性。 多个Agent操作同一份工程数据，如何保证状态同步？
调试困难。 一个任务失败，你很难定位是哪个Agent、哪一步出的问题。

2.4 三种范式的对比

架构	优势	硬约束	适用场景
ReAct	简单灵活	context有限、无全局规划、错误累积	短任务、探索性任务
Plan-and-Execute	有全局规划	Planner质量决定上限、Replan成本高	中等复杂度、可拆解任务
多Agent编排	能力解耦、context聚焦	通信开销、状态一致性、调试难	高复杂度、多职责任务

三、EDA场景的特殊约束：为什么通用架构不够用

上面的架构在信息检索、代码生成等场景已经跑得不错。但EDA场景有几个特殊约束，让通用架构直接套用会出问题。

3.1 幻觉的代价不对称

在对话场景，LLM幻觉只是尴尬。在RTL生成场景，一个错误的信号连接可能导致流片失败，代价是几千万。Cadence的ChipStack引入"Mental Model"（心智模型），本质原因就是：LLM单独缺乏可靠产出高质量RTL所需的深层理解能力。

3.2 工程数据的结构化程度高，但语义复杂

PCB设计涉及器件库、封装、网络表、设计规则、DFM约束------这些都是结构化数据。但它们的语义关系复杂：一个器件的选型依赖库存、交期、价格、替代料；一条走线的宽度依赖电流、阻抗、工艺能力。

通用Agent架构里，这些关系要么塞进context（爆），要么做成工具调用（碎）。

3.3 验证必须是确定性的

LLM可以"提出方案"，但不能"验证方案"。Siemens的Fuse Agent做了一个值得关注的设计：自我验证（Self-Verifying）------Agent把每一步决策路由回确定性的、基于物理的EDA引擎进行校验，确认无误后才继续。

这个设计的工程含义是：验证环节必须由确定性工具完成，不能交给LLM。

四、工程闭环架构：EDA365·AI的实践

基于上述约束，EDA365·AI的架构设计可以概括为"三层解耦 + 工程闭环"。

4.1 三层解耦

复制代码

┌─────────────────────────────────────┐
│  编排层（Orchestration）             │
│  - 任务拆解、Agent调度、状态管理      │
├─────────────────────────────────────┤
│  工具层（Tool Layer）                │
│  - SailWind/PADS 设计引擎            │
│  - DFM审查、建库、供应链接口          │
├─────────────────────────────────────┤
│  模型层（Model Layer）               │
│  - 熠瓴AI大模型                      │
│  - 领域微调、结构化知识注入           │
└─────────────────────────────────────┘

模型层选择自研而非直接调通用API，核心考虑是领域数据的私有性和工程场景的稳定性要求。

工具层的设计遵循一个原则：不是把API包装成"工具"，而是把工程操作封装成"可被Agent调用的能力"。区别在于：API是细粒度的（读一个寄存器、写一个字段），能力是工程语义的（"完成这个模块的布局""检查这条走线的DFM合规性"）。

编排层是差异化最大的部分。它的编排逻辑不是"对话-响应"，而是"设计-验证-反馈"的闭环。

4.2 闭环的核心：前向约束

传统流程中，设计决策和下游约束是脱节的：

markdown 复制代码

设计 → 仿真 → 采购 → 制造
              ↑
         发现问题，返工

EDA365·AI的闭环逻辑是：把下游约束提前到设计阶段。

复制代码

设计 ←→ 验证 ←→ 反馈
  ↑              │
  └──────────────┘
  布局阶段调用库存/交期数据
  铺铜阶段用DFM规则拦截制造风险

这和Cadence的Mental Model在思路上有相似之处：都是用结构化数据锚定Agent行为。但EDA365·AI锚定的不仅是设计规则，还有供应链和制造现实。

4.3 数据闭环：从"人脑经验"到"系统资产"

闭环架构的另一个工程价值是知识沉淀：

复制代码

训练 → 推理 → 应用 → 优化
  ↑                    │
  └────────────────────┘
  每一次设计定稿
  成功的布局策略、设计规范、模块级经验
  沉淀回系统

这解决了一个真实的工程痛点：企业的设计能力高度依赖个别资深工程师。智能体把"人脑里的经验"变成"系统里的资产"。

五、落地数据：架构设计的回报

架构的优劣最终要用数据说话。PCB设计智能体的实测数据：

场景	传统耗时	AI耗时
217器件BGA模块	约60分钟	约1分钟
1085元器件/4573引脚工控板	超1000分钟	约15分钟
千脚以上BGA建库	人工	效率5倍，出错率降80%+
PCB预审报价	人工	效率+55%，偏差-25%

这些数据的工程意义不在于"快"，而在于闭环架构让"快速迭代"成为可能。如果一次布局推演只需要1分钟，工程师就可以探索几十种方案，而不是在一种方案上反复微调。

六、小结

回到开头的问题：EDA Agent的架构应该长什么样？

从技术约束出发，可以得出几个判断：

ReAct适合短任务，不适合长链路工程任务。 context有限、无全局规划、错误累积，这三个约束在EDA场景会被放大。
Plan-and-Execute的瓶颈在验证。 没有确定性验证环节，规划再好在工程上也落不了地。
多Agent编排的难点在状态一致性。 工程数据的版本、依赖关系复杂，多Agent并发操作需要严格的同步机制。
工程闭环是EDA场景的必然选择。 不是"更聪明的对话模型"，而是"可验证的工程闭环"------每一步操作都产生可验证的输出，每一个下游约束都提前到设计阶段。

模型能力会持续进步，但模型只是Agent的"大脑"。在EDA场景里，决定Agent能否真正落地的，是它有没有"手脚"（工具层）、"记忆"（结构化知识）和"纪律"（验证闭环）。

本文从Agent底层架构出发，分析了EDA场景的工程约束和架构选择。文中涉及的EDA365·AI实践数据来自公开资料，具体技术细节以官方文档为准。