写在前面
最近我们在内部做了一个 AI 排障系统，效果还不错：判断准确率 95%，排障场景二三十秒出结果，成本也压得很低。
但我觉得这件事值得分享的，不是"准确率 95%"这个数字，而是我们是怎么让 AI 真正理解业务、而不是只会说漂亮话的。
我们把它叫做"仿生 Agent"。这个名字不是包装，而是它真实的工作方式：
图谱是记忆，排障和 RAG 是大脑在调用记忆、组织语言输出。
整个过程就是在模拟人的思考。
下面把这套系统的架构、设计思路和踩坑过程完整写出来，希望能给正在做 AI 落地的同学一些参考，也欢迎大家拍砖。
一、问题：为什么大多数 Agent 落地会翻车？
现在大家都在接大模型，但真正落到业务场景里，普遍会遇到几个问题：
- 会漂移：模型自由发挥，答非所问，甚至胡说八道
- 不懂业务：模型不知道你的系统长什么样、数据在哪里、逻辑是什么
- 成本失控：每次调用都走深度推理，token 用量下不来
- 不敢查库：让模型直接查生产库，怕它写错 SQL 把数据搞坏
这些问题的根因其实是一个：模型没有"记忆"。
它不知道你的业务是什么，只能靠 prompt 里塞上下文来猜，猜对了是运气，猜错了是常态。
所以我们的思路很直接：给它装上记忆，再给它套上缰绳（Harness）。
二、底层：知识图谱就是 Agent 的"记忆"
这件事能做成，前提是对业务理解足够深。我们团队对这套系统的业务逻辑和技术实现都很熟悉，知道哪些信息是关键的、哪些关系是必须保留的。
这不是一个纯技术问题，而是一个业务 + 技术的综合问题。
基于这个理解，我们设计了一套知识图谱的数据结构，把业务实体、代码逻辑、系统依赖全部编码进去。这套结构不是随便搭的，是经过反复思考和实际训练迭代出来的。
它的核心作用就一个：让大模型"看懂"我们的系统——知道该查什么、怎么查、查到之后怎么解释。
图谱的维护跟代码和设计文档绑定，代码或业务变更时会自动识别受影响的节点做增量更新，然后走一轮全量回归验证，确认准确率没有下降、关键路径没有断，才会发布。因为每次验证成本低，我们可以高频执行，迭代节奏可以拉得很紧。
三、中层：Harness 机制——为什么 Agent 不会漂移
这套 Agent 之所以不会漂移、不会说错话，核心原因是Harness 的味道很重。
- 图谱是缰绳：Agent 只能基于图谱节点回答问题，不会凭空编造
- 预案是缰绳：排障场景直接匹配预置 SQL，不需要模型现场发挥
- 预置 SQL 是缰绳：查什么表、怎么查，都是预先验证过的
- 查库规则是缰绳：只读权限、指令校验、结果可控，三层保障物理上杜绝误操作
Agent 在缰绳范围内跑，既不会跑偏，也不会失控。它不是在"自由发挥"，而是在"按规则办事"——这正是它准确率高、成本低、不漂移的根本原因。
四、上层：排障和 RAG，是大脑在调用记忆
有了记忆（图谱）和缰绳（Harness），接下来就是大脑怎么调用记忆了。我们有两类场景：
排障场景
每上一个新业务，我们会从业务点反向推理出排障场景，然后准备好对应的 SQL 语句。模型接到问题时，先用预置 SQL 查询实际业务现状，再结合图谱节点的能力给出解答。
这里有一个比较巧妙的设计："预制菜"机制。
我们把验证过的业务 SQL 预先存到 MySQL 库里，模型遇到排障问题时，不需要现场写 SQL，只需要从库里挑出对应的那条"菜"端上来就行。而且挑菜之前，模型会先从图谱里取当前的数据结构和影响字段，确保 SQL 和实际库结构始终对齐。
预案这套设计最妙的地方在于——它不是预先穷举出来的，而是从实际问题里"长"出来的，而且会越用越快。
一方面，排障入口承载的问题越多，沉淀下来的预案就越多，这是一个自然积累的过程。另一方面，新需求下来时，我们就能提前分析出可能的排障场景，预先准备好预案——相当于在问题发生之前就备好"弹药"。两条路径叠加，预案库只会越来越厚，系统响应只会越来越快。
排障入口还内置了一套 RAG 机制：先去匹配预置 SQL，同时接入 SkyWalking 的日志，准确抓取当时的业务数据和日志情况。正因为底层机制一致，排障过程中遇到非预案场景时，才能平滑过渡到图谱搜索——不需要额外适配，同一套机制无缝切换。
预案兜得住就秒出答案，兜不住就切到图谱搜索，用户感知不到切换。
效果上，排障场景二三十秒就能给出答案，准确率达到 95%，跟人工判断高度一致。
RAG 场景
纯业务问答的 RAG 更简单——搜索图谱的相关节点，组织语言回答问题。
RAG 场景耗时稍长，大概四五分钟。主要原因是模型拿到图谱节点之后需要组织语言——搜图谱本身很快，但把多个节点的信息整合成一段连贯、准确的回答，需要模型花时间"组装"。
不过这个时间是值得花的：正因为图谱节点做得好、依据给得准，模型组织出来的语言才有质量，不是瞎编的。
两类场景本质上都是依托于图谱的准确构建来做事的。图谱建得好，绝大部分问题都能直接解决。深度推理的场景几乎不存在——只有遇到图谱实在查不到、或者节点置信度太低的情况，才会触发。
五、成本：漏斗型设计让成本天然低
这套系统的成本之所以可控，根本原因在于我们采用了漏斗型设计：绝大部分场景由知识图谱直接兜底，只有极少数复杂情况才会触发深层的 ReAct 推理。
更重要的是，我们把深度推理的工作提前做在了图谱里——建图谱的时候就把推理链路编码进去，运行时只需要查图谱、匹配节点，不需要让模型现场推理。所以图谱只需要支撑排障和 RAG 就够了，token 用量极低。
同时，图谱的构建成本也因为方法得当而保持在很低的水平。两层成本优势叠加——构建便宜、运行更便宜——整个系统的成本结构非常健康。
具体来说，排障场景全量回归一次几块钱，纯 RAG 场景 50 个问题大概 20 块左右。这个成本结构说明，不是我们在"省钱"，而是架构设计得好，所以天然便宜。
六、架构哲学：仿生人类排障机制
这套架构我思考了很久，核心思路是把人类排障的思维过程完整投射到系统里。
预案兜得住就秒出答案，兜不住就平滑过渡到图谱搜索，同时拉 SkyWalking 日志还原现场——这完全模拟了一个有经验的工程师排障时的思考路径：先查已知方案，查不到就搜关联信息，同时拉日志还原现场。
所以这套系统不是在"替代人"，而是在"继承人的能力"——把人的经验编码进图谱和预案，让 AI 按照人类的思维方式去解决问题。这不是某个技术点的优化，而是整个架构的设计哲学。
七、系统边界：知道什么不该做
深度推理的场景极少，而且我们清楚它的局限性——因为没有图谱做依据，准确率会明显下降。所以这类场景的输出我们会标注低置信度，必要时转人工。
这反而说明系统的边界是清晰的：图谱能解决的，又快又准；图谱解决不了的，不硬撑，交给更合适的方式。
还有一个场景需要说明——日报。日报本质上是系统问题和运行情况的表现，本身并不适合让模型去做深度推理。这类推理 token 消耗大、成本高，而且准确率难以保障。
我们的做法是：用 coding plan 的方式把日报结构化记录下来，作为场景分析的素材。但日报里的问题和情况往往比较复杂，更需要人来监控、分析和解决。AI 负责记录，人负责判断——这是目前最优的分工。
八、关于查库安全
关于 Agent 查生产库的安全性，我们做了三层保障：
- 权限隔离：使用独立只读账号，物理上杜绝误操作
- 指令校验：生成的 SQL 经过规则过滤，不合规的直接拦截
- 结果可控：查询数据只用于生成回答依据，不会回写系统，且全程有日志记录
九、下一步迭代方向
当前这套架构已经跑通了，但还有几个方向值得继续优化：
- 预置 SQL 的管理优化：随着业务增多，预置 SQL 数量会膨胀，可以考虑加一层标签或分类索引，让模型匹配更快、更准
- 图谱节点的保鲜机制：现在我们有回归验证，但还可以再推一步——能不能自动检测哪些节点可能过时了？比如代码改了但图谱没跟着更新，能不能有一个告警机制
- RAG 回答的模板化：RAG 耗时主要在组织语言，这部分可以考虑模板化——不同类型的图谱节点组合对应不同的回答模板，模型只需要填内容，不需要从零组织语言，速度会快很多，风格也会更统一
- 日报的初筛能力：日报虽然不适合让模型做深度推理，但可以让模型做一些初筛——自动提取关键词、分类问题类型、标记紧急程度。人拿到的是初步整理过的日报，分析效率会更高
这些不是现在的问题，而是下一步迭代的方向。
写在后面
我们做的不是"接一个 AI"，而是"让 AI 懂我们的业务"。这件事做成了，后面的流程重构、效率提升都是水到渠成的。而这套能力，是建立在对业务的深度理解和架构设计能力之上的——图谱建得好，大部分场景被兜住，成本自然就降下来了。
文章发出来，也是想听听外部的声音。这套方案肯定有可以优化的地方，欢迎大家在评论区拍砖、提建议，一起把这件事做得更好。
