智能体技能、上下文协议与提示词的分工原理

在构建基于大模型的智能体系统时，开发者经常会遇到三个核心概念：提示词、上下文协议与技能。它们看似都在“告诉模型该做什么”，但在运行机制、生命周期和复用边界上存在本质差异。本文将从原理层面拆解三者的职责分工，解释它们各自解决什么问题、在系统中如何协作，以及在实际工程中应如何选择。

一、原理概述：三类机制解决三类问题

要理解三者的区别，首先要回到智能体系统的基本运行模型。一个智能体在单次任务中，通常需要完成以下环节：

1. 理解意图：将用户输入转化为可执行的目标；
2. 获取上下文：读取历史对话、外部数据、工具返回结果；
3. 决策与规划：决定调用哪个工具、按什么顺序执行；
4. 执行动作：调用外部能力，如检索、计算、写入；
5. 组织输出：将结果整理为自然语言或结构化响应。

提示词、上下文协议与技能分别作用于上述链条的不同层面：

• 提示词作用于“理解与决策”阶段，是对模型行为的即时约束；
• 上下文协议作用于“获取与执行”阶段，是模型与外部能力之间的标准化通信契约；
• 技能作用于“能力封装与复用”阶段，是可被多个智能体共享的专业知识单元。

三者的核心差异可以概括为：提示词是一次性指令，上下文协议是标准化接口，技能是可移植的能力包。

二、提示词：即时行为约束的机制与边界

提示词是三者中最基础、最直接的一类。它通过自然语言或结构化文本，向模型注入角色设定、任务目标、输出格式、约束条件等信息。

2.1 工作机制

在模型推理过程中，提示词作为输入序列的一部分参与注意力计算。模型根据提示词中的语义信号，调整输出分布。其本质是通过输入文本影响条件概率，而不是修改模型参数。

一个典型的提示词结构包括：

角色：你是一名代码审查助手
任务：检查以下代码是否存在安全隐患
约束：只输出问题列表，不要解释
输入：{代码片段}

2.2 关键特征

• 作用范围：仅当前会话或当前请求有效；
• 复用方式：复制粘贴或模板化，缺乏结构化封装；
• 能力边界：无法主动调用外部工具，只能影响模型生成；
• 维护成本：随着任务复杂度上升，提示词会迅速膨胀，难以管理。

2.3 适用场景与局限

提示词适合轻量、一次性、无需外部交互的任务。当任务涉及多步骤、多工具、多轮状态维护时，单纯依赖提示词会导致上下文污染、指令冲突和行为不稳定。这正是上下文协议与技能出现的背景。

三、上下文协议：模型与外部能力之间的标准化契约

上下文协议解决的是“模型如何与外部系统交互”的问题。它定义了一套标准化的描述方式，让模型能够发现、调用和理解外部工具或数据源。

3.1 为什么需要协议层

在没有协议的情况下，模型调用外部能力通常依赖硬编码的提示词描述，例如“你可以调用某个接口，参数格式如下”。这种方式存在明显问题：

• 工具描述与提示词耦合，难以维护；
• 不同模型对工具描述的理解不一致；
• 新增工具需要修改提示词，缺乏动态发现能力；
• 权限、参数校验、错误处理无法统一。

上下文协议通过结构化描述和标准调用约定，将“工具能力”从提示词中剥离出来，形成独立的能力层。

3.2 核心组成

一个典型的上下文协议通常包含以下模块：

模块	职责
能力描述	声明工具名称、用途、输入参数、输出格式
发现机制	让模型在运行时获取可用能力列表
调用约定	定义请求与响应的标准结构
权限与安全	控制哪些能力可被哪些智能体访问
错误处理	统一超时、重试、异常返回语义

3.3 工作流程

以一次工具调用为例，其流程大致如下：

1. 智能体启动时，通过协议获取可用能力清单；
2. 模型根据用户意图，选择合适的能力并生成调用参数；
3. 协议层校验参数、检查权限，将请求转发至对应执行模块；
4. 执行模块返回结构化结果；
5. 协议层将结果注入上下文，供模型继续推理。

这一机制的关键价值在于解耦：模型不需要知道工具的内部实现，只需要理解协议描述；工具也不需要感知模型的存在，只需要遵循协议约定。

3.4 技术边界

上下文协议本身不包含业务知识，它只是“通道”。它不能替代技能所承载的专业流程，也不能替代提示词所承担的行为约束。协议解决的是“能不能调、怎么调”，而不是“该不该调、调完怎么判断”。

四、技能：可移植的专业能力封装

技能是三者中抽象层次最高的概念。它将某一类专业能力——如安全审查流程、数据分析方法、文档处理规范——封装为独立、可复用、可移植的单元。

4.1 技能的本质

技能的核心不是“一段提示词”，也不是“一个工具接口”，而是一套结构化的专业知识与执行逻辑。它通常包含：

• 领域知识：该专业领域的规则、判断标准、常见模式；
• 执行流程：完成该类任务的步骤序列；
• 工具依赖：需要调用哪些外部能力；
• 输入输出约定：期望的输入格式与产出格式；
• 边界条件：什么情况下适用，什么情况下不适用。

4.2 为什么需要技能层

考虑一个典型场景：多个智能体都需要执行安全审查。如果每个智能体都在自己的提示词中写死审查规则，会带来三个问题：

1. 重复维护：规则更新需要修改多处；
2. 行为不一致：不同智能体的审查标准可能漂移；
3. 上下文污染：审查知识占用大量上下文窗口，挤压任务本身的空间。

技能的解决思路是：将这类通用专业能力抽离为独立单元，由智能体在需要时加载或调用。

4.3 与子代理的对比

原文提到的一个关键判断是：什么时候应该用技能而不是子代理。从原理上看，两者的差异在于：

维度	技能	子代理
定位	可复用的专业能力单元	面向特定工作流的独立执行体
复用性	高，可被多个智能体共享	低，通常为特定任务定制
上下文	按需加载，不强制隔离	独立上下文，天然隔离
工具权限	依赖宿主智能体授予	可配置独立权限
适用场景	通用专业知识	需要独立执行与隔离的任务

可以用一个通用伪代码来描述技能加载过程：

function load_skill(skill_name, agent_context):
    skill = skill_registry.get(skill_name)
    if not skill.is_compatible(agent_context):
        return error("技能与当前上下文不兼容")
    knowledge = skill.extract_knowledge()
    workflow = skill.get_workflow()
    tools = skill.get_required_tools()
    agent_context.inject(knowledge, workflow)
    agent_context.request_permissions(tools)
    return skill.ready()

4.4 技能的关键机制

技能之所以能实现复用，依赖以下机制：

• 注册与发现：技能集中注册，智能体按需发现；
• 按需加载：只在相关任务中注入，避免上下文浪费；
• 版本管理：技能可独立迭代，不影响宿主智能体；
• 权限声明：技能声明所需工具权限，由宿主决定是否授予；
• 兼容性校验：确保技能与当前智能体能力匹配。

五、三者的协作关系

理解三者区别后，更重要的是理解它们如何协作。一个完整的智能体任务通常按以下层次组织：

用户请求
   ↓
提示词层：定义当前任务目标与输出约束
   ↓
技能层：加载相关专业知识与执行流程
   ↓
协议层：发现并调用所需外部能力
   ↓
执行层：完成具体动作并返回结果
   ↓
提示词层：组织最终输出

在这个链条中：

• 提示词负责“这一次要做什么”；
• 技能负责“这类任务该怎么做”；
• 协议负责“做的时候怎么调外部能力”。

三者不是替代关系，而是分层协作关系。

六、常见误区

误区一：把技能当成提示词模板。 技能的核心是专业知识与流程封装，提示词只是其表现形式之一。技能还涉及权限、工具依赖、版本管理等机制。

误区二：认为协议可以替代技能。 协议只解决调用通道问题，不包含业务判断逻辑。没有技能层，协议只能提供原始能力，无法形成专业行为。

误区三：所有任务都用子代理。 子代理适合需要独立上下文和权限隔离的场景。如果只是共享一类专业知识，用技能更轻量、更易维护。

误区四：提示词越长越好。 提示词过长会稀释关键指令的权重，增加冲突风险。应通过技能和协议将可复用部分外置。

七、总结

提示词、上下文协议与技能分别对应智能体系统中的三个层次：即时约束、标准接口、可复用能力。提示词影响模型生成，协议打通外部调用，技能封装专业流程。

在实际工程中，判断使用哪种机制的核心标准是：

• 如果只是当前任务的行为约束，用提示词；
• 如果需要模型与外部系统交互，用上下文协议；
• 如果多个智能体或多段对话需要同一类专业能力，用技能；
• 如果需要独立执行、权限隔离和上下文隔离，用子代理。

理解这一分工原理，有助于开发者在系统设计初期就做出合理的抽象决策，避免后期因能力耦合导致的维护困境。