Agent + Harness 工程师：AI 时代的新兴工程角色

2026 年最炙手可热的 AI 工程岗位之一——Agent + Harness 工程师不是传统的"调模型"角色，而是为 AI Agent 设计"工作轨道"的系统架构师。当大模型能力趋同，真正的竞争壁垒从模型内部转移到外层工程系统。

一、什么是 Agent + Harness 工程师

Agent + Harness 工程师是为 AI Agent 构建运行基础设施的工程角色，核心公式为：

Agent = Model + Harness

• Model（模型）：负责"思考"——理解需求、逻辑推理、生成文本/代码

• Harness（驾驭层）：负责"行动"——约束、引导、验证、反馈、恢复，将模型能力转化为可靠的生产力

核心类比

一句话总结：传统工程师关注"怎么写代码"；Agent + Harness 工程师关注"怎么设计让 Agent 可靠写代码的系统"。

二、概念起源与行业背景

2.1 提出者

Harness Engineering 概念由 HashiCorp 联合创始人 Mitchell Hashimoto（Terraform、Vagrant 创造者）于 2026 年 2 月 在其个人博客中系统性提出：

"Harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future."

2.2 OpenAI 的里程碑实验

2026 年 2 月，OpenAI 发布了一份震撼行业的实验报告，一个 3 人小团队在 5 个月内用 Codex Agent 构建了超过 100 万行代码的生产级应用，零行代码由人类手动编写，效率提升约 10 倍。这件事彻底点燃了行业讨论：AI 工程正在从"调模型"走向"搭系统"。

2.3 AI 工程的三次范式跃迁

关键认知：三者是包含关系，而非替代关系——Prompt ⊂ Context ⊂ Harness。越外层越系统化，越能解决 Agent 落地的根本问题。

三、核心职责

Agent + Harness 工程师的工作围绕六大核心模块展开：

模块一：运行时基础设施（Runtime Infrastructure）

设计并实现 Agent Harness，主导：

• 任务编排：将复杂需求分解为可执行的子任务序列

• 状态持久化：解决 LLM 无状态的根本问题，支持跨会话记忆

• 断点续跑与失败恢复：Agent 失败后能从断点继续而非从头开始

• 人工接管（Human-in-the-loop）：高风险操作（删数据、扣费、发通知）必须人类审批

模块二：工具封装与安全治理

• 将内部系统、数据库及 API 封装为安全 Tools

• 构建 Sandbox 沙箱，执行环境与生产系统隔离

• 设计权限校验、护栏（Guardrails）、高风险拦截与敏感操作审计机制

模块三：上下文工程（Context Engineering）

• 维护项目知识库（AGENTS.md、CLAUDE.md），Agent 启动时自动读取

• 动态注入可观测性数据（日志、指标、追踪信息）

• 上下文隔离：子 Agent 作为"上下文防火墙"

• 上下文压缩：窗口填满时自动摘要无关信息

模块四：验证与评测体系

• 构建确定性约束（Linter、结构测试、Pre-commit）

• 实现生成-评估分离（独立评估器模式）

• 搭建 Eval 数据集与回归评测流程

• 建立"评测 → 归因 → 分析 → 改进"闭环

模块五：可观测性（Observability）

• 全链路追踪（Tracing）

• 日志与指标监控体系（LogQL、PromQL）

• 执行追踪、质量分级、异常检测

• 反馈归因：将生产失败模式追溯到 Harness 的具体缺陷

模块六：熵管理（Entropy Management）

• 后台定期运行"垃圾回收 Agent"，扫描文档不一致与架构违规

• 自动提交重构 PR，持续偿还技术债

• 多 Agent 互审机制（Ralph Wiggum Loop）

四、技能要求与技术栈

4.1 硬性技能要求

4.2 核心知识体系

Agent 基础机制：LLM API、KV Cache、Agent Loop、Tool Use、Reasoning、Planning、Skills、MCP、Memory、Subagent、Multi-Agent

工程范式：Prompt Engineering → Context Engineering → Harness Engineering

工具链：LangGraph、PydanticAI、MCP Protocol、Claude Code、Codex

可观测性：LogQL、PromQL、TraceQL、OpenTelemetry

基础设施：Docker、Kubernetes、CI/CD、Sandbox

4.3 工程师角色的根本转变

传统工程师 → Agent + Harness 工程师：

五、市场行情与招聘趋势

5.1 薪资水平

5.2 热门招聘企业

目前释放 Harness 相关岗位的企业包括：

• 基模大厂（北京/杭州）：参与设计 Harness 产品技术架构，前沿创新

• 阿里云（杭州）：AI Agent 工程，Prompt & Context & Harness 核心组件

• 多家 AI 创业公司（杭州/深圳/北京）：运行时基建、工具封装、评测体系

六、Harness 核心原则

6.1 Less is More

整个 Harness Engineering 最反直觉但最重要的发现：

约束 Agent 的解决空间 → 反而提升表现

更少的工具 = 更少的步骤 = 更少的 Token = 更高的成功率

6.2 约束换自主

规矩越明确 → Agent 独立做的事越多 约束越严格 → 信任越高 → 自主权越大

这和人类社会的运转逻辑一致：法律越完善的社会，个人自由度越高。

6.3 Harness 自改进闭环

Agent 遇困难 (1) → 识别缺失能力 (2) → 编写修复代码 (3) → Harness 改进 (4) → (循环)

核心模式：不是更努力尝试，而是反问"缺什么" → 让 Agent 自己修复 Harness 本身。

七、学习路径与资源推荐

7.1 从零开始的实施路径

7.2 推荐学习资源

• Mitchell Hashimoto 原文博客：My AI Adoption Journey（2026.02.05）

• OpenAI 官方报告：Harness engineering: leveraging Codex in an agent-first world

• LangChain Deep Agents：开源框架，Harness Engineering 理念的直接落地

• B站 唐国梁Tommy：Agent Harness Engineering 系列视频

• Martin Fowler 网站：Birgitta Böckeler 关于 Harness Engineering 的深度分析

八、未来展望

8.1 行业趋势

底层模型能力会越来越趋同，大家都能用强模型、做 RAG、搭 Agent。最后拼的只能是外层系统谁更扎实——知识组织是否清晰、接口是否适合模型、验证链路是否完整、治理机制是否成熟。

8.2 尚未解决的核心问题

• 功能和行为验证：代码能跑、测试能过，不等于功能正确

• 长期架构连贯性：完全由 Agent 生成的系统中，架构如何随时间保持一致性

• Big Model vs Big Harness 辩论：更强的模型是否会减少 Harness 的价值？

结论：短期简单任务，更强的模型能直接解决；但长期复杂项目中，熵增、上下文丢失、模式漂移、信任债务累积这些问题不会因为模型更强而消失——Harness 的价值随任务复杂度和持续时间指数增长。

九、总结

Agent + Harness 工程师的核心价值在于把模型偶尔爆发的能力，变成一种可重复、可验证、可规模化的交付能力。当 AI 开始从"会说"走向"会做"，真正决定结果的往往已经不是模型本身，而是你给它搭了一套什么样的外部系统。

一句话总结：过去大家总爱问"这个模型强不强？"接下来，更值得问的问题是——"这套系统，能不能让模型稳定把事做完？"

前一个问题决定能力上限，后一个问题决定交付下限。