Harness 壁垒崩塌，人人创建 Harness 的时代来了

原文链接：https://mp.weixin.qq.com/s/K_4UnRJzG5uz6ygQXkqwIQ

AI 高阶玩家的门槛，正在从会不会写 Harness，转向会不会定义目标、控制预算和验收结果。

年初还在讨论 Harness 的时候，它像一道门槛。

会 Harness 的人，可以让一群 Agent 并行干活，自己写调度、控状态、收结果。不会 Harness 的人，大多还停留在单点对话，或者一轮一轮派 subagent 跑腿。

没过多久，这道门槛就被 Claude Code 往下压了一截。

不是因为大家突然都会写 Harness 了。

而是 Agent 开始自己写 Harness 了。

Anthropic 在 Claude Code 里放出来的 Dynamic Workflows，我更愿意把它看成 MCP、Skills 之后的第三个用法拐点。

MCP 改变的是 Agent 怎么连接外部世界。Skills 改变的是 Agent 怎么沉淀经验。Workflow 改变的是 Agent 怎么组织一支 Agent 队伍。

官方 changelog 里写得很直接：Claude Code 2.1.154 引入 Dynamic Workflows，可以让 Claude 创建 workflow，在后台编排几十到上百个 agents，去处理更大、更复杂的任务，运行过程可以用 /workflows 查看。

到 2.1.160 后，旧的 ultracode 口径已经改成了 workflow。口令会变，但方向没变。

这句话放在几个月前，其实挺吓人的。

因为 Harness 原来不是普通用户能随手搭的东西。它不是一段 prompt，也不是一个“多开几个 Agent”的按钮。它是一套编排层，负责把多个 Agent 组织成一个能干活的队伍。

现在，这一层开始被 Agent 自己生成。

这不是又多了一个 Claude Code 功能。它在拆一个过去属于 AI 高阶玩家的护城河。

年初大家还把 Harness 当成高阶玩家的分水岭，半年不到，讨论的重心就要从 “有没有 Harness” 变成 “有多少 Harness、会不会用 Harness”。

接下来半年，Workflow、Harness、自主编排 这套玩法大概率会重新火一轮。

AI 用法又要变天了。

Harness 以前为什么是壁垒

先说清楚，Harness 到底贵在哪里。

如果只是让一个 Agent 去查一个文件、修一个小 bug、总结一篇文章，那不需要 Harness。直接派一个 subagent 就行。

但任务一复杂，问题马上变味。

比如你想让十几个 Agent 同时扫一个代码库，有的看安全，有的看性能，有的看测试，有的看架构。每个 Agent 都会返回一堆结果，有些结果互相冲突，有些结果需要二次验证，有些任务失败后还要重试。

这时候你要处理的不是 “怎么问 AI”，而是这些脏活：

编排问题

具体含义

并发控制

哪些 Agent 同时跑，哪些必须等前一步完成

限流重试

某个 Agent 失败后要不要重跑，怎么避免无限重试

中间状态

每个阶段的结果放哪里，下一步怎么读取

结果聚合

多个输出怎么合并、去重、互相校验

这些东西以前大多要人来写。

会写的人，可以把 Agent 变成一支队伍。不会写的人，只能在主对话里不断派小弟，然后看着中间结果一点点把上下文塞满。

这就是 Harness 曾经能形成壁垒的原因。

不是因为这个词高级，而是因为它确实把 AI 使用分成了两类人：一类人在调度系统，一类人在反复聊天。

Dynamic Workflows 拆的是调度层

Dynamic Workflows 的变化，不在于它也能派 subagent。

变化在这里：它把调度逻辑从主对话里剥出来，写成一段后台运行的脚本。

按现有资料看，Claude Code 会根据任务临场生成一段 JavaScript workflow 脚本。脚本里可以通过 agent() 调用派生 subagent，循环、分支、中间变量、阶段结果，都可以在脚本里流转。

主对话不再背着所有过程往前走。

以前你派 10 个 subagent，10 份中间结果都回来，Claude 的上下文越来越胖。跑到后面，模型未必是真的不会判断，更多时候是被过程垃圾稀释了注意力。

Workflow 的做法是把这些过程信息留在调度层里。 主 Agent 最后只需要读最终结果，或者读被整理过的关键结论。

这就像以前你在群里手动催每个人交活，所有聊天记录都堆在一个窗口里。现在多了一个项目经理脚本，自己分配任务、记录进度、收集结果，最后给你一份汇总。

当然，这不是魔法。

它仍然要烧 token。几十上百个 agents 一起跑，账单不会凭空消失。它也不适合一两步就能完成的小任务，更不适合需要你频繁拍板的探索工作。

但它改掉了一个关键问题：调度层不再必须由人提前写好。

这就是 Harness 壁垒开始崩的地方。

Subagent、Skill、Workflow 不是一回事

很多人容易把这几个东西混在一起。

其实最简单的区分方式是：谁握着计划。

方式

谁握着计划

中间结果在哪里

更适合什么

Subagent

主 Agent

主对话上下文

单点调查、局部修复

Skill

主 Agent + SOP

主对话上下文

标准流程、固定任务

Workflow

调度脚本

后台流程 / 脚本变量

多 Agent 并行、复杂工程

Subagent 像派一个人出去跑腿。

你告诉它去查一个问题，它查完回来，把结果交给主 Agent。简单、直接、好用，但每次结果都要回到主上下文里。

Skill 像一本 SOP。

它告诉 Agent 遇到某类任务应该怎么做，先读什么、后跑什么、哪些坑不要踩。它解决的是“经验沉淀”的问题，但主 Agent 还是一边读 SOP，一边判断下一步。

Workflow 更像一个调度室。

它不是只告诉 Agent 怎么做，而是把“怎么派活、怎么分支、怎么循环、怎么汇总”写成一段可以运行的逻辑。

所以这三者不是谁淘汰谁。

小任务用 subagent 很合理。固定流程用 skill 很合理。遇到需要并行、分支和状态管理的复杂任务，才轮到 Workflow 出场。

这也是为什么我不喜欢把 Dynamic Workflows 写成“更强的 subagent”。

它强的不是小弟更聪明，而是 它开始搭调度层。

Subagent 是派人跑腿，Skill 是发一本 SOP，Workflow 是把调度室搭起来。

这不是 Anthropic 一家的动作

这件事如果只放在 Claude Code 里看，会被误读成一个新功能。

但它不是 Anthropic 的自嗨。

OpenAI 的 Codex 也在用 /goal 模式接近类似的问题：让 Agent 围绕一个目标拆解任务、持续推进。Gemini、社区工具、各种手搓编排框架，也都在往“让 AI 自己拆任务、调度 Agent 队伍”这个方向靠。

路径不一样，产品形态也不一样，但气味已经很明显了。

接下来半年，AI 工具圈大概率会反复讨论同一个问题：怎么让 Agent 自己拆任务、自己调度、自己沉淀出可复用的 Harness。

这会是新一轮火爆点。

大家抢的也不只是“谁更会写代码”。

写代码只是执行层。再往上走，比的是谁能把一个大目标拆成多个可并行的小目标，谁能让多个 Agent 分头工作，谁能在后台控制状态、成本和结果质量。

换句话说，Coding Agent 赛道正在抢调度层。

以前你用 Agent，更多是在使用一个能力很强的个体。以后你用 Agent，可能是在临时组建一个小团队。

这对一个人公司尤其关键。

一个人公司最大的问题，从来不只是“我能不能多干一点活”。而是当事情变复杂后，你能不能把需求、调研、写作、代码、审核、发布这些环节组织起来，让它们不要全挤在一个脑子里。

Harness 这层能力被产品化之后，个人和小团队第一次有机会更自然地调度一支 Agent 队伍。

所以它讲的不是 Claude Code 多了一个按钮，而是 AI 使用方式正在换挡。

壁垒没有消失，只是换了位置

当然，“人人创建 Harness”不等于人人都能用好 Harness。

这句话要说清楚。

崩掉的是旧壁垒：只有技术人员能写编排代码，只有少数人能搭 Agent 调度层。

新的壁垒马上会出现，而且更像管理能力。

你得说清楚目标。

如果目标含糊，Workflow 只会更快地把含糊扩散出去。一个 Agent 理解错还好，十几个 Agent 同时沿着错误方向跑，最后你会得到一份看起来很完整、但根上就歪了的报告。

你得拆清楚边界。

哪些 Agent 只能读，不能改；哪些任务必须独立验证；哪些文件不能碰；哪些结论需要标来源；哪些结果只能给建议，不能自动执行。

你还得控制成本。

Workflow 是用并行换效率，并行本身就是成本。复杂任务可以跑，简单任务乱开 Workflow，就是用重型机械拧螺丝。

最后，你得会验收。

多个 Agent 给出的结果，不会因为数量多就自动正确。它们可能互相重复，也可能互相矛盾。使用者要能判断哪些结论有证据，哪些只是听起来合理。

所以壁垒没有归零。

它只是从 “会不会写 Harness”，搬到了 “会不会定义一个可执行、可控、可验收的目标”。

以前的高阶玩家会写编排。

后面的高阶玩家，要会 验收一支 Agent 队伍。

人人创建 Harness 后，稀缺的是会派活

我很喜欢“人人创建 Harness 的时代来了”这个判断，因为它够锋利。

它说的不是大家突然都变成架构师了，而是原来卡在编排代码上的那道门，正在被 Agent 自己推开。

不会写 Harness，不再是一个很好的借口。

但 不会定义目标、不会设边界、不会控预算、不会验收结果，仍然跑不出可靠交付。

这件事越往后走，人的角色会越像一个小团队的负责人。

你不一定亲手写每一段调度代码，但你要知道任务应该怎么分、风险应该拦在哪里、最后的结果怎么算合格。

一个人公司也是这样。

缺人手的时候，Agent 可以补人手。缺组织能力的时候，更多 Agent 只会制造更多混乱。

Harness 壁垒崩塌之后，差距不会消失。

差距会转移到另一个地方：谁更会把 Agent 变成岗位，把任务变成流程，把流程变成可复用资产。

Agent 不再缺小弟，缺的是会派活的人。

---

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。