一句话结论可以共享但不是必须全部共享。Skill 本质就是封装好的能力查数据库、调用接口、文件读写、计算函数它是独立的功能单元理论上可以给多个 Agent 调用。但要区分「能力代码共享」和「Agent 技能权限共享」二者完全不是一回事。两种 Skill 共享模式1. 底层代码 / 服务共享推荐工程首选把 Skill 封装成独立服务或者公共函数库所有 Agent 都调用同一套底层实现。 举个例子 有 3 个 Agent文档解析 Agent、数据分析 Agent、报表生成 Agent。 文件读取 Skill 单独抽成公共服务三个智能体都调用这个文件读取接口。 ✅优点只维护一份代码修改一次所有 Agent 同步更新减少重复开发方便统一鉴权、日志管理。 ❌注意所有 Agent 共用同一个能力实现但每个 Agent 的权限、参数、执行上下文互相隔离。A Agent 读的文件不会自动传给 B Agent。2. 直接在 Agent 实例之间共享 Skill 实例谨慎使用把同一个 Skill 对象直接交给多个 Agent 实例使用。 ❌风险很高会出现状态污染。如果 Skill 内部保存临时变量、缓存AgentA 执行完之后残留状态会干扰 AgentB 的调用结果很容易出现诡异 bug。 只有无状态 Skill纯计算不存中间变量才勉强适合这种方式带缓存、会话状态的技能坚决不能共享实例。什么时候建议共享 Skill通用基础能力文件读写、HTTP 请求、数据库查询、日期计算这类通用工具。多个 Agent 需要遵守同一套权限、安全规则统一管控调用日志。项目需要降低维护成本不想重复写多份一模一样的工具代码。什么时候不要共享 Skill技能有专属业务逻辑比如某个 Agent 独有的私有数据查询能力别的 Agent 不应该访问。技能内部维护会话状态、临时缓存多 Agent 并发调用会互相干扰。权限隔离要求严格例如财务 Agent 的资金查询 Skill不能开放给普通文档 Agent 调用。Multi-Agent 共享 Skill 容易踩的坑权限泄露共享底层服务后如果没做好鉴权低权限 Agent 可以调用高权限 Skill造成数据越权访问。并发状态污染有状态的 Skill 实例共享多个 Agent 同时调用变量互相覆盖结果错乱。调用限流冲突多个 Agent 一起调用同一个 Skill 接口并发量突增触发接口限流导致所有智能体任务失败。版本耦合公共 Skill 一旦修改所有依赖它的 Agent 全部受影响一次改动可能引发批量故障需要完备的测试。简单总结Skill底层代码 / 服务可以跨 Multi-Agent 共享技能实例尽量不要共享。 推荐做法公共能力抽成独立无状态服务多 Agent 远程调用业务专属技能单独维护做好权限隔离。留下新疑问欢迎评论区一起探讨如果 Skill 共享MCP 协议在多 Agent 场景下该怎么做权限隔离多智能体共享 Skill如何做调用审计和流量管控