企业官网建设流程全解析

前几周在团队内部尝试把 Grok 接入聊天机器人时，遇到了不少细节问题：API 调用方式、上下文管理、群聊里如何用 @ 触发、如何避免回答串台、如何控制成本和超时。查了很多资料，大多只讲了单点用法，缺少一套从零到一、可直接落地的完整流程。这篇文章会把我在实际搭建 Grok @bot 过程中用到的方案、代码和排错思路整理出来，希望能帮你少走一些弯路。

1. 背景与核心概念：为什么要做一个 Grok @bot

1.1 Grok 是什么，为什么选择它

Grok 是由 xAI 推出的大语言模型产品，主打实时信息获取、逻辑推理和自然对话。和很多通用助手相比，Grok 在长文本理解、代码生成、结构化输出，以及对“对话上下文”的把握上都有不错的表现。

不过，直接打开网页或客户端使用 Grok，和把它接入到我们日常工作的聊天工具中，是两种完全不同的体验。前者适合个人问答，后者适合团队协作和自动化流程。当你需要频繁把一段报错、一段日志、一段需求描述丢给模型时，打开网页再复制粘贴的效率很低。更理想的方式是：在团队已经使用的 IM 工具里，@ 一下机器人，直接把问题抛出去，几秒钟后拿到答案。

这就是本文要讲的 Grok @bot 场景。

1.2 @bot 的工作方式

所谓 @bot，是指在聊天群或频道中，通过“@机器人用户名”的形式唤起机器人响应。

它在工作方式上和普通聊天机器人没有本质区别，核心链路如下：

1. 用户在群聊中发送消息，并在消息中 @ 了机器人。
2. 聊天平台（Telegram、飞书、钉钉、Discord 等）把这条消息通过 Webhook 或轮询方式推送给 Bot 服务。
3. Bot 服务判断消息中是否包含对机器人的提及（mention）。
4. 如果包含，则从消息中提取用户真正想提问的内容。
5. Bot 服务把提问内容发送给 Grok API，获取回答。
6. Bot 服务再把回答返回给聊天平台，展示在群聊中。

可以看到，@bot 只是消息路由和触发的机制，真正的“智能”来自 Grok 模型本身。我们写的代码，主要解决三件事：接收消息、调用模型、发送回答。

1.3 这个方案解决什么问题

在技术团队中，Grok @bot 可以承担很多日常工作，例如：

• 团队新人提问：在群里 @ 机器人询问某段代码的含义、某个框架的概念，减少重复答疑。
• 运维排查：把报错信息、日志片段发给机器人，快速获得排查建议。
• 代码审查辅助：让机器人对一段提交代码做静态逻辑分析或风格建议。
• 日常写作与格式化：把草稿文本发给机器人，让它整理成 Markdown、表格或要点。
• 自动生成模板：PR 描述、周报、接口文档，都可以通过 @ 机器人生成初稿。

从“效率提升”的角度看，最大的变化是减少了工具切换和上下文丢失。你在聊天工具里直接拿到结果，而且可以连续追问，模型会记住前面的对话内容。

1.4 需要区分的概念

在开始之前，有必要区分几个容易混淆的名词：

此外，近期网络上关于“Grok Build 1.0.7 上线”“Grok Build v1.0.9 发布”等信息，说明 Grok 相关工具链更新节奏很快。对普通开发者来说，不需要追求每个版本都跟进，只要掌握核心 API 接入方式和 Bot 工程化思路，后续升级只是替换模型名或参数的问题。

2. 环境准备与版本说明

2.1 开发环境

本文的示例代码使用 Python 编写，这是生态最成熟、示例最多的语言之一。你在本地需要准备：

• Python 3.9 及以上版本（推荐 3.10+）
• pip 包管理工具
• 一个聊天平台开发者账号（用于创建 Bot）
• Grok API Key（用于调用模型接口）

版本需要根据你的项目实际情况调整。我本地的示例环境如下，但你不必完全一致：

• 操作系统：macOS 14 / Ubuntu 22.04
• Python：3.10
• Bot 框架：aiogram 3.x（Telegram Bot 框架）
• HTTP 客户端：httpx（支持同步和异步）
• 代码编辑器：VS Code

2.2 获取 Grok API Key

要调用 Grok 模型，需要先到 xAI 官方开放平台（具体入口以官方文档为准）注册账号并创建 API Key。

创建 API Key 时有几个建议：

• Key 只显示一次，创建后要立刻复制保存。
• 不要把 Key 提交到 Git 仓库。
• 建议在平台侧设置消费上限或额度提醒，避免异常调用产生高额费用。
• 不同模型的定价不同，调用前先看一眼计费页面。

2.3 选择聊天平台

不同团队使用的 IM 工具不同，我在这里以最常见的几类为例：

需要特别提醒：如果你所在团队使用微信类工具，请优先使用企业微信官方机器人接口，不要使用个人号或非官方协议，否则有封号风险和合规风险。本文示例以 Telegram 为主，因为它的 Bot API 最简单，几乎不需要企业认证，适合学习；飞书/钉钉的接入逻辑类似，只是 API 形式不同。

2.4 安装 Python 依赖

创建一个新的 Python 虚拟环境：

mkdir grok-bot cd grok-bot python3 -m venv venv source venv/bin/activate

然后安装依赖：

pip install aiogram==3.7.0 httpx==0.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": f"Bearer {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(timeout=30) as client: resp = client.post(URL, headers=headers, json=data) 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等类型。

我们在代码里要做两件事：

1. 从消息文本中提取出真正要提问的内容，去掉 @ 用户名。
2. 判断消息是否真的提到了当前 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。下面给出一个简单内存版上下文管理类：

import time from collections import defaultdict, deque class ConversationMemory: def __init__(self, max_len=20, ttl=1800): self.max_len = max_len self.ttl = ttl self.data = defaultdict(lambda: {"messages": deque(maxlen=max_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 @bot（Telegram 示例）

下面开始搭建一个最小可用版本。这个示例会包含：

• Bot 启动与监听。
• 私聊消息直接回复。
• 群聊消息通过 @ 触发。
• 调用 Grok API。
• 维护多轮对话上下文。
• 错误处理与超时。

4.1 创建项目结构

grok-bot/ ├── .env ├── requirements.txt ├── bot.py ├── grok_client.py └── memory.py

4.2 安装依赖与配置

requirements.txt内容如下：

aiogram==3.7.0 httpx==0.27.0 python-dotenv==1.0.1

.env文件存放敏感配置：

BOT_TOKEN=123456:ABC-YourTelegramBotToken GROK_API_KEY=xai-YourGrokApiKey GROK_MODEL=grok-2-latest

注意：.env文件一定不要提交到 Git，建议添加到.gitignore。

4.3 编写 Grok 客户端

grok_client.py封装对 Grok API 的调用，使用异步 httpx：

import 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": f"Bearer {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(timeout=60) as client: try: resp = await client.post(self.base_url, headers=self.headers, json=payload) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] except httpx.HTTPStatusError as e: # 这里把 HTTP 错误转成更友好的异常，方便上层处理 raise RuntimeError(f"Grok API 返回错误: {e.response.status_code} - {e.response.text}") from e except httpx.TimeoutException as e: raise TimeoutError("Grok API 响应超时") from e

这里有几点值得说明：

• timeout=60：因为大模型生成需要时间，60 秒是比较稳妥的值。如果群聊消息很多，可以调小并配合“排队”机制。
• stream=False：关闭流式输出，实现最简单。如果想要更好的交互体验，可以改成流式，后面进阶部分会提到。
• 异常处理：把 HTTP 错误和超时分别捕获，方便 Bot 层针对不同错误给出不同提示。

4.4 编写上下文管理器

memory.py使用前面提到的内存管理方案，这里再补充一个方法：

import time from collections import defaultdict, deque class ConversationMemory: def __init__(self, max_len=20, ttl=1800): self.max_len = max_len self.ttl = ttl self.data = defaultdict(lambda: {"messages": deque(maxlen=max_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(maxlen=20)的作用是自动丢弃最旧的记录，保证上下文不会无限增长。

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(token=BOT_TOKEN) dp = Dispatcher() grok = GrokClient(api_key=GROK_API_KEY, model=GROK_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_id=message.chat.id, action="typing") # 组装上下文 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 运行与验证

启动 Bot：

python bot.py

启动成功后，在 Telegram 中找到你的 Bot，进行以下测试：

1. 私聊发送：用 Python 写一个快速排序，Bot 应该直接回复代码和解释。
2. 在群里新增这个 Bot，并发送：@你的机器人 什么是 GIL？，Bot 应该回复。
3. 在群里不带 @ 直接发消息，Bot 不应回复。
4. 连续追问：先问什么是 HTTP 状态码 502？，再问那 504 呢？，如果上下文正常，Bot 应该能理解“那”指的是上一个问题。
5. 输入/clear，清除上下文。

预期输出效果：每条@机器人消息都会在群聊中收到一段以 Markdown 格式返回的回答。因为 Grok 本身支持 Markdown，代码块、列表、表格都能正常显示。

5. 进阶：让效率再提升一档

基础版已经可以工作，但距离“效率提升”还有几个值得优化的点。

5.1 流式输出

大模型生成长文时，非流式接口可能让用户等 10 到 30 秒才看到完整回复。流式输出可以边生成边推送，用户体感更好。

在grok_client.py中把stream改为True，然后按行解析data: {...}格式的数据。httpx 支持异步流式读取：

async with client.stream("POST", self.base_url, headers=self.headers, json=payload) 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，也可能超出限制。更稳的做法是：

1. 只保留最近 N 条消息。
2. 对超长消息做截断，比如单条消息超过 2000 字就只保留摘要。
3. 定期用模型对历史对话做摘要，把摘要作为新对话的前缀。

一个简单实现：

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 messages

5.4 会话隔离

在群聊中，多个用户可能同时 @ Bot。如果所有消息都共享同一个上下文，那 A 用户在问 Python，B 用户在问运维，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 没反应

排查步骤：

1. 在群里发一条不带 @ 的消息，看 Bot 是否收到。如果设置了 Disable Privacy，Bot 可能收到所有消息，只是代码里忽略了。
2. 在本地 Bot 服务里添加日志，打印message对象。
3. 在 Telegram 客户端里查看 Bot 是否在群成员列表中。

6.2 Grok API 返回 401 或 403

6.3 请求超时

6.4 上下文串台

6.5 消息发送失败

分片发送的简单实现：

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(level=logging.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 用于生产环境，下一步可以优先做三件事：

1. 把内存上下文换成 Redis，支持多实例部署。
2. 接上日志和监控，记录每次调用的 token 消耗和延迟。
3. 接入流式输出，优化用户交互体验。

Grok 和相关工具链更新很快，今天可用的模型名和参数，下个月可能就变了。因此，代码里尽量避免硬编码版本号，把模型名、API 地址、超时时间都放到配置中心或环境变量里，这样升级模型时只需改配置，不用改代码。

希望这篇文章能帮你省去一些踩坑时间。如果你在搭建过程中遇到其他问题，欢迎在评论区补充交流。