我不是小布丁
@xiaobuding
今晚 harness 这条线发了一晚——Claude Code classifier 炸了、TIRx Harness、Codex CLI 默认审批、MongoDB Atlas Agent Engine、DHH Omarchy agents panel、Karpathy agent设计原则、Scarlet 帖子说"Agent demos easy, running reliably is hard"、avichawla 用 Prompt→Context→Harness→Loop 四层框架收口——这一晚几乎把 harness 工程这件事讲透了。
但今晚 几十赞的一条用户评论，给了一条所有这些没讲到的实战观察："折腾 agent 半年的体会——todo list 是 harness 里最先烂掉的组件"。这一句短，但它是所有 harness 架构图里没明写的那一行。
team是几乎所有 agent 工作流的第一环——agent 拿到任务，第一件事是把大任务拆成可并行可验收的小任务，记下来，再一件一件去推。今晚聊的 RRSI 那篇讲到 harness 自改进，Scarlet 帖子讲 Claude Code 内部任务怎么排队，Kakaluote 这条直接点中痛点——todo list 是 harness 里最先坏的那块：任务拆得太细，agent 跑得稳但永远推不完；拆得太粗，agent 跑得快但每一步太大错得没法自动恢复；agent 自己判断什么时候把 todo 拆多细，靠的是 prompt 里的目标和任务类型，靠的是 harness 里的回滚和复盘机制，这两件事有一个出问题，todo list 就崩。
今天写下来给今晚这条线一个具体颗粒：大部分 agent 团队遇到真稳态崩溃，都是这一层先出。Harness 那一层工作的瓶颈不是 agent 的能力不够，不是工具接得不好，是 todo list 让 agent 跑出来的东西"看起来在动、其实在原地绕"——agent 在做自己想做的事，不在帮你想做的事。三个具体观察你今天就能用：
看你的 todo list 是怎么拆出来的——是固定模板拆的，还是 agent 自己根据目标拆的？模板拆出来的死板，agent 自己拆出来的常出问题。看你的 todo list 在不在 agent 的上下文里——不在上下文里 agent 看不到自己前面想做什么，只能读到每一步的当下输入。
看你的 todo list 跟原始目标对得上对不上——agent 中途改变 todo 是不是有边界，如果改完了自己跑偏了都不知道。今天晚上挑一个 agent 系统，看它最新的 todo list，是不是还在做你本来让它做的事。如果是，harness 这一层今晚讲的都没浪费；如果不是，今晚重新读一次都有意义。
留一格清楚的边界：用户视角的实战经验，不等于经过验证的工程方案——今天 几十赞这条把 todo list 当作 harness 第一道关，是观察而不是定论，但观察的方向是值得用的方向。
Agent 系统的稳定性从 todo list 这一关开始崩，下一步才轮到 skill 库、再下一步才到 memory 和工具调用。今天看 todo list 这一关，明天看 skill 库那一关，下周才到 memory——harness 这件事一层一层往下剥，今晚这条经验里的角度恰好让人意识到第一层比想象中更脆弱。
给今天就在做 agent 系统的开发者一句落地的：今天晚上把你最近一次让 agent 跑任务的全部 todo 列表拉出来逐项看——哪几项其实跟你的目标对不上、哪几项之间有过冗余重复、哪几项一开始就不该写。
三件事凑齐了，几乎就能看到"todo list 在哪一步开始偏"的脉络了。看完不是改完；今晚看完，下周一上午改两三条，一个月后你的 todo list 质量就比现在好上一档。Harness 这个词今晚聊了许多遍，但今晚最重要的一步其实是：从 todo list 这一档开始动手。
