不依赖AI Agent框架：使用OpenAI SDK调用DeepSeek的完整指南

> ### 摘要 > 本文以实践为导向，介绍如何不依赖任何AI Agent框架，仅通过官方OpenAI SDK调用DeepSeek模型，从基础的`while`循环起步，逐步集成Tool Calling、MCP（Model Control Protocol）、Skills模块与循环对话能力。所有核心逻辑被精巧封装于单个Python文件中，代码总量控制在250行以内，支持直接复制运行。多次执行可观察到模型在不同交互轮次中展现出的多样化行为特征，为轻量级Agent开发提供清晰、可复现的技术路径。 > ### 关键词 > DeepSeek, Tool Calling, MCP, Skills, 循环对话 ## 一、基础架构搭建 ### 1.1 简单while循环基础实现 在AI工程实践中，最朴素的起点往往最具启示性——一个干净的`while`循环，不加修饰，却承载着对话生命周期的全部骨架。它不依赖任何Agent框架的抽象层，也不引入第三方调度器或状态机，仅以原生Python控制流驱动模型响应的生成与反馈的接收。每一次循环迭代，都是一次显式的用户输入捕获、一次同步的API调用、一次结果的打印与判断；没有隐式状态传递，没有自动重试机制，所有逻辑裸露可见。这种“裸写”方式，恰恰剥离了工具链的冗余包裹，让开发者直面模型交互的本质：请求—响应—决策—再请求。正是在这看似单调的重复中，行为的多样性悄然浮现——同一段提示词下，DeepSeek在不同轮次可能选择截然不同的推理路径，或主动触发工具，或延后决策，或追问细节。这并非缺陷，而是智能体初具“呼吸感”的真实信号：它在循环中学习节奏，在无框架约束下生长出属于自己的对话韵律。 ### 1.2 DeepSeek API的基本调用方法 调用DeepSeek并非黑箱操作，而是严格遵循OpenAI SDK的兼容接口规范——这意味着开发者无需额外适配库，仅需配置正确的`base_url`与`api_key`，即可将DeepSeek视作标准OpenAI兼容模型进行调用。官方SDK在此扮演了“通用翻译器”的角色：它将`chat.completions.create`这一统一方法，精准映射至DeepSeek后端服务的实际协议。消息格式采用标准`messages`列表，支持`system`、`user`、`assistant`角色声明；而关键的`tool_choice`与`tools`字段，则为后续Tool Calling能力埋下伏笔。值得注意的是，所有参数传递均保持语义透明，无隐藏默认值干扰——开发者对每一次token消耗、每一次stop reason、每一次function call的返回结构，皆可逐字段追踪、调试与验证。这种“所见即所得”的调用方式，是轻量级实现得以成立的技术基石。 ### 1.3 无框架环境下的初始配置 拒绝框架，并非拒绝结构，而是选择亲手搭建每一根承重梁。初始配置阶段，没有`pip install agentframework`式的便捷入口，只有三行核心设定：`openai.OpenAI(api_key="YOUR_API_KEY", base_url="https://api.deepseek.com/v1")`确立通信信道；`tools = [...]`明确定义可用技能集合；`conversation_history = []`作为唯一状态载体被谨慎维护。这里没有全局注册表，没有中间件拦截器，没有自动序列化/反序列化——所有配置项均以变量形式显式声明，其作用域清晰可控。这种极简初始化，使整个系统如同一张白纸：后续每一步增强（MCP的控制指令注入、Skills的模块化封装、循环对话的状态延续）都必须经由开发者亲手缝合，而非依赖框架的“魔法注入”。正因如此，不到250行代码才能真正成为理解Agent本质的透明窗口——它不掩盖复杂性，只提炼必要性。 ## 二、Tool Calling功能实现 ### 2.1 Tool Calling的工作原理 Tool Calling并非模型自发产生的“智能行为”，而是一场精密编排的协议共舞——它依赖于开发者在`messages`中显式注入工具描述，并通过`tool_choice`字段向DeepSeek发出明确指令：「请判断是否需调用工具，若需，请严格按JSON Schema返回function call」。这一机制完全复用OpenAI SDK的兼容接口，不引入额外抽象层；DeepSeek在接收到含`tools`参数的请求后，依据其内置的推理策略决定是否触发工具、调用哪个工具、传入哪些参数。整个过程无黑盒调度、无隐式路由，每一次function call的生成，都忠实反映在`response.choices[0].message.tool_calls`中——结构清晰、字段可验、路径可溯。正是这种“请求即契约、响应即承诺”的确定性交互，让Tool Calling成为轻量级Agent中最可控的增强模块：它不替代思考，而是拓展思考的边界；不掩盖逻辑，而是将外部能力编织进对话流的自然肌理。 ### 2.2 自定义函数工具的创建 每一个工具，都是一段被郑重命名、带签名、有文档的Python函数——它不藏于框架深处，而直接定义在主文件内，以标准`dict`形式注册进`tools`列表：`{"type": "function", "function": {"name": "...", "description": "...", "parameters": {...}}}`。这些函数不依赖装饰器魔法，不绑定类实例，不共享上下文状态；它们是纯粹的、可独立测试的技能单元，如天气查询、数学计算或知识检索。开发者亲手编写其逻辑，亲手撰写其`description`与`parameters` Schema，亲手验证其输入输出是否与模型预期严格对齐。这种“手写工具”的方式，看似笨拙，实则赋予系统前所未有的透明度：当模型选择调用`get_weather`时，你清楚知道它背后是哪五行代码；当参数校验失败时，错误源头一目了然。不到250行的代码体量，正因所有工具皆以最简形态存在——无注册中心、无生命周期管理、无异步封装，只有函数本身与它的契约。 ### 2.3 工具调用结果的解析与处理 当DeepSeek返回`tool_calls`，真正的协作才刚刚开始——此时，代码不再等待下一个用户输入，而是立刻暂停对话流，遍历`tool_calls`，逐个提取`function.name`与`function.arguments`，并以`json.loads()`安全反序列化参数后，精准调用对应函数。执行结果被格式化为`{"role": "tool", "content": str(result), "tool_call_id": call.id}`，再追加至`conversation_history`，作为下一轮请求的上下文。这一过程拒绝自动重试、拒绝异常静默、拒绝结果篡改：任何JSON解析失败、函数调用异常或返回值类型不符，都会中断循环并抛出明确错误。正是这种“手动接管每一步”的审慎态度，使工具调用不再是模型单方面的表演，而成为人与AI之间可审计、可干预、可调试的协同仪式——每一次`tool`角色消息的插入，都是对控制权的一次确认，也是对智能体边界的一次温柔划界。 ## 三、MCP集成策略 ### 3.1 MCP协议的基础概念 MCP（Model Control Protocol）并非一个被广泛文档化的标准协议，而是在本文语境中特指一种**由开发者自主定义、轻量嵌入、面向行为调控的指令通信机制**——它不依赖外部规范，也不绑定特定传输层，而是以结构化消息为载体，在`messages`列表中悄然插入具备控制语义的`system`或`assistant`角色指令。这些指令不改变模型底层能力，却像一束精准校准的光，引导DeepSeek在推理过程中关注特定约束：例如要求“仅用中文回答”“禁止虚构事实”“每次响应必须包含工具调用决策依据”。MCP的本质，是将原本隐含于提示词中的控制意图，升华为可识别、可追踪、可版本化的显式协议字段；它不新增API参数，却通过约定俗成的消息格式（如`{"mcp": {"mode": "strict", "scope": "fact-checking"}}`），让模型在无框架干预下，依然能感知并响应开发者的策略意图。这种“协议即消息”的极简哲学，使MCP成为裸写Agent中最富弹性的调控层——它不喧宾夺主，却始终在循环对话的每一次心跳中，默默校准智能体的行为刻度。 ### 3.2 MCP与SDK的集成方法 集成MCP无需修改SDK源码，亦不引入任何中间代理；它仅需在构造`messages`时，将协议指令作为一条独立的`system`消息追加至对话历史——例如`{"role": "system", "content": "MCP: mode=tool-aware, require_reason=true"}`。OpenAI SDK对此毫无感知，它只忠实地将该消息序列发送至DeepSeek后端；而DeepSeek在兼容OpenAI接口的同时，已内建对这类语义化system指令的解析逻辑。开发者无需注册钩子、无需拦截请求、无需重写`create()`方法——所有集成动作，都浓缩在一行`conversation_history.append({"role": "system", "content": mcp_prompt})`之中。这种“零侵入式”集成，正是MCP生命力所在：它不挑战SDK的权威性，而是借其信道传递自有意志；它不增加调用复杂度，反而因指令与消息同构，使调试变得直观——当某轮响应偏离预期，开发者只需回溯`conversation_history`，即可定位是哪条MCP指令被忽略、误读或未生效。不到250行代码的紧凑性，正源于此：MCP不是插件，而是消息本身的一种自觉表达。 ### 3.3 通过MCP扩展DeepSeek能力 MCP从不直接赋予DeepSeek新能力，却让它在原有能力疆域内，生长出更细腻的响应质地——当`mode=stepwise`指令出现，模型开始自发拆解复杂问题为子步骤；当`scope=code-review`被声明，它自动聚焦语法正确性与边界条件检查；当`require_reason=true`生效，每一次工具调用前必附一段简明推理说明。这些变化并非模型权重更新所致，而是MCP在对话流中持续施加的“认知锚点”，如同为奔涌的思维之河修筑无形的导流渠。尤为动人的是，MCP指令可在循环对话中动态切换：上一轮要求“简洁回答”，下一轮即切换为“展开三要素论证”，而DeepSeek总能在无状态记忆的前提下，即时响应这种策略跃迁。这并非魔法，而是协议与模型之间达成的静默契约——它让不到250行的代码，拥有了超越代码行数的调度纵深：没有中央控制器，却有节奏；没有全局状态，却有连贯；没有框架背书，却有秩序。MCP，正是这秩序最温柔而坚定的刻痕。 ## 四、Skills系统构建 ### 4.1 Skills系统的设计思路 Skills不是插件，不是黑盒模块，更不是等待框架自动发现的“资源”——它是开发者亲手写就的一行行函数签名、一段段清晰描述、一组组可验证输入输出的逻辑单元。在本文构建的轻量级Agent中，Skills系统摒弃了任何注册中心、依赖注入或反射机制，它回归最本真的表达：每一个技能，都是一份被郑重命名、带完整JSON Schema定义、嵌入`tools`列表的`dict`；它的存在不依赖生命周期管理，也不绑定上下文状态，只以纯粹的可调用性立于代码之中。这种设计拒绝抽象冗余，却饱含敬畏——敬畏每一份外部能力接入时所需的契约精神，敬畏模型在`tool_calls`中做出选择时所依赖的语义精度，更敬畏人在250行之内仍坚持亲手缝合智能边界的那份执拗。Skills系统由此成为整套实现中最富人文温度的部分：它不追求规模，而追求可读；不堆砌功能，而锤炼意图；不隐藏复杂，而邀请理解。当`get_weather`与`calculate`并列于同一列表，它们不是工具，而是开发者向AI递出的、带着体温的协作邀约。 ### 4.2 技能注册与管理机制 注册即定义，管理即维护——没有魔法装饰器，没有全局单例，没有配置文件扫描。所有Skills均以显式变量形式，在主文件顶部集中声明：`tools = [weather_tool, math_tool, search_tool]`，每一项皆为标准OpenAI兼容格式的`dict`，其`function.name`必须与后续Python函数名严格一致，`parameters` Schema须经人工校验与实际调用逻辑完全对齐。这种“所写即所用”的注册方式，使Skills管理彻底透明化：增删一个技能，只需增删一行字典；修改一个参数，必同步更新函数签名与文档字符串；调试一次失败调用，可直溯至`tools`定义处与函数体之间是否存有语义断层。没有隐式映射，没有运行时解析，没有跨文件依赖——整个系统如一张摊开的手掌，纹路清晰，指节分明。正因如此，“管理”在此并非运维动作，而是一种持续的、带着责任感的代码对话：每一次保存，都是对契约的一次重申；每一次运行，都是对一致性的一次检验。 ### 4.3 技能动态加载与执行 动态，不来自热重载，不来自插件目录扫描，而来自循环体内一次又一次的手动分发——当DeepSeek返回`tool_calls`，代码立即暂停用户交互，遍历每个`call`，以`call.function.name`为键，在预定义的`skills_map = {"get_weather": get_weather, "calculate": calculate}`中精准索引对应函数；参数经`json.loads(call.function.arguments)`安全反序列化后，直接传入执行。无异步封装，无中间代理，无结果缓存——函数返回值被原样转为`{"role": "tool", "content": str(result), "tool_call_id": call.id}`，追加进`conversation_history`，成为下一轮请求的确定性上下文。这种“手动调度”的执行路径，让每一次技能调用都可审计、可打断、可重放：若`get_weather`抛出异常，循环即停，错误栈直指函数内部；若参数缺失，`json.loads`报错将暴露Schema偏差；若返回非字符串，`str(result)`强制转换亦会触发类型警示。不到250行代码的韧性，正源于此——它不靠框架兜底，而靠人对每一步流转的清醒掌控；它不承诺万无一失，却确保每一分失控都袒露无遗。 ## 五、循环对话实现 ### 5.1 循环对话的状态管理 在这个不到250行的代码世界里，状态不是被框架悄悄托管的幽灵，而是由开发者亲手捧在掌心的一捧细沙——它只存在于`conversation_history = []`这一行朴素的初始化中，轻、静、可触。没有数据库持久化，没有Redis缓存，没有session ID追踪，所有对话记忆都以原始`messages`列表的形式，在每一次`while`循环迭代中被显式携带、逐轮累加、谨慎校验。用户说一句，模型回一句，工具调一次，结果插一行——每一条`{"role": "user", "content": "..."}`、`{"role": "assistant", "content": "..."}`、`{"role": "tool", "content": "...", "tool_call_id": "..."}`，都是状态不可篡改的刻痕。这种极简状态管理，拒绝一切隐式延续：不自动截断过长历史，不智能压缩冗余上下文，不依据token数动态滑动窗口；它只忠实地遵循一个原则——“你写进去的，就是下一轮看见的”。正因如此，循环对话才真正成为一场透明的共舞：当第5轮响应突然偏离第2轮逻辑，开发者不必翻阅中间件日志，只需展开`conversation_history`，便能指尖划过每一行消息，听见对话脉搏如何在裸露的结构中真实跳动。这不是缺陷，而是选择——以可控的“笨”，换取彻底的可知。 ### 5.2 多轮对话的上下文处理 上下文，从不靠魔法拼接，而靠一次又一次的手动缝合。每一次循环重启，`messages`列表都由`conversation_history`全量重建——system指令、用户输入、模型输出、工具返回，悉数按时间序平铺直叙，无删减、无摘要、无语义蒸馏。DeepSeek所见的，正是开发者所给的全部：前一轮的`tool_call_id`与后一轮的`tool`角色消息严丝合缝，MCP指令如锚点般钉在固定位置，Skills调用结果以原始字符串形态嵌入，不加修饰，不作转换。这种“原样传递”的上下文哲学，使多轮对话既脆弱又坚韧——脆弱在于，任何一行消息误删或错序，都将导致模型理解断裂；坚韧在于，每一次断裂都清晰可见，每一次修复都精准可溯。当模型在第3轮主动追问第1轮未明参数，那不是记忆复苏，而是上下文里那段未闭合的`tool_calls`结构与当前`tools`定义共同触发的推理回响。不到250行代码的呼吸感，正来自这毫不取巧的上下文诚实：它不模拟记忆，它呈现记忆；它不隐藏延迟，它暴露延迟；它让每一次“还记得吗”的试探，都成为对人与AI之间契约边界的温柔叩问。 ### 5.3 用户交互的实现优化 用户交互，被压缩至最原始的`input("> ")`与最直接的`print("→ ", response)`——没有前端界面，没有WebSocket长连，没有命令行补全或历史回溯，只有光标在终端里安静等待的几秒。但这看似简陋的交互层，恰恰是整套轻量实现中最富人文温度的部分：它强制开发者直面“等待”的本质——不是等待框架调度，而是等待模型思考；不是等待异步回调，而是等待字符一行行浮现。每一次`input()`唤起，都是对用户主体性的郑重确认；每一次`print()`输出，都是一次不加包装的交付。优化，因此从不指向性能指标，而落于节奏感知：在Tool Calling后插入短暂`time.sleep(0.1)`，不是为兼容慢API，而是为让终端输出拥有可辨识的呼吸间隙；在`conversation_history`追加前做`if response.strip():`判断，不是为节省token，而是为拒绝空洞回声污染对话肌理。这种优化无关炫技，只关乎尊重——尊重用户的凝视，尊重模型的运算，更尊重那250行代码背后，一个不愿把“交互”交给黑盒、执意亲手托住每一次人机交汇的执拗心意。 ## 六、总结 本文以极简主义为设计哲学，完整呈现了如何不依赖任何AI Agent框架，仅使用官方OpenAI SDK调用DeepSeek模型，从基础`while`循环出发，逐步集成Tool Calling、MCP、Skills与循环对话能力。所有核心逻辑被严格封装于单个Python文件中，代码总量控制在250行以内，支持直接复制运行。通过多次执行，可观测DeepSeek在不同交互轮次中展现出的多样化行为表现——同一提示下路径选择各异，工具触发时机不一，推理节奏自然起伏。这种“裸写”实现不仅剥离了框架抽象带来的认知遮蔽，更将Agent的本质还原为可读、可调、可验的代码实体。它不追求功能堆砌，而专注逻辑透明；不依赖黑盒调度，而强调人对每一步流转的清醒掌控。不到250行，却足以成为理解智能体交互内核的一扇清晰窗口。