那些 Agent 神文没告诉你的事：照着做，系统只会更烂 【AI agent 搭建实操指南】

Hello，大家好啊。最近我

在构建一个视频AI Agent，看了很多相关的 文章。 当我看到Anthropic最

文章。 当我看到Anthropic最 新两篇关于AI Agent的 文章的时候，我觉得 真的写 得太好了。我

真的写 得太好了。我 当时就一个想法，抄， 抄完我这个AI Agent就 可以做到完美。 于是

可以做到完美。 于是 呢，我就开始了新一 轮的架构升级。 系统

轮的架构升级。 系统 提示词的升级，上下 文的隔离，让它有了 更多的 memory，做了一系 列看起来很复杂但 是自认为很优雅的 系统架构设计。 做完

系统架构设计。 做完 之后发现整个系统 变得更烂 了啊。 原来

变得更烂 了啊。 原来 同样的任务，现在不 仅Token的花费变得更 高更贵，效果并没有 变得更好， 失败的情 况比原来变得更多， 而且有些失败的例 子呀，根本没有办法 debug。当时我就想啊，不

debug。当时我就想啊，不 应该啊啊，我真的这 么弱吗？ 后来我就放

么弱吗？ 后来我就放 弃了这样一个设计 啊。不过随着AI Agent开

啊。不过随着AI Agent开 发的逐渐深入，我慢 慢意识 到，其实AI Agent 的设计和传统软件 的设计还是有着根 本的区别的。 今天我

本的区别的。 今天我 们在网上看到的文 章，大家都是把一个 好的AI Agent的最 终架 构展现出来，但是却 很少有人去提它到 底是怎么样成长到 这样一个系统的， 它 到底经过了哪些坑。

那今天我们就结合 自己的亲身 经历跟 大家去聊一聊，AI Agent 的设计到底是怎么 样从一个小小的API Call成长到一个复杂 的工业系统。 欢迎大

的工业系统。 欢迎大 家收看我们今天新 一期的视频。 我写代

一期的视频。 我写代 码的时候经常会想 啊，这个不是在做系 统设计吗？那我一开

统设计吗？那我一开 始把架构设计得更 好，更完备，嗯，不应该 更稳吗？ 说实话啊，这

更稳吗？ 说实话啊，这 样的想法在传 统的 软件设计里面一点 问题都没有，是吧。你

问题都没有，是吧。你 做后端，你先把Docker这 个部署模块全部都 规划分好，最多就是 前期慢一点啊，不会 出什么大事。 但是AI

出什么大事。 但是AI 这个东西就 不是这 个样子。呃，我后来才

个样子。呃，我后来才 发现一个非常反直 觉的点啊，AI Agent本身 就是一个非确定性 的系统，你在它上面 再搭一层精致的架 构，等于是在不确定 性 上再叠加了一层 不确定性。 举个我自

不确定性。 举个我自 己干过的蠢事儿啊： 呃，我一开始只是想 把一段话总结成一 句话，是吧？结果我直

句话，是吧？结果我直 接给它上了这个Plan and execute 这样的一个模 式， 那原本一个API Call 就能完成的事情，被 拆成了先计划再执 行。 任务没有变复杂，

行。 任务没有变复杂， 但是链路先变复杂 了。 不是AI不行 啊，只

了。 不是AI不行 啊，只 是说你一开始就把 路走复杂了。 所以我

路走复杂了。 所以我 们整期内容就只讲 一件事情：AI Agent是怎 么样从一个小得不 能再小的问题， 一步 一步被逼 着长大的。

而在这条路上，到底 是什么节点， 什么样 的因素导致了我们 需要给它加上这样 的一个架构。 就拿我

的一个架构。 就拿我 们最近在 做的视频 AI Agent来举例啊。 我说

AI Agent来举例啊。 我说 过很现实的事情，我 们这个频道其实很 早就开始用AI了，是 吧，而且用得非常的 朴素。 比如说这个标

朴素。 比如说这个标 题，我就是一般把稿 子丢 进去，让它给我 生成十个标题，我会 挑一个。 再比如说这

挑一个。 再比如说这 个封面啊，我让它生 成一个视觉主体， 然 后我自己把文字填 上去。 就这类任务，说

上去。 就这类任务，说 白了就是 一次API Call 就能搞定。 如果要是

就能搞定。 如果要是 为了这点事儿是吧， 我专门搭一个Agent加 工具做记忆、搞编排， 那就真的是给文字 装火 箭助推器啊， 看 起来很酷，但是完全 没有必要是吧？所以

没有必要是吧？所以 第一条原则非常简 单，非常残酷， 如果你 的问题一个API Call能 解决， 不要用 Agent，不要 为了用Agent而用Agent。 后

为了用Agent而用Agent。 后 来我开始有了新的 AI需求啊，剪视频的 时候，我发现一件很 琐碎的事情，就是我 有很多的语气词，有 些地方说得不好， 那 剪视频其实就是在 花时间帮自己擦屁 股，是吧。我自然就会

股，是吧。我自然就会 想，有没有办法能够 让AI帮我把这种重 复的啰嗦的地方给 剪掉。 这一步问题就

剪掉。 这一步问题就 开始升级了，你会发 现这 已经不是一个 API Call能解决的问题， 你需要做的其实是 一整条链路，先把视 频转成在时间戳的 字幕，然后再根据字 幕判断哪些地方要 剪，然后生成一个剪 辑方 案，回头去控制 音频和视频。 这是一

音频和视频。 这是一 个多步骤问题。 但注

个多步骤问题。 但注 意哈， 多步骤不等于 Agent，这里就会出现第 二个非常容易犯的 错误。很多人一看到

错误。很多人一看到 多步骤第一反应，那 我就上Agent啊，不一定。

因为这条链路有一 个非常重要的特征， 就是中间过程不需 要用户的介入。 你可

要用户的介入。 你可 以想象它有一个很 自然的使用方式，就 是我上传视频点一 下一键剪辑，拿到极 好的结果。 输入是确

好的结果。 输入是确 定的，中间步骤是固 定的，输出也是一次 性给到你的。所以这

性给到你的。所以这 种情况下 ，Agent反而是 多余的。 这种任务本

多余的。 这种任务本 质上是一个确定性 的任务，哪怕它很长， 步骤很多，中间有很 多AI，它也依然是一 个流程。 所以在 这种

个流程。 所以在 这种 阶段，应该用Workflow那种 链式结构，啊比如说 N8N，比如说Diffie啊，就已 经完全够了。不需要

经完全够了。不需要 对话，不需要多轮交 互，也不需要让用户 中途 插嘴。一个非常

中途 插嘴。一个非常 重要的判断指标，如 果用户不需要在中 间反复参与，那你大 概率不需要对话Agent。

那到底什么时候需 要Agent啊？我用我自己

要Agent啊？我用我自己 踩过的一个坑来回 答你。我当时做了一

答你。我当时做了一 个功能啊，叫做一键 生成特效，啊就像这 个一键剪辑一样，我 天真地以为我可以 点一下按钮，然后它 就给我一套我喜欢 的动画效果。 但现实

的动画效果。 但现实 给了我一巴掌啊，它 大概率不会一次就 生成到我满意，啊，有 的时候风格不对，有 时候节奏不对，有的 时候我只想改动一 个小细节，是吧？ 这种

个小细节，是吧？ 这种 任务它不是对错题， 啊它有的时候甚至 是一个审美题，或者 说有的时候呢，模型 它的能力达不到，人 需要去指导它，教它 怎么做， 它可能会需 要反复地试，反复地 改，是吧？但如果这个

改，是吧？但如果这个 时候你还坚持用按 钮，可能会发生什么 样的情况？你可能需

样的情况？你可能需 要加很多的按钮来 控制它，比如说一键 重做，啊一键改风格， 一键改颜色， 一键换 模板，一键生成图片， 是吧？ 那每出现一种

是吧？ 那每出现一种 这种需求，你可能就 会要新增加一个按 键， 最后这个产品就 会变成一个飞机驾 驶舱，是吧？很多很多

驶舱，是吧？很多很多 的按键。 这个时候我

的按键。 这个时候我 们才天然地需要一 种通用的入口。 所以

种通用的入口。 所以 你真正需要狭义上 的这种对话式的Agent， 通常只有两个信号， 第一是你这个流程 必须让人参与啊，不 管是被动的模型能 力达不到，还是说是 主动的，啊需要人的 偏好。 第二就是功能

偏好。 第二就是功能 选项多到前端会指 数型地增长，你不能 或说你不想为每一 种功能都添加一个 单独的前端的时候， 你就需要用Agent这种 通用的入口。 我确定

通用的入口。 我确定 使用Agent之后呢，我又 马 上犯了一个特别 典型的错误，我一开 始就想选一个最强 最完整能 cover一切情 况的Agent框架啊， 那种 简单的技术啊，我都 不想用啊，因 为我脑 子里有个幻觉啊，就 是我这个问题很复 杂，所以我需要一个 很长很长的链，那我 就必须上最硬核的 后端框架。 后来我才

后端框架。 后来我才 发现啊，这其实是一 个概念错 误。 链长并

个概念错 误。 链长并 不等于你必须用复 杂的调度， 流程很复 杂不等于后端很重 啊。 我当时搞混了，其

啊。 我当时搞混了，其 实是两种长链的概 念， 当你做的是 Workflow的 时候，你点一下按钮， 它就从头跑到尾，十 步二十步全部都连 续执行，这个时候你 当然会考虑这个任 务的分发、重试、 队列 调度，还有并发恢 复， 因为它会真的在后 端横着跑到底。 但是

端横着跑到底。 但是 对话式Agent不是这么 跑的，是吧？对话式Agent

跑的，是吧？对话式Agent 长链是一种可以被 人切开的那种长链， 它可以 每跑完一步 停一下，或者说跑几 步停一下，和用户进 行一个交互和确认， 是吧？ 它整体还是一

是吧？ 它整体还是一 条长的流程，但每一 次真正执行的片段 其 实可以很短。这就

其 实可以很短。这就 意味着啊，你很多时 候根本不需要一上 来就搭一个能连续 跑二十步，还要扛住 各种异常的重型调 度系统。 所以我最后

度系统。 所以我最后 选了 一个看起来平 平无奇的方案，用的 AISDK，它的集成度高，上 手快啊，有人觉得它 没有那么无敌和万 能，但是它有一个巨 大的优点，就是先把 东西跑起 来。 只要它

东西跑起 来。 只要它 能完成最基础的对 话，最基础的工具调 用，我们就能在真实 的任务迭代里面去 进行验证和修正。 所

进行验证和修正。 所 以大家不要被后端 迷了双 眼，先跑起来 比一步到位做到完 美更重要。 技术选型

美更重要。 技术选型 再补充一句啊， 复杂 架构可能还有一个 坑的地方是，它会诱 导你瞎设计。 当 你选

导你瞎设计。 当 你选 了一个很厉害的后 端架构，比如说LongGraph，啊， 它会天然地诱导你 做一件事情， 你还没 有跑任何东西，就开 始设计节点。 你会忍

始设计节点。 你会忍 不住去想，这 件事情 应该拆成哪些 step，哪 些节点应该负责什 么事情，数据应该怎 么样在节点之间进 行一个流转。 听起来

行一个流转。 听起来 很专业，但是问题是， 你连最 简单的那个 问题能不能解决你 都不知道。 这个像闭

都不知道。 这个像闭 门造车似的，你车轮 画得再远，路多宽你 都不知道。 这个地方

都不知道。 这个地方 其实是有两重不确 定性的，第一个是 这 个问题到底能不能 被模型解决，第二个 就是你这个架构会 不会干扰它。 所以我

不会干扰它。 所以我 的建议其实很简单， 就是即使你选择用 了复杂架构，它不是 错的，但是 你至少要 用它最简单的用法 去跑一遍， 先把你这 个问题的baseline给跑出 来，知道任务的底线 在哪儿，之后再决定 我要不要加节点，要 不要 加更复杂的编 排。 那在我把AISDK跑起

排。 那在我把AISDK跑起 来之后，下一关自然 就是怎么样设计系 统提示词了。 我马上

统提示词了。 我马上 踩了一个超级典型 的坑，我想 把prompt也写 到最厉害，是吧？我当

到最厉害，是吧？我当 时找了各种各样成 熟项目的prompt，那种被 传来传去，号称效果 炸裂的。还不够， 我还

炸裂的。还不够， 我还 专门去 翻那种某知 名项目泄露出来的 系统提示词。我当时

系统提示词。我当时 心想啊， 别人写得这 么好，我照着抄总不 会差吧？ 结果两秒钟

会差吧？ 结果两秒钟 就翻车了。 第一，效果

就翻车了。 第一，效果 没有更好。第二，Token消

没有更好。第二，Token消 耗直接爆炸。 举个例

耗直接爆炸。 举个例 子，我只是想让它帮 我做一个视觉设计， 是吧？我不给复杂的

是吧？我不给复杂的 prompt，我就说一句你 是 一个视觉设计师，给 我一个方案。它能给

我一个方案。它能给 我一个快能用的结 果。那当我把那些专

果。那当我把那些专 业的提示词一股脑 地丢进去，它开始拆 步骤，规划流程，一步 步 执行，最后就是更 慢，但是不一定更好。

我自己的经验来说 啊，prompt第一版不要写 成那种很复杂的说 明书。 你可以先写得

明书。 你可以先写得 没有什么限制条 件， 然后看它会怎么去 做啊，然后再不断地 去添加你的限制条 件。比如说你想让这

件。比如说你想让这 个输出更加的格式 化，你想让哪个部分 进行多一点的思考， 啊你给它提供一些 例 子，让它根据这个 例子往外进行输出。

那只要这个Agent能够 follow你的指令，让它一 步一步往上加东西， 它能照着做。说实话

它能照着做。说实话 啊， 系统提示词这 一 关就已经过了。 接下

关就已经过了。 接下 来你会遇到一个非 常现实的问题，就是 很多时候它做不好， 不是这个系统提示 词写得不够好， 而是 这个任务本身需要 的能力 它根本就没 有。 举一个例子啊，就

有。 举一个例子啊，就 我让AI帮我做动效 设计的时候，其实我 期待的是它能参考 网上流行的一些设 计，但问题是它根本 拿不到这些数据，是 吧？这个时候你再怎

吧？这个时候你再怎 么改提示词都没有 用，不是写法的问题， 是能力的缺失。 所以

是能力的缺失。 所以 这一步正确的动作 就不是再去改系统 提示词了， 而是加工 具。 如果我希望它能

具。 如果我希望它能 参考网上的信息，那 它就必须要会搜索。

我希望它写的代码 是可用的，它就必须 能验证。 那这个时候

能验证。 那这个时候 我们才需要真正地 引入工具。 当你把三

引入工具。 当你把三 四个工具加上去之 后啊，你会有一个很 明确的感觉， 就是它 开始像一个Agent了啊， 它开始自己想清楚 该用哪个工 具，甚至 开始把工具串起来 用， 这就是所谓的涌 现啊，就是工具之间 出现了一加一大于 二这样的一个效果。

而且你要注意， 在这 个阶段，其实我们 没 有做什么复杂的架 构，我们还没有去引 入这样的一个规划， 我们的这个系统提 示词也还是最基础 的版本。 那说实话，在

的版本。 那说实话，在 刚开始加 工具的那 段时间啊，做Agent的体 验就是爽爆了。你每

验就是爽爆了。你每 加一个工具，它就明 显地变得聪明一点， 之前做不了的事就 能做了。之前做得很

能做了。之前做得很 勉强的事情，现在居 然能跑通了。 你就会

然能跑通了。 你就会 忍不住继续加，继续 加，继续加，啊，这个时 候你会非常地开心。

但很快你会进入到 一个非常诡异的阶 段， 不是偶尔的失败， 而是这个Agent的 性能 持续性地变差， 成功 率开始下降，准确率 忽高忽低啊，有的时 候它开始听不懂人 说话，而且你能明显 地感觉到啊，它不是 不会做， 而是越做越 乱。 这个地方其实不

乱。 这个地方其实不 是模型不行了啊，而 是你的上下文开始 失控了。 工具一多，每

失控了。 工具一多，每 一个工具背后呢，都 会有一大段说明。任

会有一大段说明。任 务复杂，输入本身也 会变得更复杂。再加

会变得更复杂。再加 上历史对话呀，代码 呀，图片这种各种各 样的信息， 所有的信 息一股脑地塞进模 型里面，导致 太多太 散啊，模型的注意力 被平均地分散掉了。

这其实是一个非常 典型的现象，上下文 的注意力牺牲。 这个

的注意力牺牲。 这个 时候我们才真正地 需要我们 视频一开 始提到的Anthropic的第一 篇文章Context Engineering。Context Engineering本质

篇文章Context Engineering。Context Engineering本质 上只干一件事，就是 在做某一类 任务的 时候，让模型只看到 它需要看到的东西。

还是拿我们这个视 频Agent来举例啊， 当我 们想要设计某种视 频效果的时候啊，它 其实 是两种不同的 任务啊。第一种是设

任务啊。第一种是设 计，它关心用户的意 图，视觉的风格、 版式、 元素、氛围，它需要大 量的开放的、可发散 的信息， 啊，然后对这 些信息进行分析和 总结。 第二类是写代

总结。 第二类是写代 码， 把设计好的信息 进行一个实现， 它关 心的是明确的口令， 接口的结构，输出的 格式以及正确性。 它

格式以及正确性。 它 需要尽量少、尽量精 确的信息。 如果把这

确的信息。 如果把这 两件事情混在一起， 会发生什么？就是任

会发生什么？就是任 务小的时候可能还 能跑一跑，但 是任务 一旦复杂， 设计的那 些信息会开始扰乱 代码生成的准确性。

代码的信息可能会 拖慢设计的判断，是 吧？ 两个任务 相互开

吧？ 两个任务 相互开 始污染上下文， 系统 需要花大量的时间 去把它理清楚。当不

去把它理清楚。当不 同的任务明显需要 不一样的上下文的 时候， 啊，上下文的隔 离才会有意义。 这个

离才会有意义。 这个 时候我们才会开始 考虑，我是不是需要 有一个顶层的规划 者，啊，他知道所有全 局的信息，呃，然后去 调度下面的这些执 行者。但这些执行者

行者。但这些执行者 可能只 负责一些专 项任务，比如说设计 的这个sub-agent就只负责 设计相关的内容， 代 码的这个sub-agent就只负 责代码的内容，并且 这两个执行者 通过 规划者的控制，只看 到自己需要的那一 小撮必要信息。所以

小撮必要信息。所以 其实如果我们看到 一些设计啊，它虽然 设计了一个sub-agent，但是 它的 这个 sub-agent 和它这 个顶层的这个规划 者，他们看到的上下 文是一样的话， 那这 样的一个sub-agent就完全 没有意义。 那当我们

没有意义。 那当我们 开始真正使用sub-agent这 种结构，或者说开始 使用规划者、执行者 这种结构的时候呢， 会立刻遇到一个绕 不开的问题啊。 我们

不开的问题啊。 我们 假设用户现在给了 一段代码， 希望我们 帮他改， 那这个时候 呢， 顶层的规划者会 看到这段代码， 但是 顶层的规划者呢， 不 负责写这个代码， 他 需要把这个 任务交 给下面写代码的这 个执行者。 那问题来

个执行者。 那问题来 了， 规划者怎么把这 段代码百分之百原 封不动地交给执行 者？ 最 直接的解决方

者？ 最 直接的解决方 案，你把这个输入进 来的东西，就，就再输 出一遍呗，输出一遍， 然后给到这个执行 者。 这一步其实非常

者。 这一步其实非常 不合理啊，因为这里 发生了两件很糟糕 的事情。 第一个， 你其

的事情。 第一个， 你其 实是在为这个复制 粘贴付费的， 输入了 一段代码， 输出了一 段代码， 其实我们只 是在做copy paste，但是却 消耗了大量 的output token。

我们知道output token是很 贵的，是吧？ 第二件事

贵的，是吧？ 第二件事 情， 你根本没有办法 保证一字不差。 模型

保证一字不差。 模型 并不擅长机械复制， 哪怕你明 说，是吧，一 行都不要改， 它也很 可能会把一个明显 的Bug给改了， 是吧？或

的Bug给改了， 是吧？或 者说你输入的这个 代码里面有一个标 点符号是错的，我把 这个标点符号给它 改正 确了。 我本来就

改正 确了。 我本来就 是要去修Bug，结果你 还没有传到执行者 这儿，是吧，你这个Bug 就被解决了。 啊这样

就被解决了。 啊这样 的情况在很多场景 下可能是灾难性的。

所以在这 一刻，我们 意识到了一件事， 有 些信息我只想存着， 而不是让模型反复 读写。 啊那到这个时

读写。 啊那到这个时 候啊，我们必须得引 入memory记忆体这个概 念了。那这方的机器

念了。那这方的机器 系统也很简单啊，它 不是在传递这个内 容，而是在传递内容 的指针。 啊也就是说，

的指针。 啊也就是说， 呃，顶层的规划者看 到这段 代码之后呢， 它就把这段代码写 到一个文件系统里 面， 啊，然后这个文件 系统对应的这个文 件名是什么。 那它告

件名是什么。 那它告 诉下面这个写代码 的执行者的时候，它 就说， 哦，呃，你需要改 这段代码，这个代码 存在了哪儿啊？然后

存在了哪儿啊？然后 执行者需要做的一 件事情是，他根据这 个文件名把这个内 容给读出来，然后去 改代码就可以了。 那

改代码就可以了。 那 在这个 过程里面呢， 规划者不输出完整 的代码，啊，执行者不 依赖于这规划者的 输出， 从而让输出的 token成本直接下降，让 错 误率明显地降低。

所以这一整段其实 都是在讲一个判断， 就是当你开始做上 下文隔离的时候， 当 你需要开始传 递不 能改动的长内容的 时候， 记忆系统就不 再是优化项，而是一 个必需品。 那么我们

个必需品。 那么我们 把这个记忆系统的 概念引入之 后呢， 我 们又会听到一个很 常用的说法，就是，呃， 有内存，有外存，啊，那 这两个词其实没有 那么玄乎哈，它的区 别也很简单，就是如 果在这 轮对话，啊，结 束之后就消失的，就 是内存，啊， 如果说多 轮对话它都能拿到 的东西呢，就叫外存。

啊这不是两种神秘 的能力啊，本质上就 是说 我需要做一个 决定，这个东西存在 哪儿，存多久。 为什么

哪儿，存多久。 为什么 有这样的差别？因为

有这样的差别？因为 有些信息它就只对 这一轮有用，如果你 把它写到外面去，是 吧，继续带着， 它很有 可能会变成噪 音或 者污染下一轮的这 个行为，啊，所以它就 应该留在内存里。 但

应该留在内存里。 但 有些信息呢，就必须 跨轮次地保存。 最典

跨轮次地保存。 最典 型的就是像Cloud Code，像 Cursor里面的那个 To-do list， 呃，任务的步骤比较 多，中间需要用户的 确认，那你引入了一 个外部的状态系统， 来去告诉AI，我们现 在走到第几步了，用 户给了什么样的输 入，我现在不该执行 什么了。啊，所以不要

什么了。啊，所以不要 一上来看到，哦，记忆 体内存、外存，我都要 用，是吧？ 顺序永远都

用，是吧？ 顺序永远都 是你走到这个阶段， 啊发现不 用不行了 你才用。 那最后， 当你

你才用。 那最后， 当你 有了这种sub-agent的系统， 有了上下文隔离，有 了这个记忆体系统 之后啊，整个系统会 变得非常的复杂， 也 很难地去进行调试， 或者说去进行一个 debug。这个问题就变成

debug。这个问题就变成 了我到底怎么样评 价它哪里做得好，哪 里做了差？ 啊， 答案只

里做了差？ 啊， 答案只 有一个， 我们把每一 次的运行全过程全 部都存下来啊。 这方

部都存下来啊。 这方 要存的不是结果，要 存的是过程，存它到 底用了哪些工具，工 具调用得顺序是什 么，每步消 耗了多少 token啊，有哪一些上下 文根本没有被用到， 有哪些信息不应该 给到这个执行者？是

给到这个执行者？是 吧？当你回头去读这

吧？当你回头去读这 样一整个流程的时 候，你才会知道 怎么 样能够把任务规划 到更快、token用得更少、 成功率更高。 那到这

成功率更高。 那到这 一步，啊，你会突然发 现了， 哦，原来我们之 前读的两篇文 章和 这样的一个系统才 终于是对上了。啊Long-run

终于是对上了。啊Long-run task为什么一定要 memory？

是吧，context engineering到底是在 做什么？ 我最开始失

做什么？ 我最开始失 败的原因其实不 是 这两篇文章不对，啊， 而是我当时所处的 那个阶段还不需要 用到这些东西啊。 它

用到这些东西啊。 它 们这种比较成型的 文章，更像是一个毕 业设计的完整图纸， 是吧？当你已经做过

是吧？当你已经做过 中间所有的实验，踩 过坑，回头看的时候， 你会发现，欸它其实 设计得很完美，设计 得很精巧。 但是如果

得很精巧。 但是如果 你第一天开始学画 这个图，是吧，就 直接 照着这个毕业设计 去进行一些施工， 你 大概率连第一根这 个梁你都溜起来了。

问题不是这些架构 不够优雅，也 不是你 不能选择优雅的架 构， 而是你不需要一 上来就优雅。 千万不

上来就优雅。 千万不 要让优雅变成你 AI 系统设计路上的绊 脚石。 那以上 就是本

脚石。 那以上 就是本 期视频全部的内容， 如果你觉得我们的 视频做得还不错的 话，欢迎点赞收藏转 发订阅评论我们的 频道，这对我们来说 非常重要。感谢你的

非常重要。感谢你的 收看，祝你学习顺利。