前几天在 dev.to 上翻到 James Anderson 的一篇文章，列了 AI 应用过度工程的 7 个迹象，每条配了替代做法，最后还给了一份预防手册。评论区三十来条，基本都在讲自己踩过的坑。
七条我不打算挨个复述，那种清单你直接去看原文更快。这篇笔记只记读完真觉得该记下来的两件事：新增一层到底该拿什么当「该加」的证据；以及为什么推迟多智能体是一笔划算买卖。顺带记几个评论区里我想自己复现一遍的案例。
先说第一条，还没确认需要嵌入检索，就先上向量库。
作者把它排在第一位，我很认同，因为这事我见过也干过。默认路径往往是：拿到一个内部文档助手的需求，第一反应是切块、嵌入、建库、串一条检索链，整套先跑起来，然后才回头去看效果。问题是这一整套搭完，你其实还没回答「关键词搜不到的东西到底长什么样」。
评论区有个案例我印象很深：给一个大概 400 个 Markdown 文件的文档助手搭向量库和嵌入管道，前后弄了三周，最后发现关键词搜索加 SQL 过滤在相关性和 p99 延迟上都更好，整条嵌入栈最后被删掉。它的起步方案朴素到有点好笑：
grep -rn "退款失败" docs/ --include="*.md"
就这一行，配几个过滤条件，先拿一批真实问题跑一遍看召回。等你能指出「这几种问法用它确实搜不出来」，再考虑嵌入才算有依据。文章里那句话我划了线：只在效果可测量地不足时才引入嵌入。「可测量」三个字是关键——不是你觉得不够好，是你能拿出来一批失败样本。💡 顺便说下我自己的浅见：向量库当然不是不能用，文章给它的边界是大型稳定知识库，产品文档、FAQ、词汇表这一类，还得配一个好的重排序器。这个边界我接受，但我会再加一句——如果你说不清失败样本长什么样，这条边界就还没到。
然后是第二条，多智能体。这里藏着全文我最买账的一句话。
作者说，规划、研究、评审、综合这类多智能体图，多数情况下不如一次结构良好的调用，或者两三次线性调用。理由也不新鲜：更多幻觉点、更多交接断裂、更高延迟、更高成本、更强非确定性。真正让我记下来的是他在回复里提的那个不对称论证，我把它画成了一张小图：
单提示词 ──→ 拆成多智能体 随时可以拆，改坏了还能收回来
多智能体图 ──→ 压回单提示词 推倒重来，前面的编排全扔
两个方向的代价不一样。所以「先别拆」不是审美偏好，是一笔能算的账。这条我准备直接抄进以后的设计评审里。
真碰到下面三类情况再拆也不迟：需要隔离上下文的真正分支、有可测量延迟收益的独立并行、必须独立验证或对抗的步骤。我在心里给它们翻译成白话分别是：上下文串了会互相污染、串行跑真的慢到用户能感觉出来、这两步不能由同一张嘴说了算。其他理由，说实话大部分都是「看起来更专业」。
评论区还有一条案例值得贴一下：有人说他们去年的 RAG 管道有 6 个智能体、3 个编排层，外加一套每周都得盯着状态转换的东西；重写成「检索到生成」两次调用加一个评估工具之后，延迟从 4 秒掉到 800 毫秒，错误率从 12% 降到 2% 以下。少了四层，效果反而更好。这种案例我一般会存疑，但它的结构太典型了——多出来的那几层从来没被单独量过。
还有一条评论我看了半天才反应过来是自嘲，那位说他给同一个产品做了支持十多家提供商的 IDE、自己写的版本控制系统、从零用 Rust 写的浏览器、远程桌面、团队构建器、编排器和用量仪表盘，然后补了一句目前只有他自己在用。笑完之后有点心虚，因为「造那层」这件事本身确实挺上瘾的。
第三条我想记的是评估。
跳过评估是生产 AI 里最常见也最危险的错误之一，这话每年都有人说，真正跳过的团队一点没少。原文里我觉得有用的是一个门槛：小规模、高质量的标注测试集，30 到 50 个例子就够起步。不是让你先搭一套评估平台，是先把这几十条写出来：
{"input": "...", "expect": "应拒答，不该编造条款编号"}
{"input": "...", "expect": "应引用第 3 节的原文"}
有了它，你才能回答「这次改动是变好了还是变坏了」。没有它，所有架构讨论最后都会变成谁的直觉更响。作者还有一句我挺喜欢：评估往往会告诉你真正的问题出在检索质量或者提示词不够清楚，而不是你正准备动手建的那个组件。
跟评估挨着还有个小动作，我顺手记一下：把渲染后真正发出去的提示词打出来读一遍。
rendered = render_prompt(ctx)
logger.info(rendered) # 定期真的打开看一眼，别只记不读
模板引擎、条件拼装、提示词路由叠在一起，会让「模型实际收到的是什么」变成一个要开调试器才能回答的问题。作者建议提示词尽量保持扁平可读，需要动态组装就把最终渲染结果记下来定期读。这条成本极低，我打算这周就加上。
作者自己在文里承认踩过两个坑：试过微调让模型记住信息，结果转头就忘；也给一个当时只有大约四个用户的产品按大流量做过扩展。这两个坦白比七条迹象本身更有说服力——不是旁观者写的清单，是真栽过的人回头划的路标。
划重点：
- 新增一层之前，先能说出它解决的那个可观察问题，说不出来就先别加。
- 检索从最朴素可行的方案起步，关键词、过滤条件、直接把相关文档塞进提示词都算；引入嵌入的门槛是你手上有一批失败样本。
- 推迟多智能体是低成本的，因为这个方向的代价不对称——单提示词以后随时能拆，多智能体图很难压回去。
- 评估要早做，30 到 50 条起步就够；没有它，你连「这次改动有没有弄坏东西」都答不上来。
这篇就记到这里。你可以挑手上正在做的一个 AI 小功能，把它的每一层列出来，挨个问一句「这层解决的是哪个具体问题」，答不上来的那层先删掉再跑一遍——如果效果没变，那它本来就不该在。