最近我在给团队搭CANN算子知识库时，撞上一个特别典型的场景：一位刚接触算子的同事用AI编程助手写自定义算子，折腾一下午把代码跑通了，结果性能测试一出来，AI Core利用率比仓库里已有的老实现低了十几个百分点。对比代码后才发现，他要写的东西，项目里早就有一个调优过的版本，只是他没检索到，Agent也不知道有这回事。

这件事让我彻底想明白了一个问题：Agent确实能写代码，但它没有“记性”。它不知道仓库里已经沉淀了什么，不知道哪些算子在真实芯片上踩过坑，也不知道哪个版本是验证过的。于是，让Agent“先查知识库、再动笔”，就成了我们这轮改造的核心目标——同一个算子，别让它写第二遍。

这篇文章就是我这次在CANN环境下搭建算子知识库、并把Agent接入知识库的完整记录。内容包括Agent为什么总在重复造轮子、算子知识库整体怎么设计、检索与复用的闭环怎么打通，以及我自己踩过的几个坑。如果你想在自己的CANN算子工程里引入AI辅助开发，又不想让Agent把团队已有资产重写一遍，这篇文章应该能给你一份可以对照落地的方案。

1. 先弄清楚：Agent为什么总把算子重写一遍

1.1 看起来会写代码，其实是个“健忘的实习生”

多数人刚用AI编程助手时的感觉是“捡到宝”，让它写一个常规算子，代码结构、数据切分、内存申请都能一次性给你，甚至还能写出对齐逻辑。但用久了你会发现，它更像一个没接受过入职培训的实习生：你问它某个算子有没有现成实现，它不知道；你让它参考仓库历史，它没有这个习惯；它给出的“标准答案”，来自训练语料里的通用知识，而不是你团队仓库里的项目知识。

这在CANN算子开发里很危险。算子在昇腾AI处理器上跑，很多优化不是学出来的，而是“改出来的”——比如针对特定shape切分多核、把中间结果留在片上内存、利用特定流水线指令。这些经验都藏在仓库里那几百个算子实现中。Agent看不到这些，就只能靠通用解法硬写，结果看起来逻辑完整，等差在性能和细节上。

1.2 三个直接原因：上下文、隔离、检索

我把“Agent重复写算子”的原因拆成三层，方便后续对症下药。

第一层是上下文窗口限制。就算某个模型支持超长上下文，你也不能把整个算子仓库都塞进一次对话里。实际使用中，对话里的有效信息一旦超过一定量，模型对早期内容的“记忆”就会衰减。让它现场翻代码库找“同款算子”，效果基本靠运气。

第二层是知识隔离。项目里的自研算子、私有实现、调优参数，这些信息不在Agent的训练数据里。比如你们团队自研的“融合了激活函数的卷积算子”，公开语料里没有，Agent就只会按标准卷积的写法给你生成。这是天生的知识盲区，不靠工具补起来，光在提示词里说“参考已有代码”是没用的。

第三层是检索方法太粗。即便允许Agent读取代码仓库，它通常也是按文件名或关键词去猜，比如搜“conv”就把所有带conv的文件都翻出来。但算子复用的判断远比这复杂：输入是NCHW还是NHWC？支持动态shape还是固定shape？数据类型是fp16还是fp32？这些信息不在文件名里，Agent自然无法判断“能不能复用”。

1.3 重复写的代价不只是浪费那一下午

有人说“Agent写一遍，我改一改也能用”，这个想法天真了。第一，算子的正确性和性能需要完整验证，不是代码能编译通过就算完。第二，很多算子是经过几轮调优才达到当前性能的，比如在AI Core上是4核切分还是8核切分，背后都对应不同的数据搬运开销。Agent重写一遍，大概率是“性能裸奔”版本。第三，重复实现意味着团队里出现两份同职责代码，以后维护要改两遍，对排错也是灾难。

这笔账算下来，重复写的代价不是写那一下午，而是后续一整个周期的时间成本和质量风险。所以我才坚持：所有算子在落笔前，先过一遍知识库。

2. 算子知识库怎么设计，才不会被Agent当摆设

2.1 先定义一份完整的“算子资产”长什么样

搭建知识库的第一件事，不是选数据库，而是定义“一条知识”到底包含什么。只把源码丢进去那是代码仓库，不是知识库。Agent需要的不只是代码，而是“这个算子能不能用、怎么用、用了以后性能怎样”的完整信息。

我整理的最小集合如下：

• 算子名称与别名：仓库里的文件命名经常不一致，需要统一登记。
• 功能描述：一段自然语言，说清楚“这个算子完成什么计算”，用于向量检索。
• 输入输出规格：每个输入张量的形状、数据类型、数据布局（NCHW/NHWC等）、是否支持动态shape。
• 源码与构建方式：可复用的实现代码，以及编译需要的依赖项。
• 单元测试与性能基线：验证过的case，在特定芯片上的AI Core利用率、耗时等。
• 适用版本：适配的CANN版本范围。
• 业务标签：由使用方标注，比如“推荐系统”“视觉模型”，方便场景化检索。

这些信息在真实仓库里往往是散的。源码在算子目录里，测试在另一个目录，性能数据可能在调优记录文档里。知识库要做的第一件事，是把它们汇聚到一条记录里。

2.2 双通道存储：结构化元数据+语义向量

存储层面我采用了“双通道”方案：一份结构化记录放在普通数据库，一份向量表示放在向量数据库。

结构化数据库负责精确过滤。比如Agent要的是一个“支持NHWC、fp16、动态shape的卷积算子”，那就在元数据表里直接查，NCHW的、固定shape的全部排除。向量数据库负责语义搜索。比如描述里写的是“把两个特征图按通道加权求和”，向量检索可以去撞“weighted sum over channel”“per-channel fusion”这类没对齐关键词但语义相近的描述。

我当时选型时，结构化部分直接用了团队已有的数据库，向量部分用了开源的向量库，没有额外引入重量级平台。因为知识库的查询量不会像互联网搜索那么大，关键是链路简单、易维护。数据量过了几万条再考虑分布式，起步阶段没必要上重架构。

表结构大致如下：

2.3 算子指纹：复用的唯一判定标准

知识库记录建好后，最难的是“同款认定”。两个算子实现可能长得完全不一样，但功能完全一样；也可能代码结构很像，输入规格却不同，根本不能替换。这就要用到算子指纹。

我定义的算子指纹由五个要素拼接而成：算子类型、输入规格、输出规格、数据布局、计算属性。举个例子：

conv2d|input:[N,C,H,W],dtype=fp16|output:[N,OC,OH,OW],dtype=fp16|layout=NCHW|attr=no_bias,dilation=1

凡是指纹一致或兼容的算子，才进入“可复用”候选集。指纹不一致直接跳过，不做语义猜测。这一步能筛掉大量误匹配。我之前踩过一个大坑，就是只按向量相似度推荐算子，结果把NCHW的算子和NHWC的算子配在了一起，Agent照着模板写完，跑起来数据全是乱的，反过来还怪模型写得不对。加了指纹过滤后，这类问题基本绝迹。

指纹的生成不能靠人工手敲，我做了个脚本，从算子注册的代码入口自动提取输入输出规格，生成指纹字符串，避免人写错。

2.4 入库流程：验证过才让知识库记住

知识库最怕的，是入库了一堆“看似有效实则有坑”的算子。一旦Agent检索到并复用，就是拿可靠性开玩笑。所以入库流程必须有质量门槛。

我这边跑的流程分四步：

1. 候选收集：从代码仓库、历史调优记录、旧文档里抽取算子线索，生成候选清单。
2. 自动属性补齐：脚本读取算子注册文件，自动填写输入输出规格、数据类型、布局、源码路径。
3. 人工审核与打标签：算子所有者或资深工程师确认功能描述是否准确，补充业务标签，标记弃用或推荐状态。
4. 全量验证：跑一遍单元测试和基础性能测试，只有通过的算子才会被写入正式知识库；失败的就留在“待修复”状态，不会参与Agent检索。

这一步花了团队大概两周时间，把存量算子盘点了一遍。代价不小，但值得。因为后面Agent每次检索，都会命中这些经过验证的记录，准确率才有保障。

3. 检索复用闭环：让Agent拿到答案而不是拿到模板

3.1 检索策略：先过滤、再相似、最后看置信度

知识库搭好后，接下来是整个方案的核心：Agent在生成代码前，必须走一次“查库”逻辑。我设计的检索流程有三个阶段。

第一阶段是元数据过滤。Agent把当前需求拆成结构化的参数，比如输入shape、layout、dtype、是否支持动态shape，在数据库里先圈定候选集。这一步要严格，凡是规格不兼容的，直接淘汰。比如Agent这次要的是fp16，那库里只有fp32实现的算子在第一步就出局。

第二阶段是向量相似度排序。对第一步筛出来的候选集，用功能描述去向量数据库里找语义相近的记录，按相似度返回Top-K。这一步解决的是“功能描述不一致”的问题。Agent说“将两个张量逐元素相加并做ReLU”，库里的记录可能写的是“element-wise add followed by activation”，语义一致但措辞完全不同，向量检索能把它们拉近。

第三阶段是置信度判定。相似度高于某个阈值（比如0.85），直接判定“可复用”；相似度在0.65到0.85之间，判定“可参考”；低于0.65，判定“未命中”，允许Agent新写算子。这里阈值要根据实际数据调整，调太高会漏，调太低会误复用。

3.2 让Agent调用知识库的方式

检索逻辑写好了，还要让它能被Agent调用。我试过两种接入方式，各有适用场景。

第一种是工具调用（Function Calling）。把“查询算子知识库”封装成工具函数，Agent在生成代码前会自动调用。工具接收需求描述、输入规格、数据布局等参数，返回匹配的算子记录。这种方式适合在支持工具调用的Agent框架里用，Agent自主决定“我需不需要查库”。实测下来，Agent大部分情况下会主动调用，因为提示词里强调了“先查库再写码”。

第二种是提示词注入。Agent运行前，把知识库里与当前任务最相关的几条记录，直接以“已有实现参考”的形式注入提示词。这种方式实现最简单，但提示词会越来越长，一旦注入内容超出上下文有效范围，效果就下降。我一般只在小规模场景用，正式流程还是走工具调用。

我给出的建议是：如果团队用的是大模型+工具的成熟方案，直接走工具调用，让Agent的决策更自主；如果只是日常复用几个高频算子，提示词注入更快，够用就行。

3.3 复用判定与生成行为：必须给出“怎么改”而不是“抄一遍”

Agent查库命中只是第一步，真正的工程智慧在于“拿到答案后怎么用”。这里我定了三条规则，避免Agent生搬硬套。

如果命中的算子指纹完全一致，Agent直接返回该算子的调用接口，并说明数据规格和注意事项，不生成新实现。这一步就真正实现了“同一个算子不写第二遍”。

如果指纹部分兼容，比如布局一致但batch size范围不同，Agent可以复用实现代码，但必须做适配修改，比如调整循环边界或者切分逻辑，并在注释里标明“基于既有算子X做了适配”。这种半复用效果也很明显，代码骨架和优化思路都在，风险远低于从零写。

如果未命中，Agent可以写新算子，但生成顺序上要先输出一段“检索说明”，解释为什么现有知识库不满足需求。这样后续回填时，审核者能快速理解当时的决策背景。

3.4 回填机制：让知识库自己长出来

闭环的最后一步是回填。很多知识库项目死在“只吃老本”，存量算子入库后就不再更新，Agent越用越觉得知识库旧。我在方案里加了回填链路：Agent新写的算子，经过代码评审和性能验证后，会自动走一遍入库脚本，抽取指纹、生成描述向量、登记到知识库。这样知识库是活的，每多一个Agent贡献的新算子，团队的资产就厚一层。

这个机制有一个关键点：回填必须走验证流程。Agent生成代码后不能直接入库，至少要有“编译通过+单测通过+基础性能达标”三关。我见过有团队贪图省事，让入库脚本直接处理Agent输出，结果知识库里混入一堆未验证代码，整个库的可信度很快崩盘。宁可入库慢，也不能入库脏。

4. 落地过程中踩过的坑和排查建议

4.1 embedding模型的选择直接影响检索命中率

知识库检索的“语义”质量，完全取决于向量化模型。一开始我图省事，用了通用文本嵌入模型处理算子描述，结果问题百出：模型把“卷积”“池化”这些词看得懂，但一旦描述变成“对特征图进行降采样”“在通道维度上聚合信息”，它的表达就很随机。换成一个针对代码语义训练的模型后，检索命中率提升非常明显。

这不是玄学，是模型训练语料的差异。通用文本模型擅长自然语言，但对代码里那种“短词+结构符号+复合概念”的语义理解偏弱。算子描述里会出现大量术语组合，比如“element-wise multiply with broadcast”，通用模型容易把重点放到“multiply”上，但库里记录的是“broadcast mul”或者“逐元素乘”，实际含义一致，向量距离却很远。建议做检索类任务时，优先试代码场景训练的模型，哪怕要自己搭服务也值得。

4.2 动态shape和数据布局带来的误匹配

“看着像，用着崩”是知识库落地的高频事故。动态shape就是一个典型问题。库里的算子A只支持固定shape，Agent检索时用一个动态描述去撞，向量相似度很高，因为功能确实接近，但实际复用后，跑到运行时才发现不支持动态shape，整个任务中断。

我的解决办法是靠算子指纹硬性拦截。动态支持与否、数据布局、精度这些不需要让AI去“理解”，指纹字段里精确匹配就行。向量检索负责找“功能像的”，指纹过滤负责找“能用上的”，两者缺一不可。

4.3 知识库必须跟上CANN版本更新

算子在CANN不同版本下的接口和优化行为会有差异。知识库里记录的实现可能适配旧版本，到了新版本下，可能接口变了、性能变了，甚至行为也有变化。如果知识库不做版本管理，Agent复用一个过期算子，结果大概率是在新环境里编译失败或性能不达标。

我给的方案是为每条算子记录标记“适配版本区间”，检索时把当前环境的CANN版本作为过滤条件。同时，每隔一段时间做一次全量回归，跑一遍核心算子的基础测试，把版本兼容性及时更新上去。这个过程不能省，否则知识库会慢慢变成“历史存档”，而不是可用的工程资产。

4.4 防止知识库膨胀成垃圾场

知识库增长太快也不全是好事。无节制入库会让检索结果精度直线下降。Agent检索回来的候选集里混入大量“远古版本”“废弃实现”，相似度还都挺高，反而干扰判定。我加了两个约束：一是只有通过验证的算子才能入库；二是同一个算子如果有新版本，旧版本会标记为“已弃用”，检索时优先返回推荐版本。

实践下来，知识库规模控制在“每类核心算子1到2个推荐实现+几个特殊规格版本”最舒服。量不在多，够用且可信就行。

4.5 实测效果：数字背后是流程的胜利

知识库上线跑了一个月后，我做了个内部统计：在新增算子的开发任务中，Agent对已有算子的检索命中率达到了六成以上，算是覆盖了最高频的那些复用场景；新增算子的平均编码时间明显下降，更重要的是代码评审时，关于“重复造轮子”的讨论少了很多。

这些数字不具备普适性，毕竟团队存量、算子复杂度各不相同。但有一个趋势是确定的：凡是知识库质量好、检索闭环做得扎实的团队，Agent的产出质量会明显高于“裸跑”状态。这不是因为模型变聪明了，而是因为知识库替模型补上了“团队记忆”这块短板。

5. 常见问题速查表

最后分享一点个人体会

知识库做到最后，你会发现它真正沉淀的不是代码，而是团队对“什么时候该用哪个算子”的理解。Agent只是个执行者，知识库是团队给它装的“记性”。这轮项目里我最深的感触是：不要指望Agent自己变得聪明，你要做的是把团队的经验整理成它能读懂的格式。知识库不是建完就完的静态工程，它是一个需要持续投喂、持续修正的活系统。以后每次Agent写出新算子，我会顺手想一下：这条该不该回填？描述是否准确？性能是否验证过？养成这个习惯，知识库才会越用越顺手，Agent才不会一遍又一遍地去写那些我们已经写过两遍的算子。