当我们在讨论 AI 代理（agent）的能力边界时，很少会停下来问一个最基础的问题：这些代理所依赖的“技能”（skills）到底是用什么语言写的？这个看似技术细节的问题，实际上决定了代理生态的开放程度、开发者的学习曲线，以及未来标准化可能的方向。
发生了什么
Hacker News 上出现了一个简短但引人深思的提问：“What languages are agent skills written in?”（代理技能用什么语言编写？），目前获得了 11 个点赞。问题虽短，却直指当前 AI 代理开发中的一个模糊地带。在评论区，开发者们分享了各自的实践：有人用 Python 编写技能，因为其丰富的库和 AI 生态；有人选择 TypeScript，以便与前端工具链无缝集成；还有人提到 Rust 或 Go，追求性能和安全性。但一个明显的共识是：目前没有统一的标准，技能的语言选择往往取决于代理框架的默认偏好或团队的技术栈。
为什么重要
这个问题之所以重要，是因为“技能”正在成为 AI 代理的核心抽象层。不同于传统的函数调用或插件，技能通常是一段可复用的代码或指令，让代理能够执行特定任务，比如操作数据库、调用 API、处理文件等。随着代理从简单聊天走向复杂工作流，技能的可移植性和可维护性变得至关重要。如果技能被锁定在特定语言或框架中，开发者将面临高昂的迁移成本，而整个生态也会碎片化。此外，语言选择还影响安全性——某些语言更容易写出内存安全的代码，而某些则更容易引入漏洞。在代理自主行动的背景下，安全漏洞的后果可能被放大。因此，这个问题背后是对代理生态成熟度的拷问：我们是否已经建立了足够健壮的基础设施，来支撑技能的编写、共享和演进？
影响与看点
对于开发者而言，这意味着在选择代理框架时，需要评估其技能系统的语言支持是否与自身技术栈匹配。例如，如果团队擅长 Python，但框架默认技能用 JavaScript 编写，学习成本就会增加。对于平台方，如 OpenAI、Anthropic 或开源社区，他们推出的技能格式将可能成为事实标准，而语言选择是其中最关键的一环。值得关注的是，是否会出现一种“中间表示”（intermediate representation）来解耦技能与具体语言，类似于 WebAssembly 在浏览器中的作用。此外，随着多代理系统兴起，技能的可组合性也要求语言之间能够无缝互操作。我的判断是，短期内 Python 和 TypeScript 将主导，但长期来看，一个更中立的、面向安全的语言或字节码格式可能会浮出水面。无论如何，这个问题的讨论本身就是行业走向成熟的标志——我们开始关注那些基础但决定长远发展的问题了。
