在AI时代学会如何通过5-10个问题全面了解或解释一件事是一项关键技能。文章探讨了Agent架构与模型本身的重要性指出架构虽不能提升模型能力上限但能优化资源分配。文章还介绍了主流架构如ReAct和Plan-then-Execute的优缺点并强调了上下文工程、记忆系统和子agent在架构设计中的重要性。此外文章还分析了token经济学提醒评估架构改进时需对齐token预算。对于想要掌握大模型应用的开发者来说这些都是不可忽视的核心要素。首先把最近的一个关键发现分享给大家用5-10个问AI的问题把一件事情了解或者解说的相当完备是AI时代一个非常核心的技能会综合考虑你的结构化思考力和你对未知问题的把控力~因为AI的到来未来80%你将要面对场景是未知的领域而过去可能80%的场景都是你熟悉的领域AI帮人极大的扩展的知识和技能的边界~Agent架构到底有多重要还是模型本身更重要目前有两种观点一种是高估。 有人相信存在一套普适的最优架构选对了框架、摆对了角色、连对了图就能让能力平平的模型完成复杂任务。ServiceNow 的 AgentArcharXiv:2509.10769用一次彻底的消融实验回答了这个幻想18 种架构配置 × 6 个 LLM × 2 个企业级工作流正交地测试编排策略、ReAct 与 function calling、完整记忆与摘要记忆、思考工具的开关。结论有三条每一条都很扫兴——不存在跨模型通用的最优架构在复杂任务上最好的配置也只有 35.3% 的 pass1同一个架构选择在不同模型上会优劣翻转function calling 平均优于 ReAct但在 GPT-4.1-mini 上反过来。另一种是低估。 也有人相信架构只是模型的包装纸模型一强就全都不重要了。这同样被数据否定。OpenAI 在《Introducing SWE-bench Verified》中给出过一组极干净的对照同一个 GPT-4o在 SWE-Agent 脚手架下得 23%在 Agentless 脚手架下得 33.2%——换掉架构凭空多出 10.2 个百分点。架构不能提升模型的能力上限但它决定了你要花多少钱、冒多大风险、等多久才能逼近那个上限。 架构是一个资源分配问题不是一个能力问题。而所谓资源具体是四样东西上下文窗口、单步可靠性、外部反馈、token 预算。本文的全部内容都可以还原成这四者之间的交换。Anthropic 在《Building Effective Agents》里给出的区分至今仍是最实用的Workflow工作流LLM 与工具按预先编排好的代码路径执行。谁调用谁、调用几次、什么时候停都写死在代码里。Agent智能体LLM 自己动态决定下一步做什么、用什么工具循环持续到它认为任务完成。分界线不在用没用 LLM也不在有没有工具而在控制流的所有权。控制流归代码就是 workflow控制流归模型就是 agent。这个区分有直接的工程含义workflow 可预测、可测试、成本可估agent 灵活、能处理开放任务但成本和行为都是长尾分布。 后文会看到同一个 agent 任务在不同 run 之间token 消耗差异可达 30 倍。这不是 bug这是把控制流交给概率模型的必然代价。这篇论文还提出了一个被认为被严重低估的正交维度谁在驱动循环用户驱动Aider——每一轮都回到人类手上人决定下一步说什么脚手架驱动AutoCodeRover、Agentless——代码决定阶段推进LLM 只在每个阶段内做决策LLM 驱动OpenHands、Claude Code、Codex——模型自己决定循环何时继续、何时终止这三种驱动模式的可靠性、成本与心智负担完全不同而大多数架构讨论把它们混为一谈了。凡是我们的方案提升了 X%的数字先问三件事——基线是什么、token 预算是否对齐、评测集有没有被污染。1、最小内核MBZUAI VILA-Lab 那篇对 Claude Code 的逆向研究 Dive into Claude CodearXiv:2604.14228的第一个结论正是核心就是一个朴素的 while 循环真正的工程量全部落在这个循环的周边系统上——权限系统、多层压缩流水线、扩展机制、子 agent 委派、会话持久化。核心观点架构准则凡是不能违反的东西都不要写进 prompt。prompt 表达意图工具列表和权限门表达约束。权限门是一等运行时基础设施不是附加特性。在 agent 系统里工具的错误信息不是给人看的日志是给模型看的下一轮 prompt。LM agent 是一类新的终端用户。应该为它专门设计接口而不是复用给人类设计的 Linux shell。Agent 架构的设计几乎不发生在循环内部而全部发生在循环的周边。子 agent 的首要价值不是并行干活而是上下文隔离。如果只能留下三句一、Agent 架构不能提升模型的能力上限但它决定了你花多少钱、冒多大风险、等多久才能逼近那个上限二、设计任何循环之前先回答这个循环的 critic 是什么。答不上来就不要做这个循环三、复杂度应当是被基准逼出来的不是被想象出来的。每加一层自主性都要能指出它填上了哪个可测量的 gap2、流行的框架1 ReAct范式的起点与它的天花板ReActICLR 2023, arXiv:2210.03629的贡献是让推理Thought与行动Action交错使模型能基于观察调整计划。实证ALFWorld 上 71%对比 Act-only 的 45%、模仿学习基线 BUTLER 的 37%绝对提升 34 个百分点WebShop 上绝对提升 10 个百分点。ReAct 的问题今天已经很清楚在 HotpotQA 上单独的 ReAct 不如 CoT-SC作者自己就建议混合使用线性轨迹容易陷入循环——模型反复调用同一个失败的工具Thought本身消耗 token 且不总是有用——现代模型内建了 reasoning显式 Thought 字段常常是冗余的第三点在 AgentArch里得到了量化验证function calling 平均优于 ReAct而且更刺眼的是——multi-agent ReAct 是所有 18 种配置中唯一普遍最差的组合并且除 GPT-4o 外幻觉几乎只出现在 ReAct 配置中Sonnet 4 在 multi-agent ReAct 下幻觉率约 36%其他配置为 0%。这个发现的分量常被忽略ReAct 作为论文范式很成功作为 2026 年的生产默认值已经过时了。 现代模型经过原生 function calling 训练把推理硬塞进文本格式反而引入了解析脆弱性和幻觉面。2 Plan-then-Execute 的人因陷阱如果你打算靠人工审批计划来兜底CHI 2025 的一项研究arXiv:2502.01390 值得先读。N2486 类不同风险等级的任务。好消息用户介入确实能纠正不完善的计划和执行错误整体表现提升。坏消息而且是结构性的坏消息LLM 会产出结构漂亮但逻辑错误的计划而专家也会被自信的表述误导而批准它。错误在规划阶段就被固化下来了。这直接击中了人类是可靠 critic的假设。格式良好的输出会系统性地提高人类的信任度而格式与正确性无关。 这与DORA 报告提出的验证税(写代码省下的时间被审查代码重新花掉)、以及 Stack Overflow 调查里几乎正确但又不完全对是最大痛点66% 提及是同一个现象的三个侧面。另一个被这项研究点名的局限是静态计划的刚性中间步骤失败后没有调整机制。这也是我更看好活的待办清单的原因。3 token 经济学几组来自实测的数字Agentic 编码任务的输入输出比超过 150 : 1——成本主要来自反复重读上下文而不是产出的代码Agentic 任务相比普通 code chattoken 消耗高约 1000 倍同一任务在不同 run 之间token 差异可达 30 倍更高的 token 消耗并不稳定转化为更高的准确率Anthropic 披露单 agent 约耗普通对话的 4 倍 token多 agent 系统约 15 倍最后一条尤其关键因为 Anthropic 同时披露在 BrowseComp 上token 用量单独就解释了 80% 的性能方差。这是一把双刃剑——它意味着很多架构改进的收益其实只是多花了钱的收益。评估任何架构改进时必须对齐 token 预算。 一旦对齐预算多 agent 相对单 agent 的优势就基本消失了。3、核心组件1 上下文工程上下文是负债不是资产。工程师的直觉是上下文窗口越大越好能塞就多塞。Chroma 的技术报告 Context Rot2025 用一个极其干净的实验设计推翻了它固定任务难度只增加上下文长度测试 18 个前沿模型GPT-4.1、Claude 4、Gemini 2.5、Qwen3 系列。结果是 18 / 18 全部单调退化。而且不是接近窗口上限时才掉——8 个长度档位档档都掉声称支持 100 万 token 窗口的模型在 5 万 token 处已经出现明显退化。作者的归因是噪声累积而非容量耗尽。工程含义直接而残酷每往上下文里塞一个 token都在稀释模型对其余 token 的注意力。上下文预算应当像内存预算一样被主动管理而不是被动填满。2 记忆系统文件系统就是记忆这是过去两年最重要的一次范式收敛不要试图把状态塞进上下文把状态写到文件里让 agent 自己去读。具体形态包括待办清单Anthropic 明确把 Claude Code 的 to-do list 作为结构化记事的范例 【一手·厂商】。它的价值不只是给人看进度而是在每轮循环开头重新锚定意图——对抗长轨迹中的目标漂移项目约定文件CLAUDE.md / AGENTS.md 一类把这个项目怎么跑测试、代码风格是什么、什么不能碰固化下来避免每次重新发现工作产物落盘Anthropic 长任务方案里每轮留下清晰的 artifact 给下一轮本质是把跨轮次的状态传递从上下文携带改成文件系统握手这个思路的漂亮之处在于它同时缓解四个约束中的三个上下文更短约束一、状态不丢约束二、token 更省约束四。代价是引入了文件与上下文的一致性问题——agent 可能读到自己写的过期笔记。3 子 agent 作为上下文防火墙子 agent 可能烧掉几万 token 做探索但只回传 1000–2000 token 的浓缩摘要细节留在子上下文里不污染主循环。子 agent 的首要价值不是并行干活而是上下文隔离。这是一个纯粹的信息压缩比论证与多个 agent 协作更聪明完全是两回事。把这两件事混为一谈是最频繁的架构误判——用多 agent的复杂度去解决一个上下文太长的问题结果既没解决问题又引入了协调失败。4、主流方案横向拆解1codexCodex 当前实现有五个架构细节值得借鉴请求快照一致性 同一次采样所展示的工具和真正执行的工具共享同一个 StepContext避免模型看到 A 版本 schema、运行时却按 B 版本配置执行流式 item 与工具 future 解耦 模型流继续产生 item工具调用进入 in_flight 队列采样结束前 drain下一步只读取已提交的结果并发能力由工具声明 tool_supports_parallel 为真时拿共享锁否则拿独占锁。它把哪些调用可并行落实成运行时互斥而不是 prompt 建议读并行、写串行只是常见策略不是这个锁本身对工具语义的推断多 agent 是线程树 mailbox当前源码同时存在 V1V2 工具子 agent 可 spawn、接收输入、等待、列举、打断或关闭。此能力可能受模型、feature flag、协作模式和产品 surface 门控不能从主分支存在代码推断每个用户界面都默认开放原始证据与语义视图分离 opt-in 的 rollout-trace 先把 inference、tool dispatch、terminal、compaction 与子线程事件按 seq 追加到本地 bundle再由确定性 reducer 还原模型看到了什么和运行时实际做了什么。官方 README 把原则概括为 observe first, interpret later并明确提示 bundle 可能含 prompt、工具参数、终端输出和路径不能当普通遥测上传这也修正了云端并行只是多个独立任务的旧二分法Codex 既支持任务级独立并行当前 Core 也具备单个根任务内的子线程编排。两者的隔离、计费和失败传播边界不同不能混写成一个并行。5、一些使用的技巧背后的原理1loop背后怎么实现的定时任务又是怎么实现的考虑一个非常常见的请求“这个接口现在报错。30 分钟后再帮我看一下问题还存在吗”错误实现是让当前 agent loop sleep(1800)或者维持一条 HTTPSSE 连接等 30 分钟。这样会占住 worker进程退出后任务丢失无法取消也无法可靠判断是否重复执行。正确实现是把它拆成两个 run 一个持久 timerRun A 现在执行基线检查把问题是什么、怎样复现、当前证据是什么持久化Scheduler 保存一个 one-shot job把相对的30 分钟后立即解析成绝对 wake_atRun A 向用户返回 job ID、预计检查时间和取消方式然后彻底结束到点后 scheduler 原子 claim job启动新的 Run B或从一个明确 checkpoint 恢复Run B 用同一 probe 采集新证据与 baseline 比较输出 still_exists / resolved / unknown再投递给原用户。这个场景最容易被低估的地方是问题还存在吗本身没有可执行定义。登记 timer 前至少要固化下面这些字段到点后的结果必须是三态而不是二态still_existsprobe 成功且同一 predicate 仍为真resolvedprobe 成功且 predicate 已为假最好附新旧证据unknown认证过期、目标不可达、检查脚本漂移或证据不足。检查失败不能被解释成问题已消失如果目标系统能发 webhook、CI completion、日志告警或文件变更事件更好的设计是事件优先、timer 兜底先订阅目标事件事件到达立即唤醒30 分钟 timer 只是最晚复查点。Claude Code 当前的 dynamic /loop 也体现了这个模式background monitor 作为主唤醒信号timer 作为 fallback heartbeat若用户说的是每 30 分钟检查直到恢复那是另一个合同recurring job stop predicate 最大存活时间次数预算。one-shot recheck 与 recurring poll 不能混用否则一次提醒会变成无限账单。主流框架怎样放置这层Agent framework 决定醒来后怎样继续推理scheduler 决定何时可靠地把它叫醒。少数产品把两者打包但它们仍是两个状态机。2多agent架构具体是怎么做的单一的大模型LLM在面对复杂项目时常因为上下文窗口限制、幻觉、缺乏全局规划能力而崩溃。而多 Agent 架构通过“分工协作Divide and Conquer”和“标准化作业程序SOP”将复杂的软件工程任务拆解。最后当下AI大模型是当下实打实的优质风口岗位缺口大、发展前景广、薪资待遇突出对比内卷严重、涨薪晋升困难的传统技术岗是普通人转行逆袭的绝佳选择。但很多想要入局大模型领域的朋友都面临无系统学习路径、无实战资源、求职无方向的难题一个人硬啃最容易走弯路、浪费大量时间精力。这里我结合多年一线实战与教学经验整理出一套零基础大模型专属资料包含系统化学习路线图零基础到精通大模型学习书籍 文档电子版2026 最新行业报告项目实战 配套源码大厂面试真题需要的朋友微信扫描下方 CSDN 官方认证二维码免费领取保证 100% 免费。扫码免费领取全部内容下面简单介绍一下资料包含的内容1、大模型系统化学习路线图专属定制从零基础入门到企业级实战的全阶段学习体系划分清晰的四大学习阶段规避碎片化学习弊端适配新手2、0基础到进阶视频教程配套完整高清实操教程覆盖Prompt提示工程、RAG知识库搭建、Agent智能体开发、模型微调、部署落地等核心知识点所有课程搭配实操演示零基础也能轻松看懂、上手实操。3、大模型学习书籍 文档汇总30本行业经典AI、大模型、深度学习精选书籍涵盖理论原理、开发实战、算法基础、AI产品思维等各类内容4、AI大模型最新行业报告整理2024-2026年最新大模型行业白皮书、市场分析报告清晰展现行业发展趋势、技术迭代方向、岗位需求变化帮助学习者精准把握行业风口找准学习和就业方向5、大厂面试真题汇总了常见的AI大模型面试问题、知识点梳理和面经参考方便求职时针对性准备。6、大模型项目实战 配套源码包含GPT应用开发、RAG私有知识库、智能问答系统等多个企业级实战项目配套完整可运行源码从简易Demo到完整商业应用全覆盖帮助学习者将理论转化为落地实战能力积累项目经验。7、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。8、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料