为什么是这条路线#

我是 Android + Flutter 出身，客户端经验是优势不是包袱。路线按“从小到大、从确定到不确定”排：

1
01 工程任务 Agent    Structured Output、Tool Calling、Loop、Streaming、State
2
02 知识库 Agent      Ingestion、Retrieval、RAG、Citation、Eval
3
03 工作流 Agent      Durable Execution、Retry、Idempotency、Human Approval
4
04 生产级 Agent 服务  Tracing、Evals、Guardrails、Cost、Deployment

每个项目从空目录开始，以可运行、可测试、可部署为完成标准——能跑的 milestone 才算数。

三条铁律（来自 AGENTS.md）#

1. 先写确定性业务能力，再让模型通过工具使用它：模型不直写库，只调 Tool
2. 先理解 Agent Loop，再引入封装框架：手写一遍循环，才知道 LangGraph 替你省了什么
3. Prompt、Tool Schema、Eval Case 和业务代码一样进版本管理：提示词是资产，不是字符串

客户端经验的迁移#

UI -> UseCase -> Repository -> DataSource 换成 User -> Model -> Tool -> Service -> Repository，分层思想完全通用。Flutter 的状态管理直觉，对话状态、会话持久化一看就懂。转型的本质是换一套不确定性部件，工程底座不变。

系列开篇。后面四篇分别讲 01 的确定性核心、手写 Loop、02 的 RAG、03 的工作流。