最后更新：2026 年 3 月 · 源码：agent-time-awareness
智能调度与截止日期监控
时间上下文服务（TCS）— 一个轻量级 Python 服务，为 LLM 智能体提供准确的时间感知能力、带超时检测的后台任务追踪，以及在上下文压缩后仍能持久保存的事件日志。
是什么
TCS 解决了 LLM 智能体在时间方面的三个关联问题：
1. 时间上下文注入
为系统提示词生成现成的时间上下文块：当前时间戳、星期几、相对时区信息以及联系人免打扰时段。每次会话开始时包含该上下文的智能体能够精确感知当前时间。
2. 任务生命周期追踪器
注册后台任务，按可配置间隔轮询，检测超时，并标记完成。防止智能体重复启动任务或忘记跟进异步操作。
3. 持久化事件日志
基于 SQLite 的智能体事件时间线。由于它存储在 LLM 上下文窗口之外，可以在上下文压缩后继续存活。即使上下文已被截断，智能体仍可查询"过去 2 小时发生了什么"。
为什么
LLM 没有实时时钟。它们的知识截止到训练截止日期，而不是当前时刻。没有显式的时间注入，智能体无法正确回答"今天是几号？"，也无法推理截止日期和调度。这在会话开始时很容易修复——但需要专用服务来可靠地实现。
后台任务追踪更为复杂。启动了长时间运行进程（构建、测试、数据管道）的智能体需要回头检查进度。如果没有外部状态，智能体要么每轮都轮询——造成噪音——要么在上下文压缩后完全忘记。TCS 将任务状态保存在上下文窗口之外的 SQLite 中，因此它可以在会话重置后持续存在。
事件日志解决了历史记录的同一问题：上下文压缩会静默地删除早期事件。上下文窗口之外的 SQLite 事件日志提供了一个持久的时间线，任何会话都可以查询，无论上下文被截断了多少次。
架构
TCS 作为 MCP 服务器运行，通过 Model Context Protocol 将全部三个层次作为工具暴露给智能体原生调用。
| 工具 | 说明 |
|---|---|
| get_temporal_context | 当前时间上下文（文本或 JSON），用于注入系统提示词 |
| start_task | 注册一个后台任务以供追踪 |
| poll_task | 根据配置的间隔检查现在是否应该轮询任务 |
| finish_task | 将任务标记为已完成或已取消 |
| list_tasks | 列出任务，可按状态过滤 |
| check_timeouts | 扫描所有运行中的任务是否超时 |
| log_event | 向持久化时间线追加事件 |
| query_timeline | 按时间范围或类型查询事件 |
| search_events | 对事件摘要进行全文搜索 |
| get_stats | 活动统计信息 |
SQLite 数据库存储在智能体工作区之外——该路径在会话重启和上下文压缩后均能存活。WAL 模式允许并发读取与服务器写入同时进行。任务状态和事件日志共享同一个数据库，但使用独立的表。
关键设计决策
外部进程，而非上下文内状态
TCS 作为独立服务运行。状态存储在 SQLite 中，而不是智能体上下文中。这是根本性的设计选择：上下文压缩无法删除任务状态或事件历史，因为它们完全存储在上下文窗口之外。
智能轮询——"现在应该轮询吗？"而非原始时间戳
poll_task 工具返回一个布尔值：智能体现在应该检查这个任务吗？这将间隔逻辑从智能体中抽象出来。智能体不需要自己追踪上次轮询的时间戳；TCS 会处理这些。
MCP 作为接口
通过 MCP 暴露 TCS 意味着任何兼容 MCP 的智能体都可以无需自定义集成地使用它。智能体将 TCS 工具与工具箱中的任何其他工具一样对待。这也使得在不更改智能体配置的情况下添加新工具变得容易。
时间上下文在会话开始时注入一次，而非每条消息都注入
时间上下文块属于系统提示词，而不是在每条用户消息中重复。在会话开始时调用一次 get_temporal_context 并将结果包含在系统提示词中就足够了——时间戳对于调度目的来说已经足够准确。
如何自行构建
1. 将时间状态放在上下文窗口之外
核心洞察：任何需要在上下文压缩后存活的状态都必须存储在外部存储中。SQLite 是个好选择——轻量级、基于文件、无需服务器。WAL 模式允许并发读取而不阻塞写入。
2. 在每次会话开始的系统提示词中注入时间上下文块
在会话开始时生成结构化块：当前 ISO 时间戳、星期几、本地时区偏移以及任何相关的联系人免打扰时段。格式化为人类可读的散文，而不是原始 JSON——智能体对时间的推理会更可靠。
3. 将 poll_task 设计为门控，而非数据源
智能体应该在每次可能涉及被追踪任务的轮次调用 poll_task，但工具应该返回"是的，现在检查"或"还不到时候"——而不是任务状态本身。这可以防止智能体过于频繁地轮询外部系统。
4. 事件日志模式：时间戳 + 类型 + 摘要 + 可选元数据
保持事件日志模式简洁。摘要字段应该是可被 FTS 搜索的简短人类可读字符串。将结构化元数据单独存储。永远不要删除事件——归档或标记它们。查询"发生了什么"的智能体需要完整的历史。
5. 每个任务单独设置超时，而非全局超时
不同任务有不同的预期持续时间。在注册时为每个任务存储超时值。check_timeouts 工具扫描所有运行中的任务，并标记那些超出各自超时时间的任务——而不是单一的全局限制。
常见问题
为什么 LLM 智能体需要单独的时间服务？
LLM 没有实时时钟，在上下文窗口之间也没有持久记忆。TCS 解决了这两个问题：它按需提供当前时间戳，其 SQLite 事件日志记录了即使上下文被压缩或会话重启后发生的事情。
什么是任务的"智能轮询"？
poll_task 工具根据配置的间隔返回自上次轮询以来是否已经过了足够的时间。这可以防止智能体在只需要每 30 秒检查一次时，每条消息轮次都去轮询后台任务。
事件日志在 OpenClaw 会话重启后是否仍然存在？
是的。事件存储在会话状态之外的 SQLite 文件中。只要该文件存在，任何会话都可以查询历史事件。
Authors: Qiushi Wu & Orange 🍊