Task-Driven vs Goal-Driven
Task-Driven 解决执行问题，Goal-Driven 解决迭代问题。
What it is
腾讯程序员在构建「24h 打工人」Agent 系统过程中提炼的两阶段框架：
| 维度 | Task-Driven | Goal-Driven |
|---|---|---|
| 人的角色 | 项目经理 + 执行监督 | 目标设定者 / 审核者 |
| Agent 的角色 | 执行器 | 自主推进者 |
| 决策中心 | 在人脑子里 | 在目标 + 边界 + 系统状态里 |
| 主要成本 | 人持续编排 | 前期建模和约束设计 |
| 适用场景 | 简单、一次性任务 | 长期、复杂、持续推进任务 |
Why it matters
Task-Driven 的隐性边界：24h 在线不等于 24h 迭代。系统能执行，但「现在最值得做什么」「遇到阻塞该换路径还是等待」等判断仍依赖人。
真正的瓶颈不是人的能力不够，而是人的注意力有限。4-6 个终端是上限，因为人脑的并发模型就长这样。
Evidence across sources
| Source | Key Claim | Relevance |
|---|---|---|
| 腾讯程序员 — 十年老技术开发的 AI Agent 探索之路 | 24h 打工人从 4 个终端手忙脚乱 → 20-30 个并发任务的稳定执行，靠的是调度层 + SDD + 失败切换，而非更强的模型 | Scaling evidence |
| 腾讯程序员 — 十年老技术开发的 AI Agent 探索之路 | Agent 自己修自己的 bug：用户只提交反馈和确认澄清，系统自动完成分析→方案→执行→验证 | Goal-Driven evidence |
Goal-Driven 的 5 个前提
- 目标必须清晰 —— 可推进、可判断
- 边界必须清晰 —— 哪些能做、资源上限
- 状态必须可见 —— 当前做到哪一步、卡在哪
- 过程必须留痕 —— 否则无法知道为什么成功/失败
- 权限必须可控 —— 能调用哪些工具、写到哪、谁来兜底
Goal-Driven 不是更放权，而是更强约束下的有限自治。
6 步落地路径
| 步骤 | 做什么 | 核心产出 |
|---|---|---|
| 第一步 | 写清楚 spec | 要做什么、不做什么、怎么算完成 |
| 第二步 | 执行过程留痕 | Prompt、状态、输出、错误全记录 |
| 第三步 | 补 observability 和 eval | 知道为什么成功、为什么失败 |
| 第四步 | 高频动作沉淀为 Skill | 模板 + 规则 + 代码 |
| 第五步 | 引入调度和并发 | 调度层 + 轮询 + 失败切换 |
| 第六步 | 最后才尝试 Goal-Driven | 目标表达 + 治理边界 + 共享状态 |
先让一次执行可复盘，再让它可重复，再让它可规模化，最后让它可有限自主。
Open questions
- At what concurrency level does human oversight become the bottleneck regardless of harness quality?
- Which types of tasks are inherently resistant to Goal-Driven delegation due to ambiguity in completion criteria?
- Does the six-step ladder imply that most teams are currently stuck at step 2 or 3?
Related
- Purpose vs Task — 黄仁勋框架：AI 消灭任务，放大目的
- Harness Engineering — 让系统不再依赖人的实时在场
- Vibe Coding 的真实代价