一、Agentic工作流简介

1.1 什么是Agentic AI

核心定义：基于LLM的应用通过多步骤执行来完成任务的流程。

• Non-agentic：单次prompt，one-shot完成（类似写作文不许用退格键）
• Agentic：多步骤流程——列大纲 → 决定是否需要调研 → 执行搜索 → 写初稿 → 反思修改 → 最终定稿

类比：做番茄炒蛋，让多个AI各司其职（备料/烹饪/摆盘/审查）

蓝色标注的分别是AI的不同发展阶段：从prompt engineer到content engineer再到Hermes engineer（Agent）.

1.2 自主性等级

Agentic是一个形容词而非名词，避免”什么才算真正的Agent”的争论。

本质：不只是”能干活”，而是”知道怎么思考如何干活、用什么工具、能自检纠错”。
一个合格的Agentic AI应该能自主规划（Planning，自己选择工具）和自主反思（Reflection，有记忆和反思）。

1.3 三大益处

1. 性能大幅提升：HumanEval上，Agentic的GPT-3.5可超越Non-agentic的GPT-4（BTW这些听起来都是上古模型了）
2. 并行加速：多个LLM实例同时搜索/阅读，汇总后输出
3. 模块化设计：自由替换组件（搜索引擎、不同LLM、不同工具）

1.4 任务分解方法

核心方法论：

1. 观察人类行为 → 2. 拆解为子步骤 → 3. 评估LLM/工具可行性 → 4. 迭代优化

案例——写文章的递进分解：

• 1步：直接生成（肤浅）
• 3步：大纲 → 搜索 → 写文（较好但可能脱节）
• 5步：大纲 → 搜索 → 初稿 → 自我批评 → 修改（最好，模拟人的写-反思-修改循环）
• 核心方法论：“如果某一步骤效果不好，就把它再拆成更小的子步骤。”

构建模块：模型（LLM）+ 工具（API、信息检索、代码执行）

1.5 Agentic AI评估（Evals，在做之前对项目进行思考）

吴恩达强调：区分有效和无效实践者的最大预测因子，是围绕评估和错误分析的规范开发流程。

方法论：

1. 先构建，观察输出，再做评估（不要预先设计所有评估标准）：看看这事情咋弄。
2. 识别低质量输出，定义错误类型。
3. 建立评估指标追踪错误：编写脚本自动扫描智能体的所有输出，统计提及错误输出的次数和频率。
4. 主观标准可用 LLM as Judge（1-5分打分，但是不要直接让大模型去打分）。

两类评估：端到端评估（整体输出质量） / 组件级评估（单步质量）（这两种就是一个整体一个局部评估）

1.6 四大设计模式总览

现实案例：oh-my-claudecode（OMC）

OMC （oh-My-Claude）是一个真实的 Agent 系统，完美对应了这四大设计模式：

• Reflection 反思：code-reviewer / verifier agent — executor 写完代码后，由独立的 reviewer 审查。这就是笔记 2.1 说的”用不同模型，一个生成一个审查（1+1>2）”。OMC 的规则是 Never self-approve in the same active context，写代码和审代码必须是两个独立的 Agent。
• Tool Use 工具使用：MCP servers（Context7 查文档、filesystem 操作文件、LSP 做代码分析）、Skill 系统（/commit、/plan 等可调用技能）、Bash 工具 — 对应笔记 3.1 的”工具就是函数，模型自主决定何时使用”。Claude 会根据任务自主判断该用哪个工具。
• Planning 规划：planner agent、/plan skill、plan mode — 对应笔记 5.2 的”LLM输出结构化计划后再执行”。在 plan mode 下，Claude 会先探索代码库、设计方案，等你批准后才动手写代码。
• Multi-Agent 多智能体：Team 模式（/team）可以同时启动多个专项 Agent（explorer 负责搜索、executor 负责写代码、reviewer 负责审查、designer 负责 UI…），它们共享 TaskList，通过 SendMessage 通信协作。

二、反思设计模式（Reflection）

2.1 反思提升任务输出

核心类比：人类会审查和修改草稿，AI也可以。

邮件写作案例：

• AI生成V1 → 将V1反馈给LLM并附上反思prompt → 生成改进的V2

代码写作进阶路径：

• 基础：LLM写代码V1 → LLM审查生成V2
• 进阶：用不同模型——一个生成，一个推理模型审查（1+1>2）
• 终极：结合外部反馈——在沙箱执行V1，捕获错误，反馈给LLM生成V2

关键：反思是工程实践而非魔法；外部反馈是关键区分因素

2.2 Internal——自我 反思的两条黄金法则

1. 明确指示反思动作：说”审查””检查””验证”（具体的事情），不只是”改进”。客观任务：构建ground truth数据集 + 自动化代码评估（如SQL查询正确性）
2. 指定具体标准：列出明确的评估维度（如”专业语气””事实准确”）。主观任务：用**评分标准（Rubric）**引导LLM打分，避免直接比较（存在位置偏差）

论文”Self-refine”表明：在全部7个任务、4个模型上，反思一致地提升了性能。

2.3 external——外部 突破性能天花板

三条性能曲线：

• 🔴 无反思：prompt工程快速提升后停滞
• 🔵 有反思：突破停滞到更高水平
• 🟡 反思+外部反馈：再次突破到最高水平

三类外部反馈：正则匹配（避免提竞品）→ 搜索验证（事实核查）→ 字数检查（格式约束）

外部反馈打破模型信息孤岛，解决固有弱点（精确计数、事实核实），实现闭环优化。

三、工具使用（Tool Use）

3.1 工具的本质

工具就是函数，模型自主决定何时使用。

关键能力——条件调用：模型智能判断何时需要工具。

• “绿茶含多少咖啡因？” → 从内部知识回答
• “现在几点？” → 调用get_current_time工具

多工具协作：日历助手可链式调用 check_calendar → make_appointment

3.2 LLM 是如何”调用”函数的？

LLM 理论上根本触碰不到函数的执行层——它从头到尾只做一件事：生成文本。
所谓的”调用函数”，本质是一个文本中转协议。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

sequenceDiagram
    participant U as 用户
    participant S as 系统/工程代码
    participant L as LLM

    U->>L: "现在几点了？"

    Note over S,L: Step 1: 系统 prompt 告诉 LLM 可用工具
    Note right of L: 系统 prompt 中包含：<br/>函数名: get_current_time<br/>描述: 获取当前时间<br/>参数: 无

    Note over S,L: Step 2: LLM 输出结构化文本（没有执行任何东西！）
    L-->>S: tool_calls: [{<br/>  name: "get_current_time",<br/>  arguments: {}<br/>}]

    Note over S: Step 3: 外层代码拦截<br/>真正执行函数<br/>拿到结果 "15:20:45"

    Note over S,L: Step 4: 把结果塞回 LLM 上下文
    S->>L: { role: "tool",<br/>  content: "15:20:45" }

    L-->>S: "现在是下午3点20分。"
    S->>U: "现在是下午3点20分。"

三个关键认知：

1. LLM 不是在”调用”函数 — 它只是在预测”接下来应该输出一段 JSON 表示我想用这个工具”。这是从大量代码和 API 文档训练中学到的模式。

2. 真正执行函数的是外层工程代码 — Claude Code、OpenAI SDK、LangChain 这些框架负责解析 LLM 输出的结构化文本，执行函数，再把结果喂回去。

3. LLM 的核心能力在于”判断” — 它决定”这个用户问题我该用内部知识回答，还是该调工具”。笔记 3.1 里”绿茶咖啡因”（内部知识）vs “现在几点”（调工具）就是这个判断。

• 早期需要手写prompt模板触发（如”FUNCTION: get_current_time()”），现代LLM已原生理解工具调用，无需硬编码触发语法。

3.3 工具语法与AI SDK（写好函数让LLM调用）

AI SDK（Andrew Ng团队出品）统一多家LLM提供商访问：

• 函数名 → Python函数名
• 描述 → docstring
• 参数类型 → 自动提取

3.4 模型自己写代码（LLM自己写自己调）

传统方式（预定义add/subtract等）vs 代码执行（让模型自己写代码）

• 模型输出<execute_python>标签中的代码
• 在沙箱中提取执行
• 错误信息反馈给模型进行反思修改

⚠️ 安全警告：真实案例——Agentic代码执行器运行rm *.py删除了项目所有文件。必须使用沙箱环境（Docker、E2B）。

3.5 MCP（Model Context Protocol）

MCP标准化LLM访问外部工具和数据源的方式。让LLM调用的“工具范围”更大。

• 问题：m个应用 × n个工具 = m×n的工作量
• MCP方案：建n个共享MCP Server，m个应用连接 → 工作量降为 m+n
• Client：需要工具的应用（Cursor、Claude Desktop等）
• Server：工具/数据提供者（Slack、GitHub、PostgreSQL等）

四、构建Agentic AI的实用技巧

4.1 评估（Evals）实战

评估方式可以从两个维度划分，形成一个 2x2 的矩阵，用于指导评估的设计：

1. 从快速而粗糙的评估开始： 不要因为觉得评估是一个大型项目，就不敢轻易建立，或者花漫长的时间去做理论调研。先用 10-20 个例子开始，快速获得一些指标来辅助人工观察。
2. 迭代改进评估：
   1. 随着系统和评估的成熟，可以增加评估集的规模。
   2. 如果系统改进了但评估分数没有提高，意味着该改进评估本身了。
3. 以专业人士的行为为灵感： 对于自动化人类任务的系统，观察系统在哪些方面性能不如人类专家，以此作为下一阶段工作的重点。

4.2 错误分析与优先级

系统复杂度上升后，直觉驱动debug不可靠，需要系统化分析。

核心方法：

1. 检查traces和中间输出：每步输出叫”span”，合在一起叫”trace”
2. 聚焦错误案例并量化：建表格追踪各组件失败率
   • 例：搜索结果不满意45% vs 搜索关键词生成5% → 优先改搜索组件
   • 习惯性地多看看LLM和工具的交流过程。

4.3 组件级评估

类比单元测试 vs 集成测试。优势：更快迭代、信号更清晰、团队可并行。

工作流：错误分析定位问题组件 → 组件级评估调优 → 端到端评估验证整体改善

4.4 解决问题的策略

非LLM组件：调参数/超参数（搜索结果数、RAG相似度阈值）、换供应商

LLM组件（按优先级）：

1. 改进Prompt（明确指令、few-shot示例）
2. 尝试不同LLM（用eval测试多个模型）
3. 任务分解（将复杂步骤拆为生成+反思）
4. 微调（最后手段，成本最高）

4.5 延迟与成本优化

早期团队，输出质量远比延迟和成本重要。先优化质量，再优化延迟，最后优化成本。
还是以组建化的思想，先分析哪个组件最慢/最贵，再针对性优化（如改prompt、换模型、减少调用频率）。

4.6 开发过程四阶段

开发者两大活动：构建（写代码）和分析（决定聚焦哪里）。团队常花太多时间构建、太少时间分析。

五、高度自治智能体的模式

5.1 规划工作流（Planning）

规划模式：Agent自主决定工具调用序列，不硬编码。

案例——客服助手（工具：查描述、查价格、查库存、查订单、处理购买、处理退货）：

• 用户问”有100刀以下的圆墨镜吗？”
• LLM规划：查描述 → 查库存 → 查价格 → 输出答案

优势：能力丰富，无需预编排。风险：无法预测LLM的计划，可能不稳定。

5.2 结构化计划

自然语言计划有歧义 → 要求LLM输出结构化计划（JSON/XML）：

1
2
3
4

[
  {"description": "查找圆墨镜", "tool": "get_item_descriptions", "arguments": {"query": "round sunglasses"}},
  {"description": "检查库存", "tool": "check_inventory", "arguments": {"items": "$step1_result"}}
]

5.3 代码即计划 Code As Action

参考HuggingFace smolagents的CodeAgent概念——让LLM直接写代码表达多步计划。

优势：可调用大型库（Pandas数百函数）、表达力强、研究显示性能优于JSON/文本计划。
风险：明确要求LLM编写的代码并需要沙箱执行。

5.4 多智能体工作流

即使所有Agent用同一个LLM，拆分复杂任务为独立角色也更有效。

我个人觉得可能是因为提示词/上下文不同，导致模型的关注点是不一样的。

优势：

1. 任务分解：按角色/技能自然分工
2. 聚焦：开发者一次构建一个角色；更简单的任务 = 更好的输出
3. 模块化复用：通用Agent（如”图表设计师”）可跨应用复用
4. 突破上下文限制：每个Agent处理自己的上下文（对128k上下文限制至关重要）
5. 成本节省：更短的上下文 = 更少的token = 更低的成本和更快的响应

5.5 四种通信模式

当前LLM能力下，线性和层级模式更实用（层级越深信息损失越大）。

其实在这四种模式外，还有一种对话模式，比较类似去中心模式的降级版。对话模式每次都只有两个Agent互相对话交流，一方执行任务，另一方审查任务，最终交出一份双方都满意的结果。

5.6 框架推荐

• LangChain：线性工作流
• smolagents：层级工作流（作者推荐——简单、低抽象、@tool装饰器易开发）
• MetaGPT / CamelAI：去中心化工作流

总结与个人思考

我之前在公司构建了一个通过ClaudeCode调用MCP去检查UE资产和打包报错Log的Skill（但或许这个Skill其实并不算Agentic AI），如果用Agentic AI的思维来做这个项目的话，它可能能做得更完善一点。而且我非常惊讶，吴恩达课程里面的几个测试项目的稳定性。

• 1. 规划（Planning）：定时器触发后，ClaudeCode先分析报错日志，判断需要调用哪个工具（查文档、查代码、查历史报错记录等），然后再执行工具，甚至自行编写数据库查询代码。
• 2. 反思（Reflection）：ClaudeCode在得到工具结果后，先进行自我审查，看看结果是否有用，如果不满意就调整查询参数重新调用工具，直到得到满意的结果。
• 3. 多智能体（Multi-Agent）：可以设计多个专门的Agent，比如一个专门分析日志的Agent，一个专门查询文档的Agent，一个专门查询代码的Agent，它们通过共享上下文进行协作。
• 4. 评估（Evals）：可以设计一些自动化的评估脚本，来量化ClaudeCode在解决报错问题上的表现，比如成功率、平均解决时间等指标。（每一个结果执行完成之后，会有一个Json表格自动上传服务器，然后管理员每周看统计效果。并且可以让用户回答该AI解决思路是否解决了你的问题，组建一个问题解决方案数据库，这样AI遇到了类似问题就可以参考之前的解决方案）。

另外，不同的模型可能适用于不同的harness，因为模型的能力不太一样（李宏毅的课程提到了，比如说sonnet 他对于上下文会有焦虑，所以当内容很多的时候，它会出现明显的能力下降)。

最后，回到 Tool Use 这个设计模式，一个关键的实践洞察是：MCP 工具的设计质量直接决定了 Agent 的能力上限。结合我在 UE MCP 项目中的经验，总结出以下六条工具设计原则：

1. Description 是最重要的设计——描述即接口：MCP 工具的调用方是 LLM 而非人类，LLM 靠 description 字段判断”什么时候该调用、怎么调用”。好的描述要包含：做什么、什么时候用、边界限制、参数语义、返回值含义。描述写得烂，工具就是死的。
2. 粒度控制——以子系统为边界：工具太细（如按坐标轴拆分节点创建）导致调用链过长、容易出错累积；太粗（如一句话生成整个角色蓝图）变成黑盒，出错了 LLM 无法定位。以引擎子系统为边界划分，每个工具做一件完整的事。
3. 返回值要”对 LLM 友好”：返回值必须包含足够的决策上下文——成功时提示下一步可用的操作，失败时给出 error_type、error_message 和 suggestion，让 Agent 能自我纠正而不是盲重试。
4. 读写分离，副作用透明：LLM 在不确定时倾向于调用”看起来安全”的工具。只读工具和写操作要明确分类，写操作在描述里标注副作用（如”会在磁盘上创建新文件”、”不可逆操作”）。
5. 幂等性设计，让 LLM 敢于重试：LLM 可能因超时或误判而重复调用同一工具，设计为重复调用安全（如：资产已存在则返回现有资产而非报错）。
6. 分层工具结构：高层工具（面向任务的完整工作流，如 setup_character_blueprint()）减少调用次数；中层工具（面向单步操作）保证灵活性；底层 API 不直接暴露给 LLM。描述里引导 LLM 优先走高层路径。

核心一句话：好用的 MCP 工具设计，本质是”让 LLM 像一个读过文档的开发者一样能正确使用它”。 这和吴恩达课程中 Tool Use 模式的核心思想完美对应——工具的质量决定了 Agent 自主决策的上限。

参考资料

1. https://www.bilibili.com/video/BV1DfrdByE2H 课程地址
2. 原github笔记:这里面有可以运行的代码，可以通过在VSCode里面的Jupyter Notebook的形式来学习，会很方便。
3. 👆视频里面提到后面部分存在的另外一个视频：代理知识图谱构建
4. 原始的视频地址
5. 李宏毅课程：这个课程有点像 Agent