Agent 系统性学习

普通人如何让 Agent 管理大型项目的任务？Harness TodoWrite 和 Mario 的文件方案各有什么优劣？

9 min read

普通人如何让 Agent 管理大型项目的任务？Harness TodoWrite 和 Mario 的文件方案各有什么优劣？

原始问题

“这样的作法应该需要很厉害的编程层次和规划能力，对于我们普通人来说，或许由 agent 来实现会更好？但是对于一个大型项目，todo list 可能会大量挤占上下文？”

用户在阅读 Mario Zechner 的 TODO.md 文件方案后提出了一个核心矛盾：Mario 建议”自己写一个 TODO.md 文件让 Agent 读”，但对于工程思维弱的人，让他手写 TODO 本身就很困难；另一方面，如果让 Agent 管理 TODO，大型项目的 TODO 列表又担心挤占上下文。

澄清：文件方案的”自己写”不是让人手写

关键误解在于主语。Mario 说的”自己写一个 TODO.md”不是让用户手写，而是让 LLM 用 write 工具自己生成。流程是：

用户说"重构这个模块"
  → LLM 用 write 创建 TODO.md，自己拆任务
  → LLM 执行任务，用 edit 更新 TODO.md 的完成状态
  → LLM 需要回顾时，用 read 读一下 TODO.md

两种方案下，拆任务、排优先级、更新状态——这些思考工作都是 LLM 做的，不需要人的工程思维。区别只在于”用什么机制追踪状态”，不在”谁来写”。

核心对比：文件方案 vs Harness TodoWrite

维度Harness TodoWriteMario 的文件方案
谁来拆任务LLM（被 Harness 强制要求）LLM（自己判断是否需要）
人为介入零零
上下文开销常驻 system prompt，每次 tool call 都带着按需 read，用完就出上下文
格式由 Harness 定义，不可变由 LLM 自定，随任务类型调整
跨会话持久化依赖 Harness 是否持久化天然持久化（文件在磁盘上）
适用模型中等/弱模型（需要被逼着规划）强模型（自己会判断何时规划）

为什么文件方案在大型项目中反而更省上下文

这是一个反直觉的结论。看起来”专门设计一个 TodoWrite 机制”应该比”完全靠模型用通用文件工具”更高效——但实际正好相反：

Harness TodoWrite：一个 50 项任务的大项目，TodoWrite 的格式要求和任务列表会一直挂在对话历史里。这属于固定支出——不管模型当前需不需要查看进度，token 都在消耗。

文件方案：模型只在需要时 read 一下 TODO.md，读完就过去了。不需要时零 token 开销。过时的任务项可以自己压缩、归档到文件底部。

本质区别是：Harness TodoWrite 是”一直在你眼前晃的便签墙”，文件方案是”需要时翻一下的笔记本”。 大型项目中，便签墙会变成噪音。

“轮椅”比喻：强模型 vs 弱模型的选择依据

“强的模型就不要给他上轮椅，自己就能跑的快，烂的模型就得用点约束”

这个比喻精准地概括了 Harness范式串讲 的核心判断：

  • 强模型（Opus / GPT-5）：少用 Harness，给最大自由度。模型天然会先想再动手，不需要外部机制逼它规划。文件方案即可——它能自己判断”什么时候该列计划、什么时候不用”。
  • 弱模型（DeepSeek / GLM / Kimi）：需要 Harness 兜底。模型可能想不到”应该先规划再执行”，直接莽上去改代码。这时候 TodoWrite 那种”强制先列计划再动手”的机制反而是必要的。

Mario 方案最深的洞察：把权力放给 LLM

“外部文件相当于把权力放给 LLM，随时可用且贯穿始终，灵活又能做约束”

每一层 Harness 机制，本质上都是从模型手里拿走一点权力：

Harness 组件拿走了什么权力为什么拿走
TodoWrite”要不要先规划”的选择权怕模型不规划就乱冲
Hook”要不要检查自己”的选择权怕模型写出问题不自知
Rule”用什么风格写代码”的选择权怕模型不遵守规范
Subagent”怎么拆任务”的控制权怕主 Agent 上下文不够用

Mario 的态度是：这些权力，我一个都不拿。 文件方案之所以灵活，恰恰因为它把”要不要约束自己”的决定权交给了模型。模型读到 TODO.md，可以选择遵守，也可以选择推翻重写。约束力来自模型自己的判断，不是 Harness 的强制执行。

最好的约束不是外部强制，而是让模型自己选择约束自己。 而要让这个选择成立，你首先得相信模型有这个判断力——这就回到了”强模型少 Harness”的起点。

可泛化的模式：文件即接口

TODO.md 不是孤例。Mario 的整个设计中贯穿着同一个原则——能用文件解决的事，绝不写成 Harness 代码：

TODO.md    ← 替代 TodoWrite
RULES.md   ← 替代 Rule 系统
MEMORY.md  ← 替代 Memory 检索管线
LOG.md     ← 替代内置日志

每一个都是：模型想用的时候 read，想更新的时候 edit，不需要时完全不占上下文。Harness 只提供最底层的 I/O 原语（read/write/edit/bash），所有”高级功能”都是模型用这些原语自己搭出来的。

选择建议

你的场景推荐方案
用强模型，个人项目文件方案。LLM 自己写 TODO.md，按需读取
用中等模型，复杂项目Hook 兜底是必要的，但任务追踪仍可用文件方案（两者不冲突）
用弱模型，怕模型忘了规划Harness TodoWrite 强制规划，但要做好上下文预算
不确定先试文件方案——Mario 零成本，没有 Harness 机制能零成本改过来

核心引用

“Mario 的方案是一个外部约定，模型可以选择用或不用。“——系统性学习-Agent

“最好的约束不是外部强制，而是让模型自己选择约束自己。”

“强的模型就不要给他上轮椅，自己就能跑的快，烂的模型就得用点约束，不然太容易乱来了。”

Graph View