> For the complete documentation index, see [llms.txt](https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/di-wu-bu-fen-luo-di-pian/28-ji-shu-jia-gou-xuan-xing.md).

# 第 28 章 · 技术架构选型

选型这件事，不该由技术名词的时髦程度决定。管理者不必懂每种技术的内部细节，但需要一张够用的地图，知道主要有哪几种模式、各自解决什么问题、各自要付什么代价。这里按由简到繁排四种。

第一种，直接调用模型。把任务交给通用大模型，让它直接生成——写文案、拟初稿、翻译。最简单，对应第 4 章的"让 AI 说"，几乎不碰企业数据，门槛最低。

第二种，检索增强，也就是 RAG。让模型在回答前，先去企业自己的资料里检索相关内容，再据此作答。它对应"让 AI 读懂企业自己的东西"，适合基于自有知识的问答与生成。代价是要维护资料的卫生——哪份权威、哪份过期、谁有权限看，这些没管好，它会自信地引用错的东西（第 27 章）。

第三种，Agent。模型自己拆解任务、调用工具、分几步把一件事办完。它对应"让 AI 替企业动手"，适合自动化流程。但它也最复杂、最不可控——要接系统接口、要管权限、要设护栏，出错的后果也直接落到业务上。

第四种，平台或中台。把上面这些能力沉淀成一套可复用的底座，供多个场景调用。它属于规模化阶段的东西，在只有一两个场景时，搭平台往往是过早的投入。

选型的判据其实很朴素：按"要让 AI 干哪种活"，选那个最简单、够用的模式。能直接调模型解决的，别上 RAG；能 RAG 解决的，别上 Agent；只有一两个场景时，别急着搭平台。复杂度不是先进的勋章，而是实打实的成本和风险——每多一层复杂，就多一分要维护、要排错、会出事的地方。很多项目的麻烦，是先迷上了一个酷技术，再回过头去找场景来套它，顺序反了。

这里还有一个绕不开的权衡，值得管理者心里有数：最强的模型，往往最不可解释——问它为什么这么答，它自己也说不清；而最可解释的方法（规则、明确的知识结构），能力又相对弱。这意味着在金融、医疗、法务这类必须讲清"凭什么"的高风险、强监管场景，企业可能不得不选一个"够用且可解释"的方案，而用不上那个最强、却是黑箱的模型。要强，还是要说得清，常常只能选一个。

最后一句关于耐久：具体的模型和产品换代很快，今天最强的，明天可能就被超过。所以架构上的明智，是别把企业绑死在某一个模型或供应商上，保持可迁移（第 13 章）。选型服务于场景，而不是反过来——这条不会因为技术怎么变而过时。

## 要点速查

* 四种模式（由简到繁）：直接调模型（说）、RAG 检索增强（读懂企业自己的资料）、Agent（替企业动手）、平台/中台（规模化底座）。
* 选型判据：按"让 AI 干哪种活"选最简单够用的那个；能调模型别上 RAG，能 RAG 别上 Agent，一两个场景别搭平台。复杂度=成本+风险。
* 可解释-能力的权衡（N12）：目前最强的模型往往最不可解释，最可解释的方法能力又偏弱；高风险/强监管场景可能只能用"够用且可解释"的。
* 耐久：模型/产品换代快，别绑死、保持可迁移；选型服务于场景，不是反过来。

## 给管理者的三步

* 现在：对每个候选场景，先问"它到底要 AI 干哪种活"，据此定最简单够用的模式，别默认上最复杂的。
* 三个月：警惕"先选酷技术再找场景"的冲动；砍掉为炫技而上的复杂度。
* 一年：在高风险场景确认走的是"可解释"路线；在架构上保持不被单一模型/供应商锁定。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/di-wu-bu-fen-luo-di-pian/28-ji-shu-jia-gou-xuan-xing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.