5 月 25 日，InfoQ 爆出一则消息：DeepSeek 正在招人组建 **Harness 团队**，目标是从零打造一套 Agent 开发基础设施。"模型之外，皆属 Harness"——这句话的潜台词是：**模型本身已经不是瓶颈了，怎么把模型用好、用稳、用到生产环境，才是真正的硬仗。**同一时间，开发者社区里出现了一个新词——"Harness Engineering"。它不是一个工具的名称，而是一个**工种**。就像几年前 DevOps 从"运维"里长出来一样，Harness Engineering 正在从"Prompt Engineering"里长出来。## 从 Prompt Engineering 到 Harness EngineeringPrompt 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 跑得更稳。
