AI 动态速览_2026D234最先出现在AI Weekly。

AI 科技资讯周报 2026W34最先出现在AI Weekly。

先问你一个问题：如果你现在只能装一个 AI Agent，你会选 Codex 还是 WorkBuddy？

先别急着回答。我猜十个人里有八个，其实压根没搞清楚这两个东西到底是干嘛的，就已经开始纠结了。

这篇文章，我会带你一步步拆开这两个工具，最后你会发现——这根本就不是一道选择题。

第一步：先搞清楚你在跟谁打交道

很多人不知道，Codex 已经不是几个月前那个 Codex 了。

7 月 10 日，OpenAI 干了一件事：把独立的 Codex 桌面应用直接下架，塞进了新版 ChatGPT 里面。现在打开 ChatGPT 桌面端，你会看到三个模式切换：Chat、Work、Codex。

这里插一个知识点：Work 模式是全新的，专门用来干”通用办公”这件事的。翻译一下就是——OpenAI 亲自下场，做了一个对标 WorkBuddy 的东西。

而 WorkBuddy 是什么？腾讯云 CodeBuddy 团队做的桌面 Agent，底子是开源框架 OpenClaw 的商业化版本。上线前先在腾讯内部拉了 2000 多个员工内测，练熟了才对外放出来。目标用户写得明明白白：不懂技术的普通职场人。

看到这里你应该明白了：一个是代码模型努力往外扩，一个是从第一天就是为了办公室里的普通人做的。根不一样，别用同一把尺子量。

第二步：亲自上手试试，门槛差距有多大

我实测了一下两边的上手流程。

Codex 这边：注册 ChatGPT 账号，或者搞一个 API Key，国内用户网络还得自己解决。三步下来，非技术用户基本上劝退了一半。

WorkBuddy 这边：官网下载，微信或者企业微信扫码，登录完直接送 5000 个体验额度。我掐了下表，从点下载到能用，两三分钟。

结论很直接：如果你是技术人，Codex 的门槛不算门槛；如果你是普通职场人，WorkBuddy 的顺滑度是碾压级的。

第三步：真刀真枪比一下能力

这里才是重头戏，别看包装，看实测效果。

编码这条线，我的判断是：Codex（不管走的是 Codex 模式还是新出的 Work 模式）背靠 OpenAI 最新模型，复杂工程这块目前国产模型确实还追不上。你要是天天跟疑难 bug、大工程较劲，这条基本就锁死答案了。

但办公这条线，风水轮流转。WorkBuddy 是照着”写周报、做表格、出 PPT”这些场景专门打磨出来的，模板是现成的，一句话丢进去，直接吐出能用的成果，不用你自己再拼装。

我总结成一句话：Codex 给你的是顶级零件，自己拼；WorkBuddy 给你的是拼好的成品，直接用。

第四步：别忽略安全这个坑

很多人选工具只看能力，不看风险，这是个大坑。

WorkBuddy 用的是沙盒隔离 + 高危指令拦截，涉及删除、修改这种敏感操作会先停下来问你要不要确认。它的多任务其实走的是单线程（省 token），但复杂任务能拆给多个 Agent 并行跑，速度没吃亏。官方自己也说了，现在还在持续迭代，重要操作最好你自己再复核一遍。

Codex 权限也能设，但灵活是要付代价的——你得自己搞清楚它在哪个目录干活，要不要审批。一旦手滑，破坏半径可能比 WorkBuddy 大得多。

想省心，选 WorkBuddy；愿意为更大自由度多操点心，选 Codex。这是取舍，不是对错。

第五步：看看谁更懂”接地气”

WorkBuddy 把企业微信、QQ、飞书、钉钉全打通了，你人在外面，手机说一声就能远程操控电脑干活，配合内置 MCP 协议和上百个”专家”技能包，国内职场人天天用的工具链，它基本都接上了。

Codex 过去这块生态偏国外那一套，这次冒出来的 Work 模式，某种程度上就是在补这个短板。但目前看，跟 WorkBuddy 在国内生态里扎得深不深比，还是有明显差距。

最后一步：把结论摆到你面前

拆到这里，答案已经很清楚了，我直接给你结论：

• 天天写代码、啃复杂工程 → Codex（或者新 Work 模式）
• 日常写文档、做表格、出 PPT，不想折腾 → WorkBuddy
• 网络受限、技术小白 → WorkBuddy，扫码就能用
• 代码和办公两头都沾 → 两个都装，按场景切换就行

所以回到开头那个问题：Codex 和 WorkBuddy，你该选哪个？

我的答案是——这根本不是同一道题。一个是代码工具，一个是办公工具，你只是需要先搞清楚自己每天真正在跟什么打交道，答案自然就出来了。

别再纠结 Codex 和 WorkBuddy了，看完这篇你就有答案最先出现在AI Weekly。

DeepSeek Harness 是深度求索推出的开源 Agent 框架，核心理念 “一切皆插件”，通过 Model + Harness = Agent 的公式，让模型负责思考、框架负责执行，支持 Web/CLI/SDK/ 插件四种入口，可自由替换模型、自托管部署，适合有开发能力、需要定制化 Agent 的团队；与腾讯 WorkBuddy、字节 Trae Work、阿里 Qoder Work、OpenAI Codex 等闭源产品相比，它是唯一完全开源、模型可换的框架路线，但当前仍为 0.1.0 早期版本，定制门槛较高。

DeepSeek-Harness-从入门到精通【PDF下载】最先出现在AI Weekly。

它不优化模型本身，而是优化模型运行的环境。核心哲学八个字：人类掌舵，智能体执行（Human Steer, Agent Execute）The

Harness一词来自马具——缰绳、马鞍、嚼子——这是一套引导强大但不可预测的动物的完整装备。harness工程不是去削弱 AI 的能力，而是为它打造一套黄金缰绳，让它跑得又快又稳。

Harness Engineering是一门设计和维护控制系统，以规范AI Agent如何感知环境、选择行动及验证输出的学科。它与单纯的提示工程（Prompt Engineering）和模型选择有本质区别，两者共同作用，才能构建真正的智能体：Agent = Model + Harness。

对于Agent基础设施，模型质量已成为基本门槛，而Harness才是真正的差异化因素。随后Martin Fowler引入了“Guides（引导）”和“Sensors（传感器）”的分类法，将Harness组件标准化为前馈控制和反馈控制两类，并迅速成为行业标准The

在技术架构中，Harness不仅仅是代码或编排逻辑，它是一个包含引导（System Prompts、AGENTS.md文件）、传感器（Evals、验证循环）以及数据上下文层（Data Context Layer）的完整控制系统。其核心价值在于它解决了80%的Agent项目无法投入生产的难题，将原本不可靠的模型输出转化为可生产级别的行为。

Harness Engineering 正在成为 AI Agent 开发圈的高频词。它解决的核心问题是：决定 Agent 运行的天花板，到底在哪里？

今天这篇文章就来系统梳理 Harness Engineering 的核心概念和工程方法。

1. Harness 到底是什么？
2. 为什么瓶颈不在模型而在 Harness？
3. Harness 的分层设计如何让 Agent 稳定可控？
4. 从零搭建 Harness 的行动清单The

Harness 核心概念

Harness 到底是什么？

一句话：Agent = Model + Harness。

Harness Engineering 不是某一家公司的方案，而是整个行业正在经历的范式转移The

Harness 就是大模型之外的一切——系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、钩子中间件、反馈回路、约束机制。大模型本身只是能力的引擎，只有通过 Harness 把状态、工具、反馈和约束串起来，它才真正变成一个 Agent。

打个比方：大模型是 CPU，Harness 是操作系统。CPU 再强，OS 拉胯也白搭。你买了最新款 芯片，装了个崩溃不断的系统，体验还不如老芯片配稳定的 OS。

为什么需要Harness

AI 工程范式经历了三次跃迁：

要理解驾驭工程为何重要，需要先看清楚智能体是怎么一步步走到现在的。

• Prompt Engineering —— 对大模型的指令/技巧
• Context Engineering —— 给大模型看的地图
• Harness Engineering —— 整个运行系统和环境及约束

Agent 常见失败模式

业界ai工程师们在长时间运行 Agent 的过程中，总结了三种典型的翻车姿势，正是harness工程要解决的核心痛点。

此外，智能体还有一个高风险特性：它非常擅长模式复制（上下文的锅）The代码库里有什么模式，它就一味地复制并可能放大问题——包括坏模式的蔓延和架构漂移，高危操作的触发。这意味着不加约束的 Agent 会以惊人的速度积累技术债务The

Harness 与传统框架的关系

Harness 不是 SDK、脚手架或 Agent 框架的替代品，而是位于它们之上的一层：

传统框架解决的是如何构建 AI 智能体，而harness层解决的是完全不同的问题：智能体如何可靠地运行The

大模型正在逐渐吸收框架约 80% 的功能（智能体定义、消息路由、任务生命周期……），但剩余 20%——持久化、确定性重放、成本控制、可观测性、错误恢复——正是驾驭层存在的价值。

Harness 和 Prompt/Context Engineering 是什么关系？

三者不是并列关系，而是嵌套关系。更重要的是，每一层解决的是完全不同的问题：

简单任务里，提示词最重要——你把话说清楚就行；依赖外部知识的任务里，上下文很关键——你得把正确的信息喂进去；但在长链路、可执行、低容错的真实商业场景里，Harness 才是决定成败的东西。一线团队的重心都放在了 Harness 上。

Harness 包含哪些组件？

理解 Harness 的最好方式，不是直接看它包含什么，而是看大模型做不到什么。不管大模型看起来多能干，本质就是一个文本（或图像、音频）进、文本出的函数。

大模型做不到的，就是 Harness 要补的：

把这些“大模型做不了但你希望 Agent 能做到”的事情一个个补上，就得到了 Harness 的核心组件。可以 把这件内容拆解为五个子纬度：文件系统（持久化）、Bash 执行（通用工具）、沙箱环境（安全隔离）、记忆机制（跨会话积累）、上下文压缩（对抗衰减）。

Harness 的四大护栏

综合 OpenAI、Anthropic、LangChain 和 Martin Fowler 的实践，Harness 可以归纳为四个核心组件，即四道”护栏”：

护栏一：上下文工程（Context Engineering）——新员工手册

就像给新员工一本详细的工作手册，AGENTS.md 是 AI 智能体进入代码仓库时看到的第一份指南。但这不是一本静态的 又臭又长的说明书——因为上下文是稀缺资源，过多的指导反而会挤掉任务、代码和相关文档的空间，变成陈旧规则的坟场。

更好的做法是：提供一个稳定、小巧的入口点，然后教 Agent 根据当前任务按需检索和拉取更多的上下文。Mitchell Hashimoto 的 Ghostty 项目 AGENTS.md 里每一行都对应一个历史 Agent 失败案例——文档是活的反馈循环，不是静态制品。

护栏二：架构约束（Architecture Constraints）——缰绳

严格的层级依赖大模型：
Types → Config → Repo → Service → Runtime → UI
下层不能反向依赖上层。所有架构规则被编码为自定义 Linter 规则，违反即 CI 阻止合并——无论代码是人写的还是 AI 写的。
有个关键细节：Linter 的错误信息本身也是上下文工程。它不只说你违反了规则 X，而是解释为什么这个规则存在、正确做法是什么，这样 Agent 读到错误后就能自我理解并修正，不需要人类介入。

护栏三：反馈循环（Feedback Loop）——智能体审智能体

传统开发中，人类工程师负责代码审查（Code Review）。在驾驭工程中，这个工作变成了智能体对智能体的方式：Codex 在本地审核自身更改，请求额外审查，循环往复直到通过。
反馈循环中的钩子可以运行预定义的测试套件，并在失败时带着错误信息循环回到模型，或者提示模型独立评估其代码。如果 AI 写的测试用例通过了带有 Bug 的代码，Harness 就会判定测试无效，强迫它重新思考测试边界。

护栏四：熵管理（Entropy Management）——垃圾回收

随着时间推移，软件系统会逐渐混乱（熵增），技术债务会积累。可以采用持续小额偿还的策略，而不是等问题严重时集中处理——他们把这个方法形象地称为垃圾回收，并认为技术债务就像高息贷款The
具体措施：定期运行后台 Codex 任务扫描偏差、更新质量等级、发起针对性重构 PR。此外还有一个专门的 Doc-gardening Agent（文档园丁代理），在后台自动扫描文档与代码之间的不一致，发现过时内容就自动提交 PR 修复——Agent 为 Agent 维护文档。

Harness 的六层体系

上面对组件的理解是“缺什么补什么”的思路。但如果从系统设计的角度看，一个成熟的 Harness 其实有清晰的层次结构——六层体系，觉得这个框架把 Harness 的全貌描绘得比较完整：

可以类比成给一个新手员工搭建的完整工作环境。

• L1 是岗位说明书（告诉 ta 该关注什么），
• L2 是办公工具（给 ta 用什么干活），
• L3 是标准操作流程（按什么步骤做事），
• L4 是项目管理系统和笔记本（怎么记住做过的事），
• L5 是质检流程（怎么检验做对了没有），
• L6 是红线规则和应急预案（什么事绝对不能做、出了事怎么补救）。

这个六层架构最大的价值在于——它不是简单的功能堆叠，而是一个从“定义边界”到“兜底恢复”的完整闭环。附录中一线团队的实践也印证了这一点：他们的做法都可以映射到这六层里。

注意：不要试图一开始就搭齐六层。从 L1（信息边界）和 L6（约束与恢复）入手，这两层投入产出比最高。L1 决定了 Agent 知道该干什么，L6 决定了它搞砸了能不能拉回来。中间的层次随着项目复杂度增长逐步补齐。

智能体瓶颈不在模型而在 Harness

说实话，第一次看到这个结论的时候我也觉得反直觉——不是应该等更强的模型出来就好了吗？但数据确实不支持这个想法。OpenAI、Anthropic、Stripe、LangChain、Can.ac 的实验数据指向同一个结论：基础设施才是瓶颈，而非智能水平。

常见误区：很多团队一遇到 Agent 表现不好，第一反应是“换更强的模型”或“调整提示词”。但 Can.ac 的实验证明，同一模型只换了工具调用格式，效果就能差十倍。瓶颈大概率不在模型智能水平，而在 Harness 的基础设施质量。

LangChain 那边也印证了这个结论：他们优化了 Agent 运行环境（文档组织方式、验证回路、追踪系统），在 Terminal Bench 2.0 上从全球第 30 名升到第 5 名，得分从 52.8% 提升到 66.5%。模型没换，Harness 换了。

一个值得注意的发现：
LangChain 还指出了一个 model-harness 耦合问题——当前的 Agent 产品（如 Claude Code、Codex）是模型和 Harness 一起训练的，这导致一种过拟合：换了工具逻辑后模型表现会变差The
他们在 Terminal Bench 2.0 排行榜上观察到，Opus 在 Claude Code 中的 Harness 下的得分，远低于它在其他 Harness 中的得分。结论是：”the best harness for your task is not necessarily the one a model was post-trained with”——为你的任务选择 Harness 时，不要被模型的默认 Harness 束缚。

为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。

就像高速公路上的护栏——正是因为有护栏，你才敢开到最大马力。

上下文不是越多越好

Dex Horthy 观察到一个现象：168K token 的上下文窗口，用到大约 40% 的时候，Agent 的输出质量就开始明显下降。

智能体工作流流程是失败率

Anthropic 在自己的实践中也碰到了类似的问题，他们叫“上下文焦虑”：Sonnet 4.5 在上下文快填满时会变得犹豫，倾向于提前收工——哪怕任务还没做完。光靠压缩不够，他们最终的做法是直接清空上下文窗口，但通过结构化的交接文档把关键状态留下来（详见附录中 Anthropic 的 context resets 策略）。

你的目标不是给 Agent 塞更多信息，而是让它在任何时候都运行在干净、相关的上下文里。一线团队的实践都围绕着“渐进式披露”和“分层管理”在做，背后的原因就是这个 40% 阈值。

工程视角：在生产环境中监控上下文利用率是第一优先级。建议设置 40% 阈值告警——当 Agent 的上下文占用超过这个比例时，就应该触发上下文压缩或任务交接。等到 Agent 已经变蠢了再处理就晚了。

Harness搭建从哪里入手？

综合一线团队的实践经验（详见附录），梳理了一个按优先级的行动路线。你不需要一开始就把所有东西都搞齐，先把 P0 做了效果就会很明显。

P0：不用犹豫，立即可以做

常见误区：很多团队把 AGENTS.md 当成“超级 System Prompt”来写，恨不得把所有规则塞进一个文件。结果上下文窗口被撑爆，Agent 反而更蠢了。正确做法是像 OpenAI 一样——AGENTS.md 只当目录用（约 100 行），详细规则放在子文档中按需加载。

P1：P0 做完之后，可以考虑这些

P2：有余力再考虑

Harness 的各个阶段

面试准备要点

Harness Engineering 相关的高频面试问题整理在下面，方便你快速回顾：

基础概念

架构设计

实战方案

还没有答案的问题

Harness Engineering 是一个快速发展的领域，仍有许多未解的问题。了解这些“不知道”同样重要——面试时能展现你的思考深度。

绿地项目和棕地项目是软件工程里的经典比喻：

• 绿地项目（Greenfield）：从零开始的新项目，没有历史包袱。就像在一片空地上盖房子，想怎么设计都行。
• 棕地项目（Brownfield）：在已有代码库上改造，有历史架构、技术债、遗留逻辑的约束。就像在老旧城区搞翻新，到处是管线不能随便动。

OpenAI、Anthropic、Stripe、Hashimoto 这些成功案例，全部是在全新项目上从零搭 Harness。但现实中绝大多数团队面对的是已经跑了多年的代码库——怎么把 Harness 引入一个十年历史、没有架构约束、到处是技术债的项目？目前没有任何公开方法论。

Conclusion

一句话概括 Harness Engineering 做的事情：承认模型有边界，然后把边界之外的需求一个个工程化地补上。

有一句话我特别认同：模型决定了系统的上限，Harness 决定了系统的底线。

在简单任务中提示词最重要，在依赖外部知识的任务中上下文很关键，但在长链路、可执行、低容错的真实商业场景中，Harness 才是 AI 稳定落地的前提条件。

如果只记一句话：模型决定上限，Harness 决定底线。与其纠结选哪个模型，不如先把 Harness 搭好。

值得注意的是，Harness Engineering面临的最大挑战并非代码缺陷，而是数据质量问题。数据显示27%的Agent项目失败源于数据质量，而非模型或Harness架构本身。这通常表现为Schema Drift（模式漂移）或Lineage（血缘关系）过时，即Harness向Agent提供的数据环境已发生改变，导致其行为失准。

为了解决这一痛点，现代Harness Engineering强调构建受治理的数据层（Governed Data Layer）。通过企业数据图谱（Enterprise Data Graph）提供的主动血缘追踪、认证信号和漂移检测，可以显著提升Agent的准确性。实践表明，使用受治理数据层的团队，其SQL准确性提升了38%。

目前，Harness Engineering已从单纯的软件工程问题转向数据工程与软件工程的交叉领域。它要求团队不仅关注代码逻辑，更要关注数据的可信度和实时性。随着AI Agent在企业中的广泛应用，掌握Harness Engineering已成为构建可靠AI系统的必经之路。

附录：一线团队实战案例

OpenAI、Anthropic、Stripe、Mitchell Hashimoto、Martin Fowler，这五个团队/个人的实践从不同角度揭示了 Harness 设计中容易被忽略的问题。放在一起看会更有感觉——你会发现大家遇到的坑和总结出的经验，惊人地一致。

OpenAI：三个人、五个月、一百万行、零手写代码

先看数据：

比数字更有意思的是他们总结出来的五大方法论。

给 Agent 一张地图，而不是一本千页手册

OpenAI 的 AGENTS.md 只有大约 100 行，作用类似于目录，指向 docs/ 目录下更深层的设计文档、架构图、执行计划和质量评级。这是渐进式披露的实际运用——先把最关键的信息放进来，需要什么再加载什么。

就像你到一个新城市，不需要把整本旅游指南背下来。给你一张简明的地图（核心规则），然后告诉你“想了解这个景点的详细信息，翻到第 X 页”就够了。

渐进式披露的一个具体实现：Agent Skills。Agent Skills 的核心机制就是“元数据常驻，正文按需加载”——每个 Skill 只在上下文中保留简短的名称和描述（几十个 Token），详细规则和执行流程只在触发时才动态注入推理上下文。这本质上和 OpenAI 的 AGENTS.md 当目录用是同一个思路，只不过 Skills 把这个模式进一步标准化了。详细可参考：。

架构约束不能写在文档里，必须靠工具强制执行

他们给每个业务领域定义了固定的分层结构：

Types → Config → Repo → Service → Runtime → UI

依赖方向不能反过来。怎么保证？自定义 Linter 加结构测试。违反了就报错，报错消息里不光告诉你哪里错了，还直接告诉你怎么改。Agent 在被纠错的同时就被“教会”了正确的做法。

OpenAI 原话：If it cannot be enforced mechanically, agents will deviate.——文档中记录约束是不够的；如果不能机械化地强制执行，Agent 就会偏离。

可观测性也是给 Agent 看的，不只是给人看的

他们把 Chrome DevTools Protocol 接入了 Agent 运行时，Agent 能自己抓 DOM 快照、截图。日志、指标、链路追踪都通过本地可观测性栈暴露给 Agent。这样一来，“把启动时间降到 800ms 以下”就从一个模糊的愿望变成了 Agent 可以自己测量、自己验证的目标。

熵不会自己消失，必须主动对抗

一开始团队每周五花 20% 的时间手动清理 AI 生成物中的低质量代码。后来这事被自动化了——后台 Agent 定期扫描，找文档不一致、架构违规和冗余代码，自动提交清理 PR。清理的速度跟上了生成的速度，才能可持续地跑下去。

写在 Slack 里的知识，对 Agent 来说等于不存在

写在 Slack 讨论或 Google Docs 中的知识对 Agent 来说等于不存在。所有团队知识都作为版本控制的制品放置在仓库中。

工程视角：OpenAI 自己也说了，这个结果“不应该被假设为在缺少类似投入的情况下可以复现”。他们的五大方法论每一项都需要大量前期投入，不要指望直接复制。但其中的思维方式（地图式文档、机械化约束、熵管理）是可以在任何规模上立即采用的。

Anthropic：从上下文焦虑到 GAN 式三智能体架构

Anthropic 在这个方向上有两个值得细看的实践，它们从不同角度揭示了 Harness 设计中容易被忽略的问题。

用 16 个 Agent 写了个 C 编译器，发现了什么？

Nicholas Carlini 用大约两周时间，跑了 16 个并行 Claude Opus 实例，大约 2000 个 Claude Code 会话，产出了一个 GCC torture test 通过率 99% 的 C 编译器。

这个项目里几个 Harness 设计决策很有意思：

• 日志不往控制台打：全部写进文件，用 grep 友好的单行格式（ERROR: [reason]），主动控制上下文污染。
• 测试不全部跑：每个 Agent 只跑随机 1-10% 的测试子集，但子采样对单个 Agent 是确定性的（同一次运行里每次都跑同样的子集），跨 VM 是随机的（不同 Agent 跑不同子集）。这样集体覆盖了全部测试，而单个 Agent 不会花几个小时在测试上打转。
• Agent 角色专业化：随着项目成熟，Agent 承担了专门角色——核心编译器工作、去重（LLM 生成的代码经常重新实现已有功能）、性能优化、代码质量和文档。

Carlini 后来说了一句很到位的话：“我必须不断提醒自己，我是在为 Claude 写这个测试框架，不是为自己写。”——Harness 的设计目标是让 Agent 高效工作，不是为了人类方便。

Anthropic 为什么要借鉴 GAN 的思路？

Anthropic Labs 团队在 2026 年 3 月发布了一个受 GAN（生成对抗网络）思路启发的三智能体架构（原文用的是”Taking inspiration from GANs”，是借鉴思路，不是真正的对抗训练）：

Planner（规划者）→ Generator（执行者）⇄ Evaluator（评估者）

• Planner：拿到 1-4 句话的产品描述，扩展成完整的产品规格，被要求“在范围上要大胆”。
• Generator：按功能一个一个做”Sprint”，每个 Sprint 有明确的完成标准。
• Evaluator：用 Playwright MCP 实际点击运行中的应用，按产品设计深度、功能性、视觉设计、代码质量等维度打分。

这个架构要解决两个核心问题：

打分标准本身也有讲究：前端设计方面，设计质量和原创性的权重被故意调得比功能性和代码质量更高——因为模型倾向于做出“功能齐全但长相平庸”的东西，权重调整是在引导它往更难的方向使劲。

遇到上下文焦虑，不是压缩而是重启

前面提到 Anthropic 发现 Sonnet 4.5 在上下文快填满时会出现“上下文焦虑”——变得犹豫、提前收工。光靠压缩上下文不够，他们的最终做法叫做 context resets（上下文重置）：

1. 当一个 Agent 的上下文接近饱和时，先把当前任务状态、已完成的工作、待办事项结构化地提取出来
2. 启动一个全新的“干净” Agent，把结构化的交接文档交给它
3. 新 Agent 从干净的状态继续工作

这就像程序碰到内存泄漏时的解法——你不去手动释放每一个内存块（对应上下文压缩），而是直接重启进程，从检查点恢复状态。虽然粗暴，但在长任务场景里，一个干净重启的 Agent 比一个塞满了历史信息的 Agent 表现好得多。

这个思路跟 Carlini 在编译器项目里的做法本质上是一回事——他跑了 2000 个 Claude Code 会话，每个会话都是独立的、从干净状态开始。只不过 Anthropic 把这个“重启-恢复”过程正式化和结构化了。

两种配置的成本对比：

更复杂的任务差距更明显——用 Full Harness 做一个浏览器里的音乐制作工作站（DAW），跑了将近 4 小时花了 $124.70，产出了一个带有编曲视图、混音台和播放控制的可用程序。

但有一个重要发现：当他们把模型从 Sonnet 4.5 换成 Opus 4.6 后，Sprint 机制可以完全移除，Evaluator 从每个 Sprint 检查变成了最后只做一次检查。

Anthropic 对此总结得非常精辟：“Every component in a harness encodes an assumption about what the model can’t do on its own, and those assumptions are worth stress testing.”（Harness 中的每个组件都编码了一个关于“模型靠自己做不到什么”的假设，而这些假设值得定期压力测试。）

Anthropic 的结论：”The space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves.”——模型越强，不是不需要 Harness 了，而是 Harness 的设计空间转移到了新的位置。这意味着你需要定期简化 Harness——随着模型能力提升，之前必要的保护机制可能已经冗余了。

Stripe：每周 1300+ 个 PR，全程无人值守，他们是怎么做到的？

Stripe 的 Minions 系统代表了另一个极端——高度自动化的无人值守模式。开发者发一条 Slack 消息，Agent 就从写代码到跑 CI 到提 PR 全部搞定，人只在最后审查。每周超过 1300 个完全由 Minions 生产的、不含任何人写代码的 PR 被合并。

说实话，这个数字第一次看到的时候有点震惊。下面拆一下他们的架构。

Stripe 的编排设计思路很有意思。不是把所有事情都交给 Agent 判断，也不是全部走确定性流程，而是一个混合状态机——该确定的地方确定（跑 lint、推送代码），该灵活的地方灵活（实现功能、修 CI 错误）。就像一条工厂流水线，有些工位是机器人固定动作，有些工位是人工灵活处理。

核心理念：”What’s good for humans is good for agents.”——为人类工程师投资的 Devbox、工具链和开发者体验，在 Agent 上也直接产生了回报。Agent 不是需要一套单独的基础设施，而是应该跟人类工程师用同一套，只是一开始就得被当作一等公民来设计。

Agent 底层是 Block 的开源 goose 项目的一个 fork，针对无人值守场景做了定制化。

Mitchell Hashimoto：不跑多 Agent，一个人的 Harness 工程学

Mitchell Hashimoto（Vagrant、Terraform、Ghostty 终端模拟器的作者）的实践路线和 Stripe 完全相反——他坚持一次只跑一个 Agent，保持深度参与。他明确说“我不打算跑多个 Agent，也不想跑”。

他的六步进阶路线：

AGENTS.md 的正确用法：Ghostty 项目里的 AGENTS.md，每一行都对应着一个过去的 Agent 失败案例。这不是写完就扔的静态文档，而是一个持续积累的防错系统——Agent 犯了一个新类型的错误，就加一行规则，以后就不会再犯了。

Birgitta Böckeler 对 Harness 的系统化梳理

Birgitta Böckeler（Thoughtworks 的 Distinguished Engineer）在 Martin Fowler 网站上发表了对 OpenAI 实践的结构化分析。她的视角比较独特——不关注具体怎么做，而是关注这些做法可以归为哪几类、缺了什么。她把 Harness 组件归为三类：

Böckeler 还提了几个挺有前瞻性的判断：

1. Harness 将成为新的服务模板——大多数组织只有两三个主要技术栈，未来团队可能会从一组预制 Harness 中选择，就像今天从服务模板实例化新服务一样。
2. 棕地项目改造是最大挑战——所有公开成功案例都是绿地项目，将有十年历史、没有架构约束的代码库引入 Harness Engineering 是更复杂的问题。Böckeler 把它比作“在从未用过静态分析工具的代码库上运行静态分析——你会被警报淹没”。她还提出了一个关键概念”Ambient Affordances”：强类型语言天然有类型检查作 sensor，清晰的模块边界方便定义架构约束，Spring 这样的框架抽象了很多细节——环境本身的结构特性决定了 Harness 能做多好The
3. 功能验证体系几乎缺席——大量讨论了架构约束和熵管理，但功能正确性验证是被严重忽视的领域。Böckeler 对此有一个更尖锐的观察：很多团队只是让 AI 生成测试套件然后看它是否绿色通过，但这”puts a lot of faith into AI-generated tests, that’s not good enough yet”——用 AI 生成的测试来验证 AI 生成的代码，本质上是在用同一双眼睛检查自己的作业。

Buy Me a Coffee

Harness Engineering 是什么？从 Prompt 到 Agent 生产级落地的完整指南最先出现在AI Weekly。

Buy Me a Coffee

AI科技资讯周报_2026W33最先出现在AI Weekly。

AI 动态速览_2026D225最先出现在AI Weekly。

AI 动态速览_2026D223最先出现在AI Weekly。

AI科技资讯周报_2026W32最先出现在AI Weekly。

今日新闻热点 – 0806最先出现在AI Weekly。