传统大模型应用开发的主要优势在于依赖 LLM 对自然语言的理解与生成能力，在给定上下文和预置流程下，能够完成问答、总结、改写、邮件润色、闲聊等相对明确的任务。从工程架构上看，它本质上更接近一种确定性流水线：开发者提前设计好 Prompt、检索、模型调用、结果解析等执行步骤，模型只负责在固定环节完成语言处理。

一旦面临任务复杂度升高，涉及多步骤协同、动态决策、外部系统交互、工具调用和执行结果反馈时，传统大模型应用就容易暴露局限。因为它的执行路径通常是预先编排好的，缺少根据环境变化持续调整任务策略的能力。

⽽智能体Agent的核⼼使命，便是赋予AI⾃主完成任务的强⼤能⼒。这意味着当AI接收任务指令后，不再是简单的按照流程执行，而是深度思考并规划形成“计划 -> 行动 -> 观察 -> 再决策”的闭环。

从专业定义来看，AI Agent是⼀种具备感知环境变化、独⽴⾃主做出决策，并能够主动执⾏相应⾏动的先进⼈⼯智能系统。

AI Agent应用场景范围

Agent 技术的应用范围广泛且多样。它并不只是简单的自动化工具，而是能够结合大模型理解能力、工具调用能力、上下文记忆能力和任务规划能力，在多个领域中提供高效、灵活且具备创新性的解决方案。以下是 Agent 技术的主要应用场景。

（1）自动化提效

Agent 技术在复杂任务自动化和工作效率提升方面具有重要价值。它不仅可以处理简单的数据查询、内容生成、任务整理等工作，也可以参与代码开发、问题排查、流程编排等更复杂的场景，从而减少重复性人工操作，优化整体工作流程。

例如：AI Coding、代码检查、自动生成周报、会议纪要整理、工单自动处理、日志初步排查等。

（2）数据分析和处理

在海量数据处理和复杂分析场景中，Agent 可以根据用户的自然语言需求，自动完成数据查询、数据清洗、指标拆解、趋势分析和结果总结，帮助企业和研究人员更快获得有价值的洞察。

例如：日志数据分析、财务报表分析、销售数据分析、用户行为分析、数据库自然语言查询、BI 报表生成等。

（3）交互式用户体验

Agent 可以通过自然语言理解、上下文感知和多轮对话能力，为用户提供更加个性化、连续性和互动性的使用体验。相比传统基于菜单、按钮或固定流程的系统，Agent 能够让用户以更自然的方式表达需求，并推动任务完成。

例如：智能客服、个人助理、学习辅导、智能导购、办公助手、企业知识库问答等。

（4）智能决策支持

Agent 可以作为决策支持工具，帮助用户分析复杂场景、整合多源信息，并基于数据、规则和上下文给出建议。它尤其适用于变量较多、信息来源复杂、需要综合判断的业务场景。

例如：项目风险评估、风控审核、供应链调度、投资研究、招聘筛选、医疗辅助分析等。

（5）集成与扩展服务

Agent 能够通过工具调用、API 接入和插件扩展，将多个外部系统、业务服务和信息源整合到统一的交互入口中。用户只需要用自然语言描述目标，Agent 就可以根据任务需要调用不同系统完成操作。

例如：对接 CRM、ERP、OA、数据库、知识库、搜索引擎、工单系统、支付系统、代码仓库等，实现跨系统查询、流程办理、信息同步和任务执行。

（6）自适应学习和进化

Agent 具备基于历史上下文、用户反馈和行为模式持续优化的能力。它可以逐步理解用户偏好、业务规则和任务习惯，从而提供更加个性化、精准和符合实际需求的服务。

例如：个性化学习助手、长期办公助手、智能推荐助手、客户画像更新、个性化客服、自适应流程优化等。

你的产品是Agent吗？

很多团队在做 AI 产品时，容易把“能多轮对话、回答更自然”误认为“已经做成了 Agent”。但从产品能力和系统架构的角度看，Agent 不是一个更会聊天的对话模型，而是一种能够围绕目标持续行动的任务执行系统。

普通对话 AI 往往停留在“你问一句，它答一句”的响应模式，本质上仍然是单轮或多轮问答；而 Agent 接收的不是单个问题，而是一个需要被完成的目标。它不仅要理解用户意图，还要能够拆解任务、规划步骤、调用工具、执行动作，并根据中间结果持续调整下一步策略。

换句话说，判断一个 AI 产品像不像 Agent，不要只看它会不会聊天，而要看它是否具备四个关键能力：

• 是否接收的是目标而不只是问题

• 是否会自主规划下一步

• 是否能够调用工具或外部系统执行动作

• 是否会依据反馈结果持续修正执行路径。

如果这四点大多不具备，那么它更像一个增强版对话 AI，如果这四点已经形成闭环，它才真正开始接近 Agent。

从落地场景来看，Agent 更适合处理复杂、多步、可迭代、需要外部交互的任务，例如信息搜集与整理、多步骤内容生产、代码编写与自动化执行、跨系统工作流推进等。这类任务的共同特点是：目标明确，但执行路径并不固定，需要在过程中不断调用工具、整合信息并调整动作。相反，如果需求目标模糊、结果缺少明确验收标准、任务涉及高风险决策，或者系统拥有过高权限，那么就不应该轻易把任务完全交给 Agent 自动执行。

真正有价值的 Agent，不是“替你多说几句话”，而是“围绕目标持续做事”。因此，一个 AI 产品是否是 Agent，关键不在于界面上有没有聊天框，而在于底层是否已经形成“目标 + 规划 + 工具 + 反馈”的完整执行闭环。

Agent核心能力

（1）感知与理解，从单一模态到多模态

LLM 模块是 Agent 的核心能力中枢，承担着理解任务、推理决策、生成响应和协调行动的职责，相当于 Agent 的“大脑”。

但与传统固定流程应用不同，Agent 并不是完全按照预设路径执行任务，而是需要根据用户输入、上下文状态、工具返回结果以及环境反馈，动态调整后续行为策略。因此，LLM 模块的作用不只是完成文本理解和内容生成，更重要的是作为一个动态推理引擎，判断当前任务应该如何推进、是否需要调用工具、调用哪个工具，以及如何根据执行结果继续修正下一步动作。

在复杂交互和多步骤任务中，LLM 模块处于核心地位。它决定了 Agent 如何理解目标、规划路径、选择行动，并与外部系统进行有效协同。换句话说，LLM 模块不仅让 Agent “会回答”，更让 Agent 具备围绕目标持续决策和行动的能力。

最初，单纯的⼤语⾔模型主要依赖海量⽂本数据进⾏训练，其基础感知途径仅仅局限于接收⽤⼾输⼊的⽂本信息。

直⾄2023年，GPT4推出vision版本，开启了多模态的大门，多模态让 Agent 从单一文本理解走向对图像、语音乃至视频等多源信息的综合感知，使其真正具备“看、听、理解环境”的基础能力，并为复杂任务执行提供更丰富的输入支撑。

（2）决策与规划，从线性推理到自主决策

目标/规则是 Agent 任务执行链路中的核心调度能力，负责将复杂目标拆解为阶段性子任务，并组织后续行动路径。 它不仅承担初始任务规划的职责，还需要在执行过程中结合中间结果、历史经验和外部环境变化，持续进行反思、修正与重规划。对于多跳任务、长链路决策和复杂工具协同场景而言，直接决定了 Agent 的灵活性、稳定性和任务完成质量。

早期大模型虽然具备一定的问答和生成能力，但在面对复杂任务时，往往缺乏稳定的中间推理和任务规划能力，容易出现回答草率、推理跳跃和多步任务执行不稳定的问题。因此，如何让模型“先思考、再行动”，逐渐成为 Agent 技术演进中的关键方向。

围绕这一问题，规划能力大致经历了几个阶段的演进。

最早是通过提示工程引导模型显式展开推理过程，随后又出现了 Tree of Thoughts（ToT）等规划策略，使模型能够预先构思多种可能路径，并从中选择相对更优的方案。

再往后，多智能体工作流开始流行，通过多个模型分工协作来弥补单一模型规划能力不足的问题，但这种方式依然较强依赖人工预设流程，面对新任务时灵活性有限。

真正的突破来自推理型大模型的发展。以 OpenAI o 系列和 DeepSeek R1 为代表的模型，开始具备更强的自主推理能力，使模型在回答问题前能够先进行分析和判断。而像 deep Research 这类能力进一步表明，大模型已经开始具备围绕目标自主决定搜索、整理、分析和总结路径的能力，逐步摆脱对固定工作流的依赖。

（3）工具-Tool，从Function Calling到环境交互

大模型最早与外部世界交互，主要依赖 API 调用。其基本方式是：模型在需要使用工具时，生成符合约定格式的调用指令，外部系统识别后执行对应函数，再将结果返回给模型。这种机制让大模型第一次具备了“调用外部能力完成任务”的基础，但它本质上仍然依赖开发者预先定义好接口、参数和调用规则。

随着应用场景进入真实世界，仅靠 API 已经不够。因为大量系统、网页和桌面环境并没有为模型直接开放标准接口。为解决这一问题，行业开始探索视觉交互方式。2024 年 Anthropic 推出 Computer Use，尝试让模型直接理解屏幕内容并操作计算机

随后，开源社区又发展出 Browser Use 一类方案，借助浏览器自动化技术，让模型能够间接完成网页级操作。这标志着模型的工具使用能力开始从“调用接口”走向“操作环境”。

再往后，行业开始进入标准化阶段。Anthropic 推出的 MCP（Model Context Protocol）试图用统一协议规范模型与工具、数据源之间的连接方式；OpenAI 也推出了 Responses API 和 Agents SDK，从接口和开发框架层面强化模型的工具调用能力。工具使用能力因此不再只是零散的工程拼接，而开始演进为更标准化、更可扩展的基础设施。

（4）记忆/上下文，从短期缓存到长期知识库

记忆模块是 Agent 的状态与经验管理中心，负责保存短期上下文和长期知识，并为后续推理、规划和行动提供信息支撑。 它不是静态存储，而是一个具备动态演化、按需访问和持续更新能力的记忆系统。

记忆管理的成熟度，直接决定了 Agent 是否能够实现多轮上下文承接、长期个性化服务以及基于历史经验的持续优化。现在大模型差异越来越下，各种Harness工程化落地产品的差异重点就在于是否具备更佳记忆管理能力。

（5）用户反馈-Feedback

Feedback模块是 Agent 的结果校验与优化闭环，负责收集用户反馈、执行结果和环境响应，并据此识别问题、修正偏差和提升系统表现。 它的意义不只是提高回答准确率，更在于增强 Agent 在不同任务、不同环境和不同业务场景下的稳定性与可靠性。一个成熟的 Agent，必须具备基于反馈持续修正和不断优化的能力。

Agent范式

在 AI 应用开发中，Agent（智能体）通常是指一种能够感知环境、基于目标自主做出决策，并进一步采取行动的 AI 系统。它不再只是被动接收输入、生成输出，而是能够围绕任务目标持续推进执行过程。

与传统“问一句、答一句”式的大模型调用方式不同，Agent 具备多步任务处理能力。它不仅可以连续执行多个动作，还可以根据上下文和中间结果动态调整策略，调用外部工具，甚至与其他 Agent 协同工作，从而完成更复杂的任务。

Agent 的工作方式本质上是一个循环（Loop）——感知当前状态，推理下一步，执行行动，再次感知……直到任务完成。

不同架构的差异，就在于如何组织和扩展这个基本循环。Agent架构是指 Agent 系统中各个组件的组织方式，决定了 Agent 的能力边界、可靠性、灵活性和适用场景。

Agent范式是指，单个 Agent 或一组 Agent，是按照什么决策方式在工作。Agent范式通常涉及到如何利用这些模型来提升代理的规划、决策和执行能力。

（1）ReAct（Reasoning + Acting）

ReAct 模式（Reasoning + Acting）：每一步都是"先想再做"。LLM 充当大脑，工具调用是它的双手。这也是单Agent最为常见的范式。

它的核心流程在于：Thought -> Action -> Observation -> Thought -> Action

## 入口
def start(user_input: str) -> AIMessage:
    model = create_model_llm()
    usermsg = HumanMessage(content=user_input)
    tools = [get_user_info_tool,get_user_address_tool]
    model = model.bind_tools(tools)
    msglist.append(usermsg)
    
    ## 1. Thought 
    message = model.invoke(msglist)
    message = tool_loop(model,message)
    msglist.append(message)
    return message

## 工具循环
def tool_loop(model : BaseChatModel , message : AIMessage) -> AIMessage:
    while True:
        if not message.tool_calls:
            return message
        for tool_call in message.tool_calls:
            ### 2. Action
            tool_message = invokeTools(tool_call)
            msglist.append(tool_message)
        ## 3. Observation 
        message = model.invoke(msglist)

这种架构范式，每次工具调用的结果都会回写到上下文（Context Window）。因此随着任务推进，上下文会不断增长，直到触达 LLM 的上下文窗口限制——这是单 Agent 循环最主要的瓶颈。

（2）Plan-and-Execute

将"想清楚要做什么"和"实际去做"分离为两个独立阶段，提升任务的可预测性和可审计性。规划 + 执行范式将 Agent 的工作拆分为两个明确阶段：先规划（Plan），再执行（Execute）。

• 在规划阶段，模型不执行任何操作，只生成一份详细的执行步骤列表。

• 在执行阶段，系统依次完成每个步骤。这种分离让用户可以在执行前审查计划，就像 Claude Code 的 Plan Mode 一样。

Claude Code 的 Plan Mode 就是这个架构的体现——点击"计划"后，AI 先输出一份详细计划供你审查，确认后才开始执行。这大幅提升了用户的掌控感。

Plan & Execute vs. ReAct

• Plan : Agent自主决定执行哪些步骤来完成更大的任务

• ReAct: Agent根据环境的变化做出反应

（3）Reflection

Reflection 是“执行后自我检查和修正”。它的核心是在 Agent 的输出环节加入质量评估，不满意则重新生成或修正，形成内部迭代循环。

Plan & Execute 和 ReAct核心在与组织行动方式，而Reflection 在与行动后的检查与自我修正。他们可以进行组合使用在Agent架构中，例如：

• ReAct：思考、调用工具、得到答案

• Reflection：检查最终答案是否可靠，是否满足结果要求，例如格式、范围等

组合的方式可以根据实际场景确定，例如每一步Action后进行Reflection，还是整体ReAct之后进行Reflection

Reflection落地通常也可以分为多种方式：

✔️ 单Agent自我Reflection

这是最常见、成本最低的方式。在Action产生结果后，可以切换角色对结果进行检查，并将检查结果设定到上下文，继续思考处理。

✔️ 独立Critic Agent（评判者Agent）

Agent 增加了一个"质检环节"：每次生成输出后，都由一个评判者（Critic）Agent来评估质量，如果不达标则要求修正，直到输出满足标准。

这就像开发者写完代码后自己跑一遍测试——在交付之前先自查一遍。

（4）RAG + Agent

RAG Agent 是“检索增强生成”式 Agent。在 Agent 的工具集里加入向量检索能力，让 Agent 在推理过程中动态查询外部知识库，克服上下文窗口的限制。

普通 RAG 是"被动、一次性"的：用户提问时固定检索一次，将结果塞入 Prompt。

用户问题 -> 检索知识库 -> LLM 回答

RAG Agent 更进一步，Agent 自主判断在推理的哪个环节需要补充知识、需要检索什么，并可以多次查询知识库，直到获得足够的信息来完成任务。

判断是否需要检索 -> 选择检索源 -> 多轮检索 -> 综合推理 -> 回答

RAG（Retrieval-Augmented Generation，检索增强生成）本是一种让 LLM 查询外部知识库的技术。当它与 Agent 结合时，变得更加强大：Agent 可以主动决定何时检索、检索什么，而不是每次都被动地检索一次。

（5）Multi-Agent

Multi-Agent 是“多个 Agent 分工协作，该范式通过一个协调者负责全局任务拆解、调度与结果整合，再由多个专门化 Subagent 分别处理具体子任务。Subagent 可以根据任务依赖关系并行或串行执行，最终将结果汇聚回 Orchestrator（主Agent），由其完成综合判断、冲突处理和最终输出。

这种好处为，当单个 Agent 受限于上下文窗口、能力边界或任务复杂度时，多 Agent 架构是一种更具扩展性的解决方案：它将复杂任务拆分给多个职责清晰的子 Agent 协同完成，每个子 Agent 拥有独立的上下文窗口。由 Orchestrator 统一把控目标、流程和质量。

这种方式其实更趋向于一种Agent架构，而各Subagent可以采用以上各种范式推进。

子 Agent（Subagent）是短暂的、隔离的——完成一个任务后即销毁。Agent 团队（Agent Teams）则是多个独立 Agent 实例长时间协作、互相发消息，更像一个真实的团队。

（6）Workflow Agent

Workflow Agent 是“流程编排型 Agent”，它不像 ReAct 那样自由探索，而是按照预定义流程走。它把 Agent 行为固化为一张有向无环图（DAG），每个节点是一个 LLM 调用或工具调用，边表示数据依赖关系，由框架驱动执行。

这种更趋向于传统软件工程的一种落地Agent模式，它不由LLM自由发散，而是通过确定性流程来约束，Agent 的自主决策空间被限制在单个节点内部

例如报销审核：

提交单据 -> OCR 识别 -> 校验金额 -> 匹配制度 -> 判断是否合规 -> 生成审批意见

决策

在实际生产系统中，通常会组合多种架构方式，这种主要取决于Agent所要解决的具体任务目标。

• 如果你的目标工作是明确流程化任务，例如CICD中代码检查、安全扫描等，就可以采用 Workflow + Multi Agent。

• 如果目标只是一个简单工作任务，在几步之内就能搞定的，就尝试使用简单的ReAct，例如代码检查。

• 如果你的任务结果有非常严格规范、质量等要求，可以结合Relfection。

但是需要注意的是，架构并不是越复杂越好，我们尽量保持从简的架构模式来实现我们的目标，尽量从工程化、成本的维度来进行选择。