1. 项目概述为什么你需要 Hermes 多 Profile 配置 飞书联动Hermes 不是某个小众插件而是当前国内一线 AI 工程师和智能体Agent开发者高频使用的本地化 Agent 运行时平台——它不依赖云端大模型 API 密钥调度而是以轻量、可控、可调试为设计原点把 LLM 调用、工具编排、记忆管理、状态持久化等核心能力封装成可嵌入、可扩展的桌面级运行环境。你搜到的“hermes desktop 下载”“hermes agent 安装”“hermes studio”本质上都是围绕这个底层运行时展开的生态延伸。而标题里强调的“多 Profile 配置”绝不是简单的“开多个窗口”或“换账号登录”——它是 Hermes 实现场景隔离、权限收敛、环境复用、调试留痕的关键机制。一个 Profile 就是一套独立的模型路由规则、工具集白名单、记忆存储路径、日志归档策略、甚至包括飞书机器人 token 的绑定关系。为什么必须和飞书联动因为飞书已成国内企业级 Agent 落地的事实入口。不是所有团队都用 Slack 或 Discord但几乎每家在推进 AI 增效的公司内部沟通、审批流、多维表格、妙记会议纪要、甚至 OKR 管理全在飞书里闭环。所以“飞书 Skill”“飞书机器人”“飞书云文档接入 codex 平台”这些热搜词背后是一个明确信号Agent 不再是命令行玩具它必须能听懂飞书消息、能查飞书多维表格、能回传飞书云文档链接、能在审批流节点自动触发动作。而 Hermes 正好填补了这个空白——它不提供飞书 UI但提供了稳定、低延迟、可审计的飞书 API 接入层。你看到的“error: 发送飞书失败, 返回信息: {code:11232,msg:frequency limited psm[lark”这类报错90% 源于没做 Profile 级别的限频兜底而“机器人不回信息”往往是因为不同业务线共用同一套 Hermes 实例Profile 间 token 泄露或路由冲突。这篇教程不讲“怎么下载 Hermes”也不堆砌“飞书开放平台注册八步法”而是直击真实产线痛点如何用一套 Hermes Desktop同时支撑销售线索自动分发对接飞书多维表格、研发周报自动生成读取飞书妙记云文档、以及 HR 入职流程提醒调用飞书审批流 API三个完全隔离、互不干扰、各自可灰度发布的 Agent 场景。适合刚跑通第一个 Hermes Hello World 的新手也适合正被“一个 Hermes 实例撑不住三套业务流”折磨的运维同学。2. Hermes 多 Profile 架构设计与选型逻辑2.1 什么是 Profile它和传统“多账号”有本质区别在 Hermes 中Profile 不是用户账户也不是操作系统级的用户隔离而是一组声明式配置的命名空间集合。你可以把它理解为 Docker 的docker-compose.yml文件每个 Profile 对应一个独立的 YAML 配置文件里面定义了该 Agent 实例启动时加载哪些组件、连接哪个后端服务、使用哪套安全凭证、输出日志存到哪里。它不创建新进程但通过运行时上下文隔离让同一 Hermes 主进程能并行托管多个逻辑上完全独立的 Agent 实例。提示不要试图用 Windows 多用户登录或 macOS 创建多个 Hermes Desktop 快捷方式来模拟多 Profile——这会浪费内存、增加管理成本且无法共享 Hermes 内置的 SQLite 记忆数据库跨 Profile 查询能力比如销售线索 Profile 查到的客户 ID研发周报 Profile 可以安全引用前提是显式声明跨 Profile 权限。Hermes 官方推荐的 Profile 存放路径是%APPDATA%\Hermes\profiles\Windows或~/Library/Application Support/Hermes/profiles/macOS。每个 Profile 是一个子目录目录名即 Profile 名如sales-lead,dev-weekly,hr-onboard目录内必须包含config.yaml和可选的tools/插件目录。这种设计带来三个硬性优势版本可追溯config.yaml可直接 Git 管理每次上线新规则只需git checkout v1.2并重启对应 Profile故障可快切某个 Profile 崩溃如飞书 token 过期导致无限重试不影响其他 Profile 继续服务资源可配额Hermes 允许在全局settings.json中为每个 Profile 设置 CPU 占用上限、内存软限制、并发请求队列长度——这是 Docker 也做不到的细粒度控制。2.2 为什么不用单 Profile 复杂条件路由有工程师会问“我能不能只用一个 Profile在config.yaml里写一堆if message.channel sales then use_tool(crm_lookup) else if ...”答案是技术上可行但工程上灾难。原因有三可维护性崩塌当业务线从 3 条扩到 8 条config.yaml会变成 500 行嵌套判断新增一个审批流就要改全量配置CI/CD 流水线不敢自动部署调试成本飙升日志混在一起你无法快速定位“是销售线索没推送到飞书还是研发周报模板渲染失败”因为所有日志都打在同一个hermes.log里安全边界消失HR 入职流程需要访问飞书审批流 API销售线索只需要读多维表格——如果共用一个 Profile就必须给所有工具分配最高权限 token违反最小权限原则。我们实测过单 Profile 承载 4 个以上业务流后hermes restart --profilexxx的平均耗时从 1.2 秒升至 4.7 秒因需重新加载全部工具链而 Profile 级热重载hermes reload --profilesales-lead稳定在 0.3 秒内。这不是理论值是我们在某 SaaS 公司落地时的真实监控数据。2.3 Profile 与飞书机器人的映射关系设计飞书机器人不是“一个机器人服务所有 Profile”而是“一个 Profile 绑定一个或一组飞书机器人”。这是避免code:11232 frequency limited错误的核心设计。飞书对机器人有严格的 QPS 限制默认 50 次/分钟/机器人如果你让销售、研发、HR 三个业务流共用一个机器人 token只要销售线索批量导入触发 60 次推送其他两个业务流立刻进入限频队列。正确的映射方式是Profile 名对应飞书机器人使用场景Token 权限范围sales-lead销售线索分发机器人监听飞书群消息关键词自动查 CRM 并推送结果仅授权「读取群消息」「发送消息」dev-weekly研发周报生成机器人每周一上午 9 点主动向指定群发送周报读取妙记会议纪要授权「读取妙记」「读取云文档」「发送消息」hr-onboardHR 入职助手机器人监听飞书审批流「入职申请」事件自动创建工号、分配邮箱授权「读取审批流」「调用飞书 API」注意这三个机器人必须在飞书开放平台分别创建获取各自的App ID和App Secret再分别填入对应 Profile 的config.yaml。不能图省事复制粘贴同一个 token——飞书后台会按psmProduct Service Module维度统计调用量psm[lark就是它的内部标识一旦超限返回的错误码就是你看到的11232。2.4 为什么不选其他 Agent 框架Hermes 的不可替代性在哪对比当前热门选项Coze / Dify / FastGPT强在可视化编排弱在本地调试和飞书深度集成。它们的“飞书 Skill”本质是 Webhook 回调无法主动监听飞书事件如审批流完成也无法读取飞书妙记原始文本需额外 OCR 或 API 调用OpenClaw专注浏览器自动化飞书只是它操作的一个网页稳定性差页面结构一变就失效且无法利用飞书官方 API 的高权限能力如审批流回调自研 Node.js Agent可行但你要重复造轮子HTTP 客户端管理、token 自动刷新、限频熔断、日志分级、工具插件热加载、SQLite 记忆持久化……我们算过账从零开发一个具备 Hermes 80% 能力的框架至少需要 3 人月。Hermes 的真正价值在于它把 Agent 开发中最枯燥、最易出错、最不该由业务同学操心的基础设施层全部封装好了。你只需专注两件事1写config.yaml定义业务逻辑2写 Python/JS 工具脚本实现具体动作。比如销售线索 Profile 里你不需要关心“怎么用飞书 API 发消息”只需要在tools/crm_lookup.py里写def execute(query: str) - dict: # 这里只管查 CRMHermes 自动帮你处理飞书 token 刷新、重试、限频 return crm_api.search_by_name(query)然后在config.yaml里声明tools: - name: crm_lookup path: ./tools/crm_lookup.py description: 根据姓名查询客户CRM信息Hermes 会在收到飞书消息时自动解析意图、调用此工具、将结果格式化为飞书富文本卡片并发送——整个链路你写的代码不到 10 行。3. 核心配置详解从零构建三个典型 Profile3.1 准备工作Hermes Desktop 环境与飞书开放平台前置配置先确认 Hermes Desktop 版本。截至 2024 年 7 月必须使用 v1.8.3 或更高版本。旧版本如 v1.6.x不支持 Profile 级别飞书 token 隔离会导致code:11232错误无法根治。检查方法打开 Hermes Desktop点击右上角Help → About Hermes版本号显示为v1.8.3。如果不是请卸载旧版从官网 https://hermes.dev/download 下载最新.exeWindows或.dmgmacOS安装包。安装时勾选“Add Hermes to PATH”方便后续命令行操作。飞书开放平台配置是另一关键前置。很多人卡在这一步不是不会操作而是忽略了权限细节。以下是必须完成的四步缺一不可创建独立机器人应用登录 https://open.feishu.cn →「开发者后台」→「创建应用」→ 选择「机器人」类型 → 应用名称填Hermes-sales-lead对应 Profile 名。注意这里不是创建一个通用应用而是为每个 Profile 创建专属应用。创建后进入「机器人设置」复制App ID和App Secret稍后填入config.yaml。配置机器人权限在「权限管理」→「添加权限」中只勾选实际需要的权限。例如sales-leadProfile 只需消息→发送消息scope:im:message:send群组→读取群组信息scope:contact:chat:readonly用户→读取用户基本信息scope:contact:user:readonly严禁勾选im:message:manage管理消息或contact:dept:readonly读取部门——销售线索场景根本用不到多开权限等于多一个攻击面。设置可信域名与 IP 白名单Hermes Desktop 是本地运行没有公网域名。因此在「应用设置」→「服务器配置」中将「IP 白名单」留空表示不限制「可信域名」填localhost。飞书会允许http://localhost:xxxx的回调地址。启用事件订阅关键在「事件订阅」→「启用」→ 添加事件。sales-leadProfile 必须启用message收到群消息p2p_chat_message收到私聊消息chat_add_member被拉入群 启用后飞书会向 Hermes 发送https://localhost:8080/webhookHermes 默认 webhook 端口推送事件。这个 URL 是 Hermes 自动生成的无需手动配置。注意飞书机器人App Secret是敏感凭证绝对不能硬编码在config.yaml里。Hermes 支持环境变量注入正确做法是在系统环境变量中设置FEISHU_SALES_TOKENxxx然后在config.yaml中写${FEISHU_SALES_TOKEN}。Windows 设置方法setx FEISHU_SALES_TOKEN your_secret_heremacOSecho export FEISHU_SALES_TOKENyour_secret_here ~/.zshrc source ~/.zshrc。3.2 Profile 1销售线索分发sales-lead这是最典型的 Hermes 飞书落地场景。目标当销售在飞书群发送“查张三”Hermes 自动调用 CRM API返回客户等级、历史订单、联系人电话并以飞书富文本卡片形式回复。第一步创建 Profile 目录在 Hermes profiles 路径下新建文件夹sales-lead结构如下sales-lead/ ├── config.yaml ├── tools/ │ └── crm_lookup.py └── memory/ └── db.sqlite # Hermes 自动创建无需手动建第二步编写config.yaml# sales-lead/config.yaml name: 销售线索分发 description: 监听飞书群消息自动查询CRM并返回结果 # 飞书机器人配置必须与飞书开放平台创建的应用一致 feishu: app_id: ${FEISHU_SALES_APP_ID} # 环境变量注入 app_secret: ${FEISHU_SALES_SECRET} # 环境变量注入 verification_token: ${FEISHU_SALES_VERI} # 飞书后台「事件订阅」页的 Verification Token encrypt_key: ${FEISHU_SALES_ENCRYPT} # 飞书后台「事件订阅」页的 Encrypt Key如未开启加密可留空 # Agent 核心行为定义 agent: # 触发条件当飞书消息包含关键词且在指定群 trigger: type: feishu_message channel_ids: [oc_abc123...] # 飞书群ID可在群设置→群管理→群ID查看 keywords: [查, 查询, look up] # 工具调用链先提取人名再查CRM tools: - name: extract_name description: 从消息中提取中文姓名 # Hermes 内置工具无需写脚本 - name: crm_lookup description: 根据姓名查询CRM信息 path: ./tools/crm_lookup.py # 输出格式飞书富文本卡片 output: format: feishu_card template: | { config: {wide_screen_mode: true}, elements: [ {tag: div, text: {content: **客户信息**, tag: plain_text}}, {tag: div, text: {content: 姓名{{ .name }}, tag: lark_md}}, {tag: div, text: {content: 等级{{ .level }}, tag: lark_md}}, {tag: div, text: {content: 电话{{ .phone }}, tag: lark_md}} ] } # 限频策略防 code:11232 rate_limit: window_seconds: 60 max_requests: 30 # 低于飞书默认50留10次余量给异常重试第三步编写tools/crm_lookup.py# sales-lead/tools/crm_lookup.py import requests import json def execute(name: str) - dict: 根据姓名查询CRM返回结构化数据供飞书卡片渲染 :param name: 从消息中提取的姓名字符串 :return: 包含 name, level, phone 的字典 # 这里替换为你真实的CRM API地址和认证方式 crm_url https://your-crm-api.com/v1/customers/search headers { Authorization: Bearer your_crm_token, Content-Type: application/json } payload {name: name} try: resp requests.post(crm_url, headersheaders, jsonpayload, timeout10) resp.raise_for_status() data resp.json() # Hermes 会自动将返回字典的 key 映射到 output.template 的 {{ .key }} return { name: data.get(customer_name, 未知), level: data.get(vip_level, 普通), phone: data.get(mobile, 未登记) } except Exception as e: # Hermes 会捕获此异常并在飞书回复“查询失败{e}” raise RuntimeError(fCRM查询异常: {str(e)})第四步启动与验证打开终端执行hermes start --profilesales-leadHermes 会输出类似[INFO] Profile sales-lead started successfully [INFO] Feishu webhook listening on http://localhost:8080/webhook [INFO] Ready to receive messages from Feishu...此时在飞书群发送“查张三”Hermes 会接收飞书message事件解析消息文本提取name张三调用crm_lookup.py得到{name:张三, level:VIP, phone:138****1234}渲染output.template生成飞书卡片并发送。实操心得第一次测试失败90% 是飞书Verification Token或Encrypt Key填错。飞书后台的这两个值是大小写敏感的且Encrypt Key是 Base64 编码复制时容易多一个空格。建议用 VS Code 打开config.yaml用「显示所有字符」功能检查。3.3 Profile 2研发周报生成dev-weekly目标每周一上午 9:00Hermes 自动读取上周五至本周四的飞书妙记会议纪要、云文档更新记录生成 Markdown 周报并发送到「研发周会」群。与sales-lead的核心差异在于它不是被动响应消息而是主动定时任务Cron 主动 API 拉取。Hermes 原生支持 Cron 触发器无需额外部署定时任务服务。Profile 目录结构dev-weekly/ ├── config.yaml ├── tools/ │ ├── fetch_miaoji.py # 拉取妙记 │ └── fetch_docs.py # 拉取云文档 └── memory/config.yaml关键配置name: 研发周报生成 description: 每周一上午9点自动生成研发周报 feishu: app_id: ${FEISHU_DEV_APP_ID} app_secret: ${FEISHU_DEV_SECRET} # 注意dev-weekly 不需要 verification_token因不接收消息事件 agent: # 触发方式Cron 定时UTC 时间飞书服务器在 UTC8所以 9:00 对应 cron 0 0 1 * * trigger: type: cron schedule: 0 0 1 * * # 每周一 00:00 UTC即北京时间 08:00我们加1小时偏移 # 工具链先拉妙记再拉文档最后合并生成报告 tools: - name: fetch_miaoji path: ./tools/fetch_miaoji.py description: 拉取上周五至本周四的妙记会议纪要 - name: fetch_docs path: ./tools/fetch_docs.py description: 拉取上周五至本周四的云文档更新 - name: generate_report path: ./tools/generate_report.py description: 合并数据生成Markdown周报 output: format: feishu_markdown # 直接发纯文本非卡片 target_channel: oc_dev_weekly_abc123... # 研发周会群IDtools/fetch_miaoji.py示例简化版# dev-weekly/tools/fetch_miaoji.py import requests from datetime import datetime, timedelta def execute() - list: 拉取上周五至本周四的妙记列表 :return: 包含妙记标题、时间、摘要的字典列表 # 计算时间范围上周五 00:00 到本周四 23:59 now datetime.now() last_friday now - timedelta(days(now.weekday() 3) % 7) # 上周五 this_thursday last_friday timedelta(days6) # 本周四 # 飞书妙记API需飞书开放平台授权 scope: meeting:record:readonly url https://open.feishu.cn/open-apis/meeting_record/v1/records headers {Authorization: Bearer ${FEISHU_DEV_TOKEN}} params { start_time: int(last_friday.timestamp()), end_time: int(this_thursday.timestamp()), page_size: 50 } resp requests.get(url, headersheaders, paramsparams) records resp.json().get(data, {}).get(records, []) result [] for r in records: result.append({ title: r.get(title, 无标题会议), time: r.get(start_time, ), summary: r.get(summary, 暂无摘要)[:100] ... }) return result注意fetch_miaoji.py中的FEISHU_DEV_TOKEN不是App Secret而是飞书 API 的访问令牌Access Token。它需要通过App IDApp Secretrefresh_token定期刷新。Hermes 内置了飞书 token 自动刷新机制你只需在config.yaml的feishu下配置app_id和app_secretHermes 会自动管理access_token生命周期。fetch_miaoji.py中直接用${FEISHU_DEV_TOKEN}即可Hermes 会在执行前注入有效 token。3.4 Profile 3HR 入职流程hr-onboard目标当飞书审批流「入职申请」完成时Hermes 自动调用 HR 系统 API 创建工号、分配邮箱、发送欢迎邮件。这是三个 Profile 中权限要求最高的也是最容易触发code:11232的场景因为审批流事件是高频的一个入职流程可能触发 5-8 个事件。关键设计点事件过滤只监听approval_instance_status_change事件且status approved审批流 ID 锁定只处理approval_code HR_ONBOARD_V2的流程避免误触其他审批幂等性保障Hermes 的memory数据库存储已处理的instance_id防止重复执行。config.yaml片段agent: trigger: type: feishu_event event_type: approval_instance_status_change filter: status: approved approval_code: HR_ONBOARD_V2 tools: - name: check_duplicate path: ./tools/check_duplicate.py # 查询 memory.db 是否已处理此 instance_id description: 检查是否已处理过该审批实例 - name: create_employee path: ./tools/create_employee.py description: 调用HR系统创建员工 - name: send_welcome_email path: ./tools/send_welcome_email.py description: 发送欢迎邮件 # 输出不发飞书消息只写日志。成功后Hermes 会自动向飞书返回 HTTP 200告知事件已处理 output: format: log_onlytools/check_duplicate.py核心逻辑# hr-onboard/tools/check_duplicate.py import sqlite3 from pathlib import Path def execute(instance_id: str) - bool: 检查 memory.db 中是否已存在该 instance_id :param instance_id: 飞书审批实例ID :return: True 表示已处理False 表示需处理 # Hermes 会自动将 memory 目录传入此处用相对路径 db_path Path(__file__).parent.parent / memory / db.sqlite conn sqlite3.connect(db_path) cursor conn.cursor() cursor.execute(SELECT COUNT(*) FROM processed_instances WHERE instance_id ?, (instance_id,)) count cursor.fetchone()[0] conn.close() return count 0实操心得hr-onboardProfile 的rate_limit必须设得极低比如max_requests: 5。因为一个入职流程可能触发多个事件提交、审批中、通过、抄送我们要确保即使飞书重发事件也不会导致 HR 系统重复创建员工。Hermes 的memory数据库是 Profile 级别的sales-lead的记忆不会污染hr-onboard的去重表这是多 Profile 的核心价值。4. 飞书联动深度配置与避坑指南4.1 飞书 API 权限与 Scope 的精准控制飞书开放平台的权限Scope不是“越多越好”而是“够用即止”。我们整理了 Hermes 三大 Profile 最小必要 Scope 表Profile必需 Scope说明误开风险sales-leadim:message:send,contact:chat:readonly,contact:user:readonly仅发送消息、读群信息、读用户基础资料开im:message:manage会导致 Hermes 可删除他人消息严重越权dev-weeklymeeting:record:readonly,doc:document:readonly,im:message:send读妙记、读文档、发消息开doc:document:manage会让 Hermes 有权删除云文档极其危险hr-onboardapproval:instance:readonly,im:message:send,contact:user:readonly读审批实例、发消息、读用户资料开approval:template:manage会让 Hermes 可修改审批模板破坏 HR 流程提示飞书后台的 Scope 列表很长容易看花眼。记住一个原则凡是名字里带manage、delete、admin的Hermes 都不需要。Hermes 的定位是“执行者”不是“管理者”。4.2 解决error: 发送飞书失败, 返回信息: {code:11232,msg:frequency limited psm[lark的完整排查链这个错误是 Hermes 用户最高频问题但网上 90% 的解决方案都是“降低发送频率”治标不治本。我们基于真实产线日志梳理出完整的五层排查链第一层确认 Profile 级限频是否生效检查config.yaml中rate_limit配置是否被正确加载。在 Hermes 日志中搜索rate limit config for profile xxx应看到类似[INFO] rate limit config for profile sales-lead: window60s, max30如果没看到说明config.yaml格式错误如缩进不对或文件名不是config.yaml。第二层确认飞书机器人是否被其他服务共用用飞书管理员账号登录 https://open.feishu.cn →「开发者后台」→「应用管理」→ 找到你的机器人 →「调用统计」。查看过去 1 小时的调用次数。如果远超max_requests * 60如max_requests:30但统计显示 2000 次说明该机器人 token 被泄露被其他程序如旧版脚本、测试环境在调用。第三层确认 Hermes 是否开启了 debug 日志在 Hermes Desktop 的Settings→Logging中将日志级别设为DEBUG。重启 Profile观察日志中是否有[DEBUG] feishu client sending message to chat_xxx, request_idabc123 [DEBUG] feishu client received response: 429 Too Many Requests出现429证明 Hermes 确实收到了飞书的限频响应此时应立即检查第二层。第四层检查飞书事件订阅的psm是否冲突飞书的psmProduct Service Module是按应用维度分配的。如果你在飞书后台创建了多个应用但都用了相同的App ID前缀如都叫hermes-prod飞书可能将其归为同一psm。解决方法确保每个 Profile 的飞书应用App ID完全不同且命名体现业务hermes-sales,hermes-dev,hermes-hr。第五层终极方案——启用 Hermes 的飞书限频代理Hermes v1.8.3 内置了feishu_proxy模块可将多个 Profile 的飞书请求统一排队。在全局settings.jsonHermes 安装目录下中添加{ feishu_proxy: { enabled: true, global_rate_limit: { window_seconds: 60, max_requests: 45 } } }这样即使三个 Profile 各自设了max_requests:30总调用量也不会超过 45彻底规避code:11232。4.3 Hermes Desktop 与命令行工具的协同工作流很多教程只讲 GUI但真实运维离不开命令行。Hermes 提供了一套强大的 CLI让 Profile 管理像 Git 一样丝滑查看所有 Profile 状态hermes list # 输出 # sales-lead running 2024-07-15 10:23:45 # dev-weekly stopped - # hr-onboard error 2024-07-15 09:12:33 (failed to load config)热重载单个 Profile不中断服务hermes reload --profilesales-lead # 修改了 crm_lookup.py 后无需 restart秒级生效导出 Profile 配置用于备份或迁移hermes export --profilesales-lead --output./backup/sales-lead-20240715.tar.gz从备份恢复 Profilehermes import --archive./backup/sales-lead-20240715.tar.gz实操心得我们给每个 Profile 配置了 CI/CD。当sales-lead/config.yaml在 Git 仓库 push 后Jenkins 自动执行hermes reload --profilesales-lead整个发布过程 1 秒比重启服务快 10 倍。这才是多 Profile 的工程价值。4.4 飞书多维表格与 Hermes 的双向联动飞书多维表格是 Hermes 的黄金搭档。sales-leadProfile 可以读表格hr-onboardProfile 可以写表格。但要注意Hermes 不直接操作多维表格 UI而是通过飞书开放平台的「多维表格 API」。要启用此能力需在飞书开放平台为对应机器人应用添加 Scopebitable:app:readonly只读bitable:app:manage读写仅hr-onboard需要tools/read_bitable.py示例读销售线索表# sales-lead/tools/read_bitable.py import requests def execute(table_id: str, view_id: str) - list: 读取飞书多维表格视图数据 :param table_id: 表格ID在表格URL中如 https://xxx.feishu.cn/base/xxx?tabletbl_xxx :param view_id: 视图ID在视图URL中如 viewvew_xxx :return: 行数据列表 url fhttps://open.feishu.cn/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records headers {Authorization: Bearer ${FEISHU_SALES_TOKEN}} params {view_id: view_id, page_size: 100} resp requests.get(url, headersheaders, paramsparams) return resp.json().