外观
概念辨析：Agent / Workflow / Copilot / RAG
这个行业的术语是被营销部门和研究者一起搞乱的。同一家公司上周发布的「Agent」，可能只是三个 prompt 串起来的流水线；而另一个团队嘴里的「workflow」，实际上让模型自主决定每一步干什么。概念不清不只是面子问题——它直接影响技术选型、架构设计和面试回答。一个把 RAG 检索问答系统包装成「多 Agent 平台」的工程师，和一个只会背定义、却分不清 routing 和 agent 的工程师，踩的其实是同一个坑。
本文的目的很直接：给这组高频概念各下一个可操作的定义，配上典型例子和一条「判断标准」，让你看到任何一个系统都能在十秒内归类。文末附一张选型决策流程图。
一、基准定义：到底什么是 Agent
先把锚点立住。目前业界最有影响力的两个定义：
- Anthropic（2024 年 12 月发布的《Building Effective Agents》，目前被广泛引用的工程指南）把所有相关系统统称为 agentic systems，并在其中划出一条架构分界线：
- Workflow：LLM 和工具通过预定义的代码路径（predefined code paths）被编排起来的系统。
- Agent：LLM 动态地指挥自己的流程和工具使用、自己掌控如何完成任务的系统。
- OpenAI（《A Practical Guide to Building Agents》）的定义更偏向产品视角：Agent 是能代表你独立完成任务的系统（systems that independently accomplish tasks on your behalf）。
两个定义放在一起，Agent 的三个必要条件就清楚了：
- 有一个 LLM 在决策回路里——不是规则引擎，不是固定脚本；
- 模型在运行时自主决定下一步——调哪个工具、传什么参数、什么时候停，不是开发者提前写死的；
- 面向目标而非单轮响应——它为了一个「任务」工作，可以跨多轮、多工具、长时间运行。
判断一个系统是不是 Agent，核心就看第 2 条：控制流的分支决策由谁做。代码做，就是 workflow；模型做，才是 agent。这个判断标准会贯穿全文。
┌─────────────────────────────────────────┐
│ Agentic System │
│ （一切「让 LLM 干活」的系统的总称） │
├───────────────────┬─────────────────────┤
│ Workflow │ Agent │
│ 控制流写在代码里 │ 控制流由模型决定 │
│ 可预测、可复现 │ 灵活、自主、贵 │
└───────────────────┴─────────────────────┘一个快速的心智模型
Workflow 像乐谱，LLM 是按谱演奏的乐手；Agent 像爵士即兴，只给了主题和规则（目标、工具、约束），走向哪里由乐手现场决定。两者的成本结构、失败模式、测试方式完全不同——这就是为什么必须先分清它们。
二、Agent vs Workflow：最重要的一条分界线
这是所有辨析里最值钱的一组，因为它直接对应「我这个需求要不要上 agent 框架」这个工程决策。
Workflow（工作流）：流程图是人画的，LLM 只是流程里某些节点的执行者。
- 典型例子：客服工单处理流水线——第一步分类（LLM），第二步按类别路由到不同模板回复（代码 if-else），第三步敏感词审查（代码），第四步发送。模型全程没有决定过「接下来干什么」。
- Anthropic 文中归纳了五种常见 workflow 模式：prompt chaining（链式）、routing（路由）、parallelization（并行）、orchestrator-workers（编排-工人）、evaluator-optimizer（评估-优化）。注意：这些模式里哪怕有「路由」这种看似在「做决策」的环节，决策空间也是预定义的——只能从 A/B/C 三条路里选，不能发明第四条。
Agent（智能体）：开发者给的是目标、工具集和护栏，循环跑多少轮、每轮干什么由模型决定。详情见 Agent Loop。
- 典型例子：让一个 coding agent「修复这个仓库里失败的测试」——它自己决定先读哪个文件、跑什么命令、改哪里、改完再验证，循环直到测试通过或放弃。Claude Code 和 SWE-Agent 都是这类。
两两对比：
| 维度 | Workflow | Agent |
|---|---|---|
| 控制流 | 开发者预定义 | 模型运行时决定 |
| 可预测性 | 高，行为可枚举 | 低，轨迹不重复 |
| 延迟/成本 | 低且稳定 | 高且波动大（循环轮数不定） |
| 适合的任务 | 步骤已知、路径可枚举 | 步骤数与路径事先不可知 |
| 测试方式 | 单元测试式，逐节点断言 | 需要评估整条轨迹，见 Agent 评估 |
| 失败模式 | 节点报错，易定位 | 跑偏、死循环、错误累积，难定位 |
判断标准：看到「所有分支都写在代码里，模型只在节点内部工作」，就是 workflow；看到「一个 while 循环套着 LLM，循环退出条件由模型输出决定」，就是 agent。
Anthropic 原文的建议值得背下来：能不用 agentic 系统就不用，能用单次 LLM 调用加检索解决就不要上 workflow，能用 workflow 解决就不要上 agent。Agentic 系统是用延迟和成本换任务表现的，这个交换只有在任务足够开放、路径足够不可预测时才划算。行业里大量的「Agent 项目」失败，不是模型不行，而是给一个 workflow 就能解决的问题套了 agent 的复杂度。
三、Agent vs Chatbot：对话外壳 vs 行动内核
Chatbot（聊天机器人）：以「对话」为全部交付物的系统。你发消息，它回消息，交互结束。哪怕底层是顶级 LLM，只要它的输出止步于文本回复、对话历史之外不改变世界，它就是 chatbot。
- 典型例子：ChatGPT 网页版的纯聊天、客服问答机器人、绝大多数「AI 助手」钉钉/企微机器人。
Agent 的区别在于副作用（side effect）：它通过工具调用改变外部世界——改代码、发邮件、下订单、操作数据库。对话只是它与人沟通的界面之一，不是它的产出。
一个实用的判别方法：把系统的日志拿来看。如果从头到尾只有「用户输入 → 模型输出」交替出现，是 chatbot；如果中间夹杂着 tool_call 和 tool_result，且这些调用有真实外部效果，才有 agent 成分。（有 tool call 不等于有 autonomy——只调一个固定搜索工具的问答机器人，本质上还是 chatbot 加检索，见下文 RAG 一节。）
两者的工程设计也完全不同：chatbot 的核心难题是多轮对话管理与意图识别；agent 的核心难题是 上下文工程、工具接口设计（工具与 MCP）和失控防护（Agent 安全）。
判断标准：系统结束后，世界有没有被它改变？没有改变的是 chatbot；被按目标改变了的是 agent。
四、Agent vs Copilot：副驾与代驾
Copilot（副驾驶）：嵌入在人的工作流里、以增强人为目标的 AI。它补全、建议、草拟，但最终决策权与执行权始终在人手里。名字本身就是定义——copilot 是副驾，方向盘在你的手里。
- 典型例子：GitHub Copilot 的行内代码补全、Office Copilot 的文档润色、IDE 里的「解释这段代码」面板。
Agent 则是代驾：你给目的地，它开全程，你只在关键节点（比如付款、提交 PR）上被叫回来确认——这种设计模式叫 human-in-the-loop，见 人在回路。
这条边界在 2025-2026 年变得越来越模糊，因为「Copilot 类产品都在 Agent 化」：GitHub Copilot 推出了能独立完成 issue 的 coding agent 模式，Cursor 的 Composer/Agent 模式可以跨文件自主改代码（见 Cursor 案例）。判断一个功能此刻是 copilot 还是 agent，不看产品名，看默认的信任配置：
- 每一步改动都需要人确认才生效 → copilot；
- 能连续执行多步、人只在事后审查 → agent。
判断标准：看「未确认就生效的动作半径」。半径为零（只出建议）是 copilot；半径覆盖多个连续动作是 agent。同一个产品里两种模式可以并存。
从工程角度，这组辨析的真正意义在审批与回滚设计：copilot 架构假设人实时在场，agent 架构必须假设人不在场——所以要日志、要 checkpoint、要可回滚。详见 可观测性。
五、Agent vs RAG：RAG 是组件，不是 Agent
这是面试里被问烂、也答错最多的一组。
RAG（Retrieval-Augmented Generation，检索增强生成）：一种给 LLM 喂外部知识的技术——用户问题进来，先检索相关文档片段，塞进 prompt，再让模型基于这些片段生成答案。概念源自 Lewis 等人 2020 年的论文（arXiv 2005.11401，NeurIPS 2020），最初是「参数化记忆 + 非参数化记忆」的模型训练方案，今天工程上泛指一切「检索 → 拼 prompt → 生成」的流水线。详见 RAG 组件。
关键点：经典 RAG 是一条直线型 pipeline，没有任何自主决策。「检索」这一步是开发者写死的固定动作，不是模型判断「我需要更多信息」后主动发起的。所以：
- RAG 本身不是 agent，正如「发动机不是汽车」；
- RAG 可以是 agent 的一个工具——当模型在循环里自己决定「这个问题需要查知识库」并发起检索时，RAG 就成了 agent 的工具箱里的一件工具。Anthropic 把这种最小单元称为 augmented LLM（增强了检索、工具、记忆的 LLM），它是构建一切 agentic 系统的积木。
当然也有中间态，所谓 agentic RAG：查询改写、多路检索、检索结果不够好就换查询再查——一旦「要不要继续查、怎么查」由模型决定，它就开始向 agent 一侧滑动。这恰恰说明分类标准不是「有没有检索」，而永远是「控制流归谁」。
判断标准：看到「用户提问 → 检索 → 生成」的固定三步流水线，是 RAG；看到模型在循环里自主选择「现在该查知识库了」，那是用了 RAG 工具的 agent。
经典 RAG（不是 agent）：
问题 ──► 检索(固定动作) ──► 拼 prompt ──► LLM 生成 ──► 答案
Agentic RAG（agent 用 RAG 当工具）：
┌──────────────────────────────┐
▼ │
目标 ──► LLM 决策 ──► 调用检索工具 ──► 观察结果
│ 「够了，可以回答了」
▼
答案六、Agent vs Agentic AI：工程用法与学术用法
日常口语里两个词混用，但在学术文献里已经出现明确区分。Sapkota、Roumeliotis 和 Karkee 在 2025 年 5 月的论文《AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenges》（arXiv 2505.10468，被引量已超 800）里提出了一套三层分类：
| 层级 | 核心机制 | 结构 | 关键特征 |
|---|---|---|---|
| Generative AI | Prompt → LLM → 输出 | 单模型 | 内容生成、被动响应 |
| AI Agent | Prompt → 工具调用 → LLM → 输出 | LLM + 工具 | 面向特定任务的工具使用 |
| Agentic AI | 目标 → 多 Agent 编排 → 输出 | 多 Agent 系统 | 持久记忆、跨 Agent 协作、目标级自主 |
按这套学术用法：「AI Agent」指单体的、任务级的工具使用者；「Agentic AI」指具备多 Agent 协作、持久记忆、复杂目标分解的系统级范式。也就是说，学术语境下「agentic AI」几乎等于我们说的多 Agent 系统加上长期自主性。
工程圈并不严格遵守这个区分——Anthropic 用「agentic systems」统称 workflow 和 agent 两者，含义宽得多。实际建议是：读论文时按作者的定义走，写文档时先给定义再用词，聊天时别太较真。但如果简历或技术方案里要写，用「agentic」描述系统属性（这个系统有自主性）、用「agent」指代具体实体（这个系统里有两个 agent），是最不容易被挑刺的用法。
判断标准：在学术论文标题里见到「Agentic AI」，默认它在讨论多 Agent / 目标级自主的系统范式；在厂商博客见到「agentic」，默认它只是「跟 agent 有关」的营销形容词。
七、Agent vs Automation / RPA：确定性脚本 vs 概率性决策
传统自动化 / RPA（Robotic Process Automation）：用确定性规则模拟人操作软件——点这个按钮、填这个字段、从 Excel 第 3 列读数。代表厂商是 UiPath、Automation Anywhere 这一代。它的决策表是人事先穷举的，遇到例外就报错或转人工。
Agent 与 RPA 的本质差异不在「智能程度」这种模糊说法，而在错误处理的归因方向：
- RPA 失败 = 规则没覆盖到——环境变了（按钮挪了位置、多了个弹窗），脚本就死；
- Agent 失败 = 模型判断错了——它能看到弹窗、能理解页面变了，但可能做出错误的应对。
| 维度 | RPA / 传统自动化 | LLM Agent |
|---|---|---|
| 决策来源 | 预定义规则、选择器、坐标 | 模型对上下文的理解 |
| 环境变化容忍度 | 极低，UI 一改就崩 | 较高，按语义理解界面 |
| 行为可复现性 | 完全可复现 | 概率性，轨迹不重复 |
| 单次执行成本 | 接近零 | 每次都要烧 token |
| 适合场景 | 高频、固定、合规严苛的流程 | 低频到中等、多变、需要判断的流程 |
值得注意的 2025-2026 年趋势：RPA 厂商在集体「agent 化」，把 LLM 决策嵌进原有流程编排里，形成「确定性骨架 + 局部智能决策」的混合体。这其实是工程上最务实的路线——合规环节走死的规则，需要理解的环节（读邮件、分类单据）交给模型。
判断标准：看到「流程图每个分支都能画出真值表」，是自动化/RPA；看到「某些节点的输出依赖模型对非结构化输入的理解」，那部分已经是 agent 成分。
八、单 Agent vs 多 Agent：先问分工是不是真需求
单 Agent 系统：一个 LLM 循环，一套上下文，一套工具。多 Agent 系统：多个各有独立上下文的 agent 实例，由编排者（orchestrator）或点对点协议协作。架构细节见 多 Agent 系统。
业界的实际经验比框架营销冷静得多。Anthropic 在《How we built our multi-agent research system》中报告多 Agent 架构在其研究型任务上显著优于单 Agent，但同时明确指出其 token 消耗约为单 Agent 的数倍（聊天类场景的数量级差距更大），因此只适合「任务价值足够高」的场景。Cognition（Devin 的团队）那篇广为流传的《Don't Build Multi-Agents》则更激进：多 Agent 架构在需要共享上下文紧密协作的任务上容易系统性失败——子 agent 各自做决定，决策之间互相矛盾，错误难以归因。
经验法则可以压缩成一句话：多 Agent 解决的是「单个 context window 装不下 / 单一角色 prompt 顾不过来」的问题，不是「显得高级」的问题。
适合上多 Agent 的信号：
- 任务天然可并行拆分，且子任务之间不需要频繁共享中间状态（典型：广度优先的资料调研）；
- 不同子任务需要截然不同的工具集和系统 prompt（比如一个查库、一个写报告）；
- 单个 agent 的上下文被撑爆，需要隔离上下文来压缩 token（见 上下文工程）。
不该上的信号：子任务之间每一步都要看对方的中间结果——这种情况拆开只会引入决策不一致，老老实实单 agent 加好工具。
判断标准：画出系统的上下文边界。只有一个 LLM 循环、一份主上下文，是单 Agent；存在多个各自维护上下文、需要显式传递消息的循环，是多 Agent。
九、Agent vs Harness / Scaffold：模型不是 Agent
这组词 2025 年下半年开始在工程圈流行，2026 年 5 月 Hugging Face 官方博客专门发了一篇术语指南《Harness, Scaffold, and the AI Agent Terms Worth Getting Right》来厘清，可见混乱程度。其核心公式：
Agent = Model + Harness- Model（模型）：LLM 本身。吃文本吐文本，调用之间没有记忆，没有循环，没有手。它可以「表达」想调用某个工具的意图，但自己执行不了。
- Scaffold（脚手架）：模型周围的行为定义层——系统 prompt、工具描述、输出格式约定、上下文管理策略。它塑造模型「怎么看世界」。这个词源自认知科学的 scaffolding（脚手架学习理论），在评测圈早就用开了。
- Harness（缰绳/挽具）：模型周围的执行层——真正调用模型、解析工具调用、执行工具、把结果塞回上下文、决定何时停止的那个循环。Claude Code、Codex 这类产品的官方文档把整个「模型之外的一切」统称为 harness（或 agentic harness）。
这套术语解释了 2025-2026 年一个很重要的行业现象：为什么同一个模型在不同产品里表现差距巨大。Claude Code 和某个开源替代品可以调用完全相同的模型，但效果天差地别——差异全在 harness：系统 prompt 怎么写、工具 schema 怎么设计、上下文怎么压缩、错误怎么恢复。模型厂商越来越强，应用层的护城河就越来越向 harness 工程迁移。
对工程师的实操含义：评估一个 agent 产品，别只问「用的什么模型」，要问 harness 怎么设计——它什么时候停止循环、怎么管理上下文窗口、工具失败时怎么恢复、有没有可验证的完成信号。这些问题比「prompt 怎么写」更接近 agent 工程的本质，详见 Agent Loop 与 全景解剖。
判断标准：讨论的是「模型能力」，那是 model；讨论的是「prompt + 工具定义 + 上下文策略」，那是 scaffold；讨论的是「执行循环 + 工具运行时 + 停止条件」，那是 harness。三者加起来，才是你体验到的那个 agent。
别在面试里翻车
「你们的 agent 和直接调 API 有什么区别？」——正确答案全部在 harness 层：循环控制、上下文管理、工具运行时、权限与护栏、可观测性。只会回答「我们 prompt 写得好」的候选人，会被认为没做过真正的 agent 系统。
十、汇总：一张对照表
| 概念 | 一句话定义 | 典型例子 | 判断标准（看到 X 就是 Y） |
|---|---|---|---|
| Workflow | 预定义代码路径编排 LLM 与工具 | 工单分类流水线 | 所有分支写在代码里 |
| Agent | LLM 动态指挥自身流程完成任务 | Claude Code 修 bug | while 循环的退出由模型决定 |
| Chatbot | 交付物止步于对话文本 | 客服问答机器人 | 日志里没有有副作用的 tool call |
| Copilot | 人实时在场、逐步确认的增强工具 | 行内代码补全 | 未确认就生效的动作半径为零 |
| RAG | 检索→拼 prompt→生成的固定流水线 | 企业知识库问答 | 检索是写死的步骤而非模型决策 |
| Agentic AI（学术） | 多 Agent 协作 + 持久自主的范式 | 多 agent 研究系统 | 论文语境，指系统级范式 |
| RPA / 自动化 | 确定性规则驱动的流程执行 | 发票录入脚本 | 每个分支能画出真值表 |
| 多 Agent | 多个独立上下文的 agent 协作 | 并行调研系统 | 存在显式的 agent 间消息传递 |
| Harness | 模型之外的执行与控制系统 | Claude Code 本体 | 讨论循环、工具运行时、停止条件 |
十一、决策流程图：拿到需求怎么选
这是全文的落点。面对一个新需求，按下面的顺序问自己四个问题——顺序本身就是 Anthropic 的建议：从最简单的方案开始，复杂度是「挣来的」不是「默认的」。
拿到一个需求
│
Q1: 单次 LLM 调用能解决吗？
（翻译、摘要、分类、改写……）
│ │
能 不能
│ ▼
直接调 API Q2: 缺的是知识吗？
别过度设计 （内部文档、实时数据、
│ 私有领域事实）
│ │ │
│ 是 不缺，缺的是
│ │ 「行动能力」
│ ▼ │
│ 上 RAG（检索+ ▼
│ 生成，固定 Q3: 执行步骤能
│ pipeline） 事先穷举吗？
│ │ │
│ 能 不能，路径
│ │ 开放且多变
│ ▼ │
│ 写 Workflow │
│ （代码编排，可 │
│ 预测、便宜、 │
│ 好测试） │
│ │ ▼
│ │ 上 Agent
│ │ （LLM 自主循环
│ │ + 工具 + 护栏）
│ │ │
│ │ ▼
│ │ Q4: 单 Agent 的上下文
│ │ 装不下 / 角色顾不过来吗？
│ │ │ │
│ │ 否 是
│ │ │ ▼
│ │ 保持单 Agent 多 Agent 系统
│ │ 优化工具与 （并确认 token
│ │ 上下文 预算烧得起）
▼ ▼
★ 共同前提：无论选了哪条路，
都要先有评估集和基线（见 /advanced/evaluation），
否则你无法证明更复杂的方案确实更好。三个使用说明：
- Q2 和 Q3 不互斥。真实系统常常是组合体：一个 agent 的工具箱里挂着 RAG，一个 workflow 的某个节点里嵌着小 agent。分类看主干，组合看局部。
- Q4 的答案大多数时候是「否」。2026 年的今天，单 agent + 好工具 + 好上下文管理能解决绝大多数生产需求。多 Agent 是少数高价值、可并行、上下文确实会爆的任务的专用解。
- 复杂度只能往上挣，不能往下装。先上线 workflow 版本，收集失败 case，用数据证明「固定路径确实覆盖不了」，再上 agent——这个过程同时就把评估集攒出来了。反向操作（先上 agent 再简化）几乎总会卡在「不知道它到底哪里好、哪里坏」。
一句话记住全篇
Workflow 的路径是人画的，Agent 的路径是模型走的，RAG 是喂知识的组件，Copilot 是人握着方向盘，Harness 是模型之外那套真正干活的系统——判断任何系统归属，只问一个问题：这一步的决策是谁做的？
参考资料
- Building Effective Agents — Anthropic Engineering —— Workflow 与 Agent 权威区分的原始出处，含五种 workflow 模式与选型建议
- A Practical Guide to Building Agents — OpenAI —— OpenAI 对 agent 的产品化定义与何时该构建 agent 的判断框架
- Harness, Scaffold, and the AI Agent Terms Worth Getting Right — Hugging Face —— 2026 年 5 月发布的 agent 术语官方指南，「Agent = Model + Harness」公式的出处
- AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenges —— Sapkota 等人对 Generative AI / AI Agent / Agentic AI 的三层学术分类（arXiv 2505.10468）
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks —— Lewis 等人 2020 年的 RAG 原始论文（NeurIPS 2020）
- Claude Code Docs: Glossary —— Claude Code 官方对 agentic harness 等术语的定义
- How we built our multi-agent research system — Anthropic —— 多 Agent 系统收益与数倍 token 成本的一手工程报告