中小企业要进行大模型的应用的开发，是不是简单的几句话，让大家多用大模型就行了，或者统一购买公网的TOKEN就可以了？如果没有足够的开发人员，如何让全员搭建 Agent，使用知识库？如果碰到敏感信息，想在公司搭建私有的大模型，该如何做？

        实际上，市面上的一体机搭载的AI平台，大体上可以完成类似的功能，可以让公司没有资深软件开发人员的前提下，把AI平台搭建起来，在业务应用中，合理的使用AI。

        看了一下这些AI平台，发现都是同一种套路，有一定前后端开发经验的人都可以快速搭建。我尝试来拆解一下，看看最简的实现方案。

        首先，我们来看一下这样一个最简平台的架构说明。

一：架构

先看一下大语言模型的技术分层：

本文，关注的是应用开发层。我们需要考虑如何为中小企业搭建一个MVP的产品，用于不断进行AI应用层的探索。对于模型，只考虑选用，不考虑自行微调，训练。

这其实也很有作用，可以不断跟进大模型的能力，不在AI浪潮中被淘汰。

我们可以看看 DeepSeek提供的能力图谱：

可以看到，AI的能力是很广泛的，可以它在某些场景的能力有所欠缺，但加上一些程序的辅助，它实际也能干很多事情了，但如果不尝试，只是一味否定，你可能就落后了，会失去AI带来的机会，甚至被会用AI的人淘汰。

好了，那我们来看看简化的产品架构：

整个产品架构很简单：

        一堆智能体应用，基于模型的管理 ，平台管理。对于模型具体的引擎和硬件可直接使用公网，当然，有条件，有必要可以本地搭建（属于可选项）。

        应用层，呈现方式是Web（手机也支持），或者直接提供能力API供调用。

我们再来看看对应的技术层的架构：

接入层：接入层实际上指的就是Web页面，一般分为用户使用的控制台和管理人员使用的管理后台，通过权限隔离相应的页面即可。

核心应用：除了标准的对话应用，知识库，智能体搭建，API，还有就是企业自行定制的应用。

AI服务：为什么是AI平台，主要体现在这里，因为核心的服务是大模型服务，当然还会有用做匹配的嵌入服务，重排模型，代码补全服务，文件解析的服务（文件解析包括OCR，语音转文字，文字转语音之类），注意嵌入服务，重排模型主要用于RAG知识库，属于当前必须。

模型的引擎：可以本地部署 ，也可以对齐公网服务。

基础设施：这和引擎层强相关。

运维监控：这看起来很简单，但其实是一个平台必须的，但和其它平台其实是一致的，只是需要将相应的探针植入AI引擎，方便运行期的运维（排查纠错，安全审计等……）

那我们更进一步，看看具体是如何实现这个平台的？和这个平台相关的软件技术会有哪些？

这里，先简单介绍一下上图中 L7 层的技术点，具体的实现方案，后面再细讲。

L1: 大模型部署和使用

如果有实力，可以自已部署大模型，甚至自已实现一个模型的推理引擎（适配自已的硬件），当然，大多数情况下，都是购买三方的公网算力，那这里必须要知道大模型是如何调用的，标准的调用方式有哪些？因为大模型调用时，实际上是有很多参数的，必须要弄明白，才能用好。

L2: 大模型接入管理

这里指的就是 大模型调用的网关处理，因为我们都知道大模型的算力实际上就是成本。

所以，模型的使用，首先要控制，要做相应的token管理，受允许才可使用。

为了更好的使用，需要对流量进行治理，限流，路由之类的管制。

如果模型有多个，可能还需要按策略进行分发，找到合适的模型。

模型的访问，使用需要日志记录，一方面用于审计，另一方面也是对性能进行监控。

L3: 数据与知识

我们都知道大模型有幻觉，主要原因还是大模型不是万能的，就拿你所在企业的一些内部知识，大模型是不可能知道的。所以，我们必须要在这里搭一个知识库层，把公司内部的数据整理好，可供检索，提升后续AI服务的数据质量。

L4: AI中间件

对于大模型，除了它的大模型的回答能力，还包括一些周边能力中间件，来辅助大模型来完成最终的任务。

比如：

        如何写好提示词工程？有哪些提示词我们可参考？

        我想实现复杂的 AI 流程，如何编程实现？

        公司的业务能力，外部工具，AI如何调用，MCP Server如何写，A2A如何使用？

        对于知识库，实际也依赖于AI中间件的能力。

        对于AI应用开发，有哪些范式？

L5: 应用编排 

        AI应用的编排，算不算 AI 中间件的一种能力，其实也算，但是，编排太重要了，我们还是单独拿出来讲，因为为了编排我们值得研究，比如：如何不写代码完成编排？写代码如何编排？标准的编排方式有多少种模板？

L6: 应用平台

        应用会以什么方式呈现呢？首先，应该是一个统一的管理平台，我们也可以称之为Web门户，在这个门户里我们看到应用的入口，包括创建应用的入口。当然，有一些应用并不在这里，比如：程序员习惯在IDE平台里安装插件，然后在编程过程中，直接调用AI能力。还有一些普通用户，可能直接就使用大模型官网提供的聊天会话页面，或者手机端的APP来完成应用。

        还有一种重要的做法，就是和企业的协同平台做集成，比如：钉钉，企业微信，飞书等，这里要考虑如何调用外部APi完成集成。

        而对于我们的Agent应用，按编排的方式不同，其实也有一些固定的呈现形式。

        这里要注意一下，对于AI应用服务，我们应该采用单体还是微服务，这要根据实际情况来定，这可能和AI本身无关，这主要由用户使用频度来决定。

L7: 高级应用

        除了上面的应用，一些高级的企业，可能会微调自已的模型，从而需要标注和测试模型能力。也可能需要将自已的模型用其它大模型进行蒸馏。这些应用相对高级，我这里只是提出来，我自已也不一定能讲清楚。

支撑：AI 平台治理

        对于每一层，我们可能都涉及到权限，安全，审计，SLA，成本的控制，我们称之为对平台的治理，这是必须的，但可以依据实际情况有选择的进行建设。它不能没有，但也不应该过渡投入，可以迭代。       

二：大模型部署&配置

        首先，我们先排除自已做推理引擎的情况，这个我后面会单独聊，如何自定义硬件，然后如何去适配相应的推理引擎，这应该是一个非常复杂的问题，和硬件强相关，这里就不展开。

2.0: 模型部署

        我们只讲模型的本地部署，对于有一些有实力的公司，可能会自行购买算力，那可能就会碰到部署的问题，当然，有可能服务商会帮忙解决这个问题，或者会提供一个很好的管理平台，解决若干部署的问题。假如没有的话，那很简单就使用 vLLM就好了，基本上所有模型都可以搞定，对于N卡和华为的T卡都支持。其它部署方式都不是很合适，不建议（如果纯用N卡或华为和T卡，也可以使用官方提供的部署工具）。

        如果我们不需要本地部署，直接采购公网的token，那就简单了，我们直接关注使用部分即可。

         我们这里重点还是讲模型的使用。

         可能大多数人平时都是使用 LLM 自带的chat界面来完成互动，但对于AI开发，必须要了解的是API的用法。

2.1 API 调用方式

        1: HTTP  Restful  这是最常见的方式。

# 基本请求结构
curl -X POST "https://api.openai.com/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "gpt-4",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

        2: 标准的SDK，包括：OpenAI Python、Anthropic、Cohere、HuggingFace等，一般都是python的库函数方式使用。

# OpenAI Python SDK示例
from openai import OpenAI
client = OpenAI(api_key="YOUR_API_KEY")

response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "Hello!"}]
)

        3: WebSocket的方式，这是一种流式输出的方式。对于实时响应的场景有用。

// WebSocket 流式响应示例
const ws = new WebSocket('wss://api.openai.com/v1/chat/completions');
ws.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log(data.choices[0].delta.content);
};

        4: LangChain/LLamaIndex框架接入，属于高级应用。

        适用场景：复杂AI应用开发，需要工作流编排

from langchain.llms import OpenAI
from langchain.chains import LLMChain

llm = OpenAI(api_key="YOUR_KEY", temperature=0.7)
chain = LLMChain(llm=llm, prompt=prompt)
result = chain.run("Hello, how are you?")

2.2 验权方式

        最常见的验权有以下几种：

        1:  API Key​

        OpenAI, Anthropic, 大部分商业API

    使用方式：Authorization: Bearer sk-xxx

        2: OAuth 2.0​

        Google PaLM, 企业级服务

        使用方式：令牌刷新机制

        3: AK/SK​

        阿里云、腾讯云等云服务商

        使用方式：签名认证

        4: JWT Token​

        自建模型服务，如果自已实现的模型推理，可以通过JWT 来快速达成验证。

        使用方式：有时效性的令牌

2.3: 基本参数

// 通用请求格式
{
  "model": "模型名称",
  "messages": [
    {"role": "system", "content": "系统提示"},
    {"role": "user", "content": "用户输入"}
  ],
  "temperature": 0.7,
  "max_tokens": 1000,
  "stream": false
}

// 通用响应格式
{
  "id": "请求ID",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "模型回复内容"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 50,
    "total_tokens": 60
  }
}

        注意：里 system role，user role的区别。

                temperature：代表随机性参数。

2.4: 高级参数

# 完整的参数配置示例
params = {
    # 必需参数
    "model": "gpt-4",                    # 模型选择
    "messages": messages,                # 对话历史
    
    # 生成控制参数
    "temperature": 0.7,                  # 随机性：0-2，值越大越随机
    "top_p": 0.9,                        # 核采样：0-1，控制输出多样性
    "max_tokens": 1000,                  # 最大生成长度
    
    # 高级控制参数
    "frequency_penalty": 0.0,           # 频率惩罚：-2.0到2.0，减少重复
    "presence_penalty": 0.0,            # 存在惩罚：-2.0到2.0，避免重复话题
    "stop": ["\n", "。"],               # 停止序列
    
    # 流式传输
    "stream": True,                     # 是否流式输出
    
    # 多候选输出
    "n": 1,                             # 生成多个候选结果
    "best_of": 3                        # 从多个中选择最佳
}

参数	取值范围	作用	使用场景
temperature	0.0-2.0	控制输出的随机性	创意写作用0.8-1.2，代码生成用0.2-0.5
top_p	0.0-1.0	核采样，控制词汇选择范围	与temperature配合使用，通常设0.7-0.9
max_tokens	1-模型上限	单次生成的最大token数	根据需求设置，避免过长响应
​frequency_penalty	-2.0-2.0	降低重复词汇出现概率	长文本生成时设为0.1-0.5
presence_penalty	-2.0-2.0	避免重复讨论相同主题	多轮对话中设为0.1-0.3
stop	字符串数组	遇到特定序列时停止生成	控制输出格式，如["\n\n", "###"]

不同厂商，实际上还有一些特殊的参数，这里就不多说了。

 不同场景的参数，如下示例：

# 创意写作配置
creative_writing_params = {
    "temperature": 0.9,
    "top_p": 0.9,
    "frequency_penalty": 0.3,
    "presence_penalty": 0.2,
    "max_tokens": 800
}

# 代码生成配置
code_generation_params = {
    "temperature": 0.2,
    "top_p": 0.8,
    "frequency_penalty": 0.1,
    "presence_penalty": 0.1,
    "max_tokens": 500,
    "stop": ["\n\n", "```"]  # 代码块结束标记
}

# 问答系统配置
qa_system_params = {
    "temperature": 0.1,
    "top_p": 0.7,
    "frequency_penalty": 0.0,
    "presence_penalty": 0.0,
    "max_tokens": 300
}

三：大模型接入

3.1: token权限        

        大模型接入，首先要考虑的是权限的管理，也就是，最好能有一个验权，提供一个token，这样就可以限制用户的使用。

        如果模型是自已本地部署的，那可能就必须针对 API 做一下处理，提供一下token的申请方案。然后 类似上面提到  JWT Token 的方式。在封装Resftful 的接口时，在Web 服务的session管理时，针对申请的token进行解析和验权，获得用户信息的同时完成验证的日志记录。

3.2:  模型路由

       如果对于模型有路由需求，可以通过NG来简单配置，这里不再多说。

3.3:  其它

        基于token，可能还需要有一些限流策略，以及一些性能，日志监控的处理，以保证接入用户可合理，安全使用大模型的算力。

四：数据与知识

        上面提到，数据与知识，实际上就是搭建本地知识库。

        本地知识库的搭建，在技术上并不难，也就是需要一个embeding模型，一个reRank模型，以及一个存储知识的向量数据库。

4.1: RAG原理

        RAG：Retrieval-Augmented Generation 检索增强生成

        对于检索，一般的方法是全匹配，模糊匹配，全文匹配。那对于全文检索，RAG有什么不同呢？

维度	传统全文检索	现代 RAG 系统	本质区别
检索机制	关键词匹配（BM25算法）	语义向量相似度	字面匹配 vs 语义理解
返回结果	文档/网页列表	直接答案+引用	原材料 vs 加工成品
理解深度	词汇层面	概念和意图层面	表面 vs 深层理解
知识范围	索引内固定内容	可动态扩展的知识库	封闭 vs 开放
交互方式	多轮筛选	单轮智能问答	人适应机器 vs 机器适应人

        从上表可以看得出，语义相似的智能度高了太多，而语义相似是基于嵌入式模型的功劳，通过多维度的训练，将众多单词的语义相关性进行了。

        标准和处理过程如下：

        1: 文本合理进行切割，经过embedding模型编码，存入向量数据库。为了方便查询，可以人为添加一个关键字索引。

        2: 用户提问时，问题可以先通过LLM做一下判断，看是否要使用本地数据库。

        3: 到本地数据库检索时，通过语义相似度的运算，取出topN的结果，对于topN的选择，需要用rerank模型对返回值进行合理排序，保证可取到最好的返回值。

        4: 返回值给到 LLM，LLM将它作为备选答案的上下文，通过组织后，给出答案。

4.2: 关键技术

        这里最关键的技术选项：

        1: embedding 模型：

        最佳选择  bge-m3 开源模型。

        2: Rerank模型：

        可选择 bge-reranker-v2-m3

        3: Vector DB :

        Qdrant 向量数据库。或者直接使用ES这种全文索引数据库也可以，或者是两者的融合方案。

        4: 程序如何编排

        可以使用 LlamaIndex 框架，快速完成相应的过程。        

4.3: 调优的重点

        使用本地知识库，并不意味着就一定很精准。是否精准，主要取决于：

        1: 最重要的自然是你提供的数据的准确性。

        如果你提供的数据是错的，或者前后有不一致的，那不可能得到正确的答复。

        2: 数据合理的切分，或者说是添加合理的元数据对应。

        你把大模型也当成人一样看待，如果你切分的数据是支离破碎的，或者没有结构，人看不懂，大模型一样是看不懂的。所以，你要根据数据自身的情况，合理的切分，不要把关键信息给切碎了。

        切分：一般要按语义切，按结构切。如果没有好的办法，才按固定长度来切。

        重叠：为了保证语义不丢失，切分块要有一定的重叠。

        元信息：为切分的数据块加上元数据，比如：章节数，页码，标签等信息，如果信息间有父子结构关系，最好能描述清楚。

        3: 当然，选用的 embedding模型，rerank模型也影响准确度。

        4: 提示词的合理性，需要用提示词做合理的约束，或者提前做一下意图识别。比如：用户问的问题是否适合在本地知识库回答，可以用 LLM 的提示词做提前判断。对于返回信息，可以在最后返回前，通过LLM做一些约束，比如：如果在本地知识库无法获得符合XX条件的答案，可以 XXXX。

        

五：AI中间件

        我们在这里，集中介绍 AI 的一些重要能力。

        首先，既然是LLM应用，第一还是要把 大模型用好，那最重要的自然就是提示词工程。

5.1: 提示词工程

        对于提示词工程，不是要讲的重点，这里只是强调，提示词仍然是非常重要的，大模型和人一样有逻辑，如果提问不合逻辑或者条件不明确，大模型不可能给出合理的答案。并且，适当的做一些约束或修饰可能会有更好的效果。一些是沟通的技巧，更多还要靠提问者自身的领域知识能力。

        那好的提示词是怎样的呢？

        网上有一些好的资源可以参考，

        比如：

                 提示词资源库

                 smith.langchain 搜索提示词        

        当然，能有良好沟通技能，有好的领域知识背景的人更能从LLM获得更大的帮助，因为他能给出更好的提示词。

5.2: AI 代码开发框架

        现在最常用的AI开发语言是 Python，一般不会用其它开发语言。

        而最流行的开发框架是：LangChain / LangGraph，LlamaIndex。

        正常的应用，使用LangChain，如果流程复杂，有很多分支的可以采用LangGraph.

        如果你的应用偏数据处理，也可以使用LlamaIndex。

5.3: AI 工具调用

        大模型在智能应用中并非全部，除了RAG，还有就是外部的工具，比如：客户已有的系统，公网的指定应用，这些工具往往会配合完成整体的应用。比如：一个智能订票的系统，最终一定需要调用订票系统完成订票。那这些需要调用的我们称之为工具，那工具要如何调用呢？

        我们一般提供了三种方式：

        一种是FunctionCall，这是将外部工具支持按FunctionCall的方式进行封装，然后交给LLM，让它在合适的时候直接调用。

        一种是MCP，就是将需要调用的功能封装成一种可插拨的服务，方便大家统一进行调用。这是一种升级的functionCall，它可以将服务标准化，统一鉴权，统一管理，提供发现服务，可插拨（动态替换），还可以形成一种生态，大家共同提供共享的服务。

        一种是A2A，当一个任务太复杂，需要多角色分工：
        比如：研究 Agent：搜集资料、验证来源
                   编写 Agent：生成报告/文档
                   代码 Agent：写代码并跑测试
                   审核 Agent：检查事实与风险
        我调用的就是另外一个或多个Agent，或者自身也可以被调用，那就通过 A2A的方式来互相调用。

        三者的表达是，functionCall是形成一个工具，MCP 是工具复用的方式，A2A是应用间的协同。

        但三者都可以调用外部的工具，完成更强大的功能。

5.4: AI 开发范式

        写AI的应用，和写普通程序是有些不同的，最主要的不同，是思路上的转变。

        从整体的策略上，一般有三种开发范式：

模式	核心目标	所属层次	一句话总结
计划模式	先规划完整步骤，再逐步执行	中层调度框架	先想好任务路线，再执行
ReAct 模式	将「推理（Reason）」与「行动（Act）」交替结合	基础推理框架	思考一句 → 执行动作 → 再思考
Deep Research 模式	组合规划 + 多轮检索 + 长程记忆 + 汇总生成	高级多Agent协作框架	类似“研究助理”式工作流：计划 → 检索 →验证 →总结

5.4.1: 计划模式

        优点：结构清晰、适合长任务；便于把复杂任务拆给不同工具/模块。
        缺点：计划一旦写错，会“按错计划一路走到黑”；对动态信息/不确定性适配弱（除非加入重规划）

适用场景：

• 交付型任务：报告、方案、需求分解、项目计划、文档生成

• 工具链明确：已知需要哪些系统（Git/DB/检索/编译）才能完成

        计划模式很简单 ，完全依赖于计划人的经验，我们就不细讲了。

5.4.2 ：CoT（Chain of Thoughts)

        CoT 中文名称是思维链。最早是来自于人类向大模型提问时，无意中发现，如果加上一句 “Let’s think step by  step”，大模型回答的效果就会有大幅增强。

        因为现在大模型已经有了推理模式，这种用法已经不普遍，我们就不细讲了。

5.4.3: ReAct模式        

        ReAct 一词来自于论文《ReAct: Synergizing Reasoning and Acting in Language Models》

        ReAct 包含了 Reason 与 Act 两个部分。

        可以理解为就是思维链 + 外部工具调用。ReAct 思想会让大模型把大问题拆分成小问题，一步步地解决，每一步都会尝试调用外部工具来解决问题，并且还会根据工具的反馈结果，思考工具调用是否出了问题。如果判断出问题了，大模型会尝试重新调用工具。这样经过一系列的工具调用后，最终完成目标。

        其实思想非常简单，就是在 CoT 推理方案的基础上，加上工具调用，以及工具结果观察，这样做可以极大地减少幻觉的产生。由于该方案思路简单，效果霸道，在 Agent 应用开发中，使用率非常高。

       要为大模型赋予 ReAct 能力，使其变成 Agent，我们需要在向大模型提问时，使用 ReAct Prompt，从而让大模型在思考如何解决提问时，能使用 ReAct 思想。

        我们可以按上面给的提示词工程 的HUB，看一下标准的React的模板。

        推荐一个 LangChain 官方的 ReAct Prompt，链接是 LangSmith (langchain.com)：

        

        

{instructions}

TOOLS:
------

You have access to the following tools:

{tools}

To use a tool, please use the following format:

```
Thought: Do I need to use a tool? Yes
Action: the action to take, should be one of [{tool_names}]
Action Input: the input to the action
Observation: the result of the action
```

When you have a response to say to the Human, or if you do not need to use a tool, you MUST use the format:

```
Thought: Do I need to use a tool? No
Final Answer: [your response here]
```

Begin!

Previous conversation history:
{chat_history}

New input: {input}
{agent_scratchpad}

这段 prompt 开头的 {instructions} 其实是为大模型设置人设。之后告诉大模型，使用 {tools} 中定义的工具。因此在 {tools} 里，应该填入工具的描述。工具如何写，在5.3已经讲过了。

模板接下来要求大模型按照规定的格式思考和回答问题，这就是在教大模型如何推理和规划，大模型在有了推理和规划能力后就变成了 Agent。

因为 Agent 会将问题拆分成多个子问题，之后一个个的解决，因此从 Thought 到 Observation 的过程会执行 N 次，直到大模型认为得到了最终的答案。于是便有了第二个 Thought：大模型认为得到了最终的答案。Final Answer 就表示最终的答案。该模板还支持在 {chat_history} 中填入历史对话，方便大模型理解上下文。最后还有一个 {agent_scratchpad}，这是一个 Agent 剪贴板，用于记录 Agent 的思考过程，可以不填，不影响整个 Agent 执行过程。

• 优点：非常适合“边查边想”的任务；遇到不确定信息就用工具补齐；鲁棒。

• 缺点：工具调用多时成本高；如果没有良好停止条件，会“越查越多”。

适用场景

• 需要外部信息：检索问答、故障排查、数据核对、对比分析

• 需要与环境交互：写代码→跑测试→修→再跑

5.4.4：Reflection && Reflexion

        在《Language Agents with Verbal Reinforcement Learning》论文中，介绍了一种新的推理方案，名叫 Reflexion。该方案，实际上来自于一种名叫 Reflection（反思）的思路，并在此基础上做了加强设计。

        

        从 Actor 开始，还是根据用户提问，生成答案，但这次，Actor 继承了 ReAct 的能力，可以与外界环境交互，并观察答案，然后通过 Trajector 模块将对话记录存储在短期记忆，比如内存中。        

        之后，Evaluator 和 Self-reflection 模块开始介入，Evaluator 对对话结果做评估，检查答案是否正确。Self-reflection 则汇总评估结果，以及对话内容做总结反思，总结出经验教训后，存储到长期记忆中，比如 Redis 等等数据库。

        等到下次再提类似问题时，可以将经验与问题同时输入给 Actor，这样有了经验做加持，Actor 就会少走弯路。

• 优点：提升正确率、完整性、表达质量

• 缺点：多一轮（或多轮）生成，成本上升；收益对“简单任务”不明显

适用场景

• 高质量交付：对外报告、对客户答复、合规/风控文本

• 复杂推理：容易漏条件的题

5.4.5: Deep Research 模式

        多源检索 + 多步分析 + 证据合成” 的 Agent 流水线。
        运行过程：
        1. 明确研究问题与范围（时间窗口、术语、排除项）
        2. 多轮检索：分主题、分来源、分时间
        3. 阅读与摘录：做笔记、提炼要点、记录引用
        4. 交叉验证：对冲突信息做比较与溯源
        5. 结构化产出：综述/报告/决策建议，附引用清单

• 优点：信息覆盖广、证据链完整、适合“需要引用/可追溯”的输出

• 缺点：最耗时耗钱；容易“信息过载”；如果没有强约束，产出会空泛

适用场景

• 市场/竞品/政策/标准调研

• 技术选型报告、供应商评估、尽调材料

• 任何“需要引用/证据”的内容

5.4.6：其它

        可能还有一些其它开发范式，比如：Resoning Without Observation。不再论述了。

六：应用编排

        什么叫应用编排？

        假如我们认为 AI 开发不需要学习编程语言，只需要通过自然语言和一些简单配置就可以达成，那我们认为这就是一种编排的方式来生成应用。那我们会有什么样的编排方式来生成应用呢？

        实际上，最典型的示例，就是直接使用成熟的低代码/零代码开发平台来搭建AI大模型应用，这种平台在开源界最有名的就是Dify了，所以，我以dify的功能为例，来看看，AI应用有哪些编排的方式。

智能体构建平台，如果要快速搭建智能体，但又没有程序开发能力，最好的办法，就是使用类似Difi这种零代码的开发平台了。它的功能并不难，主要是用于创建Agent的工作流，其实，有点像传统的工作流设计软件。它可以将若干的动作，通过逻辑判断串在一起，完成一个完整的工作。

        我们以Dify为例，看看智能体的构建方案：

        dify可以搭建5种应用，大概如下：

6.1: workflow——工作流

        可视化编排多节点任务流（含条件判断、API调用等），有点象协同的工作流，有比较多的条件判断和分支，也可以调用不同的API。        

• 本质：通过可视化“流程图”来编排复杂、确定的自动化业务流程。你可以将AI模型、条件判断、API调用、数据处理等多个节点像搭积木一样连接起来。

• 为什么选择它：当你的业务逻辑固定、多步骤、且需要集成多种能力时。与Agent相比，Workflow的流程是预先定义好的。

        这里注意：最关键的点是，工作流一定是固定的流程，可预计的流程，这并算是标准的Agent。

        典型的场景：

        客户工单处理

        自动化内容生产

        复杂的数据处理

6.2: chatflow ——对话流

• 本质：专门为“复杂多轮对话”而优化的增强型工作流。它集成了Workflow的可视化编排能力，但节点和设计更专注于管理对话状态、上下文和分支。

• 为什么选择它：当你需要构建一个交互复杂、有状态、需要引导用户的对话系统时。它是Chatbot的复杂形态。

        对话流和工作流的区别是，它会管理对话的状态，对于对话人的上下文是会记忆的。当然，不同会话是否记录，要看我们有没有特殊处理。

        典型的场景：

        高级的个性化客服：可能记忆客户的偏好和历史。

        个性化的教育：根据用户不同的选择，进行不同的教学章节。

        那它和普通的chatbot的区别是，它是相对通用的，chatbot是完成具体明确任务的机器人。       

6.3: chatbot —— 聊天机器人

• 本质：最基础、最快速的对话应用。通过配置系统提示词和知识库，快速创建一个能回答特定领域问题的聊天机器人。

• 为什么选择它：当你需要一个“标准问答”或“知识库查询”机器人，且交互逻辑简单直接时。

• 典型场景：

  • 企业知识库客服：回答公司制度、产品FAQ。

  • 技术支持助手：提供故障排除步骤。

  • 个性化陪伴聊天：设定特定角色（如历史人物、学习伙伴）进行对话。

        举例：比如同创提供的FPGA选型助手，就类似于此。

6.4: Agent——智能代理

• 本质：具备“自主思考”和“使用工具”能力的智能体。它能理解复杂目标，自主规划步骤，并调用各种工具（如网络搜索、计算器、代码解释器、自定义API）来完成任务。

• 为什么选择它：当任务需要获取实时信息、进行计算或操作外部系统，且你希望AI自主决策如何完成时。

• 典型场景：

  • 研究助手：查询最新资讯，整理并总结一份行业报告。

  • 数据分析师：根据指令，自动编写并执行代码来分析数据集，然后得出结论。

  • 自动化助手：接收“安排下周会议”的指令，自动查看日历、协调时间、发送邀请邮件。

6.5: TextGenerator 文本创作

• 本质：专注于“文本创作”的AI助手。通过模板和指令，将简短输入转化为长文本、结构化内容或不同风格的文本。

• 为什么选择它：当你的核心需求是“生成内容”，而非多轮交互或复杂决策时。

• 典型场景：

  • 营销文案生成：根据产品描述生成广告语、社交媒体帖子。

  • 代码生成与解释：根据注释生成代码片段，或解释代码功能。

  • 邮件/报告起草：根据几个关键词生成正式邮件或报告大纲。

6.6: 知识库搭建

        知识库非常重要，因为它是上面几种应用的基础，我们在数据与知识层已经提过，这里再从编排应用的层面，再次强调它的用法。

        比如：

        专业的聊天机器人：针对企业某个产品和技术领域的服务，少不了使用内部资料。

        企业内部知识库检索：基于内部知识库的检索平台。

        研报生成：基于公司已有内部资料。

        搭建知识库有三种方式：

        1: 简单设定规则，快速生成知识库。这里只设定切分规则和重叠量，定义元数据。

        2: 基于工作流进行复杂的数据处理，生成合理的知识库。这相当于使用ETL了，按最合理的方式的文档进行拆分。实际上这是知识库使用的精髓。如果没有合理的拆分，知识库在企业场景其实起不到很大的作用。原理上，这里可以任意复杂的处理数据文件，达到最好的效果。

        3: 也可以集成其它的知识库，这里通过API 同步外部知识库。

        对于知识库，最重要的编排，实际上就是数据切分的处理过程。Dify可以支持相对复杂的切分。

6.7: 编排使用的组件

        要完成上面的流程，实际上需要一些固定的组件，形成节点，借助逻辑判断和上下文的变量，完成编排。

        用到的基础组件/节点有：

        用户输入——收集用户输入以启动工作流和对话流应用程序。

        触发器——基于定时，webhook，外部事件触发。

        大语言模型——调用语言模型进行文本生成和分析。

        知识检索——在指定知识库中检索与查询相关的信息，并将检索结果作为上下文内容传递给下游节点（如 LLM）使用。

        答案——定义了在对话流应用中向用户传递的内容。使用它来格式化响应、将文本与变量结合，以及流式传输包括文本、图像和文件在内的多模态内容。主要是对最终输出进行格式化，形成合理的答案。

        输出——结束节点。它现在在工作流中是可选的，仅用于显式地向最终用户输出数据。

        智能代理——让你的大型语言模型自主控制工具，使其能够迭代决定使用哪些工具以及何时使用它们。智能代理不是预先规划每一步，而是动态地推理问题，根据需要调用工具来完成复杂任务。

        工具——通过预构建的集成将你的工作流连接到外部服务和API。与HTTP请求节点不同，工具提供结构化接口、内置错误处理以及为流行服务简化的配置。

        问题分类器——智能地对用户输入进行分类，以将对话路由到不同的工作流路径。无需构建复杂的条件逻辑，你只需定义类别，让大型语言模型基于语义理解来确定最合适的分类。

        if-else——通过根据你定义的条件将执行路由到不同路径，为你的工作流添加决策逻辑。它评估变量并确定你的工作流应该遵循哪个分支。

        迭代——通过对每个元素按顺序或并行运行相同的工作流步骤来处理数组。用于批处理任务，这些任务若作为单一操作会遇到限制或效率低下的问题。

        循环——执行重复性工作流，每个循环都基于前一个循环的结果进行构建。与迭代处理数组元素独立不同，循环创建的是随着每次重复而演进的渐进式工作流。

        代码——执行自定义 Python 或 JavaScript 来处理工作流中复杂的数据转换、计算和逻辑。当预设节点无法满足你的特定处理需求时可以使用它。

        模板——使用 Jinja2 模板语法将来自多个来源的数据转换和格式化为结构化文本。使用它来组合变量、格式化输出，并为下游节点或最终用户准备数据。

        变量聚合器——将来自不同执行路径的变量组合成单一的统一输出。当多个分支产生相似输出时，该节点通过创建一个一致的变量引用，消除了对重复下游处理的需求。

        文档提取器——将上传的文件转换为大型语言模型可以处理的文本。由于语言模型无法直接读取PDF或DOCX等文档格式，此节点作为文件上传和AI分析之间的重要桥梁。

        变量赋值器——通过写入会话变量来管理对话流应用中的持久化数据。与每次执行都会重置的常规工作流变量不同，会话变量在整个聊天会话期间持续存在。        

        参数提取器——使用大型语言模型智能将非结构化文本转换为结构化数据。它弥合了自然语言输入与工具、API和其他工作流节点所需的结构化参数之间的差距。

        HTTP请求——将你的工作流连接到外部 API 和 Web 服务。使用它来获取数据、发送 webhooks、上传文件，或与任何接受 HTTP 请求的服务集成。

        列表操作符——通过筛选、排序和选择特定元素来处理数组。当你需要处理混合文件上传、大型数据集或任何需要在下游处理之前进行分离或组织的数组数据时，请使用它。

        当然，如果我们不使用Dify，而是自行开发，也可以使用LangChain或者LangGraph达成类似的功能和效果。

七：应用平台

 7.1: 门户&管理平台

 对于管理平台，无非就是通用的功能，比如：用户管理 ，系统管理 ，权限管理，应用中心等…… 这些功能实际上都是标准的，实在是用不着从头搭建。

        一般会有两种流行的方案：

方案一：RouYi （若依）框架

        非常流行的国产开源框架。一个集成了现代企业级开发所需各种功能的快速开发平台。

        提供了一个开箱即用的企业级基础平台，其内置的功能模块可以直接使用，也能作为二次开发的坚实基础。

• 用户、角色与权限管理：实现了精细化的权限控制，包括菜单权限、操作权限（可控制到前端的每一个按钮），以及数据权限（例如，设置不同部门的用户只能查看本部门的数据）。

• 系统管理：涵盖部门管理、岗位管理、字典管理、参数配置等企业后台系统的通用功能。

• 监控与审计：提供操作日志、登录日志、在线用户监控等功能，保障系统安全与可追溯性。同时集成服务监控、缓存监控、连接池监控等，方便运维。

• 高效开发工具：最亮眼的功能之一是代码生成器，可以连接数据库，根据数据表一键生成前、后端代码，极大提升开发效率。同时内置了定时任务管理等功能。

    技术栈：

        前端：Vue.js

        后端：Spring-boot java

        持久层：MyBatis，

用法：

        1：用户权限体系直接使用。

        2：简单封装，集成AI的服务能力。在controller层。

        3：直接复用强大的日志功能。

        4：单体版和微服务端可选。

        5：控制台，管理控制台这种标准框架页面直接复用。

方案二：CasaOS 系统框架

        基于Go语言构建的现代化、轻量级开源个人云系统。它的设计哲学是简单易用、优雅高效，旨在让每个人都能轻松搭建和管理属于自己的云服务环境。

        提供的主要功能有：

• 应用中心：提供类似应用商店的体验，可以一键部署各种流行的开源应用（如Nextcloud、Jellyfin、Bitwarden等），所有应用都通过Docker容器运行。

• 文件管理：提供直观的Web界面，用于上传、下载、管理和分享存储在个人云上的文件。

• 系统监控：实时监控宿主机的CPU、内存、磁盘和网络等资源的使用情况。

• 存储管理：轻松管理和挂载多种存储设备，并支持多种云存储驱动的集成。

        技术栈：

                前端：Vue.js 框架

                后端 ：Echo  Go Web 框架

        提供微服务架构，Docker安装。

7.2: 会话页面

        所有大模型提供商，都提供了一个会话页面，因为会话是LLM最常见的应用，也是一个超级应用入口。

        如果自已要实现一个，如何做？

7.2.1: Open WebUI —— 最常见的会话开源

        对于大模型，最基础的应用，自然是会话应用。如果要自已部署一个对话应用，最常用的就是Open Web UI。       

        可以快速通过 Docker方式完成部署，它可以方便的进行LLM的接入，支持会话的保存。

7.2.2: 自已实现会话

        如果要自已实现一个LLM Chat，最主要要注意是，要知道 LLM API的调用本身是没有记忆功能的，自已在实现会话时，需要自行处理。

class ChatBot:
    def __init__(self, api_key, model="gpt-4"):
        self.client = OpenAI(api_key=api_key)
        self.model = model
        self.conversation_history = []
    
    def add_system_message(self, system_prompt):
        self.conversation_history.append({
            "role": "system", 
            "content": system_prompt
        })
    
    def chat(self, user_input, temperature=0.7, max_tokens=500):
        self.conversation_history.append({
            "role": "user", 
            "content": user_input
        })
        
        response = self.client.chat.completions.create(
            model=self.model,
            messages=self.conversation_history,
            temperature=temperature,
            max_tokens=max_tokens,
            stream=False
        )
        
        assistant_reply = response.choices[0].message.content
        self.conversation_history.append({
            "role": "assistant",
            "content": assistant_reply
        })
        
        return assistant_reply

注意：返回的值需要叠加到后面的会话中，否则无法记住之前的会话状态。       

 7.2.3: 流式输出的实现

        对于大模型输出分为两个阶段，一个是prefill阶段，可以理解它的思考阶段，这个阶段啥都不会输出，等就好了，第二个阶段是Decode阶段，一次输出一个字符，这时候为了有更好的体验，我们一般会采用流式方式，保证输出的流畅。

# Python流式处理示例
response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    stream=True,  # 启用流式
    temperature=0.7
)

for chunk in response:
    if chunk.choices[0].delta.content is not None:
        print(chunk.choices[0].delta.content, end="")

这里注意，不同的厂商可能稍有不同。

OpenAI​ 采用 Server-Sent Events，使用标准HTTP流，每行data: {...}

Anthropic 采用​ 自定义流式协议，分块返回，有content_block_delta等事件

国内的AI大模型，基本都采用 OpenAI的方式。

对于会话的实现，我们在 3.2 中说明。

7.3：代码开发

目前AI应用面最广的除了创意写作，应该就是代码生成了。代码生成如果使用会话界面来完成，显然效率较低。所以，模型的能力被直接对接到了编程框架，也就是开发插件+后台能力的方式存在。

我们先来看看最流行的AI开发插件有哪几款。

1：Claude Code （Anthropic)——业界最强的代码开发工具。

2：GitHub Copilot——这是最早，最有名的一款开发插件，基于VS Code。

3：Cursor，Windsuf——中期比较流行，是独立的开发工具。

其它的工具我就不再一一列举，我个人用得比较多的是Github Copilot 和 Cursor。

我们来看看 AI 为代码开发到底带来了什么？

1：代码补全。

这个用得最多，就是猜你想写什么代码，提前给你选择。

这个使用的模型要考虑快速的响应速度，一般会采用轻量，低延迟，非思考型，有点像是语言的引擎。比如：GPT-4.1，Haiku 4.5等。

2：问答

这个肯定还是少不了，不过会有上下文，可以和当前代码相关。

3：重构

多文 件的编辑，有点像是重构，快速改接品，批量修复等……

这个一定要配长下文支持，有Thking模式的模型 ，比如：GPT o3。

4：代理模式

这个比较高级，给任务->出计划->改代码->跑测试->失败了再修复。

5：生成测试代码，生成文档等……

最后，我们来看看有哪些使用AI代码开发工具的方式。

Vibe coding：氛围编程 ，自然语言驱动，让AI自动产生代码。这个适合做原型，一次性的小工具，实现探索性的需求。

AI Pair-Prog：协作型。AI完成局部改造 ，补全的工作，主体任务和审核任务还是你自已来。

Spec-First：给AI限定权限，强制做审核。强调测试收敛，保证代码质量。

Agent-with-Guardrails：允许代理直接编程 ，可以在大重构，代码迁移，批量修复，依赖升级等特殊场景使用。

7.4：智能体应用

        这里提到智能体应用，其实它的形态会有很多种，我们在编排的时候，提到了一些常见的形态。但那并不是所有。我们可以认为，以后智能体应用会无处不在。

        我们在考虑自已搭建智能体应用之前，必须要提到一个应用：Manus，这是一个什么鬼？

        它被叫做能做事的通用智能体，不只是聊天回答问题，而是像你的一个虚拟同事，可能规划工作步骤，调用工具，在一台虚拟电脑里执行任务。最后直接交付产物。它的使用并不是简单的Thinking，而是会将你的任务转换成若干步骤和计划。

        我们在这里重点不在于介绍业务，但面向B端的智能体应用，最重要就是业务，所以，我们不再展开。

八：高级应用

8.1 大模型微调

        如果要做大模型的微调，并不是一件简单的事情。微调一般有三种方式：

• 在线微调

模型供应商提供了商业模型的在线微调能力，比如 OpenAI 的 GPT 3.5 等模型就支持在线微调。这种模式是基于商业大模型的微调，因此微调后模型还是商业大模型，我们去使用时依然要按 token 付费。

• 微调平台

第二种是云厂商做的一些模型在线部署、微调平台。比如阿里云的 PAI 平台的模型广场功能，就具备模型的部署和训练功能。

• 私有微调

如果你或你的公司手里有足够的卡，希望完全本地私有化部署和微调，此时就可以使用一些开源方案，部署一个微调平台来进行模型微调。

自已本地微调的方法有全量微调，参数高效微调（PEFT），一般企业会采用后者，因为代价较低。比如：LoRA / QLoRA。        

        

8.2 大模型蒸馏

如何利用DeepSeek-R1来蒸馏自己的大模型？

蒸馏的本质量快速学到其它模型的能力，自从DeepSeek-R1出来后，最主要的蒸馏就集中在如何快速学习R1的思维链推理能力（因为其它模型一般不具有此能力，此能力会大大提升模型的能力）。

第一步 生成教学数据

使用DeepSeek -R1，利用你的业务知识，生成合适的示例。

completion = client.chat.completions.create(

model="deepseek-r1",

messages=[

{'role': 'system', 'content': system},

{'role': 'user', 'content': '新闻分类：《美国队长4》被调侃为《关云长4：周仓传》'},

]

)

#通过reasoning_content字段打印思考过程

print("<think>")

print(completion.choices[0].message.reasoning_content)

print("</think>")

#通过content字段打印最终答案

print(completion.choices[0].message.content)

第二步：微调

使用上一步生成的数据，进行微调。

整个过程非常简单，重点就是要生成符合业务要求的教学数据。

8.3: 大模型数据标注

        如果要使用SFT，需要提供标注的数据：（指令/输入 -> 标准输出），这种带答案的数据，就是标注数据。

     标注数据的生成方式：

1. 定义任务与输出契约（schema/格式/边界）

2. 收集原始数据并脱敏

3. 生成候选标注（规则/强模型/历史答案）

4. 自动校验（格式、可执行性、引用一致性）

5. 人工抽检 + 返工机制

6. 建“难例集/反例集”（模型最容易错的）

7. 版本化：数据、prompt、模型、评测集都要有版本号

8.4: 大模型评测 

        大模型发布后需要评测（如果模型推理是自行研发的，实际上也需要做评测）。

常用方法（强烈建议至少做前3项）：

1. Golden set（小而精）：50–500 条高价值用例（含边界/反例）

2. 断言式测试（像单元测试）：

   • JSON 可解析、字段齐全

   • 必须包含引用/必须不泄露敏感信息

   • 关键事实必须出现/禁止出现

3. LLM-as-a-judge + rubric：对“相关性、完整性、是否幻觉、是否遵循格式”等打分

4. 回归评测：每次改 prompt/数据/模型都要跑（CI化）

5. 线上 A/B：人类反馈 + 关键指标（工单解决率、人工介入率、时延、成本）

最常见的开源框架

• DeepEval：偏“像 pytest 一样测试 LLM 系统”，支持多种指标与 LLM judge

九：平台治理

        AI 平台要正常运行，需要一些治理工作。

        比如：平台的调试，应用的发布，运行的监控，数据的审计。

        这并不是本文的重点，不再多说。