写在前面最近我们在内部做了一个 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 懂我们的业务。这件事做成了后面的流程重构、效率提升都是水到渠成的。而这套能力是建立在对业务的深度理解和架构设计能力之上的——图谱建得好大部分场景被兜住成本自然就降下来了。文章发出来也是想听听外部的声音。这套方案肯定有可以优化的地方欢迎大家在评论区拍砖、提建议一起把这件事做得更好。