AI栈图不是购物清单，是依赖图

大多数人以为 AI 就等于 ChatGPT，@triptitips 说这差得远：真正的变化发生在它底下那层生态里。他画了一张"AI 栈图"，收了 100 多个工具，并按十层摆开： · 大模型：OpenAI、Claude、Gemini、Llama、Mistral · Agent 化：LangGraph、CrewAI、AutoGen、CAMEL、Agno · RAG：LangChain、LlamaIndex、Haystack、GraphRAG · 向量化：OpenAI、Voyage、Cohere、BGE · MCP：把模型和工具、数据、系统连起来 · AI 安全：Guardrails、Presidio、Lakera、Prompt Security · 可观测与评测：LangSmith、Langfuse、Phoenix、Ragas · 记忆：Redis、Mem0、Zep、Neo4j、Chroma · Agent 框架：OpenAI SDK、Semantic Kernel、Google ADK、Bedrock · 自动化：n8n、Zapier、Make、Airflow、Prefect · 向量数据库：Pinecone、Weaviate、Qdrant、Milvus、pgvector 但他紧跟着说了一句更值钱的话：这不是购物清单，而是一张依赖图。 RAG 好不好，取决于检索和嵌入；Agent 稳不稳，取决于工具、评测和护栏；记忆如果不能被观测，context 什么时候过期、什么时候错了你都看不见；MCP 这一层如果权限和治理是事后补的，那就不是能力而是风险。他还补了一句扎心的：堆满"最强组件"的栈，照样能做成一个糟糕的生产系统。 原因是他给出的那个判断——AI 系统很少只在单个组件里失败，它们失败在交接处：模型 → 检索 → 上下文 → Agent → 工具 → 记忆 → 评测。延迟在这里叠加，上下文在这里丢，权限在这里泄漏，幻觉在这里传播，可靠性从这里开始崩。 所以他的结论是：真正的护城河不是拥有更多 AI 工具，而是设计它们怎么一起工作。栈图告诉你"有什么"，生产工程决定"它能不能扛住现实"。 我的看法是，这张图最实用的用法是定位自己缺哪一层。多数团队的工具都堆在"看得见"的层：模型、框架、向量库；而最容易被忽略的恰是评测与可观测和权限治理——它们不产出新功能，但决定出问题时你能不能查、能不能拦。第二条是"交接处"这个判断：按组件清单选型是常见错误，真正要设计的是数据和控制在层与层之间怎么流动。 如果要照这张图动手，我建议不是从选工具开始，而是从"交接处"开始列清单：模型到检索这一跳，谁保证检索到的就是该用的？上下文到 Agent 这一跳，压缩之后还剩什么？工具到记忆这一跳，写进去的东西什么时候会被读出来？每一处都问两句——这一跳由谁负责、出错时怎么发现。回答不上来的地方，就是你栈里最脆弱的地方。 举个具体例子：记忆层里存着"同事海鲜过敏"，三个月后这个人已经调岗、这条信息过期了；Agent 却照旧在聚餐建议里避开海鲜。单看每一层都没错，错在记忆到评测这一段没人负责。这类问题靠换更强的模型解决不了，只能靠在交接处加校验。 边界：这是一张生态图，工具名单更迭很快，也不构成选型结论；而且这条推文本身带推广性质（结尾在引导保存与转发）。当地图用可以，别当标准答案。