Issue类别：问题修复

参赛团队：易烟

所属赛区：东北赛区

报名绑定账号：w346868

Describe the current behavior / 问题描述 (Mandatory / 必填)

src/common/alg_parse.cc::CollectMatchedNamesForOpType 的执行器取反分支直接将匹配算法的 count 置零，遗漏了同文件已经实现的 Send/Recv 例外规则。全局 not(sole{}) 和 not(sole{mesh}) 都会将已有的 AicpuSendSoleMesh、AicpuRecvSoleMesh、AicpuBatchSendRecvSoleMesh 等候选置零。

同文件 ContainsSendRecv 上方明确注释“规则 4.6：send/recv 算法名不参与 count=0 的排除逻辑”，引擎过滤及正向匹配后的排除分支均遵守此规则；两处 isExecNegated 分支却没有检查。上述名称对应仓库已注册的 Send/Recv/BatchSendRecv 算法，不是为测试虚构的名称。selector_engine.cc 的 FilterCmByHcclAlgo 会调用该更新逻辑，因此错误 count 会进入算法选择候选模型。本次只复现并修复模型过滤结果，未声称复现 NPU 上的通信失败；规则解释和采纳请社区确认。

Environment / 环境信息 (Mandatory / 必填)

Linux x86_64；GCC；C++14；GoogleTest 1.14.0。局部测试编译真实 src/common/alg_parse.cc，沿用仓内 alg_parse/stub；本地缺完整 CANN 构建环境，使用 HCOMM 仓现有 include 与 test/stub/depends 头文件作为测试依赖，没有改动产品构建依赖。

master 基线：31054b7189b830e613b1f8d7097fa026d74cbf00。

Steps to reproduce the issue / 重现步骤 (Mandatory / 必填)

1. 构造 CostModel，包含 AicpuSendSoleMesh、AicpuRecvSoleMesh、AicpuBatchSendRecvSoleMesh，count 均为 1；加入 AicpuAllReduceSoleMesh 和 AicpuAllReduceSequenceMeshNHR 作对照。
2. HcclAlgoParser::Parser("not(sole{})") 成功后调用 UpdateCostModelWithAlgo(parser, model, {"Aicpu", "Aiv", "Dpu"})。
3. 原版会把上述 Send/Recv/BatchSendRecv 的 count 置零。改用 not(sole{mesh}) 也会出现同样结果。
4. PR 的 UpdateCostModelSendRecvTest 同时覆盖上述两个入口、显式 opType 取反、count=2 保持以及已关闭项 count=0 不重新启用。

在已配置仓库 UT 依赖的环境中使用现有 alg_parse_test 目标运行：

./alg_parse_test --gtest_filter=UpdateCostModelSendRecvTest.*
./alg_parse_test

本地编译方式（从 HCCL 仓根目录；变量分别指向 HCOMM 仓和 googletest 源码的 googletest 子目录）：

g++ -std=c++14 -pthread \
  -Itest/ut/common/alg_parse/stub -Isrc/common \
  -I"$HCOMM_ROOT/include" -I"$HCOMM_ROOT/include/hccl" \
  -I"$HCOMM_ROOT/test/stub/depends/include" -I"$HCOMM_ROOT/test/stub/depends/pkg_inc" \
  -I"$GTEST_ROOT/include" -I"$GTEST_ROOT" \
  src/common/alg_parse.cc test/ut/common/alg_parse/*.cc \
  "$GTEST_ROOT/src/gtest-all.cc" -o /tmp/alg_parse_test
/tmp/alg_parse_test

这是局部主机回归，不等同于完整 CANN UT/ST 或上板运行。

Describe the expected behavior / 预期结果 (Mandatory / 必填)

遵循现有规则 4.6，Send/Recv/BatchSendRecv 候选保留原 count；匹配的非 Send/Recv 算法仍置零，未匹配的其他执行器算法保持。

Related log / screenshot / 日志 / 截图 (Mandatory / 必填)

[==========] 31 tests from 3 test suites ran.
[  PASSED  ] 28 tests.
[  FAILED  ] UpdateCostModelSendRecvTest.NegatedExecutorPrefixPreservesSendRecv
[  FAILED  ] UpdateCostModelSendRecvTest.NegatedExecutorExactMatchPreservesSendRecv
[  FAILED  ] UpdateCostModelSendRecvTest.ScopedNegationPreservesSendRecv
3 FAILED TESTS

Special notes for this issue / 备注 (Optional / 选填)

修复方案：在执行器取反的前缀匹配和精确匹配两处复用 ContainsSendRecv，保持 Send/Recv/BatchSendRecv 原有 count，既不置零也不重新启用已关闭项。其他集合通信算法仍按原配置排除。补充 3 个 GTest 回归方法，沿用现有 alg_parse_test 目标。

查重范围：API 返回 695 条 Issue、3233 条 PR 的标题和正文。检索 ContainsSendRecv、not(sole、规则 4.6、Send/Recv 取非/取反过滤，未发现相同缺陷报告或修复。未声称逐一检视所有历史 diff。

请社区确认问题并安排责任人，未自行认领。采纳、问题档位及积分以社区回复为准。