使用 Fast 档位时，我们期待 Agent 更早给出判断和下一步动作。但在编程任务里，模型回答只是执行过程的一部分：用户最终需要的是一份改对了代码、通过验证的结果。要让这份结果更早交付，还要把模型之外的等待一起缩短。
以修复一个接口错误为例，Agent 要准备运行环境、读取代码、组织上下文、请求模型、修改文件，再运行测试。如果验证失败，还要带着结果继续判断；如果中途断流，还要确认哪些操作已经完成。用户等待的是一份通过验收的修复，这段时间取决于整条链路怎样协同。本文沿着这条链路，解释 Qoder 的 Harness 如何减少等待。
模型、Harness 与 Qoder CLI：从能力到执行
模型负责理解上下文、推理和生成动作；Harness 负责让这些动作进入一个可执行、可观察、可恢复的过程。它组织每轮模型请求，管理上下文，校验并执行工具，记录结果，再决定继续、结束还是处理异常。选择 Fast 等模型档位，是这个过程中的模型选择；请求多少轮、每轮带什么、工具什么时候开始，则由执行链路共同决定。
Qoder CLI 是这套执行能力的主要运行载体。它既提供终端交互，也在内部承载 Agent 循环、上下文管理、工具调度、权限与恢复。Harness 描述的是这些工程职责，CLI 描述的是承载它们的程序。终端用户直接使用 CLI；桌面端和自建应用可以通过 Qoder Agent SDK 接入 CLI 进程或常驻 daemon，提交任务、接收流式结果并处理权限请求。
SDK 负责程序接入与输入输出协议，具体任务仍由 CLI 的会话执行器进入核心 Agent 循环：组装请求、消费模型响应、执行工具、写入结果，再进入下一轮。当前既有按会话启动进程的接入，也有由常驻 daemon 管理多会话的接入；一次会话中的多轮请求复用已有执行过程，SDK 接入并不意味着每轮都重新启动进程。不同入口复用的是同一套 Harness 能力。
图 1：Qoder CLI、SDK 与 Harness 的关系
接下来沿着一次任务看等待从哪里产生：启动准备完成后，模型请求与工具执行可能交替多轮，最后得到结果并完成收尾。流式执行会让部分模型生成与工具运行重叠；中断恢复则是异常时进入的分支。优化要减少用户必须等待的那条依赖链，同时保留正确的执行顺序。
图 2：Agent 任务执行链路及各阶段的优化位置
启动：把准备工作移出用户等待的时间
程序开始工作前，需要加载代码、准备配置与执行环境。这里有三种不同的办法：把可预计算的工作提前到构建时，把不必阻塞当前操作的工作放到后台，以及提前准备首轮很可能用到的资源。它们分别改变计算发生的时机和用户需要等待的依赖。
把解析与编译提前到构建时
不开字节码时，运行时需要在启动阶段解析和编译 JavaScript 载荷。当前二进制构建默认生成字节码，把这部分工作提前到发布产物的构建阶段，启动时直接加载，减少运行时需要完成的准备。
后台化：让非必要准备离开当前关键路径
当前启动生命周期会在后台发起部分身份设备信息初始化和用户状态刷新；交互入口也不会为了等待配置服务初始化完成而一直挡住界面启动。这样，展示界面或继续初始化的工作可以与这些准备重叠，用户不必先串行等完每一项。
后台化保留了原有工作量，也保留了必要的依赖。首次模型请求如果确实需要某项尚未就绪的配置，仍然要等待。
预热：把首轮需要的环境提前准备好
配置初始化完成后，程序会尝试预热 Bash 执行环境，并提前采集系统提示需要的 Git 上下文。符合条件的交互入口，还会提前准备代码检索所需的运行组件。
Git 预热只在已信任的目录中进行，缓存按工作目录关联，避免切换目录后把旧仓库信息带进新请求。预热的价值取决于提前量：在用户输入期间，或与其他启动准备同时进行，首轮就能少等一部分；提交早于预热完成时，只能复用已经完成的部分或继续等待。换句话说，它不是把准备变快，而是把准备挪到用户还没提交的那段时间里。程序退出时，未完成的预热会被取消，避免后台任务继续占用资源。
推理与传输：减少模型请求与传输开销
一次任务可能包含多轮模型调用。每轮都要准备输入、传输请求、等待模型处理并接收输出。Fast 档位关注模型侧的响应能力，Harness 还可以从调用次数、输入内容和传输过程继续减少开销。
能直接使用的结果，省去二次模型处理
模型调用本身也有成本：即使只是把已有内容重新概括一次，也要多一次请求和生成。如果上一步已经给出了适合主模型继续使用的内容，Harness 会按明确条件直接返回结果。
WebFetch 就有这样的分支：网页抓取成功后，程序会检查地址是否预先获准、内容类型是否受支持、长度是否在限制内。符合条件的 Markdown，或以 /llms.txt 结尾的纯文本索引，会直接作为工具结果返回，省去一次辅助摘要；明确的 HTTP 错误也会直接返回诊断。这条路径减少的是一次二次处理请求，并没有省掉网页抓取，其他网页仍可能需要正文转换和模型处理。
辅助调用使用匹配任务的推理预算
不是所有调用都需要最强模型。网页摘要、标题、子 Agent 这类辅助任务，可以使用更快的模型和更合适的推理预算，把强模型留给主任务。历史压缩要保留足够信息，复杂子 Agent 要完成自己的判断；这类任务省下的时间，以结果够用为前提。
保持重复前缀稳定，为缓存复用创造条件
生成历史摘要时，派生请求要再次处理主会话已经发过的内容。Harness 会让摘要请求沿用主会话的系统提示、工具定义和请求前缀，尽量保持分块一致，这样后端就有机会复用已经处理过的前缀。反过来，前缀开头的内容频繁变化，会让后面可复用的部分变短。
复用工具说明和允许执行工具是两件事：摘要请求可以带上主会话的工具定义以保持输入一致，同时禁止实际调用。它复用的是请求表示；真实命中多少、能省多少时间，取决于后端的缓存能力。
按需展开 MCP 工具定义
接入几百个外部工具时，把完整参数说明全部常驻上下文，代价很高。按需加载把“发现、取定义、调用”拆开：先用目录找到候选工具，需要时再取参数定义，最后发起调用；需要常驻的工具仍可直接暴露。目录只承担导航职责，展示省略不会删除服务端真实可用的工具。
按需加载把完整说明的开销推迟到真正需要时：接入工具较多时，可以避免让大量暂时用不上的定义常驻上下文；使用工具前则可能多一次发现和获取定义的往返。是否采用这一模式，由入口和配置决定。
控制长历史和工具输出的体积
长会话会不断积累代码、日志和工具结果。Harness 会先处理体积过大的工具输出，再根据实际上下文判断是否生成历史摘要；摘要形成新的边界，后续请求带着摘要和保留内容继续工作。较大的工具结果还可以落盘，在上下文里只保留预览和读取位置。
工具输出的预算，按单条消息内的合计体积计算。历史摘要本身也要调用模型，也可能遗漏细节；压缩让上下文更短，完整任务是否更快，取决于后面这些内容怎么被使用。
请求体压缩：减少上传字节
请求在传输层还会做压缩，服务端解压后仍拿到原始内容，所以模型看到的输入 Token 不会因此减少。只有开关启用、传输适配且请求达到体积门槛时才尝试压缩；压缩结果没有变小时，直接发送原始内容。
小请求或快速网络下，压缩省下的绝对时间有限；它减少的是上传字节，模型输入 Token 并不变。
工具执行：沿着依赖关系重叠工作
模型给出工具调用后，参数解析、权限判断、排队和实际执行仍要占用时间。
能不能并发，由工具的并发契约和本次参数校验共同决定；无法确认时按独占执行。以“读取 A、读取 B、修改 A、再次读取 A 验证结果”为例：两个读取可以同时开始；修改要等它们结束；最后的校验读取再等修改完成。独占操作会形成屏障，阻止后续调用越过写入。
并发执行和结果返回顺序是两回事：工具可以在后台重叠运行，结果仍按提交顺序归集。
流式执行让开工更早：模型还在生成后面的调用时，前面已经完整的调用可以先送进调度器；参数没完整的调用不会被猜测补齐。工具真正执行前，仍要经过参数检查与权限流程。这样，模型生成与工具执行可以重叠。
图 3：流式工具调度与安全并发机制
中断恢复：沿着已确认的执行事实继续
假设读取 A 已结束，修改 B 也已写入文件，但模型随后断流。文件修改不会因为网络中断自动回滚；恢复时要先确认这次执行留下了什么，再决定下一步，否则可能重复修改或重复触发外部副作用。
Harness 会按调用 ID 收集已下发工具的结果，并区分已确认结果、未下发调用和结果未知的调用。已确认的结果写回历史，恢复消息告诉模型哪些已经完成、哪些没有执行；还没收到完整参数的调用不进入执行。可恢复的中断沿着这些记录继续，并受有限的恢复次数约束。
存在未知结果时，不自动续跑，并明确保留“副作用可能已经发生”的事实。用户取消或终止收尾时，工具结果的等待还有时间边界，超时后隔离迟到回调。这样既保留确定的进度，也避免把无法确认的执行状态当成可安全重试。
MCP 临时断线后，下一次已授权调用会先等待连接恢复与工具重新发现。多个调用可以共享连接恢复过程，某一个调用取消只结束自己的等待。恢复后还会核对工具名称、参数定义及权限相关契约；契约变化时，需要重新取定义并发起调用。恢复连接只说明通道可用，不代表上一次调用已经完成，因此不会自动重放结果未知的请求。
使用者也能减少哪些等待
使用方式会改变 Harness 接收到的工作量和依赖，日常可以从上下文、任务边界和同步扩展入手。
- 别什么都常驻。 几百个 MCP 工具、用不上的 Skill 都堆在上下文里，每轮输入都被它们占满——只留常用的，其余按需再开。
- 别一个会话干到底。 不相关的任务堆在同一会话里，上下文越滚越大，每轮都要重新处理——新任务开新会话；只是顺带一问，用
/btw提问，别占用主任务的上下文。
- 关键路径上的 Hook 要精简。 处于关键路径上的 Hook 会把耗时带进当前操作，触发越频繁，累计等待越明显。先确认它是否必须在执行前完成，再在保持行为顺序的前提下考虑缓存、合并或后台处理。
- 跑偏了别让它跑完。 方向错了还等它收尾再返工，比当场打断慢得多——该插话、该中断就及时出手。
- 别每轮重新交代背景。 把稳定的偏好和项目背景交给记忆，不用每次重说。
结语
Fast 模型与 Harness 的工程优化，共同决定用户何时拿到可用结果：模型更快地给出判断，执行链路减少重复准备和重复输入，让独立工作重叠，并在异常时保留确定的进度。
