1. 项目缘起：为什么我要从零搭建企业AI智能体？

去年年底，公司内部开始讨论引入AI能力来优化几个核心业务流程，比如智能客服、内部知识库问答和销售线索的初步筛选。老板把这个“探路”的任务交给了我，预算有限，要求是“快速验证、成本可控、后续能扩展”。一开始，我觉得这活儿不难，市面上不是有很多现成的SaaS服务吗？但真干起来才发现，从选型、部署到最终让一个AI智能体稳定、聪明地跑起来，中间全是坑。我指的“AI智能体”，不是简单调用个ChatGPT API就完事了，而是一个能感知环境、自主规划、使用工具、并从交互中学习的系统。它需要大脑（大语言模型）、记忆（向量数据库）、手脚（各种API工具）和一个协调它们的“操作系统”（Agent框架）。

我花了将近两个月，几乎把主流云服务商和开源方案试了个遍，过程堪称一部“踩坑血泪史”。今天这篇记录，就是想把我从零搭建一个企业级可用AI智能体的完整过程、关键决策背后的逻辑，以及那些官方文档里不会写的“坑”和“技巧”，毫无保留地分享出来。无论你是想给公司做技术选型的架构师，还是自己折腾个人项目的开发者，希望这些实打实的经验能帮你少走弯路。

2. 整体设计与核心思路拆解

2.1 明确需求：企业需要什么样的“智能体”？

在动手写第一行代码之前，必须把需求掰扯清楚。企业级应用和个人玩具项目有本质区别，我总结了四个核心考量点：

  1. 数据安全与隐私 ：这是红线。我们的客户数据、内部文档绝不能泄露到公网。这意味着，要么使用本地化部署的模型和数据库，要么选择信誉良好、能提供严格数据隔离协议的云服务。
  2. 可控性与可解释性 ：智能体做出的决策，尤其是涉及业务逻辑的（比如判断客户意向），必须可追溯、可审计。我们不能接受一个“黑箱”突然拒绝了一个优质客户，却说不清为什么。
  3. 成本与性能的平衡 ：按Token收费的API调用，在业务量上去之后会是天文数字。但完全自建高性能模型，硬件和维护成本又太高。需要在响应速度、准确率和月度账单之间找到一个甜蜜点。
  4. 集成与扩展性 ：智能体不能是孤岛。它需要能方便地接入公司现有的CRM、OA、客服系统，也能在未来容易地添加新的工具和能力（比如连接财务系统查报表）。

基于这四点，我放弃了直接使用ChatGPT等纯公有云API方案，决定采用 “本地模型+云基础设施+开源框架” 的混合架构。核心思路是：将最敏感的数据处理和核心推理放在可控的环境内，同时利用云的弹性来降低运维复杂度。

2.2 技术栈选型：一场艰难的“排列组合”

确定了思路，接下来就是具体的技术选型。这就像在玩一个多维度的拼图游戏，每个选择都相互关联。

大脑（大语言模型）选型 ： 这是智能体的“智商”天花板。我评估了几个方向：

  • 国际顶级闭源模型（GPT-4， Claude-3） ：能力最强，但API费用高、数据出境风险大、响应延迟不稳定。对于需要高频调用的企业内部应用，首先排除。
  • 国内大厂云上模型（通义千问、文心一言、腾讯混元） ：合规性好，接口稳定，但存在厂商锁定风险，且定制化能力较弱。可以作为备选或特定场景的补充。
  • 开源模型本地部署 ：这是最终的主选方向。它彻底解决了数据隐私问题，一次部署，固定成本。我重点测试了 Llama 3 、 Qwen 和 DeepSeek 系列。最终，在8B参数这个级别上，我选择了 Qwen-7B-Chat 。原因有三：其一，中文能力在开源模型中公认的出色，对中文业务场景友好；其二，社区活跃，工具调用（Function Calling）的生态支持较好；其三，量化后（如使用GPTQ量化到4bit）能在消费级显卡（如RTX 4060 Ti 16G）上流畅运行，硬件门槛低。

踩坑记录1：模型量化不是万能的 。为了节省显存，我一开始尝试了8bit量化，发现模型响应速度确实快，但在一些需要复杂推理的链式思考任务上，准确率有可感知的下降。后来改用 4bit GPTQ量化 ，在几乎相同的显存占用下，精度损失更小。这里的关键是，一定要用你的实际业务问题（而不仅仅是标准测试集）去评估量化后的模型表现。

记忆（向量数据库）选型 ： 智能体需要“记住”大量的产品文档、客服话术和历史对话，向量数据库就是它的海马体。选型核心看三点：性能、易用性和成熟度。

  • Milvus ：名声最响，功能最全，但架构较重，需要依赖Etcd、MinIO等组件，运维复杂度高。对于中小型项目，有点“杀鸡用牛刀”。
  • Chroma ：简单易用，Python原生，适合快速原型验证。但在生产环境中，其持久化和集群能力偏弱。
  • 腾讯云向量数据库（Tencent Cloud VectorDB） 与 阿里云OpenSearch向量检索 ：云服务的优势是开箱即用，免运维，有完善的监控和扩缩容。我最终选择了 腾讯云向量数据库 。决定性因素是它的 “全托管” 特性。我不需要关心底层集群状态，只需通过API写入和查询向量。它提供了媲美Milvus的检索性能（支持标量过滤、多向量查询），并且与腾讯云的其他产品（如COS对象存储）集成顺畅，对于追求稳定、希望降低运维负担的企业团队来说，这是一个非常务实的选择。虽然需要付出一些费用，但相比雇佣一个专职的数据库运维工程师，成本依然低得多。

躯干与神经（Agent框架）选型 ： 这是智能体的“操作系统”，负责调度模型、管理记忆、调用工具。我考察了LangChain、LlamaIndex、AutoGen等。

  • LangChain ：生态最庞大，模块最多，但抽象层次高，概念复杂（Chains, Agents, Tools…），学习曲线陡峭，有时感觉“为了框架而框架”。
  • LlamaIndex ：专注于数据连接和检索增强生成（RAG），在这方面做得非常优雅，但作为一个完整的Agent框架略显单一。
  • 最终方案：轻量级自定义框架 。鉴于初期需求明确，我决定不引入重型框架，而是基于 FastAPI 和 Pydantic 自己搭建一个轻量级框架。核心组件包括：一个 工具注册中心 （用Python装饰器注册各种API函数）、一个 规划与执行引擎 （解析模型输出，按顺序调用工具）、一个 对话与记忆管理器 。这样做的好处是代码完全可控，没有黑魔法，调试极其方便，并且能完美贴合我们的业务逻辑。对于大多数目标明确的企业应用，这可能比学习一个庞大框架更高效。

基础设施（云服务）选型 ： 模型和数据库跑在哪里？我选择了 腾讯云轻量应用服务器 和 容器服务 。

  • 轻量应用服务器 ：用于部署量化后的Qwen模型。选择它是因为性价比高，提供纯净的Linux环境，自带公网IP和流量包，特别适合跑这种长期运行的、中等算力的服务。我选配了 GPU型实例（如GN7） ，虽然比纯CPU实例贵，但对于保证7B模型生成速度至关重要。
  • 容器服务（TKE） ：用于部署我们自研的Agent框架、FastAPI接口以及一些辅助微服务。容器化部署保证了环境一致性，也便于后续的滚动更新和扩缩容。腾讯云容器服务与镜像仓库、监控日志的集成做得不错，省去了自己搭建K8s集群的麻烦。

3. 核心模块搭建与实操要点

3.1 本地大模型服务化部署

让开源模型像OpenAI API一样提供标准化的服务，是后续所有工作的基础。

步骤1：模型准备与量化 我从魔搭社区下载了 Qwen-7B-Chat 的原始模型。然后使用 AutoGPTQ 工具库进行4bit量化。这里有个关键命令：

# 示例量化命令，参数需根据你的GPU调整
python quantize.py --model_path ./qwen-7b-chat \
                   --output_path ./qwen-7b-chat-gptq-4bit \
                   --bits 4 \
                   --group_size 128 \
                   --damp_percent 0.01

量化过程可能需要几个小时，并且需要足够的CPU内存（建议32G以上）来加载原始模型。

步骤2：使用FastAPI封装推理服务 我没有用官方推荐的 vLLM 或 TGI ，因为它们对GPTQ量化的支持当时还不够完善。我选择了 text-generation-webui 的API模式作为后端，然后用FastAPI写了一个薄薄的中间层。这样做的好处是， text-generation-webui 社区支持好，各种模型加载和量化格式兼容性强，而FastAPI中间层让我可以自定义API格式、添加认证、限流和监控。

核心的FastAPI端点看起来像这样：

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import requests

app = FastAPI()
MODEL_API_URL = "http://localhost:5000/api/v1/generate" # text-generation-webui 地址

class GenerateRequest(BaseModel):
    prompt: str
    max_new_tokens: int = 512
    temperature: float = 0.7

@app.post("/v1/chat/completions")
async def chat_completion(request: GenerateRequest):
    # 构造符合text-generation-webui要求的payload
    payload = {
        "prompt": request.prompt,
        "max_new_tokens": request.max_new_tokens,
        "temperature": request.temperature,
        "stopping_strings": ["\n\nUser:", "</s>"] # 根据模型调整停止词
    }
    try:
        response = requests.post(MODEL_API_URL, json=payload, timeout=60)
        response.raise_for_status()
        result = response.json()
        # 从结果中提取生成的文本
        generated_text = result['results'][0]['text']
        return {"choices": [{"message": {"content": generated_text}}]}
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"Model inference error: {str(e)}")

踩坑记录2：停止词（Stopping Strings）设置 。不同的模型、不同的提示词模板，需要不同的停止词来告诉模型“何时该停下”。比如Qwen模型使用 <|im_end|> 作为对话轮次结束标记。如果停止词设错，模型就会一直“自言自语”下去，直到达到 max_new_tokens 限制。这需要反复试验，观察模型的原始输出来确定。

步骤3：服务部署与优化 将上述服务部署到腾讯云轻量应用服务器。除了安装依赖，关键优化点：

  • 使用Systemd托管服务 ：确保服务在服务器重启后能自动拉起。
  • 配置Nginx反向代理 ：对外提供HTTPS访问，并做一层负载均衡（如果你部署了多个模型实例）。
  • 设置监控告警 ：使用云监控或Prometheus监控服务的CPU、GPU、内存使用率以及API的响应时间和错误率。

3.2 腾讯云向量数据库集成

向量数据库是智能体的“长期记忆”，用于存储和检索知识库。

步骤1：创建与配置 在腾讯云控制台开通向量数据库服务，创建一个新的数据库实例和集合。关键配置：

  • 索引类型 ：选择 HNSW ，它在精度和速度之间取得了很好的平衡，适合大多数RAG场景。
  • 向量维度 ：必须与你的文本嵌入模型输出维度一致！我选用 text-embedding-3-small ，维度是1536。如果你用 BGE 或 M3E 等开源模型，通常是768维。
  • 分区与副本 ：初期数据量小（<1000万条），单分区即可。设置一个只读副本，提升查询可用性。

步骤2：数据灌入与向量化 这是最耗时但也最关键的步骤。流程是：原始文档 -> 文本分割 -> 向量化 -> 存入数据库。

  1. 文本分割 ：不要简单按固定字符数切割。我使用 LangChain 的 RecursiveCharacterTextSplitter ，并设置 chunk_size=500 和 chunk_overlap=50 。重叠部分能避免一个知识点被生硬地切断。
  2. 向量化 ：调用嵌入模型API生成向量。这里我 没有使用腾讯云向量数据库自带的嵌入模型 ，而是坚持使用本地部署的 BGE 模型。原因是为了保证数据在生成向量这个环节也不出私域网络，同时嵌入模型可以随时更换、调优。
  3. 批量写入 ：使用SDK的 upsert 接口批量写入。一定要处理好人机交互，为每段文本（chunk）生成一个包含源文件、页码等信息的 metadata ，方便后续追溯答案来源。
from tencentcloud.vdb.v20220106 import vdb_client, models
from sentence_transformers import SentenceTransformer

# 初始化嵌入模型和VDB客户端
embed_model = SentenceTransformer('BAAI/bge-small-zh-v1.5')
client = vdb_client.VdbClient(credential, region="ap-guangzhou")

# 假设docs是分割好的文本列表
embeddings = embed_model.encode(docs, normalize_embeddings=True).tolist()

# 准备写入数据
records = []
for i, (doc, emb) in enumerate(zip(docs, embeddings)):
    record = models.UpsertRequest()
    record.Id = str(i) # 简单ID，生产环境建议用更复杂的
    record.Vector = emb
    record.Fields = {"text": doc, "source": "产品手册_v1.2.pdf", "page": 10}
    records.append(record)

# 分批写入，每批100条
batch_size = 100
for i in range(0, len(records), batch_size):
    req = models.UpsertRequest()
    req.Records = records[i:i+batch_size]
    req.CollectionName = "my_knowledge_base"
    client.Upsert(req)

步骤3：检索策略优化 简单的向量相似度搜索（余弦相似度）有时不够用。

  • 混合搜索 ：腾讯云向量数据库支持 “向量检索 + 标量过滤” 。例如，在检索时，可以添加过滤器 metadata['department'] == '销售' ，这样只检索销售部门相关的文档，大大提升了精度。
  • 重排序（Re-ranking） ：先通过向量检索召回Top K个结果（比如K=20），再用一个更精细但更慢的交叉编码器模型（如 bge-reranker ）对这20个结果进行重排序，选出最相关的3-5个。这一步能显著提升最终答案的质量，尤其是当知识库文档很多、内容相似度高的时候。

3.3 Agent核心逻辑实现

这是整个系统的大脑皮层，负责思考、规划和行动。

步骤1：工具（Tools）的定义与注册 工具是智能体与外界交互的手脚。我设计了一个装饰器来注册工具：

import inspect
from typing import Callable, Dict

class ToolRegistry:
    def __init__(self):
        self._tools: Dict[str, Dict] = {}

    def register(self, name: str, description: str):
        def decorator(func: Callable):
            # 利用inspect自动提取函数参数信息，用于生成给LLM的schema
            sig = inspect.signature(func)
            parameters = {}
            for param_name, param in sig.parameters.items():
                parameters[param_name] = {
                    "type": param.annotation.__name__ if param.annotation != inspect.Parameter.empty else "string",
                    "description": f"参数 {param_name}" # 可以更详细
                }
            self._tools[name] = {
                "function": func,
                "description": description,
                "parameters": parameters
            }
            return func
        return decorator

    def get_tools_schema_for_llm(self):
        # 生成符合OpenAI Function Calling格式的schema
        schema = []
        for name, info in self._tools.items():
            schema.append({
                "type": "function",
                "function": {
                    "name": name,
                    "description": info["description"],
                    "parameters": {
                        "type": "object",
                        "properties": info["parameters"],
                        "required": list(info["parameters"].keys())
                    }
                }
            })
        return schema

registry = ToolRegistry()

@registry.register(name="query_weather", description="查询指定城市的当前天气")
def query_weather(city: str) -> str:
    # 实际调用天气API
    return f"{city}的天气是晴，25摄氏度。"

@registry.register(name="search_knowledge_base", description="从知识库中检索相关信息")
def search_knowledge_base(query: str, top_k: int = 3) -> str:
    # 调用前面实现的向量数据库检索逻辑
    results = vector_db_search(query, top_k)
    return "\n\n".join([f"来源[{r['source']}]: {r['text']}" for r in results])

步骤2：规划与执行引擎 这是Agent的核心循环。我实现了一个简单的 ReAct 模式（Reasoning + Acting）：

  1. 观察 ：接收用户输入和当前对话历史。
  2. 思考 ：将用户问题、可用工具列表、历史记录组合成提示词（Prompt），发送给本地部署的Qwen模型，要求模型“思考”下一步该做什么（调用哪个工具，参数是什么），或者直接给出最终答案。
  3. 行动 ：解析模型的输出。如果模型决定调用工具，就执行对应的函数。
  4. 再观察 ：将工具执行的结果反馈给模型，进入下一轮“思考-行动”循环，直到模型认为可以给出最终答案。
class SimpleAgent:
    def __init__(self, llm_client, tool_registry):
        self.llm = llm_client
        self.tools = tool_registry

    def run(self, user_input: str, conversation_history: list) -> str:
        # 初始化系统提示词，告诉模型它的角色和能力
        system_prompt = f"""你是一个有帮助的AI助手，可以调用工具来解决问题。你可以使用的工具有：
        {self._format_tools_for_prompt()}
        请根据用户问题，决定是直接回答，还是调用工具。如果需要调用工具，请严格按照以下JSON格式回复：
        {{"action": "call_tool", "tool_name": "工具名", "arguments": {{"arg1": "value1"}}}}
        如果可以直接回答，请回复：
        {{"action": "final_answer", "answer": "你的回答内容"}}
        """
        messages = [{"role": "system", "content": system_prompt}] + conversation_history + [{"role": "user", "content": user_input}]

        max_turns = 5 # 防止无限循环
        for turn in range(max_turns):
            # 调用LLM进行“思考”
            llm_response = self.llm.chat_completion(messages)
            # 解析LLM的响应（这里需要健壮的JSON解析和错误处理）
            try:
                decision = json.loads(llm_response)
            except json.JSONDecodeError:
                # 如果模型没有返回合法JSON，可能它想直接说话，这里做兜底处理
                return llm_response

            if decision['action'] == 'final_answer':
                return decision['answer']
            elif decision['action'] == 'call_tool':
                tool_name = decision['tool_name']
                tool_args = decision['arguments']
                # 查找并执行工具
                if tool_name in self.tools._tools:
                    tool_func = self.tools._tools[tool_name]['function']
                    result = tool_func(**tool_args)
                    # 将工具执行结果作为新的上下文加入对话
                    messages.append({"role": "assistant", "content": llm_response})
                    messages.append({"role": "user", "content": f"工具执行结果：{result}"})
                else:
                    messages.append({"role": "user", "content": f"错误：工具 '{tool_name}' 不存在。请重新思考。"})
            else:
                messages.append({"role": "user", "content": "你的回复格式不正确，请严格按照指定的JSON格式回复。"})
        return "抱歉，经过多轮尝试仍未能解决问题。"

踩坑记录3：提示词工程是魔鬼 。让模型稳定地输出可解析的JSON，并且做出合理的工具调用决策，极度依赖提示词的设计。我花了大量时间调整系统提示词，包括：清晰定义工具、给出多个思维链（Chain-of-Thought）的示例、严格规定输出格式。一个技巧是，在提示词里加入“如果问题不清晰，请先向我提问澄清”的指令，能有效减少模型胡编乱造参数的情况。

4. 联调测试与性能优化

当各个模块都搭建好后，真正的挑战才刚刚开始：让它们协同工作，并且满足企业级应用的性能要求。

4.1 端到端流程集成测试

我设计了几类测试用例：

  1. 简单问答 ：测试知识库检索和模型生成的基本能力。
  2. 多轮对话 ：测试对话历史管理是否正常，模型能否理解上下文。
  3. 工具调用 ：测试Agent能否正确选择工具、传入参数并理解返回结果。
  4. 复杂任务分解 ：例如“帮我查一下北京和上海的天气，然后对比一下哪里更暖和”。这需要Agent规划多个步骤。

测试中暴露的问题五花八门：

  • 问题A：向量检索召回不相关文档 。表现为回答偏离主题。 排查 ：检查文本分割策略是否合理，过长的chunk会包含无关信息，过短的chunk会丢失上下文。调整 chunk_size 和分割符（优先按段落、标题分割）。同时，检查嵌入模型是否适合你的领域，可以尝试在领域数据上微调嵌入模型。
  • 问题B：模型不调用工具，总是尝试自己编答案 。 排查 ：首先检查提示词是否足够强调工具的使用。其次，检查提供给模型的工具描述是否清晰易懂。一个有效的方法是 “少即是多” ，初期不要给模型太多工具，只给1-2个最相关的，并配上非常详细的描述和示例。等模型学会使用后，再逐步添加。
  • 问题C：JSON解析失败 。 排查 ：模型输出不稳定，有时会多出一些解释性文字。解决方案是在调用LLM时，设置 temperature=0 来降低随机性，并在提示词中严格要求“只输出JSON，不要有任何其他文字”。在代码解析时，使用更健壮的方法，比如先尝试用正则表达式提取JSON块，再解析。

4.2 性能瓶颈分析与优化

在压力测试下，系统瓶颈显现：

  1. 响应延迟高 ：一个用户问题，从发起到收到最终答案，平均需要8-10秒，无法接受。
    • 分析 ：使用火焰图工具分析，发现耗时大头在：a) 向量数据库检索（约500ms），b) 大模型生成（约3000-5000ms），c) 网络延迟（各服务间RPC调用）。
    • 优化 ：
      • 向量检索异步化 ：在Agent“思考”是否需要检索的同时，就 异步发起 向量检索。如果模型决定需要，结果可能已经快拿到了；如果不需要，取消任务即可。这能节省一轮往返时间。
      • 模型推理优化 ：启用 vLLM 的 连续批处理（Continuous Batching） 功能。当多个请求同时到来时，它能高效地复用GPU显存中的模型权重，显著提高吞吐量。将 max_model_len 调整到合适大小，避免不必要的内存占用。
      • 缓存 ：对常见的、结果不变的查询（如“公司介绍”），在应用层增加Redis缓存，直接返回缓存结果。
  2. 并发能力弱 ：模拟10个并发用户，错误率飙升。
    • 分析 ：轻量服务器GPU资源被占满，模型服务成为瓶颈；数据库连接数不足。
    • 优化 ：
      • 模型服务水平扩展 ：使用腾讯云容器服务，将模型服务打包成Docker镜像，并部署多个副本，前面用Nginx做负载均衡。虽然每个副本都需要加载模型，占用显存，但这是提升并发处理能力的直接方法。也可以考虑使用 模型并行 技术，将超大模型拆分到多张卡上，但这对架构改造要求高。
      • 数据库连接池 ：确保Agent服务使用连接池来访问向量数据库，避免频繁建立和断开连接的开销。
      • 限流与降级 ：在API网关层面设置限流，防止突发流量打垮服务。当模型服务压力过大时，可以设计降级策略，例如返回一个简化的、基于规则的回答，或者引导用户稍后再试。

4.3 成本监控与优化

企业项目必须关注成本。

  1. 云资源成本 ：
    • GPU实例 ：这是最大头。通过监控发现，夜间使用率极低。于是编写脚本，在业务低峰期（凌晨1点至早上7点）自动将GPU实例 关机 ，高峰期前再启动。腾讯云关机后仅收取磁盘和公网IP费用，大幅节省了算力成本。
    • 向量数据库 ：主要成本是存储和读取单元。定期清理测试数据和过期日志。对于历史对话记录等冷数据，可以转存到更便宜的对象存储（COS）中，只在需要时再导入查询。
  2. 模型推理成本 ：
    • 提示词优化 ：精简系统提示词和上下文，减少不必要的Token消耗。在RAG中，控制检索返回的文本片段（chunk）数量和长度。
    • 输出长度限制 ：合理设置 max_new_tokens ，避免模型生成冗长无关的内容。

5. 常见问题排查与运维心得

5.1 问题排查速查表

问题现象 可能原因 排查步骤与解决方案
智能体回答“我不知道”或内容空洞 1. 向量数据库检索失败或未命中。
2. 检索到的上下文未正确注入提示词。
3. 模型温度参数过高，随机性太强。		 1. 检查向量数据库连接和查询日志，确认检索是否执行并返回了结果。
2. 打印出发送给模型的完整提示词，检查检索到的文本是否被正确拼接在“上下文”部分。
3. 将 temperature 调低至0.1-0.3，增加确定性。
工具调用被忽略，模型自行编造 1. 工具描述不够清晰。
2. 提示词中未强调必须使用工具。
3. 示例（Few-shot）不足。		 1. 重写工具描述，使用更具体、无歧义的语言，说明输入输出。
2. 在系统提示词开头用强语气说明：“ 你必须使用提供的工具来回答问题，严禁捏造信息。 ”
3. 在提示词中提供2-3个完美演示工具调用的对话示例。
响应速度突然变慢 1. 模型服务内存/显存泄漏。
2. 向量数据库负载过高。
3. 网络波动或依赖的外部API变慢。		 1. 重启模型服务实例。监控GPU显存使用情况，考虑定期重启服务作为临时措施。
2. 查看向量数据库控制台的监控指标，如CPU、查询延迟。考虑增加索引副本或升级规格。
3. 在代码中添加对关键依赖服务的超时和熔断机制（如使用 tenacity 库进行重试）。
对话历史混乱，上下文丢失 1. 对话历史管理逻辑有bug，未正确拼接或截断。
2. Token数超过模型上下文长度限制。		 1. 调试代码，确保每轮对话的user和assistant消息都被正确追加到历史列表。
2. 实现一个“滑动窗口”或“摘要”策略。当历史对话的Token总数接近限制（如Qwen-7B是8K）时，将最早的消息移除，或者用模型对之前的对话生成一个简短摘要，用摘要替代详细历史。

5.2 运维与监控建议

  1. 日志标准化 ：给所有服务的关键步骤（收到请求、开始检索、调用模型、调用工具、返回结果）打上结构化的日志（JSON格式）。使用 ELK 或 Loki 进行集中收集和查询，便于链路追踪。
  2. 指标监控 ：
    • 业务指标 ：请求量、平均响应时间、错误率、工具调用成功率。
    • 资源指标 ：GPU利用率、显存占用、向量数据库查询延迟、连接数。
    • 模型指标 ：每次请求的输入/输出Token数（估算成本）、生成速度（Tokens per second）。
  3. 健康检查与告警 ：为每个服务（模型API、Agent服务、向量数据库）设置HTTP健康检查端点。当连续检查失败时，通过钉钉、企业微信或短信触发告警。
  4. 版本管理与回滚 ：将模型文件、代码、配置文件全部纳入Git版本控制。使用Docker镜像哈希或Git Commit ID作为服务版本标签。一旦新版本上线出现问题，能快速回滚到上一个稳定版本。

5.3 关于向量数据库的一个深度思考

在构建知识库时，我遇到了一个典型问题： 意思相近的词汇需要统一吗？比如“上下文理解”和“语境推测”。 我的结论是： 对于追求高精度的垂直领域知识库，非常有必要进行一定程度的归一化。 原因在于，当前的文本嵌入模型（如BGE、OpenAI的text-embedding）虽然具备一定的同义词理解能力，但并非完美。如果知识库中同时存在“上下文理解”和“语境推测”两种表述，而用户查询用的是“如何理解上下文”，那么向量相似度搜索可能会更偏向“上下文理解”的段落，而忽略了那些用“语境推测”表述但内容高度相关的宝贵资料。 我的做法是 ：在数据预处理阶段，增加一个“术语标准化”步骤。针对业务领域的核心概念，建立一个同义词映射表。在文本分割和向量化之前，先将文档中的词汇进行替换。例如，将所有“语境推测”替换为“上下文理解”。这相当于人为地帮助模型对齐了语义空间，能显著提升检索的召回率和准确性。当然，这个映射表需要领域专家参与制定，并且是一个持续维护的过程。

从零搭建一个企业级AI智能体，远不止是技术组件的堆砌。它更像是一个系统工程，需要你在数据隐私、成本控制、性能表现和开发效率之间反复权衡。我的体会是，没有“银弹”，最适合的方案往往是最贴合自己业务场景和团队技术栈的“组合拳”。开源模型+云托管数据库+自研轻量框架这条路径，给了我们足够的控制权和灵活性，虽然踩坑不少，但每一步都走得心里踏实。现在，这个智能体已经稳定运行了几个月，每天处理着上千次内部咨询。回头看，最大的收获不是做出了一个多酷的系统，而是打通了从数据、算法到工程落地的完整闭环，这套经验或许比代码本身更有价值。如果你也正准备开始，我的建议是：从小处着手，定义一个最明确的场景，快速搭建一个最小可行产品，然后沿着“数据->检索->推理->交互”这个链条，一个环节一个环节地去打磨和优化。

# AI智能体
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

大 硬 仗14小时：用2009年的上古亮机卡跑完深度学习，CPU满载但代码没崩

avatar 亚马逊云科技技术品牌专区
cover

原来AI、画图、导航都在用向量！

avatar 亚马逊云科技技术品牌专区
cover

害虫检测和识别3：基于深度学习YOLO26神经网络实现害虫检测和识别(含训练代码、数据集和GUI交互界面）

avatar 亚马逊云科技技术品牌专区