企业官网建设流程全解析

最近有一类观点在技术圈里讨论度很高：多位 AI 领域的领军人物公开表示，技术奇点可能已经到来。很多开发者的第一反应是“这跟我有什么关系？”其实关系很大。无论“奇点是否已开始”这个判断最终如何被验证，背后的技术趋势已经实实在在影响了我们日常工作方式：大模型越来越会推理，AI Agent 开始能独立完成多步任务，模型部署和 AI 应用开发的门槛在快速下降。

这篇文章我不想停留在口号层面的讨论，而是从概念、技术信号、动手实践、工程落地四个角度，拆解“AI 奇点已开始”这种说法对开发者意味着什么。我们会一起梳理 AI 工程实践的关键环节，包括模型部署、Agent 开发、应用构建、问题排查与最佳实践。无论是刚开始接触大模型开发的新手，还是已经在做 AI 应用的后端工程师，都能从中找到一条可执行的路径。

1. 先理解“奇点”这个概念

1.1 技术奇点的由来

“奇点”这个词最早来自数学和物理学，指的是一个函数取值趋向无穷、超出常规认知范围的临界点。后来被未来学家和计算机科学家引入技术领域，用来描述“技术发展速度超过人类理解能力”的那个历史时刻。

在计算机科学圈子里，比较有代表性的是 Vernor Vinge 在上世纪 90 年代提出的观点：一旦机器智能超过人类智能，社会和技术的发展节奏将发生不可逆的变化。Ray Kurzweil 则在《奇点临近》中进一步给出了时间预测，认为人工智能会在某个时间点实现自我改进的循环，从而带来爆炸式发展。

需要注意的一点是，技术奇点本身是一个带有争议的预测性概念，不是计算机科学里严格定义的理论。我们讨论它时，更多是在讨论“当前 AI 技术是否已经进入一个新的能力阶段”。

1.2 AI 领袖们说的“奇点已开始”指什么

近期多位 AI 公司创始人和研究者表达了一个共同判断：随着大语言模型在推理能力、多模态理解、工具调用、代码生成等方面的持续突破，AI 不再只是“聊天机器人”，而是开始成为能够参与实际工作的智能体。

他们所说的“奇点已开始”，通常包含几个信号：

• 模型具备较强的复杂推理能力，不再只是“记住知识”，而是能一步步推导结果。
• AI 可以自主调用外部工具、访问数据库、执行代码，完成多步骤任务。
• 模型从“生成文本”走向“生成行动”，开始改变软件的生产方式。
• AI 开发门槛下降，普通开发者可以通过提示词、Agent 框架快速构建应用。

从工程角度看，这些信号意味着 AI 技术已经从实验室研究走向工程交付阶段。我们不需要纠结“奇点是否真的到来”这种哲学问题，更需要关注的是：作为开发者，如何在新的技术环境下构建可靠、可维护、可落地的 AI 应用。

1.3 为什么开发者需要关注这个趋势

一句话：AI 开发不再是大公司研究团队的专属领域。

以前要做一个 AI 应用，需要自己训练模型、准备数据集、调参、部署推理服务，流程长、成本高、门槛壁垒明显。现在的大模型时代，基础模型通过 API 或者开源权重对外提供，开发者可以通过少量代码对接模型能力，将精力集中在业务逻辑、数据流和用户体验上。

这种变化带来的具体影响是：

• 应用开发模式改变：从“编写规则”转向“设计提示词和 Agent 工作流”。
• 技能需求变化：提示词工程、RAG、Agent 开发、模型评估成为新的核心技能。
• 架构复杂度增加：AI 应用需要处理模型输出不确定性、上下文长度限制、成本控制等问题。
• 工程化要求提高：不能只在本地跑通 Demo，要考虑生产环境的性能、安全和监控。

所以，与其争论“奇点是否已开始”，不如去掌握 AI 工程化的核心能力。

2. 支撑“奇点”判断的几条技术主线

2.1 大模型能力从“生成”走向“推理”

过去几年大模型的发展路径非常清晰：最初是词向量和上下文预测，随后是千亿参数大模型的涌现能力，再到当前对推理能力的强化。

以 OpenAI o1、DeepSeek-R1 等推理模型为代表的新一代模型，在数学、编程、逻辑推理等任务上表现出显著提升。它们不再只是“生成概率最大的下一个词”，而是会在内部进行类似“思考链”（Chain of Thought）的推理过程，再输出最终答案。

对开发者来说，推理能力的价值在于：

• 复杂任务可以被拆解并可靠执行。
• 代码生成的准确率更高，更适合进入生产流程。
• 多步 Agent 任务的中间步骤决策更稳定。

2.2 AI Agent 与工具调用

“奇点已开始”的一个重要技术支点是 AI Agent。

Agent 和普通聊天机器人的区别在于：Agent 不只是回答问题，而是被赋予目标、工具和行动能力。它可以通过函数调用（Function Calling）操作外部系统，比如查询数据库、调用 API、读写文件、执行代码，然后根据结果决定下一步行动。

当前主流的 Agent 开发范式包括：

• 单 Agent：一个模型实例完成整个任务流程。
• 多 Agent 协作：多个 Agent 分别承担规划、执行、审查等不同角色。
• Human-in-the-loop：关键步骤由人工确认，降低完全自动化的风险。

2.3 基础设施和开发生态的成熟

大模型应用能落地，离不开底层基础设施的成熟。当前已经形成了比较完整的工具链：

• 模型提供方：OpenAI、Anthropic、Google、阿里、百度、智谱、DeepSeek 等。
• 开源模型生态：Llama、Qwen、DeepSeek、GLM 等系列。
• Agent 框架：LangChain、LlamaIndex、AutoGen、Spring AI 等。
• 向量数据库：Milvus、Chroma、Pinecone、Weaviate 等。
• 可观测平台：LangSmith、Langfuse、OpenTelemetry 等。

这些工具的存在，让 AI 应用开发从“从零搭建”变成了“组件选型与集成”。

2.4 从研究到工程化的范式转变

过去，AI 落地最大的障碍是“模型能力不够”和“工程化成本过高”。现在模型能力已经不是主要瓶颈，工程化反而成了新的焦点。

举个直观的例子：做一个基于企业知识库的问答系统，技术栈可能包括：

数据层 → 文档解析、切片、向量化、存储 模型层 → 大模型 API 或开源模型推理服务 检索层 → 向量检索、关键词检索、混合检索 应用层 → 问答接口、业务逻辑、权限控制 监控层 → 日志、成本、质量评估

这个技术栈已经非常接近传统软件工程的体系了。换句话说，AI 应用开发正在回归“软件工程”本身。

3. AI 工程实践的核心框架

3.1 三层架构：数据、模型、应用

从工程角度，一个 AI 应用通常可以拆成三个层次。

第一层是数据层。无论模型多强，业务知识仍然需要来自企业自己的数据。数据层要做的事情包括采集、清洗、解析、切片、向量化、索引管理。

第二层是模型层。可以选择云端大模型 API，也可以部署开源模型。模型层还需要考虑推理性能、成本、并发量和安全合规。

第三层是应用层。这是开发者最常写代码的地方，包括 RAG 流程、Agent 逻辑、提示词管理、权限控制、结果校验和前端交互。

理解这个分层，有助于在项目规划时明确工作重心。很多团队一开始就把精力放在“微调模型”上，但实际业务中，80% 的场景可以通过 RAG 或提示词工程解决，不需要微调。

3.2 RAG：让模型拥有“企业知识”

检索增强生成（Retrieval-Augmented Generation，RAG）是目前 AI 应用工程落地中最重要的模式之一。

RAG 的基本思想是：不要求模型记住你的业务数据，而是在回答问题时先把相关文档检索出来，作为上下文一起送给模型，让模型基于这些信息生成答案。

一个典型的 RAG 流程分为离线与在线两个部分：

离线流程：

• 采集文档。
• 文档解析和清洗。
• 文本切片。
• 向量化并写入向量数据库。

在线流程：

• 用户提问。
• 对问题进行向量化。
• 在向量数据库检索相关片段。
• 将“问题 + 相关上下文”组装成提示词。
• 大模型生成回答。

RAG 的优势是：

• 知识更新成本低，不需要重新训练模型。
• 回答有据可查，可以给出引用来源。
• 降低幻觉风险，因为模型是基于检索结果回答。

3.3 提示词工程：AI 应用的第一道门槛

不少初学者误以为提示词工程只是“写几句好听的话让 AI 配合”，实际上它是一个系统性工程。

一个好的系统提示词应该包含：

• 角色定义：让模型清楚自己以什么身份工作。
• 任务描述：明确输入、输出和约束条件。
• 上下文格式：规定数据如何组织。
• 输出格式要求：JSON、Markdown 或其他结构化格式。
• 边界与兜底：模型不知道答案时的处理策略。
• 示例：提供 Few-shot 示例，帮助模型理解期望的输出模式。

提示词不是写一次就结束的。业务需求变化、模型版本升级、线上反馈波动，都需要维护和迭代提示词。所以建议把提示词作为代码一样管理，纳入版本控制。

4. 动手实战：构建一个最小可运行的 AI 应用

这一节我们实际动手构建一个“企业知识库问答助手”。为了便于理解，我选择使用 Python 和 FastAPI 搭建，使用一个支持 OpenAI 兼容接口的大模型服务。整体流程先跑通，再逐步加固工程细节。

4.1 准备开发环境

环境说明如下，你可以根据自己本机的实际情况调整：

• 操作系统：macOS / Linux / Windows 均可。
• Python 版本：3.9 及以上。
• 包管理工具：pip 或 poetry。
• 大模型服务：一个支持 OpenAI 兼容格式的模型 API，或者本地部署的模型服务。
• 向量数据库：Chroma（本地运行，方便快速 Demo）。

建议新建一个虚拟环境，避免依赖冲突：

python3 -m venv venv source venv/bin/activate

4.2 创建项目结构

项目结构尽量保持清晰：

ai-rag-demo/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── ingestion.py │ ├── retrieval.py │ └── config.py ├── data/ │ └── sample_docs/ ├── requirements.txt └── README.md

4.3 安装依赖

在requirements.txt中写入：

fastapi==0.115.6 uvicorn[standard]==0.32.1 openai==1.58.1 chromadb==0.5.20 python-dotenv==1.0.1

然后执行：

pip install -r requirements.txt

注意：版本号会不断更新，这里只是示例。实际安装时可以去掉版本号，让 pip 选择当前兼容的版本。

4.4 编写配置模块

app/config.py负责读取环境变量，避免把密钥写死在代码里：

import os from dotenv import load_dotenv load_dotenv() MODEL_NAME = os.getenv("MODEL_NAME", "gpt-4o-mini") BASE_URL = os.getenv("BASE_URL", "https://api.openai.com/v1") API_KEY = os.getenv("API_KEY", "") EMBEDDING_MODEL = os.getenv("EMBEDDING_MODEL", "text-embedding-3-small") COLLECTION_NAME = os.getenv("COLLECTION_NAME", "knowledge_base")

在项目根目录创建.env文件：

MODEL_NAME=gpt-4o-mini BASE_URL=https://api.openai.com/v1 API_KEY=你的密钥 EMBEDDING_MODEL=text-embedding-3-small

这里要提醒一句：任何密钥都不能提交到 Git 仓库，.env文件需要加入.gitignore。

4.5 实现文档导入与向量化

app/ingestion.py负责读取文档、切片、向量化并写入 Chroma：

import os from langchain_text_splitters import RecursiveCharacterTextSplitter from openai import OpenAI import chromadb from app.config import API_KEY, BASE_URL, EMBEDDING_MODEL, COLLECTION_NAME client = OpenAI(api_key=API_KEY, base_url=BASE_URL) chroma_client = chromadb.PersistentClient(path="./chroma_data") collection = chroma_client.get_or_create_collection(COLLECTION_NAME) def embed_texts(texts): resp = client.embeddings.create(model=EMBEDDING_MODEL, input=texts) return [item.embedding for item in resp.data] def ingest_document(file_path: str): with open(file_path, "r", encoding="utf-8") as f: raw_text = f.read() splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", " "], ) chunks = splitter.split_text(raw_text) if not chunks: print("No content extracted from file:", file_path) return embeddings = embed_texts(chunks) ids = [f"{os.path.basename(file_path)}-{i}" for i in range(len(chunks))] collection.add( ids=ids, documents=chunks, embeddings=embeddings, metadatas=[{"source": file_path} for _ in chunks], ) print(f"Inserted {len(chunks)} chunks from {file_path}")

这里的关键点是文本切片。切片长度和重叠大小会直接影响检索质量。切得太短，语义不完整；切得太长，噪声多，还容易超出模型上下文限制。实践中需要根据文档类型调整。

4.6 实现检索与问答

app/retrieval.py负责在线流程：将用户问题向量化，检索相关文档片段，组装提示词后调用大模型生成回答：

from openai import OpenAI from app.config import API_KEY, BASE_URL, MODEL_NAME, EMBEDDING_MODEL, COLLECTION_NAME import chromadb client = OpenAI(api_key=API_KEY, base_url=BASE_URL) chroma_client = chromadb.PersistentClient(path="./chroma_data") collection = chroma_client.get_collection(COLLECTION_NAME) SYSTEM_PROMPT = """ 你是一个企业知识库问答助手。请严格基于提供的资料回答用户问题。 如果资料中没有相关内容，请直接回答“资料库中暂无相关信息”，不要编造。 回答时请尽量结构清晰，可以分点说明。 参考资料： {context} """ def search_related_chunks(query: str, top_k: int = 4): query_emb = client.embeddings.create( model=EMBEDDING_MODEL, input=[query] ).data[0].embedding result = collection.query(query_embeddings=[query_emb], n_results=top_k) documents = result["documents"][0] metadatas = result["metadatas"][0] return documents, metadatas def ask_question(question: str): documents, metadatas = search_related_chunks(question) context = "\n\n".join(documents) messages = [ {"role": "system", "content": SYSTEM_PROMPT.format(context=context)}, {"role": "user", "content": question}, ] resp = client.chat.completions.create( model=MODEL_NAME, messages=messages, temperature=0.2, ) answer = resp.choices[0].message.content.strip() sources = list(set(m["source"] for m in metadatas)) return answer, sources

4.7 编写 FastAPI 入口

app/main.py提供两个接口：一个是导入文档，一个是提问。

from fastapi import FastAPI, File, UploadFile from pydantic import BaseModel from app.ingestion import ingest_document from app.retrieval import ask_question app = FastAPI(title="AI RAG Demo") class QuestionRequest(BaseModel): question: str class QuestionResponse(BaseModel): answer: str sources: list[str] @app.post("/ingest") async def ingest(file: UploadFile = File(...)): file_path = f"data/{file.filename}" content = await file.read() with open(file_path, "wb") as f: f.write(content) ingest_document(file_path) return {"status": "ok", "file": file.filename} @app.post("/ask", response_model=QuestionResponse) async def ask(req: QuestionRequest): answer, sources = ask_question(req.question) return QuestionResponse(answer=answer, sources=sources)

4.8 运行与验证

启动服务：

uvicorn app.main:app --reload --port 8000

先准备一个示例文档data/sample_docs/员工手册.txt，内容可以是一段关于公司制度的说明。

调用导入接口：

curl -X POST http://localhost:8000/ingest \ -F "file=@data/sample_docs/员工手册.txt"

调用提问接口：

curl -X POST http://localhost:8000/ask \ -H "Content-Type: application/json" \ -d '{"question": "公司的年假政策是什么？"}'

预期返回结果中会包含基于文档内容的回答，以及引用来源。如果文档中没有相关信息，模型会按照系统提示词返回“资料库中暂无相关信息”，而不是自行编造。

到这里，一个最小可运行的 RAG 应用就完成了。它虽然简单，但已经覆盖了 AI 应用的核心链路：数据导入 → 切片 → 向量化 → 检索 → 生成。

5. 从 RAG 到 AI Agent：让应用具备行动能力

5.1 什么是 AI Agent

RAG 解决的是“让模型知道更多信息”的问题。AI Agent 解决的是“让模型做更多事情”的问题。

Agent 是一套“模型 + 工具 + 循环控制”的系统：

• 模型负责理解任务、拆分步骤、做出决策。
• 工具负责执行具体操作，比如搜索、计算、查库、调 API。
• 循环控制负责在模型和工具之间反复交互，直到任务完成或达到终止条件。

一个简单的工作流如下：

用户输入目标 ↓ 模型规划下一步（需要什么工具、什么参数） ↓ 调用工具，获取结果 ↓ 模型判断任务是否完成 ↓ 未完成则继续循环；已完成则输出结果

5.2 用 Function Calling 实现工具调用

目前主流的实现方式是通过模型的 Function Calling（函数调用）能力。模型在生成回复时，不是直接输出最终答案，而是输出一个“需要调用哪个函数、参数是什么”的结构化结果，由程序真正执行函数，再把结果返回给模型。

下面是一个简化示例，演示如何让模型调用一个自定义天气查询工具：

from openai import OpenAI client = OpenAI(api_key="你的密钥") tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，例如 北京"} }, "required": ["city"], }, }, } ] def get_weather(city: str): # 实际项目中这里会接入真实天气 API return f"{city} 今天多云，气温 18℃" def run_agent(user_input: str): messages = [{"role": "user", "content": user_input}] while True: resp = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=tools, ) msg = resp.choices[0].message # 如果模型没有要求调用工具，说明最终答案已生成 if not msg.tool_calls: return msg.content messages.append(msg) for tool_call in msg.tool_calls: if tool_call.function.name == "get_weather": import json args = json.loads(tool_call.function.arguments) result = get_weather(args["city"]) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result, }) print(run_agent("北京今天天气怎么样？"))

这个例子虽然简单，但展示了 Agent 的核心循环：模型请求调用工具 → 程序执行 → 结果回传 → 模型继续推理。

5.3 Agent 开发中的几个关键问题

在实际项目中做 Agent，比 Demo 复杂得多。有几个问题必须要提前考虑。

第一个是“怎么让 Agent 不跑偏”。模型在多步循环中可能做出错误决策，所以需要给 Agent 设置严格的约束条件，比如只允许调用白名单工具、限制最大迭代次数、关键操作需要人工审批。

第二个是“怎么管理上下文”。每一次工具调用结果都要放回上下文，多轮之后很容易超过上下文窗口限制。解决办法是设计上下文裁剪策略，比如只保留最近的工具结果摘要，或者把长期记忆放到外部存储。

第三个是“怎么保证结果可审计”。Agent 自主执行带来的风险在于不可控。建议记录完整的执行轨迹，包括每一步的决策、工具调用、参数、结果，方便事后审计和排错。

6. 模型部署与推理优化

6.1 选 API 还是自部署？

很多团队在“调用云上 API”和“自部署开源模型”之间犹豫。这两种方式各有适用场景。

调用 API 的优势是部署成本低、上线速度快、模型质量高。适合中小型应用、创业项目、以及模型能力要求较高的场景。缺点是数据会经过第三方服务，对数据合规要求高的企业需要谨慎评估。

自部署开源模型的优势是数据可控、长期推理成本可能更低、可以针对业务微调。劣势是需要 GPU 资源，运维复杂度高，模型效果可能不如头部商业模型。

实践中，很多企业的策略是“两者结合”：核心敏感业务走私有化部署，非敏感、高并发场景走 API，或者作为降级方案。

6.2 开源模型部署的基本思路

如果选择自部署，以 vLLM 为例，部署一个 Qwen 系列模型的流程大致如下。

先安装 vLLM：

pip install vllm

然后启动 OpenAI 兼容的推理服务：

vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8001 \ --dtype auto \ --served-model-name qwen2.5-7b

启动后，客户端代码可以直接用 OpenAI SDK 调用：

from openai import OpenAI client = OpenAI( api_key="EMPTY", base_url="http://localhost:8001/v1", ) resp = client.chat.completions.create( model="qwen2.5-7b", messages=[{"role": "user", "content": "介绍一下 RAG 的核心流程"}], ) print(resp.choices[0].message.content)

这里要强调的是，不同开源模型的硬件需求差异很大。7B 级别的模型在消费级显卡上可以运行，但并发能力有限；70B 以上级别的模型通常需要多卡 A100/H100 甚至更高配置。部署前一定要根据实际流量评估硬件成本。

6.3 推理优化的常见手段

模型部署后，性能优化是长期工作。常见的优化方向包括：

• 量化：把 FP16 权重压缩为 INT8 或 INT4，降低显存占用，提升推理速度，但可能带来微小精度损失。
• 批处理：通过动态批处理提高 GPU 利用率。
• Prompt 缓存：相同前缀的请求可以复用 KV Cache，降低延迟。
• 流式输出：首字延迟降低，用户体验提升。
• 多副本与负载均衡：应对高并发场景。

需要注意的是，优化手段不是越多越好。每种优化都会在性能、成本、质量之间做权衡，需要通过压测和线上数据来验证。

7. 常见问题与排查思路

AI 应用开发和传统后端开发不同，模型输出具有不确定性，排查问题的方式也需要调整。

下面整理了几个高频问题：

这里再展开说一个非常常见的排查场景：模型“幻觉”问题。

很多团队把幻觉归结为模型不够好。实际上，幻觉的根源往往是信息不足或提示词约束不够。排查时可以按以下顺序逐层检查：

1. 检索是否命中。打印出每次提问命中的文档片段，确认相关资料是否真的被检索到。
2. 上下文是否完整。检查送入模型的 Context 是否包含了检索结果，有没有因为长度截断丢失关键内容。
3. 提示词约束是否明确。系统提示词里是否明确要求“无法回答时说明不知道”。
4. 温度参数是否过高。生成类任务可以适当调低 temperature，比如 0.2 到 0.5。

8. 最佳实践与工程建议

8.1 把提示词当成代码管理

提示词是 AI 应用的核心逻辑之一。建议把提示词抽离成独立模块或配置文件，纳入 Git 管理，并建立版本记录。当线上效果波动时，可以快速回滚到稳定版本。

提示词的变更要有评审和测试机制。一个简单的做法是建立黄金评测集，每次修改提示词后，用同一批问题跑一遍，对比输出质量。

8.2 建立评估闭环

传统软件有单元测试，AI 应用也需要评估体系。

至少应该建立三层评估：

• 单点评估：针对每条回答，检查内容正确性、格式规范性、引用准确性。
• 场景评估：针对典型用户问题集，统计整体通过率。
• 线上监控：对线上请求做抽样评估，监控回答长度、延迟、用户反馈、成本等指标。

评估指标可以包括准确率、相关性、召回命中率、无效回复率、平均响应时间等。

8.3 安全与权限边界

AI 应用上线前，安全是必须考虑的问题。

涉及内部数据时，必须在应用层做权限控制，不能把所有知识库文档都无差别提供给所有用户。一个常见设计是：先判断用户权限，再决定检索范围，最后才调用模型生成回答。

还需要关注提示词注入风险。用户输入可能包含恶意指令，试图绕过系统提示词约束。缓解手段包括：对用户输入做长度限制和关键词过滤、将系统提示词与用户输入隔离、对模型输出做二次校验等。

8.4 成本控制

大模型 API 的成本按 token 计算，设计不当会导致成本快速上升。

控制成本的几个实用策略：

• 缓存常见问题的回答，减少重复调用。
• 压缩多轮对话历史，只保留必要信息。
• 根据任务难度选择不同模型，简单任务用便宜模型，复杂任务才用更强的模型。
• 长文档处理尽量用“先检索再生成”，避免把所有内容都塞进上下文。
• 设置每日调用上限和异常告警。

8.5 生产环境注意事项

最后总结几个生产环境特别需要注意的点：

• 依赖版本要锁定，避免模型 API、SDK 升级导致行为变化。
• 所有外部调用都要有超时和重试机制。
• 日志要记录模型输入输出、token 消耗、耗时，方便排错和成本分析。
• 模型升级前要做回归测试，不能只看单条效果。
• 涉及数据删除、修改、自动执行等操作时，保留人工确认环节。
• 开发、测试、生产环境隔离，使用不同的 API Key 和权限。

9. 学习路线与下一步

9.1 第一阶段：打牢基础

• 了解大模型的基本原理：Token、Prompt、Temperature、上下文窗口。
• 熟悉主流模型的能力边界和 API 调用方式。
• 掌握 Python 基础，能编写简单的 API 调用脚本。

9.2 第二阶段：掌握 RAG 与提示词工程

• 手写一个简单的 RAG 流程，理解各环节职责。
• 熟悉文本切片的常见策略和向量检索原理。
• 学会用评估问题集验证提示词修改效果。

9.3 第三阶段：深入 Agent 开发

• 掌握 Function Calling 的调用流程。
• 使用主流 Agent 框架搭建多步骤任务。
• 理解 Agent 的上下文管理、工具权限和失败恢复机制。

9.4 第四阶段：工程化与生产落地

• 学习模型部署工具，理解量化、批处理、流式输出。
• 建立 AI 应用的监控、评估、安全体系。
• 在真实项目中实践成本控制、权限隔离、灰度发布。

关于学习路径，有一点想提醒各位读者：不要贪多。AI 领域每天都有新模型、新框架出现，追新永远追不完。建议选定一个主攻方向，比如“RAG 应用开发”或者“Agent 开发”，围绕它做两到三个完整项目，把工程化能力练扎实，再横向扩展。

回到文章开头的话题——AI 领袖们说奇点已开始。我们无法预测这个判断最终是否成立，但可以确定的是，AI 工程化的大门已经打开，模型正在从“展示品”变成“生产力工具”。这对开发者来说是一个实在的机会：与其争论概念，不如动手写一个属于自己的 AI 应用，然后把可靠、可用、可控这四个字贯穿到整个开发过程中。

如果这篇文章对你有帮助，建议收藏备用。后续我还会结合实际项目，继续整理 RAG 细节调优、Agent 架构设计、模型部署压测等专题内容。有什么问题，也欢迎在评论区一起交流。