通用 Agent vs 垂直 Agent

只讲四件事：分别是什么 → 各自的架构 → 区别和联系 → 怎么选。

配图目录：./流程图/通用Agent与Skill架构/

---

一、分别是什么

1. 垂直 Agent

面向一个具体场景打造的 Agent。一个 Agent 只干一类事。

日志排查 Agent
订单异常排查 Agent
SQL 分析 Agent
客服 Agent
代码审查 Agent

它的业务知识、Workflow、Tools、Prompt、领域规则，都是为这一个场景定制的。

2. 通用 Agent

不绑定具体场景，接收自然语言目标，自己判断该用什么能力。

例如用户说：

帮我分析一下这个订单为什么失败

它自己决定：

查订单 → 查支付 → 查日志 → 需要时查数据库 → 汇总结论

它的能力不是写死在代码里，而是通过 Skill（方法）+ Tool / MCP（能力） 挂进来。

3. 一句话对比

垂直 Agent：一个 Agent → 一个场景
通用 Agent：一个 Agent → 多个场景

---

二、各自的架构

1. 垂直 Agent 的架构

PNG 备用文件：01_垂直Agent完整组成.png

一个能上生产的垂直 Agent，是一整套系统，不只写个 Prompt 挂几个 Tool：

接入与会话    渠道、鉴权、多租户、多模态解析
理解          意图识别、槽位抽取、Query 改写、路由
编排          ReAct / Planner / Workflow / LangGraph / Multi-Agent
模型          主 LLM、推理模型、小模型、Embedding、Rerank
知识与记忆    RAG 检索、向量库、短期与长期记忆、State / Checkpoint
执行能力      Tools、Tool Registry、MCP、沙箱与 Subagent
--------------------------------------------------------------
横切（每层都要）护栏、评测、可观测 Tracing、权限、Prompt 版本
底座          LangChain（组件） / LangGraph（Runtime） / LangSmith（工程）

三个容易混的点：

LangChain 不是 Agent，是组件库与胶水层
LangGraph 不是 Prompt 框架，是运行时（状态 / 循环 / 断点）
ReAct、RAG、意图识别 都是其中的一个环节或能力，不是整套 Agent

关键点：这一整摞是为一个场景搭的。换个场景，要从头再来一遍。

2. 通用 Agent + Skill 的架构

PNG 备用文件：02_Skill架构与渐进式披露.png

通用 Agent（统一 Runtime）
├── System Prompt + Agent Loop
├── 记忆、权限、工具调用
└── Skill 目录（常驻的只有 name + description）
          ↓ 命中才加载
       SKILL.md 正文（流程 / 注意事项 / 输出规范）
          ↓ 用到才读
       references / scripts / assets
          ↑
   MCP Tool 池（共享的 API / SQL / 第三方能力）

核心是三层渐进式披露：

L1 目录层     只放 name + description，几百个 Skill 也只占几百行
L2 指令层     命中后加载 SKILL.md 正文
L3 资源层     正文指到哪才读哪（长文档 / 脚本 / 模板）

三个关键认识：

Skill 不是运行时：跑的仍然是 Agent Runtime，Skill 只注入「方法」
Skill 不是 Tool：Tool 负责执行，Skill 负责「怎么做」
description 是 Skill 的接口：写得像触发条件才会被选中

关键点：新增一个场景，加的是一份 Markdown，不是一个新服务。

---

三、区别和联系

1. 区别

PNG 备用文件：03_垂直Agent与通用Agent对比.png

结构上的差别：

垂直 Agent：场景 → 服务（N 个场景 = N 套完整系统，重复建设）
通用 Agent + Skill：场景 → Skill（1 套运行时 + N 份方法包）

维度	垂直 Agent	通用 Agent + Skill
能力复用	各写一套，跨场景复制粘贴	一个 Skill 全局复用，Tool / MCP 共享
新增场景	新建服务 + 开发上线，按周计	加一个 SKILL.md 目录，按小时计
确定性	流程写死，路径可预测	模型临场决策，靠 Skill 与约束兜底
可观测	链路短，容易复现	决策链长，要靠 Tracing
权限隔离	按服务天然隔离	共用运行时，要额外设计
评测	场景窄，用例集好建	场景宽，评测难覆盖
领域深度	能单场景做极深优化	受通用流程限制，深度优化更难
成本结构	每个 Agent 都有决策与运维成本	运行时共享，边际成本低
失败影响面	单场景，可控	可能跨场景放大（选错 / 串味 / 越权）
适合	高频、确定、强合规、强审计	长尾、多变、跨系统、快速试错

2. 联系

它们不是替代关系，是同一套能力的不同组织方式。

垂直 Agent 里的 Workflow / Prompt / 规则  →  抽出来就是 Skill
两边都要用的 Tool / MCP                   →  本来就是同一批共享能力
通用 Agent 的 Skill 库                    →  大多是从垂直 Agent 沉淀下来的经验

一句话：

垂直 Agent = 把流程固化在代码里
通用 Agent + Skill = 把方法沉淀成资产

所以趋势不是「通用 Agent 消灭垂直 Agent」，而是：

轻量场景（几个 API + 一套流程 + 一套 Prompt） → 被通用 Agent + Skill 吸收
重领域（医疗、金融、工业、复杂审批）           → 继续保留垂直形态

---

四、怎么选

1. 判断标准

选垂直 Agent / Workflow：
   高频主链路
   路径确定、可预期
   强合规、强审计、要留痕
   性能和成本敏感，要承诺 SLA
   领域逻辑很深，需要极致调优

选通用 Agent + Skill：
   长尾场景、需求多变
   要跨多个系统取数
   探索性任务，流程事先说不清
   需要快速接新场景、快速试错

2. 推荐的混合形态

通用 Agent   统一入口：理解意图、选能力、做编排、兜底
Skill        领域方法：流程、规范、输出格式
Workflow     关键路径：高频确定的流程下沉成固定流程
Tool / MCP   执行能力：标准化、可复用、可授权

一个通用 Agent 做入口
  → 命中 Skill，拿到「怎么做」
  → 关键路径交给确定性 Workflow
  → 需要外部能力时走 MCP Tool

3. 一句话记住

Agent 做大脑，Skill 做方法，Workflow 做脊柱，Tool 做手脚，MCP 做神经。