智能体和工作流：先想清楚要不要用智能体

"智能体"是这两年最热的词之一。好像什么东西都要做成智能体才够先进。

在动手之前，先想清楚一个问题：你的任务真的需要智能体吗？这一课先把智能体和工作流区分清楚，再用一个实验看看它们的代价差多少，最后给出一份判断清单。

两者的区别

回顾一下 RepoBot v2 回答问题的过程：改写问题、检索文档、把文档和问题交给模型回答。这三步是你写死在代码里的，顺序固定，每次都一样。模型只负责其中两步里的具体内容：改写成什么词、回答什么。这叫工作流（workflow）。

智能体（agent）不一样：你只给它目标和一组工具，下一步做什么由模型决定。它可能先搜索，发现结果不对就换个词再搜；可能读一个文件，觉得不够，再读另一个；也可能觉得信息够了，直接回答。步骤的数量和顺序，事先都不知道。

工作流：                          智能体：
  改写问题（固定）                   ┌─▶ 模型决定：下一步做什么？
     ▼                             │       │
  检索文档（固定）                   │   ┌───┴───┬────────┬────────┐
     ▼                             │  搜索   读文件   列目录    回答 ──▶ 结束
  回答（固定）                       │   │       │        │
                                   └───┴───────┴────────┘

两者之间没有明确的界线。一个工作流里，某一步让模型决定"要不要检索"，就已经有一点智能体的意思了。更实用的问法是：控制权在谁手里。控制权越多地交给模型，系统越灵活，也越难预测。

实验：同样的问题，两种做法

用第 04 模块的 RAG 流程（改写、混合检索、带引用回答）和上一课将要写的智能体（自己决定用 grep_docs、read_doc、list_docs 查文档），回答同样三个问题。代码见 code/05-agents/workflow_vs_agent.py，我运行的结果（中间是智能体每一步的轨迹）：

问：httpx 默认会自动跟随重定向吗？
  固定流程：1 次回答调用，2.2 秒，输入 831 词元，输出 109 词元
    不会。与 `requests` 不同，HTTPX 默认不跟随重定向 [1]。默认情况下，HTTPX 对所有 HTTP 方法都不会跟随重定向 [2]。
[第 1 步] grep_docs({"keyword": "follow_redirects"}) → compatibility.md:19: response = client.get(url, follow_redirects=True) | compatibility.md:
[第 1 步] grep_docs({"keyword": "redirect"}) → advanced/transports.md:178: Or this example, which uses a custom transport and `httpx.Moun
[第 2 步] read_doc({"path": "compatibility.md", "start": 8, "end": 30}) → 8: ## Redirects | 9:  | 10: Unlike `requests`, HTTPX does **not follow redirects by defaul
[第 2 步] read_doc({"path": "quickstart.md", "start": 430, "end": 445}) → 430: [] | 431: >>> r.next_request | 432: <Request('GET', 'https://github.com/')> | 433: ``
  智能体：  3 次调用，3.8 秒，输入 3261 词元，输出 457 词元
    **不会。httpx 默认不自动跟随重定向。**

问：怎么给 httpx 设置代理？
  固定流程：1 次回答调用，3.7 秒，输入 1550 词元，输出 518 词元
    可以，以下是文档中提到的几种设置代理的方式。
（智能体的轨迹省略）
  智能体：  4 次调用，5.8 秒，输入 6756 词元，输出 732 词元
    httpx 设置代理主要有三种方式：

问：httpx 的超时分成哪几种？每种管什么？
  固定流程：1 次回答调用，2.6 秒，输入 991 词元，输出 208 词元
    httpx 的超时分为四种：**connect**、**read**、**write** 和 **pool** [1]。
（智能体的轨迹省略）
  智能体：  3 次调用，4.1 秒，输入 3731 词元，输出 546 词元
    httpx 的超时一共分成 **四种**（依据 `advanced/timeouts.md:45-61`）：

（固定流程只统计了回答那一次调用，改写问题的调用结果已经缓存了。）

两种做法都答对了三道题。但智能体每道题要 3 到 4 次模型调用，输入词元是固定流程的 4 倍左右，耗时多一到两秒。

原因很好理解：智能体的每一步都要把之前所有的步骤重新发一遍。第 1 步读了一段 grep 结果，第 2 步的输入就包含它；第 2 步读了两个文件，第 3 步的输入就包含这两个文件的内容。步数越多，输入越长。

对这类"查一个事实"的问题，一次检索就能找到答案，智能体的灵活性没有用武之地，只剩下多花的钱和时间。

智能体的代价

• 更贵、更慢。多步调用，上下文一步步变长。
• 不可预测。同一个问题，这次查 3 步，下次可能查 6 步；这次查对了文件，下次可能在错误的方向上越走越远。
• 难以测试和调试。工作流每一步的输入输出都是确定的，可以单独测试；智能体的问题要翻执行轨迹才能找到。
• 风险更大。模型能自己决定调用工具，如果工具能修改数据、发消息、花钱，一个错误的决定或者一次成功的攻击（第 8 课）就会造成实际的后果。

智能体的价值

智能体值得用的地方，是那些步骤没法事先确定的任务：

• 要查什么，取决于前一步查到了什么。比如排查一个报错：先看报错信息，再根据报错去找对应的源码，再根据源码去找相关的配置。
• 可能要试好几种办法。第一次搜索没找到，换个关键词、换个地方再找。
• 任务的形式千变万化，没法为每一种写一个固定流程。比如编程助手，用户可能让它修 bug、加功能、写测试、改文档。

RepoBot v2 回答不了"默认最多跟随几次重定向"，因为答案不在文档里，只在源码里。一个固定的"检索文档再回答"的流程，天生做不到"文档里没有，就去源码里找"。这才是需要智能体的地方，第 9 课会做出来。

判断清单

在做一个新功能之前，按顺序问自己：

1. 一次模型调用能做好吗？ 很多任务，一个写得好的提示词加上合适的资料就够了。能，就别往下想了。
2. 步骤能事先写死吗？ 如果能画出一张固定的流程图（先 A 再 B，如果 X 就 C），就用代码写成工作流。每一步可以调用模型，但控制流程的是你的代码。
3. 是否必须根据中间结果决定下一步？ 如果是，而且情况多到没法一一写成分支，才考虑智能体。
4. 出错的代价能不能承受？ 智能体会犯错。它的工具能造成什么后果？有没有办法让危险操作先经过人确认？
5. 成本和延迟能不能接受？ 智能体的一次任务可能是工作流的几倍花费、几倍时间。

一个实用的策略：先做成工作流，遇到它处理不了的情况，再把那一部分交给智能体。比如 RepoBot 可以先走固定的 RAG 流程，只有检索结果显示"文档里没有"时，才启动一个能翻源码的智能体。

常见的误区

"用了工具调用，就是智能体"。第 03 模块第 3 课的程序也用了工具调用，但它只是"模型要查版本就查一次"，流程非常固定。有没有工具不是关键，关键是步骤是不是由模型动态决定的。

"智能体更高级，所以效果更好"。本课的实验里，三道题固定流程和智能体都答对了，但智能体花了四倍的钱。在步骤固定的任务上，智能体不会更准，只会更贵、更慢、更难预测。

"先做一个通用智能体，什么都能干"。工具越多、任务越宽泛，模型越容易选错工具、走错方向。实际项目里更靠谱的做法是：一个智能体只负责一类任务，给它的工具只和这类任务相关。

练习

1. 在 workflow_vs_agent.py 里加一个问题"httpx 默认最多跟随几次重定向？"（答案在源码里，文档没写）。两种做法分别怎么回答？
2. 回想你工作中的一项任务（比如处理客户工单、整理周报），按本课的判断清单走一遍，写下你的结论：用一次调用、工作流还是智能体？为什么？这道题没有标准答案。

自测

1. 工作流和智能体的根本区别是什么？

控制权在谁手里。工作流的步骤和顺序由代码写死，模型只负责每一步的具体内容；智能体只给定目标和工具，下一步做什么由模型自己决定，步数和顺序事先不知道。

2. 为什么智能体回答同样的问题，输入词元比工作流多好几倍？

智能体要调用多次模型，每一次都要带上之前所有的步骤：工具调用的请求和返回的结果。步数越多，每一步的输入就越长，加起来比一次调用多得多。

3. 什么样的任务才值得用智能体？

步骤没法事先确定的任务：下一步做什么取决于上一步的结果，可能需要多次尝试，情况多到没法一一写成固定的分支。能用一次调用或固定流程做好的任务，不要用智能体。