当大模型的能力不再成为瓶颈,真正的挑战从“模型怎么训”变成了“应用怎么做”。本文深入 AGI 应用开发的工程全貌,涵盖 RAG、Agent、评估、成本与架构设计,为开发者提供一份可落地的实战指南。所有代码片段均可直接运行或改造后用于生产环境。
2025 年,大模型的技术曲线正在趋缓——模型参数量不再是新闻头条,多模态能力逐渐成为标配,上下文窗口从 128K 卷到 10M 也接近边际效应递减。真正发生剧变的,是模型之上的应用层。
如果说过去两年是“模型能力秀”,那么从现在开始,赛场已经切换到了“工程化落地”。同一个 GPT-4 级别的模型,有的人用它做出来的是高级聊天机器人,有的人却做出了能够自主处理供应链异常、自动生成合规报告并完成跨系统操作的智能体。差距不在于模型,而在于应用架构、工程实践和对业务场景的深度理解。
本文从一线实战视角出发,系统拆解 AGI 大模型应用开发的完整技术图谱,帮你从“能调 API”进阶到“能交付可靠产品”。
RAG(检索增强生成)是目前企业落地最广泛、ROI 最清晰的 AGI 应用模式。它让大模型不再依赖训练时“背下来”的知识,而是实时检索外部知识库,实现“开卷作答”。
一条标准的 RAG 流水线包含五个环节:
从 Demo 到生产,RAG 需要跨过几道坎:
切分策略的精细化:固定长度切分容易切断语义边界。生产环境需要引入语义切分——基于段落边界、标题层级或 Embedding 相似度动态调整切分点。
检索质量优化:简单的向量相似度检索远远不够。需要引入混合检索(向量检索 + 关键词检索,如 BM25),并根据场景动态调整权重。rrf(倒数排名融合)是一种简单有效的融合算法。
多路召回与重排序:召回之后,用更精细的重排序模型(Reranker) 对候选段落进行二次打分,过滤掉低相关度的内容,再送入大模型。这能显著提升回答质量。
索引策略:对于千万级以上的文档规模,需要合理选择索引类型。FLAT 索引支持精确搜索但内存占用大,适合百万级以下;HNSW 和 IVF 系列支持近似搜索,适合大规模场景。
以下是使用 Python 实现的一个基础 RAG 流程,涵盖文档切分、向量化和检索:
import os
from typing import List
from langchain.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA
# 1. 加载文档
loader = PyPDFLoader("./knowledge_base/运维手册.pdf")
documents = loader.load()
# 2. 语义切分
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", "。", "!", "?", ";", ",", " ", ""]
)
chunks = text_splitter.split_documents(documents)
# 3. 向量化存储
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db")
# 4. 检索器配置:混合检索(需要额外安装 BM25 插件)
retriever = vectorstore.as_retriever(
search_type="mmr", # 最大边际相关性,提升多样性
search_kwargs={"k": 5, "fetch_k": 20}
)
# 5. 构建 QA 链
llm = ChatOpenAI(model_name="gpt-4", temperature=0.2)
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff",
retriever=retriever,
return_source_documents=True
)
# 执行查询
result = qa_chain("CPU 使用率持续超过 90% 应该如何处理?")
print(f"答案: {result['result']}")
print(f"参考文档: {[doc.metadata for doc in result['source_documents']]}")静态 RAG 的局限在于:一次检索就生成答案,无法应对需要多轮信息获取的复杂问题。引入 Agentic RAG 模式后,模型可以自主判断是否需要补充检索、换一个检索方向、或者调用外部工具获取实时数据,从而显著提升复杂问答场景的准确率。
以下是使用 LangGraph 实现的可迭代检索的 Agentic RAG:
from langgraph.graph import StateGraph, END
from typing import TypedDict, List
class AgentState(TypedDict):
question: str
retrieved_docs: List[str]
rounds: int
answer: str
def retrieve(state: AgentState):
# 初次检索
docs = vectorstore.similarity_search(state["question"], k=5)
return {"retrieved_docs": [d.page_content for d in docs], "rounds": 1}
def evaluate(state: AgentState):
# 用大模型评估检索结果是否充分
prompt = f"问题: {state['question']}\n已检索内容: {state['retrieved_docs']}\n这些信息足够回答吗?回复'是'或'否'及理由。"
response = llm.invoke(prompt)
if "是" in response.content and state["rounds"] >= 1:
return "generate"
elif state["rounds"] >= 3:
return "generate" # 最多 3 轮
else:
return "refine"
def refine_query(state: AgentState):
# 改写查询词,补充检索
prompt = f"原始问题: {state['question']}\n已有内容: {state['retrieved_docs']}\n请生成一个更精准的检索查询。"
new_query = llm.invoke(prompt).content
docs = vectorstore.similarity_search(new_query, k=3)
state["retrieved_docs"].extend([d.page_content for d in docs])
state["rounds"] += 1
return state
def generate(state: AgentState):
prompt = f"基于以下信息回答问题:\n{chr(10).join(state['retrieved_docs'])}\n\n问题: {state['question']}"
answer = llm.invoke(prompt).content
return {"answer": answer}
# 构建状态图
graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve)
graph.add_node("evaluate", evaluate)
graph.add_node("refine", refine_query)
graph.add_node("generate", generate)
graph.set_entry_point("retrieve")
graph.add_conditional_edges("evaluate", lambda s: s["next_step"])
graph.add_edge("refine", "evaluate")
graph.add_edge("generate", END)
app = graph.compile()
result = app.invoke({"question": "如何排查数据库连接池耗尽问题?", "rounds": 0})
print(result["answer"])如果说 RAG 让大模型“会查资料”,那么 Agent 让大模型“会办事”。Agent 的核心能力是自主规划 + 工具调用 + 记忆反思。
一个成熟的 Agent 系统由以下模块构成:
相比 Python 的 LangChain 和 AutoGen,Java 生态也在快速追赶:
Spring AI:背靠 Spring 生态,提供统一的 Model API 抽象和函数调用(Function Calling)机制。开发者只需将 Java 方法注册为工具,AI 会自主决定调用时机。
LangChain4j:LangChain 的 Java 移植版,功能更接近 Python 原版,提供了完整的 Agent 构建模块。
以下是使用 Spring AI 构建一个带工具的 Agent 的完整示例:
import org.springframework.ai.chat.ChatClient;
import org.springframework.ai.chat.ChatResponse;
import org.springframework.ai.chat.prompt.Prompt;
import org.springframework.ai.chat.prompt.SystemPromptTemplate;
import org.springframework.ai.tool.annotation.Tool;
import org.springframework.ai.tool.annotation.ToolParam;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.List;
@Service
public class AgentService {
@Autowired
private ChatClient chatClient;
@Tool(description = "查询指定时间范围内的订单数量")
public int queryOrderCount(
@ToolParam(description = "开始时间,格式 yyyy-MM-dd HH:mm:ss") String startTime,
@ToolParam(description = "结束时间,格式 yyyy-MM-dd HH:mm:ss") String endTime) {
// 实际场景中这里会查询数据库
System.out.println("查询订单: " + startTime + " 到 " + endTime);
return 1342; // 模拟返回
}
@Tool(description = "获取当前系统时间")
public String getCurrentTime() {
return LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));
}
public String processUserRequest(String userInput) {
// 构建系统提示词,声明可用工具
String systemPrompt = """
你是一个智能运维助手,你可以使用以下工具:
1. queryOrderCount - 查询订单数量
2. getCurrentTime - 获取当前时间
请根据用户问题,自主决定调用哪些工具,并基于结果给出最终答案。
""";
Prompt prompt = new Prompt(
new SystemPromptTemplate(systemPrompt).createMessage(),
new UserMessage(userInput)
);
// Spring AI 会自动将 @Tool 注解的方法注册给模型
ChatResponse response = chatClient.call(prompt);
return response.getResult().getOutput().getContent();
}
}ReAct 模式(Reasoning + Acting):每次推理和行动交替进行——思考下一步做什么,执行,观察结果,再思考。适合简单任务。
Plan-and-Execute 模式:首先生成完整的任务计划,再按计划逐步执行,每个步骤完成后根据反馈决定是否调整后续计划。适合复杂多步骤任务。
以下是 ReAct 模式的核心循环实现(使用 Python):
def react_loop(user_question, max_steps=5):
thought_history = []
for step in range(max_steps):
# 1. 推理:决定下一步动作
prompt = f"""
你是一个 Agent,当前任务:{user_question}
历史操作:{thought_history}
可选工具:search(query), calculate(expr), get_weather(city)
请输出下一步行动,格式:Action: tool_name(parameters)
如果已经有答案,输出:Final Answer: 答案内容
"""
response = llm.invoke(prompt).content
if "Final Answer:" in response:
return response.split("Final Answer:")[1].strip()
# 2. 解析动作并执行
action = parse_action(response) # 解析出 tool_name 和参数
result = execute_tool(action.tool, action.params)
# 3. 观察结果,加入历史
thought_history.append(f"执行 {action.tool} 得到结果: {result}")
return "抱歉,未能完成任务。"
# 使用示例
print(react_loop("帮我查一下北京今天的天气,然后计算比昨天高多少度?"))选择哪种模式取决于场景复杂度:简单的单步工具调用用 ReAct 就足够了;涉及跨系统协同、多条件判断的复杂任务,Plan-and-Execute 更可控。
AGI 应用与传统软件最大的不同在于:输出是非确定性的。这使得评估不再是“上线前测一次就完事”,而是需要建立持续的质量监控体系。
准确性评估:回答是否正确、是否基于事实。对于有标准答案的场景(如知识库问答),可以构建测试集,用精确匹配或 LLM-as-Judge 方式进行自动化评估。
相关性评估:回答是否切题、是否冗余。Context Relevance 和 Answer Relevance 是两个核心指标,可以使用 RAGAS 等开源框架自动计算。
安全性评估:是否产生有害内容、是否泄露敏感信息、是否出现幻觉。特别是 Agent 场景下,需要验证模型不会调用危险的工具或超出授权范围操作。
# 使用 RAGAS 对 RAG 系统进行自动评估
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
from datasets import Dataset
# 准备测试数据
test_data = Dataset.from_dict({
"question": [
"什么是 Kubernetes 的 Pod?",
"如何排查内存泄漏?"
],
"answer": [
qa_chain("什么是 Kubernetes 的 Pod?")["result"],
qa_chain("如何排查内存泄漏?")["result"]
],
"contexts": [
["Kubernetes Pod 是...", "Pod 是 K8s 最小部署单元..."],
["内存泄漏通常表现为...", "使用 jstat 监控 GC 频率..."]
]
})
# 运行评估
result = evaluate(
dataset=test_data,
metrics=[faithfulness, answer_relevancy, context_recall]
)
print(result)
# 将结果接入 CI:如果 faithfulness < 0.8,构建失败
if result["faithfulness"] < 0.8:
raise Exception("RAG 质量不达标,请检查检索效果")在 CI/CD 流水线中集成评估:
# .github/workflows/rag_eval.yml
name: RAG Quality Check
on: [push, pull_request]
jobs:
evaluate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v4
with:
python-version: '3.11'
- run: pip install -r requirements.txt
- run: python tests/evaluate_rag.py
- name: 检查评估结果
run: |
if [ $(cat eval_result.json | jq '.faithfulness') -lt 0.8 ]; then
echo "Faithfulness 低于阈值 0.8,请优化 RAG 流水线"
exit 1
fi大模型 API 的调用成本在 POC 阶段可以忽略不计,但一旦产品日活达到万级,成本将成为不可回避的问题。
一个标准 AGI 应用的成本由四部分构成:
一个简单的成本监控模块:
import hashlib
from datetime import datetime
class CostTracker:
def __init__(self):
self.total_input_tokens = 0
self.total_output_tokens = 0
self.input_price_per_1k = 0.01 # 以 GPT-4 为例
self.output_price_per_1k = 0.03
def log_call(self, prompt: str, response: str, model: str = "gpt-4"):
# 粗略估计 Token 数:中文约 1.5 字符/Token,英文约 4 字符/Token
input_tokens = len(prompt) // 2
output_tokens = len(response) // 2
self.total_input_tokens += input_tokens
self.total_output_tokens += output_tokens
cost = (input_tokens / 1000 * self.input_price_per_1k +
output_tokens / 1000 * self.output_price_per_1k)
print(f"[{datetime.now()}] 本次调用成本: ${cost:.4f}")
return cost
def report(self):
total = (self.total_input_tokens / 1000 * self.input_price_per_1k +
self.total_output_tokens / 1000 * self.output_price_per_1k)
print(f"总输入 Token: {self.total_input_tokens}")
print(f"总输出 Token: {self.total_output_tokens}")
print(f"总成本: ${total:.2f}")
# 使用
tracker = CostTracker()
response = qa_chain("什么是智能运维?")
tracker.log_call("什么是智能运维?", response["result"])Prompt 压缩:对检索到的上下文进行重排序和截断,只保留最相关的段落,控制输入长度。
缓存策略:对高频相似提问进行语义缓存——如果新问题的向量与已缓存问题足够接近,直接返回缓存结果,零 Token 消耗。
模型分级路由:简单问题用小模型(如 GPT-3.5 或 Qwen-Turbo),只有复杂推理场景才路由到最强模型。
以下是一个基于意图分类的模型路由实现:
def route_model(user_question: str) -> str:
"""根据问题复杂度选择模型"""
# 用轻量级分类器判断问题复杂度
simple_keywords = ["是什么", "定义", "多少", "几", "哪个"]
complex_keywords = ["为什么", "如何", "比较", "分析", "优化", "设计"]
if any(k in user_question for k in simple_keywords) and \
not any(k in user_question for k in complex_keywords):
return "gpt-3.5-turbo" # 低成本模型
else:
return "gpt-4" # 高性能模型
# 调用时动态选择
model = route_model(user_input)
response = chat_completion(model=model, messages=[...])一个可长期维护的 AGI 应用建议采用以下分层架构:
层级 | 职责 | 技术选型示例 |
|---|---|---|
接入层 | 统一 API 网关、鉴权、限流、路由 | Spring Cloud Gateway / Kong |
编排层 | Agent 调度、任务规划、状态管理 | Spring AI / LangChain4j |
执行层 | 工具执行、数据库操作、第三方调用 | 微服务 + 消息队列 |
模型层 | 大模型 API 调用、降级、切换 | OpenAI / Azure / 通义千问 / 私有化 |
数据层 | 向量库、关系库、缓存、对象存储 | Milvus / PostgreSQL / Redis |
超时控制:大模型 API 的 P99 延迟远高于普通后端服务,必须设置分级超时。
// 使用 Spring Retry 实现模型调用降级
@Retryable(
value = {TimeoutException.class},
maxAttempts = 2,
backoff = @Backoff(delay = 1000)
)
public String callModelWithFallback(String prompt) {
try {
return primaryModel.generate(prompt);
} catch (Exception e) {
// 降级到备用模型
return fallbackModel.generate(prompt);
}
}
// 备用模型返回兜底响应
@Recover
public String recover(TimeoutException e, String prompt) {
return "抱歉,当前模型服务繁忙,您的请求已转交人工处理,工单号: " + UUID.randomUUID();
}结构化日志:记录每一次模型调用的输入输出、Token 消耗、延迟。
import structlog
logger = structlog.get_logger()
def call_with_observability(prompt, model="gpt-4"):
start = time.time()
try:
response = llm.invoke(prompt)
latency = time.time() - start
logger.info(
"model_call",
model=model,
prompt_length=len(prompt),
response_length=len(response.content),
latency_ms=latency * 1000,
status="success"
)
return response
except Exception as e:
logger.error("model_call_failed", model=model, error=str(e))
raiseTrace 追踪:对于 Agent 的多步推理,需要记录完整的“思维链”和执行轨迹。
import json
from uuid import uuid4
class Trace:
def __init__(self, session_id):
self.session_id = session_id
self.steps = []
def add_step(self, step_name, input_data, output_data, metadata=None):
self.steps.append({
"step": step_name,
"input": input_data[:200], # 截断防止过大
"output": output_data[:200],
"metadata": metadata or {},
"timestamp": datetime.now().isoformat()
})
def save(self):
with open(f"traces/{self.session_id}.json", "w") as f:
json.dump(self.steps, f, indent=2, ensure_ascii=False)
# 在 Agent 中使用
trace = Trace(session_id=uuid4().hex)
trace.add_step("retrieve", question, retrieved_docs, {"k": 5})
trace.add_step("generate", prompt, answer, {"model": "gpt-4"})
trace.save()AGI 应用开发对人才的要求,介于传统后端开发和 AI 算法研究之间:
对于中小团队,不必一开始就追求全建制,“强后端 + 懂 Prompt + 业务理解力”的铁三角组合足以启动大部分 AGI 应用项目。
AGI 大模型应用的开发,正在经历从“demo 满天飞”到“产品硬碰硬”的关键转折期。早期靠“套壳”就能获得关注的红利已经消失,真正能活下来的应用,拼的是:
大模型给了我们前所未有的能力,但把这种能力转化为可靠的产品,依然需要回到软件工程最朴素的那些原则:解耦、抽象、可测试、可观测、可演进。
代码已经为你准备好了,从 RAG 到 Agent,从评估到成本管控。接下来,就看你在真实业务场景中,如何把这些代码片段组装成真正能产生价值的 AI 产品了。AGI大模型应用:从模型到产品的工程化蜕变
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。