Agent Harness：2026 年 AI 工程最重要的概念，一篇文章讲透

Marvin_Kai

24人浏览 · 2026-06-26 19:50:18

Marvin_Kai · 2026-06-26 19:50:18 发布

"模型智力已经在线，我们现在比拼的就是 Harness。"
—— 黄佳，《动手做 AI Agent》作者

2026 年上半年，AI Agent 领域冒出了一个绕不开的高频词：Harness。

Anthropic 连发两篇工程博客讲它，OpenAI 专门撰文讨论，Microsoft 在 BUILD 2026 直接把它做成了 Agent Framework 的核心模块，Thoughtworks 的 Birgitta Böckeler 在 martinfowler.com 上做了系统梳理，连第一篇以 Harness 为研究领域的学术论文（arXiv:2604.25850）都发表了。

这不是又一个被过度炒作的 buzzword。Harness 代表的是 AI 工程范式的第三次跃迁——理解它，才能理解 2026 年 Agent 领域所有的重要决策。

一、Harness 到底是什么

1.1 一句话定义

Agent = Model + Harness

Harness（/'hɑːrnɪs/）原意是"马具"、"缰绳"，引申为"驾驭、控制"。在 AI Agent 语境下，它指的是把一个大语言模型转变为能够自主行动的 Agent 所需的全部外围基础设施。

模型提供智力，Harness 提供行动能力。模型决定"想什么"，Harness 决定"怎么做"和"什么不能做"。

1.2 一个精准的类比

Beren Millidge 在 2023 年提出了一个至今仍然最精准的类比：

表格

组件	类比	职责
LLM	CPU	提供推理和决策能力
Context Window	RAM	快速但有限的短期记忆
External Database	硬盘	大容量但较慢的长期存储
Tool Integrations	设备驱动	与外部世界交互的接口
Harness	操作系统	统筹管理一切的运行环境

一个原始 LLM 就像一台没有 RAM、没有硬盘、没有 I/O 的 CPU。无论这颗 CPU 多强，没有操作系统，它就跑不了任何应用。Harness 就是 Agent 世界的操作系统。

1.3 官方定义

Anthropic："The SDK is the agent harness that powers Claude Code."
Salesforce Agentforce："An agent harness is the operational software layer that manages an AI's tools, memory, and safety to ensure reliable, autonomous task execution."
Microsoft 在 BUILD 2026 中将 Agent Harness 定义为："The layer where model reasoning meets real execution."

二、AI 工程的三次范式跃迁

要理解 Harness 为什么在 2026 年爆发，需要先看 AI 工程这四年的演进脉络。据 colourful.codes 的梳理来源：

第一代：Prompt Engineering（2022-2024）

关注点：写好一条指令。

Few-shot learning、Chain-of-Thought、角色扮演……所有技巧都围绕"如何优化单次输入"。这个阶段的核心假设是：只要 prompt 写得够好，模型就能给出正确答案。

第二代：Context Engineering（2025）

关注点：动态构建整个上下文。

单条 prompt 不够用。工程师学会了动态组装完整的上下文——相关文件、对话历史、工具定义、知识库检索结果——让模型在充分信息下做出决策。RAG 是这个时代的标志性技术。

第三代：Harness Engineering（2026）

关注点：约束、反馈回路、架构规则、工具链和生命周期管理。

Context Engineering 成了基本功（table stakes），Harness Engineering 在上层运作：它创造的是一个环境，让 Agent 能持续、稳定、高质量地工作。Prompt 和 Context Engineering 成了 Harness 的子学科。

表格

层次	做什么	作用域
Prompt Engineering	调优单次输入字符串	单次模型调用
Context Engineering	决定什么信息进入上下文窗口	检索、压缩、技能加载
Agent Framework（LangChain/CrewAI 等）	提供可组合的构建块	库 / SDK
Harness Engineering	设计、运维、保护、评估整个运行时	系统工程学科

三、为什么是 2026 年？数据说话

Harness 概念的爆发不是偶然的，而是因为业界终于有了足够的数据来证明：Harness 的质量比模型的选择更重要。

3.1 同模型、不同 Harness 的惊人差距

来自多个独立来源的数据来源：

Nate B Jones 实验：同一个模型，不同 Harness → 成功率从 42% 跃升到 78%
Anthropic 实验：同一个 prompt、同一个模型 → 20 分钟/$9 产出了损坏的核心功能，而 6 小时/$200 产出了可运行的完整游戏
LangChain 实验：Terminal Bench 2.0 分数从 52.8% 升到 66.5%，只换了 Harness，模型没变
Terminal Bench 2.0 排行：Claude Opus 4.6 用 Harness A 排第 33 名，用 Harness B 排第 5 名——同一个模型，28 个名次之差

3.2 Terminal-Bench 2.0 全面数据

Terminal-Bench 2.0 是 2026 年 Agent 评测的核心基准，89 个任务覆盖软件工程、安全、生物、游戏，每个任务在 Docker 容器中独立运行，自动验证。

Top Agent + 模型组合：

表格

排名	Agent + 模型	分数
1	Forge Code + Gemini 3.1 Pro	78.4%
2	Droid + GPT-5.3-Codex	77.3%
3	Simple Codex + GPT-5.3-Codex	75.1%
5	Terminus-KIRA + Claude Opus 4.6	74.7%
6	Mux + GPT-5.3-Codex	74.6%

同一时期裸模型分数：

表格

模型	裸跑分数
GPT-5.5	73.20%
Claude Opus 4.7	68.54%
Gemini 3.1 Pro Preview	67.42%

注意看：排名第 1 的 Forge Code + Gemini 3.1 Pro（78.4%）比排名第 1 的裸模型 GPT-5.5（73.2%）高出 5.2 个百分点。而 Gemini 3.1 Pro 裸跑只有 67.4%——好的 Harness 能把同一个模型的表现提升 11 个百分点。

3.3 结论

优化模型外层的 Harness，回报可能比等下一代模型更高。

这是 2026 年 AI 工程最重要的认知转变。

四、Harness 的十大核心组件

把 Anthropic、OpenAI、Microsoft、Thoughtworks 的工程实践放在一起看，一个标准栈已经收敛成型。不是谁抄谁，而是大家在解决同一组问题时，独立走到了相似的答案。

4.1 Agentic Loop（心脏）

while (true) {

// 1. 解构状态

// 2. 压缩上下文

// 3. 构建系统提示

// 4. 调用 LLM API（流式）

// 5. 收集 tool_use 块

// 6. 错误恢复

// 7. 工具执行

// 8. Stop Hook → 终止或继续

// 9. 更新状态 → continue

}

这是 Harness 的心脏。本质是 ReAct（Reasoning + Acting）论文的工程化——思考和行动交替执行。所有复杂行为都从这个简单循环中涌现。

关键设计原则：

Async Generator：不是返回最终结果，而是 yield 每一个中间事件，让上层应用实时监控、随时中断
无限循环 + 显式退出：只在 return Terminal 时退出，提供最大灵活性
单一 State 对象：维护伪不可变语义，方便回滚和审计

4.2 Tool Registry（手脚）

Agent 能看到哪些工具、能调用哪些 API，都在这里定义。

经验法则：10 个精准工具 > 50 个重叠工具。

工具菜单膨胀是 Agent 不可靠的最常见原因之一。Anthropic 发现，当 Claude 3.5 Sonnet 在 SWE-bench Verified 上达到 49% 时，它只用了两个工具：bash 和文本编辑器。不是定制的 Agent 工具，而是每个版本的 Claude 都会使用的通用开发者工具。

核心洞察：不要为模型构建新工具，让它用自己已知工具的组合来解决问题。 Agent Skills、Programmatic Tool Calling、Memory Tools——全都是从 bash + 文本编辑器的新颖组合中涌现出来的。

4.3 Sandbox & Execution（安全隔离）

容器、浏览器、隔离文件系统——限制错误操作的爆炸半径。

没有沙箱，每次工具调用都是一次赌博。生产级 Harness 必须让 Agent 在受控环境里执行，出错了能快速回滚。

OpenAI Codex 使用内核级沙箱，Cursor 使用容器隔离，Claude Code 目前仅部分沙箱化。这是各家 Harness 在安全维度的核心差异点。

4.4 Permission Model（缰绳）

三级权限控制：

表格

权限级别	行为	适用场景
Allow	自动执行，无需确认	只读操作：读文件、搜索、查询
Deny	不可绕过，直接拒绝	高危操作：删除系统文件、访问凭证
Ask	暂停执行，等待人工确认	写操作：创建文件、发送 API 请求

Claude Code 一直问你"要不要执行这个操作"，就是在做这个。人必须控制权限——这是 Harness 区别于"全自动脚本"的关键。

Anthropic 进一步建议：将需要安全控制、用户交互或审计追踪的操作，从 bash 中提取为独立工具。 比如 Claude Code 的 edit 工具是独立的，不是 bash 命令。这让 Harness 能在编辑前检查文件是否过期，防止覆盖。如果用 bash 的 sed 来编辑，Harness 根本不知道哪些文件被改了。

4.5 Memory & Context Management（记忆）

核心原则：Agent 无法在上下文中访问的信息，等于不存在。

记忆分两层：

静态上下文：仓库文档、CLAUDE.md/AGENTS.md 文件、设计文档
动态上下文：日志、指标、目录映射、CI/CD 状态

上下文压缩（Compaction） 是 Harness 最关键的子系统之一。当 token 用量达到上下文窗口的 98% 时，Harness 自动启动压缩：总结早期历史、保留关键元数据、剥离图像和 PDF。

Microsoft MAF 内置了 Automatic Context Compaction，在长时间工具调用链中监控 token 使用并自动压缩聊天历史，全程无需人工干预。

Anthropic 发现了一个有趣的现象——压缩质量高度依赖模型本身：

表格

模型	压缩后任务完成率
Sonnet 4.5	43%
Opus 4.5	68%
Opus 4.6	84%

同一个压缩机制，不同模型的表现天差地别。这证明模型本身知道该记住什么、该忘记什么。

另一个进化案例——在宝可梦游戏测试中：

表格

模型	14,000 步后的表现
Sonnet 3.5	还在第二个小镇，31 个文件（包括重复的毛毛虫笔记）
Opus 4.6	10 个文件，按目录组织，获得三个徽章，还有一个从失败中提取的"经验教训"文件

同样的机制，更聪明的模型。从"记录 NPC 对话"进化到"记录战斗失败经验"。

4.6 Hooks（守卫）

在关键节点插入检查逻辑，防止危险操作。

Anthropic 的双阶段 Harness 架构中，Hooks 扮演了关键角色：

Pre-execution Hook：工具调用前检查权限和参数合法性
Post-execution Hook：工具调用后验证结果是否符合预期
Stop Hook：判断任务是否真正完成，防止"假性完工"

实际案例：代码提交到 GitHub 之前，Hook 自动检查是否误传了 .env 文件或 API Key。这类检查看起来简单，但在 Agent 自主操作场景下，没有 Hook 就等于裸奔。

4.7 Sub-agents（子任务编排）

将子任务委派给并行运行的子 Agent，实现 fan-out 编排。

Anthropic 发现，让模型自己决定何时 fork 一个干净的上下文窗口、把子任务隔离出去，比让 Harness 硬编码编排逻辑效果更好。Opus 4.6 的 Subagent 能力在 BrowseComp 基准上比最佳单 Agent 运行提高了 2.8%。

Microsoft MAF 的 BackgroundAgentsProvider 也是这个思路——主 Agent 拆任务，子 Agent 并行执行，结果汇总回来。

4.8 System Prompt & Skills（渐进式披露）

System prompt 的每一行都应该源自一次过去的失败——Addy Osmani 称之为 "棘轮原则"（Ratchet Principle） 。推测性规则是分散注意力的噪音。

Skills 的渐进式披露是 Anthropic 的重要创新：

每个 Skill 的 YAML frontmatter 提供简短描述，加载到上下文中作为概览
完整内容只在需要时通过 read file 工具加载
这给了 Claude 自由组装自己上下文窗口的能力

传统做法是把所有指令预装进 system prompt。问题是：指令越多，模型的注意力预算越紧张，而且大部分指令在大部分时候都不相关。Skills 机制完美解决了这个矛盾。

4.9 Observability（可观测性）

OpenTelemetry 追踪、Token 消耗监控、成本追踪。

Anthropic 和 OpenAI 都发现了同一件事：改进基础设施的回报大于改进模型。

一个能清楚看到以下信息的 Harness，比一个黑盒 Harness 有用得多：

每轮对话的 token 消耗
每个工具的调用成功率和延迟
上下文窗口的使用率变化
缓存命中率（直接影响成本——缓存 token 只花基础输入 10% 的费用）

Microsoft MAF 内置了 OpenTelemetryAgent，自动按照 Semantic Conventions 追踪，零额外配置。

4.10 Eval Loop（评估闭环）

不是评测"答对题"，而是评测"完成任务"。

当前主流模式是 Planner / Generator / Evaluator 分离（Anthropic 三代理架构）：

Planner Agent：将高层需求拆解为可验证的端到端特性列表
Generator Agent：每次只专注一个特性，增量推进
Evaluator Agent：独立于执行者，用端到端测试验证结果

分离的关键是消除自我打分偏差——让执行者评价自己的工作，就像让学生批改自己的试卷。

五、长时间运行 Agent 的核心难题

为什么 Harness 如此重要？因为长时间运行的 Agent 面临一组独特难题。Anthropic 的工程博客来源精准诊断了四个核心问题：

5.1 上下文断裂

长时间运行的 Agent 必须在多个离散 session 中工作。每个新 session 都从"没有前情记忆"开始，像换了一位完全不了解前因后果的新工程师接手项目。

Harness 解法：Initializer Agent 创建 init.sh（统一启动环境）、claude-progress.txt（进度日志）、初始 git commit（状态快照），让新 session 能快速恢复上下文。

5.2 一次性过载

模型容易试图一口气做太多，结果在实现中途耗尽上下文，留下"只完成一半、又没有文档"的半成品。下一轮 Agent 还得花大量时间猜测之前到底做了什么。

Harness 解法：强制"每次只做一个特性"的规则，通过结构化特性清单（JSON 格式）管理进度。

5.3 假性完成

项目推进到后期后，后续 Agent 可能因为"看起来已经有进展"就过早宣布任务完成，导致功能其实并未真正收尾。

一位 DevOps 工程师分享的真实案例来源：

"我的 AI 编码 Agent 开始了一次零停机迁移，在 Helm chart 做到一半时耗尽了上下文。第二天醒来，看了一眼半成品 YAML，然后欢快地宣布'All done! 🚀'"

Harness 解法：完成标准绑定到端到端验证。特性清单用 JSON 管理，只有当端到端测试通过后，才能把 passes 从 false 改为 true：

{

"category": "deployment",

"description": "Implement blue-green rollout for prod",

"steps": ["Update Helm values", "Add traffic switch logic", "Test rollback"],

"passes": false

}

5.4 状态不可见

如果没有标准化的环境记录、进度日志和启动脚本，新来的 Agent 很难快速判断当前代码能不能跑、哪里坏了、下一步该做什么。

Harness 解法：每个新 session 启动时的标准流程：

读 pwd 确认位置
读 git log 了解历史
读 progress file 了解当前进度
读 feature list 了解待办事项
启动开发服务器做基础端到端测试，确认现有功能没坏
然后才开始推进新功能

六、Anthropic 的反直觉洞察：该停止做什么

Anthropic 的第二篇 Harness 工程博客回答了一个关键问题："有什么是我可以停止做的？" 随着模型进步，Harness 也需要进化。

6.1 停止为模型构建新工具

Claude 3.5 Sonnet 在 SWE-bench Verified 上达到 49% 时，只用了 bash 和文本编辑器两个工具。所有高级能力（Agent Skills、Programmatic Tool Calling、Memory Tools）都是从这两个工具的新颖组合中涌现出来的。

启示：与其花精力开发自定义工具，不如让模型用它已经熟悉的通用工具来组合解决方案。

6.2 停止由 Harness 编排一切

传统 Harness 假设每次工具调用的结果都必须返回模型的上下文窗口来做出下一个决策。但这浪费了大量 token。

旧方式：读取一个大表格来分析一列数据 → 所有行都消耗 token。

新方式：给 Claude 一个代码执行工具（bash 或 REPL），让它自己写代码来调用工具、过滤结果、串联逻辑。只有最终输出才返回上下文。

这把编排权从 Harness 转移到了模型。因为代码是通用的编排语言，编码能力强的模型天然就是强大的通用 Agent。

实际效果：在 BrowseComp（Web 搜索 Agent 基准）上，给 Opus 4.6 自我过滤能力后，准确率从 45.3% 提升到 61.6%——这还是一个非编程任务。

6.3 停止由 Harness 管理上下文

传统方法：把所有任务指令预装进 system prompt。问题：指令越多，注意力预算越紧张，而且大部分指令在大部分时候都不相关。

新方式：Skills 渐进式披露 + Subagent 隔离 + Compaction 自动压缩。让模型自己决定看什么、记什么、忘什么。

6.4 停止由 Harness 管理记忆

传统方法：在模型周围构建检索基础设施（向量数据库、RAG pipeline）。

Anthropic 的方式：给 Claude 简单的读写能力，让它自己选择保存什么。

Compaction：让 Claude 总结历史上下文以维持连续性
Memory Folders：给 Claude 一个读写文件夹，让它自己决定持久化什么

后者的效果：Sonnet 4.5 在 BrowseComp-Plus 上的分数从 60.4% 提升到 67.2%。

七、业界实践：五大 Harness 对比

截至 2026 年 6 月，主流的 Agent Harness 实现及其设计哲学来源：

7.1 Claude Code（Anthropic）

设计哲学：少即是多，让模型自组织

工具系统极简（bash + text editor 为核心）
1M token 上下文窗口，业界最大
权限模型最严格，默认 Ask 模式
SWE-bench Verified 80.9%，首次通过率约 95%
Agent Teams 支持多 Agent 协作

7.2 OpenAI Codex

设计哲学：云端沙箱，内核级安全

云端沙箱执行环境，内核级隔离
用 Rust 重写后 Token 效率大幅提升
Terminal-Bench 2.0 得分 77.3%
原生 CI/CD 集成（GitHub Actions）
Plan 模式：先规划后执行

7.3 Cursor

设计哲学：IDE 原生，人机协作

亚 100ms 延迟的实时 Tab 补全
Plan 模式 + 截图转代码
200K 上下文窗口
底层模型可选（配 Claude 时表现最佳）
沙盒安全执行（容器隔离）

7.4 Microsoft Agent Framework (MAF)

设计哲学：开箱即用的完整 Harness

agent = create_harness_agent(

client=client,

max_context_window_tokens=128_000,

name="ResearchAgent",

description="A research assistant",

agent_instructions=RESEARCH_INSTRUCTIONS,

)

一行代码获得全部十大组件：

自动上下文压缩
FileMemoryProvider（会话级文件记忆）
FileAccessProvider（通用文件访问）
TodoProvider（多步任务管理）
AgentModeProvider（计划/执行模式分离）
AgentSkillsProvider（模块化技能注入）
BackgroundAgentsProvider（子 Agent 并行编排）
Web Search（内置网络搜索）
Shell Execution（沙箱化 Shell 执行）
OpenTelemetry 追踪

7.5 开源方案对比

表格

工具	协议	Stars	模型灵活性	入门成本
OpenCode	MIT	156,000	75+ 供应商，BYOK	免费
Gemini CLI	Apache 2.0	103,000	仅 Gemini	免费（1000 req/天）
Codex CLI	Apache 2.0	80,600	OpenAI 为主，支持 Ollama	$20/月
Aider	Apache 2.0	44,500	100+ via LiteLLM	免费

7.6 核心差异一览

表格

能力维度	Claude Code	Codex	Cursor	MAF
上下文窗口	1M	1M (Pro)	200K	128K (可配)
沙箱安全	部分	内核级	容器级	可插拔
多 Agent 协作	Agent Teams	并行容器	有限	BackgroundAgents
自动上下文压缩	98% 触发	内置	无	内置
记忆持久化	Memory Folder	会话文件	无	FileMemoryProvider
可观测性	基础日志	基础日志	无	OpenTelemetry
工具数量哲学	极简	中等	丰富	模块化

八、成本经济学：Harness 如何影响你的钱包

Harness 不只是技术问题，也是经济问题。

8.1 缓存设计决定成本

Anthropic Messages API 是无状态的——每轮对话都需要发送完整历史。缓存的 token 只花基础输入 10% 的费用，所以最大化缓存命中率直接影响成本。

五条缓存原则：

把动态内容放在 prompt 末尾
追加新消息而不是每次当单轮处理
对话中途不要切换模型（会破坏缓存）
谨慎管理工具（增删工具会使缓存失效）
多轮 Agent 对话中，把断点移到最新消息

8.2 自编排节省 Token

让模型自己用代码过滤工具输出（而不是把所有输出塞进上下文），能大幅减少 Token 消耗。

BrowseComp 基准数据：给模型自过滤能力后，准确率提升 16.3 个百分点的同时，每任务平均 Token 消耗降低了约 30%。

8.3 Anthropic 的成本实验

同一任务：

20 分钟 / $9：核心功能损坏
6 小时 / $200：产出可运行的完整游戏

便宜 ≠ 好。Harness 的价值之一就是帮你在成本和质量之间找到平衡点。

九、合规视角：EU AI Act 与 Harness

2026 年 8 月 2 日，欧盟 AI 法案（EU AI Act）的高风险义务条款将正式生效来源。

Articles 9-15 要求的内容，恰好是一个 Harness 应该产出的东西：

表格

EU AI Act 要求	Harness 对应组件
风险管理系统	Permission Model + Guardrails
数据治理	Memory & Context Management
技术文档	Observability + Hooks 审计日志
透明度	System Prompt & Skills 记录
人类监督	Permission Model（Ask/Deny）
准确性和稳健性	Eval Loop + Sandbox
可追溯性	Git 历史 + Progress File + Session 记录

换句话说：一个好的 Harness 天然就是一套合规基础设施。 如果你的 Agent 系统涉及 EU AI Act 定义的高风险场景，Harness 不是可选项，而是必需品。

十、生产环境常见失败模式

来自实战的教训，值得提前规避：

表格

失败模式	表现	Harness 解决方案
无限循环	Agent 陷入死循环，无法终止	Stop Hook + 最大轮次限制
上下文爆炸	Token 超限，关键信息丢失	四级压缩管道 + 磁盘持久化
权限失控	Agent 执行危险操作	Guardrails + 人工确认
假性完成	"看起来好了"但实际没好	端到端测试 + Evaluator Agent
质量不可控	输出质量参差不齐	验证循环 + 质量审核
成本不透明	Token 消耗难以预估	成本追踪 + 预算限制
上下文漂移	Agent 忘了最初目标	Progress File + Git History
工具过载	工具太多导致选错	精简工具注册表

十一、实操指南：设计你自己的 Harness

第一步：定义工具边界

不要一开始就注册 50 个工具。从 5-10 个核心工具开始，观察 Agent 在哪里卡住，再按需添加。

每添加一个工具，问自己：

这个工具的失败场景是什么？
如果 Agent 误用了它，最坏结果是什么？
能不能把它和其他工具合并？

第二步：建立权限模型

三类操作必须分开：

yaml

permissions:

allow: # 自动执行

- read_file

- search

- list_directory

ask: # 需要人工确认

- write_file

- send_api_request

- install_package

deny: # 绝对禁止

- delete_system_file

- access_credentials

- modify_harness_config

第三步：设计退出条件

Agent 不能无限运行。必须有：

python

exit_conditions = {

"max_turns": 100, # 最大轮次

"token_budget": 200_000, # Token 上限

"timeout_seconds": 3600, # 超时机制

"stop_hook": verify_task, # 完成度验证

"cost_limit_usd": 10.0, # 成本上限

}

第四步：接入可观测性

从第一天就接入。事后加的成本是事前接入的 10 倍。

关键指标：

每轮对话的 token 消耗
每个工具的调用成功率和延迟
上下文窗口的使用率变化
缓存命中率
单任务总成本

第五步：建立评估闭环

不要用"感觉"评估 Agent 质量。设计评测集，定期跑，跟踪趋势。

python

eval_metrics = {

"task_completion_rate": 0.0, # 任务完成率

"avg_steps_per_task": 0.0, # 平均完成步数

"error_recovery_rate": 0.0, # 错误恢复成功率

"cost_per_task_usd": 0.0, # 单任务成本

"false_completion_rate": 0.0, # 假性完成率

}

第六步：为长时间任务设计交接协议

如果你的 Agent 需要跨多个 session 工作（超过 30 分钟的任务通常都需要）：

Session 启动协议：

1. 读取 pwd 确认工作目录

2. 读取 git log 了解最近变更

3. 读取 progress.txt 了解当前进度

4. 读取 feature_list.json 了解待办事项

5. 运行基础端到端测试，确认现有功能没坏

6. 然后才开始推进新功能

Session 结束协议：

1. 提交带描述性 commit message 的 git commit

2. 更新 progress.txt，记录本轮做了什么、下一步是什么

3. 更新 feature_list.json 中对应条目的状态

4. 确认工作区处于干净可续接状态

十二、从 30 年软件工程演进看 Harness

从更大的视角看，Harness Engineering 不是凭空出现的。它呼应了软件工程 30 年来反复出现的主题。

表格

年代	复杂性中心	解决方案
1990s	单体应用	面向对象、设计模式
2000s	企业系统	SOA、企业架构
2010s	分布式服务	微服务、容器化
2020s	数据密集型系统	大数据、流处理
2026	不确定性系统	Harness Engineering

复杂性一直在转移，但本质从未改变——通过抽象和结构化，把复杂的东西变得可控。

Harness 就是我们驾驭 Agent 这个"不确定性系统"的缰绳。

结语

2026 年的 AI 工程，正在经历从"写好 Prompt"到"设计好 Harness"的范式跃迁。核心认知已经确立：

Agent = Model + Harness。模型是 CPU，Harness 是操作系统。没有好的操作系统，再强的 CPU 也跑不了应用。
Harness 比模型更重要。同一个模型，不同 Harness，成功率差距可达 36 个百分点。优化 Harness 的回报可能比等下一代模型更高。
十大组件已成标准栈。Agentic Loop、Tool Registry、Sandbox、Permission Model、Memory、Hooks、Sub-agents、Skills、Observability、Eval Loop——这些不是选项，是必需品。
让模型做更多，Harness 做更少。Anthropic 的反直觉洞察：最好的 Harness 不是控制最多，而是让模型自编排、自管理上下文、自管理记忆。
合规是驱动力。EU AI Act 8 月生效，好的 Harness 天然就是合规基础设施。

对于工程师来说，这意味着：你的竞争力不在于"会用哪个模型"，而在于"能设计出多好的 Harness"。

这个转变，已经在发生了。

参考资料：