本文深入剖析了LLM Agent的核心结构指出其并非简单的聊天机器人加工具而是一个完整的控制系统。文章基于Princeton团队实验展示通过优化接口设计模型性能可大幅提升。详细解读了Agent的感知、决策、行动、反馈四层结构并结合CoALA框架分析了每一层的工程实现和设计原则。同时文章还探讨了Workflow与Agent的选择、记忆架构、上下文管理、任务分解、工具设计、动态加载、安全边界、代码执行、反馈机制、自我反思、错误恢复以及人机协作等关键问题并提供了一套完整的工程实践Checklist旨在帮助开发者构建高效、可靠的LLM Agent系统。Agent 不是 ChatBot 工具2024 年Princeton 团队做了一个实验把 GPT-4 接入 SWE-bench一个真实的 GitHub Issue 修复基准模型没换训练数据没动只改了一件事——接入模型的那套接口重新设计了一遍。通过率从 3.8% 跳到了 12.5%。同年Anthropic 把 Claude 3.5 Sonnet 接入一套精简框架两个工具Bash Edit加一条约束强制绝对路径。SWE-bench Verified 得分49%。同一个模型从 3.8% 到 49%。差距不在模型在结构。Agent 不是聊天机器人加了几个工具。它是一个控制系统。核心问题不是怎么生成更好的回答而是怎么在开放环境中持续完成目标。控制系统有一个经典结构传感器采集信息 → 控制器做出决策 → 执行器改变环境 → 反馈回路检验效果。这个结构在工业控制、机器人、自动驾驶中反复出现因为它是任何需要在不确定环境中持续运行的系统的最小完备架构。LLM Agent 也收敛到了同样的结构感知 → 决策 → 行动 → 反馈 → 感知 → ...这篇文章拆解这四层每一层在做什么为什么这么设计工程上怎么落地。全局框架CoALA 与四层闭环1.1 CoALA给 Agent 一个形式化的骨架2023 年CoALACognitive Architectures for Language Agents试图回答一个问题所有 LLM Agent 的共同结构是什么答案是三个组件记忆分为工作记忆当前上下文窗口里的内容和长期记忆外部存储。长期记忆又分三种• 程序性记忆怎么做事技能、流程• 语义记忆知道什么事实、知识库• 情节性记忆经历过什么过去的成功和失败动作空间Agent 能做的所有事情分为内部动作推理、检索、写入记忆和外部动作调用工具、与环境交互。决策过程从动作空间中选择下一步的机制。三者组合起来构成一个完整的认知架构。任何 Agent 系统不管它用什么框架、什么模型都可以用这套词汇来描述和分析。1.2 四层映射CoALA 的形式化与控制论的四层闭环之间存在清晰的对应层CoALA 对应核心问题工程关注点感知工作记忆的输入模型能看见什么观察格式、记忆检索、上下文管理决策决策过程下一步做什么推理链、规划策略、搜索算法行动外部动作空间对环境做什么工具定义、执行沙箱、权限控制反馈观察 → 记忆更新做对了没结果验证、反思机制、错误恢复四层各有独立的工程问题也有跨层的耦合关系后面逐层展开最后再讲耦合。1.3 Workflow vs Agent什么时候用哪个Anthropic 在工程指南中做了一个关键区分Workflow编排型LLM 和工具通过预定义的代码路径编排步骤确定开发者写死了流程适合定义清晰的任务。Agent自主型LLM 动态决定自己的执行路径和工具使用步骤不可预测模型自己选择下一步适合开放式问题。选择原则从最简单的方案开始。Workflow 提供可预测性和一致性Agent 提供灵活性但代价是更高的成本、更难调试、错误会复利累积。只在复杂度确实需要时才升级到 Agent。五种 Workflow 模式复杂度递增Prompt Chaining顺序执行每步的输出是下一步的输入Routing根据输入类型分发到不同处理路径Parallelization拆成独立子任务并行处理Orchestrator-Workers中心 LLM 动态拆任务、分配、合并Evaluator-Optimizer一个生成一个评估迭代改进大多数生产系统用 Workflow 就够了能解决的问题就不要上 Agent。感知层模型能看见什么核心矛盾上下文窗口有限而环境信息无限。模型不能直接看见环境它看见的是喂给它的文本。感知层的设计决定了模型能理解什么、会忽略什么、在哪里犯错。2.1 观察格式设计Agent-Computer InterfaceSWE-agent 的实验揭示了一个反直觉的事实同一个模型仅仅改变它与环境交互的接口格式性能就能翻倍。这个发现催生了一个概念ACIAgent-Computer Interface。就像 HCI 为人类设计界面ACI 为 LLM 设计界面。两者的需求完全不同人类需要视觉、空间、交互LLM 需要文本、顺序且受限于上下文窗口。三条设计原则最小认知开销用模型在训练数据中自然见过的格式。Markdown 表格比自定义 XML 好带行号的代码比纯代码好结构化错误信息比 raw stack trace 好。先给上下文再要求精确输出不要上来就问第 47 行应该改成什么——先展示第 40-55 行的代码再问。模型需要足够的 token 看清楚才能给出精确答案。防错设计强制绝对路径消灭相对路径错误用枚举参数替代自由文本在工具定义里写清楚不要做 X。Anthropic 在 SWE-bench 开发中发现花在工具接口设计上的时间比花在 prompt 上的时间更有价值。一个具体的例子是文件浏览给模型看整个 2000 行文件它会迷失在中间给它一个分页查看器每次 100 行带行号带当前位置标记它能准确定位问题。这就是 ACI 设计的差距。2.2 记忆架构三层模型Lilian Weng 在综述中提出了 Agent 记忆的三层模型对应人类认知科学中的记忆分类感知记忆Sensory Memory原始输入的第一层处理。对 Agent 来说就是 API 返回的 raw JSON、终端输出的原始文本、截图的像素数据。持续时间极短很快要么进入短期记忆要么被丢弃。短期记忆Short-term / Working Memory也就是上下文窗口快但有限。128K token 看起来很多但对一个需要跨越几十个文件、几百次工具调用的长任务来说很快就不够了。长期记忆Long-term Memory外部存储包括向量数据库、文件系统、结构化数据库。容量无限但检索有延迟且检索质量不稳定。工程实现上每层对应不同的技术方案层实现特点感知记忆工具输出格式化ACI 设计管这里短期记忆上下文窗口管理压缩、裁剪、摘要长期记忆RAG / 文件系统 / KV Store需要检索策略Agent Patterns Atlas 提供了几个记忆相关的工程模式•Filesystem as Context把工作状态写入文件每次读取最新版本。文件系统本身就是一种外部记忆。Voyager 的技能库就是这个模式——成功的代码写入文件按描述索引下次检索复用。•Variables Manager显式追踪关键状态变量当前目标、已完成步骤、待验证假设而不是让模型从整个对话历史中隐式推断。•RAG语义检索适合知识库查询但对状态追踪不太适用。2.3 上下文管理对抗信息腐化上下文窗口有一个不直觉的性质不是越长越好。Stanford 的Lost in the Middle研究发现当关键信息落在长上下文的中间位置时模型检索性能下降 30% 以上。即使窗口足够大模型的注意力分布也不均匀——开头和结尾的信息更容易被注意到。更严重的问题是上下文超过窗口容量约 40% 后性能开始急剧下降不是线性衰减是断崖式。Agent 在长任务中跑着跑着就不对了很多时候不是推理能力退化而是上下文已经腐化——充满了过时的工具输出、无关的中间步骤、早期的错误假设。五种生产级上下文管理策略1. 压缩把历史对话摘要化保留关键决策和未解决问题丢弃冗余的工具输出。ACON 研究表明优先保留推理链Thought而非原始工具输出Observationtoken 减少 26-54%准确率保持 95% 以上。2. 观察遮蔽JetBrains 的 Junie 实践隐藏旧的工具输出内容但保留工具调用记录可见。模型知道我之前运行了测试但不需要再看一遍完整的测试输出。3. JIT 检索不预加载整个代码库需要看文件时用 grep/glob/head 按需拉取。Claude Code 的实践95% 的上下文节省来自按需加载而非全量预加载。4. 工具输出卸载2000 行的日志不塞进上下文写入文件系统上下文里只保留一句摘要和文件路径需要时再读取特定部分。5. 注意力工程把最关键的信息放在 prompt 的开头和结尾。系统指令放最前面当前任务放最后面中间是可以被忽略的历史。决策层模型怎么选择下一步核心矛盾搜索空间指数爆炸而计算预算有限。每一步决策模型面对的是一个巨大的动作空间调用哪个工具、传什么参数、还是先推理一下、还是回头检查之前的假设。决策层的设计决定了 Agent 在这个空间里怎么搜索、搜索多深、什么时候停下来。3.1 执行循环的三代演化Agent 的决策机制经历了三代演化每代增加了计算成本也抬高了能力上限。第一代ReAct2023ReAct 确立了至今所有 Agent 的基础循环Thought → Action → Observation。Thought: 我需要找到这个函数的定义Action: Search[def calculate_total]Observation: Found in src/billing.py, line 47-62Thought: 看到了问题在第 53 行的类型转换Action: Edit[src/billing.py, line 53, ...]Observation: File updated successfully推理和行动必须交替进行。纯推理Chain-of-Thought会产生幻觉模型编造不存在的事实纯行动无 Thought 直接调用工具会盲目执行模型不知道为什么要做这一步。ReAct 通过显式的 Thought 步骤迫使模型先说清楚我为什么做这一步再通过 Observation 用真实的环境反馈纠正推理。HotpotQA 上的幻觉率从 56% 降到接近 0%。但 ReAct 有一个局限它是单线的每一步做完就往前走不回头。如果某一步走错了后面所有步骤都建立在错误的基础上。第二代Reflexion2023Reflexion 在 ReAct 的基础上加了一层如果任务失败了不是简单重试而是先反思为什么失败了把反思结果写入记忆下次避免同样的错误。Trial 1: 尝试 → 失败测试不通过 ↓反思: 我没有考虑到空数组的边界情况 ↓存入 episodic memory ↓Trial 2: 读取反思 → 调整方案 → 尝试 → 成功这是一种语言强化学习——不需要更新模型权重用自然语言作为学习的介质。HumanEval代码生成的 pass1 从 67% 提升到 91%。但 Reflexion 也有局限它只能在失败后学习。对于需要在行动前就深度规划的问题比如博弈、优化它仍然是被动的。第三代LATS2024LATSLanguage Agent Tree Search把蒙特卡洛树搜索MCTS引入 Agent 决策。不再是单线执行而是构建一棵搜索树Root: 当前状态├── Action A (评估分: 0.7)│ ├── Action A1 (0.9) ← 最佳路径│ └── Action A2 (0.3) ← 被剪枝├── Action B (0.4) ← 低分不展开└── Action C (0.6) └── ...LLM 承担三个角色• 生成候选动作树的展开• 评估状态好坏价值函数• 失败时生成反思指导未来搜索方向HumanEval 达到 92.7% pass1。但代价是巨大的——每一步决策需要多次 LLM 调用生成 评估 可能的反思成本是 ReAct 的 5-10 倍。三代对比代方法循环结构计算代价适用场景1ReActThink → Act → Observe低1次调用/步常规任务2Reflexion执行 → 失败 → 反思 → 重试中失败时额外调用需从错误中学习3LATS多路搜索 评估 回溯高多次调用/步高价值复杂决策3.2 任务分解把大问题变成小问题一个复杂任务“修复这个 bug”如果不拆分模型要在一个巨大的搜索空间中找到完整路径。拆分后“1. 定位错误 2. 理解原因 3. 写修复 4. 写测试 5. 验证”每一步的搜索空间大幅缩小。几种分解策略Orchestrator-Workers一个中心 LLM 负责拆任务和分配多个 worker 执行具体子任务最后中心 LLM 合并结果适合子任务之间相对独立的情况如多文件修改。极端分解Agent Patterns Atlas每一步只做一件最小的、可验证的事。不是实现登录功能而是创建 login 函数签名 → 实现参数验证 → 实现数据库查询 → 实现返回值 → 写测试每步完成后立刻验证错误不会累积。自动课程VoyagerAgent 自己生成下一个目标不需要人类预定义任务列表。Voyager 在 Minecraft 中根据当前状态和已有技能自动生成下一个值得尝试的事情灵活但也最难控制。Routing根据输入类型分流到不同的专用路径。客服系统根据问题类型退款/技术/咨询路由到不同的处理 Agent。3.3 规划的工程权衡过度规划是一个常见错误。模型花了 10 步生成了一个完美的计划然后第 2 步的执行结果就偏离了计划的假设后面 8 步全部作废。Anthropic 的工程原则直接从最简单的方案开始。实际的选择逻辑• 任务步骤固定→ 用 Prompt Chaining确定性流程• 步骤不固定但可收敛→ 用 ReAct单步循环随时调整• 子任务明确可独立→ 用 Orchestrator-Workers分治• 高价值且可回溯→ 用 LATS搜索树• 完全开放式→ 用自动课程让 Agent 自己定义目标一条经验规则如果 Agent 花了 30% 以上的 token 在规划上而不是执行上规划粒度可能太细了降低粒度让执行层的反馈来指导后续方向。行动层模型能对环境做什么核心矛盾工具越多能力越强但误选率也越高。行动层定义了 Agent 的手——它能触达什么、改变什么。工具设计的好坏直接影响 Agent 能否把正确的决策转化为正确的执行。4.1 工具设计原则Anthropic 在 SWE-bench 开发中积累了一条核心经验花在工具设计上的时间应该超过花在 prompt 上的时间。五条设计原则1. 格式自然用模型训练数据中高频出现的格式。Markdown 比自定义 DSL 好JSON 比 YAML 好出现频率更高。函数名用英文动词名词search_files而不是fs_query_op。2. 文档完整工具描述不是给人看的是给模型看的。它需要一句话说清用途、参数的类型和约束、1-2 个使用示例、失败时返回什么、和相邻工具的区别“用edit_file修改已有文件用create_file创建新文件不要混用”。3. 防错设计强制绝对路径消灭当前目录是哪里的歧义参数用枚举而不是自由文本mode: append | overwrite而不是mode: string必填参数和可选参数明确区分。4. 输出可读工具的返回值是 Agent 的感知输入。一个返回 5000 行 raw JSON 的工具等于给 Agent 塞了一堆噪音。结构化、摘要化、只返回 Agent 需要的信息。5. 边界清晰每个工具做一件事工具之间不重叠。如果两个工具的使用场景模糊“什么时候用 search 什么时候用 grep”模型就会出错。可用工具超过 30 个时模型的工具选择准确率开始明显下滑。改用动态加载每步只暴露 Top 5-10 个最相关的工具准确率提升约 30%。4.2 动态工具管理在一个复杂的 Agent 系统中可能有几十个甚至上百个工具。全部塞进 prompt上下文爆炸全部隐藏Agent 不知道自己能做什么。几种平衡策略静态全量暴露简单适合工具数 10 的场景。所有工具的 schema 始终在 prompt 里模型随时知道自己的全部能力但随着工具增加prompt 越来越长噪音越来越大。动态加载根据当前任务阶段只暴露相关的工具子集。写代码时暴露文件操作工具运行测试时暴露执行工具搜索时暴露搜索工具。Vercel 在 v0 中删掉了 80% 的工具反而得到了更好的结果。Skill DiscoveryAgent Patterns AtlasAgent 运行时自行发现可用工具不是预定义工具列表而是通过查询一个工具注册表来获取当前可用的能力适合工具集合会动态变化的场景如 MCP 服务器连接/断开。技能库Voyager最激进的方案Agent 不仅使用预定义工具还能创造新工具。Voyager 把执行成功的代码片段自动存入技能库下次遇到类似任务时检索复用工具集合随着 Agent 的经验增长而增长。4.3 行动的安全边界Agent 能做的事越多出错的后果就越严重行动层必须有安全机制。沙箱执行文件操作限制在特定目录网络请求限制白名单代码执行在容器中Agent 不能触达它不应该触达的东西。权限最小化Constrained Tool UseAgent 只能用完成当前任务所需的最小工具集不需要删除文件的任务就不暴露删除工具。不可逆操作确认删除、发布、支付这类操作在执行前必须经过人类确认。错误的代价不对称这是结构性要求不是信任问题。Handoff 机制OpenAI Agents SDK当一个 Agent 判断当前任务超出自己能力范围时把控制权转移给另一个更合适的 Agent转移时携带完整的对话历史确保上下文不丢失。4.4 代码即行动Voyager 引入了一种不同于 JSON 工具调用的行动方式直接生成可执行代码。传统方式{tool: move_to, args: {x: 100, y: 64, z: 200}}{tool: mine_block, args: {block_type: diamond_ore}}Voyager 方式async function mineDiamonds(bot) { await bot.navigate(100, 64, 200); const block bot.findBlock(diamond_ore, 5); if (block) await bot.dig(block);}代码的优势•组合性复杂行为由简单函数组合不需要为每种组合定义新工具•可验证代码可以运行、可以测试、可以 type check•可存储成功的代码直接入库变成新的技能代价是需要更严格的沙箱。JSON 工具调用的安全边界很清晰参数验证就够了代码执行的安全边界需要容器级别的隔离。反馈层模型怎么知道做对了核心矛盾即时反馈便宜但浅层深层反馈有价值但贵。没有反馈的 Agent 是一个开环系统它不知道自己的行动产生了什么效果只能盲目前进错误会累积一步错步步错。反馈层闭合了这个环路让 Agent 能够感知行动的结果并据此调整。5.1 反馈信号的层次不同类型的反馈在延迟、成本和可靠性上差异巨大类型来源延迟可靠性成本执行反馈编译器、测试、API 返回码即时高确定性低环境反馈状态变化观察秒级中低评估反馈另一个 LLM 评判秒级中有偏差中反思反馈模型自我审视秒级低可能过度纠正中人类反馈用户确认/纠正分钟~小时高高工程原则能用确定性验证就不用 LLM 判断能用 LLM 判断就不打扰人类。5.2 验证机制Anthropic 推荐三类验证方式规则验证测试通过了吗类型检查过了吗Linter 有没有报错这是最可靠的反馈——确定性的、无偏差的、成本几乎为零。代码任务几乎都有规则验证的条件优先用它。视觉验证UI 任务中用 Playwright 截图让模型或另一个评估器判断界面是否符合预期适合无法用代码断言的视觉结果。语义验证LLM-as-Judge用一个独立的 LLM最好是不同的模型或不同的 prompt来评估结果质量适合开放式任务“这段代码的可读性好不好”。Claude Code 的实践验证了这一点给模型一种验证自己工作的方式哪怕只是运行测试质量提升 2-3 倍。Evaluator-Optimizer 模式把验证做成迭代循环。一个 LLM 生成结果另一个 LLM 评估并给出改进建议然后第一个根据建议修改适合翻译、写作等需要打磨的任务。5.3 自我反思强大但危险Reflexion 证明了自我反思的价值——Agent 在失败后生成文本反思存入记忆下次避免同样的错误。HumanEval 从 67% 到 91%。但反思有一个被低估的风险过度自我纠正。研究发现当模型被指示再检查一下你的答案时在 58% 的情况下它会把原本正确的答案改成错误的。这不是 bug而是反思机制的结构性问题——模型倾向于找到问题来证明反思是有意义的即使实际上没有问题。工程实践中的约束•限制反思次数最多 2-3 次无限反思不会收敛只会震荡。•区分信心低和确认出错信心低但无外部证据表明出错就不反思只有外部反馈测试失败、用户否定明确表明出错时才触发反思。•外部验证优先能用测试验证的就跑测试不要让模型自己判断自己对不对。编译器永远比内省可靠。5.4 错误恢复不要从头重来AgentDebug2025的核心洞察当 Agent 失败时不要从头重跑整个任务先定位失败点在执行链的哪个位置然后只从那个点重新执行。两类根因•记忆错误Agent 忘了关键信息上下文被截断、检索没命中→ 修复补充记忆从遗忘点重跑•推理错误Agent 从正确信息中得出了错误结论 → 修复换推理策略从错误决策点重跑效果成功率提升 26%。错误分类决定恢复策略错误类型策略示例瞬态重试指数退避API 超时、限流语义换策略模型被内容过滤阻断 → 改写 prompt规划从当前状态重新规划原计划不可行记忆重新检索上下文关键信息丢失不可恢复升级到人类任务本身不可能VIGIL2025更进一步运行时持续监控 Agent 行为检测到异常循环、延迟飙升、输出退化时自动诊断并生成修复方案不需要等到任务完全失败。5.5 人机协作架构的一部分不是兜底Human-in-the-Loop 不是Agent 不行了找人帮忙它是架构设计的一部分——在特定的节点上人类介入是比自动化更优的选择。何时交给人类•不可逆操作前删除数据、发布上线、发送邮件•信心低于阈值模型不确定但又无法通过更多计算变得确定•检测到异常模式循环、矛盾、持续失败Red-Flagging•高价值决策影响大但频率低的判断人类检查点的位置应该预先设计好而不是失败了就问人。好的人机协作像高速公路上的收费站——在关键节点短暂停下确认而不是随时随地可能被打断。四层耦合一个完整的例子四层不是独立的用一个代码修复 Agent 的完整执行过程来展示它们之间的耦合任务修复一个 GitHub Issue——“用户注册时邮箱验证不生效”代码库的初始状态auth/register.py处理注册逻辑auth/validators.py里已有validate_email函数但register.py从未调用它。第一轮循环感知Agent 读取 Issue 描述 相关代码文件auth/register.py。ACI 设计决定了它看到的是带行号的代码片段而不是整个文件。决策ReActThought: Issue 提到邮箱验证不生效。我需要找到验证逻辑在哪里。Action: Search[email_validation in auth/]行动搜索工具执行返回auth/validators.py:23有一个validate_email函数。反馈环境反馈搜索成功返回结果→ 更新感知现在知道了验证函数的位置第二轮循环感知读取auth/validators.py的第 20-40 行。决策Thought: validate_email 函数存在但 register 函数没有调用它。问题在 register.py 而不是 validators.py。Action: Edit[auth/register.py, line 45, add: if not validate_email(email): raise ValidationError(...)]行动编辑工具执行修改。反馈运行测试 → 测试失败。Error: NameError: validate_email is not defined第三轮循环反思触发反馈 → 感知更新测试失败的错误信息进入上下文。Agent 同时触发 Reflexion“我忘了添加 import 语句。”决策Thought: 我需要在文件顶部 import validate_email。Action: Edit[auth/register.py, line 3, add: from auth.validators import validate_email]行动编辑执行。反馈运行测试 → 全部通过 ✓四层耦合关系耦合表现设计影响感知 × 决策搜索结果的格式直接影响推理质量ACI 设计决定了决策层的输入质量决策 × 行动添加验证的规划粒度必须匹配 Edit 工具的能力规划粒度要适配工具粒度行动 × 反馈Edit 的返回成功不够需要测试才能验证真正的正确性行动结果 ≠ 任务成功需要独立验证反馈 × 感知测试失败的错误信息 反思 下一轮的新感知反馈质量决定了下一轮感知的信息量如果四层之间的接口设计不匹配系统性能会远低于各层单独的能力。一个优秀的决策层配上一个返回 raw dump 的感知层整体表现会很差。SWE-agent 的实验证明了这一点——改善感知层的格式ACI在不改变决策层的情况下整体性能翻了 3 倍。工程实践 Checklist7.1 架构选择决策树你的任务步骤是否固定├── 是 → Workflow│ ├── 步骤独立→ Parallelization│ ├── 步骤有序→ Prompt Chaining│ └── 需要分流→ Routing└── 否 → 步骤数可预测吗 ├── 是 → Orchestrator-Workers └── 否 → Agent自主循环 ├── 常规任务 → ReAct ├── 需要从失败中学习 → Reflexion └── 高价值复杂决策 → LATS7.2 四层设计清单感知层• [ ] 观察格式是否用了模型训练数据中的自然格式• [ ] 长期记忆是否有语义检索机制• [ ] 是否有上下文压缩/裁剪策略• [ ] 关键信息是否放在 prompt 首尾• [ ] 工具输出是否结构化而非 raw dump决策层• [ ] 循环复杂度是否匹配任务复杂度不过度规划• [ ] 是否有任务分解一步不做太多事• [ ] 是否有终止条件最大轮次 token 预算• [ ] 失败时是否有回退策略行动层• [ ] 工具定义是否包含示例、边界、失败行为• [ ] 工具数量是否控制在 10 个以内或动态加载• [ ] 是否有执行沙箱• [ ] 不可逆操作是否有确认机制• [ ] 相似工具之间的边界是否写清楚了反馈层• [ ] 是否有确定性验证测试/编译/类型检查• [ ] 反思机制是否有次数限制≤3• [ ] 错误是否分类处理瞬态/语义/不可恢复• [ ] 是否有人类升级路径• [ ] 反馈信息是否足够具体定位到行/函数/原因7.3 常见坑与修复坑症状根因修复感知过载模型忽略关键信息、回答偏题上下文太长或格式混乱JIT 检索 注意力工程规划过深计划完美但执行偏离前几步的假设就错了用 ReAct 替代长期规划工具过多频繁选错工具工具描述重叠、数量超限动态加载 Top 5-10反思过度正确答案被改成错误无限自我怀疑限 2-3 次 外部验证优先无终止条件无限循环、成本失控缺少退出机制轮次上限 token 预算双保险反馈缺失错误累积不可逆每步执行后无验证每步验证 状态检查点层间不匹配各层单独可用但组合表现差接口格式不兼容检查各层的输入输出格式是否对齐最后对于正在迷茫择业、想转行提升或是刚入门的程序员、编程小白来说有一个问题几乎人人都在问未来10年什么领域的职业发展潜力最大答案只有一个人工智能尤其是大模型方向当下人工智能行业正处于爆发式增长期其中大模型相关岗位更是供不应求薪资待遇直接拉满——字节跳动作为AI领域的头部玩家给硕士毕业的优质AI人才含大模型相关方向开出的月基础工资高达5万—6万元即便是非“人才计划”的普通应聘者月基础工资也能稳定在4万元左右。再看阿里、腾讯两大互联网大厂非“人才计划”的AI相关岗位应聘者月基础工资也约有3万元远超其他行业同资历岗位的薪资水平对于程序员、小白来说无疑是绝佳的转型和提升赛道。如果你还不知道从何开始我自己整理一套全网最全最细的大模型零基础教程我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的大模型学习资源希望能帮到你。扫码免费领取全部内容最后1、大模型学习路线2、从0到进阶大模型学习视频教程从入门到进阶这里都有跟着老师学习事半功倍。3、 入门必看大模型学习书籍文档.pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里4、AI大模型最新行业报告2026最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】