企业 Agent 为什么难？看懂 Skill Routing、Registry 与 MCP 全链路

企业 Agent 的本质，从来不是让模型回答问题，而是让模型 理解任务 ，并 调用企业能力完成工作 。

最近半年我看了不下五十个所谓的“企业 AI Agent”项目，说实话， 九成以上本质上就是一个套了系统提示词的聊天窗口 。用户输入问题，模型输出答案，中间隔着一层“角色扮演”的皮。这种东西放在 Demo 里演示效果很炸裂，一旦拿去接真实业务，基本上三天就会露馅。

很多人对 Agent 的理解还停留在“大模型 + Prompt + 聊天窗口”这个层面。这个思路在 C 端闲聊场景没什么问题，但真正进入企业场景后就会发现远远不够。一个能在业务里跑起来的 Agent， 至少要做到四件事 ：理解业务意图、调用企业内部能力、控制权限和数据边界、处理复杂任务的编排。这四件事， 没有一件是靠“调 Prompt”就能解决的 。

我见过最典型的翻车场景是这样的：某零售企业上线了一个“智能客服 Agent”，用户问一句“帮我把这个订单取消掉”，Agent 一本正经地回复了一段取消订单的操作指南——它以为自己在做知识问答，完全不知道这是一个需要真正执行的动作。这不是模型能力不行，是 架构从一开始就想错了 。

所以我一直强调一个判断：企业 Agent 的本质，是从“让模型回答问题”，变成“ 让模型理解任务，并调用企业能力完成工作 ”。这个转变背后，对应的是一整套闭环——用户提出需求，Agent 理解，路由到合适的技能，调用能力执行，整合结果，反馈给用户。这也是 AI Agent 从 Demo 走向生产系统的分水岭 。今天这篇文章，就想把这套闭环拆开，一层一层讲清楚。

📌 本文看点

举个例子会更直观。假设用户对 Agent 说：

这句话看着简单，但背后要走的流程 一点都不简单 。系统大致要经历这几步：接住这句话，搞清楚用户到底想干嘛，判断需要调用哪些能力，去技能库里找到对应的模块，检查这个技能能不能用、这个用户有没有权限用，把当前会话的上下文和业务背景装进去，真正执行任务，中途可能要调用外部系统拿数据，把拿回来的原始数据整理成结构化结果， 最后汇总成一份完整的答复丢给用户 。

这一整套流程走下来，涉及的角色大致 可以分成七层 ：用户层负责发起请求；Agent 层负责理解和调度；技能路由层负责匹配能力；技能注册表负责管理“有哪些能力可用”；上下文层负责让同一个技能“因人而异”；执行层负责真正把事情办成；外部服务层则是企业已有的那些系统——ERP、CRM、数据仓库等等。下面我按几个关键阶段拆开讲，每个阶段我会说说自己踩过的坑，以及 一些不太主流但我认为很重要的判断 。

很多人低估了“意图理解”这一环的难度。业务场景里的语言 远比想象中模糊 。

这句话里藏着好几层信息：意图是“归因分析”，范围是“华东区域”，指标是“销售额”，隐含的时间维度可能是“最近一个周期”。如果 Agent 只做了字面意义上的关键词提取， 大概率会给出一份文不对题的分析 。

我一直坚持一个观点——

很多团队把它简化成“这句话属于哪个意图类别”，这在客服场景里也许够用，但在业务场景里远远不够。真正靠谱的做法，是 把一句自然语言拆解成结构化的任务描述 ——目标是什么，涉及哪些实体，有没有隐含的约束条件。这一步做得糙，后面所有环节都是 在错误的地基上盖楼 。

再举个例子，“帮我安排明天下午上海客户会议”这句话，拆出来至少要包含：意图（会议安排）、时间（明天下午）、地点（上海）、对象（客户）。 任何一个信息漏掉 ，后面调用日程工具的时候都可能出错——要么时间冲突没提示，要么地点信息缺失导致会议室预定失败。这种细节问题，在演示环境里几乎不会暴露， 一到真实业务量就全暴露了 。

企业内部能力非常多——CRM 查询、ERP 操作、数据分析、邮件发送、文档生成、流程审批，随便一数就是几十上百种。很多团队做到这一步会图省事，把所有能力的描述 一股脑塞进系统提示词里 ，让模型自己去“选”该调用哪个工具。当技能数量在十个以内的时候，这么干还凑合；一旦技能库涨到几十上百个， 这套做法基本就废了 ——上下文塞不下，模型选择也开始变得不稳定，今天选对了，明天换个说法就选错。

所以真正成熟的架构里，一定会单独拎出一个技能路由层，做的事情类似于一个内部的“专家推荐系统”。这个过程一般拆成三步：第一步是 技能匹配 ，根据用户意图、任务目标和 Skill 描述，找出候选技能；第二步是 技能排序 ，在候选里挑出最相关、调用成本最低、权限又允许的那一个；第三步是 生成执行计划 ，决定调用顺序、参数怎么传、数据之间有什么依赖关系。

这里我想强调一个容易被忽视的点：技能路由不是一次性决策，而是要考虑 技能之间的依赖顺序 。比如“生成销售报告”这个任务，可能要先调用“数据查询”技能拿到原始数据，再调用“数据分析”技能做加工，最后调用“文档生成”技能出成品。如果路由层只做单点匹配，不考虑这种链式依赖，执行的时候大概率会卡壳或者顺序错乱。这也是为什么我一直认为， 路由层的设计水平，基本决定了一个 Agent 系统能不能撑住复杂任务 。

技能一多，管理成本就会指数级上升。我见过一家公司做到后期技能库有小两千个，压根没有做统一注册管理， 靠着一份 Excel 手工维护 ——谁在用、版本改没改、依赖了哪些接口，全靠人脑记。

技能注册表这一层，说白了就是给整个 Skill 生态建一套 “身份证系统” 。核心能力大致有三块：一是技能注册，记录每个技能叫什么名字、干什么用的、需要什么输入、会返回什么输出；二是技能发现，帮 Agent 找到能力、理解能力、选择能力；三是 可用性校验和生命周期管理 ，检查技能状态、版本兼容性、依赖关系，并且负责发布、更新、下线的全过程。

这一步看起来最不“性感”，没有意图识别听起来智能，也没有执行层看起来直接产生价值，但恰恰是 决定整套系统能不能长期稳定运行的地基 。我个人的经验是，团队但凡在这一层偷懒，后期维护成本一定会成倍反弹。这不是“锦上添花”的工程能力，是 “必须有”的基础设施 。

这一步我想多说几句，因为这是我判断一个 Agent 项目“是不是真的懂企业”的 核心标准之一 。

对话式 AI 最多是回答错了让人不舒服，顶多算体验问题。但一个能执行动作的 Agent 一旦权限没控制住， 后果是实打实的 ——删错数据、下错订单、把不该看到的财务信息透出去，这些都不是“优化一下体验”能补救的。所以企业 Agent 面对的最大挑战，从来不是“回答得准不准”，而是 “谁，可以，执行什么”这三个字要死死卡住 。

企业级的权限校验至少 要拆成三层 ：用户权限，判断这个人是否有访问资格（比如实习生能不能审批采购单）；Skill 权限，判断这个技能是否允许被这类用户调用；数据权限，判断最终能看到的数据范围有多大——同样是查销售数据，销售经理只能看自己团队，区域总监能看全区域。这 三层缺一不可 ，很多团队图快，只做了用户鉴权这一层，技能权限和数据权限完全没有拆开设计，结果就是“有权限用这个功能”和“能看到不该看的数据”混在一起，埋了个安全隐患进去自己都不知道。

说句实话，这一环也是最容易被业务方忽略、被技术团队嫌麻烦的一环，因为它不产生“看得见”的体验提升。但恰恰是这一环，决定了这套系统 敢不敢真的接入生产环境 、敢不敢让它碰真实数据和真实业务动作。我见过太多项目卡在这一步——不是技术做不出来，是压根没人重视， 直到出了一次安全事故才回头补课 。

同一个技能，喂给不同的人，应该给出不同的结果。这句话听起来是句正确的废话，但 真做起来很容易被忽略 。

举个例子：查询销售数据这个技能，销售经理调用，应该看到的是自己团队的执行明细；CEO 调用，应该看到的是公司层面的战略趋势和同比环比。如果技能本身不感知调用者是谁、当前处于什么业务场景、之前聊过什么，那它输出的永远是一份 “通用版”结果 ， 没法真正贴合业务需求 。

上下文这块，我建议至少拆成三类去构建：一是 用户上下文 ，包括身份、角色、历史行为；二是 业务上下文 ，包括当前任务进展到哪一步、历史对话里提到的条件要不要延续；三是 企业知识上下文 ，包括相关的文档、数据、业务规则。这三类信息拼起来，才能让同一个技能在不同场景下“表现得不一样”。

很多团队在这块只做了最基础的“记住上一句话”，连简单的多轮对话都经常掉上下文，更别提结合用户角色和企业知识去动态调整了。这也是为什么很多 Agent 用几次就会让人觉得“很傻”，不是模型笨，是 上下文这层根本没搭起来 。

前面所有环节，其实都是在为这一步做铺垫。技能真正执行的时候，要做的是 调用具体的业务逻辑 ，可能是查一次数据仓库，可能是调一次 CRM 接口，也可能是触发一次 OA 审批流程。比如一个销售分析 Skill，执行的时候往往要同时对接数据仓库、BI 系统、CRM 好几个系统。

企业 Agent 通常需要连接的外部系统很杂——ERP、CRM、OA、数据库、各种 SaaS 平台。现在业界比较主流的做法，是通过 标准化的工具调用协议 去接这些系统，不管是自研的 API 网关，还是最近很火的 MCP 协议， 核心思路是一致的 ：把企业里五花八门的老系统，用一套统一的方式暴露给 Agent 去调用，而不是每接一个系统就单独写一套定制逻辑。这个抽象层做得好不好，直接决定了后期新增一个业务系统接入 Agent 的成本是“一天”还是“两周”。

外部服务处理完请求、返回结果之后，还需要一道 “结果解析”的工序 ，把返回的一堆结构化甚至半结构化数据，统一整理成后续可以直接使用的格式。这一步经常被简化甚至省略，直接导致后面生成回复的时候东拼西凑，答非所问。

最后一步是把执行结果整合成用户能理解的东西，这一步的 重要性经常被低估 。

设想一下，技能执行完返回的是这样一坨数据： { revenue: 123456, growth: -8% } 。用户想知道的 从来不是这两个数字 ，而是“为什么下降了，接下来该怎么办”。如果 Agent 直接把这坨 JSON 转成大白话念一遍，那和一个只会念数据的播报机器没什么区别。

真正的结果整合，是要在数据的基础上 做解释、做归因、给建议 ，最终输出的应该是自然语言 + 图表 + 文件 + 操作结果的组合，而不是单纯的“文字转述”。这一步做得好不好，是普通用户唯一能直接感知到的部分——前面六步做得再扎实，如果这一步输出得又生硬又啰嗦，用户体感照样很差。所以我一直认为，这最后一环虽然排在最末尾，但恰恰是 决定产品口碑的临门一脚 ，值得投入不亚于前面任何一环的精力去打磨。

回过头看这一整套链路，本质上是 从“聊天机器人”升级到“业务执行系统” 的过程。传统 ChatBot 干的事是回答问题，而 AI Agent 干的事是 理解任务、调用能力、完成工作 ——这是两种完全不同量级的产品形态。

支撑这套升级的，是 四种核心能力 ：意图识别负责理解用户真正的需求；智能路由负责匹配最合适的技能，避免“大而全”的单体设计；权限控制负责保障企业级的安全合规；上下文感知负责让每一次执行都尽可能贴合具体的人和场景。这四个能力叠加起来，才能撑出一个结果闭环—— 稳定、可靠、并且全程可追溯 。

再往深一层看，这套架构真正的价值其实是 工程层面的 ：模块解耦让每个技能可以独立开发、独立迭代，不会牵一发动全身；技能复用让研发效率大幅提升，不用每接一个新场景就重新造轮子；安全可控是企业级落地的前提，没有这个，再智能的 Agent 也进不了生产环境； 全链路可观测 ，则决定了系统出问题的时候能不能被快速定位和修复，这对长期运维至关重要。

我个人的判断是：未来企业 AI 之间比拼的，不会是谁的底座模型参数更大，而是谁的 Skill 生态更完整、调度更精准、执行更稳 。模型这两年进步很快，底座之间的差距在肉眼可见地缩小，但企业沉淀下来的业务能力封装，才是 真正带不走的护城河 。

说到底，这件事情可以浓缩成一句话：

大模型负责思考，Skill 负责行动。

谁能把更丰富的 Skill、更完善的工具生态、更强的业务连接能力沉淀下来，谁就能在这一轮企业 AI 落地里 占到真正的先机 。

企业 Agent 的落地，本质是一套新的软件架构。它连接的是大模型的智能、企业已有的业务系统、外部工具能力、沉淀下来的数据资产，还有一整套权限体系—— 缺了任何一块，都撑不起“企业级”这三个字 。

回过头看这一整套链路，会发现一个挺有意思的现象：真正决定一个企业 Agent 能不能用的，往往不是那些听起来最“AI”的环节，比如意图识别、自然语言理解，而是那些 听起来最“工程”的环节 ——权限校验、技能注册管理、结果解析这些又枯燥又不容易被外行看懂价值的部分。真正成熟的 Agent，从来不是一个会聊天的机器人，而是一套能够理解业务、调用能力、完成任务的 智能执行系统 。

所以下次再看到一个宣称自己是“企业级 Agent”的产品，不妨多问一句：它的技能库怎么管理的？权限控制拆了几层？上下文怎么构建的？如果这几个问题对方答不上来，那大概率， 它还只是一个套了壳的聊天机器人 。

你在实际项目里遇到过哪些 Skill 调用的坑？欢迎在评论区聊聊。