Day 15 / 共 20 天 · 第 3 周 工具/记忆/资源（收官）

数据模型

第3周收官。系统地看 models/ 的 35 个 DB 模型的关键几个——数据模型就是整个系统的骨架。前面学的一切都落在这些表上。

📍 你在整门课的位置（第 3 周收官）
第1周 核心概念→ 第2周 Agent执行→ D11-12 工具→ D13-14 记忆/资源→ D15 数据模型（骨架）→ 第4周 平台/异步/生态
L01

DBBaseModel 公共基类

🤔 前面 14 天都在讲代码逻辑，为什么收官要回头看数据库表？ 因为你会发现：Agent、Execution、Feed、Workflow、Tool、Resource……这些一路遇到的概念，最终都落在一张张 DB 表里。逻辑是"临时运行的"，表才是"持久存在的骨架"。看懂这些表之间的关系，前 14 天的知识就被串成一张完整的图。
💡 一句话本质 SuperAGI 的"状态"几乎全在数据库里——所以整个系统 = 一组 SQLAlchemy 模型（表）+ 在这些表上读写的逻辑。所有模型都继承 DBBaseModel（models/base_model.py:10）拿到统一的时间戳和序列化；再按"三层租户 → Agent → Execution/Feed → Workflow → Tool → Resource"组织。读懂表，就读懂了系统骨架。

数据库就像公司的"档案室"：一柜一类档案（一表一类实体），每份档案都盖着统一格式的日期章（created_at/updated_at 来自 DBBaseModel）。公司哪天全员下班（进程重启），档案室还在——第二天照着档案就能把所有事务接着办。今天全天沿用这个"公司档案室"世界观。
⚠️ 小白常误以为 "智能体的记忆和进度在程序内存里，重启就没了"。其实 SuperAGI 恰恰相反：进度在 AgentExecution 表、对话在 Feed 表、配置在 AgentConfiguration 表——进程重启丢的只是"正在算的那一下"，状态全在档案室（DB）里，随时可续。

所有模型继承 DBBaseModel（models/base_model.py:10），统一提供时间戳和序列化：

class DBBaseModel(Base):
    __abstract__ = True                             # 本身不建表，只被继承
    created_at = Column(DateTime, default=datetime.utcnow)
    updated_at = Column(DateTime, ..., onupdate=datetime.utcnow)
    def to_dict(self): return {c.name: getattr(self, c.name) for c in self.__table__.columns}
读法：__abstract__=True 表示它不建表、只被继承。所有子表自动有 created_at/updated_at 和 to_dict/to_json（DRY）。SQLAlchemy ORM——每个模型类映射一张数据库表。
L02

三层租户（Day 02 复习）

层级模型关键字段
顶层Organisation（organisation.py:7）id/name/description
中层Project（project.py:5）organisation_id
底层Agent（agent.py:20）project_id + agent_workflow_id
Organisation → Project → Agent 三层，用外键（organisation_id/project_id）串起。多租户隔离的基础：查询时用这些外键框住范围，保证 A 组织看不到 B 组织的数据（Day 02）。
整个系统的骨架：核心表怎么用外键串起来（收官全景） Organisation Project Agent 三层租户 AgentConfigurationkey-value 配置袋 AgentWorkflow+ WorkflowStep(图) Resource文件登记(Day14) AgentExecution一次运行的状态机 ExecutionFeed每步消息流水 Toolkit → Tool存"代码定位"(Day12)
前 14 天的概念全落在这些表上：租户三层 → Agent（+配置/工作流/资源）→ 一次 Execution → Feed 流水。
🎵 记忆口诀（把骨架背下来） 「组织建项目，项目养 Agent；配置袋里装，流程图上走；一跑一 Execution，一步一条 Feed；工具存地址，文件登个记。」
对应：Organisation→Project→Agent 三层 / AgentConfiguration / AgentWorkflow(Step) / AgentExecution / AgentExecutionFeed / Tool(folder+file+class) / Resource。背下这七句，35 张表的主干就在手里了。
生活类比（档案室世界观）：这三层就像公司→部门→员工——查一个员工的档案，先进公司柜、再翻部门夹；外键就是档案上的"所属部门"栏，保证 A 公司的档案员翻不到 B 公司的柜子。
L03

Agent + AgentConfiguration

回忆 Day 02：Agent 表极简（身份+归属+绑工作流），配置拆到 AgentConfiguration（EAV key-value）。

📝 一个 Agent 的配置长这样（多行 key-value） 
# Agent 表：只有身份
Agent(id=7, name="调研助手", project_id=3, agent_workflow_id=1)
# AgentConfiguration 表：每个配置一行（EAV）
(agent_id=7, key="goal",             value="调研竞品定价")
(agent_id=7, key="instruction",      value="用中文，列表输出")
(agent_id=7, key="model",            value="gpt-4")
(agent_id=7, key="tools",            value="[3, 8, 12]")
(agent_id=7, key="resource_summary", value="竞品分析.pdf")   # Day14 写进来的
想加一个新配置项（比如 max_tokens）？只需多插一行，不用改表结构——这就是"稳定身份 + 灵活配置袋"的好处。
为什么这个拆分值得再强调 Agent 表 = 稳定的"身份证"；AgentConfiguration = 灵活的"配置袋"（目标、指令、工具、模型…每个一行）。加新配置项无需改表结构。这是"稳定实体 + 灵活属性"的经典建模——身份少变、配置多变，分开存。Day 14 的 resource_summary 也是存在 AgentConfiguration 里。
L04

AgentExecution + Feed

（Day 02 学过）AgentExecution = 一次运行的状态机（status、num_of_calls、num_of_tokens、current_agent_step_id）；AgentExecutionFeed = 运行过程的消息流水（feed、role、feed_group_id）。

读法：Execution 记"这次运行到哪了、用了多少"，Feed 记"每一步说了什么做了什么"。Feed 是短期记忆（Day 08 读回拼上下文）+ GUI 展示源 + 执行审计。fetch_agent_execution_feeds 按 feed_group_id 取本轮对话重建 LLM 上下文；get_last_tool_response 取最近某工具输出。
📝 一次运行在这两张表里的样子 AgentExecution(id=42, agent_id=7, status="RUNNING", current_agent_step_id=2, num_of_calls=5) —— 记"进行到第 2 步、已调 5 次 LLM"；
Feed 表则一行行记：(role="user", feed="目标是…")、(role="assistant", feed="{tool: search, args:…}")、(role="system", feed="工具返回：…")……
Celery worker 挂了重启后，靠读 Execution 的 current_agent_step_id 就知道"该从第几步接着跑"——这就是"循环存在 DB 里、可断可恢复"（Day 02）。
这两张表是"循环在 DB 里"（Day 02）的物理载体：进度在 Execution.current_agent_step_id、对话在 Feed。Celery worker 每步读写它们，实现可断可恢复的自主循环。
L05

工作流模型（Day 07 复习）

  • AgentWorkflow（workflows/agent_workflow.py:9）：一个工作流（id/name/description）。Agent 绑定它。
  • AgentWorkflowStep（agent_workflow_step.py:13）：节点——step_type、action_type、action_reference_id、next_steps（JSONB，带条件的边）。
  • IterationWorkflow/IterationWorkflowStep：内层迭代子工作流（Day 06 的两级 step）。
工作流建模成图的意义（再强调） 智能体"按什么流程干活"是数据（这些表里的图）而非硬编码。于是能有多套预置工作流、能在市场分享、能可视化编辑。next_steps 的 JSONB 存"结果 X → 去 step Y"的条件边，让流程能分支/循环（Day 07）。"把流程建模成数据驱动的图"是 SuperAGI（和 CrewAI Flow、AutoGPT Graph）的共同选择。
L06

Tool + Toolkit（Day 12 复习）

  • Tool（tool.py:8）：单个工具，存"代码定位"（folder_name/file_name/class_name）+ toolkit_id——靠它反射加载（Day 12）。
  • Toolkit（toolkit.py:13）：一组工具，含 organisation_id、tool_code_link（GitHub 链接）——支持从市场安装。
Tool 表存"代码在哪"而非逻辑，是插件化的基础（Day 12 反射加载）。Toolkit 的 tool_code_link 指向 GitHub——工具市场从这里下载。这两张表让"工具即插件、可从市场安装"成立。
L07

记忆相关模型

  • Resource（resource.py:6，Day 14）：登记每个文件（storage_type/path/channel/agent_id/summary）。
  • Knowledges（knowledges.py:12）：外部知识库实体，通过 vector_db_index_id 关联向量索引，支持市场安装。
  • VectordbIndices（vector_db_indices.py:9）：一个向量库里的索引/集合（name/vector_db_id/dimensions）。配套 vector_dbs.py、vector_db_configs.py。
这三张表把记忆"关系化" Day 13 讲的向量库是"运行时的向量存储"。这几张 DB 表则是把"文件资源""知识库""底层向量索引"在关系型数据库里串起来管理——让智能体记忆既有向量检索（语义），又有元数据管理（这个知识库属于谁、用哪个向量索引、维度多少）。向量库负责"语义检索"，关系表负责"元数据/归属管理"，两者配合。
L08

🎓 第 3 周收官 + 动手

第 3 周（Day 11-15）你已吃透工具/记忆/资源

  • Day 11 工具体系深入：复合工具、token 管理、@tool
  • Day 12 工具市场：下载/登记/反射加载/依赖注入
  • Day 13 向量记忆：RAG、embedding、语义检索
  • Day 14 资源管理：双写、隔离、灌向量库、摘要
  • Day 15 数据模型：整个系统的骨架表

你已理解智能体的能力、记忆、数据是怎么组织的。下周（Day 16-20）进入 平台/异步/生态——API、Celery、GUI、部署、收官。

✋ 动手

P=superagi/models
sed -n '10,68p' base_model.py | head -30      # DBBaseModel
sed -n '11,40p' agent_execution.py            # Execution
sed -n '8,30p' agent_execution_feed.py        # Feed
sed -n '13,35p' workflows/agent_workflow_step.py  # 工作流 step
ls . | head -35                                # 35 个模型概览
下周预告 · Day 16：进入平台层——API controllers：FastAPI 28 个控制器、agent/execution/tool/project 主要端点、前端怎么驱动智能体创建和运行。
← Day 14 资源管理 Day 16 · API →