ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

ARIS feishu-notify 技能深度解析:为无人值守 ML 研究工作流打造飞书/Lark 通知与双向审批

ARIS feishu-notify 技能深度解析:为无人值守 ML 研究工作流打造飞书/Lark 通知与双向审批 AI 技能/插件AI 评测科研人工智能MCP 服务dsh-plugin【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep点击查看免费下载导读ARISAuto-Research-In-Sleep是一套以 Markdown 技能为核心、与 Claude Code / Codex / OpenClaw 等任意 LLM Agent 协同的轻量级自主科研框架。本文围绕其中的feishu-notify技能讲解如何在实验跑完、评审出分、checkpoint 等待审批等关键事件发生时通过飞书Lark机器人向手机推送富文本卡片甚至基于桥接服务实现在手机飞书里审批 idea、回复 checkpoint的双向交互。读完本文你将掌握~/.claude/feishu.json的完整配置语法、push 与 interactive 两种模式的调用协议、事件卡片模板约定以及它与 ARIS 源码、测试用例之间的对应关系能够独立为任何 Agent 工作流接入飞书通知与远程审批能力。一、feishu-notify 是什么定位与设计哲学feishu-notify是 ARIS 内部的一个通用通知工具技能其定位在 skills/feishu-notify/SKILL.md 的 front-matter 中写得很清楚它是一个internal utility内部工具其他技能在关键事件实验完成、评审出分、checkpoint 等待时调用它它也可以手动触发用户说发飞书、notify feishu或直接调用/feishu-notify [message-text]它的allowed-tools只放开三类能力Bash(curl *)、Bash(cat *)、Read与Glob——这意味着它只通过 curl 与 cat 与外部系统打交道不引入任何额外框架或 Python 依赖完全符合 ARIS Lightweight Markdown-only skills, no framework, no lock-in 的项目定位。零影响保证Zero-impact guarantee这是该技能最重要的设计约束文档原文强调如果不存在feishu.json配置该技能什么都不做并静默返回所有既有工作流完全不受影响。落到实现上文档在 Workflow 章节 给出了统一的判定逻辑cat ~/.claude/feishu.json 2/dev/null文件不存在 → 静默返回什么都不做mode: off→ 静默返回什么都不做mode: push→ 进入 Step 2 推送流程mode: interactive→ 进入 Step 3 交互流程。这种缺省即关闭、配置即启用的模式让 feishu 能力成为一种可选项注入无论用户是否配置飞书其他所有技能如auto-review-loop、run-experiment的既有行为都不会被破坏。这在仓库多处源码中得到了印证例如 skills/run-experiment/SKILL.md 的 Step 6 明确写着检查~/.claude/feishu.json若配置缺失或 mode 为 off 则整体跳过no-op。二、配置详解~/.claude/feishu.json技能读取用户主目录下的~/.claude/feishu.json。只要该文件不存在飞书功能即整体关闭所有技能行为与未安装飞书时完全一致。2.1 完整配置格式{ mode: push, webhook_url: https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_WEBHOOK_ID, interactive: { bridge_url: http://localhost:5000, timeout_seconds: 300 } }字段说明字段类型必填条件含义mode字符串必填运行模式取值off/push/interactivewebhook_url字符串push 与 interactive 模式必填飞书群自定义机器人的 Webhook 地址interactive.bridge_url字符串interactive 模式必填桥接服务的 HTTP 地址默认http://localhost:5000interactive.timeout_seconds整数interactive 模式可选等待用户回复的超时秒数默认 3002.2 三种模式对比模式mode值行为前置要求关闭off或文件不存在什么都不做纯 CLI 原样运行无仅推送push在关键事件时向 webhook 发送通知手机收推送、不能回复飞书机器人 webhook URL双向交互interactive全双工可在飞书里审批/拒绝、回复 checkpoint桥接服务如 feishu-claude-code在运行关于interactive模式依赖的桥接服务ARIS 仓库本身在 mcp-servers/feishu-bridge/server.py 提供了一个同协议的参考实现见本文第三节可作为 feishu-claude-code 之外的自托管替代依赖仅一行lark-oapi1.0,2.0见 mcp-servers/feishu-bridge/requirements.txt。三、push 模式向飞书 webhook 推送富文本卡片3.1 消息体格式push 模式的核心动作是向 webhook 发送一条msg_type: interactive的卡片消息curl -s -X POST $WEBHOOK_URL \ -H Content-Type: application/json \ -d { msg_type: interactive, card: { header: { title: {tag: plain_text, content: TITLE}, template: COLOR }, elements: [ {tag: markdown, content: BODY} ] } }要点卡片头部header由plain_text标题与template颜色组成正文区elements使用markdown标签承载富文本内容可包含 Markdown 加粗、列表等push 模式是 fire-and-forgetcurl 发出后立即返回不等待任何响应。3.2 事件卡片模板约定ARIS 为不同事件类型规定了统一的标题、颜色与正文内容使手机端扫一眼就能判断状态事件标题颜色正文内容experiment_doneExperiment Completegreen结果对比表、与 baseline 的 deltareview_scoredReview Round N: X/10blue≥6/orange6分数、结论、Top 3 weaknesscheckpointCheckpoint: Waiting for Inputyellow问题、选项、上下文errorError: [type]red错误信息、哪里失败了pipeline_donePipeline Completepurple最终总结、交付物清单customCustomblue来自$ARGUMENTS的自由文本这套颜色语义在 docs/integrations/FEISHU_CN.md 的集成文档中也有对应的中文描述Review 出分 ≥6 绿色、6 橙色、实验完成绿色、Checkpoint 黄色、出错红色、流水线结束紫色两处文档相互印证。3.3 投递验证与容错push 模式检查 curl 退出码非零则记录 warning但绝不阻塞工作流卡片 JSON 的结构可对照仓库测试 tests/test_feishu_bridge_server.py 中的TestBuildCardPayload标题必须是plain_text标签、颜色默认blue、正文为markdown元素且支持 Unicode这些断言与技能文档中的 curl 示例完全一致。四、interactive 模式桥接服务与双向审批4.1 工作方式interactive 模式在 push 基础上叠加了双向对话能力推送卡片发到群里状态所有人可见交互对话走私聊你回复Agent 执行。其调用协议分为四步发送消息到桥接服务curl -s -X POST $BRIDGE_URL/send \ -H Content-Type: application/json \ -d {type: EVENT_TYPE, title: TITLE, body: BODY, options: [approve, reject, custom]}等待回复长轮询curl -s $BRIDGE_URL/poll?timeout$TIMEOUT_SECONDS返回结果约定{reply: approve}/{reply: reject}/{reply: user typed message}或{timeout: true}。超时回退超时后采用AUTO_PROCEED行为以默认选项继续回传结果把用户的回复返回给调用方技能由其执行后续动作。4.2 桥接服务源码feishu-bridge 参考实现ARIS 仓库在 mcp-servers/feishu-bridge/server.py 提供了一个同协议的桥接服务实现可以用它替代或对照 feishu-claude-code。其 HTTP API 与技能协议严格对齐端点方法作用关键参数/sendPOST发送卡片/文本消息到飞书用户user_id、typecard/text、title、body、color/pollGET长轮询等待用户回复message_id、timeout/replyPOST外部 webhook 回调注入用户回复message_id、text/healthGET健康检查无底层实现要点对应 server.py通过环境变量配置FEISHU_APP_ID、FEISHU_APP_SECRET、FEISHU_USER_ID目标用户的 open_id、BRIDGE_PORT默认 5000使用飞书官方 SDKlark-oapi构建 client发送卡片时以receive_id_type(open_id)指定接收者消息类型interactive卡片结构header 标题 elements markdown与技能文档中的 webhook 卡片完全同构见 send_card回复机制基于内存中的reply_store与threading.Eventsend_card成功后会为该message_id注册一个事件poll_reply调用event.wait(timeout)阻塞等待receive_reply被/reply触发时写入回复并set()唤醒等待线程见 poll_reply。4.3 源码级行为验证单元测试tests/test_feishu_bridge_server.py 在不依赖真实飞书凭证的前提下验证了桥接的核心逻辑纯逻辑部分抽取在 tests/_feishu_bridge_helpers.py回复存储receive_reply后poll_reply能取回用户文本未注册的message_id返回unknown message_id超时返回{timeout: true}回复被 poll 消费后即删除test_poll_consumes_reply并发唤醒另一线程投递回复能唤醒阻塞中的轮询线程test_concurrent_receive_and_poll多消息隔离多个并发消息互不干扰test_multiple_independent_messages卡片结构标题plain_text、默认颜色blue、正文markdown、支持中文 Unicode、空正文允许路由/health返回 200、/poll缺message_id返回 400、/reply缺message_id返回 400、未知路径 404。这些测试从行为层面印证了技能文档中poll返回协议与超时语义的真实性。4.4 超时与 AUTO_PROCEED 语义interactive 模式有一条硬性规则交互超时 自动继续绝不能无限等待。文档要求RespectAUTO_PROCEED: In interactive mode, if the user doesnt reply within timeout, use the same auto-proceed logic as the calling skill.也就是说timeout_seconds默认 300 秒到期后技能以调用方预设的默认选项继续执行保证无人值守的科研流水线不会因为没人看手机而卡死。同时交互模式下若桥接服务不可达技能会降级回 push 模式若配置了 webhook或静默跳过。五、Event Catalog各技能在什么时机发什么事件feishu-notify文档以事件目录Event Catalog形式规定了整个生态的集成点这是其他技能调用本技能的契约表Skill事件触发时机/auto-review-loopreview_scored每一轮评审出分后/auto-review-looppipeline_done循环结束正向完成或达到最大轮数/auto-paper-improvement-loopreview_scored每一轮评审出分后/auto-paper-improvement-looppipeline_done全部轮次完成/run-experimentexperiment_donescreen 会话结束/idea-discoverycheckpoint阶段之间interactive 模式下/idea-discoverypipeline_done最终报告就绪/monitor-experimentexperiment_done结果收集完成/research-pipelinecheckpoint工作流阶段之间/research-pipelinepipeline_done整条流水线完成以两个真实调用点为例skills/auto-review-loop/SKILL.md解析完评审分数后检查~/.claude/feishu.json发送review_scoredRound N: X/10 — [verdict] Top 3 weaknesses若为 interactive 模式且结论是almost则以 checkpoint 形式等待用户决定继续还是停止skills/run-experiment/SKILL.md实验部署验证通过后发送experiment_done启动了哪些实验、占用哪些 GPU、预计耗时。中文集成文档 docs/integrations/FEISHU_CN.md 的哪些 skill 会发通知章节还补充了/vast-gpu实例租用/销毁实例 ID 成本等事件点与 Event Catalog 形成互补。六、其他技能接入 feishu-notify 的标准写法为了让任意技能都能低侵入地接入通知文档给出了一套统一 helper 模式其他技能只需照抄这段 Markdown 即可### Feishu Notification (if configured) Check if ~/.claude/feishu.json exists and mode is not off: - If **push** mode: send webhook notification with event summary - If **interactive** mode: send notification and wait for user reply - If **off** or file absent: skip entirely (no-op)配套的关键规则Key Rules如下绝不因飞书不可达而阻塞工作流——始终 fail open绝不强制要求飞书配置——所有技能在无配置时照常工作配置文件缺失 mode off——无报错、无告警、无日志push 模式即发即忘——发 curl、查退出码、继续交互超时 自动继续——不无限等待回复通知中不包含机密信息——绝不发送 API key、token、密码。七、动手实战从配置到验证场景 A仅推送约 5 分钟在飞书群中创建自定义机器人复制 Webhook 地址安全设置可添加自定义关键词ARIS因所有通知均包含该词或不设限制写入配置cat ~/.claude/feishu.json EOF { mode: push, webhook_url: https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_WEBHOOK_ID } EOF手动验证curl -s -X POST YOUR_WEBHOOK_URL \ -H Content-Type: application/json \ -d { msg_type: interactive, card: { header: {title: {tag: plain_text, content: ARIS Test}, template: blue}, elements: [{tag: markdown, content: Push mode working!}] } }群里出现蓝色卡片即成功之后auto-review-loop、run-experiment等技能会在关键事件自动推送。场景 B双向交互约 15 分钟先完成场景 A 的推送配置两种模式并存在飞书开放平台创建企业自建应用并开通机器人能力关键权限包括im:message、im:message:send_as_bot、im:message.group_at_msg:readonly、im:message.p2p_msg:readonly极易遗漏不开则机器人永远收不到私聊消息、im:resource事件回调选择长连接模式并添加im.message.receive_v1事件提交版本审核部署桥接服务feishu-claude-code 或本仓库的 mcp-servers/feishu-bridge配置FEISHU_APP_ID/FEISHU_APP_SECRET/FEISHU_USER_ID更新 ARIS 配置cat ~/.claude/feishu.json EOF { mode: interactive, webhook_url: https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_WEBHOOK_ID, interactive: { bridge_url: http://localhost:5000, timeout_seconds: 300 } } EOF此后技能行为变为群卡片推送状态 私聊做决策checkpoint 审批、继续/停止、自定义指令。常见问题排查症状原因处理机器人连上但收不到消息缺少im:message.p2p_msg:readonly权限开通权限 → 创建新版本 → 发布机器人回复但不认识项目DEFAULT_CWD指向错误目录修改配置 → 重启桥接旧 session 上下文过时修改配置前的 session 被缓存在聊天中发送/new开启新 session保存事件时提示未检测到连接桥接服务尚未启动先启动桥接再保存事件配置八、扩展与边界多平台复用push 模式的 webhook 协议适用于任何支持 incoming webhook 的服务Slack、Discord、钉钉、企业微信只需替换webhook_url并调整卡片格式交互模式可参照社区桥接方案如 cc-connect、lark-openapi-mcp做适配集成文档完整的中文配置教程含飞书开放平台权限表、长连接保存时序、私聊测试步骤见 docs/integrations/FEISHU_CN.md英文版见 docs/integrations/FEISHU.md配置迁移路径其他 IM 桥接示例与多平台选择见集成文档其他 IM 平台一节。需要说明的适用前提interactive模式依赖外部桥接服务feishu-claude-code 或仓库内的 feishu-bridge 参考实现持续运行且需要飞书开放平台应用凭证若桥接不可用技能会自动降级为 push 或静默跳过不影响主流程。结语feishu-notify以零影响保证为根基、以统一事件契约Event Catalog为骨架把飞书能力做成了 ARIS 生态中一个可插拔的通知/审批层push 模式负责状态广播interactive 模式负责远程决策超时自动继续保证无人值守。结合 skills/feishu-notify/SKILL.md、mcp-servers/feishu-bridge/server.py 与 tests/test_feishu_bridge_server.py 三份文件你既能按协议接入任意 Agent 工作流也能深入底层理解其长轮询回复机制真正把边睡边跑实验变成手机在手审批我有。赞分享AI 技能/插件AI 评测科研人工智能MCP 服务dsh-plugin【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep点击查看免费下载相关推荐ARIS 飞书/Lark 集成实战从 Webhook 推送通知到手机端双向交互审批ARIS 飞书/Lark 集成实战从 Webhook 推送通知到手机端双向交互审批 ARISAuto Research In Sleep默认以纯 CLIAI 技能/插件AI 评测科研人工智能MCP 服务dsh-pluginARIS 与飞书/Lark 集成实战指南Webhook 推送与双向交互审批ARIS 与飞书/Lark 集成实战指南Webhook 推送与双向交互审批 本文基于仓库 docs/integrations/FEISHU.md https:AI 技能/插件AI 评测科研人工智能MCP 服务dsh-plugin飞书审批提单工作流实战lark-cli approval 从搜索定义到创建审批实例飞书审批提单工作流实战lark cli approval 从搜索定义到创建审批实例 导读 本文以官方 Lark/飞书 CLIlark cli的 larkCLIAI 技能创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表