需求提取智能体

① 负责什么业务

客户的询单从来不是一张填好的表。它可能是一封邮件，外加一张拍歪的规格表照片，以及电话里顺口一句「用在北方冬天的户外结构上」。需求提取智能体的活，就是把这些多模态材料转成一份标准化诉求：牌号、规格、性能要求、数量、交期，每个字段都有明确的单位和取值。

比「抄对」更难的是隐性需求。客户说用途是低温户外结构，却没写冲击试验温度；有经验的销售工程师会意识到：要追加一个低温冲击韧性要求（例如在零下几十摄氏度量级做冲击试验，数值仅为示意）。需求提取智能体要把这类「客户没说、但一定要问清」的指标挖出来，单独列成隐性需求清单，交给下游确认。

它的产出会沿 A2A 横向交给需求答复智能体；技术上明显偏难的诉求（比如标准里查不到的非常规性能组合），同时抄送技术协议制订智能体做预警。牌号、标准体系这些底子没打牢的话，先读钢铁工业全景。

② 经 MAB 上行的业务请求

它不直接翻本体、不自己挑模型，只经 MAB 向 AIP 提一个业务请求。

intent: 提取标准化诉求          # 业务意图：做什么
target: inquiry#示意编号       # 目标对象：对哪张询单做
context:                       # 现场工况：做的时候已经知道什么
  attachments: [询单正文, 规格表图片, 用途说明]
  customer_profile_ref: 客户画像引用
# 注意：不写用哪个模型、查哪张表——那是 AIP 生成任务规范时决定的

③ AIP 怎样放行

AIP 拿到请求后先补全任务规范（时限、授权范围），再按对象去 DLA 本体里寻址，只激活钢材本体与销售域本体这一小片子网——牌号、标准号、用途与性能的映射关系，而不是整座知识库。

编排上以推理为主：多模态识别附件、从用途推断隐性指标。模型输出不会直接放行，而要过一道结构化校验：

• 字段完整性：牌号、规格、性能、数量、交期五类字段是否齐全，缺项要标注「待澄清」，而不是编一个值；
• 单位合法性：厚度、强度、温度的单位是否与字段匹配，换算后数值是否落在该类产品的合理量级里。

本步不写产线系统，准入相对宽松；校验不过则驳回留痕、回头澄清。治理环节的完整顺序见治理 · AIP 驾驭层。

④ 用到的本体与知识

• 牌号别名：同一个牌号在国标、行业标准、客户习惯叫法里可能有好几种写法，本体要把它们归到同一个对象上；
• 标准号：客户写的标准号要能指向具体的标准对象与版本；
• 用途 → 性能映射规则：L 孪生里的规则，例如「低温工况 → 需关注冲击韧性」「焊接结构 → 需关注碳当量」；
• 客户画像：D 孪生里的历史订单与习惯要求，帮助判断这个客户以往额外要求过什么。

⑤ 推理子域与计算子域

按推理 ≠ 计算的分工：

• 推理子域：多模态大模型读邮件和图纸，OCR 解析规格表图片，再由用途描述推断隐性指标。这些是形成候选的活；
• 计算子域：单位换算、规格合法性检查（例如厚度与宽度的组合是否在产品目录的量级范围内）。这些有确定答案，不该交给模型「估」。

⑥ 读写哪些 DAS 接口

• 读：经 MCP 从观测接口读取询单附件存储与客户画像；
• 写：标准化诉求写回统一状态，询单对象的状态机从「已受理」推进到「需求已结构化」。