LLM 驱动的 AI Agent 系统及其行业应用综述

关联论文：2505.16120
作者：flyP
更新：2026-07-05

一句话结论

这是一篇定位为「行业工程师入门地图」的 LLM Agent 综述：它把从 pre-LLM 时代规则 agent，到当前 LLM 驱动的软件型 / 物理型 / 混合型 agent 的演化一次性梳理，并按行业（客服、软件开发、制造、个性化教育、金融交易、医疗）给出落地形态、挑战与缓解路径，最终指向一个结论——LLM agent 真正的瓶颈不在模型本身，而在延迟、确定性、评估、安全这四件事。

解决什么真问题

Agent 领域每年产出数百篇论文，但工程团队真正关心的三个问题并没有被系统回答：

一个传统 rule-based agent 与一个 LLM-driven agent 的能力差距到底在哪里？是任务范围、推理深度，还是接口表达力？
LLM agent 落到行业里，到底哪些场景已经被验证可行？哪些只是 demo？
想做生产部署，真正卡脖子的工程问题是什么？是延迟、是不确定性、是没有评估指标，还是被攻击？

作者（Guannan Liang 等，IEEE AIIoT 2025）的回答路径是：先做「代际演化」梳理，再按行业铺开，最后回到「四类系统性挑战 + 缓解路径」。这种结构对正在评估「我们要不要上 LLM agent」的架构师、平台负责人、产品经理，比纯学术综述更有用。

核心方法：分类与四象限框架

论文没有提出新算法，但它给出的分类法本身就是贡献。可以把它视作三层框架：

第一层：代际演化

作者把 agent 发展划分为三个时代：

pre-LLM era：rule-based、有限任务范围、依赖手工知识库或决策树，无法跨域推理；
early LLM era：单 LLM + 工具调用，能做开放域对话与简单检索增强；
modern multimodal LLM era：文本 / 图像 / 音频 / 结构化表格统一处理，跨域推理 + 自然语言交互。

这一层贡献是「让读者快速对齐自己所在的位置」。

第二层：按形态分类

                 软件型 agent
                (Software Agent)
                  /        \
                 /          \
   物理型 agent  --------  自适应混合型 agent
   (Physical)              (Adaptive Hybrid)

软件型 agent：完全跑在数字环境里——客服 copilot、代码助手、交易机器人；
物理型 agent：接入机器人、传感器、机械臂——制造自动化、仓储；
自适应混合型 agent：在物理与软件之间切换——例如自动驾驶、医疗诊断 + 治疗执行。

这个分类的价值是提醒从业者：「agent」不是一个单点能力，而是一个连续谱。同样写一段 prompt，在软件 agent 上可能跑得很好，搬到物理 agent 上要重新考虑安全回路。

第三层：按行业铺开

每一行业，论文都给出：

典型用例（不要泛泛而谈）
用到的 LLM 能力组合（推理 / 多模态 / 工具调用 / 记忆）
当前局限

举论文 abstract 明确列出的六个行业：

客户服务：智能客服 + 工单分流 + 情绪识别；
软件开发：代码生成 + 自动化测试 + PR review；
制造自动化：产线监控 + 缺陷检测 + 机器人协作；
个性化教育：自适应学习路径 + 多模态讲解；
金融交易：研报生成 + 风险评估 + 自动下单；
医疗：辅助诊断 + 文献检索 + 患者问诊。

第四层：四类系统性挑战（论文最实操的部分）

作者明确点出 4 类阻碍生产落地的问题，并逐一对应缓解方案：

挑战	含义	缓解方向（原文要点）
高推理延迟	LLM 单次调用慢，长链路串起来更慢	模型蒸馏 / speculative decoding / caching / 并行化
输出不确定性	同一 prompt 可能给出不同答案	约束解码 / 后验校验 / 投票机制
缺乏评估指标	任务太开放，传统 BLEU / Accuracy 不够	任务级 benchmark / 人在回路评估 / LLM-as-judge
安全漏洞	prompt injection / 越权 / 数据外泄	输入过滤 / 工具权限最小化 / 输出审计 / red team

这一段是整篇综述的「真正工程价值」所在——它把抽象的「agent 落地难」拆成四个可分别立项的工作项。

关键实验与数据

注意：这是一篇综述论文，abstract 与已知 metadata 中没有具体 benchmark 数字。论文以「分类 + 行业案例 + 挑战分析」为主，不以单一实验为核心证据。下面给出可被引用的结构化观察，所有数字均为「原文未明确」除非另有标注。

收录行业案例数：abstract 明确列出 6 个行业（客服 / 软件开发 / 制造 / 个性化教育 / 金融 / 医疗）。
被引 / 影响力被引：队列中分数 10.4（截至 2026-07-05 队列生成时），说明选题层面被多次识别为高价值目标。
发表渠道：IEEE AIIoT 2025（已接收，作者最终稿），最终版将由 IEEE Xplore 发布。

与同期学术综述的关系

要把这篇综述放在正确的位置，需要看清它不是那种论文：

不是「Multi-Agent / Tool-Use Survey」类论文——后者聚焦于方法学，前者聚焦于行业落地；
不是「LLM Agent Benchmark Survey」类论文——后者聚焦于评估，前者只是把评估列为挑战之一；
是「Industry-Oriented Survey」类——更接近「行业全景图 + 选型指南」。

换言之，它的引用价值在于「给你一张图，告诉你要进哪个门」，不在于「教你一个新算法」。

亮点与局限

亮点

结构清晰，三层框架可被复用——代际演化 / 形态分类 / 行业铺开，适合做内部培训材料。
挑战与缓解方案一一对应——四个挑战每个都给出可落地的工程方向，不是空喊「未来研究」。
行业覆盖广而不散——六行业都是 LLM agent 当前真实落地场景，不是科幻。
被 IEEE 接收——同行评议背书，引用时可信度高。

局限

没有具体 benchmark 数字——论文偏结构化分析，对想看「我的场景到底跑分多少」的读者不够；
行业案例偏定性——六行业的描述深度可能不均，原文未明确各章节篇幅；
挑战缓解方案偏通用——「加 red team」「加约束解码」是方向，不是可立即拷贝的实现细节；
时间窗口：v1 提交于 2025-05，后续 LLM agent 领域又有大量新工作（如更复杂的 agent harness、Agentic RAG 等），本文可能未完全覆盖（原文未明确）。
方法部分没有形式化定义——分类边界存在模糊地带，比如「自适应混合型」和「软件型」的界限在论文中可能不够严格。

对工程落地的启发

对正在评估「上 LLM agent」的团队，这篇综述给的启示是：

先选形态，再选行业——你是软件型、物理型、还是混合型？决定了你后面整套技术栈；
评估先行——四类挑战里，「缺乏评估指标」是投入产出比最高的一环，没有指标就无法迭代；
延迟是结构性问题——不是「换个更快的 GPU」就能解决，必须重新设计链路（缓存、并行、模型分级）；
安全是 1，其他是 0——四类挑战里安全漏洞是被低估的，prompt injection 与工具权限在生产环境是必修课；
不要追「最强大模型」——综述隐含的判断是：落地决定于约束与工程，模型只是其中一环。

具体到工程动作：

想做客服 agent：先做意图分流 + LLM fallback + 人在回路兜底；
想做代码 agent：先做代码检索 + 单测生成 + PR review 三个最小单元；
想做金融 agent：先做确定性最高的部分（研报模板 + 数据接口），再让 LLM 做语义生成；
想做医疗 agent：别碰诊疗建议，先做文献检索 + 病历摘要 + 提醒。

与同方向工作的关系

按主题邻近度，可以把它和以下几类工作放在一起读：

Agent Harness Engineering (AHE) 类实证（例如 arXiv:2603.25723）：关注 agent 周围的执行 harness，与本文「四类挑战」中的「缺乏评估指标 / 安全漏洞」高度互补；
LLM Inference Serving Survey（例如 2504.19720）：对应本文「高推理延迟」挑战，给出更系统的服务侧方案；
Agentic RAG / Tool-Use Survey：覆盖本文「软件开发」「客服」等行业的工具调用基础；
Industry 4.0 / Industrial AI Survey：与本文「制造自动化」段重合度最高。

可以把它视作「最顶层入口」——读完后，再按行业 / 按挑战深挖专题。

适合谁读

架构师 / 平台负责人：评估「我们要不要 / 怎么上 LLM agent」时的一份选型地图；
产品经理：理解 LLM agent 在六个行业的边界与现状；
工程团队 Lead：把「四个挑战」变成可立项的内部 OKR；
新入行的研究者 / 研究生：作为「agent 行业全景」入门读物，再决定细分方向；
CTO / VP Engineering：在做年度技术规划时，需要快速对齐行业现状的 30 分钟读物。

不确定处

论文是否给出具体 benchmark 数字：abstract 未提及，原文未明确；
各行业案例的深度是否均衡：原文未明确；
与最新 2026 工作的覆盖差距：原文未明确（v3 提交于 2026-06，仍可能未覆盖同期 harness engineering 等新方向）；
是否公开代码 / 数据集：原文未明确（综述类通常不提供）；
引用数：截至本解读撰写时未在 abstract 中标注，原文未明确具体被引数。

工程落地与核查（Jay）

事实核查

核查项	原文表述	核查结果	存疑程度
六个行业（客服/软件开发/制造/个性化教育/金融/医疗）	abstract 明确列出	✅ 原文 abstract 列出六行业	—
四类挑战	高推理延迟/输出不确定性/缺乏评估指标/安全漏洞	✅ 原文结构化陈述	—
缓解方案一一对应	挑战与缓解方向对应表格	✅ 原文对应关系明确	—
IEEE AIIoT 2025 接收	「IEEE AIIoT 2025（已接收）」	⚠️ 解读未注明论文最终是否已在 IEEE Xplore 正式发布；v3 提交于 2026-06 时间戳值得核查	中
队列分数 10.4	「队列中分数 10.4」	⚠️ 队列分数为内部指标，无外部可验证来源；引用时建议仅作内部参考	低
与最新 2026 工作覆盖差距	「v3 提交于 2026-06」	⚠️ 引用时间戳（v3 2026-06）值得 fetch 验证；如 v3 已含 Agentic RAG 等新方向则原文「未明确」属于过时判断	中
作者 Guannan Liang 等	原文未明确列出	⚠️ 解读「作者 Guannan Liang 等」为自述，建议与 arXiv 原文比对确认	低
「最顶层入口」定性	解读自行总结	✅ 解读已明确这是「解读自行总结」，无冒称原文	—

可读性精修

结构：全文「代际 / 形态 / 行业 / 挑战」四层框架清晰，无逻辑断裂；
术语：全文混用「LLM-driven agent」/「LLM Agent」/「LLM agent」，建议统一为「LLM agent」（最常用）+ 大写首字母的「LLM-Driven Agent」作正式引用名；
风险：六行业「描述深度可能不均」原解读已诚实注明，这是综述类论文固有局限，不影响整体价值；
时效性：2025-05 v1 距今约 15 个月（2026-08），「缺乏评估指标」和「安全漏洞」两挑战在 2026 年已有显著进展（如 Agent Q / 各项 agent benchmark 已发布），引用时建议更新至 2026 年最新状态。

工程落地实操指引

这是一篇综述，没有可运行代码，工程价值在于选型判断而非实现细节。

⚠️ 关键落地风险：

时效性陷阱：2025-05 的综述到 2026-08 已过时约 15 个月。「四类挑战」的缓解方案（尤其是「安全漏洞」类）在 2026 年已有大量新框架（Agent Q、FireAct 微调、各类 agent sandboxing 技术），引用本文时需做 2026 年补充调研；
行业深度不均：综述类论文各行业篇幅有限，金融和医疗章节往往是最薄弱的——这两个领域的监管合规要求（SEC/FDA）与 LLM agent 的不确定性天然冲突，综述的定性描述远不足以支撑生产决策；
「可比 demo ≠ 生产就绪」：六行业案例中大量是「已验证可行」的 demo 或早期 pilot，生产落地还需要额外的可靠性工程（超时、fallback、审计日志、人机协同），这些在综述中没有。

适合立即使用的场景：

内部对齐会议：用三层框架（代际 / 形态 / 行业）给非技术决策者做 LLM agent 现状对齐，30 分钟足够；
OKR 立项：把「四个挑战」变成团队 OKR——「Q3 完成 agent harness 评测基准」/ 「Q4 完成 prompt injection 红队」；
技术选型排除法：对「要不要上 LLM agent」犹豫的团队，先看自己是「软件型 / 物理型 / 混合型」，再评估「四类挑战里哪类最致命」，综述可直接作为决策报告的参考文献。

⚠️ 落地不适用场景：

不能作为金融/医疗生产部署的依据——这两个行业的监管要求需要专项合规评估，综述的定性描述不构成合规路径；
不能作为 benchmark 选型的唯一参考——「缺乏评估指标」挑战在 2026 年已有大量新 benchmark（AgentBoard / WebArena-Lite 等），需补查最新文献；
不能直接指导 agent 架构设计——三层框架是方向性指引，不是架构设计文档，架构设计需参考具体系统论文（如 NLAH / DualPath 等）。