深入探讨Skill和Multi-Agent两种技术方案如何解决LLM上下文窗口有限的问题。通过对比分析两种方案的优势与局限，揭示Skill模式如何降低技术门槛，让非研发人员也能参与线上业务迭代，为AI开发提供新思路。
智能速览
Skill和Multi-Agent都为解决LLM上下文窗口有限而生
Skill通过注入知识共享上下文，Multi-Agent采用独立上下文隔离
单Agent加Skill方案在多数场景下运行效率更高
Skill可移植性极佳，非研发人员也能编写并部署
仅需简单框架即可实现Skill的线上迭代能力
Multi-Agent在真正需要并行、隔离、异构能力的场景仍然必要
精华内容
技术方案的演进往往遵循效率与可用性的平衡。在AI Agent领域，Skill与Multi-Agent的争论实际上反映了开发者对更高效、更易用架构的不懈追求。
技术核心差异
Skill和Multi-Agent虽然都致力于解决LLM上下文窗口有限的问题，但实现路径截然不同。Skill采用知识注入方式，将所需能力集成到当前上下文中，与主Agent共享同一个窗口；而Multi-Agent则创建独立的上下文环境，让SubAgent在隔离空间中完成任务。这种根本性差异决定了两者在应用场景和实施复杂度上的不同表现。
Skill优势显著
单Agent、单上下文、低复杂度是Skill方案的显著优势。遵循"maximize a single agent’s capabilities first"原则，Skill在多数场景下能提供更高的运行效率。实际测试显示，单Agent加Skill的执行效率明显优于传统的Multi-Agent架构，特别是在不需要真正并行处理的场景中。
可移植性革命
Skill最美妙的特性在于其极佳的可移植性。没有代码基础的用户，只要掌握Claude Code编写Skill，就能直接参与线上Agent能力的迭代。开发者仅需搭建简单框架：静态文件服务器托管Skill文件、Agent接入Skill tool、开发read tool指向服务器、需要执行脚本时加沙箱。非研发人员本地编写测试无误后上传，线上Agent服务即可立即生效。
应用场景分析
并非所有场景都适合用Skill替代Multi-Agent。真正需要并行处理、上下文隔离、异构能力融合的复杂场景，Multi-Agent仍然是更好的选择。值得注意的是，现在Skill也可以通过指定context: fork来实现上下文隔离，某种程度上具备了SubAgent的能力。两者并非对立关系，而是针对不同需求的互补方案。
技术方案的演进总是向着更低门槛、更高效率的方向发展。Skill模式的出现让更多人能参与到AI应用的构建中，这种民主化趋势值得期待。未来，随着技术的不断成熟，Skill与Multi-Agent的界限可能会进一步模糊，开发者需要根据具体场景灵活选择最适合的方案。
关键评论
很多被设计为multi-agent的系统，实际上可以改成single agent + skill，获得相同的模块化好处+更高的运行效率
Subagent隔离上下文减少了开销但是引发通信障碍，究竟是利大于弊还是弊大于利
今天刚看到一个论文比较multi-agent和skill运行效率，单agent加skill执行效率是会高一些
本来就是有不同的应用场景，skill现在也可以指定context: fork来做context isolation变成subagents
这两个玩意图各有各的用处，没必要对立起来
