Agent 开发 = Harness 开发！用软件的确定性驯服 LLM 的不确定性，这是我的 Harness 分类法！

admin@yesmiracle.net (万戈) — Tue, 18 Aug 2026 00:00:00 +0000

最近跟几个做 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 怎么「做」——一个管决策，一个管兜底，正好互补。

DeepSeek Harness on AI博士 万戈

Agent 开发 = Harness 开发！用软件的确定性驯服 LLM 的不确定性，这是我的 Harness 分类法！

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

我的 Harness 七分法

1. 编程 Agent Harness

2. 桌面/界面 Agent Harness

3. 浏览器 Agent Harness

4. 知识/检索 Harness（RAG）

5. 安全护栏 Harness

6. 多 Agent 编排 Harness

7. Meta-Harness（框架型）

那么 DeepSeek Harness 算什么？

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

写在最后

DeepSeek Harness on AI博士万戈