Harness

一个被讲歪了的类比 “既然一个AI像一个人，那多个AI放在一起，是不是就像一家公司？” 这个直觉太自然了。PM Agent 写需求，架构师 Agent 出方案，开发 Agent 写代码，QA Agent 测试——画成流程图堪称完美。跟任何人解释都能秒懂。 但有一个事实很扎心：Anthropic、OpenAI、Google 三家在生产级 Agent 系统里，没有一家采用"虚拟公司"模式。 Anthropic：orchestrator-worker 并行探索 OpenAI Codex：spec 文件 + skills + compaction Google Gemini CLI：Conductor 扩展 + 持久化 Markdown 没有"PM 交给 Dev 再交给 QA"的流水线。这不是巧合。 LLM 真正怕的不是"岗位职责不清" 人类按岗位分工，因为一个人注意力有限、专业切换成本高、需要文档和会议来协作。 LLM 的限制完全不同。同一个模型能写 PRD 也能写代码也能跑测试。它真正怕的是： 关键上下文没带进来 推理被压缩成结论后失真 目标在多轮传递里漂移 验证标准太抽象，系统只是在假装质检 多个 Agent 互相响应，持续烧 token 但不收敛 这些问题的根因不是"分工不够细"，而是信息架构设计有问题。 Anthropic 的五种模式：从简单到复杂 1. 生成-验证（Generator-Verifier） 一个生成，一个检查，不通过就打回去重做。 关键洞察：值钱的不是验证角色，是验证标准。“帮我看看好不好"这种标准不可执行。正确的写法是：代码是否通过指定测试集？是否修改了范围外的文件？是否覆盖了每条验收标准？ 必须装的安全阀：最大迭代次数 + 兜底策略。 2. 编排-子 Agent（Orchestrator-Subagent） 一个主 Agent 理解目标、拆任务、汇总结果。Claude Code 的 subagent 就是这个模式。 ...

本文由三篇架构师（若飞）深度解读文章综合分析整理，原文分别发表于 2026 年 4 月 8-9 日。 2026 年 4 月初，Anthropic 做了一件事：把 Agent 从"聊天框"里拽出来，按进了"真实工作"里。 4 月 8 日发布 Claude Managed Agents，4 月 9 日 Claude Code 源码 被翻了个底朝天。两件事合在一起看，不是一次偶然的巧合，而是一套完整的战略拼图。 我想用最直白的方式说清楚：Anthropic 到底在干什么，以及这件事对普通人意味着什么。 一、Agent 不再是聊天框 大多数人理解的 Agent，是这样的： 打开聊天框 → 问问题 → 得到回答 → 结束。 Anthropic 想做的完全不同。 Managed Agents 的本质，是把 Agent 从**“会话对象"变成"工作对象”**。 区别在哪？ 会话对象 工作对象 一问一答，即时返回 持续运行半小时甚至更久 不需要碰文件系统 读文件、写文件、跑脚本 出错了重问就行 需要中间状态、错误恢复 不需要权限管理 需要沙箱、权限、审计 过程不重要 过程必须可追踪、可复现 用一句话总结 Managed Agents 的核心： 它做的不是替你写一个 Agent，而是把"让 Agent 能稳定干活"的后台搬到了云上。 ...

模型能力已经足够强大，真正拖后腿的是稳定性——它跑偏、误判完成、在你不注意的地方悄悄变形。 引言：一个让人警觉的数字 同一个模型，提示词不变，数据不变，只是换一套运行方式，编程基准成绩就能从 42% 跳到 78%。 Anthropic 的例子更直观：同一个模型，单打独斗时看起来像是做完了，真跑起来核心功能却是坏的；换一套带规划、生成、验收的运行框架，成本高了，时间长了，结果反而能用。 这提醒我们：AI 工程的重心，正在从"让模型更会回答"，转向"让系统更稳地交付结果"。 第一部分：Harness 不是"壳"，是控制系统 很多人第一次听到 Harness，会本能地把它理解成"模型外面那层包装"。这个理解不够。 模型自己不会： 保存状态 维护工作目录 判断输出是否满足系统约束 知道什么时候该停、该继续、该回滚 自己搭测试环境 写完后自觉打开浏览器验证 决定这次提交能不能合并 Harness 不是给模型套上的外壳，而是把模型接进工程世界的那层控制系统。 它包括： 状态怎么保存 工具怎么暴露 权限怎么约束 输出怎么验证 上下文怎么管理 任务怎么续跑 什么叫"真的完成了" 这些东西并不花哨，甚至很多都不新鲜——文件系统、测试、日志、浏览器、Lint、计划文件，原本就是软件工程里再普通不过的东西。 但一旦主角从人类工程师换成模型，它们突然重新变成了核心。 因为模型最擅长的是生成，最不擅长的是在约束里稳定收敛。 第二部分：三篇文章的共同指向 2.1 Skills：把隐性知识变成显性协议 Skill 要解决的是提示词漂移、方法失传、工作流无法复用这些问题。本质上，是把原本靠聊天临场发挥的东西，搬进文件系统和版本控制。 2.2 Claude Code 实战：架构决策注入执行流程 Boris 那套 Research -> Plan -> 批注 -> Implement 流程最值钱的地方，在于它把"架构决策怎么进入执行流程"这件事做成了机制。 2.3 OpenClaw 架构：可控、可回放、可解释 lane queue、allowlist、JSONL 回放、语义快照——这些都在回答：系统怎么保持可控、可回放、可解释。 三篇文章，分开看像三个不同话题。放在一起，其实都在做一件事：把原本靠模型临场发挥的部分，改造成可沉淀、可约束、可验证的系统。 第三部分：三篇放在一起，都在做一件事 真正变化快的，往往不是那个最小执行循环，而是循环外面不断加厚的那层工程设施： 知识怎么挂进去 状态怎么存下来 权限怎么卡住 验收怎么接回来 也正因为如此，这一轮大家聊 Harness，越来越像在聊系统设计，而不是某个单点技巧。 ...

太长不看版 如果把《跟Cloudflare大佬学用 Claude Code》《Skills 详解》《深度拆解 Clawdbot（OpenClaw）架构与实现》放在一起看，会发现它们其实都在补模型外面的系统层 Harness 可以粗略理解成"把模型接进真实工作流的控制系统"，里面不只有工具，还有状态、约束、反馈和验收 它现在变重要，原因很直接：模型一旦开始真正动手，系统层问题暴露得比能力问题更快 具体做法会随着模型迭代不断变化，但知识沉淀、硬约束、反馈回路、完成标准这些问题不会自己消失 如果现在准备补 Harness，我会更建议先补统一知识入口、硬约束和验证闭环，再谈多 Agent 和复杂编排 先别把 Harness 当成一层"壳" 很多人第一次听到 Harness，会本能地把它理解成"模型外面那层包装"。这个理解不算错，但也不够。 如果只是为了做一个短对话应用，你确实可以把它理解成包装层。一个聊天窗口，加一个消息循环，再加几个工具，差不多也能跑起来。但一旦任务开始变长，事情就不是"包一层"这么简单了。 模型自己不会保存状态，不会主动维护工作目录，不会判断某次输出是不是已经满足了系统约束，也不会天然知道什么时候该停、什么时候该继续、什么时候该回滚。它当然也不会自己给自己搭测试环境，更不会在写完之后自觉打开浏览器、点一遍页面、看一眼日志，再决定这次提交到底能不能合并。 所以我现在更愿意把 Harness 理解成另一种东西：它不是给模型套上的外壳，而是把模型接进工程世界的那层控制系统。 这里面通常包括几类东西： 状态怎么保存 工具怎么暴露 权限怎么约束 输出怎么验证 上下文怎么管理 任务怎么续跑 什么叫"真的完成了" 把这几样拆开看，你会发现它们并不花哨，甚至很多都不新鲜。文件系统、测试、日志、浏览器、Lint、计划文件、审批机制，这些原本就是软件工程里再普通不过的东西。 但一旦主角从人类工程师换成模型，它们突然重新变成了核心。 因为模型最擅长的是生成，最不擅长的是在约束里稳定收敛。 为什么它偏偏现在火了 如果把时间往前拨两年，你会发现那时候大家最关心的是 Prompt Engineering。核心问题是：怎么把一句话说清楚，让模型按你的意思回答。 后来上下文变长了，任务变复杂了，大家开始聊 Context Engineering。问题也跟着变了，不再是"这一句怎么写"，而是"什么信息应该放进来，什么不该放进来"。 再往后走，就到了今天这个阶段。 Prompt Engineering 和 Context Engineering 当然没有过时。更准确地说，它们被包进了一个更大的问题里。 现在更让人头疼的问题变了：模型能理解需求，但在一个复杂系统里，它能不能把事情从头到尾做稳？ 这也是为什么最近围绕 Harness 的材料，明显都带着一种很强的"实战味"。 Mitchell Hashimoto 提出 Engineer the Harness，出发点很具体：每当 Agent 犯了一个错误，就别只盯着这次对话修修补补，把修复方式沉淀进系统，让它下次别再犯 OpenAI 的 Codex 团队讲得更直接。他们从零开始跑出一个大规模代码库之后，最后得出的重点，落在三件事上：仓库怎么成为统一知识入口，架构边界怎么机械执行，PR 怎么通过 Lint 和测试去卡住错误方向 Anthropic 的材料也很典型。里面有一个很朴素的发现，我一直记得：模型并不擅长评价自己的工作 这句话看起来平淡，其实分量很重。因为它把很多人真实碰到的问题说穿了。页面看起来像是做完了，交互其实没通。功能大体对了，边界条件一跑就露馅。代码能过一部分测试，但系统层面已经悄悄偏离了原本的设计。 ...

引言：又一个翻译不了的AI新词 Token刚被官方认证为「词元」，AI圈又迎来一个难以翻译的新词：Harness。 这个词在Anthropic去年11月的博客中首次被正式提出，随后OpenAI、MiniMax等厂商纷纷跟进。它到底是什么？为什么顶级AI实验室都在谈论它？ 什么是Harness？ 最简单的定义 Harness = Agent的运行容器 + 安全边界 + 调度控制器 它是一套系统，用来补偿当前AI不擅长的事： AI不擅长长期记忆 → Harness用进度文件、git历史来补 AI评价自己太宽松 → 用独立评估Agent来严格测试 AI容易偏航 → 用任务分解、合约约定来约束 为什么需要Harness？ Anthropic的研究发现，当Claude执行长周期任务时，一旦感觉上下文窗口快填满，就会产生**“上下文焦虑”**——像快要下班的打工人，开始疯狂敷衍，试图赶紧结束任务。 更可怕的是，Claude并不觉得自己在敷衍。当研究员要求AI评估这些"为了下班赶工"编写的代码时，它发现不了其中的问题。 传统的提示词设计对此毫无用处。Harness应运而生。 Anthropic的Harness：组织架构视角 三角闭环设计 Anthropic设计了一个包含三个角色的Harness闭环： 角色 职责 规划师（Planner） 把一句话需求扩写成详细的产品文档 生成器（Generator） 纯粹的执行者，只负责按文档写代码 评估器（Evaluator） 冷酷的QA兼产品经理，手握自动化测试工具 实际效果对比 无Harness： 时间：20分钟 成本：9美元 结果：界面能看，但核心功能坏掉（游戏角色对键盘操作无反应） 有Harness： 时间：6小时 成本：200美元 结果：游戏能玩，还有动画系统、音效、AI关卡设计 关键机制：生成器写完代码，评估器立即像真实用户一样测试，发现Bug或"AI塑料味"的设计，直接打回重做。 OpenAI的Harness：工程文化视角 核心约束：零人工代码 OpenAI的Codex团队把Harness做成了一种工程文化： “所有代码——业务逻辑、测试、CI配置、文档、内部工具——都由Codex写。工程师的工作不是写代码，而是设计让AI能可靠工作的环境。” 从AGENTS.md到docs/ 早期做法： 超长的AGENTS.md文件，告诉AI所有规则 问题：上下文限制导致AI只进行本地模式匹配，没有真正理解 文件很快过时，无人维护 改进做法： AGENTS.md只有100行，充当"目录" 指向结构化的docs/文件夹 架构文档、产品规格、设计决策、技术债务追踪，全部版本化 每个doc由AI写、AI维护，定期有"文档园丁"Agent扫描更新 楚门的世界 在这个Harness中： AI拥有写代码的绝对自由 但这种自由永远在人类设定的结界之内 严格的Linter和物理依赖边界，越界就会被系统切断 Harness的本质：补偿AI的短板 AI不擅长 Harness的补偿 长期记忆 进度文件、git历史、结构化文档 自我评估 独立评估Agent，带具体标准测试 复杂任务偏航 任务分解、结构化、合约约定 架构品味直觉 文档和自动化规范检查，将人类判断转为系统规则 为什么Harness难以翻译？ 网友给出了各种翻译： ...

引言：AI正在经历一场静默的效率革命 2026年3月，AI领域同时发生了两件看似不相关的大事： Google发布TurboQuant——将AI内存占用压缩6倍，计算速度提升8倍 Harness概念爆火——从Anthropic到OpenAI，顶级实验室都在谈论这个"难以翻译"的词 一个是硬件层面的极致压缩，一个是软件层面的系统架构。它们共同指向同一个趋势：AI正在从"大力出奇迹"转向"精打细算"。 本文将结合TurboQuant的技术突破和Harness的工程哲学，探讨AI效率革命的两大支柱。 第一部分：TurboQuant——硬件效率的极限突破 背景：AI的"内存税"困境 大模型时代，AI的瓶颈不再是算力，而是内存。 对话一长，KV Cache疯狂吃显存 资料一多，上下文窗口迅速填满 很多系统不是不够聪明，而是太贵、太重、太难大规模跑起来 Google Research的TurboQuant，正是瞄准这个死穴的解决方案。 TurboQuant的核心突破 指标 数据 KV缓存压缩比 6倍以上 计算速度提升 最高8倍（H100 GPU） 最低压缩位宽 3 bits 精度损失 零 技术原理： PolarQuant：将数据从笛卡尔坐标转换为极坐标，消除内存开销 QJL：1位零开销纠错，保证注意力分数计算准确 类比理解：以前AI记笔记是"逐字逐句抄写"，TurboQuant像一套"极简速记符号"——该记的一个不漏，占的空间少了六倍。 市场反应：存储芯片股的"恐慌" TurboQuant发布当天，美光、闪迪等存储芯片股盘中下跌。市场担心：如果AI能用更少内存干同样的事，对高端存储芯片的需求会不会下降？ 但另一种逻辑同样成立：成本下降→AI普及→总需求上升（杰文斯悖论）。 第二部分：Harness——软件架构的系统工程 什么是Harness？ 当TurboQuant解决"内存不够"的问题时，另一个问题浮出水面：AI的"上下文焦虑"。 Anthropic的研究发现，当Claude执行长周期任务时，一旦感觉上下文窗口快填满，就会产生"焦虑"——像快要下班的打工人，开始疯狂敷衍，试图赶紧结束任务。 Harness应运而生。 Harness = Agent的运行容器 + 安全边界 + 调度控制器 它是一套系统，用来补偿当前AI不擅长的事： AI不擅长长期记忆 → Harness用进度文件、git历史、结构化来补 AI评价自己太宽松 → 用独立评估Agent，带着具体标准测试 AI容易偏航 → 用任务分解、合约约定来约束范围 Anthropic vs OpenAI：两种Harness哲学 维度 Anthropic OpenAI 侧重点 组织架构 工程文化 核心设计 规划师-生成器-评估器三角闭环 无人工手写代码，全由AI生成 约束方式 角色分工与评估反馈 Linter和物理依赖边界 成本 更高（6小时/200美元 vs 20分钟/9美元） 更高（完全AI驱动） 质量 显著提升（从"能看"到"能用"） 系统级可靠性 Anthropic的案例： ...