长时间任务设计 - Agent Harness

• 参考源

Harness design for long-running application development

Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

https://www.anthropic.com/engineering/harness-design-long-running-apps

Effective harnesses for long-running agents

Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

Anthropic Just Dropped the New Blueprint for Long-Running AI Agents.

👉 Access our AI Builder course & join hundreds of serious AI builders in our community https://www.theaiautomators.com/?utm_source=youtube&utm_medium=video&utm_campaign=tutorial&utm_content=anthropic-harness-v2 🔗 Anthropic Article: https://www.anthropic.com/engineering/harness-design-long-running-apps Anthropic's engineering team just published a deep dive on harness design for long-running agents. And buried in the technical details are some honest admissions and crucial insights that apply to anyone building multi-step AI systems, not just coding agents. The core problem: when you ask an AI agent to evaluate its own work, it approves it. Confidently. Almost every time. Even when the output is mediocre. Their solution borrows from the GAN architecture: separate the agent doing the work from the agent judging it. One generates, one evaluates, and the tension between them drives quality upward. They demonstrated this with a 2D retro game maker (6 hours, fully autonomous) and a Digital Audio Workstation (nearly 4 hours on Opus 4.6), both built without human intervention. In this video, we break down the two failure modes they identified (context anxiety and poor self-evaluation), the 3-agent architecture they built to solve them (planner, generator, evaluator), and how you can apply these principles to your own systems, whether that's contract review, research pipelines, content generation, or data analysis. 🔗 Links: AI Builder Series Episode 6 (Harness Engineering): https://www.youtube.com/watch?v=I2K81s0OQto GitHub Repo (PRDs): https://github.com/theaiautomators/claude-code-agentic-rag-series Anthropic Article from November 2025: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents Opus 1 million Context Window: https://www.anthropic.com/news/claude-opus-4-6 Stripe Minions: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2 📌 This connects directly to our AI Builder series where we're building specialized harnesses into a full Python and React app using Claude Code. #AI #HarnessEngineering #AIAgents #Anthropic #LongRunningAgents #AdversarialEvaluation #ClaudeCode #AgenticRAG #LLM #AIBuilder #ContextEngineering #MultiAgentSystems

https://www.youtube.com/watch?v=9d5bzxVsocw

什么是Harness

• Harness - 围绕AI模型编排的可靠系统，目的是让模型在长时间or复杂任务中保持在正轨上，本质上是一个编排层（Orchestration），包含：
• 提示词（Prompts）、工具（Tools）、反馈循环（Feedback loops）、约束条件（Constraints）以及验证机制（Validation）。

解决的痛点

目标问题

• 如何给 AI Agent 设定一个复杂的目标（例如开发一个完整的应用、执行为期一个月的合规审计、建立内容管道），并让它在数小时甚至数天内持续工作以达成该目标？

目标挑战

• 试图一步到位（One-shots everything）：它会尝试在一次生成中完成整个应用的构建。

• 上下文耗尽（Runs out of context）：在任务执行到一半时，超出模型的记忆窗口。

• 半途而废（Leave work half-finished）：留下大量未完成且没有文档说明的半成品代码。

• 过早宣布“大功告成”（Declares "done" early）：仅仅为了尽早结束任务，而在工作未达标时宣布完成。

工作解耦 + 渐进式进展 + 交接上下文

• 参考源2方案 - Anthropic 25年的Blog

• 初始化 Agent（Initializer agent）：负责设置环境，并将整个大项目拆解为多个具体的功能点（Features），然后创建一个进度追踪文件（Progress tracking file）。

• 编码 Agent（Coding agent）：一次只处理一个功能点。每完成一个模块就提交一次 Git commit，并为下一个接手的 Coding agent 留下清晰的产出物（Artifacts）。

方案不足

Context Anxiety

• 随着上下文窗口（Context window）被逐渐填满，模型不仅会失去连贯性，它的行为模式也会发生实质性的改变，模型会试图过早地结束对话，会匆忙跳过必要的步骤，在任务根本没有完成的情况下，强行宣布事情已经做完了（见于Sonnet4.5，Opus4.5无相关倾向）。

• 缓解（上下文压缩）：对对话进行总结，腾出更多可用的上下文空间，但只能推后并不能解决问题。

• 根除（上下文重置）：总结不能重置模型的状态，所以需要进行上下文重置。即新窗口 -> 读取进度文件中的最新功能 -> 测试之前构建的功能 -> 构建当前特定任务 -> 完成后触发结构化交接（Structured handoffs） -> 重启动下一个 Agent。

Poor Self-Evaluation

• Agent 倾向于自信地赞扬自己的作品，尽管以人的标准而言并不够好。

• 主观任务设计较差：在客观任务（如编写后端代码）中，可以通过 Linter、类型检查器、回归测试等确定性工具来进行验证。但在主观任务（如前端界面设计、图形的视觉设计、法律分析的专业性）中，不存在绝对的“对与错”。

• AI Slop：Claude 对一些典型AI风格，平淡的的前端设计，在自己评价中打高分。进而引出一种需求 - 让主观质量变得可被打分与评估

对抗性评估 - 面向主观质量评估的方案

• 解决AI乐观的自我评估和主观任务难以量化的问题，以 GAN（生成对抗网络）的思路作对抗性评估（Adversarial Evaluation）系统。

• 生成器 Agent（Generator Agent）：负责实际干活，编写代码、创建前端内容。

• 评估器 Agent（Evaluator Agent/QA Agent）：用来刁难生成Agent，给出标准分数，并将反馈通过循环（Feedback Loop）发回给生成器进行迭代（分数，怎么打出来的）。这两者之间的交互迭代提升最终质量。

• 原则一：让主观质量变得可被评分（Make Subjective Quality Gradable）
放弃直接问“这个设计漂亮吗？（Is this design beautiful?）”这种模糊的问题。取而代之的是，提供一套设计原则，并询问“这是否遵循了我们的设计原则？”。在前端设计的案例中，设定了四个维度的具体评分标准：
• 设计质量（Design quality）：整体是否连贯。
• 原创性（Originality）：必须避免 AI 生成的刻板印象。
• 工艺（Craft）：排版、间距、对比度等技术执行力。
• 功能性（Functionality）：核心功能是否可用。

• 原则二：针对模型的弱点对评分标准进行加权（Weight the Criteria Towards the Model's Weaknesses）
Opus模型在后两项标准上已经表现优异，着重强调的应是另外两个弱项上。因此，在评估的 Prompt 中，加重对通用模式的严厉惩罚，迫使模型承担更多风险，提高“原创性”的权重。

• 原则三：让评估器真实地与输出物进行交互（Let the Evaluator Interact with the Output）
不能仅仅让评估器看静态的代码。团队集成了 Playwright MCP（模型上下文协议），让评估器 Agent 获得了真实测试工具。它可以在浏览器中导航该应用、进行屏幕截图，像真实用户一样去点击和测试，从而给出基于真实反馈的评价。

Anthropic Blog的效果展示

 

单句Prompt完全体架构

• Solo Harness（无控制单体运行）：耗时 20 分钟，花费 $9。结果是：应用看起来像个样子，但根本无法运行，处于完全不可玩的状态。

• Full Harness v1（完整控制系统）：引入了规划器 Agent（Planner agent）将大纲扩展为详细规范，然后按“迭代周期（Sprint - 敏捷开发用词）”执行。每一次 Sprint 都包含生成器与 QA Agent 的标准制定（Contract negotiation，预先定义什么是“完成”）、上下文重置以及结构化交接。耗时 6 小时，花费$200。结果是：构建出了完全跑得通的可用游戏引擎。

• Harness 的“做减法”（Full Stack Harness v2）

• 移除了 Sprint 拆解。（直接一把梭）

• 移除了标准协商。

• 移除了上下文重置（No context resets）（一站到底）。

• 改用持续会话（Continuous session）结合 SDK 内部的上下文压缩。

• 在这个版本中，生成器 Agent 直接一气呵成构建整个应用，而评估器 Agent（QA）只在整个构建周期的末尾运行一次，提供全局审查反馈。

总结

• 寻找最简单的可行解，只在必要时增加复杂性

• 识别并隔离模型的物理与行为边界（Identify Model Bounds）
在设计任何系统前，必须通过极限测试找出模型在当下会表现出的“失效模式”。比如，它是在50k tokens 时开始出现“Context Anxiety”？还是在审查视觉 UI 时会陷入“自我开脱的自我评估”？Harness 的每一个组件（如上下文重置模块、QA Agent），都应该直接且唯一地对应一个已被验证的模型缺陷。

• 构建对抗与补偿机制（Build Compensatory Mechanisms）
针对找出的缺陷，设计具体的脚手架。
• 针对遗忘与焦虑：实施带有结构化交接（Structured handoffs）的强制上下文重置。
• 针对盲目自信与幻觉：切断模型的单体决策权，引入类似 GAN的生成-评估循环。将模糊的主观标准（如“好不好看”）硬性转化为基于检查清单的客观可评分项（如设计质量、原创性、工艺、功能性），并通过赋予评估器真实世界交互工具（如 Playwright 截屏测试）来进行实测。

• 警惕“过期的假设”（Beware of Stale Assumptions）
Harness 中的每一个组件，本质上都是对“模型目前无法独自完成某事”的假设（An assumption about what the model can't do on its own）。随着底层大模型的快速迭代（例如从 Sonnet 到 Opus 的升级），这些旧有的假设会迅速过期（Quickly go stale）。 昨天必须使用的“上下文重置”策略，在今天可能只会徒增系统的延迟和复杂性。

• 定期进行“系统修剪”（Periodic Pruning & Simplification）
开发者可以定期对Harness 进行“破坏性测试（Trial and error of simplification）”。尝试移除现有的补偿机制（例如去掉中间的Sprint阶段、去掉协商机制），观察系统是否崩溃。如果新一代模型在没有这些脚手架的情况下依然能输出相同或更好的结果，就应毫不犹豫地将这部分Harness 砍掉。永远让系统向着更扁平、更连续的单次会话架构（Continuous sessions）靠拢，直到触碰到模型新的极限。

• 重新评估“评估者”的必要性（Re-evaluating the Evaluator）
即使是对抗性评估机制，也不是永恒的。评估器的工作效果完全取决于模型本身的能力。如果你把模型推到了其能力的绝对极限（Stretching the model to its limits），那么一个挑剔的评估器是至关重要的；但如果这个任务完全落在模型的“舒适区（Wheelhouse）”内，引入评估器只会浪费 Token 和时间。