---
title: 养小龙虾，到底养的是什么？
slug: copilot-workflow-agent
description: Copilot、Workflow、Agent 不是谁取代谁，而是覆盖不同确定性的任务。以及 Agent 该如何迭代、何时该被「拆掉」。
date: 2026-07-20
published_at: 2026-07-20 16:23
category: Notes
tags:
  - AI
  - Agent
  - Workflow
  - Copilot
  - 产品
draft: false
featured: true
hidden: false
archived: false
---

最近我一直在想一个问题：

**Copilot、Workflow、Agent，到底有什么区别？我们什么时候应该选择哪一种？**

我的结论是：它们并不是谁取代谁，而是分别适合不同确定性的任务。

## 目前的 AI 产品有哪些形态？

AI 产品大致可以分为四种形态：

```d2
direction: right

Copilot: {
  label: "Copilot\n人主导，AI 辅助"
  shape: class
  style.fill: "#282840"
  style.stroke: "#CBA6F7"
  style.stroke-width: 2
  style.border-radius: 12
}

Workflow: {
  label: "Workflow\n固定流程，AI 执行部分"
  shape: class
  style.fill: "#282840"
  style.stroke: "#FAB387"
  style.stroke-width: 2
  style.border-radius: 12
}

Agent: {
  label: "Agent\n理解目标，动态执行"
  shape: class
  style.fill: "#282840"
  style.stroke: "#A6E3A1"
  style.stroke-width: 2
  style.border-radius: 12
}

Autopilot: {
  label: "Autopilot\n持续自主运行"
  shape: class
  style.fill: "#282840"
  style.stroke: "#89B4FA"
  style.stroke-width: 2
  style.border-radius: 12
}

Copilot -> Workflow -> Agent -> Autopilot: {
  style.stroke: "#6C7086"
  style.stroke-width: 2
}
```

从左到右，AI 的自主性越来越强：

- 用户参与越来越少；
- 系统能够处理的问题越来越复杂；
- 结果的确定性逐渐降低；
- 产品风险和治理成本逐渐提高。

因此，AI 产品的发展并不是简单地从 Copilot 升级成 Agent。

更准确地说，是产品开始能够覆盖不同类型的任务。

## 什么时候选择 Copilot？

Copilot 的特点是：

> **人做判断，AI 提供辅助。**

它适合那些需要专业判断、结果难以标准化、用户希望保留控制权的场景。例如：

- 帮用户总结信息；
- 生成文案或方案；
- 分析简历；
- 给出招聘建议；
- 帮用户准备下一步操作。

Copilot 的优势是安全、透明、容易建立信任。

但它的问题也很明显：AI 只是提高了单个环节的效率，并没有真正替用户完成工作。

### 判断标准

当一个任务满足下面的条件时，优先选择 Copilot：

- 用户需要亲自做最终判断；
- AI 输出主要是建议或草稿；
- 错误成本较高；
- 任务没有稳定的执行流程。

## 什么时候选择 Workflow？

Workflow 的特点是：

> **流程是确定的，AI 替代其中部分人工。**

例如招聘流程：

```d2
direction: right

读取职位: {
  shape: circle
  style.fill: "#282840"
  style.stroke: "#CBA6F7"
  style.stroke-width: 2
}

生成候选人画像: {
  shape: rectangle
  style.fill: "#1E1E2E"
  style.stroke: "#585B70"
  style.stroke-width: 1
  style.border-radius: 8
}

搜索候选人: {
  shape: rectangle
  style.fill: "#1E1E2E"
  style.stroke: "#585B70"
  style.stroke-width: 1
  style.border-radius: 8
}

筛选与去重: {
  shape: rectangle
  style.fill: "#1E1E2E"
  style.stroke: "#585B70"
  style.stroke-width: 1
  style.border-radius: 8
}

生成沟通内容: {
  shape: rectangle
  style.fill: "#1E1E2E"
  style.stroke: "#585B70"
  style.stroke-width: 1
  style.border-radius: 8
}

人工确认后发送: {
  shape: circle
  style.fill: "#282840"
  style.stroke: "#A6E3A1"
  style.stroke-width: 2
}

读取职位 -> 生成候选人画像: { style.stroke: "#6C7086" }
生成候选人画像 -> 搜索候选人: { style.stroke: "#6C7086" }
搜索候选人 -> 筛选与去重: { style.stroke: "#6C7086" }
筛选与去重 -> 生成沟通内容: { style.stroke: "#6C7086" }
生成沟通内容 -> 人工确认后发送: { style.stroke: "#6C7086" }
```

整体步骤是确定的，只是某些节点由 AI 完成。

Workflow 适合：

- 高频重复任务；
- 输入和输出相对明确；
- 可以定义标准步骤；
- 需要稳定、可控、可追踪的结果。

它通常比纯功能更智能，又比 Agent 更稳定。

### 判断标准

当一件事已经知道「应该怎么做」时，就应该优先做成 Workflow。

不要让 Agent 每次都重新思考一遍。

## 什么时候选择 Agent？

Agent 的特点是：

> **用户只描述目标，AI 自己决定怎么完成。**

例如用户说：

> 帮我分析这个职位为什么一直招不到人，并给出下一步招聘方案。

这个任务没有唯一的固定流程。Agent 可能需要：

1. 阅读职位信息；
2. 查看历史招聘数据；
3. 分析淘汰原因；
4. 搜索市场人才情况；
5. 判断问题出在画像、薪资还是招聘渠道；
6. 输出建议，甚至继续执行下一步任务。

Agent 更适合：

- 非标准问题；
- 用户只知道目标，不知道具体步骤；
- 需要跨系统、跨工具执行；
- 执行过程中需要根据结果动态调整。

Agent 的价值不是让一个已知流程自动运行，而是处理那些**暂时还无法被标准化的工作**。

## 如何做选择？

可以用两个维度来判断：

- 任务是否标准；
- 是否需要 AI 自主决策。

| 任务类型 | 推荐形态 |
| --- | --- |
| 需要人做判断，AI 提供建议 | Copilot |
| 步骤明确、重复频繁 | Workflow |
| 目标明确，但执行路径不确定 | Agent |
| 长期稳定运行、风险可控 | Autopilot |

也可以浓缩成三句话：

> 不知道用户是否会接受 AI 时，先做 Copilot。  
> 已经知道一件事应该怎么做时，做 Workflow。  
> 用户知道目标，但不知道怎么做时，使用 Agent。

## Agent 应该如何迭代？

我越来越觉得，Agent 不能按照传统功能的方式迭代。

Agent 更像是一名被派到客户身边的员工：进入用户的真实工作，帮助用户完成任务，也暴露自己当前做不到的事情。

因此，Agent 的迭代应该形成一个循环：

```d2
direction: right

A: {
  label: "先让用户\n用起来"
  shape: class
  style.fill: "#282840"
  style.stroke: "#CBA6F7"
  style.stroke-width: 2
  style.border-radius: 12
}

B: {
  label: "记录用户\n交给 Agent 的任务"
  shape: class
  style.fill: "#282840"
  style.stroke: "#FAB387"
  style.stroke-width: 2
  style.border-radius: 12
}

C: {
  label: "复盘成功、\n失败和人工纠正"
  shape: class
  style.fill: "#282840"
  style.stroke: "#A6E3A1"
  style.stroke-width: 2
  style.border-radius: 12
}

D: {
  label: "补充知识、工具、\n数据和权限"
  shape: class
  style.fill: "#282840"
  style.stroke: "#89B4FA"
  style.stroke-width: 2
  style.border-radius: 12
}

E: {
  label: "把成熟做法沉淀\n为 Workflow 或功能"
  shape: class
  style.fill: "#282840"
  style.stroke: "#F5C2E7"
  style.stroke-width: 2
  style.border-radius: 12
}

A -> B: { style.stroke: "#6C7086"; style.stroke-width: 2 }
B -> C: { style.stroke: "#6C7086"; style.stroke-width: 2 }
C -> D: { style.stroke: "#6C7086"; style.stroke-width: 2 }
D -> E: { style.stroke: "#6C7086"; style.stroke-width: 2 }
E -> A: { style.stroke: "#F5C2E7"; style.stroke-width: 2; style.stroke-dash: 4 }
```

每天让 Agent 做一次复盘：

- 用户今天想完成什么？
- 哪些任务完成了？
- 哪些任务没有完成？
- 缺少什么工具或资源？
- 哪些需求出现得最多？
- 哪些优秀做法已经可以标准化？

这就像一次数字员工的日会。

## 做得好的 Agent，最终应该被「拆掉」

这可能是一个有些反直觉的观点。

Agent 做得好的部分，不应该永远留在 Agent 里。当某类任务已经高频发生、流程逐渐稳定，就应该把它沉淀成：

- 工作流；
- 固定按钮；
- 标准功能；
- 专业的子 Agent。

因为确定的事情，不应该一直依赖 Agent 的临场发挥。

最终会形成这样的产品循环：

> **Agent 探索需求，Workflow 沉淀经验，功能规模化交付。**

所以，「养小龙虾」养的并不只是一个更聪明的 AI。

我们真正培养的是一名能够进入用户工作、发现需求、积累经验的数字员工。而产品团队的工作，是不断把这名员工在一线学到的东西，变成更稳定的产品能力。