跳至主要内容

为什么 AI 干活总是半吊子？Multi-Agent 动态工作流

Fen9Pi2026/6/16AI AgentAI Agent大约 14 分钟

题图 "

为什么 AI 干活总是"半吊子"？Multi-Agent + 动态工作流，让 AI 学会团队作战

你有没有遇到过这种情况：

跟 AI 对话半天，它终于把任务干到一半，突然卡住了。

比如你让 AI "帮我分析一个项目并给出优化建议"：

  • 前半段，它分析代码很顺利
  • 后半段，要写优化方案时，开始胡言乱语
  • 最后你不得不手动接手，把活干完

这不是 AI 笨，而是单 Agent 的天然局限。

就像让一个全栈工程师同时搞定前端、后端、运维、测试，他能行，但肯定干不过一个团队。

今天我们聊聊 Multi-Agent + 动态工作流，这是让 AI 从"一个人"变成"一支队伍"的关键技术。

为什么 AI 干活总是"半吊子"？

先看一个真实场景。

假设你让 AI "部署一个 Web 应用到生产环境"：

Round 1： AI 开始分析项目结构

  • 读 package.json
  • 找入口文件
  • 分析依赖

Round 2： AI 开始写 Dockerfile

  • 生成基础镜像配置
  • 添加构建步骤
  • 配置端口映射

Round 3： AI 开始部署

  • 写 docker-compose.yml
  • 配置环境变量
  • 启动容器

Round 4： 突然卡住了

  • 测试失败了，AI 不知道该修哪里
  • 性能有问题，AI 不会优化
  • 安全漏洞，AI 不懂怎么修补

最后还是得你亲自上阵。

这不是 AI 不努力，而是单 Agent 的架构问题。

单 Agent 的死穴：一只手抓不了两条鱼

单 Agent 的核心问题是什么？

注意力分散。

一个 Agent 要同时干好几件事：

  • 理解需求
  • 分析代码
  • 编写配置
  • 执行测试
  • 处理错误
  • 优化性能

结果就是：

  • 干得越多，错得越多
  • 任务越复杂，越容易"半路翻车"
  • 遇到边界情况，不知道该优先处理什么

这就像让一个厨师同时切菜、炒菜、摆盘、洗碗，肯定干不过一个有分工的厨房团队。

更致命的是：单 Agent 无法并行处理任务。

比如 "分析 10 个文件的代码质量"，单 Agent 只能：

  1. 读文件 A → 分析 → 记住结论
  2. 读文件 B → 分析 → 记住结论
  3. ...
  4. 最后汇总

中间任何一个步骤出错，全盘崩溃。

而 Multi-Agent 可以：

  • Agent 1-10 并行分析 10 个文件
  • Agent 11 汇总结果
  • 任何一个出错，只影响自己那部分

这就是 Multi-Agent 的核心价值：分工 + 并行 + 容错。

Multi-Agent：从"一个人"到"一支队伍"

Multi-Agent 不是简单的"多调用几次 AI"，而是真正的团队协作。

一个真实的 Multi-Agent 案例

假设要做一个"竞品分析报告"，单 Agent 的流程是：

1. 搜索竞品信息
2. 分析产品功能
3. 对比价格
4. 总结优劣势
5. 写报告

一步错，步步错。

而 Multi-Agent 的流程是：

Agent PM（任务分解）：
  - 定义分析维度（功能、价格、用户评价）
  - 分配子任务

Agent Researcher-1（调研竞品 A）：
  - 搜索产品信息
  - 分析功能列表
  - 输出结构化数据

Agent Researcher-2（调研竞品 B）：
  - 搜索产品信息
  - 分析功能列表
  - 输出结构化数据

Agent Analyst（数据分析）：
  - 对比功能差异
  - 计算价格差距
  - 总结优劣势

Agent Writer（撰写报告）：
  - 整合所有数据
  - 生成 Markdown 报告
  - 检查格式和逻辑

Agent Reviewer（审核）：
  - 检查数据准确性
  - 验证结论合理性
  - 提出修改意见

注意： 这 6 个 Agent 可以并行工作。

Researcher-1 和 Researcher-2 同时跑，互不干扰。

Analyst 等 Researcher 完成后开始，Writer 等 Analyst 完成后开始。

最后 Reviewer 检查一遍，有问题打回去重来。

Multi-Agent 的四种协作模式

根据 Claude Code 团队的实践，Multi-Agent 有四种主流模式：

1. 转交模式（Handoff）

任务在 Agent 间顺序传递：Agent A → Agent B → Agent C

适用场景： 流水线式任务，如"代码审查 → 修改 → 测试"

2. 分治模式（Divide & Conquer）

主任务分解为子任务，多个 Agent 并行处理，最后汇总

适用场景： 可并行的大任务，如"分析 100 个文件的代码质量"

3. 协作模式（Collaborative）

多个 Agent 同时处理同一个任务，各自负责不同维度

适用场景： 多维度分析，如"从性能、安全、可维护性三个角度评估代码"

4. 辩论模式（Debate）

多个 Agent 提出不同方案，通过辩论选出最优解

适用场景： 方案选型，如"选择技术栈时，让不同 Agent 代表不同技术辩护"

动态工作流：让 AI 学会"见招拆招"

Multi-Agent 解决了"分工"问题，但还有一个难题：怎么协调？

传统做法是"静态工作流"：

1. Agent A 干活
2. 干完交给 Agent B
3. Agent B 干完交给 Agent C
4. 出错了？重来

这种模式的致命伤是：无法应对不确定性。

比如 Agent B 干了一半发现"这个任务需要更多信息"，怎么办？

  • 停下来等 Agent A？
  • 自己去搜索？
  • 把任务打回去？

静态工作流没法处理这种情况。

动态工作流的核心是：让系统根据中间结果动态调整下一步。

Claude Code 的动态工作流实践

Anthropic 工程师 Thariq 在分享中提到：

动态工作流允许 Claude 根据具体任务即时编写定制化执行框架，协调多个子 Agent 并行工作。

这段话的核心是："即时编写定制化执行框架"。

也就是说，不是预设固定的流程图，而是让 AI 根据当前任务动态决定：

  • 下一步该哪个 Agent 上
  • 是否需要拆分任务
  • 是否需要并行处理
  • 出错了怎么恢复

一个动态工作流的例子

假设任务是"优化一个慢查询"：

静态工作流：

1. 分析 SQL
2. 添加索引
3. 测试性能
4. 结束

如果第 2 步发现"已经加了索引但还是慢"，怎么办？静态工作流卡住了。

动态工作流：

1. Agent 分析 SQL
2. Agent 发现"索引已存在"
3. Agent 动态决策：检查表结构
4. Agent 发现"表数据量过大"
5. Agent 动态决策：建议分表
6. Agent 生成分表方案
7. Agent 测试性能
8. 如果还是慢，回到第 1 步重新分析

每一步都是根据前一步的结果动态决定的，不是预设的。

这就是动态工作流的威力：见招拆招，不按套路出牌。

Goal：不是任务，是"成功标准"

在 Multi-Agent 和动态工作流中，"Goal"是什么？

很多人理解错了。

Goal 不是"要做什么"，而是"什么叫成功"。

错误的 Goal 定义

Goal：写一个登录页面

这不是 Goal，这是 Task。

为什么？因为"什么叫写完"没有标准。

  • 写完了 HTML 就算完？
  • 还要加 CSS？
  • JavaScript 呢？
  • 表单验证？
  • 安全检查？

正确的 Goal 定义

Goal：用户能在 30 秒内成功登录，登录成功率 > 95%

这才是 Goal。

因为它定义了成功标准：

  • 不关心具体实现（可以用现成的 OAuth）
  • 不关心步骤（可以直接用框架）
  • 只关心结果（30 秒内，95% 成功率）

Goal 在 Multi-Agent 中的作用

在 Multi-Agent 系统中，有三个关键角色：

1. Goal Setter（目标设定者）

把模糊的"我想做个登录功能"转化为可度量的 Goal：

  • 输入： "我想做个登录功能"
  • 输出： "用户能在 30 秒内成功登录，登录成功率 > 95%"

2. Goal Keeper（目标守护者）

监控执行过程，确保不偏离 Goal：

  • Agent 在做性能优化？符合 Goal
  • Agent 在加花哨动画？偏离 Goal，打回去
  • Agent 在做安全加固？符合 Goal

3. Goal Evaluator（目标评估者）

最终判断是否达成 Goal：

  • 登录成功率 98%？达成
  • 平均耗时 25 秒？达成
  • 结论：Goal 完成

Goal vs Task 的本质区别

维度TaskGoal
关注点做什么什么叫成功
灵活性固定步骤可选择路径
评估标准做完了吗做对了吗
适用场景简单任务复杂任务

Goal 的本质：把"怎么做"交给 Agent，人类只定义"做成什么样"。

Skill：可复用的"肌肉记忆"

Multi-Agent + 动态工作流 + Goal，这套组合拳已经很强大了。

但还有一个问题：怎么让 Agent 越干越聪明？

答案是：Skill。

Skill 不是 Prompt，是"能力封装"

很多人把 Skill 等同于"好的 Prompt"，这是错的。

Skill 是一个完整的"能力单元"，包括：

  • 清晰的职责定义（这个 Skill 干什么）
  • 标准的输入输出格式（接口规范）
  • 完整的执行逻辑（怎么干）
  • 错误处理机制（出错了怎么办）
  • 最佳实践文档（怎么用效果最好）

一个 Skill 的例子

比如"代码审查 Skill"，它不是一条 Prompt，而是：

Skill：code_review

职责：
  - 检查代码质量
  - 发现潜在 bug
  - 提出优化建议

输入：
  - 代码文件路径
  - 审查维度（性能、安全、可维护性）

输出：
  - 问题列表
  - 严重程度分级
  - 修复建议

执行逻辑：
  1. 静态分析（语法、规范）
  2. 逻辑分析（边界条件、异常处理）
  3. 性能分析（算法复杂度、资源使用）
  4. 安全分析（注入漏洞、权限问题）

错误处理：
  - 文件不存在？返回错误
  - 代码无法解析？返回错误
  - 分析超时？返回部分结果

最佳实践：
  - 一次只审查 < 1000 行代码
  - 优先标记高危问题
  - 提供可执行的修复代码

这才是 Skill，一个完整的能力封装。

Skill 在 Multi-Agent 中的价值

1. 能力复用

一次编写，多次使用。

比如"代码审查 Skill"：

  • Agent A 可以用
  • Agent B 可以用
  • 不同的项目也可以用

不需要每次都重新写 Prompt。

2. 质量保证

Skill 经过验证和优化，比临时写的 Prompt 可靠得多。

就像你写代码：

  • 临时写的脚本 → 容易出 bug
  • 封装成库 → 经过测试，更可靠

3. 知识沉淀

每次使用 Skill，都可以记录：

  • 哪些场景效果好
  • 哪些参数组合最优
  • 常见的错误和解决方法

这些知识沉淀下来，Skill 会越来越聪明。

Skill 的生命周期

1. 识别（发现需要什么能力）
   ↓
2. 设计（定义职责、接口、逻辑）
   ↓
3. 实现（编写 Skill 脚本）
   ↓
4. 验证（测试效果、边界情况）
   ↓
5. 部署（集成到系统）
   ↓
6. 优化（根据使用反馈改进）
   ↓
7. 复用（跨项目、跨 Agent 使用）

Skill 的本质：把"一次性的好 Prompt"变成"可复用的能力库"。

OpenClaw 的实践：sessions_spawn 怎么用？

讲了这么多理论，怎么落地？

以 OpenClaw 为例，看看 Multi-Agent + 动态工作流 + Goal + Skill 怎么配合使用。

sessions_spawn：创建 Subagent 的核心工具

在 OpenClaw 中，sessions_spawn 是创建 Subagent 的标准工具。

基本用法：

sessions_spawn(
    task="分析这个项目的代码质量",
    runtime="subagent",
    mode="run"
)

但这只是最基础的用法，真正强大的地方在于参数组合。

一个完整的 Multi-Agent 案例

假设任务是"从零开始部署一个 Web 应用"：

主 Agent（指挥官）

# 主 Agent 负责任务分解和协调
task = "部署一个 Web 应用到生产环境"

# Step 1: 创建任务分解 Subagent
subtasks = sessions_spawn(
    task=f"将'{task}'分解为可执行的子任务列表",
    runtime="subagent",
    mode="run"
)

# Step 2: 并行创建多个执行 Subagent
agents = []
for subtask in subtasks:
    agent = sessions_spawn(
        task=subtask,
        runtime="subagent",
        mode="session",  # 持久化会话
        cleanup="keep"    # 保留会话以便后续调试
    )
    agents.append(agent)

# Step 3: 创建结果汇总 Subagent
result = sessions_spawn(
    task="汇总以下 Agent 的执行结果并生成部署报告",
    attachments=[
        {"name": "agent1_result", "content": agents[0].result},
        {"name": "agent2_result", "content": agents[1].result},
        # ...
    ],
    runtime="subagent",
    mode="run"
)

Subagent（执行者）

每个 Subagent 职责明确，独立工作：

# Subagent 1: 分析项目结构
task = """
分析项目结构，识别：
- 项目类型（Node.js / Python / Java）
- 依赖管理工具（npm / pip / maven）
- 配置文件位置
- 环境变量需求

输出结构化的项目分析报告。
"""

# Subagent 2: 生成 Docker 配置
task = """
基于项目分析报告，生成：
- Dockerfile（多阶段构建）
- docker-compose.yml
- .dockerignore

要求：
- 镜像大小 < 500MB
- 支持热重载（开发环境）
- 零停机部署（生产环境）
"""

# Subagent 3: 配置 CI/CD
task = """
生成 CI/CD 配置文件：
- GitHub Actions workflow
- 自动测试
- 自动部署

要求：
- 测试覆盖率 > 80%
- 部署时间 < 5 分钟
"""

动态工作流的实现

OpenClaw 的动态工作流通过"主 Agent 实时决策"实现：

# 主 Agent 的决策逻辑
while not goal_achieved:
    # 获取当前状态
    current_state = get_system_status()

    # 动态决策下一步
    decision = sessions_spawn(
        task=f"""
        当前状态：{current_state}
        目标：{goal}

        分析并决策：
        1. 当前状态是否需要人工介入？
        2. 下一步应该哪个 Agent 上？
        3. 是否需要拆分新的 Subtask？
        4. 是否需要调整 Goal？

        输出具体的行动指令。
        """,
        runtime="subagent",
        mode="run"
    )

    # 执行决策
    if decision.action == "spawn_agent":
        new_agent = sessions_spawn(task=decision.task, ...)
    elif decision.action == "adjust_goal":
        goal = decision.new_goal
    # ...

Goal 的定义和检查

# Goal 定义
goal = {
    "success_criteria": {
        "deployment_success_rate": "> 95%",
        "deployment_time": "< 5 minutes",
        "downtime": "< 10 seconds",
        "test_pass_rate": "> 80%"
    },
    "constraints": {
        "max_image_size": "500MB",
        "allowed_downtime": "10s",
        "rollback_time": "< 30s"
    }
}

# Goal 检查
def check_goal(goal, result):
    checker = sessions_spawn(
        task=f"""
        检查部署结果是否满足 Goal：
        Goal：{goal}
        结果：{result}

        逐项验证：
        - 部署成功率是否 > 95%？
        - 部署时间是否 < 5 分钟？
        - 停机时间是否 < 10 秒？
        - 测试通过率是否 > 80%？

        输出：PASS / FAIL + 详细说明
        """,
        runtime="subagent",
        mode="run"
    )
    return checker.result

Skill 的封装和使用

在 OpenClaw 中，Skill 通过 SKILL.md 文件封装：

~/.qclaw/skills/
├── code-review/
│   └── SKILL.md          # 代码审查 Skill
├── deployment/
│   └── SKILL.md          # 部署自动化 Skill
├── testing/
│   └── SKILL.md          # 测试生成 Skill
└── security/
    └── SKILL.md          # 安全扫描 Skill

每个 Skill 定义了：

  • 职责范围
  • 输入输出格式
  • 执行逻辑
  • 错误处理
  • 最佳实践

Subagent 可以调用这些 Skill：

# Subagent 调用 Skill
result = sessions_spawn(
    task="审查 /path/to/code 的代码质量",
    runtime="subagent",
    mode="run",
    skills=["code-review"]  # 指定使用的 Skill
)

OpenClaw Multi-Agent 的最佳实践

1. 职责单一

每个 Subagent 只干一件事，干好一件事。

  • ❌ Subagent 同时负责"分析代码 + 修复 bug + 写测试"
  • ✅ Subagent A 分析代码，Subagent B 修复 bug，Subagent C 写测试

2. 并行优先

能并行的任务一定并行：

  • ❌ 顺序处理 10 个文件
  • ✅ 10 个 Subagent 并行处理 10 个文件

3. 容错设计

假设每个 Subagent 都会失败：

  • 设置超时时间
  • 提供重试机制
  • 失败时记录详细日志

4. 可观测性

记录每个 Subagent 的：

  • 输入参数
  • 执行过程
  • 输出结果
  • 耗时统计

这些数据对后续优化至关重要。

总结：从"写提示词"到"设计组织"

Multi-Agent + 动态工作流 + Goal + Skill，这套组合拳的核心是什么？

是思维方式的转变。

从"写提示词"到"设计组织"

传统模式：

  • 你是"提示词工程师"
  • 每天琢磨的是"怎么让 AI 听懂"
  • 关注的是"单次对话的质量"

新范式：

  • 你是"AI 组织架构师"
  • 每天琢磨的是"怎么设计分工和协作"
  • 关注的是"系统的整体效能"

四个核心转变

1. 从"单点优化"到"系统设计"

不再是"怎么写一条好 Prompt"，而是：

  • 怎么拆分任务？
  • 怎么定义职责？
  • 怎么设计协作流程？

2. 从"手工调度"到"自主执行"

不再是"我来一步步指挥 AI"，而是：

  • 定义 Goal，让 AI 自己决定怎么做
  • 设计动态工作流，让 AI 自己调整
  • 提供 Skill，让 AI 自己选择工具

3. 从"临时方案"到"能力沉淀"

不再是"每次都重新写 Prompt"，而是：

  • 封装 Skill，一次编写，多次使用
  • 记录最佳实践，越用越聪明
  • 跨项目复用，降低边际成本

4. 从"人工验收"到"自动验证"

不再是"我检查结果对不对"，而是：

  • 定义可度量的 Goal
  • 自动验证是否达成
  • 不满足则自动调整策略

这不是未来，是现在

这套东西不是理论，已经在落地了：

  • Claude Code 内部就有完整的 Agent 和 Subagent 体系
  • OpenClaw 提供了 sessions_spawn 等工具支持
  • 企业级应用 已经在用 Multi-Agent 处理真实任务

最后，坦白讲一句

Multi-Agent + 动态工作流 + Goal + Skill，这些东西听起来复杂，但本质就一句话：

别把 AI 当工具，把 AI 当团队。

工具是你拿在手里的，团队是你设计的。

未来的 AI 工程师，不是"写提示词"的人，而是"会设计 AI 组织"的人。

你准备好了吗？

参考资料：

  • Claude Code 团队关于动态工作流的分享
  • OpenClaw Multi-Agent 协作实践
  • Anthropic 关于 Agent 编排的论文
最近更新:
贡献者: Fen9Pi
Copyright © 2016-2022 风派 | 苏ICP备2025227748号-3