Felix - Blog

背景在构建自动化运营体系时，定时推送是最常见的需求之一。比如： 每天定时推送销售数据看板 定时推送报价更新通知 定时推送系统健康报告 然而，我在实现定时推送时踩了不少坑。这篇文章记录了从踩坑到找到正确方法的完整过程。 踩坑过程错误思路：OpenClaw cron delivery我一开始尝试使用 OpenClaw 自带的 cron 和 delivery 机制，结果反复失败： 123456789# 错误示例openclaw cron add \ --name "daily-push" \ --cron "0 18 * * *" \ --session "isolated" \ --channel "feishu" \ --to "user:ou_xxx" \ --announce \ --message "推送消息内容" 问题： isolated session 没有访问 channel 的权限 delivery 配置复杂，容易出错 消息身份...

最近在技术社区看到不少人讨论 OpenClaw 这个 AI Agent 工具。它的 Logo 像个虾钳，所以圈里人管这叫”养虾”。 和 ChatGPT 这种”你问我答”的聊天机器人不一样，AI Agent 是直接动手干活的。给它一个指令，它能读代码、找 Bug、分析文档，甚至从零搭建项目。 但不少新手配置好 API，跑了一晚上，第二天看账单就崩溃了——几百万 Token，几十美金没了。 这篇文章分享两个实测可用的零成本方案，以及如何避免不必要的 Token 消耗。 Token 消耗的真相很多人以为发一句”帮我写个网页”，AI 就只收这一句话的钱。其实不是。 AI Agent 的核心模式是”循环迭代”。简单理解： 读取整个项目文件（消耗 5 万 Token） 写代码发现报错，开始反思（消耗 2 千 Token） 为了修复 Bug，把刚才读过的文件、写错的代码、报错信息全部再看一遍（消耗 6 万 Token） 80% 的成本浪费在重复阅读冗余上下文上。 不加限制，复杂任务分分钟能抽干钱包。 方案一：Google Gemini 免费额度如果你电脑配置一般，可以考虑 Google 的...

别再把 OpenClaw 当聊天机器了！掌握 5 个核心技巧，彻底榨干”大龙虾”一、OpenClaw 进阶使用技巧的正确姿势深夜两点，桌面上堆满了待处理的邮件、还没整理的会议纪要、一堆需要下载的文件。打开 OpenClaw，输入”帮我整理一下今天的工作”，AI 秒回了一大段废话。又试了”帮我看看明天有什么安排”，又是一堆不痛不痒的建议。 这玩意儿不就是个不用翻墙的 ChatGPT 吗？除了能聊天，还能干啥？ 然后刷知乎，看到有人用 OpenClaw 做了个全自动工作流，每天自动抓取 GitHub 热门项目、生成简报、推送到飞书。又看到有人用它做了个价格监控机器人，盯了好几个电商平台，一有降价立刻通知。甚至还有人让它自己写代码、自己调试、自己部署——全程不用人管。 开始怀疑：我是不是用了个假 OpenClaw？ 尝试按照教程装了几个 OpenClaw Skills，结果不是报错就是跑不起来。试着配置定时任务，结果一觉醒来，API 费用被烧了几百块，任务还没办成。这个工具是不是被吹过头了？ 问题到底出在哪？ 二、OpenClaw 新手的三个致命误解很多人对 OpenClaw 有三个致...

一个深夜的场景凌晨两点，你躺在床上刷手机，看到又一条新闻：某大厂裁员，AI 自动化了某个岗位。你开始计算自己的工作内容有多少能被替代，越想越清醒。第二天上班，老板在会上提到要引入 AI 工具提效，你下意识摸了摸自己的岗位说明书，心里冒出一个念头：我还能干多久？ 这种场景，过去一年在无数人的生活中重演。焦虑像慢性感冒，不致命，但持续消耗你的注意力和判断力。你尝试过学 Python、看 AI 教程、报名各种课程，结果越学越焦虑——技术更新太快，追不动。你又试过”躺平”心态，告诉自己”船到桥头自然直”，但每次看到 AI 相关的新闻，焦虑还是会跳出来。 这背后到底缺了什么？为什么我们越努力对抗焦虑，焦虑反而越强？ 那些听起来很对但没用的答案最常见的建议是：学技术，跟上时代。 听起来很有道理。但问题是，你学的速度永远追不上 AI 迭代的速度。GPT-4 出来刚一年，GPT-5 就在路上了。你刚学会用 Midjourney，新的图像生成工具又出来了。技术学习变成了无底洞，越学越觉得自己落后。 另一个常见建议是：AI 只是工具，不会取代人。 这句话也很有道理。但如果你仔细看那些被自动化的岗位—...

4月14日，OpenAI要发GPT-6了。内部代号”Spud”（土豆），听着有点随意，但这次发布可能是AI行业三年来最重要的一次。 确认的信息OpenAI在4月8日官宣，GPT-6将于4月14日全球同步发布。预训练已经在3月17日完成，目前在做最后的安全对齐和API调试。 这次研发周期18个月，训练投入超过20亿美元，用了大约10万张H100 GPU。参数规模在5到6万亿之间，但因为是混合专家架构（MoE），实际激活的参数只有10%左右。 三个核心升级200万Token上下文这是最直观的提升。200万Token大约相当于150万字，两部《三体》的体量。 以前处理长文档，要么分段，要么用RAG（检索增强生成）。现在可以直接把整个代码仓库、几十份合同、一套产品文档塞进去，模型能完整理解。 但有个工程问题：上下文越长，推理成本越高。腾讯云的测算显示，中小型知识库用长上下文方案，比RAG更简单准确，但每次查询的成本和延迟都上去了。 原生多模态统一GPT-6用的是”Symphony”架构，文本、图像、音频、视频在同一向量空间处理。以前的多模态是模块拼接——文本模型加个图像理解插件，像让语言...

凌晨搞定了博客图片优化，顺手把源码同步到了 GitHub。过程比预想的曲折，记录一下。 WebP 图片优化博客加载速度一直不算快，首页背景图 172KB，头像 95KB。WebP 格式能省不少流量，决定试一下。 用 ffmpeg 转了两张主图： 12ffmpeg -i avatar.jpg -q:v 75 avatar.webpffmpeg -i home-bg-final.jpg -q:v 75 home-bg-final.webp 效果还行： 头像：95KB → 33KB（省 65%） 背景：172KB → 79KB（省 54%） 总共省了 155KB。 改了 Butterfly 主题配置 _config.butterfly.yml，把图片引用从 .jpg 改成 .webp。hexo generate 之后确认图片路径正确，收工。 Git 仓库同步博客源码一直在服务器本地，没有版本控制。今天顺手初始化了 Git 仓库，想推到 GitHub 备份。 然后踩坑开始了。 Git 连接 GitHub 失败git push 一直超时，7 秒左右就断。试了几个 GitHub 镜像：...

问题现象在飞书中与 OpenClaw 交互时，状态信息始终显示： 1📌 Tasks: 1 active · 1 total · subagent · 完成飞书文档到静态博客的发布流程 但实际上这个任务早已结束（状态为 killed），属于过期的残留记录。 排查过程1. 初步定位首先使用 subagents list 查看任务列表： 12345{ "total": 1, "active": [], "recent": []} 结果显示 total=1，但 active 和 recent 都为空，说明数据不一致。 2. 查找数据源OpenClaw 的任务数据存储在多个位置： ~/.openclaw/subagents/runs.json - 子代理运行记录（JSON 格式） ~/.openclaw/tasks/runs.sqlite - 任务运行记录（SQLite 数据库） ~/.openclaw/flows/registry.sqlite - 流程注册表（SQLite 数据库） 3. 数...

在 AI 技术持续演进的浪潮中，Agent（智能体）的落地成为行业关注的焦点。本文结合行业观点与工程实践，对 Agent 落地的关键逻辑进行系统梳理与深度补充。 一、Agent 落地的本质：解决真实痛点与复杂意图编排Agent 落地的核心命题，首先在于能否解决现实场景的真实痛点。一个无法处理实际问题的 Agent，无论技术架构多么花哨，都称不上真正「可用」。 现实业务的复杂性决定了 Agent 需要处理的往往不是「单一意图」的简单任务，而是多意图的复杂编排——可能跨领域、跨基础设施、跨软件系统。例如： 场景 涉及意图 复杂度 商务旅行规划 查询航班、预订酒店、安排行程、处理报销 跨系统 企业客服 Agent 意图识别、知识检索、工单创建、满意度跟进 多轮对话 代码审查 静态分析、漏洞检测、规范检查、建议生成 串行 + 并行 多意图编排的核心挑战在于意图的拆解、排序与状态管理，这要求 Agent 不仅要「理解」用户需求，还要具备「规划」与「执行」的闭环能力。 二、基座模型的三大核心能力Agent 高效落地的技术基石是基座模型，模型需具备以下三项关键能力： 2...

引言专家最值钱的东西，不是他们知道什么，而是他们如何判断。 一个 10x 工程师之所以快，不是因为他技术文档看得多，而是因为他在拿到一个问题时，脑子里已经跑了一个隐形的决策树：这个问题属于哪类？应该先查什么？什么时候该停？ 这种判断框架，是隐性知识，写不出来，只能还原。 Skill 是 OpenClaw 的能力扩展单元。本文的方法论是把专家的隐性知识封装进 skill——不是写教程，是还原判断机器。 专家知识的三层结构纯显性记录（文档/博客）只能捕获第三层： 层级 内容 被捕获的难度 元规则 面对 X 情况，优先做 Y；什么时候停，什么时候转 最难，需要还原 方法论 解决某类问题的固定套路 中等，通常被简化 具体答案 可直接使用的结论/方案 易，但价值最低 专家说出来的方法论，通常是事后合理化的，不是他真实使用的。 三层同时存在，但大多数知识管理只捕获了第三层。 四步提取法第一步：观察——不是问，是看不要问专家”你怎么想的”。问他实际怎么做： 拿到一个问题，他默认先查什么？ 多个约束冲突时，他先放弃哪个？ 他什么时候知道”这不...

概述@tdai/memory-tdai 是一个运行在 OpenClaw 上的四层本地记忆系统插件。核心特性：完全离线、四层渐进式提炼、零外部依赖，通过 LLM 将对话原始数据逐层抽象为结构化记忆、场景块和用户画像。 本文深入解析其核心机制，源代码级解读。 整体架构12345678910111213141516171819202122232425对话结束 │ ▼┌─────────────────────────────────────────────────────────┐│ L0 Capture 对话录制 SQLite vec0 + JSONL 双写 │└────────────────────┬──────────────────────────────────┘ ▼┌─────────────────────────────────────────────────────────┐│ L1 Extraction 记忆提取 本地 LLM → 场景切分+去重 │└───...