s07_task_system.py，本质上是在前面几个章节基础上，第一次把“Agent 的工作”从一次性对话升级成了持久化任务系统（Task System）。
前面的演进：
-
s01：循环
-
s02：工具
-
s03：Todo
-
s04：Subagent
-
s05：Skill
-
s06：Context Compact
这些都还是“当前会话内”的能力。
而 s07 开始：
Agent 不再只是“聊天时临时做事”，而是开始维护一个长期存在的任务板（Task Board）。
官方文档对它的定位是：
“A file-based task graph with ordering, parallelism, and dependencies”
—— 基于文件的任务图，支持顺序、并行、依赖关系。 (learn.shareai.run)
一、这一章到底解决什么问题
先看一个真实问题。
假设用户说：
做一个博客系统：
1. 后端 API
2. 数据库设计
3. 登录系统
4. 前端页面
5. Docker 部署
如果没有 Task System：
-
agent 只能靠 messages 记忆
-
容易忘
-
中途打断就丢
-
无法恢复
-
无法依赖管理
-
无法多 agent 协作
所以 s07 引入：
Task = 外部持久化状态
核心思想：
把 Agent 的“脑内计划”
变成“磁盘上的任务图”
这是 AI Agent 从 Demo 到工程化的关键一步。
二、s07 的核心架构（最重要）
这一章只有一个真正核心：
任务文件 = Agent 的长期记忆
整体结构：
User Request
↓
Agent
↓
TaskManager
↓
tasks.json
任务被写入磁盘：
[ { "id": "task-1", "title": "Build API", "status": "todo", "deps": []
}
]
于是：
-
关闭程序后还能恢复
-
多 agent 能共享
-
可以追踪状态
-
可以做依赖调度
这就是后面：
-
s08 Background Tasks
-
s09 Agent Teams
-
s11 Autonomous Agents
的基础。
三、你应该重点理解的 5 个概念
1. Task 数据结构
通常类似：
@dataclass
class Task:
id: str
title: str
status: str
deps: list[str]
它本质就是：
任务节点（Node）
注意：
deps
这是整个章节最重要字段。
它代表：
当前任务依赖谁
例如：
Task C depends on A/B
图结构：
A ──┐
├──> C
B ──┘
这已经不是 Todo List。
而是：
DAG（有向无环图）
这是工作流系统的基础。
2. 任务状态（status）
通常：
todo
doing
done
或者：
pending
running
completed
failed
Claude Code 真正内部也是类似状态机： (Claude Wiki)
pending -> running -> completed/failed/killed
为什么一定需要状态？
因为 Agent 需要：
-
知道哪些能执行
-
哪些执行完
-
哪些失败
-
哪些阻塞
这就是：
Workflow Runtime
的雏形。
3. 文件持久化（Persistence）
这是 s07 最大升级。
前面所有章节：
状态都在内存
s07：
json.dump(tasks, f)
或者：
json.load(f)
开始：
状态外部化
意义巨大。
因为：
LLM 上下文 ≠ 系统真实状态
真正生产级 Agent：
-
必须把状态存磁盘
-
或数据库
-
或 Redis
-
或任务队列
否则：
context 一炸
系统就失忆
4. Task CRUD
这是经典后端思想。
四件事：
操作
含义
Create
创建任务
Read
查询任务
Update
更新状态
Delete
删除任务
所以你会看到类似：
create_task()
list_tasks()
update_task()
本质：
AI Agent 开始拥有“后端”
5. 调度（Scheduling）
最关键逻辑：
if all(dep.done for dep in task.deps):
runnable.append(task)
这是：
依赖解析器
含义：
只有依赖完成
当前任务才能执行
例如：
1. 先建数据库
2. 再写 API
3. 再写前端
不能乱序。
这就是：
工作流引擎
的最小实现。
四、这一章最关键的“认知升级”
这里是整个 learn-claude-code 非常重要的一次跃迁。
前面：
Agent = 会聊天的循环
s07 后：
Agent = 状态机 + 工作流系统
区别巨大。
五、代码里几个最值得学习的地方
1. 为什么用 JSON 文件
因为：
最低成本的持久化
它有几个优点：
-
人类可读
-
调试容易
-
无数据库
-
跨平台
-
能直接 git diff
这是 AI Agent 原型里非常常见的方案。
很多 Claude Code 类项目：
memory/
tasks/
sessions/
其实都是 JSON 文件。
2. 为什么任务必须有 ID
例如：
id = str(uuid.uuid4())
因为：
title 不可靠
可能有：
"build api"
"build api"
但 ID 唯一。
后面：
-
mailbox
-
multi-agent
-
worktree
全部靠 ID 串联。
3. 为什么依赖关系比 Todo 更高级
Todo：
线性列表
Task Graph：
图结构
这是从：
个人待办
升级成：
工程 orchestration
比如：
Backend Team
Frontend Team
DevOps Team
之间的协调。
六、这一章和后续章节的关系（非常重要）
s07 是整个“并发 Agent 系统”的地基
后续章节全依赖它。
s08 Background Tasks
会变成：
Task 异步执行
任务不再阻塞主循环。
s09 Agent Teams
会变成：
多个 Agent 共同处理 Task Board
s10 Team Protocols
会增加：
任务审批
任务交接
状态同步
s11 Autonomous Agents
会变成：
Agent 自动认领任务
即：
while True:
claim_unassigned_task()
七、你应该重点学习的代码片段（按重要度）
第一优先级
任务依赖：
deps
这是整个系统灵魂。
第二优先级
任务状态流转：
todo -> doing -> done
这是 Workflow Engine 基础。
第三优先级
JSON 持久化：
save_tasks()
load_tasks()
这是生产级 Agent 的必要条件。
第四优先级
可运行任务筛选：
runnable_tasks()
这是调度器。
八、这一章本质上在模仿什么系统
它其实在模仿：
1. Jira
任务管理
状态
依赖
负责人
2. Airflow
DAG 调度
3. Temporal / Prefect
Workflow Runtime
4. Claude Code 内部 Task Runtime
官方资料里明确提到： (Claude Wiki)
Task System = coordination backbone
即：
协调主干
九、为什么这一章特别重要
因为：
真正复杂 AI 系统
一定是“任务驱动”
而不是“对话驱动”
这句话非常关键。
ChatBot：
message-driven
Production Agent：
task-driven
区别：
Chat
Agent
临时上下文
长期状态
单轮响应
生命周期
线性对话
DAG 工作流
用户驱动
调度驱动
s07 就是这个分水岭。
十、一句话总结 s07
s07 做的事情可以浓缩成一句话：
把 Agent 的计划，
从“脑中的 Todo”
升级成“磁盘上的任务图”
这是 AI Agent 工程化真正开始的地方。 (learn.shareai.run)
