本文主体是鲁力老师和姬阁阁老师在datawhale的宣讲，精练易懂。

辅以一些本人的看法，希望各位大佬一起交流指正。

个人看法

目前业界对 Agent 尚未形成统一定义，更多是从实际需求出发进行探索。在以提升生产效率为目标的场景下，通常会先分析任务的结构与复杂度：对于重复性强、路径可预期的任务，更适合通过工作流编排来解决；而对于不确定性高、需要动态决策的任务，则更倾向于引入自主智能体。在实现层面，也会根据需求权衡是直接调用大模型 API，还是借助 LangChain 等框架进行更底层、可控的能力组合，同时还要考虑人力成本、时间成本等，像有些场景 RAG + Prompt 已经足够，增加 Agent 有点画蛇添足

1. 智能体定义

本没有路，走的人多了便有了路

定义也是从共识来的

Agent 同理，目前还没有具体的共识，任何一个非单次大模型调用的系统都有可能被称为Agent

看一些大厂商的定义

OpenAI 的 AGI 五级分类

1. Conversational AI：语言对话，缺乏推理能力
2. Reasoners：没有外部工具，在专业领域能独立推理
3. Agents：可以长时间自主行动执行任务
4. Innovators：能产生创新思想
5. Organizers：可以管理协调整个组织

• 翁荔：Agent = 大模型 + 记忆 + 主动规划 + 工具使用

• LangChain作者Horrison：Agent是使用LLM决定应用程序控制流的系统

• 吴恩达：不必拘泥是否为Agent，更应该关注其Agentic程度

取决于LLM对系统行为的决策权重，后面完全由LLM掌控

• Agent = 自动机 + LLM

┌────────────┐
│  状态机     │  ← 负责：约束、流程、可控性
└─────┬──────┘
      │
┌─────▼──────┐
│   LLM      │  ← 负责：推理、生成、语义理解
└────────────┘

自动机：一个按规则，在状态之间跳转的抽象计算模型。只关心三件事：当前状态、什么输入、下一个状态（例如DP的状态转移）

M = (Q, Σ, δ, q0, F)

Q	状态集合
Σ	输入符号集合
δ	状态转移函数
q0	初始状态
F	接受状态（终止/成功状态）

2. 智能体系统划分

划分为两类

1. 工作流 workflow ：通过预定义代码路径编排LLM和工具，侧重任务明确、流程固定和可预测性
2. 自主智能体 Autonomous Agent：LLM 动态控制决策和工具使用，自主规划任务，侧重面对难以预测任务的自主性

对于很多场景，通过 RAG检索增强生成 和 prompt 优化可能已经足够，增加系统复杂度往往会伴随延迟和成本，需要权衡

3. 智能体系统组成模块

a. 基础构建模块：增强型LLM

检索、工具使用、记忆能力的增强型LLM

本质是调用一个远程推理服务的 API

请求体的 JSON 中包含各种 LLM 需要的信息，例如 https://github.com/ceilf6/ScreenSniper/commit/f62eb32bc92038033f24dc846e5d9a99c9911cfa 中我通过在 JSON中包含文本和图片进行交互

Function Calling 本质是一种 意图结构化协议

通过在请求中添加 functions 参数，使用 JSON Schema 向 LLM 声明可用的函数能力。LLM 在响应中以结构化 JSON 的形式返回其希望调用的函数及参数，实际的函数执行由业务代码完成。

b. 工作流常见模式

1. 提示链

• 按顺序拆分工作，每一步由 LLM 生成内容
• 可以在任意中间步骤添加程序检查以确保整个过程依然按计划执行

目标场景执行一连串的任务链

我认为是一种把长推理拆成可插入校验点的线性状态机

2. 路由模式 - 分流

根据输入分类，分配给专门的后续任务，以提高模型适配性和消耗的性价比提高

3. 并行

同时执行多个任务，最后再对输出聚合

一种是分段：将任务划分为可以并行运行的独立子任务

还有一种是投票：对同一任务多次执行，判别输出的多样性进行对比

4. 协调者 - 工作者

协调者拆解任务，子任务不可预期

工作者完成子任务

我感觉就像 MCP 协议，拆解者是大模型，工作者是由 MCP Server 执行

5. 评估 - 优化循环

一个 LLM 生成输出

另一个 LLM 进行反馈和优化

我感觉像 manus 中就会用到

Manus：可执行的数字员工为目标的通用Agent，目标就是能完成任务而不是交流，基本架构都是

Goal（目标）
 ↓
Planner（任务拆解）
 ↓
Executor（工具调用 / Workflow）
 ↓
Memory（状态 / 上下文）
 ↓
Evaluator（结果评估 / 决策）

然后后面可能还有 reTry 这种类似状态机一样不断去评估

总之一切以需求为主

c. 自主智能体范式

• 执行过程中获取环境真实反馈
• 支持人工检查点干预 - 反馈
• 设置终止边界条件

适用于开放问题，当任务步骤数量难以预知、无法预先固定

关键组件

1. 规划模块

• 子目标拆解：将复杂任务分解为可管理的子目标
• 反思优化：通过自我评估改进执行策略

2. 记忆系统

• 短期记忆：上下文
• 长期记忆：外部存储

3. 工具使用

获取预训练模型外的实时信息与功能拓展

我认为这部分就是和 MCP 拼接的部分

4. 国内外Agent平台、框架、产品

全代码框架

• LangChain & LangGraph
• LlamaIndex

低代码

• Dify
• Coze
• FastGPT

例如之前我在 Coze 上只需要拖拽子模块并进行拼接就能实现一个完整的工作流功能等等

特点就是中间过程支持灵活的输入、输出和多样性的人机交互

工作流一般是DAG无环的，防止无法终止，但是当你输入改变的时候又是作为一个状态机是允许继续执行一次的，因为不是同一个实例

还有像 isheng 作为 toB 的低代码平台是会建立目标企业内部的 SOB 库从而提高效率

其中 SOB 是 Standard Operating Block（标准业务模块 / 标准操作块），把企业内部反复出现、稳定、可复用的业务能力，抽象成“可拼装的积木块”，从而实现 企业底层API 和业务流程 workflow 之间的稳定

从产品角度看AI

开发者总是追求更优的技术

GPT是一种技术，ChatGPT作为一种产品解决了技术和没有技术背景的人员的间隔

个人感觉是一种技术到面向用户的商业化的转变

“以用户为中心”

生命周期

1. AI产品机会发现

相对于toB，toC的用户更需要去挖掘

灵感的不确定性比较高，但也有一些方法论

例如用 semrush 去爬高流量网页，发现这个网页的主题是土味情话然后就有了Rizz的idea（我感觉还有一些原因是SEO好、曝光高）

我认为本质还是需要流量、曝光，那么即使概率低最后进筐的还是很多

2. AI产品设计、开发与上线

冷启动：通过LLM生成问题对，来应对客户

提示词工程 → 模型能力 → 评判

GUI around LUI, GUI in LUI, 画布式UI

尽快让核心功能展示给用户

3. AI产品运营

产品的流量发现，要尽可能的拓展覆盖域，同时和用户保持交流

还有一些博客主发布推广软文

QA

• Q: 意图识别如何做

  A: LLM

• Q: Agent方向

  A: 即两个划分：工作流和自主智能体。像Manus和claude code这种都很不错

• Q: 低代码平台的使用边界是什么？什么场景适合用什么场景不适合？

  A: 快速迭代（研发部门主导），但是现在claude code发展迅速可能产品部门后面也会主导

• Q: 纯代码框架

  A: 推荐LangGraph，本质还是状态机。LangChain概念比较多，学习成本高

• Q: 商业化收费

  A: 标准化Sass产品去买平台服务

• Q: Write范式

  A: 向量模型、向量数据库、大模型。向量模型切割的处理。Agent中包含Write的执行

我感觉像 SDD 就属于 Write 范式，作为一个评判标准、工具去让 Agent 调用