让新员工的AI权限当天生效 - 我把飞书机器人接到了统一网关后面
带过团队的人都知道，工具权限的落地流程有多磨人。新同事入职，想用大模型处理飞书里的咨询消息，以前要走三步：申请预算、注册某家模型账号、把 API Key 明文贴进群里。等审批走完，两天过去了；等某个离职同事的 Key 忘记回收，就是一次安全事件。
我后来做了个决定：所有 AI 能力统一走一个网关（ThisToken.AI），团队不再各自持有任何模型的原始 Key。飞书机器人是第一个接入的场景。这篇文章把完整流程写出来，重点是流程怎么定、权限怎么收、出了问题怎么查——代码只是流程的最后一步。
一、为什么管理者应该关心“Key 放在哪”
自建机器人直接调用某家模型，技术上没问题，但管理上有三个坑：
- Key 分散：每个开发者手里一把 Key，离职交接必漏。
- 账单失控：谁调了多少、花在哪，月底才看报表，来不及控制。
- 模型变更风险：模型停服、涨价，你得挨个改代码。
统一网关的价值就是把这些风险收拢：Key 只有一份，在网关侧；调用记录集中可查；换模型改一个参数就行。价格方面，以官网价格页为准，团队按量消费即可。
二、开通流程（当天可完成）
- 注册账号：访问 ThisToken.AI，用团队公共邮箱注册（不要用个人邮箱，方便后续交接）。
- 创建 API Key：进入控制台，建议按“项目”建 Key，比如
feishu-bot-prod、feishu-bot-test各一把，方便按环境隔离和吊销。 - 充值或开通额度：以官网价格页为准。
- 在飞书开放平台创建企业自建应用，开启“机器人”能力，配置事件订阅（接收消息事件
im.message.receive_v1），拿到 App ID 和 App Secret。
到这里，团队需要的所有凭证都齐了，但注意：模型的 Key 只进网关配置，模型的原始 Key 团队里任何人都不该持有——这就是风险控制的第一条红线。
三、跑通第一段代码
最小可用版本，Python，依赖 flask、openai（网关兼容 OpenAI 协议）、飞书官方 SDK：
import os
import json
from flask import Flask, request
from openai import OpenAI
import lark_oapi as lark
from lark_oapi.api.im.v1 import ReplyMessageRequest, ReplyMessageRequestBody
app = Flask(__name__)
# 统一网关入口：Key 只存在环境变量，不进代码库
client = OpenAI(
api_key=os.environ["THISTOKEN_API_KEY"],
base_url="https://api.thistoken.ai/v1",
)
lark_client = lark.Client.builder() \
.app_id(os.environ["FEISHU_APP_ID"]) \
.app_secret(os.environ["FEISHU_APP_SECRET"]) \
.build()
SYSTEM_PROMPT = "你是团队内部助手，回答保持简洁、专业，涉及不确定的信息要明确说明。"
def ask_llm(question: str) -> str:
resp = client.chat.completions.create(
model="gpt-4o-mini", # 按需替换为团队白名单内的模型
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": question},
],
)
return resp.choices[0].message.content
def reply(message_id: str, text: str):
req = ReplyMessageRequest.builder() \
.message_id(message_id) \
.request_body(ReplyMessageRequestBody.builder().content(
json.dumps({"text": text})).msg_type("text").build()) \
.build()
lark_client.im.v1.message.reply(req)
@app.route("/webhook", methods=["POST"])
def webhook():
body = request.json
event = body.get("event", {})
msg = event.get("message", {})
if msg.get("message_type") == "text":
question = json.loads(msg["content"])["text"]
answer = ask_llm(question)
reply(msg["message_id"], answer)
return {"code": 0}
if __name__ == "__main__":
app.run(port=8000)几个管理上的细节藏在代码里：
- Key 全部走环境变量，代码库可开源、可交接，审计时不用做脱敏。
- 模型名写死在代码里而非让用户指定，配合团队的角色白名单制度，谁能触发哪个模型，由代码和 Key 权限共同约束。
- System Prompt 集中维护，机器人的“人设”和合规口径由管理者把关，而不是每个开发者随手写。
本地跑通后，把服务部署到内网或云服务器，飞书事件订阅地址填上你的 /webhook 路径即可。
四、上线后的三条管理动作
代码跑通只是开始，真正决定这件事能不能长期跑的是流程：
- 每周看一次调用报表。网关侧有集中用量记录，谁在用、用多少、调的什么模型，一目了然。异常流量当天发现，而不是月底看账单吓一跳。
- Key 定期轮换。建议每季度换一次网关 Key，测试环境的 Key 随时可吊销，不影响生产。
- 回答质量抽检。让运营或客服负责人每周抽几条机器人回复，反哺 System Prompt。机器人是团队的对外口径，这话不能只靠模型自觉。
这套东西上线后最直观的变化是：新同事入职当天，飞书里 @机器人 就能用上 AI；离职当天，回收的是网关子 Key，一行代码都不用改。工具的效率最终取决于管理它的流程，而不是模型本身有多强。
如果你也想把团队的 AI 能力收拢到统一网关，可以先注册一个账号试跑上面这段代码：https://api.thistoken.ai/register
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。