Agent 技术科普：开启智能体的新时代

AI AgentLLM

一、引言

人工智能正处于一次范式迁移的节点：从“能说”的大语言模型（LLM）走向“能做”的智能体（Agent）。LLM 带来了通用的语言理解和生成能力，但它仍然是一个
封闭、被动、短期记忆的系统：知识停留在训练时刻，无法直接访问实时世界；只能在用户输入后响应；上下文窗口限制使得记忆易失；输出不含可执行语义，更谈不上与外界系统协作。

Agent 的提出，正是为 LLM 补齐“行动力”：通过工具调用连入 API/数据库/计算环境，通过记忆维持跨会话状态，通过编排
将复杂任务拆解为可控的工作流，必要时引入多 Agent 协作。当这四个维度协同起来，语言就不再是终点，而是驱动系统执行任务的接口。

二、Agent 是什么

我们将 Agent 抽象为：大脑（LLM） + 工具（Tools/Functions） + 记忆（Memory） + 编排（Orchestration）。

  • 大脑：理解意图、推理计划、生成结构化中间表示（思考链/计划/工具参数）。
  • 工具：把自然语言转化为外部动作：HTTP API、数据库查询、代码执行、文件读写，甚至机器人控制。
  • 记忆：短期记忆承载对话上下文与临时事实；长期记忆借助向量数据库/关系库沉淀用户偏好、文档知识与任务状态。
  • 编排：以状态机/DAG表达任务流程，处理条件分支、并行、重试回退、超时与配额，提供可观测性与审计。

换句话说：Agent 是“会说话的操作系统进程”。它既遵循自然语言接口，又遵守工程系统的边界与约束。

三、Agent 能做什么

  1. 检索增强生成（RAG）：在回答前检索企业知识库或互联网，降低幻觉，确保时效与可追溯引用。
  2. 工具化操作：把“帮我预定会议室/查 Jira/跑报表”翻译为真实 API 调用与数据落库。
  3. 任务分解与计划执行：从“调研—起草—审稿—发布”的完整管道，到“数据提取—转换—加载（ETL）”的数据工程链路。
  4. 多 Agent 协作：研究员、撰稿员、质检员、执行官等角色并行或串行协同。
  5. 持续记忆与个性化：长期学习用户偏好与业务上下文，形成“专属助理”。

这些能力已在客服、法务审查、财务报表、运维巡检、投研分析、政企知识库等场景落地。

四、为什么需要编排

单一 LLM + 工具调用可以跑出 demo，但难以支撑生产。编排让 Agent 系统具备：

  • 任务有序性：复杂流程的前后置依赖、并行合并、条件分支。
  • 可靠性：失败重试、幂等、回退策略、超时与熔断、降级链路。
  • 安全性：提示注入防护、工具白名单、参数校验、沙箱执行、RBAC 与审计。
  • 可观测性：结构化日志、链路追踪（OTEL）、成本与延迟指标、交互回放。

没有编排，就没有“可运营”的 Agent。

五、主流框架详解

下面逐一剖析当前最具代表性的范式与框架：*
ReAct、Plan-and-Execute、LLMCompiler、LangChain、LangGraph、LlamaIndex、CrewAI/AutoGen*。每节都覆盖“背景 → 解决的问题 →
核心机制/特征 → 现状与生态 → 典型应用 → 优缺点 → 示例 → 学习建议”。

5.1 ReAct（Reason + Act）

背景
2022 年提出，动机是让 LLM 的行为可解释：将“思考过程”与“实际动作”分离，便于调试与审计。

要解决的问题

  • 让模型在调用工具前给出思考链（Thought），避免“黑箱行动”。
  • 在“思考—行动—观察”循环中逐步逼近目标。

核心机制
Thought → Action(tool, params) → Observation → Thought → ...

  • Thought：输出中间推理（可省略给用户，但用于系统决策）。
  • Action：按 JSON/函数签名触发工具调用。
  • Observation：工具/环境返回，再进入下一轮推理。

现状与生态
ReAct 已成为各框架默认参考范式，LangChain/AutoGen 等均内置。

典型应用

  • RAG 问答（先思考应检索哪些关键字→检索→解读→回答）。
  • 金融/运维查询（先枚举数据源→调用行情/监控 API→计算→结论）。

优缺点

  • 优点：透明、易调试、适合逐步探索。
  • 缺点：每步都要调 LLM，延迟与成本上升；需要控制泄露 Thought。

示例（LangChain 简化）

from langchain.agents import initialize_agent, load_tools
from langchain.chat_models import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini")
tools = load_tools(["serpapi", "llm-math"], llm=llm)

agent = initialize_agent(tools, llm, agent="zero-shot-react-description", verbose=True)
agent.run("美元兑日元的即期汇率是多少？100 美元大约换多少日元？")

学习建议
先学 ReAct，再看其他模式；理解“中间思考—外部行动”的边界与安全性。

5.2 Plan-and-Execute

背景
为缓解 ReAct 调用频繁、成本高的问题，提出“先规划再执行”，把 LLM 调用集中到规划阶段。

要解决的问题

  • 降低长任务的 LLM 调用次数与延迟。
  • 提高执行阶段的确定性与可回放性。

核心机制

  • Planning：LLM 产出任务分解（步骤、依赖、所需工具）。
  • Execution：流程引擎按计划逐步执行，必要时少量“再规划”。

现状与生态
LangChain 等框架提供内置链路；在复杂长任务中广泛使用。

典型应用

  • 报告/白皮书生成（规划章节→检索资料→写作→审稿）。
  • 数据工程（ETL）与指标计算。

优缺点

  • 优点：成本可控；对工程侧友好。
  • 缺点：对“初始计划质量”依赖高；需要良好的失败恢复策略。

示例（伪代码）

plan = llm("把‘新能源车行业研究’分解为可执行步骤")
for step in plan.steps:
    execute(step)  # 工具/代码/SQL
final = llm(f"根据执行产物撰写摘要：{collect_outputs()}")

学习建议
结合任务编排引擎（如 LangGraph）使用；关注“计划修正”的闭环设计。

5.3 LLMCompiler

背景
源自微软研究，借鉴编译器思想：把自然语言任务编译为可并行执行的DAG，以获得高吞吐。

要解决的问题

  • 将多工具/多数据源任务并行化，避免串行瓶颈。
  • 把“任务—执行图”的关系结构化，便于优化。

核心机制

  • 编译：LLM 将任务语义转成节点与依赖（DAG）。
  • 执行：节点并行运行，统一汇总。

现状与生态
学术与实验为主，工程落地探索中。

典型应用

  • 多网站并行爬取与聚合分析。
  • 多 API 并行获取数据后统一建模。

优缺点

  • 优点：吞吐高、结构清晰。
  • 缺点：实现复杂；缺少成熟的标准化工具链。

示例（伪代码）

dag = compile_to_dag("对‘政策/销量/技术’三方面做新能源车行业分析")
dag.execute_parallel()
summary = llm("汇总 DAG 结果并给出结论")

学习建议
理解 DAG/并行执行与幂等性；适合系统工程背景的团队。

5.4 LangChain

背景
2022 年开源，首个“把 LLM 嵌入应用”的通用开发框架。

要解决的问题

  • 统一抽象 Prompt/LLM/Memory/Tools/Chains/Agents。
  • 快速搭建原型与 PoC，降低入门门槛。

核心特征/架构

  • LLM Wrappers：适配主流云模型与本地模型。
  • PromptTemplates：可参数化提示词。
  • Memory：会话/长期记忆，支持自定义后端。
  • Tools：声明式工具定义与参数校验。
  • Chains/Agents：组装工作流或启用工具化智能体。

现状与生态

  • 社区最大、教程与示例最全；大量第三方集成。
  • 复杂生产系统往往与LangGraph/自研编排结合使用。

典型应用

  • 文档问答（RAG Agent）。
  • 智能客服/助手。
  • 代码/数据处理助手。

优缺点

  • 优点：生态全、迭代快、原型成本低。
  • 缺点：组件众多、耦合度易升高；需谨慎裁剪。

示例（RAG QA 极简）

from langchain.chains import RetrievalQA
from langchain.chat_models import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini")
qa = RetrievalQA.from_chain_type(llm, retriever=vectorstore.as_retriever())
print(qa.run("总结这份合同的关键风险"))

学习建议
用它“站起来”，但不要把它当全部；与观测/编排/缓存协同设计。

5.5 LangGraph（含 LangGraph Platform）

背景
LangChain 的链式范式难以表达循环、回退、并行与长时状态。LangGraph 将 Agent 视为显式状态机/DAG，并与观测平台集成。

要解决的问题

  • 复杂工作流的可控性与可观测性。
  • 长运行任务的状态持久化与弹性伸缩。

核心特征/架构

  • 状态图（StateGraph）：定义节点（函数/Agent）与边（条件/并行/回路）。
  • 人机协作：在关键节点注入“人工审核/纠偏”。
  • 与 LangSmith/OTEL 联动：日志、追踪、成本面板。
  • Platform：受管端点、持久队列、版本化与回放。

现状与生态
企业采用度上升；Platform 侧提供“从开发到部署”的一体化体验。

典型应用

  • 合规审查流水线：抽取 → 规则/LLM 检查 → 复核 → 报告。
  • 企业知识库问答：检索 → 生成 → 评估不合格回退。

优缺点

  • 优点：工程化最佳平衡点；对复杂任务友好。
  • 缺点：学习成本较高；图的演进需要治理。

示例（检索→生成→评估→回退）

from langgraph.graph import StateGraph


def retrieve(state): ...


def generate(state): ...


def evaluate(state): ...  # 返回 pass/fail


g = StateGraph()
g.add_node("retrieve", retrieve)
g.add_node("generate", generate)
g.add_node("evaluate", evaluate)

g.set_entry_point("retrieve")
g.add_edge("retrieve", "generate")
g.add_edge("generate", "evaluate")
g.add_conditional_edges("evaluate", {"pass": "END", "fail": "generate"})

学习建议
把“业务流程图”翻译成“状态图”，自下而上替换节点：先用伪实现跑通，再替换为真实工具/服务。

5.6 LlamaIndex

背景
（原 GPT Index）从“让 LLM 使用外部数据”出发，沉淀为数据接入与检索增强平台。

要解决的问题

  • 把文档/表格/数据库接入到 LLM。
  • 提供多索引与混合检索以提高召回与可控性。

核心特征/架构

  • 数据连接器：FS、S3、GDrive、Notion、数据库等。
  • 索引：向量索引、关键词索引、图索引等。
  • 检索：BM25 + 向量 + 重排（可插拔）。
  • 与 LangChain/LangGraph 兼容，可作为检索层。

现状与生态
在知识库/文档问答领域最常用；正扩展到多模态。

典型应用

  • 合同与政策问答；内部 Wiki 助手；会议纪要问答。

优缺点

  • 优点：数据侧强、接入快、检索策略丰富。
  • 缺点：编排弱；需要配合工作流框架。

示例（向量索引）

from llama_index import GPTVectorStoreIndex, SimpleDirectoryReader

docs = SimpleDirectoryReader("docs").load_data()
index = GPTVectorStoreIndex.from_documents(docs)
query_engine = index.as_query_engine()
print(query_engine.query("列出这份合同的终止条款"))

学习建议
作为“数据/RAG 层”的强力搭档，与 LangGraph 共同组成“检索 + 编排”的主干。

5.7 CrewAI / AutoGen（多 Agent 协作）

背景
开源社区探索“虚拟团队”形态：通过多个角色化 Agent 的协作完成复杂任务。

要解决的问题

  • 单 Agent 能力边界：需要专家分工与相互制衡。
  • 让“研究—写作—审稿—发布”自然映射到多 Agent。

核心特征/架构

  • 角色与职责：researcher、writer、reviewer 等。
  • 消息编排：对话驱动的协同；可插人类审核。
  • 任务路由：不同子任务交由不同角色处理。

现状与生态
科研/实验社区活跃；企业落地需要补齐观测、安全与治理。

典型应用

  • 行业研报与竞品分析；内容生产流水线。

优缺点

  • 优点：贴近人的协作心智模型，易扩展角色库。
  • 缺点：生产治理薄弱；复杂度随角色数上升。

示例（AutoGen 极简）

from autogen import AssistantAgent, UserProxyAgent

assistant = AssistantAgent("researcher", llm_config={"model": "gpt-4o-mini"})
user_proxy = UserProxyAgent("writer", human_input_mode="NEVER")
user_proxy.initiate_chat(assistant, message="写一份新能源车行业调研大纲")

学习建议
以“小团队”起步（2–3 角色），收敛职责边界；引入编排框架承接生产治理。

六、学习路径（技术依赖关系）

只给“依赖链”，便于立刻开工：

  1. 语言与接口 → Python/JS 基础；HTTP/JSON；异步与并发。
  2. LLM 能力 → Prompt Engineering；Function Calling/Tool Use；结构化输出（JSON Schema）。
  3. RAG 能力 → 文档分块与清洗；嵌入模型；向量数据库（pgvector/Milvus/Weaviate）；混合检索与重排。
  4. 编排能力 → 状态机/DAG（LangGraph）；重试回退；超时熔断；人机协作。
  5. 运维能力 → 日志/追踪（OpenTelemetry）；指标（Prometheus/Grafana）；安全（提示注入防护、RBAC、审计）；部署（Docker/K8s/Cloud
    Run）。

沿这条路径递进，你可以从“能调模型与工具”，稳步走到“能搭生产可运维的 Agent 系统”。

七、未来展望

多模态 Agent 将同时处理文本、图像、语音与视频，统一在一个任务图里协同；模型路由与降级会让系统自动在质量、成本、延迟之间折中；
Agent OS/编排平台将成为企业的“智能内核”，承载权限、任务、审计与经济计量；而 LLMOps 标准化
则会把“可观测、安全治理、回放评测”固化为工程必修课。

八、结语

从 LLM 到 Agent，不只是“接口变了”，而是软件工程边界的扩大：语言成了新的“应用协议”，编排成了“智能内核”，数据与工具成了“外设”。掌握本文的框架图谱与依赖链，意味着你可以按需组装：以
LlamaIndex 做数据底座，以 LangGraph 管编排，以 LangChain/AutoGen/CrewAI 做场景拼装，再用监控与安全把它变成真正可运营
的系统。愿你从 demo 出发，驶向生产。

加载导航中...

评论