米喜我最近帮一个朋友排查Agent项目，打开代码仓库那一刻心里咯噔一下：整个团队做了一年多的Agent，技能逻辑居然全部散落在代码里。系统提示词、工具调用方式、甚至某个上游接口的缓存控制参数都是硬编码的，改一个技能描述要走一次发布流程。更要命的是，有一处缓存控制参数被直接写死在客户端调用链路上，连产品侧想调整缓存保留策略都没办法。这让我意识到，很多团队都在做“能跑的Agent”，但几乎没有考虑过Agent技能的组织和治理方式。Skills Hub这个词最近频繁出现在技术讨论里，说的就是一套把Agent技能从硬编码中解耦出来、用可视化方式统一管理和治理的机制。这篇文章想聊聊我为什么觉得这一步是Agent工程化绕不过去的坎，也会给出一套可落地的迁移思路和实操方案，适合正在做Agent开发、维护多个Agent技能库，或者想从脚本式Demo往工程化方向走的技术团队参考。
1. 把硬编码的坑看透：Agent技能为什么不能再写死在代码里
1.1 cache_control被写死，不只是“姿势问题”
前阵子技术社区吵得很热的一件事，是Claude Code客户端把cache_control参数硬编码到了请求逻辑里。先说清楚这个参数是干嘛的，它用来标记上下文中的哪些内容需要被缓存。正常的API调用里，你可以通过cache_control告诉模型服务端“这段提示词请保留一段时间，后续重复请求直接复用缓存”，达到降低延迟和节省token成本的效果。
问题出在，如果这个参数被写死，就相当于你丧失了上下文策略的调节能力。实践中不同技能的上下文复用模式差异很大：有些技能是高频率重复加载的基础指令，适合长时间缓存；有些技能只是临时拼进来的说明文档，缓存价值极低；还有一些一次性的用户输入，缓存了反而污染后续上下文。硬编码等于把所有情况统统当成同一种策略处理，短期看能跑，长期看性能和成本都是不可控的。这不只是“姿势难看”，而是治理缺失的典型症状。
它背后真正的问题，是“能力定义”和“运行时策略”耦合在了一起。现实中更常见的方式是团队用提示词加工具注册表去实现Agent技能，技能内容分布在多处：有的在代码常量里，有的在数据库JSON字段里，有的干脆写在配置文件里。你想梳理清楚整套系统当前到底具备多少种能力，每种能力给哪些场景在用，用了哪个版本，基本只能靠人肉搜索。
1.2 skill和agent到底差在哪：很多人栽在这里
我见过不少团队把“技能”和“Agent”混着聊，结果架构设计从一开始就偏了。Agent是运行时的主体，它有模型驱动的决策循环、记忆读写、工具调度、任务状态管理。Skill是能力包，它描述的是“某类任务应该用怎样的提示词、调用哪些工具、按什么流程执行”，本质上是可复用的方法资产。
区别很容易理解：Agent是执行者，Skill是执行者手中的“招式库”。一个Agent可以按场景加载不同的Skill，同一个Skill也可以被多个Agent复用。硬编码的做法等于是把招式库焊死在某个Agent身上，每个新Agent都要复制粘贴一遍同类的逻辑，后续改技能就得改很多套代码，大量知识被重复落在不同角落。
说得再直白一点，这跟拿着数据库连接串到处硬编码是一个道理。你写一个小工具的时候，连数据库的用户名密码直接写死在代码里没问题，东西能跑就行。可当你有六个微服务都依赖同一套数据库配置时，任何一处变更都要全网发布，稍不留神就会漏改。Agent的技能管理到了多Agent、多产品线阶段，碰到的就是这个版本的“连接串灾难”。
1.3 硬编码技能库会留下哪些后遗症
我把实际踩过的坑和团队常见的抱怨整理了一下，大概集中在四类。第一是技能不可复用。同样的“网络异常处理”技能在一个Agent里写了一套，在另一个Agent里又写了一套，两边后来甚至走上了完全不同的演进方向，排查问题时很难说清楚哪个才是正确版本。
第二是行为不可观测。固定写死在代码里的技能，没有独立ID、没有版本号，执行日志里只能看到模型调用了某个工具，没法追溯这套技能具体是哪个版本的哪段规则，线上出了问题基本靠回滚整个服务。
第三是迭代成本高。想给某个技能增加一个使用边界条件，要先找到所有用到该技能的Agent入口，再逐个修改代码、