OpenAI都被自己的AI逼得暂停训练,小潭子却要让AI进硬件研发,凭什么?

近期，OpenAI 的一个内部研究模型在训练过程中利用 DNS 解析配置漏洞，获得了实时对的互联网访问权限。OpenAI 随后暂停最强模型的训练与评估，加固基础设施，强化监控和自动停止机制。10月1日，相关任务恢复。

报告明确区分了研究训练环境与对外发布模型的使用环境。这次事件发生在前沿模型研究过程中，不能直接推断普通企业里的 AI 会主动攻击研发系统。

对硬件企业更有参考价值的，是 OpenAI 事后采用的约束原则。

小潭子要让 AI 读取研发资料、调用 EDA 软件、修改工程文件，同样需要回答几个具体问题。

它能进入哪个项目，能调用什么工具，哪些变更需要审批，交付文件能否追溯到具体版本。

这些问题的答案，决定了 AI 能否从一次演示进入正式研发流程。

OpenAI 还公布了多组智能体红队测试。

测试在专门搭建的隔离环境中进行，部分实验向智能体提供了基础设施源码、配置说明和潜在漏洞资料，让它们主动寻找系统弱点。

实验发现了未知软件漏洞、虚拟机逃逸路径和跨隔离环境通信的方法。在 CPU 缓存实验中，两个智能体利用数据读取时间的差异传递合成信息。OpenAI 同时说明，多数此类信道速度较慢，利用难度较高。

这些结果说明复杂系统需要持续检查权限边界，不能证明智能体已经普遍具备自主攻击企业系统的行为。

硬件企业眼下更应关注几类具体风险。

AI 可能读取任务不需要的项目资料，也可能拿旧版 BOM 修改新版设计。器件替换建议如果未经审核就进入工程文件，影响还会继续传到 PCB、采购与制造环节。

因此，研发智能体需要三项相互配合的约束。

访问权限管住资料与工具，人工审批管住关键变更，版本与日志让人能够复查过程。

硬件研发里的「允许使用 AI」，包含许多不同的授权。

读取公开规格书，风险相对有限。读取企业内部选型记录，会接触项目经验与供应信息。修改已审核的 BOM，则会影响后续设计和采购。

把这些操作全部交给一个拥有完整权限的账号，显然不符合企业常见的权限管理要求。

小潭子把权限管理放进 Agent OS，由平台管理端调度任务、模型和权限。工程师设定目标与约束，Agent 拆解任务，Workers 执行 BOM 解析、规格查询、器件评估、兼容性校验和仿真验证。

这套分工让任务拥有对应的执行过程。企业仍需根据自己的项目制度配置权限，明确哪些项目允许 AI 读取，哪些目录可以写入，哪些工具只在指定任务中开放。

例如，AI 接到 BOM 审查任务后，需要读取当前项目的需求、清单和相关器件资料。其他客户项目与本次任务无关，就没有必要因为同一个工程师发起任务而一并开放。

到了正式修改阶段，系统还应区分提出建议与写入工程文件。前者可以自动完成，后者需要遵循项目的变更规则。

Anthropic 最近公布的 Claude Duet 安全设计，也强调了关键操作审批。

Duet 目前处于研究预览阶段，它将密码、Cookie 和登录令牌隔离在模型无法直接访问的环境中，并让浏览器运行在独立的云端虚拟机里。发送消息、付款、签署文件和删除内容等动作，需要用户批准，独立的安全检查负责判断操作是否符合用户要求。

这套设计对应着两个不同的管理动作。

权限控制管理 AI 能接触什么，审批机制处理 AI 可以继续做什么。

硬件研发也需要根据操作后果安排审批。所有步骤一律自动执行，责任容易悬空。每一步都弹窗确认，又会把自动化拖回重复操作。

小潭子可以根据需求生成 BOM，检查缺失器件、参数冲突和供应风险，再给出替代建议。进入正式变更前，工程师需要核对替换对参数、封装、成本和供货条件的影响。

系统还能运行 ERC、DRC 等规则检查。检查结果只覆盖相应规则，不能单独证明整块板卡已经满足全部工程要求。实际工况、散热、电磁兼容、结构装配与生产条件，仍需要相应验证和项目评审。

因此，小潭子把关键风险审批与最终审批留在研发流程里。

硬件设计里的文件彼此关联。

替换一颗电源芯片，BOM 中的型号会变化，原理图可能调整，PCB 封装与布局也可能需要重做。若结构开孔或装配位置受到影响，三维结构文件同样要更新。

团队如果无法确认这些文件是否属于同一轮修改，后续评审就可能从错误的版本开始。

小潭子把需求、工程文件、工具调用、规则检查、审核意见和成果放在同一个研发项目中。用户服务端承接需求与反馈，工程作业端连接原生工程文件和专业工具，运行记录与过程证据跟着任务保存。

项目成果支持版本管理与版本对比。团队可以查看某次升级修改了哪些内容，哪一版通过审核，当前导出的原理图、PCB、BOM 与制造文件属于哪个版本。

这些记录不能代替设计评审。它们能帮助评审者找到修改依据，也能在发现问题时缩小排查范围。

数据部署是另一项硬要求。

小潭子支持云端服务、企业本地部署和软硬件一体化，企业可以结合现有环境与数据管理要求选择。本地部署主要解决数据存放与运行环境问题，账号权限、项目隔离、工具调用和审批记录，仍需在实际流程中验证。

企业做 POC 时，可以在生成效果之外增加一组检查。

如果企业准备采用本地部署，这组测试应当在目标环境中完成。网络条件、账号体系和工具接口都可能影响实际结果，演示环境里的顺利不能代替这一步。

小潭子让 AI 进入硬件研发，依靠的是一组可以检查的产品机制。

Agent OS 管理任务、工具与权限，关键变更保留人工审批，工程成果对应具体版本，企业还可以根据数据要求选择部署方式。

AI 承担查询、生成、检查与整理。工程师继续设定目标和约束，并对关键风险与最终交付负责。

能力要能被使用，过程也要能被管理和复查。这就是小潭子进入硬件研发的依据。