写在前面欢迎大家关注Rocky的公众号WeThinkIn欢迎大家关注Rocky的知乎Rocky DingAIGC/LLM/AI Agent算法工程师/开发工程师面试面经秘籍分享WeThinkIn/Interview-for-Algorithm-Engineer欢迎大家StarAIGC时代的《三年面试五年模拟》AI算法工程师/开发工程师求职面试秘籍独家资源【三年面试五年模拟】AI算法工程师面试秘籍Rocky最新撰写AI AgentAI智能体的深入浅出全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识AIGC/LLM/AI Agent算法岗/开发岗面试面经交流社群涵盖AI Agent、AIGC图像创作、AI视频、LLM大模型、AI多模态、数字人、传统深度学习、具身智能等AIGC面试干货资源欢迎大家加入https://t.zsxq.com/33pJ0大家好我是Rocky。核心导读Manus 在 2025 年 7 月 18 日发布的《Context Engineering for AI Agents: Lessons from Building Manus》表面上是团队复盘自己做 Agent 的工程经验真正值得看的地方是它把 Context Engineering 从“理念层”推进到了“生产系统层”。如果说 Anthropic 那篇文章讲清楚了上下文工程为什么重要那么 Manus 这篇更像是把手伸进机器内部告诉你一个真实 Agent 产品到底会被什么问题卡住KV-cache 命中率、工具空间膨胀、上下文压缩不可逆、长任务目标漂移、错误恢复、few-shot 模式固化。Rocky认为这篇文章的价值不在于它给了六条技巧而在于它暴露了 Agent 落地的一个底层事实**Agent 的智能不是只由模型参数决定而是由模型、上下文、工具、环境、缓存、记忆和错误反馈共同塑造出来的。**模型越强工程系统越不能粗糙任务越长越不能把上下文当成一个无限塞东西的容器。这也是今天 AI Agent 创业最容易被误判的地方。很多团队还在用 Demo 逻辑理解 Agent给模型一个很长的 prompt接几个工具跑通一个视频展示。但真正进入生产环境后决定用户体验的往往不是“能不能跑通一次”而是成本能不能压住、延迟能不能接受、错误能不能恢复、长任务能不能不断线、工具越多会不会反而变笨。问题背景Manus 为什么选择 Context EngineeringManus 作者 Yichao “Peak” Ji 在开头讲了一个很有代表性的技术选择团队一开始就要决定是基于开源底座训练一个端到端 Agent 模型还是利用前沿模型的 in-context learning 能力在模型之上构建 Agent。这个选择背后其实是整个 AI 应用层过去几年最重要的一次迁移。早期 NLP 时代团队经常要 fine-tune 一个模型再评估再迭代。哪怕模型比今天小得多一个新任务也可能需要数周反馈周期。对 pre-PMF 阶段的产品来说这种迭代速度很危险。作者提到自己上一家公司曾经从头训练开放信息抽取和语义搜索模型但 GPT-3、Flan-T5 出来后自研模型很快失去意义。这个经历让 Manus 选择押注 Context Engineering。因为它可以把迭代周期从“周”缩短到“小时”也让产品能力尽量和底层模型进步保持正交如果模型进步是上涨的潮水Manus 希望自己是一艘船而不是固定在海底的柱子。这句话很重要。Rocky认为它讲的是 AI 应用公司的生存策略。底层模型迭代太快应用层如果把护城河压在某个自研小模型或某个静态 prompt 上很容易被新模型浪潮吞掉。更稳的路径是把自己的能力沉淀在任务上下文、工具编排、环境反馈和业务流程里让模型进步变成顺风而不是重构成本。但 Manus 也很诚实Context Engineering 不是一套优雅公式而是一门实验科学。文章说他们重建过四次 Agent framework把这个过程称为 “Stochastic Graduate Descent”。这有点玩笑但很真实。Agent 工程不是把论文方法搬过来就结束它更像生产系统里的经验搜索架构试错、提示词微调、工具行为观察、失败轨迹复盘最后收敛到一组局部最优。核心思路Agent 上下文工程本质是控制生产摩擦很多人谈 Context Engineering会自然想到“怎么让模型看到更合适的信息”。这没错但 Manus 这篇文章更进一步它把上下文工程和生产系统的成本、延迟、稳定性、可恢复性绑定在一起。在一个真实 Agent 里上下文不是静态材料而是循环系统的一部分。用户输入后Agent 根据当前上下文选择 actionaction 在环境里执行得到 observationaction 和 observation 再被追加到上下文进入下一轮。这个循环不断发生直到任务完成。这意味着上下文不仅决定模型“想什么”还决定系统“花多少钱”“等多久”“错了能不能回来”。如果上下文前缀不稳定KV-cache 命中率下降成本和延迟就会上升如果工具定义频繁变动模型会困惑缓存也会失效如果所有观察都硬塞进窗口模型失焦且费用变高如果错误被清理掉模型就失去调整行为的证据如果历史轨迹太相似模型又可能被自己的 few-shot 模式带进死胡同。所以 Manus 讲的上下文工程本质上不是“提示词艺术”而是围绕 Agent 循环做生产摩擦控制让模型每一轮看到的信息足够稳定、足够可恢复、足够可行动同时把延迟、成本和错误反馈控制在产品可承受范围内。方法展开Manus 的六条生产级上下文原则1. 围绕 KV-cache 设计成本和延迟也是智能的一部分Manus 认为如果只能选一个生产级 Agent 指标KV-cache hit rate 可能是最重要的一个。这个判断非常工程化也非常现实。普通聊天机器人里输入和输出的比例通常还比较均衡。但 Agent 不一样。Agent 每一轮都要带着系统提示词、工具定义、历史 action、observation 和任务状态去推理输出却经常只是一个结构化函数调用。Manus 给出的数据是平均输入输出 token 比例大约是 100:1。也就是说Agent 的主要成本不在“生成了多少字”而在“每一轮推理前要预填多少上下文”。这时 KV-cache 就变成关键基础设施。相同前缀可以复用缓存大幅降低 time-to-first-token 和推理成本。文章举例说Claude Sonnet 的 cached input tokens 是 0.30 USD/MTok而 uncached input tokens 是 3 USD/MTok差了 10 倍。这张图的意义不只是解释缓存而是提醒 Agent 团队上下文是否稳定会直接影响商业模型。一个看起来只差一个时间戳的系统提示词如果放在 prompt 前缀开头每次都变就可能从那个 token 开始让缓存失效。一个 JSON 序列化如果 key 顺序不稳定也可能悄悄破坏缓存。一个动态工具定义如果频繁改变更是把后面所有 action 和 observation 的缓存价值都打掉。Manus 给出的做法很朴素保持 prompt prefix 稳定让上下文 append-only不随意改写历史 action 和 observation必要时显式设置 cache breakpoint自托管模型时打开 prefix/prompt caching并用 session ID 保证请求尽量路由到一致的分布式 worker。Rocky认为这里有一个经常被忽略的行业判断**Agent 的产品体验不是只由模型智商决定成本和延迟会反过来决定智能能不能被用户持续使用。**如果一个 Agent 每一步都慢每个任务都贵再聪明也很难成为高频工作流。KV-cache 看似是底层推理优化实际上是 Agent 商业闭环的一部分。2. Mask不要 Remove工具空间不能随便增删Agent 能力越多工具越多。MCP 的流行会进一步放大这个问题。用户可配置工具一旦开放理论上有人会把上百个奇怪工具接进来。看起来 Agent 武装到牙齿实际可能更容易选错工具、走低效路径甚至因为工具含义重叠而变笨。直觉上很多团队会想做动态工具空间根据任务需要加载工具不需要的就移除像 RAG 一样按需召回工具定义。Manus 试过但结论很明确除非绝对必要不要在单次迭代中动态添加或删除工具。原因有两个。第一工具定义通常序列化在上下文前部接近 system prompt。任何工具定义变化都会破坏后续 action 和 observation 的 KV-cache。第二如果历史 action/observation 里引用了某个工具而当前上下文里这个工具定义被移除了模型会困惑。在没有 constrained decoding 的情况下容易出现 schema violation 或 hallucinated actions。Manus 的方案是不要删除工具而是 Mask。也就是用一个 context-aware state machine 管理工具可用性在解码阶段通过 token logits mask 来阻止或强制选择某些 action。这个设计很漂亮因为它同时满足两个目标工具定义保持稳定缓存前缀不被破坏模型的行动空间又能根据状态收窄避免乱选。文章还提到 response prefill 可以配合函数调用模式使用例如 Auto、Required、Specified 三种模式通过预填到不同位置来约束模型是否调用工具、必须调用工具或者只能从特定前缀的一组工具中选。这也是为什么 Manus 会给工具命名设计一致前缀例如浏览器工具都以browser_开头命令行工具以shell_开头。命名不是审美问题而是可控性问题。好的工具命名可以成为解码约束的接口。Rocky认为这一点对 Agent 产品非常关键。工具不是越多越好工具空间需要被“语义稳定化”。真正成熟的 Agent 平台不会只是一个工具市场而会有工具分组、状态机、权限、前缀约束、失败兜底和上下文稳定策略。否则工具越开放系统越不可控。3. 把文件系统当 Context长上下文不是万能药前沿模型已经支持 128K 甚至更长上下文但 Manus 仍然认为真实 Agent 场景里不够而且有时会变成负担。它列了三个痛点Observation 可能巨大尤其是网页、PDF、表格、代码仓库上下文长度超过某个范围后模型表现会退化长输入很贵即便有 prefix caching也仍要传输和预填 token。很多系统会用 truncation 或 compression 解决。但 Manus 指出过度压缩有天然风险Agent 需要基于所有先前状态预测下一步 action而你很难提前知道十步之后哪条 observation 会突然变关键。任何不可逆压缩都可能埋下未来错误。所以 Manus 把文件系统视为 ultimate context它容量大、持久、可由 Agent 直接操作。模型学会按需写文件、读文件把文件系统不只是当存储而是当结构化外部记忆。这里真正重要的是“可恢复压缩”。网页正文可以从当前上下文删除但 URL 要保留文档内容可以不塞进窗口但文件路径要保留在 sandbox 里。这样上下文可以缩短但信息没有永久丢失。Rocky认为这是 Agent 工程里的一个底层分水岭。很多团队还在争论“上下文窗口多长才够”但更重要的问题是“什么信息必须在脑子里什么信息应该放在外部工作台”。人类做复杂任务时也不是把所有资料背下来而是依赖文件夹、笔记、书签、目录、命名和搜索。Agent 也一样。文章还引出一个很有意思的联想如果 State Space Model 能掌握文件型记忆那么它虽然缺少 Transformer 式全注意力却可能通过外部化长期状态获得 Agent 场景里的效率优势。这个判断不一定马上兑现但方向值得关注。未来 Agent 的长程能力未必只靠更长 attention也可能靠更好的外部记忆接口。4. 通过 Recitation 操纵注意力todo.md 不是装饰Manus 用户可能会注意到它做复杂任务时经常创建todo.md并随着任务推进不断更新、勾选。这不是可爱的小习惯而是一个注意力操纵机制。Manus 说一个典型任务平均需要大约 50 次工具调用。50 次调用意味着很长的 action-observation 轨迹。LLM 负责决策时很容易在长上下文里忘记原始目标、偏离计划或者被最近的局部信息带偏。不断重写 todo list相当于把全局目标反复“背诵”到上下文末尾。因为模型对近处上下文通常更敏感这可以缓解 lost-in-the-middle让主计划重新进入模型的近期注意力范围。这件事很朴素但很有启发。很多时候Agent 不需要神秘的新架构只需要把目标管理做得像一个严谨的人类工程师列计划、更新进度、标记完成、暴露未完成项。自然语言本身就是一种控制信号。Rocky认为这对 AI 编程、研究 Agent、企业流程 Agent 都适用。长任务的核心不是“开始时计划写得多漂亮”而是计划能不能在执行过程中反复被刷新到系统最容易看见的位置。todo.md 的价值本质上是把任务目标从历史深处拉回当前工作台。5. 保留错误失败轨迹是 Agent 学习的证据Agent 一定会犯错。模型会幻觉工具会异常网页会变外部 API 会失败环境会返回不可预测结果。多步任务里失败不是例外而是循环的一部分。很多系统的直觉是把错误清理掉隐藏失败轨迹、重试 action、重置状态或者寄希望于 temperature 带来不同路径。这样看起来更干净但 Manus 的判断相反擦掉失败就是擦掉证据。当模型看到一次失败 action 和对应 observation/stack trace它会隐式更新自己的判断降低重复类似动作的概率。这不是显式训练但它是 in-context learning 的一部分。错误轨迹会改变模型在当前任务里的先验。Manus 甚至认为error recovery 是 true agentic behavior 最清晰的指标之一。但今天很多学术工作和公开 benchmark 更关注理想条件下的任务成功率对失败恢复研究不足。Rocky非常认同这个判断。真正的 Agent 不是不犯错而是犯错后能不能利用环境反馈修正路线。人类工程师排查问题时也依赖错误日志、堆栈、失败命令和中间状态。如果系统把这些都清理掉Agent 就像被剥夺了调试记忆。这对产品也有启发。很多 AI 产品为了“干净体验”会隐藏中间过程但 Agent 的可控性和可解释性往往来自中间过程。未来的高质量 Agent 产品不一定要把所有错误暴露给用户但系统内部必须保留可用于恢复的错误证据。6. 不要被 Few-shot 自己困住重复轨迹会诱导重复行为Few-shot prompting 通常被认为是提升 LLM 输出质量的好方法。但在 Agent 系统里它会有反作用。原因是模型很擅长模仿上下文里的行为模式。如果上下文里充满相似的 action-observation 对模型就会倾向于继续沿用这种模式即使当前场景已经不适合。Manus 举了一个例子让 Agent 审核 20 份简历时Agent 可能进入一种节奏重复相似动作只是因为上下文里前面都这么做。这会导致漂移、过度泛化甚至幻觉。Manus 的解决方案是增加 diversity在 action 和 observation 中引入少量结构化变化比如不同序列化模板、不同表述、顺序或格式上的轻微扰动。这个受控随机性可以打破模式调整模型注意力。这条经验很反直觉。很多工程师追求完全一致的格式认为越一致越可靠。但在 Agent 长循环里过度一致可能把模型锁进行为惯性。真正难的是找到稳定和变化之间的平衡缓存前缀需要稳定工具定义需要稳定但重复任务轨迹不能完全僵化。Rocky认为这里体现了 Agent 工程的复杂性。上下文不是越整齐越好也不是越多样越好。不同层级的上下文有不同目标系统前缀追求稳定行动历史追求可恢复重复任务追求足够变化外部记忆追求可索引。把这些目标混在一起就容易做出局部正确、整体失败的系统。实验与证据这篇文章能支撑到什么程度这篇文章不是论文没有严密 benchmark也没有开放完整实验设置。它的证据主要来自 Manus 团队的真实产品经验包括多次 framework 重建、生产级 Agent 循环、平均 100:1 输入输出 token 比、典型任务约 50 次工具调用以及面向大量真实用户的测试。所以它不能被当成“普适定理”。Manus 自己也说这些不是 universal truth而是他们在实际产品中收敛出来的 patterns。但 Rocky认为这类一线工程复盘的价值恰恰在于它补足了论文 benchmark 很难覆盖的部分。很多 Agent 失败不是因为单步能力不够而是因为长链路里的缓存、工具、记忆、错误、目标漂移和成本结构没有被同时考虑。学术评测经常看“最后有没有完成任务”但真实产品还要看“完成一次要多少钱、等多久、失败后怎么恢复、下一次是否更稳”。从这个角度看Manus 这篇文章的证据强度属于“生产经验可信、机制解释清晰、外部可复现性有限”。它最适合作为 Agent 工程团队的设计清单而不是作为某个具体架构的最终答案。这篇工作的边界与可复现性第一文章没有公开 Manus 完整框架也没有提供足够细的实验对照。比如 KV-cache 优化带来的实际端到端收益、tool mask 对 action selection 的提升、结构化扰动对 few-shot rut 的缓解程度都需要在具体系统里复测。第二这些经验依赖模型和平台能力。不同模型的工具调用格式、缓存策略、response prefill 支持、logits mask 能力并不完全一样。一个在 Manus 系统里有效的做法换到另一个模型提供商或自托管推理框架里可能需要重写。第三文章更偏通用 Agent不直接覆盖强监管行业、低延迟交易、医疗法律等高风险场景。在这些场景里“保留错误轨迹”“让 Agent 自主操作文件系统”“引入结构化随机性”都要重新经过权限、安全、审计和合规设计。第四它没有解决 Agent 评估问题。上下文工程能改善系统行为但如何稳定衡量长期任务质量、错误恢复能力、目标保持能力和上下文污染程度仍然是开放问题。如果继续研究/落地应该关注什么对 Agent 团队来说这篇文章可以直接转化为六个工程检查项。第一检查 KV-cache。系统提示词前缀是否稳定是否有动态时间戳、随机 ID、非确定性 JSON 序列化破坏缓存是否设置了合适 cache breakpoint自托管模型是否开启 prefix caching第二检查工具空间。工具定义是否频繁变化工具命名是否支持按前缀分组工具可用性是通过删除定义解决还是通过 mask/state machine 解决历史 action 是否还引用当前上下文里不存在的工具第三检查外部记忆。哪些 observation 必须留在上下文哪些可以保存到文件系统压缩是否可恢复URL、文件路径、查询语句、数据快照是否被保留第四检查任务目标。长任务是否有 todo、plan、state file 或其他目标重申机制计划是否被更新到上下文末尾Agent 是否会在 30 到 50 次工具调用后仍然知道原始目标第五检查错误恢复。失败 action、stack trace、工具错误是否被保留系统是否让模型看到足够证据来避免重复错误是否有专门评测错误恢复而不是只评测理想成功第六检查模式固化。重复任务里是否出现机械循环是否可以在不破坏系统稳定性的前提下引入结构化变化打破 few-shot rutRocky认为真正成熟的 Agent 工程团队会把这些检查项产品化、平台化而不是每个项目靠人工经验临时补丁。未来 Agent 平台的底层能力可能就是一套上下文操作系统缓存管理、工具状态机、文件记忆、计划重申、错误轨迹、轨迹扰动和评估闭环。术语与概念速查概念含义Rocky式理解Context Engineering管理 Agent 推理时看到的信息、工具、记忆和反馈Agent 生产系统的核心工程不只是 PromptKV-cache复用相同上下文前缀的 key/value 缓存决定 Agent 延迟和成本的关键基础设施Prefilling模型生成前处理输入上下文的阶段Agent 成本大头常在这里不在输出字数Append-only Context只追加新 action/observation不改写历史保持缓存稳定也保留完整任务轨迹Tool Masking不删除工具定义而是在解码时限制可选工具保持上下文稳定同时收窄行动空间File System as Context用文件系统承载长期状态和可恢复信息把“记忆”从上下文窗口外部化Recitation反复重写 todo/目标让计划靠近上下文末尾用自然语言操纵模型近期注意力Error Recovery利用错误轨迹修正后续行为真正 Agentic 行为的重要指标Few-shot Rut模型被重复 action-observation 模式困住上下文太整齐也可能导致行为僵化拓展思考Agent 的护城河会从模型调用迁移到上下文系统这篇 Manus 文章和 Anthropic 的上下文工程文章放在一起看会得到一个很清晰的判断Agent 时代应用层竞争正在从“谁会写 prompt”迁移到“谁会管理上下文系统”。Prompt 是入口但不是系统。工具是手脚但不是大脑。模型是能力底座但不自动产生稳定产品。真正能把 Agent 从 Demo 推向工作流的是上下文系统什么信息进入什么信息外部化什么信息可恢复什么工具可选什么错误保留什么目标反复重申。Rocky认为这会改变 AI 应用公司的组织能力要求。过去一个小团队可以靠 prompt、UI 和 API 快速做出 Demo。未来要做可靠 Agent需要懂模型推理、缓存成本、工具协议、文件系统、沙箱环境、评估体系、产品流程和行业数据。单点技术红利会被模型进步吞掉系统工程红利才会留下。对开发者来说这也是 Vibe Coding 继续演化后的新要求。AI 会越来越会写代码但复杂任务仍然需要人设计上下文给模型什么文件、保留什么错误、如何拆解计划、怎样验证结果、什么时候压缩历史、什么时候开子任务。工具会越来越强人的价值会从“亲手写每一行”转向“设计可执行的工作现场”。对创业者和投资人来说这篇文章给出的校准更直接不要只看一个 Agent Demo 有多惊艳要看它有没有上下文工程能力。能不能控制成本能不能处理工具膨胀能不能长程执行能不能错误恢复能不能把行业任务转成可持续的上下文结构。这些东西不性感但决定产品能不能活过第一轮热度。最后用 Manus 这篇文章最值得带走的一句话来收束Agentic future will be built one context at a time.Rocky把它翻译成更工程化的说法Agent 的未来不是一次生成一个答案而是一轮一轮把上下文工程好。这才是 AI Agent 从玩具走向生产力工具的真正分水岭。参考来源Manus Blog: Context Engineering for AI Agents: Lessons from Building Manus推荐阅读Rocky一直在运营技术交流群WeThinkIn-技术交流群这个群的初心主要聚焦于技术话题的讨论与学习包括但不限于算法开发竞赛科研以及工作求职等。群里有很多人工智能行业的大牛欢迎大家入群一起学习交流请添加小助手微信Jarvis8866拉你进群1. 深入浅出完整解析AI AgentAI智能体的核心基础知识2025年可以说是AI Agent全面落地应用的元年因此Rocky在持续撰写对AI Agent的全维度解析文章深入浅出完整解析AI AgentAI智能体的核心基础知识2. 深入浅出完整解析扩散模型DDPM、DDIM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识和Rocky一起学习探究扩散模型的本质原理与和核心基础知识同时不断跟进扩散模型的最新发展。Rocky在本文中对扩散模型的本质做了全面系统的梳理与讲解深入浅出完整解析扩散模型DDPM、DDIM、SDE、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识3. 深入浅出完整解析FLUX.2、Seedream即梦、Z-image、GLM-Image核心基础知识https://zhuanlan.zhihu.com/p/19751746910491895624. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识5. 深入浅出完整解析DeepSeek系列核心基础知识深入浅出完整解析DeepSeek系列核心基础知识6、Sora等AI视频大模型的核心原理核心基础知识网络结构经典应用场景从0到1搭建使用AI视频大模型从0到1训练自己的AI视频大模型AI视频大模型性能测评AI视频领域未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Sora等AI视频大模型文章地址深入浅出完整解析Sora、Wan2.1、AnimateDiff、CogVideoX等AI视频大模型核心基础知识7、Stable Diffusion 3和FLUX.1核心原理核心基础知识网络结构从0到1搭建使用Stable Diffusion 3和FLUX.1进行AI绘画从0到1上手使用Stable Diffusion 3和FLUX.1训练自己的AI绘画模型Stable Diffusion 3和FLUX.1性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion 3和FLUX.1文章地址深入浅出完整解析Stable Diffusion 3SD 3和FLUX.1系列核心基础知识8、Stable Diffusion XL核心基础知识网络结构从0到1搭建使用Stable Diffusion XL进行AI绘画从0到1上手使用Stable Diffusion XL训练自己的AI绘画模型AI绘画领域的未来发展等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion XL文章地址深入浅出完整解析Stable Diffusion XLSDXL核心基础知识9、Stable Diffusion 1.x-2.x核心原理核心基础知识网络结构经典应用场景从0到1搭建使用Stable Diffusion进行AI绘画从0到1上手使用Stable Diffusion训练自己的AI绘画模型Stable Diffusion性能优化等全维度解析文章正式发布码字不易欢迎大家多多点赞Stable Diffusion文章地址深入浅出完整解析Stable DiffusionSD核心基础知识10、ControlNet核心基础知识核心网络结构从0到1使用ControlNet进行AI绘画从0到1训练自己的ControlNet模型从0到1上手构建ControlNet商业变现应用等全维度解析文章正式发布码字不易欢迎大家多多点赞ControlNet文章地址深入浅出完整解析ControlNet核心基础知识11、LoRA系列模型核心原理核心基础知识从0到1使用LoRA模型进行AI绘画从0到1上手训练自己的LoRA模型LoRA变体模型介绍优质LoRA推荐等全维度解析文章正式发布码字不易欢迎大家多多点赞LoRA文章地址深入浅出完整解析LoRALow-Rank Adaptation模型核心基础知识12、深入浅出完整解析AIGC时代Transformer核心基础知识在AIGC时代中Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向成为AI技术架构大一统与多模态整合的关键核心基座大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析Transformer文章地址深入浅出完整解析AIGC时代Transformer核心基础知识13、最全面的AIGC面经《手把手教你成为AIGC算法工程师斩获AIGC算法offer2024年版》文章正式发布码字不易欢迎大家多多点赞AIGC面经文章地址手把手教你成为AIGC算法工程师斩获AIGC算法offer14、50万字大汇总《“三年面试五年模拟”之算法工程师的求职面试“独孤九剑”秘籍》文章正式发布码字不易欢迎大家多多点赞算法工程师三年面试五年模拟文章地址https://zhuanlan.zhihu.com/p/545374303《三年面试五年模拟》github项目地址希望大家能多多starhttps://github.com/WeThinkIn/Interview-for-Algorithm-Engineer15、Stable Diffusion WebUI、ComfyUI、Fooocus三大主流AI绘画框架核心知识从0到1搭建AI绘画框架从0到1使用AI绘画框架的保姆级教程深入浅出介绍AI绘画框架的各模块功能深入浅出介绍AI绘画框架的高阶用法等全维度解析文章正式发布码字不易欢迎大家多多点赞AI绘画框架文章地址深入浅出完整解析主流AI绘画框架ComfyUI、Stable Diffusion WebUI、Fooocus核心基础知识16、GAN网络核心基础知识网络架构GAN经典变体模型经典应用场景GAN在AIGC时代的商业应用等全维度解析文章正式发布码字不易欢迎大家多多点赞GAN网络文章地址https://zhuanlan.zhihu.com/p/66315730617. AI算法工程师的《三年面试五年模拟》求职秘籍AIGC时代的算法工程师的求职面试秘籍持续更新中18. AIGC产业的深度思考与分析2023年3月21日微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示自从1980年首次看到图形用户界面graphical user interface以来以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。Rocky也认为AIGC及其生态会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期未来随着AIGC的全面落地和深度商用会深刻改变我们的工作、生活、学习以及交流方式各行各业都将被重新定义过程会非常有趣。那么在此基础上我们该如何更好的审视AIGC的未来我们该如何更好地拥抱AIGC引领的革新Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点希望能帮助各位读者对AIGC有一个全面的了解深入浅出全面解析AIGC时代核心价值与发展趋势2025年版