企业官网建设流程全解析

写在前面

欢迎大家关注Rocky的公众号：WeThinkIn
欢迎大家关注Rocky的知乎：Rocky Ding
AIGC/LLM/AI Agent算法工程师/开发工程师面试面经秘籍分享：WeThinkIn/Interview-for-Algorithm-Engineer欢迎大家Star～

AIGC时代的《三年面试五年模拟》AI算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】AI算法工程师面试秘籍

Rocky最新撰写AI Agent（AI智能体）的深入浅出全维度解析文章：深入浅出完整解析AI Agent（AI智能体）的核心基础知识

AIGC/LLM/AI Agent算法岗/开发岗面试面经交流社群（涵盖AI Agent、AIGC图像创作、AI视频、LLM大模型、AI多模态、数字人、传统深度学习、具身智能等AIGC面试干货资源）欢迎大家加入：https://t.zsxq.com/33pJ0

大家好，我是Rocky。

核心导读

Anthropic 在 2025 年 9 月 29 日发布的工程文章《Effective context engineering for AI agents》，表面上是在讨论 Agent 的上下文管理，实际上讲的是 AI 应用工程正在发生的一次范式迁移：真正难的部分，正在从“怎么写一句更聪明的 Prompt”，转向“怎么为模型持续组织一个可行动、可裁剪、可恢复的工作现场”。

Rocky认为，这篇文章值得认真读，不是因为它发明了一个新名词，而是因为它把 Agent 落地里的一个底层矛盾讲清楚了：模型能力越强，Agent 执行链越长，系统里可用信息就越多；但上下文窗口、注意力预算、工具返回、历史消息、外部知识、项目记忆这些东西并不会自动变成有效智能。它们如果没有被工程化管理，反而会变成噪声、拖慢推理、污染判断，最后把一个看似强大的 Agent 拉回到“知道很多，但做不稳”的状态。

这件事对 AI 应用创业、算法工程、Agent 产品和 Vibe Coding 都有直接启发。上半场奖励的是谁能把模型调得“像会说话”；下半场奖励的是谁能把模型放进一个可靠的上下文系统里，让它在多轮、多工具、长周期任务里仍然保持目标、边界和判断。

问题背景：Prompt Engineering 为什么不够了

早期大模型应用的主战场，确实是 Prompt Engineering。那时很多任务是一次性分类、摘要、改写、抽取、文案生成，系统提示词写得清不清楚、示例给得好不好，往往能直接决定效果。于是行业里沉淀出大量提示词模板、角色设定、few-shot 写法、XML 标签、Markdown 分区和“魔法咒语”。

但 Agent 把问题变复杂了。一个真正可用的 Agent 不只是回答一次问题，而是在循环中不断观察、调用工具、读取文件、查询外部数据、生成中间结果、修正计划，再进入下一轮推理。每一轮都会产生新信息，每一次工具调用都可能带回新材料，每一段历史消息都可能看似有用。

问题来了：这些信息到底哪些该进入下一次模型调用？哪些该被保留？哪些该被压缩？哪些该通过工具按需读取，而不是提前塞进上下文？哪些曾经有用，但现在已经变成干扰？

Anthropic 把这个问题称为 Context Engineering。它不是把 Prompt Engineering 否定掉，而是把 Prompt 放回更大的系统里看：Prompt 只是上下文的一部分，真正影响 Agent 行为的，是系统提示词、工具描述、工具返回、MCP 资源、外部数据、历史消息、示例、项目文件、记忆和当前任务状态共同组成的“上下文现场”。

这张图的关键点，不在于给两个概念画了边界，而在于它指出了一个工程节奏的变化。Prompt Engineering 更像一次性写作任务，Context Engineering 则是一个循环过程：每一次模型推理前，系统都要重新决定应该把什么交给模型。

Rocky认为，这里有一个非常重要的行业判断：**未来 Agent 系统的护城河，不会只来自某个提示词模板，而会来自持续管理上下文状态的能力。**提示词可以复制，工具可以复刻，模型 API 也越来越同质化，但在一个复杂业务现场里，怎样让模型始终看到“刚好足够”的信息，这就是产品和工程的结合部。

核心思路：上下文不是仓库，而是工作台

很多团队做 Agent 的第一个误区，是把上下文窗口当成一个越来越大的仓库。既然模型窗口变长，那就多塞一点；既然工具能返回很多，那就多给一点；既然检索能召回很多，那就尽量召全。这个思路在 Demo 阶段经常有效，因为短链路任务的噪声还没有大到压垮系统。

但 Anthropic 的文章提醒我们，Context 是一种有限资源。它不是硬盘，不是知识库，也不是日志池，而是模型当前推理时的工作台。工作台太空，模型缺信息；工作台太乱，模型会失焦。

这背后有两个技术原因。

第一，大模型虽然上下文窗口越来越长，但长上下文并不等于等质量上下文。文章提到类似 needle-in-a-haystack 的测试已经暴露了 context rot：上下文越长，模型从中准确回忆和使用关键信息的能力会下降。这个下降不一定是断崖式的，更像一个性能梯度，模型还能工作，但精度、稳定性和长程推理质量会变差。

第二，Transformer 的注意力机制天然要处理 token 之间的成对关系。上下文长度增加以后，需要协调的信息关系会快速变复杂。即使模型通过位置编码插值等方式适配更长序列，也并不意味着它对所有远距离依赖都拥有同样强的理解能力。更现实地说，训练数据分布里短序列更常见，模型对极长上下文中跨段依赖的经验也更少。

所以，“把所有东西都给模型”不是慷慨，而是一种工程偷懒。真正有效的上下文工程，应该追求的是：用最小的高信号 token 集合，最大化模型产生目标行为的概率。

这句话听起来像常识，但落到 Agent 产品里非常难。因为它要求团队同时理解模型、任务、工具、数据、用户路径和失败模式。你不能只问“模型缺什么”，还要问“模型看到什么会被误导”；不能只问“信息是否相关”，还要问“现在这一轮推理是否需要它”；不能只问“上下文够不够长”，还要问“注意力是否被浪费”。

方法展开：Context Engineering 到底管什么

1. 系统提示词：不是越细越好，而是高度要对

Anthropic 对系统提示词的建议很克制：用清晰、直接、简单的语言，把任务放在合适的抽象高度上。

这里的“高度”非常关键。太低，就会把系统提示词写成一堆 if-else 式的硬编码规则。短期看起来可控，长期会越来越脆：业务条件一变，工具一换，异常一多，提示词就变成没人敢动的规则泥潭。太高，又会变成空泛口号，比如“请专业、准确、高质量地完成任务”，模型既不知道具体边界，也不知道输出标准。

这张图真正想表达的是：系统提示词不是把人类所有决策写死，也不是把责任全部丢给模型，而是在脆弱硬编码和空泛泛化之间找到可执行的启发式。一个好的系统提示词应该给模型足够具体的行为方向，又给它保留处理复杂场景的弹性。

Rocky认为，这对今天很多 AI 应用团队是很现实的提醒。很多失败的 Agent 不是模型不够强，而是系统提示词把模型关进了错误的轨道：要么规则太碎，模型只能机械执行；要么边界太虚，模型开始自行脑补。真正可维护的 Prompt，不是长，而是结构清楚、边界明确、失败模式可迭代。

2. 工具：工具不是功能列表，而是 Agent 与世界的契约

Agent 的工具设计，是上下文工程里最容易被低估的一环。因为工具不仅提供能力，也会决定模型如何理解任务空间。

Anthropic 强调，工具应该自包含、鲁棒、用途清楚，输入参数要描述明确，功能边界要尽量少重叠。一个常见失败模式是工具集膨胀：接口很多、能力重叠、命名含糊，工程师自己都说不清某个场景应该用哪个工具，却期待模型自己做出更好的选择。

这其实是产品设计问题，也是组织工程问题。工具不是“我把后端接口都暴露给模型”；工具是你帮模型塑造一套可行动的世界模型。工具名称、参数、返回格式、错误信息、数据粒度，都会进入模型的上下文，影响下一步决策。

所以好的工具设计要同时满足两件事：第一，返回内容要 token efficient，不要把一整堆低价值字段塞回来；第二，工具本身要诱导高效行为，让模型自然走向正确路径，而不是在一堆相似工具里反复试错。

这也是为什么 Agent 产品不能只靠模型团队。它需要后端、产品、数据、算法、交互甚至业务专家共同设计工具契约。工具红利会退潮，但围绕任务拆工具、定义边界、管理返回的能力，会变成跨周期工程资产。

3. 示例：few-shot 仍然重要，但不要把边界条件当垃圾桶

Anthropic 仍然建议使用示例，也就是 few-shot prompting。但它反对把所有边界条件都塞进提示词里。

原因很简单：示例对模型来说是“图像化”的行为参照，但过多、过碎、互相冲突的示例会降低信号密度。模型并不是在读法律条文，它是在从上下文里归纳行为模式。你给它十几个质量参差不齐的边界案例，不一定比给它三个高质量、覆盖典型分布的 canonical examples 更好。

Rocky在做技术文章、面试题库、AIGC 工作流和 Agent 任务设计时也有类似体感：示例的价值不在数量，而在能否把“你真正想要的判断方式”显性化。好的示例不是补丁，而是标尺。

动态上下文：从提前召回到 Just-in-time

如果说系统提示词、工具和示例解决的是静态上下文，那么 Agent 的真正难点在动态上下文。

很多 AI-native 应用会在模型调用前使用 embedding 检索，把看似相关的材料提前召回。这对很多问答和知识库场景依然有效，但 Agent 越复杂，预先把所有相关材料塞进去的成本就越高。Anthropic 观察到，越来越多团队开始转向 just-in-time context：不是提前加载全部数据，而是给 Agent 保留轻量引用，比如文件路径、存储查询、网页链接、数据库表名，让模型在运行时通过工具按需读取。

Claude Code 是这个思路的典型例子。它不需要把整个代码库一次性塞进上下文，而是通过文件系统、查询、Bash、grep、glob 等工具逐步探索。模型可以先看目录、再看文件名、再看文件片段、再运行命令验证。这样做的本质，是让 Agent 像人一样工作：我们也不会把整本书背进脑子里，而是依赖文件夹、书签、搜索、笔记和命名系统，在需要时把信息拿到工作台上。

这里还有一个常被忽略的点：路径、文件名、目录层级、时间戳，本身就是上下文。一个叫test_utils.py的文件，如果在tests/目录下，和在src/core_logic/目录下，对模型的含义完全不同。好的信息架构，本身就是给 Agent 的导航信号。

当然，just-in-time 不是免费午餐。它会增加运行时探索成本，也要求团队给模型提供足够可靠的工具和启发式。没有边界的自主探索，可能让 Agent 在无关信息里打转、误用工具、反复追死路。对很多业务场景来说，更现实的策略是混合式：一部分关键上下文预先放入，一部分细节让 Agent 运行时检索。

Rocky认为，这里对创业公司尤其重要。不要迷信“做一个万能 RAG + Agent 平台”就能解决所有问题。真正的产品壁垒往往藏在行业信息如何被组织、任务如何被拆分、工具如何被调用、上下文如何被裁剪这四个细节里。模型会进步，但业务现场不会自动变干净。

长程任务：Agent 真正的成人礼

短任务里，Agent 的失败常常还能靠重试掩盖。长程任务不一样。大代码库迁移、复杂研究、跨文件修复、连续数据分析、企业流程自动化，都要求 Agent 在几十分钟甚至数小时里保持目标一致、状态连续、错误可恢复。

Anthropic 提到三类关键技术：compaction、structured note-taking 和 sub-agent architectures。

1. Compaction：不是简单摘要，而是上下文换窗

Compaction 的基本做法，是当对话接近上下文窗口上限时，把历史内容压缩成高保真摘要，再开启新的上下文窗口继续工作。

这件事的难点不在“压缩”，而在“保真”。如果压得太粗，关键架构决策、未解决 bug、实现细节和用户约束会丢掉；如果压得太松，又无法真正降低上下文污染。Anthropic 的建议是先追求 recall，确保复杂 Agent 轨迹里的重要信息都能保留，再逐步提高 precision，删掉冗余工具输出、重复消息和低价值历史。

这对所有做长程 Agent 的团队都是底层能力。你不能只问“窗口够不够大”，还要设计“窗口换掉以后，任务灵魂还在不在”。

2. Structured note-taking：让 Agent 有外部记忆

结构化笔记，或者说 agentic memory，是让 Agent 定期把关键状态写入上下文窗口之外的持久存储，后续再按需读回。

这比“把所有历史消息留在上下文里”更像人类工作方式。人做复杂项目时，也会维护 TODO、设计文档、会议纪要、变更记录、实验日志。Agent 也一样。一个NOTES.md、一个任务清单、一个项目状态文件，都可能让模型在数十轮工具调用之后仍然知道自己在哪、做过什么、还差什么。

Anthropic 用 Claude Code 的待办列表和 Claude 玩宝可梦的长程记忆举例，说明外部记忆能让 Agent 在上下文重置后继续多小时任务。这一点很关键：长程智能不是把一切都塞在脑子里，而是把记忆变成可读写的外部结构。

3. Sub-agent：把脏上下文隔离出去

多 Agent 或子 Agent 架构提供了另一种绕开上下文限制的方式。主 Agent 负责高层规划和综合判断，子 Agent 用干净窗口处理局部任务、深度搜索或工具探索，最后只把压缩后的结果交回主 Agent。

这个模式的核心价值是上下文隔离。复杂搜索过程里会产生大量中间噪声，如果全部留在主 Agent 的窗口里，主线判断会被污染。让子 Agent 去“脏活累活”，再把高信号结论带回来，本质上是在系统层面做信息蒸馏。

Rocky认为，这个思路会成为未来企业级 Agent 的常见架构。不是每个任务都需要多 Agent，但当任务天然可以拆解、并行探索收益高、搜索过程噪声大时，子 Agent 就不是炫技，而是上下文卫生。

这篇文章真正给行业的启发

Anthropic 的这篇文章没有给出一个万能框架，也没有承诺某种神奇架构。它更像一次工程价值观校准：随着模型越来越强，应用层团队不能再把问题简单归因于“模型还不够聪明”。

很多时候，模型已经足够聪明，真正不聪明的是系统给它的上下文。

对 AI 算法工程师来说，Context Engineering 意味着能力边界要从模型调用扩展到信息组织。你不仅要知道怎么写 prompt，还要知道工具返回、历史压缩、检索策略、记忆结构如何影响行为。

对产品经理来说，Context Engineering 意味着 Agent 产品不是把聊天框接上工具那么简单。你要设计的是一个动态工作台：用户意图如何进入，任务状态如何显性化，模型何时读取外部信息，何时压缩历史，何时交给子任务。

对创业者和投资人来说，Context Engineering 提醒我们：AI Agent 的商业闭环不在“我也接了某个大模型 API”，而在能不能把某个行业的任务现场结构化。真正可持续的壁垒，是数据、工具、工作流、记忆和交付标准的组合。

对开发者来说，这篇文章也解释了为什么 Vibe Coding 会继续演化。未来写代码的门槛会降低，但定义问题、维护上下文、拆解任务、验证结果、组织项目记忆的能力会更值钱。AI 不会尊重一个人背过多少提示词，只会放大一个人能不能把复杂工作现场整理成模型可执行的结构。

边界与反思：更大窗口不会自动解决上下文问题

一个常见反驳是：既然模型上下文窗口越来越大，为什么还要做这么多上下文工程？

Rocky的判断是，更大窗口当然有价值，但它解决的是容量问题，不自动解决质量问题。容量扩大以后，低质量信息也更容易被塞进来；工具返回更多以后，噪声也更多；历史保留更长以后，过期决策也更容易干扰当前判断。

这就像一个团队办公室变大了，不代表协作效率一定变高。真正决定效率的，是文件怎么归档、会议怎么记录、任务怎么拆分、谁负责决策、过期信息怎么清理。

上下文工程的长期价值，恰恰在于它不依赖某一代模型的窗口大小。模型越强，越需要被放进更好的信息结构；任务越长，越需要外部记忆和压缩；工具越多，越需要清晰契约；业务越复杂，越需要把行业知识变成可导航的上下文。

术语与概念速查

拓展思考：Context Engineering 会成为 Agent 的基础设施层

这篇文章真正值得继续研究的地方，是它把 Agent 的竞争维度从“模型调用”推向了“上下文系统”。

未来的 Agent 产品可能会出现三层分化。

第一层是模型层。它决定推理、代码、工具使用、多模态和长上下文能力的上限。但模型层会持续迭代，应用团队很难只靠调用某个模型形成长期护城河。

第二层是工具与工作流层。它决定 Agent 能不能进入真实环境，能不能调用数据库、文件系统、浏览器、企业软件和业务 API。这里会产生大量行业适配机会。

第三层是上下文工程层。它决定 Agent 在复杂任务中能不能保持清醒：什么时候看，怎么看，看多少，看完怎么记，记住什么，忘掉什么，交给谁继续看。

Rocky认为，真正有跨周期价值的 AI 应用团队，会越来越像“信息结构工程师 + 业务流程设计师 + 模型产品经理”的混合体。Prompt 仍然重要，但它会从主角变成系统中的一个组件。工具仍然重要，但没有上下文管理，工具越多越容易失控。模型仍然重要，但模型能力必须被上下文系统转化成稳定交付。

所以，这篇 Anthropic 工程文章最值得带走的一句话不是某个技巧，而是一种判断：

Agent 的未来，不是让模型一次看到更多，而是让模型每一次都看到更对。

这句话听起来朴素，但它会决定很多 AI 产品能不能从 Demo 走向长期工作流。

参考来源

• Anthropic Engineering: Effective context engineering for AI agents

推荐阅读

Rocky一直在运营技术交流群（WeThinkIn-技术交流群），这个群的初心主要聚焦于技术话题的讨论与学习，包括但不限于算法，开发，竞赛，科研以及工作求职等。群里有很多人工智能行业的大牛，欢迎大家入群一起学习交流～（请添加小助手微信Jarvis8866，拉你进群～）

1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2025年可以说是AI Agent全面落地应用的元年，因此Rocky在持续撰写对AI Agent的全维度解析文章：深入浅出完整解析AI Agent（AI智能体）的核心基础知识

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/1975174691049189562

4. 深入浅出完整解析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 3（SD 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 XL（SDXL）核心基础知识

9、Stable Diffusion 1.x-2.x核心原理，核心基础知识，网络结构，经典应用场景，从0到1搭建使用Stable Diffusion进行AI绘画，从0到1上手使用Stable Diffusion训练自己的AI绘画模型，Stable Diffusion性能优化等全维度解析文章正式发布！

码字不易，欢迎大家多多点赞：

Stable Diffusion文章地址：深入浅出完整解析Stable Diffusion（SD）核心基础知识

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文章地址：深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

12、深入浅出完整解析AIGC时代Transformer核心基础知识

在AIGC时代中，Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向，成为AI技术架构大一统与多模态整合的关键核心基座，大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析：

Transformer文章地址：深入浅出完整解析AIGC时代Transformer核心基础知识

13、最全面的AIGC面经《手把手教你成为AIGC算法工程师，斩获AIGC算法offer！（2024年版）》文章正式发布！

码字不易，欢迎大家多多点赞：

AIGC面经文章地址：手把手教你成为AIGC算法工程师，斩获AIGC算法offer！

14、50万字大汇总《“三年面试五年模拟”之算法工程师的求职面试“独孤九剑”秘籍》文章正式发布！

码字不易，欢迎大家多多点赞：

算法工程师三年面试五年模拟文章地址：https://zhuanlan.zhihu.com/p/545374303

《三年面试五年模拟》github项目地址（希望大家能多多star）：https://github.com/WeThinkIn/Interview-for-Algorithm-Engineer

15、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/663157306

17. 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年版）