把你的项目变成 skill 能力还挺麻烦

如果你的接口、MCP 鉴权都不一样，那肯定需要每次都问的。
或者是提醒用户一次性都全部提供。

@killva4624 鉴权，我有设计成本地的 config.yaml 类似的配置方式。就是因为链路需要更多的参数，例如查询 x 账单，需要你提供具体的产品 id ，产品的参数类似的，需要填入更多，那这种设计成 skill ，会不会询问录入的有点过多了？？

你这个问题太大了，context 不足没法给到合适的建议。
比如鉴权，是不是都是内部系统，有没有统一的账号体系和 sso 登录，情况都不一样。
如果纯内部服务，有统一账号/SSO ，最好的办法是你做一个 gateway 服务统一包一层，gateway 做代理鉴权和返回，而不是每个用户都各种本地配 config

@TimePPT 这个确实应该内部在讨论一下。主要对于接口的参数，是不是得一个一个询问才行了。我记得之前千问搞了一个奶茶免单活动，对于奶茶流程是“关键词询问-用户选择-下单-选择扣款方式-结束”，缺少了很多参数的录入，用户语言来操作都可以基本是，这类的接口简化流程倒是交互感不错

我觉得核心是你要 build 的是环境，不是 skill 。

后者你实际上是一个外包，所有的需求都要经过你自己理解之后转译一道再实现。

前者你构建的类似一个低代码平台，你的用户自己去构建 skill 。

@maichael 确实是，就是用户的问法比较发散，skill 固定语序的话，得看 agent 和模型的能力，尤其很考验模型的处理。

例如 skill 中设定"用户需要查询[x][y]账单,需要执行 a 逻辑" "用户需要查询[z]账单,需要执行 b 逻辑"

用户询问：我需要查询 1 月 1 日的某个业务账单的情况

agent 组装 prompt 交给模型来处理,优秀的模型会找到业务账单归类，然后找到这个设定执行 a 逻辑；模型可能比较差的情况，可能两个都会执行。


当然也看 agent 的规划设计情况。我在想就是模型现在可能下限已经提高了一些，能不能通过 skill 去规避掉这种情况。

@NNCandy 是的，我曾经主持过几次类似的内部需求，最好的办法就是先统一内部意见，然后尽可能通过工程手段简化用户的配置成本（不管是面向公众的 C 端产品还是内部的 B 端工具）。Gateway 的好处是横向扩展性，而且即使不是统一的 SSO ，也可以通过引导用户去内部平台配置账号授权来代替本地 config 配置。
对话流内也不是说不能配，就是很麻烦。目前市面上做的体验比较好的是 Muse 这样的 Personal Agent ，预置一些 Connector ，一旦用户触发，则在对话里弹出账号授权提示，做配置，校验，然后生效。但总觉得如果是内部系统这么搞没必要。
其实你提供的 skill 只是 Agent 接入的一个语义 interface ，重点还是如何工程化服务本身。