Agent做到后面才明白，这活跟AI没多大关系

我最近在改善一个AI Agent。东西不复杂，但接的API多，工具参数也复杂。如果全塞进去，Agent又傻又费钱。上下文里摆了几十个工具的JSON Schema，AI光是理解"我现在能干什么"就要耗掉大量注意力和钱。

为了解决这个问题，大家熟悉的有两条路。

第一条：动态加载工具

因为现在某一些模型已经支持工具参数不再像以前一样全塞进System Prompt，而是挪到后面。这样上下文前缀不变，KV Cache保住了——这直接决定响应速度和成本。

但不是所有模型都支持。你选的模型不支持，这条路就走不通。

第二条：Skills

把业务逻辑从工具定义里抽出来，写成Markdown文档，按需加载。AI不需要一次性看到所有能力，遇到具体场景再读对应的操作手册。

这条路解决了"怎么思考"的问题，但引入了新问题：如果Skill里不只是文字说明，还涉及要执行的代码呢？那就需要sandbox。没有sandbox，Skill就只能停留在"给AI读的说明书"，跑不起来。

所以如果你恰好碰上一个组合——模型不支持动态工具加载，也没有现成的sandbox——两条路都堵了。

我碰上的就是这个情况。

穷人版动态加载

最后的做法挺土的：自己写一个skill registry。对AI来说，它只看到一个工具叫run_skill，背后按skill名称分发到对应的函数去执行。相当于在应用层手动造了一个穷人版动态加载。

不优雅。但能跑。

上下文管理才是核心

搭了这么久Agent，一个越来越强的感受是：现在大部分工作不是在写提示词，是在想怎么管理上下文。哪些信息什么时候出现，出现在什么位置，待多久——这些决定了Agent是聪明还是傻。

又是一个没有最优解的问题，只有没办法的脚手架。先跑起来再说吧。