7 篇文章带有标签 “Anthropic”

罗福莉 2026年4月6日

两天前，Anthropic 切断了第三方客户端（Harnesses）使用 Claude 订阅的通道——这并不令人意外。三天前，MiMo 推出了其 Token 计划（Token Plan）——这是一个我投入了大量精力去设计的方案，也是我认为在实现合理的算力分配和智能体客户端开发方面一次严肃的尝试。将这两件事结合起来，我有以下几点思考：

Claude Code 的订阅制是一个专为平衡算力分配而设计的精美系统。 我的猜测是——它并不赚钱，甚至可能在亏本，除非他们的 API 利润率高达 10-20 倍，但我对此深表怀疑。虽然我无法严密地计算出第三方客户端接入所带来的损失，但我近距离观察过 OpenClaw 的上下文管理——它真的很糟糕。在单个用户查询中，它会把一轮轮低价值的工具调用作为独立的 API 请求发送出去，每个请求都携带长达 100K 以上 Token 的长上下文窗口——即便有缓存命中，这也是极大的浪费，在极端情况下还会推高其他查询的缓存未命中率。其单次查询的实际请求次数最终比 Claude Code 自身框架高出数倍。折算成 API 定价的话，真实成本恐怕是订阅价格的几十倍。这不仅是一个差距，而是一个巨大的黑洞。 像 OpenClaw/OpenCode 这样的第三方客户端依然可以通过 API 调用 Claude——它们只是不能再薅订阅制的羊毛了。

Harness Engineering 是 AI 时代的全新软件工程学科 —— 设计和实现系统来约束、引导、验证和修正 AI 智能体的行为，让强大但不可预测的 AI 模型能够可靠地完成复杂任务。

• 核心概念
• 核心原理
• 技术架构
• 企业实践案例
• 最佳实践指南
• 实施路线图
• 未来趋势

Harness Engineering 是设计和实现系统的学科，这些系统能够：

1. 约束：定义 AI 智能体可以做什么（架构边界、依赖规则）
2. 告知：告诉智能体应该做什么（上下文工程、文档体系）
3. 验证：检查智能体是否正确完成任务（测试、 linting、CI 验证）
4. 修正：当智能体出错时引导其自我修复（反馈循环、自我修正机制）

类比：AI 模型是一匹强大但无方向的骏马，Harness 是缰绳、马鞍和全套马具，人类工程师是骑手。没有 Harness 的 AI 是开阔场地里的纯种马——速度快、令人印象深刻，但完全无法用来完成任何实际工作。

AI 行业正在达成一个共识：底层模型的重要性远低于围绕它的系统。LangChain 的实验最能证明这一点：他们的编码智能体在 Terminal Bench 2.0 上的得分从 52.8% 提升到 66.5%，从排名前 30 跃升至前 5 —— 完全没有改动模型，只是优化了 Harness。

Harness Engineering，是在AI大模型时代，以确定性系统外壳约束概率性AI行为，通过上下文工程、架构约束、熵管理三位一体，构建可长期稳定运行的AI Agent系统，推动软件工程从代码实现转向系统设计，成为下一代AI工程化的核心范式。

在人工智能，特别是大型语言模型（LLM）能力迅速发展的时代，软件开发领域正经历一场深刻的范式转移。传统以代码为中心的工程方法正在被一种以语言为中心的新范式所取代。这一新范式将工程设计的核心原则，如控制、可靠性和可扩展性，应用到了人与AI的交互界面上。本报告将深入探讨这一新兴领域，提出“Harness Engineering”（驾驭工程）这一术语，用以描述其背后的系统性原则、核心实践、行业案例及未来挑战。报告旨在为软件工程师、技术领导者及行业观察家提供一个全面的框架，以理解并应用这一即将定义未来技术格局的关键技术。

在深入探讨Harness Engineering之前，必须首先理解它所处的演化脉络。它并非一个凭空出现的概念，而是对已有AI工程实践的一次系统性整合与升华。它标志着行业的焦点从与AI模型的“单次对话”转向了构建一个让AI能够“持续可靠工作”的完整系统。

Harness Engineering（驾驭工程）被定义为一个新兴的工程学科，其核心目标是设计和实现一套围绕AI Agent（人工智能体）的完整系统，该系统由约束（Constrain

在智能体（Agentic）编程的前沿领域，Harness 设计（测试与运行框架设计）是性能表现的关键。以下是我们如何推动 Claude 在前端设计和长时间运行的自主软件工程中进一步突破的实践。

作者：Prithvi Rajasekaran，Labs 团队成员

发布日期：2026年3月24日

• Harness design for long-running application development

在过去的几个月里，我一直致力于解决两个相互关联的问题：如何让 Claude 产出高质量的前端设计，以及如何让它在无需人工干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计能力和长时间运行编程智能体 Harness 方面的尝试。当时，我和同事们通过提示词工程（Prompt Engineering）和 Harness 设计，能够将 Claude 的性能提升到远高于基准线的水平——但两者最终都遇到了瓶颈。

为了实现突破，我寻求了一种能够跨越两个完全不同领域的全新 AI 工程方法：一个由主观审美定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GAN）的启发，我设计了一种包含**生成器（Generator）和评估器（Evaluator）**智能体的多智能体结构。要构建一个能够可靠且具审美感地对输出进行评分的评估器，意味着首先要开发一套标准，将“这个设计好吗？

这是一篇由 Anthropic 发布的技术博客文章，探讨了如何通过构建有效的“脚手架”（harnesses）来提升长时运行智能体（long-running agents）的工作效率。

发布日期：2025 年 11 月 26 日

• Effective harnesses for long-running agents

智能体在跨越多个上下文窗口工作时仍面临挑战。我们从人类工程师身上汲取灵感，为长时运行的智能体构建了一个更有效的脚手架。

随着 AI 智能体（agents）能力的不断提升，开发者正越来越多地要求它们承担复杂的任务，这些任务往往需要持续数小时甚至数天的工作。然而，让智能体在多个上下文窗口（context windows）中保持连贯的进度仍然是一个悬而未决的问题。

长时运行智能体的核心挑战在于：它们必须在离散的“会话”中工作，且每个新会话开始时都没有之前发生的记忆。想象一下，一个软件项目由实行轮班制的工程师负责，而每位新来的工程师对上一班发生的事情毫无记忆。由于上下文窗口是有限的，且大多数复杂项目无法在单个窗口内完成，智能体需要一种方法来弥合多次编码会话之间的差距。

我们开发了一种方案，使 Claude Agent SDK 能够有效地跨多个上下文窗口工作。

🤯 最近看了Anthropic关于如何构建高效AI智能体的文章，简直是醍醐灌顶！💡 原来最成功的秘诀不是堆砌复杂技术，而是简单可组合的模式！

Anthropic的大佬们和超多团队合作后发现，很多时候我们并不需要“全自动”的智能体，理解不同模式的适用场景超重要！

👇 先搞清楚俩概念：

• 工作流 (Workflow): 就像搭积木🧱，是预设好的、一步步执行的LLM和工具协调流程。适合任务清晰固定的场景。
• 智能体 (Agent): 像有个聪明的小脑袋🧠，LLM自己决定怎么走、用什么工具、怎么完成任务。适合需要灵活应变、动态决策的复杂场景。

🌟 什么时候用，什么时候不用？

别一上来就想搞个超级Agent！ Anthropic建议从最简单的方案开始：优化单个LLM调用 + 检索/上下文就够了！只有简单方案搞不定时，才考虑更复杂的系统。简单工作流提供稳定可预测性，而智能体提供灵活性，但要权衡成本和速度哦！

⚠️ 框架迷思！

市面上框架一大堆（LangChain, Bedrock Agents...），能帮你快速入门。但Anthropic提醒：它们可能增加抽象层，让调试变难，还可能诱惑你过度设计！💥 划重点： 建议直接用LLM API开始，很多模式几行代码就能实现！用框架也要搞懂底层原理，别被绕晕！

🧱 AI智能体的构建模块：

基础是增强型LLM，能自主调用工具、记忆、检索。

模型	模型名称	价格（MTok）	能力
Opus	claude-3-opus-20240229	Input: $15<br>Output:$75	处理复杂的分析、多步骤的长期任务，以及更高阶的数学和编码任务
Sonnet	claude-3-sonnet-20240229	Input: $3<br>Output:$15	适用于高效、高吞吐量的任务
Haiku	claude-3-haiku-20240307	Input: $0.25<br>Output:$1.25	执行轻量级操作，速度领先行业

• MTok = million tokens.(百万 Token)
• 所有 Claude 3 模型都支持视觉和 200,000 个 Token 上下文窗口。

• Meet Claude
• Build with Claude