Harness工程调度优化：利用Ultracode解放LLM上下文

背景

在基于大语言模型（LLM）的多智能体协作架构中，Harness 工程通常采用“逐步委派”的模式来管理复杂的开发任务。传统的调度器（Scheduler）需要在一个对话上下文中，通过手动循环的方式协调 Generator（生成者）、Evaluator（评估者）和 Product Acceptance（产品验收）等子智能体。

随着冲刺（Sprint）数量的增加，这种模式面临严峻挑战：调度器的上下文窗口需要承载所有的中间状态、信号文件读取逻辑以及循环判断逻辑。这导致上下文负载随冲刺数线性增长，不仅消耗大量 Token，还容易因上下文溢出导致状态丢失或逻辑混乱。此外，手工编写的串行等待逻辑限制了子智能体的并发潜力，且缺乏原生的中断恢复机制。

为了解决上述问题，作者引入了 Claude Code 的 ultracode 机制，对 Harness 工程的调度层进行了重构，旨在利用官方运行时机制实现更高效的上下文隔离与任务编排。

核心内容

本次优化的核心在于将“循环逻辑”的执行主体从调度器的上下文转移至 ultracode 运行时脚本，从而解放调度器的上下文负担。

1. 升级动因

• 上下文隔离与辅助：虽然当前模型支持 1M 上下文，但使用 ultracode 可以进一步辅助上下文隔离，聊胜于无。
• 官方机制依赖：利用 ultracode 的官方协作机制，Harness 框架能更好地调度和管理各子智能体（Subagent）。这使得后续可以依赖官方对 ultracode 机制的升级而自动获益，减少维护成本。
• Token 效率：ultracode 在 Token 考量指标上表现优异，能够轻松完成复杂任务。
• 主观偏好：作者对 ultracode 的功能表示高度认可。

2. 架构对比：原版 vs. 新版

原版架构（逐步委派）

• 调度逻辑：调度器在每个冲刺中手动执行循环：
  1. 委派 Generator 执行冲刺 N。
  2. 等待 sprint_N_signal.json 出现。
  3. 委派 Evaluator 进行 QA。
  4. 等待 sprint_N_qa_signal.json 出现。
  5. 若 FAIL，委派 Generator 修复，删除信号文件，重新委派 Evaluator，直到 PASS。
  6. 委派 PA 进行产品验收。
  7. 若 Rejected，委派 Generator 修复，重新走 QA + PA 流程。
  8. 进入冲刺 N+1，重复上述过程。
• 痛点：调度器上下文需承载所有中间状态，随冲刺数增加，上下文负载线性增长；子智能体必须串行执行（手工等待）；中断恢复依赖调度器读取信号文件判断。

新版架构（ultracode 动态工作流）

• 调度逻辑：调度器在阶段二仅做一件事——触发 ultracode 编排 web-builder 冲刺构建工作流。
  1. 读取 sprint_plan.json。
  2. 发出指令让 ultracode 顺序执行 Generator → QA → 修复循环。
  3. 调度器立即退场，不再参与后续循环。
• 运行时接管：Claude Code 的 ultracode 运行时接管后续逻辑，自动生成 JavaScript 编排脚本，按定义好的逻辑启动子智能体、等待信号文件、判断分支并循环修复。
• 优势：
  • 上下文零增长：调度器仅进行一次一次性委派，上下文负载几乎不增长。
  • 并发优化：运行时可在依赖允许范围内优化子智能体的并发执行。
  • 内建恢复：ultracode 拥有内建的 Checkpoint 机制，支持更好的中断恢复。

3. 实际工作流指令详解

新版调度器通过以下指令驱动 ultracode：

1. 触发：在提示中包含 "ultracode" 关键词，让 Claude Code 自动生成工作流编排脚本。
2. 输入：读取 .web-builder/sprint_plan.json 获取冲刺列表。
3. 执行逻辑：
   • 顺序约束：对每个冲刺 N（从 1 到 M）必须顺序执行，不可并行。
   • 阶段 A - 生成：委派 web-builder-generator 执行冲刺 N，等待 sprint_N_signal.json 状态为 "generated"。若为 "error" 则记录并跳过。
   • 阶段 B - QA：委派 web-builder-evaluator 执行 7 维度全量验收（技术 QA、用户场景、视觉、UX、回归、规格审计、集成），等待 sprint_N_qa_signal.json。
   • 修复循环：若 QA FAIL，委派 web-builder-generator（修复模式）读取报告逐项修复，更新状态为 "fixed"，删除旧信号文件，重新执行 QA。最多循环 3 次。
   • 通过：若 QA PASS，继续下一冲刺。
4. 完成检查：所有冲刺完成后，输出 BUILD_COMPLETE，并通过 Python 脚本检查 feature_list.json 统计通过的功能数量。

4. 局限性说明

• 并行性限制：尽管 ultracode 是 2026 年 5 月底进入 Research Preview 的新功能，但对于线性依赖的冲刺循环（如冲刺 2 必须等冲刺 1 完成），它并不会真正并行执行。
• 本质变化：核心收益并非并行加速，而是将“驱动循环的责任”从调度器上下文移至运行时脚本，从而实现了调度器上下文的彻底解放。

关键要点

• 上下文解放：新版架构最大的收益是调度器上下文不再随冲刺数量线性增长，从“撑过 10 轮委派+等待+判断”变为“发出一次指令即退场”。
• 责任转移：循环逻辑、信号文件读取、分支判断和修复循环的执行主体，从调度器 LLM 上下文转移到了 ultracode 运行时生成的脚本中。
• 依赖官方机制：通过依赖 Claude Code 的 ultracode 机制，Harness 框架获得了自动化的子智能体调度、内建 Checkpoint 以及潜在的后续官方升级红利。
• 串行约束依旧：对于具有严格线性依赖关系的任务（如 Sprint N+1 依赖 Sprint N），ultracode 依然保持顺序执行，并未突破并行瓶颈，但提升了编排的健壮性和可维护性。
• 真实可部署：该改动并非理论探讨，而是真实可部署的架构变化，实际效果取决于 ultracode 自身的能力表现。

意义与影响

这一优化案例展示了多智能体系统中调度层解耦的重要趋势。通过将复杂的控制流逻辑从主对话上下文剥离，交由专门的运行时引擎（如 ultracode）处理，系统能够显著降低对 LLM 上下文窗口的依赖，提高长周期任务的稳定性。

对于 Harness 这类需要多次迭代、严格质量门禁的工程化场景，这种架构转变意味着：

1. 可扩展性提升：系统不再受限于调度器的上下文长度，理论上可以处理更多数量的冲刺或更复杂的任务链。
2. 维护成本降低：利用官方机制替代手工编写的信号文件轮询逻辑，减少了代码维护负担，并利用了官方提供的容错和恢复机制。
3. 范式参考：为其他类似的多智能体框架提供了参考，即如何利用新兴的运行时编排工具（如 ultracode）来优化传统的“提示词驱动循环”模式，实现更优雅的状态管理和资源调度。