Jacin Blog

AI 大模型开发

分类下的全部文章

AI 大模型开发
22 分钟

OpenAI工具调用

这篇笔记围绕 OpenAI Chat Completions 的工具调用机制，说明模型如何在收到 messages 与 tools 定义后，通过 tool_calls 返回要调用的函数名和参数，再由本地代码执行函数并把结果回填给模型生成最终回答。示例从“北京天气”查询入手，给出 get_weather 的工具 schema 写法，包括 function name、description、parameters、required 等字段，并展示 tool_choice="auto" 下模型自行判断是否调用工具的流程。实现部分使用 AsyncOpenAI 封装流式服务，先非流式请求检测 tool_calls，解析 JSON 参数、执行本地函数，再按 assistant 的 tool_calls 记录和 tool 角色消息补齐上下文，最后二次 stream 请求输出自然语言结果，强调 tool_call_id 必须与原调用保持对应。后半部分把单个函数判断抽象为 BaseTool 注册器，通过类变量 registry 管理工具，利用 inspect.signature 自动生成参数 schema，并提供 register、call、acall 等方法支持同步和异步调度。笔记还解释了 @classmethod 的作用，说明类方法适合用于工具注册、访问类变量和无需实例化的统一管理，并与 staticmethod、普通实例方法做了对比。整体适合正在把 OpenAI 工具调用接入 Python 后端、需要理解消息拼接顺序、工具 schema 生成和函数调度封装的开发者阅读。

AI 大模型开发
15 分钟

FastAPI-MCP

这篇笔记聚焦 fastapi-mcp 在 FastAPI 与大模型工具调用之间的衔接方式，说明它如何把现有 API 端点转换为符合 MCP 的工具描述，让 Coze、通义、百川、智谱等平台更容易识别接口能力。内容先给出服务端示例：使用 FastApiMCP 挂载到 /mcp，接口通过 Pydantic 模型定义请求体，并显式设置 operation_id，同时可额外暴露 openapi.json 供客户端读取。文章强调 operation_id 是外部调用时定位接口的唯一标识，不能依赖 FastAPI 自动生成的冗长默认值；请求方法、请求体结构、description、summary 等信息也会影响大模型是否能准确理解参数。随后它拆解 MCPClient 的实际工作流程：先获取 openapi.json，根据 operation_id 找到路径和方法，再组装并发送普通 HTTP 请求，因此 MCP 并不是替代 HTTP 的新传输协议，而是面向大模型的 OpenAPI 子集和调用约定。后半部分用 OpenAI 兼容的 tool call 示例说明，大模型通常只生成函数名和参数，不会自动替开发者请求本地接口。要形成完整闭环，仍需要中转层或代理服务负责执行 HTTP 调用、把工具结果写回 messages，并再次请求模型生成最终回复；LangChain、Flowise 或自建代理可以承担这类自动执行逻辑。

fastapimcp
类openai基本对话代码
AI 大模型开发
11 分钟

类openai基本对话代码

这份笔记围绕 Python 异步项目中封装类 OpenAI Chat 接口的基础用法展开，场景是通过 one-api 统一管理不同模型服务后，在业务代码里只需关注 model 参数切换具体模型。代码使用 AsyncOpenAI 初始化客户端，并提供两个常用方法：gpt_stream 以异步生成器方式开启 stream=True，逐块 yield 模型返回内容；gpt_chat_no_stream 则一次性获取回复，适合普通问答或需要结构化结果的调用。非流式函数还演示了 JSON 输出的处理方式，包括在 system 提示中强调只返回 JSON、设置 response_format，以及对返回内容执行 json.loads。文章同时说明 Chat 接口的 messages 结构由 system、user、assistant 三类角色组成，推荐将 system 放在最前，历史对话按时间顺序追加，再放入当前用户输入。需要注意的是，历史记录可以帮助模型延续上下文，但不应重复塞入 system 指令，过长历史也会增加 token 成本，因此应根据业务做裁剪或摘要。整体适合正在把大模型能力接入后端服务、需要同时支持流式输出和结构化返回的开发者参考。

openai对话代码
多段AI记忆拼接与上下文压缩(初步)
AI 大模型开发
12 分钟

多段AI记忆拼接与上下文压缩(初步)

这份草稿围绕 AI 对话系统中的长期记忆与上下文压缩展开，目标是在多轮聊天中兼顾相关历史召回、上下文长度限制、响应延迟和存储成本。方案把一次请求链路拆成 MemoryRetriever、ContextManager、PromptBuilder、GPTClient、MemoryUpdater 等模块：先按用户输入检索多段记忆，再用滑动窗口裁剪近期对话，必要时调用 Summarizer 压缩溢出内容，最后拼接 system、memory、window、user 形成模型 messages，并把回复或摘要写回 MemoryStore。实现细节强调在消息记录中预存字符数或 token 数，从最近 5 轮对话取 5 条用户消息和 5 条 AI 回复，按时间排序后累加长度，以较低遍历成本避免单条长消息撑爆上下文。摘要策略部分比较了按回合生成 memory_segment、让主模型同次输出 answer 与 summary、以及后台 Worker 异步调用廉价模型摘要三种做法。草稿也指出工程上的取舍：同步摘要更简单但可能增加延迟，异步摘要能保留流式体验并通过固定条数淘汰控制规模，格式异常时还需要客户端校验和降级。它适合作为聊天产品、AI 应用后端或 Agent 记忆系统的初步设计参考，帮助评估上下文完整性、检索粒度、调用成本和实现复杂度之间的平衡。

上下文记忆拼接
AI 大模型开发
6 分钟

openai流式解析

这篇笔记聚焦 Python 中 OpenAI Chat Completions 的异步流式调用，适用于希望把模型响应按片段实时输出到终端或业务层的开发场景。内容先从环境变量读取入手，强调用 os.getenv 获取 OPENAI_API_KEY、OPENAI_BASE_URL 和 OPENAI_MODEL，并说明 python-dotenv 的安装包名与导入模块名不同：通过 pip install python-dotenv 安装，但代码中从 dotenv 导入 load_dotenv。核心示例封装了一个 AsyncOpenAIOut 类，在初始化阶段创建 AsyncOpenAI 客户端，在 gpt_stream 方法中组合 history、system_prompt 和用户消息，并以 stream=True 发起请求。代码通过 async for 遍历 OpenAI 返回的流式 response，检查 chunk.choices[0].delta.content 后用 yield 逐块产出内容，因此调用方也需要用 async for 消费这个异步生成器。文章还补充了 print(chunk) 在事件循环中的行为：它是同步执行，但在简单逐步输出场景通常可接受；若希望更严格地避免占用事件循环，可以用 asyncio.to_thread(print, chunk) 放到后台线程执行。整体价值在于把 .env 配置、AsyncOpenAI 初始化、消息组装、流式响应解析和 async for/yield 的语义串成一个可运行样例，适合正在接入 OpenAI 兼容接口或学习 Python 异步流处理的开发者。

openai流式
AI 大模型开发
1 分钟

关于“AI 大模型开发”类别

“AI 大模型开发”类别用于为与大模型应用、工程实现和开发实践相关的内容建立清晰归档入口，重点服务于需要快速判断文章是否属于该主题的分类选择场景。该类别说明强调先给出简短定位，再通过更完整的准则解释设立理由、使用目的、与既有类别的边界以及可收录的话题范围。它关注的不只是命名本身，还包括分类是否会与其他类别重叠、是否应作为独立类别保留，以及在维护成本和检索便利之间如何取舍。适合纳入的内容应围绕 AI 大模型开发这一主题展开，而不应仅因泛泛提到 AI 或工具名称就归入其中。对站点维护者来说，这类说明的价值在于统一收录标准，减少后续文章分类时的随意性和重复归档。对于读者而言，清晰的类别定位也有助于在浏览知识库时判断这里是否集中呈现大模型开发相关的实践、规则和经验。