我是小兵，一个动手派AI架构师。“AI工程化实战”系列第 15 篇。

一句欠账，十四篇才还上

上一篇《Multi-Agent 协作实战》（第 14 篇）结尾我撂下一句话：“多 Agent 怎么协作，这一篇讲完；几十个工具怎么选，下一张地图上见。”今天来还这笔账。

翻回前十四篇，工具其实是零散出现过的：第 5 篇讲网关，点名了 LiteLLM、One API；第 8 篇讲全链路 Trace，Langfuse 和 OpenTelemetry 给了用法；第 11 篇讲知识库，Milvus / Qdrant / pgvector 只说了“该看哪个”；第 13 篇讲 LLMOps，把 MLflow / HF Hub / DVC / W&B 一股脑塞进了附录；第 14 篇讲多 Agent，LangGraph / AutoGen / CrewAI 直接一句“优劣全推给第 15 篇”就打发了。几十个工具飘了十四篇，却从来没被摊成一张能查的地图。

存了五十个工具名字，为什么还是选不明白

真到选型那天我才发现，记着几十个工具名字一点用没有。三个误区，一个比一个贵。

第一，把工具信息当分类学收集。我按“类别”存：向量库一栏、Agent 框架一栏、网关一栏。可清单只回答“有哪些”。打开它，我还是不知道选哪个——因为我要的答案跟我的场景和约束绑在一起，跟“这工具属于哪一类”没关系。信息是按“工具是什么”存的，而我要的是按“我的处境”查。

第二，把选型当找最强的。横向测评的落点是“谁是第一”，可工具好坏强依赖你：数据能不能出域、团队扛不扛得住运维。脱离约束谈强弱，就是耍流氓。

第三，把罗列当工作量、把核实当零头。真做地图才发现，几十个工具的版本、许可、维护状态才是会烂的活。编死一个版本号，比留一句“待核实”危险得多。

先把结论放这儿：这一篇把前十四篇点过名的几十个工具，摊成“站点 × 约束”两个坐标轴的地图。每格给“什么条件下选谁”的判据，不给“谁第一”的排名。

两个坐标轴：你在干哪件事 × 你的约束

整篇的主线就一句：工具没有普适最优，只有约束下的最优。地图按“你的活 × 你的约束”组织，不按“工具类别”组织。

横轴 A 是“你在干哪件事”，也就是前十四篇的流水线站点：网关/路由、Prompt 管理、评测、灰度/发布、护栏/安全、Trace/可观测、成本/缓存、反馈闭环、数据底座、向量库/检索、Embedding、模型注册、实验追踪、推理引擎、多 Agent 编排、Agent 间协议、低代码胶水。

纵轴 B 是“你的约束是什么”，也就是你的枷锁：开源还是托管、要不要国产化/信创、数据能不能出域、团队规模和运维能力、预算、已有技术栈。

一句话记住这张地图的逻辑：同一件事，约束一换，候选就换。

举个我最爱举的样板，Trace 那一格。同一件事，数据能不能出域，直接把答案劈成两半——

• 数据可以出域、托管可用：Langfuse、LangSmith 都能上；
• 数据不许出域：LangSmith 这种只有托管形态的直接出局，只剩自托管的 Langfuse。

这里的关键是：不是 LangSmith“更差”，是它在你的约束下“根本不能选”。这就是地图和测评最大的区别。

还有两根要划清的边界。第一，判据全部复用前十四篇、一条不新造——上面每一格的判据，都是前面某一篇在真实场景里立过的，比如第 8 篇的“自托管 Langfuse 要自己扛 ClickHouse 成本”、第 11 篇的“alias 原子切 / snapshot / MVCC”、第 13 篇的“模型是耗材”、第 14 篇的“框架给你边，不给你边契约”。我不是在这一篇临时编一套判据来评工具，是把前十四篇立过的搬进对应的格子。第二，地图敢说“这格不需要工具”——结构化输出那一格，很多活原生能力就够，硬推三款工具反而不诚实。

三个取舍点，每个都有代价

第一，坐标轴是“你的活 + 你的约束”，不是“工具类别”。代价是同一个工具会在多个格子里反复冒头——vLLM 既在“推理引擎”，也在“数据不出域”下被重新看到；Dify 既在“低代码胶水”，也在“灰度发布”。这不是冗余，恰恰说明坐标轴量的是“你的处境”而不是“工具的户籍”。但代价也实在：组合数会炸，还不好做 SEO。

第二，每格给判据，不给排名。代价是读起来不痛快，判据还会过期。可我认——脱离约束谈好坏就是耍流氓，一个只会喊“第一名”的清单，到了你的约束下可能第一名压根不能选。

第三，做 30+ 工具地图，最大的活是核实，不是罗列。代价是个无底洞：版本、许可、维护状态，还得定期复查。多 Agent 框架这条线最典型——原版进了 maintenance、社区分叉出 AG2、两家又合并成 MAF，全是一两年内的事；网关线的 One API 低维护、继任者 new-api，也是说变就变。一张不标日期的工具地图，比没有地图更危险——它让你以为你查到了答案，其实你查到的是两年前的世界。

落点：一个纯标准库可跑的查询器

说得再多，地图得能查。这一篇的落点是一个纯标准库可跑的查询器：工具是数据不是文字，输入“我在做 X + 我的约束 Y”，确定性地吐出一份带理由的候选清单。代码细节这里不搬，只留一条不能反的顺序——硬约束先过滤、软权重后排序；一反过来，就会算出“托管在私有化场景里排名第一”这种荒谬结果。

三个真金白银的坑

坑一：照着“AI 工具大全”挑，挑了一堆单看都强、凑一起不搭的工具。我按“每个类别里最强的”选——Trace 上了 Langfuse、评测上了 LangSmith，结果两套都想要自己那套 Trace 标准，同一批数据要在两个地方打两遍标，换了半天也没把“一次发布”串起来。根因是我按工具类别选型，从没问过“它们在一条流水线上怎么配合”。教训：工具不是按“哪个强”选的，是按“它们在一条流水线上怎么接得上”选的——单看每个都第一，串起来照样废。

坑二：托管用着爽，出事才发现数据出不了域、账单失控、供应商说改就改。早期我什么都上托管——Trace、评测、向量库全 SaaS，又快又省心。等到业务要过合规、数据不许出域，才发现一半组件得整体换血，而它们的数据结构、SDK、trace 标准全不一样，迁移比重建还贵。根因是我把“约束”当成了选完再看的后验项。教训：约束不是选完再看的附录，是第一性条件。你挑的每一个“爽”，将来都要用迁移的痛还。

坑三：照着一篇两年前的选型文，装了一个已经没人维护的框架。我照着挺权威的对比文选了个多 Agent 框架，装完才发现它早进了 maintenance，社区分了叉、上游改了名——我照着“还在迭代”的描述，用了一个“已经收摊”的东西。根因是我信了一篇没标日期的文。教训：一张不标日期的工具地图，比没有地图更危险。

那张大表，我只留两行结论

原文附录把站点、工具、版本、许可、维护状态全列成了大表，这里不搬，你记住两个结论就够：

• 工具的版本、许可、维护状态都会烂，所以原文正文里一个版本号都不编死，真实版本号全放进“标了核实日期（2026-09）”的附录——因为编死一个版本号，比留一句“待核实”危险得多。
• 结论永远是“什么约束下看谁”，不是“谁第一”。比如向量库那格：无约束时 pgvector、华为 GaussDB、百度 BES、Milvus 都可看；一旦加上“国产化”这根约束，只剩华为 GaussDB 和百度 BES。

顺带送你一个可直接抄走的动作清单——选型 7 问里的前 3 问：你要挑的这件事，能用一句话说得清是什么“活”吗？你的硬约束有哪些（先列约束、再列候选，顺序反了就等着迁移）？这一格真的需要引入一个工具吗，原生能力够不够？

一句收口 + 下一篇预告

选型地图不是“有哪些工具”的清单，是“我处在这个处境该看哪几个、凭什么”的查询。工具没有普适最优，只有约束下的最优。一张查不出答案的地图，排版再漂亮也是废物。

但还欠一笔账：这张地图上，“国产化 / 私有化”是一整根约束轴，我每个格子里都给了国产候选（向量库的华为 GaussDB / 百度 BES、Embedding 的 BGE-M3……），可政企落地时这些格子会怎么卡你——合规怎么过、信创那根轴怎么核（数据库类有国测目录，LLM 组件却没有统一名单，只能逐家看口径）、私有化之后运维谁来扛、国产硬件上推理引擎跑不跑得动——这一篇我只标、没展开。下一篇《政企国产化避坑》：地图上标了国产化的那些格，背后的坑单独一篇来讲。

这篇是脱水版。完整版含可离线跑的 mini_toolmap.py + 8 个断言的测试、“站点 × 工具”收编表、带核实日期（2026-09）的版本/许可/维护状态核实表，已同步发布在 CSDN。点文末“阅读原文”看完整代码和可跑 Demo。

评论区聊聊：你做工具选型，是先列约束，还是先列候选？

我是小兵，一个动手派AI架构师。这里只写自己跑过、摔过、复盘过的AI工程化案例。如果你想持续收到这类实战内容，点击关注，下篇见。