智能体怎样发现该建什么

第 2 课 · 共 6 课 约 8 分钟

先读说明书；三种线索：答不出的问题、新的数据源字段、使用证据；把缺口写成一条能核对的触发原因。

本课目标

读完这一课，你将能够

  • 说出智能体发现「该建什么」的三种线索
  • 按「先读说明书、再查数据、再下结论」的顺序确认缺口是真的
  • 写出一条审核的人能核对的触发原因

先读说明书，再下结论

上一节讲了谁来建。智能体动手前的第一件事是读，不是改。aidc semantic describe --markdown 会输出整份给大模型读的说明书：有哪些Object Type，属性叫什么（包括同义词），能做哪些 Action，当前是第几个语义版本。要看结构化的全貌，用 aidc semantic ontology。

aidc semantic describe --markdown         # 说明书：类型、属性、同义词、Action、当前语义版本
aidc semantic ontology --json             # 全貌：对象类型、关系、接口
aidc semantic object-types purchaseOrder  # 一个类型的属性与关系

采购员问的是「哪些供应商在哪些物料上晚了」。智能体逐个词去对：「供应商」对上 supplier，「物料」对上 material，「采购订单」对上 purchaseOrder。那「晚了」呢？purchaseOrder.expectedAt 只是下单时的约定日期，同义词里没有「承诺」，也没有「延期」。

找不到，不等于缺。先查同义词，再查有没有别的类型已经放着它，都没有，才算缺口。

三种线索

QUESTIONS

答不出的问题

采购员、智能体或应用问了，本体（Ontology）给不出答案。这是最强的线索：问题来自真实工作，不是从现有模型能答什么倒推出来的。

SOURCES

新的数据源字段

aidc semantic streams list、aidc semantic streams get <stream> 看有哪些数据流和字段，aidc semantic datasource list 看谁接了谁。有流没绑定，就是没人能问的数据。

USAGE

使用证据

aidc evolve evidence <app> 汇总反馈、操作和数据画像（空值率、被人改过几次、样例值）。同一个属性被反复改、反复问，多半是名字或口径有问题。

三种里，答不出的问题分量最重。一个模型好不好，要看它能不能回答真实的业务问题：答不出的问题本身就是结果，应该回头去找缺了的概念、关系或业务逻辑。第四种线索最直接：有人开口要求。

用数据确认，不凭感觉

线索只是线索。智能体先用只读 SQL 看现有数据能走多远：一条 SELECT 最多返回 10,000 行、最长跑 20 秒，表名就是Object Type的 API name。

aidc semantic sql 'SELECT "supplierId", count(*) AS n FROM "purchaseOrder" WHERE "expectedAt" < current_date GROUP BY 1 ORDER BY 2 DESC'

这条只能数出「下单时约定的到货日已经过了」的订单，看不到供应商后来又承诺过哪一天。一张采购订单可以有好几次承诺，一个属性装不下。所以缺的不是属性，而是一个新概念：交期承诺。

多半是什么原因对应的改法
找不到起点类型名字、同义词或说明不清补说明和同义词，改动很小
走不到相关的东西缺一条关系加一个 Link Type
只能手工导出再拼表业务里有这个概念，本体里没有加一个 Object Type
没有任何路径能答缺数据，或缺概念先查数据流有没有进来，再定

把缺口写成一条触发原因

发现的结果不是「我觉得该改」，而是一句能被人核对的触发原因：什么问题、试过什么、缺什么、证据在哪。它会原样进到提案里，审核的人靠它判断这次修改值不值得。

分不清是缺概念，还是大家说法不同，就去问人，别自己猜。比如问采购员：「供应商改口以后，你们以哪个日期为准？」问清楚再写，比猜出一个模型强。

随口一问

本体不够用，建议新增一个Object Type。

好的交代

采购员本周三次问「哪些供应商在哪些物料上晚了」，答不出。说明书里没有交期承诺：purchaseOrder.expectedAt 只有下单时的一个日期，供应商改口后的承诺没处放。ERP 发布端的 po-promises 流已在送数据，aidc semantic datasource list 里没有任何绑定接它。

要点

  • 动手前先读：describe --markdown 是给大模型读的说明书；找不到先查同义词，再查别的类型。
  • 三种线索：答不出的问题、新的数据源字段、使用证据；答不出的问题分量最重。
  • 用只读 SQL 确认现有数据能走多远，一条 SELECT 最多 10,000 行、20 秒。
  • 先分清缺的是说明、关系还是概念，再决定改什么。
  • 触发原因写明问题、试过什么、缺什么、证据在哪，让审核的人不用猜。

练一练

替采购智能体做一次发现

用你自己的业务，或者示例工厂。

运行 aidc semantic describe --markdown，把一个业务问题里的每个词对到类型或属性上，标出对不上的词。

小测

选一个答案，马上看解析。

Q1智能体在说明书里找不到「晚了」这个词，下一步该做什么？

Q2下面哪一种情况属于「新的数据源字段」这条线索？

Q3哪一条触发原因写得合格？

延伸阅读