Claude Code 新功能实战：Goal、Workflows 与后台代理

0. 先把环境打到可实验状态#

需要确认的点：

• Dynamic workflows 是否开启；Pro 用户要在 /config 里打开 Dynamic workflows
• Ultracode keyword trigger 是否开启；它决定 ultracode: 关键字是否触发 workflow
• 当前 permission mode 是否适合后台任务；长任务不要靠交互确认硬撑
• 项目是否已 trust；/goal 依赖 hooks 系统，未信任 workspace 会被拦

我会先给项目写一份保守的 .claude/settings.json，让后台代理能跑本地验证，但碰不到远程危险操作：

1
{
2
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
3
  "permissions": {
4
    "defaultMode": "normal",
5
    "allow": [
6
      "Read",
7
      "Edit",
8
      "Glob",
9
      "Grep",
10
      "Bash(git status)",
11
      "Bash(git status --short)",
12
      "Bash(git diff *)",
13
      "Bash(pnpm check)",
14
      "Bash(pnpm build)",
15
      "Bash(pnpm test *)",
16
      "WebSearch"
17
    ],
18
    "deny": [
19
      "Read(**/.env)",
20
      "Read(**/.env.*)",
21
      "Bash(git reset --hard *)",
22
      "Bash(git push --force *)",
23
      "Bash(rm -rf *)",
24
      "Bash(Remove-Item * -Recurse *)",
25
      "mcp__github__merge_*",
26
      "mcp__github__delete_*"
27
    ]
28
  }
29
}

这段配置的目标很直接：让 Claude 自己能读代码、改文件、跑构建、跑测试、看 diff；但远程写、强推、硬删、读密钥全部拦住。后面讲的 /goal 和 workflows 都建立在这个权限基线上。

1. /goal 的本质：会话内控制循环#

/goal 不是计划工具，也不是 todo list。它更像给当前会话挂了一个 Stop hook：

1
/goal pnpm check exits 0, pnpm build exits 0, and git status --short only shows expected source changes

设置后，Claude 会立刻开始第一轮。每轮结束后，Claude Code 把目标条件和当前 transcript 发给一个小模型做判断。如果判断为 no，小模型会给出原因，Claude 用这个原因继续下一轮；如果判断为 yes，goal 自动清除。

可以把它想成这个循环：

1
goal = "pnpm check exits 0 and pnpm build exits 0"
2

3
while true:
4
  main_model.run_next_turn(goal, evaluator_reason)
5
  transcript.append(turn_output)
6

7
  decision = fast_model.evaluate(goal, transcript)
8
  if decision == "yes":
9
    clear_goal()
10
    break
11

12
  evaluator_reason = decision.reason

这里有两个技术细节很重要：

• 评估器默认使用你配置的小快模型，官方文档里说默认是 Haiku；评估 token 通常比主轮次小很多
• 评估器不会自己调用工具，不会自己读文件，只能判断 transcript 里已经出现的证据

所以 goal 不能写成：

1
/goal make the code good

它应该写成：

1
/goal pnpm test test/auth exits 0, pnpm check exits 0, and git diff contains no unrelated formatting-only changes

2. 写 goal 要像写 CI 断言#

我的写法是把 goal 当成“人类可读的 CI 断言”。它至少包含三段：

1
/goal <最终状态>, verified by <命令或证据>, without <禁止副作用>

几个可直接复制的例子：

1
/goal all failing tests in test/auth pass, verified by pnpm test test/auth, without modifying production auth behavior outside src/auth

1
/goal every import from @/legacy/client under src/modules/payment is migrated to @/api/client, verified by rg \"@/legacy/client\" src/modules/payment returning no matches and pnpm check exiting 0

1
/goal CHANGELOG.md has one entry for every merged PR listed in docs/release-prs.md, and git diff only touches CHANGELOG.md

长任务一定要写预算条件：

1
/goal migrate src/modules/search to the new query client, verified by pnpm test src/modules/search and pnpm check, or stop after 10 turns with a remaining-work checklist

状态查看：

1
/goal

提前清除：

1
/goal clear

非交互模式也能跑：

1
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week, verified by reading docs/release-prs.md"

如果一个 active goal 所在会话被关闭，之后用 --resume 或 --continue 回来，goal 条件会恢复，但计时、turn count 和 token baseline 会重置。已经完成或清除的 goal 不会恢复。

3. /goal + auto mode：一个管权限，一个管轮次#

auto mode 和 /goal 经常被混用，但它们在控制流里位置不同：

1
user prompt
2
  -> main model turn
3
    -> tool call
4
      -> permissions.deny
5
      -> auto mode classifier
6
      -> tool executes
7
  -> turn ends
8
    -> /goal evaluator
9
      -> next turn or clear

auto mode 解决的是“这个工具调用要不要问你”；/goal 解决的是“这一轮结束后要不要自动开下一轮”。

如果你要让 Claude 在本地自己修测试，我会这样配：

1
{
2
  "permissions": {
3
    "allow": [
4
      "Read",
5
      "Edit",
6
      "Glob",
7
      "Grep",
8
      "Bash(pnpm test *)",
9
      "Bash(pnpm check)",
10
      "Bash(git diff *)",
11
      "Bash(git status --short)"
12
    ],
13
    "deny": [
14
      "Read(**/.env*)",
15
      "Bash(git push *)",
16
      "Bash(git reset --hard *)"
17
    ]
18
  },
19
  "autoMode": {
20
    "hard_deny": [
21
      "Do not publish, deploy, merge, or push to a remote repository.",
22
      "Do not read secrets or environment files.",
23
      "Do not run destructive filesystem cleanup commands."
24
    ]
25
  }
26
}

然后在会话里：

1
/goal pnpm test test/auth exits 0 and pnpm check exits 0, with no changes outside src/auth and test/auth

permissions.deny 是硬门，先于 auto mode classifier。凡是“绝对不能发生”的动作，写 deny，不要只写进 prompt。

4. Dynamic workflows：Claude 写脚本，runtime 跑代理#

Dynamic workflows 的工作方式比 subagents 更像一个后台 job：

1
你的任务描述
2
  -> Claude 生成 workflow JavaScript
3
  -> 你批准 workflow plan
4
  -> runtime 在后台执行脚本
5
  -> 脚本批量启动 subagents
6
  -> agents 返回结构化中间结果
7
  -> 脚本汇总、交叉验证、生成最终报告

脚本运行在隔离环境里。它本身不直接读写文件，也不直接执行 shell；真正的文件读取、编辑、命令执行由它启动的 agents 完成。中间结果保存在脚本变量里，不会把主会话上下文塞爆。

最小入口是官方内置 workflow：

1
/deep-research What changed in the Node.js permission model between v20 and v22?

这个命令会 fan out 多个搜索和阅读角度，抓取来源，交叉检查 claim，最后产出带引用的报告。它比“请你搜索一下”更像一个有 cross-check 阶段的 research pipeline。

查看运行状态：

1
/workflows

在 workflow 面板里常用按键：

5. 用 ultracode 触发自定义 workflow#

如果你想让 Claude 为当前任务写一个 workflow，最直接的方式是加 ultracode:：

1
ultracode: audit every API route under src/pages/api for missing authentication. Split by directory, have independent agents cross-check findings against middleware and tests, then return only verified vulnerabilities with file path, route, and reproduction condition.

也可以在会话里打开全局努力级别：

1
/effort ultracode

这会让 Claude 对每个实质性任务都倾向于规划 workflow。这个模式很猛，也更贵。我只会在代码库级审计、系统性迁移、复杂设计评审时开，普通修 bug 用 high 就够了。

触发 workflow 时，CLI 会先展示 planned phases。你可以：

• 直接运行
• 查看 raw script
• 用 Ctrl+G 打开脚本
• Tab 调整 prompt
• 选择以后对同名 workflow 不再询问

不同 permission mode 的提示行为不一样：

更关键的是：workflow 生成的 subagents 会以 acceptEdits 模式运行，并继承你的 tool allowlist。文件编辑会自动批准，但 shell、WebFetch、MCP 如果不在 allowlist 里，仍可能在半路请求确认。

所以长 workflow 开跑前，先把它会用到的命令写清楚：

1
{
2
  "permissions": {
3
    "allow": [
4
      "Read",
5
      "Grep",
6
      "Glob",
7
      "Edit",
8
      "Bash(pnpm test *)",
9
      "Bash(pnpm check)",
10
      "Bash(rg *)",
11
      "WebSearch",
12
      "mcp__github__get_*",
13
      "mcp__github__list_*"
14
    ],
15
    "deny": [
16
      "mcp__github__merge_*",
17
      "mcp__github__delete_*",
18
      "Bash(git push *)"
19
    ]
20
  }
21
}

6. 保存 workflow：把一次编排变成可复跑命令#

Workflow 跑起来后，Claude Code 会把脚本写到当前 session 目录下，路径在 ~/.claude/projects/ 里。你可以在会话里问 Claude：

1
show me the workflow script path for the last run

如果这个 run 的编排质量不错，在 /workflows 面板里按 s 保存。两个位置：

1
.claude/workflows/       # 项目级，进仓库，团队共享
2
~/.claude/workflows/     # 用户级，所有项目可用，只给自己

保存后它会变成 slash command：

1
/security-audit src/server

保存的 workflow 可以接收输入，脚本里通过全局 args 读取。你可以这样调用：

1
Run /triage-issues on issues 1024, 1025, and 1030

Claude 会把 issue 列表作为结构化数据传进去，而不是让脚本自己解析一段字符串。这点很实用：同一个 workflow 可以处理不同路径、不同 issue、不同 release 范围。

我通常会让 Claude 在保存前做一次“脚本解释”：

1
Explain the workflow script phases, the agent prompts, what args it expects, and where it may spend the most tokens.

看懂以后再放进 .claude/workflows/。项目级 workflow 本质上是团队自动化资产，别把实验脚本随手提交。

7. 一个真实工作流：安全审计到修复闭环#

下面是我会在真实项目里跑的一组命令。

第一步，用 workflow 做 fan-out 审计：

1
ultracode: audit src/pages/api and src/server for missing authorization. Split the work by route group. Each finding must be independently verified by a second agent against middleware, tests, or call sites. Return only verified issues in a markdown table with file, route, risk, evidence, and suggested fix.

第二步，把报告保存下来：

1
write the verified findings to docs/security-audit.md

第三步，用 /goal 进入修复闭环：

1
/goal every verified issue in docs/security-audit.md is fixed, pnpm test exits 0, pnpm check exits 0, and docs/security-audit.md marks each issue as fixed with the commit-relevant file path

这个组合的重点是分工：

• workflow 负责大规模发现问题和交叉验证
• 文档文件负责把中间结果落盘
• /goal 负责持续修复直到验收条件成立
• pnpm test / pnpm check 负责把“感觉修好了”变成可验证事实

这比直接说“帮我全面检查并修复安全问题”稳定得多，因为每一层都有明确产物。

8. /loop、routines 和 workflow 的技术差异#

/loop 是 bundled skill，负责在当前会话里重复运行提示词：

1
/loop 5m check whether CI passed and summarize the latest failure

也可以只写 prompt，让 Claude 自己选择间隔：

1
/loop check whether CI passed and address any review comments

项目级默认 prompt 可以写到：

1
.claude/loop.md

用户级默认 prompt 可以写到：

1
~/.claude/loop.md

裸 /loop 会读取这些默认 prompt。它适合短期轮询，不适合大规模并行，也不适合离线云端任务。

Routines 是 Claude Code on the web 的云端自动化：按 schedule、API call 或 GitHub event 触发，不依赖你本机开着。Desktop scheduled tasks 则适合需要本地文件和工具的周期性任务。

我会这样记：

9. 成本和失控保护#

Workflows 很容易把 token 用量拉高。官方限制是单次最多 16 个并发 agents，单次最多 1000 个 agents，但这不代表你应该让它跑满。

我的成本控制模板：

1
ultracode: run the audit only on src/modules/auth first. Use at most 6 agents. Report the phase plan and estimated token-heavy steps before expanding to other modules.

运行中看 /workflows，重点看：

• 哪个 phase token 飙升
• 是否有 agent 卡在同一路径反复搜索
• 是否有大量未验证 claim
• 是否需要停掉 run，缩小范围重来

如果你要完全禁用 workflow：

1
{
2
  "disableWorkflows": true
3
}

或者用环境变量：

1
export CLAUDE_CODE_DISABLE_WORKFLOWS=1

Windows PowerShell：

1
$env:CLAUDE_CODE_DISABLE_WORKFLOWS = "1"

调度器也可以整体关掉：

1
export CLAUDE_CODE_DISABLE_CRON=1

这些开关适合 CI、生产运维仓库、强合规环境。不是所有项目都需要多代理后台任务。

总结#

Claude Code 现在可以按三层来用：

1. 单会话执行层：普通提示词、Skill、subagents
2. 持续控制层：/goal、/loop、Stop hooks
3. 后台编排层：dynamic workflows、agent view、routines

真正的变化是第二层和第三层。你不再只能盯着一轮回复，而是可以给 Claude 一个可验证终点，或者让它写一段可复跑的多代理编排脚本。

我的建议很简单：把 /goal 当 CI 断言写，把 workflow 当后台 job 设计。命令、证据、权限、产物都写清楚，Claude Code 才会从“会聊天的 CLI”变成真的工程工具。