1. 从“一次性问答”到“持续思考”：为什么你的AI需要Agentic模式？

不知道你有没有过这样的经历：让ChatGPT写一篇技术文章，它洋洋洒洒给你生成了一大段，乍一看逻辑通顺，但仔细一读，发现某个关键的技术细节是它“编造”的，或者代码示例里藏着一个低级错误。你叹了口气，只好自己动手修改，或者再给它一个更详细的提示，让它“重新生成”。

这其实就是传统“零样本提示”的典型困境。我们把AI当成一个“神灯精灵”，许一个愿望（给一个提示），就期望它立刻吐出完美的答案。但现实是，复杂的任务，无论是写代码、做分析还是创作内容，都是一个迭代和修正的过程。人类自己写代码不也得先写个草稿，跑一遍，发现bug，再调试，最后优化重构吗？

Agentic设计模式，说白了，就是教AI学会这种“人类式”的工作方法。它不再是一次性的“提问-回答”，而是构建一个让AI能够自主规划、执行、检查、再执行的循环工作流。你可以把它想象成给你的AI助手配了一个“项目经理”的大脑。这个“项目经理”不会一次性把活儿干完交差，而是会先拆解任务（规划），动手做第一版（执行），自己检查一遍有没有问题（反思），发现工具不够就去查资料（工具使用），如果任务太复杂，它甚至会召唤几个“同事”一起分工协作（多智能体）。

我最初接触这个概念时，也觉得有点“玄乎”，直到我在一个实际项目中尝到了甜头。当时我需要用AI批量处理几百份技术文档，提取关键信息并生成摘要。如果只用简单提示，结果参差不齐，我还得花大量时间人工核对。后来我设计了一个简单的Agentic流程：先让AI识别文档类型并规划提取字段，然后执行提取，接着让另一个“检查员”AI实例核对提取的信息是否完整、是否与原文矛盾，最后再生成摘要。这么一套下来，准确率飙升，我几乎只需要处理一些边缘案例。从那以后，我就彻底迷上了这种“让AI自己管理自己”的思路。

所以，如果你已经厌倦了和AI进行“挤牙膏”式的对话，或者你的项目对输出的准确性和可靠性有较高要求，那么掌握这几种Agentic设计模式，就是你从“AI使用者”进阶为“AI架构师”的关键一步。它不仅仅是几个酷炫的概念，而是一套能真正落地、极大提升生产效率的工程方法。

2. 核心模式一：反思模式 —— 让AI学会“自我批评”

我们常说要“复盘”，AI也一样。反思模式是四种模式中最基础，也最能直接提升输出质量的一种。它的核心思想是：让AI生成一个初步答案后，不要就此停止，而是基于预设的标准或更广泛的上下文，对自己的输出进行批判性审查，然后进行修订。

这听起来简单，但效果是颠覆性的。Andrew Ng（吴恩达）在他的课程里分享过一个让我印象深刻的实验：在标准的HumanEval代码生成基准测试中，GPT-3.5在零样本提示下正确率是48.1%，而GPT-4是67%。这已经不错了，对吧？但当研究者为GPT-3.5设计了一个包含自我反思环节的Agentic工作流后，它的正确率直接飙到了95.1%！这个数字甚至超过了原始GPT-4的表现，接近人类工程师的水平。这充分说明，很多时候限制模型能力的不是它的“知识量”，而是它的“工作方式”。

2.1 如何实现一个基础的反思循环？

你不需要高深的框架，用你熟悉的ChatGPT API或者LangChain就能轻松搭建。关键在于设计好“反思提示词”。这个提示词的任务是引导AI从一个“审查者”的角度看待自己刚才的产出。

举个例子，假设我们要AI写一个Python函数，用于计算列表的移动平均值。

第一步：生成初稿。 你给AI的提示是：“写一个Python函数moving_average，输入一个数字列表data和窗口大小window，返回移动平均值列表。”

AI可能会生成一个看起来可用的版本，但可能没处理窗口大小大于列表长度的情况，或者没考虑性能。

第二步：触发反思。 这时，你不要直接说“这里不对，改一下”。而是给它一个新的、更强大的提示：

“你刚刚编写了moving_average函数。现在，请你扮演一个严格的代码审查员。请逐一检查以下方面：

1. 健壮性：函数是否处理了所有可能的无效输入？例如，window <= 0，window > len(data)，空列表等。
2. 效率：算法的时间复杂度是否最优？对于大数据量是否可能成为瓶颈？
3. 可读性：变量名是否清晰？是否有必要的注释？
4. 功能性：输出列表的长度是否正确？边缘情况下的计算是否准确？

请列出你发现的所有潜在问题或改进点。”

第三步：基于反思进行修订。 将AI自己找出的问题列表，连同最初的代码和任务描述，再次交给它：“根据你刚才的审查意见，请重构并优化moving_average函数，修复所有问题。”

通过这个“生成-审查-优化”的循环，你最终得到的代码质量，会远高于一次性生成的版本。在实际操作中，这个循环可以进行多次，直到AI自己认为“没有问题可提”为止。

2.2 进阶实践：Self-RAG框架的启示

原始文章里提到了SELF-RAG，这是一个将反思深度集成到检索增强生成中的研究框架。它给我们的核心启发是：反思可以量化、结构化，并嵌入到生成过程的每一步。

SELF-RAG会在生成文本时，插入一些特殊的“反思令牌”，比如[检索必要]、[信息支持]、[信息无关]。模型在生成过程中，会主动判断“我是否需要去外部知识库检索信息来支撑接下来的内容？”或者“我刚才说的这句话，有没有被检索到的文档充分支持？”。

我们在自己的项目中可以借鉴这种思路。比如，在构建一个客服AI时，我们可以定义反思点：

• 在回答产品价格前，必须触发“[检索最新价目表]”的反思。
• 在给出操作建议后，必须触发“[检查与知识库一致性]”的反思。
• 最终回答生成后，必须触发“[评估回答完整性与友好度]”的反思。

通过将这些检查点自动化，我们就能构建出一个既准确又可靠的AI系统，而不是一个偶尔会“信口开河”的聊天机器。

3. 核心模式二：工具使用模式 —— 给AI装上“手脚和感官”

如果反思模式是增强了AI的“内省”能力，那么工具使用模式就是为AI插上了与真实世界交互的“翅膀”。它的理念是：AI不应该只是一个封闭在文本世界里的头脑，它应该能调用各种外部工具（API、数据库、计算引擎、甚至其他软件）来获取信息、执行操作，从而解决那些仅凭内部知识无法解决的问题。

回想一下，人类专家在解决问题时，会查资料、用计算器、操作专业软件。一个只会“空想”的AI，能力天花板是很明显的。工具使用模式打破了这层天花板。

3.1 从“知道”到“能做到”：工具集的构建

实现工具使用的核心，是为AI提供一个清晰的“工具目录”和调用规范。这通常通过“函数调用”功能来实现。你需要用结构化的方式告诉AI：你有什么工具，每个工具是干什么的，输入输出是什么。

假设我们在构建一个“个人旅行规划助理AI”。它的工具集可能包括：

工具名称	功能描述	输入参数	输出
search_flights	查询航班信息	出发地、目的地、日期	航班列表及价格
get_weather	获取城市天气预报	城市名、日期	天气状况、温度
search_hotels	查询酒店信息	城市、入住日期、离店日期	酒店列表及价格
calculate_budget	计算旅行预算	交通费、住宿费、餐饮标准、天数	预算明细及总额

当用户说：“我想下个月去三亚玩5天，预算控制在5000元左右，帮我看看。” AI的思考过程就不再是凭空编造，而是：

1. 理解需求：目的地（三亚）、时长（5天）、预算约束。
2. 规划工具调用顺序：先查天气（决定是否适合去），再查航班和酒店（主要开销），最后计算总预算。
3. 执行：调用get_weather(“三亚”, “下个月”)；根据结果，调用search_flights和search_hotels；最后将获取到的价格数据喂给calculate_budget工具。
4. 整合：将所有工具返回的结果，组织成一段人性化的回复提供给用户。

这样生成的建议，是基于实时、准确的数据，而不是AI训练数据中可能过时或模糊的记忆。

3.2 踩坑经验：工具使用的可靠性与安全性

在我实际集成工具时，踩过两个大坑，这里分享给你，希望能帮你避开：

第一坑：工具描述的模糊性。 早期我给AI一个search_web的工具，描述是“搜索网络信息”。结果AI经常用它去搜索一些非常宽泛的概念，返回大量无关信息。后来我把描述改得非常具体：“使用谷歌搜索API，针对用户问题中的关键实体和疑问词，构建一个精确的搜索查询词，返回前3条结果的摘要。” 并给出了好和坏的查询示例。调整之后，AI调用工具的准确性和有效性大大提升。

第二坑：无限循环与错误处理。 AI在尝试解决问题时，可能会陷入“调用工具A失败 -> 调用工具B -> 又回头调用工具A”的死循环。你必须在系统层面设置“最大重试次数”和“异常处理机制”。例如，当工具返回错误（如API限流、网络超时）时，不是直接把错误信息丢给AI，而是封装成一种AI能理解的指令：“工具X暂时不可用，请尝试用已有信息继续，或向用户说明部分数据可能延迟。”

提示：给你的AI工具命名时，尽量使用动词开头（如fetch_, calculate_, send_），这更符合它的“行动”本质。同时，为每个工具编写清晰、无歧义的文档，这步投资绝对物超所值。

4. 核心模式三：规划模式 —— 教会AI“谋定而后动”

对于一顿饭吃什么这种简单问题，我们可以直接回答。但对于“组织一场200人的技术大会”这种复杂项目，我们本能地会先做计划：定主题、找场地、邀嘉宾、排日程、做宣传… 规划模式就是让AI具备这种将宏大、模糊的目标分解为有序、可执行步骤序列的能力。

没有规划的AI，处理复杂任务就像无头苍蝇，容易迷失在细节中，产出缺乏条理。规划模式为AI提供了“任务分解树”和“执行路线图”。

4.1 两种经典的规划策略：ReAct与思维链（CoT）的融合

原始文章提到了ReAct（Reasoning + Acting），这是目前非常流行的一种将规划与工具使用结合的模式。我更喜欢把它理解为 “边想边做”。

传统思维链是让AI把整个推理过程在脑子里想完，最后输出一个答案。这就像你在心里默默规划了整个旅行路线。 ReAct则是：我想一步（Reasoning），就马上做一步（Acting），根据做的结果再想下一步。这就像你实际在旅行：先想去机场（想），然后叫车（做）；上车后发现堵车（观察结果），于是重新规划路线（再想），让司机改道（再做）。

在代码中，一个ReAct循环通常长这样：

# 伪代码示意
user_query = “去年我们公司销售额最高的产品是什么？”
agent_state = “开始分析...”

while not task_finished(agent_state):
    # 1. Reasoning: 分析当前状态，决定下一步做什么
    reasoning_prompt = f”当前问题：{user_query}，当前状态：{agent_state}，下一步我应该做什么？是思考，还是调用某个工具？”
    next_action = llm(reasoning_prompt)

    if next_action == “需要查询销售数据库”:
        # 2. Acting: 执行动作（调用工具）
        tool_result = call_tool(“query_database”, sql=“SELECT product FROM sales WHERE year=‘last_year’ ORDER BY revenue DESC LIMIT 1”)
        agent_state = f”已查询数据库，结果是：{tool_result}”
    elif next_action == “需要整合答案”:
        final_answer = llm(f”根据已有信息{agent_state}，回答问题：{user_query}”)
        agent_state = “任务完成，答案是：” + final_answer

这种模式特别适合信息需要逐步获取、路径可能随时调整的动态任务。

4.2 实战：用规划模式搞定一份季度市场分析报告

假设老板让你“分析一下上一季度市场表现，并给出下季度建议”。如果你直接把这句话扔给AI，它可能给你一篇空泛的文章。但用规划模式，我们可以这样设计：

第一步：任务分解规划。 提示AI：“请将‘分析上一季度市场表现并给出建议’这个复杂任务，分解成一个具体的、线性的步骤列表。每个步骤应该是可执行的原子操作。”

AI可能会输出：

1. 数据获取：明确需要哪些数据（销售额、用户增长、竞品动态、渠道成本）。
2. 数据获取执行：调用工具从CRM、财务系统、公开信息源获取具体数据。
3. 现状分析：计算关键指标（环比、同比、市场份额），识别异常点和趋势。
4. 归因分析：针对发现的趋势，分析可能的原因（内部运营、市场环境、竞争动作）。
5. 机会与风险识别：基于分析，列出下季度的主要机会点和潜在风险。
6. 建议制定：针对每个机会和风险，提出具体的、可操作的建议。
7. 报告合成：将以上所有分析结果，整合成结构清晰、图文并茂的报告文档。

第二步：按计划执行。 让AI（或由主AI协调的多个AI）严格按照这个步骤列表，一步步推进。每一步都可能调用不同的工具（数据分析工具、图表生成工具），也可能包含小的反思循环（“我计算出的增长率是否合理？”）。

通过这种方式，你最终得到的不是一篇散文，而是一份有数据支撑、有逻辑深度、有 actionable 建议的专业报告草稿。你作为人类，只需要在关键节点进行审核和决策即可，极大地提升了工作质量和效率。

5. 核心模式四：多智能体模式 —— 组建你的AI“梦之队”

当任务复杂到单个AI“分身乏术”时，就该多智能体模式登场了。它的思想是：为什么不组建一个专家团队呢？ 你可以创建多个具备不同角色、专长和工具的AI智能体，让它们各司其职、相互协作，共同攻克一个难题。

这不再是让一个“通才”AI勉强应付所有事，而是让“专才”AI们组成流水线或项目组。这种模式的力量在于分工、协作与制衡。

5.1 智能体团队的常见架构

根据我的实践，通常有三种组织方式，对应不同的应用场景：

1. 流水线式协作： 就像工厂生产线，每个智能体只负责一个环节，处理完后交给下一个。例如一个“内容创作团队”：

• 策划智能体：根据热点生成文章选题和大纲。
• 研究智能体：根据大纲，调用工具搜索和整理相关资料。
• 写作智能体：基于大纲和资料，撰写文章初稿。
• 审核智能体（反思模式）：检查初稿的事实准确性、逻辑和文风，提出修改意见。
• 编辑智能体：根据审核意见，对文章进行最终润色和排版。

每个智能体只专注于自己最擅长的部分，效率和专业性都更高。

2. 辩论式协作： 这对于需要深度决策或创意发散的场景非常有效。你创建两个或多个持不同“观点”的智能体。比如一个“技术选型辩论会”：

• 智能体A（激进派）：主张采用最新的、性能最强的技术栈，并陈述其优势。
• 智能体B（保守派）：主张采用最成熟、社区支持最广的技术栈，并分析新技术的风险。
• 智能体C（主席）：听取双方陈述，总结各自论点和论据，并最终结合项目背景（由你提供）给出一个平衡的建议。

这种方式能极大地拓宽思考的维度，避免单个AI的思维定式。

3. 管理者-工作者层级： 这是最接近人类公司架构的模式。一个管理者智能体负责接收总任务，进行顶层规划，然后将子任务分派给不同的工作者智能体。管理者负责协调进度、汇总结果、处理冲突。例如在软件开发中，管理者可以分配“前端智能体”去写UI代码，“后端智能体”去设计API，“测试智能体”去生成测试用例。

5.2 搭建你的第一个多智能体系统：以自动代码审查为例

理论可能有点抽象，我们来看一个我实际搭建过的、相对简单的例子：一个自动化的代码审查助手。它由两个智能体组成：

• 开发者智能体：它的任务是“模拟提交代码的开发者”。当收到一段新代码时，它会先尝试理解代码功能，然后为这段代码编写提交信息和单元测试。它的提示词被设定为“积极、建设性”。
• 审查者智能体：它的任务是“扮演严格的代码审查员”。它会仔细阅读代码、提交信息和单元测试，然后从代码风格、潜在bug、性能问题、测试覆盖率等角度提出详细的审查意见。它的提示词被设定为“挑剔、细致、关注安全”。

工作流程如下：

1. 用户提交一段代码。
2. 开发者智能体启动，生成提交信息和单元测试。
3. 将代码、提交信息、单元测试一并发送给审查者智能体。
4. 审查者智能体生成审查意见报告。
5. 系统将原始代码和审查报告一并呈现给用户。

这样一来，用户在提交代码前，就能获得一份堪比资深同事的、双角度的预审查报告。两个智能体相互制衡，“开发者”努力让代码更完整，“审查者”努力挑出毛病，最终受益的是代码质量。

注意：多智能体系统设计的关键在于清晰界定角色和通信协议。你必须为每个智能体定义明确的“职责范围”和“输出格式”，避免它们之间产生混淆或重复劳动。一开始可以从2-3个智能体的小团队开始实践，再逐步扩展。

6. 融合与实战：设计你的第一个Agentic工作流

读到这里，你可能已经摩拳擦掌，但也会有点疑惑：这四种模式，我该先用哪个？它们能一起用吗？答案是：当然可以，而且它们常常是强强联合。 一个强大的Agentic系统，往往是多种模式的混合体。

让我用一个更综合的实战案例，带你走一遍设计流程。假设我们要构建一个 “智能技术博客选题与大纲生成器”。

我们的目标：输入一个宽泛的技术领域（如“云原生安全”），系统能自动产出一个具体的、有深度的、具备SEO潜力的博客文章大纲。

第一步：规划模式打头阵（分解任务）。 我们首先用一个具备规划能力的AI，将模糊需求分解成具体步骤。 提示：“请将‘为技术领域[云原生安全]生成一篇博客文章大纲’的任务，分解为具体的执行步骤。” AI规划结果可能：

1. 理解当前“云原生安全”领域的热点与趋势。
2. 基于热点，构思3-5个具体的、有吸引力的文章选题。
3. 为选定的最佳选题，进行深入的信息检索。
4. 基于检索信息，设计文章的逻辑结构（大纲）。
5. 为大纲的每个部分，建议所需的数据、案例或代码示例。

第二步：多智能体模式分工协作。 我们根据规划，组建三个智能体：

• 趋势分析智能体：专精工具使用。它调用搜索引擎API、技术社区趋势榜工具，执行第1步，输出热点关键词和话题列表。
• 创意策划智能体：专精反思。它接收热点列表，负责第2步和第3步。它会先生成一批选题，然后自我批判：“这个选题是否太泛？”“是否有足够的资料支撑？”“与其他热门文章是否同质化？”，最终筛选出一个最优选题。
• 大纲架构师智能体：专精规划与整合。它接收最优选题和检索到的资料，执行第4、5步。它需要规划文章的整体叙事逻辑（是什么-为什么-怎么做），并将资料合理分配到大纲的每个章节，甚至指出哪里需要配图、哪里可以插入代码片段。

第三步：工具使用模式贯穿始终。 在整个流程中，多个智能体都会用到工具：

• 趋势分析智能体调用search_tech_trends工具。
• 创意策划智能体在反思时，可能会调用check_article_similarity工具来避免重复。
• 大纲架构师智能体可以调用generate_mind_map工具来可视化结构。

第四步：反思模式确保质量。 在最终大纲输出前，我们可以再加入一个终审智能体，对整个工作流产出的结果进行最终反思：“这个大纲是否结构平衡？深度是否足够？是否涵盖了核心热点？目标读者是否能跟上？” 根据它的反馈，可以触发前序某个环节进行微调。

通过这样一个融合了规划、多智能体、工具使用和反思的工作流，我们就能从一个简单的关键词，自动化地生成一个高质量、可直接交付给写作者的内容蓝图。这比单纯让AI“想一个云原生安全的博客大纲”要可靠和深入得多。

启动你的第一个Agentic项目，不妨从一个你日常工作中重复性高、但又有点复杂的小任务开始。比如自动回复特定类型的邮件、生成每周数据报告摘要、或者像上面说的代码审查。先实现一个核心模式（比如反思），看到效果后，再像搭积木一样，逐步引入工具、规划或多智能体。记住，Agentic设计的精髓不在于技术的炫酷，而在于让AI以一种更可靠、更省心的方式，真正成为你的生产力倍增器。