第 1 章 Agent 的定义与边界¶

1.1 从 LLM 应用到 Agent¶

在开始讨论 Agent 架构、RAG、Memory 和多 Agent 协作之前，首先必须回答一个看似简单但实际上经常被混用的问题：什么是 Agent？

在过去两年里，很多团队把“调用了大模型 API 的应用”直接称为 Agent。这种说法在传播上很方便，但在工程上并不准确。因为一旦定义模糊，后续关于架构、评测和治理的讨论就会失去基准。一个只负责问答的大模型应用，和一个能够拆解任务、调用工具、维护状态并根据外部反馈持续调整行为的系统，虽然都可能使用同一个模型，但它们面对的问题和设计重点完全不同。

从最宽泛的角度看，LLM 应用是所有“以大模型为核心能力部件的软件系统”的统称。它可以是一个客服问答页面、一个会议纪要总结工具，也可以是一个代码补全助手。它们共同的特点是：系统把输入组织成上下文，交给模型，然后接收模型输出。这个过程中，系统本身的控制逻辑往往相对薄，真正关注的是生成质量、响应速度和用户体验。

而 Agent 则更进一步。它并不满足于“一次性输出一段文本”，而是围绕某个任务目标展开一系列决策和动作。它需要理解用户的意图，判断当前状态，决定下一步做什么，必要时调用外部工具获取额外信息或执行真实动作，并根据执行结果继续调整后续行为。换句话说，Agent 的关键不在于它是否能够多轮对话，而在于它是否形成了一个以目标为导向、以反馈为驱动的任务闭环。

因此，我们可以给出一个更偏工程视角的定义：

Agent 是一个以目标为导向、能够结合上下文进行决策、调用外部能力执行动作，并根据执行反馈持续调整行为的软件系统。

这个定义里有几个关键词值得特别强调。

第一，Agent 是“以目标为导向”的。用户交给它的通常不是一段简单问答，而是一个需要被完成的任务，例如“定位线上故障”“修复一个测试失败”“根据知识库回答问题并生成工单”。

第二，Agent 需要“结合上下文进行决策”。这意味着它不是机械地执行固定流程，而是要根据当前信息判断什么动作更合适。

第三，Agent 会“调用外部能力执行动作”。这种能力可以是搜索、数据库查询、文件读写、HTTP 请求、代码执行，甚至是企业内部系统的 API。没有这一步，很多系统充其量只是一个会解释任务的助手，而不能真正完成任务。

第四，Agent 会“根据执行反馈持续调整行为”。它不是一次调用结束，而是在动作与反馈之间形成迭代。这个反馈既可能来自工具结果，也可能来自环境状态变化或人工确认。

所以，从 LLM 应用到 Agent，并不是模型能力的一次简单升级，而是系统形态的一次变化。前者更像“生成系统”，后者更像“带有语言推理能力的执行系统”。前者主要关心输出质量，后者还必须关心任务闭环、可控性、失败恢复和状态管理。

工程提示¶

很多初学者会把“支持多轮对话”视为 Agent 的核心特征。这是一个常见误区。多轮只是交互形式，规划、行动和反馈闭环才是 Agent 的关键特征。

1.2 Agent 与 Chatbot、Workflow、Copilot 的区别¶

理解 Agent 的一个有效方法，不是单独给它下定义，而是把它放回软件系统家族中，与几个容易混淆的对象进行对比：Chatbot、Workflow 和 Copilot。

首先看 Chatbot。Chatbot 的核心目标是围绕对话展开交互，它强调的是“理解用户表达并生成合适回复”。有些 Chatbot 会接入知识库，也可能调用部分工具，但系统的中心仍然是对话本身。它通常由用户持续驱动，系统很少在无人介入的情况下自行推进任务。而 Agent 的中心不是对话，而是任务。对话在 Agent 中只是接口，真正重要的是系统是否能围绕目标自主推进下一步。

再看 Workflow。传统 Workflow 的优势在于确定性和可控性。流程节点、执行顺序和分支逻辑通常都由工程师提前设计好，系统做的是“按既定规则推进”。它很适合规则明确、可预测性高的业务流程，例如审批流、订单编排、数据同步和 ETL 作业。Agent 则更适合处理路径不固定、需要临场判断的任务。它面对的是不完整信息和动态环境，因此路径往往不能完全预定义。很多现实系统其实不是“Workflow 或 Agent”二选一，而是“用 Workflow 托住确定性主链路，在局部复杂节点嵌入 Agent”。

Copilot 则更强调人在回路中的协同。一个典型的 Copilot 系统会主动给出建议、补全、推荐或候选方案，但最终操作权和决策权仍主要在用户手上。例如代码补全、文本润色、数据分析建议都更接近 Copilot 范式。Agent 则可以在更大范围内接管任务推进，只在关键节点引入人工确认。这意味着 Copilot 的设计重心是“高频协作”，而 Agent 的设计重心是“有限自治”。

最后还可以把 Agent 与 Script 或传统自动化程序对比。Script 解决的是“已知流程的自动化”，它擅长把人工规则翻译成固定程序。而 Agent 解决的是“部分未知流程中的任务推进”，它需要在执行过程中补充信息、做条件判断和路径选择。前者追求确定性和低波动，后者必须面对不确定性并设计相应约束。

如果用一句话概括这些差异，可以这样理解：

Chatbot 以对话为中心。
Workflow 以预定义流程为中心。
Copilot 以人机协作为中心。
Agent 以任务闭环为中心。

这里必须避免另一个常见误区：不要把 Agent 理解为这些系统的“高级版本”。它并不是更先进的统一替代品，而是一种适用于特定问题空间的系统形态。很多优秀的生产系统反而是几种模式的组合：前台是 Chatbot 交互，后台由 Workflow 托底，在少量高复杂度节点中调用 Agent，并通过 Copilot 机制让人类在关键环节保持监督。

工程提示¶

如果一个问题本身可以用显式规则和固定流程稳定解决，那么优先使用 Workflow 往往比直接引入 Agent 更可靠、更便宜。

1.3 什么场景适合用 Agent，什么场景不适合¶

在工程实践中，真正重要的问题从来不是“能不能做 Agent”，而是“值不值得用 Agent”。因为 Agent 的引入意味着更高的系统不确定性、更复杂的状态管理、更严格的安全约束，以及更困难的评测与治理。只有在这些复杂性能够换来真实收益时，Agent 才是合理选择。

一般来说，以下几类任务更适合使用 Agent。

第一类是目标明确但路径不固定的任务。例如“定位一个线上报错的原因”“根据用户问题查询多个系统并给出处理建议”“读取若干文档后生成一份带引用的分析报告”。这些任务的目标可以定义，但达成目标的步骤会随着上下文变化而变化，因此很难完全预先写死流程。

第二类是需要动态调用多个外部工具的任务。比如代码助手需要读文件、搜索代码、运行测试；运维 Agent 需要查询监控、调用日志系统、访问配置平台；企业助手可能需要查知识库、读工单、调用审批服务。只靠模型自身参数知识无法完成这些动作，必须通过工具与真实环境建立连接。

第三类是需要根据中间结果不断调整计划的任务。例如一个排障 Agent 在拿到第一轮日志后发现线索不足，就需要继续查询监控指标；一个研究 Agent 在发现资料互相冲突后，需要追加检索和交叉验证。这里的关键不是“能不能列出一个计划”，而是“能不能在执行中更新计划”。

第四类是任务跨越多个步骤、多个系统甚至多个角色的场景。只要任务的真实完成过程不是单次输出，而是连续状态推进，那么 Agent 的价值就会开始显现。

与之相对，以下场景通常不适合优先引入 Agent。

第一类是流程完全固定、规则十分明确的任务。例如固定表单审批、规则引擎驱动的结算流程、格式严格的批处理作业。这类场景最需要的是确定性和可审计性，而不是灵活性。

第二类是高风险动作多、但缺少审批与约束机制的任务。比如直接修改生产配置、执行资金流转、批量操作核心数据。如果系统没有足够严格的权限控制、审计和人工确认，贸然引入 Agent 往往风险过高。

第三类是评判标准高度模糊、缺少反馈闭环的任务。如果系统自己都无法知道“做得对不对”，那就很难持续优化 Agent 的行为。一个没有评测标准和失败恢复机制的 Agent，通常只会停留在演示层面。

第四类是本质上只需要检索、模板填充或固定逻辑拼装的任务。很多团队把简单 FAQ、固定报表生成、表单映射之类的需求包装成 Agent，结果只是增加了复杂性，却没有带来真正的系统收益。

为了帮助读者做更具体的判断，可以在项目早期先问自己五个问题：

这个任务的执行路径是否高度不确定？
系统是否需要动态选择工具或信息源？
任务是否需要根据中间反馈改变后续动作？
我们能否定义成功标准、失败标准和回退策略？
我们是否有能力为这个系统加上权限、审计和评测？

如果这些问题大部分回答“否”，那么大概率并不需要 Agent，或者至少不需要把 Agent 放在系统中心。

工程提示¶

很多项目失败不是因为 Agent 做不出来，而是因为一开始就把它放进了错误的问题空间。先判断边界，再判断方案，往往比直接选框架更重要。

1.4 Agent 不是能力堆砌，而是闭环系统¶

在对 Agent 有了初步定义之后，还需要再澄清一个容易误导初学者的认知：Agent 并不是 Prompt、Tools、Memory 和 RAG 的简单相加。

这些能力模块当然重要，但它们本身并不会自动构成一个可用系统。真正决定 Agent 是否成立的，是这些模块能否围绕任务目标形成稳定闭环。一个典型的闭环通常包含以下阶段：

接收目标：理解用户想解决的实际问题。
理解状态：整理当前上下文、已有信息和约束条件。
选择动作：判断下一步是推理、提问、检索还是调用工具。
执行动作：真正与外部环境交互，获取结果或施加影响。
读取反馈：分析动作结果是否推进了任务。
调整行为：决定继续、修正、回滚、终止或请求人工介入。

如果缺少反馈闭环，系统就很容易退化成一次性生成器；如果缺少状态管理，系统就会在多步任务中迷失；如果缺少工具和外部反馈，系统就无法真正触达业务环境。很多看似“组件齐全”的 Agent 原型之所以效果不稳，原因往往不是少了某个功能点，而是没有把这些部件组织成一个可持续运转的系统。

因此，本书后续各章虽然会分别讨论 Prompt、Planning、Tool Use、RAG 和 Memory，但读者始终需要记住一个前提：这些都不是独立的终点，它们只是构成任务闭环的不同部件。

1.5 小结¶

Agent 不是“会聊天的大模型”，也不是“接了几个工具的对话框”。从工程视角看，Agent 是一个以目标为导向、以状态为基础、以工具为手段、以反馈为驱动的软件系统。它与 Chatbot、Workflow 和 Copilot 都有关联，但不能简单互相替代。

比起“Agent 很强大”这样的宽泛表述，更有价值的问题是：这个问题是否真的需要动态决策、外部行动和持续反馈？如果答案是肯定的，Agent 才值得进入系统中心。否则，简单系统通常反而更好。