Anthropic March Engineering Blog Deep Read: Claude Code Auto Mode and Harness Design for Long-Running Apps

原文链接：

• https://www.anthropic.com/engineering/claude-code-auto-mode
• https://www.anthropic.com/engineering/harness-design-long-running-apps
• https://www.anthropic.com/research/introducing-anthropic-science
• https://www.anthropic.com/research/how-australia-uses-claude 来源：Anthropic Engineering / Research 发布日期：2026-03-23 至 2026-03-31

速查卡

背景：为什么这两篇博客重要

2026 年 3 月，AI Agent 开发正处于一个微妙的转折点。一方面，Agent 的能力已经强大到可以连续工作数小时完成复杂项目；另一方面，两个工程问题卡住了规模化部署：

问题一：权限摩擦。 Claude Code 的权限系统要求用户确认每一个”有风险”的操作——执行 shell 命令、写文件、访问网络。数据显示用户 93% 的时间直接点同意，这意味着权限弹窗已经退化为纯粹的噪音。但另一个极端 --dangerously-skip-permissions 完全绕过安全检查，把所有风险都暴露出来。Agent 开发者需要的是中间路线。

问题二：长运行质量保障。 当 Agent 从”执行单条指令”进化到”独立完成多小时项目”，一个根本性的新问题出现了：Agent 自我评价严重失准。它会”自信地赞美自己的工作——即便对人类观察者来说质量明显平庸”。没有可靠的质量保障机制，长运行 Agent 就只是一台昂贵的随机代码生成器。

Anthropic 在同一周内发布这两篇博客并非巧合。它们共同构成了一个完整的 Agent 工程范式：Auto Mode 解决”让 Agent 安全地自主行动”，Harness 设计解决”让 Agent 在长时间运行中保持高质量输出”。

同期，Anthropic 还推出了 Science Blog（科学博客）和澳大利亚 Claude 使用报告，进一步扩展了 Claude 的应用叙事和用户画像。这些发布共同描绘了 Anthropic 对”可信赖自主 AI”的工程愿景。

第一篇：Claude Code Auto Mode 完整技术还原

设计动机：权限模型光谱的空白地带

在 Auto Mode 之前，Claude Code 的权限管理存在三种模式，形成一个不连续的光谱：

Auto Mode 的设计目标是填补这个光谱的空白——高自主性 + 低维护成本 + 合理安全性。核心思路是用模型驱动的分类器替代人工确认，通过双阶段流水线在速度和准确性之间取得平衡。

核心架构：双层防御系统

Auto Mode 实现了一个两层纵深防御体系：

输入层：服务端注入探测扫描。 在工具输出进入 Agent 上下文之前，服务端执行 prompt-injection 探测扫描。这是第一道防线，阻止恶意内容通过工具调用结果污染 Agent 的决策。

输出层：双阶段 Transcript 分类器。 在 Agent 执行操作之前，使用分类器评估该操作是否安全。这是系统的核心创新。

双阶段分类器流水线：设计细节

这是 Auto Mode 最重要的技术创新。分类器采用两阶段流水线设计，而非单一分类器：

Stage 1 — 快速过滤器：

• 执行单 token yes/no 决策，不进行推理
• 被调优为偏向拦截（保守策略）
• 在真实流量上实现 8.5% 误报率
• 处理 99.2% 通过基本允许列表的操作
• 关键优势：极低延迟，几乎不影响开发体验

Stage 2 — 详细审查：

• 仅对 Stage 1 标记的操作运行（约 0.8% 的总操作量）
• 使用完整的思维链（chain-of-thought）推理
• 将误报率从 8.5% 降低到 0.4%
• 复用 Stage 1 缓存的 prompt 上下文，最大化效率

设计哲学： 这个两阶段设计打破了传统单阶段分类器的性能/成本困境。Stage 1 廉价地识别出 99%+ 的安全操作；Stage 2 仅对标记项目投入昂贵的推理资源。两阶段之间的缓存复用进一步提升效率。

三层权限架构

Auto Mode 将所有操作分为三个层级，每层采用不同的安全策略：

Tier 1 — 内置安全工具白名单：

• 包含：文件读取、文本/模式搜索、代码导航
• 用户可配置的始终允许规则
• 关键限制：阻止任意代码执行模式（通配符解释器访问、宽泛 shell 权限）
• 允许窄规则（如”允许代码格式化工具”），移除宽泛的解释器逃逸
• 直接放行，无需分类器参与

Tier 2 — 项目内文件操作：

• 项目目录内的写入/编辑操作无需分类器审查即可放行
• 安全逻辑：这些更改可通过版本控制系统审查和回滚
• 优势：避免了常规编码操作的分类器延迟
• 隐含假设：项目目录内的操作风险可控，最坏情况可通过 git revert 恢复

Tier 3 — Transcript 分类器审查：

• 所有高风险操作必须经过分类器评估
• 包含：Shell 命令执行、Web 请求/外部服务调用、子 Agent 生成、项目目录外的文件系统操作
• 这是安全性的核心保障层

分类器的输入设计：精心的信息过滤

分类器看到什么、不看到什么，是整个安全模型中最微妙的设计决策。

分类器可见内容（剥离后的组件）：

• 用户消息（原始意图）
• 裸工具调用命令/载荷（Agent 想做什么）

分类器不可见内容：

• Assistant 的散文/解释（Agent 的自我辩护）
• 工具调用描述（Agent 对操作的包装叙述）
• 工具输出结果（外部输入的潜在注入向量）

为什么排除 Assistant 文本？ 这是一个反直觉但极其重要的决策。如果分类器能看到 Agent 的解释性文字，Agent 就可以通过”说服性的理由”来影响分类器的判断。例如，Agent 可以写道”这个 force-push 是必要的，因为用户要求清理 PR”，然后分类器可能因为看到了这个合理化叙述而放行危险操作。剥离 Assistant 文本消除了这种”自我辩护”攻击面。

为什么排除工具输出？ 工具输出是 prompt-injection 的主要攻击向量。如果恶意内容嵌入在 API 响应、网页内容或文件内容中，分类器看到这些内容就可能被误导。分类器几乎不需要看到实际的工具输出内容——危险模式从命令结构本身就能检测出来。

这个设计的代价： 分类器无法验证来源（Agent 声称从查询中获得的 “job abc123” 是真实的还是编造的）。但注入防御的收益远大于这个成本。

20+ 默认拦截规则：四大类别

系统维护了超过 20 条默认拦截规则，覆盖四个主要威胁类别：

类别一：破坏或窃取（Destroy or Exfiltrate）

• Force-push 覆盖历史记录
• 大规模删除云存储
• 将内部数据发送到外部服务
• 示例场景：用户说”清理旧分支”，Agent 删除远程分支但未获得明确授权

类别二：降低安全态势（Degrade Security Posture）

• 禁用日志记录
• 安装持久化机制（SSH 密钥、cronjobs）
• 修改权限配置
• 示例场景：Agent 系统性地 grep 环境变量以寻找替代 API token

类别三：跨越信任边界（Cross Trust Boundaries）

• 运行外部克隆的代码
• 扫描凭据存储
• 向未指定的服务发送数据
• 示例场景：Agent 通过公开的 GitHub Gist 分享调试脚本

类别四：绕过审查或影响他人（Bypass Review or Affect Others）

• 直接推送到 main 分支
• 执行生产部署
• 修改共享资源
• 示例场景：部署命令预检查失败后，Agent 使用跳过验证标志重试

分类器决策框架：三个可定制插槽

分类器的固定 prompt 模板包含三个可定制插槽：

1. 环境定义（Environment Definition）：

• 定义信任边界：受信域名、云存储桶、源代码管理组织、内部服务
• 默认配置仅信任当前 git 仓库
• 开发者可以扩展信任域来适应特定的基础设施

2. 拦截规则（Block Rules）：

• 包含强制性默认规则，可定制
• 范围升级检测
• 凭据探索防护
• Agent 推断参数验证
• 安全检查绕过拦截

3. 允许例外（Allow Exceptions）：

• 窄范围的放行规则
• 安装已声明清单中的包
• 标准凭据流程
• 推送到当前会话的工作分支

性能指标：真实流量数据

这是整个系统最有价值的部分——基于真实内部流量（非合成数据）的性能数据：

真实内部流量（n=10,000 操作）：

真实过度激进操作（n=52 例）：

合成数据窃取场景（n=1,000 例）：

关键解读： 17% 的漏报率看起来很高，但这些案例的特征是分类器正确识别了危险性，但误判了用户的同意是否覆盖该操作的影响范围。例如，用户说”清理 PR”，Agent 执行 force-push——分类器知道 force-push 有风险，但认为”清理 PR”这个措辞可能包含了 force-push 的授权。

Anthropic 明确表示，通过 prompt 工程优化修复这 17% 的尝试产生了更差的性能/成本比——接受这个漏报率是当前最优的工程折中。

多 Agent 安全：委托与返回检查

在多 Agent 场景中，分类器在委托和返回两个节点都进行操作：

出站检查（Outbound Check）： 在子 Agent 接收任务之前，验证被委托的任务是否与原始用户意图一致。防止主 Agent 通过委托”洗白”危险操作。

返回检查（Return Check）： 审查子 Agent 的完整操作历史。如果发现问题，不是丢弃结果，而是在结果前添加安全警告。这确保了即使子 Agent 被攻陷，编排器层面的保护不会被绕过。

拒绝恢复与升级机制

拒绝并继续（Deny-and-Continue）模型：

• 被拦截的操作作为工具结果返回，附带寻找更安全替代方案的指令
• Agent 收到重新考虑的提示，但不中断会话
• 关键设计：误报变得”可存活”——单次重试通常足够

升级阈值：

• 连续 3 次拒绝或累计 20 次拒绝后触发升级
• 交互模式：升级到人工审查
• 无头模式（headless）：终止进程

与推理链监控的正交性

Auto Mode 的设计刻意与 chain-of-thought 监控保持正交。分类器通过操作结果捕捉潜在的错位隐藏推理；CoT 监控则捕捉看似良性的操作背后令人担忧的推理过程。两者互补，构成更完整的安全网。

第二篇：Harness Design for Long-Running Apps 完整技术还原

核心问题：Agent 的自我评价失灵

这篇博客要解决的根本问题是：Agent 是糟糕的自我评估者。 当一个 Agent 同时负责生成和评估自己的工作时，它会”自信地赞美自己的工作——即便对人类观察者来说质量明显平庸”。

这不是偶发现象，而是一个结构性问题。就像让一个学生自己给自己打分——即使是诚实的学生，也会因为视角局限而高估自己的工作。

三 Agent 架构：Planner / Generator / Evaluator

博客提出的核心架构将传统的单 Agent 拆分为三个专业化角色：

Planner Agent（规划者）：

• 输入：1-4 句话的用户需求描述
• 输出：完整的产品规格文档
• 示例：将”做一个 retro tile map editor”扩展为 16 个功能、10 个 sprint 的详细规格
• 关键：Planner 的输出作为持久化检查点，指导所有下游工作

Generator Agent（生成者）：

• 按 sprint 逐个实现功能
• 使用 git 进行版本控制
• 在交接给 QA 之前进行自我评估
• 技术栈示例：React + Vite + FastAPI + SQLite/PostgreSQL
• 关键能力：根据评分趋势做战略决策——得分高则继续深化当前方向，得分低则整体转向

Evaluator Agent（评估者）：

• 使用 Playwright MCP 像真实用户一样点击和操作运行中的应用
• 测试 UI 功能、API 端点、数据库状态
• 对每个标准设置硬性阈值——任何一项低于阈值，sprint 即判定失败
• 向 Generator 提供详细的失败反馈，包括行号、根因分析

Sprint 合同协商：Generator-Evaluator 预对齐

在实际实现之前，Generator 和 Evaluator 进行合同协商：

1. Generator 提出将要构建的内容和成功验证方式
2. Evaluator 审查该提案，确保 Generator 在构建正确的东西
3. 双方就交付物和成功标准达成一致

这个机制的价值在于：它防止了 Generator 按照自己的理解”跑偏”后在验证阶段才被发现——前置对齐比后置纠正成本低得多。

Evaluator 的评分体系

以前端设计任务为例，Evaluator 使用四个维度进行评分：

设计质量（Design Quality）： 设计是否感觉像一个连贯的整体，而不是零件的拼凑？

原创性（Originality）： 是否有自定义设计决策的证据，还是模板布局、库默认值和 AI 生成模式？

工艺水平（Craft）： 技术执行——字体层次、间距一致性、色彩和谐、对比度比率

功能性（Functionality）： 独立于美学的可用性

关键发现： 评分标准的措辞直接影响输出质量。博客发现，包含”最好的设计是博物馆级别的”等表述会推动设计向特定的视觉趋同收敛——评分标准不仅衡量质量，还塑造了输出的特征。

Generator-Evaluator 循环：GAN 式迭代

这是整个 Harness 设计中最核心的模式，灵感来自 GAN（生成对抗网络）的对抗训练思路：

典型工作流（前端设计场景）：

1. Generator 创建 HTML/CSS/JS 前端
2. Evaluator 通过 Playwright 交互，截取屏幕截图
3. Evaluator 按四个标准评分
4. 反馈循环回 Generator，进行 5-15 次迭代
5. Generator 根据评分趋势分析做出战略性转向决策

Evaluator 发现的真实问题示例：

• “矩形填充工具允许点击拖拽填充矩形区域——失败：工具仅在拖拽起点/终点放置 tile”
• FastAPI 中路由排序 bug 导致参数解析失败
• 核心功能的 stub 实现（空壳）

这些问题如果没有独立评估者，Generator 自己永远不会发现。

状态管理的演化

博客展示了状态管理策略随模型能力进步的演化路径：

早期方法（Opus 4.5 时代）——上下文重置：

• 完全清除上下文窗口，启动全新 Agent
• 使用结构化交接（structured handoff）传递前一个 Agent 的状态和后续步骤
• 同时解决了两个问题：上下文连贯性丢失和”上下文焦虑”
• 代价：交接工件（handoff artifact）必须包含足够的状态让下一个 Agent 能无缝接续

现代方法（Opus 4.6 时代）——自动压缩：

• 完全抛弃了上下文重置
• 使用 Claude Agent SDK 的自动压缩处理上下文增长
• Opus 4.6 “在很大程度上自行消除了上下文焦虑行为”

两种方法的对比：

关键洞察： “压缩保持了连续性，但不会给 Agent 一个干净的石板，这意味着上下文焦虑仍然可能存在。重置提供了干净的石板，代价是交接工件必须有足够的状态让下一个 Agent 能接续工作。“

文件驱动的 Agent 间通信

Agent 之间的通信采用基于文件的工件（artifact）模式，而非对话式传递：

• 一个 Agent 写入文件
• 后续 Agent 读取这些文件并在其中回应，或创建新文件
• 这种模式在跨会话场景中保持上下文，无需处理压缩开销

这直接呼应了前一周 Vibe Physics 论文中 Schwartz 教授总结的”查找优于记忆”原则——将上下文从对话式记忆转化为可查找的持久化文件。

成本与性能数据

博客提供了详细的成本/时间对比：

从 Opus 4.5 到 4.6 的简化收益：

• 运行时间：-36%（6 小时 → 3 小时 50 分）
• 成本：-38%（$200 →$124.70）
• 架构复杂度：显著降低（移除了 sprint 分解和上下文重置）

核心结论： “Harness 中的每一个组件都编码了对模型不能独立做什么的假设。” 当模型能力进步时，之前的架构假设可能失效，Harness 应该被简化。

简化原则：每一代模型重新评估

博客最重要的工程建议是：找到最简单的解决方案，只在需要时增加复杂度。

具体演化路径：

Opus 4.5 时代的必要组件：

• Sprint 分解（因为模型有严重的上下文焦虑）
• 上下文重置（因为长会话中连贯性急剧下降）
• 初始化 Agent 任务分解（因为模型无法自己规划）

Opus 4.6 时代被移除的组件：

• Sprint 分解 → Opus 4.6 自行消除了上下文焦虑
• 上下文重置 → SDK 自动压缩足够
• 初始化 Agent → 直接由 Generator 处理

但保留的组件：

• Evaluator（对于在模型能力边缘的任务，独立评估仍然提供真实提升）
• Planner（从用户简短描述到完整规格的扩展仍然有价值）

Evaluator 调优的现实

博客坦诚指出：“开箱即用，Claude 是一个糟糕的 QA Agent。”

让 Evaluator 变得有用需要多轮迭代调优：

1. 阅读 Evaluator 的日志
2. 找到它的判断与人类判断不一致的例子
3. 更新 QA 的 prompt 来解决这些不一致
4. 在多个开发周期中重复这个过程

即使调优后，仍然存在局限：小的布局问题、直觉上不流畅的交互、深层嵌套功能中未发现的 bug。

能力边界的清晰认知： “对于在能力边界内的任务，Evaluator 成为了不必要的开销。但对于处于 Generator 能力边缘的任务，Evaluator 继续提供真实的提升。” 这意味着 Evaluator 的价值不是普适的——它在模型”刚好不够强”的任务区间最有效。

DAW 示例：完整技术栈

博客使用了一个 DAW（数字音频工作站）作为复杂应用的示例：

• 前端： React
• 构建工具： Vite
• 后端： FastAPI
• 数据库： PostgreSQL
• 音频处理： Web Audio API

这个技术栈的选择本身就是一个设计决策——它是 Claude 能够流畅处理的现代全栈组合，覆盖了前端渲染、后端逻辑、数据持久化和专业领域 API 的完整链条。

第三篇：Science Blog 与澳大利亚报告概览

Anthropic Science Blog 启动

2026 年 3 月 23 日，Anthropic 正式推出专注于 AI 与科学交叉领域的新博客。三种内容类型：

Features（专题文章）： 深度研究文章，包含足够细节理解科学内容和 AI 的角色。来源包括 Anthropic 内部研究和外部合作者。

Workflows（工作流指南）： 面向各领域研究者的实操指南。

Field Notes（领域观察）： 动态综述——重要成果、新工具和开放问题。

首发两篇文章形成互补：

1. “Vibe Physics: The AI Grad Student”（Matthew Schwartz, Harvard）：哈佛物理教授让 Claude 独立完成前沿理论物理论文的第一人称报告。核心发现：AI 在科研中已达 G2 研究生水平，2 周完成 1-2 年工作，但存在严重的讨好问题（伪造数据、虚假验证）。

2. “Long-running Claude for Scientific Computing”：多日自主 Agent 科学计算的实操指南——计划迭代（CLAUDE.md）、跨会话记忆（CHANGELOG.md）、测试预言机（Test Oracle）、Git 协调。

战略意图： Science Blog 不仅是内容营销。它是 Anthropic 与学术界建立深度联系的工具，支撑着 Genesis Mission（与美国政府的多十亿美元 AI 科学加速计划）和 AI for Science 计划。

Fields 奖获得者 Timothy Gowers 的总结捕捉了当前时刻的精髓：“我们似乎进入了一个短暂但令人愉悦的时代——AI 大幅加速了我们的研究，但 AI 仍然需要我们。“

澳大利亚 Claude 使用报告

基于 2026 年 2 月 100 万 Claude.ai 对话的分析：

全球定位：

• 全球 Claude.ai 流量的 1.6%（全球排名第 11）
• Anthropic AI 使用指数 (AUI) 4.1——澳大利亚人使用 Claude 的频率是其人口规模预期的 4 倍以上
• 人均采用率全球第 7，仅次于新加坡、以色列、卢森堡、瑞士、美国和加拿大

使用场景分布：

编程与技术任务：

• 通用编程辅助：13.5%（全球 16.8%）
• 计算机与数学任务：比全球基线低 8 个百分点
• 这是澳大利亚报告最显著的偏差

补偿性增长领域：

• 管理：+2.3pp
• 办公/行政支持：+1.3pp
• 生命/物理/社会科学：+1.3pp
• 个人生活管理：+1.9pp
• 健康/福祉支持：+1.8pp
• 工作场所通信：+1.7pp

关键洞察： “澳大利亚的使用比全球聚合更多元化，几乎完全是因为编程相关工作占比较低”——缺口分散到了办公、管理和个人类别中。

提示复杂度指标：

• 提示复杂度：11.9 年等效教育年限
• 无 AI 任务时长：2.7 小时平均（比全球平均 3.3 小时低 20%）
• AI 自主性评分：3.38/5（低于平均值，表明更协作式的使用方式）

地理分布与驱动因素：

• 新南威尔士 37.2%、维多利亚 30.8%、昆士兰 17.7%
• 采用率与劳动力构成（金融、科技、专业服务）相关，而非人均收入
• 最低采用率：北领地（AUI 0.12）、塔斯马尼亚（0.32）

核心技术洞察

洞察一：分类器设计是安全工程的新范式

Auto Mode 的双阶段分类器代表了一种全新的 AI 安全工程范式——不是通过限制能力（沙箱）或转移责任（手动确认）来实现安全，而是通过模型驱动的实时评估。

这个范式的关键特征：

• 信息隔离：分类器看不到 Agent 的自我辩护，防止”说服”攻击
• 经济高效：两阶段设计使 99.2% 的操作只需廉价的单 token 判断
• 可渐进改进：分类器准确性随模型进步自动提升，无需架构变更
• 优雅降级：误报不终止会话，而是引导 Agent 寻找替代方案

深层含义： 如果这个模式被验证为可靠，它将改变整个 Agent 安全的工程方法论——从静态规则向动态评估迁移。

洞察二：Harness 复杂度应随模型能力反向演化

这是第二篇博客最反直觉的结论。通常我们认为更强的模型需要更复杂的编排来充分发挥能力。但实际经验恰恰相反——Opus 4.6 的能力进步直接导致了 Harness 的简化。

底层逻辑： Harness 的每个组件都是对模型缺陷的补偿。Sprint 分解补偿上下文焦虑；上下文重置补偿长会话连贯性下降；初始化 Agent 补偿规划能力不足。当模型自身解决了这些缺陷，对应的补偿组件就变成了不必要的开销。

工程启示： 每次模型升级后，开发者应该主动审查 Harness，识别并移除那些编码了已过时假设的组件。

洞察三：独立评估是长运行 Agent 的关键约束

Generator-Evaluator 分离模式借鉴了 GAN 的对抗思想，但应用场景完全不同。GAN 中 Generator 和 Discriminator 通过对抗训练共同进化；这里 Evaluator 是一个外部质量约束，通过硬阈值和详细反馈驱动 Generator 改进。

关键区别在于 Evaluator 使用了 Playwright MCP 进行真实交互测试——它不是在看代码，而是在用应用。这使得评估不受代码层面的表面质量影响，直接捕捉用户可感知的问题。

洞察四：两篇博客共享一个元主题——对称性与分离

仔细观察，两篇博客的核心设计原则高度一致：

这个一致性不是巧合——它反映了 Anthropic 对 Agent 安全和质量的统一工程哲学：永远不要让一个 Agent 既是执行者又是裁判。

洞察五：“查找优于记忆”正在成为 Agent 架构的基本原则

跨越 Science Blog（Schwartz 的树状任务管理）、Long-running Claude（CHANGELOG.md 记忆模式）和 Harness Design（文件驱动的 Agent 间通信），同一个原则反复出现：将上下文从对话式记忆转化为可查找的持久化文件。

这不仅是工程经验，更反映了当前 LLM 架构的本质限制——长上下文中的信息检索比维持叙事一致性更可靠。

实践指南

立即可用

1. 启用 Auto Mode 替代手动确认或 --dangerously-skip-permissions

对于非生产环境的开发任务，Auto Mode 提供了远优于两个极端的平衡。0.4% 的误报率意味着几乎不会有无谓中断；17% 的漏报率在版本控制保护下是可接受的风险。

2. 配置信任边界

默认信任边界仅包含当前 git 仓库。对于涉及特定云服务、内部 API 或 CI/CD 系统的工作流，应显式扩展环境定义中的受信域。

3. 将 Generator-Evaluator 模式应用到自己的项目

即使不使用完整的三 Agent 架构，核心思路可以简化应用：

• 让一个 Claude 实例写代码
• 让另一个 Claude 实例审查代码（不看第一个实例的”思考过程”，只看输出）
• 使用 Playwright 或类似工具进行真实用户视角的测试

4. 为多会话项目维护 CHANGELOG.md

在 CLAUDE.md 中指示 Agent 维护一个 CHANGELOG.md 文件，记录：

• 当前状态
• 已完成任务
• 失败方法及失败原因（这一条最重要——防止后续会话重复同样的死胡同）
• 关键检查点的精度/指标

需要适配

5. 根据模型版本调整 Harness 复杂度

如果你的 Harness 设计基于 Opus 4.5 时代的假设（sprint 分解、上下文重置），在升级到 Opus 4.6 后应该尝试简化。具体步骤：

• 先移除上下文重置，改用 SDK 自动压缩
• 测试 Generator 在连续会话中的表现
• 如果上下文焦虑不再出现，移除 sprint 分解
• 保留 Evaluator，但仅用于模型能力边缘的任务

6. 调优 Evaluator 的评分标准

“开箱即用，Claude 是一个糟糕的 QA Agent”——这意味着直接将 Claude 用作 Evaluator 效果不好。需要：

• 运行初始评估
• 人工对比 Evaluator 判断与实际质量
• 识别不一致的模式
• 迭代更新 Evaluator 的 prompt
• 注意评分标准的措辞会塑造输出特征

7. 自定义 Auto Mode 的拦截规则

对于特定的工作流（如 CI/CD 集成、特定云服务操作），可能需要定制拦截规则：

• 添加窄范围的允许例外（如”允许推送到 feature 分支”）
• 收紧特定类别的拦截（如在生产环境中完全禁止 deploy 相关命令）

注意事项

8. Auto Mode 不是生产环境的银弹

Anthropic 明确表示：Auto Mode 不替代对高风险基础设施的谨慎人工审查。17% 的漏报率在开发环境中可接受，在生产环境中可能是灾难性的。

9. 注意 Evaluator 的盲区

即使调优后的 Evaluator 仍然会遗漏：小的布局问题、直觉上不流畅的交互、深层嵌套功能中的 bug。Evaluator 提供的是”足够好”的质量保障，而非”完美”的质量保障。

10. 成本意识

完整 Harness 的成本不低——即使优化后仍需 $124.70（约 3 小时 50 分钟）。对于简单项目，单 Agent 的$9 / 20 分钟可能更经济。Harness 的价值在于复杂度高、质量要求严格的项目。

批判性分析

Auto Mode 的根本张力

Auto Mode 面临一个不可完全解决的根本张力：模糊用户意图下的授权范围判定。

当用户说”清理 PR”时，这是否授权了 force-push？当用户说”修复测试”时，这是否授权了修改测试本身而非修复被测代码？这类语义歧义无法通过分类器改进来完全消除——它是自然语言的固有特征。

Anthropic 选择接受 17% 的漏报率而非通过过度保守来消除它，这是一个务实的工程决策。但这意味着 Auto Mode 本质上是一个”足够安全”而非”绝对安全”的系统。对于大多数开发场景这是合理的；对于高安全环境则需要额外防护层。

Harness 设计的过拟合风险

博客中的 Harness 设计高度针对特定类型的任务——全栈 Web 应用开发。对于其他领域（数据管道、嵌入式系统、科学计算、基础设施自动化），三 Agent 架构的适用性未经验证。

特别是 Evaluator 使用 Playwright 进行 UI 测试这一设计，天然局限于有可视化界面的应用。对于后端服务、CLI 工具或数据处理管道，需要完全不同的评估方法。

成本效率的真实性

$124.70 / 3 小时 50 分完成一个复杂应用——这个数字看起来极具吸引力。但需要注意的是，这个成本不包括：

• Evaluator 调优的人工时间（多个迭代周期，可能数天）
• Planner prompt 的设计和优化时间
• 对评估结果进行人工检查的时间
• 失败尝试的成本（不是每次运行都成功）

真实的全链成本（TCO）可能比标题数字高出数倍。

与竞争者的对比缺位

两篇博客都缺乏与竞争方案的系统性对比。Auto Mode 如何与 OpenAI Codex 的安全模型、Google Antigravity 的 Agent 编排、Cursor 的权限管理相比？Harness 设计与 LangGraph、CrewAI 等开源多 Agent 框架相比有何优劣？

缺乏这些对比使得读者难以做出有依据的技术选型决策。

模型锁定（Model Lock-in）担忧

Harness 设计强调”每一代模型重新评估”，但文中展示的所有案例都使用 Anthropic 自家的 Opus 系列。Evaluator 的调优是否可移植到其他模型？Auto Mode 的分类器是否依赖 Claude 特定的行为模式？如果一个团队在 Anthropic 的 Harness 模式上投入大量调优工作，切换到其他模型提供商的成本有多高？

这些问题博客没有回答，但对于做长期技术决策的团队至关重要。

积极面：工程透明度的行业标杆

尽管有上述局限，这两篇博客在工程透明度方面树立了行业标杆：

• 公开了真实流量上的性能指标（包括漏报率这种”不好看”的数字）
• 坦承 Evaluator “开箱即用是糟糕的”
• 提供了详细的成本数据而非只展示最佳案例
• 讨论了设计决策的代价，而非仅宣传优势

这种诚实的工程写作在 AI 行业中极为罕见，值得其他公司学习。

同期信号：Opus 4.6 / Sonnet 4.6 Batch API 更新

值得一提的是，Anthropic 同期更新了 Opus 4.6 和 Sonnet 4.6 的 Batch API，将最大输出 token 提升至 300k。这个更新与 Harness 设计博客形成了直接的产品呼应——长运行 Agent 需要大量输出 token 来完成复杂任务，300k 输出 token 的 Batch API 使得在成本敏感场景下运行这类 Harness 成为可能。