企业官网建设流程全解析

如果你最近在关注 AI 创业生态，会发现一个明显趋势：几乎每周都有新的 LLM 创业项目出现在 GitHub Trending、Product Hunt 和技术社区。无论是做 AI Agent、垂直行业知识库、代码助手，还是自动化工作流，团队的方向各不相同，但本质都在回答同一个问题：如何在大模型能力之上，做出别人难以复制的产品价值。

这篇文章不是要给你一份“风口预测”，而是从技术落地角度，拆解 LLM 创业方向背后的通用技术栈。你会看到初创公司追逐的“下一个大事件”到底对应哪些工程问题，也会拿到一套可以直接运行的 LLM 应用开发示例，包括 RAG 检索、Agent 思路、本地模型部署，以及一个经常被问到的问题：ComfyUI 与 LLM 是否必须在同一台电脑上运行。

适合正在选型的后端开发者、准备入门 LLM 应用的新人，以及想在企业内部推进 AI 落地的技术负责人阅读。

1. 背景与核心概念：LLM 创业公司到底在追什么

1.1 LLM 成为应用基础设施

大型语言模型（Large Language Model，LLM）是通过海量文本数据训练的深度学习模型，核心能力是根据上下文生成自然语言文本。ChatGPT 这类产品火爆之后，LLM 已经被视为新一代应用基础设施，就像过去的数据库、消息队列一样，开发者在它之上快速搭建智能应用。

但基础设施本身并不稀缺。真正稀缺的是把通用模型变成特定业务价值的能力。初创公司很少去从零训练一个基础大模型，因为数据、算力、人才门槛太高。它们更愿意做三件事：

• 在 LLM 之上做应用层产品，比如 AI 客服、AI 法律助手、AI 编程工具。
• 围绕 LLM 构建工具链和开发框架，比如编排框架、评估平台、模型网关。
• 做垂直场景的私有化模型或部署方案，比如医疗、金融等对数据敏感行业。

这也解释了为什么标题说的是“chasing the next big thing in LLMs”：大家追逐的不是模型参数规模的数字，而是能用模型解决实际问题的产品形态。

1.2 初创公司布局的热门方向

从近两年的项目类型看，LLM 创业方向大致可以分为几类：

你会发现，这些方向不是互斥的。一个做垂直知识库的公司，可能同时用 RAG 和 Agent；一个做代码智能的公司，也要考虑私有化部署。最终考验的是工程能力，而不是单纯“调用模型”。

1.3 开发者应该如何切入

对普通开发者来说，不需要一上来就训练自己的大模型。更务实的学习路径是：

1. 学会调用主流 LLM API，理解 Prompt、Token、温度系数等基本概念。
2. 掌握 RAG 全链路，知道如何把私有知识库接入模型。
3. 了解 Agent 的工作原理，能写简单的工具调用流程。
4. 学会本地部署一个开源模型，理解量化、显存、推理延迟之间的关系。

下面几章会按照这个路径展开，每一部分都尽量给出可运行的示例。

2. LLM 应用落地要解决的核心问题

2.1 模型能力与业务需求之间的差距

很多人以为 LLM 应用开发就是把用户问题发给模型，再把结果返回给用户。但真实业务往往复杂得多：模型不知道企业内部文档，模型会一本正经地编造不存在的内容，模型调用接口的格式不稳定，单个模型无法完成多步任务。

所以初创公司追逐的“下一个大事件”，本质上是在缩小模型能力和业务需求之间的差距。缩小差距的手段主要有三个：RAG、Agent 和微调。三者解决的问题不同，可以组合使用。

2.2 RAG：把知识库交给模型

RAG（Retrieval-Augmented Generation）即检索增强生成。核心思路是：在模型生成答案之前，先从外部知识库中检索相关文档片段，把检索结果拼进 Prompt，再让模型基于这些内容生成答案。

RAG 要解决的典型问题：

• 模型训练数据有截止时间，不知道最新信息。
• 企业内部文档、私有数据没有被模型学习过。
• 模型容易凭空编造内容，需要提供事实依据。

一个完整的 RAG 流程包含五个环节：

1. 文档加载：把 PDF、Word、Markdown 等解析成纯文本。
2. 文本切块：按段落、句子或固定长度切成小块，避免超出模型上下文。
3. 向量化：用 Embedding 模型把文本块转换成向量。
4. 向量存储：把向量写入向量数据库，如 Chroma、Milvus、Weaviate。
5. 检索生成：把用户问题向量化后检索最相似的文本块，拼入 Prompt 后调用 LLM 生成答案。

RAG 的优势是无需训练模型、知识可实时更新、结果可溯源。缺点是检索质量直接影响生成质量，如果切块不合理或向量相似度匹配不准，答案仍然会偏。

2.3 Agent：从“回答问题”到“完成任务”

Agent（智能体）是比 RAG 更进一步的形态。RAG 仍然是被动回答，Agent 则能主动规划：拆解任务、调用工具、观察结果、调整策略，直到完成目标。

一个典型的 Agent 循环：

1. 接收用户目标。
2. 模型规划出若干子任务。
3. 调用外部工具（搜索、计算器、API、代码执行器）执行子任务。
4. 把工具结果反馈给模型。
5. 模型根据结果决定是否继续或输出最终答案。

Agent 适合的场景包括：自动整理资料、自动操作浏览器、自动生成并执行脚本、多系统数据汇总。但 Agent 的稳定性是个难点：任务步骤越长，越容易出错；工具调用失败时需要重试策略；同时 Agent 消耗的 Token 远高于普通问答，成本控制是个现实问题。

2.4 微调、蒸馏与私有化

RAG 和 Agent 都是在模型外部做文章。微调（Fine-tuning）则是修改模型自身的行为。

什么时候需要微调？

• 需要固定输出格式，比如要求模型总是输出 JSON。
• 需要掌握特定领域术语和表达风格。
• 需要降低延迟，用较小模型获得接近大模型的效果。
• 需要对某些行为进行约束，比如拒绝回答范围外问题。

微调的成本和门槛比 RAG 高很多。你需要准备高质量标注数据，需要训练资源，还需要评估微调后模型是否出现“灾难性遗忘”——也就是学到了新知识，却忘了原来的能力。

私有化部署则是在算力层面解决问题。金融、医疗、政务等行业要求数据不出域，只能把模型部署在自有服务器上。私有化部署要重点关注显存占用、推理速度、并发能力和运维成本。模型量化（如 4bit、8bit）是降低显存门槛的常用手段。

3. LLM 框架选型：不必重复造轮子

3.1 主流 LLM 框架盘点

LLM 应用开发涉及很多重复工作：调用 API、管理对话历史、拼接 Prompt、调用工具、连接向量数据库等。框架的意义在于把这些工作抽象成通用组件，让开发者专注业务逻辑。

目前生态中常见的几类框架：

• 编排框架：LangChain、LlamaIndex、Haystack。
• 企业级框架：Spring AI（面向 Java 生态）、Semantic Kernel（微软出品，支持 C#/Python/Java）。
• 低代码平台：Dify、FastGPT、Coze，适合快速搭建 Demo 和内部工具。
• 本地模型管理：Ollama、vLLM、Text Generation Inference，负责模型加载和推理服务。

以 LangChain 为代表的编排框架生态最丰富，但接口变动也比较频繁。如果你在社区看到某段代码运行报错，优先检查是不是 LangChain 版本升级导致 API 变化。LlamaIndex 更偏向知识库检索场景，对 RAG 的支持很完善。Spring AI 的好处是能让 Java 后端团队用熟悉的语法接入 LLM，不需要引入 Python 服务。

3.2 框架选型维度

选型时建议从几个角度评估：

1. 团队语言栈：如果团队是 Java 后端，优先看 Spring AI；如果是 Python，选择范围更大。
2. 场景复杂度：只是做简单 Prompt 调用，可以不引入框架，直接写 HTTP 请求。
3. 社区活跃度：社区活跃意味着踩坑资料多、更新快，但也意味着 API 不稳定。
4. 可调试性：框架封装越深，越难排查问题。简单场景优先用轻量方案。
5. 运维成本：低代码平台开发快，但部署自由度低，不适合深度定制。

3.3 框架对比与选型建议

选型没有标准答案。我的建议是：个人学习优先 Ollama 加轻量 Python 脚本，理解底层原理后再考虑框架；团队项目根据语言栈和场景复杂度选择；如果只是内部工具，低代码平台能省很多事。

4. 实战：搭建一个 LLM 问答应用

4.1 环境准备与版本说明

以下示例基于 Python 3.10 及以上版本，依赖包尽量使用当前主流的稳定版本。由于 LLM 相关库迭代很快，如果你在实际运行中遇到 API 变更，可以查阅对应版本的官方文档。

建议先创建虚拟环境：

mkdir llm-demo cd llm-demo python3 -m venv .venv source .venv/bin/activate pip install openai chromadb

这里安装了 OpenAI 官方 Python SDK 和 Chroma 向量数据库。OpenAI SDK 不仅支持 OpenAI 官方接口，也支持很多兼容 OpenAI 协议的本地推理服务，后续会看到具体用法。

还需要准备环境变量：

export OPENAI_API_KEY=你的API密钥

不要把你的密钥硬编码在代码里，更不要提交到 Git 仓库。日常开发建议使用环境变量或本地.env文件。

4.2 调用大模型 API 的最小示例

先写一个最简单的对话调用，文件路径为chat_basic.py：

import os from openai import OpenAI # 从环境变量读取密钥 client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1"), ) resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一名耐心、专业的技术助手。"}, {"role": "user", "content": "请用三句话解释什么是 RAG。"}, ], temperature=0.3, ) print(resp.choices[0].message.content)

运行：

python chat_basic.py

这个示例的关键点：

• base_url默认指向 OpenAI 官方，但如果你使用代理网关、Azure OpenAI 或本地 Ollama，只需要修改base_url。
• temperature控制随机性，值越低回答越稳定。生产环境里的客服类场景通常用 0.2 左右。
• messages是对话列表，system消息用于设定角色和行为边界，user是用户输入。

4.3 给应用加上 RAG 检索

接下来我们做一个简洁但完整的 RAG 示例。它包含：准备知识库 -> 向量化 -> 存入 Chroma -> 检索 -> 生成答案。

文件路径为rag_demo.py：

import os from openai import OpenAI import chromadb client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1"), ) # 1. 准备知识库 documents = [ "大型语言模型（LLM）是基于海量文本训练的深度学习模型，能够完成文本生成、翻译、摘要等任务。", "RAG 是检索增强生成（Retrieval-Augmented Generation）的缩写，它先在外部知识库中检索相关资料，再把资料交给模型生成答案。", "Agent 是一种能够自主规划、调用工具并迭代执行任务的智能体程序，常见技术包括 Function Calling 和 ReAct。", ] # 2. 向量化 def embed(texts): resp = client.embeddings.create( model="text-embedding-3-small", input=texts, ) return [item.embedding for item in resp.data] embeddings = embed(documents) # 3. 存入向量库 chroma_client = chromadb.Client() collection = chroma_client.create_collection(name="demo_kb") collection.add( ids=[str(i) for i in range(len(documents))], documents=documents, embeddings=embeddings, ) # 4. 检索与生成 def ask(question: str): query_vec = embed([question])[0] results = collection.query( query_embeddings=[query_vec], n_results=1, ) context = results["documents"][0][0] resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "请基于提供的上下文回答用户问题，如果上下文不足以回答，请直接说明。"}, {"role": "user", "content": f"上下文：{context}\n\n问题：{question}"}, ], ) return resp.choices[0].message.content if __name__ == "__main__": print(ask("什么是 RAG？"))

运行：

python rag_demo.py

这段代码展示了 RAG 的完整主链路。实际项目中，你还需要考虑文本切块、多路召回、重排序、引用来源等细节，但核心思想就是这个流程。

4.4 接入本地模型示例

很多企业要求数据不出域，开发阶段也经常需要本地验证。Ollama 是目前最简单的本地模型管理工具，安装后拉取模型即可启动 OpenAI 兼容接口。

安装并启动：

ollama pull qwen2.5 ollama serve

然后在另一个终端里运行：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # Ollama 本地服务不需要真实密钥 ) resp = client.chat.completions.create( model="qwen2.5", messages=[ {"role": "user", "content": "什么是 RAG？"} ], ) print(resp.choices[0].message.content)

把这段代码保存为ollama_chat.py，运行：

python ollama_chat.py

注意，model名称必须和你ollama pull拉取的模型名称一致。如果拉取的是其他模型，要对应修改。

这个方案特别适合学习阶段：不需要付费 API，可以在本地反复调试 Prompt 和检索流程。但本地模型的推理速度和效果与 OpenAI 等商业模型存在差距，正式选型时要根据业务要求权衡。

4.5 运行与验证

三个示例分别覆盖了 API 调用、RAG 链路、本地模型调用。建议按下面的顺序验证：

1. 先运行chat_basic.py，确认 API 密钥和网络链路正常。
2. 再运行rag_demo.py，观察检索到的上下文和模型最终答案是否一致。
3. 最后运行本地模型示例，体验无外网接口的部署方式。

如果rag_demo.py出现乱码或意外结果，优先检查知识库文本是否被正确切块，以及temperature是否过高。RAG 的效果上限取决于检索质量，模型只是最后的“表达能力”。

5. ComfyUI 与 LLM 是否必须在同一台电脑上

5.1 为什么会有这个问题

ComfyUI 是一个面向 Stable Diffusion 等图像生成模型的可视化节点工具，用户可以像搭积木一样连接节点，控制图像模型的输入输出。

在 AI 绘画工作流中，经常需要 LLM 来辅助生成 Prompt：比如根据用户一句自然语言描述，让 LLM 扩展成适合图像模型的详细提示词，再传给 ComfyUI 的采样器。

于是很多人纠结：ComfyUI 和 LLM 要不要装在同一台电脑上？

答案是：不必须。两者可以同机运行，也可以跨机器通信，关键看你的资源情况和业务约束。

5.2 两种部署架构对比

同机部署：

• ComfyUI 本地启动，Ollama 或 vLLM 也启动在本机。
• 优点是部署简单，数据不出机器，网络延迟低。
• 缺点是显存和内存争抢严重。图像生成本身很吃显存，再同时加载一个 7B 或 14B 模型，很容易爆显存。

分离部署：

• ComfyUI 装在有图像显卡的机器 A 上，LLM 服务部署在机器 B 上，或者直接调用云端 API。
• 两者通过 HTTP 协议通信，ComfyUI 只需要知道 LLM 服务的地址和端口。
• 优点是资源隔离，互不影响；缺点是增加了网络依赖，需要保证连通性和接口鉴权。

如果你只是偶尔用 LLM 生成图像 Prompt，直接调用云端 API 成本最低；如果数据敏感或需要离线，则可以单独部署 LLM 到一台较高配置的机器上，和 ComfyUI 分开放置。

5.3 推荐方案与示例

假设你有一台 LLM 服务器，IP 为192.168.1.100，在上面启动 Ollama。然后在一台装有 ComfyUI 的机器上，通过 Python 调用它：

import requests response = requests.post( "http://192.168.1.100:11434/v1/chat/completions", json={ "model": "qwen2.5", "messages": [ {"role": "system", "content": "你是提示词专家，把用户中文描述改写为英文图像提示词。"}, {"role": "user", "content": "一只橘猫坐在窗台上，午后阳光，油画风格"} ] } ) prompt = response.json()["choices"][0]["message"]["content"] print(prompt)

拿到prompt之后，可以作为 ComfyUI 正向提示词节点的输入。ComfyUI 本身不关心 LLM 在哪台机器，它只关心最终得到的文本内容。

部署建议：

• 局域网内部署要配置防火墙规则，仅开放必要的端口。
• 如果服务暴露到公网，必须加上 API Key 鉴权，不要裸奔。
• 同机部署时优先选择量化模型，比如 4bit 或 8bit，降低显存占用。
• 先用小模型验证流程，确认效果后再切换到更大模型。

6. 常见问题与排查思路

6.1 模型生成内容与事实不符

出现幻觉时，不要只想着换更大模型，先检查知识管线：知识库是否覆盖了问题？切块是否合理？检索结果是否和问题相关？这些环节对答案质量的影响往往比模型本身更大。

6.2 响应速度慢、请求超时

流式输出是提升体验的有效手段。用stream=True可以让首个 token 更快返回，用户感觉更流畅。

6.3 上下文长度不够用

不要把所有历史消息都塞进 Prompt。生产系统通常会对会话历史做滑动窗口，或者用短期记忆模块管理对话状态。

6.4 Token 成本失控

成本控制要提前设计，不要等月底账单出来再补救。可以记录每次调用的 token 数量和模型价格，在监控面板上实时可视化。

6.5 依赖与版本冲突

LLM 框架迭代速度极快，建议在项目里使用虚拟环境并固定依赖版本。从网上下载的示例代码不能保证兼容你的版本，拿到代码第一步是检查环境和版本。

7. 最佳实践与工程建议

7.1 Prompt 管理与离线评测

Prompt 是 LLM 应用的灵魂，但它需要被当作代码来管理。建议做好三件事：

• 把所有 Prompt 提取到配置中心或代码仓库，不要散落在业务代码里。
• 每次变更 Prompt 都记录版本，并配套变更说明。
• 建立一套离线评测集，包含常见问题、边界问题和已知错误案例。修改 Prompt 后跑一遍评测集，对比通过率，而不是靠感觉判断效果好坏。

评测集不用很大，几十条精心挑选的问题就够了。关键是覆盖各种异常场景，比如超长输入、空输入、诱导性问题。

7.2 安全边界与权限控制

LLM 应用存在两类主要安全风险：

一是提示注入。恶意用户可能通过输入让模型执行非预期指令。缓解手段包括：对输入做长度和内容校验，不把未处理的外部数据直接放入 system prompt，对模型输出做二次过滤。

二是数据泄露。业务数据一旦发送给外部模型 API，就很难控制它被如何使用。对敏感业务，建议使用私有化模型，或者对数据先做脱敏处理。API Key 和内部服务地址绝不能提交到前端代码或公共仓库。

7.3 可观测性与日志

生产环境里，LLM 调用比普通接口更难排查，因为你很难从最终输出判断内部发生了什么。建议记录以下信息：

• 请求 ID 和用户 ID。
• 完整的 messages 请求体。
• 模型返回的 completion 内容。
• Token 数量、延迟时间、错误信息。
• 是否命中缓存、检索的内容片段。

这些日志既能用于排错，也能用于后续的数据分析。不过要格外注意：日志里不要记录比业务需求更敏感的原始信息，日志本身也需要权限保护。

7.4 成本与性能优化策略

成本优化的核心思路是“分级模型 + 缓存 + 提前拦截”。

• 简单问题用便宜的小模型，复杂问题才路由到大模型。
• 相同问题用语义缓存命中，直接返回缓存结果。
• 对低价值请求设置预算上限，避免账户额度被耗尽。
• 批量任务错峰执行，避开高峰时段的 API 限流。

性能优化则要关注两个数字：首 token 延迟和端到端延迟。流式输出对于体验改善非常明显，同时要考虑服务端并发能力，比如用 vLLM 替代简单的 Transformers 推理。

7.5 生产环境发布流程

LLM 应用不能像普通代码一样直接上线。建议在发布前完成：

1. 灰度发布：先让少量流量进入新 Prompt 或新模型。
2. 效果对比：对比新旧版本的满意度指标和错误率。
3. 一键回滚：把模型配置和 Prompt 配置存入配置中心，出现问题时秒级回滚到旧版本。
4. 监控告警：关注错误率、超时率、成本增长曲线。

这听起来复杂，但只要是线上产品，这些机制迟早要补上。

8. 总结与学习路线

8.1 本文要点回顾

回到开头的问题：Startups 在 LLM 领域追逐的“下一个大事件”，不是模型参数本身，而是如何用模型价值解决具体场景问题。围绕这个目标，RAG、Agent、微调、私有化部署是四条最核心的技术路径。

• RAG 解决知识来源问题，让模型基于事实回答。
• Agent 解决任务执行问题，让模型从“说话”变成“做事”。
• 微调解决行为对齐问题，让模型输出符合业务规范。
• 私有化部署解决数据安全问题，让模型进入高门槛行业。

同时，框架是提效工具，不是银弹。先理解底层流程，再决定是否引入框架，可以避免陷入框架版本迁移的泥潭。

8.2 下一步学习建议

如果你是第一次接触 LLM 应用开发，建议按以下顺序推进：

1. 先把 Prompt 工程玩熟，理解 temperature、max tokens、system/user/assistant 三种角色的作用。
2. 用本文的 RAG 示例改造一个自己的知识库，比如把团队的 FAQ 文档做成问答机器人。
3. 学习 Function Calling，做一个能查天气、查数据库的简单 Agent。
4. 用 Ollama 跑一个本地模型，体验离线部署和资源瓶颈。
5. 再深入 Serverless 推理、评估体系和 LLMOps 工具链。

LLM 的技术栈还在快速变化，今天好用的框架可能过几个月就被替代，但底层要解决的问题——检索、规划、记忆、评估、成本——不会变。把这几个基本功打扎实，比盲目追新框架更值得投入。

如果本文对你有帮助，可以收藏备用，也欢迎在实际项目中多动手验证。遇到报错时，先看版本，再看文档，最后检查数据链路，大部分问题都能通过这三步定位。