在面试的时候, 你要是把 Skill 这个概念说成是给 Agent 加上某种能力, 又把 MCP 解释成去调用外部的工具, 这么回答确实不算错。

但是, 如果你只是停在这个层面, 没有进一步深入的话, 就会漏掉一个非常关键的问题点。那就是到底是谁来专门规定这些任务具体的执行步骤, 而又是谁负责去严格地守住权限的边界呢?

这里有一个直截了当的结论, 那就是, Skill 这个东西负责把工作流里的知识给包裹起来。 另一方面呢, MCP 是干标准化这事儿的, 它用来把那些受到控制的能力给接入进来。

至于说 Skill 能不能授予能力这个问题, 答案是否定的, 它能够对这些能力做出选择动作, 但是绝对不可能去授予这些能力本身。

先用一张表答清边界

维度

Skill

MCP

核心职责

你要去告诉那个叫做Agent的东西, 它是怎么样才可以把某一类任务给做好的。

得使得那个Host/能够自己去把那个能力给发现到, 而且还要去把这个能力进行调用, 这是必须要做到的一种状态。

主要内容

关于那个名为SKILL.md的文件里面的具体指令内容, 我们目前来看一看。

包括Tools, 以及对于协议消息还有能力进行协商。

典型问题

在进行那个工单升级的动作之前, 需要核对一些具体的字段内容, 同时也需要搞清楚在什么时候停下来。

关于要怎样去查询工单, 需要把升级的情况提交上去, 并且参数具体是什么样子?

加载方式

目录描述这一块主要是用来做发现工作的, 一旦成功命中之后, 就要去读取相应的指令以及按需提供的资源。

在初始化之后, 去进行协商能力的处理, 紧接着再去一一地列举出来, 并且按照顺序来实施调用操作。

权限含义

这句话是可以对约束进行描述的, 但是它是不能成为那种强制性的授权的。

它可以承担受控调用的入口工作, 不过业务授权这件事情还是必须要由宿主或者相应的实现部分来进行处理。

那就是最合适的产物。

可以变成不同版本的领域过程包。

在多个不同的客户端那边,对于某个外部的系统接口, 实现重复使用。

那个 Agent 把 Skill 定义成了一个目录, 但是这个目录要达到 SKILL.md 这个最低标准才算数；它把东西分成了三个层次来进行渐进式的加载, 第一个层次是名称和描述, 第二个层次是完整的指令, 第三个层次是按需提供的资源。

在那些规范里面提到的内容, 比如相关的配置项什么的, 全部都是为完成任务所用的知识服务的, 而不是说去把每一个外部的 API 都重新书写一遍。

MCP这个体系里面所包含的要点其实是三部分, 这三部分分别是、还有 Tools: 其中那个是用户自己可以选择使用的模板, 而另一个则是应用在进行管理的时候所使用的上下文环境, 最后一个 Tool 就是提供给模型去调用的可以执行的函数。

MCP官方的概览里明确地将这些内容的控制权力进行了区分。把这两者放在一起讨论, 并不是说只能从其中选一个, 而是将流程与能力这两个东西给拆开来看待。

关于一个工单任务, 究竟要如何来进行分工。

这个工单得往上层提, 你那边协助解决一下。

合理的调用链如下：

Skill部分应该明确写明, 第一步先去读, 然后再进行核对, 如果发现缺少信息就停下不继续, 任何操作的书写行为都必须先确认；MCP部分则需要提供例如那些小而明确的Tool。

在两者之间还必须设置一个Host或者策略层, 这个层级的作用是决定该用户在当前的时刻具体能够看到哪些Tool, 并且会把最终的身份信息传递给对应的目标对象。

最小组合, 这一项操作不要将权限给写入进去。

在Skill这一部分当中, 是可以把这样的指令给保留在里面的:

可是“获得到了验证的那个结果”这个话的意思, 是不等于模型它只是说了一句“得到了确认”, 调用层的那些功能需要去把确认的信息, 弄成那种可以被验证的数据, 然后还要在服务端再去重新检查一遍。

def call_escalation(mcp, actor, ticket_id, approval_id):

if not actor.has_scope("ticket:escalate"):

raise PermissionError("scope required")

if not approval_service.valid(approval_id, actor.id, ticket_id):

raise PermissionError("valid approval required")

return mcp.call_tool("request_escalation", {

"ticket_id": ticket_id,

"approval_id": approval_id,

"idempotency_key": f"{ticket_id}:{approval_id}",

})

这里的 MCP 工具, 它有自己的名称, 也有自己的描述内容, 还可以包含输入部分的设置。

任何支持这种工具的地方, 都会在配置文件或者是参数里面去声明这个 tools , 然后客户端那边, 就会去使用那个叫做 tools/list 的东西, 来获取当前所有可用的 Tool 都有哪些, 接着, 它再借助于 tools/call 这个手段, 把具体的调用操作给发起出去。

关于 Tools 的这个规范文件里边的说法是, 它不仅规定了怎么调用, 同时还建议说, 为了安全或者出于其他考虑, 应该为这个工具的后续调用过程提供那么一个人工来进行拒绝确认的机制安排一下。

你要注意的是, 那些专门用来挡住错误形状的参数, 它是没有能力去挡住越权业务意图的, 而对付后面这种越权的情况, 它本来就应该只是授权策略和业务服务的职责所在。

在面试期间, 最经常出现的三种错位情况的第一种, 就是拿 MCP Tool 这种东西, 去把一整条长长的流程步骤进行描述说明。

目前分类、查知识库、补字段、升级的通知操作被封装进了Hing里, 导致整个模型其实只有一个万能入口。这种架构引发的问题是参数数量出现膨胀, 而且步骤是不可见的状态, 当审计部门想要定位到具体是哪一环发生故障时, 会发现根本做不到, 同时也很难给写操作单独进行审批流程。

具体的操作流程需要调整到技能这个位置去。至于MCP工具, 它得保持一种单一的状态, 并且要是那种可以被核实的业务动作, 比如说像是前面提到的一些例子那样。

2. 在 Skill 里放 token、 或“管理员权限”提示

Skill 这个东西, 是容易被发现、读取、复制以及进行版本控制的。如果你把那些凭证或者默认的拥有高权限的东西写进 Skill 里面, 那么就意味着, 原本可以灵活变动的那些流程和知识, 就会一下子变成泄露秘密的通道, 以及越过权限去操作别的系统的一个入口点。

改法是这样的, Skill 这边只去引用能力名和前置条件, Host 在运行的时候注入最小权限身份, 然后每一次调用都要把它和用户还有租户以及 scope 进行绑定。远程的授权流程要涉及到 MCP、授权服务器还有资源服务器这个情况, 是不可以用 Skill 文本代替的, 至于 MCP。

3. 很多人存在这样一种理解上的偏差, 那就是误以为模型在进行选择工具这一操作的时候, 就等同于用户已经给予了动作执行的授权, 这其实并不是一个正确的认知。

我们说做模型选择, 那其实只是一次推理出来的结果而已。

对于那种风险高、要写数据的操作, 必须要要求它有一个独立的确认步骤, 还非得要有服务端的授权才行, 并且还得有那种可以审计的记录保存下来；再退一步讲重试这个事, 它也必须有幂等键这东西撑腰, 要是没有的话, 万一遇到网络超时的这种状况, 很可能就会造成多次升级或者是重复发送的情况发生。

采取读写的分级处理办法, 按照不同的阶段来暴露出工具功能, 将审批的识别码与目标对象进行绑定操作, 实施复核权限的验证动作, 并且对调用的过程链条做出记录工作。

大家经常会有这样的疑问, 那就是关于Skill、MCP 还有 MCP 这三个选项, 应该按照什么样的思路去进行选择?

需求

优先放置

团队在处理工单这一件事儿上, 有着全套的、一连串的操作步骤, 同时还有当事情办砸了时候该停下来的标志, 以及需要根据具体实际情况去查阅的相关资料。

Skill

提供, 由用户明确选择的一段交互模板。

MCP

需要让客户端负责进行管理的工作, 是包含有被注入进去的工单资料, 产品方面的文档, 还有状态内容。

MCP

进行查询或者是实施改变, 来针对外部系统的那个状态进行操作。

MCP Tool

你必须要把那些关于执行的时候需要看什么权限, 还有怎么进行审批, 以及涉及到金额的阈值是多少这样的规则给确定下来。

在服务这头儿的策略, 或者是在业务那部分写的代码。

用一分钟的时间来进行回答。

Skill 和 MCP 之间是互补关系。关于 Skill, 它的主要职责是把领域中积累的经验, 变成可以查找得到、能够逐步加载的工作流。这种工作流规定了在阅读资料时需要关注哪些内容、按照何种逻辑去处理后续步骤, 以及在发生错误的时候应该采取什么样的停止措施。

至于 MCP 的作用, 是用来支持 Host 通过符合标准规范的协议接入某些功能, 并访问 Tools。这里的 Tools 指的是那些受到描述文件所定义的外部运行能力。在当下的具体架构之中, Skill 这一环节已经拿到了被允许的 Tool 的资源权限。

而接下来的 Host 模块, 则会根据具体的用户身份以及所处的流程阶段, 来进行工具层面的过滤操作。同时呢, 策略层配合着 MCP 平台, 会去依次处理身份的核验、租户的划分、权限范围的限定、审批流程的检查、幂等性的保证以及审计日志的记录等工作。

这里有一个非常关键的边界点需要大家清楚注意: 那就是 Skill 发出来的指令虽然能够对模型产生约束作用, 但是它绝对无法替代真正意义上的授权行为；另外还有一种情况也必须明白, 即便 Tool 已经在系统中被发现并可用, 这并不等同于当前登录的用户就一定拥有去执行该工具的合法权力。

自查清单