最近读到 Anthropic 最新两篇关于 AI Agent 的文章，看了不少视频博主总结，与我们建设 Agent 踩坑一样，深有感触。不是因为知道了正确答案，而是知道了为什么这样设计，以及结合过往经验，真正理解了这种设计。
其实，AI Agent 设计与传统软件设计有着根本区别。网上很多文章都在展示一个“好”的 AI Agent 最终架构，但很少有人提及其成长过程：这样一个系统到底经历了哪些坑？今天，我就结合自身实践，和大家聊聊 AI Agent 如何从一个简单的 API 调用，成长为一个复杂的工业系统。
一、反直觉的起点：在不确定性上叠加不确定性
当我写代码时，常常会想：这不就是在做系统设计吗？一开始就把架构设计得更完备、更稳固，难道不对吗？说实话，这种想法在传统软件设计中完全正确。比如做后端，先把 Docker、部署模块都规划好，前期慢一点，后期不会出大问题。
但 AI Agent 完全不同。我后来发现一个非常反直觉的点：AI Agent 本身就是一个非确定性的系统。在它之上再搭建一层精致的架构，相当于在不确定性上又叠加了一层不确定性。
举一个我干过的“蠢事”：一开始，我只是想把一段话总结成一句话。结果，我直接为它上了“规划与执行”（Plan and Execute）模式。原本一个 API 调用就能完成的事情，被拆成了“规划”和“执行”两步。任务本身没有变复杂，但链路变复杂了。这不是 AI 不行，而是一开始就把路走复杂了。
所以，我们只讲一件事：AI Agent 是如何从一个微小的问题开始，一步一步被“逼”着长大的。在这条路上，到底是什么节点、什么因素，导致我们必须为它加上某种架构？
二、第一阶段：能用 API 调用解决，就绝不用 Agent
以我们最近做的视频 AI Agent 为例。我们早就开始用 AI，而且用得非常简单朴素。比如生成标题，就是把稿子丢进去，让它生成十个，我再挑一个。再比如生成封面，我让它生成一个视觉主体，然后自己填上文字。
这类任务，说白了就是一次 API 调用就能搞定。如果为了这点事，专门去搭建一个 Agent，加上工具、记忆、编排……那真是“给蚊子装火箭助推器”，看起来很酷，但完全没必要。
第一条原则既简单又残酷：如果你的问题，一个 API 调用能解决，就不要用 Agent。不要为了用 Agent 而用 Agent。
三、第二阶段：多步骤不等于 Agent，确定性任务用工作流
后来，我有了新的 AI 需求。剪视频时，我发现处理语气词、啰嗦或没讲好的地方很琐碎，自然就想：能否让 AI 帮我把这些重复、冗余的部分剪掉？
这时，问题升级了。你会发现这不是一个 API 调用能解决的，而是一整条链路：先把视频转成带时间轴的字幕，再根据字幕判断哪些地方要剪，然后生成剪辑方案，最后控制音视频进行剪辑。
这是一个多步骤问题。但请注意：多步骤不等于 Agent。这里容易出现第二个错误：很多人一看到多步骤，第一反应就是“上 Agent”。其实不一定，因为这类任务有一个重要特征：中间完全不需要用户介入。自然的使用方式是：上传视频，点“一键剪辑”，拿到最终结果。输入是确定的，中间步骤是固定的，输出也是一次性给到的。
所以，这种情况下，Agent 反而是多余的。这种任务本质上是确定性的，哪怕步骤很长、中间有很多 AI 调用，它依然是一个流程。在这个阶段，应该使用 工作流（Workflow）或链式结构（比如 n8n、Dify 等框架），就已经足够了。不需要对话，不需要多轮交互，也不需要用户中途插嘴。
一个重要的判断指标：如果用户不需要在中间反复参与，那你大概率不需要“对话式 Agent”。
四、第三阶段：什么时候才真的需要 Agent？
用我自己踩过的一个坑来回答：我曾做一个“一键生成特效”功能，天真地以为点一下按钮，它就能给我一套满意的动画效果。现实给了我一巴掌——它大概率不会一次就让我满意。有时风格不对，有时节奏不对，有时只想改一个小细节。
这种任务不是对错题，有时甚至是“审美题”。或者因为模型能力暂时达不到，需要人去指导、反复调试。如果坚持只用按钮，会发生什么？你可能需要加很多按钮来控制：“一键重做”、“一键改风格”、“一键改颜色”、“一键换模板”……每出现一种需求，就加一个新按键，产品最终会变成“飞机驾驶舱”，布满各种按钮。
这时，我们才天然地需要一个通用的入口——对话式 Agent。
真正需要狭义上的对话式 Agent，通常只有两个信号：
1. 流程必须让人参与（无论是被动因模型能力不足，还是主动因需要人的偏好）。
2. 功能选项多到前端会指数级增长，你不想为每个功能都添加单独的前端控件。
五、第四阶段：技术选型——别被“重型框架”迷惑
确定使用 Agent 后，我又马上犯了一个典型错误：一开始就想选一个最强、最完整、能覆盖一切情况的 Agent 框架，觉得简单技术“配不上”我的复杂问题。
后来我才发现，这是一个概念错误：链长不等于必须用复杂的调度流程，任务复杂不等于后端必须很重。我当时搞混了两种“长链”的概念：
- 工作流（Workflow）的长链：点一下按钮，从头跑到尾，10步、20步连续执行。这时你才需要考虑任务分发、重试、队列、调度、并发和恢复，因为它真的会在后端“横着跑到底”。
- 对话式 Agent 的长链：这是一种“场面”，是可以被人“切开”的场面。它可以跑完一步停一下，或跑几步停一下，和用户交互确认。整体是一条长流程，但每次真正执行的片段其实可以很短。这意味着，很多时候你根本不需要一上来就搭建一个能连续跑20步、还要扛住各种异常的重型调度系统。
我最终选择了一个看起来平平无奇的方案（比如 LangChain 这类集成度高、上手快的 SDK）。它可能不是最无敌的，但有一个巨大优点：能先把东西跑起来。只要它能完成最基础的对话和工具调用，我们就能在真实任务迭代中进行验证和修正。
所以，不要被“后端架构”迷住双眼。先跑起来，比一步到位做到“完美”更重要。
复杂架构还可能有一个潜在问题：它会诱导你进行过早设计。当你选了一个很厉害的后端框架（比如 LangGraph），它会天然地引导你在还没跑通任何东西时，就开始设计节点、思考数据流转。这听起来很专业，但问题是：你连最简单的问题“能不能被模型解决”都不知道。这就像闭门造车，车轮设计得再远，却不知道路有多宽。
这里其实有两重不确定性：
- 这个问题到底能不能被模型解决？
- 你的架构会不会干扰它？
我的建议很简单：即使你选择了复杂架构，也至少要先用它最简单的用法跑一遍，把你这个问题的“基线（baseline）”跑出来，知道任务的底线在哪儿，之后再决定要不要加复杂的编排。
六、第五阶段：提示词设计——从简开始，逐步添加
在把基础 SDK 跑起来后，下一关自然是如何设计系统提示词（System Prompt）。这时我马上踩了一个超级典型的坑：我想把提示词写到“最厉害”。
我找了很多成熟项目的提示词，那种被传来传去、“效果炸裂”的还不够，甚至还去翻某些知名项目泄露出来的系统提示词。心想：别人写得这么好，我照着抄总不会差吧？结果立刻翻车：第一，效果没有更好；第二，Token 消耗直接爆炸。
举个例子：我只是想让 AI 帮我做一个视觉设计。如果我不给复杂提示词，只说“你是一个视觉设计师，给我一个方案”，它能给出一个勉强可用的结果。但当我把那些专业的提示词一股脑丢进去，它开始拆步骤、规划流程、一步步执行……结果就是：更慢，但效果不一定更好。
我的经验是：提示词的第一版，不要写成复杂的“说明书”。可以先写得没什么限制，看看它会怎么做，然后不断地、一步一步地添加限制条件。 比如，想让输出更格式化，想让它在某方面多思考，就给它提供一些示例（few-shot），让它根据示例进行输出。只要 Agent 能遵循你的指令，一步步往上加东西，能照着做，那么系统提示词这一关其实就过了。
七、第六阶段：能力不足时，不是改提示词，而是加工具
接下来会遇到一个非常现实的问题：很多时候 AI 做不好，不是因为系统提示词写得不够好，而是任务本身需要的能力它根本就不具备。
比如，我让 AI 帮我做动效设计时，其实期待它能参考网上流行的设计，但问题是他根本拿不到这些数据。这时再怎么改提示词都没用——这不是写法问题，是能力缺失。
所以，这一步正确的动作不是再去改系统提示词，而是加工具。如果希望它能参考网上信息，它就必须会搜索；希望它写的代码可用，它就必须能验证。这个时候，我们才需要真正引入工具。
当你把三四个工具加上去后，会有一个明确的感觉：它开始像一个 Agent 了。它开始自己想清楚该用哪个工具，甚至把工具串起来用。这就是所谓的“涌现”——工具之间出现了 1+1 > 2 的效果。注意，在这个阶段，我们还没有做什么复杂的架构，没有引入规划模块，系统提示词也还是基础版本。
说实话，刚开始加工具的那段时间，做 AI 的体验“爽爆了”。每加一个工具，它就明显变聪明一点，之前做不了的事现在能做了，之前做得很勉强的事现在跑通了。你会忍不住继续加、继续加……这时会非常开心。
八、第七阶段：工具泛滥与上下文失控
但很快，你会进入一个非常诡异的阶段：不是偶尔失败，而是 Agent 性能持续性变差。成功率下降，准确率忽高忽低，有时甚至开始“听不懂人话”。你能明显感觉到：它不是“不会做”，而是“越做越不对”。
这个地方，其实不是模型不行了，而是你的上下文开始失控了。工具一多，每个工具背后都有一大段说明；任务变复杂，输入本身也更复杂；再加上历史对话、代码、图片等各种信息……所有信息一股脑塞进模型，导致信息太多太散，模型的注意力被平均分散掉了。
这是一个非常典型的上下文注意力稀释问题。
九、第八阶段：上下文工程与子智能体（Sub-Agent）的引入
这时，我们才真正需要本文开头提到的 Anthropic 第一篇文章所讲的 Context Engineering（上下文工程） 。它的本质就是：在做某一类任务时，让模型只看到它需要看到的东西。
还是拿视频 Agent 举例。当我们想要设计某种视频效果时，其实有两种不同任务：
- 设计任务：关心用户意图、视觉风格、版式、元素、氛围。它需要大量开放的、可发散的信息，并对这些信息进行分析总结。
- 写代码任务：把设计好的信息进行实现。它关心明确的指令、接口结构、输出格式及正确性。它需要尽量少、尽量精确的信息。
如果把这两件事混在一起，会发生什么？任务简单时或许还能跑，但任务一复杂，设计信息会扰乱代码生成的准确性，代码信息又会拖慢设计的判断——两个任务相互“污染”，系统需要花大量时间去“理清楚”。
当不同任务明显需要不一样的上下文时，上下文的隔离才有意义。这时，我们才会开始考虑：是否需要有一个顶层的规划者，它掌握所有全局信息，然后去调度下面的执行者（子智能体） 。这些执行者只负责专项任务（比如“设计子智能体”只负责设计，“代码子智能体”只负责写代码），并且，在规划者的控制下，它们只看到自己需要的那一小撮必要信息。
如果一个子智能体看到的上下文和顶层规划者完全一样，那它就完全没有意义。
十、第九阶段：记忆（Memory）系统的必要性
当我们开始真正使用子智能体（规划者-执行者）结构时，会立刻遇到一个绕不开的问题：如何精确传递内容？
假设用户给了一段代码，希望我们修改。顶层规划者看到了这段代码，但它不负责写代码，需要把这个任务交给下面的“代码执行者”。那么，规划者如何把这段代码原封不动地交给执行者？
最直接的解决方案是：让规划者把输入的东西“再输出一遍”给执行者。但这非常不合理，因为发生了两件糟糕的事：
- 你在为“复制粘贴”付费：输入一段代码，输出一段代码，只是做 copy-paste，却消耗了大量昂贵的 Output Token。
- 你无法保证一字不差：模型不擅长机械复制。即使你明说“一行都不要改”，它也可能把某个明显的 bug “改”了，或者“纠正”一个你故意留的错误标点。如果你本来就是想去修这个 bug，结果它在传递过程中就被“解决”了，这在很多场景下是灾难性的。
所以，这一刻我们意识到：有些信息，我只想“存着”，而不是让模型反复读写。 到这个时候，我们必须引入 Memory（记忆） 这个概念了。
**实现系统很简单：它不是在传递内容，而是在传递内容的指针。**比如，顶层规划者看到代码后，把它写到一个文件系统里，记录下文件名。当它调度代码执行者时，就说：“你需要改这段代码，代码存在[文件名]。” 执行者根据文件名取出内容修改即可。
在这个过程中，规划者不输出完整代码，执行者不依赖规划者的输出，从而让 Output Token 成本直接下降，错误率显著降低。
所以，当你开始做上下文隔离，当你需要开始传递不能改动的长内容时，记忆系统就不再是“优化项”，而是一个“必需品”。
十一、第十阶段：内存 vs. 外存——按需使用，而非标配
引入记忆概念后，常会听到“内存（短期记忆）”和“外存（长期记忆）”的说法。这两个词没那么玄乎，区别很简单：
· 内存：在这轮对话结束后就消失的信息。 · 外存：多轮对话都能拿到的信息。
这不是两种神秘能力，本质上是一个决定：这个东西存在哪儿？存多久？ 为什么有差别？因为有些信息只对这一轮有用，如果写到外存一直带着，可能会变成噪音、污染下一轮的行为，所以它应该留在内存里。而有些信息必须跨轮次保存，比如代码的上下文、任务步骤的状态、用户的待办列表（To-Do List）等。
所以，不要一上来就看到“LangChain”、“内存外存”就都想用。顺序永远都是：你走到这个阶段，发现不用不行了，才去用。
十二、最终阶段：调试与评估——记录全过程
当你有了子智能体系统、上下文隔离、记忆系统之后，整个系统会变得非常复杂，也很难调试。问题变成了：我到底怎么评价它哪里做得好，哪里做得差？
答案只有一个：把每一次运行的全过程全部存下来。 这里存的不是结果，而是过程：它到底用了哪些工具？调用顺序是什么？每步消耗了多少 Token？有哪些上下文被用到？有哪些信息本不该给某个执行者？
当你回头去读这样一整个流程时，才会知道怎么样能把任务规划得更快、Token 用得更少、成功率更高。
到这一步，你才会突然发现：哦，原来我们之前读的 Anthropic 那两篇文章，它们的系统设计才终于是对上了。我最初失败的原因，不是那两篇文章不对，而是我当时所处的阶段，还不需要用到那些东西。
这类比较成型的文章，更像是一份“毕业设计的完整图纸”。当你已经做过中间所有实验、踩过坑再回头看时，会发现它设计得很完美、很精巧。但如果你第一天学画图，就直接照着这份毕业设计去施工，大概率连第一根梁都立不起来。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（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 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
