AI-Compass：开源工具集助力LLM应用工程化开发与架构设计-平芜编程栈

1. 项目概述：AI-Compass，一个为AI应用开发导航的开源工具集

如果你正在或计划开发一个AI应用，无论是基于大语言模型的聊天机器人，还是集成了图像识别、语音处理的多模态智能体，你大概率会遇到一个共同的困境：从想法到可运行的原型，中间隔着一条名为“工程化”的鸿沟。模型选型、API调用、提示词工程、数据流设计、前后端集成、部署运维……每一个环节都充满了选择与挑战。今天要聊的这个开源项目AI-Compass，就是试图为开发者们绘制一张穿越这片复杂地形的导航图。

AI-Compass 并非一个单一的框架或库，而是一个精心设计的工具集合与最佳实践指南。它的核心目标非常明确：降低AI应用，特别是基于大语言模型（LLM）的应用的开发门槛，提升开发效率与工程质量。你可以把它理解为一个“脚手架生成器”加上一个“模式库”，它不强制你使用特定的技术栈，而是提供了一套经过验证的、模块化的解决方案，让你能快速搭建起一个结构清晰、易于维护的AI应用骨架。

这个项目适合谁？如果你是AI领域的初学者，面对浩如烟海的工具和概念感到无从下手，AI-Compass 能为你提供一个清晰的起点和结构化的学习路径。如果你是有经验的开发者，正在为团队寻找可复用的工程范式，或者希望优化现有AI项目的架构，那么AI-Compass 中沉淀的设计模式和工具链将极具参考价值。它试图回答的不是“用什么模型”，而是“如何以更好的工程方式去使用模型”。

2. 核心设计理念与架构拆解

2.1 为什么需要“指南针”？AI应用开发的典型痛点

在深入代码之前，理解AI-Compass要解决什么问题至关重要。传统的软件开发有成熟的MVC、微服务等架构模式，但AI应用，尤其是LLM应用，引入了一些新的复杂性：

非确定性交互：传统API的输入输出是结构化的、可预测的。而LLM的响应是非确定性的，同一提示词可能产生不同结果，这给错误处理、测试和用户体验设计带来了挑战。
上下文管理复杂：如何有效地组织、存储、检索和限制与模型的对话历史（上下文），以支持多轮对话、长期记忆或知识库检索，是一个核心工程问题。
工具/函数调用集成：让LLM能够调用外部工具（如计算器、数据库、搜索引擎）是增强其能力的关键。如何设计一个清晰、安全、易扩展的工具调用框架？
提示词工程与模板化：提示词是驱动LLM的“代码”。如何管理这些提示词，使其可版本控制、可复用、可针对不同场景进行A/B测试？
流式输出与用户体验：为了获得类似ChatGPT的逐字输出体验，需要处理服务器发送事件（SSE）等流式技术，这对前后端协作提出了要求。
多模型路由与降级：不同模型在成本、速度、能力上各有优劣。如何设计一个路由层，能根据请求内容、预算或性能要求智能地选择或降级到备用模型？

AI-Compass 正是瞄准了这些痛点，它的设计不是凭空想象，而是从大量实际项目中提炼出的共性需求。

2.2 模块化架构：像搭积木一样构建AI应用

AI-Compass 倡导一种清晰的、关注点分离的架构。它通常将应用划分为以下几个核心层次，每一层都有相应的工具或模式支持：

应用层 (Application Layer)这是用户直接交互的界面，可以是Web前端、移动端、命令行工具或消息平台（如Slack、钉钉）的机器人。AI-Compass 可能提供前端组件（如聊天窗口）的示例，或与流行框架（如Next.js, Streamlit）集成的样板代码。

编排层 (Orchestration Layer)这是AI应用的大脑，也是AI-Compass 的核心价值所在。它负责接收用户输入，协调各个模块工作：

代理（Agent）框架：定义AI代理的工作流。是简单的单次问答，还是需要规划、执行工具、观察结果的ReAct模式？AI-Compass 可能会提供基础代理类的实现。
提示词管理：将提示词从代码中分离出来，作为模板文件或数据库记录进行管理。支持变量插值、示例（few-shot）注入，便于迭代优化。
工具注册与调用：提供一个统一的装饰器或注册机制，让开发者能轻松地将Python函数“暴露”给LLM作为工具。框架负责生成符合OpenAI Function Calling或类似规范的函数描述。
会话与上下文管理：维护用户会话状态，处理对话历史的裁剪、总结和持久化，以应对模型的上下文长度限制。

核心服务层 (Core Service Layer)提供AI应用所需的底层能力：

模型抽象层：定义统一的接口来调用不同的LLM（如OpenAI GPT, Anthropic Claude, 开源Llama等）。这样，业务逻辑代码无需关心具体是哪个供应商的API。
向量数据库集成：为检索增强生成（RAG）场景提供与Chroma、Pinecone、Weaviate等向量数据库的连接器。
数据预处理管道：提供文档加载、文本分割、向量化嵌入的标准化流程。

基础设施层 (Infrastructure Layer)关注部署、监控和可观察性：

日志与追踪：集成像LangSmith、Phoenix或自定义的日志系统，记录每一次LLM调用、工具执行的输入输出、延迟和成本，便于调试和优化。
配置管理：通过环境变量或配置文件集中管理API密钥、模型参数、开关等。
部署模板：提供Dockerfile、docker-compose.yml或Kubernetes manifests示例，帮助应用快速容器化部署。

这种分层设计的好处是，开发者可以根据需求，选择性地使用AI-Compass中的某些模块，而不是被一个庞大的框架所绑架。

3. 关键组件深度解析与实操要点

3.1 提示词模板引擎：告别字符串拼接的混乱

在项目中硬编码提示词是灾难的开始。AI-Compass 通常会引入一个轻量级的模板系统。

核心实现思路：它可能使用类似Jinja2的语法，但更轻量。一个典型的提示词模板文件（prompts/query_rewrite.yaml）可能长这样：

name: "query_rewrite_for_retrieval" description: "将用户问题重写为更适合向量检索的格式。" template: | 你是一个专业的搜索查询优化助手。请将以下用户问题，在不改变原意的前提下，改写成更完整、包含关键实体、适合用于知识库检索的句子。 如果问题指代模糊（如“它”、“那个”），请根据对话历史进行消歧。 对话历史： {{ history | default('无') }} 用户当前问题：{{ query }} 优化后的查询： variables: - history - query

在代码中使用：

from aicompass.prompt_manager import PromptManager pm = PromptManager(prompts_dir="./prompts") rewrite_prompt = pm.get_prompt("query_rewrite_for_retrieval") filled_prompt = rewrite_prompt.render(history=chat_history, query=user_input)

> 注意：模板引擎的关键是“变量隔离”和“版本控制”。将提示词存为文件，意味着你可以用Git来管理它的迭代历史，可以方便地进行A/B测试（例如，同时维护query_rewrite_v1.j2和query_rewrite_v2.j2），而无需修改代码。

3.2 工具调用框架：安全地将世界赋予LLM

让LLM调用代码是质变的一步。AI-Compass 的工具框架需要解决三个问题：描述、路由、执行。

1. 工具描述：使用装饰器自动生成符合规范的JSON Schema。

from aicompass.tools import tool @tool def get_weather(city: str, country_code: str = "CN") -> str: """ 获取指定城市的当前天气情况。 Args: city: 城市名称，例如“北京”。 country_code: 国家代码，默认为中国“CN”。 Returns: 描述天气的字符串。 """ # 模拟或真实调用天气API return f"{city}的天气是晴朗，25摄氏度。"

装饰器会解析函数的文档字符串（Docstring）和类型注解，自动生成供LLM理解的工具描述，包括名称、参数说明和返回值。

2. 工具路由与执行：当LLM返回一个工具调用请求时（如{"name": "get_weather", "arguments": {"city": "上海"}}），框架需要：

在注册的工具列表中查找get_weather。
验证参数是否符合类型要求（这里city是字符串）。
安全地执行该函数（考虑超时、异常处理）。
将执行结果（字符串或结构化数据）格式化后返回给LLM进行下一步分析。

> 实操心得：工具设计的“单一职责”原则一个常见的错误是把一个工具做得太复杂。例如，设计一个search_and_summarize工具。这会导致LLM难以正确使用，且错误难以排查。更好的做法是拆分成两个工具：search_web(query)和summarize_text(text)。让LLM来协调多次调用，这更符合其推理特性，也使得每个工具更易于测试和维护。

3.3 会话与上下文管理：突破模型限制的智慧

模型的上下文窗口（如128K）是宝贵的资源。AI-Compass 的会话管理器需要智能地维护这段“记忆”。

核心策略包括：

自动截断：当对话轮数超过预设阈值或Token数接近上限时，丢弃最老的几轮对话。
智能总结：更高级的策略是，在需要截断时，不是简单丢弃，而是调用LLM将早期的对话历史总结成一段简短的摘要，然后将摘要和近期对话一起放入上下文。这能保留更长期的“记忆”。
外部记忆存储：对于需要永久或大规模记忆的场景，将会话中的关键信息（如用户偏好、事实陈述）提取并存储到外部数据库（如向量库或键值库），在需要时通过检索召回。

一个简单的实现片段：

class ConversationManager: def __init__(self, max_tokens=8000, summarization_model="gpt-3.5-turbo"): self.messages = [] self.max_tokens = max_tokens self.summarizer = summarization_model def add_message(self, role, content): self.messages.append({"role": role, "content": content}) self._maybe_compress() def _maybe_compress(self): if self._estimate_tokens() > self.max_tokens: # 策略1：简单移除最早的消息 self.messages.pop(0) # 策略2（更优）：将前N条消息总结为一条系统消息 # summary = call_llm_to_summarize(self.messages[:5]) # self.messages = [{"role": "system", "content": f"历史摘要：{summary}"}] + self.messages[5:]

> 注意事项：Token估算的准确性精确计算Token数需要依赖模型的Tokenizer。对于混合使用多种模型的应用，估算可能不准。一个实用的技巧是使用近似值（如1个英文单词≈1.3个Token，1个中文字≈2个Token），并设置一个比模型实际限制低10-20%的安全阈值，为系统提示词和可能生成的回复预留空间。

4. 从零开始：使用AI-Compass搭建一个智能客服助手

让我们通过一个具体的场景——构建一个能回答产品问题的客服助手——来串联AI-Compass的核心组件。这个助手需要能查询知识库（RAG），并在无法回答时建议转接人工。

4.1 环境准备与项目初始化

首先，假设AI-Compass以Python包的形式提供了一些核心模块。我们创建一个新项目。

# 创建项目目录 mkdir product-support-agent && cd product-support-agent python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装假设的AI-Compass核心库及其他依赖 pip install aicompass-core openai chromadb langchain-community # 注：aicompass-core 是假想的包名，实际可能是从GitHub克隆源码

项目结构规划如下，这体现了关注点分离：

product-support-agent/ ├── app.py # 主应用入口（FastAPI/CLI） ├── config.py # 配置管理 ├── agents/ # 代理逻辑 │ └── support_agent.py ├── tools/ # 工具定义 │ ├── __init__.py │ └── product_tools.py ├── prompts/ # 提示词模板 │ ├── rag_qa.yaml │ └── handoff.yaml ├── services/ # 核心服务（模型、向量库客户端） │ └── llm_service.py └── knowledge_base/ # 知识库处理脚本 └── ingest.py

4.2 构建知识库与RAG查询工具

1. 知识库预处理 (knowledge_base/ingest.py): AI-Compass 可能不直接处理文档加载和分割，但会推荐模式。我们使用LangChain社区工具（与AI-Compass理念兼容）来简化。

# knowledge_base/ingest.py from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma def create_knowledge_base(data_dir="./product_docs", persist_dir="./chroma_db"): # 1. 加载文档 loader = DirectoryLoader(data_dir, glob="**/*.txt", loader_cls=TextLoader) documents = loader.load() # 2. 分割文本 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) splits = text_splitter.split_documents(documents) # 3. 生成向量并存储 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectordb = Chroma.from_documents( documents=splits, embedding=embeddings, persist_directory=persist_dir ) vectordb.persist() print(f"知识库已创建，包含 {len(splits)} 个片段。")

2. 创建RAG查询工具 (tools/product_tools.py):

# tools/product_tools.py from aicompass.tools import tool from langchain_chroma import Chroma from langchain_openai import OpenAIEmbeddings # 初始化向量数据库连接（实际中应通过配置或依赖注入） embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectordb = Chroma(persist_directory="./chroma_db", embedding_function=embeddings) @tool def search_product_knowledge(query: str, k: int = 3) -> list: """ 从产品知识库中搜索与问题相关的信息。 Args: query: 用户的问题。 k: 返回的最相关片段数量，默认为3。 Returns: 一个列表，每个元素是一个包含‘content’（文本内容）和‘metadata’（来源）的字典。 """ docs = vectordb.similarity_search(query, k=k) result = [] for doc in docs: result.append({ "content": doc.page_content, "metadata": doc.metadata }) return result

4.3 定义客服代理与流程编排

1. 提示词定义 (prompts/rag_qa.yaml):

name: "support_agent_rag" template: | 你是一家科技公司“星辰科技”的智能客服助手。请根据以下提供的产品知识库信息，专业、友好地回答用户的问题。 如果知识库信息不足以完全回答问题，请基于已知信息给出部分答案，并明确说明哪些部分未知，建议用户提供更多细节或转接人工。 严禁编造知识库中不存在的信息。 知识库信息： {{ context }} 用户问题：{{ question }} 请用中文回答： variables: - context - question

2. 代理逻辑实现 (agents/support_agent.py):

# agents/support_agent.py from aicompass.agent import BaseAgent from aicompass.prompt_manager import PromptManager from services.llm_service import llm # 统一的LLM调用接口 from tools.product_tools import search_product_knowledge class SupportAgent(BaseAgent): def __init__(self): self.pm = PromptManager('./prompts') self.tools = [search_product_knowledge] # 注册可用工具 def run(self, user_question: str, conversation_history: list = None) -> str: # 1. 知识检索：调用工具 search_results = search_product_knowledge.invoke(user_question) # 将检索结果格式化为上下文字符串 context_str = "\n---\n".join([f"[来源：{r['metadata'].get('source', '未知')}]\n{r['content']}" for r in search_results]) # 2. 填充提示词模板 qa_prompt = self.pm.get_prompt("support_agent_rag") filled_prompt = qa_prompt.render(context=context_str, question=user_question) # 3. 调用LLM生成回答 # 这里使用AI-Compass抽象的llm服务，底层可以是OpenAI、Azure等 response = llm.chat_completion( model="gpt-4o-mini", messages=[{"role": "user", "content": filled_prompt}], temperature=0.1 # 客服场景要求低随机性 ) # 4. （可选）后处理：检查置信度，决定是否转人工 if self._low_confidence(response, context_str): # 可以触发另一个提示词，生成建议转人工的回复 handoff_prompt = self.pm.get_prompt("handoff_suggestion") handoff_response = llm.chat_completion(...) return handoff_response return response def _low_confidence(self, answer: str, context: str) -> bool: # 一个简单的启发式规则：如果回答中包含“我不知道”、“知识库中没有”等短语，且上下文信息很少 low_conf_phrases = ["无法回答", "知识库中未提及", "没有相关信息"] if any(phrase in answer for phrase in low_conf_phrases) and len(context) < 100: return True return False # 更复杂的实现可以训练一个分类器或调用LLM自身来评估回答的置信度。

4.4 集成与启动应用

最后，我们创建一个简单的FastAPI应用来暴露这个智能客服助手。

# app.py from fastapi import FastAPI, HTTPException from fastapi.middleware.cors import CORSMiddleware from pydantic import BaseModel from agents.support_agent import SupportAgent import uvicorn app = FastAPI(title="Product Support Agent API") app.add_middleware(CORSMiddleware, allow_origins=["*"]) # 生产环境应限制来源 agent = SupportAgent() class QueryRequest(BaseModel): question: str session_id: str = None # 用于跟踪会话 class QueryResponse(BaseModel): answer: str session_id: str @app.post("/query", response_model=QueryResponse) async def handle_query(req: QueryRequest): try: answer = agent.run(req.question) return QueryResponse(answer=answer, session_id=req.session_id or "default_session") except Exception as e: raise HTTPException(status_code=500, detail=f"Agent processing failed: {str(e)}") if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=8000)

现在，运行python app.py，你的智能客服助手就启动在http://localhost:8000了。你可以通过/query端点发送问题，它将自动检索知识库并生成回答。

5. 进阶话题与生产环境考量

5.1 可观察性与评估：你的AI应用在如何运行？

开发完成只是第一步。在真实用户使用中，你需要知道：

每次调用花了多少钱？（Token消耗）
回答的质量如何？（是否准确、有用）
哪个工具最常被调用？（功能使用情况）
用户问了什么我们答不上来？（发现知识缺口）

AI-Compass 应倡导或集成可观察性工具。一个基本的方法是结构化日志。

# 在llm_service.py中包装LLM调用 import time import json from openai import OpenAI class ObservableLLMService: def __init__(self): self.client = OpenAI() def chat_completion(self, model, messages, **kwargs): start_time = time.time() try: response = self.client.chat.completions.create( model=model, messages=messages, **kwargs ) end_time = time.time() latency = end_time - start_time # 结构化日志记录 log_entry = { "timestamp": start_time, "model": model, "input_messages": messages, "output_message": response.choices[0].message.content, "usage": dict(response.usage) if response.usage else {}, "latency_seconds": latency, "parameters": kwargs } # 写入文件、数据库或发送到监控系统（如LangSmith） self._emit_log("llm_call", log_entry) return response.choices[0].message.content except Exception as e: self._emit_log("llm_error", {"error": str(e), "model": model}) raise def _emit_log(self, event_type, data): # 实现你的日志输出逻辑，例如： print(json.dumps({"event": event_type, "data": data})) # 简单打印 # 或: logging.info(json.dumps(...)) # 或: requests.post('https://your-monitoring.com/ingest', json=...)

更专业的方案是集成像LangSmith这样的平台。AI-Compass 可以提供与LangSmith SDK的便捷集成，自动追踪每次LLM调用、工具执行，形成可视化的调用链，便于调试和成本分析。

5.2 测试策略：如何测试非确定性的AI应用？

测试传统软件可以断言输出等于预期值。测试LLM应用则困难得多，因为输出是概率性的。AI-Compass 应提供测试模式或指南。

1. 单元测试（工具与逻辑）：对于工具函数、提示词渲染、上下文管理逻辑等确定性部分，使用标准的单元测试。

def test_search_tool(): result = search_product_knowledge.invoke("如何重启路由器？") assert isinstance(result, list) assert len(result) > 0 assert "content" in result[0]

2. 集成测试（代理流程）：使用“模拟”（Mock）LLM。替换掉真实的LLM调用，返回预设的响应，来验证整个代理流程是否正确。

from unittest.mock import Mock, patch def test_agent_flow(): agent = SupportAgent() # 模拟search工具返回固定知识 with patch('tools.product_tools.search_product_knowledge.invoke') as mock_search: mock_search.return_value = [{"content": "按住路由器背面Reset按钮5秒。", "metadata": {}}] # 模拟LLM返回固定答案 with patch('services.llm_service.llm.chat_completion') as mock_llm: mock_llm.return_value = "请按住路由器背面的Reset按钮5秒钟来重启。" answer = agent.run("路由器怎么重启？") assert "Reset按钮" in answer mock_search.assert_called_once_with("路由器怎么重启？")

3. 评估测试（回答质量）：这是最挑战的部分。可以结合使用：

基于规则的检查：检查回答是否包含某些关键词、是否超过最大长度、是否避免了敏感词。
基于LLM的评估：使用另一个（通常是更强大或更便宜的）LLM作为“裁判”，根据问题、上下文和生成的回答，按照预设的标准（如相关性、准确性、完整性）进行评分。AI-Compass 可以提供这种评估链的模板。

5.3 部署与扩展：从原型到服务

部署模式：

Serverless函数：对于轻量级、偶发性的应用，可以将AI-Compass代理打包成云函数（AWS Lambda, Vercel Serverless Function）。注意冷启动问题和上下文长度限制。
容器化微服务：更通用的方式。使用AI-Compass提供的Dockerfile模板，将应用、依赖和模型（如果使用本地小模型）打包成镜像，通过Kubernetes或ECS进行编排管理。这便于水平扩展和版本回滚。
边缘部署：如果使用量化后的中小型开源模型（如Llama 3.1 8B），可以考虑使用ONNX Runtime或llama.cpp在边缘设备部署，减少延迟和API成本。AI-Compass 可以包含与Ollama、LocalAI等本地推理框架集成的示例。

扩展性考虑：

会话状态存储：在单机内存中存储会话状态无法水平扩展。需要将会话数据（对话历史、用户信息）存储到外部数据库，如Redis或PostgreSQL。
异步处理：对于耗时的任务（如文档处理、复杂推理），应设计为异步队列（使用Celery、RQ或基于Redis的队列），避免阻塞HTTP请求。
模型路由与负载均衡：前面提到的多模型路由，在生产中可以实现为一个独立的服务或中间件，根据实时负载、预算和性能指标动态分配请求。

6. 避坑指南与常见问题排查

在实际使用AI-Compass或类似模式开发时，以下是我踩过的一些坑和对应的解决方案。

问题1：提示词效果不稳定，时好时坏。

排查：首先检查提示词中是否包含了不必要的随机性指令（如“请发挥创造力”），在需要确定性的任务中，应将temperature参数设为0或接近0（如0.1）。其次，检查变量插值是否正确，有时模板渲染会意外引入多余空格或换行符，影响模型理解。
解决：建立提示词版本库，对任何修改都进行A/B测试。使用AI-Compass的提示词管理功能，可以轻松回滚到上一个稳定版本。对于关键任务，可以设计多个不同角度的提示词，让LLM生成多个候选答案，再通过一个“选择器”模型或规则选出最佳答案。

问题2：工具调用经常失败，LLM无法正确生成参数。

排查：检查工具函数的文档字符串（Docstring）是否清晰、格式规范。LLM（特别是GPT-4之前的模型）对复杂的参数描述理解能力有限。确保每个参数都有简单明了的说明和示例。
解决：
1. 简化工具：遵循“单一职责”原则。
2. 提供示例：在系统提示词中，加入一两个工具调用的完整示例（Few-shot Learning）。
3. 后处理验证：在框架层面，对LLM返回的工具调用参数进行严格的JSON解析和类型验证，如果失败，可以将错误信息反馈给LLM，让其重试（Retry）。AI-Compass的工具框架应内置这种重试机制。

问题3：RAG效果不佳，检索到的内容不相关。

排查：这是RAG系统最常见的问题。问题可能出在：
- 文档切分不当：块（Chunk）太大或太小，或者在不该断句的地方切开了。
- 检索策略单一：仅使用简单的相似性搜索（similarity_search），对于包含多个子问题或需要综合信息的查询效果差。
- 查询表述不佳：用户的问题可能太模糊。
解决：
1. 优化切分：尝试不同的文本分割器（如按语义分割的SemanticChunker），调整块大小和重叠区。
2. 增强检索：
  - 多路检索：同时使用相似性搜索和基于关键词的搜索（如BM25），然后合并结果。
  - 查询重写：在检索前，先用一个LLM将用户问题重写成更利于检索的格式（这正是前面示例中的query_rewrite提示词的作用）。
  - 重新排序：检索出较多结果（如k=10）后，使用一个更小的、专注于相关性的模型（如text-embedding-3-small的rerank模型）对结果进行重新排序，只取最相关的3-5个。
3. 迭代评估：构建一个包含“问题-标准答案-相关文档”的测试集，定量评估不同检索策略的命中率（Hit Rate）和平均精度（Mean Average Precision）。

问题4：应用响应慢，用户体验差。

排查：使用可观察性工具（如前面提到的日志）分析瓶颈。是LLM API调用慢？还是工具执行（如网络请求）慢？或者是检索向量数据库慢？
解决：
- 缓存：对频繁出现的、答案固定的问题（如“你们的客服电话是多少？”），可以将LLM的最终回答缓存起来（使用Redis）。甚至可以对嵌入向量进行缓存，避免对相同查询重复计算。
- 流式响应：对于LLM生成的长文本，务必使用流式接口（Server-Sent Events），让用户看到文字逐个出现，感知延迟会大大降低。AI-Compass 应在Web框架集成中提供流式响应的示例。
- 模型降级：在非核心推理步骤中使用更小、更快的模型。例如，查询重写、检索结果重新排序可以使用gpt-3.5-turbo或专门的小模型，只在最终答案生成时使用gpt-4。

问题5：成本失控。

排查：没有监控Token消耗和API调用次数。
解决：
1. 预算与限流：在应用层面为每个用户或每个会话设置Token预算和调用频率限制。
2. 使用小模型：在能够接受的精度损失范围内，尽可能使用更便宜的模型。gpt-4o-mini在成本和性能上往往是一个很好的平衡点。
3. 优化提示词：冗长的提示词会持续消耗Token。定期审查和精简你的系统提示词和少样本示例。
4. 上下文管理：如前所述，积极的历史对话总结和截断是控制成本的关键，因为输入Token通常比输出Token更贵。

开发AI应用是一场充满探索的旅程，而像AI-Compass这样的项目，其价值在于它提供了一张由社区共同绘制的、标注了常见陷阱和捷径的地图。它不会替你走完所有的路，但能让你起步更稳，方向更明，把更多精力集中在创造独特的业务价值上，而不是反复解决那些共性的工程难题。