5 月 25 日，InfoQ 爆出一则消息：DeepSeek 正在招人组建 Harness 团队，目标是从零打造一套 Agent 开发基础设施。"模型之外，皆属 Harness"——这句话的潜台词是：模型本身已经不是瓶颈了，怎么把模型用好、用稳、用到生产环境，才是真正的硬仗。

同一时间，开发者社区里出现了一个新词——"Harness Engineering"。它不是一个工具的名称，而是一个工种。就像几年前 DevOps 从"运维"里长出来一样，Harness Engineering 正在从"Prompt Engineering"里长出来。

从 Prompt Engineering 到 Harness Engineering

Prompt Engineering 火了一年多。但如果你真的在工作中跑过 Agent，你很快会发现一个问题：写好 Prompt 只是起点，离"能用"还差十万八千里。

一个生产级的 Agent 系统至少要解决这些：

层次 Prompt Engineering Harness Engineering
输入 写一条好 Prompt 动态构建上下文、管理 system prompt 版本、根据用户场景路由
工具 描述工具让模型自己调 工具注册、权限控制、调用链追踪、错误重试、降级策略
输出 期待模型返回好结果 结构化解析、校验、后处理、格式化
观测 看最终输出对不对 每一跳的 token 消耗、延迟、工具调用成功率、异常告警
安全 简单的内容过滤 注入检测、工具调用沙箱、敏感操作人机复核

Prompt Engineering 解决的是单次调用的质量问题。Harness Engineering 解决的是系统运行的可靠性问题。

为什么现在才出现？

不是现在才有的需求——Agent 生产化的问题一直都存在。但有三个变化让这个工种不得不独立出来：

1. Agent 从 Demo 走进了生产环境

半年前大家还在玩"让 AI 帮我写个网页"，现在企业开始让 Agent 处理客服工单、审计日志、合规检查。一出问题就是真金白银的损失。

2. 模型能力提升让"包装"比"调参"更重要

以前大家花 80% 精力在调 Prompt 上，因为模型太笨。现在模型聪明了，但聪明不等于可靠。如何约束一个聪明的模型按规矩办事，比教一个笨模型变聪明更难。

3. 多 Agent 协作让复杂度爆炸

一个 Agent 的失败率可能是 5%。10 个 Agent 串行协作，整体失败率就飙到 40%。这不是简单的"加个重试"能解决的——你需要编排、超时、熔断、回滚，全是分布式系统的经典难题。

从社区讨论看真实痛点

当天几个帖子的讨论暴露了实际的工程痛点：

  • "Prompt 工程在 Agent 里怎么跑？"——不是写一条 Prompt，而是管理一个 Prompt 栈：系统层 → 任务层 → 工具层 → 格式化层，每层有不同的版本策略和测试方法。
  • "Agent Harness 可观测性"——传统监控看 CPU/内存/QPS，Agent 监控需要看 token 消耗趋势、工具调用成功率分布、幻觉率变化。没有一个现成的工具能覆盖这些。
  • "AI 生成到 90% 突然断了，你的解决方案是什么？"——这是一个经典的 partial failure 问题，面试题级别的讨论暴露了行业还没有形成最佳实践。

这些讨论的共同点是：谈的都不是 AI 模型本身，而是工程问题。

我的视角：Harness Engineering 的五个核心能力

如果让我来定义这个工种，我认为一个合格的 Harness 工程师需要掌握：

1. 上下文工程（Context Engineering）

不是写 Prompt，而是设计 Agent 的"工作记忆"——哪些信息应该注入、何时注入、以什么格式注入。这里有大量的取舍：注入太多浪费 token，注入太少 Agent 不会干活。这本质上是一个信息检索 + 压缩的问题。

2. 工具链治理

Agent 每接入一个工具，就多一个攻击面。你需要像管理 API 一样管理工具：谁有权调用、调用频率限制、异常熔断、日志审计。这和微服务治理是一回事——只是容器变成了 LLM。

3. 输出约束

让 LLM 输出结构化数据，但也要容忍它偶尔不按格式来。实践中通常用三层防护：Schema 约束（生成时）→ 正则解析（抽取时）→ 人工兜底（极端情况）。核心原则是：永远不要让格式错误阻断整个流程。

4. 评估体系

Agent 的评估不能用传统的 precision/recall。你需要两套指标：功能指标（任务完成率、准确率）和成本指标（平均 token 消耗、延迟、API 费用）。而且因为 Agent 的输出是非确定性的，评估必须跑多次取分布，不能只看一次。

5. 安全边界

Agent 能做的事越多，能搞砸的事也越多。文件删除、API 调用、数据库写入——这些操作必须有人机复核（Human-in-the-loop）。安全不是一道防线，是分层防御：注入检测 → 工具白名单 → 操作审批 → 行为审计。

务实建议

如果你是一个开发者在关注这个方向：

  • 从单 Agent 开始。先把你最日常的一个重复性任务 Agent 化（比如代码审查、日报生成、日志分析），不要在第一个项目就搞多 Agent 编排。
  • 先做观测，再做优化。不埋点就优化是盲人摸象。至少记录每次 Agent 调用的 token 消耗和工具调用结果。
  • 工具链做减法。给 Agent 5 个精挑细选的工具，比给它 50 个什么都能做的工具有效得多。每多一个工具，推理出错概率就涨一截。

DeepSeek 的招聘信号很清楚：工程化是 Agent 落地的真正瓶颈，不是模型。 对于普通开发者来说，这个判断同样成立——与其追最新的模型，不如把你手头的 Agent 跑得更稳。