共计 2702 个字符,预计需要花费 7 分钟才能阅读完成。
真实场景问题
- 过度耦合的客服系统 :某团队将所有对话逻辑硬编码在单个 Agent 中,导致增加新问答类型需修改核心决策逻辑,每次变更影响全量测试用例
- 失控的智能家居系统 :开发者用多个独立 Skill 直接互相调用实现联动(如灯光 Skill 直接调用空调 Skill),当需求变更为 ” 仅夜间联动 ” 时,需修改所有 Skill 的代码
技术定义与对比
基本定义
- Skill(原子化能力单元):完成特定任务的不可再分功能模块(如 NLP 中的实体识别、数据库查询)。特征包括:
- 无状态性:输出仅依赖当前输入
- 单一职责:每个 Skill 对应一个明确的功能契约
- Agent(决策协调者):根据上下文选择和执行 Skill 的调度中枢。核心能力包括:
- 状态管理:维护对话历史、用户画像等上下文
- 决策流控制:通过策略决定 Skill 执行顺序
特性对比表
| 维度 | Skill | Agent |
|---|---|---|
| 输入 | 结构化参数 | 原始用户输入 + 上下文 |
| 输出 | 标准化结果对象 | 用户响应 + 新上下文 |
| 状态管理 | 无(纯函数式) | 维护会话状态 |
| 典型生命周期 | 毫秒级 | 长周期(如整个用户会话) |
| 错误处理 | 抛出特定异常 | 决定重试 / 降级 / 终止 |
实现示例
Python Skill 示例
class WeatherQuerySkill:
"""
天气查询 Skill(原子化能力单元)职责:根据城市名返回当前天气数据
契约:输入必须包含 valid_city 参数
"""
def __init__(self, api_key):
self._validate_api_key(api_key) # 内部初始化逻辑
def execute(self, params: dict) -> dict:
"""
执行入口
:param params: 必须包含 {'city': str}
:return: 标准化结果格式 {
'temperature': float,
'conditions': str
}
"""if not params.get('city'):
raise SkillInputError("Missing required parameter: city")
try:
# 调用第三方 API 获取原始数据
raw_data = self._call_weather_api(params['city'])
return {'temperature': raw_data['main']['temp'],
'conditions': raw_data['weather'][0]['description']
}
except APIError as e:
# 转换第三方 API 错误为 Skill 标准异常
raise SkillExecutionError(f"Weather API failed: {str(e)}")
Agent 伪代码
class DialogAgent:
"""决策协调者示例"""
def __init__(self):
self.skills = {'weather': WeatherQuerySkill(API_KEY),
'calendar': CalendarSkill()}
self.context = {} # 维护跨 Skill 的会话状态
def process_input(self, user_input: str) -> str:
"""
决策流程:1. NLU 解析意图
2. 根据上下文选择 Skill
3. 执行并更新上下文
"""
intent = self._nlu_parse(user_input)
# 决策逻辑:根据意图和上下文路由
if intent == 'query_weather':
# 从上下文中补充城市参数(如之前用户提到过)params = {'city': self.context.get('last_city')}
result = self.skills['weather'].execute(params)
self.context['last_weather'] = result # 记录上下文
return f"当前温度:{result['temperature']}℃"
elif intent == 'schedule_meeting':
# 组合使用多个 Skill 的例子
weather = self.skills['weather'].execute(...)
if 'rain' in weather['conditions']:
return self.skills['calendar'].suggest_indoor()
架构设计建议
Skill 拆分原则
- 当功能满足以下条件时应设计为独立 Skill:
- 有明确的功能边界(如查询 / 修改 / 计算)
- 可能被多个 Agent 复用
-
需要独立升级或替换实现

-
典型反面案例:
- 把用户认证和订单查询合并为一个 Skill
- 在翻译 Skill 中硬编码语言黑名单
Agent 决策模式
-
策略树模式 :
def decide_skill(intent, context): if intent == 'book_hotel': if context.get('premium_member'): return VIPBookingSkill() return StandardBookingSkill() -
流水线模式 :
# 按固定顺序执行 Skill(如:先身份验证再业务处理)for skill in [AuthSkill(), PaymentSkill()]: if not skill.check(context): return "Requirement not met"
避坑指南
Skill 设计陷阱
- 隐形耦合 :
# 错误:Skill 内部直接调用其他 Skill class BadSkill: def execute(self): # 直接依赖外部系统状态 if Database.check_status(): ...
正确做法:通过 Agent 注入依赖参数
class GoodSkill:
def execute(self, params):
# 所有依赖通过显式参数传入
if params.get('system_status') == 'normal': ...
Agent 性能优化
- 决策循环优化 :
- 对高频 Skill 做预热加载
- 缓存 NLU 解析结果
- 上下文剪枝 :
# 定期清理过期上下文 def cleanup_context(self): for key in list(self.context.keys()): if key.startswith('temp_') and self.context[key]['expire'] < now(): del self.context[key]
开放式问题
- 在你的业务场景中,哪些功能适合抽象为原子化 Skill?它们之间的依赖关系如何?
- Agent 需要维护哪些跨会话的上下文信息?这些信息的生命周期如何管理?
- 当多个 Skill 的执行结果存在冲突时(如推荐系统中有不同策略),Agent 的仲裁策略应该如何设计?
正文完
发表至: 人工智能
近一天内

