原文地址：https://x.com/sairahul1/status/2078367561453101097原文：Loops & Harnesses: Why The Best AI Engineers Stopped Writing Prompts

两位资深 AI 工程师在同一个月里表达了几乎相同的观点。

OpenClaw 创建者、现任 OpenAI 工程师 Peter Steinberger 表示：

不应该再直接给 Coding Agent 写 Prompt，而应该设计一套能够持续给 Agent 下达任务的 Loop。

Anthropic Claude Code 负责人 Boris Cherny 也提到：

我已经不再直接 Prompt Claude。我运行的是一些会自行 Prompt Claude、判断下一步该做什么的 Loop。我的工作变成了编写 Loop。

很多人看到这些说法后的第一反应是：Loop 到底是什么？又该怎样构建？

本文将从工程角度回答这两个问题。

大多数人使用 AI 的方式已经落后

写 Prompt，等待，阅读输出，手工修正，再写一个 Prompt。

在这套交互方式里，人本身就是 Loop：每一步都必须经过人，AI 等待人的判断；人一停下来，整个流程也随之停止。

2026 年进展最快的开发者，并不是单纯把 Prompt 写得更精巧，而是在构建能够自动规划、执行、验证和继续推进的系统。杠杆点已经从“输入 Prompt”转向“设计 Loop”。

Loop 究竟是什么

Prompt 更像一个问题：人提出请求，模型回答一次，交互结束。

Loop 则代表一项工作：Agent 持续执行、检查进度，并不断迭代，直到任务真正完成。判断标准不应是“模型已经生成了一段回答”，而应是“系统已经得到可验证的结果”。

这种“重复执行直到完成”的机制，就是 Loop，也是多数 AI Agent 的基础运行方式。Claude Code、Cursor、Codex 等工具在底层都可以抽象为类似过程：

Agent 调用模型；模型选择下一项行动或工具；Harness 执行行动；执行结果返回模型；模型基于环境反馈继续决策；达到完成条件或资源上限后停止。

Loop 让 Agent 不再只是一次模型回复，而成为能够与环境持续交互的执行系统。

不过，成熟产品中的 Loop 通常由产品方预先设计，用户只能使用既定的工具、权限、上下文策略和停止逻辑，未必能直接修改它们。

Agent Loop 的基础运行过程

从 Loop 走向可编程 Harness

原文以 Random Labs 的 Slate 为例，介绍了一种可编程 Agent 工作流。Slate 是一个 CLI，强调把任务拆成独立线程并行执行。其 Program 允许开发者用 JavaScript 描述工作流，为不同步骤选择模型、连接真实软件，并自行控制 Loop，而不是完全依赖黑盒式的 managed agent。

Slate Program 的工作流示意

按照原文的定义，Loop 是“持续工作直到完成”的思想；Program 则是 Slate 中实现这种思想的具体方式。开发者需要决定：

每一步执行什么；哪个模型负责哪一步；继续执行前检查什么；怎样判定成功；何时停止或升级给人处理。

如果能清楚描述步骤，就能把它们组织成 Loop。可组合的基础模块包括：

Goal input：定义目标、约束和验收标准；Planner：研究任务并将其分解为步骤；Worker：执行各个子任务；Verifier：基于独立证据检查执行结果；Loop controller：管理重试、继续和退出；Model routing：按任务难度选择模型；State：在步骤或会话之间保存必要状态；Stop conditions：规定成功、失败、超时和预算耗尽的处理方式。

Program 的可组合模块

原文进一步设想，系统在已有模块能够协作后，还可以诊断工作流中的薄弱环节并建议增加模块。不过，“Loop 会自动变得越来越聪明”更适合作为产品愿景理解；生产系统仍需依靠版本控制、离线评测、可回滚变更和人工审批，避免自动修改引入不可预期的行为。

为什么模型应该按步骤选择

一个 Program 中的不同步骤，不一定需要同一模型。

例如，文件枚举、格式转换和简单分类可以交给速度快、成本低的模型；跨文件推理、架构决策和高风险审查则交给能力更强的 frontier model。也可以在适当场景使用 open-weight model。

为不同步骤选择不同模型

这种做法的重点不是“永远使用最强模型”，而是根据以下指标进行路由：

任务难度与上下文规模；错误造成的损失；延迟和成本预算；工具权限及数据敏感性；在真实评测集上的成功率。

模型路由应当显式、可观测、可评测。不能因为某种 lead/worker 组合在一个案例中有效，就把它视为所有任务的固定最优解。

一个实际案例：构建山火数据 Wiki

假设目标是构建一个山火数据交互式 Wiki。传统方式可能需要一两天手工连接数据源、规划页面并实现功能。使用可重复工作流时，可以把过程拆成四类模块。

Block 1：Deep Research

围绕问题搜索资料、阅读来源、筛选数据集，并总结真正重要的信息。

Block 2：Planner

把研究结果交给 Planner，先确定项目初始化方式，再把 Wiki 拆为地图、时间线、数据表和搜索等可执行需求。

Block 3：Parallel Workers

将相互独立的需求分发给不同 Worker 并行处理，每个 Worker 围绕自己的目标持续执行和验证，直到对应功能完成。

Block 4：Compose

汇总各模块的产物，形成可以实际操作的 React Wiki。需要更新数据或重新生成时，再运行同一套 Loop。

山火数据 Wiki 的并行执行过程

真正有价值的不是某一次生成结果，而是：研究输入能够稳定地转换为可交付网站，且流程可以重复运行、检查和改进。

Program 不应从空白文件开始

原文认为，用户只需要告诉 Slate 想构建什么，Slate 就能逐步协助起草 Loop、保存工作流并负责运行。它更像共同设计 Harness 的工程搭档，而不是一个只能按固定方式工作的 Agent。

传统模式是：“这里有一个固定 Agent，请在我们的系统里使用它。”

Program 模式则是：“这里有一组模块，请描述目标，我们共同把它们连接成适合任务的系统。”

由 AI 协助搭建 Program

JavaScript Program 可以连接真实系统

Prompt 通常返回一次答案；Program 则可以通过 API、CLI、数据库和其他工具与现实系统交互。

例如：

定期检查 Slack 新消息，并按需生成代码；针对代码库运行迁移、测试与复验；持续处理电子表格中的新数据；构建类似 Claude Tag 的消息驱动工作流；组织由多个专职 Agent 构成的软件交付流水线。

Program 与外部软件集成

但“能够连接系统”不等于“应该拥有无限权限”。生产 Harness 至少需要：最小权限、工具 allowlist、沙箱、敏感操作审批、幂等设计、审计日志和失败补偿。像迁移数据库或自动发布代码这样的操作，不能只依赖 Prompt 中的一句约束。

Slate 的安装与启动

原文给出的安装命令如下：

npm i -g @randomlabs/slate

进入项目后启动：

安装命令和产品行为可能随版本变化，实际使用前应检查包来源、版本、权限范围及官方文档。

原文此处为约 8 秒视频。由于视频源连接超时，本文保留了原始预览图；可通过原帖查看视频。

技术补充：真正重要的是 Harness，而不只是 Loop

Loop 只是重复机制。决定 Agent 是否可靠的，是包围模型的整套 Harness：

上下文如何构造与压缩；工具怎样定义、授权和执行；环境反馈如何返回模型；状态如何持久化和恢复；子任务怎样并行、隔离和汇总；结果怎样验证；成本、轮数和时间怎样限制；失败后怎样重试、降级或交给人。

Anthropic 将 workflow 与 agent 区分开来：workflow 通过代码中的预定义路径编排模型和工具；agent 则根据环境反馈动态决定过程与工具使用。官方同时强调，应从最简单的方案开始，只有在评测证明复杂架构有必要时，才增加 Agent、自主规划和多 Agent 编排。

1. Verification Loop：完成必须由证据决定

优先采用确定性验收信号：

单元测试、集成测试和静态检查全部通过；数据库状态满足断言；队列已经清空；产物存在且结构合法；质量指标达到阈值；PR 已通过检查并合并。

对于文字质量、视觉设计等难以完全确定性判断的任务，可以加入 rubric 或 LLM judge，但它们只能补充测试，不能替代权限控制和事实验证。

2. Parallel Agents：只并行真正独立的工作

检索、审查、分类和互不依赖的功能模块适合并行。多个 Agent 同时修改同一份状态则容易发生竞争和覆盖，应使用独立工作目录、worktree、事务或明确的合并策略。

并行也不是免费的：fan-out 会增加 Token、API 限流压力、汇总成本和冲突概率。只有当子任务彼此独立、结果易于压缩，而且并行节省的时间大于协调成本时，才值得使用。

3. State：对话状态不等于系统状态

至少要区分：

Conversation state：Prompt、工具调用、结果与回复；Business state：任务、队列、审批和执行进度；Workspace state：文件、数据库及构建产物；Long-term memory：跨会话规则与稳定知识。

恢复一段对话并不会自动回滚文件系统。会话 fork 也不等于 workspace fork。长任务必须显式保存 checkpoint，并保证重复执行不会造成破坏。

4. Stop Conditions：停止是一项产品能力

一个可控 Loop 同时需要：

成功条件：可验证目标已经达成；失败条件：连续失败、依赖不可用或结果不再改善；资源边界：最大轮数、Token、预算、时间与并发；策略中断：权限不足或触发安全规则；人工升级：遇到高风险、歧义或不可逆操作时暂停。

如果只设置“模型不再调用工具就结束”，系统可能过早退出；如果只设置“持续到成功”，系统又可能无限重试。可靠 Harness 会同时处理语义完成信号和硬性资源上限。

5. OpenAI Agents SDK 中的对应机制

OpenAI Agents SDK 展示了同一类基础 Loop：模型产生最终输出且不再调用工具时结束；产生 tool call 时，Runner 执行工具、追加结果并再次调用模型；发生 handoff 时，则切换 active agent 后继续同一次 run。这里的默认退出只代表协议层允许结束，并不自动证明任务结果正确。

其官方资料还提供了几类 Harness 组件：

max_turns：限制模型调用轮数，超过后抛出 MaxTurnsExceeded；Guardrail：在输入、最终输出或工具执行前后检查策略，并通过 tripwire 中止运行；RunState：在工具需要人工审批时暂停并序列化执行状态，批准或拒绝后恢复；Session：保存会话历史，但不应与业务状态、文件系统状态和长期记忆混为一谈；Manager-as-tools 与 handoff：分别对应中央编排者保留控制权，以及把 active-agent 控制权移交给专职 Agent；asyncio.gather 与 parallel_tool_calls：分别实现应用层固定并行和模型规划的并行工具调用。

这进一步说明，“Agent 自动运行”并非单一开关，而是 Loop、工具、状态、验证、路由、并行策略和停止机制共同组成的系统。对于付款、写数据库或发送外部消息等不可逆操作，Guardrail 若与 Agent 并行执行，可能在检查失败前已经产生副作用，因此应采用阻塞式预检、工具级 Guardrail 或人工审批。

总结Prompt 通常只回答一次；Loop 代表一项持续执行、反馈和验证的工作。Claude Code、Cursor、Codex 等 Agent 产品的底层都包含某种模型—工具—环境反馈循环。Program 是原文中 Slate 对可编程 Loop 的实现：用 JavaScript 描述步骤、模型、状态、验证和停止条件。不同步骤可以选择不同模型，但路由策略必须通过评测验证。独立子任务适合并行；共享写操作必须隔离和受控合并。结果必须由测试与环境证据确认，而不是由 Agent 自称“已经完成”。真正的工程重点不是写出更长的 Prompt，而是构建可观测、可恢复、有限额、有权限边界的 Harness。

换句话说，开发者的角色正在从“逐轮指导模型的人”，转变为“设计执行环境、反馈回路和验收机制的人”。Prompt 仍然重要，但它只是 Harness 中的一部分。