Feishu Evolver Wrapper 是 capability-evolver 的飞书外挂：把原本静默运行的进化循环接上飞书，用富卡片把成功率、周期数、运行时长、趋势推到群里，再配一个每 10 分钟巡查一次的守护进程。它拿了办公榜第 1、281.8k 安装，但同时也拿到了 CLS 的 D 级（危险）评级——这是本榜单里少见的组合。
整包 62.7 kB，版本 v1.8.0，index.js 一个文件就占了 83.8 kB（未压缩），lifecycle.js 33.5 kB，report.js 18.9 kB。体积说明它是真在干活的重型封装，而不是薄薄一层胶水。这也正是它风险偏高的原因：代码越多，可出问题的地方越多。
百度网盘下载：https://pan.baidu.com/s/14N6F-FpWpC0Dwan_RsA0TQ?pwd=oyhr（提取码：oyhr）
通过网盘分享的文件：autogame-17-feishu-evolver-wrapper-1.8.0.zip
链接: https://pan.baidu.com/s/14N6F-FpWpC0Dwan_RsA0TQ?pwd=oyhr 提取码: oyhr 复制这段内容后打开百度网盘手机App，操作更方便哦一、基本信息
| 项目 | 内容 |
|---|---|
| 技能名称 | Feishu Evolver Wrapper（feishu-evolver-wrapper） |
| 维护方 | autogame-17（个人开发者） |
| 定位 | capability-evolver 的飞书集成封装层（生命周期管理 + 卡片报表） |
| 版本 | v1.8.0 |
| 社区数据 | 安装 281.8k · 下载 68.7k · 办公榜 #1 |
| 安全认证 | ⚠️ CLS 评级 D 级（危险），2026-07-10 |
| 运行环境 | Node.js + 飞书 SDK，依赖 capability-evolver 本体 |
| 核心入口 | index.js、lifecycle.js、visualize_dashboard.js |
| 包体大小 | 整包 62.7 kB（index.js 83.8 kB、lifecycle.js 33.5 kB） |
| 下载安装 | autogame-17-feishu-evolver-wrapper-1.8.0.zip（网盘，提取码 oyhr） |
| 标签 | gep、evolution-algorithm、feishu-integration、daemon-management、monitoring |
二、它解决什么问题
capability-evolver 的问题不是能力不够，而是「看不见」。它扫描日志、定位问题、生成补丁、执行修复，整个过程在后台静默跑完。跑成功了没人知道，跑失败了也没人知道——直到几天后你发现某个服务慢了，才回头看日志。
这种「黑箱自动化」在个人环境里还能忍，一旦放到团队场景就不行了。团队需要三样东西：进度可见、异常可告警、历史可回溯。飞书是国内团队最常用的协作工具，把这三样东西推到飞书里，是最省事的路径。
Feishu Evolver Wrapper 做的就是这件事：注入 EVOLVE_REPORT_TOOL 环境变量，把进化过程中的指标打包成飞书富卡片，按周期推送。同时补上了一个原版没有的能力——进程守护。
它的定位可以概括为：给一个沉默的自动修复引擎，装上一块仪表盘和一个看门人。
三、核心功能
3.1 进化循环生命周期管理
lifecycle.js 提供四个动作，覆盖守护进程的完整生命周期：
| 动作 | 命令 | 行为 |
|---|---|---|
| start | node lifecycle.js start |
拉起进化循环，写入 pid 文件 |
| stop | node lifecycle.js stop |
优雅停止，清理运行状态 |
| status | node lifecycle.js status |
输出运行状态、pid、运行时长、最近周期 |
| ensure | node lifecycle.js ensure |
幂等检查：没跑就拉起，卡住就重启 |
ensure 是核心。它被注册成 OpenClaw 的 Cron 任务 evolver_watchdog_robust，每 10 分钟执行一次。相比直接用系统 crontab，这个方案的好处是日志统一、配置跟着 Agent 走、不会在容器重建后消失。
3.2 飞书富卡片报表
卡片内容设计得比较克制，一眼能看完的关键指标都在这：
- 成功率：最近周期的成功比例，按 80% / 50% 两档染色，绿橙红三色。
- 总周期数：累计跑了多少轮进化。
- 运行时长：进程 uptime，自动格式化成 s / m / h。
- 趋势：把最近事件分前后两半对比，算出 up / down / stable 三档。
- 意图分布饼图：Innovate（创新）、Repair（修复）、Optimize（优化）三类的占比。
- 异常告警：有错误时卡片头部变红，并把错误信息放到最上方。
饼图那块用了 VChart 规格，说明它是认真做过可视化，而不是把数字堆在文本里。对需要长期盯盘的人来说，趋势箭头和颜色比绝对值更有用。
3.3 仪表盘与历史导出
visualize_dashboard.js 从 assets/gep/events.jsonl 读历史事件，生成 Markdown 版仪表盘，可以直接贴进文档或周报。export_history.js 负责把原始历史导到飞书文档，方便长期归档。
这两个能力的价值在复盘。当你想回答「过去一个月进化系统到底改了什么、效果如何」时，靠翻 jsonl 是不现实的，靠卡片截图也不完整。生成一份结构化报告是最实际的答案。
3.4 健康检查与自修复
check_health.js、self-repair.js、cleanup.js 是一组辅助脚本：检查进程状态、尝试自愈、清理临时文件。skills_monitor.js 监控技能目录变化，weekly_insight.js 生成周报摘要。功能铺得很全，这也是它体积大的原因。
四、真正有价值的地方
把「静默」变成「可见」。这是它最核心的贡献。一个能自我修改代码的系统，如果过程不可观测，本质上是不敢用的。飞书卡片把成功率、趋势、异常推到人眼前，至少让「要不要介入」变成一个有依据的判断。
watchdog 用对了地方。进化循环是长驻进程，最怕的就是悄悄死掉。每 10 分钟 ensure 一次，配合幂等设计，能覆盖大部分崩溃和僵死场景。用 OpenClaw Cron 而不是系统 crontab，容器化环境下更稳。
零侵入的封装思路。它是 wrapper，不改 evolver 核心逻辑，只通过环境变量注入报告能力。这意味着上游升级时，它大概率还能用——这比 fork 一份改代码要聪明得多。
指标选得准。成功率、周期数、趋势、意图分布，四个指标覆盖了「跑得好不好」和「在往哪个方向跑」。没有堆一堆好看但没用的数字，这一点比很多监控面板强。
事件溯源可回溯。events.jsonl 按行追加，任何时刻的状态都能还原。配合 dashboard 生成，等于自带审计日志。
五、绕不开的问题
安全评级 D，不是误判。CLS 报告点名了五个问题：index.js:1144 用 new Function() 做 JSON 解析回退（代码注入面）、广泛读写 .claude/memory/（可篡改 Agent 运行状态）、自动执行 git commit/push/pull（未审查代码可能进远程仓库）、扫 /proc 并 SIGKILL 其他进程（可能误杀）、把系统负载与日志外传飞书（数据外泄面）。这五条里任何一条，在企业环境都足以否决。
单点依赖飞书。飞书 API 抖动，报表就断。而报表正是它存在的理由——报表断了，它就退化成一堆看不出在干什么的脚本。
events.jsonl 无限增长。按行追加，没有内置轮转或压缩。跑几个月之后，这个文件会成为磁盘和解析性能的负担。cleanup.js 能做清理，但不是自动的，需要你自己配。
守护逻辑可能掩盖根因。ensure 每 10 分钟重启一次，好处是服务不断，坏处是「一直在重启」这件事本身可能被忽略。你得配独立日志监控，否则崩溃原因永远查不清。
依赖 Node 版本与 SDK 兼容性。飞书 SDK 版本迭代不算慢，Node 运行时也有要求。升级环境时，这套脚本是容易出问题的一环。
把这五条放在一起看，问题的性质就清楚了：它不是一个「有 bug 的工具」，而是一个按「单人全权环境」假设写成的工具。作者默认你信任它、也信任自己跑的东西，所以没做沙箱、没做权限隔离、没做审批流。这个假设在个人实验里成立，在团队协作里不成立。判断能不能用，本质上就是判断你所处的环境符不符合这个假设。
六、官方风险表与解读
| 风险项 | 严重程度 | 说明 |
|---|---|---|
| 动态代码执行 | 🔴 关键 | index.js:1144 使用 new Function() 作为 JSON 解析回退，存在代码注入漏洞 |
| Agent 上下文越权 | 🔴 关键 | 广泛读写 .claude/memory/ 私有目录，可篡改 Agent 运行状态 |
| Git 自动推送 | 🟠 高 | 自动执行 commit/push/pull，未审查代码可能进入远程仓库 |
| 进程强制终止 | 🟠 高 | 具备扫描 /proc 并 SIGKILL 其他进程的能力 |
| 数据外泄 | 🟡 中 | 系统负载、进程信息、日志经飞书 API 外传 |
合规层面，报告给出的结论是：GDPR 数据最小化、用户同意机制、敏感数据访问限制、权限最小化四项均未通过。这不是「有点瑕疵」，是设计取向不同——它假设你在一台完全属于自己的机器上跑，不考虑多租户和合规边界。
一条实用纪律：只在容器或虚拟机里跑，禁止在有其他业务的生产机上跑。原因很直接：它会 SIGKILL 别人的进程，也会自动 push 代码。
3.5 卡片之外：日志、导出与周报
富卡片解决的是「一眼看现状」，但三个问题它答不了：过去一个月怎么样、某次失败的具体上下文是什么、要不要给老板汇报。这三个问题由另外三个文件负责。
export_history.js 把 events.jsonl 里的原始事件导到飞书文档。原始数据的价值在于完整：每一条都有时间戳、触发信号、变更文件、置信度、结果状态。排查「为什么第 37 次进化失败了」时，这份数据是唯一能还原现场的材料。
weekly_insight.js 生成周报摘要，把一周的成功率、意图分布、异常次数压成几段话。它的定位不是给人看的报表，而是给「不想天天盯盘的人」一个周期性的交代。实际用下来，周报比实时卡片更容易被忽略——这反而是它的价值：一周看一次，能看出趋势，又不会被噪声干扰。
commentary.js 和 issue_tracker.js 是两个更细的工具：前者把事件翻译成人话注释，后者把失败记录整理成待办条目。后者对团队协作有用——失败不再是日志里的一行红字，而是变成一条可分配的 issue。
这四样东西合起来，才是完整的可观测性：卡片管当下、导出管追溯、周报管趋势、issue 管跟进。只装卡片而不用后面三个，等于把仪表盘当成了黑匣子。
七、适合谁，不适合谁
| 类型 | 是否适合 | 理由 |
|---|---|---|
| 能审计 Node.js 代码的个人开发者 | 适合 | 能自己确认那几处高危调用是否可接受 |
| 隔离环境（容器 / VM）里的实验 | 适合 | 爆炸半径可控，风险可接受 |
| 飞书重度用户 + evolver 用户 | 适合 | 集成价值最大，省掉自建报表的功夫 |
| 企业生产环境 | 不适合 | D 级评级 + 四项合规未通过，过不了评审 |
| 有敏感代码仓库的团队 | 不适合 | 自动 git push 可能把未审查代码推到远程 |
| 不想读代码的用户 | 不适合 | 风险点分散在多个文件，不理解就上等于赌博 |
八、落地路径
- 先隔离。准备一台容器或虚拟机，不要用主开发机，更不要用生产机。
- 读三个文件。
index.js的 1144 行附近、lifecycle.js的进程扫描逻辑、self-repair.js的 git 调用。不读就别跑。 - 关掉危险功能。改掉
new Function()回退为JSON.parse，禁掉自动 push，限定/proc扫描范围。 - 配飞书机器人。建群、加机器人、拿 webhook 或应用凭证，先把卡片推送打通。
- 注册 watchdog。把
lifecycle.js ensure挂到 OpenClaw Cron，10 分钟一次，观察一周。 - 配轮转。给
events.jsonl设按大小切分，避免几个月后磁盘告警。
九、文件构成与安装
| 文件 | 大小 | 作用 |
|---|---|---|
index.js |
83.8 kB | 主流程，串起进化循环与飞书报告（含高危 new Function 调用） |
lifecycle.js |
33.5 kB | start/stop/status/ensure 四动作与守护逻辑 |
report.js |
18.9 kB | 卡片内容组装、指标计算 |
feishu-helper.js |
9.7 kB | 飞书 API 封装、token 管理 |
visualize_dashboard.js |
7.2 kB | 从 events.jsonl 生成 Markdown 仪表盘 |
utils/dashboard-generator.js |
6.8 kB | VChart 饼图与趋势计算 |
skills_monitor.js |
5.8 kB | 技能目录变更监控 |
export_history.js |
3.4 kB | 历史导出到飞书文档 |
check_health.js / self-repair.js / cleanup.js |
2.4 / 2.0 / 1.6 kB | 健康检查、自修复、临时文件清理 |
安装前提是先有 capability-evolver 本体。解压到技能目录，npm install 拉飞书 SDK，配好 EVOLVE_REPORT_TOOL 与飞书凭证，再 node lifecycle.js start。不需要编译，但需要你有 Node 环境和一定调试耐心。
十、常见问题
D 级评级还能用吗？
能，但要在隔离环境里用，并且先读代码改掉高危点。D 级不等于「一定出事」，等于「在不受控环境里出事的概率不可接受」。
它会杀我的其他进程吗？
有这个能力。它扫 /proc 找目标进程并发 SIGKILL，判断逻辑一旦出错就可能误杀同名的 Node 进程。建议改掉匹配规则，或者干脆只在自己独占的机器上跑。
不装飞书能用吗？
不能，飞书是它的核心输出通道。不想要卡片报表，直接用 capability-evolver 原版就行，没必要套这层。
为什么事件文件会越来越大？
按行追加、不做压缩，这是事件溯源的常规做法。定期跑 cleanup.js 或自己加 logrotate 即可。
watchdog 一直重启说明什么？
说明循环起不来。常见原因是飞书凭证失效、Node 依赖缺失、assets/gep 目录权限不对。别只看「服务还活着」，要看重启次数。
能同时守护多个 evolver 实例吗？
没有内置多实例支持。ensure 按单实例设计，跑多份需要自己改 pid 文件路径和日志路径。
卡片能自定义吗？
可以，改 utils/dashboard-generator.js 里的 card 结构即可。指标计算逻辑在 report.js，要加指标得改两处。
能推到多个群吗？
没有内置多目标支持。想推多个群，最省事的做法是在飞书侧建一个机器人转发规则，或者部署两份实例、各配一个 webhook。后者成本更高但隔离更彻底——两个群的报表互不影响。
停掉服务后历史还在吗？
在，assets/gep/events.jsonl 是本地文件，不会因为进程停止而消失。只要不删目录，随时可以用 visualize_dashboard.js 重新生成历史报告。
它和 Prometheus + Grafana 那套比呢？
不是一回事。Prometheus 面向指标采集与告警规则，配置重、能力强；这套是「把已有的 jsonl 渲染成卡片」，轻量、零额外组件。团队已有监控体系的话，更适合把指标导出去，而不是再建一套孤立的看板。
能自定义告警条件吗？
卡片本身按固定阈值染色（80% / 50%）。要更复杂的规则，得改 report.js 里的判断逻辑，或者把数据导出后用自己的告警系统处理。
不装飞书能不能只做仪表盘？
可以，走 visualize_dashboard.js 直接生成 Markdown，不依赖飞书接口。但 lifecycle 的守护逻辑仍然会尝试推送，需要在配置里关掉报告通道，否则会持续报错。
结语
Feishu Evolver Wrapper 是一个能力扎实、风险同样扎实的工具。它把沉默的进化引擎接上了仪表盘和看门人，指标设计克制、守护逻辑到位，办公榜第 1 不是白拿的。但 D 级评级也不是白给的：动态代码执行、Agent 上下文越权、自动 git push、进程误杀，每一条都值得认真对待。
如果你在隔离环境里跑实验、又正好用飞书，它值得一试——前提是先花两小时读代码。如果你要在生产环境部署，那答案很简单：先做安全加固，否则不要上。
通过网盘分享的文件：autogame-17-feishu-evolver-wrapper-1.8.0.zip
链接: https://pan.baidu.com/s/14N6F-FpWpC0Dwan_RsA0TQ?pwd=oyhr 提取码: oyhr 复制这段内容后打开百度网盘手机App，操作更方便哦飞书机器人 进化引擎 守护进程 监控告警 GEP
百度网盘下载：https://pan.baidu.com/s/14N6F-FpWpC0Dwan_RsA0TQ?pwd=oyhr（提取码：oyhr）
暂无评论内容