「Agent」——智能体是什么

所属：第一部分 · 模型和 Agent 到底是什么（第 1–4 章） 前置：第 2 章（工具、循环、上下文装配、轮数上限）、第 1 章（输出可能变化、跨调用状态来自外部系统） 本章要建立：提示词手法、运行结构和产品形态不是同一层；工作流与 Agent 的差别在于谁提供任务级控制流；真实系统可以固定骨架、局部开放路径自主性 本章新概念：工作流、Agent（收窄后的定义）、编排、自主性

一、上一章留下的问题¶

上一章把三个零件装好了：工具、循环、上下文装配。装完之后有一个问题立刻冒出来——这个圈，该让模型自己做多少主？

这个问题不好答，是因为答它之前先得处理一件更烦人的事：「Agent」这个词常被用在三个层面，听起来却像在说同一类东西。

二、四个人都说自己在用 Agent¶

先看四个真实会听到的说法。

说法一。 同事说：「我给它写了个 Agent 提示词，让它回答之前先在里面列个计划再照着写，效果好多了。」他手上的东西是一段文字。

说法二。 产品经理说：「我在自动化平台上搭了个 Agent，每天早上八点把昨天的客诉分好类发到群里。」他手上的东西是一张连线图——哪个格子做什么、连到哪个格子，是他自己拖出来的。

说法三。 工程师说：「我写了个 Agent，你丢给它一个题目，它自己决定搜几次、读哪几篇、什么时候收工。」他手上的东西就是上一章那个圈。

说法四。 销售说：「我们买了个客服 Agent，接进来就能用。」他手上的东西是一个别人做好的软件。里面是说法二那种还是说法三那种，他不知道，也没人告诉他。

这四种说法在市场和日常交流里都可能听到；它们是否符合某一份工程定义，是另一回事。

真正的问题是：这四种说法不在同一个层面，不能直接拿来比较成本、排错和交付时间。你按预设工作流的预期去验收一个模型主导的循环，或者用模型主导的循环去做一条固定流程就能做完的事，都会翻车。

先把四样东西摆在一起看一遍：

三、四个里面只有两个在回答同一个问题¶

上面四项里，只有中间两项处在同一个比较层面：它们都在回答任务的控制流怎样形成。

第一种要摘出去，因为它不是一个系统，是一种手法。 「先列个计划再照着写」这件事，改的是你发给模型的内容。第 1 章说过，当前上下文会改变它接下来最可能生成什么，所以这么写确实可能管用。但它没有回答外部运行系统下一项要执行什么动作；同一段提示词技巧，既可以放进工作流，也可以放进 Agent。它是手法，不是运行结构。

第四种也要摘出去，因为它是包装，不是结构。 一个卖给你的客服 Agent，拆开看里面可能是一条预设流程，也可能是一个放开的循环，还可能骨架固定、中间某一步放开。所以「买还是自己做」和「路径谁来定」是两个各自独立的问题，答其中一个不会顺带答掉另一个。买了成品，「它里面是哪一种」这个问题不会消失，只是从「我要做哪一种」变成了「我验收时该问什么」。

摘完剩下中间两样。它们才是同一个问题的两个答案，也才是真正需要比较的那一对。 从这里开始它们各有名字，不再叫第二种、第三种。

四、那条判据¶

本课不看「模型有没有参与」，而看任务级控制流由谁提供。判据可以写成一句：

程序是否已经写好可执行步骤、转移规则和停止条件，只让模型完成其中一个固定职责；还是由模型根据每轮结果持续提出下一项动作，并选择何时停止请求工具、给出最终答案候选？

程序预先写好任务级节点和转移规则，模型只负责某个节点里的摘要、分类或打分，这种结构叫工作流（workflow）。程序给出目标、可用动作和硬边界，却不枚举完整的任务路径，由模型根据现场结果形成具体动作序列，这个局部才是本课所说的 Agent。这是本课为了判断结构采用的操作性定义；Anthropic 的工程指南也采用了相近区分：工作流走预定义代码路径，Agent 则让模型动态主导过程和工具使用。

顺着这句话可以捡起一个词：编排（orchestration）——决定步骤怎样排序、分支、循环、交接和停止。工作流把这些转移规则主要写在程序里；Agent 把一部分路径选择留到运行时，由模型输出下一项动作请求，再由运行系统校验并执行。模型获得的是边界内的路径选择权，不是创造新工具或绕过权限的权力。

这里要拦掉一个很常见的误判。

有分支、有循环，不等于是 Agent。 一条工作流里完全可以有「金额超过五千就走另一条线」，也可以有「检查没通过就退回上一步重做一次」。如果分支条件、可达节点和跳转规则都由程序预先写好，它仍是工作流，哪怕有二十个分支。

还有一个方向相反的误判：用了模型，不等于是 Agent。 模型可以在固定节点里写摘要，也可以从五个类别中选一个标签，再由程序把每个标签送往预设分支。此时模型影响了节点里的结果，却没有持续掌握后续动作序列；它仍是工作流上的一个格子。

五、同一件事，两种做法¶

换一个比查天气更实的任务：把这周关于某个题目的公开资料查一遍，写成一页纸。

做法一：写成工作流。 你把路径先画出来。

模型在这条线上出现了两次，每次的输入和产出都是你规定死的：给它一篇正文，要一段摘要；给它十五段摘要，要一页纸。它不决定搜什么、不决定读哪几篇、不决定什么时候算做完。

做法二：写成 Agent。 你不预写完整的调研路径，而是给出任务目标、工具清单（搜索、抓正文）、权限、轮数上限和需要人工确认的动作。具体先搜什么、读哪几篇、是否补搜和什么时候收工，交给上一章那个圈逐轮选择。

它这一次可能这么走：

搜一次 → 结果太杂，换个词再搜 → 打开三篇 → 发现其中两篇在说同一件事 → 从正文里冒出一个新关键词，补搜一次 → 再打开两篇 → 开始写 → 写到一半发现某个数字没出处 → 回头再搜一次 → 写完

这十步的具体选择、顺序和次数没有被逐步写死；但可用工具、权限、循环和硬上限仍由程序定义。

两种做法的差别，落到一句话上：工作流始终在预设的控制图里运行；Agent 的具体动作序列会由模型根据本次中间结果形成。

需要说明白的是「预设的控制图」指什么。工作流里模型的输出仍可能变化，所以第 4 步的摘要两次可能不同；若程序按模型给出的分类或分数走分支，两次也可能进入不同的预设分支。不变的是可达节点与转移规则已经列好。Agent 额外变化的是模型在允许的动作集合里持续形成下一步，因而实际顺序和长度都可能改变；可用工具与权限边界仍由程序预设。

六、这个差别的代价长什么样¶

在任务、工具、输入规模和质量要求大致可比的前提下，把两者放到四个维度上看：

机制上，工作流把更多路径选择放在设计时，Agent 把更多路径选择留到运行时。把这条差异压成一句容易记的话：

工作流的代价花在「你得先想清楚」上，Agent 的代价花在「它可能想歪」上。

于是决定用哪一种，先做第一道筛选：任务级动作与转移规则，能不能以可接受的成本提前写清并持续维护？

• 能写清并维护 → 优先工作流。你把路径选择提前完成，通常能换回更窄的成本区间、更容易定位的错误和更稳定的完成时间。
• 不能合理写清（状态组合太多、每次情况差异很大，或必须根据中间结果继续探索）→ 再考虑 Agent。还要继续问：动作能否被权限约束、结果能否检查、失败后果能否承受。

这是一笔交换，不是一次升级。 Agent 不是工作流的高级版本。能满足任务时，先用工作流；只有具体的路径缺口和相应的边界都说得清，才把那一部分交给 Agent。

七、判断规则：别只问「画不画得出来」¶

规则一句话：任务级动作与转移规则能被完整、经济地预定义并维护，就优先工作流；只有无法合理预定义的局部，才考虑 Agent。

为什么不能只问「能不能画图」？因为任何 Agent 的外层都能画成「模型 → 工具 → 模型」的圈。真正要问的是：到了当前状态，程序能否明确写出什么条件对应什么下一项动作，而不需要模型根据开放世界的信息继续选路。能写出来，这一步就留在工作流；写不出来的具体缺口，才是 Agent 的候选位置。

这条规则量的是一项路径决策职责，不是整个系统。

对单项职责而言，控制流由程序还是模型提供可以区分；放到整个系统里，路径自主性（autonomy）却是一条刻度：模型能不能选工具、决定做几步、判断何时完成，或推翻前面的结论重来。工具权限和高风险动作能否自动执行是另一条轴，后面的安全章节再讲。

一种常见的生产做法是：骨架固定，只放开某一两步。 举个具体的，一套客诉处理：

五格里只有最后一格是 Agent 步骤。它之所以放开，不是因为「不知道客户会说什么」——五类判断同样面对未知输入。真正的差别在于：落进五个已知类别后，程序已经规定了后续路径；落到五类之外后，还需要根据调查结果连续选择动作与停止时点。

「能不能提前写清」不能只按理论上的可能性判断，还要看三种现实成本：

一，规则可以枚举，但写完不经济。 几百个分支，每个只出现一次。这时要比较的不只是编写工时，还包括两边的验证、维护、排错、风险和失败后果。

二，规则变化得比维护速度快。 写一次要三天，一个月改两次——那套预设规则本身就会变成负债。

三，你低估了例外。 需求方说「就三步」，做下去发现每一步都有例外。拿不准时，可以先实现最短的工作流并记录它在哪里失败；观察到真实路径缺口后，只放开那个局部。这样做是在用运行证据决定自主性边界，不代表所有项目从工作流改成 Agent 都更便宜。

八、三条结论¶

一，「Agent」的四种常见用法分属三个层面。 提示词是使用手法，工作流与 Agent 是运行结构，买来的成品是产品形态。只有工作流与 Agent 处在同一个比较维度。

二，运行结构的判据是「任务级控制流由谁提供」，而且它按路径决策职责判断，不给整个系统贴一个笼统标签。 程序预先写好节点与转移规则、模型只填固定节点，是工作流；模型根据每轮结果持续提出下一项动作和停止时点，才是 Agent 步骤。

三，Agent 不是工作流的升级版，而是把一部分路径选择从设计时移到运行时。 它用更宽的成本、排错和完成时间分布，换取在既定工具与权限范围内适应未预见情况的机会。能用工作流满足任务时就不额外开放路径自主性；确有路径缺口时，只放开必要的局部。

九、这一章引出的问题¶

判据用完，假设你发现某个局部的转移规则确实无法经济地预定义，而且动作可约束、结果可检查，因此决定采用 Agent 步骤。

那接着就得回答一个更实的问题——那个圈到底怎么转起来。

上一章给了三个零件的名字，但有几件事一直悬着：你发过去的那串文字具体长什么样？模型说「我要用这个工具」的时候，还给你的到底是什么格式？工具执行完，结果怎么接回去？循环凭什么条件停？

下一章把一轮循环从头到尾跑一遍，落到具体的字段上，再给出这件事能跑起来的最小版本。

十、自检题¶

1. 同事说「我们上了个 Agent，每天扫一遍值班表，把当天的排班推送给对应的人，谁没确认就再催一次」。按这一章的判据，他做的多半是哪一种？你凭什么判断？
2. 有人主张「工作流是过渡形态，等模型再强一点，大家都会转向 Agent」。这句话哪里不成立？
3. 你要做一个员工报销审核：金额小于 500 自动通过，500–5000 走主管审批，超过 5000 走财务加主管。该用哪一种？
4. 接上题，再加一条需求：报销单上传的是发票照片，要判断它和历史发票是否重复。这一步可能要用图像相似度服务或模型。它会改变你上一题的答案吗？
5. 为什么说「买成品还是自己做」和「用工作流还是用 Agent」是两个独立的问题？
6. 一个 Agent 昨天把任务做对了，今天同一个任务做错了，中间你一行代码都没改。怎么解释这件事？

十一、参考答案¶

先自己答完再往下看。

1. 工作流。 判据是「任务级控制流由谁提供」——什么时候扫、扫哪张表、推给谁、多久没确认要催、催几次，节点和转移规则都由程序预设。里面那句「谁没确认就再催一次」是个 if，条件和去向都是他写的，有分支不等于是 Agent。这件事里甚至可能一次模型都没调用过；就算调用了（比如让模型把排班写成一句人话），模型也只是这条线上的一格。
2. 两处。第一，它把一笔交换看成了一条线上的先后。 Agent 换来的是「应付没见过的情况」，交出去的是更窄的成本区间、更容易定位的错误和更稳定的完成时间——这些交付要求不会因为模型变强就消失。第二，即使模型更强，一件路径固定的事让它反复决定已知路线，通常仍会增加调用、延迟和不确定性。
3. 工作流。 三条分支全画得出来，判断依据是一个数字，代码一行就能算准。这里没有任何一步需要模型当场决定什么。（顺带一提：这种能用代码算准的判断如果交给模型做，等于把一个不会错的步骤换成一个偶尔会错的步骤。）
4. 不改变骨架，只改变其中一格的实现。 完全相同的文件可以用哈希判断；角度、裁剪不同的照片可以用图像相似度服务或模型给出一个分数，再由代码按阈值路由。无论采用哪种实现，判完仍回到原来的审批分支。用了模型不等于让模型决定下一步，所以整体仍是工作流。
5. 因为两者问的不是同一件事。「买还是自己做」问的是这东西由谁实现和维护；「工作流还是 Agent」问的是任务级控制流由谁提供。一个买来的客服系统，里面完全可能是一条预设工作流；一个你自己写的东西，也完全可以是一个放开的循环。买了成品之后，「它里面是哪一种」这个问题不会消失，只是变成你验收时该问的问题。
6. 两个原因叠在一起。 一是线上模型输出未必逐字可复现，同一个输入的下一步候选可能不同。二是 Agent 的具体动作序列由模型在运行时逐轮形成，第一步偏一点点，后面的可选路径就会改变，最后可能差得很远。这也解释了为什么它的完成时间分布更宽、排错更依赖完整运行记录：你要查的不只是固定代码里的 bug，还包括这一次为什么选了这条路。

上一章：第 2 章　Agent 的最小运行链：三个外部零件 下一章：第 4 章　一轮循环里到底发生了什么