Bash 定时 Agent 拆分简报
你是独立开发者自动化顾问。只根据用户约束写提问清单，不要编造已上线。
例行任务列表：{{jobs}}
数据源：{{sources}}
月预算上限：{{monthly_budget}}
输出 Markdown：
1. 一任务一脚本的拆分表
2. 每脚本状态落点与幂等键
3. 超时/预算帽/失败通知
4. 人工周维护清单
禁止建议无帽调用；禁止声称月费已固定。← 返回用例列表
René：生产里跑约 10 个 Agent，全是带预算帽的 Bash 脚本
对照个人生产实践：触发→取数→限域提示→写回/通知；日跑约 $1、周规划约 $5、筛选约 $0.25、月约 $80；弃框架改脚本；不代你保证稳定、不外推账单。
场景说明
面向独立开发者把 Agent 当真生产任务：把「再上一层编排框架」写成可对账的单职责定时脚本+状态管理+硬预算帽，区别于 Personal OS 晨报与 n8n 总控。
案例叙事
01他们做了什么
René Zander 在《I Run 10 AI Agents in Production. They're All Bash Scripts.》（页内 March 12, 2026；JSON-LD datePublished 2026-03-12 → 2026-03-12）写明：约十个生产 Agent 处理日简报、团队跟进、任务分类、周报与职位筛选等「不炫但有用」的活；架构一律是 Trigger → Fetch data → Scoped prompt → Write output → Notify。无框架、无编排层、无 Agent 互聊协议——各自独立脚本，带超时与预算帽。
成本口径（作者自述）：日跑约 $1/次，周规划因上下文更大约 $5，职位筛选用更小模型约 $0.25；合计月约 $80。状态是核心：例如保留最近约 500 个已处理邮件 message ID，防重处理；夜间增量重嵌向量（元数据-only 变更跳过），否则约 30 分钟可压到约 30 秒；跟进笔记按日期追加不删。维护数据管道（陈旧描述、上下文膨胀、双写）比调提示更耗时。曾试框架约三个月后放弃：同一行修复，框架多出中间件/状态层排障面。设计教训：先状态、一 Agent 一职、可预测节奏优先定时而非 webhook 链、第一天就设硬花费上限触顶大声失败。本场景据此输出「Bash 定时生产 Agent」提纲。禁止把约 $80 写成对你账单的承诺。
02实际效果
- 源披露约 10 个 Agent、日/$1·周/$5·筛选/$0.25、月约 $80，以及约 500 条 message ID 与增量同步等作者窗口数字；属个人生产叙事，不可外推为你的云账单或故障率。
- 能把「再上 Agent 框架」与「单职责脚本 + 状态文件 + 硬预算帽」拆开。
- 为状态损坏导致重复通知、上下文膨胀与超预算提供提问清单。
03值得知道
- 脚本栈把复杂度推到运维纪律；缺监控时静默失败更难发现。
- 成本随模型价与任务量变；文中数字是作者当时窗口。
- 上面写的是个人博客生产复盘，不是某云厂商官方 Agent 文档。
04可复制提示词
状态损坏重复通知复盘提纲
Agent 因状态文件损坏对同一批邮件重复告警，请写复盘提纲。
症状：{{symptom}}
状态文件形态：{{state_shape}}
输出：
1. 是未原子写、并发写，还是缺校验和
2. 最小修复
3. 回填/去重步骤
4. 人工确认清单
不要伪造「收件箱已自动洁净」。怎么做
- 粘贴要自动化的例行任务、数据源与单次/月预算上限
- Agent 按实践帖输出：单职责拆分→状态落点→超时与预算帽→通知边界提问清单
- 人工保留出站与删改权；Agent 不代你声称月费已固定为 $80
实用提示
- 源帖关键：状态（已处理邮件 ID、向量增量同步、任务笔记追加）比模型调用更吃时间；框架失败变成框架调试
- 与 tobias-personal-os-n8n-claude-todoist / flux-run-budget-llm-router 不同：本条是多枚单职责 Bash 定时 Agent+经验成本表，不是 n8n Personal OS 或 run 级 LLM 路由产品