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，稳定性会弱一些，所以必须加格式校验、重试、超时、权限控制和兜底提示。
9、针对Plan-and-Execute这篇，第一个问题：这题考的是知识面，不是技术面
你这个说法有道理，第一层确实是在考知识面：你知不知道 ReAct、Plan-and-Execute、Planner、Executor、Replanner 这些基本概念。
但我觉得面试里它不会只停在知识面。因为面试官很容易继续追问：什么场景用 ReAct，什么场景用 Plan-and-Execute？规划失败怎么办？重规划什么时候触发？强模型和弱模型怎么分工？这些就开始进入工程判断了。
所以我更倾向于说：这题入口是知识面，往深了问就是技术面和工程经验。
10、“感觉这个模式有点像算法里的贪心算法”
这个类比挺好，尤其是从“每一步执行当前计划”这个角度看，确实有点像贪心。
但严格来说，Plan-and-Execute 不是典型贪心。贪心一般是每一步只基于当前最优做选择；而 Plan-and-Execute 的核心是先做一次全局规划，再逐步执行，中间如果发现结果不对，还会通过 Replanner 调整后续计划。
所以更准确地说：ReAct 更像局部贪心，一步一步看结果再决定下一步；Plan-and-Execute 更像“先全局规划，再局部执行，必要时动态修正”。你这个类比很适合帮助理解，但不能完全等同。
11、“tool call这些都是agent的组件而已，写个脚本发prompt就是agent了”
这个说法前半句我认同，Tool Call 确实只是 Agent 的一个组件，不是 Agent 的全部。
但“写个脚本发 prompt”要分情况：如果只是 prompt -> response 一次调用，那更像普通 LLM API 封装；如果这个脚本还能维护状态、让模型决定下一步、执行工具、处理失败、控制权限、判断什么时候停止，那它就已经是一个简化版 Agent Harness 了。
所以关键不在于是不是脚本，而在于它有没有“循环决策 + 工具执行 + 状态管理 + 失败兜底”。
12、“Tool不也是看描述吗”
对，这个点说得没错，Tool 选择确实也会看 description。
但 Tool Call 不只是看描述。它一般会把工具名、描述、参数 JSON Schema 一起交给模型。description 影响“选不选这个工具”，JSON Schema 约束“参数怎么填”，ToolRegistry 再负责“这个工具存不存在、能不能执行”。
所以 Tool 和 Skill 都依赖描述，但不是一回事。Tool 更偏结构化函数调用，Skill 更偏一组能力/流程的触发和加载。可以类比，但不能完全画等号。
面试官问：Agent挂了几十个skill,怎么保证命中率呢？
网友1：很简单 最好只激活很少量的skill 什么多了都不好使 也记不住
回复1：对，这个思路是很对的。Skill 不是越多越好，尤其是一次性把几十个完整 Skill 都塞进上下文，模型肯定容易混。更合理的做法是“少量激活 + 按需加载”：常用 Skill 保持可见，其他 Skill 先只暴露 description，需要时再加载完整内容。
网友2：Tool不也是看描述吗
回复2：是的，Tool 也看描述，这点没问题。但 Tool Call 还会看工具名和参数 JSON Schema，属于结构化函数调用；Skill 更像一组能力包，靠 description 触发后再加载流程、规则、脚本或上下文。两者都依赖描述，但抽象层级不一样。
网友3：你这不就是路由吗？我理解的有问题？
回复3：你的理解没问题，从工程结果看，确实都像是在“把请求分到某个能力上”。我想强调的是：这里不是传统 if/else 规则路由，而是模型根据 description 做语义选择。大规模场景也可以先召回、重排，再交给模型判断，这属于工程路由和语义匹配结合。
网友4：最后一个问题我就觉得奇怪：问skill 数量爆炸怎么办，skill是你自己加的，自己写的，然后自己觉得多，要么是你自己写的时候都不知道 skill能力重叠 ，要么就是你自己涉及的范围太广需要用的太多，后者就没法解决呀，每个skill对你来说都是有用的。应该说在skill数量过多的时候如何提高skill的匹配效率。
回复4：这个建议非常好，“提高匹配效率”这个说法确实更精准。Skill 多通常有两类问题：一类是设计问题，职责重叠、边界不清；另一类是业务确实复杂，Skill 必须多。前者要合并和重写 description，后者就要分组、向量召回、Top-K 候选、rerank 和按需加载，而不是全部塞给模型。
网友5：load skill 这个动作还是会 function call
回复5：对，很多实现里加载 Skill 的动作最终确实可能落成一次 tool/function call，比如调用 load_skill(name)。但这不代表 Skill 等于 Tool。Tool 是可执行函数，Skill 是能力包；load skill 只是把能力包加载进来的执行手段。
网友6：tf-idf 参考cc
回复6：可以，TF-IDF、BM25、embedding 都能做 Skill 候选召回。Claude Code 这类产品里也有渐进式披露的思路：先让模型看到少量摘要或描述，需要时再加载更完整的规则/Skill。核心不是迷信哪一种检索算法，而是别把所有 Skill 全量塞进上下文。
面试官问：什么是Agent,他和直接调用大模型API有什么区别？
网友1：那么多讲究，直接套壳open code完事。
回复1：能套成熟项目当然是好事，做 Demo 或内部工具，直接基于 open code 二开效率很高。但面试和工程落地不能只停在套壳，因为出问题时你还是要知道：上下文怎么组装、工具怎么注册、权限怎么控、失败怎么重试、循环什么时候停止。会用是效率，会拆才是能力。
面试官问：Agent和ChatBot最大的区别是什么？
网友1：chatbot早已不知是这样了 chatbot也可以做调研 也可以调用skills 同时chatbot在agent这个概念出现之前就有memory了 另外chatbot通过deep research功能也早就实现规划后再执行的能力了 这些都不是agent的核心能力，Agent的核心能力在于可以执行超长任务且可以调用本地的文件以及直接在ide里进行编程
回复1：这个补充很有价值，现在很多 ChatBot 产品确实已经集成了工具、记忆和 deep research，所以不能再用“能不能聊天、能不能查资料”来粗暴区分。更准确地说，现代 ChatBot 和 Agent 的边界在变模糊。我的观点是：ChatBot 更偏交互入口，Agent 更偏可持续执行的运行架构；而你说的超长任务、本地文件、IDE 编程，本质上就是 Agent 在权限、状态、工具和执行环境上的强化。
网友2：chatbot是产品形态， agent是架构形态
回复： 这句话我很认同，而且比“ChatBot 只能聊天、Agent 才能干活”更准确。ChatBot 是用户看到的交互形态，Agent 是背后的执行架构。一个 ChatBot 背后完全可以接 Agent，所以现在很多产品看起来是 ChatBot，用起来其实已经是 Agent 了。
面试官问：什么是React?他和Cot有什么区别？
网友1：react不是边想边做吗？
回复1：对，ReAct 就是边想边做，这个理解是对的。再补一句会更完整：ReAct 是 Thought、Action、Observation 的循环，不只是“想”，还会调用工具去验证结果。CoT 主要是在模型脑子里推理，ReAct 则是推理一步、行动一步、观察结果后再继续推理。
面试官问：智能体是如何做意图识别的？
网友1：向量模型
回复： 向量模型是常见做法，尤其适合做候选召回，比如从一堆 Tool、Skill、知识库或 workflow 里先找 Top-K。
但 Agent 的意图识别不只有向量模型，还可以靠规则、关键词、分类模型、LLM 直接判断，或者混合方案。工程上通常是：向量召回提高效率，LLM/规则再做最终决策和兜底。
面试官问：怎么解决Agent上下文撑爆的问题？
网友1：错误，tool这些应该直接塞进rag里，如果tool太多，塞上下文还是有问腿。
回复1：这个方向是对的，Tool 太多时不应该全量塞上下文，可以把 Tool/Skill 的描述做成可检索索引，每次只召回最相关的一小批候选。
但要注意，RAG 解决的是“候选召回”，不是完整执行。最终真正要让模型调用的 Tool，还是需要把工具名、description、参数 schema 放进当前上下文，否则模型不知道怎么稳定填参数。更准确的方案是：Tool 元信息进检索库，Top-K 召回后再注入上下文，而不是所有 Tool 常驻上下文。
Agent 怎么避免上下文爆炸？
提问：虚空打靶，一个bug如果一个单独的窗口都改不完，该思考的是不是人的问题了，需求同理。
这个观点我同意一半。一个 bug 如果在一个干净的窗口里都说不清、改不完，那确实要先怀疑需求拆分、问题定位和人的表达方式，而不是怪上下文窗口。
但这篇讲的不是“把超大需求硬塞给 Agent”。上下文爆炸更多发生在排查过程中：日志、源码、测试结果、报错信息、重复观察、无关文件一路追加，最后模型反而抓不住关键线索。哪怕是一个合理范围内的 bug，也可能因为工具输出太长、无关信息太多，把上下文污染掉。
所以正确做法不是“窗口越大越好”，也不是“全靠人把问题拆解完”，而是两边都要做：人负责把目标和边界说清楚，Agent 负责截断无关工具输出、压缩历史、必要时拆子任务。需求同理，复杂需求先拆清楚，再让 Agent 执行，不要指望一个窗口吞掉所有混乱信息。
面试官问你：“为什么LLM的上下文窗口不能无限大？”
网友1：小米都是无限大，你这个不行 回复1： 网友2：无限大和long context 的遗忘上下文可是两方面的事 回复2： 网友3：mamba是线性空间复杂度，为什么不用mamba 回复3： 网友4：假设AI有能力处理无限大的窗口，那么它会把所有的答案都激活，一定有大堆你不想要的东西，就好像直接给你一座图书馆，没有任何意义 回复4：
回复