企业官网建设流程全解析

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

1. 先别急着选平台，搞清楚AI Agent到底能帮你解决什么

最近聊AI Agent的人很多，但很多人第一步就错了——不是先看哪个平台功能多、哪个平台火，而是要先想清楚，你的业务到底需要AI Agent做什么。

AI Agent，简单说，就是一个能理解目标、自主调用工具去完成任务的智能体。它和普通聊天机器人的最大区别在于自主性和工具调用能力。比如，一个客服Agent能自己查订单、算运费、生成工单；一个数据分析Agent能自动拉取数据库、清洗数据、生成图表报告。

所以，在评估任何平台之前，你得先明确几个事：

1. 任务目标是否清晰？是处理固定格式的工单，还是应对开放性的用户咨询？
2. 需要调用哪些工具？是内部的API（如CRM、ERP接口），还是外部的服务（如天气、地图、支付）？
3. 对稳定性和成本有多敏感？是内部测试用，还是直接面向客户的生产环境？

我见过不少团队，一上来就冲着“大而全”的闭源商业平台去，结果要么发现核心API对接不了，要么成本远超预期，要么流程过于僵化，业务根本“跑不起来”。折腾一圈后才发现，反而是那些开源方案，因为灵活、可定制、能私有化部署，成了最终落地的主力。

这篇文章，我就结合实测经验，帮你理清思路。我们不比谁的口号响，就看谁能真把业务逻辑跑通。重点会放在如何用开源方案，从零搭建一个能稳定工作的AI Agent。

2. 开源AI Agent的核心组件：不是魔法，是积木

别被“智能体”这个词唬住，拆开看，一个能跑起来的AI Agent系统，主要由以下几块“积木”构成：

2.1 “大脑”：大语言模型

这是Agent的决策中心，负责理解用户指令、规划任务步骤、生成调用工具的指令。你可以用云端API（如OpenAI GPT、Claude、国内大模型），也可以用本地部署的开源模型（如Llama、Qwen、DeepSeek等）。选择的关键在于：

• 成本与隐私：敏感数据或高频调用，本地部署模型是更稳妥的选择。
• 上下文长度：处理长文档或多轮对话，需要支持长上下文的模型。
• 工具调用格式：模型必须能输出结构化的JSON等格式，以准确调用工具。

2.2 “工具箱”：Function/Tool Calling

这是Agent的手和脚。每个工具对应一个具体的函数或API接口。例如：

• get_weather(city: str)：调用天气API。
• query_database(sql: str)：执行数据库查询。
• send_email(to: str, subject: str, body: str)：调用邮件服务。

平台或框架需要有能力将工具的描述（名称、参数、说明）清晰地“告诉”大模型，并能够解析大模型的输出，准确地调用对应的工具函数。

2.3 “记忆体”：短期与长期记忆

• 短期记忆：即对话上下文（Context），让Agent记得当前会话中说过的话。通常由大模型本身的上下文窗口承担。
• 长期记忆：需要持久化存储的信息，如用户偏好、历史会话摘要、知识库。这通常需要向量数据库（如Chroma、Milvus、Qdrant）来存储和检索。

2.4 “调度器”：工作流与状态管理

对于复杂任务，Agent需要拆解步骤、判断条件、循环或并行执行。这就需要一个调度器来管理任务状态（State）。比如，一个订票Agent的流程可能是：理解需求 -> 查询航班 -> [无结果则调整日期重查] -> 确认价格 -> 生成订单。

2.5 “运行环境”：框架与平台

这就是将以上所有积木组合起来的“脚手架”。开源领域有几个主流选择：

• LangChain/LlamaIndex：生态最丰富的Python框架，组件多，灵活度高，但需要一定的开发量。
• Semantic Kernel：微软出品，与.NET生态结合好，同样功能强大。
• AutoGen：由微软研究院推出，擅长多智能体协作场景。
• Dify/FastGPT：更偏向于开源的“低代码”应用平台，提供了可视化编排工作流、知识库管理、Web用户界面的能力，能更快地搭建出可交付的应用。

对于大多数想让业务“跑起来”的团队，我建议从Dify/FastGPT 这类应用平台或LangChain 这类成熟框架入手。它们帮你解决了最繁琐的工程整合问题。

3. 实战：用开源方案搭建一个客服工单处理Agent

我们以一个具体的场景为例：搭建一个能自动处理内部IT支持工单的AI Agent。它的任务是：从邮件或聊天窗口读取用户提交的工单描述，自动分类、提取关键信息（如员工ID、设备号、问题类型），并调用内部API在Jira或类似系统中创建工单。

3.1 环境与工具准备

假设我们选择LangChain作为框架，Qwen作为本地大模型，使用FastAPI提供Web接口。

环境清单：

• Python 3.9+
• 至少8GB内存（运行7B参数的量化版模型）
• 安装核心库：

  pip install langchain langchain-community langchain-core pip install fastapi uvicorn pip install requests # 用于调用外部API

• 下载一个适合工具调用的开源模型，例如Qwen2.5-7B-Instruct，并使用Ollama或vLLM在本地启动模型服务。这里以Ollama为例：

  # 安装Ollama (详见官网) # 拉取并运行模型 ollama pull qwen2.5:7b ollama run qwen2.5:7b # 默认会在 localhost:11434 提供API

3.2 定义工具（工具箱）

首先，我们定义两个核心工具：classify_ticket用于分类和提取信息，create_jira_ticket用于创建工单。

import json from typing import TypedDict import requests # 定义工单信息结构 class TicketInfo(TypedDict): category: str # 如 “硬件”, “软件”, “网络” employee_id: str asset_tag: str problem_summary: str priority: str # “高”, “中”, “低” # 工具1：分类与信息提取（这里用LLM模拟，实际可接入更复杂的NLP模型） def classify_ticket(description: str) -> str: """ 根据用户描述，提取结构化工单信息。 参数: description: 用户的工单描述文本 返回: 格式化的JSON字符串，包含分类、员工ID、资产标签、问题摘要、优先级。 """ # 这里是模拟，实际应调用LLM进行处理 # 使用LangChain的LLM组件 from langchain_community.llms import Ollama llm = Ollama(model="qwen2.5:7b", base_url="http://localhost:11434") prompt = f""" 你是一个IT支持工单分类助手。请从以下用户描述中提取信息，并以JSON格式返回。 要求： 1. 分类：硬件、软件、网络、账户权限、其他。 2. 提取员工ID（格式如 E12345）。 3. 提取设备资产标签（格式如 ASSET-1001）。 4. 用一句话总结问题。 5. 判断优先级：高（系统宕机、无法工作）、中（功能受限）、低（咨询、轻微不便）。 用户描述：{description} 只返回JSON，不要有其他文字。 JSON格式示例： {{ "category": "硬件", "employee_id": "E12345", "asset_tag": "ASSET-1001", "problem_summary": "笔记本电脑无法开机", "priority": "高" }} """ response = llm.invoke(prompt) # 简单清理响应，确保是合法JSON try: # 尝试从响应中提取JSON部分 start = response.find('{') end = response.rfind('}') + 1 json_str = response[start:end] parsed = json.loads(json_str) # 验证必要字段 if all(key in parsed for key in ["category", "employee_id", "asset_tag", "problem_summary", "priority"]): return json.dumps(parsed, ensure_ascii=False) else: return json.dumps(TicketInfo(category="其他", employee_id="", asset_tag="", problem_summary=description, priority="中")) except json.JSONDecodeError: # 如果解析失败，返回一个默认结构 return json.dumps(TicketInfo(category="其他", employee_id="", asset_tag="", problem_summary=description, priority="中")) # 工具2：创建Jira工单（模拟） def create_jira_ticket(ticket_info_json: str) -> str: """ 根据提取的工单信息，调用Jira API创建工单。 参数: ticket_info_json: classify_ticket函数返回的JSON字符串。 返回: 创建成功的工单Key，如 “IT-1001”。 """ ticket_info = json.loads(ticket_info_json) # 这里是模拟调用，实际需要替换为真实的Jira API端点、认证信息 jira_url = "https://your-jira-instance.atlassian.net/rest/api/2/issue" headers = { "Content-Type": "application/json", "Authorization": "Bearer YOUR_TOKEN" # 实际使用中请安全地管理令牌 } payload = { "fields": { "project": {"key": "IT"}, "summary": f"[{ticket_info['priority']}] {ticket_info['category']}: {ticket_info['problem_summary']}", "description": f"员工: {ticket_info['employee_id']}\n设备: {ticket_info['asset_tag']}\n\n原始描述: {ticket_info['problem_summary']}", "issuetype": {"name": "故障"}, "priority": {"name": ticket_info['priority'].upper()} } } # 实际调用（此处注释掉，避免误操作） # response = requests.post(jira_url, json=payload, headers=headers) # response.raise_for_status() # return response.json()['key'] # 模拟返回 print(f"[模拟] 正在创建Jira工单， payload: {payload}") return "IT-模拟-1001"

3.3 构建智能体（大脑与调度）

使用LangChain的AgentExecutor来组装。

from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from langchain_community.llms import Ollama # 1. 初始化LLM llm = Ollama(model="qwen2.5:7b", base_url="http://localhost:11434") # 2. 将函数包装成LangChain工具 from langchain.tools import Tool tools = [ Tool( name="classify_ticket", func=classify_ticket, description="""用于分析和分类IT工单描述。输入是用户的原始问题描述文本，输出是包含category, employee_id, asset_tag, problem_summary, priority的JSON字符串。""" ), Tool( name="create_jira_ticket", func=create_jira_ticket, description="""根据结构化的工单信息（JSON格式）创建Jira工单。输入是classify_ticket工具输出的JSON字符串，输出是新创建的Jira工单Key。""" ) ] # 3. 创建提示词模板 prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个专业的IT支持助手。请根据用户的问题，按步骤使用工具来处理。首先，使用 classify_ticket 工具分析问题。然后，使用 create_jira_ticket 工具创建工单。最后，将工单号告知用户。"), ("placeholder", "{chat_history}"), ("human", "{input}"), ("placeholder", "{agent_scratchpad}"), ]) # 4. 创建智能体和执行器 agent = create_tool_calling_agent(llm=llm, tools=tools, prompt=prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True) # verbose=True 打印详细过程 # 5. 测试运行 if __name__ == "__main__": test_input = "我是员工E54321，我的电脑ASSET-7890突然蓝屏了，完全没法工作，非常紧急！" result = agent_executor.invoke({"input": test_input}) print("\n--- 最终回复 ---") print(result["output"])

3.4 封装为API服务

使用FastAPI提供一个简单的HTTP接口。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI(title="IT Support Agent API") class TicketRequest(BaseModel): description: str @app.post("/process_ticket/") async def process_ticket(request: TicketRequest): """ 处理工单描述，自动分类并创建Jira工单。 """ try: result = agent_executor.invoke({"input": request.description}) return {"status": "success", "ticket_created": True, "agent_response": result["output"]} except Exception as e: raise HTTPException(status_code=500, detail=f"Agent处理失败: {str(e)}") if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

现在，你可以通过向http://localhost:8000/process_ticket/发送POST请求（JSON body:{"description": "你的问题描述"}）来调用这个Agent了。

4. 从“能跑”到“跑得好”：关键配置与避坑指南

上面的例子只是一个最小可行产品。要让它在业务中真正可靠运行，你需要关注以下几个层面：

4.1 模型选择与调优

• 不要盲目追求大参数：7B、14B的模型在工具调用、分类等任务上已经表现很好，且对资源要求低。先从7B模型开始测试。
• 提示词工程是关键：classify_ticket函数里的prompt是核心。你需要反复调试，给出清晰的指令和输出格式示例（Few-shot），确保模型输出稳定、可解析的JSON。
• 温度参数：对于工具调用这类需要确定性的任务，将LLM的温度（temperature）设置为0或接近0（如0.1），以减少随机性。

4.2 工具调用的稳定性

• 结构化输出：确保LLM的输出能被稳定解析。除了在提示词中约束，可以使用LangChain的StructuredOutputParser或框架自带的结构化输出功能。
• 错误处理与重试：在create_jira_ticket等调用真实API的工具中，必须加入重试逻辑和异常捕获。网络超时、API限流、认证失败都是常见问题。

  from tenacity import retry, stop_after_attempt, wait_exponential @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=10)) def call_jira_api(payload): # ... API调用代码

• 工具描述要精准：给Agent的工具描述（description）要尽可能准确、无歧义，说明输入输出是什么，这直接影响LLM选择工具的准确性。

4.3 记忆与状态管理

• 会话记忆：上述示例是单次调用。如果是多轮对话，需要将chat_history传入。LangChain提供了多种记忆后端（ConversationBufferMemory等）。
• 长期记忆与知识库：如果Agent需要根据公司知识库（如Wiki、手册）回答问题，就需要集成向量数据库。流程是：将知识库文档切片、向量化存储；用户提问时，先检索相关片段，再将“片段+问题”一起交给LLM生成答案。Dify/FastGPT这类平台将此过程可视化，降低了实现难度。

4.4 部署与监控

• 私有化部署：这是开源方案的最大优势。使用Docker将你的Agent应用、模型服务（Ollama）、向量数据库打包，可以在任何内部服务器部署。
• API网关与认证：生产环境一定要为FastAPI接口添加API密钥认证、速率限制等。
• 日志与监控：记录每一次Agent的调用、工具使用、LLM的请求和响应。这不仅是排查问题的依据，也是优化提示词、分析成本的基础。将日志输出到ELK或类似监控平台。
• 成本控制：如果使用云端LLM API，必须监控Token消耗。设置预算告警。对于内部工具，本地模型是控制长期成本的最佳选择。

5. 开源平台 vs. 自研框架：怎么选？

回到标题的问题，为什么“能让业务真跑起来的，居然是开源的”？因为可控。

• 商业/闭源平台：像早期的某些云平台，提供一站式服务，上手快。但当你需要深度定制、对接私有系统、处理特殊数据格式、或对响应延迟和成本有极致要求时，就会遇到天花板。
• 开源框架（如LangChain）：给你最大的灵活性。你可以选择任何模型、任何数据库、自定义任何工具。但需要较强的开发能力，需要自己组装所有部件，处理工程细节。
• 开源应用平台（如Dify/FastGPT）：在灵活性和易用性之间取得了平衡。它们提供了可视化的Agent编排、知识库管理、用户界面，同时后端代码是开放的，允许你修改和扩展。对于大多数中小团队，这是目前最推荐的起点。

选择建议：

1. 验证想法阶段：直接用Dify/FastGPT，快速拖拽出一个工作流，连接你的模型（云端或本地），看看核心逻辑是否通。
2. 深度定制与集成阶段：如果Dify无法满足你的复杂业务逻辑或特殊的集成需求，再基于LangChain进行二次开发。你可以把Dify当作原型工具，验证后的逻辑再用代码实现。
3. 追求极致性能与控本阶段：全线采用开源模型和开源框架，实现完全私有化部署，掌控每一个环节。

6. 评估AI Agent平台是否合格的检查清单

最后，无论你评估哪个平台（开源或闭源），都可以用下面这个清单来拷问它：

1. 工具接入：能否方便地接入我内部的核心系统API？是写代码还是配置？
2. 模型支持：是否支持我想要的模型（特别是本地部署的模型）？切换模型成本高吗？
3. 数据隐私：我的业务数据是否会离开我的控制范围？能否私有化部署？
4. 流程编排：复杂的工作流（判断、循环、分支）是否容易实现？是写代码还是画图？
5. 记忆与知识：是否支持多轮对话？构建和维护知识库是否方便？
6. 调试与监控：是否有清晰的日志让我看到Agent的“思考过程”？能否监控每次调用的耗时和成本？
7. 异常处理：工具调用失败时，Agent能否重试或降级处理？是否有统一的错误处理机制？
8. 部署运维：部署是否复杂？是否有Docker镜像？如何扩缩容、更新版本？

核心就一点：别只看演示，动手搭一个与你真实业务场景相关的、最简单的流程跑一遍。过程中遇到的每一个“卡点”，比如API不好接、日志看不清、部署太麻烦，都是评估这个平台是否适合你的最重要依据。很多时候，正是开源方案的“不完美”所赋予的透明度和控制力，让它成为了那个最终能把业务扛起来的选项。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度