最近跟几个做 agent 的朋友聊天，大家不约而同都在感慨：我们哪是在开发 agent，我们分明在开发 agent 的 harness。

每天的工作不是写 prompt，不是调模型，而是在建一套「软件系统」——工具定义、执行沙箱、状态管理、错误恢复、安全过滤、上下文窗口的切割与压缩……把 LLM 那团模糊的「我试试看」变成可靠的、可预测的、可回滚的自动化流水线。

这让我忍不住想深入拆一拆：harness 到底是什么？它有哪些类型？ 更重要的是——DeepSeek 最近开源的 “Harness” 到底算 harness 还是 agent？

先说结论：软件工程师不会失业，反而会更被需要。因为 harness 没有银弹，每一种 agent 场景都需要专门定制的 harness。

什么是 Harness？——软件的确定性 vs LLM 的不确定性

先给个定义。

LLM 本质上是一个概率生成器。同样的 prompt，这次给你 curl，下次给你 requests，下下次可能给你写个 Invoke-WebRequest（PowerShell）。你用 Python 问的，它可能给你写个 Ruby 脚本出来。不是它叛逆，是你面对的是一个采样过程。

Harness 就是套在 LLM 外面那层确定性壳。

它的职责很明确：

• LLM 说「读这个文件」→ harness 帮你完成实际的文件 I/O
• LLM 说「运行这个测试」→ harness 处理进程管理、超时、标准输出解析
• LLM 说有「python」这个工具 → harness 检查函数签名是否匹配、参数格式是否合法
• LLM 产生了 10 万 tokens 的思考链 → harness 决定什么该保留、什么该压缩、什么该存档

LLM 是那团火，harness 是那口锅。没有锅，火只能点着整个厨房。

这就是软件工程师的价值所在——我们用自己擅长的确定性工程去围堵 LLM 的随机性。

我的 Harness 七分法

把市面上各种 agent 拆开看 inner loop，harness 的类型其实非常清晰。

1. 编程 Agent Harness

代表：Cursor、Claude Code、Aider、Continue.dev

这类 harness 的核心循环是 「编辑 → 测试 → 编译 → 反馈」。

确定性层包括：

• 文件系统操作（读写、找文件、git diff）
• LSP（语言服务器协议）集成——代码跳转、类型检查、自动补全
• 测试运行器 + 错误解析器
• 仓库上下文管理（repo map、索引、chunking）

它的独特挑战在于：代码是一个高度结构化的文本域。你不能简单地把整个 repo 塞进上下文，也不能随便编辑一个函数就指望编译通过。编程 agent harness 需要对 AST（抽象语法树）、依赖图、调用关系有第一手的、确定性的理解。

Cursor 的自研索引、Claude Code 的 repo map——这些都是编程 harness 独有的工程创新。

2. 桌面/界面 Agent Harness

代表：Claude Computer Use、OpenAI CUA、UI-TARS、OmniParser

核心循环：「截图 → 规划 → 点击/键盘 → 校验」（Observe → Plan → Act → Verify）。

确定性层包括：

• 屏幕截图 + 坐标系统
• UI 元素检测（accessibility tree、OCR、元素识别模型）
• 鼠标/键盘模拟（点击坐标、拖拽、快捷键）
• 状态变化检测（元素是否存在、界面是否加载完成）

这类 harness 最难的点在于：视觉空间的连续性和不确定性。截图后点哪里？点了之后页面的变化是瞬时的还是要等的？元素有没有被遮挡？这些在代码域里能用类型检查解决的问题，在视觉域里全得靠 harness 去做「近似推理」。

3. 浏览器 Agent Harness

代表：Browser Use、Playwright + LLM 范式、Stealth Browser Agent

核心循环：「导航 → DOM 提取 → 交互 → 校验」（Navigate → Extract → Interact → Verify）。

确定性层包括：

• 无头浏览器控制（Page 对象、导航、等待）
• DOM 解析与元素定位（CSS 选择器、XPath、accessibility tree）
• JavaScript 执行引擎
• 反检测/反封禁层（指纹伪装、请求模拟）
• Cookie/会话管理

它和桌面 agent harness 最大的区别是：DOM 给了你一个结构化的「界面理解入口」。浏览器 agent 不需要 OCR 猜「这个按钮的文字是什么」，DOM 已经告诉你了。但坏消息是：DOM 是网页开发者写的，有的写得规范，有的写得一塌糊涂。

4. 知识/检索 Harness（RAG）

代表：各种 RAG 系统、上下文引擎、记忆系统

核心循环：「索引 → 检索 → 排序 → 注入」（Index → Retrieve → Rank → Inject）。

确定性层包括：

• 文本分块（chunking 策略、重叠窗口）
• 向量索引 + BM25 混合检索
• 重排序（reranking）
• 上下文窗口管理与压缩
• 缓存策略（避免重复检索）

这类 harness 的独特之处在于：它处理的是信息的不确定性，而非行为的不确定性。LLM 的行为问题（写什么代码、点哪里）是决策性问题；而 RAG 面对的是事实性问题（正确答案在哪一篇文档里）。这两种不确定性的 harness 设计思路完全不同。

5. 安全护栏 Harness

代表：Guardrails AI、Lasso Security、各类内容过滤器

核心循环：「输入检查 → 工具调用监测 → 输出过滤」（Check → Monitor → Filter）。

确定性层包括：

• 输入 sanitization（PII 脱敏、prompt injection 检测）
• 工具调用权限验证（白名单、参数校验）
• 输出过滤（敏感内容、代码注入）
• 速率限制与用量控制
• 审计日志

我自己的 ClawGuard 就属于这个分类——在 eBPF 层面做 agent 行为的可观测性和安全拦截。不做 LLM 的决策，只做 LLM 行为的外围监视。这个分类里最大的挑战是：安全 harness 必须在不降低 agent 体验的前提下做防护。

6. 多 Agent 编排 Harness

代表：LangGraph、AutoGen、CrewAI、Semantic Kernel

核心循环：「任务分解 → 委托 → 聚合 → 冲突解决」（Decompose → Delegate → Aggregate → Resolve）。

确定性层包括：

• 任务队列与调度（DAG 图、拓扑排序）
• Agent 间通信协议（消息格式、路由）
• 状态共享（共享内存、事件总线）
• 结果聚合与冲突判定
• 超时与降级策略

它的核心挑战是：多个概率系统叠在一起的组合不确定性。一个 agent 搞砸了，后面的恢复怎么做？两个 agent 给出了矛盾的结论，谁来仲裁？这已经不是单个 LLM 的随机性问题了，而是分布式系统中经典的「共识」问题。

7. Meta-Harness（框架型）

代表：LangChain、Vercel AI SDK、LlamaIndex

这类 harness 不直接服务终端用户，它提供的是构建所有上述 harness 的通用原语：

• Tool 定义与执行抽象
• Prompt 构建与模板化
• 上下文窗口管理
• LLM Provider 抽象
• 流式输出处理

它的设计哲学：不替你决定怎么跑，只让你跑得更顺。

那么 DeepSeek Harness 算什么？

回到用户说的那个点。8 月 13 日 DeepSeek 开源了 deepseek-harness，MIT 许可，CLI 名字叫 dsh。发布两天拿到 95,000 GitHub 星，铺天盖地的报道说「DeepSeek 开源了替代 Claude Code 的 agent」。

但在它名字里是 “Harness”。

我看了它的代码。dsh 包含：CLI 界面、工具系统（文件读写、代码执行、网络请求）、规划-执行循环、自我纠错机制。这些东西组合在一起，用户打开终端敲 dsh "fix this bug"，它就开始工作——读代码、改代码、测试、再改。

我认为这已经是一个 agent 了，不是一个 harness。

我的区分标准很简单：

• Harness 是框架层、API 层、库——开发者拿来组合自己的 agent
• Agent 是面向终端用户的、有完整工作流的、可独立运行的实体

DeepSeek Harness 的 Agent 面：dsh CLI 是一个完整的编码 agent，用户不写一行集成代码就能用。 DeepSeek Harness 的 Harness 面：同时它也提供了 Python SDK，开发者可以拿里面的 Tool 系统和规划引擎组装自己的 agent。

所以合理的说法是：DeepSeek 开源了一个带完整 Agent 实现的 Harness 框架。它既是一个可用的产品，又是一个可扩展的平台。

为什么软件工程师不会失业

整理完这七类 harness，我的结论反而更坚定了。

没有银弹。 编程 agent 的 harness 不能用在桌面 agent 上，浏览器的 DOM 引擎帮不了 RAG 的 chunking 策略。每一种场景都需要不同的确定性层设计。

软件工程师不是在「被 AI 替代」，而是在替 AI 修路：

• 每多一类 agent 场景，就多一套 harness 需要设计
• 每多一个 LLM 能力（多模态、长上下文、function calling），harness 就得重新适配
• 每多一个安全漏洞曝光，harness 的安全层就得补一块

每一段 harness 代码，都是软件工程师把 LLM 从「玩具」变成「工具」的过程。

AI 把生产力的天花板推高了，但真正摸到那个天花板的手，是 harness。而 harness，是软件工程师写的。

写在最后

最近也看到有人担心：「agent 能写代码了，软件工程师是不是要失业了？」

我觉得恰恰相反。Agent 每多写一行代码，就更需要人在旁边写 harness。——因为 agent 产生的每一行代码都可能是对的但跑不起来的，每一个操作都可能是合理的但不符合基线的。概率需要确定性去兜底，这就是软件工程师的新战场。

我自己的 MCPZERO 和 ClawGuard 也在做这件事。前者给 agent 提供安全的外部通信底座，后者在 eBPF 层面做 agent 行为的可观测性。都是在 harness 层做功。

说到底，AI 负责天马行空，我们负责铺铁轨。

📌 延伸阅读：我前面写过一篇 《Agent 架构全景图：从单次调用到多 Agent 协作的 8 种设计》，把 agent 内部的设计模式梳理了一遍。两篇配合看，你会发现 loop engineering 在讲 agent 怎么「想」，harness 在讲 agent 怎么「做」——一个管决策，一个管兜底，正好互补。