Sherconan.

· 16 min read · AI Agent · Enterprise AI · Architecture · Anthropic · MCP

从 0 到 1 设计企业 AI Agent 架构：双层结构 × 五模式 × 1/3 员工日活的关键 5 步

一份"内部 AI 产品如何做到 1/3 员工日活"的产品架构复盘。覆盖认知层 + 执行层双层结构设计、对照 Anthropic Building Effective Agents 的五种 Pattern、以及从 demo 到产品的关键决策。

内部 AI 产品最大的失败模式不是技术不行，而是做出来没人用。一个能让 1/3 员工日常使用的企业 AI 平台，靠的不是模型选得多好，是架构层的几个底层决策。

TL;DR

  • 企业 AI 平台的底层架构应当是双层结构：认知层（Cognition Layer） 整合非结构化知识 + 执行层（Execution Layer） 暴露后台系统为 callable tools。
  • Agent 的设计模式可以严格对照 Anthropic 《Building Effective Agents》的五种 Pattern：Prompt Chaining · Routing · Orchestrator-Workers · Evaluator-Optimizer · Tool-Use Agent。这五种覆盖 90% 的真实场景。
  • 从 0 到 1/3 员工日活的关键不在”模型多强”——是 5 个产品决策：入口贴到日常工作流 · 第一次成功体验 · 数据闭环 · 内推机制 · Eval 驱动迭代。
  • MCP（Model Context Protocol）是把”执行层”标准化的关键基建——别再造私有协议轮子。

一、双层结构：Cognition Layer + Execution Layer

我做企业 AI 平台 5 年里最大的认知升级，是把”做一个 AI 产品”切换为”做一套 AI 能力底座”。

底座的形状是双层：

认知层 · Cognition Layer

把企业里散落在邮箱、企微 / 飞书、内部文档、协同工具、CRM、Wiki 里的非结构化知识整合成一个面向人 / 团队的”知识上下文”。

技术形态通常是 RAG + Tool Use 的混合：

  • Vector DB（embedding 检索）+ BM25 / 关键词（精确匹配）+ Reranker（top-k 重排）
  • 跨多个 connector（邮箱 / IM / 文档系统 / 协同工具）
  • 安全层（行级权限、最小可见性、审计日志）

为什么是底座而不是产品：因为认知层一旦做好，所有上层 AI 产品都能复用——投研助手、内部 FAQ、合规审查、HR 问答……每个上层场景都不需要自己重新做 RAG。

执行层 · Execution Layer

把企业各类后台系统（OA / CRM / 内部 API / 数据库 / 工单系统）以 tool-use 的形式暴露给 LLM，让 Agent 可以真正执行任务——不只是回答问题。

技术形态：

  • 每个内部系统包装成一个或多个 tool function
  • 用 MCP（Model Context Protocol） 做协议标准化（详见后文）
  • 加入鉴权、审计、回滚、人工兜底（高风险操作必须 human-in-loop）

为什么是底座：执行层做好以后，AI 产品可以从”问答”升级到”代我做”——这是企业 AI 真正的价值跃迁点。

双层的产品形态

┌─────────────────────────────────────────────────────┐
│             AI Products / Chatbot / Agents          │
│  (智能投研  ·  智能审核  ·  内部 FAQ  ·  合规审查 ...)│
├──────────────────────────┬──────────────────────────┤
│   认知层 · Cognition     │   执行层 · Execution     │
│   ─────────────────      │   ─────────────────      │
│   邮箱 · IM · 文档       │   OA · CRM · DB · API    │
│   Wiki · CRM · 协同      │   工单 · 审批 · 数据看板 │
│   RAG · Reranker · 权限  │   MCP · Tool · Audit     │
└──────────────────────────┴──────────────────────────┘

二、对照 Anthropic 的五种 Agent Pattern

Anthropic 的《Building Effective Agents》一文把 Agent 设计抽象为 5 个 Pattern。我把它们映射到企业场景：

Pattern 1 · Prompt Chaining

把任务拆成一串顺序步骤，每步一个 LLM 调用。

典型场景：合规审查（先抽取 → 再分类 → 再判定 → 再生成报告）。

坑：链路越长越容易在某一环放大错误。每个 step 之间加 deterministic gate。

Pattern 2 · Routing

按 query 类型路由到不同的 sub-pipeline。

典型场景：内部 Chatbot 入口分流——FAQ 问题走轻量检索；专业分析走重 RAG + 强模型；工具调用走执行层。

关键：Router 自己也是个 LLM，需要单独的 Eval 集（详见上一篇博客《Multi-Model Routing 决策框架》）。

Pattern 3 · Orchestrator-Workers

一个 orchestrator LLM 决定要做什么，调度 N 个 worker LLM 并行执行。

典型场景：研报智能体——orchestrator 拆解”分析 X 公司”为”找财报 / 找新闻 / 找估值数据”，并行交给三个 worker，再汇总。

关键：orchestrator 必须有明确的任务图（DAG），不要让它自由发挥。

Pattern 4 · Evaluator-Optimizer

一个 LLM 生成、另一个 LLM 评判、循环优化。

典型场景：合规审核——生成模型写初稿，评判模型按规则打分，不通过就重写。

关键：评判模型必须比生成模型强或同强（详见博客 1）。

Pattern 5 · Tool-Use Agent（自主 Agent）

LLM 自主决定下一步用哪个 tool、什么时候停。

典型场景：客户查询——LLM 自己决定先查 CRM 还是先查工单还是先 RAG。

关键：必须有明确的 stop condition 和 max-turn 限制——否则会陷入死循环或无限调用。同时 high-risk 操作必须 human-in-loop。

三、从 0 到 1/3 员工日活：关键 5 步

技术架构再漂亮，没人用也是 0。我把”内部 AI 产品做到 1/3 员工日活”这件事拆成 5 个产品决策：

1. 入口贴到日常工作流（不是单独建一个 App）

最常见的反模式：开一个独立的 web app，要求员工”先登录这里再用”。99% 的员工不会主动来。

正确做法：贴到现有的高频入口——

  • 飞书 / 企微的 Bot
  • IDE 插件
  • 浏览器 Sidebar
  • 邮件签名 / 日历活动 deep link

核心信念：AI 应该出现在用户已经在的地方，不是要求用户来 AI 在的地方。

2. 第一次成功体验（First Successful Use）

新用户第一次用产品的体验决定了 70% 的留存。我们做了几件事：

  • 首次启动有 1 个明确的成功 demo（不是”什么都能问”）——比如”试试问我：上季度某个产品的销售数据”。
  • 第一次回答必须 < 5 秒返回（否则用户走了）。
  • 第一次回答必须有引用 / 来源（否则用户不信）。

3. 数据闭环（用户行为 → 产品迭代）

每个交互埋点必须落到 dashboard：

  • 提问数量 / 回答采纳率 / thumbs up/down
  • Bad case 自动归类（详见博客 1）
  • 用户分群分析（哪个部门用得多、用什么场景多）

用户行为是唯一可信的产品反馈——比任何 user research 都直接。

4. 内推机制（Champion 用户 → 部门扩散）

不要做”全公司大推广”。先找 5-10 个 champion 用户（早期高频用户），把他们的使用 case 包装成内部分享：

  • 一对一深聊——他们怎么用、解决了什么、有什么不爽
  • 把他们的 case 拍成 90 秒视频在公司大群发
  • 让 champion 在自己部门做内部分享（你出题目，他出讲）

冷启动靠 5 个 champion，不是靠 5,000 张 banner。

5. Eval 驱动迭代（不靠拍脑袋）

每周 review 一次 Eval 数据 + Bad case 分类（见博客 1）：

  • 哪类失败模式占比上升？→ 下周优化重点
  • 哪个新场景流量起来？→ 加 Eval case
  • 哪个旧场景留存下降？→ 看是不是模型 / Prompt / Retrieval 退化

四、为什么 MCP 值得拥抱

MCP（Model Context Protocol）是 Anthropic 在 2024 年发布的开放协议，把 “LLM ↔ 工具 / 数据源” 的连接标准化。

为什么对企业 AI Agent 关键：

  • 你内部有 N 个系统（OA / CRM / DB…），每个都给 Agent 一个 tool 接口——用 MCP 就不用为每家 LLM 厂商重新写一遍 adapter。
  • 标准化的好处是复用：今天用 Claude，明天换 GPT，后天加 DeepSeek，工具层不用改。
  • 生态在快速起来——MCP server 的社区实现已经覆盖 200+ 系统（GitHub / Slack / Postgres / Notion …）。

给 PM 的决策：新建 Agent 项目时，优先考虑用 MCP 接工具。 别再造私有协议轮子。

五、回到原点：架构服务于产品

写这篇之前我自己问过一个问题——这套架构和方法论到底是不是过度设计？

答案是：对小公司、小场景、demo 阶段确实过度。但对一个有 10K+ 员工、跨业务线、要做到日活的企业 AI 平台，这套架构是底线。

底层逻辑就一句话——复用 + 健壮 + 可演进：

  • 复用：双层底座让上层产品共享一份知识 + 一份工具，避免每个场景重做轮子。
  • 健壮：多模型 Routing + Fallback + Cost Cap 让单点故障不炸。
  • 可演进：MCP 等标准协议让你换模型不换工具、加场景不重构底座。

后记

这是 AI Builder 系列三篇文章的最后一篇：

  1. 《从 0 到 1 构建企业级 LLM Eval 集》
  2. 《企业 AI 的 Multi-Model Routing 决策框架》
  3. 《从 0 到 1 设计企业 AI Agent 架构》（本文）

如果你也在做企业 AI / AI Agent 产品，欢迎交流——

GitHub：github.com/sherconan 邮件：shinyashokudo@163.com WeekendGo Live Demo：sherconan.github.io/weekend-go

—— 刘鹏洋 · AI Builder · AI Product Manager · 北京

← 全部文章