--- article.previous.md
+++ article.md
@@ -8,83 +8,223 @@
---
-## 基础模型限制与纵轴工程路线
-
-如果你有在关注 AI，这一两年最炙手可热的工作一定是 AI Engineer、AI Builder。大型语言模型越强，这群人越吃香，他们有能力帮公司打造内部工具、优化运营流程，也已经有一堆人自己动手把想法做成产品，成立了自己的公司。而这种人，现在每间公司都在抢。想学 AI 的人很多，但大多数人都不知道从哪里下手，市面上的资源不是太破碎就是太过艰涩，看完还是不知道自己学到了什么，或者下一步该往哪走。
-
-斯坦福大学有一堂课叫作 Beyond LLM，我认为这是目前最接近那个答案的东西。从大型语言模型的本质讲起，一路带到 Prompt Engineering、RAG、Fine-Tuning、Agentic Workflow，还有 Multi-Agent 的框架。这堂课时长两小时，今天我就用一支影片的时间把核心整理给你。你看完之后，会对 AI 在商业领域上的应用有一套完整的认知框架，知道这些技术怎么组合在一起，也能规划自己接下来的学习路线。那我们废话不多说，直接开始。
-
-首先我们要知道大型语言模型的限制是什么。LLM 要变强有两条路：第一条是横轴，就是换更强的 base model，比方说从 GPT-4 升级到 GPT-5。但横轴是 OpenAI 跟 Anthropic 在做的，一般人没有那个能力，也没有那个金钱去训练自己的大型语言模型。你能施力的地方是纵轴，也就是在现有的 LLM 上面叠各种工程技术，又叫做 Augmenting LLM，也就是想办法提升这些 base model 的能力。而这整堂课，包括这支影片，讲的都是纵轴的事情。如果你只会使用 base model，在商业场景上一定会撞墙。举个例子，ChatGPT 刚出来的时候没有连网功能，没办法调用工具，充其量就是一个很聪明的问答机器人，没办法实际帮你做完一件事。
-
-Stanford 的教授整理了 base model 几个常见的限制。第一是缺乏 domain knowledge。比方说有一组学生做自动化农业设备，要用相机判断作物有没有生病，这种农业病害的数据集市面上根本找不到。换句话说，你的公司资料、内部文件、产品规格，base model 都不知道，它也没办法根据这些资料帮你解决问题。第二是信息落后。模型不可能每几个月重训一次，新词、新事件、新公司它通通不认得，年轻人在用的网络流行用语模型大多也听不懂。第三个，控制很难。LLM 是概率性输出，同样的 prompt 跑两次可能结果不一样。在 ChatGPT 上聊天当然 OK，但你想想生产环境，用户问退费，AI 一下说可以一下说不行，公司就麻烦了。教授说，就连 OpenAI 跟 xAI 这种资金最多、人才最齐的团队，都还没办法把 LLM 完全控制好，更何况一般公司。第四个，当 context 太长，模型的表现会显著退步。现在主流模型的 context window 已经拉到 100 万 token，差不多十几本书的长度，但在这么大的 context 里还是会出现 lost in the middle 的现象。简单讲，你把“Gary 午餐吃了一颗苹果”这样的小细节藏进公司过去一年的会议记录里，再问模型 Gary 午餐吃了什么，虽然这个状况现在已经显著改善，但 LLM 有时候还是会答不出来。想做 AI 产品，光换更强的 base model 不够，你需要在纵轴上施力。
-
-## Prompt Engineering：基本功与最佳实践
-
-接下来这支影片的前半段会告诉你强化单一 LLM 的三个工具和观念，也就是 Prompt Engineering、Fine-Tuning 还有 RAG。影片后半段会进到系统设计，介绍 Agentic Workflow 和 evaluation 评估方法，然后用一个客服 agent 的 case study 把这些东西串起来，最后也会带到很多人感兴趣的 Multi-Agent。那我们直接从 Prompt Engineering 开始讲。
-
-Stanford 的教授说他不认为 prompt engineer 会是一个职业，因为提示词工程应该是每个工程师都该会的基本技能。你不会靠 prompt engineering 当饭吃，但这个技能会让你的职业生涯用一辈子，就像九九乘法表一样是基本功。我之前做过一部影片专门在讲 prompt engineering，有兴趣的朋友可以去看。关于 prompt engineering，有一个很有意思的研究我想分享给你。顶级管理顾问公司 BCG 做过一个实验，他们把一群顾问分成三组：第一组没有 AI，第二组可以使用 ChatGPT，第三组则是在使用 ChatGPT 之外还有接受撰写提示词的训练。最后研究结果发现三件事。
-
-第一个叫 The Jagged Frontier，锯齿边界，意思是 AI 不是在所有任务上都表现得好，有些任务搭配 AI 显著加分，但有些任务 AI 反而扯后腿。第二个发现叫 Falling asleep at the wheel，翻译成中文就是在方向盘前打瞌睡——当你不知道任务刚好是 AI 不擅长的，却太信任它把产出直接送出，结果比没用 AI 还惨。也就是说，你要知道 AI 的边界在哪，才不会在它弱的地方踩雷。第三个现象最有趣，他们发现使用 AI 的方式分成两种，分别是 Centaurs 和 Cyborgs。Centaur 是半人马，也就是分工委派型，丢一个长 prompt 给 AI 叫它做整份简报，自己去做别的事。Cyborg 是生化人，是高频率来回型，跟模型一句一句对话协作。Stanford 的教授说，学生的使用习惯会比较像 Cyborg，而企业在自动化 workflow 时比较像 Centaur。那你应该用哪一种？关键看任务性质。重复性高、流程清楚的任务用 Centaur 模式委派出去就好；需要判断、需要创意、需要来回校正的任务，Cyborg 模式才能逼出 AI 的最佳输出。两者没有好坏之分，实务上两种都会用，重点是要有意识地切换。
-
-接着进到实作。通常一个好 prompt 要有三个东西：给谁看、产出格式、重点是什么。“请帮我总结这篇文章”是一个很烂的提示词，因为什么信息都没给。但如果你写的是“请将这份可再生能源论文整理成 5 个重点摘要，并且聚焦在其背后的政策意涵上”，模型立刻知道对象是政策制定者，长度是 5 个点，重点放在政策意涵上，你的产出质量会立刻提升。但教授说，prompt engineering 里最常用、最重要的一个技巧不是这些，而是 Prompt Chaining。注意，chaining 跟 Chain of Thought 不一样。Chain of Thought 是叫模型 step by step 思考，Chaining 则是把一个复杂的 prompt 拆成多个独立的 prompt，前一个的 output 喂给下一个。有用过 n8n 的朋友应该知道我在说什么。举例，你要做客户投诉回信。单一个 prompt 写法是：“读这封投诉信，写一封专业的回应”，这就是一个黑盒子，最后产出如果有问题你也不知道该调整哪里。但如果使用 prompt chaining，拆成三个 prompt：第一个抽出客户在抱怨什么，第二个用抽出来的问题起草大纲，第三个用大纲写完整回信。每一步都可以独立测试、独立 debug。Chaining 不只让模型表现更好，也让你得到 observability，能观察 LLM 在做什么、哪个流程出了问题。
-
-## Fine-Tuning：能不做就不做
-
-讲完 Prompt Engineering，下一个是 Fine-Tuning。Stanford 教授对 fine-tuning 的立场很简单：能不做就不做。原因有四个。第一，要大量的优质数据。如果你想要自己 fine-tune 模型，就要有大量高质量的、标注好的资料，成本对一般人来说太高了。第二，容易 overfit。模型容易在你那个特定任务上变得很强，但通用问题反而答不出来，就会失去 base model 原本的广度。第三，时效性差，这应该是最伤的点。你花两个月 fine-tune 完一个模型上线，下个月新一代 base model 就出来，直接打贏你 fine-tune 的版本。第四，通常用 prompt engineering 也可以达到一样的效果，而且成本低很多。你想换新 base model，原本的 prompt 大多都是 portable 的，但 fine-tuning 的模型不行。当然，针对少数情境，fine-tune 还是值得做的，比方说法律、科学那种需要重复高精度输出的领域，或者 base model 在某些 domain 上表现吃力的情况。但大多数人不会得到太大的效益。
-
-## RAG：注入领域知识的标准方案
-
-所以，如果你想把特定的 domain knowledge 塞进模型，单纯的提示词工程可能塞不下，fine-tuning 的成本效益又对不起，那实作端应该怎么办呢？Stanford 教授给出的答案是 RAG。RAG 是 AI 工程师面试最常考的题目之一，面试官常常会请你用五岁小孩听得懂的方式解释什么是 RAG。你做 AI Builder 也好，做 AI 工程师也好，这是你一定要知道的事情。RAG 解的痛点有几个：context window 太小、长 context 抓不准、信息有时效性，或者模型会产生幻觉。RAG 的做法很单纯，我用“药物副作用”这个需要高度准确的医疗场景来说明。通常 RAG 的做法是这样：先把所有资料、文件用 embedding 模型把这些信息转成向量，存进向量数据库，英文叫 vector database。所谓向量，就是把一段文字的语义转换成一串数字，语义相近的文字转出来的数字数组在数学空间里距离也会比较近。所以当用户问“药物 A 的副作用”，我们不是在做关键字比对，而是在找语义最接近的文件片段，就算文件里写的是“不良反应”而不是“副作用”，一样能找到。用户的问题也用同一个 embedding 模型转成向量，再用距离 metric 从 vector database 里找出最相近的 documents，最后把这些 documents 加上 system prompt，加上 user query，组合成喂给 LLM 的最终 prompt。Prompt template 大概长这样：“根据以下 documents 回答用户的问题，如果 documents 里没有答案，就说‘我不知道’。”这样设计是为了把模型锁定在你提供的资料范围内，避免它自由发挥、凭空捏造。当然，你还可以要求模型回答时附上这个答案来自第几页、第几章、第几行加超链接，这样用户可以自行回溯数据源进行验证。
-
-但是单纯这样做有时候不够。比方说一种药的相关文件可能足足有 50 页，整份直接转成向量，很多细节遗漏其中。所以通常会搭配 chunking。最基本的 chunking 是把文件切成固定大小的片段，每段各自转成向量。更进阶的做法是多层次存储，同时保留整篇、每章、每段的向量，retrieval 时可以先找到相关的章节，再往下钻到精确的段落，这样在大文件里的命中率会更高。还有一个最近比较多人在讨论题：有人说像现在已经有模型支持超长的 context window，等这个技术成熟、算力够便宜，base model 直接读完整数据库，RAG 就没用了。但 Stanford 的教授认为这样的说法理论上对，实务上错。因为实际上你还会遇到很多问题，比方说 latency——你想想看，每次问问题模型都要把整个 Google Drive 重读一次，没人等得了。就像搜索引擎也是靠预先建好的索引来快速定位资料，不可能每次 query 都把整个网络重新爬一遍。所以 RAG 除了准确度以外，还有检索效率、可即时更新这类优势，而这些优势在可预见的未来都还是有存在的价值。
-
-好，到这边我们讲完了影片的第一部分。从 base LLM 的限制出发，我们看了 Prompt Engineering、Fine-Tuning 还有 RAG，这三个工具本质上都是在强化单一 LLM 的能力。但单一 LLM 再强，还是有它做不到的事。所以接下来进入第二部分 AI 系统设计，我们会讲 Agentic Workflow、Evaluation 还有 Multi-Agent。这些东西让你能把 AI 从一个会回答问题的模型变成一套真正可以运作、实际产出价值的系统。看到这边，如果你觉得这支影片对你有帮助，想请你帮我按个赞、点个追踪，这是我持续创作下去的动力。那我们直接进 Part 2。
-
-## Agentic Workflow：从模型到系统的心法
-
-先讲一下 Agentic Workflow 这个命名。这个词来自吴恩达。如果你不认识他，吴恩达是 Coursera 的共同创办人、Google Brain 的创始负责人、前百度首席科学家，是在 AI 领域讲话有一定分量的人。吴恩达用 Agentic Workflow 这个词是因为 AI Agent 已经被用烂了：有人写了一个很长的 prompt，叫 agent；有人做了复杂的 multi-agent 系统，也叫 agent。这个词什么都能套，反而什么都说不清楚。所以他用 Agentic Workflow 来精确描述一件事：把一堆提示词、外部工具还有各种元件组合进一个有结构的工作流程里，成为一套系统，这就叫 Agentic Workflow。还记得我们前面讲的 RAG 吗？RAG 主要做一件事：给 LLM 外部数据当参考。但 agent 把 RAG 当作工具之一，外加 tool calls、memory、多步骤决策，所以能做到 RAG 单独做不到的事。举个例子，用户说“我想退这笔订单”，RAG 只能丢政策文件给你；agent 则是用 RAG retrieve 政策，主动问订单编号，用 tool 查订单，确认退费，告诉你 3 到 5 个工作日会处理。RAG 是工具，Agent 是使用 RAG 这个工具的系统。
-
-要打造 Agentic Workflow，你的工程心态要先翻转过来，因为传统 software 跟 agentic AI software 在四个面向都很不一样。首先是数据，传统软件吃结构化数据——JSON、数据库、表单，格式固定，边界清楚；Agentic 系统吃的是自由文本、图片、音频，没有固定格式。第二个是逻辑，传统 software 是 deterministic，同样的 input，永远给你同样的 output。
-
-用RAG检索政策，主动询问订单编号，通过工具查询订单，确认退费，并告知你3到5个工作日会处理。RAG是一种工具，而Agent是使用RAG这个工具的系统。要打造agentic workflow，你的工程心态需要先翻转过来，因为传统软件和agentic AI软件在四个维度上差异很大。
-
-首先是数据。传统软件处理结构化数据，例如JSON、数据库、表单等，格式固定，边界清晰。而Agentic系统处理的是自由文本、图片、音频，没有固定格式。第二个是逻辑。传统软件是确定性的，相同的输入永远给出相同的输出，可预测、可重现。Agentic系统则是模糊的，同样的输入在不同时间可能产生不同的输出，因为LLM本身带有随机性，加上它需要根据上下文做判断，没有固定答案。第三个是架构心态，这也是最重要的。传统工程师的思维是写微服务或单体应用，精确控制每一步执行路径。Agentic系统的思维则像管理者，你给AI一个目标和限制，让它自己决定如何完成，你管理的是方向和边界，而不是每一行代码。第四个是测试。传统测试是确定性的，跑一百次结果都一样。Agentic测试则是迭代探索式的，因为系统本身是非确定性的，对上下文非常敏感，你无法穷举所有情况。
-
-理解这四点之后，第一个落地原则就随之而来：能用确定性方法解决的问题，就用确定性方法解决；剩下的模糊部分，则加上护栏。教授举了自己的例子：在做技能评估时，选择题、配对题、拖拉题用确定性方法算分，因为这些问题有标准答案，对就是对，错就是错。但口语题、语音加编码的混合题型没有标准答案，无法用确定性方法评分，只能让LLM去判断，这就是模糊评分。比如，让LLM听一段语音回答，判断这个人是否真正理解了概念，表达是否清晰，逻辑是否正确，这些不是简单的对或错，而是程度的判断。LLM会给出一个分数，但这个分数是它认为合理的答案，不是计算出来的。模糊评分的问题是它一定会犯错，LLM可能误判一个正确答案，或对模棱两可的回答给出偏低分数。在考试评分这种高风险的场景下，这是不可接受的。因此，他们设计了申诉功能，受测者可以对agent的评分提出申诉，由真人介入审查并纠正。这就是护栏的具体形式——不是试图让AI零错误，而是在它出错时有人能兜底。
-
-## 打造Agent：核心要素与工具协议
-
-原则讲完后，要实际打造一个agent需要哪些东西？教授以订机票去巴黎为例，整理出三个核心要素。第一个是Prompts，也就是提示词工程，告诉AI它的角色是什么，它能做什么、不能做什么。第二个是Context Management，即如何管理agent在每一个当下能看到的信息，包括Memory（对话历史）、RAG检索回来的数据等，所有这些都要塞进有限的上下文窗口中。你需要决定什么重要、什么可以丢弃、什么需要压缩。Context Management本质上只做一件事：把正确的信息在正确的时间提供给agent。Memory本身又分为两层：Working Memory是高频率、需要快速访问的信息，比如用户的名字、这次的目的地是巴黎；Archival Memory是低频、可以慢一些的信息，比如用户过去五年的订房记录，需要时再去检索。第三个是Tools，即agent能够调用的外部能力，通常分为两种：一种是做事的，比如航班搜索、酒店预订、支付等；另一种是查资料的，比如从CRM系统检索客户数据、从数据库查询订单记录。
-
-此外，课堂上教授将agent的自主性分为三个层级。最低的是硬编码步骤，所有步骤都写死，必须按顺序执行，比如先识别用户意图、再查询历史记录、最后调用API。这种方式安全、可预测，但很僵硬，遇到预期外的情况就会卡住。第二层是硬编码工具，但让agent自己决定执行步骤。你给它一组工具，告诉它你是旅行顾问，这些是你能用的工具，怎么用由你决定。你控制工具范围，但给agent空间去判断如何组合。这是目前最常见的生产设置，也是教授推荐的起点。第三层是完全自主，agent自己决定步骤，甚至自己创建工具。给它代码编辑器、网络搜索功能，让它自己写代码解决问题。这种模式能力最强，但风险也最高，你无法完全预测它会做什么。如果agent判断错误，自己订了100张机票，你就完蛋了。
-
-还有一个关键概念是MCP（Model Context Protocol）。传统做法是你要为每一个API单独编写串接逻辑，教会LLM如何使用这个API、那个API需要传什么参数。而MCP的做法是在中间放置一个协议层，agent不需要认识每一个API，只需与MCP服务器沟通，MCP负责帮它与背后的服务打交道。可以把MCP想象成一个通用插头——以前每个国家的插座规格不同，你需要带一堆转接头，但有了MCP，插一个就能全部通用。斯坦福教授还提到了对MCP的更大想象：即agent间的通信，你可以把别人做好的agent当作一种工具，让你自己的agent去调用它，就像现在agent调用API一样。这是Multi-Agent系统的基础。
-
-## Evaluation与实战案例
-
-无论是单Agent还是多Agent系统，上线之前都需要回答同一个问题：怎么知道它真正有效？答案是Eval（评估），这也是生产级Agentic系统的命脉。教授在课堂上给出了一个完整的评估框架，包含三个维度。第一个维度是端到端评估与组件级评估。端到端评估看整体，比如用户用完给几分、满不满意；组件级评估则拆开每一步看，比如某个工具老是忘记更新邮件、发送邮件那一步格式不对。只看整体你知道哪里出了问题，但不知道原因；只看组件你可能修复了细节但整体体验仍然差。实际上两者都需要。第二个维度是客观评估与主观评估。客观评估是可以通过自动化验证的，比如用户说订单ID是X，LLM写入数据库变成Y，你可以编写Python脚本自动对照，因为对就是对、错就是错。主观评估没有标准答案，比如语气好不好、回答够不够有同理心，这需要人工评分，或使用另一个LLM作为评审。第三个维度是定量评估与定性评估。定量评估是数字，比如改地址成功率是多少、每个环节的延迟有多长。定性评估是感觉，比如在哪里出现幻觉、语气哪里不对、用户在哪一步卡住，这需要人工逐一查看，没有捷径。
-
-刚刚提到的用LLM作为评审（又称LLM-as-Judge）是进行主观评估的常用做法。设计上有四种主流玩法：第一种是成对比较，给评审两个答案，问它哪个更好；第二种是单项答案评分，直接打1到5分；第三种是参考引导的成对比较，额外提供一个标准答案做对比，让评分更有依据；第四种是基于评分标准的，你自己定义评分标准，比如5分等于100字以内、包含三个要点、第一句是概述，0分等于答非所问、冗长失焦。这四种方法可以混用，比如基于评分标准加上少量示例，让评审更清楚你要什么。
-
-如何实际进行主观评估？课堂上教授以旅行顾问礼貌度评估为例，拆成四个步骤。第一步是错误分析，从1000个用户对话中抽取20个进行人工阅读，你可能会发现LLM说话很短、有点生硬、缺乏同理心。这一步不能省，你必须先了解问题长什么样，才能设计出正确的评估。第二步是设计评估，使用LLM-as-Judge加上自己编写的礼貌度评分标准，将第一步发现的问题翻译成评分标准。第三步是A/B测试模型，固定提示词，将底层模型从GPT换成Opus或其他模型，然后运行同一批对话，让评审评分，看哪个模型礼貌度最高。第四步是A/B测试提示词，固定模型，将“扮演旅行顾问”改成“扮演乐于助人的旅行顾问”，看一个词的差异影响有多大。核心原则只有一个：先人工找出问题，再设计自动化评估，而且模型和提示词这两个变量一次只动一个，否则不知道是哪个改动造成了差异。
-
-讲完评估，教授给出了一个完整的案例研究，把所有前面的内容串联起来。题目很简单：我们要做一个客服AI agent。用户可能会说“我要改A127订单的地址，因为我搬家到建国南路了”。这样的AI客服agent你会怎么做？这个题目有两层：表面上看是如何改地址，本质上是如何构建一个能够自主处理客服请求的agent。课堂上一个学生回答说：“我会先去客服旁边坐一到两天，看他们实际如何处理这类请求，他们的日常工作流是什么。”教授很喜欢这个答案，因为你要先理解人如何做这件事，才知道如何让AI做。而这就是构建agentic workflow的第一步，叫做任务分解，即把大任务拆解成小任务，让LLM可以逐个击破。
-
-经过观察，你会发现客服处理一个改地址请求实际上走了五步：第一步，提取关键信息，包括客户的意图是什么、订单ID是哪个、新地址是什么；第二步，去数据库查询客户记录；第三步，查询公司政策，比如这笔订单能否改地址、是否已经发货；第四步，根据前面收集的信息起草回复邮件；第五步，发送邮件。每一步都很明确，这就是任务分解。有了任务分解，下一步是决定每一步用什么工具。第一步提取信息，单纯用LLM的一次API调用通常就能解决。第二步查询和修改数据库，需要自定义工具或MCP服务器。第三步检查政策，需要用RAG，因为政策文件会更新，且需要高效检索，不能让客户等太久。第四步是根据前几步收集的信息开始撰写邮件。第五步发送邮件，使用agent能够调用的邮件发送工具。做这些判断的方法很简单：先问自己哪些步骤是模糊的、哪些是确定性的，再决定每一步是用LLM一次性调用、RAG、工具还是其他手段。这就是AI Builder真正在做的工作——了解每个工具、每种技术的能力和限制，然后组合出你需要的解决方案。
-
-最后是构建评估，把前面讲的三个维度全部用上。端到端评估看最终回复的正确性、语气、用户满意度；组件级评估拆开看每一步，比如提取信息的准确性、API错误率、政策遵守率。客观部分可以自动验证，比如提取的订单ID是否正确、是否违反退款政策。主观部分需要人工加上LLM-as-Judge，比如回复是否有礼貌、有同理心。定量评估看改地址成功率、延迟、退款正确率。定性评估看哪里有幻觉、哪里语气不一致、用户在哪一步感到困惑。到这里，一个完整的AI客服agent从零到上线的工程流程就出来了，总共三个步骤：先把大任务拆解成小任务，再设计工作流程，最后建立评估系统，确保产出稳定。
-
-这堂课的最后一个主题是Multi-Agent（多智能体系统）。前面单个agent已经能够拆分步骤、调用工具、做RAG、写信，看起来够用了。但Multi-Agent仍然有存在的理由，主要原因是并行处理。有些事情没有理由排队执行，比如订机票时，找航班、找酒店、查天气这三件事完全可以同时进行。如果只有一个agent，就只能一件一件做。Multi-Agent就是把这些可以并行的事情拆给三个专门的agent同时运行，速度直接提升。次要原因是可复用性。公司里的设计agent可以给市场部门用，也可以给产品部门用。不过，Multi-Agent听起来很厉害，但做产品时首先要问自己是否真的需要。如果一个agent就能解决的任务，硬上Multi-Agent反而增加复杂度。所以还是那句老话：工程设计能简单就简单，不要过度设计。
-
-## Multi-Agent与课程总结
-
-教授以智能家居为例进行头脑风暴。一个完整的智能家居Multi-Agent系统可能包含温度控制、灯光、安全、娱乐、通知以及能源管理等agent，再加上一个协调者统筹。互动模式有两种：第一种是层级式，用户只与协调者对话，由它分派任务给下面的agent，指挥链清晰；第二种是扁平式，agent之间直接互通，没有中间人。教授建议智能家居以层级式为主，因为从用户角度，你不想同时与五个agent对话，只想跟一个助手说你出门了，它就会自动协调灯光、安全、温控。但在后台，某些agent之间可以建立横向沟通渠道，比如温度控制agent与能源管理agent直接互通，省去每次都要经过协调者的沟通成本。当agent之间互相沟通时，本质上就是MCP协议的应用——你把agent当作工具。
-
-在层次化（Hierarchical）架构中，由一个 orchestrator 负责指挥，派工给下面的 agent，指挥链清晰。第二种是扁平（Flat）架构，agent 之间直接互通，没有中间人。教授建议智慧家庭以 hierarchical 为主，因为从用户的角度，你不想同时跟五个 agent 讲话，只想跟一个 assistant 说“我要出门了”，它就会自己去协调灯光、保全、温控。但在后台，某些 agent 之间可以有水平沟通的连线方式，比如温度控制的 agent 跟能源管理的 agent 直接互通，省掉每次都要经过 orchestrator 的沟通成本。当你让 agent 之间互相沟通，本质上就是 MCP protocol：你把 agent 当作 tool，就跟把 API 当作 tool 一样。这个心态一旦想通，设计就清楚了。每个 agent 对外暴露一组 tool-like 接口，其他 agent 像呼叫工具一样呼叫这个 agent。这样做结构干净，容易 debug，也支持平行处理。Multi-agent 听起来复杂，但其实只是把你已经懂的东西多叠一层。
-
-好，那最后整理一下这堂课的重点。我们从基础模型的限制开始讲起，并带到能够加强模型表现的技术。首先是 Prompt Engineering，强化 LLM 输出，成本最低，重点放在 chaining 和 testing。第二层是 Fine-Tuning，除非你在处理法律、科学那种需要重复高精度的 domain，或者兴趣使然，否则别没事找事去调模型。第三层是 RAG，帮模型补足知识的标准解法，做 AI 产品基本上一定会碰到。最后是 Agentic Workflow，从强化单一 LLM 进到系统设计，重点是思维上的心态转变——从过往的 deterministic engineering 到现在的 fuzzy engineering，以及应对 fuzzy engineering 的 evaluation 系统，还有在实战上要如何从拆解任务开始，打造自己的 agentic workflow。第五层是 Multi-Agent，把每个 agent 都当成 tool，彼此协作来提升处理速度和复用性。教授在两个小时内跑完产业上常见的实作技巧，每个技术的存在理由和适用情境都交代清楚。有了这样的认知，你就不会盲目跟风——看到别人在做 multi-agent 就跟着做，看到别人讲 fine-tuning 觉得很帅就去玩自己的模型。
-
-那么你的下一步是什么？我给的建议是，从实作中学习。看看你的生活上或工作上有什麼痛点，从痛点出发去思考解决方法。在这个过程中你就会发现自己需要学会哪些技术，就能很有效率地规划自己的学习路线。我把这支影片整理成了一篇深度文章，附带 4 组 prompts：帮你想清楚自己的 workflow 怎么拆、现有架构有没有 over-engineering、帮你建立 eval 系统、以及该不该上 multi-agent。有兴趣的朋友可以在信息栏找到链接。那今天这支影片差不多就讲到这边。如果你喜欢这样的内容，想请你帮我点个赞，也在底下留言告诉我你们想看什么样的内容，那我们下次见。
+## LLM的局限与纵向增强之路
+
+如果你關注過 AI，就會發現近一兩年最炙手可熱的職業，一定是 AI Engineer 或 AI Builder。隨著大型語言模型（LLM）能力不斷提升，這群人越來越吃香。他們能幫公司打造內部工具、優化運營流程，甚至有人已經自己動手把想法變成產品，創立了自己的公司。如今，幾乎每家公司都在搶這類人才。
+
+想學 AI 的人很多，但大多數人卻不知道從哪裡下手。市面上的資源不是太零散，就是太晦澀難懂，看完還是搞不清自己學到了什麼，也不知下一步該怎麼走。而史丹佛大學有一門課叫做 *Beyond LLM*，我認為這是目前最接近這個問題的答案。
+
+這堂課從大型語言模型的本質講起，一路涵蓋 Prompt Engineering、RAG、Fine-Tuning、Agentic Workflow，以及 Multi-Agent 框架，總時長兩小時。今天我就用一支影片的時間，把核心內容整理給你。你看完之後，會對 AI 在商業場景中的應用建立起一套完整的認知框架，清楚這些技術如何組合，也能規劃出接下來的學習路徑。
+
+我們直接開始。首先得理解大型語言模型的限制是什麼。LLM 要變強有兩條路：橫軸是換更強的 base model，例如從 GPT-4 升級到 GPT-5。但這條路是 OpenAI、Anthropic 這些巨頭在做的事，一般人既沒能力也沒資金去訓練自己的大模型。
+
+你能施力的地方是縱軸——也就是在現有的 LLM 上疊加各種工程技術，又稱為 Augmenting LLM。這整堂課、這支影片講的都是縱軸的事。如果你只會使用 base model，在商業場景中一定會撞牆。
+
+舉個例子，ChatGPT 初推出時沒有連網功能，也無法調用工具，頂多只是一個很聰明的問答機器人，無法真正完成一件事。史丹福教授總結了 base model 的幾個常見限制：
+
+第一，缺乏 domain knowledge。比如一組學生在開發自動化農業設備，要用相機判斷作物是否生病。這種農業病害的資料集市面上根本找不到。換句話說，你的公司資料、內部文件、產品規格，base model 都不知道，自然無法根據這些資訊解決問題。
+
+第二，資訊落後。模型不可能每幾個月就重訓一次，新詞、新事件、新公司它通通不認識。年輕人常用的網路流行語，模型大多也聽不懂。
+
+第三，控制困難。LLM 是機率性輸出，同樣的 prompt 兩次跑，結果可能不一樣。在聊天時當然沒問題，但在 production 環境就不行了——使用者問退費，AI 一下說可以，一下說不行，公司就麻煩了。教授指出，連 OpenAI 和 xAI 這樣資金最雄厚、人才最齊全的團隊，都還沒辦法完全掌控 LLM，更別說一般公司。
+
+第四，當 context 太長時，模型表現會明顯退步。現在主流模型的 context window 已經拉到 100 萬 token，約等於十幾本書的長度。即便如此，仍會出現「lost in the middle」的現象。舉例來說，你把「Gary 午餐吃了一顆蘋果」這樣的細節藏進公司過去一年的會議記錄裡，再問模型 Gary 午餐吃了什麼，它可能還是答不出來。雖然這個問題現在已大幅改善，但 LLM 有時仍會遺漏關鍵資訊。
+
+想做 AI 產品，光靠換更強的 base model 是不夠的。你需要在縱軸上用力。接下來這支影片的前半段會介紹強化單一 LLM 的三個核心工具與觀念：Prompt Engineering、Fine-Tuning 和 RAG。後半段則進入系統設計層面，介紹 Agentic Workflow 與評估方法，並以一個客服 agent 的案例，把這些技術串起來，最後也會談到很多人感興趣的 Multi-Agent。
+
+我們先從 Prompt Engineering 開始。史丹福教授認為，prompt engineer 不會成為一個獨立職業，因為提示詞工程應該是每個工程師的基本技能。你不會靠它賺飯錢，但它會伴隨你整個職涯，就像九九乘法表一樣，是基本功。
+
+我之前也拍過一部專門講 Prompt Engineering 的影片，有興趣的朋友可以去看看。這裡分享一個很有意思的研究：頂級管理顧問公司 BCG 曾做過實驗，將一群顧問分成三組：第一組不用 AI，第二組可用 ChatGPT，第三組除了可用 ChatGPT，還接受過提示詞撰寫訓練。
+
+結果發現三件事：
+
+第一，The Jagged Frontier（鋸齒邊界）——AI 不是在所有任務上都表現好。有些任務搭配 AI 顯著加分，但有些反而拖後腿。
+
+第二，Falling asleep at the wheel（在方向盤前打瞌睡）——當你不知道任務恰好是 AI 不擅長的，卻過度信任它，直接送出產出，結果比沒用 AI 還糟。這提醒我們：必須清楚知道 AI 的邊界在哪，才不會在它弱的地方踩雷。
+
+第三，最有趣的現象是，使用 AI 的方式分為兩種：Centaurs 與 Cyborgs。Centaurs 是半人馬，代表分工委派型——丟一個長 prompt 給 AI，讓它做整份簡報，自己去做別的事。Cyborg 是生化人，代表高頻互動型——跟模型一句一句對話協作。
+
+教授說，學生的使用習慣比較像 Cyborg，而企業在自動化 workflow 時則偏向 Centaur。那該用哪一種？關鍵在於任務性質。重複性高、流程清晰的任務，用 Centaur 模式委派即可；需要判斷、創意與反覆校正的任務，才適合用 Cyborg 模式，才能逼出 AI 最佳表現。兩者無優劣之分，實務上都會用，重點是意識到要主動切換。
+
+## 单模型能力强化三利器：Prompt、Fine-Tuning、RAG
+
+接下來進入實作。一個好的 prompt 必須包含三要素：目標對象、產出格式、核心重點。舉例來說，「請幫我總結這篇文章」是個爛提示詞，因為什麼資訊都沒給。但如果改成「請將這篇再生能源論文整理成 5 個重點摘要，並聚焦其背後的政策意涵」，模型立刻知道對象是政策制定者，長度是五點，重點在政策意涵，產出品質自然大幅提升。
+
+但教授指出，Prompt Engineering 中最常用、最重要的技巧其實不是這些，而是 Prompt Chaining。注意，chaining 跟 Chain of Thought 不同——Chain of Thought 是讓模型 step by step 思考，Chaining 則是把一個複雜的 prompt 拆成多個獨立的子 prompt，前一個的 output 餵給下一個。
+
+用過 n8n 的朋友應該很清楚這概念。舉例來說，你要寫客戶投訴回信。如果用單一 prompt 寫法，就是「讀這封投訴信，寫一封專業回應」——這是一個黑盒子，一旦產出有問題，你也不知道該調整哪裡。
+
+但如果用 Prompt Chaining，拆成三步： 第一，抽出客戶在抱怨什麼； 第二，根據問題起草大綱； 第三，用大綱寫完整回信。
+
+每一步都可以獨立測試、獨立 debug。Chaining 不僅提升模型表現，還帶來 observability——你能觀察 LLM 在做什麼，哪個環節出了問題。
+
+講完 Prompt Engineering，接下來是 Fine-Tuning。史丹福教授的立場很明確：能不做就不做，原因有四：
+
+第一，需要大量優質數據。想 fine-tune 模型，就得有大量標注良好的高品質資料，成本對一般人而言太高。
+
+第二，容易 overfit。模型可能在特定任務上變得很強，但通用問題反而答不出來，失去 base model 原本的廣度。
+
+第三，時效性差，這是最致命的。你花兩個月 fine-tune 完一個模型上線，下個月新一代 base model 就出來，直接打敗你原本的版本。
+
+第四，通常用 Prompt Engineering 就能達到相同效果，且成本低得多。你想換新 base model，原本的 prompt 大多都能直接移植；但 fine-tuned 模型不行。
+
+當然，針對少數情境，fine-tuning 仍有價值，例如法律、科學等需要高精度重複輸出的領域，或當 base model 在某個 domain 表現吃力時。但對大多數人來說，效益不高。
+
+所以，如果你想要把特定 domain knowledge 塞進模型，單純靠提示詞工程塞不下，而 fine-tuning 又成本效益不對，那實作端該怎麼辦？史丹福教授的答案是：RAG。
+
+RAG 是 AI 工程師面試中最常考的題目之一，面試官常常要求你用「五歲小孩聽得懂的方式」解釋什麼是 RAG。無論你是做 AI Builder 還是 AI 工程師，這都是必懂知識。
+
+RAG 解決的痛點包括：context window 太小、長 context 抓不准，以及資訊有時效性或模型會產生幻覺。
+
+以醫療場景中的藥物副作用為例，RAG 的做法很簡單：先把所有資料、文件用 embedding 模型轉成向量，存入向量資料庫（vector database）。所謂向量，就是把一段文字的語意轉成一串數字。語意相近的文字，轉出來的數字陣列在數學空間中距離也較近。
+
+因此，當使用者問「藥物 A 的副作用」，我們不是做關鍵字比對，而是找語意最接近的文件片段。就算文件寫的是「不良反應」而非「副作用」，一樣能命中。
+
+使用者的問題也用相同的 embedding 模型轉成向量，再用距離度量（distance metric）從 vector database 中找出最相關的 documents。
+
+最後，把這些 documents 加上 system prompt 與 user query，組合成餵給 LLM 的最終 prompt。典型的 prompt template 是：
+
+> 根據以下 documents 回答使用者的問題。如果 documents 裡沒有答案，就說「我不知道」。
+
+這樣設計是為了把模型鎖在你提供的資料範圍內，避免它自由發揮、憑空捏造。
+
+當然，你還可以要求模型回答時附上答案來自第幾頁、第幾章、第幾行，甚至加上超連結，讓使用者能自行回溯資料源驗證。
+
+但單純這樣做有時不夠。例如一份藥物文件可能有 50 頁，整份直接轉成向量，許多細節會遺失。因此通常會搭配 chunking——最基本的作法是把文件切成固定大小的片段，每段各自轉成向量。
+
+更進階的做法是多層次存儲：同時保留整篇、每章、每段的向量。檢索時可先找到相關章節，再往下鑽到精確段落，提高大文件中的命中率。
+
+最近也有不少人討論：既然現在已有模型支援超長 context window，未來算力足夠便宜，base model 直接讀完整個資料庫，RAG 就沒用了？
+
+但史丹福教授認為，理論上對，實務上錯。因為實際上你仍會遇到諸如 latency（延遲）的問題。每次問問題，都要讓模型重讀整個 Google Drive，沒人等得起。就像搜尋引擎依賴預先建好的索引快速定位資料，不可能每次 query 都重新爬一遍整個網路。
+
+## 从单模型到系统：Agentic Workflow的思维革命
+
+因此，RAG 不僅提升準確度，還有檢索效率與可即時更新的優勢。這些價值在可預見的未來依然存在。
+
+到此為止，我們完成了影片的第一部分：從 base LLM 的限制出發，介紹了 Prompt Engineering、Fine-Tuning 與 RAG。這三個工具本質上都是在強化單一 LLM 的能力。但單一 LLM 再強，也有做不到的事。
+
+所以接下來進入第二部分：AI 系統設計。我們將講解 Agentic Workflow、Evaluation 與 Multi-Agent。這些技術讓你能把 AI 從一個會回答問題的模型，轉化為一套真正能運作、實際產出價值的系統。
+
+看到這裡，如果你覺得這支影片對你有幫助，歡迎按個讚、點個追蹤，這是我持續創作下去的動力。
+
+我們直接進入 Part 2。
+
+先談 agentic workflow 這個名詞的由來。這個詞出自吳恩達（Andrew Ng）。如果你不認識他，他是 Coursera 共同創辦人、Google Brain 創始負責人、前百度首席科學家，是 AI 領域極具影響力的人物。
+
+吳恩達使用「agentic workflow」這個詞，是因為「AI Agent」一詞已被濫用。有人寫了一個長 prompt 就叫 agent，有人做了複雜的 multi-agent 系統也叫 agent。這個詞什麼都能套，反而什麼都說不清楚。
+
+所以他提出「agentic workflow」，用來精確描述一件事：把一堆提示詞、外部工具、各類元件，組合成一個有結構的工作流程，形成一套系統——這就叫 agentic workflow。
+
+還記得我們前面講的 RAG 嗎？RAG 主要功能是給 LLM 提供外部資料作為參考。但 agent 把 RAG 當作工具之一，再加上 tool calls、memory、多步驟決策能力，因此能完成 RAG 無法做到的事。
+
+舉例來說，使用者說「我想退這筆訂單」，RAG 只能丟出政策文件給你；而 agent 則是先用 RAG 擷取政策，主動詢問訂單編號，透過 tool 查閱訂單狀態，確認退費資格，再告知「3 到 5 個工作天內處理」。
+
+可見，RAG 是工具，Agent 是使用 RAG 這個工具的系統。
+
+要打造 agentic workflow，你的工程心態必須翻轉過來。因為傳統軟體與 agentic AI 軟體，在四個面向上截然不同：
+
+首先是資料。傳統軟體處理結構化資料——JSON、資料庫、表單，格式固定，邊界清晰。而 agentic 系統處理的是自由文本、圖片、音訊，沒有固定格式。
+
+使用 RAG 检索政策信息，主动询问订单编号，并通过工具查询订单详情，确认退费流程后告知用户将在3到5个工作日内处理。RAG 是一种工具，而 Agent 是使用 RAG 这类工具的系统。要构建一个 agentic workflow，首先必须转变工程思维——因为传统软件与 agentic AI 软件在四个维度上存在根本差异。
+
+首先是数据形态：传统软件依赖结构化数据，如 JSON、数据库表单等，格式固定、边界清晰；而 agentic 系统则处理自由文本、图片、音频等非结构化内容，没有统一格式。
+
+其次是逻辑特性：传统软件是确定性的（deterministic），相同的输入始终产生相同的输出，可预测、可重现；而 agentic 系统具有模糊性（fuzzy），同样的输入在不同时间运行可能得到不同结果，因为 LLM 本身带有随机性，且会根据上下文动态判断，不存在唯一正确答案。
+
+第三是架构思维，这一点最为关键。传统工程师习惯于编写 microservices 或 monolith，精确控制每一步执行路径；而 agentic 系统的思维方式应像一位管理者——你只需设定目标和约束条件，让 AI 自行决定如何完成任务。你关注的是方向与边界，而非每一行代码的具体实现。
+
+第四是测试方式：传统测试是确定性的，重复运行一百次结果一致；而 agentic 系统的测试必须采用迭代探索式方法，因其本身是非确定性的，且对上下文高度敏感，无法穷举所有场景。
+
+理解这四点后，第一个落地原则自然浮现：能用确定性方式解决的问题，就用确定性方式解决；剩下的模糊部分，则需加入“护栏”机制。
+
+教授以自己团队开发的技能评估系统为例说明：选择题、配对题、拖拽题这类有标准答案的题目，采用确定性评分；但语音题或语音+编程混合题型，因无标准答案，只能交由 LLM 判断，这就是所谓的 fuzzy scoring——即基于程度的评分。例如，让 LLM 听一段语音回答，评估其是否真正理解概念、表达是否清晰、逻辑是否连贯。这些都不是对错问题，而是程度判断，LLM 给出的分数是它认为合理的估计，而非计算得出的结果。
+
+然而，模糊问题必然伴随错误风险：LLM 可能误判正确答案，也可能对模棱两可的回答打分过低。在考试评分这种高风险场景中，这是不可接受的。因此他们设计了“申诉功能”（Appeal feature），允许受测者对 AI 的评分提出异议，由真人介入审查并纠正。这正是“护栏”的具体体现——不是追求 AI 零错误，而是在它出错时有人能及时接住。
+
+讲完原则，接下来是如何实际打造一个 agent。教授以“帮用户订去巴黎的机票”为例，提炼出三个核心要素。
+
+第一是 Prompts，即提示词工程，在 agent 中扮演核心角色。你需要清晰定义 AI 的角色、能力边界与行为规范。
+
+第二是 Context Management，即如何管理 agent 在每个时刻所能看到的信息。这包括对话历史（memory）、RAG 检索回来的内容等，都必须塞进有限的 context window。你需要决定哪些信息重要、哪些可以丢弃、哪些需要压缩。本质上，Context Management 就是确保在恰当的时间，把正确的信息提供给 agent。
+
+Memory 又分为两层：Working memory 是高频、快速访问的，比如用户姓名、本次目的地是巴黎；Archival memory 是低频、可延迟获取的，如用户过去五年的预订记录，需要时再调取。
+
+第三是 Tools，即 agent 可调用的外部能力。通常分为两类：一类是执行类操作，如航班搜索、酒店预订、支付；另一类是查询类操作，如从 CRM 获取客户资料，或从数据库查订单记录。
+
+此外，课程中将 agent 的自主性划分为三个层级：最低级是 hard-coded steps，所有步骤完全写死，按顺序执行，安全可控但僵化，遇到意外情况容易卡住；第二级是 hard-coded tools，但允许 agent 自主决定执行顺序。你提供一组可用工具，并告诉它是旅行代理，具体怎么组合由它自己判断。这种方式既保持了工具范围的可控性，又赋予 agent 一定决策空间，是目前最常见且推荐的生产环境起点；第三级是 fully autonomous，agent 不仅自主规划步骤，还能自行创建工具，比如配备代码编辑器、网页搜索能力，让它自己写代码解决问题。虽然能力最强，但风险也最高——一旦判断失误，可能造成灾难性后果，比如误订 100 张机票。
+
+还有一个关键概念是 MCP（Model Context Protocol）。传统做法是为每个 API 单独编写对接逻辑，教 LLM 如何调用、传什么参数；而 MCP 则在中间引入一个协议层，agent 不必了解每一个 API 的细节，只需与 MCP server 通信，由它负责与后端服务对接。你可以把 MCP 想象成一个通用插头：过去各国插座规格不一，需带一堆转接头；有了 MCP，插一个就能全通。
+
+斯坦福教授还提出了更宏大的愿景：agent-to-agent communication。这意味着你可以将别人开发好的 agent 当作工具来调用，就像现在调用 API 一样。这构成了 multi-agent 系统的基础，我们稍后会详细讨论。
+
+无论是单个 agent 还是多 agent 系统，上线前都必须回答同一个问题：它真的有用吗？答案是——eval（评估）。评估也是生产级 agentic 系统的生命线。
+
+教授在课堂上给出了一个完整的评估框架，包含三个维度的交叉：
+
+第一个维度是 End-to-End 与 Component-based。End-to-End 关注整体效果，比如用户最终打几分，是否满意；Component-based 则拆解每一步，比如某个工具总是忘记更新邮箱，发送邮件的格式出错。只看整体，不知道哪里坏了；只看组件，可能修好了细节却仍影响整体体验。实践中两者缺一不可。
+
+第二个维度是 Objective 与 Subjective。Objective 是可自动验证的，例如用户说订单号是 X，LLM 写入数据库变成 Y，这类问题可以用 Python 脚本自动比对，对就是对，错就是错。Subjective 则没有标准答案，如语气是否友好、回应是否有同理心，这类评价需人工打分，或使用另一个 LLM 作为评审。
+
+第三个维度是 Quantitative 与 Qualitative。Quantitative 是数字指标，如改地址成功率、各环节延迟时间；Qualitative 是主观感受，如是否存在幻觉、语气是否突兀、用户在哪一步卡住。这部分必须人工逐条分析，没有捷径。
+
+前面提到的用 LLM 作为评审（LLM-as-Judge），是做 subjective eval 的常用手段。主流有四种玩法：第一种是 Pair-wise comparison，给 judge 两个答案，问哪个更好；第二种是 Single-answer grading，直接打 1 到 5 分；第三种是 Reference-guided pair-wise，额外提供一个标准答案作为对比依据，使评分更有参照；第四种是 Rubric-based，自定义评分标准，例如五分要求在一百字以内，包含三个重点，首句为概述；零分则是答非所问、冗长失焦。这四种方法可以混合使用，例如结合 rubric-based 和 few-shot examples，帮助评审更清楚理解期望。
+
+如何实际运行一次 subjective eval？教授以旅行代理的礼貌度评估为例，共分四步：第一步是 error analysis，从一千个用户对话中抽样二十个进行人工阅读，你可能会发现 LLM 回应过于简短、缺乏同理心，甚至显得冷漠。这一步不能省略，只有先识别出问题，才能设计有效的评估方案。
+
+## 实战案例：客服代理的全流程构建
+
+第二步是设计 eval，结合 LLM-as-Judge 与自定义的礼貌度评分标准，将第一步发现的问题转化为具体的评分规则。
+
+第三步是 A/B test 模型，固定 prompt，更换底层模型（如从 GPT 换成 Opus），跑同一组对话，让 judge 评分，比较哪个模型更礼貌。
+
+第四步是 A/B test prompt，固定模型，将“act like a travel agent”改为“act like a helpful travel agent”，观察仅一个词的变化带来的影响有多大。
+
+核心原则只有一个：先人工扫描发现问题，再设计自动化评估；且每次只改变一个变量——要么换模型，要么改 prompt，否则无法判断差异来源。
+
+讲完评估，教授给出一个完整案例研究，串联起前述所有内容。题目很简单：我们要做一个客服 AI agent，用户说：“我要改 A127 订单的地址，因为我搬家到建国南路了。”表面看是改地址，本质是构建一个能自主处理客服请求的 agent。
+
+一位学生回答：“我会先在客服旁边坐一两天，观察他们真实如何处理这类请求，了解日常的工作流。”教授非常赞赏这个答案，因为你要先理解人类怎么做，才能让 AI 做得同样好。而这正是构建 agentic workflow 的第一步——task decomposition，即将大任务拆解为小任务，让 LLM 逐个击破。
+
+经过观察，你会发现客服处理改地址请求其实包含五个步骤：第一步，提取关键信息，包括用户意图、订单号、新地址；第二步，查询客户记录数据库；第三步，查阅公司政策，判断该订单是否可改地址、是否已发货；第四步，基于收集的信息起草回复邮件；第五步，发送邮件。
+
+每一步都清晰明确，这就是 task decomposition 的价值。
+
+下一步是决定每一步使用什么工具：第一步提取信息，通常一次 LLM API 调用即可解决；第二步查改数据库，需定制工具或通过 MCP server 实现；第三步政策检查，使用 RAG，因为政策文档会更新，必须高效检索，不能让用户久等；第四步撰写邮件，利用前几步收集的信息；第五步发送邮件，调用 agent 可用的邮件发送工具。
+
+判断依据很简单：先问哪些步骤是 fuzzy（模糊），哪些是 deterministic（确定）；再决定每一步用 LLM one-shot、RAG、tool 还是其他工具。这正是 AI Builder 真正在做的事——理解每种技术的能力与局限，然后调配出符合需求的解决方案。
+
+最后是建立评估体系，综合运用前述三个维度：End-to-End 评估最终回复的准确性、语气、用户满意度；Component-based 拆解每一步，检查信息抽取准确率、API 错误率、政策遵守率；Objective 部分可自动化验证，如订单号是否正确、是否违反退费政策；Subjective 部分则靠人工加 LLM-as-Judge，如回信是否有礼貌、是否体现同理心；Quantitative 看改地址成功率、延迟时间、退费正确率；Qualitative 则关注幻觉出现位置、语气不一致处、用户卡顿环节。
+
+至此，一个完整的 AI 客服 agent 从零到上线的工程流程便完整呈现。整个过程归根结底只有三步：先把大任务拆解为小任务，再设计工作流程，最后建立评估系统，确保产出稳定可靠。
+
+课程最后一个主题是 Multi-Agent。前面一个 agent 已经能拆解步骤、调用工具、做 RAG、写信，看起来已经足够。但 multi-agent 依然有其存在的意义。
+
+主要原因在于并行处理：有些任务本就不该排队。比如订机票时，找航班、找酒店、查天气完全可以同时进行。如果只有一个 agent，只能一件件做；而 multi-agent 可将这些可并行的任务分配给三个专业 agent 同时执行，效率大幅提升。
+
+## 多智能体系统：何时需要？如何设计？
+
+次要原因是可复用性（reusability）：公司内部的设计 agent 可供市场团队使用，也可供产品团队调用，提升资源利用率。
+
+尽管听起来很强大，但在实际产品设计中，必须先问自己：真的需要吗？如果一个 agent 就能解决问题，硬上 multi-agent 反而增加复杂度。因此，工程设计的核心原则仍是：能简单就简单，避免过度设计。
+
+教授以智能家居为例进行头脑风暴：一个完整的 multi-agent 系统可能包括温度控制、灯光管理、安保、娱乐、通知、能源管理等多个 agent，外加一个 Orchestrator 统筹协调。交互模式有两种：第一种是 Hierarchical，用户只跟 orchestrator 对话，由它派发任务给下层 agent，指挥链清晰；第二种是 Flat，agent 之间直接互通，无需中介。
+
+教授建议智能家居以 hierarchical 为主，因为从用户角度，你不想同时跟五个 agent 对话，只想说“我要出门了”，系统就会自动协调灯、安防、温控。但在后台，某些 agent 之间可以建立水平沟通通道，比如温度控制 agent 与能源管理 agent 直接联动，省去每次都经过 orchestrator 的通信开销。
+
+当你让 agent 之间互相沟通时，本质上就是在使用 MCP protocol——你把 agent 当作 tool 来调用。
+
+在系统架构设计中，有两种常见的Agent协作模式：一种是分层式（Hierarchical），由 orchestrator 指派任务给下层的 agent，指挥链清晰；另一种是扁平式（Flat），各 agent 之间直接通信，没有中间协调者。教授建议智慧家庭系统以分层式为主，因为从用户角度出发，你并不想同时跟五个 agent 对话，而是只需对一个 assistant 说“我要出门了”，它便会自动协调灯光、安防、温控等各项功能。而在后台，某些 agent 之间仍可建立水平沟通的连接，例如温度控制 agent 与能源管理 agent 可直接互通，避免每次都要经过 orchestrator 的通信开销。
+
+当你让 agent 之间互相沟通时，本质上就是在使用 MCP 协议——把 agent 当作工具，就像把 API 当作工具一样。一旦建立起这种思维，系统设计就变得清晰：每个 agent 对外暴露一组类似工具的接口，其他 agent 就像调用工具一样调用它。这样的结构干净、易于调试，也支持并行处理。
+
+多智能体系统听起来复杂，其实只是将你已掌握的知识再叠加一层而已。最后我们来总结这堂课的重点：本片从基础模型的局限讲起，逐步深入到提升模型表现的各项技术。第一层是 Prompt Engineering，这是最低成本强化 LLM 输出的方法，关键在于 chain 构建与测试。第二层是 Fine-Tuning，除非你在处理法律、科学这类需要高精度重复性的领域，或出于兴趣，否则不建议随意调参。第三层是 RAG，是弥补模型知识短板的标准方案，做 AI 产品几乎一定会遇到。第四层是 Agentic Workflow，从强化单一 LLM 走向系统级设计，核心在于思维转变——从过去的确定性工程（deterministic engineering）转向如今的模糊工程（fuzzy engineering），并建立相应的评估体系。实战中要从任务拆解开始，逐步构建自己的 agentic workflow。
+
+第五层是 Multi-Agent，将每个 agent 视为独立工具，通过协作提升处理效率与复用性。教授在两小时内完整梳理了产业界常见的实作技巧，每项技术存在的理由与适用情境都交代得清清楚楚。有了这样的认知，你就不会盲目跟风：看到别人做 multi-agent 就跟着上，看到别人谈 fine-tuning 觉得很酷就去折腾自己的模型。
+
+那么你的下一步该怎么做？我的建议是：从实践中学习。观察生活或工作中的痛点，从问题出发思考解决方案。在这个过程中，你会自然意识到自己需要掌握哪些技术，从而高效规划学习路径。我把这支影片整理成一篇深度文章，附带四组 prompts，帮助你理清 workflow 如何拆解、现有架构是否过度设计、如何建立评估系统，以及是否真的需要引入 multi-agent。有兴趣的朋友可以在视频信息栏找到链接。
+
+今天的分享就到这里，如果你喜欢这类内容，欢迎点赞支持，并在评论区告诉我你想看什么主题。我们下次见。
---