AITM 在本地保存了相当多的状态,以便可靠运行并记住它对项目所了解的内容。以下是用通俗语言绘制的存储内容地图,以及这些内容为何对您重要。

AITM 存储哪些数据

数据地图

是什么位于何处为何重要
项目级数据库每个受管项目各有一个专用的数据库文件保存该项目的 Contracts 和 Task 历史—按项目分开存放,因此一个项目的数据绝不会与另一个项目的混在一起
全局数据库供 AITM 自身使用的一个共享数据库保存应用范围的设置、提示、变量注册表以及其他跨项目配置
Task 执行日志按项目划分的日志文件夹逐行记录 Task 运行期间所发生情况的详细记录—有助于调试行为异常的 Task
Task 数据文件夹按项目划分的 Task 文件夹,每个 Task 编号对应一个子文件夹包含该 Task 的结果文件、元数据以及为其捕获的所有截图—结果与 Archive 视图即由此驱动
Worktrees临时的 Git 检出副本,每个运行中的 Task 一个Task 的 AI Agent 实际编辑的隔离工作副本;在 Task 启动时创建,合并后自动删除—参见 Pipeline
知识图谱文档自动生成的文档文件Knowledge Sharing 中所述 Contracts 和依赖知识的人类可读导出文件;每次合并后自动重新生成

为何本地持久化状态很重要

这一切都不是可有可无的簿记工作—它们是本指南其他部分所述一切功能背后的机制:

  • 项目级数据库使 Contracts、Task 历史和先例查询得以在会话之间、Task 之间持续存在,而不是在每次关闭应用时重置。
  • Task 数据文件夹使 Archive 成为真正有用的审计轨迹,而不仅是一串标题—在那里看到的每个结果、截图和元数据字段,都是直接从这些文件夹读取的。
  • Worktrees 是 Pipeline 中所述隔离保证的机制基础—由于每个 Task 都获得真正独立的文件系统检出副本,进行中的工作绝不可能意外泄漏到主分支。
  • 知识图谱文档把“AI 碰巧记住了某些东西”变成了“项目拥有关于自身行为的持久、可检查的记录”—参见 Knowledge Sharing。

如何防止数据库备份无限增长和静默丢失数据

数据库备份本身也需要保护—否则它们可能要么占满磁盘,要么在最需要时悄然消失。AITM 采用分层保留策略来保管备份,并监控其大小是否异常:

  • 分层保留 — 与“一刀切地一次性删除所有超过 N 天的数据库备份”(若漏掉了某一天的运行,就可能一次性清除全部数据库备份)不同,AITM 会逐步稀疏化备份:保留少量最近的每日备份、若干间隔数天的较早备份,以及一个更早的每周备份。结果是得到一组数量不多但分布均匀的恢复点,同时不会让备份存储无限增长。
  • 大小异常告警 — 在进行任何清理之前,AITM 会将今天的数据库备份大小与昨天的进行比较。显著缩小(可能发生了数据丢失)或意外显著增大都会触发电子邮件告警,其中包含之前的大小、当前大小和变化百分比,使您能在较早的健康备份被覆盖或清理之前就得知异常。
  • 增量(delta)备份的验证式清理 — 超过 3 天的增量恢复备份会被持续清理,但前提是该链中仍保留的最新备份已被验证为完好无损。如果验证失败,则该数据库的清理会停止,更早的备份不会被删除—因此一个损坏的最新备份绝不会连锁导致删除其下仍然完好的较早备份。

提示

  • 项目代码绝不会在 Worktree 之外被修改—Task 运行期间,您的常规工作副本保持不动。
  • 除了对所配置 AI 提供商的调用之外,没有任何内容会被发送出本机。
  • 这种本地持久化的知识使 AITM 能随着时间推移越来越熟悉您的项目,而不是每个 Task 都从零开始。