[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-922":3,"consumer-news-interaction-922":39,"consumer-news-related-922":42},{"detail":4,"item":35},{"card":5,"schemaVersion":22,"fields":23,"content":29},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":15,"href":16,"sourceName":12,"meta":17,"metrics":19,"tags":20,"resolved":21},"NEWS_ARTICLE:922","news","NEWS_ARTICLE",922,"资讯","用 crontab 给 LLM 使用量装上“监控眼”","博客园","在把大模型接入日常工作流之后，笔者很快遇到了一个新问题：模型到底被用了多少次？每天的高峰时段是什么时候？周末是不是真的没人调用？如果对这些数据一无所知，就谈不上优化成本、排查异常，更谈不上为后续扩容做规划。 于是，笔者为 LLM 使用量加了一层可观测性，做法很简单——用 Linux 自带的 cron","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F635610\u002F202608\u002F635610-20260830013552425-1810240964.png","","\u002Fnews\u002F922",[18],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":24,"summary":13,"description":13,"publishTime":25,"updateTime":26,"sourceUrl":27,"language":28},"AlfredZhao","2026-08-30T01:36","2026-09-02T20:37:56","https:\u002F\u002Fwww.cnblogs.com\u002Fjyzhao\u002Fp\u002F22757555","中文",{"format":30,"policy":31,"normalized":21,"html":32,"text":33,"wordCount":34,"hasBody":21},"HTML","NEWS_CONTENT_V1","\u003Cp>在把大模型接入日常工作流之后，笔者很快遇到了一个新问题：模型到底被用了多少次？每天的高峰时段是什么时候？周末是不是真的没人调用？如果对这些数据一无所知，就谈不上优化成本、排查异常，更谈不上为后续扩容做规划。\u003C\u002Fp>\n\u003Cp>于是，笔者为 LLM 使用量加了一层可观测性，做法很简单——用 Linux 自带的 \u003Ccode>crontab\u003C\u002Fcode> 定时任务，周期性采集使用数据。下面把这份配置拆开讲讲。\u003C\u002Fp>\n\u003Ch2>01 | 定时任务的整体设计\u003C\u002Fh2>\n\u003Cp>先看完整的 \u003Ccode>crontab\u003C\u002Fcode> 配置：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>$ crontab -l\n# 工作日：09:00–11:45、14:00–17:45，每 15 分钟\n*\u002F15 9-11,14-17 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\n# 工作日：12:00、18:00 各执行一次\n0 12,18 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\n# 工作日夜间：20:00、00:00、04:00、08:00，每 4 小时\n0 0,4,8,20 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\n# 周末全天：每 4 小时\n0 *\u002F4 * * 0,6 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\n# 每周一 08:01 额外执行一次\n1 8 * * 1 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>所有任务都指向同一个脚本 \u003Ccode>\u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\u003C\u002Fcode>，脚本负责采集当前时间点的 LLM 调用数据。区别只在于触发频率不同，这样既能覆盖关键时段，又不会给系统带来太大负担。\u003C\u002Fp>\n\u003Ch2>02 | 工作日：白天加密采样\u003C\u002Fh2>\n\u003Cp>工作日的白天是 LLM 使用的高峰期，所以采样频率最高。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>*\u002F15 9-11,14-17 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>这段配置的含义是：周一至周五，在 9 点到 11 点 45 分、14 点到 17 点 45 分这两个时间段内，每 15 分钟执行一次脚本。\u003Ccode>*\u002F15\u003C\u002Fcode> 表示“每 15 分钟”，\u003Ccode>9-11,14-17\u003C\u002Fcode> 用逗号并列了两个小时段，\u003Ccode>1-5\u003C\u002Fcode> 限定为工作日。\u003C\u002Fp>\n\u003Cp>这样密集的采样，可以清晰还原白天的工作节奏——比如上午 10 点是不是比下午 3 点调用更频繁，午休前后有没有明显回落。\u003C\u002Fp>\n\u003Ch2>03 | 工作日：午间与傍晚定点记录\u003C\u002Fh2>\n\u003Cpre>\u003Ccode>0 12,18 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>中午 12 点和傍晚 18 点各执行一次。这两个时间点比较特殊：12 点是午休边界，18 点是下班前后。单独记录这两个时刻的数据，有助于观察“午休是否真的没人用模型”以及“下班后是否还有零散调用”。\u003C\u002Fp>\n\u003Ch2>04 | 工作日夜间与周末：低频兜底\u003C\u002Fh2>\n\u003Cpre>\u003Ccode>0 0,4,8,20 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>工作日的夜间和清晨，调用量通常很低，没必要保持 15 分钟一次的频率。这里改为每 4 小时一次，覆盖 20 点、0 点、4 点和 8 点四个时间点，保证全天 24 小时都有数据落点，不会出现观测盲区。\u003C\u002Fp>\n\u003Cp>周末的情况类似：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>0 *\u002F4 * * 0,6 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Ccode>0,6\u003C\u002Fcode> 表示周六和周日，\u003Ccode>*\u002F4\u003C\u002Fcode> 表示每 4 小时一次。周末整体调用量偏低，低频采样足够反映趋势，同时避免无意义的重复执行。\u003C\u002Fp>\n\u003Ch2>05 | 每周一的额外校准\u003C\u002Fh2>\n\u003Cpre>\u003Ccode>1 8 * * 1 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>每周一早上 8 点 01 分额外执行一次。注意这里用的是 \u003Ccode>1 8\u003C\u002Fcode>，而不是 \u003Ccode>0 8\u003C\u002Fcode>，刻意错开整点。这样做的目的是笔者这里的LLM是每周8点重置额度，可测试发现原本整8点采样的结果还是未重置的状态，所以这里专门加了这条一分钟的offset，保证可以及时捕捉到重置额度的关键信息。不然有时候不小心提早就用超了，期待着能赶在重置时刻第一时间就恢复满血状态，可前端如果因为没及时采样到而一直显示0%，看起来也是非常焦虑啊。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F635610\u002F202608\u002F635610-20260830013552425-1810240964.png?w=720&quality=65&strip=all\" alt=\"image.png\">\u003C\u002Fp>\n\u003Ch2>小结\u003C\u002Fh2>\n\u003Cp>整套定时任务的核心思路是：\u003Cstrong>高峰时段加密采样，低谷时段低频兜底，关键节点单独记录\u003C\u002Fstrong>。通过 \u003Ccode>crontab\u003C\u002Fcode> 的灵活配置，笔者用极小的系统开销，换来了对 LLM 使用量全天候、分时段的清晰观测。有了这些数据，后续无论是做成本分析、容量规划，还是排查异常调用，都有了可靠的依据。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F635610\u002F202608\u002F635610-20260830013601540-1824172018.png?w=720&quality=65&strip=all\" alt=\"image.png\">\u003C\u002Fp>\n\u003Cp>关注我，和AI一起成长~\u003C\u002Fp>","在把大模型接入日常工作流之后，笔者很快遇到了一个新问题：模型到底被用了多少次？每天的高峰时段是什么时候？周末是不是真的没人调用？如果对这些数据一无所知，就谈不上优化成本、排查异常，更谈不上为后续扩容做规划。 于是，笔者为 LLM 使用量加了一层可观测性，做法很简单——用 Linux 自带的 crontab 定时任务，周期性采集使用数据。下面把这份配置拆开讲讲。 01 | 定时任务的整体设计 先看完整的 crontab 配置： $ crontab -l # 工作日：09:00–11:45、14:00–17:45，每 15 分钟 *\u002F15 9-11,14-17 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh # 工作日：12:00、18:00 各执行一次 0 12,18 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh # 工作日夜间：20:00、00:00、04:00、08:00，每 4 小时 0 0,4,8,20 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh # 周末全天：每 4 小时 0 *\u002F4 * * 0,6 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh # 每周一 08:01 额外执行一次 1 8 * * 1 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh 所有任务都指向同一个脚本 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh，脚本负责采集当前时间点的 LLM 调用数据。区别只在于触发频率不同，这样既能覆盖关键时段，又不会给系统带来太大负担。 02 | 工作日：白天加密采样 工作日的白天是 LLM 使用的高峰期，所以采样频率最高。 *\u002F15 9-11,14-17 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh 这段配置的含义是：周一至周五，在 9 点到 11 点 45 分、14 点到 17 点 45 分这两个时间段内，每 15 分钟执行一次脚本。*\u002F15 表示“每 15 分钟”，9-11,14-17 用逗号并列了两个小时段，1-5 限定为工作日。 这样密集的采样，可以清晰还原白天的工作节奏——比如上午 10 点是不是比下午 3 点调用更频繁，午休前后有没有明显回落。 03 | 工作日：午间与傍晚定点记录 0 12,18 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh 中午 12 点和傍晚 18 点各执行一次。这两个时间点比较特殊：12 点是午休边界，18 点是下班前后。单独记录这两个时刻的数据，有助于观察“午休是否真的没人用模型”以及“下班后是否还有零散调用”。 04 | 工作日夜间与周末：低频兜底 0 0,4,8,20 * * 1-5 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh 工作日的夜间和清晨，调用量通常很低，没必要保持 15 分钟一次的频率。这里改为每 4 小时一次，覆盖 20 点、0 点、4 点和 8 点四个时间点，保证全天 24 小时都有数据落点，不会出现观测盲区。 周末的情况类似： 0 *\u002F4 * * 0,6 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh 0,6 表示周六和周日，*\u002F4 表示每 4 小时一次。周末整体调用量偏低，低频采样足够反映趋势，同时避免无意义的重复执行。 05 | 每周一的额外校准 1 8 * * 1 \u002Fhome\u002Falfred\u002Fscripts\u002Fllm_usage.sh 每周一早上 8 点 01 分额外执行一次。注意这里用的是 1 8，而不是 0 8，刻意错开整点。这样做的目的是笔者这里的LLM是每周8点重置额度，可测试发现原本整8点采样的结果还是未重置的状态，所以这里专门加了这条一分钟的offset，保证可以及时捕捉到重置额度的关键信息。不然有时候不小心提早就用超了，期待着能赶在重置时刻第一时间就恢复满血状态，可前端如果因为没及时采样到而一直显示0%，看起来也是非常焦虑啊。 小结 整套定时任务的核心思路是：高峰时段加密采样，低谷时段低频兜底，关键节点单独记录。通过 crontab 的灵活配置，笔者用极小的系统开销，换来了对 LLM 使用量全天候、分时段的清晰观测。有了这些数据，后续无论是做成本分析、容量规划，还是排查异常调用，都有了可靠的依据。 关注我，和AI一起成长~",1702,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":16,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":38},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":40,"likeCount":41,"commentCount":41,"contentLikeCount":41,"contentCommentCount":41,"sourceLikeCount":41,"sourceCommentCount":41},false,0,[43,52,58,65,73,80,86,93],{"id":44,"kind":7,"title":45,"summary":46,"image":47,"href":48,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":50},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[51],"人工智能",{"id":53,"kind":7,"title":54,"summary":55,"image":15,"href":56,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":57},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":59,"kind":7,"title":60,"summary":61,"image":62,"href":63,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":64},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":66,"kind":7,"title":67,"summary":68,"image":15,"href":69,"meta":70,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":71},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[72],"软件开发",{"id":74,"kind":7,"title":75,"summary":76,"image":77,"href":78,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":79},"NEWS_ARTICLE:831","Agent Sandbox 规模化：JuiceFS 探索与实践","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","\u002Fnews\u002F831",[7,8],{"id":81,"kind":7,"title":82,"summary":83,"image":15,"href":84,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":85},"NEWS_ARTICLE:830","百智云长期记忆服务：长期记忆与上下文窗口的区别","很多人在接触 AI 长期记忆时，第一反应是：「这不就是把聊天记录存起来吗？」其实这是一个很常见的误解。今天我们把「长期记忆」和「上下文窗口」这两个概念彻底讲清楚。 一、什么是上下文窗口 上下文窗口（Context Window）是模型在单次推理时能「看到」的文本上限。它像一个临时的工作台：模型只能处","\u002Fnews\u002F830",[7,8],{"id":87,"kind":7,"title":88,"summary":89,"image":90,"href":91,"meta":49,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":92},"NEWS_ARTICLE:835","体验向量数据库 qdrant","作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 背景 为了早点搞懂公司的百万行 C# 的祖传代码，我想在缺乏文档、缺乏帮手的情况下，先建立一个 企业知识库 来快速帮我理清头绪。 一开始，我是打算以 weav","https:\u002F\u002Fimg2022.cnblogs.com\u002Fblog\u002F1457949\u002F202202\u002F1457949-20220216153819145-1193738712.png","\u002Fnews\u002F835",[51],{"id":94,"kind":7,"title":95,"summary":96,"image":15,"href":97,"meta":18,"badge":10,"author":12,"stats":-1,"accent":36,"coverRatio":37,"tags":98},"NEWS_ARTICLE:833","如何利用AI技术实现漫画翻译","漫画作为图文结合的特色文化载体，承载着各国潮流文化与人文故事，但跨语言的文字壁垒，长期制约着漫画的传播与交流。传统漫画翻译高度依赖人工操作，需要人工框选文字、擦除原图文字、翻译文案、排版适配画风，流程繁琐、耗时费力，且极易出现排版错乱、画风违和、语义偏差等问题。 随着深度学习、计算机视觉与大模型技术","\u002Fnews\u002F833",[7,8]]