Agent 意图库和知识图谱

用"从直觉 → 类比 → 逐步拆开系统 → 最后给你一套可直接套用的模板"的方式，把 意图库 和 知识图谱 讲到你能落地用。

接下来会分 4 步：

用一句话直觉区分
用一个生活类比（外卖/客服）建立画面
回到 Agent 流水线：它们分别在哪一步工作
用运维诊断例子，把"同一句话"如何分别被两者处理讲透

最直觉的一句话区分（先记住这个就够用了）

意图库 ：一张"菜单/目录"，回答 "用户想干什么？"（分类 + 路由 + 需要哪些参数）
知识图谱 ：一张"关系网/通讯录/拓扑图"，回答 "这个领域里有什么东西，它们怎么相互关联？"（实体 + 关系 + 证据）

如果只记一句话： 意图库管"做什么（Action/Workflow）"， 知识图谱 管"关于世界我知道什么（Facts/Relations）"。

类比理解：外卖平台（非常贴切）

假设你是外卖平台的智能客服 Agent。

2.1 意图库像什么？

像"问题类型目录"，比如：

催配送
申请退款
修改地址
投诉商家

每个意图背后都有对应流程：

催配送 → 查询骑手位置 → 发消息 → 记录工单
退款 → 查订单状态 → 看是否已出餐 → 走退款规则

也就是说：意图库 = 把你的话分到哪个"办事窗口"。

2.2 知识图谱像什么？

像"订单-商家-骑手-地址-时间"的关系网：

订单A 属于用户U
订单A 来自商家S
订单A 由骑手R 配送
骑手R 当前坐标 x,y
商家S 是否已出餐

也就是说：知识图谱 = 这些对象之间的关系，能让客服查得到、串得起来、推得出原因。

2.3 你现在困惑的点通常是：

你会觉得"意图库里也有很多知识啊"。对，但它的"知识"是 为了执行流程而服务的 （比如需要哪些参数、走哪个 handler）。知识图谱的"知识"是 领域事实本身（订单属于谁、服务依赖谁、告警影响谁）。

回到 Agent：意图识别流水线里它们分别做什么

一个典型 Agent 流程可以粗分为三层：

3.1 第 1 层：识别"要做什么"（意图库主场）

输入：用户一句话输出：Intent = XXX + Slots = {...} + Confidence

例如：

Intent：ops.query_alerts
Slots：{service: "order-service", time_range: "yesterday"}

这一步最依赖：意图库（意图集合、边界定义、槽位定义、路由信息）

3.2 第 2 层：补齐"这句话里指的到底是谁/哪一个"（知识图谱主场）

用户常说的是"简称/口语"，比如：

"订单系统""支付""那个Redis""昨天那次变更" 这些都需要对齐到真实对象（实体消歧与补全）。

知识图谱可以把：

"订单系统" → order-service（prod）还是（staging）？
"Redis" → redis-cluster-A 还是 redis-cluster-B？
"昨天那次变更" → 具体的 change_id = CHG-20260114-xxx

3.3 第 3 层：执行与推理（两者一起用）

意图库告诉你：该走"性能诊断 workflow"
知识图谱告诉你：该查哪些依赖、哪些告警、谁负责、哪些变更相关

用运维诊断例子，由浅入深拆开

下面我用同一句话，分别展示"意图库在做什么"和"知识图谱在做什么"。

4.1 用户说：

"订单系统好慢，是不是 Redis 出问题了？"

A) 意图库会怎么处理？

它的目标是：选对流程。

它会把这句话归到某个意图，比如：

ops.performance_diagnosis（性能诊断）并抽取参数（槽位）：
service = 订单系统（注意：这里只是原始文本，还没对齐）
suspect = redis（嫌疑组件）

然后路由到对应 workflow，例如：

查 APM（P95、错误率、吞吐）
查依赖组件指标（Redis、DB）
查告警与变更
汇总根因候选

到这里，意图库完成的事情是："启动哪条诊断流水线"。

B) 知识图谱会怎么处理？

它的目标是：把"订单 系统 、Redis"这些词变成真实可查询对象，并串起证据链。

知识图谱里可能有这些事实（关系）：

order-service depends_on redis-cluster-A
order-service deployed_in prod
redis-cluster-A has_metric latency_p99
redis-cluster-A has_alert RedisLatencyHigh#123
RedisLatencyHigh#123 occurred_at 2026-01-15 10:03

于是它能帮助 Agent：

消歧：订单系统 = order-service(prod)
定位：它依赖的 Redis = redis-cluster-A（而不是别的 Redis）
关联证据：redis-cluster-A 刚好有延迟告警

到这里，知识图谱完成的事情是："把上下文与证据补齐，让诊断更像'查案'，而不是'瞎猜'"。

为什么你会觉得"意图库"和"知识图谱"像一回事？

因为它们都会出现"名词"：

意图库里也会写：意图名、槽位名、样例语料（看起来像知识）
知识图谱里也会有：服务名、告警名（看起来像分类）

关键差别是：

意图库里的名词是"为了执行"

它的终点是：调用哪个工具/流程（可执行） 例如：ops.query_logs → 去调日志系统接口

知识图谱里的名词是"为了建模世界"

它的终点是：查事实、做关联、出证据链（可解释） 例如：从 order-service 沿依赖边扩展到 Redis/DB/下游服务

Agent 意图库 和 知识图谱