把一周要交的东西从群聊、笔记和转发邮件里捞出来,这件事本身比做还烦。SlothDigest 的做法是:文件丢进 inbox 文件夹,跑一条命令,第二天早上拿到一份短简报——按截止时间排好的前三件优先事项,外加每个文件一句话摘要。

打开网易新闻 查看精彩图片

测试用的 inbox 里放了三份编造的文件:一封短邮件、一段约 35 行的群聊、一份笔记,合计 1,891 个字符。在作者自己的笔记本上,本地运行的 1B 参数 Gemma 模型用 34 秒给出了三条优先事项。多次运行耗时在 34 到 51 秒之间。文件内容是虚构消息,不涉及个人数据。

输出的三条任务是这样的:

  • 回复供应商(周一前),来自 email.txt
  • 为周一的评审准备 5 页幻灯片(周一前),来自 notes.md
  • 周三晚上前填好预算表(周三前),来自 groupchat.txt

排序依据是截止日期还有几天。这次运行发生在周一,所以周一的条目算作今天到期。

一条命令跑起来的流程

整个东西是一个小的 Node 加 TypeScript 脚本。对每个文件,它向通过 Ollama 本地运行的 Gemma 3(1B)要严格 JSON:一句话摘要,加一组带截止时间的任务。Zod 校验每一个回答。所有文件的任务合并、去重、按截止时间排序,前三名写进 brief.json 和一个纯 HTML 页面。

运行方式:装 Ollama,执行 ollama pull gemma3:1b,然后 cd agent、npm install、npx tsx src/index.ts,HTML 视图再跑 npx tsx src/page.ts。

1B 模型容易演示,难被信任

作者列了五种实际翻车的情况,以及对应的处理代码:

  1. 字段缺失。笔记文件里模型返回了一个没有截止时间的任务,校验连续两次拒掉整个文件,兜底逻辑又悄悄丢掉了两个真实任务。修法:缺失的截止时间记为 null,并在提示词里要求必须带上这个键。
  2. 任务列表里混进非任务。模型把一个不是任务对象的东西塞进列表,校验再次失败。修法:校验前先过滤掉所有非对象,并要求只返回对象。
  3. 卡进循环。Ollama 中止了一次请求,报 500 错误说触发了 token 重复上限,模型开始自我重复。修法:重试一次,再不行走纯文本兜底,保证简报总能产出。
  4. 编造截止时间。对"给电工打电话,不急"这句,模型说截止时间是今天。第一版修法是检查日期词是否出现在文件任意位置,结果放过了"更新幻灯片(明天前)",因为群里有人说"明天见"。有效的修法:日期词只有出现在与任务匹配的那一行源文本里,或出现在任务文本本身,才保留。
  5. 两个请求被合并成一个。一封邮件说周五前发幻灯片、周一前回复供应商,模型把它变成一个错误任务"周一前给供应商发幻灯片"。加了一条拆分请求的提示词规则后,最后一次运行做对了。1B 模型不是确定性的,所以这算改善,不算解决。

被放弃的部分:最初想用 Mastra 搭脚手架,但在慢网络下安装器的 60 秒限制把它杀掉了,npm install 花了大约五分钟。于是直接调 Ollama 的 HTTP API。这是一个脚本,不是完整的 agent 框架。

本地跑的三个理由

文件从磁盘到 localhost 上的模型进程,没有账号、没有 API 密钥、什么都不上传。成本上,一次性下载不到 1 GB 之后,每次运行不花钱。脚本只和 localhost 通信,模型下载完成后不需要联网——不过作者注明没有在关掉 Wi-Fi 的情况下测过。模型名是一个环境变量,换别的开源模型不用改代码,但其他模型也还没测。

更大的托管模型很可能不会犯这些错,作者也没有测。但用小开源模型,每一个失败都看得见,每一个都能用普通代码修掉,这才是他信任输出的原因。

懒人收益与边界

三个文件、1,891 个字符,变成三条正确且有序的任务,用时 34 秒。局限也很清楚:摘要比任务弱,有一条还在提猫的生日;只认星期几、"今天"和"明天",不认日历日期;只读 .txt 和 .md;只显示前三项任务;1B 模型仍会出错,简报需要人眼过一遍。目前是手动运行,下一步是用 Windows 任务计划程序做定时。

这个项目投的是 Hacktoberfest 开源 AI 挑战赛第三周"慢而稳",同时报名 Gemma 最佳用例——整条流水线都跑在通过 Ollama 本地运行的 Gemma 3(1B)上。作者提到自己用 Claude 当结对程序员,把终端报错的照片贴回去,一个一个修,上面五个 bug 都是真实发生在他屏幕上的。