结论先说：不是所有问题都配得上 Agent，更不是所有 Agent 都该长成多 Agent #

做完前 17 篇，最后真正该问的问题不是“还能加什么能力”，而是：

什么问题根本不该用 Agent？

这是架构判断里最重要的一步。因为很多系统不是不够强，而是从一开始就选错了形态。

一、先把四种形态分清 #

1.1 普通函数 #

输入明确，步骤固定，输出规则化。

1.2 工作流（Workflow） #

步骤有限，但包含条件分支和状态推进。

1.3 单 Agent #

需要基于当前状态做开放式规划，但仍有统一控制面。

1.4 多 Agent #

不同子任务需要不同角色、不同上下文、不同局部目标协作。

很多时候，问题只配得上前两种。

二、什么时候该用普通函数 #

如果任务满足这三个条件：

1. 输入结构固定
2. 步骤路径稳定
3. 输出判断明确

那最好的架构就是函数。

def daily_report():
    rows = query_db(...)
    summary = aggregate(rows)
    send_email(summary)

这类任务强行上 Agent，只会引入：

• 不必要 token 消耗
• 不稳定规划
• 更多失败路径

所以一个成熟的架构师，首先要有勇气说：

这个地方不要上 Agent。

三、什么时候工作流比 Agent 更合适 #

工作流适合：

• 状态多步推进
• 分支清楚
• 每一步动作基本已知
• 恢复路径主要靠规则而不是开放式推理

flowchart TD
    Start --> Parse
    Parse --> Validate
    Validate -->|ok| Query
    Validate -->|bad| Reject
    Query --> Aggregate
    Aggregate --> Report

工作流的优势 #

• 可预测
• 易审计
• 易测试
• 成本低

工作流的局限 #

• 对开放问题适应差
• 不擅长动态选择能力
• 对模糊用户意图不够灵活

所以工作流不是低级方案，而是在确定性问题上更高级的选择。

四、单 Agent 什么时候值得上 #

当任务开始具备这些特征时，单 Agent 才真正有价值：

1. 用户目标不完全结构化
2. 系统需要在多个能力之间动态选择
3. 执行中会根据结果修正策略
4. 恢复路径不能完全靠固定规则写死

这时单 Agent 的优势就出来了：

• 统一状态
• 统一控制面
• 统一恢复与停止逻辑
• 成本仍可控

所以大多数真实项目，最合理的上限其实是：

工作流不够用时，先上单 Agent，而不是直接拆成多 Agent。

五、为什么多 Agent 不是默认答案 #

多 Agent 看起来很高级，但它会立刻带来新的复杂度：

1. Agent 之间如何共享状态
2. 谁负责冲突协调
3. token 成本如何累加
4. 恢复路径如何跨角色传播
5. trace 如何解释清楚

如果这些问题你还没想明白，多 Agent 很可能只是把一个系统问题拆成多个更难 debug 的系统问题。

多 Agent 真正适合的场景 #

• 子任务目标差异很大
• 每个角色需要不同工具和上下文
• 角色分工天然存在
• 单 Agent 的上下文已经明显过载

如果只是“一个 Agent 有点复杂”，通常还不到上多 Agent 的时候。

六、真正的架构判断顺序 #

这一步很重要。架构不是看潮流，而是按问题约束往上升级。

普通函数
  -> 工作流
  -> 单 Agent
  -> 多 Agent

正确判断顺序应该是：

6.1 先问：能不能用普通函数 #

如果能，就别用 Agent

6.2 再问：能不能用工作流 #

如果步骤已知、分支有限，优先工作流

6.3 再问：是否真的需要开放式规划 #

如果需要，再上单 Agent

6.4 最后问：单 Agent 是否已经明显过载 #

只有这时，多 Agent 才开始有意义

七、SecurityClaw 给出的真正启发 #

SecurityClaw 值得学习的，不是“用了 Agent”，而是它没有把所有问题都扔给 Agent。

它的整体设计说明了一件事：

• 技能层保持能力独立
• 控制面保持系统约束统一
• 知识层和状态层分离
• Agent 主要负责开放式规划与证据迭代

这意味着它已经在架构上默认承认：

不是所有事都应该交给模型自由决定。

这其实比“会不会做多 Agent”更难得。

八、这一篇真正要记住的框架 #

架构取舍可以压成这张表：

所以真正成熟的结论不是“多 Agent 更强”，而是：

先选最低复杂度、仍能覆盖问题约束的那种形态。

九、验证命令 #

pytest tests/ -k "workflow or agent or orchestration" -v