这周 ArXiv 上又是一堆 agent 论文，什么递归自我改进、软件形式第三转，连 GDP 和人类脱钩 这种活儿都有人接。HN 上基本被编码 agent 占满。但没看到一篇正经讨论时间的。我反而觉得这个最该聊。模型不知道今天是几号，是结构性问题，系统必须注入；但真正让人难受的不是这个，是"下周三"——看起来是字符串解析问题，实际上是语义问题。
模型不知道今天是几号，这不是模型的错
所有 LLM 对"现在"的唯一认知来自训练语料。知识截止日期给了它一个模糊的"大约是哪个年代"的印象，它知道 2026 年有 8 月 20 日这一天，但没有机制知道写输出时是几号。"当前时间必须由系统注入 prompt"，在我这儿不是最佳实践，是硬性要求。
关键是注入方式。放在系统消息第一行，固定格式，每次请求重新生成。别在服务里缓存带日期的 prompt 模板，缓存一小时就错一小时。有人真这么干过——我不说是我。
时区在工具边界丢，ISO 8601 救不了一半
"工具参数统一用带时区的 ISO 8601"，这条规矩我赞成，但它的作用被高估。危险不在接口定义，在中间层。Python 的 datetime.now()、Postgres 的 timestamp without time zone、JavaScript 的 Date.parse()，每一层都会悄悄把带时区的时间降级成 naive 时间。等你从日志里发现"为什么 agent 昨天 14 点删了数据"，那个 +08:00 已经消失在三层抽象里。
我有个笨自测：构造一个 UTC 正午的时间戳传进工具，看它进工具和落库时各变成什么。能扛住这一轮的，时区至少漏一半。绝大多数第一轮就露馅。
"下周三"是个糟糕的 API 参数
模型不会算日历，但它会硬答。你问"下周三的评审安排一下"，它不会说"我不确定你指的是哪一天"，它直接给你个日期。错了也不报错——这是最危险的。
所以相对时间必须在工具内解析，不能交给模型发挥。工具拿到"下周三"要做三件事：取今天的日期、取用户时区、取业务方定义的周起点，然后才能算出具体日期。算完要回显，人也好、模型也好，得有机会看一眼。
这时候准有人说：每次都回显，交互轮数翻倍。
这个批评我认一半。读操作不用回显——查错一个日期的数据，用户瞟一眼结果就发现了。写操作必须回显——订错机票、删错快照，这个错会一直疼。回显做成写操作的专属护栏，比做成全局仪式划算。按我现在看，读写两侧的错误成本差一个数量级都不止，这个取舍值得。
Agent 会替我们把坑再踩一遍
这周 HN 上 Claude Code 的 AGENTS.md feature request 热度不低，ArXiv 上也有人在问 coding agent 到底怎么读文档。AGENTS.md 里写"每周三发布"，我们以为自己是写给人看的——但读它的可能是个 agent。它知道周三零点还是下午三点是发布日期吗？这些坑不会因为 agent 变聪明就消失，只会从我们手上传染过去。
MidTool 那篇讲 mid-training 增强工具调用的论文，方向没问题，但再多的数据合成也写不进"今天几号"。时间从来不是模型能力问题，是系统设计问题。模型负责把话说漂亮，日历、时区、星期起点，得我们替它兜住。