从 LLM 应用到 AI Agent：根据业务边界，在架构谱系中找到你的落脚点

在 2026 年的今天，我们已经跨过了”大模型只会聊天”的阶段。

企业真正关心的，不再是”AI 能考多少分”，而是更直接的问题：

「这东西，能不能把一段业务流程接过去。」

但一旦进入落地，问题很快变得具体——也变得有点混乱：有的团队用一个简单的问答系统，试图覆盖所有场景；有的团队一开始就上多智能体（Multi-agent），把系统做得像一套”AI 团队”；也有人在两者之间反复摇摆，不确定哪里才是”刚刚好”。

结果往往并不意外：

• 本来只是 FAQ，却引入复杂编排，维护成本反而更高；
• 为了”更智能”加上反思和循环，响应时间从几秒变成十几秒；
• 工具链设计得很完整，但一旦某个 API 波动，整条流程就失效。

Gartner 的数据印证了这一点：至少 30% 的 GenAI 项目会在 PoC 阶段结束后被放弃，主要原因不是模型不够聪明，而是成本失控和业务价值始终说不清。¹ 针对 Agent 类项目，Gartner 进一步预测：超过 40% 的 Agentic AI 项目将在 2027 年底前被取消²。

问题通常出在更早的一步——

「我们还没搞清楚系统的“边界”，就已经开始堆砌“能力”了。」

为什么“边界”比“能力”更重要？

在 AI 系统设计中，有一个极具迷惑性的陷阱：认为 LLM (（大语言模型，也就是 ChatGPT、Claude 这类 AI 产品背后的核心技术) 的模型能力（Reasoning Ability）越强，系统就越能解决问题。但在工程实践中，我个人认为 “边界（Boundary）”才是决定设计产品架构成败的重要因素。

所谓边界，包含三个维度：

1. 任务边界：这个任务是否有明确的对错标准？是“确定性输出”还是“启发式探索”？
2. 时延边界：业务能容忍多长的等待？1 秒（实时交互）、30 秒（异步任务）还是数分钟？
3. 执行权限边界：系统只需要“说”（信息输出），还是需要“做”（调用 API、修改数据库、触发物流）？

如果你用一个高自主性的 Agent 去解决一个只需要 RAG（检索增强生成）就能回答的 FAQ 任务，你不仅是在浪费昂贵的 Token，更是把一个原本确定的流程引入了不必要的不确定性。 Anthropic 工程团队在梳理大量客户实践后，得出了一个非常直接的建议：：找到能解决问题的最简方案，只在真正需要时才增加复杂度³。

乐高积木：Agent 系统的四大基础组件

在讨论不同层级的架构之前，我们需要统一对“积木”的认知。无论系统多么复杂，它们本质上都由以下四个组件构成。理解这些组件，才能理解为什么架构会发生演进：

• 推理核心 (LLM Brain)：系统的“大脑”，负责根据上下文做出决策。
• 规划能力 (Planning)：将目标拆解为步骤的能力。在低层级中，规划是硬编码的；在高层级中，规划由模型动态生成。
• 记忆机制 (Memory)：包含短期上下文（对话历史）和长期知识（RAG 向量库）。
• 工具空间 (Action Space)：系统能调用的外部能力（API、代码解释器、ERP 接口等）。

上面的这四个组件其实也属于一些主流对于 AI agent 的整体定义。在某些业务场景里，我们并不需要使用一个完整的 agent，只需要利用部分的组件就可以达到了。这就是为什么我们需要理解不同边界和架构的重要性。

另外，以前我们会重点关注 LLM 的能力（大脑能力），最近大家的关注点不再是单纯强调 LLM 的能力，而是在利用好 LLM 的情况下，如何让其发挥最大的功效。包括从以前的 Prompt Engineering到 Context Engineering，再到现在的 Harness Engineering，本质上都是在不断地利用好现在的 LLM 能力。

因此，这系列的文章不是在讨论一个不同的 LLM 能力如何去构建产品，而是讨论如何去选择好合适的架构，从而利用好 LLM。当系统拥有了”做事”的能力之后，问题就不再只是能力本身，而是——你如何限制它在什么范围内做事。这也是”边界”这个词贯穿整个系列的原因。

全景地图：从 LLM 应用到 AI Agent 的架构谱系

LLM 和 AI Agent 作为产品实现功效的主体，接下来使用“边界”的视角来区分不同的架构来使用它们。下面这套框架将作为整个系列的基础参照。分类的核心维度是 LLM 在系统中的自主性程度：从被动响应，到主动决策，再到自主探索。

追加几个补充说明：

• 这个谱系涵盖了从简单 LLM 应用到完整 AI Agent 的完整范围。L1/L2 是 LLM 驱动的工作流，流程由外部代码控制，LLM 作为一个能力组件被嵌入；L3 起，LLM 开始主导自身的执行路径，这才是 Agent 行为的起点。³ 框架把 L1/L2 包含进来，是因为很多场景下它们才是正确答案——“需不需要 Agent”本身就是第一个要判断的问题。
• L1–L5 架构谱系框架，是作者基于学习和工程实践归纳的分析工具，并非行业统一标准。后续每篇将对单个层级做独立的深度拆解。
• L4 的内部可以包含 L1–L3：层级描述的是系统的整体编排复杂度，不是单一组件的能力。一个 L4 系统的子 Agent，本身可以是 L3 的实现。

L1-L5 架构全景图 （以电商客户服务系统为例）

为了直观和方便理解 L1–L5 五个等级，我们以一个 “电商客户服务系统” 的演进作为类比：

L1：基础响应者（被动生成）

• 架构：Prompt + RAG
• 角色：知识库搬运工。
• 客服类比：用户问“退货政策是什么？”，系统从文档中检索出条款并回答。
• 特点：流程高度可控，LLM 只负责翻译和润色。

L2：路由分发者（分类触发）

• 架构：Intent Classification + Router
• 角色：分诊台。
• 客服类比：判断用户意图是“投诉”还是“询问进度”，如果是投诉，则触发固定的投诉处理脚本。
• 特点：利用 LLM 的语义理解能力来做决策，但后续执行路径依然是预设的。

L3：工具执行者（主动规划）—— Agent 的起点

• 架构：Function Calling / Tool Use
• 角色：熟练操作员。
• 客服类比：用户说“帮我查一下我的快递到哪了”。系统意识到需要调用get_shipping_status接口，自主提取单号并输出结果。
• 特点：LLM 开始决定执行路径。 它知道什么时候该用工具，什么时候该说话。

L4：协同编排者（主动协调）

• 架构：Multi-agent / Orchestrator
• 角色：项目经理/数字员工团队。
• 客服类比：用户要求“我要退货，但我弄丢了发票”。此时 L4 系统会启动一个“财务 Agent”核实流水，同时启动“物流 Agent”安排上门，最后由“主管 Agent”汇总结论。
• 特点：任务可以并行、拆解并由多个子 Agent 协作完成。

L5：自主探索者（自我进化）

• 架构：Goal-oriented / Recursive Self-Correction
• 角色：初级专家。
• 客服类比：面临一个从未出现过的异常退款案例，系统能自主分析日志、查找类似案例、甚至临时编写一段数据清理脚本来解决问题。
• 特点：目前多处于实验阶段，工程化风险高。

两个关键视角：自主性 vs. 架构

关于这些架构和边界，我们应该如何进行区分呢？我们需要利用两个非常关键的视角.

在实际决策中，你需要区分两件独立的事情：

1. 自主性等级 (Autonomy Level)：决定的是“系统可以被放手到什么程度”（即上述 L1-L5）。
2. 系统架构 (System Architecture)：决定的是“系统靠什么方式运转”（单 Agent 还是多 Agent）。

这两者并不是死绑定的。 一个 L4 级的复杂多 Agent 架构，可以被设计成“每一步都需要人工审核”的低自主模式；同样，一个简单的 L3 单 Agent，也可以在某些闭环场景里实现 100% 自主运行。

先选场景（定等级），再选架构（定拼法）。 很多项目走偏的起点，就是为了用 Multi-agent 这种时髦架构，强行把一个 L2 级的路由任务搞复杂了。

三个问题，帮你在谱系中定位

结合边界的维度以及上述的层级架构，我们可以在这里简单地把”业务边界”具体化为三个判断问题：

问题一：任务有没有明确的”对/错”？

问题二：能容忍多长的响应时延？

问题三：系统需不需要”真的去做事”？

快速过滤逻辑：

这个系列接下来会做什么

在后续每一篇文章里，我会沿着同一条线往下拆：

• 这个层级的典型系统长什么样
• 在什么业务场景下，它是”刚刚好”的选择
• 常见的设计误区在哪里
• 如何建立必要的边界，而不是一味增强能力

你可以用这些内容来评估一个正在做的项目，判断一个方案是不是被”设计过头”，或者回答那个最常见的问题：

「这个需求，真的需要做成一个 Agent 吗？」

AI 系统的开发，已经从”调 Prompt”变成了一种工程系统设计。在我接触的项目里，真正能稳定落地的方案，往往不是最”聪明”的，而是那些在边界内可控、可维护、能长期运行的系统。

目标其实很简单：不是做一个无所不能的系统，而是做一个在业务里能长期运行的那个系统。