企业官网建设流程全解析

看到“7天从小白到大神”这类标题，多数人的第一反应是反感。但如果你把它拆开看，它真正想表达的问题并不夸张：AI Agent 开发这个新赛道，确实给很多没有名校背景、没有大厂经历的人留下了一道门。

难点从来不是“学不会”，而是“不知道按什么顺序学”“学到什么程度算入门”“拿什么作品证明自己会”。

这篇文章不是标题党式的“7天速成承诺”，而是把 7 天重新定义为一个“可交付的入门闭环”。我会完整拆解一套适合零基础双非背景读者入局 AI Agent 开发的路径，覆盖 LangChain 与 LangGraph 的关系、RAG 知识库实战、私有化部署、调优与对齐、以及双非背景如何用工程作品证明自己。

读完你可以得到三样东西：一条不绕弯的学习路线、几个能直接跑通的代码示例、一套能写进简历的项目描述思路。

1. AI Agent 开发到底在学什么

很多人听说过“AI Agent 很火”，但第一步就理解偏了。他们以为 Agent 是一个更聪明的模型，学习路径应该是“先学大模型原理，再学微调”。实际上，AI Agent 是一个程序系统，不是一个人工智能模型。

一个完整 Agent 通常由四部分组成：

• 模型（Model）：负责理解和生成文本，通常是 GPT、Qwen、Llama 这类大模型。
• 规划（Planning）：把用户任务拆解成步骤，决定先做什么、后做什么、做错了要不要重试。
• 工具（Tools）：调用外部能力，比如搜索、数据库、HTTP API、代码执行器。
• 记忆（Memory）：短期记忆保存当前对话上下文，长期记忆保存用户偏好和历史事实。

如果你只把 Agent 当作“套了一层 Prompt 的模型调用”，那你做出来的东西只能是聊天机器人，不是 Agent。Agent 最核心的技术含量，在“规划”和“工具调用”这两个环节，而这两个环节恰恰需要工程化的编排框架来支撑。

这也是为什么 AI Agent 开发对双非背景友好。它不是纯科研岗位，不需要你复现 Transformer 论文，它需要的是把多个组件编排成稳定服务的工程能力。工程能力可以通过 GitHub 仓库、技术博客、可运行的 Demo 来证明，学历在里面占的比重没有想象中那么大。

真正要警惕的是另一个误区：收藏了大量教程、安装了十几个框架，却始终没有完整跑通过一个带知识库、能调用工具、能部署上线的 Agent 项目。

2. 技术栈地图：从 LangChain 到 LangGraph

2.1 LangChain：先理解“链条”思想

LangChain 是 AI Agent 生态里最出名的框架之一。它解决的核心问题，是把 Prompt、模型、输出解析器、记忆、工具这些组件串成一条可执行的链（Chain）。

一个最简单的 LangChain 应用，概念上类似这样：用户输入 → 拼装 Prompt → 调用模型 → 解析输出 → 返回结果。在简单问答、文档总结、批量生成场景里，链式结构完全够用。

但它有个天然限制：链条是线性的。一旦任务需要“先检索知识库，再判断是否需要调用外部工具，如果工具结果不完整就重新提问”，线性链条写起来就非常别扭，代码会变成一堆 if-else 和胶水逻辑。

2.2 LangGraph：从“链”到“图”

LangGraph 是 LangChain 生态内的一个编排框架，它把执行流程从“链”升级为“图”。

图由节点（Node）和边（Edge）组成。节点就是一个处理函数，边表示执行流向。相比链条，图有两个关键优势：

• 支持循环：Agent 判断工具结果不满意时，可以回到之前的节点重新执行。
• 支持条件路由：根据某个节点的输出，决定下一步走哪个分支。

这对 Agent 来说是刚需。因为 Agent 的本质是“自主规划 + 多轮工具调用”，它不是一次走完固定的步骤，而是一个动态循环：思考 → 行动 → 观察结果 → 再思考。

2.3 LangChain 与 LangGraph 的关系

很多新手会把 LangChain 和 LangGraph 对立起来，认为学新不学旧。实际上 LangGraph 脱胎于 LangChain 生态，两者解决的是不同层级的问题。

用一句话概括我的判断：LangChain 帮你理解“模型外面要包哪些组件”，LangGraph 帮你理解“这些组件如何被动态调度”。想入局 Agent 开发，重心应该放在 LangGraph。

2.4 周边技术栈

除了编排框架，还需要掌握四类周边能力：

• RAG 与向量数据库：给 Agent 注入私有知识，常用 Chroma、FAISS、Milvus、Qdrant。
• 模型服务化：把本地模型包装成可调用的 API，常用 Ollama、llama.cpp、vLLM。
• 私有化部署：涉及容器、GPU 资源、网络隔离、权限控制。
• 评测与调优：构建评测集，记录每次改动效果，否则无法判断项目是变好还是变差。

这四块下面都会展开讲，但先记住：Agent 开发的完整闭环是“模型 + 编排 + 知识 + 服务化 + 评测”，不是只有一个 LangGraph。

3. 7天入门路线设计

先说结论：7 天不可能把一个零基础的人变成“大神”，但 7 天足够让一个人完成一次“可交付的入门闭环”。关键在于把目标从“精通”换成“跑通 + 能解释 + 能改”。

我给出的路线以实践为主要驱动，每天都有明确产出和验证标准。

每天的落地细节可以灵活调整，但节奏不要变：先跑通，再理解，再改进。

如果第一天环境搭建卡住了，不要死磕“最完美的方案”。比如本地模型太慢，就先用一个较小的量化模型；显存不够，就把模型规模调小，或者先用在线 API 跑通流程，后续再换私有化模型。

这套路线的本质是：先用最小成本建立“模型输出感”，然后逐步增加工程复杂度。很多新手学 AI Agent 的第一个失败点，就是试图在大模型原理学完、LangChain 文档读完之后才开始动手，结果一个月过去了连一个 Demo 都没有。

4. LangGraph 核心概念与最小示例

4.1 四个核心概念

LangGraph 最重要的四个概念是：

• State（状态）：整个图执行过程中共享的数据结构，通常用 TypedDict 定义。
• Node（节点）：一个普通函数，输入 State，输出 State 的增量更新。
• Edge（边）：节点之间的连接关系，分为普通边和条件边。
• StateGraph（状态图）：承载上述所有定义的图对象，编译后可以运行。

条件路由对应 LangGraph 中的add_conditional_edges，它允许你在一个节点执行完后，根据返回值决定下一步去哪个节点。

还有一个容易忽略的概念是 Checkpointer（检查点）。它用来保存每一步执行的状态，配合thread_id可以实现对话历史持久化，也就是 Agent 的长期记忆。没有检查点，图每次运行都是“失忆”的。

4.2 最小示例：带条件路由的状态图

下面用一段可运行的 Python 代码演示 StateGraph 的完整流程。

# 文件路径：demo_langgraph_tutorial.py from typing import TypedDict, Literal from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): user_input: str step: int messages: list # 节点函数：处理用户输入 def process_input(state: AgentState) -> AgentState: return { "step": state["step"] + 1, "messages": state["messages"] + ["已接收输入：" + state["user_input"]], } # 节点函数：走检索分支 def search_node(state: AgentState) -> AgentState: return { "step": state["step"] + 1, "messages": state["messages"] + ["执行知识库检索"], } # 节点函数：走对话分支 def chat_node(state: AgentState) -> AgentState: return { "step": state["step"] + 1, "messages": state["messages"] + ["执行普通对话"], } # 路由函数：根据输入决定下一步 def route(state: AgentState) -> Literal["search", "chat"]: if "文档" in state["user_input"] or "知识库" in state["user_input"]: return "search" return "chat" # 创建状态图 builder = StateGraph(AgentState) # 添加节点 builder.add_node("process", process_input) builder.add_node("search", search_node) builder.add_node("chat", chat_node) # 添加边：入口 -> process builder.add_edge(START, "process") # 添加条件路由：process 执行完后根据返回值走 search 或 chat builder.add_conditional_edges( "process", route, {"search": "search", "chat": "chat"}, ) # 添加结束边 builder.add_edge("search", END) builder.add_edge("chat", END) # 编译并运行 graph = builder.compile() result = graph.invoke({ "user_input": "帮我查一下知识库里的部署文档", "step": 0, "messages": [], }) print("最终状态：", result)

这段代码的关键逻辑有三处。

第一，每个节点函数接收当前 State，返回更新后的 State 字段。LangGraph 会自动合并这些更新。

第二，add_conditional_edges是条件路由的入口。它接收三个参数：源节点名、路由函数、返回值到目标节点的映射表。路由函数必须返回映射表中存在的 key。

第三，graph.invoke()是运行入口，输入初始 State，输出最终 State。

运行这段代码，预期输出是：

最终状态： {'user_input': '帮我查一下知识库里的部署文档', 'step': 2, 'messages': ['已接收输入：帮我查一下知识库里的部署文档', '执行知识库检索']}

如果输入改成“你好”，最后一条消息会变成“执行普通对话”。这样你就亲眼看到了条件路由的效果。

4.3 循环、子图与记忆

条件路由只是开始。LangGraph 真正强的地方在于它可以表达循环。

比如 Agent 调用完工具后，发现工具返回的结果不完整，可以通过条件边回到“规划节点”重新生成下一步计划。这种能力用 LangChain 的线性 Chain 很难优雅实现，用 LangGraph 就是加一条边的事情。

子图（Subgraph）则用于拆分复杂流程。当一个 Agent 太大时，可以把它拆成多个子图，然后在一个总图中按条件调用。这是一种自然的模块化手段。

长期记忆则依赖 Checkpointer。LangGraph 提供了基于内存或外部存储的检查点保存机制，配合thread_id可以把历史人机对话保存下来，下次继续执行。这部分实现方式会随版本变化，建议直接查阅你安装版本的官方文档。

4.4 可视化与调试

把图编译后，可以用graph.get_graph().draw_ascii()打印 ASCII 形式的图结构，快速确认节点和边的连接是否符合预期。

print(graph.get_graph().draw_ascii())

如果涉及更复杂的可视化，可以考虑把图导出为 Png 或接入前端框架，但初期用 ASCII 图就够了。不少人在这一步会纠结“要不要用可视化平台”，我的建议是先把执行日志打清楚，比可视化更重要。

5. RAG 实战：给 Agent 注入企业知识

5.1 RAG 解决什么问题

RAG（Retrieval-Augmented Generation，检索增强生成）是当前企业知识库问答最主流的方案。

它解决的核心问题是：大模型没有学习过你的私有数据，直接问它就会胡说。RAG 的思路是，在模型生成之前，先从外部知识库检索出与问题相关的文档片段，再把这些片段作为上下文塞给模型，让模型基于事实回答。

相比让模型“记住”全部知识，RAG 的优势在于知识可更新、可追溯、不需要重新训练模型。企业内部文档、操作手册、产品 FAQ、日志分析报告，都可以用 RAG 接入。

5.2 完整链路拆解

一个标准的 RAG 流程包含五个步骤：

1. 文档加载：读取 PDF、Word、Markdown、HTML 等格式。
2. 文本切块：把长文档切成有语义边界的短片段。
3. 向量化：用 Embedding 模型把文本转成向量。
4. 向量存储与检索：把向量存入向量数据库，用户提问时做相似度检索。
5. 生成：把检索到的片段拼入 Prompt，交给大模型生成回答。

这里的核心难点是切块和检索质量，不是向量化本身。切得太碎，上下文不完整；切得太大，检索精度下降，还浪费模型上下文窗口。

5.3 代码示例：切块 + 向量存储 + 检索问答

下面给出一个最小 RAG 示例，重点演示切块和向量检索两个环节。

# 文件路径：demo_rag_tutorial.py from langchain_text_splitters import RecursiveCharacterTextSplitter # 模拟一份本地文档内容 doc = """AI Agent 是一个由模型、规划、工具、记忆组成的程序系统。 它可以自主拆解任务，调用外部工具，并根据执行结果调整下一步计划。 LangGraph 是一个用于构建状态化 Agent 的编排框架。 RAG 是检索增强生成，用于给模型注入私有知识。""" splitter = RecursiveCharacterTextSplitter( chunk_size=100, chunk_overlap=20, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " "], ) chunks = splitter.split_text(doc) for i, chunk in enumerate(chunks): print(f"[chunk {i}] {chunk}")

这里的关键参数是chunk_size和chunk_overlap。前者决定每个块的最大字符数，后者让相邻块保留一部分重叠，避免关键句子被拦腰截断。

如果要把这些文本块交给模型检索，就需要向量化和向量存储。下面用 Chroma 做演示：

# 文件路径：demo_rag_vector_store.py from langchain_chroma import Chroma from langchain_ollama import OllamaEmbeddings # 初始化本地 Embedding 模型 embedding_model = OllamaEmbeddings(model="qwen2.5:7b") # 基于上面的 chunks 构建向量库 vector_store = Chroma.from_texts( texts=chunks, embedding=embedding_model, persist_directory="./chroma_db", ) # 检索与问题最相关的 2 个片段 query = "LangGraph 是什么？" docs = vector_store.similarity_search(query, k=2) for doc in docs: print(doc.page_content)

在这个示例中，我把向量库持久化到了本地目录./chroma_db，这样下次启动不需要重新构建。

检索到相关片段后，把片段拼进 Prompt，再交给 ChatOllama 生成回答，就是一个完整的 RAG 问答闭环。工程上还需要处理一个问题：答案里的引用溯源。真正可信的 RAG 系统，应该把检索到的文档来源一起返回给用户，让用户能点击查看原文片段。

5.4 企业级 RAG 的常见痛点

5.5 从 RAG 到 Agentic RAG

RAG 和 Agent 也不是两条独立的路线。目前热门的“Agentic RAG”，把 RAG 封装成 Agent 的一个能力：Agent 先判断问题是否需要检索，需要的话再决定检索策略、评估检索结果是否充分，甚至多次检索后汇总。

这里引入 LangGraph 的意义在于，把“是否需要检索”“检索结果是否够用”“是否需要重新检索”这些判断变成图里的条件路由。逻辑清晰，也方便测试。

6. 私有化部署：从 Demo 到可交付

6.1 为什么企业强制要求私有化部署

很多 Agent 项目在本地跑得很好，一谈到交付就卡壳。原因在于企业对数据安全的要求：内部文档、客户信息、业务数据不能发给外部 API，必须在自有服务器或私有云环境内运行。

私有化部署意味着三件事：模型权重私有化、数据不出域、服务接口内网可控。这也是当前很多企业级 Agent 平台的核心卖点。

6.2 模型服务化方案选型

选型原则很简单：个人学习选 Ollama，边缘设备选 llama.cpp，企业生产首选 vLLM。

6.3 本地部署示例：Ollama 启动模型并验证接口

下面以 Ollama 为例，演示把本地模型变成一个 OpenAI 兼容接口。

# 拉取本地模型（以 qwen2.5 7B 为例） ollama pull qwen2.5:7b # 启动 Ollama 服务 ollama serve

启动后，Ollama 默认监听本机 11434 端口。可以通过 curl 验证接口是否可用：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": "用一句话介绍 AI Agent"} ] }'

如果返回包含choices字段的 JSON，说明模型服务调用成功。这个接口格式与 OpenAI 兼容，意味着你的应用层代码可以复用大量现成 SDK，只需要把 base_url 指向本地地址。

6.4 FastAPI 封装成一个对外服务

模型服务层解决后，业务代码也应该包装成 HTTP 接口，方便前端或业务系统调用。

# 文件路径：app.py from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class QueryRequest(BaseModel): question: str @app.post("/agent/ask") def ask_agent(req: QueryRequest): # 这里替换为你的 LangGraph 图调用逻辑 answer = f"收到问题：{req.question}" return {"question": req.question, "answer": answer}

启动命令：

uvicorn app:app --host 0.0.0.0 --port 8000

这里有一个重要的安全提醒：0.0.0.0意味着所有网卡都可以访问这个接口。如果服务器有公网 IP，千万不要在没有鉴权的情况下直接暴露，否则任何人都可以调用你的模型接口，产生费用甚至有数据泄露风险。生产环境至少要加一层 API Key 或网关鉴权。

6.5 部署中的资源与风险控制

私有化部署真正难的不是安装，而是资源规划与权限控制。

显存决定你能部署多大的模型。7B 量化模型在 6GB 以上显存可能跑起来比较勉强，14B 模型则需要更大显存。如果只有 CPU，可以尝试小量化模型，但速度会明显下降。实际项目中，应该先用小模型跑通流程，再评估升级大模型的成本。

权限控制方面，遵循最小权限原则：服务只监听内网或通过反向代理暴露，模型目录只授权给运维账号，数据写入目录单独隔离。任何涉及生产环境的变更，都要先在测试环境验证，准备好回滚方案。

7. 调优与对齐：让 Agent 真正可用

7.1 调优不是只有微调

很多人一听到“调优”就想到大模型微调。实际上，对于入门和大部分业务场景，调优的顺序应该是：

1. Prompt 调优：调整提示词、系统人设、输出格式。
2. 生成参数调优：调整温度、上下文长度、随机性。
3. RAG 参数调优：调整切块大小、召回数量、重排序策略。
4. 微调与对齐：数据量足够且行为仍不对时，再考虑对模型本身做微调，或使用对齐技术。

前三种成本低、见效快，是 Agent 项目调优的重点。

7.2 Prompt 调优示例

用一个系统提示词模板说明：

你是一个企业知识库问答助手。 回答规则： 1. 只能基于提供的文档片段作答； 2. 如果文档片段中没有答案，明确回答“资料库中暂无相关信息”； 3. 回答需要标注引用编号，格式为[1]、[2]； 4. 不要编造事实，不要猜测； 5. 保持中文回答，语气专业简洁。

这个 Prompt 的价值不在于“提示词写得好”，而在于把输出边界限定死了。尤其“资料库中暂无相关信息”这条，能明显减少模型在 RAG 场景下的幻觉。你可以在评测集上统计：加了这个约束后，无中生有的答案占比是否下降。

7.3 生成参数与检索参数调整

RAG 调优里最容易被忽视的是“重排序”。第一次检索返回 20 个候选片段，用 Rerank 模型挑出最相关的 5 个，效果往往比单纯调大 top_k 好很多。但如果项目刚起步，先把chunk_size、top_k和 Prompt 约束调好，就能获得大部分收益。

7.4 对齐：让模型行为符合产品预期

大模型领域的“对齐”通常指让模型行为符合人类偏好，常见方法有 RLHF（基于人类反馈的强化学习）和 DPO（直接偏好优化）。这些方法新手不需要在第一阶段实现，但要理解它的目标：不只让模型“会说话”，而是让模型“按产品规则说话”。

工程层面的对齐，更常见的手段是：

• 工具权限限制：Agent 只能调用白名单内的工具。
• 输出格式约束：统一返回 JSON，方便下游解析。
• 敏感词过滤与内容审核：在模型输入输出两侧做规则校验。
• 越权行为拦截：比如 Agent 尝试执行危险命令时，强制终止并记录日志。

7.5 建立自己的评测集

调优如果没有评测，就等于碰运气。建议从第一天开始就维护一个评测集：

• 收集 20 到 50 个真实问题，覆盖常见场景和边界场景。
• 每个问题记录标准答案或关键信息点。
• 每次改动 Prompt 或参数，跑一遍评测集，记录正确率和失败案例。
• 把失败的案例归因：是检索没找到、模型没理解，还是输出格式错误。

这个评测集不需要很复杂，一个 Markdown 表格或者 JSON 文件就够。但它的价值极高：面试时你能拿出“我迭代了几次、效果提升了多少”的数据，这比一百句“我很熟练”都有说服力。

8. 常见问题与排查思路

排查时记住一个原则：先看日志，再猜原因。LangGraph 的执行日志会打印每个节点的输入输出，这是定位 Agent 行为问题最直接的入口。不要一上来就改代码，先确认问题出在哪个节点。

9. 双非背景如何用作品证明自己

9.1 什么项目能打动面试官

面试官看一个 Agent 项目，通常只看三件事：

• 它的架构是否清晰：是否分清了模型、编排、知识库、服务化各层。
• 你是否踩过真实坑：是否经历过切块效果差、条件路由失效、接口无鉴权这类问题。
• 它是否可交付：能不能部署、有没有接口文档、有没有效果记录。

明白这一点，你就不该做一个“照着教程抄一遍”的 Demo，而应该做一个能回答这三个问题的完整项目。

建议项目实践方向：

• 做一个带 RAG 知识库的企业内部问答 Agent，支持引用溯源。
• 把 Agent 封装成 FastAPI 服务，在本地或云服务器上部署起来。
• 维护一份评测集，记录 Prompt 调整前后效果变化。
• 写一篇技术博客，画清楚你的图结构，讲明白一次失败排查过程。

一个能跑通的本地 Demo 只能证明你“会抄”，一个能部署、能评测、能回答提问的完整项目，才能证明你“会做”。

9.2 把学习过程变成工程资产

所有学习过程中的代码、文档、测试记录，都放进 GitHub 仓库。这不是为了给别人看，而是为了让自己形成“可复现”的习惯。

推荐的最小仓库结构：

agent-project/ ├── app/ # 业务代码 │ ├── agent_graph.py # LangGraph 图定义 │ └── main.py # FastAPI 入口 ├── data/ # 知识库文档 ├── tests/ # 评测集与自动化脚本 ├── docs/ # 架构设计、部署文档 └── README.md # 项目说明

README 里至少写清楚：项目解决了什么问题、技术栈是什么、如何运行、如何验证效果。这份 README 就是你的“技术名片”。

9.3 面试表达建议

面试讲项目时，不要只讲“我用了 LangGraph 和 RAG”。要讲清楚一个完整的故事：输入是什么、状态怎么流转、在哪个节点做了条件判断、检索失败怎么办、最后怎么部署和评测。

比如可以这样说：

“这个项目是一个企业知识库问答 Agent。用户输入问题后，图先进入意图判断节点，如果判断需要检索知识库，就进入 RAG 节点；向量库召回片段后，再经过一个判断节点，如果相关度不够就重新检索，如果够了就交给大模型生成答案。最初检索效果不好，我把切块方式从固定字符切块改成了按文档标题结构切块，并在召回后加入了一道相关性阈值判断，最终在 30 条评测集上把回答准确率从 60% 提到 85%。”

这段表达之所以有效，是因为它包含了状态流转、真实调优过程和评测数据，完整体现了工程能力。

9.4 回顾与后续学习方向

再回到开头那句话：7 天成为大神不现实，但 7 天入门 Agent 开发是能做到的。关键在于不要追逐框架数量，而是围绕一个完整项目把“模型调用、图编排、RAG、私有化部署、调优对齐、效果评测”这条链路真正走通一次。

走通之后，值得继续深入的方向有几个：Agentic RAG 的复杂检索策略、多 Agent 协作与消息通信、长期记忆的存储与检索、更大规模评测体系的建设、以及生产级部署中的可观测性与灰度发布。

这些方向都属于“在已有项目上做厚”，而不是“从零开始学另一个框架”。所以第一篇博客可以从今天开始写，第一个项目可以从明天开始动手。Agent 开发的窗口期还没关，真正拉开差距的，是你实际跑通并交付过几个项目。