

最近看到一篇文章，大意是说 Anthropic 发现模型在长上下文中会"偷懒"——系统性地缩减思考深度，而通过调节模型内部的情绪状态（比如让它"冷静下来"）就能改善表现。文章由此推论：既然模型自己能变好，那 Harness Engineering 是不是快过时了？

评论区吵得很热闹。有人说作者混淆了概念，有人说这结论太傲慢，也有人觉得工程界解决的问题根本不是模型优化能替代的。

作为一个正在开发 Harness 框架（prax-agent）的人，我想从实践角度聊聊这个问题。不是要打谁的脸，而是觉得这个话题值得认真讨论。

## 先搞清楚：Harness Engineering 到底管什么

讨论一个东西会不会过时，得先搞清楚它是什么。

原文最大的问题是把 Harness Engineering 和 Context Engineering 混为一谈了。这两个东西有交集，但职责完全不同：

**Context Engineering** 管的是"什么进入上下文"——RAG 检索、记忆召回、上下文压缩、prompt 组装。它关心的是信息的质量和相关性。

**Harness Engineering** 管的是"进入上下文的信息是否被遵从、结果是否可验证、行为是否可控"。它关心的是执行的可靠性和安全性。

打个比方：Context Engineering 是"给厨师准备好食材"，Harness Engineering 是"确保厨师按食谱做、菜品经过质检、厨房不会着火"。你说食材越好，厨师是不是就不需要质检了？显然不是。

拿我在 prax-agent 里实现的中间件体系来说，Harness 的职责分成五层：

- **Guard 层**（优先级最高）：权限控制、循环检测。模型要执行 `rm -rf /` 或者陷入无限工具调用？在这层就被拦下来了。
- **Cache 层**：prompt 缓存优化、模型降级回退。Claude 挂了自动切 GPT，GPT 挂了切 GLM。
- **Inject 层**：重新注入待办事项、运行边界提醒、验证修复引导。模型"忘了"该做什么？这层帮它想起来。
- **Extract 层**：从对话中提取持久化记忆——事实、知识三元组、问题-解决方案模式。
- **Eval 层**（优先级最低）：质量门禁、弱模型输出优化。代码改了就自动跑检查，不过就不算完。

这五层中间件，没有一层是在"管上下文该放什么"。它们管的是：模型的行为是否安全、信息是否被遵循、结果是否可验证。

所以原文说"模型优化能替代 Harness"，其实是搞错了 Harness 的核心职责。

## 模型"偷懒"恰恰是 Harness 要解决的问题

原文引用的那个研究——模型在长上下文中会偷懒——这个观察本身是对的。我在实践中天天跟这个问题打交道。

模型"偷懒"的具体表现包括：

1. **跳步执行**：明明还有三个待办事项，模型处理完一个就说"全部完成了"
2. **重复无效操作**：同一个工具调用反复执行，期待不同的结果
3. **草率收场**：遇到困难就绕过去，而不是想办法解决
4. **忽视约束**：上下文里明确写了"必须先跑测试再标记完成"，模型直接跳过

但原文说这是"情绪问题"，通过调节模型的内部状态就能解决——这个归因太简单了。

模型"偷懒"至少有四个层面的原因：

**指令遵循能力的结构性缺陷**。模型天然倾向于"快速了结"。这不是情绪问题，是训练目标的副产品——模型被优化为生成"看起来合理的回复"，而不是"严格执行复杂指令"。

**注意力机制的物理局限**。Lost in the Middle 问题是真实存在的——长上下文中间的信息，模型就是容易忽略。你再怎么调节"情绪"，注意力窗口的数学特性不会变。

**无状态特性**。模型每次调用都是全新的。上一轮对话里得出的关键结论，这一轮就不记得了。这不是偷懒，是架构决定的。

**自我验证能力不足**。模型写了一段代码，它自己没法编译、没法跑测试。它只能"猜"代码是对的。

Prax 怎么应对这些问题？不是靠劝模型"别偷懒"，而是靠工程机制：

- **LoopDetectionMiddleware**：跟踪每个工具的调用次数，超过 5 次就注入警告，强制模型换策略。不是跟模型讲道理，是设硬限制。
- **TodoReminderMiddleware**：待办事项滚出上下文窗口了？在下一轮对话自动注入回来。模型"忘了"没关系，Harness 帮它记着。
- **VerificationGuidanceMiddleware**：验证失败了？把错误信息转化成聚焦的修复提示，而不是让模型自己琢磨怎么办。
- **QualityGateMiddleware**：代码改了就自动跑质量检查。过了才算完，不过就继续改。模型说"我觉得没问题"不算数，编译器说了算。

你看，Harness 不是在"控制上下文"，而是在"治理行为"。模型确实在偷懒，而 Harness 正是为了应对偷懒而存在的。说模型不偷懒了 Harness 就过时了，就好像说"员工能力强了就不需要制度了"——这不符合任何组织管理的经验。

## 模型内部优化能做什么、不能做什么

我不否认模型优化的价值。过去两年模型进步很大，确实有些以前需要 Harness 兜底的场景，现在模型自己就能处理好了。

但模型优化有明确的边界。用 Prax 的实践来说，至少有五类问题是模型再怎么优化也解决不了的：

### 1. 跨会话记忆

模型是无状态的。每次 API 调用，对模型来说都是第一次见面。

上周你跟 Agent 聊了三个小时，定了一套代码规范。今天你开了新会话，它什么都不记得。这不是模型"偷懒"，是它的架构决定的——每次调用就是一个独立的推理过程。

Prax 的方案是三层记忆系统：会话级记忆（Episodic）管当前对话上下文，长期记忆（Semantic）存跨会话的事实和知识，问题-解决方案模式（Compound）记录"遇到 X 问题用 Y 方案解决过"。这些记忆存在外部，在新会话开始时注入。

模型优化能解决吗？不能。你可以把上下文窗口扩到 100 万 token，但用户不可能每次都把历史对话全贴进去。记忆必须外部持久化，这是架构问题，不是能力问题。

### 2. 权限控制

模型不能自我约束危险操作。

你让 Agent 帮你整理项目文件，它可能觉得"这个目录看起来没用，删了吧"。你让它调用 API，它可能把认证 token 打进日志。这些不是恶意行为，是模型对"什么操作是危险的"缺乏工程判断。

Prax 的 PermissionMiddleware 基于 ExecutionPolicy 做三级权限控制：只读模式只允许安全工具，工作区写入模式限制在指定目录内操作，全权限模式才放开所有操作。每个工具调用在执行前都要过权限检查。

模型优化能解决吗？不能。安全问题不能依赖模型"自觉"。就像你不会因为程序员技术好就不做代码审查一样。权限控制必须是外部强制的。

### 3. 质量门禁

模型不能自我验证代码正确性。

它可以生成代码，可以"审查"代码，但它没法真的编译和运行。它说"这段代码应该能跑"，但"应该"两个字在生产环境里毫无意义。

Prax 的 QualityGateMiddleware 在模型修改代码后自动触发质量检查——编译、测试、lint，都是真实执行。通过了才继续下一步，没通过就把错误信息反馈给模型，让它修。

模型优化能解决吗？不能。代码是否正确，只有真实执行才知道。这是工程问题，不是推理问题。

### 4. 工具编排

模型不能管理复杂的工具依赖关系。

A 工具调用失败了，应该重试还是换 fallback？B 工具依赖 A 的输出，A 还没返回怎么办？并发执行三个工具，怎么处理竞态条件？

Prax 的 StreamingToolExecutor 处理工具的流式执行、错误恢复、轨迹捕获。ModelFallbackMiddleware 管理 Claude → GPT → GLM 的降级链。这些不是"提示词"能搞定的，需要真实的状态管理和异常处理。

模型优化能解决吗？不能。工具编排是系统工程问题，需要进程管理、网络通信、状态同步。模型是一个推理引擎，不是一个操作系统。

### 5. 可观测性

模型不能提供结构化的日志、指标和追踪。

Agent 跑了 20 轮工具调用，哪一步出了问题？总共花了多少 token？哪些工具调用是无效的？这些信息对调试和优化至关重要，但模型自己产生不了。

Prax 的每一层中间件都有结构化日志输出，工具调用有完整的轨迹记录，包括耗时、输入输出、成功与否。这些数据让你能复盘 Agent 的行为，找到优化点。

模型优化能解决吗？不能。可观测性是运维基础设施，需要日志收集、指标聚合、链路追踪。这些东西和模型能力完全是两个维度。

所以，模型优化和 Harness 工程是互补的，不是替代关系。模型变强了，Harness 不是变得没用了，而是可以少干一些"保姆式"的事，把精力放在更高层次的治理上。

## Harness 的未来不是消失，而是进化

模型在进步，Harness 也得跟着变。不变的是核心职责——治理、验证、持久化、编排——变的是实现方式。

基于 Prax 的实践和我对这个领域的观察，我认为 Harness 有四个进化方向：

**从"硬约束"到"软引导"**

早期的 Harness 像交通信号灯——红灯停，绿灯行，没有商量余地。未来的 Harness 更像领航员——根据模型的意图和上下文动态调整干预力度。模型能力强了，Harness 就少管；模型表现异常了，Harness 就加强干预。Prax 的 Intent Gate 就在往这个方向走。

**从"单模型"到"多模型编排"**

现在大多数 Agent 框架还是单模型模式——一个 Claude 或 GPT 干到底。但生产环境越来越多地需要多模型协作：主模型做推理，小模型做分类，专用模型做代码生成。Harness 负责路由、调度、结果合并。

**从"会话级"到"项目级"记忆**

当前的记忆大多停留在会话级别。未来的 Harness 需要管理跨会话、跨项目的知识图谱。你在项目 A 踩过的坑，换到项目 B 时 Harness 应该能提醒你。Prax 的 Compound Memory 就是在做这件事。

**从"被动执行"到"主动治理"**

OpenClaw 给了我一个很大的启发。它不是等用户发指令才干活的——它有 Heartbeat 和 Cron 机制，能 24 小时常驻、主动扫描、定时执行。Harness 不只是"约束"Agent，更是"赋能"Agent。让 Agent 从被动的"工具"变成主动的"同事"。

Harness 的终局不是消失，而是变得越来越"透明"——你感受不到它的存在，但它一直在确保一切可靠运行。就像你今天用手机，不会意识到操作系统在帮你管理内存、调度进程、保护安全——但没有操作系统，App 一个都跑不起来。

## 给从业者的建议

如果你正在做 AI Agent 相关的工作，不管是开发框架还是应用 Agent，有几点建议：

**不要把 Harness 当成"临时补丁"**。有些人觉得 Harness 是模型还不够好的权宜之计，等模型足够强了就可以扔掉。这是误解。Harness 之于 Agent，就像操作系统之于应用程序。应用程序可以变得更强大，但它不会替代操作系统。

**从权限控制开始**。如果你的 Agent 能执行任何工具调用而没有权限检查，这是最大的安全隐患。先做权限控制，这是最基础也最重要的 Harness 能力。

**逐步加入质量门禁**。Agent 改了代码就自动跑测试，生成了文案就自动检查合规性。不要依赖模型"自觉"保证输出质量，用工程手段验证。

**最后考虑记忆和编排**。这些是锦上添花的能力，前提是安全和质量已经有了保障。

工具方面，除了我自己的 Prax 之外，LangGraph、Semantic Kernel 也是值得关注的框架。选择时重点看三个维度：中间件机制是否灵活、记忆管理是否完善、工具编排是否健壮。

## 回到争议本身

原文的观察有价值——模型确实在进化，确实在变得更强。Anthropic 关于模型情绪状态的研究也很有意思，值得业界关注。

但"Harness 过时"这个结论是站不住的。模型优化解决的是"模型能做什么"的问题，Harness 解决的是"怎么确保模型可靠地做"的问题。这两个层面的工程永远会共存。

评论区有人说得好：好马配好鞍。马变了，鞍也要跟着变，但你不能说马跑得快了就不用鞍了。

Harness 不会过时。它只是被误解了。

最近看到一篇文章，大意是说 Anthropic 发现模型在长上下文中会"偷懒"——系统性地缩减思考深度，而通过调节模型内部的情绪状态（比如让它"冷静下来"）就能改善表现。文章由此推论：既然模型自己能变好，那 Harness Engineering 是不是快过时了？

别急着给 Harness 判死刑，它管的根本不是上下文

Harness Engineering 不会过时，它与模型优化是互补关系而非替代关系。

人工智能

架构设计

开发工具

Harness Engineering与模型优化是互补关系，而非替代关系。Harness负责AI模型的行为治理、权限控制、质量验证和跨会话记忆等核心功能，这些是模型架构本身无法解决的问题。随着模型能力提升，Harness将从硬约束转向软引导，从单模型扩展到多模型编排，实现更智能的AI治理。安全可靠的大模型应用离不开Harness工程的持续进化。

中间件

编译器

路由

Agent

2026采购季 | AI焕新·智启新局

message-queue-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Harness Engineering与模型优化是互补关系，而非替代关系。Harness负责AI模型的行为治理、权限控制、质量验证和跨会话记忆等核心功能，这些是模型架构本身无法解决的问题。随着模型能力提升，Harness将从硬约束转向软引导，从单模型扩展到多模型编排，实现更智能的AI治理。安全可靠的大模型应用离不开Ha...

别急着给 Harness 判死刑，它管的根本不是上下文-腾讯云开发者社区-腾讯云

别急着给 Harness 判死刑，它管的根本不是上下文

别急着给 Harness 判死刑，它管的根本不是上下文

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐