Agentic AI（1）｜个人完整框架解读

简单学习一点东西，浅浅的基础。祝食用愉快～🫠

引言

先看一个现象。我们平时用 ChatGPT 时，问一个问题，它“一口气”给出答案——这是传统 LLM 的标准用法：一次提示，一次生成。这种用法应付简单问题绰绰有余，可一旦遇到复杂任务，比如“帮我调研一个行业，并产出一份深度报告”，它就开始不行了：一次生成的信息量有限，容易产生幻觉，而且生成完就结束了，没有机会自我检查、没有渠道获取最新数据。

要解决这个问题。需要换一条路：让 AI 不只“回答一次”，而是像一位员工一样，进入“思考 → 行动 → 检查 → 再行动”的工作循环，直到任务真正完成。这样的 AI，就叫智能体 AI（Agentic AI）。

一：概念

1.1 什么是智能体 AI？

传统 LLM 是“一次性生成器”，智能体 AI 是“循环工作者”。

智能体 AI 由三个要素构成，缺一不可：

1. 模型（大脑）：负责推理，决定下一步做什么；
2. 工具（手脚）：负责行动，比如搜索网页、执行代码、调用 API；
3. 循环（工作方式）：生成 → 观察结果 → 再生成，反复迭代直到完成任务。

注意“循环”这个要素——它正是智能体和普通 LLM 的分水岭。

1.2 自主性

智能体并不一定要全自动。

• 人在环内（human-in-the-loop）：每一步执行前都要人类批准，最安全、最慢；
• 人在环上（human-on-the-loop）：人类负责监控，遇到异常再介入；
• 全自主（fully autonomous）：AI 独立完成，人类只验收结果。

不是越自主越好。任务的风险越高（比如医疗建议、转账操作），越要留人在环内；风险低、流程固定的任务，才适合放权。自主性的选择，本质上是一次“效率与安全”的权衡。

1.3 为什么值得做？

了智能体 AI 的根本依据：智能体的性能，会随着推理时投入的计算量（test-time compute）增加而显著提升。

什么意思？过去我们提升 AI 表现，靠的是把模型做大、把训练数据做多——这是“训练时计算”。而智能体开辟了另一条路：同一个模型，只要给它更多“想的机会”（多轮反思、多步工具调用、多轮修正），输出质量就能持续提升。就像同一支笔，写一稿和改五稿，质量天差地别。

这带来的四个直接收益是：准确率更高、性能更强、速度可控、模块可复用——每个环节单独构建、单独替换，想升级哪块就升级哪块。

1.4 任务分解

实操第一步：任务分解。设计一个智能体，先把大任务拆成有序的、可执行的步骤。

以“深度研究”为例：接到“调研某行业”的任务，你需要把它拆成“明确问题 → 搜索资料 → 阅读筛选 → 综合分析 → 撰写报告 → 审校修改”。任务分解的结果，直接决定了工作流的结构——拆得好，后续每个环节的模型选择、工具配置、评估指标都顺理成章；拆得粗，整个系统就是一笔糊涂账。

1.5 评估与四大模式

• 评估（evals）：没有评估，你永远不知道智能体是变好了还是变坏了。定义“好”的标准，用测试集量化衡量
• 四大设计模式：总框架——反射、工具使用、规划、多智能体协作。

二：反射

2.1 反射是什么

反射（Reflection）是第一个设计模式，也是最直观的一个。它的流程只有三步：

1. 生成：模型先写出一版初稿；
2. 批评：模型（或另一个模型）以批评家视角审视这版稿子，找出问题；
3. 修正：作者根据批评意见重写。

这三步可以循环多轮，每循环一轮，输出质量就上一台阶。实现时最简单的方式是“角色切换”：同一个模型，先用作者提示词生成，再用批评家提示词审校。反射的本质，是把“检查”从人的责任变成了 AI 自己的责任。

2.2 为什么不直接生成呢？

这是最自然的疑问。实在的回答是：一次生成时，模型压根没有机会看到自己的错误。它写完了就交卷，幻觉、逻辑漏洞、格式问题统统没人发现。

而反射给了它第二次、第三次机会：让它先跳出来当“读者”，回头审视“作者”的作品。这正好呼应核心洞见——多花一点推理时计算（多几轮反思），就能换来质量提升。当然，天下没有免费的午餐：反射的代价是更高的延迟和更多的 token 消耗。

2.3 案例：图表生成工作流程

一个具体案例：让 LLM 生成图表（比如用代码画一个数据图）。第一版几乎必有毛病——坐标轴不对、样式难看、数据映射错位。这时让模型自己当批评家审一遍，指出问题，再让它重写代码，通常两三轮就能得到满意结果。

2.4 评估反射的影响

光说“反射有用”不够，需要证明它有用：设置对照组——同一批任务，一组用反射，一组不用，用统一的评估标准量化对比。结果显示反射能显著提升输出质量，同时你也可以量化它多花了多少 token。

这一步的意义远超本模块：它示范了智能体开发的正确姿势——任何模式改动，都要靠评估来验证效果。

2.5 使用外部反馈

反射走到最后，一个重要的升级：“批评者”不一定非得是模型自己。外部反馈来源包括：

• 另一个 LLM 当独立评论家（避免“自己改自己”的盲区）；
• 规则校验器：基于规则的检查，比如格式、必填字段；
• 代码运行结果：程序报错就是最客观的反馈；
• 人类反馈：人在环内，直接给修改意见。

一个非常实用的经验：让 LLM 当评委时，用带评分标准（rubric）的二元打分，比“你觉得这个回答怎么样”式的泛泛评价可靠得多——因为评分标准把“好”的定义具体化了。

三：工具使用

3.1 为什么需要工具？

LLM 有三个天生短板：

1. 知识有截止日期：它不知道训练之后发生的事；
2. 无法访问实时数据：看不了你的日历、查不了今天的股价；
3. 无法执行动作：只能输出文字，不能真的发邮件、改文件。

工具（Tools）就是补这三块短板的“手脚”：搜索、计算器、日历、数据库、API……让模型能把“想做的事”变成“真做成的事”。

3.2 工具是什么

在实现层面，工具并不神秘——它就是一个普通函数，外加一份给模型看的“说明书”。说明书要写清楚：函数叫什么、是干什么的、参数有哪些、类型是什么、返回什么。

为什么说明书这么重要？因为模型是“读说明书来决定要不要调用”的。描述写得越清楚，模型越能在正确的时机调用正确的工具。

3.3 工具语法

工具调用的机制（function calling）是理解本模块的关键，流程是：

1. 模型看到任务后，输出一个结构化的调用请求（JSON：函数名 + 参数）；
2. 你的代码解析这个请求，执行对应的函数；
3. 把函数执行结果返回给模型；
4. 模型基于结果继续推理，直到完成任务。

注意这个分工：模型只负责“决定调什么”，执行永远由你的代码控制。这让整个流程既灵活又安全——模型没有直接执行能力，只是“提议”，你随时可以在执行层加校验、加限制。

3.4 代码执行

工具里最特别、也最强大的一种，是让模型自己写代码，并在沙箱环境中执行。数据分析、画图、数值计算这类任务，让模型“写代码来做”，比让它“直接输出答案”可靠得多——因为结果可以运行、可以验证、可以迭代。

但代码执行也带来两个必须处理的问题：安全（必须沙箱隔离，不能让模型代码乱跑）和错误处理（代码报错时，把报错信息回传给模型，让它自己修——注意，这里工具使用和反射模式天然地组合起来了：报错就是最客观的“批评”）。

3.5 MCP

最后一个点是 MCP（Model Context Protocol）。随着工具越来越多，每个应用都自己对接一堆工具，接口五花八门，维护成本爆炸。MCP 的解决思路是标准化：用一套统一协议连接 LLM 应用和工具/数据源——好比 AI 界的 USB-C 接口。你写好一个 MCP 服务端，任何支持 MCP 的客户端都能直接使用。

工具生态的演进方向：从“每个工具各自为政”走向“标准化、可插拔”。

四：工程方法论

4.1 评估

核心流程三步：

1. 定义成功标准：这个任务怎样算“好”？标准越具体越好；
2. 构建评估集：收集一批有代表性的测试任务，覆盖典型情况和边界情况；
3. 量化打分：用统一指标给每次输出打分。

评估的方式多种多样：规则检查、人工打分、以及最常用的 LLM 当评委。课程反复强调一个经验：LLM 当评委时，要给它明确的评分标准并让它做二元判断（这项达标/不达标），而不是让它自由发挥打印象分——标准化的评委，打分才稳定、可复现。

4.2 误差分析与优先级

评估跑完，你会得到一叠失败案例。接下来不是闷头修，而是做误差分析：

1. 逐个检查失败案例；
2. 把错误归类；
3. 统计每类错误的出现频率 × 影响程度，排序；
4. 优先修排在最前面的那一类。

这背后是典型的二八法则：少数几类错误往往造成了大多数失败。与其平均用力，不如集中火力解决最大的一类问题，然后再评估、再分析——每次迭代都打在最大的靶子上。

4.3 组件级评估

整体评估只能告诉你“系统好不好”，却说不清“问题出在哪”。所以强调组件级评估：分别评估每个环节——计划质量、工具选择是否正确、反思是否有效、检索结果是否相关。

4.4 解决你发现的问题

定位到问题后，有一整套修复手段，按“从便宜到贵”排列：

• 改进提示词：把指令写得更明确、更具体；
• 增加示例：给模型几个 few-shot 范例，模仿着做；
• 加规则与后处理：用代码校验输出格式、过滤非法结果；
• 换更强的模型：某些环节确实需要更强推理能力；
• 调整工作流结构：比如把一个大步骤拆成两个、加一道人工审核。

原则很实用：先用最便宜的手段试，按“改动成本 × 预期收益”选方案

4.5 延迟与成本

技术问题解决后，还要面对两个商业现实：延迟（用户等多久）和成本（token 烧多少钱）。优化手段包括：

• 缓存：重复的结果直接复用；
• 模型分级：简单任务用小模型，只有难题才动用大模型；
• 控制循环轮数：反射、规划不是越多越好，够用就停；
• 精简上下文：只给模型真正需要的信息，既省钱又快。

4.6 开发过程总结

最后一讲把整套方法论收拢成一个循环

“ 定义任务 → 构建基线 → 评估 → 误差分析 → 排序优先级 → 修复 → 再评估 → …… ”

开发智能体的本质，就是这个数据驱动的迭代循环。它贯穿全课——事实上，讲反射时就已经在示范这个循环了（先有基线、加反射、评估对比）。

五：高度自主

5.1 规划

面对复杂任务（比如一份深度研究报告），让智能体“边想边做”很容易跑偏。**规划模式（Planning）**的思路是：让 LLM 先产出一份完整的步骤计划，再逐步执行。

计划包括：把任务分解为子任务 → 确定先后顺序与依赖 → 逐项执行 → 汇总结果。

5.2 创建和执行 LLM 计划

讲实现方式（Plan-and-Execute）：模型先生成结构化计划，系统按计划执行，每步可以调用工具。关键点在于：计划不是写死的一次性产物，而是随执行结果滚动调整的——某步发现资料不足，就动态修改后续计划。计划是“活的路线图”，不是“死剧本”。

5.3 结合代码执行的规划

再进一步：让 LLM 直接用代码来承载计划——把计划步骤写成可运行的 Python 程序，在沙箱中执行。代码既是计划又是执行器，特别适合多步骤的数据处理、分析类任务（比如“下载数据 → 清洗 → 计算 → 画图 → 存结果”一步到位）。

这是“代码执行”与规划模式的组合——课程反复展示这种“模式叠加”，因为真实系统从来不是单一模式，而是组合拳。

5.4 多智能体工作流

与其造一个全能智能体，不如造一个智能体团队。每个智能体有专属角色、专属工具、专属提示词，各司其职。以课程的终极项目“深度研究智能体”为例：

• Planner（规划者）：拆解任务、调度分工；
• 多个 Research agents（研究员）：各自负责一个子课题，搜索、阅读、提炼；
• Writer（写作者）：把研究结果写成报告；
• Editor / Critic（审校者）：用反射模式审校修改，保证质量。

笔者的话

“ 一点基础的总结，最近笔者顺便在补充基础内容，因为有点小忙啊hhhh～ ”

参考资料

• 吴恩达Agent2026课程