AI Agent开发入门——从Prompt工程开始

关注

原创最新推荐文章于 2026-11-10 21:15:35 发布 564 阅读 AI 写同款· GEO 优化 ›

人工智能知识普及，AI，大模型，Agent，prompt 但是，如果你问，从政治，经济，文化，制度等方面，来分析一下古代大一统封建王朝三百年的宿命论；虽然现在基于大模型可以实现文本，图片和视频的生成，但AI怎么实现在科学研究，医药，法律，制造业等其它领域的应用，而这就是agent需要解决的问题。至于agent它的手和脚是怎么实现的，然后又是怎么和大模型拼接到一块成为一个人的；我们知道大模型是通过大量的数据进行训练出来的一种具有“一定智能”的人工智能，之所以说具有一定智能是因为大模型目前为止并没有自己的意识，也就是说它没有像人类一样具有自己独立的思想。阅读详情

“技术的爆发从来不是线性演进，而是在临界点处瞬间重构世界。”——凯文·凯利

📚 第一篇：零基础指南：构建AI Agent的四大支柱（1/4）

🎯 开篇：为什么写这篇指南？

过去两三年，我曾为多家公司的资深开发人员开展Agent开发培训；最近一个月，我也一直在为毕业生设计和培训AI Agent。

直到本周，结合AI能力的模拟项目showcase完成后，我才真正理清楚：如何针对不同阶段的开发者，系统地构建Agent的学习路径。

这个过程，也让我深刻体会到 “知识诅咒” 的存在——原来自己习以为常的知识，对于初学者来说，可能是最大的障碍。

🗺️ 学习路径总览：四大支柱

我们将学习过程分为四大部分，形成完整的AI Agent开发能力体系：

支柱	核心内容	难度
1. 结构化提示词工程	如何工程化设计高效、可复用的提示词	⭐⭐
2. 上下文工程与知识检索	知识检索、生成与压缩上下文信息	⭐⭐⭐
3. 工具函数的系统化设计	设计并实现可供Agent调用的工具与接口	⭐⭐⭐
4. Agent规划与多Agent	构建任务规划与执行路径，实现闭环自动化	⭐⭐⭐⭐

本文是第一篇，聚焦第一大支柱：结构化提示词工程。

🤖 先定义：什么是AI Agent？

在开始前，我们需要简单定义AI Agent。考虑到Agent有大量不同定义，我们参考Anthropic在《Building effective agents》中的说法：

一些客户将其定义为完全自主运行的系统，能长期独立运作并使用多种工具完成复杂任务；另一些则用它描述遵循预定义工作流程的系统。

因此，围绕一个提示词的简单任务可以视为AI Agent；而围绕一个复杂系统、多工具、多步骤的任务，也是一个AI Agent。

📝 第一章：结构化提示词工程

尽管Context Engineering是一个非常火的词，但如何写好Prompt，依然是入门重点。

从我的经验来看，我们可以把重点放在三个部分：

提示词输入与输出的结构化
复杂问题的链式与模块化设计
提示词路由分发任务

1.1 提示词输入与输出的结构化

在开发Agent的过程中，尽管模型能生成一部分提示词，但调提示词依然是工作的重点。我们希望模型输出的内容可以是JSON、XML或Java类，以便结合其它代码一起使用。

提示词（Prompts）是用于引导AI模型生成特定输出而输入的设计艺术与科学。

格式化的输入指令

我们需要结构提示词模板来动态生成提示词：

动态提示词模板（PromptTemplate）：采用模板引擎动态结合上下文，如LangChain的Jinja2，Spring AI的StringTemplate
结构化的文本结构：包括角色定位（Role）、任务描述（Task）、约束条件（Constraints）、输出格式等
示例驱动（Few-shots）：通过提供示例输入与期望输出，提高模型输出的稳定性

转换模型输出结果

针对不同的场景采用合适的输出格式：

格式	优点	缺点	适用场景
JSON	可直接序列化传输	不能实时渲染，不够健壮	API接口、数据交换
XML	结构清晰，可扩展	标签冗余，传输成本高	复杂嵌套结构
YAML	更好地处理流式问题，传输成本低	解析稍复杂	配置文件、日志输出
Markdown	可读性好，适合展示	结构化程度低	文档生成、报告输出

异常场景处理：由于模型生成存在不确定性，需要设计字段缺失时的默认值、回退策略，以及触发模型重试的机制。

1.2 提示词路由分发任务

在复杂的AI系统中，单个提示词往往无法完成所有任务。我们需要提示词路由（Prompt Routing）：

提示词路由是在多任务、多Agent或复杂AI流程中，将任务拆分、分析输入并智能分配给最合适模型或子任务提示词的工程化模式。

核心思想：通过分析输入和上下文，动态决定信息处理路径、使用哪条提示词或调用哪个工具、子Agent。

典型QA场景示例：

非系统相关问题 → 直接告诉用户不支持
基础知识问题 → 调用文档检索和QA模型
复杂分析问题 → 调用数据分析工具，再生成总结

1.3 复杂问题的链式与模块化设计

在有提示词路由的前提下，复杂问题可以通过**提示链（Prompt Chaining）**进行系统化拆解。

提示链的优势：

每个子任务专注于处理特定阶段任务
可以按需重写某个子任务，增加或替换提示词
根据前一阶段输出动态调整后续提示词

软件需求分析示例：

产品经理想法 → 创意收集 → 需求逻辑梳理 → 需求预排期 → 需求定稿

每个环节可以由不同的提示词或子Agent处理：

创意收集：借助具备搜索功能的AI Agent
需求逻辑梳理：使用Dify、Copilot 365等工具
需求预排期：生成初步的任务列表
需求定稿：确认最终需求，生成正式文档

📌 第一篇小结

今天我们学习了AI Agent开发的第一大支柱：结构化提示词工程。

核心要点：

✅ 提示词需要结构化输入输出，确保可解析、可复用
✅ 复杂系统需要提示词路由，动态分配任务
✅ 复杂问题使用提示链拆解，保持模块化灵活性

[第二篇：上下文工程]

📚 第二篇：上下文工程——让Agent"记得住、找得到"

零基础指南：构建AI Agent的四大支柱（2/4）

🔗 上篇回顾

在第一篇中，我们学习了结构化提示词工程：

提示词的输入输出结构化（JSON/XML/YAML/Markdown）
提示词路由分发任务
提示链（Prompt Chaining）模块化设计

但有个关键问题：Agent如何获取外部知识？如何处理海量信息？如何"记得住"之前的对话？

这就是本篇的核心——上下文工程与知识检索。

📖 什么是上下文工程？

Anthropic在《Effective context engineering for AI agents》中给出定义：

上下文工程是一门将不断变化的信息宇宙中最相关内容，精心筛选并放入有限上下文窗口的艺术与科学。

简单来说：在有限的上下文窗口中挑选最关键的信息，让模型理解和推理更高效。

🛠️ 开发方案选择：NoCode vs ProCode

方案	适用场景	工具示例	特点
NoCode	快速验证、原型开发	Dify、N8N、Coze	预配置RAG管道，UI配置检索策略
ProCode	定制化需求、生产环境	LangChain、Spring AI	自定义检索流程，多阶段优化

建议：初学者从NoCode入手，理解原理后转向ProCode实现定制化需求。

🧩 六种核心上下文工程技术

Drew Breunig总结的6种常见上下文工程技术：

技术	核心思想	适用场景
Context Offloading	将信息存储在LLM上下文之外，通过工具管理	长期记忆、大量历史数据
RAG	选择性添加相关信息，帮助LLM生成更好响应	知识库问答、文档检索
Tool Loadout	只选择相关工具定义添加到上下文	多工具场景，减少干扰
Context Pruning	移除无关或不需要的信息	上下文窗口有限时
Context Summarization	将累积上下文浓缩为摘要	长对话、多轮交互
Context Quarantine	将上下文隔离在独立线程中	多Agent协作、并行任务

🔍 RAG：检索增强生成

**RAG（Retrieval-Augmented Generation）**是目前最主流的上下文工程技术。

RAG核心流程

用户查询 → 查询理解/改写 → 向量检索 → 重排序 → 上下文组装 → LLM生成

查询改写技术

技术	原理	效果
HyDE	生成假设性答案，再用答案去检索	提高召回率
Query Expansion	扩展同义词、相关概念	覆盖更多相关文档
Multi-Query	生成多个子查询并行检索	多角度获取信息

检索策略

策略	说明	适用
关键词检索	传统BM25、TF-IDF	精确匹配场景
向量检索	Embedding语义相似度	语义理解场景
图检索	基于知识图谱的关系遍历	复杂关联场景
混合检索	关键词+向量+重排序	综合效果最佳

💾 上下文窗口管理

上下文窗口是LLM的"工作记忆"，需要精心设计：

典型上下文组成：

System Prompt（系统提示）
历史消息（Message History）
检索到的文档（Retrieved Docs）
工具定义（Tool Definitions）
用户当前输入（User Message）

Agent记忆体系

记忆类型	说明	示例
工作记忆	当前对话上下文	最近的10轮对话
语义记忆	事实性知识	世界知识、领域知识
程序记忆	技能和操作	如何使用工具、执行流程
情景记忆	历史事件和经验	过去成功/失败的案例

优化策略：

动态裁剪：根据重要性保留关键历史
分层摘要：远距离历史做摘要，近距离保留细节
智能刷新：主动遗忘无关信息，保留关键状态

🧠 长期记忆与短期记忆

维度	短期记忆	长期记忆
存储位置	上下文窗口内	向量数据库/外部存储
访问速度	快（直接读取）	慢（需要检索）
容量限制	受限于模型上下文长度	理论上无限
实现方式	直接拼接	RAG、知识图谱、数据库存储
适用信息	当前任务相关	历史知识、用户画像、领域知识

📌 第二篇小结

今天我们学习了AI Agent开发的第二大支柱：上下文工程与知识检索。

核心要点：

✅ 上下文工程是在有限窗口中筛选最关键信息的艺术
✅ RAG是主流方案，需要掌握查询改写、检索策略、重排序
✅ 六种技术各有适用场景，需要灵活组合使用
✅ 记忆分层：短期记忆（上下文内）+ 长期记忆（外部检索）

下篇预告：《工具函数的系统化设计》——如何让Agent"干得了"具体任务？

[第三篇：工具设计]

📚 第三篇：工具函数的系统化设计——让Agent"干得了"具体任务

零基础指南：构建AI Agent的四大支柱（3/4）

🔗 上篇回顾

在第二篇中，我们学习了上下文工程与知识检索：

上下文工程的六种核心技术
RAG检索增强生成的完整流程
短期记忆与长期记忆的分层管理

但Agent光有"脑子"不够，还需要"手"——也就是工具（Tools）。本篇聚焦如何让Agent调用外部能力，完成实际任务。

🔧 为什么工具设计如此重要？

大语言模型（LLM）本质上是"纸上谈兵"的专家，它知道很多知识，但无法直接操作现实世界：

❌ 不能查询数据库
❌ 不能发送邮件
❌ 不能调用API
❌ 不能操作文件系统

工具（Tools）就是连接LLM与现实世界的桥梁。通过工具，Agent可以：

✅ 获取实时数据（天气、股价、库存）
✅ 执行操作（发送通知、创建订单、更新状态）
✅ 与外部系统交互（ERP、CRM、数据库）

🛠️ 工具调用的核心机制：Function Calling

Function Calling（函数调用）是目前最主流的工具使用方式。其核心流程：

1. 用户提出问题2. LLM分析是否需要调用工具3. 如需调用，生成工具调用请求（函数名+参数）4. 应用层执行工具函数5. 将执行结果返回给LLM6. LLM基于结果生成最终回答

📋 工具设计的系统化方法

3.1 工具定义的标准格式

一个标准的工具定义包含：

{"name":"查询订单状态","description":"根据订单ID查询订单的当前状态和物流信息","parameters":{"type":"object","properties":{"order_id":{"type":"string","description":"订单唯一标识符，格式为ORD-XXXXXX"},"include_details":{"type":"boolean","description":"是否返回详细物流信息","default":false}},"required":["order_id"]}}

设计原则：

原则	说明	示例
语义清晰	工具名和描述要让LLM一看就懂	`查询订单状态` 优于 `getOrder`
参数明确	每个参数都要有类型和描述	`order_id` : “订单唯一标识符”
约束完整	标明必填项、默认值、取值范围	`required` : [“order_id”]
错误处理	定义异常返回格式	订单不存在时返回什么

3.2 工具分类与分层

层级	工具类型	说明	示例
基础层	数据访问工具	读写数据库、文件、缓存	查询用户表、读取配置文件
业务层	领域服务工具	封装业务逻辑	创建订单、计算价格、审核流程
交互层	外部通信工具	与第三方系统交互	发送邮件、调用支付接口、推送消息
智能层	AI增强工具	调用其他AI能力	图像识别、语音合成、文本摘要

3.3 工具编排：从单工具到多工具协作

复杂任务往往需要多个工具协作完成。

示例：智能客服处理退款请求

用户：我要退款，订单号是12345Agent执行流程：1. 【查询订单工具】→ 获取订单信息（商品、金额、状态）2. 【查询退货政策工具】→ 判断是否符合退款条件3. 【用户画像工具】→ 查询用户历史信用4. 【创建退款单工具】→ 生成退款申请5. 【发送通知工具】→ 通知财务部门6. 【记录日志工具】→ 记录操作日志

编排模式：

模式	说明	适用场景
顺序执行	工具A → 工具B → 工具C	有明确依赖关系的流程
并行执行	工具A、B、C同时执行	无依赖的独立查询
条件分支	根据结果选择不同工具	需要判断决策的场景
循环迭代	重复执行直到满足条件	分页查询、递归处理

🔌 MCP：模型上下文协议

MCP（Model Context Protocol）是Anthropic推出的开放协议，旨在标准化AI模型与外部工具的连接方式。

MCP的核心价值：

🔄 标准化：统一工具定义和调用方式
🔌 即插即用：工具可以像USB设备一样热插拔
🌐 跨平台：不同AI模型可以共享同一套工具
🔒 安全可控：内置权限管理和审计日志

🧰 工具设计的最佳实践

3.4 工具发现与动态加载

当工具数量增多时，需要让Agent自动发现合适的工具：

策略：

语义匹配：根据用户问题语义，匹配工具描述
关键词过滤：通过关键词快速筛选候选工具
使用历史：优先推荐之前成功使用过的工具组合

3.5 工具调用的容错设计

场景	处理策略
工具调用失败	重试3次 → 降级到备用工具 → 告知用户
参数缺失	询问用户补充 → 使用默认值 → 智能推断
执行超时	异步执行 → 回调通知 → 提供任务ID查询
权限不足	引导用户授权 → 记录审计日志 → 升级处理

📌 第三篇小结

今天我们学习了AI Agent开发的第三大支柱：工具函数的系统化设计。

核心要点：

✅ Function Calling是工具调用的核心机制
✅ 工具设计需要语义清晰、参数明确、约束完整
✅ 工具分层：基础层→业务层→交互层→智能层
✅ 工具编排：顺序、并行、分支、循环四种模式
✅ MCP协议正在标准化工具连接方式

下篇预告：《Agent规划与多Agent协作》——如何让Agent"想得好、干得成"？

[第四篇：Agent规划]

📚 第四篇：Agent规划与多Agent协作——让Agent"想得好、干得成"

零基础指南：构建AI Agent的四大支柱（4/4）

🔗 前三篇回顾

在前三篇中，我们构建了AI Agent的基础能力：

第一篇：结构化提示词工程（如何写好Prompt）
第二篇：上下文工程与知识检索（如何让Agent"记得住"）
第三篇：工具函数的系统化设计（如何让Agent"干得了"）

但Agent还需要"脑子"——规划能力。本篇聚焦如何让Agent自主思考、决策、执行，以及多Agent如何协作。

🧠 为什么Agent需要规划能力？

想象一个场景：你让AI"帮我策划一场北京到上海的商务出差"。

没有规划的Agent：

直接调用"订机票"工具，但不知道日期
尝试调用"订酒店"，但不知道预算
陷入死循环或给出荒谬答案

有规划的Agent：

理解需求：商务出差，需要机票+酒店+会议安排
信息收集：询问日期、预算、偏好
任务拆解：订机票 → 订酒店 → 安排会议 → 准备材料
执行监控：每步检查是否成功，失败则调整
结果整合：生成完整行程单

规划（Planning）是Agent从"工具"进化为"智能体"的关键。

🎯 ReAct：推理与行动的协同

ReAct（Reasoning + Acting）是目前最主流的Agent规划框架。

核心思想：让LLM在**推理（Thought）和行动（Action）**之间交替进行，形成"思考-行动-观察"的循环。

用户问题：明天上海天气怎么样？ReAct执行流程：Thought 1: 用户询问明天上海的天气，我需要查询天气信息。Action 1: 调用get_weather_tool(location="上海", date="明天")Observation 1: {"temperature": "22°C", "weather": "晴", "humidity": "60%"}Thought 2: 我已经获取到天气信息，现在可以回答用户了。Final Answer: 明天上海天气晴朗，气温22°C，湿度60%，适合出行。

🔄 Agent的完整执行循环

一个完整的AI Agent执行循环包含四个关键步骤：

步骤	名称	说明
1	规划（Planning）	分析目标，拆解任务，制定执行计划
2	执行（Action）	调用工具，与外部世界交互
3	观察（Observation）	收集执行结果，感知环境变化
4	反思（Reflection）	评估进展，调整计划，决定是否继续

🤖 Multi-Agent：从单兵作战到团队协作

当任务足够复杂时，一个Agent搞不定，需要多个Agent协作。

典型Multi-Agent架构

角色	职责	示例
规划Agent	拆解任务，分配工作	项目经理
执行Agent	调用工具，完成具体任务	开发工程师
检查Agent	验证结果，发现错误	QA测试
优化Agent	改进方案，提升效率	架构师

Multi-Agent协作模式

模式	说明	适用场景
层级式	一个主Agent指挥多个子Agent	任务明确，需要分工协作
平等式	多个Agent平等讨论，达成共识	需要创意碰撞，如头脑风暴
竞争式	多个Agent提出不同方案，择优录取	需要多方案对比，如代码评审
流水线式	Agent A输出 → Agent B输入 → Agent C处理	流程固定，如内容生产流水线

🛡️ Agent的护栏设计：安全与可控

完全自主的Agent风险极高，需要设计护栏（Guardrails）：

护栏类型	作用	示例
输入护栏	过滤恶意输入	防止Prompt注入攻击
输出护栏	检查生成内容	防止泄露敏感信息
执行护栏	限制工具调用	禁止删除生产数据
预算护栏	控制资源消耗	限制API调用次数
人工审核点	关键节点人工确认	大额转账需人工审批

🏗️ Agentic Workflow：编排的艺术

Agentic Workflow是将所有元素编排在一起的"指挥系统"。

核心设计原则：

模块化：每个Agent、每个工具都是独立模块
可观测：全程记录思考过程和执行日志
可回滚：失败时能回到之前状态重试
人机协同：关键节点保留人工干预能力

📌 第四篇小结与全系列总结

今天我们学习了AI Agent开发的第四大支柱：Agent规划与多Agent协作。

核心要点：

✅ ReAct框架：推理与行动交替进行，形成完整循环
✅ 四步循环：规划 → 执行 → 观察 → 反思
✅ Multi-Agent：复杂任务需要多角色协作完成
✅ 护栏设计：安全可控是生产环境的必要条件
✅ Agentic Workflow：系统化编排所有执行单元

🎓 全系列回顾：四大支柱

支柱	核心能力	关键技术
1. 结构化提示词工程	让Agent"听得懂"	PromptTemplate、提示链、路由
2. 上下文工程与知识检索	让Agent"记得住"	RAG、向量检索、记忆分层
3. 工具函数的系统化设计	让Agent"干得了"	Function Calling、MCP、工具编排
4. Agent规划与多Agent	让Agent"想得好"	ReAct、Multi-Agent、Workflow