3 篇博文 含有标签「skills」

每个构建 Agent 的团队最终都会遇到同样的瓶颈。系统提示词（System Prompt）起初只有 400 个 token。接着有人添加了数据库迁移检查清单。然后是复盘模板、部署运行手册、客户邮件风格指南。18 个月后，它变成了一个拥有 9,000 个 token 的巨石，没人敢去改动它，因为修改关于回滚流程的一行内容，竟然会降低 Agent 在支持工单中的语气表现。你构建了一个相当于 50,000 行的 main.c 的提示词——而且每个人都在对其进行静态链接。

直觉的反应是使用 RAG：将运行手册切片、嵌入（embed），然后按需检索。但这会以一种更隐蔽的方式失败。RAG 是为检索“事实”而生的，而事实在被碎片化时可以平滑退化——关于你计费模型的五个相关切片中检索到三个，仍然能告诉 Agent 大部分所需信息。但程序（Procedures）无法平滑退化。检索到 60% 的数据库迁移运行手册并不是 60% 有用，而是意味着一场生产事故。有第 1 到 4 步但缺失了第 5 步（“在切换前验证复制延迟”）比完全没有运行手册更糟，因为 Agent 现在的行为带着一种它尚未赢得的自信。

2023 年初，大量企业 AI 培训项目带着同一个卖点涌现：我们将教你的工程师提示工程。然而大多数项目完成第一批学员培训时，所教的具体技术已被模型自身自动化淘汰。到 2025 年，曾短暂标价 20 万美元年薪的"提示工程师"职位实际上已走向消亡。而那些培训项目依然在运转。

这就是 AI 课程陷阱。它不是努力或预算的问题。各组织在结构化 AI 培训、认证项目和以工具熟练度为核心的招聘标准上投入了大量资源。但工具的迭代速度快于任何课程所能追赶的速度，结果是一种永久性的结构性滞后：培训项目始终在教 18 个月前的 AI 工程。

我上个月交流过的一个团队遇到了一个任何资深包管理器用户都能一眼识破的 Bug。他们的智能体中有两个技能（skills）都提供了相同的 search_orders 能力 —— 一个来自计费工具包（billing toolpack），另一个来自 CRM 工具包。最后添加到清单（manifest）中的那个成了生效者。智能体在三周内都在静默地调用错误的能力。退款发到了错误的客户 ID。他们告诉我，修复方法是召集 CRM 和计费工程师开会以“协商命名”。开会。只为了解决两个可安装模块之间的名称冲突。

就在那一刻，我意识到了当前的智能体运行时（agent runtimes）正在发生什么。运行时加载能力模式 —— 技能、工具包、提示词片段、检索提供程序、MCP 服务器 —— 正汇聚到几十年前编程语言通过导入系统（import systems）解决的相同问题上：名称解析、版本锁定、依赖图、冲突检测、延迟加载。而大多数智能体运行时要么在拙劣地重新发明每一项，要么干脆无视，并以“开会”的形式将账单寄给用户。