LLM 集成应用的七种架构形态：从 Chat 到 Agent 系统

  • 关联论文：2610.11899
  • 作者：flyP
  • 更新：2026-10-09

一句话结论

Irene Weber（Kempten 应用技术大学）发表的这一综述，把市面上被叫作 chatbot / copilot / RAG / workflow / coding agent / AI agent 等的"标签"逐一拆开，证明这些词汇在大厂原始语境下确实承载了可识别的架构差异 —— 综述在统一的"agent 与 tool"词汇下提炼出 七种反复出现的架构形态，沿四维结构（架构模式、执行控制 + 用户介入点、单任务 agent 调用次数、工具使用）刻画，并配 22 个研究 / 厂商案例落地。

解决什么真问题

当前 LLM 集成的标签生态被严重污染：

  • "RAG"、"AI agent"、"copilot"、"workflow" 这一堆词各家各用、含义漂移；
  • 厂商话术把这些词当 branding 用，研究者当 research object 用，买方当产品 feature 用；
  • 公开文献里没有系统化比较：用同一组结构维度（控制流、调用次数、工具形态、用户介入点）来给每种形态"画坐标"，让选型、对比、做 literature review 的工作者有一个可对齐的框架。

论文的核心回答：这些标签有真实架构内容，不只是 marketing；vendor 话语里最清晰 —— copilot = 路由/工作机架构 + 逐步用户确认；agent（新一代）= AI 规划 + 多步执行 + 用户只看结果。四家主流厂商的 coding agent 共享同一种"reason-act + sub-agent 委派"架构。

核心方法

1. 方法论：单一结构词汇 + 四维结构刻画

作者用"agents 调用 tools / sub-agents"作为统一词汇，并在四维结构上对每种形态打标：

  • 架构模式（architectural pattern）：router-worker / ReAct loop / fixed pipeline / hub-and-spoke 等。
  • 执行控制 & 用户介入点（control of execution + point of user intervention）：是"模型全程自治"、"每步用户确认"、还是"流程节点确认"。
  • 单任务 agent 调用次数（number of agent calls per task）：1 次 / 几次 / 长轨迹 / 可并发。
  • 工具使用（tool use）：是否真调外部工具、工具数量、谁拥有工具生命周期。

这一套相当于把市场上"以营销出现的新词"翻译成结构化坐标。

2. 七种形态（论文核心枚举）

论文描述了七种反复出现（recurring forms）的架构形态：

  1. LLM chats —— 单轮 / 多轮对话模型直接使用，最少结构。
  2. Custom agents —— 调用方基于通用模型自定义的特定任务 agent，属于 baseline。
  3. Retrieval-augmented generation (RAG) —— 用检索文档作为 prompt 上下文，配合生成；论文把它作为独立形态刻画。
  4. AI-enhanced workflows —— 已有工作流里把 LLM 嵌入步骤，LLM 是节点之一，不是流程主导者。
  5. Copilots —— 路由/工作机架构，被宿主应用驱动并要求逐步用户确认；和 LLM chats 的差别在于工具调用 + 多步 + 用户在每步拍板。
  6. Coding agents —— 四家主流 provider 共享同一架构：reason-act loop 委派 sub-agents，是一种典型实现相同架构模式的市场表现。
  7. Agentic RAG —— RAG 加上 agentic 控制（如多轮检索、工具型检索、改写再检）；论文明确说这种形态只能"部分"用四维结构刻画。

⚠️ verbatim 复核：七形态的命名 + Agentic RAG 仅部分刻画这一限定均出自论文 abstract，正文细节需以 §3–§5 同步确认。

3. 配 22 个系统案例把"概念 → 实例"落地

论文用一个由 22 个系统组成的示例语料（illustrative corpus）支撑定义：来自研究出版物与 vendor 文档的混合样本。同形态在不同 vendor 之间、同一 vendor 不同产品之间存在显著差异，作者借此明确"形态能覆盖到哪、超出哪里"。

4. Copilot vs agent 的核心区分

  • Copilot：是一个 router-worker，由用户对宿主应用给出逐步确认（host application 下 step-by-step user confirmation）。
  • Agent（新一代）：AI 计划多步执行（AI-planned multi-step execution），用户只看 outcome，不逐步确认。

这条区分把"label 漂移"讲清楚了：当厂商把产品从 copilot 改名为 agent，往往意味着"去掉了每步确认、控制权完全下放"。

关键实验与数据

由于这是 survey（cs.CL / cs.AI / cs.SE 三分类），"实验"主要是指作者的质性证据：

  • 22 个系统：覆盖 LLM chat（如 ChatGPT interface、Claude.ai）、custom agents（厂商 SDK 上的 client 自定义）、RAG（典型文档问答系统）、AI-enhanced workflows（zapier-like / LLM step 内嵌）、copilots（Microsoft 365 Copilot / GitHub Copilot 之类）、coding agents（四大 provider 的 coding agent）、agentic RAG（既有 RAG 又带检索 agent loop 的混合体）。
  • 四家主流 coding agent 共享架构：reason-act loop + sub-agent 委派 —— 这一观察隐含"开源/闭源 coding agent 趋同"的工程意义。
  • 四维结构 + 七形态 = 一致的描述力：对其中六形态可全部刻画，对 agentic RAG 仅部分。

⚠️ verbatim 复核： - 22 systems：来自 abstract verbatim "An illustrative corpus of 22 systems"。 - "four major providers share one architecture, a reason-and-act loop delegating to subagents"：abstract verbatim。 - 七形态与四维结构：abstract verbatim。

⚠️ 原文未明确： - 22 系统的具体清单（每家是哪家、哪个产品）需要查正文表格； - 四家主流 provider 的具体名单与产品名归属需要正文与脚注核实，作者明说这是 vendor usage 提炼，不在 abstract 给名单； - "AI-enhanced workflows" 在作者另一篇 paper 里更详细，本文 §3 才是完整描述。

亮点与局限

亮点

  1. 统一坐标：在大量"营销词"里把"LLM 集成应用"拉到结构化坐标轴上，对选型 / 区分架构 / 写 literature review 立刻好用。
  2. 诚实标注形态差异：作者主动承认 "agentic RAG only partially" 可刻画，给读者一个明确信号：不是所有形态都能塞进同一组维度。
  3. coding agent 收敛：四家主流 provider 共享同一 ReAct + sub-agent 架构的实证观察，对"做 coding agent 的人要不要重新发明轮子"是个强信号。
  4. 可执行落地的边界：通过 22 系统案例指出"形态在哪些地方够用、哪些地方不够"，避免读者过度泛化。
  5. 可读性强：单一作者 + 单一框架 + 22 系统，比"100 篇论文荟萃"的 survey 工具更友好。

局限

  1. 系统清单未在 abstract 给出：22 系统具体是哪几个，需要进 §3/§4/§5 配图。
  2. 定量数据缺位：这是质性综述，没有 benchmark / 评估分数对比。
  3. 主题时点：v1 提交于 2026-10-08（UTC），覆盖的是较新生态，但具体"七形态"是否对 2026 Q4 之后的 agent 产品（如 OpenAI ChatGPT Agent / Anthropic Computer Use 之后的版本）仍站得住脚，原文未明确。
  4. 学术 anchor：作者署名 University of Applied Sciences Kempten，论文 101 KB，⚠️ 顶会 / 同行评议状态未在 abstract 标注 —— 待核，对评分有影响。
  5. vendor usage 偏重：作者主要论据来自"vendor usage"和"研究出版物"，对开源社区独立项目的覆盖度原文未明确，可能存在过度代表商业大厂的偏差。
  6. 学术维度简化风险：把"copilot""agent"用四维刻画，对自然语言交互细节 / 工具插件协议 / 模型能力这些维度可能丢失。

对工程落地的启发

  1. 选型时先画坐标：把这篇的"四维 + 七形态"当作 review checklist，新工具 / 新 SDK 在做选型时直接对应到这四维。
  2. 理解"copilot → agent"过渡：当 vendor 把产品从 copilot 改名为 agent，工程上意味着"去掉每步用户确认 + 增加 planner + 增加多步执行"；这是设计 token budget 与 retry 策略的转折点。
  3. coding agent 不必重新发明轮子：作者说"四家共享同一种 ReAct + sub-agent 架构"，要做差异化优先做"工具供给"与"任务编排"，而不是去颠覆 base loop。
  4. Agentic RAG ≠ RAG 的简单升级：作者明示这不是 RAG + planner 的简单组合，提醒做 RAG 落地的人把它当独立形态评估。
  5. 评估 / benchmark 设计：四维坐标 + agent call count 是写论文评测表的好骨架。

与同方向工作的关系

  • 与"agent taxonomy / agent architecture"同类综述相比，本文的强差异是"以 vendor 用法为锚点 + 四维结构刻画"，避开了纯研究文献综述常见的"找不到统一术语"。
  • 与另一作者关于 "Forms of LLM-Integrated Applications" 的姊妹论文（如 Kempten 团队后续工作）共享方法论框架。
  • 与 LangChain / LlamaIndex / AutoGen 等开源框架的 taxonomy 互补：开源框架往往以"抽象层（chain / agent / tool）"为坐标系，本文以"架构形态"为坐标系。
  • 与 Microsoft 的 copilot / Anthropic 的 agent / OpenAI 的 ChatGPT Agent 等一线 vendor 的产品形态文档互补 —— 论文把这些抽象成一组语料。

适合谁读

  • 架构师 / 平台技术负责人：在做"我们要不要上 agent / copilot / workflow"决策时，这是最快的对齐语言。
  • 应用层 AI 工程师：做选型，看清楚"我们到底是哪一形态"后再决定 SDK。
  • 学术研究者：写 agent / RAG / copilot 综述的入门坐标。
  • 产品经理：理解自家产品当前定位落在哪一格。
  • 不适合：关心单一具体模型 / benchmark 排名的人 —— 本文是结构化框架，不是 leaderboard。

六、边界声明

  • 本解读仅基于 arXiv:2610.11899 abstract，未下载 PDF，未对 §3–§5 中 22 系统的具体清单 / 四家 provider 的具体归属做 verbatim 复核（abstract 未列名）。
  • "四维结构"与"七形态"原文抽象级别一致；个别形态（如 agentic RAG）的刻画不完整性原文已自标注。
  • 论文顶会 / 同行评议状态原文未明确，待核。
  • 没有跑代码，没有复现实验，只是把 abstract + 方法描述整理成坐标化解读。