前几周在团队内部尝试把 Grok 接入聊天机器人时遇到了不少细节问题API 调用方式、上下文管理、群聊里如何用 触发、如何避免回答串台、如何控制成本和超时。查了很多资料大多只讲了单点用法缺少一套从零到一、可直接落地的完整流程。这篇文章会把我在实际搭建 Grok bot 过程中用到的方案、代码和排错思路整理出来希望能帮你少走一些弯路。1. 背景与核心概念为什么要做一个 Grok bot1.1 Grok 是什么为什么选择它Grok 是由 xAI 推出的大语言模型产品主打实时信息获取、逻辑推理和自然对话。和很多通用助手相比Grok 在长文本理解、代码生成、结构化输出以及对“对话上下文”的把握上都有不错的表现。不过直接打开网页或客户端使用 Grok和把它接入到我们日常工作的聊天工具中是两种完全不同的体验。前者适合个人问答后者适合团队协作和自动化流程。当你需要频繁把一段报错、一段日志、一段需求描述丢给模型时打开网页再复制粘贴的效率很低。更理想的方式是在团队已经使用的 IM 工具里 一下机器人直接把问题抛出去几秒钟后拿到答案。这就是本文要讲的 Grok bot 场景。1.2 bot 的工作方式所谓 bot是指在聊天群或频道中通过“机器人用户名”的形式唤起机器人响应。它在工作方式上和普通聊天机器人没有本质区别核心链路如下用户在群聊中发送消息并在消息中 了机器人。聊天平台Telegram、飞书、钉钉、Discord 等把这条消息通过 Webhook 或轮询方式推送给 Bot 服务。Bot 服务判断消息中是否包含对机器人的提及mention。如果包含则从消息中提取用户真正想提问的内容。Bot 服务把提问内容发送给 Grok API获取回答。Bot 服务再把回答返回给聊天平台展示在群聊中。可以看到bot 只是消息路由和触发的机制真正的“智能”来自 Grok 模型本身。我们写的代码主要解决三件事接收消息、调用模型、发送回答。1.3 这个方案解决什么问题在技术团队中Grok bot 可以承担很多日常工作例如团队新人提问在群里 机器人询问某段代码的含义、某个框架的概念减少重复答疑。运维排查把报错信息、日志片段发给机器人快速获得排查建议。代码审查辅助让机器人对一段提交代码做静态逻辑分析或风格建议。日常写作与格式化把草稿文本发给机器人让它整理成 Markdown、表格或要点。自动生成模板PR 描述、周报、接口文档都可以通过 机器人生成初稿。从“效率提升”的角度看最大的变化是减少了工具切换和上下文丢失。你在聊天工具里直接拿到结果而且可以连续追问模型会记住前面的对话内容。1.4 需要区分的概念在开始之前有必要区分几个容易混淆的名词名词含义GrokxAI 推出的大语言模型产品/APIGrok BuildGrok 生态中偏工具化/工程化的一类应用具体能力随版本迭代变化较快需以官方发布说明为准Bot运行在聊天平台上的机器人程序接收消息并自动回复bot用户在群里通过 符号唤起机器人的交互方式此外近期网络上关于“Grok Build 1.0.7 上线”“Grok Build v1.0.9 发布”等信息说明 Grok 相关工具链更新节奏很快。对普通开发者来说不需要追求每个版本都跟进只要掌握核心 API 接入方式和 Bot 工程化思路后续升级只是替换模型名或参数的问题。2. 环境准备与版本说明2.1 开发环境本文的示例代码使用 Python 编写这是生态最成熟、示例最多的语言之一。你在本地需要准备Python 3.9 及以上版本推荐 3.10pip 包管理工具一个聊天平台开发者账号用于创建 BotGrok API Key用于调用模型接口版本需要根据你的项目实际情况调整。我本地的示例环境如下但你不必完全一致操作系统macOS 14 / Ubuntu 22.04Python3.10Bot 框架aiogram 3.xTelegram Bot 框架HTTP 客户端httpx支持同步和异步代码编辑器VS Code2.2 获取 Grok API Key要调用 Grok 模型需要先到 xAI 官方开放平台具体入口以官方文档为准注册账号并创建 API Key。创建 API Key 时有几个建议Key 只显示一次创建后要立刻复制保存。不要把 Key 提交到 Git 仓库。建议在平台侧设置消费上限或额度提醒避免异常调用产生高额费用。不同模型的定价不同调用前先看一眼计费页面。2.3 选择聊天平台不同团队使用的 IM 工具不同我在这里以最常见的几类为例平台开发复杂度适用场景Telegram低Bot 生态完善海外团队、开源项目飞书中应用市场完善国内企业、技术团队钉钉中需要配置机器人安全设置国内企业、电商/运营团队Discord低Bot API 友好游戏社区、海外社群微信生态高且有平台合规风险不建议个人开发者直接使用非官方接口需要特别提醒如果你所在团队使用微信类工具请优先使用企业微信官方机器人接口不要使用个人号或非官方协议否则有封号风险和合规风险。本文示例以 Telegram 为主因为它的 Bot API 最简单几乎不需要企业认证适合学习飞书/钉钉的接入逻辑类似只是 API 形式不同。2.4 安装 Python 依赖创建一个新的 Python 虚拟环境mkdir grok-bot cd grok-bot python3 -m venv venv source venv/bin/activate然后安装依赖pip install aiogram3.7.0 httpx0.27.0如果你用的是飞书或钉钉则不需要 aiogram改用它们的官方 SDK 或直接调用 Webhook API。为了便于展示本文会先写一个 Telegram 版本再给出一个通用 Flask Webhook 版本供参考。3. 核心原理拆解Grok API 与 Bot 消息机制3.1 Grok API 的基本调用方式Grok API 兼容 OpenAI 风格的 Chat Completions 接口。这意味着只要你熟悉 OpenAI API就能很快上手 Grok。基本请求格式如下接口地址https://api.x.ai/v1/chat/completions以官方文档为准请求头Authorization: Bearer API_KEY请求体包含model、messages、temperature等参数一个最简单的同步调用示例import httpx API_KEY 你的 API Key URL https://api.x.ai/v1/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } data { model: grok-2-latest, # 模型名以你账号下实际可用模型为准 messages: [ {role: system, content: 你是一个乐于助人的技术助手。}, {role: user, content: 用一句话解释 Python 的 GIL。}, ], temperature: 0.7, } with httpx.Client(timeout30) as client: resp client.post(URL, headersheaders, jsondata) resp.raise_for_status() result resp.json() print(result[choices][0][message][content])这里有几个关键点需要解释model参数不同时间段可用的模型名会变化比如grok-2、grok-2-latest、grok-3等等。不要写死某个版本建议从环境变量读取。messages参数这是对话上下文的核心。system消息用于设定机器人人格和规则user消息是用户输入assistant消息是模型之前的回答。多轮对话就是把历史消息按顺序放进去。temperature参数控制随机性0 到 1 之间。代码生成建议 0.2 左右创意写作可以 0.8。timeout网络请求必须有超时否则一旦 API 响应慢Bot 会一直卡住。3.2 Bot 如何感知 提及在 Telegram 中Bot 默认只能收到两种消息用户直接与 Bot 私聊时发送的消息。群聊中用户 Bot 时发送的消息前提是 Bot 的 Privacy Mode 没有关闭。这里的关键点是“”触发。在 Telegram 群聊中如果用户直接发消息不加 Bot 默认收不到。如果用户输入my_grok_bot 你好Bot 就能收到这条消息并且消息对象里会带上实体信息标注bot_command、mention等类型。我们在代码里要做两件事从消息文本中提取出真正要提问的内容去掉 用户名。判断消息是否真的提到了当前 Bot。aiogram 提供了简化处理。消息对象message.mention或message.text可以用来判断。下面这段逻辑比较通用from aiogram.types import Message def extract_prompt(message: Message) - str | None: if not message.text: return None text message.text.strip() # 私聊场景直接使用消息文本 if message.chat.type private: return text # 群聊场景必须包含 机器人 bot_username (await bot.me()).username if f{bot_username} not in text: return None # 去掉 用户名得到真正的提问内容 prompt text.replace(f{bot_username}, ).strip() return prompt这段代码的逻辑很直观先判断是否私聊再判断群聊中是否包含当前机器人的 最后从文本中移除 部分得到干净的用户提问。3.3 上下文管理这是让 bot 真正“好用”的关键。如果你每次调用 Grok API 都只传当前这一条消息那模型就不知道前面聊了什么。举例来说用户问“帮我写一个 Python 函数判断一个字符串是不是回文。”Bot 回复了代码。用户接着说“那再帮我加一个递归版本。”如果第二条消息没有带上第一条的上下文模型会一脸茫然。正确的做法是维护一个“会话历史”把之前的对话内容存下来在调用 API 时一起传入。常见的存储方式有三种存储方式优点缺点内存字典实现简单适合单机服务重启丢失多实例无法共享Redis支持分布式速度快需要额外部署 RedisSQLite/数据库持久化可回溯查询慢需要建表对于团队内部小规模使用内存字典就够了如果是多实例部署或希望持久化建议用 Redis。下面给出一个简单内存版上下文管理类import time from collections import defaultdict, deque class ConversationMemory: def __init__(self, max_len20, ttl1800): self.max_len max_len self.ttl ttl self.data defaultdict(lambda: {messages: deque(maxlenmax_len), last_time: 0}) def _cleanup(self, chat_id: str): item self.data[chat_id] if time.time() - item[last_time] self.ttl: item[messages].clear() item[last_time] time.time() def add(self, chat_id: str, role: str, content: str): self._cleanup(chat_id) self.data[chat_id][messages].append({role: role, content: content}) def get(self, chat_id: str): self._cleanup(chat_id) return list(self.data[chat_id][messages])这里的max_len表示最多保留多少条历史消息ttl表示会话多长时间没互动就自动清空。这样做可以避免上下文无限膨胀也方便释放内存。3.4 系统提示词的设计在调用 Grok 时system消息决定了机器人的行为边界。一个合理的系统提示词可以大幅提升回答质量。以技术团队场景为例你是一个技术团队助手叫 Grok Helper。 你的职责是回答编程、运维、架构相关问题。 回答要求 1. 优先给出可执行的解决方案代码要完整。 2. 如果问题信息不完整先指出缺失信息再给假设方案。 3. 涉及生产环境变更、数据库操作时必须提醒风险和备份。 4. 回答使用中文代码块标注语言。 5. 如果用户要求做违法或危险操作礼貌拒绝。这段系统提示词并不复杂但它在实际使用中非常重要它让模型在回答数据库修改、生产环境操作时主动带上安全提醒。4. 完整实战搭建一个 Grok botTelegram 示例下面开始搭建一个最小可用版本。这个示例会包含Bot 启动与监听。私聊消息直接回复。群聊消息通过 触发。调用 Grok API。维护多轮对话上下文。错误处理与超时。4.1 创建项目结构grok-bot/ ├── .env ├── requirements.txt ├── bot.py ├── grok_client.py └── memory.py4.2 安装依赖与配置requirements.txt内容如下aiogram3.7.0 httpx0.27.0 python-dotenv1.0.1.env文件存放敏感配置BOT_TOKEN123456:ABC-YourTelegramBotToken GROK_API_KEYxai-YourGrokApiKey GROK_MODELgrok-2-latest注意.env文件一定不要提交到 Git建议添加到.gitignore。4.3 编写 Grok 客户端grok_client.py封装对 Grok API 的调用使用异步 httpximport os import httpx class GrokClient: def __init__(self, api_key: str, model: str): self.api_key api_key self.model model self.base_url https://api.x.ai/v1/chat/completions self.headers { Authorization: fBearer {api_key}, Content-Type: application/json, } async def chat(self, messages: list[dict], temperature: float 0.7): payload { model: self.model, messages: messages, temperature: temperature, stream: False, } async with httpx.AsyncClient(timeout60) as client: try: resp await client.post(self.base_url, headersself.headers, jsonpayload) resp.raise_for_status() data resp.json() return data[choices][0][message][content] except httpx.HTTPStatusError as e: # 这里把 HTTP 错误转成更友好的异常方便上层处理 raise RuntimeError(fGrok API 返回错误: {e.response.status_code} - {e.response.text}) from e except httpx.TimeoutException as e: raise TimeoutError(Grok API 响应超时) from e这里有几点值得说明timeout60因为大模型生成需要时间60 秒是比较稳妥的值。如果群聊消息很多可以调小并配合“排队”机制。streamFalse关闭流式输出实现最简单。如果想要更好的交互体验可以改成流式后面进阶部分会提到。异常处理把 HTTP 错误和超时分别捕获方便 Bot 层针对不同错误给出不同提示。4.4 编写上下文管理器memory.py使用前面提到的内存管理方案这里再补充一个方法import time from collections import defaultdict, deque class ConversationMemory: def __init__(self, max_len20, ttl1800): self.max_len max_len self.ttl ttl self.data defaultdict(lambda: {messages: deque(maxlenmax_len), last_time: 0}) def _cleanup(self, chat_id: str): item self.data[chat_id] if time.time() - item[last_time] self.ttl: item[messages].clear() item[last_time] time.time() def add(self, chat_id: str, role: str, content: str): self._cleanup(chat_id) self.data[chat_id][messages].append({role: role, content: content}) def get(self, chat_id: str): self._cleanup(chat_id) return list(self.data[chat_id][messages])这里deque(maxlen20)的作用是自动丢弃最旧的记录保证上下文不会无限增长。4.5 编写主 Bot 程序bot.py是核心入口import os import asyncio from dotenv import load_dotenv from aiogram import Bot, Dispatcher, types from aiogram.filters import Command from grok_client import GrokClient from memory import ConversationMemory load_dotenv() BOT_TOKEN os.getenv(BOT_TOKEN) GROK_API_KEY os.getenv(GROK_API_KEY) GROK_MODEL os.getenv(GROK_MODEL, grok-2-latest) bot Bot(tokenBOT_TOKEN) dp Dispatcher() grok GrokClient(api_keyGROK_API_KEY, modelGROK_MODEL) memory ConversationMemory() SYSTEM_PROMPT 你是一个技术团队助手回答要简洁、可执行。涉及生产环境操作时提醒风险。 def extract_prompt(message: types.Message) - str | None: 从消息中提取模型输入私聊直接取文本群聊要求 触发。 if not message.text: return None text message.text.strip() if message.chat.type private: return text # 这里需要在收到消息时动态获取机器人信息因此抽成 async 函数 return None async def get_prompt(message: types.Message) - str | None: if not message.text: return None text message.text.strip() if message.chat.type private: return text me await bot.me() bot_username me.username mention f{bot_username} if mention not in text: return None return text.replace(mention, ).strip() dp.message(Command(start, help)) async def handle_help(message: types.Message): await message.answer( 你好我是 Grok Helper。\n 在群里 我或者直接私聊我提问即可。\n 输入 /clear 清除当前会话上下文。 ) dp.message(Command(clear)) async def handle_clear(message: types.Message): chat_id str(message.chat.id) memory.data.pop(chat_id, None) await message.answer(已清除当前会话上下文。) dp.message() async def handle_message(message: types.Message): chat_id str(message.chat.id) # 提取用户真正想提问的内容 prompt await get_prompt(message) if prompt is None: # 群聊中但没 机器人直接忽略 return # 先告诉用户消息已收到避免群聊中等待过久 await bot.send_chat_action(chat_idmessage.chat.id, actiontyping) # 组装上下文 history memory.get(chat_id) messages [{role: system, content: SYSTEM_PROMPT}] messages.extend(history) messages.append({role: user, content: prompt}) try: reply await grok.chat(messages) except TimeoutError: await message.answer(请求超时了请稍后重试或简化你的问题。) return except RuntimeError as e: await message.answer(f调用 Grok 失败{e}) return except Exception as e: await message.answer(f发生未知错误{e}) return # 写入上下文只保留真实对话部分不包含 system memory.add(chat_id, user, prompt) memory.add(chat_id, assistant, reply) # 回复消息 await message.answer(reply) async def main(): print(Grok bot 已启动...) await dp.start_polling(bot) if __name__ __main__: asyncio.run(main())4.6 运行与验证启动 Botpython bot.py启动成功后在 Telegram 中找到你的 Bot进行以下测试私聊发送用 Python 写一个快速排序Bot 应该直接回复代码和解释。在群里新增这个 Bot并发送你的机器人 什么是 GILBot 应该回复。在群里不带 直接发消息Bot 不应回复。连续追问先问什么是 HTTP 状态码 502再问那 504 呢如果上下文正常Bot 应该能理解“那”指的是上一个问题。输入/clear清除上下文。预期输出效果每条机器人消息都会在群聊中收到一段以 Markdown 格式返回的回答。因为 Grok 本身支持 Markdown代码块、列表、表格都能正常显示。5. 进阶让效率再提升一档基础版已经可以工作但距离“效率提升”还有几个值得优化的点。5.1 流式输出大模型生成长文时非流式接口可能让用户等 10 到 30 秒才看到完整回复。流式输出可以边生成边推送用户体感更好。在grok_client.py中把stream改为True然后按行解析data: {...}格式的数据。httpx 支持异步流式读取async with client.stream(POST, self.base_url, headersself.headers, jsonpayload) as resp: async for line in resp.aiter_lines(): if line.startswith(data: ): chunk line[6:] if chunk [DONE]: break # 解析 JSON取出 delta.content然后在 Bot 层不能再用message.answer一次性发送需要用到 Telegram 的edit_message_text来逐步更新。5.2 指令系统与快捷键除了 触发可以定义一些“斜杠指令”来提升效率。例如/code让模型只输出代码不加解释。/explain让模型只解释不生成新代码。/review让模型做代码审查。/clear清除上下文。实现方式很简单在handle_message前根据指令前缀改写 system prompt。例如if message.text.startswith(/review): system_prompt 你现在是一名资深代码审查工程师请从正确性、性能、可维护性三个维度审查代码。5.3 上下文窗口裁剪Grok 模型有上下文长度限制但在长对话中直接把所有历史都传给 API 会浪费 token也可能超出限制。更稳的做法是只保留最近 N 条消息。对超长消息做截断比如单条消息超过 2000 字就只保留摘要。定期用模型对历史对话做摘要把摘要作为新对话的前缀。一个简单实现MAX_TOKENS 4000 MAX_MESSAGE_LEN 2000 def trim_history(messages): # 估算 token中文 1 字约 1 token英文 1 词约 1.3 token total sum(len(m[content]) for m in messages) while total MAX_TOKENS and len(messages) 1: removed messages.pop(0) total - len(removed[content]) return messages5.4 会话隔离在群聊中多个用户可能同时 Bot。如果所有消息都共享同一个上下文那 A 用户在问 PythonB 用户在问运维Bot 就会“串台”。解决方案以chat_id user_id作为会话 key而不是只以chat_id作为 key。修改memory.py中的 key 逻辑session_id f{message.chat.id}:{message.from_user.id}这样每个人在群聊中有独立的对话上下文互不干扰。5.5 与外部工具链集成“效率提升”不只体现在问答上。把 bot 与 CI/CD、日志系统、知识库连接起来效果会更强。例如当用户在群里 Bot 发送一段报错日志Bot 先调用内部日志检索 API 获取上下文再让 Grok 分析。当用户要求生成 PR 描述时Bot 调用 Git 命令获取 diff再让 Grok 生成 Markdown 描述。当用户提问“某个函数怎么用”时Bot 先从内部知识库检索相关文档片段附在 prompt 后面提高回答准确性。这种“RAG检索增强生成 Bot”的模式是团队效率工具的主流方向。限于篇幅本文不展开实现但架构上是完全兼容的只需要在handle_message中额外调用检索函数把结果拼进messages列表即可。5.6 把 Grok 生成的文本导入 Word很多做运营、方案、文档的同事问过一个问题Grok 生成的文本怎么放进 Word最简单的方式是让 Grok 直接输出 Markdown 格式然后把 Markdown 粘贴到支持 Markdown 的编辑器如 Typora、Obsidian中再导出为 Word。如果你希望 Grok 生成的文本直接以 Word 需要的风格呈现可以在 system prompt 中加一句输出时使用标准文档结构包含标题层级、段落、项目符号和表格适合直接复制到 Word。还有一种方式是编写一个小的转换脚本用 Python 的python-docx库把 Grok 返回的 Markdown 文本转换成.docx文件。这个方案适合批量处理。核心思路from docx import Document import markdown # 先转 HTML再用 BeautifulSoup 解析成 Word 段落不过这已经超出本文范围后续可以单独写一篇。6. 常见问题与排查思路在搭建和使用 Grok bot 的过程中会遇到不少问题。下面是高频问题及排查方法。6.1 群聊中 Bot 没反应问题现象常见原因解决思路群聊里 了 Bot但 Bot 不回复Bot 没有开启群聊隐私模式找 BotFather 发送/setprivacy选择 Disable群聊里 了 Bot但 Bot 不回复代码中get_prompt判断逻辑有误在函数开头打印message.text检查 内容是否被正确识别群聊里 了 Bot但 Bot 不回复Bot 权限不足无法读取群消息确认 Bot 是否被设置为管理员或至少在群成员列表中排查步骤在群里发一条不带 的消息看 Bot 是否收到。如果设置了 Disable PrivacyBot 可能收到所有消息只是代码里忽略了。在本地 Bot 服务里添加日志打印message对象。在 Telegram 客户端里查看 Bot 是否在群成员列表中。6.2 Grok API 返回 401 或 403问题现象常见原因解决思路调用 API 返回 401API Key 错误或已过期检查.env中的 key重新生成调用 API 返回 403账号无权限或欠费检查账号状态确认模型是否有访问权限调用 API 返回 404模型名不存在去官方文档确认当前可用的模型名6.3 请求超时问题现象常见原因解决思路Bot 一直转圈最终提示超时Grok API 响应慢或网络不稳定调大 httpx 的 timeout使用流式输出优化体感群聊中多条消息同时触发并发请求导致排队引入队列或限制并发数如asyncio.Semaphore6.4 上下文串台问题现象常见原因解决思路多个用户同时提问Bot 回答混乱会话 key 只用了 chat_id改为chat_id user_id对话历史积累太久Bot 忘了前文内存清理策略太激进或太宽松调整 ttl 和 max_len6.5 消息发送失败问题现象常见原因解决思路消息太长Telegram 拒绝发送超过 Telegram 4096 字符限制分片发送每段不超过 4000 字符消息包含非法 HTML 标签Telegram 解析模式问题使用parse_modeMarkdown或关闭解析分片发送的简单实现def split_message(text: str, chunk_size: int 4000): for i in range(0, len(text), chunk_size): yield text[i:i chunk_size]7. 最佳实践与工程建议7.1 密钥管理不要把 API Key 写死在代码里。使用环境变量或密钥管理服务如 Vault、KMS。如果使用 Docker 部署通过env或secrets注入。这是最基本的安全要求。7.2 日志与监控在生产环境中Bot 和 Grok API 的调用都需要留痕。建议记录以下内容收到消息的时间、chat_id、user_id、消息长度。请求 Grok API 的模型名、输入 token 数、输出 token 数。接口响应时间、是否异常。错误堆栈。使用 Python 的logging模块即可import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(grok-bot) logger.info(收到消息: chat_id%s, user_id%s, len%s, message.chat.id, message.from_user.id, len(prompt))7.3 成本控制Grok API 按 token 计费上下文越长、回复越长费用越高。建议对单条消息长度设上限超过 4000 字先截断。定期清理历史上下文避免无意义的 token 消耗。关注 API 平台上的用量报表设置预算提醒。7.4 异常处理策略不要只 catch 一个Exception。按照错误类型分层处理TimeoutError提示用户稍后重试。RateLimitError提示用户不要频繁提问并做限流。AuthError记录日志提醒管理员检查密钥。BadRequestError通常是参数错误需要修正代码。7.5 安全边界当 Grok bot 被团队大规模使用时必须注意不要允许机器人执行 shell 命令或修改文件除非你显式实现了这个能力并做了权限控制。对群聊中所有人开放时要考虑 prompt injection 风险。比如用户直接在消息里写“忽略你的 system prompt”模型可能会被带偏。缓解方式是让可信管理员担任群管理员或者实现关键词过滤。涉及生产环境的建议类回答系统提示词应强制要求模型输出免责提醒。7.6 部署方式开发时用polling最简单但生产环境更推荐 Webhook 模式减少无效轮询。以 Telegram 为例Webhook 地址需要配置为公网 HTTPS 地址可以使用 Nginx 反向代理到 Flask/uvicorn 服务。核心思路server { listen 443 ssl; server_name your-domain.com; location /webhook { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; } }使用 Webhook 后Bot 程序不再轮询而是由 Telegram 主动推送消息响应更快、资源占用更少。8. 结语与下一步到这里一个可用的 Grok bot 已经搭起来了。我们完成了从 API Key 获取、Bot 创建、消息接收、上下文管理到异常处理的完整链路。虽然示例以 Telegram 为主但“消息触发 调用模型 API 管理上下文”这套架构可以平移到飞书、钉钉和 Discord。差别只在于平台 SDK 不同数据格式不同核心思想是一致的。如果你要把这个 Bot 用于生产环境下一步可以优先做三件事把内存上下文换成 Redis支持多实例部署。接上日志和监控记录每次调用的 token 消耗和延迟。接入流式输出优化用户交互体验。Grok 和相关工具链更新很快今天可用的模型名和参数下个月可能就变了。因此代码里尽量避免硬编码版本号把模型名、API 地址、超时时间都放到配置中心或环境变量里这样升级模型时只需改配置不用改代码。希望这篇文章能帮你省去一些踩坑时间。如果你在搭建过程中遇到其他问题欢迎在评论区补充交流。