架构选型的判断力

前三卷把 AI 编程系统的主要零件都摆上了桌面——大模型怎么工作，Agent 怎么执行，MCP 和 Skill 怎么扩展能力，记忆、上下文和知识注入又分别解决什么问题。到这里，一个更实际的问题才真正出现：当这些零件你都知道了，面对一个具体场景，你到底该怎么选，怎么配，怎么把它们装成一个真正能运行的系统。
很多团队的问题不是"不知道新东西"，而是太容易把新东西都用上。一个本来单 Agent 加几个内置工具就能解决的任务，最后被做成了多 Agent、RAG、MCP、规范系统全家桶；结构看起来很先进，成本却高得吓人，效果也未必更好。真正稀缺的不是工具本身，而是判断力——知道什么时候该加一层，什么时候反而该减一层。
这一卷讨论的，就是这种从"知道概念"走向"能够选型"的能力。前两章先解决决策问题：面对一个真实任务，什么时候该直接对话，什么时候需要 Agent，什么时候该上 MCP、Skill 或规范驱动，什么时候其实什么都不加才是更好的工程选择。接下来的两章再把视角从"选什么"推进到"怎么装起来"与"怎么守住边界"：一章把从用户请求到代码交付的全链路蓝图完整摊开，让前面分散讨论过的模块重新落回一张系统图里；另一章讨论安全与对齐，解释当系统开始接触真实代码库、真实文档和真实生产环境时，信任边界为什么会成为架构本身的一部分。
所以这一卷的关键词不是组件，而是判断。不是看到什么都想加进去，而是能分清什么是必要复杂度，什么只是概念上的兴奋；不是只会局部优化一个 Prompt 或一个工具，而是能从整体上判断一套 AI 编程系统应不应该这样设计，以及它的边界究竟在哪里。