核心原理（三）：任务原子化为可独立执行的单元

公众号名称：James的成长日记

作者名称：Jameszyh

发布时间：2026-06-20 12:37

大家好，我是 James，今天是端午节第二天，端午安康🛶。

上一篇我们聊了流程结构化为阶段——把 AI 的工作拆分成 Discover、Define、Design、Develop、Deliver 五个阶段，每个阶段有具体产出物，阶段之间设「门」，确保人类在假设成本最低的时候介入对齐。

这一篇讲第三条核心原理：任务原子化。

如果说「决策外化为文件」是空间维度的解药，「流程结构化为阶段」是时间维度的解药，那么「任务原子化」是资源维度的解药——它让每个任务都能拿到 100% 干净的上下文资源。

一句话总结：任务原子化 = 给每个任务一块独立的「工作沙箱」。它把巨型功能切碎为可独立加载、独立执行、独立验收的最小单元，每个单元都在干净的上下文中运行，从根本上解决了「长任务执行到一半 AI 就糊涂了」的问题。

01 | 问题的本质：上下文是单一稀缺资源

LLM 的上下文窗口是一个全局共享的稀缺资源，存在三组本质矛盾。

矛盾 1：广度 vs 深度

要做一个完整功能，AI 需要：读懂需求（spec.md）、理解技术方案（plan.md）、知道任务清单（tasks.md）、加载相关代码文件（可能 10 个以上）、理解项目约定（constitution.md）——加起来可能 50K-80K tokens。这只是输入。

但执行任务时还需要推理（思考占 token）、生成代码（输出占 token）、处理错误回退（重试占 token）。上下文越广（信息全），剩余执行空间越窄（容易超限）。

矛盾 2：长任务 vs 注意力衰减

一个大任务执行到 30K token 时，AI 对最早 10K token 内的指令（可能很关键，比如「必须用 TypeScript」、「禁止使用 any」）的注意力权重已经显著下降。任务越长，违反早期约束的概率越高。

矛盾 3：并行 vs 串行

如果一个会话从头到尾做完所有任务（串行），中间任何一步出错都污染整个上下文。如果想并行做（多个会话同时进行），又如何保证它们对项目状态的认知一致？

这三个矛盾指向同一个结论：把大任务塞进一个会话，是 AI 编程质量下降的根本原因。

02 | 核心机制：原子化 + 隔离 + 并行

任务原子化的解决方案包含三个紧耦合的机制，缺一不可。

机制 1：原子化任务

一个原子任务必须满足三个条件：

可独立加载：所需上下文能在 30%-50% 的窗口内塞下
可独立执行：不依赖其他正在进行的任务的中间状态
可独立验收：完成标准明确，能 binary 判定 done/not-done

反例（非原子）：「实现用户认证模块」。这不是原子任务，因为上下文要加载整个用户系统（太大），需要决定 JWT 还是 Session（决策未冻结），验收标准模糊（「能登录」算不算？要不要含找回密码？）。

正例（原子）：「在 src/auth/jwt.service.ts 中实现 generateToken 函数，接收 userId: string，返回签名后的 JWT 字符串。使用项目已配置的 JWT_SECRET，过期时间 24h。完成标准：单元测试 jwt.service.test.ts 中的 4 个测试用例全部通过。」每一项都明确：输入、输出、依赖、验收。

机制 2：上下文隔离

每个原子任务在独立的上下文实例中执行。传统做法是一个会话从头到尾串行执行，上下文累积越来越乱。Harness 做法是每个任务独立上下文，从文件系统加载共享状态。

关键技术：Claude Code 的 Sub-Agent、Cursor 的 Background Agents、GSD 框架的 /clear + 重新加载、多会话/多 worktree。

机制 3：子代理并行

无依赖关系的原子任务并行执行。波次 1（无依赖，并行）实现基础模型文件，波次 2（依赖波次 1，并行）实现对应的服务层，波次 3 继续推进。这就是 GSD 框架的「波次执行」（Wave Execution）。

这本质上是在把 LLM 改造成一种「分布式计算系统」：主代理 = 调度器，子代理 = 工作节点，文件系统 = 共享存储，任务依赖图 = DAG。经典分布式系统通过「任务分片 + 独立 worker + 共享存储」解决了「单机算力不足」的问题。Harness Engineering 在做同样的事——用任务原子化和子代理解决「单上下文窗口不足」的问题。

03 | 原子化的三个核心标准

标准 1：上下文足迹 < 50%

一个原子任务所需的全部上下文（spec + plan + 相关代码 + 推理空间），加起来不应超过模型上下文窗口的 50%。

为什么是 50%？30% 留给推理（chain-of-thought），20% 留给输出生成。留出充足「工作空间」是质量的保障。如果一个任务要塞满 90% 上下文，它事实上已经太大了，应该继续拆分。

标准 2：依赖闭包可显式声明

一个原子任务应该能够明确说出：「我依赖 X、Y、Z 这几个文件，仅此而已」。如果一个任务的依赖是「理解整个系统」，它就不是原子任务。

实操验证法：让一个完全没看过这个项目的开发者，只读你给他的依赖文件清单，能不能完成任务？能 → 原子任务；不能 → 还需要拆分或补充上下文清单。

标准 3：完成标准可二元判定

任务完成与否，必须能用一个明确的标准判定，不存在「做完了 80%」的中间态。

好的完成标准：单元测试通过、集成测试某个 case 通过、API 返回特定 schema、编译无错误 + lint 通过。坏的完成标准：「代码看起来不错」、「应该可以工作」、「基本功能实现了」。

04 | 为什么「原子化 + 隔离」比「长会话」更好？

1. 每个任务都拿到 100% 干净的上下文

长会话执行到第 5 个任务时，上下文里塞满了前 4 个任务的代码、错误、修改历史。原子化执行第 5 个任务时，上下文里只有该任务相关的内容。这种「无前历史污染」是质量保障的根基。

2. 失败可以局部回滚

长会话中第 3 个任务失败 → 整个会话状态混乱 → 通常只能从头开始。原子化中第 3 个任务失败 → 仅该任务回滚 → 其他任务结果完整保留。

3. 真并行带来性能跃升

长会话天然串行——前一个任务不结束，下一个无法开始。原子化任务可以波次并行——10 个无依赖任务同时执行，理论上 10 倍速。

4. 主上下文保持轻盈

主代理（Orchestrator）只负责调度任务、检查产出、推进流程。它不持有任何具体任务的实现细节，所以主代理上下文始终在 30%-40% 占用率，能长期高效运行。

05 | 各 Harness 框架的原子化实践

不同 Harness 框架在原子化上的实践差异很大：

框架	原子化机制	上下文隔离方式	并行能力
GSD	强制原子任务 + 200K Token 单任务上限	每任务独立子代理 + 强制 /clear	波次执行（Wave）
OMC	19 个专业代理（架构师、审查员等）	代理职责隔离	团队级并行
ECC	48 个代理 + 182 技能	跨工具代理隔离	多代理协作
Trelli	tasks/ 目录每条任务独立文件	任务级文件隔离	中等
Spec-Kit	tasks.md 中的 Task	弱隔离（同会话执行）	弱
OpenSpec	tasks.md 中的 Task	弱隔离	弱

关键观察：SDD 框架（Spec-Kit、OpenSpec）的原子化偏弱——它们更关注规范结构，对执行隔离的关注不够。上下文工程框架（GSD）的原子化最强——它们就是为了解决 Context Rot 而生。

实操中的最佳组合：SDD 框架管「任务怎么拆」，上下文工程管「任务怎么执行」。两者结合 = 完整的 Harness 闭环。

06 | 原子化的反模式

反模式 1：伪原子任务

典型表现：tasks.md 里写了一条任务「实现用户管理」，看起来是一条任务，但展开后涉及 20 个文件、3 个数据表、5 个 API。后果：执行时仍然超出窗口，原子化变成名义上的。正确做法：原子任务的粒度应该是 30 分钟内能完成的最小单元。如果预估超过 1 小时，必须拆分。

反模式 2：上下文不隔离

典型表现：拆了原子任务，但都在同一个会话中串行执行，不 /clear，不切子代理。后果：所有原子化收益归零。正确做法：每个任务执行前显式清除上下文（或使用子代理），从文件系统重新加载所需信息。

反模式 3：并行无共享状态

典型表现：开了 5 个 worktree 并行做任务，但每个 worktree 里的代理对项目最新状态认知不一致。后果：合并时出现冲突、重复实现、命名不一致。正确做法：所有并行任务必须共享一份真相源（git 主分支 + 中央 spec），完成后通过 PR 合并到主线。

反模式 4：忽视任务依赖

典型表现：把所有任务都标为可并行，结果 Task B 在 Task A 完成前开始执行，找不到 Task A 的产物。后果：依赖任务失败，整个波次推迟。正确做法：tasks.md 必须显式标注依赖关系（如「Task 5 depends on Task 3」），调度器据此分波次执行。

07 | 延伸思考：与微服务架构的同构性

任务原子化和微服务架构有惊人的同构性：

微服务架构	任务原子化
服务边界清晰	任务边界清晰
服务独立部署	任务独立执行
服务间通过 API 通信	任务间通过文件系统通信
服务数据库私有	任务上下文私有
编排器（K8s）调度	主代理调度子代理

这不是巧合。两者解决的是同一类问题：复杂系统拆分为可独立运转的小单元。微服务解决的是人类协作和系统复杂度，任务原子化解决的是 LLM 上下文限制。

从并行计算的角度看，任务原子化把 AI 编程从「单核 CPU」升级为「多核 CPU」：1 个会话顺序执行 = 单核，N 个子代理并行 = N 核，通过 DAG 协调 = SIMD 调度。这意味着 Harness Engineering 让 AI 编程的速度理论上线性可扩展——只要任务能切到足够细，硬件能支撑足够多的并行子代理。

三条原理的协同关系：

决策外化为文件 → 提供持久化的真相源 → 被加载到流程结构化为阶段 → 在 Tasks 阶段产出可调度的任务清单 → 被拆分为任务原子化为单元 → 在隔离的子代理上下文中并行执行后产出代码 → 写入文件系统 → 成为新一轮的真相源。

三者构成一个自我闭环的工程化系统。决策外化提供「地基」，流程结构化提供「骨架」，任务原子化提供「血肉」。缺一不可，互为支撑。

常见坑

任务粒度失当：太粗（「实现整个认证系统」）导致上下文溢出，太细（「写这个变量名」）导致碎片化。甜点区：一个函数、一个组件、一个 API 端点。
只拆不隔离：拆了原子任务但都在同一个会话执行，原子化收益归零。
并行不共享真相源：多个子代理各自为政，合并时冲突不断。
没有显式依赖声明：调度器不知道任务先后顺序，导致波次执行失败。
验收标准模糊：任务做完了但不知道算不算「完成」，AI 和人类各说各话。

总结

上下文是单一稀缺资源：广度 vs 深度、长任务 vs 注意力衰减、并行 vs 串行，三组矛盾不可调和
原子化三件套：原子化任务（可独立加载/执行/验收）+ 上下文隔离 + 子代理并行
三个核心标准：上下文足迹 < 50%、依赖闭包可显式声明、完成标准可二元判定
反模式要警惕：伪原子任务、上下文不隔离、并行无共享状态、忽视任务依赖
与微服务同构：本质是把 AI 编程从单核升级为多核

下一篇我们进入 OpenSpec 深度剖析——规约驱动开发的终极形态，看看如何用规范来驱动 AI 编程。

关注我，James 的成长日记，持续分享干货，帮你在 AI 时代少走弯路。

内容效果不满意？点此反馈