AI 代理正在改变我们的工作方式。 传统软件通常构建的是确定性（“若 X 则 Y”）且刚性的系统，难以处理模糊性或多变目标——但这一切正在改变。随着大语言模型（LLM）的进步，能够自主推理分步并采取行动以完成目标的智能系统正在出现。这些 AI 代理（AI agents） 正在接管越来越多原以为只有人类才能完成的工作，而这一切才刚刚开始。
在读完本书后，你将熟练使用 OpenAI Agents SDK 创建 AI 代理。最好的学习方式就是上手实干，用该框架构建代理系统。不过，在动手之前，我们需要从最基础的问题开始—— “什么是 AI 代理？”
本章将覆盖回答这一问题所需的一切，更重要的是，为全书其余内容打下基础。我们会精确定义 AI 代理，并说明它与传统系统的区别。这一点很重要，因为许多读者常把 AI 代理与复杂应用（如聊天机器人或反欺诈系统）混为一谈。在构建之前，先理解 AI 代理系统的工作原理至关重要。我们还会探讨 AI 代理在生产力之外的实际应用。最后，我们将梳理构建 AI 代理时可用的设计模式与框架，并解释为何 OpenAI Agents SDK 是大多数生产系统的务实之选。
本章将涵盖：
- AI 代理系统的概览，以及与传统系统相比的优劣势
- AI 代理的实际应用
- AI 代理的构成（anatomy）与用于构建它们的设计/框架模式
在本章结尾，我们会形成一张心智蓝图：现实世界中的 AI 代理是如何装配起来的——它将成为我们后续动手构建时的指南针。
技术准备
本章以理论概览为主，为后续实作打地基，因此不写代码也不开发应用。但要完成全书其余章节的练习与项目，请在开发环境中准备好：
- 操作系统：Windows 10/11、macOS 或 Linux（推荐 Ubuntu）
- Python：3.8 或更高（终端/命令行运行
python --version查看） - OpenAI 账户：在 platform.openai.com/signup 注册
- OpenAI API Key：创建账户后获取；使用 OpenAI Agents SDK 必需
- 代码编辑器：VS Code、PyCharm 或任意偏好的 IDE/编辑器
全书的示例与完整代码会在配套 GitHub 仓库提供：
github.com/PacktPublis…
建议你 clone 该仓库，按需复用/改造示例代码，并在学习过程中参考。
AI 代理概览
在深入探索之前，我们先直观理解：什么是 AI 代理、它与传统软件根本区别何在，以及这带来的利弊。由于定义会随着技术演进而变化，先明确关键概念——包括其智能自治、推理能力、自适应解题等优势——能为后续的应用与构建方法打好铺垫。
什么是 AI 代理？
AI 代理是能独立运行以达成特定目标的智能系统：它感知所处环境并采取行动。其关键特征包括：能从宽泛甚至含糊的目标中思考与推理、能制定计划以实现目标，并能自主使用手头的一组工具与外界交互以完成目标。
这与确定性、按预定义步骤运行、遇到计划外情形就无法应对的传统系统形成鲜明对比。AI 代理可以观察环境—推理需求—持续行动。
AI 代理通过将 LLM 的智能与推理与标准化 API 行动结合而实现上述能力。下面用一个简单的类比来加深理解，并把它与传统自动化框架区分开来。
用类比理解 AI 代理
设想你是五星餐厅的主厨，要培训两位学徒：Carlos 和 Adam。
- Carlos 像传统的自动化系统/模型；
- Adam 则像一个 AI 代理。
培训与他们的工作方式完全不同：
- Carlos 需要你把每道菜的每一步教到位：做煎蛋要如何开冰箱、取鸡蛋、开火、倒油、打蛋……步骤必须逐条定义。之后他会严格按步骤执行。
- Adam 更像人：你教他如何在厨房行动——如何拿食材、如何用灶、一些烹饪学基础……当你让他做煎蛋时，他会依赖自己的推理与已学的动作/工具去完成，而不是照抄固定步骤。
两人都能做出好菜，但长短各异。Adam 能拥抱复杂与模糊；因具通用行动能力与推理，他不仅能做煎蛋，还能做炒蛋、水波蛋、溏心蛋，甚至能用同一套“动作”制作更多菜式。
这正是 AI 代理 vs. 传统自动化 的完美类比：智能自治让 AI 代理能执行大量含糊多变的任务，这是传统方法无法复制的。
注：智能自治需要护栏。若“脑子”（模型）被误导，自主代理可能做出糟糕决定。我们稍后会讨论如何通过提示（prompt）与规则（guardrails）引导与约束代理，确保其自治负责任地发挥。关键 takeaway：AI 代理具备目标导向的独立性，这使其不同于传统自动化系统。
与传统系统的优劣对照
从类比可见，AI 代理除能拥抱复杂性外，还有这些优势：
-
目标导向自治：Adam 不只会煎蛋，还能做炒蛋/水波蛋/溏心蛋，甚至创新菜式；必要时还能调整步骤顺序。
-
推理与自适应解题：
- 因人下菜：可根据顾客口味把熟度做得更/更不凝固，因他理解“多加热更干”。
- 缺料应变：能寻找替代食材，在模糊、真实世界里游刃有余。
而 Carlos 只会固定做法，遇到外部阻碍（冰箱打不开、灶点不着）就停摆；Adam 则能适应。
但 AI 代理也有劣势，在某些场景下足以让它不是最佳选择：
- 幻觉：LLM 可能“自信地胡说”，代理可能做出不合逻辑的动作（例如把牛排端上来却声称是豆腐，后果严重）。
- 过度即兴：为快而常开大火，忽视安全；为达目标可能走了非最优路径。
- 成本与延迟：推理需要时间与算力，可能比传统软件慢且贵 100 倍。
- 可解释性不足：难以清晰说明采取某步行动的理由，这是深度学习常见弱点。
了解了 AI 代理的定义与优劣，我们就能进一步思考：它相较传统系统的实际应用价值何在。
AI 代理的实际应用
AI 代理不只是一个时髦概念——它们正成为企业利用 AI 解决真实问题的核心方式。尤其是早期采用者，已在组织的各个层面使用代理：既有面向客户的一线代理（销售产品、解决问题），也有用于内部生产力的代理（软件开发、研究等）。
生产力提升
AI 代理最直观、最直接的动机是提高生产力，方式是替代或增强传统软件无法替代/增强的人类工作。代理能自主处理这些任务，从而让人类把精力转向更高层次的战略与创造性工作。
以客服为例：传统呼叫中心可能需要数十到上百名人工坐席。传统软件也许会用按照树状问答层级的自动聊天机器人替代部分工作，但它们无法采取行动、难以应对模糊请求。传统系统或许能回答“如何重置密码？ ”，却很难处理“请查看我最近一笔交易并告诉我在哪里消费，然后帮我申请退款，同时给我的会计发送确认邮件？ ”。具备合适架构与工具链的 AI 代理可以轻松应对，并在必要时引入人工协作。事实上，预计在不久的将来，95% 的客户服务将由 AI 处理（www.tidio.com/blog/ai-cus…）。
软件开发也是代理密集涌入的职能领域。众所周知，GitHub Copilot 等 AI 编码助手已被证明可使开发者完成任务快 55% ，并帮助他们保持心流；开发者还报告编程时的挫败感降低 60% （github.blog/news-insigh…）。AI代理更进一步：已有公司打造全自主开发代理，贯穿整个开发生命周期修复错误、构建新功能（理解需求、写代码、测代码、管理 PR、更新 Jira、与经理沟通）。除 Copilot 外的例子还包括 Devin、Cursor 等。
此外，还有面向特定领域/行业的生产力代理（如 HR、法律，以及银行、零售等）。例如在 HR 场景，代理可自动化候选人筛选、预测员工流失、个性化入职流程；在法律行业，像 MinterEllison 部署了 Lantern 等工具以加速文档审阅，每小时处理数千份文件，远快于人工；在银行业，JPMorgan Chase 等机构用代理自动化个性化投顾及相关研究，提升客户服务。
总体而言，AI 代理通过执行或增强人类任务，成为生产力的催化剂。
更佳的人机交互
AI 代理正在重塑我们与计算机的交互方式。传统上，多数交互遵循僵硬流程，且需要领域专家来完成。比如零售经理若想分析门店销售在一段时间内相对其他门店的表现，往往需要数据分析师把经理的请求翻译成 SQL 在数据库上执行。或者通过更高抽象层的工具（Power BI、Excel 等）来实现，但这仍要求经理熟悉这些工具（菜单、表单等）。
AI 代理彻底移除了这道门槛：它们用自然语言接收请求，并内置执行 SQL 的工具链。LLM 可将用户需求完全翻译为所需 SQL，并将结果解释给用户。经理因此可以直接与数据对话。
而且这不只限于文本：代理正不断多模态化，能处理语音与视觉。例如，语音代理可让医生口述病历并自动生成处方发送至药房；零售商用视觉能力审计货架、自动下单补货，并在货架空时指示店员补货。
总之，AI 代理正推动从“工具”到“伙伴”的转变：不再要求用户适应软件（学习界面、按固定方式输入），而是软件适应用户，消除学习门槛与相关摩擦。
崭新的商业形态
AI 代理不仅提升生产力与交互体验，还在催生全新的业务与策略。类比互联网：它让既有任务更快（写邮件快于邮寄纸信），同时也创造了全新商业模式（电商、数字化市场、在线服务等）。
例如，Jasper.ai、Copy.ai 等公司涌现，提供由 AI 代理驱动的平台，能自主生成营销内容、社交媒体帖子、销售文案。这类解决方案让企业大幅加速内容生产、降低营销成本，并将信息传达的规模扩展到传统方法难以企及的程度。
AI 代理的构建方法论（Build methodology of AI agents）
现在我们已经从概念与应用层面理解了 AI 代理，接下来将讲解 AI 代理的“解剖结构” ，以及自顶向下、逐步设计与构建它们的方法。理解这些组成部分有助于我们系统化地设计与实现代理，确保各组件齐备并正常协同。
AI 代理的解剖结构（Anatomy of an AI agent）
多数 AI 代理遵循一个通用模式，可拆分为三大核心组件：
- 模型（Model） ：大脑。负责理解输入、推理行动、生成输出。通常是带有系统指令与控制逻辑框架的 LLM，使其具备推理与迭代能力。
- 工具接口（Tooling interface） ：手与眼。赋予代理行动能力，例如通过 API 或本地函数调用去发邮件、查网页等。
- 记忆与知识（Memory and knowledge） ：参考教材。包含支持代理完成任务所需的信息，如数据库、文档等。
模型（Model）
一切智能代理都由某个“模型”驱动，使其能够理解输入—拟定行动方案—生成动作参数—审阅动作结果—迭代，直至达到目标。理论上，这个“核心模型”未必一定是 LLM——只要能遵循我们前述的 **“观察—推理—行动”**范式即可。但在实践中，通常是强大的 LLM，例如 OpenAI 的 GPT-4o 或 Google Gemini 2.5 Pro。
模型即代理的大脑，因此选择合适的 LLM 至关重要。常见权衡包括：
- 成本（Cost） ：以每处理一定 token 的美元费用计价。通用基座模型通常比重推理、深度微调的模型便宜。
- 时延（Latency） ：响应速度取决于模型架构以及部署与托管方式/地点。
- 性能（Performance） ：随场景而异。某些模型擅长编程，另一些更适合创作。有的支持多模态（文本/图像/音频/视频的输入输出）。上下文窗口大小也不同，决定一次能读/写多少内容。
- 偏向（Bias） ：模型的知识面与倾向不同。许多模型有知识截断日期（只“知道”某日期之前的事件），若你构建需要回忆近期事件的代理，这会是问题。另外，模型可能存在政治或信息偏向。例如据《卫报》报道，DeepSeek 展现出明显的亲中倾向（www.theguardian.com/technology/…）。
注意
对于知识截断、倾向偏差等问题，可以通过 RAG（检索增强生成） 、更精细的提示词工程、或训练后微调来缓解。本书稍后会涉及。
还需注意，为 AI 代理提供动力的模型并不是为每个代理“定制训练”的专用模型，而是通用预训练模型，通过系统指令使其以“代理”的方式行事。换言之，ChatGPT、旅行规划代理、GitHub Copilot、客服代理等，底层都可能是同一个 GPT-4o；它们的差别在于提供给模型的指令以及与其他组件的交互方式。
这些“指令”通过系统提示（system prompt）提供。系统提示规定模型的行为方式与角色定位。很多与代理性能相关的“调试”，本质上是调整系统提示以获得更理想的结果。类比而言：撰写系统提示就是在定义模型的身份与使命，因此准确、细腻的系统提示极其重要。
控制逻辑框架（Control logic framework）
另一个关键点是控制逻辑框架——也就是让代理循环执行“观察—推理—行动”直到达成目标的能力。这个循环不一定由模型自身完成；通常由代理框架的代码来驱动模型反复运行此循环。它通常被视为模型组件的一部分，其伪代码可概括为：
读取用户目标并创建行动计划
For 行动计划中的每一步:
生成该步的动作输入
执行动作
获取结果
将结果写入记忆
若有必要或尚未达成目标，则调整计划
若目标已达成:
返回结果给用户
不同的“代理式（agentic）框架”在具体实现上各有差异，但大多遵循高层规划 + 执行的结构。常见思路包括 CoT（chain-of-thought，链式思维） 与 ReAct。还有一些框架会让代理先生成答案，再进行第二遍“裁判”式评估，由同一个或另一个代理复核第一遍的回答与推理链。
工具接口（Tooling interface）
我们先前提到，AI 代理的关键要求之一是其与外部世界交互的能力，这部分称为工具接口。通常，LLM 通过文本、图像、音频与用户交互，本质上是从其深度神经网络中生成 token。而所谓外部世界，是指模型之外的环境，通常是指其他应用（如电子邮件、网页搜索、控制你的电脑等）。工具接口让 AI 代理能做事，相当于它的手与眼。
AI 代理与其他应用交互的机制，是为代理提供一套在这些应用中何时、如何执行动作的框架。比如，一个帮助处理邮件的 AI 代理，其框架可包含如下动作（伪代码）：
动作 #1：发送邮件
描述：向用户发送一封电子邮件
参数：to_email_address, email_subject, email_body
动作 #2：列出所有邮件
描述：列出所有邮件（含 email_id）
参数：search_term（可选）
动作 #3：读取邮件
描述：返回某封邮件的内容
参数：email_id
当 AI 代理注册了这些工具后，其模型与控制逻辑框架会决定何时使用哪些动作，并为这些动作生成正确的输入。
例如，AI 代理接到任务：找出与“咖啡业务扩张提案（coffee expansion proposal）”相关的所有邮件，进行总结，并把摘要发送给用户的经理。它可能会先调用“列出所有邮件”并传入搜索词 coffee expansion proposal，随后使用“读取邮件”逐封读取，借助 LLM 生成摘要，最后调用“发送邮件”把摘要发出。
将这些工具注册到 AI 代理的方式，取决于所用的代理框架。但无论哪种框架，AI 代理通常都需要具备以下能力：
-
知晓工具的存在：通常做法是把工具名称、定义与参数自动加入模型的**系统提示（system prompt）**中。
-
执行工具动作：一般由所选代理框架自动完成。执行形式可以是：
- 本机函数调用（运行代理的客户端同时包含工具逻辑），或
- 服务端 API 调用（工具逻辑部署在服务器，代理通过调用服务器 API 来执行）。
-
接收工具输出并回传给模型：这通常也由所选的代理框架自动完成。
我们先前将 AI 代理定义为能够迭代地与外部世界交互以实现目标的系统。由此可见，工具接口（即代理如何与外部世界交互）就是核心组件。因此，编写工具本身（实现具体逻辑、提供详尽说明与输入参数、注册到代理、选择合适的动作粒度、错误处理、如何向代理暴露等）是本书的关键模块之一，我们会用整整一章进行讲解。
记忆与知识（Memory and knowledge）
前文我们把 AI 代理称作智能系统。
在 AI 代理中，记忆（memory）与知识（knowledge）是相互关联但并不相同的概念。两者的目的，都是在用户总体请求的背景下，为模型提供相关上下文，以提升代理的智能性与有效性。下面分别说明两者的含义及其为代理提供更多上下文的实现方式。
记忆（Memory）
记忆指代理对当前与以往交互中相关信息的保留。常见有两类：
工作记忆（Working memory）
工作记忆是当前会话中的交互历史。可以把它类比为聊天场景：你先问 “太阳有多热？” ，得到回答后紧接着问 “它有多大？” ——由于模型在工作历史中保留了前一轮对话，它能明白“它”指的仍是太阳。
在机制上，最近的聊天轮次会被保存在发送给模型的提示（prompt）里，使 LLM 随时能回溯并理解用户请求的上下文。因此我们可以连问带追问，而系统仍能准确响应。需要注意的是，将工作记忆**注入系统指令（system instructions）**也很常见。
工作记忆有容量上限。例如，GPT-4o 的上下文可能只有 128K tokens；超过后，较早的消息会被滑动窗口策略丢弃以保留最近且相关的信息，具体策略随代理框架而异。
长期记忆（Long-term memory）
长期记忆是跨会话存储的历史信息，使体验从无状态（每次请求独立处理）变为有状态（每次请求都会参考历史）。在消费者视角，被认为“更聪明”的代理通常具备某种长期记忆能力，例如一个帮助你写邮件的代理。
在机制上，代理会把交互中的关键信息写入数据库，并在之后读取（两者都可通过工具调用完成）。例如，可为代理提供如下工具：
动作 #1：存储信息
描述：保存关于用户的重要信息
参数：information
动作 #2：读取信息
描述：检索关于用户的重要信息
记忆与知识的实现会随代理框架与选用模型而变化。多数情况下，工作记忆与训练知识属于“内建能力”，无需额外开发；而长期记忆或外部知识则需要专门的工具链，会增加系统复杂度——本书将用一章专讲。
知识（Knowledge）
知识指代理从外部知识库中检索并回忆相关信息。与“记忆”不同，知识不是来自用户以往交互，而是来自文档、数据库、文件、文本语料等来源。常见两类：
训练知识（Training knowledge）
训练知识是模型训练语料中固有的信息。例如，所有 LLM 都能回答 “太阳有多大？” ，因为答案存在于其训练语料中，也称为通用知识或内置知识。
LLM 的训练知识是其强项：能在数秒内调取海量常识并适配用户请求。但就AI 代理而言，其用途有限：
- 代理通常不以“背常识”为目标；简单的“常识问答”交给纯聊天更合适。
- LLM 无法跨越其知识截断日期，也无法回忆非公开的信息——而这两点恰恰是实用代理所必需的。
因此，我们经常刻意要求模型忽略自身训练知识，以免干扰。
更理想的做法是让代理实时检索与用户请求强相关的上下文——这就需要另一类知识。
检索知识（Retrieved knowledge）
检索知识是代理在运行时，基于用户请求，从知识存储中实时检索到的信息。与训练知识静态固定不同，检索知识动态可更新。知识库可以是文档库、数据库等；关键在于只把与当前请求相关的片段在运行时注入模型。
在机制上，这依赖与长期记忆类似的工具：
- 向量数据库 / RAG（检索增强生成）
- 结构化 API
- 文件库搜索（如 SharePoint、Google Drive）
- Web 搜索
代理用用户输入在这些来源中搜索相关记录/文档，再把结果作为上下文提供给模型生成回答。
集成检索知识的好处很多，尤其是代理可以：
- 回答最新的或专有的问题；
- 提供引用/来源，提高可追溯性（而单靠训练知识很难给出来源）。
这类相关知识是让代理有用且有影响力的关键。例如，担任企业 HR 的代理，只有通过知识检索，才能回答休假政策、福利、病假等问题；销售代理也需检索公司 CRM 中的客户记录来回应询问。
设计模式（Design patterns）
所有 AI 代理的设计模式都包含那三个核心组件，但在实现方式上各有差异，尤其体现在控制逻辑框架与工具链成熟度上。常见模式包括 ReAct、CoT、规划—执行（planner–executor） 与 分层/多代理（hierarchical/multi-agent） 。
CoT（Chain of Thought）
CoT 的思路很直接：在给出最终答案前，先让模型逐步输出推理过程。直白地说，就是“先想清楚要怎么解，再按步骤去解”。
局限：无法执行动作，更重要的是，无法依据动作结果调整计划。
ReAct（Reasoning + Acting）
ReAct 是前文伪代码里描述的模式：强制代理在一个连续循环中交替推理与行动，选择工具/动作、获取结果并回灌到循环，直至达成目标。与 CoT 的关键区别在于它能采取行动并据结果调整计划。这非常适合需要推理 + 调用工具来解决复杂任务的“现实世界”代理，也因此成为多数传统 AI 代理的首选模式。
规划—执行（Planner–execution）
在该模式中，规划与执行由不同系统承担：先由一个代理生成高层计划，再由另一个（或多个）代理去执行计划中的各项任务。适用于超长期、复杂或易模块化并可下放给子代理的任务。
分层 / 多代理（Hierarchical / Multi-agent）
将任务划分给多个专长代理（特定领域/任务的专家）。还能分布式并行开展工作，而非严格串行。它很像一家公司：有经理/总负责人制定与分配任务，下设 CMO/COO/CFO 等各司其职。
例如，构建“客户投诉处理”代理：
- 一个接收与规划的代理生成行动方案；
- 多个专长代理各自执行：如客户信息代理查询客户、合规模块审阅政策、回复代理起草答复。它们各自拥有模型、工具基础设施、记忆与知识。
注
这些模式并非互斥。现实中的代理（尤其是接下来要简述的框架所构建的）常会混用，取决于任务复杂度与可用工具。例如 OpenAI Agents SDK 就结合了 ReAct 与 分层/多代理 模式。
除设计模式外，业界还构建了多种开发与部署框架，在所采用的模式与功能集上各不相同，包括 OpenAI Agents SDK、LangChain、LangGraph、AutoGen、AutoGPT、Crew AI 等。
总体来看，OpenAI Agents SDK 以其极简与灵活脱颖而出：
- 具备与模型无关的强大架构，既能整合 OpenAI 的能力（如网页搜索、电脑操作）也能接入自定义工具；
- 内置追踪（tracing） 、护栏（guardrails）等企业级安全性与可观测性；
- 开源且快速演进（例如在该模块发布数周后就加入了 MCP（Model Context Protocol） 集成）。
总结（Summary）
本章我们了解了 AI 代理、其实际应用与构建方法论：
- AI 代理是能自主达成目标的智能系统，具备推理、规划并通过工具与外界交互的能力。不同于需要刚性、预定义步骤的传统自动化，AI 代理能处理模糊性并动态调整步骤与行动。
- 它们通过替代/增强人类工作帮助组织更快运转，也让个人无门槛直连工具与数据；同时，企业正基于代理架构孵化全新业务形态。
- 代理的核心解剖结构包括：模型、工具接口、记忆与知识。设计模式决定这些组件如何协同：如 ReAct 让代理在每一步行动中推理并自适应；多代理将任务分派给专长子代理以提升效率。不同框架对这些理念有不同实现。
- 在这些框架中，OpenAI Agents SDK 以极简、可扩展的架构、内置可观测性与企业级特性，成为构建生产级 AI 代理的有力之选。
下一章将深入解析 OpenAI Agents SDK 框架。
