Work Summary
本周期工作集中在基础设施运维层面。主要触发点是 Grafana 监控发现磁盘持续增长，排查后定位到 Docker 容器日志无限制输出是主因，完成了镜像清理和 log rotation 配置。同期还处理了 cron 定时任务中 claude 命令找不到的环境变量问题，根因是 cron 不加载 zsh 的 PATH 配置。
此外探索了 poco 远程桌面工具，评估后决定删除，保持环境简洁。整体来看这个周期以"救火"和环境维护为主，缺乏主动的功能开发或架构改进。
Improvement Areas
1. Docker 运维：缺乏主动监控和预防机制
现象：磁盘涨满才发现问题，靠 Grafana 告警被动响应，没有预防性的清理策略。
根因：容器日志没有配置 max-size / max-file，镜像也没有定期 prune 的自动化任务。
行动项：
- 在
/etc/docker/daemon.json全局设置"log-driver": "json-file", "log-opts": {"max-size": "50m", "max-file": "3"} - 添加 weekly cron：
docker system prune -f --filter "until=168h" - Grafana 磁盘告警阈值降到 70%，提前预警
2. Cron 环境隔离问题反复踩坑
现象：zsh:1: command not found: claude 在 cron 中出现，需要人工介入排查。
根因：cron 使用最小环境，不加载 ~/.zshrc 或 ~/.profile，nvm/conda 等工具的 PATH 注入全部失效。
行动项：
- cron 脚本统一用绝对路径，或在脚本头部显式
source ~/.profile - 建立 cron 调试模板：
* env > /tmp/cron-env.log先确认环境再写任务 - 关键 cron 任务加执行日志和失败告警
3. LLM Agent 成本意识薄弱
现象：日常使用 Claude Code 时没有意识到 token 消耗模式，缺乏分层调用策略。
根因：对 Opus/Haiku 分层架构没有实践经验，所有任务都走最贵的模型。
行动项：
- 参考 Mendral 的"triager + planner + executor"三层架构：Haiku 做分类和读取，Opus 只做规划
- 对重复性任务（日志分析、格式转换）先用 Haiku 过滤，再决定是否升级
- 监控每次 growth-analysis 的 token 消耗，建立基线
Strengths
- 问题定位能力强：磁盘问题从 Grafana 发现到定位 Docker 日志根因，路径清晰，没有盲目猜测
- 工具链熟练：能快速在 docker inspect、journalctl、df/du 之间切换，运维工具使用流畅
- 决策果断：评估 poco 工具后直接删除，不留技术债
Action Items
- P0 - 配置 Docker 全局日志限制 → 防止磁盘再次被日志打满
- P0 - 修复所有 cron 任务使用绝对路径 → 消除环境依赖问题
- P1 - 实现 Haiku triager 层用于 growth-analysis → 降低 token 成本 ~60%
- P2 - Grafana 磁盘告警阈值调整为 70% → 提前 2-3 天预警
Tech Trends
今日 HackerNews 热门技术话题精选。
1. Ghostty is leaving GitHub
Points: 1669 | Comments: 539
Mitchell Hashimoto 宣布将 Ghostty 迁出 GitHub，核心原因是可靠性：他追踪了一个月的 GitHub 故障，发现"几乎每天都有中断"。4 月 27 日的大规模宕机成为压垮骆驼的最后一根稻草，GitHub Actions 中断导致 PR review 流程停摆约两小时。他的不满不针对 Git 本身，而是 Issues、PR、Actions 这套围绕 Git 的基础设施。
这个决定有深厚的情感背景——Hashimoto 是 GitHub 第 1299 号用户，2008 年加入，称其为"让我最快乐的地方"。迁移计划已酝酿数月，目的地尚未公布，正在与多家商业和开源平台洽谈。GitHub 上会保留只读镜像。
对开源项目的启示：中心化平台的可靠性已成为 OSS 工作流的硬依赖。当一个深度忠实的维护者都到达临界点，说明平台可用性问题已经从"偶发不便"升级为"工程风险"。
Key Takeaways:
- GitHub 可靠性问题已影响到顶级开源项目的托管决策
- 自托管或多平台镜像策略值得提前规划，不要等到出问题再迁移
2. GitHub RCE Vulnerability: CVE-2026-3854
Points: 245 | Comments: 61
CVE-2026-3854 是 GitHub 内部 git 基础设施中的严重注入漏洞。git push 时，push options 通过内部 X-Stat header 以分号分隔的 key=value 传递，但 babeld 没有对分号做转义，攻击者可以注入任意字段。由于 header 采用 last-write-wins 语义，注入字段会静默覆盖合法安全设置。
RCE 链由三步注入构成：覆盖 rails_env 绕过沙箱 → 重定向 custom_hooks_dir 到攻击者控制路径 → 注入 repo_pre_receive_hooks 触发路径遍历执行。git 用户对共享存储节点有广泛文件系统访问权限，Wiz 确认数百万公私有仓库数据可被访问。
GitHub.com 在报告后 6 小时内完成修复。GitHub Enterprise Server 修复版本为 3.14.24+、3.15.19+、3.16.15+ 等，但披露时约 88% 的 GHES 实例仍未打补丁。
Key Takeaways:
- 自托管 GitHub Enterprise 用户需立即升级，88% 未打补丁是高危现状
- header 注入 + last-write-wins 是经典的信任边界问题，网关/代理层的 header 处理要格外注意分隔符转义
3. We decreased our LLM costs with Opus
Points: 21 | Comments: 0
Mendral 通过三层架构将 Opus 的使用压缩到只处理"新问题"：一个廉价的 Haiku triager 处理 80% 的 CI 失败（判断是否是已知问题的重复），成本约为完整调查的 1/25。只有新型失败才升级到 Opus。
Opus 介入时也不直接读原始数据——不是把 200K 行日志塞进 prompt，而是让 agent 通过 SQL 查询 ClickHouse 只拉相关数据。Opus 只做规划，派发窄范围的子任务给 Haiku 执行。最终 Haiku 处理约 65% 的输入 token，但只占 36% 的费用。
Key Takeaways:
- "贵的模型思考，便宜的模型读取"是可落地的成本控制原则
- 上下文管理（任务后丢弃）和数据预过滤（SQL 而非全量日志）是降成本的两个关键杠杆
4. Claude system prompt bug wastes user money and bricks managed agents
Points: 78 | Comments: 22
Claude Code 中存在一个 system prompt bug，导致 managed agents 在特定条件下陷入循环，持续消耗 token 直到上下文耗尽。受影响的场景主要是多 agent 编排中的 sub-agent，问题在于 system prompt 的某个指令与 agent 的终止条件产生了语义冲突。
Key Takeaways:
- 使用 Claude Code managed agents 时需要监控 token 消耗，设置硬性上限
- agent 编排中的 system prompt 设计要显式定义终止条件，避免歧义