最近刚好有业务需求，就寻思去买点云手机做海外营销。但打开闲鱼之后发现有挺多这样能够代充值的业务，而且最低的我看能做到 5.8 折，感觉还是挺颠的。 这东西渠道总感觉怪怪的，有没有懂得佬，来讲讲 1 个帖子 - 1 位参与者 阅读完整话题
每次让他帮我读取飞书的聊天记录的时候或者发信息的时候就直接完成，装死 lark-cli im +messages-search --chat-id oc_90b1e95ada7f1d9946c14269b11918d9 --start “2026-05-11T00:00:00+08:00” --end “2026-05-11T23:59:59+08:00” --page-all --format json --as user { “ok”: false, “identity”: “user”, “error”: { "type": "permission", “code”: 99991679, “message”: “Permission denied [99991679]”, “hint”: “check app permissions or re-authorize: lark-cli auth login”, “detail”: null } } 2 个帖子 - 1 位参与者 阅读完整话题
rt, 写完代码，让codex 调用 lark cli 填写流程和日报爽的一批 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 在之前的版本(<0.3.0)中，LarkDocx2md 只能读取 */wiki/* 链接文档，不支持支持飞书电子表格，此处更新到 0.3.0+，支持多种来源的电子表格处理。这里会将电子表格转化为 Markdown 格式（这个库是为 Agent 读取飞书文档准备的，不是给人准备的）。 github： GitHub - Byte-n/larkDocx2md: 飞书（lark）文档导出未 Markdown 格式，支持文档内的画板数据导出。AI 友好，支持 Agent Skill · GitHub 支持多种来源的电子表格 */wiki/* 链接文档中嵌套的电子表格 */wiki/* 链接电子表格 */sheets/* 链接的电子表格 （移除 sheet=* 参数，将处理所有的 sheet ） 表格的跨行跨列通过重复后续的行和列的值实现： --agent local 改参数会在内部强制 --image-mode=local 、 --wb-image-mode=local （Markdown、图片、画板中的图片均落盘）； --wb-format 默认 yaml ，仅允许 inline-svg / yaml ；stdout 输出引导 AI 读取文件的提示词（包含绝对路径）。 同时 Skill 中的默认 --agent 也转为 --agent local 2 个帖子 - 2 位参与者 阅读完整话题
我想推荐一个我最近做的飞书 CLI Skill：lark-retro GitHub： https://github.com/gkzzhs/lark-retro 它的目标很简单：用一句话生成飞书工作复盘 / 周报。 比如你只要对 AI Agent 说： > 帮我做一下上周的回顾 它就会自动通过飞书 CLI 读取日历、会议纪要/会议记录、任务、消息、文档等数据，整理成一份结构化复盘报告，并写入飞书文档。还可以继续创建行动项任务、追踪上期行动项、归档到知识库或 Bitable ，甚至预约下一次回顾会议室。 我做这个 Skill 的原因是，写周报和复盘最麻烦的地方不是“写”，而是到处找材料：翻日历、翻群聊、找任务、找上期报告。lark-retro 希望把这些零散的工作痕迹串起来，让 AI Agent 真正基于飞书里的真实数据来生成报告，而不是凭空写一篇看起来很像周报的文字。 目前它已经适配到 lark-cli v1.0.21 ，支持一些比较新的能力，比如： - 会议纪要 / 会议记录分析 - OKR 对齐和进展记录分析 - 审批阻塞信号补强 - 历史回顾文档搜索和权限申请补救 - 群消息 @ 提及过滤 - Bitable 行动项归档和记录分享链接 - 多会议室名称查找、日程搜索、下期回顾预约和更新 - 知识库归档、报告文件夹和快捷方式管理 我也把真实测试记录写在仓库里了，包括哪些能力完整跑通过，哪些能力只是做了权限或边界验证，避免只写 README 不实测。 如果你也经常写周报、Sprint Retro 、项目复盘，或者想看看飞书 CLI Skill 能把一个办公流程做到什么程度，可以试试这个项目： https://github.com/gkzzhs/lark-retro
项目地址： https://github.com/RyanWeb31110/lark-cli-codex-app 最近在折腾一个小项目：让飞书/Lark 变成 Codex App 的远程入口。 我想解决的不是简单的“机器人回复消息”，而是一个更完整的闭环： 人在飞书/Lark 里发起任务 -> 本地 gateway 接收消息事件 -> 任务分发给 Codex App / codex exec -> Codex 在本机读取代码、运行命令、操作浏览器或桌面 -> Codex 通过 lark-cli / skills 操作飞书 -> 结果回写到飞书对话、文档、日历、表格等协作对象 https://i.v2ex.co/wp9YaoVXl.png 简单说，就是： 飞书负责入口和协作，Codex App 负责本地执行，中间这个项目负责把两边接起来。 为什么做这个 我现在越来越觉得，很多 AI agent 的关键问题不是“模型能不能回答”，而是它能不能进入真实工作流。 比如我在外面，只带手机，突然想到一个任务： 让家里或办公室电脑上的 Codex 看一下某个仓库 跑一轮测试 查一个报错 总结某个飞书文档 把结论回到飞书群里 必要时再触发本地浏览器或桌面操作 如果只是一个聊天 bot ，它通常只能做到“收消息、回消息”。 但 Codex App 本来就在本地，能看到 workspace ，能运行命令，能读写文件，也有 computer use / skills / 多任务这些方向。那飞书/Lark 更适合做的事情，其实是成为 Codex App 的远程控制面和团队协作界面。 所以这个项目想做的是： 飞书/Lark 发起和承接任务 Codex App 在本地真实执行 lark-cli-codex-app 负责事件接入、任务分发和结果回写 为什么选择 Codex App ，而不是使用通用 agent 我也看过 OpenClaw 、Hermes 这类项目。它们更像是从 agent runtime 开始做一套完整系统：长期运行、记忆、工具编排、多入口交互、任务调度都自己承载。 这个路线很强，也很适合做通用个人助理。 但我这个项目的边界不一样。我不太想重新造一个 agent runtime ，而是更想依托 Codex App 已经有、并且未来还会继续增强的能力。 Codex App 更贴近真实工程任务：本地代码上下文、终端、文件、浏览器、computer use 、skills 、多任务、插件生态，这些都天然适合开发者工作流。 所以我希望把精力放在另一个问题上： 飞书/Lark 如何可靠地触发 Codex ？ Codex 如何把结果自然地回写到飞书/Lark ？ 需要 GUI 操作时，如何交给本地 Codex App 处理？ 这样边界会比较清楚： agent 能力交给 Codex App 演进 飞书/Lark 集成由这个项目打磨 本地执行和团队协作之间形成闭环 目前已经有的东西 项目是基于 yjwong/lark-cli 的 MIT fork 做的扩展，保留了原许可证。 当前主要包含： 飞书/Lark CLI：日历、消息、文档、通讯录、表格、多维表格、邮件、妙记等操作 Codex 插件元数据：可以作为 Codex plugin 项目使用 skills 目录：把常见飞书操作封装成 Codex 可调用的技能 gateway 模式：通过飞书/Lark WebSocket 长连接接收消息事件，不需要公网 callback agent bridge：把飞书消息分发给本地 codex exec desktop task queue：把 GUI / computer use 类任务放进本地桌面任务队列 README 里整理了中文说明和流程图 和普通 bot 的区别 普通 bot 更像是： 聊天软件 -> bot -> 回复 我想做的是： 飞书/Lark -> 本地 Codex App -> 电脑 / 代码 / 浏览器 / 飞书 -> 飞书/Lark 也就是不只是“回复一段话”，而是让 Codex 能在本地真的把事情做完，再把结果带回协作场景。 现在还比较早期 这个项目现在还不是一个非常成熟的产品，更像是一个方向已经明确的开源原型。 我接下来比较想继续打磨这些点： 降低飞书/Lark 应用配置门槛 让 gateway 的事件日志、任务状态和错误排查更清楚 把桌面任务队列和 Codex App 前台操作串得更顺 让 README 和安装流程更适合第一次尝试的人 继续补充 Codex skills ，让飞书操作更自然 如果你也在折腾 Codex App 、本地 agent 、飞书/Lark 自动化，欢迎看看这个项目，顺手提 issue 或拍砖。 项目地址： https://github.com/RyanWeb31110/lark-cli-codex-app
项目地址： https://github.com/RyanWeb31110/lark-cli-codex-app 最近在折腾一个小项目：让飞书/Lark 变成 Codex App 的远程入口。 我想解决的不是简单的“机器人回复消息”，而是一个更完整的闭环： 人在飞书/Lark 里发起任务 -> 本地 gateway 接收消息事件 -> 任务分发给 Codex App / codex exec -> Codex 在本机读取代码、运行命令、操作浏览器或桌面 -> Codex 通过 lark-cli / skills 操作飞书 -> 结果回写到飞书对话、文档、日历、表格等协作对象 https://i.v2ex.co/wp9YaoVXl.png 简单说，就是： 飞书负责入口和协作，Codex App 负责本地执行，中间这个项目负责把两边接起来。 为什么做这个 我现在越来越觉得，很多 AI agent 的关键问题不是“模型能不能回答”，而是它能不能进入真实工作流。 比如我在外面，只带手机，突然想到一个任务： 让家里或办公室电脑上的 Codex 看一下某个仓库 跑一轮测试 查一个报错 总结某个飞书文档 把结论回到飞书群里 必要时再触发本地浏览器或桌面操作 如果只是一个聊天 bot ，它通常只能做到“收消息、回消息”。 但 Codex App 本来就在本地，能看到 workspace ，能运行命令，能读写文件，也有 computer use / skills / 多任务这些方向。那飞书/Lark 更适合做的事情，其实是成为 Codex App 的远程控制面和团队协作界面。 所以这个项目想做的是： 飞书/Lark 发起和承接任务 Codex App 在本地真实执行 lark-cli-codex-app 负责事件接入、任务分发和结果回写 为什么选择 Codex App ，而不是使用通用 agent 我也看过 OpenClaw 、Hermes 这类项目。它们更像是从 agent runtime 开始做一套完整系统：长期运行、记忆、工具编排、多入口交互、任务调度都自己承载。 这个路线很强，也很适合做通用个人助理。 但我这个项目的边界不一样。我不太想重新造一个 agent runtime ，而是更想依托 Codex App 已经有、并且未来还会继续增强的能力。 Codex App 更贴近真实工程任务：本地代码上下文、终端、文件、浏览器、computer use 、skills 、多任务、插件生态，这些都天然适合开发者工作流。 所以我希望把精力放在另一个问题上： 飞书/Lark 如何可靠地触发 Codex ？ Codex 如何把结果自然地回写到飞书/Lark ？ 需要 GUI 操作时，如何交给本地 Codex App 处理？ 这样边界会比较清楚： agent 能力交给 Codex App 演进 飞书/Lark 集成由这个项目打磨 本地执行和团队协作之间形成闭环 目前已经有的东西 项目是基于 yjwong/lark-cli 的 MIT fork 做的扩展，保留了原许可证。 当前主要包含： 飞书/Lark CLI：日历、消息、文档、通讯录、表格、多维表格、邮件、妙记等操作 Codex 插件元数据：可以作为 Codex plugin 项目使用 skills 目录：把常见飞书操作封装成 Codex 可调用的技能 gateway 模式：通过飞书/Lark WebSocket 长连接接收消息事件，不需要公网 callback agent bridge：把飞书消息分发给本地 codex exec desktop task queue：把 GUI / computer use 类任务放进本地桌面任务队列 README 里整理了中文说明和流程图 和普通 bot 的区别 普通 bot 更像是： 聊天软件 -> bot -> 回复 我想做的是： 飞书/Lark -> 本地 Codex App -> 电脑 / 代码 / 浏览器 / 飞书 -> 飞书/Lark 也就是不只是“回复一段话”，而是让 Codex 能在本地真的把事情做完，再把结果带回协作场景。 现在还比较早期 这个项目现在还不是一个非常成熟的产品，更像是一个方向已经明确的开源原型。 我接下来比较想继续打磨这些点： 降低飞书/Lark 应用配置门槛 让 gateway 的事件日志、任务状态和错误排查更清楚 把桌面任务队列和 Codex App 前台操作串得更顺 让 README 和安装流程更适合第一次尝试的人 继续补充 Codex skills ，让飞书操作更自然 如果你也在折腾 Codex App 、本地 agent 、飞书/Lark 自动化，欢迎看看这个项目，顺手提 issue 或拍砖。 项目地址： https://github.com/RyanWeb31110/lark-cli-codex-app
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 lark-cli-codex-app：用飞书/Lark 远程控制 Codex App 的本地闭环工作流 项目地址： github.com GitHub - RyanWeb31110/lark-cli-codex-app: A token-efficient CLI for Lark/Feishu APIs,... A token-efficient CLI for Lark/Feishu APIs, designed for AI assistants like Claude Code. Supports calendar, contacts, documents, and messages. 这是一个围绕 Codex App 和飞书/Lark 做的本地控制项目。简单说，它想解决的是： 人在飞书里发消息、派任务；本地 Codex App 收到后在电脑上执行；Codex 可以读取本地仓库、运行命令、操作浏览器/桌面，也可以通过飞书/Lark API 回写消息、文档、日历、表格、多维表格等协作对象。 也就是说，飞书/Lark 既是远程入口，也是协作结果的回写界面； 依托 Codex App 的原生能力； Codex App 则负责真正的本地执行、代码理解、工具调用和 computer use。 这个项目想做什么 我自己理解的核心链路是： 人在飞书/Lark 发起任务 -> 本地 gateway 接收飞书消息事件 -> 任务分发给 Codex App / codex exec -> Codex 在本机执行代码、终端、浏览器或桌面任务 -> Codex 通过 lark-cli / skills 操作飞书 -> 结果回写到飞书对话、文档、日历、表格等地方 它不是重新造一个 agent，而是依托 Codex App 原生的本地执行能力、代码理解能力、工具调用能力、computer use 能力，以及未来插件生态的潜力，把飞书/Lark 接成一个更适合团队协作的远程控制面。 为什么做这个 我之前试过一些聊天工具控制本地 agent 的方案，很多都停留在“发一条消息，agent 回复一段结果”的单向链路。 但我更想要的是闭环： 我可以在飞书群里让 Codex 排查一个 bug Codex 在本地 workspace 里读代码、跑测试、改文件 需要 GUI 时，可以交给 Codex App / computer use 操作电脑 需要协作时，可以把结果回写到飞书群、文档、任务、表格或多维表格 出门在外时，也能用手机飞书给家里/办公室电脑上的 Codex 派任务 这个场景对我来说挺自然：飞书负责入口和协作，Codex 负责本地执行和智能操作，中间通过一个本地 gateway 串起来。 为什么选择 Codex App，而不是使用 OpenClaw / Hermes 这类通用 agent？ OpenClaw、Hermes 这类项目更像是从 agent runtime 开始构建一套完整的通用助理系统：长期运行、记忆、任务调度、工具编排和多入口交互都由项目自身承载。这条路线很强，也很适合做通用个人助理。 OpenClaw 的稳定性让我崩溃，每次都要单独挂一个 CC、CX 去救OpenClaw。 这个项目没有选择重新造一个 agent runtime，而是选择站在 Codex App 上做飞书/Lark 控制层，原因很简单：我更看重 Codex App 已经具备、并且还会持续增强的原生能力。 Codex App 本身更贴近真实工程任务：它理解本地代码上下文，可以使用终端、文件、浏览器、computer use、skills、多任务和未来插件生态。对我来说，飞书/Lark 不应该替代 Codex App，而应该成为 Codex App 的远程入口和团队协作界面。 所以这个项目的定位不是“再做一个 OpenClaw / Hermes”，而是： 飞书/Lark 负责发起任务、团队协作和结果承接 Codex App 负责本地执行、代码理解、工具调用和 computer use lark-cli-codex-app 负责把两边连成闭环 这样做的好处是边界更清楚：agent 能力交给 Codex App 演进，飞书/Lark 集成交给这个项目打磨。未来 Codex App 的 skills、computer use、多 agent、自动化和本地执行能力越强，这个项目能承接的飞书协作场景也会越多。 当前已经有的能力 目前项目里主要包括： 飞书/Lark CLI：日历、消息、文档、通讯录、表格、多维表格、邮件、妙记等操作 Codex 插件元数据：可以作为 Codex plugin 项目使用 skills 目录：把常见飞书操作封装成 Codex 可调用的技能 gateway 模式：通过飞书/Lark WebSocket 长连接接收消息事件，不需要公网 callback agent bridge：把飞书消息分发给本地 codex exec desktop task queue：把 GUI / computer use 类任务放进本地桌面任务队列 README 里配了两张流程图，方便理解整体链路 和普通 bot 的区别 普通 bot 更像是： 聊天软件 -> bot -> 回复 这个项目想做的是： 飞书/Lark -> 本地 Codex App -> 电脑 / 代码 / 浏览器 / 飞书 -> 飞书/Lark 重点不只是“回复消息”，而是让 Codex 成为一个能在本地真实干活、并能把结果带回协作场景里的执行层。 开源情况 项目是基于 MIT 协议的 yjwong/lark-cli fork 做的扩展，保留了原许可证，并在此基础上增加 Codex App / gateway / desktop queue / skills 相关能力。 当前项目完整开源，没有保留未开源部分。README 中也已链接并认可 LINUX DO 社区： github.com GitHub - RyanWeb31110/lark-cli-codex-app: A token-efficient CLI for Lark/Feishu APIs,... A token-efficient CLI for Lark/Feishu APIs, designed for AI assistants like Claude Code. Supports calendar, contacts, documents, and messages. 欢迎佬友们拍砖，尤其是这几个方向： 飞书控制 Codex App 这个闭环是否还有更自然的交互方式 gateway / desktop queue 的设计是否合理 作为 Codex 插件项目还缺哪些关键能力 有哪些具体的工作场景可以落地 README 和使用门槛哪里还可以继续降低 1 个帖子 - 1 位参与者 阅读完整话题
太太公司做投资咨询的，每天要回复大量重复问题（产品说明、费用标准、流程咨询）。网站流量不多，但问题都很标准。 于是给她做了个 AI 客服： - 上传文档（ PDF/DOCX ）就能生成客服 - 回答只基于上传的文档，每条都附来源引用 - 除了嵌入网站，还接了 Lark 机器人，同事在飞书里直接问 做完之后觉得这东西对很多小团队也有用，就做成了平台 Kodda 。 技术栈是 Next.js + MongoDB + Qdrant ，标准 RAG 管线，7 个环节：上传 → 解析 → 分块 → 向量化 → 存储 → 检索 → 重排序。远程 LLM ，OpenAI 兼容接口。 目前在 public beta ，免费计划够试用的。投顾场景已经跑通了，Lark 集成也能用。 https://kodda.dev 做这个的初衷很简单：不想再一遍遍回答同样的问题了。欢迎同场景的朋友试试看。
太太公司做投资咨询的，每天要回复大量重复问题（产品说明、费用标准、流程咨询）。网站流量不多，但问题都很标准。 于是给她做了个 AI 客服： - 上传文档（ PDF/DOCX ）就能生成客服 - 回答只基于上传的文档，每条都附来源引用 - 除了嵌入网站，还接了 Lark 机器人，同事在飞书里直接问 做完之后觉得这东西对很多小团队也有用，就做成了平台 Kodda 。 技术栈是 Next.js + MongoDB + Qdrant ，标准 RAG 管线，7 个环节：上传 → 解析 → 分块 → 向量化 → 存储 → 检索 → 重排序。远程 LLM ，OpenAI 兼容接口。 目前在 public beta ，免费计划够试用的。投顾场景已经跑通了，Lark 集成也能用。 https://kodda.dev 做这个的初衷很简单：不想再一遍遍回答同样的问题了。欢迎同场景的朋友试试看。
太太公司做投资咨询的，每天要回复大量重复问题（产品说明、费用标准、流程咨询）。网站流量不多，但问题都很标准。 于是给她做了个 AI 客服： - 上传文档（ PDF/DOCX ）就能生成客服 - 回答只基于上传的文档，每条都附来源引用 - 除了嵌入网站，还接了 Lark 机器人，同事在飞书里直接问 做完之后觉得这东西对很多小团队也有用，就做成了平台 Kodda 。 技术栈是 Next.js + MongoDB + Qdrant ，标准 RAG 管线，7 个环节：上传 → 解析 → 分块 → 向量化 → 存储 → 检索 → 重排序。远程 LLM ，OpenAI 兼容接口。 目前在 public beta ，免费计划够试用的。投顾场景已经跑通了，Lark 集成也能用。 https://kodda.dev 做这个的初衷很简单：不想再一遍遍回答同样的问题了。欢迎同场景的朋友试试看。
太太公司做投资咨询的，每天要回复大量重复问题（产品说明、费用标准、流程咨询）。网站流量不多，但问题都很标准。 于是给她做了个 AI 客服： - 上传文档（ PDF/DOCX ）就能生成客服 - 回答只基于上传的文档，每条都附来源引用 - 除了嵌入网站，还接了 Lark 机器人，同事在飞书里直接问 做完之后觉得这东西对很多小团队也有用，就做成了平台 Kodda 。 技术栈是 Next.js + MongoDB + Qdrant ，标准 RAG 管线，7 个环节：上传 → 解析 → 分块 → 向量化 → 存储 → 检索 → 重排序。远程 LLM ，OpenAI 兼容接口。 目前在 public beta ，免费计划够试用的。投顾场景已经跑通了，Lark 集成也能用。 https://kodda.dev 做这个的初衷很简单：不想再一遍遍回答同样的问题了。欢迎同场景的朋友试试看。
太太公司做投资咨询的，每天要回复大量重复问题（产品说明、费用标准、流程咨询）。网站流量不多，但问题都很标准。 于是给她做了个 AI 客服： - 上传文档（ PDF/DOCX ）就能生成客服 - 回答只基于上传的文档，每条都附来源引用 - 除了嵌入网站，还接了 Lark 机器人，同事在飞书里直接问 做完之后觉得这东西对很多小团队也有用，就做成了平台 Kodda 。 技术栈是 Next.js + MongoDB + Qdrant ，标准 RAG 管线，7 个环节：上传 → 解析 → 分块 → 向量化 → 存储 → 检索 → 重排序。远程 LLM ，OpenAI 兼容接口。 目前在 public beta ，免费计划够试用的。投顾场景已经跑通了，Lark 集成也能用。 https://kodda.dev 做这个的初衷很简单：不想再一遍遍回答同样的问题了。欢迎同场景的朋友试试看。
最近我给自己的新产品「云雀通」Larktun 做了一个文档网站。源码放在 GitHub 上，公开访问，日常更新也很简单：我在本地电脑或笔记本上改文档，确认没有问题后提交到 GitHub。 问题出在「部署」这一步。 之前我一直是手动发布。倒不是不想自动化，而是生产服务器配置比较低，不适合把 Node 依赖安装、站点打包、发布脚本这些事情都压在它身上。身边也没有一台现成的 Jenkins 或 CI 服务器。与此同时，我又申请了一台甲骨文免费的 ARM 服务器，配置是 4 核 24G 内存，长期闲置有点可惜。 于是我开始琢磨：能不能把这台闲置服务器变成自动化发布中枢？真正线上服务仍然跑在原生产服务器上，但构建、同步、流水线、部署控制这些重活交给甲骨文服务器。 这一次，我没有手工从零搭环境，而是让 hermes-agent 接管了从方案完善到落地实施的大部分工作。hermes 绑定的是 ChatGPT，使用 gpt-5.4 模型。最后形成的链路是： 我本地更新文档 → GitHub → GitLab → GitLab Runner → deploy → 生产服务器更新 → 发布成功 背景：为什么不直接用 GitHub Actions 对一个公开文档站来说，GitHub Actions 当然是一个很自然的选择。但这次它并不适合我的场景。文档站最终要部署到正式生产服务器，而这台服务器的安全管控比较严格，不能随意把外部 CI 的访问权限接入生产环境。换句话说，GitHub 可以继续作为公开源码仓库，但 GitHub Actions 不能直接进入生产发布链路。 所以我的目标不是「找一个最常见的 CI」，而是在安全边界可控的前提下，把现有资源利用起来，同时尽量不改动自己的工作习惯。 我当时的约束大概有几个： 文档源码已经在 GitHub，继续保留 GitHub 作为公开协作入口。 生产服务器配置较低，不希望在上面执行安装依赖、构建前端、跑流水线等任务。 甲骨文免费 ARM 服务器配置不错，适合承担 GitLab、Runner、构建缓存和自动化任务。 生产服务器是正式环境，安全管控严格，不适合让 GitHub Actions 这类外部 CI 直接持有发布权限。 生产发布需要可控，最好使用专门的低权限账号，避免 CI 拿到过大的服务器权限。 我希望后续不只是这个文档站，其他小项目也能复用这套发布基础设施。 所以最终方案不是把所有东西塞进生产服务器，也不是完全依赖外部平台，而是让甲骨文服务器承担「自动化控制平面」的角色。 方案：GitHub 保持入口，GitLab 负责自动化 整个结构可以理解为两层： 第一层是内容协作层。我仍然在本地写文档、预览、提交，然后推送到 GitHub。这个路径不变，因为它已经足够顺手。 第二层是发布自动化层。甲骨文服务器上部署 GitLab，并将 GitHub 文档仓库同步到 GitLab。GitLab Runner 监听仓库更新，触发打包流程，构建完成后通过专门的 deploy 账号发布到生产服务器。 这个方案的好处是职责很清晰： 环节 职责 放在哪里 写作与源码托管 修改文档、提交代码、公开访问源码 本地电脑 + GitHub 自动化控制 仓库镜像、流水线、任务调度 甲骨文 ARM 服务器 构建 安装依赖、生成静态站点产物 GitLab Runner 发布 上传产物、切换线上版本 生产服务器 deploy 账号 访问 对外提供文档网站 生产服务器 这里面最关键的一点是：生产服务器不参与构建。它只接收已经构建好的静态文件，并完成一次轻量级发布。 hermes-agent 做了什么 我先把自己的想法告诉 hermes-agent：我有一台甲骨文 ARM 服务器，有一个 GitHub 上的文档站仓库，有一台低配置生产服务器，希望实现自动打包和自动发布。 它先帮我完善方案，把实施过程拆成几个阶段： 在甲骨文服务器上准备基础环境。 部署 GitLab，并配置从 GitHub 同步文档仓库。 安装并注册 GitLab Runner。 编写 CI 流水线，让 Runner 完成依赖安装和文档站打包。 为生产服务器创建专门的 deploy 用户。 配置 SSH key、发布目录和权限边界。 编写部署脚本，保证发布过程中网站不会异常。 跑通一次完整链路，并根据失败日志继续修正。 然后它开始执行。 比较有意思的是，hermes-agent 在需要敏感信息的时候会停下来问我。例如 GitLab token、SSH 私钥、公钥部署、生产服务器地址和 deploy 用户信息，这些它不会凭空假设，也不会试图绕过授权。我的角色从「执行每一条命令」变成了「确认方案并提供必要密钥」。 剩下的事情，基本都由它完成：安装 GitLab、部署 GitLab Runner、配置仓库同步、编写流水线、调试构建环境、调整发布脚本、处理权限问题，直到最后能够自动把文档站发布到生产服务器。 发布时不能影响线上访问 我最关心的一点，是自动发布不能把线上文档站搞挂。 如果直接在网站目录里覆盖文件，发布过程中很容易出现短暂的不一致：有些文件已经更新，有些文件还没更新；用户访问时可能遇到资源 404、页面样式错乱，甚至空白页。 更稳妥的做法是「构建产物先上传到新目录，确认完整后再切换线上指针」。也就是说，Runner 先把新的静态文件上传到生产服务器的某个 release 目录，比如： /var/www/larktun-docs/releases/20260426-1130 上传完成后，再把 current 指向这个新目录： /var/www/larktun-docs/current → /var/www/larktun-docs/releases/20260426-1130 Nginx 或其他 Web 服务始终读取 current 。这样发布动作本质上就是一次目录指针切换，速度很快，也方便回滚。 这个策略带来的安全感很明显：如果构建失败，不会发布；如果上传失败，不会切换；只有新版本完整到达生产服务器之后，才会让线上流量看到它。 这套链路有什么好处呢 改造完成后，我的日常操作变成了： 本地修改文档 提交到 GitHub 等待 GitLab Runner 自动构建 自动发布到生产服务器 验证线上页面 和过去相比，最大的变化不是「少敲了几条命令」，而是发布过程变得稳定、可追踪、可复用。 过去手动部署时，我需要记住在哪台机器上执行什么命令、构建产物放在哪里、发布目录怎么更新、失败了怎么恢复。现在这些动作被写进流水线和脚本里，每次都按同样的方式执行。 对我来说，这就是自动化最有价值的地方：它把临时经验变成了可重复流程。 我们需要清楚的知道安全边界 这类自动化方案一旦涉及生产服务器，安全边界必须明确。我的处理方式是给生产服务器专门创建一个发布账号，而不是直接使用 root，限定这个账号的最小权限。 这个 deploy 账号只需要拥有文档站发布目录的权限，不应该能随便操作系统其他目录。SSH key 也只服务于发布流程，后续如果泄露或不再使用，可以单独吊销。 我建议至少注意这几件事： CI/CD 使用专门的 deploy 用户，不使用 root。 发布目录和服务目录权限分离，不给过大的写权限。 SSH 私钥、GitLab token 等敏感信息只放在私有的 GitLab CI 变量或受控位置。 生产服务器保留最近几个 release，方便快速回滚。 首次跑通后，整理关键命令和恢复流程，避免以后只剩「它当时能跑」。 hermes-agent 能把大量工程细节执行到位，但最终的安全策略仍然要由人来确认。尤其是密钥、权限、生产服务器访问范围这些部分，不能完全交给自动化惯性。 关于 hermes-agent 的使用感受 这次体验让我对 agent 类工具的定位有了更具体的认识。 它不是一个只会回答问题的聊天窗口，而更像一个能持续推进任务的远程工程助手。传统上，我可能会问「GitLab Runner 怎么装」「GitLab 怎么同步 GitHub」「rsync 怎么做发布」，然后自己把答案拼起来。hermes-agent 的不同之处在于，它可以从目标出发，把这些步骤串成一个完整方案，并持续执行到环境真正跑起来。 当然，这不代表人可以完全放手。我的参与点仍然很关键： 明确目标：我要的是文档站稳定自动发布。 提供上下文：服务器配置、仓库位置、生产环境限制、密钥来源。 审核方案：确认 GitLab、Runner、deploy 用户这些设计是否符合自己的长期维护习惯。 掌握边界：敏感密钥由我提供，生产权限由我控制。 验收结果：最终以线上文档站是否正常发布为准。 这更像是一种新的协作方式：人负责目标、边界和验收，agent 负责把中间大量繁琐但可执行的工程步骤推进下去。 小结 这次 hermes-agent 实战，最终把一台闲置的甲骨文免费 ARM 服务器变成了云雀通 Larktun 文档站的 CI/CD 中枢。 现在我的发布链路是： 本地电脑 → GitHub → GitLab → GitLab Runner → deploy → 生产服务器 → 发布成功 hermes-agent 帮我完成了从 GitLab 开始的绝大部分工作：部署 GitLab、配置 Runner、同步仓库、编写流水线、设置发布流程、处理构建和权限问题。除了密钥和关键权限由我提供与确认，其余部分基本由它连续推进完成。 这篇文章记录的不是一个复杂到无法复制的架构，而是一个很适合个人开发者、小团队和轻量产品的实践：把闲置资源用起来，把手动经验固化成AI自动流水线，把自己从构建压力中解放出来。 对我来说，这就是 hermes-agent 最有价值的地方。它没有替我决定产品方向，却帮我把一个长期想做、但一直嫌麻烦的基础设施任务真正落地了。 1 个帖子 - 1 位参与者 阅读完整话题
今天openclaw从2026.04.15升级到2026.04.21,又报错了，貌似又是飞书的问题： 报错 Error: Cannot find module '@larksuiteoapi/node-sdk' 安装的是飞书发布的官方插件，之前就因为openclaw自带的飞书插件在3月份搞崩过，换了飞书自己的插件之后又崩了。。。搞不懂是咋想的，这玩意怎么老是破坏性更新，都没人测试直接胡乱发布的吗？ 或者有没有佬友分享一下GA的使用体验，能不能把openclaw这一坨升级如抽奖的破玩意给换了？ 1 个帖子 - 1 位参与者 阅读完整话题
全球最大纸浆生产商巴西Suzano公司即将获得欧盟反垄断监管机构的无条件批准，以推进其与美国消费品巨头Kimberly-Clark价值34亿美元的纸巾业务合资交易。两位知情人士透露，欧盟委员会在5月11日初步审查结束后将亮出绿灯，因其未发现该交易存在任何竞争方面的顾虑。此次收购将使Suzano获得Kimberly-Clark国际纸巾业务51%的股权，涵盖Kleenex、Scott和Cottonelle等知名品牌。（新浪财经）