从零搭建AI Agent：用Python实现对话智能体核心功能

文章正文

在AI Agent（智能体）成为技术热点的当下，很多开发者想要动手实践却不知从何入手。本文基于一份实战教程，带你理解Agent的两大核心概念——大模型与提示词，并通过Python代码完整实现一个最基础的对话智能体。掌握这一步，是搭建复杂Agent的起点。

理解Agent的两大核心：大模型与提示词

AI Agent（智能体）是一种能够感知环境、自主决策并执行任务的AI系统。与传统的单次问答式AI不同，Agent具备目标导向性、持续交互能力和工具调用能力，能够将复杂任务分解为多个步骤并逐一完成。

从架构层面看，Agent本质上是一个「感知-决策-行动」的闭环系统：感知层负责接收外部输入（文本、图像、传感器数据等）；决策层由大语言模型承担，负责理解意图、规划步骤；行动层则通过工具调用（Function Calling）与外部世界交互。这一架构与强化学习中的「智能体-环境」交互范式高度一致——在经典强化学习中，智能体通过观察环境状态（Observation）选择动作（Action），环境反馈奖励信号（Reward）并转移到新状态，智能体据此更新策略。LLM-based Agent的核心创新在于用预训练语言模型替代了传统的策略网络（Policy Network）：传统策略网络需要在特定环境中通过数百万次交互样本才能学会一项任务，而语言模型凭借预训练阶段积累的世界知识，无需大量环境交互即可泛化到新任务，这使得Agent的开发门槛从「需要专业强化学习工程师」降低到「会写提示词的开发者」。当前Agent热潮的兴起，主要得益于大语言模型（LLM）推理能力的突破——GPT-4、Claude、DeepSeek^广告等模型已具备足够强的指令理解和逻辑推理能力，使得Agent从概念走向实用。

要搭建一个智能体，首先必须理解它最重要的两个组成部分：大模型和提示词。

大模型是整个智能体的核心，可以把它理解为一个「超级大脑」。从技术层面看，大语言模型（Large Language Model，LLM）是基于Transformer架构、经过海量文本数据训练的神经网络模型。Transformer架构由Google在2017年论文《Attention Is All You Need》中提出，其核心创新是「自注意力机制」（Self-Attention）。

自注意力机制的工作原理可以这样理解：对于输入序列中的每个词，模型会将其映射为三个向量——Query（查询向量，代表「我想关注什么」）、Key（键向量，代表「我能提供什么信息」）、Value（值向量，代表「我实际携带的信息」）。通过计算Query与所有Key的点积并经过Softmax归一化，得到注意力权重分布，再用这些权重对Value向量加权求和，就得到了该词融合了全局上下文信息的新表示。这一机制允许模型在处理「银行」这个词时，根据上下文动态判断它指的是「金融机构」还是「河岸」，从而捕捉长距离语义依赖关系。

值得深入理解的是，自注意力机制的「多头」（Multi-Head）变体是现代大模型的标配设计：通过将Query/Key/Value投影到多个不同的子空间并行计算注意力，模型能够同时从多个语义维度（如句法关系、语义相似性、指代关系等）捕捉词语间的依赖，最后将多个头的输出拼接融合。这种设计类似于CNN中多个卷积核从不同角度提取特征的思路，赋予了模型更丰富的表达能力。相比此前主流的RNN/LSTM架构——后者需要逐步传递隐藏状态，长序列中早期信息容易在反向传播时梯度消失——Transformer的自注意力机制允许任意两个位置直接交互，且所有位置可以并行计算，使得在超大规模数据集上训练成为可能。现代大语言模型均基于Transformer的解码器（Decoder-only）变体构建，采用因果注意力机制（Causal Attention）确保每个位置只能关注其之前的Token，参数量从数十亿到数万亿不等。

大语言模型的核心机制是「下一个Token预测」——模型通过学习语言的统计规律，在给定上下文的情况下预测最可能出现的下一个词。DeepSeek、GPT系列等现代大模型通常还经过RLHF（基于人类反馈的强化学习）对齐训练。RLHF解决的核心问题是「能力」与「意图对齐」之间的鸿沟——一个预训练模型可能拥有强大的语言能力，却不知道如何以对人类有益的方式使用这种能力。RLHF的流程分三阶段：首先对预训练模型进行监督微调（SFT）；其次训练奖励模型（Reward Model），让人类标注者对模型多个输出进行排序，学习人类偏好；最后使用强化学习算法以奖励模型的评分为信号优化语言模型。近年来，DPO（Direct Preference Optimization）作为RLHF的简化替代方案被广泛采用，它直接从偏好数据中优化模型，无需单独训练奖励模型，降低了训练复杂度。OpenAI的InstructGPT论文证明，经过RLHF训练的1.3B参数模型在人类评估中甚至优于未经对齐的175B模型，说明对齐训练对实用性的提升远超单纯扩大参数规模。用户与大模型进行对话，它会根据输入返回相应的消息。而在这个交互过程中，用户发送给AI的内容，本质上就是提示词（Prompt）。

提示词的两种类型

提示词是向AI模型发送的指令或输入，它决定了AI如何理解你的意图并作出回应。从模型内部机制来看，提示词的质量直接影响模型的「注意力分配」——精心设计的提示词能够激活模型在预训练阶段学到的相关知识和推理模式，而模糊或歧义性的提示词则可能导致注意力分散到无关信息上，进而决定输出质量。根据作用不同，提示词分为两类：

系统提示词（System Prompt）：用于设定AI的基础人设、行为规范以及全局约束。它相当于给AI立下的「基本规则」，在整个对话过程中持续生效。从技术实现角度，系统提示词在每次API调用时都会被放置在messages列表的首位，以role: system标识，模型在生成每一个Token时都会受到系统提示词的条件约束。需要注意的是，系统提示词并非绝对不可突破的「防火墙」——「提示词注入攻击」（Prompt Injection）是当前Agent安全领域的重要研究课题，攻击者可能通过精心构造的用户输入诱导模型忽略系统提示词的约束，这也是生产环境中需要额外设计安全防护层的原因。
用户提示词（User Prompt）：即用户每次提问时的具体内容，是每一轮对话的实际输入。

举个直观的例子：当你打开DeepSeek官网，输入「你好」，这个「你好」就是一个用户提示词。背后的大模型接收到后，据此生成回复返回给你。理解了这个基本流程，接下来我们用代码把它复现出来。

环境准备与模块引入

实现的第一步是搭建开发环境。在VS Code中创建本地虚拟环境，并新建代码文件。

接下来需要引入两个关键的第三方模块：

OpenAI：用于调用兼容OpenAI接口的大模型API。值得一提的是，OpenAI API格式已成为大模型接口的事实标准——DeepSeek、Moonshot、智谱AI等众多国内外模型厂商均提供与OpenAI格式兼容的API。OpenAI API格式之所以能成为行业标准，原因是多方面的：OpenAI是商业化大模型API的先行者，其接口设计经过大量开发者验证；messages列表+role角色的设计直观映射了多轮对话的自然结构；Function Calling、流式输出（Streaming）等扩展能力设计合理，易于实现。对于模型厂商而言，兼容OpenAI格式意味着可以直接复用庞大的OpenAI生态工具链（如LangChain、LlamaIndex等框架），大幅降低开发者的迁移门槛，形成了正向的生态飞轮效应。这意味着开发者只需学习一套接口规范，即可无缝切换不同的底层模型，极大降低了迁移成本；
python-dotenv：用于从本地 .env 文件读取API密钥等配置信息。这一实践遵循「配置与代码分离」的工程规范（即十二要素应用方法论中的第三要素），避免敏感信息出现在代码仓库中，防止因误提交到GitHub等公开平台而导致密钥泄露。

在虚拟环境的终端中，通过 pip install 安装这两个模块即可。这一步是所有后续开发的基础。

延伸：Python虚拟环境的工程价值 Python虚拟环境（venv）是隔离项目依赖的标准实践。不同项目可能依赖同一库的不同版本（如一个项目需要openai==0.x，另一个需要openai>=1.0），若共用全局环境将产生版本冲突。虚拟环境为每个项目创建独立的Python解释器和包目录，彻底杜绝依赖污染。在团队协作中，通常配合requirements.txt或pyproject.toml锁定依赖版本，确保不同开发者、CI/CD流水线和生产环境的依赖完全一致，是「可复现构建」这一工程原则的具体体现。

接着它这里面是需要用到一些

调用DeepSeek API实现基础对话

有了环境和模块，下一步就是完成后台的对话交互。核心技巧是：直接参考DeepSeek官方API文档。

在DeepSeek的API官方文档中，提供了调用对话接口的标准代码示例。将其复制到自己的文件中，再做少量修改，就能得到一个最基础的对话程序。

安全管理API密钥

API密钥的安全管理是工程实践中的重要规范。直接把API密钥硬编码在代码里既不安全也不规范。推荐的做法是：

新建一个 .env 文件；
将从DeepSeek官网获取的API Key填入其中；
在代码里通过读取本地环境变量的方式调取密钥。

python-dotenv库通过读取.env文件将敏感配置注入环境变量，在团队协作场景下，.env文件通常被加入.gitignore，配合.env.example模板文件供团队成员参考配置项。在生产环境中，密钥管理则会进一步升级为使用AWS Secrets Manager、HashiCorp Vault等专业密钥管理服务，这些工具提供密钥轮换（Key Rotation）、访问审计、细粒度权限控制（基于IAM策略）等企业级安全能力——密钥轮换尤为重要，它能确保即使某个密钥泄露，其有效期也被限制在较短的时间窗口内，大幅降低安全风险。

延伸：API密钥泄露的真实风险 API密钥一旦泄露后果严重：攻击者可利用泄露的密钥无限调用付费API，产生巨额账单（业内俗称"账单劫持"，Bill Hijacking）；在企业场景中还可能导致数据泄露或服务中断。GitHub的Secret Scanning功能会自动扫描公开仓库中的已知格式密钥并发出告警，但这仍是事后补救。最佳实践是在提交前通过git-secrets、pre-commit等工具在本地阻断含密钥的提交，从源头消除风险，而非依赖平台的事后检测。

获取API Key的流程也很简单：进入API文档页面，创建API Key，填写用户名后点击创建即可。这样代码本身不暴露敏感信息，密钥统一在 .env 文件中管理，既安全又便于维护。

我们在这里面来启用一下它

实现多轮对话：让Agent持续交互

最初的代码有一个明显限制：每次运行只能发送一次对话，且对话内容是写死在代码里的。要让程序变成真正可交互的Agent，需要引入循环机制。

添加 while 循环实现持续交互

具体做法如下：

使用 while 循环包裹对话逻辑，让程序可以反复接收输入；
通过 input() 函数动态获取用户每次输入的内容；
设置退出条件——当用户输入「退出」时，终止循环。

改造后，程序就能持续接收用户提问、返回回复，形成真正的多轮交互体验。

同时我们在这里面给它一个退出条件

组织 messages 消息结构

在API调用中，messages 参数承载了对话内容。OpenAI API的messages参数采用角色（role）+ 内容（content）的列表结构，支持三种角色：system（系统）、user（用户）、assistant（助手）。这种设计模拟了真实对话的上下文堆叠方式——每一轮对话都被追加到列表中，模型在生成回复时会「看到」完整的对话历史，这也是多轮对话能够保持上下文连贯性的根本原因。messages主要包含两个部分：

系统提示词：初始设定，如「你是一个助手」；
用户提示词：用 user_input 替换写死的内容，即用户每次的真实输入。

需要特别注意的是，随着对话轮次增加，messages列表会越来越长，最终可能超出模型的**上下文窗口（Context Window）**限制。上下文窗口是大语言模型一次能够处理的最大Token数量——Token是模型处理文本的基本单位，由分词器（Tokenizer）将原始文本切分而来，并非等同于字符：中文通常1-2个字符对应1个Token，英文约4个字符对应1个Token，这也是为什么同等内容的中文文本往往比英文消耗更多Token的原因。早期GPT-3的上下文窗口仅4K Token，而当前主流模型已扩展至128K甚至更长（如Claude 3系列支持200K Token，相当于约15万字的中文内容）。

上下文窗口的扩展并非没有代价：由于自注意力机制的计算复杂度与序列长度呈平方关系（O(n²)），更长的上下文窗口意味着更高的计算开销和推理延迟，这也是为什么即便模型支持超长上下文，在实际应用中仍需权衡使用的原因。

延伸：分词器（Tokenizer）的设计原理 现代大模型普遍采用BPE（Byte Pair Encoding，字节对编码）或SentencePiece等子词分词算法。BPE的核心思路是从字符级别起步，通过统计训练语料中最高频的字符对并将其合并为新子词，反复迭代直至达到预设词汇表大小（通常3万至10万）。这种设计兼顾了词汇覆盖率与序列长度效率：高频词被编码为单个Token（如"the"），低频词或新词则被拆分为多个子词Token（如"tokenization"→"token"+"ization"），实现了对任意文本的无损编码，同时避免了词典外（OOV）问题。不同模型使用的分词器存在差异，导致相同文本的Token数可能不同，这在估算API调用成本时需要特别注意。

当对话历史超出上下文窗口时，模型将无法「看到」早期对话内容，导致上下文丢失。这催生了多种记忆管理策略：

滑动窗口（保留最近N轮对话）：实现简单，但会丢失早期重要信息；
摘要压缩（用模型将历史对话压缩为摘要后注入系统提示词）：能保留关键信息，但摘要过程本身消耗Token且可能引入信息损失；
向量数据库检索（将历史对话嵌入为向量存储，在每轮对话前检索最相关的历史片段召回）：这是RAG（检索增强生成）技术在Agent记忆管理中的典型应用——文本通过嵌入模型（Embedding Model）转化为高维向量，存储在Pinecone、Chroma、Milvus等向量数据库中，检索时通过计算余弦相似度找到语义最相关的历史片段，实现「按需回忆」而非「全量记忆」，在Token效率和信息完整性之间取得平衡。

这些记忆管理策略正是后续「记忆管理」模块需要解决的核心问题，也是区分简单聊天机器人与真正智能Agent的关键能力差异。

完成这些设置后运行程序，输入「你好」，就能看到Agent返回的回复。为了让输出更清晰，还可以将回复内容用边框格式展示。

我们是把它给它框起来

用系统提示词塑造AI人设

程序跑通后，最后一步是体验系统提示词的威力。系统提示词工程是当前AI应用开发的核心竞争力之一。在商业产品中，系统提示词往往包含角色定义、能力边界、输出格式规范、安全限制、业务知识注入等多个维度，长度可达数千字——例如，GitHub Copilot的系统提示词会注入代码风格规范和仓库上下文；客服机器人的系统提示词会包含产品知识库摘要和标准回复话术；金融类应用的系统提示词则会包含严格的合规免责声明和风险提示要求。

提示词工程（Prompt Engineering）已发展为一个独立的技术方向，涵盖多种核心技巧：

思维链（Chain-of-Thought，CoT） 通过在提示词中加入「让我们一步步思考」引导模型显式输出中间推理步骤。其核心原理是利用模型的自回归特性——模型生成文本时，已生成的内容会成为后续生成的条件，因此让模型先输出正确的中间推理步骤，能为最终答案的生成提供更强的概率约束，相当于将复杂的一步推理拆解为多个更容易的子步骤。Google研究表明CoT可将数学推理准确率提升40%以上，这也是为什么DeepSeek-R1等推理模型会输出大量「思考过程」的理论基础。

少样本学习（Few-shot Learning） 利用了大模型的上下文学习（In-Context Learning）能力——模型能够从提示词中的2-5个示例中推断出任务模式，无需梯度更新即可适配特定任务。这一能力被认为是大模型在参数量超过某一阈值后「涌现」出的核心能力之一，小模型通常不具备这种能力。与之对应的是「零样本学习（Zero-shot Learning）」，即不提供任何示例，直接通过自然语言描述任务——现代大模型在零样本场景下已能处理大量通用任务，但对于格式严格或领域专业的任务，少样本提示仍能显著提升输出质量。

此外，结构化输出提示（要求模型以JSON格式返回，便于程序解析）、自洽性（Self-Consistency）（对同一问题多次采样，取多数答案以提升准确率）等技巧也被广泛应用于生产环境的Agent开发中。

延伸：涌现能力（Emergent Abilities）与规模定律 大模型研究中，「涌现能力」指随着模型参数量超过某一临界点，模型突然展现出在小模型中几乎不存在的能力，如算术推理、代码生成、多步逻辑推理等。这一现象与「规模定律」（Scaling Laws）密切相关——OpenAI的研究表明，模型性能与参数量、训练数据量、计算量之间存在幂律关系，可以预测性地提升。然而，涌现能力的突变性打破了简单的线性外推：在某些能力上，小模型表现接近随机，而大模型的准确率却能跃升至接近完美。这一规律深刻影响了业界对大模型研发路线的判断，也是各大AI实验室持续追求更大规模训练的核心驱动力之一。

这里做一个有趣的演示：把系统提示词设置为「让AI扮演一个机器人，每次回复完之后都要发出『滴——』的声音」。重新运行程序并输入「你好」后，AI的每一次回复末尾都会带上「滴」，鲜明地呈现出机器人的人设。

这个小实验直观说明了系统提示词的价值：同样的用户输入，通过不同的系统提示词，可以让AI呈现出完全不同的性格和行为模式。这也是构建各类专用Agent（如客服助手、代码专家、角色扮演机器人）的关键所在。

总结：从零到对话Agent的完整路径

通过本文，我们完成了AI Agent最核心的部分——对话能力的代码实现。回顾整个流程：

理解大模型与提示词两大核心概念；
搭建虚拟环境并引入OpenAI等模块；
参考官方文档调用DeepSeek API，并用 .env 安全管理密钥；
通过 while 循环实现可持续的多轮交互；
用系统提示词灵活塑造AI的人设与行为。

虽然这只是一个最基础的对话程序，但它已经具备了Agent的雏形。在此基础上，后续可以逐步加入以下能力：

记忆管理：通过滑动窗口、摘要压缩或向量数据库检索解决上下文窗口限制问题，让Agent具备真正的「长期记忆」能力；
工具调用（Function Calling）：让Agent能够调用搜索引擎、执行代码、查询数据库等外部工具。Function Calling的技术实现是：开发者在API请求中声明可用工具的JSON Schema描述（包含工具名称、参数类型、功能说明），模型在推理过程中判断何时需要调用工具，并输出结构化的工具调用指令，由外部代码执行后将结果以role: tool的消息格式返回给模型继续推理。ReAct（Reasoning + Acting）框架将这一过程形式化为「思考（Thought）→行动（Action）→观察（Observation）」的交替循环，使Agent能够根据工具执行结果动态调整后续计划，是LangChain Agent、AutoGPT等主流Agent框架的理论基础，实现「感知-决策-行动」的完整闭环；
多智能体协作：多个专职Agent分工协作，处理更复杂的任务流程。例如，一个「规划Agent」负责将复杂任务分解为子任务，多个「执行Agent」并行处理各自专长的子任务，最后由「汇总Agent」整合结果——这一模式被称为Multi-Agent系统，是当前Agent研究的前沿方向，AutoGen、CrewAI等框架已提供了成熟的多智能体协作实现。值得关注的是，多智能体系统中的「智能体间通信协议」设计是核心挑战之一：智能体之间如何传递任务状态、如何处理冲突决策、如何防止「幻觉传播」（一个Agent的错误输出被其他Agent当作事实接受）等问题，正是当前学术界和工业界的活跃研究方向。

延伸：幻觉（Hallucination）问题与缓解策略 大语言模型的「幻觉」是指模型生成看似合理但实际上错误或捏造的内容，如虚假的参考文献、不存在的事实、错误的代码逻辑等。幻觉产生的根本原因在于模型的训练目标是「生成流畅连贯的文本」而非「输出真实信息」——模型并不区分已知事实与合理推断，而是基于统计规律填充最符合上下文的内容。在多智能体场景中，幻觉问题被放大：一个Agent输出的幻觉内容若未经验证即传递给下一个Agent，可能形成「错误链式传播」。常见缓解策略包括：RAG（检索增强生成）引入外部知识库作为事实锚点、要求模型引用来源并进行二次验证、在Agent流程中设置专门的「验证Agent」对关键信息进行交叉核实，以及采用置信度评估机制对低确定性输出进行标注。

对于想入门Agent开发的读者来说，动手把这个例子跑通，是最好的第一步。