顺序即架构#

1
User -> Model -> Tool Call -> Task Service -> Repository -> SQLite
2
                    ^              |
3
                    +-- Tool Result+

M1 先做了任务领域模型（Task/TaskStatus/TaskDraft）、SQLite Repository、CLI 和自动化测试——全程没模型什么事。M2 才接 DeepSeek 做自然语言解析（interpret 只出草稿不写库），M3 手写 Tool Calling 让模型调 create_task。

1
uv run task-agent --db .data/tasks.db create "实现登录页" --priority high
2
uv run task-agent interpret "高优先级实现 Flutter OAuth 登录页"  # 只解析
3
uv run task-agent agent "创建一个高优先级的登录任务"              # 走 Tool 写库

为什么模型不能直写库#

LLM 幻觉写错一行 SQL 就是脏数据。中间隔一层 TaskService：参数校验、业务约束、幂等，全部用确定性代码写死。Tool Schema 就是权限边界，模型能调什么、传什么，全在 schema 里定死。

客户端老熟人#

ports.py 定义端口（接口），sqlite_task_repository.py 实现——六边形架构的 Python 版。uv 管包、ruff + mypy 守质量，M0 先把工具链钉死再写业务。

确定性优先：模型负责理解，代码负责正确。下一篇手写 Agent Loop。