級問數(shù)智能體基礎(chǔ)設(shè)施搭建：從零到可運(yùn)行的完整指南)
1. 項(xiàng)目全景與基礎(chǔ)設(shè)施需求拆解1.1 問數(shù)智能體到底是做什么的我先把這個(gè)項(xiàng)目的定位說清楚。LCODER這個(gè)系列的第一篇講的是方案設(shè)計(jì)到了第二篇就是動(dòng)真格的時(shí)候了。所謂的“問數(shù)項(xiàng)目”準(zhǔn)確說是做一 個(gè)Text-to-SQL形態(tài)的智能體用戶用一句大白話提問比如“上個(gè)月華東區(qū)各品類的銷售額排名是什么樣的”智能體負(fù)責(zé)理解意圖、匹配到正確的表和字段、生成SQL、到數(shù)據(jù)庫里把數(shù)據(jù)查出來最后用自然語言把結(jié)果解釋給用戶聽。這句話讀起來輕飄飄的但拆開看就有很多硬骨頭自然語言怎么轉(zhuǎn)成結(jié)構(gòu)化查詢大模型幻覺導(dǎo)致SQL寫錯(cuò)怎么辦數(shù)據(jù)庫表太多召回不準(zhǔn)怎么辦查詢結(jié)果怎么判斷要不要展示給用戶……這些問題的答案恰恰都依賴一個(gè)設(shè)計(jì)合理的基礎(chǔ)設(shè)施層。你可以把基礎(chǔ)設(shè)施理解為房子的地基和管線——用戶看不見但如果沒鋪好后續(xù)每一層業(yè)務(wù)功能都會(huì)在各種莫名其妙的地方漏水。這一篇把基礎(chǔ)設(shè)施搭建講透目的在于把后續(xù)開發(fā)工作里的不確定性提前消化掉。如果你也準(zhǔn)備做一個(gè)類似的企業(yè)級問數(shù)機(jī)器人這一篇可以直接跟著復(fù)現(xiàn)如果你只是對Agent開發(fā)感興趣這些基礎(chǔ)設(shè)施選型思路和踩坑過程同樣能幫你避免“模型對話沒問題、一接數(shù)據(jù)庫就崩”的尷尬。1.2 基礎(chǔ)設(shè)施要做哪幾件事我從實(shí)際需要出發(fā)把基礎(chǔ)設(shè)施拆成四個(gè)層面這個(gè)分類也直接對應(yīng)后面的章節(jié)安排。第一層是工程基座Python環(huán)境、依賴管理、目錄結(jié)構(gòu)、配置管理、日志系統(tǒng)。這些不起眼的東西決定了團(tuán)隊(duì)協(xié)作時(shí)會(huì)不會(huì)互相踩腳也決定了代碼半年后還能不能繼續(xù)維護(hù)。第二層是模型接入層大模型API怎么統(tǒng)一封裝、密鑰怎么管理、超時(shí)重試怎么做、流式輸出怎么處理。這是所有Agent能力的“水電煤”同時(shí)也往往是團(tuán)隊(duì)最容易亂搞的一層。第三層是數(shù)據(jù)設(shè)施層業(yè)務(wù)數(shù)據(jù)庫連接、表結(jié)構(gòu)元數(shù)據(jù)的管理、向量數(shù)據(jù)庫的初始化、Embedding模型接入。問數(shù)項(xiàng)目的數(shù)據(jù)鏈路是全局最復(fù)雜的一段牽涉結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化索引的配合必須在一開始就打好底。第四層是運(yùn)行時(shí)設(shè)施核心Agent框架的初始化、工具注冊機(jī)制、對話記憶、外部服務(wù)化API以及緩存與日志追蹤。這層決定了對外的服務(wù)能力和后續(xù)迭代的效率。1.3 技術(shù)選型總覽我把整個(gè)基礎(chǔ)設(shè)施的選型方案先列出來后面的章節(jié)會(huì)逐個(gè)解釋為什么選它層級組件選型替代方案開發(fā)語言Python3.113.10也可但不建議低于3.10依賴管理uvPoetry / pip-toolsAgent框架LangChain 0.3.xLlamaIndex輕量場景可手寫Web服務(wù)FastAPIFlask / Quart業(yè)務(wù)數(shù)據(jù)庫PostgreSQL 15MySQL 8.0向量數(shù)據(jù)庫Qdrant 1.9Milvus / pgvector緩存/會(huì)話Redis 7KeyDB大模型接入OpenAI兼容協(xié)議各家原生SDK這套方案不是拍腦袋選的。比如向量庫為什么不用pgvector——如果業(yè)務(wù)庫本身有地理信息、全文檢索之外還需處理大規(guī)模向量pgvector的性能和運(yùn)維隔離感都差點(diǎn)意思Qdrant單機(jī)部署足夠輕后期需要分布式擴(kuò)展也有成熟的方案。用PostgreSQL存業(yè)務(wù)數(shù)據(jù)用Qdrant存表結(jié)構(gòu)描述和樣例數(shù)據(jù)的向量索引兩者各管一攤界限清晰。2. 工程基座與項(xiàng)目腳手架搭建2.1 Python環(huán)境與依賴管理問數(shù)智能體涉及的技術(shù)棧非常雜LangChain、數(shù)據(jù)庫驅(qū)動(dòng)、向量庫客戶端、Web框架、數(shù)據(jù)處理庫每個(gè)庫又有自己的依賴樹很容易出現(xiàn)依賴沖突。所以環(huán)境的隔離和依賴鎖定必須從第一天就做好不然后面裝一個(gè)包就崩一次環(huán)境心態(tài)會(huì)直接報(bào)廢。我用的是Python 3.11加uv。uv是目前Python生態(tài)里速度最讓人舒適的包管理器底層用Rust寫的裝依賴比pip快上好幾倍同時(shí)生成的lock文件能保證團(tuán)隊(duì)所有人的環(huán)境完全一致。如果你還在用Python 3.9或者3.10建議至少升到3.10因?yàn)門ype Hint的語法支持會(huì)舒服很多Agent代碼里大量用到類型注解老版本寫起來很憋屈。初始化項(xiàng)目的步驟很簡單# 安裝uvmacOS/Linux curl -LsSf https://astral.sh/uv/install.sh | sh # 初始化項(xiàng)目并創(chuàng)建虛擬環(huán)境 uv init lcoder-agent cd lcoder-agent uv venv --python 3.11 .venv source .venv/bin/activate # 安裝核心依賴 uv add langchain langchain-openai langchain-community uv add fastapi uvicorn[standard] pydantic-settings uv add psycopg[binary] sqlalchemy uv add qdrant-client uv add redis uv add pandas openpyxl uv add loguru注意這里我把pandas和openpyxl也加進(jìn)來了。問數(shù)Agent查完數(shù)據(jù)之后往往需要做一些聚合、排序、格式轉(zhuǎn)換再把結(jié)果渲染成表格或圖表數(shù)據(jù)pandas是這類工作的主力工具。openpyxl是為后續(xù)直接導(dǎo)出Excel報(bào)表預(yù)留的如果項(xiàng)目沒有這個(gè)需求可以去掉。2.2 項(xiàng)目目錄結(jié)構(gòu)設(shè)計(jì)基礎(chǔ)設(shè)施階段最重要的產(chǎn)出之一就是一套清晰的目錄結(jié)構(gòu)。我見過太多Agent項(xiàng)目所有代碼都塞在兩三個(gè)文件里剛開始跑demo很爽一旦要加工具、加技能、加知識庫整個(gè)項(xiàng)目就變成一團(tuán)亂麻。我這邊的目錄設(shè)計(jì)如下lcoder-agent/ ├── app/ │ ├── main.py # FastAPI入口 │ ├── config.py # 配置管理 │ ├── api/ # HTTP接口層 │ ├── agent/ # Agent核心 │ │ ├── agent.py # 主Agent封裝 │ │ ├── prompts.py # 提示詞模板 │ │ └── skills/ # 工具/技能注冊 │ ├── tools/ # 具體工具實(shí)現(xiàn) │ │ ├── sql_executor.py # SQL執(zhí)行工具 │ │ └── db_metadata.py # 元數(shù)據(jù)查詢工具 │ ├── models/ # 數(shù)據(jù)模型 │ ├── services/ # 業(yè)務(wù)服務(wù) │ ├── vector/ # 向量庫相關(guān) │ └── utils/ # 工具函數(shù) ├── data/ # 本地?cái)?shù)據(jù)文件 ├── logs/ # 日志目錄 ├── scripts/ # 初始化腳本 ├── tests/ # 測試 ├── .env.example # 環(huán)境變量模板 ├── pyproject.toml └── README.md這套結(jié)構(gòu)的關(guān)鍵在于把“Agent邏輯”和“工具實(shí)現(xiàn)”做了隔離。Agent層只負(fù)責(zé)調(diào)度——決定下一步調(diào)哪個(gè)工具、怎么處理工具的返回結(jié)果而具體的工具實(shí)現(xiàn)放在tools目錄比如SQL執(zhí)行器、元數(shù)據(jù)查詢器。這樣后續(xù)加一個(gè)新工具不需要改Agent的主邏輯只要在skills里注冊一下就行擴(kuò)展性很好。2.3 配置管理與環(huán)境變量Agent項(xiàng)目里有大量需要外部注入的配置項(xiàng)比如大模型的API密鑰、數(shù)據(jù)庫連接字符串、向量庫地址、Redis地址。我強(qiáng)烈建議所有配置走環(huán)境變量并且用一個(gè)config.py統(tǒng)一讀取和管理。我是用pydantic-settings來做這件事的它最大的好處是能在啟動(dòng)時(shí)做類型檢查和必填校驗(yàn)避免密鑰或地址配錯(cuò)時(shí)到了使用環(huán)節(jié)才報(bào)錯(cuò)。# app/config.py from functools import lru_cache from pydantic_settings import BaseSettings, SettingsConfigDict class Settings(BaseSettings): model_config SettingsConfigDict( env_file.env, env_file_encodingutf-8, extraignore ) # 大模型配置 LLM_MODEL: str gpt-4o-mini LLM_API_BASE: str LLM_API_KEY: str LLM_TEMPERATURE: float 0.1 LLM_MAX_TOKENS: int 4096 LLM_TIMEOUT: int 60 # Embedding配置 EMBEDDING_MODEL: str text-embedding-3-small EMBEDDING_API_BASE: str EMBEDDING_API_KEY: str # 業(yè)務(wù)數(shù)據(jù)庫配置 DB_HOST: str localhost DB_PORT: int 5432 DB_USER: str postgres DB_PASSWORD: str DB_NAME: str business_db DB_POOL_SIZE: int 10 # 向量庫配置 QDRANT_HOST: str localhost QDRANT_PORT: int 6333 QDRANT_COLLECTION: str db_metadata # Redis配置 REDIS_HOST: str localhost REDIS_PORT: int 6379 REDIS_DB: int 0 REDIS_PASSWORD: str # 服務(wù)配置 API_HOST: str 0.0.0.0 API_PORT: int 8000 lru_cache def get_settings(): return Settings()注意兩個(gè)細(xì)節(jié)。第一LLM_TEMPERATURE我默認(rèn)調(diào)到0.1問數(shù)場景需要的是準(zhǔn)確不是創(chuàng)意溫度越高SQL寫錯(cuò)的概率越大。第二用lru_cache裝飾get_settings確保整個(gè)應(yīng)用生命周期里配置只加載一次避免反復(fù)讀取.env文件浪費(fèi)IO。對應(yīng)的.env.example模板是這樣LLM_MODELgpt-4o-mini LLM_API_BASEhttps://your-llm-endpoint.example.com/v1 LLM_API_KEYsk-your-key-here DB_HOSTlocalhost DB_PASSWORDchange-me QDRANT_HOSTlocalhost REDIS_HOSTlocalhost.env文件絕對不能提交到Git倉庫這條要寫進(jìn).gitignore一旦密鑰泄露到代碼倉庫后續(xù)換密鑰的成本比任何人想象的都高。2.4 日志與調(diào)試設(shè)施基礎(chǔ)設(shè)施階段必須把日志系統(tǒng)鋪好否則等到Agent跑起來之后LLM的輸入輸出、工具的調(diào)用鏈、SQL的執(zhí)行情況全都沒有記錄出了問題你根本不知道是哪個(gè)環(huán)節(jié)掛了全靠猜是非常痛苦的。我之前用Python自帶的logging后來換成loguru它的使用體驗(yàn)更順手配置簡單日志格式也更直觀。我的做法是按天切分日志文件并同時(shí)輸出到控制臺(tái)和文件方便開發(fā)時(shí)實(shí)時(shí)看和事后排查。# app/utils/logger.py import sys from loguru import logger logger.remove() logger.add( sys.stdout, levelINFO, formatgreen{time:YYYY-MM-DD HH:mm:ss}/green | level{level: 8}/level | cyan{name}/cyan:cyan{line}/cyan - level{message}/level ) logger.add( logs/agent_{time:YYYY-MM-DD}.log, levelDEBUG, rotation00:00, retention30 days, encodingutf-8, enqueueTrue, format{time:YYYY-MM-DD HH:mm:ss} | {level: 8} | {name}:{line} | {message} ) core_logger logger這里retention設(shè)30天保證能追蹤一個(gè)月內(nèi)的問題軌跡。enqueueTrue是讓日志寫入走異步隊(duì)列避免在高并發(fā)環(huán)境下日志I/O阻塞主業(yè)務(wù)邏輯。3. 大模型接入層搭建3.1 統(tǒng)一走OpenAI兼容協(xié)議問數(shù)Agent的大模型接入有一個(gè)很關(guān)鍵的決策不要綁死某一家廠商的SDK。現(xiàn)在各家大模型廠商都提供了OpenAI兼容的接口格式這意味著你可以用同一個(gè)OpenAI客戶端庫去對接幾乎所有主流模型服務(wù)包括各類國產(chǎn)模型、開源模型的私有化部署服務(wù)。實(shí)際做法是在配置里指定LLM_API_BASE指向?qū)?yīng)廠商的地址然后統(tǒng)一使用langchain-openai提供的ChatOpenAI類來實(shí)例化模型。這個(gè)做法的好處是后續(xù)換模型時(shí)只改配置不改代碼對模型做A/B對比測試時(shí)更省事。# app/agent/llm.py from langchain_openai import ChatOpenAI from functools import lru_cache from app.config import get_settings DEFAULT_SYSTEM_PROMPT 你是一名數(shù)據(jù)分析助手負(fù)責(zé)根據(jù)用戶的問題編寫并執(zhí)行SQL查詢來回答業(yè)務(wù)問題。請遵循以下原則 1. 只使用提供的數(shù)據(jù)庫表結(jié)構(gòu)信息不要臆測不存在的字段。 2. SQL查詢結(jié)果為空時(shí)如實(shí)告知用戶不要編造數(shù)據(jù)。 3. 涉及金額時(shí)保留兩位小數(shù)。 4. 嚴(yán)格按照工具返回的結(jié)果組織回答。 lru_cache def get_llm(): settings get_settings() return ChatOpenAI( modelsettings.LLM_MODEL, api_keysettings.LLM_API_KEY, base_urlsettings.LLM_API_BASE, temperaturesettings.LLM_TEMPERATURE, max_tokenssettings.LLM_MAX_TOKENS, timeoutsettings.LLM_TIMEOUT, max_retries2, )3.2 密鑰管理與安全邊界模型密鑰的安全級別和數(shù)據(jù)庫密碼是同一個(gè)等級這是基礎(chǔ)設(shè)施階段最容易忽視的問題。我見過不止一個(gè)團(tuán)隊(duì)把API密鑰直接寫在代碼里甚至提交到Git倉庫結(jié)果被掃描工具掃出來之后只能緊急輪換密鑰。我的建議是至少做到三點(diǎn)。第一密鑰只存在于.env文件且.env不入庫倉庫里只保留.env.example。第二團(tuán)隊(duì)內(nèi)部用環(huán)境變量注入的方式分發(fā)密鑰不要通過聊天工具傳明文。第三后端服務(wù)調(diào)用模型前端瀏覽器永遠(yuǎn)接觸不到模型密鑰。如果你的Agent對外提供服務(wù)一定不要做成前端直連大模型API的架構(gòu)中間必須隔一層后端代理否則密鑰會(huì)在瀏覽器開發(fā)者工具里暴露無遺。3.3 模型調(diào)用的可靠性設(shè)計(jì)大模型API在生產(chǎn)環(huán)境里并不像本地跑demo那么穩(wěn)定超時(shí)、限流、網(wǎng)絡(luò)抖動(dòng)都是常態(tài)。問數(shù)項(xiàng)目中模型調(diào)用是鏈路最上層的環(huán)節(jié)一旦模型接口超時(shí)或返回異常下游SQL執(zhí)行和結(jié)果展示全都跟著失敗所以必須在接入層就把可靠性機(jī)制做扎實(shí)。第一件要做的是超時(shí)控制。ChatOpenAI的timeout參數(shù)一定要設(shè)我之前用的默認(rèn)值經(jīng)常在模型服務(wù)負(fù)載高時(shí)把請求掛到兩分鐘以上用戶那邊早就等得不耐煩了。目前我這邊設(shè)置60秒對普通非流式請求來說60秒足夠如果超過這個(gè)時(shí)間基本可以判定模型服務(wù)異常繼續(xù)等待沒有意義。第二件是重試機(jī)制。max_retries設(shè)2次配合OpenAI客戶端的內(nèi)置重試邏輯可以在請求失敗時(shí)自動(dòng)重試避免因?yàn)榕及l(fā)的網(wǎng)絡(luò)問題直接返回錯(cuò)誤給用戶。第三件是請求日志。每次模型調(diào)用的入?yún)⒑统鰠⒍家涗浀@里有個(gè)安全提醒日志里不要記錄完整的API Key同時(shí)考慮是否需要對SQL查詢結(jié)果做脫敏這取決于你的數(shù)據(jù)敏感程度。從問數(shù)項(xiàng)目長遠(yuǎn)來看這個(gè)數(shù)據(jù)權(quán)限問題會(huì)在后文中詳細(xì)展開基礎(chǔ)設(shè)施階段先留好日志擴(kuò)展位即可。3.4 Embedding模型與向量化準(zhǔn)備除對話模型外基礎(chǔ)設(shè)施階段還要把Embedding模型接入好。問數(shù)Agent在做表結(jié)構(gòu)召回時(shí)需要把用戶的問題和表的描述信息都轉(zhuǎn)成向量然后在向量庫里做相似度檢索這就要用到Embedding模型。Embedding模型的接入方式和對話模型類似用langchain-openai里的OpenAIEmbeddings# app/vector/embedding.py from langchain_openai import OpenAIEmbeddings from functools import lru_cache from app.config import get_settings lru_cache def get_embeddings(): settings get_settings() return OpenAIEmbeddings( modelsettings.EMBEDDING_MODEL, api_keysettings.EMBEDDING_API_KEY, base_urlsettings.EMBEDDING_API_BASE, timeout30, max_retries2, )Embedding模型的選擇有幾個(gè)考慮維度。第一是維度大小常見的有1536維也有1024或768維的維度越高精度通常越好但存儲(chǔ)和計(jì)算成本也越高。第二是中文效果一定要拿實(shí)際表結(jié)構(gòu)描述去做評測不同模型在中文業(yè)務(wù)文本上的效果差異可能超出你的預(yù)期。第三是調(diào)用成本Embedding是批量調(diào)用的元數(shù)據(jù)初始化時(shí)要對大量文本做向量化量大的時(shí)候成本不可忽略選型時(shí)要算清楚賬。4. 數(shù)據(jù)層與向量檢索設(shè)施搭建4.1 業(yè)務(wù)數(shù)據(jù)庫連接管理問數(shù)項(xiàng)目的核心操作對象就是業(yè)務(wù)數(shù)據(jù)庫這層的連接管理質(zhì)量直接決定了Agent查詢數(shù)據(jù)的穩(wěn)定性和速度。PostgreSQL是我最常用的選擇在復(fù)雜SQL支持、JSON處理、擴(kuò)展生態(tài)方面都很成熟用它存業(yè)務(wù)數(shù)據(jù)非常穩(wěn)妥。SQLAlchemy是Python里最主流的數(shù)據(jù)訪問層它提供了連接池管理、ORM映射、SQL表達(dá)式語言等能力。在Agent場景下我們既要執(zhí)行動(dòng)態(tài)生成的SQL也需要ORM層來做一些配置管理和元數(shù)據(jù)記錄兩者不沖突。# app/services/database.py from sqlalchemy import create_engine, text from sqlalchemy.pool import QueuePool from contextlib import contextmanager from functools import lru_cache from app.config import get_settings lru_cache def get_engine(): settings get_settings() db_url ( fpostgresqlpsycopg://{settings.DB_USER}:{settings.DB_PASSWORD} f{settings.DB_HOST}:{settings.DB_PORT}/{settings.DB_NAME} ) return create_engine( db_url, poolclassQueuePool, pool_sizesettings.DB_POOL_SIZE, max_overflow5, pool_pre_pingTrue, pool_recycle1800, ) contextmanager def get_db_connection(): engine get_engine() conn engine.connect() try: yield conn finally: conn.close() def execute_sql(sql: str): 執(zhí)行只讀查詢返回結(jié)果集 with get_db_connection() as conn: result conn.execute(text(sql)) columns list(result.keys()) rows [dict(zip(columns, row)) for row in result.fetchall()] return {columns: columns, rows: rows, row_count: len(rows)}幾個(gè)關(guān)鍵參數(shù)我要重點(diǎn)解釋一下。pool_pre_pingTrue是在每次從連接池取連接之前先發(fā)送一個(gè)ping信號檢測連接是否存活避免數(shù)據(jù)庫端連接因?yàn)榭臻e太久被斷開拿到一個(gè)壞連接導(dǎo)致查詢報(bào)錯(cuò)。pool_recycle1800表示連接最多存活30分鐘就要回收重建防止數(shù)據(jù)庫端主動(dòng)斷連造成的“connection already closed”錯(cuò)誤。max_overflow5意味著連接池在繁忙時(shí)最多可以額外創(chuàng)建5個(gè)臨時(shí)連接超過這個(gè)數(shù)就排隊(duì)等待——問數(shù)場景不需要盲目的高并發(fā)限制連接數(shù)反而是對數(shù)據(jù)庫的一種保護(hù)。4.2 只讀賬號與權(quán)限的最小化設(shè)計(jì)這件事我必須放在數(shù)據(jù)庫連接這一節(jié)里重點(diǎn)強(qiáng)調(diào)問數(shù)Agent連數(shù)據(jù)庫絕對不能使用業(yè)務(wù)系統(tǒng)管理員的賬號。原因很簡單Agent再智能本質(zhì)上是代碼在執(zhí)行SQL代碼一旦出現(xiàn)邏輯漏洞或者被提示詞注入攻擊就可能執(zhí)行出刪表、改數(shù)據(jù)這類破壞性操作。我在項(xiàng)目里單獨(dú)創(chuàng)建了一個(gè)只讀賬號CREATE USER agent_readonly WITH PASSWORD strong-password; GRANT CONNECT ON DATABASE business_db TO agent_readonly; GRANT USAGE ON SCHEMA public TO agent_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_readonly; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO agent_readonly;ALTER DEFAULT PRIVILEGES這一行很多人容易忽略。它保證了后續(xù)新建的表默認(rèn)給只讀賬號授予SELECT權(quán)限否則表建好后Agent又查不了排查半天才發(fā)現(xiàn)是權(quán)限問題。除了數(shù)據(jù)庫側(cè)應(yīng)用側(cè)也要做一個(gè)兜底防線。SQL執(zhí)行器里檢查SQL語句強(qiáng)制執(zhí)行語句前判斷第一條非注釋語句的動(dòng)詞必須是SELECT、WITH、SHOW、EXPLAIN這些只讀操作其他的直接拒絕執(zhí)行。雖然模型生成的SQL絕大多數(shù)情況不會(huì)寫DELETE但安全邊界永遠(yuǎn)要相信自己寫的代碼不要相信外部模型的輸出。4.3 表結(jié)構(gòu)元數(shù)據(jù)提取與加工問數(shù)Agent要寫好SQL前提是它得知道數(shù)據(jù)庫里有哪些表、每張表有哪些字段、字段的業(yè)務(wù)含義是什么。這些信息就是數(shù)據(jù)庫的“元數(shù)據(jù)”。元數(shù)據(jù)可以從PostgreSQL的系統(tǒng)目錄直接查詢SELECT t.table_name, c.column_name, c.data_type, c.is_nullable FROM information_schema.tables t JOIN information_schema.columns c ON t.table_name c.table_name WHERE t.table_schema public AND t.table_type BASE TABLE ORDER BY t.table_name, c.ordinal_position;但只靠系統(tǒng)目錄還不夠。系統(tǒng)目錄里的表和字段名往往是英文縮寫或者技術(shù)命名比如cst_amt模型根本猜不出這是“客戶金額”的意思。所以我額外做了一個(gè)“字段注釋”的加工環(huán)節(jié)把業(yè)務(wù)注釋寫入PostgreSQL的COMMENT里COMMENT ON TABLE sales_order IS 銷售訂單表每行代表一條客戶訂單記錄; COMMENT ON COLUMN sales_order.cst_amt IS 客戶訂單總金額元含稅; COMMENT ON COLUMN sales_order.order_status IS 訂單狀態(tài)0-草稿1-已提交2-已發(fā)貨3-已完成4-已取消;這些COMMENT信息同樣可以從系統(tǒng)目錄讀出來我們在做元數(shù)據(jù)時(shí)要把“表名字段名字段類型業(yè)務(wù)注釋”組合成一段完整描述文本后續(xù)它有兩個(gè)用途一是直接作為提示詞上下文喂給大模型幫助它理解表結(jié)構(gòu)二是做向量化后存入向量庫用于檢索召回。4.4 向量數(shù)據(jù)庫的初始化與集合管理Qdrant的初始化非常輕量本地用Docker啟動(dòng)一個(gè)單節(jié)點(diǎn)就夠開發(fā)調(diào)試了docker run -d --name qdrant \ -p 6333:6333 -p 6334:6334 \ -v $(pwd)/qdrant_storage:/qdrant/storage \ qdrant/qdrant:v1.9.7注意6334端口是gRPC接口生產(chǎn)環(huán)境建議用內(nèi)部網(wǎng)絡(luò)通gRPC提升性能開發(fā)階段用6333的HTTP接口就夠。集合的創(chuàng)建考慮兩個(gè)核心參數(shù)向量維度和距離度量方式。向量維度必須和你選的Embedding模型輸出維度一致比如text-embedding-3-small是1536維如果后續(xù)換模型向量維度變了舊集合的數(shù)據(jù)就完全失效了。距離度量我用Cosine尤其在文本相似度場景下Cosine比Dot Product更直觀穩(wěn)定對向量的模長不敏感適合描述文本語義的接近程度。# scripts/init_qdrant.py from qdrant_client import QdrantClient from qdrant_client.http import models as qdrant_models client QdrantClient(hostlocalhost, port6333) client.recreate_collection( collection_namedb_metadata, vectors_configqdrant_models.VectorParams( size1536, distanceqdrant_models.Distance.COSINE, ), ) print(collection created)在采樣數(shù)據(jù)上我再多提一句。問數(shù)Agent的召回策略里表結(jié)構(gòu)文本做向量化后存入向量庫而表名和字段名可以同時(shí)做關(guān)鍵詞過濾或全文匹配。在實(shí)際使用時(shí)兩者結(jié)合的效果比單用向量好很多因?yàn)楸砻恼Z義往往是精準(zhǔn)匹配更可靠。向量檢索負(fù)責(zé)語義接近性關(guān)鍵詞匹配負(fù)責(zé)精確對應(yīng)這個(gè)雙通道策略在第五章還會(huì)展開。5. 智能體運(yùn)行框架搭建5.1 Agent框架選型LangChain還是LlamaIndex問數(shù)項(xiàng)目里關(guān)于框架的選型我的結(jié)論是主Agent編排用LangChain數(shù)據(jù)處理和檢索部分參考LlamaIndex的設(shè)計(jì)思路但不直接引入整個(gè)LlamaIndex。為什么不用LlamaIndex做主線LlamaIndex在文檔問答、知識庫RAG場景下有巨大優(yōu)勢尤其是數(shù)據(jù)索引和數(shù)據(jù)加載器的生態(tài)非常完善。但問數(shù)項(xiàng)目的核心是Text-to-SQL加上動(dòng)態(tài)工具調(diào)用LangChain在這塊的抽象更成熟AgentExecutor和工具裝飾器用起來更順手社區(qū)案例也更多。為什么不完全手寫如果你只是調(diào)一個(gè)模型、連一個(gè)數(shù)據(jù)庫手寫沒問題。但問數(shù)Agent后續(xù)要加記憶、加多工具協(xié)同、加復(fù)雜的編排邏輯LangChain提供了這些組件的基礎(chǔ)抽象把Web搜索、API調(diào)用、代碼執(zhí)行等工具接入標(biāo)準(zhǔn)化省掉了重復(fù)造輪子的時(shí)間。5.2 工具注冊與技能機(jī)制這一節(jié)是整個(gè)Agent基礎(chǔ)設(shè)施里最核心的部分對應(yīng)目前很多團(tuán)隊(duì)在實(shí)踐的“Agent Skill”機(jī)制。我的工具注冊設(shè)計(jì)很簡單用裝飾器把函數(shù)注冊到工具中心注冊時(shí)附帶名稱、描述、參數(shù)SchemaAgent運(yùn)行時(shí)通過讀取注冊中心來決定調(diào)用哪個(gè)工具。# app/tools/registry.py from typing import Callable, Dict, Any from pydantic import BaseModel, create_model class ToolSpec(BaseModel): name: str description: str args_schema: Any func: Callable _tool_registry: Dict[str, ToolSpec] {} def register_tool(name: str, description: str, args_schema: type[BaseModel]): def decorator(func): _tool_registry[name] ToolSpec( namename, descriptiondescription, args_schemaargs_schema, funcfunc, ) return func return decorator def get_all_tools(): return list(_tool_registry.values())工具描述文本的寫法對Agent的效果影響比想象中大得多。描述里要寫清楚這個(gè)工具是做什么的、在什么條件下使用、參數(shù)怎么填、有什么限制。大模型是靠描述來決定調(diào)用哪個(gè)工具的描述寫得含糊它就會(huì)在你預(yù)期的工具之外瞎猜。這個(gè)設(shè)計(jì)最大的好處是模塊解耦。每加一個(gè)新的數(shù)據(jù)查詢能力比如查ERP系統(tǒng)的接口、查報(bào)表平臺(tái)的API只要實(shí)現(xiàn)一個(gè)函數(shù)并注冊Agent的編排邏輯完全不需要變。后面想加權(quán)限校驗(yàn)、審計(jì)日志也只需要在注冊中心統(tǒng)一包一層不需要改動(dòng)每個(gè)工具的內(nèi)部實(shí)現(xiàn)。5.3 SQL執(zhí)行工具的實(shí)現(xiàn)有了注冊機(jī)制接下來實(shí)現(xiàn)問數(shù)項(xiàng)目里最核心的工具SQL執(zhí)行器。它要接收大模型生成的SQL執(zhí)行查詢并返回結(jié)果。但這里有一個(gè)真實(shí)的工程問題是大模型生成的SQL很可能有語法錯(cuò)誤也可能踩到數(shù)據(jù)庫不支持的語法。# app/tools/sql_executor.py from pydantic import BaseModel, Field from app.tools.registry import register_tool from app.services.database import execute_sql from app.utils.logger import core_logger class SQLExecuteArgs(BaseModel): sql: str Field(description要執(zhí)行的SQL查詢語句必須是SELECT只讀查詢) register_tool(sql_executor, 執(zhí)行只讀SQL查詢語句返回查詢結(jié)果, SQLExecuteArgs) def sql_execute(sql: str): core_logger.info(f[SQL Executor] executing: {sql}) # 安全檢查只允許以SELECT開頭的語句 stripped sql.lstrip().lstrip(().strip().lower() if not stripped.startswith((select, with, show, explain)): return {error: 僅允許執(zhí)行只讀查詢SELECT/WITH/SHOW/EXPLAIN} try: result execute_sql(sql) core_logger.info(f[SQL Executor] rows returned: {result[row_count]}) return result except Exception as e: core_logger.error(f[SQL Executor] error: {e}) return {error: str(e)}工具的返回格式很重要。不要把數(shù)據(jù)庫原始結(jié)果直接扔給模型而是要做結(jié)構(gòu)化的封裝。模型拿到結(jié)果后還需要判斷是否滿足用戶的原始問題如果不滿足可能要調(diào)整SQL重查。所以返回結(jié)果最好加上列名、行數(shù)、以及前N行數(shù)據(jù)。數(shù)據(jù)量大時(shí)還得做截?cái)噙@個(gè)后面會(huì)詳細(xì)講。5.4 元數(shù)據(jù)召回工具的實(shí)現(xiàn)問數(shù)Agent使用元數(shù)據(jù)工具的方式和人類分析師很相似。人分析數(shù)據(jù)之前得先看有哪些表、哪些字段Agent也是一樣——先查到可用的表結(jié)構(gòu)把它作為提示詞的上下文才能進(jìn)入SQL生成階段。元數(shù)據(jù)工具有兩條獲取路徑。一條是精準(zhǔn)路徑根據(jù)用戶問題中出現(xiàn)的表名直接查系統(tǒng)目錄拿表結(jié)構(gòu)另一條是模糊路徑把用戶問題做向量化在Qdrant里做相似度檢索把最相關(guān)的表描述召回出來。# app/tools/db_metadata.py from pydantic import BaseModel, Field from app.tools.registry import register_tool from app.services.metadata import get_table_schema class SearchSchemaArgs(BaseModel): keywords: str Field(description表名或字段名的關(guān)鍵詞) register_tool(search_table_schema, 搜索業(yè)務(wù)數(shù)據(jù)庫中與關(guān)鍵詞相關(guān)的表和字段結(jié)構(gòu), SearchSchemaArgs) def search_table_schema(keywords: str): return get_table_schema(keywords)在實(shí)際項(xiàng)目中精準(zhǔn)路徑和模糊路徑建議都實(shí)現(xiàn)。精準(zhǔn)路徑用來快速定位——當(dāng)用戶提到“訂單表”時(shí)直接拿到sales_order的結(jié)構(gòu)模糊路徑用來兜底——用戶用“客戶買了多少錢”這種口語化描述時(shí)通過向量檢索找到cst_amt字段?；A(chǔ)階段先把兩條路徑都留好具體調(diào)參在后續(xù)的業(yè)務(wù)邏輯章節(jié)里繼續(xù)做。5.5 主Agent運(yùn)行時(shí)封裝最后把模型、工具、記憶、提示詞粘合在一起的就是主Agent本體。我用LangChain的create_react_agent來構(gòu)建。ReAct模式的核心思想是讓模型在“思考”和“行動(dòng)”之間循環(huán)思考當(dāng)前需要什么信息、決定調(diào)用哪個(gè)工具、觀察工具的返回結(jié)果、繼續(xù)思考下一步直到有足夠信息回答用戶。這種模式非常適合問數(shù)場景因?yàn)橐卮稹坝唵谓痤~最大的客戶是誰”模型需要調(diào)用元數(shù)據(jù)工具看表結(jié)構(gòu)、調(diào)用SQL執(zhí)行器查數(shù)據(jù)這中間至少要兩個(gè)步驟。# app/agent/agent.py from langchain.agents import create_react_agent, AgentExecutor from langchain_core.prompts import PromptTemplate from langchain_core.tools import StructuredTool from app.agent.llm import get_llm, DEFAULT_SYSTEM_PROMPT from app.tools.registry import get_all_tools def build_agent(): llm get_llm() tools [] for spec in get_all_tools(): tools.append(StructuredTool.from_function( funcspec.func, namespec.name, descriptionspec.description, args_schemaspec.args_schema, )) prompt PromptTemplate.from_template(DEFAULT_SYSTEM_PROMPT) agent create_react_agent( llmllm, toolstools, promptprompt, stop_sequenceTrue, ) executor AgentExecutor( agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue, max_iterations5, return_intermediate_stepsTrue, ) return executormax_iterations5是很重要的參數(shù)。它限制Agent最多只能思考和行動(dòng)5輪超過就直接返回避免大模型陷入無限循環(huán)、反復(fù)調(diào)用工具停不下來。真實(shí)項(xiàng)目里一次查詢很少超過4輪如果超過了往往是提示詞或工具描述出了問題排查的時(shí)候優(yōu)先看中間步驟的日志基本能定位到是哪一步的意圖沒被識別對。6. 服務(wù)化與工程化配套搭建6.1 FastAPI封裝Agent服務(wù)Agent內(nèi)核搭好了還需要把它封裝成服務(wù)才能讓前端頁面或者同事的客戶端調(diào)用。FastAPI在這層做得非常舒服類型提示天然支持、OpenAPI文檔自動(dòng)生成、異步性能也足夠。# app/main.py from fastapi import FastAPI from pydantic import BaseModel from app.agent.agent import build_agent app FastAPI(titleLCODER問數(shù)智能體) class QueryRequest(BaseModel): question: str session_id: str history: list[dict] [] class QueryResponse(BaseModel): answer: str sql: str data: dict {} intermediate_steps: list [] agent_executor build_agent() app.post(/api/query, response_modelQueryResponse) async def query(req: QueryRequest): # 將結(jié)構(gòu)化參數(shù)包裝成給Agent的輸入 result await asyncio.to_thread( agent_executor.invoke, {input: req.question} ) return QueryResponse( answerresult[output], intermediate_stepsresult.get(intermediate_steps, []) )這里有一個(gè)要點(diǎn)AgentExecutor的invoke方法是同步阻塞的直接放進(jìn)FastAPI的async函數(shù)里會(huì)阻塞事件循環(huán)導(dǎo)致其他請求排隊(duì)。用asyncio.to_thread把同步調(diào)用丟到線程池里執(zhí)行不阻塞主事件循環(huán)實(shí)測在普通服務(wù)器上的并發(fā)能力就夠用了。6.2 Redis緩存與輕量會(huì)話管理如果每次請求都重新走一次建模-推理-SQL生成的完整流程不僅慢而且模型成本會(huì)高得驚人。對于一些高頻的、相似的查詢可以加一層緩存。Redis在這里充當(dāng)兩個(gè)角色。第一是查詢結(jié)果緩存把問題做規(guī)范化處理后作為key第一次查詢把結(jié)果寫入Redis并設(shè)置過期時(shí)間后續(xù)相同問題直接命中。第二是會(huì)話上下文緩存存儲(chǔ)Agent和用戶的對話記錄支持多輪問答的場景。比如按用戶question的哈希值做緩存import hashlib import json from redis import Redis from app.config import get_settings settings get_settings() redis_client Redis( hostsettings.REDIS_HOST, portsettings.REDIS_PORT, dbsettings.REDIS_DB, decode_responsesTrue, ) def get_cache_key(question: str) - str: digest hashlib.md5(question.strip().lower().encode()).hexdigest() return fagent:query:{digest} def set_query_cache(question: str, answer: dict, expire_seconds: int 3600): key get_cache_key(question) redis_client.setex(key, expire_seconds, json.dumps(answer, ensure_asciiFalse)) def get_query_cache(question: str): key get_cache_key(question) cached redis_client.get(key) return json.loads(cached) if cached else None緩存粒度是值得斟酌的。如果整個(gè)SQL查詢結(jié)果都緩存數(shù)據(jù)變化后緩存會(huì)過期不準(zhǔn)如果只緩存SQL生成結(jié)果每次執(zhí)行SQL才能拿最新數(shù)據(jù)但大模型調(diào)用省了。折中方案是緩存的過期時(shí)間根據(jù)業(yè)務(wù)數(shù)據(jù)新鮮度來調(diào)整對實(shí)時(shí)性要求高的報(bào)表類型直接跳過緩存。這一塊屬于業(yè)務(wù)策略的范疇基礎(chǔ)設(shè)施階段先把緩存的通道打通后面按需調(diào)整就行。6.3 全鏈路可觀測與排查輔助Agent項(xiàng)目的調(diào)試難度比普通Web服務(wù)高一截關(guān)鍵在于鏈路太長用戶請求先進(jìn)FastAPI然后進(jìn)AgentExecutor再到大模型API模型返回后可能調(diào)元數(shù)據(jù)工具、再調(diào)SQL執(zhí)行器最后拼接答案返回。任何一個(gè)環(huán)節(jié)出錯(cuò)表現(xiàn)在用戶端的都只是“回答不對”或“超時(shí)”。所以基礎(chǔ)設(shè)施階段必須把可觀測性搭好。不只是日志而是要把一次請求的關(guān)鍵節(jié)點(diǎn)串聯(lián)起來。我目前的方案是在每個(gè)工具調(diào)用和模型調(diào)用前后打點(diǎn)import time import uuid from loguru import logger from contextvars import ContextVar request_id_var: ContextVar[str] ContextVar(request_id, default-) def log_with_context(message: str, **kwargs): rid request_id_var.get() logger.info(f[{rid}] {message}, **kwargs) def track_execution(func, name: str): def wrapper(*args, **kwargs): start time.monotonic() log_with_context(f{name} start, argsargs) try: result func(*args, **kwargs) elapsed time.monotonic() - start log_with_context(f{name} end, elapsed_msround(elapsed * 1000, 2)) return result except Exception as e: elapsed time.monotonic() - start log_with_context(f{name} error, elapsed_msround(elapsed * 1000, 2), errorstr(e)) raise return wrapper在FastAPI入口為每個(gè)請求生成一個(gè)request_id通過ContextVar貫穿整個(gè)請求生命周期。這樣排查問題時(shí)只需要用一個(gè)request_id把日志文件里所有相關(guān)記錄撈出來就能還原一次完整調(diào)用鏈效率比沒有request_id時(shí)大海撈針高得多。7. 常見問題與排查技巧實(shí)錄7.1 依賴沖突與版本地獄LangChain生態(tài)的版本更新速度非?？觳煌蟀姹局gAPI可能完全不兼容。我遇到的典型問題是項(xiàng)目里裝了一個(gè)依賴庫它依賴的是舊版langchain-core結(jié)果跟新裝langchain-openai的版本沖突程序啟動(dòng)時(shí)報(bào)出一堆ABC簽名錯(cuò)誤。排查這類問題我的建議是按這幾個(gè)步驟來第一啟動(dòng)時(shí)如果報(bào)錯(cuò)先別急著搜索報(bào)錯(cuò)信息檢查itsdangerous的提示里有沒有“conflict with”或者“requires a different version”的字樣第二用pip list或uv pip list確認(rèn)當(dāng)前環(huán)境里langchain相關(guān)包的版本號第三鎖定一個(gè)“全家桶版本組合”比如langchain 0.3.x配langchain-openai 0.2.x配langchain-community 0.3.x不要一個(gè)最新一個(gè)舊版混著裝。還有一個(gè)小技巧uv的lock文件把版本精確鎖定到commit級別團(tuán)隊(duì)協(xié)作時(shí)大家同步的是完全一致的環(huán)境。你自己調(diào)試時(shí)如果用pip自由裝很容易在“我這邊能跑啊”和“為什么我這邊跑不了”之間反復(fù)橫跳。一旦基礎(chǔ)設(shè)施階段鎖好版本后面的各種集成問題會(huì)少非常多。7.2 數(shù)據(jù)庫連接池被打滿開發(fā)調(diào)試階段可能沒啥感覺一旦服務(wù)同時(shí)處理多個(gè)會(huì)話數(shù)據(jù)庫連接池很容易被打滿報(bào)錯(cuò)通常是“connection pool exhausted”或者“timeout waiting for connection”。這里要注意一個(gè)LangChain的隱藏行為默認(rèn)情況下AgentExecutor每執(zhí)行一步工具調(diào)用都會(huì)新建一個(gè)連接如果連接池沒關(guān)好工具多輪調(diào)用就會(huì)把連接池耗盡。解決辦法是確保execute_sql使用同一個(gè)engine connection池engine用lru_cache緩存工具執(zhí)行完連接正常釋放回到池里。還有一個(gè)排查姿勢查看數(shù)據(jù)庫端的pg_stat_activity表看是不是有大量idle in transaction狀態(tài)的連接堆積。如果有多半是事務(wù)沒有正常提交或回滾。檢查代碼里有沒有把數(shù)據(jù)寫入和讀取操作混在同一個(gè)長事務(wù)里問數(shù)Agent只做讀操作事務(wù)越短越好。SELECT pid, state, state_change, query_start, left(query, 80) AS query FROM pg_stat_activity WHERE datname business_db ORDER BY query_start;7.3 模型生成的SQL質(zhì)量不穩(wěn)定SQL生成質(zhì)量是最讓人頭疼也最需要長期迭代的問題。基礎(chǔ)設(shè)施階段能做的準(zhǔn)備是預(yù)設(shè)好錯(cuò)誤反饋機(jī)制一旦SQL執(zhí)行報(bào)錯(cuò)把報(bào)錯(cuò)信息返回給模型讓它根據(jù)報(bào)錯(cuò)信息修正SQL重寫。Agent工具的返回本身就是模型下一步?jīng)Q策的輸入所以SQL執(zhí)行器返回的錯(cuò)誤信息要足夠詳細(xì)。PostgreSQL的報(bào)錯(cuò)信息對程序不太友好但對大模型其實(shí)是很好的修正信號——比如“column sales_order.cst_amt does not exist”這句話模型讀完就能理解自己用錯(cuò)了字段名。在此基礎(chǔ)上我還發(fā)現(xiàn)一個(gè)很有用的做法在元數(shù)據(jù)工具里把字段的枚舉值或者數(shù)據(jù)分布概要也帶上。比如訂單狀態(tài)字段如果明確告訴模型“order_status的取值是0草稿/1已提交/2已發(fā)貨/3已完成/4已取消”模型生成帶過濾條件的SQL時(shí)基本不會(huì)寫錯(cuò)。這個(gè)信息可以通過查詢字段的distinct value來獲取但注意數(shù)據(jù)量大的字段不要做全量distinct會(huì)拖慢元數(shù)據(jù)工具性能。7.4 上下文令牌超限怎么辦問數(shù)Agent的上下文里要放表結(jié)構(gòu)描述、歷史對話、工具調(diào)用結(jié)果內(nèi)容很容易超過模型的token上限。尤其是元數(shù)據(jù)召回的數(shù)量控制不好時(shí)一次性塞給模型幾十張表的描述光表結(jié)構(gòu)就把上下文撐爆了模型反而抓不住重點(diǎn)。我的經(jīng)驗(yàn)是一個(gè)查詢流程里召回的元數(shù)據(jù)控制在3到5張表以內(nèi)。召回更多時(shí)模型通常不會(huì)認(rèn)真看反而增加token消耗和推理延遲。如果確實(shí)需要跨很多表查詢先把問題拆解成子問題讓Agent分步處理而不是一次性把所有表都塞進(jìn)去。工具返回的結(jié)果集也要做截?cái)?。SQL查詢?nèi)绻祷亓藥浊袛?shù)據(jù)不能一股腦扔給大模型生成回答那會(huì)讓token瞬間爆炸。我的方案是最多返回前50行并附上“共有N行”的提示。如果模型需要更詳細(xì)的數(shù)據(jù)它可以通過追加LIMIT子句或加GROUP BY聚合來重新查詢。7.5 調(diào)試鏈路“中間步驟”是唯一真相Agent項(xiàng)目調(diào)試時(shí)最大的錯(cuò)覺就是模型回答錯(cuò)了但你看不出為什么錯(cuò)。FastAPI的接口返回里我把intermediate_steps字段也帶上了這個(gè)字段記錄的是Agent每一步的思考、調(diào)用的工具、工具的輸入輸出。排查問題的時(shí)候先看這個(gè)字段而不是猜。比如用戶問“訂單最多的前十個(gè)客戶”結(jié)果回答錯(cuò)了?？粗虚g步驟就能定位是工具沒調(diào)對比如搜索表結(jié)構(gòu)時(shí)沒有命中客戶表還是SQL寫錯(cuò)了比如沒加GROUP BY還是返回結(jié)果被截?cái)嗔?。這比讓開發(fā)人員一遍遍重放問題高效太多。我在loguru里專門對intermediate_steps做了結(jié)構(gòu)化輸出用JSON格式記錄。后續(xù)如果接入Lunary或LangSmith這類可觀測性平臺(tái)這些數(shù)據(jù)也能直接對接為模型調(diào)優(yōu)和回歸測試提供數(shù)據(jù)基礎(chǔ)。從基礎(chǔ)設(shè)施搭建的角度回顧這一階段我把工程基座、模型接入、數(shù)據(jù)設(shè)施、運(yùn)行框架、服務(wù)化與可觀測性這幾層都立住了。技術(shù)選型不一定是最新最潮的但每一層都是經(jīng)過實(shí)際項(xiàng)目和踩坑驗(yàn)證過的組合。我個(gè)人體會(huì)是基礎(chǔ)設(shè)施階段花的時(shí)間完全值得因?yàn)楹竺婷繉懸恍袠I(yè)務(wù)代碼都有穩(wěn)的地基接著而如果地基沒打好加功能的同時(shí)還得修補(bǔ)之前的破洞那種感覺才是真的折磨。下一步就可以在這個(gè)底座上填充具體的業(yè)務(wù)技能了比如問數(shù)SQL生成、結(jié)果校驗(yàn)、數(shù)據(jù)可視化這些模塊都有得聊。 企業(yè)級問數(shù)智能體基礎(chǔ)設(shè)施搭建：從零到可運(yùn)行的完整指南
1. 項(xiàng)目全景與基礎(chǔ)設(shè)施需求拆解1.1 問數(shù)智能體到底是做什么的我先把這個(gè)項(xiàng)目的定位說清楚。LCODER這個(gè)系列的第一篇講的是方案設(shè)計(jì)到了第二篇就是動(dòng)真格的時(shí)候了。所謂的“問數(shù)項(xiàng)目”準(zhǔn)確說是做一 個(gè)Text-to-SQL形態(tài)的智能體用戶用一句大白話提問比如“上個(gè)月華東區(qū)各品類的銷售額排名是什么樣的”智能體負(fù)責(zé)理解意圖、匹配到正確的表和字段、生成SQL、到數(shù)據(jù)庫里把數(shù)據(jù)查出來最后用自然語言把結(jié)果解釋給用戶聽。這句話讀起來輕飄飄的但拆開看就有很多硬骨頭自然語言怎么轉(zhuǎn)成結(jié)構(gòu)化查詢大模型幻覺導(dǎo)致SQL寫錯(cuò)怎么辦數(shù)據(jù)庫表太多召回不準(zhǔn)怎么辦查詢結(jié)果怎么判斷要不要展示給用戶……這些問題的答案恰恰都依賴一個(gè)設(shè)計(jì)合理的基礎(chǔ)設(shè)施層。你可以把基礎(chǔ)設(shè)施理解為房子的地基和管線——用戶看不見但如果沒鋪好后續(xù)每一層業(yè)務(wù)功能都會(huì)在各種莫名其妙的地方漏水。這一篇把基礎(chǔ)設(shè)施搭建講透目的在于把后續(xù)開發(fā)工作里的不確定性提前消化掉。如果你也準(zhǔn)備做一個(gè)類似的企業(yè)級問數(shù)機(jī)器人這一篇可以直接跟著復(fù)現(xiàn)如果你只是對Agent開發(fā)感興趣這些基礎(chǔ)設(shè)施選型思路和踩坑過程同樣能幫你避免“模型對話沒問題、一接數(shù)據(jù)庫就崩”的尷尬。1.2 基礎(chǔ)設(shè)施要做哪幾件事我從實(shí)際需要出發(fā)把基礎(chǔ)設(shè)施拆成四個(gè)層面這個(gè)分類也直接對應(yīng)后面的章節(jié)安排。第一層是工程基座Python環(huán)境、依賴管理、目錄結(jié)構(gòu)、配置管理、日志系統(tǒng)。這些不起眼的東西決定了團(tuán)隊(duì)協(xié)作時(shí)會(huì)不會(huì)互相踩腳也決定了代碼半年后還能不能繼續(xù)維護(hù)。第二層是模型接入層大模型API怎么統(tǒng)一封裝、密鑰怎么管理、超時(shí)重試怎么做、流式輸出怎么處理。這是所有Agent能力的“水電煤”同時(shí)也往往是團(tuán)隊(duì)最容易亂搞的一層。第三層是數(shù)據(jù)設(shè)施層業(yè)務(wù)數(shù)據(jù)庫連接、表結(jié)構(gòu)元數(shù)據(jù)的管理、向量數(shù)據(jù)庫的初始化、Embedding模型接入。問數(shù)項(xiàng)目的數(shù)據(jù)鏈路是全局最復(fù)雜的一段牽涉結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化索引的配合必須在一開始就打好底。第四層是運(yùn)行時(shí)設(shè)施核心Agent框架的初始化、工具注冊機(jī)制、對話記憶、外部服務(wù)化API以及緩存與日志追蹤。這層決定了對外的服務(wù)能力和后續(xù)迭代的效率。1.3 技術(shù)選型總覽我把整個(gè)基礎(chǔ)設(shè)施的選型方案先列出來后面的章節(jié)會(huì)逐個(gè)解釋為什么選它層級組件選型替代方案開發(fā)語言Python3.113.10也可但不建議低于3.10依賴管理uvPoetry / pip-toolsAgent框架LangChain 0.3.xLlamaIndex輕量場景可手寫Web服務(wù)FastAPIFlask / Quart業(yè)務(wù)數(shù)據(jù)庫PostgreSQL 15MySQL 8.0向量數(shù)據(jù)庫Qdrant 1.9Milvus / pgvector緩存/會(huì)話Redis 7KeyDB大模型接入OpenAI兼容協(xié)議各家原生SDK這套方案不是拍腦袋選的。比如向量庫為什么不用pgvector——如果業(yè)務(wù)庫本身有地理信息、全文檢索之外還需處理大規(guī)模向量pgvector的性能和運(yùn)維隔離感都差點(diǎn)意思Qdrant單機(jī)部署足夠輕后期需要分布式擴(kuò)展也有成熟的方案。用PostgreSQL存業(yè)務(wù)數(shù)據(jù)用Qdrant存表結(jié)構(gòu)描述和樣例數(shù)據(jù)的向量索引兩者各管一攤界限清晰。2. 工程基座與項(xiàng)目腳手架搭建2.1 Python環(huán)境與依賴管理問數(shù)智能體涉及的技術(shù)棧非常雜LangChain、數(shù)據(jù)庫驅(qū)動(dòng)、向量庫客戶端、Web框架、數(shù)據(jù)處理庫每個(gè)庫又有自己的依賴樹很容易出現(xiàn)依賴沖突。所以環(huán)境的隔離和依賴鎖定必須從第一天就做好不然后面裝一個(gè)包就崩一次環(huán)境心態(tài)會(huì)直接報(bào)廢。我用的是Python 3.11加uv。uv是目前Python生態(tài)里速度最讓人舒適的包管理器底層用Rust寫的裝依賴比pip快上好幾倍同時(shí)生成的lock文件能保證團(tuán)隊(duì)所有人的環(huán)境完全一致。如果你還在用Python 3.9或者3.10建議至少升到3.10因?yàn)門ype Hint的語法支持會(huì)舒服很多Agent代碼里大量用到類型注解老版本寫起來很憋屈。初始化項(xiàng)目的步驟很簡單# 安裝uvmacOS/Linux curl -LsSf https://astral.sh/uv/install.sh | sh # 初始化項(xiàng)目并創(chuàng)建虛擬環(huán)境 uv init lcoder-agent cd lcoder-agent uv venv --python 3.11 .venv source .venv/bin/activate # 安裝核心依賴 uv add langchain langchain-openai langchain-community uv add fastapi uvicorn[standard] pydantic-settings uv add psycopg[binary] sqlalchemy uv add qdrant-client uv add redis uv add pandas openpyxl uv add loguru注意這里我把pandas和openpyxl也加進(jìn)來了。問數(shù)Agent查完數(shù)據(jù)之后往往需要做一些聚合、排序、格式轉(zhuǎn)換再把結(jié)果渲染成表格或圖表數(shù)據(jù)pandas是這類工作的主力工具。openpyxl是為后續(xù)直接導(dǎo)出Excel報(bào)表預(yù)留的如果項(xiàng)目沒有這個(gè)需求可以去掉。2.2 項(xiàng)目目錄結(jié)構(gòu)設(shè)計(jì)基礎(chǔ)設(shè)施階段最重要的產(chǎn)出之一就是一套清晰的目錄結(jié)構(gòu)。我見過太多Agent項(xiàng)目所有代碼都塞在兩三個(gè)文件里剛開始跑demo很爽一旦要加工具、加技能、加知識庫整個(gè)項(xiàng)目就變成一團(tuán)亂麻。我這邊的目錄設(shè)計(jì)如下lcoder-agent/ ├── app/ │ ├── main.py # FastAPI入口 │ ├── config.py # 配置管理 │ ├── api/ # HTTP接口層 │ ├── agent/ # Agent核心 │ │ ├── agent.py # 主Agent封裝 │ │ ├── prompts.py # 提示詞模板 │ │ └── skills/ # 工具/技能注冊 │ ├── tools/ # 具體工具實(shí)現(xiàn) │ │ ├── sql_executor.py # SQL執(zhí)行工具 │ │ └── db_metadata.py # 元數(shù)據(jù)查詢工具 │ ├── models/ # 數(shù)據(jù)模型 │ ├── services/ # 業(yè)務(wù)服務(wù) │ ├── vector/ # 向量庫相關(guān) │ └── utils/ # 工具函數(shù) ├── data/ # 本地?cái)?shù)據(jù)文件 ├── logs/ # 日志目錄 ├── scripts/ # 初始化腳本 ├── tests/ # 測試 ├── .env.example # 環(huán)境變量模板 ├── pyproject.toml └── README.md這套結(jié)構(gòu)的關(guān)鍵在于把“Agent邏輯”和“工具實(shí)現(xiàn)”做了隔離。Agent層只負(fù)責(zé)調(diào)度——決定下一步調(diào)哪個(gè)工具、怎么處理工具的返回結(jié)果而具體的工具實(shí)現(xiàn)放在tools目錄比如SQL執(zhí)行器、元數(shù)據(jù)查詢器。這樣后續(xù)加一個(gè)新工具不需要改Agent的主邏輯只要在skills里注冊一下就行擴(kuò)展性很好。2.3 配置管理與環(huán)境變量Agent項(xiàng)目里有大量需要外部注入的配置項(xiàng)比如大模型的API密鑰、數(shù)據(jù)庫連接字符串、向量庫地址、Redis地址。我強(qiáng)烈建議所有配置走環(huán)境變量并且用一個(gè)config.py統(tǒng)一讀取和管理。我是用pydantic-settings來做這件事的它最大的好處是能在啟動(dòng)時(shí)做類型檢查和必填校驗(yàn)避免密鑰或地址配錯(cuò)時(shí)到了使用環(huán)節(jié)才報(bào)錯(cuò)。# app/config.py from functools import lru_cache from pydantic_settings import BaseSettings, SettingsConfigDict class Settings(BaseSettings): model_config SettingsConfigDict( env_file.env, env_file_encodingutf-8, extraignore ) # 大模型配置 LLM_MODEL: str gpt-4o-mini LLM_API_BASE: str LLM_API_KEY: str LLM_TEMPERATURE: float 0.1 LLM_MAX_TOKENS: int 4096 LLM_TIMEOUT: int 60 # Embedding配置 EMBEDDING_MODEL: str text-embedding-3-small EMBEDDING_API_BASE: str EMBEDDING_API_KEY: str # 業(yè)務(wù)數(shù)據(jù)庫配置 DB_HOST: str localhost DB_PORT: int 5432 DB_USER: str postgres DB_PASSWORD: str DB_NAME: str business_db DB_POOL_SIZE: int 10 # 向量庫配置 QDRANT_HOST: str localhost QDRANT_PORT: int 6333 QDRANT_COLLECTION: str db_metadata # Redis配置 REDIS_HOST: str localhost REDIS_PORT: int 6379 REDIS_DB: int 0 REDIS_PASSWORD: str # 服務(wù)配置 API_HOST: str 0.0.0.0 API_PORT: int 8000 lru_cache def get_settings(): return Settings()注意兩個(gè)細(xì)節(jié)。第一LLM_TEMPERATURE我默認(rèn)調(diào)到0.1問數(shù)場景需要的是準(zhǔn)確不是創(chuàng)意溫度越高SQL寫錯(cuò)的概率越大。第二用lru_cache裝飾get_settings確保整個(gè)應(yīng)用生命周期里配置只加載一次避免反復(fù)讀取.env文件浪費(fèi)IO。對應(yīng)的.env.example模板是這樣LLM_MODELgpt-4o-mini LLM_API_BASEhttps://your-llm-endpoint.example.com/v1 LLM_API_KEYsk-your-key-here DB_HOSTlocalhost DB_PASSWORDchange-me QDRANT_HOSTlocalhost REDIS_HOSTlocalhost.env文件絕對不能提交到Git倉庫這條要寫進(jìn).gitignore一旦密鑰泄露到代碼倉庫后續(xù)換密鑰的成本比任何人想象的都高。2.4 日志與調(diào)試設(shè)施基礎(chǔ)設(shè)施階段必須把日志系統(tǒng)鋪好否則等到Agent跑起來之后LLM的輸入輸出、工具的調(diào)用鏈、SQL的執(zhí)行情況全都沒有記錄出了問題你根本不知道是哪個(gè)環(huán)節(jié)掛了全靠猜是非常痛苦的。我之前用Python自帶的logging后來換成loguru它的使用體驗(yàn)更順手配置簡單日志格式也更直觀。我的做法是按天切分日志文件并同時(shí)輸出到控制臺(tái)和文件方便開發(fā)時(shí)實(shí)時(shí)看和事后排查。# app/utils/logger.py import sys from loguru import logger logger.remove() logger.add( sys.stdout, levelINFO, formatgreen{time:YYYY-MM-DD HH:mm:ss}/green | level{level: 8}/level | cyan{name}/cyan:cyan{line}/cyan - level{message}/level ) logger.add( logs/agent_{time:YYYY-MM-DD}.log, levelDEBUG, rotation00:00, retention30 days, encodingutf-8, enqueueTrue, format{time:YYYY-MM-DD HH:mm:ss} | {level: 8} | {name}:{line} | {message} ) core_logger logger這里retention設(shè)30天保證能追蹤一個(gè)月內(nèi)的問題軌跡。enqueueTrue是讓日志寫入走異步隊(duì)列避免在高并發(fā)環(huán)境下日志I/O阻塞主業(yè)務(wù)邏輯。3. 大模型接入層搭建3.1 統(tǒng)一走OpenAI兼容協(xié)議問數(shù)Agent的大模型接入有一個(gè)很關(guān)鍵的決策不要綁死某一家廠商的SDK。現(xiàn)在各家大模型廠商都提供了OpenAI兼容的接口格式這意味著你可以用同一個(gè)OpenAI客戶端庫去對接幾乎所有主流模型服務(wù)包括各類國產(chǎn)模型、開源模型的私有化部署服務(wù)。實(shí)際做法是在配置里指定LLM_API_BASE指向?qū)?yīng)廠商的地址然后統(tǒng)一使用langchain-openai提供的ChatOpenAI類來實(shí)例化模型。這個(gè)做法的好處是后續(xù)換模型時(shí)只改配置不改代碼對模型做A/B對比測試時(shí)更省事。# app/agent/llm.py from langchain_openai import ChatOpenAI from functools import lru_cache from app.config import get_settings DEFAULT_SYSTEM_PROMPT 你是一名數(shù)據(jù)分析助手負(fù)責(zé)根據(jù)用戶的問題編寫并執(zhí)行SQL查詢來回答業(yè)務(wù)問題。請遵循以下原則 1. 只使用提供的數(shù)據(jù)庫表結(jié)構(gòu)信息不要臆測不存在的字段。 2. SQL查詢結(jié)果為空時(shí)如實(shí)告知用戶不要編造數(shù)據(jù)。 3. 涉及金額時(shí)保留兩位小數(shù)。 4. 嚴(yán)格按照工具返回的結(jié)果組織回答。 lru_cache def get_llm(): settings get_settings() return ChatOpenAI( modelsettings.LLM_MODEL, api_keysettings.LLM_API_KEY, base_urlsettings.LLM_API_BASE, temperaturesettings.LLM_TEMPERATURE, max_tokenssettings.LLM_MAX_TOKENS, timeoutsettings.LLM_TIMEOUT, max_retries2, )3.2 密鑰管理與安全邊界模型密鑰的安全級別和數(shù)據(jù)庫密碼是同一個(gè)等級這是基礎(chǔ)設(shè)施階段最容易忽視的問題。我見過不止一個(gè)團(tuán)隊(duì)把API密鑰直接寫在代碼里甚至提交到Git倉庫結(jié)果被掃描工具掃出來之后只能緊急輪換密鑰。我的建議是至少做到三點(diǎn)。第一密鑰只存在于.env文件且.env不入庫倉庫里只保留.env.example。第二團(tuán)隊(duì)內(nèi)部用環(huán)境變量注入的方式分發(fā)密鑰不要通過聊天工具傳明文。第三后端服務(wù)調(diào)用模型前端瀏覽器永遠(yuǎn)接觸不到模型密鑰。如果你的Agent對外提供服務(wù)一定不要做成前端直連大模型API的架構(gòu)中間必須隔一層后端代理否則密鑰會(huì)在瀏覽器開發(fā)者工具里暴露無遺。3.3 模型調(diào)用的可靠性設(shè)計(jì)大模型API在生產(chǎn)環(huán)境里并不像本地跑demo那么穩(wěn)定超時(shí)、限流、網(wǎng)絡(luò)抖動(dòng)都是常態(tài)。問數(shù)項(xiàng)目中模型調(diào)用是鏈路最上層的環(huán)節(jié)一旦模型接口超時(shí)或返回異常下游SQL執(zhí)行和結(jié)果展示全都跟著失敗所以必須在接入層就把可靠性機(jī)制做扎實(shí)。第一件要做的是超時(shí)控制。ChatOpenAI的timeout參數(shù)一定要設(shè)我之前用的默認(rèn)值經(jīng)常在模型服務(wù)負(fù)載高時(shí)把請求掛到兩分鐘以上用戶那邊早就等得不耐煩了。目前我這邊設(shè)置60秒對普通非流式請求來說60秒足夠如果超過這個(gè)時(shí)間基本可以判定模型服務(wù)異常繼續(xù)等待沒有意義。第二件是重試機(jī)制。max_retries設(shè)2次配合OpenAI客戶端的內(nèi)置重試邏輯可以在請求失敗時(shí)自動(dòng)重試避免因?yàn)榕及l(fā)的網(wǎng)絡(luò)問題直接返回錯(cuò)誤給用戶。第三件是請求日志。每次模型調(diào)用的入?yún)⒑统鰠⒍家涗浀@里有個(gè)安全提醒日志里不要記錄完整的API Key同時(shí)考慮是否需要對SQL查詢結(jié)果做脫敏這取決于你的數(shù)據(jù)敏感程度。從問數(shù)項(xiàng)目長遠(yuǎn)來看這個(gè)數(shù)據(jù)權(quán)限問題會(huì)在后文中詳細(xì)展開基礎(chǔ)設(shè)施階段先留好日志擴(kuò)展位即可。3.4 Embedding模型與向量化準(zhǔn)備除對話模型外基礎(chǔ)設(shè)施階段還要把Embedding模型接入好。問數(shù)Agent在做表結(jié)構(gòu)召回時(shí)需要把用戶的問題和表的描述信息都轉(zhuǎn)成向量然后在向量庫里做相似度檢索這就要用到Embedding模型。Embedding模型的接入方式和對話模型類似用langchain-openai里的OpenAIEmbeddings# app/vector/embedding.py from langchain_openai import OpenAIEmbeddings from functools import lru_cache from app.config import get_settings lru_cache def get_embeddings(): settings get_settings() return OpenAIEmbeddings( modelsettings.EMBEDDING_MODEL, api_keysettings.EMBEDDING_API_KEY, base_urlsettings.EMBEDDING_API_BASE, timeout30, max_retries2, )Embedding模型的選擇有幾個(gè)考慮維度。第一是維度大小常見的有1536維也有1024或768維的維度越高精度通常越好但存儲(chǔ)和計(jì)算成本也越高。第二是中文效果一定要拿實(shí)際表結(jié)構(gòu)描述去做評測不同模型在中文業(yè)務(wù)文本上的效果差異可能超出你的預(yù)期。第三是調(diào)用成本Embedding是批量調(diào)用的元數(shù)據(jù)初始化時(shí)要對大量文本做向量化量大的時(shí)候成本不可忽略選型時(shí)要算清楚賬。4. 數(shù)據(jù)層與向量檢索設(shè)施搭建4.1 業(yè)務(wù)數(shù)據(jù)庫連接管理問數(shù)項(xiàng)目的核心操作對象就是業(yè)務(wù)數(shù)據(jù)庫這層的連接管理質(zhì)量直接決定了Agent查詢數(shù)據(jù)的穩(wěn)定性和速度。PostgreSQL是我最常用的選擇在復(fù)雜SQL支持、JSON處理、擴(kuò)展生態(tài)方面都很成熟用它存業(yè)務(wù)數(shù)據(jù)非常穩(wěn)妥。SQLAlchemy是Python里最主流的數(shù)據(jù)訪問層它提供了連接池管理、ORM映射、SQL表達(dá)式語言等能力。在Agent場景下我們既要執(zhí)行動(dòng)態(tài)生成的SQL也需要ORM層來做一些配置管理和元數(shù)據(jù)記錄兩者不沖突。# app/services/database.py from sqlalchemy import create_engine, text from sqlalchemy.pool import QueuePool from contextlib import contextmanager from functools import lru_cache from app.config import get_settings lru_cache def get_engine(): settings get_settings() db_url ( fpostgresqlpsycopg://{settings.DB_USER}:{settings.DB_PASSWORD} f{settings.DB_HOST}:{settings.DB_PORT}/{settings.DB_NAME} ) return create_engine( db_url, poolclassQueuePool, pool_sizesettings.DB_POOL_SIZE, max_overflow5, pool_pre_pingTrue, pool_recycle1800, ) contextmanager def get_db_connection(): engine get_engine() conn engine.connect() try: yield conn finally: conn.close() def execute_sql(sql: str): 執(zhí)行只讀查詢返回結(jié)果集 with get_db_connection() as conn: result conn.execute(text(sql)) columns list(result.keys()) rows [dict(zip(columns, row)) for row in result.fetchall()] return {columns: columns, rows: rows, row_count: len(rows)}幾個(gè)關(guān)鍵參數(shù)我要重點(diǎn)解釋一下。pool_pre_pingTrue是在每次從連接池取連接之前先發(fā)送一個(gè)ping信號檢測連接是否存活避免數(shù)據(jù)庫端連接因?yàn)榭臻e太久被斷開拿到一個(gè)壞連接導(dǎo)致查詢報(bào)錯(cuò)。pool_recycle1800表示連接最多存活30分鐘就要回收重建防止數(shù)據(jù)庫端主動(dòng)斷連造成的“connection already closed”錯(cuò)誤。max_overflow5意味著連接池在繁忙時(shí)最多可以額外創(chuàng)建5個(gè)臨時(shí)連接超過這個(gè)數(shù)就排隊(duì)等待——問數(shù)場景不需要盲目的高并發(fā)限制連接數(shù)反而是對數(shù)據(jù)庫的一種保護(hù)。4.2 只讀賬號與權(quán)限的最小化設(shè)計(jì)這件事我必須放在數(shù)據(jù)庫連接這一節(jié)里重點(diǎn)強(qiáng)調(diào)問數(shù)Agent連數(shù)據(jù)庫絕對不能使用業(yè)務(wù)系統(tǒng)管理員的賬號。原因很簡單Agent再智能本質(zhì)上是代碼在執(zhí)行SQL代碼一旦出現(xiàn)邏輯漏洞或者被提示詞注入攻擊就可能執(zhí)行出刪表、改數(shù)據(jù)這類破壞性操作。我在項(xiàng)目里單獨(dú)創(chuàng)建了一個(gè)只讀賬號CREATE USER agent_readonly WITH PASSWORD strong-password; GRANT CONNECT ON DATABASE business_db TO agent_readonly; GRANT USAGE ON SCHEMA public TO agent_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_readonly; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO agent_readonly;ALTER DEFAULT PRIVILEGES這一行很多人容易忽略。它保證了后續(xù)新建的表默認(rèn)給只讀賬號授予SELECT權(quán)限否則表建好后Agent又查不了排查半天才發(fā)現(xiàn)是權(quán)限問題。除了數(shù)據(jù)庫側(cè)應(yīng)用側(cè)也要做一個(gè)兜底防線。SQL執(zhí)行器里檢查SQL語句強(qiáng)制執(zhí)行語句前判斷第一條非注釋語句的動(dòng)詞必須是SELECT、WITH、SHOW、EXPLAIN這些只讀操作其他的直接拒絕執(zhí)行。雖然模型生成的SQL絕大多數(shù)情況不會(huì)寫DELETE但安全邊界永遠(yuǎn)要相信自己寫的代碼不要相信外部模型的輸出。4.3 表結(jié)構(gòu)元數(shù)據(jù)提取與加工問數(shù)Agent要寫好SQL前提是它得知道數(shù)據(jù)庫里有哪些表、每張表有哪些字段、字段的業(yè)務(wù)含義是什么。這些信息就是數(shù)據(jù)庫的“元數(shù)據(jù)”。元數(shù)據(jù)可以從PostgreSQL的系統(tǒng)目錄直接查詢SELECT t.table_name, c.column_name, c.data_type, c.is_nullable FROM information_schema.tables t JOIN information_schema.columns c ON t.table_name c.table_name WHERE t.table_schema public AND t.table_type BASE TABLE ORDER BY t.table_name, c.ordinal_position;但只靠系統(tǒng)目錄還不夠。系統(tǒng)目錄里的表和字段名往往是英文縮寫或者技術(shù)命名比如cst_amt模型根本猜不出這是“客戶金額”的意思。所以我額外做了一個(gè)“字段注釋”的加工環(huán)節(jié)把業(yè)務(wù)注釋寫入PostgreSQL的COMMENT里COMMENT ON TABLE sales_order IS 銷售訂單表每行代表一條客戶訂單記錄; COMMENT ON COLUMN sales_order.cst_amt IS 客戶訂單總金額元含稅; COMMENT ON COLUMN sales_order.order_status IS 訂單狀態(tài)0-草稿1-已提交2-已發(fā)貨3-已完成4-已取消;這些COMMENT信息同樣可以從系統(tǒng)目錄讀出來我們在做元數(shù)據(jù)時(shí)要把“表名字段名字段類型業(yè)務(wù)注釋”組合成一段完整描述文本后續(xù)它有兩個(gè)用途一是直接作為提示詞上下文喂給大模型幫助它理解表結(jié)構(gòu)二是做向量化后存入向量庫用于檢索召回。4.4 向量數(shù)據(jù)庫的初始化與集合管理Qdrant的初始化非常輕量本地用Docker啟動(dòng)一個(gè)單節(jié)點(diǎn)就夠開發(fā)調(diào)試了docker run -d --name qdrant \ -p 6333:6333 -p 6334:6334 \ -v $(pwd)/qdrant_storage:/qdrant/storage \ qdrant/qdrant:v1.9.7注意6334端口是gRPC接口生產(chǎn)環(huán)境建議用內(nèi)部網(wǎng)絡(luò)通gRPC提升性能開發(fā)階段用6333的HTTP接口就夠。集合的創(chuàng)建考慮兩個(gè)核心參數(shù)向量維度和距離度量方式。向量維度必須和你選的Embedding模型輸出維度一致比如text-embedding-3-small是1536維如果后續(xù)換模型向量維度變了舊集合的數(shù)據(jù)就完全失效了。距離度量我用Cosine尤其在文本相似度場景下Cosine比Dot Product更直觀穩(wěn)定對向量的模長不敏感適合描述文本語義的接近程度。# scripts/init_qdrant.py from qdrant_client import QdrantClient from qdrant_client.http import models as qdrant_models client QdrantClient(hostlocalhost, port6333) client.recreate_collection( collection_namedb_metadata, vectors_configqdrant_models.VectorParams( size1536, distanceqdrant_models.Distance.COSINE, ), ) print(collection created)在采樣數(shù)據(jù)上我再多提一句。問數(shù)Agent的召回策略里表結(jié)構(gòu)文本做向量化后存入向量庫而表名和字段名可以同時(shí)做關(guān)鍵詞過濾或全文匹配。在實(shí)際使用時(shí)兩者結(jié)合的效果比單用向量好很多因?yàn)楸砻恼Z義往往是精準(zhǔn)匹配更可靠。向量檢索負(fù)責(zé)語義接近性關(guān)鍵詞匹配負(fù)責(zé)精確對應(yīng)這個(gè)雙通道策略在第五章還會(huì)展開。5. 智能體運(yùn)行框架搭建5.1 Agent框架選型LangChain還是LlamaIndex問數(shù)項(xiàng)目里關(guān)于框架的選型我的結(jié)論是主Agent編排用LangChain數(shù)據(jù)處理和檢索部分參考LlamaIndex的設(shè)計(jì)思路但不直接引入整個(gè)LlamaIndex。為什么不用LlamaIndex做主線LlamaIndex在文檔問答、知識庫RAG場景下有巨大優(yōu)勢尤其是數(shù)據(jù)索引和數(shù)據(jù)加載器的生態(tài)非常完善。但問數(shù)項(xiàng)目的核心是Text-to-SQL加上動(dòng)態(tài)工具調(diào)用LangChain在這塊的抽象更成熟AgentExecutor和工具裝飾器用起來更順手社區(qū)案例也更多。為什么不完全手寫如果你只是調(diào)一個(gè)模型、連一個(gè)數(shù)據(jù)庫手寫沒問題。但問數(shù)Agent后續(xù)要加記憶、加多工具協(xié)同、加復(fù)雜的編排邏輯LangChain提供了這些組件的基礎(chǔ)抽象把Web搜索、API調(diào)用、代碼執(zhí)行等工具接入標(biāo)準(zhǔn)化省掉了重復(fù)造輪子的時(shí)間。5.2 工具注冊與技能機(jī)制這一節(jié)是整個(gè)Agent基礎(chǔ)設(shè)施里最核心的部分對應(yīng)目前很多團(tuán)隊(duì)在實(shí)踐的“Agent Skill”機(jī)制。我的工具注冊設(shè)計(jì)很簡單用裝飾器把函數(shù)注冊到工具中心注冊時(shí)附帶名稱、描述、參數(shù)SchemaAgent運(yùn)行時(shí)通過讀取注冊中心來決定調(diào)用哪個(gè)工具。# app/tools/registry.py from typing import Callable, Dict, Any from pydantic import BaseModel, create_model class ToolSpec(BaseModel): name: str description: str args_schema: Any func: Callable _tool_registry: Dict[str, ToolSpec] {} def register_tool(name: str, description: str, args_schema: type[BaseModel]): def decorator(func): _tool_registry[name] ToolSpec( namename, descriptiondescription, args_schemaargs_schema, funcfunc, ) return func return decorator def get_all_tools(): return list(_tool_registry.values())工具描述文本的寫法對Agent的效果影響比想象中大得多。描述里要寫清楚這個(gè)工具是做什么的、在什么條件下使用、參數(shù)怎么填、有什么限制。大模型是靠描述來決定調(diào)用哪個(gè)工具的描述寫得含糊它就會(huì)在你預(yù)期的工具之外瞎猜。這個(gè)設(shè)計(jì)最大的好處是模塊解耦。每加一個(gè)新的數(shù)據(jù)查詢能力比如查ERP系統(tǒng)的接口、查報(bào)表平臺(tái)的API只要實(shí)現(xiàn)一個(gè)函數(shù)并注冊Agent的編排邏輯完全不需要變。后面想加權(quán)限校驗(yàn)、審計(jì)日志也只需要在注冊中心統(tǒng)一包一層不需要改動(dòng)每個(gè)工具的內(nèi)部實(shí)現(xiàn)。5.3 SQL執(zhí)行工具的實(shí)現(xiàn)有了注冊機(jī)制接下來實(shí)現(xiàn)問數(shù)項(xiàng)目里最核心的工具SQL執(zhí)行器。它要接收大模型生成的SQL執(zhí)行查詢并返回結(jié)果。但這里有一個(gè)真實(shí)的工程問題是大模型生成的SQL很可能有語法錯(cuò)誤也可能踩到數(shù)據(jù)庫不支持的語法。# app/tools/sql_executor.py from pydantic import BaseModel, Field from app.tools.registry import register_tool from app.services.database import execute_sql from app.utils.logger import core_logger class SQLExecuteArgs(BaseModel): sql: str Field(description要執(zhí)行的SQL查詢語句必須是SELECT只讀查詢) register_tool(sql_executor, 執(zhí)行只讀SQL查詢語句返回查詢結(jié)果, SQLExecuteArgs) def sql_execute(sql: str): core_logger.info(f[SQL Executor] executing: {sql}) # 安全檢查只允許以SELECT開頭的語句 stripped sql.lstrip().lstrip(().strip().lower() if not stripped.startswith((select, with, show, explain)): return {error: 僅允許執(zhí)行只讀查詢SELECT/WITH/SHOW/EXPLAIN} try: result execute_sql(sql) core_logger.info(f[SQL Executor] rows returned: {result[row_count]}) return result except Exception as e: core_logger.error(f[SQL Executor] error: {e}) return {error: str(e)}工具的返回格式很重要。不要把數(shù)據(jù)庫原始結(jié)果直接扔給模型而是要做結(jié)構(gòu)化的封裝。模型拿到結(jié)果后還需要判斷是否滿足用戶的原始問題如果不滿足可能要調(diào)整SQL重查。所以返回結(jié)果最好加上列名、行數(shù)、以及前N行數(shù)據(jù)。數(shù)據(jù)量大時(shí)還得做截?cái)噙@個(gè)后面會(huì)詳細(xì)講。5.4 元數(shù)據(jù)召回工具的實(shí)現(xiàn)問數(shù)Agent使用元數(shù)據(jù)工具的方式和人類分析師很相似。人分析數(shù)據(jù)之前得先看有哪些表、哪些字段Agent也是一樣——先查到可用的表結(jié)構(gòu)把它作為提示詞的上下文才能進(jìn)入SQL生成階段。元數(shù)據(jù)工具有兩條獲取路徑。一條是精準(zhǔn)路徑根據(jù)用戶問題中出現(xiàn)的表名直接查系統(tǒng)目錄拿表結(jié)構(gòu)另一條是模糊路徑把用戶問題做向量化在Qdrant里做相似度檢索把最相關(guān)的表描述召回出來。# app/tools/db_metadata.py from pydantic import BaseModel, Field from app.tools.registry import register_tool from app.services.metadata import get_table_schema class SearchSchemaArgs(BaseModel): keywords: str Field(description表名或字段名的關(guān)鍵詞) register_tool(search_table_schema, 搜索業(yè)務(wù)數(shù)據(jù)庫中與關(guān)鍵詞相關(guān)的表和字段結(jié)構(gòu), SearchSchemaArgs) def search_table_schema(keywords: str): return get_table_schema(keywords)在實(shí)際項(xiàng)目中精準(zhǔn)路徑和模糊路徑建議都實(shí)現(xiàn)。精準(zhǔn)路徑用來快速定位——當(dāng)用戶提到“訂單表”時(shí)直接拿到sales_order的結(jié)構(gòu)模糊路徑用來兜底——用戶用“客戶買了多少錢”這種口語化描述時(shí)通過向量檢索找到cst_amt字段?；A(chǔ)階段先把兩條路徑都留好具體調(diào)參在后續(xù)的業(yè)務(wù)邏輯章節(jié)里繼續(xù)做。5.5 主Agent運(yùn)行時(shí)封裝最后把模型、工具、記憶、提示詞粘合在一起的就是主Agent本體。我用LangChain的create_react_agent來構(gòu)建。ReAct模式的核心思想是讓模型在“思考”和“行動(dòng)”之間循環(huán)思考當(dāng)前需要什么信息、決定調(diào)用哪個(gè)工具、觀察工具的返回結(jié)果、繼續(xù)思考下一步直到有足夠信息回答用戶。這種模式非常適合問數(shù)場景因?yàn)橐卮稹坝唵谓痤~最大的客戶是誰”模型需要調(diào)用元數(shù)據(jù)工具看表結(jié)構(gòu)、調(diào)用SQL執(zhí)行器查數(shù)據(jù)這中間至少要兩個(gè)步驟。# app/agent/agent.py from langchain.agents import create_react_agent, AgentExecutor from langchain_core.prompts import PromptTemplate from langchain_core.tools import StructuredTool from app.agent.llm import get_llm, DEFAULT_SYSTEM_PROMPT from app.tools.registry import get_all_tools def build_agent(): llm get_llm() tools [] for spec in get_all_tools(): tools.append(StructuredTool.from_function( funcspec.func, namespec.name, descriptionspec.description, args_schemaspec.args_schema, )) prompt PromptTemplate.from_template(DEFAULT_SYSTEM_PROMPT) agent create_react_agent( llmllm, toolstools, promptprompt, stop_sequenceTrue, ) executor AgentExecutor( agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue, max_iterations5, return_intermediate_stepsTrue, ) return executormax_iterations5是很重要的參數(shù)。它限制Agent最多只能思考和行動(dòng)5輪超過就直接返回避免大模型陷入無限循環(huán)、反復(fù)調(diào)用工具停不下來。真實(shí)項(xiàng)目里一次查詢很少超過4輪如果超過了往往是提示詞或工具描述出了問題排查的時(shí)候優(yōu)先看中間步驟的日志基本能定位到是哪一步的意圖沒被識別對。6. 服務(wù)化與工程化配套搭建6.1 FastAPI封裝Agent服務(wù)Agent內(nèi)核搭好了還需要把它封裝成服務(wù)才能讓前端頁面或者同事的客戶端調(diào)用。FastAPI在這層做得非常舒服類型提示天然支持、OpenAPI文檔自動(dòng)生成、異步性能也足夠。# app/main.py from fastapi import FastAPI from pydantic import BaseModel from app.agent.agent import build_agent app FastAPI(titleLCODER問數(shù)智能體) class QueryRequest(BaseModel): question: str session_id: str history: list[dict] [] class QueryResponse(BaseModel): answer: str sql: str data: dict {} intermediate_steps: list [] agent_executor build_agent() app.post(/api/query, response_modelQueryResponse) async def query(req: QueryRequest): # 將結(jié)構(gòu)化參數(shù)包裝成給Agent的輸入 result await asyncio.to_thread( agent_executor.invoke, {input: req.question} ) return QueryResponse( answerresult[output], intermediate_stepsresult.get(intermediate_steps, []) )這里有一個(gè)要點(diǎn)AgentExecutor的invoke方法是同步阻塞的直接放進(jìn)FastAPI的async函數(shù)里會(huì)阻塞事件循環(huán)導(dǎo)致其他請求排隊(duì)。用asyncio.to_thread把同步調(diào)用丟到線程池里執(zhí)行不阻塞主事件循環(huán)實(shí)測在普通服務(wù)器上的并發(fā)能力就夠用了。6.2 Redis緩存與輕量會(huì)話管理如果每次請求都重新走一次建模-推理-SQL生成的完整流程不僅慢而且模型成本會(huì)高得驚人。對于一些高頻的、相似的查詢可以加一層緩存。Redis在這里充當(dāng)兩個(gè)角色。第一是查詢結(jié)果緩存把問題做規(guī)范化處理后作為key第一次查詢把結(jié)果寫入Redis并設(shè)置過期時(shí)間后續(xù)相同問題直接命中。第二是會(huì)話上下文緩存存儲(chǔ)Agent和用戶的對話記錄支持多輪問答的場景。比如按用戶question的哈希值做緩存import hashlib import json from redis import Redis from app.config import get_settings settings get_settings() redis_client Redis( hostsettings.REDIS_HOST, portsettings.REDIS_PORT, dbsettings.REDIS_DB, decode_responsesTrue, ) def get_cache_key(question: str) - str: digest hashlib.md5(question.strip().lower().encode()).hexdigest() return fagent:query:{digest} def set_query_cache(question: str, answer: dict, expire_seconds: int 3600): key get_cache_key(question) redis_client.setex(key, expire_seconds, json.dumps(answer, ensure_asciiFalse)) def get_query_cache(question: str): key get_cache_key(question) cached redis_client.get(key) return json.loads(cached) if cached else None緩存粒度是值得斟酌的。如果整個(gè)SQL查詢結(jié)果都緩存數(shù)據(jù)變化后緩存會(huì)過期不準(zhǔn)如果只緩存SQL生成結(jié)果每次執(zhí)行SQL才能拿最新數(shù)據(jù)但大模型調(diào)用省了。折中方案是緩存的過期時(shí)間根據(jù)業(yè)務(wù)數(shù)據(jù)新鮮度來調(diào)整對實(shí)時(shí)性要求高的報(bào)表類型直接跳過緩存。這一塊屬于業(yè)務(wù)策略的范疇基礎(chǔ)設(shè)施階段先把緩存的通道打通后面按需調(diào)整就行。6.3 全鏈路可觀測與排查輔助Agent項(xiàng)目的調(diào)試難度比普通Web服務(wù)高一截關(guān)鍵在于鏈路太長用戶請求先進(jìn)FastAPI然后進(jìn)AgentExecutor再到大模型API模型返回后可能調(diào)元數(shù)據(jù)工具、再調(diào)SQL執(zhí)行器最后拼接答案返回。任何一個(gè)環(huán)節(jié)出錯(cuò)表現(xiàn)在用戶端的都只是“回答不對”或“超時(shí)”。所以基礎(chǔ)設(shè)施階段必須把可觀測性搭好。不只是日志而是要把一次請求的關(guān)鍵節(jié)點(diǎn)串聯(lián)起來。我目前的方案是在每個(gè)工具調(diào)用和模型調(diào)用前后打點(diǎn)import time import uuid from loguru import logger from contextvars import ContextVar request_id_var: ContextVar[str] ContextVar(request_id, default-) def log_with_context(message: str, **kwargs): rid request_id_var.get() logger.info(f[{rid}] {message}, **kwargs) def track_execution(func, name: str): def wrapper(*args, **kwargs): start time.monotonic() log_with_context(f{name} start, argsargs) try: result func(*args, **kwargs) elapsed time.monotonic() - start log_with_context(f{name} end, elapsed_msround(elapsed * 1000, 2)) return result except Exception as e: elapsed time.monotonic() - start log_with_context(f{name} error, elapsed_msround(elapsed * 1000, 2), errorstr(e)) raise return wrapper在FastAPI入口為每個(gè)請求生成一個(gè)request_id通過ContextVar貫穿整個(gè)請求生命周期。這樣排查問題時(shí)只需要用一個(gè)request_id把日志文件里所有相關(guān)記錄撈出來就能還原一次完整調(diào)用鏈效率比沒有request_id時(shí)大海撈針高得多。7. 常見問題與排查技巧實(shí)錄7.1 依賴沖突與版本地獄LangChain生態(tài)的版本更新速度非?？觳煌蟀姹局gAPI可能完全不兼容。我遇到的典型問題是項(xiàng)目里裝了一個(gè)依賴庫它依賴的是舊版langchain-core結(jié)果跟新裝langchain-openai的版本沖突程序啟動(dòng)時(shí)報(bào)出一堆ABC簽名錯(cuò)誤。排查這類問題我的建議是按這幾個(gè)步驟來第一啟動(dòng)時(shí)如果報(bào)錯(cuò)先別急著搜索報(bào)錯(cuò)信息檢查itsdangerous的提示里有沒有“conflict with”或者“requires a different version”的字樣第二用pip list或uv pip list確認(rèn)當(dāng)前環(huán)境里langchain相關(guān)包的版本號第三鎖定一個(gè)“全家桶版本組合”比如langchain 0.3.x配langchain-openai 0.2.x配langchain-community 0.3.x不要一個(gè)最新一個(gè)舊版混著裝。還有一個(gè)小技巧uv的lock文件把版本精確鎖定到commit級別團(tuán)隊(duì)協(xié)作時(shí)大家同步的是完全一致的環(huán)境。你自己調(diào)試時(shí)如果用pip自由裝很容易在“我這邊能跑啊”和“為什么我這邊跑不了”之間反復(fù)橫跳。一旦基礎(chǔ)設(shè)施階段鎖好版本后面的各種集成問題會(huì)少非常多。7.2 數(shù)據(jù)庫連接池被打滿開發(fā)調(diào)試階段可能沒啥感覺一旦服務(wù)同時(shí)處理多個(gè)會(huì)話數(shù)據(jù)庫連接池很容易被打滿報(bào)錯(cuò)通常是“connection pool exhausted”或者“timeout waiting for connection”。這里要注意一個(gè)LangChain的隱藏行為默認(rèn)情況下AgentExecutor每執(zhí)行一步工具調(diào)用都會(huì)新建一個(gè)連接如果連接池沒關(guān)好工具多輪調(diào)用就會(huì)把連接池耗盡。解決辦法是確保execute_sql使用同一個(gè)engine connection池engine用lru_cache緩存工具執(zhí)行完連接正常釋放回到池里。還有一個(gè)排查姿勢查看數(shù)據(jù)庫端的pg_stat_activity表看是不是有大量idle in transaction狀態(tài)的連接堆積。如果有多半是事務(wù)沒有正常提交或回滾。檢查代碼里有沒有把數(shù)據(jù)寫入和讀取操作混在同一個(gè)長事務(wù)里問數(shù)Agent只做讀操作事務(wù)越短越好。SELECT pid, state, state_change, query_start, left(query, 80) AS query FROM pg_stat_activity WHERE datname business_db ORDER BY query_start;7.3 模型生成的SQL質(zhì)量不穩(wěn)定SQL生成質(zhì)量是最讓人頭疼也最需要長期迭代的問題。基礎(chǔ)設(shè)施階段能做的準(zhǔn)備是預(yù)設(shè)好錯(cuò)誤反饋機(jī)制一旦SQL執(zhí)行報(bào)錯(cuò)把報(bào)錯(cuò)信息返回給模型讓它根據(jù)報(bào)錯(cuò)信息修正SQL重寫。Agent工具的返回本身就是模型下一步?jīng)Q策的輸入所以SQL執(zhí)行器返回的錯(cuò)誤信息要足夠詳細(xì)。PostgreSQL的報(bào)錯(cuò)信息對程序不太友好但對大模型其實(shí)是很好的修正信號——比如“column sales_order.cst_amt does not exist”這句話模型讀完就能理解自己用錯(cuò)了字段名。在此基礎(chǔ)上我還發(fā)現(xiàn)一個(gè)很有用的做法在元數(shù)據(jù)工具里把字段的枚舉值或者數(shù)據(jù)分布概要也帶上。比如訂單狀態(tài)字段如果明確告訴模型“order_status的取值是0草稿/1已提交/2已發(fā)貨/3已完成/4已取消”模型生成帶過濾條件的SQL時(shí)基本不會(huì)寫錯(cuò)。這個(gè)信息可以通過查詢字段的distinct value來獲取但注意數(shù)據(jù)量大的字段不要做全量distinct會(huì)拖慢元數(shù)據(jù)工具性能。7.4 上下文令牌超限怎么辦問數(shù)Agent的上下文里要放表結(jié)構(gòu)描述、歷史對話、工具調(diào)用結(jié)果內(nèi)容很容易超過模型的token上限。尤其是元數(shù)據(jù)召回的數(shù)量控制不好時(shí)一次性塞給模型幾十張表的描述光表結(jié)構(gòu)就把上下文撐爆了模型反而抓不住重點(diǎn)。我的經(jīng)驗(yàn)是一個(gè)查詢流程里召回的元數(shù)據(jù)控制在3到5張表以內(nèi)。召回更多時(shí)模型通常不會(huì)認(rèn)真看反而增加token消耗和推理延遲。如果確實(shí)需要跨很多表查詢先把問題拆解成子問題讓Agent分步處理而不是一次性把所有表都塞進(jìn)去。工具返回的結(jié)果集也要做截?cái)?。SQL查詢?nèi)绻祷亓藥浊袛?shù)據(jù)不能一股腦扔給大模型生成回答那會(huì)讓token瞬間爆炸。我的方案是最多返回前50行并附上“共有N行”的提示。如果模型需要更詳細(xì)的數(shù)據(jù)它可以通過追加LIMIT子句或加GROUP BY聚合來重新查詢。7.5 調(diào)試鏈路“中間步驟”是唯一真相Agent項(xiàng)目調(diào)試時(shí)最大的錯(cuò)覺就是模型回答錯(cuò)了但你看不出為什么錯(cuò)。FastAPI的接口返回里我把intermediate_steps字段也帶上了這個(gè)字段記錄的是Agent每一步的思考、調(diào)用的工具、工具的輸入輸出。排查問題的時(shí)候先看這個(gè)字段而不是猜。比如用戶問“訂單最多的前十個(gè)客戶”結(jié)果回答錯(cuò)了?？粗虚g步驟就能定位是工具沒調(diào)對比如搜索表結(jié)構(gòu)時(shí)沒有命中客戶表還是SQL寫錯(cuò)了比如沒加GROUP BY還是返回結(jié)果被截?cái)嗔?。這比讓開發(fā)人員一遍遍重放問題高效太多。我在loguru里專門對intermediate_steps做了結(jié)構(gòu)化輸出用JSON格式記錄。后續(xù)如果接入Lunary或LangSmith這類可觀測性平臺(tái)這些數(shù)據(jù)也能直接對接為模型調(diào)優(yōu)和回歸測試提供數(shù)據(jù)基礎(chǔ)。從基礎(chǔ)設(shè)施搭建的角度回顧這一階段我把工程基座、模型接入、數(shù)據(jù)設(shè)施、運(yùn)行框架、服務(wù)化與可觀測性這幾層都立住了。技術(shù)選型不一定是最新最潮的但每一層都是經(jīng)過實(shí)際項(xiàng)目和踩坑驗(yàn)證過的組合。我個(gè)人體會(huì)是基礎(chǔ)設(shè)施階段花的時(shí)間完全值得因?yàn)楹竺婷繉懸恍袠I(yè)務(wù)代碼都有穩(wěn)的地基接著而如果地基沒打好加功能的同時(shí)還得修補(bǔ)之前的破洞那種感覺才是真的折磨。下一步就可以在這個(gè)底座上填充具體的業(yè)務(wù)技能了比如問數(shù)SQL生成、結(jié)果校驗(yàn)、數(shù)據(jù)可視化這些模塊都有得聊。