ARTICLE · 1209303
LongCore AI:让 Agent 真正进入芯片研发工作流
LongCore AI让 AI 写一段 SystemVerilog，已经不难。让它进入一个真实的芯片项目，读懂设计、接入工具、分析失败，再把结论交给工程师复核，才是更难的一步。
一段代码看起来合理，并不意味着它能在现有工程中编译通过；一个用例成功运行，也不意味着它验证了真正重要的需求。
芯片研发对 AI 的要求，最终会落到一个具体问题上：它能否沿着真实的工程流程，把任务推进到有证据、可复现、能验收的结果？
围绕这个问题，LongCore AI 提出了一条工程化路径：以 Skills 驱动工作流，以 MCP 连接 EDA 基础设施，以专业 Agent 分工协作，再用 Benchmark 持续检验能力。
从代码生成走向工程闭环，是芯片 Agent 落地的关键。示意图来自所附演示材料。
01 从“生成一段代码”到“完成一项任务”
先看一个典型场景：工程师希望分析一次仿真失败，并给出修复建议。
真正有用的结果，不只是一句“可能存在时序问题”。它需要回答：失败发生在哪个测试、哪个随机种子、哪个时间点？预期行为来自哪条设计要求？实际行为在哪个信号上开始偏离？问题出在 RTL、激励、检查器，还是环境配置？修改以后，如何验证原来的失败已经消失？
这些问题串起了设计理解、工具执行、日志解析、波形分析和回归验证。任何一环缺失，都可能让一个听起来合理的答案失去工程价值。
这也是芯片 Agent 进入真实项目时常见的几道门槛：
- 上下文不完整。
只有代码片段，没有模块层次、接口约束、协议规则和项目规范。 - 任务缺少连续性。
能生成一次答案，却不能保存中间状态、处理工具报错、继续下一轮分析。 - 工具没有接通。
仿真、Lint、形式化和波形分析仍需要工程师反复搬运输入输出。 - 结果缺少检验。
没有明确的任务标准，很难判断方案是否可靠、升级是否带来退步。
因此，评估芯片 Agent 的起点，应当从“它能生成什么”，转向“它能完成什么，以及凭什么证明完成了”。
02 Skills：把工程经验变成可执行流程
在 LongCore AI 的方案中，Skill 是承载芯片工程方法的基本单元。
一个完整的 Skill，需要定义任务何时触发、接受什么输入、按什么顺序执行、产出什么结果，以及遇到异常时如何处理。中间状态和执行日志也应当保留下来，供后续任务复用和工程师检查。
以调试 Skill 为例，调用一次仿真器只是其中一步。完整流程还应包括确认失败环境、提取关键日志、选择波形信号与时间窗口、关联 RTL 和设计要求、形成根因假设，并给出复现与验证方法。
Skill 的价值，是把工程师反复使用的判断顺序和操作方法，沉淀成可复用、可检查的工作单元。
围绕前端设计验证，LongCore AI 将这些能力组织为几类：
- 设计理解：
梳理 RTL 层次、端口、接口、数据流与模块边界，建立项目上下文。 - UVM 验证：
理解现有 Testbench，生成与环境匹配的 Sequence 和 Testcase，分析覆盖缺口。 - 形式化验证：
从设计要求中提取属性，编写断言，分析反例与证明状态。 - 调试诊断：
解析编译和仿真日志，追踪波形与信号关系，形成有证据的修复建议。 - 工程检查：
对接编译、Lint、可综合性检查等流程，并按任务需要辅助分析约束和 PPA 相关结果。
执行时，Agent 接收工程师的目标，将其拆成子任务，调度相应 Skill，并根据工具反馈继续推进。最终交付的应当包括工程结论、关键证据和执行轨迹。
03 MCP：连接工具，也要落实工程边界
Skills 要在真实环境中执行，就需要访问项目文件、仿真服务器、EDA 工具和版本管理系统。MCP（Model Context Protocol）在这套方案中承担标准化连接层的角色。
可以把两者的分工理解为：
MCP 提供工具访问通道，Skills 组织完成任务的方法。Agent 根据目标与反馈，决定何时使用哪些能力。
例如，一个仿真服务可以通过 MCP 暴露任务提交、状态查询和结果读取等接口。设计理解、验证和调试 Agent 可以复用这些接口，减少重复建设。
但标准化连接仍需要具体适配。不同工具的启动参数、许可证、任务队列、日志格式和结果目录，都需要在项目环境中明确约定。
同样，MCP 本身并不自动保证“数据不出内网”或企业级安全。 项目数据如何流转，取决于模型与服务的部署位置、发送给模型的内容、网络策略，以及权限和审计机制。
对芯片团队而言，接入方案需要把这些边界落实到执行中：哪些目录可以读取，哪些操作可以执行，哪些结果可以返回，哪些步骤需要工程师确认。这样，连接能力才能变成可管理的工程能力。
04 四类专业 Agent，围绕同一个项目协作
LongCore AI 将前端设计验证中的核心任务，划分为四类专业角色。
Design Understanding Agent：先建立共同理解
设计理解 Agent 负责梳理模块结构、接口关系、数据流和协议约束，为其他角色提供上下文。
这里有一个关键边界：设计规格描述预期行为，RTL 展示当前实现。两者出现差异时，应当记录并交由工程师判断，不能直接把现有 RTL 当成需求依据。
UVM Agent：沿着现有验证环境补齐缺口
UVM Agent 的工作需要贴合项目已有的 Agent、Driver、Monitor、Scoreboard 和配置机制，再生成或调整激励与测试。
评价重点也应落到任务本身：新增用例能否运行，检查机制是否有效，是否覆盖了计划中的场景，是否帮助暴露了设计或验证环境的问题。
Formal Agent：把需求变成可检查的属性
Formal Agent 负责辅助提取验证属性、生成断言、分析反例，并帮助工程师检查假设和约束。
形式化结果需要区分清楚：证明通过、发现反例、不可达，以及超时或未完成证明，代表不同状态。对反例的分析，也需要结合设计要求和环境假设，避免把约束问题误判为设计缺陷。
Debug Agent：把失败现象连到根因证据
Debug Agent 聚焦日志、波形和 RTL 之间的关联，逐步缩小问题范围，给出根因假设和修复建议。
一个可复核的调试结论，至少应包含失败条件、关键时间点、相关信号、代码位置，以及支持判断的证据。如果信息不足，也应明确指出还需要哪些日志或波形。
专业 Agent 围绕共享项目上下文协作。示意图来自所附演示材料。
四类角色的协作基础，是共同的项目上下文和一致的工具结果。它们需要知道自己正在分析哪个设计版本、哪次运行、哪份计划，才能把各自结论接成一条可信的任务链。
05 用一次仿真失败，串起完整闭环
下面是一条说明性的协作路径，用来展示这套架构如何组织工作。
- 工程师提出任务。
分析某次仿真失败，要求定位原因并给出修复建议。 - 设计理解 Agent 建立上下文。
关联相关模块、接口规则和设计要求，明确预期行为。 - Debug Agent 收集证据。
读取日志，提取失败时间点，选择相关波形，追踪异常传播路径。 - 按问题调用验证能力。
UVM Agent 辅助检查激励和检查器；适合属性验证的问题，再由 Formal Agent 辅助分析。 - 工程师审查方案。
判断根因证据是否充分，确认修改范围和验证方法。 - 修复后复验。
在可复现的配置下重跑原失败场景，再执行相关回归，检查是否引入其他问题。
这条路径的验收点，是问题是否得到解释、修改是否有依据、结果是否经得起复验。Agent 的执行记录，也因此成为工程交付的一部分。
06 Benchmark：让能力提升有据可查
要让这套流程持续改进，还需要稳定的评测方法。LongCore AI 的材料将芯片 Agent Benchmark 划分为六个维度：设计理解、UVM 验证、形式化验证、Debug、工程鲁棒性和可复现性。
这六个维度，分别对应不同的验收问题：
能否准确解释接口、数据流和协议，并指出依据？ 生成的验证资产能否融入工程，覆盖目标场景并提供有效检查？ 断言是否符合需求，假设是否合理，证明状态是否被正确解释？ 调试能否定位真实问题，并给出可复验的证据？ 面对复杂层次、残缺日志和工具异常，能否合理处理并说明边界？ 固定输入、版本和配置后，任务结果能否复验，执行过程是否可追溯？
为了比较不同模型或 Skill 版本，评测还应记录任务配置、工具版本、成功判据，以及耗时和资源开销。这样，团队才能识别哪些变化带来了改进，哪些变化让既有能力退步。
目前所附材料没有给出公开的 Benchmark 数据集、评测分数或量产项目验收结果。因此，这里介绍的是评测框架与落地路径，实际能力仍需要通过明确任务和可复现结果来验证。
07 从一个可验收的任务开始
对于希望引入 Agent 的芯片团队，一个务实的起点，是先选定边界清楚、结果可检查的任务：例如分析一类仿真失败、补齐一组协议场景，或把一部分规格要求映射成验证属性。
先定义输入与验收标准，再接通必要工具，沉淀 Skill，保留执行证据。等这条任务链稳定下来，再逐步扩大协作范围。
在这条路径上，工程师仍负责架构决策、关键判断和最终验收；Agent 则承担更多上下文整理、重复执行、结果解析和迭代工作。
LongCore AI 希望推动的，正是这样的转变：让 AI 持续参与设计、验证、形式化与调试，把能力落到一项项可追踪、可复核的工程任务中。
芯片 Agent 的价值，最终要由它完成的任务，以及支撑结果的工程证据来证明。
欢迎芯片设计、验证、形式化与 EDA 领域的同行，围绕具体场景交流共建。
