01Agent 的本质：让语言模型具备行动能力

1.1 LLM 只是推理引擎，而不是完整智能体

从工程定义上看，LLM 的职责主要集中在语义理解、信息压缩、计划生成与语言输出。它可以根据任务目标进行链式思考，可以对比多个方案，可以从一堆信息中抽取结构化结论，但它并不天然拥有任务上下文的持久化能力，也不拥有对外部世界施加影响的执行能力。

因此，把一个大模型封装成对话机器人，并不等于构造了 Agent。真正的 Agent 至少要满足两个条件：第一，它能够围绕目标而不是围绕单轮提问工作；第二，它能够通过感知环境反馈来持续调整执行路径。前者要求系统具备任务级状态，后者要求系统具备工具使用与观察回流机制。

1.2 Agent = Reasoning + Planning + Memory + Tools

今天大量 Agent 框架都会使用一个近似共识的定义：Agent 由 Reasoning（推理）、Planning（规划）、Memory（记忆）以及 Tools/Skills（工具能力）构成。Reasoning 负责理解局势和作出决策，Planning 负责把复杂目标分解为可执行步骤，Memory 负责管理历史上下文与中间状态，Tools/Skills 则负责真正触发外部动作。

这几个模块缺一不可。没有推理，Agent 只会机械执行；没有规划，Agent 无法处理跨步骤任务；没有记忆，Agent 不能在长流程中保持一致性；没有工具，Agent 就只能停留在文本层面的“建议者”。工程上的关键，不在于把这些模块简单堆起来，而在于把它们置于一个可循环、可观测、可中断的运行时之中。

1.3 Agent Runtime：连接“大脑”与“现实世界”的执行层

Agent Runtime 可以理解为整个智能体系统的操作系统。它一端接收用户目标，一端对接模型与外部能力，在中间承担调度、状态管理、策略约束、日志追踪以及异常处理职责。没有 Runtime，模型调用工具只能是一段孤立的 function call；有了 Runtime，工具调用才变成一个可编排的工作流。

在生产级系统中，Runtime 往往不止负责“把模型的函数参数转发给工具”这么简单。它还需要决定工具清单是否需要动态装载、是否需要对敏感操作进行人工确认、如何缓存结果、如何记录 trace、如何在失败后重试，甚至如何在多 Agent 协作时进行任务路由。也正因此，讨论 Skill 时不能脱离 Runtime 语境。

1.4 ReAct：Agent 如何形成闭环

Agent 的核心工作流通常可以归纳为 Observation → Reasoning → Action → Observation 的闭环，也就是常说的 ReAct 范式。模型先根据当前观察进行推理，再决定下一步动作，动作执行后产生新的观察，新的观察又反过来改变模型判断。

这一闭环使 Agent 与传统脚本产生本质区别。传统脚本通常是一条预定义好的线性流程，而 Agent 则可以在执行过程中根据反馈变化而改变策略。例如，搜索没有结果时改换关键词、调用接口失败时退回备用接口、生成文档前先检查依赖是否就绪。闭环意味着系统具备了“任务内自适应”能力，这也是它从聊天工具迈向数字执行者的关键。

02 Skill 的本质：Agent 的能力扩展系统

2.1 为什么 LLM 需要 Skill

如果说 Agent 决定“做什么”，那么 Skill 决定“怎么做”。Skill 的本质作用，是把外部世界的能力以一种模型可理解、系统可治理、运行时可执行的方式封装起来。它既是能力接口，也是能力边界。

在很多初学者的理解里，Skill 只是“一个 API + 一份说明文档”。这一定义并没有错，但不够完整。真正的 Skill 还隐含了输入输出契约、调用前提、风险等级、权限范围、执行语义、异常处理与可观测性等工程属性。换句话说，Skill 不是孤立的接口，而是 Agent Runtime 中的一级能力单元。

2.2 Skill、Tool、Function Calling、MCP 的关系

Tool 是最宽泛的称呼，泛指一切可被模型或系统调用的外部能力；Function Calling 则是一种让模型以结构化方式表达调用意图的交互机制；MCP（Model Context Protocol）强调模型与外部能力、资源和上下文提供方之间的标准化连接方式；而 Skill 更像是面向具体 Agent 应用的一层封装与组织语义。

在实践中，Skill 往往会以内置工具、远程 API、MCP server 能力、本地脚本、数据库查询器等多种形式存在。一个 Skill 的底层实现可以是 MCP，也可以不是 MCP；可以通过 Function Calling 调用，也可以通过显式路由器调用。理解这些概念的关系，有助于避免把整个能力系统错误地简化成“模型会不会调函数”这一单点问题。

2.3 一个 Skill 的完整组成

一个可用于生产环境的 Skill，至少包含如下组成部分：其一是 Metadata，用于声明名称、版本、标签、作者、可见性和适用场景；其二是 Description，用自然语言告诉模型这个能力解决什么问题、输入输出是什么、何时应该或不应该使用；其三是 Input Schema，用结构化格式约束参数；其四是 Executor，负责把调用真正落地；其五是 Guardrails，用于进行安全检查、权限校验和参数修正；其六是 Output Schema，用于让上游系统稳定消费结果。

从这个角度看，Skill 既面向模型，也面向系统。Description 主要服务于模型选择，Schema 主要服务于系统验证，Guardrails 主要服务于安全治理，Executor 主要服务于能力落地，而 Output 则服务于结果链路与后续推理。

2.4 Skill 的价值不在“接得上”，而在“管得住”

很多工具集成工作看似完成于“接口打通”的那一刻，但对于 Agent 而言，真正困难的并不是接入，而是治理。系统必须知道什么任务适合调用这个 Skill，什么任务不适合；必须知道哪些参数是必填、哪些参数需要默认值；必须知道执行失败时如何恢复，以及结果是否可信。

因此，一个好的 Skill 设计，不是拼命追求“功能多”，而是保证“语义清晰、边界明确、行为稳定”。真正高质量的 Skill 往往不是最复杂的，而是最容易被模型正确选择、被 Runtime 稳定执行、被开发者安全维护的那类能力单元。

03 Agent 如何理解并调用 Skill

3.1 Function Calling 的调用链

在主流模型体系中，模型调用工具通常要经历四个步骤：第一步，系统把可用 Skill 的描述、参数模式和必要约束注入上下文；第二步，模型根据用户意图与当前状态判断是否需要调用某个 Skill；第三步，模型输出结构化调用请求；第四步，Runtime 验证参数并触发执行，再把结果回流给模型。

需要强调的是，模型输出的“调用意图”并不等于真正执行。真正落地执行的主体始终是 Runtime。也就是说，模型负责提出建议，系统负责裁决与实施。这样的分层设计可以避免把安全控制完全交给模型。

3.2 Description Engineering：为什么描述决定调用效果

模型并不阅读你的源代码，它主要通过 Description 来理解 Skill 的用途。因此，Description 的质量直接决定工具选择的质量。好的描述应该同时回答三个问题：这个 Skill 是做什么的；在什么场景下使用它；输入和输出大概长什么样。必要时，还应明确“不应该用于哪些场景”。

例如，两个“查询天气”的工具，如果一个只适用于美国城市，另一个只适用于中国城市，那么这类约束必须写入描述。否则模型就会在看起来相似的选项之间随机摇摆，导致命中率下降。Description Engineering 的本质，就是为模型构造可判别的工具语义空间。

3.3 多个 Skill 冲突时如何选择

在实际系统里，多个 Skill 的功能重叠几乎不可避免。常见做法有三种：一是通过描述区分适用范围；二是引入 metadata 过滤，例如根据 domain、region、risk_level、latency 等条件缩小候选集；三是在 Runtime 层增加显式路由策略，例如优先走内部数据源，再回退到公共接口。

这意味着 Skill 选择不是单纯的“模型自由发挥”，而是模型语义判断与系统策略约束共同作用的结果。越是生产级的系统，越不会完全依赖模型自由选择，而会通过注册中心、路由规则和评估反馈不断收紧调用边界。

3.4 Tool Result Verification：为什么还要验证结果

很多人以为只要工具执行成功，结果就是可信的。事实上并非如此。工具可能返回空结果、过期结果、格式异常结果，甚至因为实现错误返回明显错误的内容。Agent 若盲目信任工具，同样会输出错误结论。

因此，生产系统中通常需要做结果验证，包括：结构验证（结果是否符合 schema）、业务验证（字段是否合法）、一致性验证（是否与上下文或常识冲突）、置信度验证（是否需要再次确认）。对于高风险任务，还可以引入二次校验或人工确认。

04 从静态工具集到动态 Skill Discovery

4.1 为什么不能把所有工具一次性塞给模型

当系统只有三五个工具时，直接把全部能力描述放进上下文是一种可行方案。但当工具数量扩展到数百、数千甚至上万时，这种做法会迅速失效。首先，上下文空间有限；其次，工具太多会造成选择噪声，降低命中率；再次，每轮对话都灌入大量工具描述会带来明显的 token 成本和时延。

4.2 Tool Registry 与 FindSkill

因此，现代 Agent 系统通常会引入 Tool Registry（工具注册中心）和 FindSkill（能力发现器）机制。Registry 负责集中存放工具元数据、描述、版本和可见性信息；FindSkill 则根据当前任务从 Registry 中检索最相关的一小部分候选 Skill，临时注入当前上下文。

这本质上是一种“按需装载能力”的思路。模型不需要一开始知道所有工具，它只需要知道如何找到合适的工具。这样既节省上下文，又提高了工具选择的可控性。

4.3 向量检索与元数据过滤

动态发现通常会结合语义向量检索与结构化过滤两种机制。前者负责根据任务语义找到“像是能解决这个问题的能力”，后者负责根据环境约束进一步筛选，例如只允许当前租户可见、只允许低风险工具、只允许某个业务域内的能力。

这两类检索结合后，动态发现才既有召回能力，也有治理能力。它避免了纯文本匹配过于粗糙的问题，也避免了纯向量检索对风险边界不敏感的问题。

4.4 MCP 的价值

MCP 的意义，在于为模型与外部资源之间建立更加标准化的连接方式。随着工具、文件、数据库、知识源、IDE 环境越来越多，模型侧若仍然使用彼此割裂的私有接入协议，能力生态将极度碎片化。MCP 试图统一“模型如何发现并消费外部能力”的接口方式，使不同客户端、不同工具提供方之间形成更好的互操作性。

从工程角度看，MCP 并不会替代 Skill 的概念，反而会成为 Skill 的重要底座之一。Skill 是面向应用层的能力组织方式，MCP 则是更底层的连接与暴露协议。两者共同作用，才能支撑真正可扩展的 Agent 生态。

05 生产级 Skill Runtime 的架构设计

5.1 Skill 生命周期

在生产系统中，Skill 的存在不是静态的。一个 Skill 会经历注册、发现、装载、执行、评估、回收与更新等生命周期阶段。注册阶段解决“系统知道它存在”的问题；发现阶段解决“当前任务是否需要它”；装载阶段解决“把哪些描述和权限注入当前上下文”；执行阶段解决“真正如何落地”；评估阶段则关注“这次调用是否成功、是否准确、是否安全”。

5.2 Runtime 的核心模块

一个完整的 Runtime 至少包含以下核心模块：Session/Memory 用于维护对话态与任务态；Planner 用于生成计划或下一步动作；Policy Guard 用于进行风险控制；Tool Router 负责做工具层面的路由决策；Executor Pool 负责执行具体能力；Tracing/Audit 用于记录全链路行为；Observability 用于指标监控与问题定位。

这些模块的边界设计决定了系统的可扩展性。比如，若 Planner 与 Tool Router 强耦合，后续很难支持多模型或多策略切换；若 Policy Guard 缺位，则敏感能力可能被直接暴露给模型；若没有 tracing，系统就很难分析“为什么模型总是选错工具”。

5.3 失败恢复与可观测性

Skill 调用不可能永远成功，失败恢复是 Runtime 必须认真设计的部分。常见失败包括参数错误、网络超时、权限不足、外部依赖不可用、返回结果不合规等。对于这些失败，系统可以采用重试、回退、替代 Skill、向用户澄清、人工接管等多种策略。

而要让这些策略真正有效，可观测性是前提。Runtime 必须记录每一轮思考、每一次工具候选筛选、每一个调用参数、每一条返回结果及其耗时、每一次异常和恢复动作。只有看得见，才能评估；只有评估得了，才能持续优化。

5.4 为什么 Runtime 设计比单个 Skill 更重要

在早期原型阶段，开发者往往聚焦于“先把几个 Skill 接起来”。但随着系统走向真实业务，瓶颈很快会从“有没有工具”转向“工具怎么被调用、怎么被约束、怎么被评估”。从这个意义上说，Skill 决定的是能力上限，而 Runtime 决定的是能力质量。真正的竞争力，往往体现在 Runtime 的工程成熟度。

06 Skill 安全问题：从能用到可信

6.1 风险来源

Skill 让模型具备了操作现实世界的能力，也因此把风险一起引入系统。典型风险包括：提示词注入导致模型偏离原任务；工具污染导致模型误信恶意描述；本地执行能力被滥用导致读写越权；网络访问能力被滥用导致数据外传；高风险副作用操作在无审查情况下直接执行。

6.2 多层防御思路

安全治理不能依赖单点方案，而应该采用多层防御。第一层是 Prompt Shield，对输入进行基本过滤并防止指令劫持；第二层是 Policy Check，对模型意图进行策略校验；第三层是 Permission Gateway，对具体能力按用户、租户、任务类型做授权；第四层是 Sandbox Executor，对本地代码执行和文件访问做环境隔离；第五层是 Audit Log，对所有敏感操作留痕。

6.3 沙箱、最小权限与 Human-in-the-loop

对于能够执行代码、操作文件、访问内部系统的 Skill，沙箱几乎是刚需。通过 Docker、虚拟机或托管沙箱环境，可以将模型执行限制在受控边界内。与此同时，应坚持最小权限原则：只读就不要给写权限，只需访问工作目录就不要放开系统目录，只需访问白名单域名就不要开放全网。

对于删除文件、发送邮件、调用财务接口、修改生产配置等高风险动作，Human-in-the-loop 仍然是现阶段非常现实的安全机制。模型可以提出建议，系统也可以完成准备，但最终执行应由人类点击确认。这不是对模型能力的不信任，而是对风险后果的负责。

6.4 安全不是附加项，而是 Skill 设计的一部分

很多团队习惯先把功能做出来，再考虑安全补丁。但在 Skill 体系里，安全并不是外层贴膜，而应是能力设计的内生约束。风险等级、权限范围、可访问资源、审计策略，都应该成为 Skill 元数据的一部分，从注册阶段就被纳入治理体系。