网硕互联帮助中心假设一家软件公司花了几个月，把售后处理中的经验整理成一个AI技能：怎样查订单，怎样判断可退金额，什么情况需要补充凭证，怎样提交申请，遇到结果不确定时到哪里核实。
如果另一家公司能够直接复用这份经验，显然是一件好事。开发者少写一套流程，业务人员少解释一遍规则，许多曾经依赖口头传授的细节，也终于有机会被保存和改进。
AI的工作能力，正在变得更容易分享。
10月22日，Anthropic宣布将Agent Skills贡献给Agentic AI Foundation。Linux Foundation同日公告确认，Agent Skills与另外三个项目进入基金会的开放、中立治理体系。
按照官方介绍，Skills可以将指令、脚本和相关资源组织成可复用的形式，让支持它的智能体按需加载。过去附着在某个助手里的工作方法，有了跨产品、跨平台传播的基础。
这一步值得肯定。很多企业需要的AI能力，都包含大量具体行业经验。让这些经验能够积累、流动和接受共同维护，有助于更多团队从已有成果出发。
随着复用变得容易，另一个问题也会更加具体：一个技能被搬进新公司之后，它原来依赖的业务条件，由谁重新确认？
工作方法能够被复制，行动资格需要有明确的授予者。
继续看这份退款技能在两家公司之间迁移的情形。甲公司服务于直营门店，规定特定类型的退款在核验条件后可以自动处理，超过金额门槛再交给负责人批准。
乙公司引入这份技能，也有订单系统，也有退款接口。但乙公司采用加盟模式，门店能看到的订单范围不同；同样金额的退款，可能还需要总部承担费用，批准人也随之变化。
查找订单、整理凭证、核对结果的方法，依然有参考价值。退款额度、可操作门店、费用承担方式和批准关系，则需要按照乙公司的实际情况建立。
即使两家公司使用同一套商城软件，接口名称完全相同，这些差异也会存在。软件能够表达一种业务，企业如何分配这项业务的决定权，仍然需要自己的安排。
一个写得很好的退款技能，可以准确说明“满足这些条件时提交申请”。至于当前员工有没有资格代表这家门店提出申请，当前订单是否属于这项委托，以及这一笔是否已经得到必要批准，需要有权的系统和组织作出判断。
技能作者掌握的是工作方法。采用技能的企业，掌握的是对自己业务作出委托的权利。两者衔接得清楚，共享经验才能顺利转化为生产能力。
“决定引入”与“批准执行”，也发生在不同的时刻。
企业允许安装一个退款技能，可以表示认可它的来源、版本和用途。安装完成后，谁可以调用它、能够操作哪些订单、能否直接改变资金状态，还需要具体约定。
这与引入一套财务软件相似。采购决定让软件进入公司，财务岗位和审批制度决定谁可以使用哪些功能。软件拥有付款模块，并不能单独说明某位员工可以批准某笔付款。
AI技能把流程描述和执行能力带得更近。有些技能附带脚本，能够调用接口、处理文件或连接外部服务。采用它时，企业实际接入的内容，可能已经超过一份供人阅读的操作手册。
因此，采用者需要了解它会读什么、调用什么、把数据交给哪里，以及哪些步骤可能产生业务后果。来源可信和代码经过检查，有助于判断实现是否值得采用；具体业务授权，则需要根据使用者、任务和接收系统继续建立。
同一个技能用于整理模拟订单，与用于处理正式退款，承担的后果不同。授权可以随用途分配，无须因为技能具备完整流程，就一次性交出它可能用到的全部能力。
模型能够从上下文中理解“这次只处理某家门店”，有助于正确规划。把这一限制放进实际调用能够经过的检查里，才能让执行也遵守同一项约定。
技术连接建立以后，业务范围还要对得上。
迁移一个技能，往往要先解决环境问题：新系统的接口在哪里，字段怎样对应，登录凭据从哪里取得，宿主支持哪些工具。
这些工作很具体，也很容易成为交付清单的主体。接口返回成功，查询拿到数据，演示中的订单能够处理，团队就可能认为迁移已经完成。
但一条能够调用的退款接口，还可能只识别一个权限很大的服务账号。若业务系统没有区分操作者、门店和订单范围，技能里写得再细，也不能凭空生成这些隔离能力。
遇到这种情况，需要接收系统补充判断依据，或通过受限接口、独立身份等方式，把可执行范围收窄。短期无法做到的部分，应当明确限制用途，保留相应人工步骤。
现有身份认证、权限管理和审批系统可以继续发挥作用。需要补齐的是连接关系：智能体发来的这次操作，怎样对应到已有用户、业务范围和批准记录，而不只是证明某个程序持有一个有效密钥。
因此，一次有意义的接入验收，除了验证允许的操作能够完成，还应当在安全的测试条件下，核对超出范围的请求会在哪里被拒绝。
如果甲公司店长的凭据换成乙公司总部管理员的凭据，演示很可能更容易成功。但这同时改变了谁在承担操作资格，不能仅凭演示顺利就认定迁移条件已经等价。
技能可以提出要求，业务系统需要核准这些要求如何成立。
当前Agent Skills规范包含一个可选、实验性的allowed-tools字段，用于声明预先批准的工具，具体支持取决于智能体实现。
这样的声明可以帮助宿主理解技能所需的工具条件。到了企业业务里，还需要继续回答更具体的问题：允许使用退款工具，对应哪家企业、哪些订单、什么金额范围，以及哪些前提？
工具层的许可与业务对象上的权限需要相互配合。它们可以由已有系统共同表达，也可以通过新的公共接口衔接；实施方式可以不同，判断依据应该能够核对。
技能中一句“取得店长同意后执行”，可以描述工作流程。系统仍需知道同意由谁作出、针对什么操作、在什么条件下有效。否则，模型引用了一段流程文字，也可能被误当成已经取得这次批准。
合理的批准可以覆盖一类有明确边界的工作。例如，企业可以允许某个角色在限定期间、限定门店和限定条件下处理一批申请，再把超出范围的情况交给负责人。这样既能减少反复打断，也能保留清楚的责任。
自动化的空间，可以来自组织预先作出的明确决定。技能擅长执行这些决定，授权系统负责表达和校验它们，业务系统则保留对实际状态和领域规则的判断。
越容易更新，越需要知道哪些变化触及了原来的委托。
技能共享以后，维护者会不断改进它：补充异常处理，增加新接口，优化流程，减少不必要的步骤。
这些更新通常有价值。但原来只读取订单的技能，后来加入了自动创建退款申请；原来只在本地整理凭证，后来增加了外部识别服务。名称可能没变，企业需要评估的行为已经变化。
版本号有助于定位采用了什么，变更说明有助于理解变化。继续允许执行哪些操作，则应结合新增工具、数据去向和副作用判断。只调整表述、未改变行为与数据范围的修订，可以沿用原流程；行为范围发生实质变化时，需要重新确认是否仍被原授权覆盖。
反过来，即使技能文件完全没变，企业的规则也可能已经更新：门店负责人调岗，售后政策调整，原来的服务账号被撤销。固定版本能够稳定实现，执行时仍需要使用当前有效的身份和业务条件。
这也解释了为什么工作经验适合长期积累，某一次批准却不能在所有时间和场景下反复沿用。它们各自有有效范围，需要能够独立变化。
维护得好的技能，应当帮助采用者看懂行为边界，并在必要条件缺失时清楚停下。若每次接入失败都靠扩大权限解决，短期能跑通，后续维护者却会越来越难解释这套流程为什么拥有那些能力。
真正值得复用的，还有失败之后怎样确认事实。
一个成熟的退款技能，除了知道正常流程，也应知道接口超时后怎样查原申请，哪些失败可以重试，哪些结果必须等待核实。
这些经验很适合跨企业贡献。它们能让新的采用者少踩一些已经踩过的坑，尤其是在模型、网络和业务系统分别运行的情况下。
不过，具体到乙公司，原申请标识在哪里、业务状态由哪个系统确认、重复请求如何识别，仍需要对接。技能里的恢复策略，必须找到当地系统能够提供的事实依据。
“请求已经发出”“业务系统已经受理”“退款已经完成”，可以是三个不同的事实。把它们表达清楚，后来的人才能判断下一步是查询、等待、批准还是补救。
共享流程越广泛，这类事实越值得形成公共表达。接入双方可以先对齐什么叫受理、什么叫完成、什么叫待核实，再映射到各自系统的状态，减少对同一个词作出不同理解。
行业需要的可移植性，也包括怎样理解彼此的责任。
如果每个软件厂商都要为每种智能体重新解释一遍身份、门店范围、批准和结果，技能格式带来的便利，仍会在业务接入阶段消耗掉相当一部分。
公共规范有机会降低这部分成本。它可以帮助不同实现表达同一类问题，让开发者知道应该提供哪些依据，也让接收企业知道哪些决定需要自己作出。
共同的表达方式，允许企业保留不同的政策。甲公司批准什么金额、乙公司采用什么流程，可以各自决定；双方仍然能够理解一个批准覆盖什么，以及一条执行记录究竟证明了什么。
这也是我们作为软件开发者持续关注A2B的原因。当智能体开始代表人进入业务系统，主体、边界、停点和事实，会成为接入双方都需要处理的问题。
我们尝试用ACC提供一份能力与治理语义的开放参考，再通过BailingHub将其中一部分做成可运行的执行治理实现。实践中更有价值的积累，来自接入、失败、恢复和多轮调整，也来自业务系统对自身最终权限的坚持。
这些经验值得贡献给同行。我们希望有人能够直接复用，也希望有人指出不足，或者提出更好的公共方案。行业形成更成熟的规范后，我们同样可以跟进，让已有实践成为共同建设的一部分。
AI技能的流通，让一家企业积累的方法有机会帮助另一家企业。让这种流通走得更远，需要接收方能够清楚判断：这份经验到了这里，可以在什么条件下替谁完成哪些事。
当工作方法可以共享，委托能够被准确表达，执行结果又能够核对，企业才更有条件把优秀的外部经验接进自己的真实业务。
拓展阅读
- ACC能力契约v1.0.5。
- BailingHub开源实现与边界v0.10.0。
评论前必须登录！
注册