1、怎么一直有人说路由选择，路由选择是很少的情况，skil就该封装成tools°放向量库，每次都去检索
这个补充很专业，向量库召回确实是 Skill 数量上来后的工程解法。但我视频里反对的是“把 Skill 选择简单理解成手写 if/else 路由”，不是反对候选召回。小规模 Skill 靠 description 就够；规模大了可以做 embedding 召回、rerank，再把候选 Skill 交给模型决策，最后由 registry 校验执行。
2、真是奇怪了，skill的调用可以靠description°，大模型自主判断，也可以靠意图识别，再走承接动作路由调用，具体得看Agent的设计。
你说得对，具体要看 Agent 的设计。可以靠 description 让大模型自主判断，也可以先做意图识别，再进入承接动作或路由链路。我想强调的是：路由是应用层/框架层策略，Skill 本身能不能稳定命中，仍然离不开 description、职责边界和执行层校验。
3、加一个技能:当AI不是百分百确认使用skil时，将待确认skil列表交由用户进行二次确认。
这个思路很好，本质上就是 Human-in-the-loop。低置信度、多候选接近、高风险操作时，把待确认 Skill 列出来让用户二次确认，是很实用的兜底机制。我的建议是：它可以作为治理误触的增强手段，但不要替代 Skill description 的质量建设。
4、造那么多概念，最终都是一段提示词调api
哈哈，这句话有一半对：最后确实都会落到 prompt、API、工具调用。但工程里区分 Skill、Tool、Workflow、Agent 不是为了造概念，而是为了把职责、权限、上下文、复用、失败恢复这些边界讲清楚。Demo 可以是一段提示词，复杂系统只靠一段提示词就很难维护了。
5、注重深度而并非广度，分层skilltree，深召回精重排bro
这个方向我认同，分层 skill tree、粗召回、精重排，是 Skill 规模化后的正确路线。视频里说“别盲目堆 Skill”，和这个并不冲突：先保证每个 Skill 的职责足够清晰，再考虑分层召回和重排。小规模靠 description，大规模靠检索、rerank 和上下文压缩。
6、为什么提示词里的路由会无效，workflow里直接告诉模型当某个意图的时候触发skill(填写skil的名称)
(我用的是agentscopeJava1.0.x)我试过只要名字完全匹配的上，是可以触发的，但如果名字不对那么底层框架就会报错工具名字不存在所以这个时候模型并没有将上面得ski内容和下面的workflow联系起来，但他能准确的翻译workflow里的激活skill就是调用激活skill的工具并传入skil的名称
你这个 AgentScope Java 1.0.x 的实验很有价值。它说明 workflow 里写“触发某个 Skill 名称”时，模型可以把它翻译成工具调用；但执行层仍然要求名字精确匹配 registry。名字不对就报“工具不存在”，这很正常。工程上最好不要手写字符串，而是从注册表生成 Skill 名称，或者执行前做候选纠错和合法性校验。
7、那现在这种模式有现成的python的框架吗?
有现成 Python 框架，但要看你要哪一层能力。LangGraph 更适合状态机、流程编排和 HITL；AutoGen/AG2 偏多 Agent 协作；CrewAI 偏角色、任务、工具编排；LlamaIndex AgentWorkflow 偏知识库、工具和工作流结合。但“Skill 体系”通常还需要你自己设计：Skill registry、description、召回、重排、执行校验，这些框架不会自动替你想好。
8、不支持fc的模型怎么让他支持?不要豆包直接回答
不支持 Function Calling 的模型，不能让它“原生支持”，只能在应用层模拟。做法是：把工具列表和参数格式写进 prompt，让模型按 JSON 输出；应用层解析、校验、白名单匹配；参数错了就让模型重试；工具执行完再把结果回填给模型。这个能用，但它不等于原生 FC，稳定性会弱一些，所以必须加格式校验、重试、超时、权限控制和兜底提示。
回复