概览

Harness 工程已经在基础章节中定义过：模型之外负责上下文、工具、约束、验证和纠正的系统外壳，决定了 Agent 能否从一个可运行 Demo 变成可靠产品。

这里不再重新解释 Harness 是什么，而是讨论一个更实际的问题：当任务越来越长、状态越来越多、失败方式越来越复杂时，Harness 应该怎样从一段控制流演进成一套可维护的系统。

Anthropic 从 2024 到 2026 年发布的四篇工程文章，正好给出了一条清晰路径：

  1. 先判断是否真的需要 Agent。
  2. 如果控制流可预测，优先使用 Workflow。
  3. 如果任务需要模型自主决定下一步，才进入 Agent。
  4. 如果任务跨上下文窗口、跨多个 Agent、跨多个执行环境，Harness 本身就要具备交接、评估、恢复和替换能力。

这条路径的价值不在于给所有系统套同一种架构，而在于提醒我们：每增加一层自主性，都必须补上一层相应的工程约束。

从模式到基础设施

早期的 Agent 设计重点在“模型如何行动”：给模型工具、让它观察结果、再决定下一步。这个阶段最重要的是选择合适的模式，避免把简单任务过度 Agent 化。

长程任务出现后，问题变成“模型如何接上之前的工作”：上下文窗口会满，Agent 会重启，环境会变化，下一轮执行必须知道当前做到哪里、哪些假设仍然成立、哪些测试可以证明进展是真的。

多 Agent 架构又把问题推进一步：复杂应用开发不只是“写代码”，还包括规格拆解、主观质量判断、实现检查和反复迭代。让同一个 Agent 同时负责生成和评估，往往会放大自我确认偏差，所以需要把 planner、generator、evaluator 的职责拆开。

Managed Agents 最后把视角从“某个 Harness 怎么写”提升到“Agent 平台应该暴露什么稳定接口”。如果 Session、Harness、Sandbox 绑在一起，系统很难替换模型、迁移执行环境或从 Harness 失败中恢复。把大脑、双手和会话状态解耦后，Harness 才能成为可替换的基础设施，而不是必须小心照料的单点系统。

四篇文章回答的问题

页面核心问题读完应该带走什么
有效 Agent什么时候用普通 LLM 调用、Workflow 或自主 Agent？复杂度阶梯：先用最简单方案，只有任务需要模型自主决策时才使用 Agent。
长程交接Agent 如何跨越多个上下文窗口继续工作？用 initializer / coding agent、功能清单、进度文件、git 历史和测试建立交接机制。
多 Agent 架构复杂应用开发中，怎样把生成、评估和规划拆开？让不同 Agent 承担不同判断，尤其不要让生成者独自评价自己的输出。
Managed AgentsHarness 自己会失效或过时时，平台接口应该怎样设计？用 Session / Harness / Sandbox 解耦大脑、双手和状态，让系统可恢复、可替换、可扩展。

选择哪一层复杂度

可以用任务的不确定性来决定 Harness 形态。

如果任务步骤清楚、输出容易验证，通常不需要 Agent。一次模型调用、结构化输出和简单校验就足够。

如果任务要分多步，但路径可以提前写清楚，使用 Workflow。提示链、路由、并行化、编排器-工作者、评估器-优化器，都属于这一层。这里的关键是让控制流留在代码里，而不是过早交给模型决定。

如果任务需要模型在执行过程中根据反馈选择下一步，才使用自主 Agent。此时 Harness 的重点不再只是“调用工具”，还包括停止条件、权限边界、轨迹记录、错误恢复和人工接管点。

如果任务会持续很久，跨越多个上下文窗口或多次运行，就需要长程 Harness。上下文管理不再只是截断和压缩，而是要把任务状态写入可恢复的外部记录，让下一个 Agent 能可靠接手。

如果任务本身包含多种判断，例如产品规格、视觉质量、代码正确性和用户体验，就需要考虑多 Agent 架构。拆分 Agent 的理由不是“多个 Agent 更先进”，而是不同判断标准需要不同上下文和不同失败路径。

如果要规模化运行大量 Agent，或者允许模型、执行环境、Harness 实现独立替换，就进入 Managed Agents 的问题域。此时最重要的是稳定接口，而不是某一次运行里的提示词技巧。

贯穿本章的判断

复杂度必须有成本意识。 多 Agent、长程运行和托管基础设施都会增加调试难度。只有当任务本身的不确定性超过简单 Workflow 的承载能力时，复杂 Harness 才值得引入。

上下文是交接机制，不只是窗口内容。 长程 Agent 最怕的不是上下文不够长，而是没有可靠记录说明任务为什么走到当前状态。更多关于压缩、记忆和上下文生命周期的内容放在 Context 章节。

评估要有独立性。 对复杂产物而言，评估器需要自己的标准、证据和失败出口。否则评估很容易退化成生成结果的解释器。

状态要放在能恢复的地方。 Agent 循环和沙箱都应该可以被杀掉、重启或替换；用户意图、工具结果、进度记录和会话事件必须留在持久 Session 中。

Harness 会随模型进步而过时。 每个 Harness 组件都暗含一个关于模型能力的假设。模型变强后，曾经必要的分解、重置、限制或检查可能变成负担；换模型时要重新审视这些组件是否仍然承重。

阅读顺序

建议按发表顺序阅读，因为它对应了问题规模的扩大：

  1. 有效 Agent
  2. 长程交接
  3. 多 Agent 架构
  4. Managed Agents

如果你正在设计一个具体系统，也可以反过来从问题出发：先确认是否真的需要自主 Agent，再判断任务是否长程、是否需要多 Agent 评估、是否已经进入平台化和托管化阶段。

来源

这页有帮助吗？
在 GitHub 编辑