看到这样一则爆料。在携程 4 年月薪 30000 左右研发岗基本是没有涨薪了。不过这么多年还是挺满足的毕竟稳定福利待遇也不错。截图来自职级对标网在如今这个快节奏的 AI 时代能说出“满足”两个字的人我是真的佩服。看看你的周围是不是每个人都在卷早上出了个新模型要测测中午出了个新 Work 要试试。整个行业的节奏快得像在赶末班车每个人都马不停蹄地、拼了命地往前冲。但这位老哥说满足稳定福利不错。深得我心啊。这两年 AI 把节奏拉得太快了快到大家忘了一件事——人还应该有生活。准时下班、周末不加班、半夜不用回消息这些更应该是我们追求的不是吗要我说稳定才是最好的学习姿势。反正我只有在外界环境都顺风顺水的状态下才有心情工作才想去学习新东西。如果你也渴望稳定同时又想在稳定的心态和节奏下学一些新的 AI 知识那接下来这些 Agent 面试题可以好好读一读。全文比较肝保证大家能学到很多很多系好安全带我们粗粗粗粗发contentPSPaiCLI 是一个类 Claude Code 的终端 Agent已开源。如果你想拥有一个 Agent 的项目经验可以参考。GitHub: https://github.com/itwanger/PaiCLI-Python01、Claude Code 与 Codex 各自有什么特别老王翻开面试题直接问“Claude Code 和 Codex 你都用过吗各自有什么特别的地方”“都用过。这两个产品方向完全不一样。”“Claude Code 是 Anthropic 做的终端 Agent最大的特点是实时交互和 AI 时代完美契合不需要 IDE 就可以完成 Coding 工作。在终端里给它任务然后读代码、改文件、跑命令整个过程全程可见并且随时可以打断、纠正。就目前来说Claude Code 就是最强的终端 Agent没有之一。”“Codex 是 OpenAI 做的桌面端 Agent走的是异步多线程可视化比 Claude Code 更强。”“我个人是两者的重度用户Claude Code 配合 Opus 模型在文本领域更强整体架构能力上更强。Codex 我更喜欢配合 GPT-5.6 Sol 做代码开发和生图特别消耗 Token 的任务也会交给它。”02、输入到模型的 prompt 由哪些部分组成“你做的 Agent输入到模型的 prompt 是怎么组装的哪些部分是必须注入的哪些不是”“prompt 组装用的是分层拼接一共 9 层按固定顺序拼进去。”“前 4 层是静态的整个会话期间不变。”第一层是身份定义包括工具的 schema、安全策略、行为守则这一层是必须注入的没有它模型连自己是谁都不知道更不知道能用什么工具。第二层是人格层控制语气和风格。第三层是模式层根据当前执行路径加载不同的指令集ReAct、Plan、Team 三种模式各一套。第四层是审批层定义哪些工具调用需要用户确认。“后 5 层是动态的每轮都可能变。运行时上下文日期、时区、项目记忆、Skills 索引、上下文管理策略、收尾指令。”“必须注入的是身份层和模式层——模型必须知道自己是谁、当前在什么执行模式下工作。人格层、Skills 索引、项目记忆这些不是必须的没有它们模型照样能干活但体验会差不少。比如没有 Skills 索引模型就不知道有哪些现成的技能可以加载遇到问题只能靠自己硬想。”为什么静态内容要排在最前面“因为 Prompt Caching。”“Prompt Caching 会按最长公共前缀命中。前 4 层是静态内容放在提示词最前面每轮请求的前缀都一样缓存命中率能拉到最高。如果把动态内容插到前面前缀每轮都变缓存基本不会中token 成本会高出好几倍。”03、你做的 coding agent 和 Claude Code 与 Codex 区别在哪“Claude Code 是终端 Agent 的标杆。”但我在使用这些工具的过程中产生了一个疑问——这些工具底层到底是怎么工作的它是怎么理解我的指令的、怎么决定该读哪个文件的、怎么判断该调用什么工具的、多轮对话的上下文它是怎么管理的。我发现如果我只会用这些工具但不理解它们的底层设计遇到工具表现不好的时候比如 Agent 选错了工具、上下文丢失了关键信息、生成的代码跟项目风格不一致我只能试着换个说法重新问而不能从原理层面判断问题出在哪里。所以我决定自己从零实现一个 Agent CLI把 ReAct 推理循环、Tool Calling、Memory 管理、MCP 协议这些核心模块都自己写一遍。做完之后我对 Agent 系统的每一层都有了源码级的理解再回去用 Claude Code 的时候我能明显感觉到我对工具的驾驭能力提升了——我知道什么样的指令能让 Agent 更准确地理解我的意图、我知道在什么场景下应该手动压缩上下文、我知道怎么设计 Tool 的描述信息能提高调用准确率。04、上下文压缩是怎么做的老王往前倾了倾身子继续问“你提到了上下文压缩具体是怎么做的”“三层压缩每一层处理不同粒度的内容。”“第一层是工具结果截断。单次工具返回的内容如果超过阈值——比如 grep 一下出来几千行——直接截断保留首尾和关键信息中间用摘要替代。这一层是即时生效的工具一返回就处理。”“第二层是对话历史摘要。当整个对话的 token 数接近上下文窗口的上限时保留最近几轮完整对话把更早的历史用 LLM 做一次摘要压缩。摘要会保留四类关键信息用户的核心诉求、Agent 已完成的操作、达成的共识、还没解决的待办。”“第三层是紧急降级。如果摘要压缩之后 token 数还是超限按优先级丢弃非核心上下文——Skills 索引、非关键记忆、项目记忆里优先级低的部分给核心对话腾空间。”05、为什么要采用三层压缩策略每一层压缩的内容一致吗“设计思路是粒度从细到粗触发条件从宽到严。”“第一层处理的是单条消息级别的冗余触发条件最宽松——每次工具返回都会检查超了就截。成本几乎为零不需要调 LLM。”“第二层处理的是对话历史级别的膨胀触发条件是 token 数超过上下文窗口的差不多 80%。200k 的窗口大概在 167k 左右触发。这一层要调一次 LLM 做摘要有成本所以不会太频繁。”“第三层是最后防线只在前两层都不够用的时候才启动。丢弃的是可恢复的辅助信息——Skills 索引可以重新加载、项目记忆可以重新检索——核心对话内容不到万不得已不动。”“三层压缩的内容完全不一样。第一层压的是工具输出第二层压的是对话历史第三层丢的是辅助上下文。如果只用一层笼统地压缩要么压得太早浪费上下文空间要么压得太晚直接超限报错。”06、压缩过度效果不理想怎么发现怎么处理“靠两个信号。”“第一个是行为异常。模型开始重复做已经做过的事情——比如读一个文件明明十分钟前已经读过了又读了一遍。或者模型直接说’我不太清楚之前讨论了什么’这就是压缩把关键信息压丢了。”“第二个是任务成功率下降。同样类型的任务之前能完成压缩几轮之后开始失败大概率是上下文丢了关键内容。”“处理有三个手段。”第一动态调整保留轮数。默认保留最近 3 轮不压缩如果检测到异常临时扩大到 5 轮。第二关键信息标注。用户明确给出的需求、已确认的技术方案标记为不可压缩摘要的时候跳过。第三压缩前备份原始历史发现效果不好可以回滚到压缩前的状态用更保守的策略重新压。07、增量修改系统怎么做需要重新注入哪些信息“走的是 Plan 审查机制。”“Agent 生成执行计划之后用户可以审查。如果需要加新功能用户选择’补充需求’把新的需求描述传进去。系统拿着原计划和新需求一起交给规划器让它重新生成一份计划。”“重新注入的信息有三块原始任务描述、已完成步骤的摘要、新需求的补充说明。已完成的步骤不会重新执行规划器基于当前进度来安排后续的步骤。”为什么不直接在原计划上追加而要重新规划“因为新需求可能改变已有任务的依赖关系。”“举个例子原计划是’先创建数据库表再写 CRUD 接口’。用户补充说’加一个缓存层’。这不是简单地在后面追加一个缓存任务——CRUD 接口的实现逻辑要改读操作要先查缓存再查库写操作要同步更新缓存。直接追加的话前面已经写好的接口代码就不对了。”“重新规划让规划器看到全貌重新安排依赖和执行顺序避免后续步骤建立在错误的前提上。”08、工具调用的流程是怎样的老王翻了一页笔记继续问“工具调用这块讲讲完整流程是什么”“三个阶段。”“第一阶段LLM 生成 tool_call。模型看到工具的 schema 定义之后根据当前任务决定调哪个工具、传什么参数输出一个结构化的 tool_call 请求。”“第二阶段策略审批。写操作改文件、跑命令会过一道安全检查——路径是否在允许范围内、命令是否在黑名单里。需要用户确认的操作会暂停等审批通过。”“第三阶段执行。单个工具直接执行多个工具可以并行跑线程池上限 4 个并发。执行结果作为 tool 消息追加到对话历史里LLM 拿到结果之后再决定下一步。整个过程是一个循环生成 → 审批 → 执行 → 结果回到模型 → 继续生成直到模型认为任务完成。”能不能用 Skill 替代工具不能两个东西完全不一样。维度Tool工具Skill技能本质可执行能力——读文件、跑命令、搜代码决策知识——怎么用工具、什么策略、什么规范调用方式LLM 通过 tool_call 协议调用LLM 调用 load_skill内容注入下一轮消息返回内容结构化结果文件内容、命令输出Markdown 指令提示词级别的知识生命周期单次调用用完即走加载后驻留在上下文里持续影响后续决策“Tool 是手Skill 是脑子里的经验。你不能用经验代替手去拧螺丝也不能用手代替经验去判断该拧哪颗。两个是互补关系不是替代关系。”09、讲讲你的 Skills 有哪些“核心设计思路是渐进式披露分三层加载。”“第一层是索引。只把 Skill 的名称和一句话描述放进 system prompt控制在 4KB 以内最多 20 个 Skill。这一层常驻上下文成本很低。”“第二层是正文。LLM 看到索引后判断当前任务需要哪个 Skill调一个 load_skill 工具把完整指令拿进来单个 Skill 正文上限 5KB。加载进来的 Skill 放在一个 LRU 缓冲区里最多同时持有 3 个超出的按最久未使用淘汰。”“第三层是参考文档。部分 Skill 自带参考文档目录只在 Skill 指令明确要求的时候才加载。”为什么不一次性全量加载因为 system prompt 越长Prompt Caching 命中率越低。绝大多数对话只会用到一两个 Skill全量加载等于让用户为用不到的内容付 token 成本。“Skill 来源有三个优先级内置的、用户级的、项目级的从低到高覆盖。项目级的 Skill 可以覆盖内置同名 Skill 的行为不用改源码。”10、工具调用时模型用了几次Skill 用了几次“这个跟任务复杂度有关说个典型场景。”“比如’帮我在项目里加一个分页接口’这种任务模型差不多要调 10 到 15 次工具——读项目结构、读已有接口代码、读数据库模型、写新接口、写测试、跑测试、修 bug每一步都是一次工具调用。Skill 的话可能就加载了一个代码规范相关的 Skill一次。”“工具调用频率远高于 Skill 加载差不多 10:1 到 20:1 的比例。这也是为什么 Skill 要做渐进式加载——使用频率不像工具那么高没必要全部常驻上下文。”场景题11、面向一个复杂任务你的 coding agent 的 plan 是怎么做的老王合上笔帽换了个方向“来道场景题。如果来了一个复杂任务你的 Agent 会怎么做 plan”“先判断任务是不是真的需要 plan。简单任务——比如’把这个变量名改一下’——直接走 ReAct 模式一步到位不需要规划。”“复杂任务走 Plan-and-Execute 模式。规划器接收用户任务之后生成一个带依赖关系的 JSON 计划。每个子任务有 id、描述、类型和依赖列表。”“计划生成之后先做拓扑排序确认没有环依赖。然后按依赖关系分批执行——没有依赖的任务可以并行跑有依赖的等前置任务完成再启动。”“用户可以在执行前审查计划觉得不对可以调整也可以补充需求让规划器重新出方案。”多 Agent 编排具体是怎么做的“Team 模式下有三个角色。”“规划器负责把任务拆解成带依赖关系的执行计划只动脑子不动手不调任何工具。Worker 是干活的角色有独立的对话历史和完整的工具集同一批没有依赖的任务可以分给不同的 Worker 并行执行默认最多 2 个 Worker 同时工作。审查器负责质量把关Worker 干完活之后审查器检查产出不合格就打回重做最多打回 2 次。”每个子 Agent 的区别是什么“区别在两个维度系统提示词和对话历史。”“每个角色有专属的系统提示词通过不同的模式加载——规划器的提示词告诉它’你只负责拆解任务不许调工具’Worker 的提示词告诉它’你负责执行具体步骤工具随便用’审查器的提示词告诉它’你负责检查质量给出通过或打回的判断’。”“对话历史完全隔离。每个角色只看得到自己的交互记录Worker-1 不知道 Worker-2 在干什么审查器也看不到规划器是怎么想的。每个角色只关注自己职责范围内的信息上下文干净不容易互相干扰。”为什么这么设计能不能所有的子 Agent 共享工具“工具本身是共享的。三个角色用的是同一个工具注册表11 个核心工具加上 MCP 动态工具技术上所有角色都能访问到。”“但规划器和审查器不调工具这是通过提示词约束的不是技术上做不到。设计上故意不让它们碰工具原因是角色隔离——如果审查器有工具执行权限它发现 Worker 的代码有问题可能会自己动手去改。改完之后它再审查自己改的代码那就是既当运动员又当裁判了。”“工具执行权集中在 Worker 手里规划器和审查器只做判断。出了问题也好定位——代码写得不对找 Worker计划拆得不合理找规划器漏检了找审查器职责边界清清楚楚。”学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
看到这样一则爆料。在携程 4 年月薪 30000 左右研发岗基本是没有涨薪了。不过这么多年还是挺满足的毕竟稳定福利待遇也不错。截图来自职级对标网在如今这个快节奏的 AI 时代能说出“满足”两个字的人我是真的佩服。看看你的周围是不是每个人都在卷早上出了个新模型要测测中午出了个新 Work 要试试。整个行业的节奏快得像在赶末班车每个人都马不停蹄地、拼了命地往前冲。但这位老哥说满足稳定福利不错。深得我心啊。这两年 AI 把节奏拉得太快了快到大家忘了一件事——人还应该有生活。准时下班、周末不加班、半夜不用回消息这些更应该是我们追求的不是吗要我说稳定才是最好的学习姿势。反正我只有在外界环境都顺风顺水的状态下才有心情工作才想去学习新东西。如果你也渴望稳定同时又想在稳定的心态和节奏下学一些新的 AI 知识那接下来这些 Agent 面试题可以好好读一读。全文比较肝保证大家能学到很多很多系好安全带我们粗粗粗粗发contentPSPaiCLI 是一个类 Claude Code 的终端 Agent已开源。如果你想拥有一个 Agent 的项目经验可以参考。GitHub: https://github.com/itwanger/PaiCLI-Python01、Claude Code 与 Codex 各自有什么特别老王翻开面试题直接问“Claude Code 和 Codex 你都用过吗各自有什么特别的地方”“都用过。这两个产品方向完全不一样。”“Claude Code 是 Anthropic 做的终端 Agent最大的特点是实时交互和 AI 时代完美契合不需要 IDE 就可以完成 Coding 工作。在终端里给它任务然后读代码、改文件、跑命令整个过程全程可见并且随时可以打断、纠正。就目前来说Claude Code 就是最强的终端 Agent没有之一。”“Codex 是 OpenAI 做的桌面端 Agent走的是异步多线程可视化比 Claude Code 更强。”“我个人是两者的重度用户Claude Code 配合 Opus 模型在文本领域更强整体架构能力上更强。Codex 我更喜欢配合 GPT-5.6 Sol 做代码开发和生图特别消耗 Token 的任务也会交给它。”02、输入到模型的 prompt 由哪些部分组成“你做的 Agent输入到模型的 prompt 是怎么组装的哪些部分是必须注入的哪些不是”“prompt 组装用的是分层拼接一共 9 层按固定顺序拼进去。”“前 4 层是静态的整个会话期间不变。”第一层是身份定义包括工具的 schema、安全策略、行为守则这一层是必须注入的没有它模型连自己是谁都不知道更不知道能用什么工具。第二层是人格层控制语气和风格。第三层是模式层根据当前执行路径加载不同的指令集ReAct、Plan、Team 三种模式各一套。第四层是审批层定义哪些工具调用需要用户确认。“后 5 层是动态的每轮都可能变。运行时上下文日期、时区、项目记忆、Skills 索引、上下文管理策略、收尾指令。”“必须注入的是身份层和模式层——模型必须知道自己是谁、当前在什么执行模式下工作。人格层、Skills 索引、项目记忆这些不是必须的没有它们模型照样能干活但体验会差不少。比如没有 Skills 索引模型就不知道有哪些现成的技能可以加载遇到问题只能靠自己硬想。”为什么静态内容要排在最前面“因为 Prompt Caching。”“Prompt Caching 会按最长公共前缀命中。前 4 层是静态内容放在提示词最前面每轮请求的前缀都一样缓存命中率能拉到最高。如果把动态内容插到前面前缀每轮都变缓存基本不会中token 成本会高出好几倍。”03、你做的 coding agent 和 Claude Code 与 Codex 区别在哪“Claude Code 是终端 Agent 的标杆。”但我在使用这些工具的过程中产生了一个疑问——这些工具底层到底是怎么工作的它是怎么理解我的指令的、怎么决定该读哪个文件的、怎么判断该调用什么工具的、多轮对话的上下文它是怎么管理的。我发现如果我只会用这些工具但不理解它们的底层设计遇到工具表现不好的时候比如 Agent 选错了工具、上下文丢失了关键信息、生成的代码跟项目风格不一致我只能试着换个说法重新问而不能从原理层面判断问题出在哪里。所以我决定自己从零实现一个 Agent CLI把 ReAct 推理循环、Tool Calling、Memory 管理、MCP 协议这些核心模块都自己写一遍。做完之后我对 Agent 系统的每一层都有了源码级的理解再回去用 Claude Code 的时候我能明显感觉到我对工具的驾驭能力提升了——我知道什么样的指令能让 Agent 更准确地理解我的意图、我知道在什么场景下应该手动压缩上下文、我知道怎么设计 Tool 的描述信息能提高调用准确率。04、上下文压缩是怎么做的老王往前倾了倾身子继续问“你提到了上下文压缩具体是怎么做的”“三层压缩每一层处理不同粒度的内容。”“第一层是工具结果截断。单次工具返回的内容如果超过阈值——比如 grep 一下出来几千行——直接截断保留首尾和关键信息中间用摘要替代。这一层是即时生效的工具一返回就处理。”“第二层是对话历史摘要。当整个对话的 token 数接近上下文窗口的上限时保留最近几轮完整对话把更早的历史用 LLM 做一次摘要压缩。摘要会保留四类关键信息用户的核心诉求、Agent 已完成的操作、达成的共识、还没解决的待办。”“第三层是紧急降级。如果摘要压缩之后 token 数还是超限按优先级丢弃非核心上下文——Skills 索引、非关键记忆、项目记忆里优先级低的部分给核心对话腾空间。”05、为什么要采用三层压缩策略每一层压缩的内容一致吗“设计思路是粒度从细到粗触发条件从宽到严。”“第一层处理的是单条消息级别的冗余触发条件最宽松——每次工具返回都会检查超了就截。成本几乎为零不需要调 LLM。”“第二层处理的是对话历史级别的膨胀触发条件是 token 数超过上下文窗口的差不多 80%。200k 的窗口大概在 167k 左右触发。这一层要调一次 LLM 做摘要有成本所以不会太频繁。”“第三层是最后防线只在前两层都不够用的时候才启动。丢弃的是可恢复的辅助信息——Skills 索引可以重新加载、项目记忆可以重新检索——核心对话内容不到万不得已不动。”“三层压缩的内容完全不一样。第一层压的是工具输出第二层压的是对话历史第三层丢的是辅助上下文。如果只用一层笼统地压缩要么压得太早浪费上下文空间要么压得太晚直接超限报错。”06、压缩过度效果不理想怎么发现怎么处理“靠两个信号。”“第一个是行为异常。模型开始重复做已经做过的事情——比如读一个文件明明十分钟前已经读过了又读了一遍。或者模型直接说’我不太清楚之前讨论了什么’这就是压缩把关键信息压丢了。”“第二个是任务成功率下降。同样类型的任务之前能完成压缩几轮之后开始失败大概率是上下文丢了关键内容。”“处理有三个手段。”第一动态调整保留轮数。默认保留最近 3 轮不压缩如果检测到异常临时扩大到 5 轮。第二关键信息标注。用户明确给出的需求、已确认的技术方案标记为不可压缩摘要的时候跳过。第三压缩前备份原始历史发现效果不好可以回滚到压缩前的状态用更保守的策略重新压。07、增量修改系统怎么做需要重新注入哪些信息“走的是 Plan 审查机制。”“Agent 生成执行计划之后用户可以审查。如果需要加新功能用户选择’补充需求’把新的需求描述传进去。系统拿着原计划和新需求一起交给规划器让它重新生成一份计划。”“重新注入的信息有三块原始任务描述、已完成步骤的摘要、新需求的补充说明。已完成的步骤不会重新执行规划器基于当前进度来安排后续的步骤。”为什么不直接在原计划上追加而要重新规划“因为新需求可能改变已有任务的依赖关系。”“举个例子原计划是’先创建数据库表再写 CRUD 接口’。用户补充说’加一个缓存层’。这不是简单地在后面追加一个缓存任务——CRUD 接口的实现逻辑要改读操作要先查缓存再查库写操作要同步更新缓存。直接追加的话前面已经写好的接口代码就不对了。”“重新规划让规划器看到全貌重新安排依赖和执行顺序避免后续步骤建立在错误的前提上。”08、工具调用的流程是怎样的老王翻了一页笔记继续问“工具调用这块讲讲完整流程是什么”“三个阶段。”“第一阶段LLM 生成 tool_call。模型看到工具的 schema 定义之后根据当前任务决定调哪个工具、传什么参数输出一个结构化的 tool_call 请求。”“第二阶段策略审批。写操作改文件、跑命令会过一道安全检查——路径是否在允许范围内、命令是否在黑名单里。需要用户确认的操作会暂停等审批通过。”“第三阶段执行。单个工具直接执行多个工具可以并行跑线程池上限 4 个并发。执行结果作为 tool 消息追加到对话历史里LLM 拿到结果之后再决定下一步。整个过程是一个循环生成 → 审批 → 执行 → 结果回到模型 → 继续生成直到模型认为任务完成。”能不能用 Skill 替代工具不能两个东西完全不一样。维度Tool工具Skill技能本质可执行能力——读文件、跑命令、搜代码决策知识——怎么用工具、什么策略、什么规范调用方式LLM 通过 tool_call 协议调用LLM 调用 load_skill内容注入下一轮消息返回内容结构化结果文件内容、命令输出Markdown 指令提示词级别的知识生命周期单次调用用完即走加载后驻留在上下文里持续影响后续决策“Tool 是手Skill 是脑子里的经验。你不能用经验代替手去拧螺丝也不能用手代替经验去判断该拧哪颗。两个是互补关系不是替代关系。”09、讲讲你的 Skills 有哪些“核心设计思路是渐进式披露分三层加载。”“第一层是索引。只把 Skill 的名称和一句话描述放进 system prompt控制在 4KB 以内最多 20 个 Skill。这一层常驻上下文成本很低。”“第二层是正文。LLM 看到索引后判断当前任务需要哪个 Skill调一个 load_skill 工具把完整指令拿进来单个 Skill 正文上限 5KB。加载进来的 Skill 放在一个 LRU 缓冲区里最多同时持有 3 个超出的按最久未使用淘汰。”“第三层是参考文档。部分 Skill 自带参考文档目录只在 Skill 指令明确要求的时候才加载。”为什么不一次性全量加载因为 system prompt 越长Prompt Caching 命中率越低。绝大多数对话只会用到一两个 Skill全量加载等于让用户为用不到的内容付 token 成本。“Skill 来源有三个优先级内置的、用户级的、项目级的从低到高覆盖。项目级的 Skill 可以覆盖内置同名 Skill 的行为不用改源码。”10、工具调用时模型用了几次Skill 用了几次“这个跟任务复杂度有关说个典型场景。”“比如’帮我在项目里加一个分页接口’这种任务模型差不多要调 10 到 15 次工具——读项目结构、读已有接口代码、读数据库模型、写新接口、写测试、跑测试、修 bug每一步都是一次工具调用。Skill 的话可能就加载了一个代码规范相关的 Skill一次。”“工具调用频率远高于 Skill 加载差不多 10:1 到 20:1 的比例。这也是为什么 Skill 要做渐进式加载——使用频率不像工具那么高没必要全部常驻上下文。”场景题11、面向一个复杂任务你的 coding agent 的 plan 是怎么做的老王合上笔帽换了个方向“来道场景题。如果来了一个复杂任务你的 Agent 会怎么做 plan”“先判断任务是不是真的需要 plan。简单任务——比如’把这个变量名改一下’——直接走 ReAct 模式一步到位不需要规划。”“复杂任务走 Plan-and-Execute 模式。规划器接收用户任务之后生成一个带依赖关系的 JSON 计划。每个子任务有 id、描述、类型和依赖列表。”“计划生成之后先做拓扑排序确认没有环依赖。然后按依赖关系分批执行——没有依赖的任务可以并行跑有依赖的等前置任务完成再启动。”“用户可以在执行前审查计划觉得不对可以调整也可以补充需求让规划器重新出方案。”多 Agent 编排具体是怎么做的“Team 模式下有三个角色。”“规划器负责把任务拆解成带依赖关系的执行计划只动脑子不动手不调任何工具。Worker 是干活的角色有独立的对话历史和完整的工具集同一批没有依赖的任务可以分给不同的 Worker 并行执行默认最多 2 个 Worker 同时工作。审查器负责质量把关Worker 干完活之后审查器检查产出不合格就打回重做最多打回 2 次。”每个子 Agent 的区别是什么“区别在两个维度系统提示词和对话历史。”“每个角色有专属的系统提示词通过不同的模式加载——规划器的提示词告诉它’你只负责拆解任务不许调工具’Worker 的提示词告诉它’你负责执行具体步骤工具随便用’审查器的提示词告诉它’你负责检查质量给出通过或打回的判断’。”“对话历史完全隔离。每个角色只看得到自己的交互记录Worker-1 不知道 Worker-2 在干什么审查器也看不到规划器是怎么想的。每个角色只关注自己职责范围内的信息上下文干净不容易互相干扰。”为什么这么设计能不能所有的子 Agent 共享工具“工具本身是共享的。三个角色用的是同一个工具注册表11 个核心工具加上 MCP 动态工具技术上所有角色都能访问到。”“但规划器和审查器不调工具这是通过提示词约束的不是技术上做不到。设计上故意不让它们碰工具原因是角色隔离——如果审查器有工具执行权限它发现 Worker 的代码有问题可能会自己动手去改。改完之后它再审查自己改的代码那就是既当运动员又当裁判了。”“工具执行权集中在 Worker 手里规划器和审查器只做判断。出了问题也好定位——代码写得不对找 Worker计划拆得不合理找规划器漏检了找审查器职责边界清清楚楚。”学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
