Claude Code 2.1.149 被藏起来的 Workflows，也许是 Harness

Claude Code 2.1.149 这次最值得看的东西，是 Workflows，虽然已经从 changelog 删除。

这个功能还不完美。体验需要通过 env 配置才用得到，类似：

CLAUDE_CODE_WORKFLOWS=1

你可以说这是一个实验，但是。

因为只要看一眼它生成的 workflow js，再看一眼 run 记录，就知道这东西不是普通 slash command。

它更像 Claude Code 内部正在长出来的一层 Agent 编排控制面。

说得再简单一点：Claude Code 不只是想让一个 Agent 更会写代码，它开始想管一群 Agent 怎么一起干活。

这件事比“多 Agent”本身重要。

我为什么不直接叫它 Harness

一开始我也想叫它“小型 Harness”。

后来想了下，这个说法有点快。

完整 Harness 应该有很多硬性东西：任务图、artifact ledger、evidence protocol、独立 validator、milestone sealing、失败后的 triage / repair loop、权限分层、稳定恢复、可审计记录。

Workflows 现在还没有完整露出这些。

但它已经有骨架。

workflow js 会落盘。
run 有 runId。
脚本有 meta。
任务有 phases。
Agent 有 label。
结果可以走 schema。
运行记录里能看到 agentCount、durationMs、totalTokens、totalToolCalls。
子 Agent 的 transcript 也会被放到对应 workflow run 目录下。

这就不是“一个 prompt 包装器”了。

它已经在做执行系统该做的事：命名、分阶段、调度、记录、统计、汇总。

所以我更愿意这样定义它：

Claude Code Workflows 是一个实验性的 Agent 编排控制面。它已经露出 Harness 的骨架，但还不是完整 Harness。

这个判断比“多 Agent 功能”更接近它的真实位置。

看 workflow js，比看名字有用

一个 workflow js 大概长这样：

export const meta = {
  name: 'mini-branch-review',
  description: 'Review current branch with finder and verifier agents',
  phases: [
    { title: 'Find' },
    { title: 'Verify' },
    { title: 'Synthesize' },
  ],
}

phase('Find')

const reviews = await parallel([
  () => agent('Find correctness bugs in the current branch.', {
    label: 'correctness',
    phase: 'Find',
  }),
  () => agent('Find architecture issues in the current branch.', {
    label: 'architecture',
    phase: 'Find',
  }),
])

phase('Synthesize')

return reviews

这段代码很短，但信息量不小。

meta 说明它是一个被命名的任务单元，不是临时对话。

phases 说明它有阶段模型。Find、Verify、Synthesize 这些词不是写给人类看的标题，它们会进入运行记录和进度展示。

agent() 说明 subagent 在这里变成了执行节点。

parallel() 说明它能并发调度多个节点。

schema 则更关键。它可以要求 Agent 输出结构化结果，而不是一篇自然语言报告。

这些东西拼起来，Claude Code 的形态就变了。

以前是：

用户 -> Claude -> 工具

现在开始像：

用户 -> Workflow -> 多个 Agent -> 结构化结果 -> 验证/汇总

这不是交互体验上的小改动。

这是执行模型变了。

多 Agent 本身不值钱

这几年 multi-agent 已经快被讲烂了。

一个 Agent 写代码，一个 Agent review，一个 Agent 跑测试。demo 看着很爽，真实项目里经常一地鸡毛。

我见过最典型的失败模式是这样的：

A Agent 改了接口。
B Agent 还按旧接口写测试。
C Agent review 的时候指出一个不存在的问题。
最后主 Agent 把三份结果整理成一份非常顺滑的总结。

你读完会觉得“流程完整”。

但其实从第一步就歪了。

所以我现在对多 Agent 很警惕。没有调度，没有边界，没有验证，多 Agent 只是把错误并行化。

Workflows 真正有意思的地方，是它开始回答“怎么管 Agent”。

谁先跑？
谁并行？
谁等谁？
谁的输出给谁用？
输出要不要结构化？
哪些步骤能统计？
哪些结果能追踪？
哪里需要 verifier 反驳？

这些问题，才是 Agent Harness 要解决的问题。

`schema` 是一个分水岭

自然语言报告很好看，但很难继续处理。

比如一个 Agent 输出：

我发现缓存更新路径可能存在问题，更新后旧 key 没有被清理，可能导致用户看到旧数据。

人能读懂。

但下一个 Agent 要验证它，就得重新解析这段话。文件在哪？严重程度是什么？证据是什么？不确定性在哪里？

如果 finder 输出的是 JSON，就不一样：

{
  "findings": [
    {
      "title": "缓存失效条件遗漏",
      "file": "src/cache.ts",
      "severity": "medium",
      "evidence": "更新路径没有清理旧 key"
    }
  ]
}

Verifier 可以直接消费这条 finding，再输出：

{
  "confirmed": false,
  "reason": "调用方在更上层已经统一清理缓存，finding 不成立"
}

这一步非常关键。

一旦结果结构化，Agent 就不再只是“会写解释的人”。它变成了 workflow graph 里的一个节点。

节点有输入，有输出，有契约。

这是从聊天走向执行系统的分界线。

finder / verifier 分离，才是它最该做的事

如果 Workflows 只用来多找几个问题，价值有限。

我觉得它最该用在 finder / verifier 分离上。

Finder 负责提出候选问题。
Verifier 负责反驳候选问题。
Synthesizer 只保留反驳后还成立的结果。

这里的关键是 verifier 要有敌意。

prompt 不能写成：

请验证这个 finding 是否成立。

这样太温和了。

更好的写法是：

请尽量反驳这个 finding。
如果证据不够，就判为不成立。
不要帮 finder 圆场。

这是一个很小的差别，但结果会差很多。

LLM 很容易顺着自己刚才说过的话继续写。Finder 刚提出一个 bug，如果你让同一个语气的 Agent 去“验证”，它往往会帮这个 bug 找证据。

Workflow 的价值，就是把这种角色分开。

一个 Agent 提出。
另一个 Agent 拆台。
最后只留下拆不掉的。

这比“多开几个 Agent”有意义多了。

run 记录暴露了它的执行系统

我更关心的其实不是 workflow js，而是 run 记录。

一个普通 slash command 跑完就完了。

Workflow 不一样。

它会留下 run。里面能看到脚本、路径、阶段、agent 数量、日志、耗时、token、tool call、最终 result。子 Agent 的 transcript 也会放在 workflow 对应目录里。

这说明 Claude Code 不只是让 Agent 跑起来，还在记录它们怎么跑。

这点很关键。

因为长任务最怕的不是失败，而是不知道失败在哪里。

如果一个 branch review 开了 10 个 Agent，其中 2 个超时，3 个产出为空，1 个 verifier 误判，你需要知道是哪一步出了问题。否则最后 synthesis 再漂亮，也没法信。

Workflows 现在的可观测性还不算完整，但方向已经对了。

它开始让 Agent 工作变成可以追踪的执行过程。

不是一团聊天记录。

为什么它要藏在 env 后面

我觉得这很正常。

Workflows 不是一个无害功能。

单 Agent 出错，风险通常还在一个对话里。Workflow 出错，可能是一串 Agent 一起读文件、跑工具、开 worktree、写结论。

更麻烦的是，它改变了用户和 Claude Code 的关系。

以前你是一句一句看着它干活。
Workflow 更像是你给一个目标，它自己拆任务、调 Agent、跑一段时间，再把结果交回来。

这对权限、成本、隔离、日志、恢复，都提出更高要求。

所以它需要 env gate，我不觉得奇怪。

一个能调度多个 Agent 的功能，如果默认开放，用户很容易直接来一句：

彻底审完整个仓库，越深越好。

然后 token 开始飞，权限开始弹，工作区开始热闹。

最后你可能得到一份“看似被验证过”的错误报告。

多 Agent 不会自动更安全。
它只会让边界问题变得更大。

它还不是完整 Harness

Workflows 现在有骨架，但还没长完整。

我会期待一个完整 Harness 至少有这些东西：

明确的 task graph UI
每个节点的输入、输出、状态
artifact ledger
evidence protocol
validator 和 worker 隔离
milestone sealing
失败后的 triage / repair loop
更细粒度权限
稳定恢复语义
和测试、lint、浏览器、CI 的硬连接

现在 Workflows 已经有一些底层 primitive：

meta
phases
agent()
parallel()
schema
scriptPath
run record
token / tool call stats

可能还有运行时暴露出来的 pipeline()、budget、resumeFromRunId、workflow nesting。

但这些还不等于完整产品。

所以文章里不要把它吹成“Claude Code 已经内置完整 Harness”。

更准确的说法是：

Workflows 是 Claude Code 内部 Agent Harness 的一块外露骨架。

这个说法比较克制，但够有判断。

Skill、Agent、Workflow 的关系也因此变清楚了

Workflows 露出来之后，Claude Code 里的几个概念反而更好理解了。

Skill 是方法卡片。

比如 /diagnose 是排障方法，/review 是审查方法，/mission 是大任务推进方法。它告诉 Claude Code 应该按什么规程做事。

Agent 是执行单元。

它可以读代码、查资料、找问题、验证结论。

Workflow 是编排控制面。

它把方法和执行单元组织成一个过程。

这个过程可以分阶段，可以并行，可以结构化输出，可以记录运行痕迹。

所以它不是 Skill 的替代品，也不是 Agent 的替代品。

它是 Skill 和 Agent 上面那层“怎么组织”的东西。

2.1.149 附近那些小更新，放在一起看就不小了

单看 2.1.149 的公开 changelog，很多都是小修：

/usage 展示 skills、subagents、plugins、MCP server 成本拆分
remote session 相关修复
skill / agent 状态栏显示修复
权限和 sandbox 相关修复
Bash find 资源耗尽修复
/ultraplan 和远程 session 创建修复

这些每条都不惊人。

但如果放在 Workflows 这个方向下看，就有另一层意思。

Claude Code 里的 agent 工作正在变多。
agent 工作一多，就需要 usage 可见。
需要 subagent 状态。
需要 remote session 稳定。
需要权限修补。
需要 sandbox 边界。
需要后台任务和恢复。

Workflows 不是孤立冒出来的。

它更像是这条线上的一个明显信号：Claude Code 正在从单 Agent 交互，往可调度 agent 工作系统走。

这对 Claude Code 意味着什么

过去看 Claude Code，我们经常看模型：

Opus 强不强。
Sonnet 快不快。
上下文够不够。
tool use 稳不稳。

这些当然还重要。

但 Workflows 指向的是另一个竞争点：

谁能把一群不稳定的 Agent，组织成一个可追踪、可验证、可恢复、可控成本的软件工程过程。

这比“模型再聪明一点”更接近真实交付。

真实团队也不是靠一个天才工程师写完整个系统。真实团队靠分工、接口、review、CI、回滚、验收和责任边界。

Agent 也一样。

一个 Agent 再强，也会漏、会猜、会自信过头。Workflow 的价值不是让这些问题消失，而是把这些问题关进流程里。

Finder 只负责找。
Verifier 负责拆。
Schema 负责约束输出。
Run record 负责留下痕迹。
测试和 CI 负责最终裁判。

这才是 Claude Code Workflows 让我在意的地方。

它不是一个正式宣言。

changelog 变过。
env gate 挡着。
文档还没铺开。

但 workflow js 已经把路线漏出来了。

Claude Code 不只想做一个会写代码的 CLI。它在试着长出一个本地 Agent Harness。

还没长完。

但骨头已经能看见了。

现目前最好的 Harness - Factory Droid Missions

Factory Missions - Factory Documentation

Mission Control orchestration view

Claude Code 2 1 149 藏起来的 Workflows，露出了 Agent Harness 的骨架