很多人一提起“大模型应用”，脑子里还停留在那种：写一条超级长的 Prompt，按回车，等模型给自己一个“一步到位”的回复。

Andrew Ng 在 Sequoia 的 AI Ascent 演讲里，就是是把这个幻想当场掀掉， 他反复强调，真正能把模型能力榨干的，不是更大一代的基础模型，而是一整套更像人干活的 agentic workflow： 先拆解任务，再规划、调用工具、自我反思，甚至让多个 Agent 互相吵一吵。

这篇笔记就是围绕这场演讲，整理出一些对我做系统设计、RAG、Agent 编排都很有启发的要点，方便以后翻回来复用。

基本信息 & TL;DR

  • 主讲人：Andrew Ng（DeepLearning.AI、AI Fund 创始人）
  • 场合：Sequoia 的 AI Ascent 活动演讲
  • 主题：Agentic Workflows——让 LLM 不再一次性回答，而是 像人一样分步思考、反复迭代、协同工作。

一句话总结：

与其砸更多钱上最强模型，不如先把「工作流」做好：拆解任务 + Reflection + 工具调用 + 规划 + 多 Agent 协作。 很多场景里，老模型 + 好工作流 可以干翻 新模型 + 一条 Prompt。

从单条 Prompt 幻觉，到 Agentic Workflow

传统使用方式：Non-Agentic Workflow

绝大多数人（包括我们自己 😅）大多数时候使用大模型的方式是：

扔进一条长 Prompt → 期待一次性给出“完美答案”。

Andrew Ng 的观点： 这就像让一个人写论文时 从头打到尾，中间不许按 Backspace。模型偶尔能干出来，但整体非常不可靠。

Agentic Workflow：让模型像人一样干活

Agentic Workflow 的思路是：

  1. 先让模型 规划/拆解任务（outline / plan）。
  2. 再按子任务逐步执行（检索 → 草稿 → 自我检查 → 修改……）。
  3. 每一步都可以 反思 / 调整 / 重试，甚至根据中间结果换一种策略。

它不再是“一个万能 Prompt”，而是一条 可循环的流程：

Think → Act → Observe → Reflect → Update Plan → Repeat

关键结论：

在 HumanEval 这类编码基准测试上，

GPT-3.5 + 合理的 Agentic workflow 可以跑赢 GPT-4 + 传统零样本 Prompt。

这对产品/系统设计的含义是：

先别把希望全寄托在“换个更大模型”上，问自己一句：工作流设计好了吗？

Andrew 总结的四类 Agentic Reasoning 设计模式

Andrew 把杂乱的 “AI Agent” 研究和实践，粗略归纳成四种设计模式：

  1. Reflection（自我反思）
  2. Tool Use（工具调用）
  3. Planning / Chain-of-Thought / Chain-of-Action（规划与行动链）
  4. Multi-Agent Collaboration / Debate（多 Agent 协作/辩论）

他自己的评价是：

  • Reflection、Tool Use：比较成熟、好调教，工程上很实用。
  • Planning、多 Agent：效果有时惊艳，有时翻车，目前还不算稳，但值得持续尝试。

四种模式逐个拆解

Reflection

最典型的例子是代码生成：

  1. Coder Agent（写代码）

    Prompt：根据任务写出函数实现。

    输出：version 1 代码。

  2. Self-Reflection / Critic（自我检查）

    把 同一段代码 再喂给模型： “这是为任务 X 写的代码，请你仔细检查它的正确性、效率、代码风格，指出问题并给出修改建议。”

    模型会： 找出潜在 bug（例如边界条件、时间复杂度、异常处理等）。 输出一段“评审意见”。

  3. 应用反馈，再生成 version 2

    把评审意见作为追加上下文，再让它重写代码。

    如果有单元测试，再加一轮： 跑单测 → 失败 → 把错误信息给模型 → 让它解释原因、继续修。

进阶玩法：

两个不同的 Agent：

Coder Agent：“你是资深工程师，负责写代码。”

Critic Agent：“你是严苛 code reviewer，专门挑毛病。”

两个 Agent 之间形成一个 “虚拟的 PR 流程”。

对我自己的启发： 以后写 Agent 时，可以考虑默认把「反思环节」当作 必选，而不是“可选锦上添花”。

Tool Use

这块其实大家已经很熟悉了：

  • 写代码 → 运行代码 → 读回输出
  • 搜索网页 → 汇总结果
  • 调用向量检索 → 读 RAG 上下文……

Andrew 的补充点：

  • 早期工具调用很多是从 视觉领域 长出来的： 语言模型看不见图片，只能通过“调用函数”去做检测、分割、生成等操作。

  • 今天的工具早已扩展到：

    • 数据分析（Python、SQL）、
    • 调用内部业务 API、
    • 发邮件、改日程、拉工单……

这里的要点是： Tool Use 实质是把「LLM 的输出」变成「函数调用/行动」，再把结果变回「输入」，形成闭环。

Planning / Chain-of-Thought / Chain-of-Action

Planning 对应的是：

先想清楚再动手

在 Agent 场景里，大概包含几层：

  1. 任务分解：

把一个大目标拆成子任务（信息收集 → 方案生成 → 验证 → 总结）。

  1. 行动序列规划（Chain-of-Action）：

决定先用哪些工具、再执行哪些步骤。

  1. 根据反馈动态调整计划：

工具调用失败？

某步结果不符合预期？ → 允许 Agent 修改计划、重试、绕路。

Andrew 提到：

  • 有时会出现“现场表演”：

    他做 live demo 时，有步骤失败，Agent 会自动改路线，重新查资料或采用备选方案。

  • 表现不算每次都稳定，但当它成功时，会给人一种新的 wow moment。

Multi-Agent Collaboration / Debate

最后一类是多 Agent 协作 / 辩论：

  • 可以是 同一模型，不同角色 Prompt：

    Agent A：偏“乐观派/生成派”。

    Agent B：偏“怀疑派/评审派”。

  • 也可以是 不同模型互相辩论：

    例如 “GPT vs Gemini” 对同一问题展开多轮讨论，最后综合他们的共识。

他说的一个结论：

多 Agent Debate 是一个 性能显著提升的通用设计模式，目前已经在不少任务上被证明有效。

对我们自己的系统设计来说，这意味着：

不必迷信“一个万能超级 Agent”。

很多任务其实天然适合拆成：

  • 生成者 / 评审者
  • 规划者 / 执行者
  • 乐观策略 / 保守策略 之间的对话与博弈。

4. 性能、成本与“快模型”的重要性

Andrew 在结尾强调了一个容易被忽略的点：token 生成速度。

  • Agentic Workflow 的特点是：

    多轮自言自语 + 多次调用工具 + 多次重写输出

  • 在这种模式下：

    稍弱但很快的模型，因为能跑更多轮迭代， 可能实际效果 好过 慢吞吞但单次质量更高的大模型。

同时，他也提醒：

开发者和用户需要 调整对响应时间的预期：

Agentic 工作流很可能比“单轮问答”更慢。 但换来的，是更高的可靠性与任务完成度。

我自己的小结（站在开发者视角）

这场分享对我最大的提醒有三点：

  1. 模型升级或许没那么神奇，工作流升级空间反而更大。

  2. Agentic 设计模式（Reflection / Tools / Planning / Multi-Agent）已经足够工程化，可以写进自己的架构规范，而不是停留在论文和 Demo。

  3. 以后评估一个系统，不应该只问： “你用的是什么模型？” 还要加一句： “你的 Agentic 工作流是怎么设计的？”