AI Day 12
AI Day 12: Agent框架：ReAct / Tool Use / Planning — 让AI不只是聊天，而是"做事"
AI Agent 是以LLM为"大脑"，配备记忆(Memory)、工具(Tools)和规划能力(Planning)的自主系统——它不只是回答问题，而是能感知环境、制定计划、调用工具、执行多步任务，并根据结果动态调整策略。
2026-04-13
AIReActToolFunctionPlanningLangChainLangGraphCrewAIAutoGenClaudeMulti-AgentMemory
日期：2026-04-13
阶段：第一阶段 — AI/LLM技术深潜 (Day 1-15)
标签：AI Agent ReAct Tool Use Function Calling Planning LangChain LangGraph CrewAI AutoGen Claude Agent SDK Multi-Agent Memory
学习路径树
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15)
│ ├── Day 1: Transformer架构与LLM基础 ✅
│ ├── Day 2: 模型量化与本地部署 ✅
│ ├── Day 3: 训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│ ├── Day 4: Prompt Engineering与上下文学习(ICL)原理 ✅
│ ├── Day 5: RAG架构：检索增强生成全链路 ✅
│ ├── Day 6: 向量数据库与Embedding模型 ✅
│ ├── Day 7: Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│ ├── Day 8: 推理优化：vLLM / TensorRT-LLM / SGLang ✅
│ ├── Day 9: 长上下文技术：RoPE扩展 / Ring Attention ✅
│ ├── Day 10: 多模态模型：Vision-Language架构 ✅
│ ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking ✅
│ ├── Day 12: Agent框架：ReAct / Tool Use / Planning ← 你在这里
│ ├── Day 13: MCP协议与Tool生态
│ ├── Day 14: 模型评估：Benchmark / Arena / 安全评估
│ └── Day 15: 阶段复习与架构总结
│
├── 第二阶段：工程实践 (Day 16-30)
│ ├── Day 16-20: LLM应用架构设计（微服务/网关/缓存/监控）
│ ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│ └── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│ ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│ └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念
一句话定义
AI Agent 是以LLM为"大脑"，配备记忆(Memory)、工具(Tools)和规划能力(Planning)的自主系统——它不只是回答问题，而是能感知环境、制定计划、调用工具、执行多步任务，并根据结果动态调整策略。
金融类比
普通LLM (ChatGPT/Claude聊天模式):
= 银行客服热线
→ 客户问什么答什么
→ "请问我的余额是多少？" → "抱歉，我无法查询您的账户"
→ "如何转账？" → "您可以通过手机银行..."
→ 只能回答知识性问题，不能实际操作任何东西
→ 纯粹的信息输出，没有行动能力
AI Agent (Agent模式):
= 专属客户经理 / 私人银行顾问
→ 客户说: "帮我把10万转到理财账户，选一个年化4%以上的产品"
→ 客户经理:
1. [思考] 先查看客户当前余额和风险等级
2. [行动] 登录核心系统查询余额 → 确认有10万可用
3. [思考] 筛选符合条件的理财产品
4. [行动] 调用产品系统查询 → 找到3个符合条件的
5. [思考] 根据客户风险偏好排序
6. [行动] 执行转账 + 购买理财
7. [观察] 确认交易成功
8. [回复] "已完成。为您选择了XX产品，年化4.2%，已投入10万"
→ 能思考、能查系统、能操作、能确认结果
→ 一个完整的"任务闭环"
本质区别:
LLM: 输入文本 → 输出文本 (语言模型)
Agent: 输入目标 → 完成任务 (行动系统)
LLM 的能力边界 = 它的知识 + 推理能力
Agent 的能力边界 = LLM能力 × 可用工具数 × 规划能力
为什么2025-2026 Agent是最热方向
时间线:
2023.03 AutoGPT引爆Agent概念 → 但实际效果很差(循环/幻觉/失控)
2023.10 OpenAI Function Calling → 标准化工具调用接口
2024.04 Devin发布 → AI软件工程师，引发Agent+编码热潮
2024.11 Anthropic Computer Use → Claude可以操作电脑GUI
2025.01 OpenAI Operator → Agent直接操作浏览器完成任务
2025.03 Anthropic Claude Agent SDK → 官方Agent开发框架
2025.05 Claude Code → Agent范式的代码开发工具，日活工程师百万+
2025.06 MCP(Model Context Protocol)生态爆发 → Agent工具标准化
2025-26 "Agentic AI" 成为企业AI部署第一关键词
为什么现在Agent终于可用了？
1. Reasoning模型 → Agent的"大脑"够强了(Day 11)
2. 长上下文 → Agent能处理复杂任务的完整信息(Day 9)
3. Tool Use标准化 → Function Calling / MCP成熟
4. 错误恢复 → 模型能自我纠错，不再陷入死循环
5. 成本下降 → GPT-4o/Claude Sonnet让Agent调用变得经济可行
知识点1: Agent基本概念
什么是AI Agent
AI Agent的定义:
一个能够自主感知环境、做出决策、执行行动以达成目标的AI系统
四大核心组件:
┌─────────────────────────────────────────────────┐
│ AI Agent │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ LLM │ │ Memory │ │ Tools │ │
│ │ (大脑) │ │ (记忆) │ │ (工具) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └─────────┬───┘─────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ Planning │ │
│ │ (规划引擎) │ │
│ └─────────────┘ │
└─────────────────────────────────────────────────┘
LLM (大脑):
→ 理解指令、推理、决策、生成文本
→ GPT-4o / Claude Opus 4 / Gemini 2.5 Pro
→ 越强的LLM = 越聪明的Agent
Memory (记忆):
→ 短期: 当前对话上下文
→ 长期: 历史交互、用户偏好、学到的知识
→ 工作记忆: 当前任务的中间状态(scratchpad)
Tools (工具):
→ API调用(天气/搜索/数据库)
→ 代码执行(Python/SQL)
→ 浏览器操作 / 文件读写
→ 每个工具 = Agent能做的一件"事"
Planning (规划):
→ 分解目标为子任务
→ 决定工具调用顺序
→ 根据结果动态调整计划
Agent与普通Chatbot的区别
┌────────────────┬───────────────────┬───────────────────┐
│ │ Chatbot (聊天机器人)│ Agent (智能代理) │
├────────────────┼───────────────────┼───────────────────┤
│ 交互模式 │ 问→答→问→答 │ 目标→规划→执行→反馈 │
│ 工具使用 │ 无 │ 调用多种外部工具 │
│ 状态管理 │ 无状态或简单上下文 │ 复杂状态机+记忆 │
│ 自主性 │ 被动响应 │ 主动规划和执行 │
│ 错误处理 │ 给出错误答案 │ 检测错误并重试/换策略│
│ 任务复杂度 │ 单轮简单问答 │ 多步骤复杂任务 │
│ 行动能力 │ 只输出文本 │ 可执行真实操作 │
│ 典型耗时 │ 秒级 │ 分钟到小时级 │
├────────────────┼───────────────────┼───────────────────┤
│ 金融场景示例 │ "什么是基金定投？" │ "帮我定投每月5000到│
│ │ → 解释概念 │ 沪深300，对比3个平 │
│ │ │ 台费率后选最优方案" │
└────────────────┴───────────────────┴───────────────────┘
Agent Loop: Observe → Think → Act → Observe
这是所有Agent系统的核心循环:
┌──────────────────────────────────────────────┐
│ │
│ ┌─────────┐ │
│ │ Observe │ ← 感知环境/工具返回/用户输入 │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ Think │ ← LLM推理: 分析观察，决定行动 │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Act │ ──→ │ 工具执行 │ │
│ └────┬────┘ └────┬────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌────────────────────────┐ │
│ │ Observe (新的观察) │────────────┐ │
│ └────────────────────────┘ │ │
│ │ │
│ 任务完成？ │ │
│ ├── 否 → 继续循环 ─────────────────────┘ │
│ └── 是 → 输出最终结果 │
│ │
└──────────────────────────────────────────────┘
金融Agent示例:
用户: "帮我分析茅台最新财报，评估是否值得买入"
Loop 1:
Observe: 用户想分析茅台财报
Think: 需要先获取最新财报数据
Act: 调用财报API → 获取2025年Q4数据
Loop 2:
Observe: 收到财报 → 营收1800亿，净利润800亿
Think: 需要计算关键指标(PE/ROE/毛利率)并对比历史
Act: 调用计算工具 → PE=30x, ROE=32%, 毛利率91%
Loop 3:
Observe: 指标计算完成，PE略高于历史均值
Think: 需要对比同行业和查看分析师观点
Act: 调用搜索工具 → 获取行业对比和分析师报告
Loop 4:
Observe: 同行业PE中位数25x，分析师一致看多
Think: 综合分析 → PE偏高但基本面极强，估值合理
Act: 生成分析报告返回用户
→ 4轮循环，每轮都是Observe→Think→Act
→ 普通Chatbot只能说"我无法访问实时财报数据"
知识点2: ReAct模式
Reasoning + Acting 交替执行
ReAct (Yao et al., 2022):
将Reasoning(推理)和Acting(行动)交织在一起
→ 不是先想完再做 → 而是想一步做一步
为什么这很重要？
纯Reasoning (CoT only):
"茅台PE=30, 行业均值=25, 所以偏贵"
→ 问题: 如果你的知识是过时的？PE可能已经变了
→ 推理基于可能错误的前提 → 结论不可靠
纯Acting (工具调用 only):
调用API获取PE → 调用API获取行业均值 → 计算差值
→ 问题: 没有推理，不知道什么时候该停止调用
→ 可能无限调用工具或调错工具
ReAct (推理+行动交替):
Thought: 我需要茅台当前PE，不能依赖过时知识
Action: 调用财报API获取实时PE
Observation: PE = 28.5
Thought: PE=28.5比我预期的低，可能最近有回调，继续查行业
Action: 调用行业对比API
Observation: 行业均值PE = 24
Thought: PE=28.5 vs 行业24，溢价18%，合理范围。完成分析
→ 每步推理指导下一步行动 → 每步行动结果修正推理
ReAct详细流程
用户请求
│
▼
┌────────────────┐
│ 生成Thought │ ← LLM推理当前状况
│ (推理步骤) │
└───────┬────────┘
│
▼
┌────────────────┐
┌─── │ 需要行动吗？ │
│ └───────┬────────┘
│ │
│ 不需要 │ 需要
│ ▼
│ ┌────────────────┐
│ │ 生成Action │ ← 选择工具+参数
│ │ (行动步骤) │
│ └───────┬────────┘
│ │
│ ▼
│ ┌────────────────┐
│ │ 执行工具调用 │ ← 实际API/计算
│ └───────┬────────┘
│ │
│ ▼
│ ┌────────────────┐
│ │ Observation │ ← 工具返回结果
│ │ (观察结果) │
│ └───────┬────────┘
│ │
│ ▼
│ ┌────────────────┐
│ │ 更新上下文 │ ← 将结果加入记忆
│ └───────┬────────┘
│ │
▼ ▼
┌────────────────────────┐
│ 任务完成？ │
│ ├── 否 → 回到Thought │──→ (继续循环)
│ └── 是 → 生成最终答案 │
└────────────────────────┘
实际Prompt格式
ReAct的Prompt模板（简化版）:
System Prompt:
You are a helpful financial analyst agent.
You have access to the following tools:
- search(query): Search the web for information
- get_stock_data(ticker, metric): Get stock financial data
- calculate(expression): Evaluate a math expression
Use the following format:
Thought: [your reasoning about what to do next]
Action: [tool_name(parameters)]
Observation: [tool output - this will be filled by the system]
... (repeat Thought/Action/Observation as needed)
Thought: I now have enough information to answer
Final Answer: [your complete answer]
User: 比较苹果和微软的PE，哪个更值得买入？
Agent执行过程:
Thought: 需要获取苹果(AAPL)和微软(MSFT)的PE数据来对比
Action: get_stock_data("AAPL", "pe_ratio")
Observation: {"ticker": "AAPL", "pe_ratio": 32.1, "date": "2026-04-13"}
Thought: 已获取苹果PE=32.1。现在获取微软的PE
Action: get_stock_data("MSFT", "pe_ratio")
Observation: {"ticker": "MSFT", "pe_ratio": 35.8, "date": "2026-04-13"}
Thought: AAPL PE=32.1, MSFT PE=35.8。微软更贵，但PE本身
不够，需要看盈利增长率(PEG)才能评估是否合理
Action: get_stock_data("AAPL", "earnings_growth")
Observation: {"ticker": "AAPL", "earnings_growth_yoy": 0.12}
Thought: 苹果盈利增长12%，PEG = 32.1/12 = 2.68。查微软
Action: get_stock_data("MSFT", "earnings_growth")
Observation: {"ticker": "MSFT", "earnings_growth_yoy": 0.18}
Thought: 微软盈利增长18%, PEG = 35.8/18 = 1.99。微软PEG更低，
说明虽然PE更高但增长更快，性价比其实更好。
我现在有足够信息做出分析了。
Final Answer: 从估值角度看:
- 苹果 PE=32.1, 盈利增长12%, PEG=2.68
- 微软 PE=35.8, 盈利增长18%, PEG=1.99
微软虽然PE更高，但PEG更低(1.99 vs 2.68)，说明...
为什么ReAct比纯CoT更强
对比实验 (Yao et al., 2022):
任务: 多步知识推理 (HotpotQA)
┌───────────────┬──────────┐
│ 方法 │ 准确率 │
├───────────────┼──────────┤
│ Standard IO │ 29.0% │
│ CoT only │ 34.0% │
│ Act only │ 26.0% │
│ ReAct │ 35.0% │ ← 最高
│ ReAct + CoT-SC│ 40.0% │ ← 结合后更强
└───────────────┴──────────┘
为什么ReAct优于纯CoT？
1. 信息获取: CoT只能用已有知识推理 → ReAct能获取新信息
2. 事实校验: CoT可能基于幻觉推理 → ReAct通过工具验证事实
3. 计算准确: CoT让LLM心算 → ReAct用计算器精确计算
4. 可追溯性: ReAct的Thought链 → 可审计决策过程
为什么ReAct优于纯Act？
1. 目标导向: 推理让Agent知道"为什么"调用工具
2. 效率: 推理减少不必要的工具调用
3. 整合: 推理把多个工具结果综合成有意义的结论
4. 终止: 推理判断何时已收集足够信息 → 避免无限循环
金融PM视角:
ReAct = 最符合人类工作方式的Agent模式
→ 分析师也是: 看数据(Observe) → 想(Think) → 查更多资料(Act) → 循环
→ 可解释性强 → 监管/合规场景下可审计
知识点3: Tool Use / Function Calling
核心机制
Tool Use 让 LLM 从"纯文本生成器"变成"工具使用者":
传统LLM:
用户: "今天上海天气怎么样？"
LLM: "我没有实时天气数据，无法回答" ← 老实但没用
Tool Use LLM:
用户: "今天上海天气怎么样？"
LLM: [决定调用天气工具]
→ {"tool": "get_weather", "params": {"city": "Shanghai"}}
系统: [执行工具调用] → {"temp": 22, "condition": "晴"}
LLM: "今天上海天气晴朗，气温22°C，适合外出" ← 有用
技术实现流程:
┌────────┐ 1.发送消息 ┌────────┐
│ 用户 │ ──────────→ │ LLM │
└────────┘ └───┬────┘
│ 2.LLM判断需要调用工具
│ 返回tool_call JSON
▼
┌────────────┐
│ 应用程序 │ 3.解析tool_call
│ (你的代码) │ 执行实际API调用
└──────┬─────┘
│ 4.将工具结果返回给LLM
▼
┌────────────┐
│ LLM │ 5.LLM综合结果生成最终回答
└──────┬─────┘
│
▼
┌────────────┐
│ 用户看到 │ 最终自然语言回答
│ 完整回答 │
└────────────┘
关键: LLM本身不执行工具 → 只生成"调用意图"(JSON)
→ 应用程序负责实际执行 → 结果喂回LLM
→ 这保证了安全性: 你的代码控制什么能执行、什么不能
OpenAI Function Calling
OpenAI的Tool Use实现 (2023年开创，2025年成熟):
工具定义格式:
tools = [
{
"type": "function",
"function": {
"name": "get_stock_price",
"description": "获取指定股票的当前价格和关键指标",
"parameters": {
"type": "object",
"properties": {
"ticker": {
"type": "string",
"description": "股票代码，如AAPL、MSFT"
},
"metrics": {
"type": "array",
"items": {"type": "string"},
"description": "需要的指标: price/pe/volume/market_cap"
}
},
"required": ["ticker"]
}
}
}
]
LLM返回的tool_call:
{
"tool_calls": [{
"id": "call_abc123",
"type": "function",
"function": {
"name": "get_stock_price",
"arguments": "{\"ticker\": \"AAPL\", \"metrics\": [\"price\", \"pe\"]}"
}
}]
}
你的代码执行后返回:
{
"role": "tool",
"tool_call_id": "call_abc123",
"content": "{\"price\": 198.5, \"pe\": 32.1}"
}
2025年改进:
- Parallel Function Calling: 一次返回多个tool_call → 并行执行
- Strict Mode: 返回JSON严格符合schema → 减少解析错误
- Streaming: 工具调用也支持流式 → 更好的用户体验
Anthropic Tool Use
Anthropic的实现 (Claude 3+ 系列):
工具定义格式:
tools = [
{
"name": "query_database",
"description": "查询金融数据库，获取交易记录和账户信息",
"input_schema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "SQL查询语句"
},
"database": {
"type": "string",
"enum": ["transactions", "accounts", "products"]
}
},
"required": ["query", "database"]
}
}
]
Claude返回:
{
"content": [
{
"type": "text",
"text": "我需要先查询该客户的交易记录..."
},
{
"type": "tool_use",
"id": "toolu_abc123",
"name": "query_database",
"input": {
"query": "SELECT * FROM txn WHERE user_id='U001' ORDER BY date DESC LIMIT 10",
"database": "transactions"
}
}
]
}
Anthropic的独特设计:
1. 工具调用可以和文本混合在同一个response中
→ Claude会先解释为什么要调用这个工具
→ 提升可解释性（对金融合规很重要）
2. Extended Thinking + Tool Use (2025)
→ Claude先在thinking中规划用哪些工具
→ 然后执行工具调用
→ Reasoning Agent的最佳实践
3. Computer Use (2024.11发布)
→ 特殊工具类型: 操作电脑GUI
→ 截屏 → 识别界面元素 → 模拟点击/输入
→ 可以操作没有API的遗留系统(金融行业尤其多)
并行工具调用
单次请求多个工具 → 大幅提升Agent效率:
串行调用 (慢):
Thought: 需要查苹果和微软的PE
Action: get_stock_data("AAPL", "pe") → 等2秒
Observation: PE=32.1
Action: get_stock_data("MSFT", "pe") → 又等2秒
Observation: PE=35.8
→ 总计4秒
并行调用 (快):
Thought: 需要同时查苹果和微软的PE
Actions: [
get_stock_data("AAPL", "pe"),
get_stock_data("MSFT", "pe")
]
→ 同时执行 → 2秒得到两个结果
Observations: AAPL PE=32.1, MSFT PE=35.8
何时适合并行:
✓ 多个独立的数据获取（不互相依赖）
✓ 批量操作（同类型不同参数）
✗ 有依赖关系的调用（B的参数取决于A的结果）
金融场景:
"对比5家银行的理财产品利率"
→ 并行查5个银行API → 秒级完成
→ 串行查 → 可能要10秒+
2025-2026最佳实践:
OpenAI GPT-4o: 原生支持parallel tool calls
Claude Opus 4: 支持多tool_use block并行
自定义框架: 通常需要自己实现并行执行层
工具选择策略
当Agent有很多工具时，如何选择正确的工具？
问题:
Agent可能有50+工具
→ 全部放进System Prompt → token太多/模型选择困难
→ 如何高效匹配？
策略1: 全量注入 (工具数 < 20)
所有工具定义都放在System Prompt中
→ 简单直接
→ 适合工具少且模型强的场景
策略2: 分类分层 (工具数 20-100)
┌─────────────────────────────┐
│ 第一层: 工具类别选择 │
│ → 金融分析 / 数据查询 / 交易 │
├─────────────────────────────┤
│ 第二层: 具体工具选择 │
│ → get_pe / get_revenue / ...│
└─────────────────────────────┘
→ 两步决策，减少每步的选择空间
策略3: 语义检索 (工具数 > 100)
用户请求 → Embedding → 向量搜索最相关的5个工具
→ 只把最相关的工具注入Prompt
→ 类似RAG，但检索的是工具描述而非文档
策略4: MCP动态注册 (Day 13详解)
工具不硬编码 → 通过MCP协议动态发现
→ Agent运行时发现"哦，有新的区块链分析工具可用"
→ 最灵活但最复杂
金融系统的工具选择:
合规要求: 不是所有Agent都能调用所有工具
→ 零售客户Agent: 只能查产品/费率，不能执行交易
→ 投顾Agent: 可以查行情+分析，不能直接下单
→ 交易Agent: 可以下单，但有限额和审批
→ 权限控制 = Agent安全的核心
知识点4: Planning策略
为什么Agent需要规划
简单任务 → ReAct即可 → 一步步想/做
复杂任务 → 需要先规划 → 否则Agent会迷路
对比:
ReAct (无规划):
"帮我做一份行业分析报告"
Thought: 先查行业规模... → 查了 → 然后呢？
Thought: 再查竞争格局... → 查了 → 还需要什么？
Thought: 呃，查查政策环境？ → ...
→ 缺乏全局视角 → 可能遗漏重要维度 → 产出不完整
有规划的Agent:
"帮我做一份行业分析报告"
Plan:
1. 行业概览（规模/增长率/关键驱动因素）
2. 竞争格局（主要玩家/份额/差异化）
3. 产业链分析（上游/中游/下游）
4. 政策环境（监管趋势/合规要求）
5. 未来趋势（技术/市场/风险）
6. 整合成报告
→ 有全局蓝图 → 每步都知道自己在整体中的位置
Plan-and-Execute
最直觉的规划方式: 先做计划，再逐步执行
┌──────────────────────────────────┐
│ Phase 1: Planning │
│ LLM生成完整的执行计划 │
│ Step 1: ... │
│ Step 2: ... │
│ Step 3: ... │
└──────────────┬───────────────────┘
│
▼
┌──────────────────────────────────┐
│ Phase 2: Execution │
│ 逐步执行计划中的每一步 │
│ Step 1 → 执行 → 结果 │
│ Step 2 → 执行 → 结果 │
│ Step 3 → 执行 → 结果 │
└──────────────┬───────────────────┘
│
▼
┌──────────────────────────────────┐
│ Phase 3: Synthesis │
│ 整合所有步骤结果，生成最终输出 │
└──────────────────────────────────┘
优点:
+ 结构清晰，步骤可预测
+ 用户可以在执行前审核计划
+ 适合有固定流程的任务(审计/报告/合规检查)
缺点:
- 计划是静态的 → 如果步骤2失败，整个计划可能需要重做
- 不适合需要根据中间结果调整策略的场景
Hierarchical Planning (层次化规划)
复杂任务 → 分解为子任务 → 子任务再分解:
用户: "帮我设计一个DeFi借贷协议的产品方案"
高层计划 (Strategic):
1. 市场分析
2. 产品设计
3. 技术方案
4. 风险评估
5. Go-to-market
中层计划 (Tactical):
2. 产品设计:
2.1 核心借贷机制设计
2.2 利率模型选择
2.3 清算机制设计
2.4 代币经济模型
底层执行 (Operational):
2.2 利率模型选择:
2.2.1 查询Aave利率模型参数
2.2.2 查询Compound利率模型参数
2.2.3 对比两者优劣
2.2.4 推荐最优方案
┌────────────────────────────────────┐
│ 高层规划Agent │
│ (分解为5个子任务) │
└──────┬──────┬──────┬──────┬───────┘
│ │ │ │
▼ ▼ ▼ ▼
┌──────┐ ┌──────┐ ... ┌──────┐
│子任务1│ │子任务2│ │子任务5│
│ Agent│ │ Agent│ │ Agent│ ← 每个可以是独立Agent
└──────┘ └──────┘ └──────┘
优点:
+ 可并行执行子任务
+ 每个子Agent可以专精一个领域
+ 失败隔离: 一个子任务失败不影响其他
缺点:
- 架构复杂
- 子Agent之间需要信息共享机制
- 成本高(多个LLM调用)
动态重规划 (Adaptive Re-planning)
计划不是一成不变的 → 根据执行结果动态调整:
初始计划:
Step 1: 查询用户信用评分 → 预期结果: 分数
Step 2: 根据分数推荐产品 → 预期结果: 产品列表
Step 3: 生成推荐报告
执行到Step 1:
结果: "该用户无信用记录" → 原计划失效!
重新规划:
Step 1: [已完成] → 用户无信用记录
Step 2: [调整] → 改为查询替代数据(社保/公积金/消费记录)
Step 3: [新增] → 基于替代数据做风险评估
Step 4: [调整] → 推荐适合新用户的产品(小额/担保类)
Step 5: 生成推荐报告
→ 计划根据实际情况动态演进
→ 这才是真实世界中Agent最需要的能力
实现方式:
每执行完一步 → 检查:
1. 结果是否符合预期？
2. 是否需要调整后续步骤？
3. 是否发现了新的必要步骤？
→ 如果需要 → 重新调用LLM生成修正后的计划
ReAct vs Planning: 何时用哪个
┌─────────────────┬──────────────────┬──────────────────┐
│ 维度 │ ReAct │ Planning │
├─────────────────┼──────────────────┼──────────────────┤
│ 任务步骤数 │ 1-5步 │ 5-20+步 │
│ 是否需要全局视角 │ 不需要 │ 需要 │
│ 中间结果可预测 │ 不可预测 │ 大致可预测 │
│ 用户是否需要预览 │ 不需要 │ 需要审批计划 │
│ 容错要求 │ 可以试错 │ 错误代价高 │
│ 典型延迟 │ 快(秒级/轮次少) │ 慢(先规划再执行) │
├─────────────────┼──────────────────┼──────────────────┤
│ 适用场景示例 │ "查一下ETH价格" │ "做一份尽调报告" │
│ │ "解释这段代码" │ "设计空投方案" │
│ │ "搜索最新新闻" │ "迁移遗留系统" │
└─────────────────┴──────────────────┴──────────────────┘
最佳实践 (2025-2026):
大多数生产系统会组合使用:
简单请求 → ReAct模式 → 快速响应
复杂请求 → 先Plan → 用户确认 → 逐步ReAct执行每个子任务
执行中出现意外 → 动态Re-plan → 继续执行
这就是LangGraph/CrewAI等框架的核心设计思路
知识点5: 2025-2026 Agent框架对比
主流框架概览
2025-2026年Agent框架生态:
┌─────────────────────────────────────────────────────────┐
│ Agent框架生态图 │
│ │
│ 平台级 (厂商官方): │
│ OpenAI Assistants API / Responses API │
│ Anthropic Claude Agent SDK │
│ Google Vertex AI Agent Builder │
│ │
│ 通用框架: │
│ LangChain / LangGraph (最大生态) │
│ Pydantic AI (类型安全) │
│ Smolagents (HuggingFace) (极简主义) │
│ │
│ 多Agent框架: │
│ CrewAI (角色扮演) │
│ AutoGen / AG2 (Microsoft) (多Agent对话) │
│ OpenAI Swarm (轻量多Agent) │
│ │
│ 协议标准: │
│ MCP (Model Context Protocol) (工具标准化) │
│ A2A (Agent-to-Agent Protocol) (Agent间通信) │
└─────────────────────────────────────────────────────────┘
LangChain / LangGraph
LangChain (2022年底发布):
最早的LLM应用框架 → 生态最大
核心: Chain(链式调用) + Agent(工具调用) + Memory + 集成
优点:
+ 生态最丰富: 600+ 集成(向量库/LLM/工具)
+ 文档完善，社区活跃
+ LangSmith: 配套的观测/调试平台
缺点:
- 过度抽象 → "简单事情变复杂"
- 版本迭代激进 → 频繁Breaking Change
- 调试困难 → 抽象层太多层
LangGraph (2024年发布，LangChain团队):
用"图"(Graph)来定义Agent工作流
核心: 节点(Node) + 边(Edge) + 状态(State)
┌─────┐ 条件边 ┌─────────┐
│ 开始 │ ──────────→ │ 分析请求 │
└─────┘ └────┬────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 查数据 │ │ 搜新闻 │ │ 查行情 │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└─────────┬──┘────────────┘
▼
┌──────────┐
│ 综合分析 │
└────┬─────┘
▼
┌──────────┐
│ 生成报告 │
└──────────┘
优点:
+ 流程可视化
+ 支持条件分支/循环/并行
+ 状态持久化 → 适合长运行任务
+ Human-in-the-Loop: 关键节点人工审批
定位: 最适合复杂的、有确定工作流的Agent系统
CrewAI
CrewAI (2024年爆发):
核心理念: 多个Agent角色协作完成任务
→ 模拟团队协作 → 每个Agent扮演不同角色
金融分析团队示例:
Crew = 金融分析团队
├── Agent 1: 宏观分析师
│ Role: 分析宏观经济环境
│ Tools: [economic_data_api, news_search]
│ Goal: 评估当前经济周期
│
├── Agent 2: 行业分析师
│ Role: 深度行业研究
│ Tools: [industry_reports, company_data]
│ Goal: 行业竞争格局分析
│
├── Agent 3: 量化分析师
│ Role: 估值和数据建模
│ Tools: [financial_calculator, backtester]
│ Goal: 计算合理估值区间
│
└── Agent 4: 报告编写员
Role: 整合分析，生成报告
Tools: [document_generator]
Goal: 产出专业投研报告
优点:
+ 直觉上容易理解(团队协作隐喻)
+ 每个Agent可以用不同的LLM
+ 内置角色分配和任务委派
+ 2025年发布了CrewAI Enterprise (企业版)
缺点:
- 角色定义质量决定输出质量
- 多Agent通信开销大
- 成本高(N个Agent × M次调用)
- 调试复杂: 问题出在哪个Agent?
AutoGen / AG2 (Microsoft)
AutoGen (Microsoft Research, 2023):
核心: Multi-Agent对话系统
→ Agent之间通过"对话"协作(不是预定义工作流)
2025年重大变化:
AutoGen → 分裂为两个项目
├── AutoGen 0.4+ (Microsoft官方): 重写，更模块化
└── AG2 (社区Fork): 延续原版设计理念
核心概念:
ConversableAgent: 能对话的Agent
GroupChat: 多个Agent在群聊中协作
GroupChatManager: 管理谁该发言
示例: 代码审查场景
┌────────────┐ "写一个支付接口" ┌────────────┐
│ 用户 │ ────────────────→ │ 编码Agent │
└────────────┘ └──────┬─────┘
│ 写完代码
▼
┌────────────┐
│ 审查Agent │ → 发现bug
└──────┬─────┘
│ 反馈修改意见
▼
┌────────────┐
│ 编码Agent │ → 修复
└──────┬─────┘
│
▼
┌────────────┐
│ 测试Agent │ → 通过
└────────────┘
优点:
+ 灵活的Agent对话协议
+ 支持人参与对话(Human Agent)
+ 微软背景 → 企业级支持
+ 代码执行能力强(Docker沙箱)
缺点:
- 对话式协作 → 有时低效(Agent之间废话太多)
- 分裂后生态碎片化
- 学习曲线较陡
Pydantic AI
Pydantic AI (2024年底发布):
来自Pydantic团队 (FastAPI / Pydantic的创建者)
核心理念: 类型安全 + 简洁 + 生产就绪
设计哲学:
LangChain: "给你所有工具，自己组装"
Pydantic AI: "像写FastAPI一样写Agent"
代码风格 (伪代码):
from pydantic_ai import Agent
agent = Agent(
'openai:gpt-4o',
system_prompt='你是金融分析助手',
result_type=StockAnalysis, # 强类型输出
)
@agent.tool
def get_stock_data(ticker: str) -> StockData:
"""获取股票数据"""
return api.fetch(ticker)
result = await agent.run("分析苹果股票")
# result.data 是 StockAnalysis 类型 → IDE自动补全
优点:
+ 类型安全 → 编译期就能发现错误
+ 极简API → 学习成本低
+ 原生异步 → 适合高并发Web服务
+ 结构化输出 → result_type保证返回格式
+ LangChain/LangGraph可以集成Pydantic AI
缺点:
- 生态较小(新框架)
- 不适合超复杂的多Agent场景
- 文档还在完善中
适合: Python后端开发者、需要快速构建生产级单Agent
Smolagents (HuggingFace)
Smolagents (2025年发布):
HuggingFace的极简Agent框架
名字来自"Small Agents" → 强调轻量
核心特色: Code Agent
传统Agent: 生成JSON描述工具调用 → 应用程序解析执行
Code Agent: 直接生成Python代码 → 执行代码来调用工具
传统: {"tool": "search", "query": "ETH price"} → 解析 → 执行
Code: result = search("ETH price") → 直接执行
为什么Code更好?
→ LLM本来就擅长写代码
→ 代码天然支持变量/循环/条件/函数调用
→ 不需要特殊的JSON schema解析层
优点:
+ 极简: 核心代码不到1000行
+ Code Agent模式高效
+ 与HuggingFace Hub集成
+ 支持本地开源模型
缺点:
- 功能较少(故意为之)
- Code执行有安全风险(需沙箱)
- 不适合复杂多Agent场景
适合: 快速原型、研究实验、与HuggingFace生态集成
OpenAI Assistants API / Responses API
OpenAI的Agent平台 (持续演进):
Assistants API (2023.11):
→ 托管的Agent运行时
→ 内置: Code Interpreter / File Search / Function Calling
→ 状态管理: Thread(对话) + Run(执行)
→ 自带向量存储 → 不需要自己搭RAG
Responses API (2025.03 新):
→ 取代Chat Completions API的新一代
→ 原生支持: Web Search / File Search / Computer Use
→ 内置工具更丰富
→ 与Agents SDK配合使用
优点:
+ 最简单的上手路径 → OpenAI全托管
+ 内置Code Interpreter → 数据分析Agent一行代码
+ 内置File Search → 文档RAG零配置
+ 有GPT Store生态
缺点:
- 厂商锁定 → 只能用OpenAI模型
- 可观测性有限 → 黑箱运行
- 定制化受限
- 成本: 存储/运行都按用量收费
Claude Agent SDK
Anthropic Claude Agent SDK (2025.03发布):
核心设计:
→ 基于Claude模型的Agent开发框架
→ 原生支持Extended Thinking + Tool Use
→ 强调安全性和可控性
关键特性:
1. Agentic Loop: 内置Observe→Think→Act循环
2. MCP集成: 原生支持MCP协议 → 无缝连接工具生态
3. Guardrails: 内置安全护栏 → Agent不会执行危险操作
4. Multi-turn: 自动管理对话状态
5. Streaming: 实时显示Agent思考和行动过程
与Claude Code的关系:
Claude Code = 基于Agent SDK构建的编程Agent产品
→ Agent SDK是基础设施
→ Claude Code是上层应用
→ 你可以用Agent SDK构建自己的"Claude Code"
优点:
+ Anthropic官方支持 → 与Claude深度集成
+ 安全设计优先 → 适合金融/医疗等受监管行业
+ MCP原生 → 工具生态最丰富
+ Extended Thinking → Agent规划能力最强
缺点:
- 只支持Claude模型
- 相对较新 → 社区资源还在建设中
详细对比表
┌──────────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
│ │LangGr. │CrewAI │AutoGen │Pydant. │Smol. │OAI API │Claude │
│ │ │ │/AG2 │AI │agents │ │SDK │
├──────────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
│ 复杂度 │ 高 │ 中 │ 高 │ 低 │ 极低 │ 低 │ 中 │
│ 灵活性 │ 极高 │ 中 │ 高 │ 中 │ 低 │ 低 │ 中 │
│ 多Agent │ ✓ │ ✓✓ │ ✓✓ │ ✗ │ ✗ │ ✗ │ ✓ │
│ 模型无关 │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │ ✗ │
│ 类型安全 │ 弱 │ 弱 │ 弱 │ 强 │ 弱 │ 中 │ 中 │
│ 可视化 │ ✓✓ │ ✓ │ ✗ │ ✗ │ ✗ │ ✗ │ ✗ │
│ 企业就绪 │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │ ✓ │ ✓ │
│ 学习曲线 │ 陡 │ 平 │ 陡 │ 平 │ 极平 │ 平 │ 中 │
│ 生态规模 │ 极大 │ 大 │ 大 │ 小 │ 中 │ 极大 │ 中 │
│ MCP支持 │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │ ✓✓ │
├──────────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
│ 最适合场景 │复杂 │团队 │研究 │生产 │原型 │快速 │安全 │
│ │工作流 │协作 │实验 │API │实验 │上线 │合规 │
│ │企业级 │创意 │多Agent │微服务 │教学 │全托管 │金融 │
└──────────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
选型决策树:
你的场景是什么？
│
├── 快速原型/学习 → Smolagents 或 Pydantic AI
│
├── 生产级单Agent API → Pydantic AI 或 OpenAI Assistants
│
├── 复杂工作流(有确定流程) → LangGraph
│
├── 多Agent团队协作 → CrewAI 或 AutoGen
│
├── 需要最强推理能力 → Claude Agent SDK + Extended Thinking
│
├── 金融/合规场景(安全优先) → Claude Agent SDK
│
└── 全托管、不想管基础设施 → OpenAI Assistants API
知识点6: Agent Memory
三种记忆类型
人类的记忆系统:
工作记忆 → 当前正在处理的信息 (脑子里装着的)
短期记忆 → 最近发生的事 (今天做了什么)
长期记忆 → 持久的知识和经验 (一辈子学到的)
Agent的记忆系统对应:
┌─────────────────────────────────────────────────┐
│ Agent Memory System │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Working Memory (工作记忆 / Scratchpad) │ │
│ │ = 当前任务的中间状态 │ │
│ │ 例: "我已查了苹果PE=32, 还需查微软" │ │
│ │ 实现: Agent内部变量 / State管理 │ │
│ │ 生命周期: 单次任务执行期间 │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Short-term Memory (短期记忆) │ │
│ │ = 当前对话的上下文窗口 │ │
│ │ 例: 用户之前问的问题 + Agent之前的回答 │ │
│ │ 实现: LLM的Context Window (128K tokens) │ │
│ │ 生命周期: 单次对话 / Session │ │
│ │ 限制: 上下文窗口大小(token上限) │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Long-term Memory (长期记忆) │ │
│ │ = 跨对话/跨任务持久存储的知识 │ │
│ │ 例: "这个用户偏好保守型理财, 风险厌恶" │ │
│ │ 实现: 向量数据库 / 关系数据库 / 文件系统 │ │
│ │ 生命周期: 持久(跨Session) │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
记忆管理策略
问题: 上下文窗口有限(即使128K tokens也会满)
→ 需要策略管理什么信息保留、什么信息丢弃
策略1: 滑动窗口 (Sliding Window)
保留最近N轮对话 → 丢弃更早的
简单但粗暴 → 可能丢失重要的早期信息
策略2: 摘要压缩 (Summarization)
每当上下文接近限制 → LLM生成摘要 → 替换详细对话
"前10轮对话摘要: 用户是金融从业者，正在研究DeFi借贷..."
→ 信息密度提高，但可能丢失细节
策略3: 语义检索 (Semantic Retrieval)
所有历史对话存入向量库
每次新请求 → 检索最相关的历史片段 → 注入上下文
→ 类似RAG(Day 5)，但检索的是历史对话而非文档
策略4: 实体记忆 (Entity Memory)
提取关键实体和关系 → 结构化存储
"用户: 张三 → 职业: PM → 投资风格: 保守 → 关注: DeFi"
→ 像CRM系统一样管理用户画像
策略5: 分级记忆 (Tiered Memory) — 2025最佳实践
┌────────────┬────────────────────┬──────────┐
│ 层级 │ 内容 │ 存储 │
├────────────┼────────────────────┼──────────┤
│ L0 即时 │ 当前对话最近5轮 │ Context │
│ L1 对话 │ 本次对话摘要 │ Context │
│ L2 用户 │ 用户偏好/画像 │ 向量DB │
│ L3 知识 │ Agent学到的经验 │ 知识图谱 │
└────────────┴────────────────────┴──────────┘
金融Agent的记忆特殊需求:
1. 合规留痕: 所有Agent决策过程必须可追溯 → 不能"忘记"
2. 隐私保护: 用户个人信息不能存在公共向量库
3. 时效性: 金融数据有时效 → 过期的记忆必须标记/清除
4. 一致性: 同一用户的多个Agent会话 → 记忆必须同步
知识点7: Agent设计模式
Single Agent (单Agent)
最简单的模式: 一个Agent搞定一切
用户请求 → [Agent] → 结果
适用:
+ 任务类型单一(客服/搜索/分析)
+ 工具数量适中(<20个)
+ 不需要并行处理
金融示例:
客服Agent: 回答产品问题 + 查询账户信息 + 简单操作
→ 一个Agent + 10个工具 → 覆盖80%客户需求
Multi-Agent (多Agent并行)
多个Agent同时工作 → 各管一个领域:
用户: "帮我做投资组合分析"
│
┌────┴────┬────────────┐
▼ ▼ ▼
┌─────┐ ┌──────┐ ┌──────┐
│股票 │ │债券 │ │另类 │
│分析 │ │分析 │ │资产 │
│Agent │ │Agent │ │Agent │
└──┬──┘ └──┬───┘ └──┬───┘
│ │ │
└────┬───┘─────────┘
▼
┌──────────┐
│ 整合Agent │ → 综合分析报告
└──────────┘
适用: 任务可以分解为独立的子任务
优点: 并行执行 → 速度快
挑战: 子Agent结果如何整合？冲突如何解决？
Hierarchical (层级Agent)
上级Agent管理下级Agent:
┌──────────────────┐
│ Manager Agent │ ← 理解全局目标，分配任务
│ (经理) │
└────────┬─────────┘
│ 分配任务
┌──────┼──────┐
▼ ▼ ▼
┌────┐ ┌────┐ ┌────┐
│研究│ │分析│ │写作│ ← 执行具体工作
│员 │ │师 │ │员 │
└────┘ └────┘ └────┘
Manager的职责:
1. 理解用户最终目标
2. 分解为子任务
3. 分配给合适的子Agent
4. 收集结果并质量检查
5. 如果不满意 → 要求返工
6. 整合最终输出
金融类比: 投行业务部
MD(Manager Agent): 理解客户需求，分配工作
VP(中间Agent): 管理执行细节
Analyst(Worker Agent): 做具体的数据分析和建模
Supervisor-Worker (监督者-工人)
类似Hierarchical但更强调"监督":
┌──────────────────────────────┐
│ Supervisor Agent │
│ - 接收任务 │
│ - 决定由哪个Worker处理 │
│ - 审核Worker输出质量 │
│ - 决定是否需要另一个Worker │
│ - 组合最终结果 │
└──────────┬───────────────────┘
│
┌────┼────┬────┐
▼ ▼ ▼ ▼
W1 W2 W3 W4 (专业Worker)
与Hierarchical的区别:
Hierarchical: Manager提前分配所有任务
Supervisor: 动态决定下一步让谁做 → 更灵活
LangGraph实现:
Supervisor是一个特殊节点 → 根据当前状态路由到不同Worker
每个Worker完成后 → 回到Supervisor → 决定下一步
→ 这是LangGraph最推荐的多Agent模式
错误恢复 / 重试 / Human-in-the-Loop
Agent会失败 → 必须设计错误处理:
错误类型和恢复策略:
1. 工具调用失败 (API超时/返回错误)
策略: 自动重试(最多3次) → 换备用工具 → 报告错误
┌──────┐ 失败 ┌──────┐ 失败 ┌──────┐
│重试1 │ ────→ │重试2 │ ────→ │备用 │
└──────┘ └──────┘ │工具 │
└──────┘
2. LLM输出格式错误 (JSON解析失败/幻觉)
策略: 重新调用LLM → 附加格式纠正提示 → 强制结构化输出
"你上次返回的格式不正确，请严格按以下JSON schema..."
3. 逻辑死循环 (Agent反复做同样的事)
策略: 设置最大循环次数 → 超过则强制终止 → 请求人工介入
max_iterations = 10 # 超过就停止
4. 结果不可靠 (Agent不确定/信心低)
策略: Agent主动请求人工确认
"我的分析可能不准确，原因是...，是否需要人工审核？"
Human-in-the-Loop (HITL) — 金融场景必备:
┌────────┐ ┌────────┐
│ Agent │ ──分析──→ │ 人类 │ ← 审核Agent的分析
│ 自动化 │ │ 审批 │
└────────┘ └───┬────┘
│ 批准/驳回/修改
▼
┌────────────┐
│ Agent继续 │ ← 根据人类反馈调整
│ 或终止 │
└────────────┘
金融场景中HITL不是可选的——是合规要求:
→ 大额交易 → Agent建议 + 人工审批
→ 投资建议 → Agent分析 + 投顾审核
→ 风控告警 → Agent预判 + 风控员确认
→ 完全自主的金融Agent → 目前监管不允许
今日思考
思考1: Agent是2025年最被高估还是最被低估的技术？
高估论:
- 2023年AutoGPT热潮 → 实际效果很差 → "Agent幻灭期"
- 大多数"Agent产品"本质上还是带工具调用的Chatbot
- 可靠性不够: 企业不敢让Agent自主决策
- 成本问题: 一个复杂Agent任务可能花费$1-10
低估论:
- 2025年的Agent和2023年完全不同:
→ Reasoning模型让规划能力质变
→ MCP/A2A让工具生态标准化
→ Claude Code证明了Agent在编码领域的生产力
→ 错误恢复能力大幅提升
- 企业落地正在加速:
→ 客服Agent替代率达40-60%
→ 代码Agent(Claude Code/Cursor)已成为开发者标配
→ 数据分析Agent在金融/咨询领域快速渗透
我的判断:
Agent在"通用自主"上被高估 → "帮我做任何事"还太远
Agent在"专业垂直"上被低估 → 特定领域的Agent正在爆发
→ 金融PM应该关注的是:
不是"全能Agent" → 而是"某个具体场景的Agent"
如: 合规审查Agent / 客户尽调Agent / 投研分析Agent
每个Agent = 解决一个明确的业务问题
组合多个专业Agent = 逐步替代知识工作者的重复性劳动
思考2: 金融行业的Agent应该多大程度自主？
自主性光谱:
Level 0: 纯工具 (Excel/计算器)
→ 人操作，工具执行
→ 完全可控，但效率低
Level 1: 建议型Agent (当前主流)
→ Agent分析 + 给出建议 → 人做最终决定
→ 如: "建议批准此贷款，理由是..."
Level 2: 半自主Agent (正在发展)
→ 低风险操作自动执行 + 高风险操作请求审批
→ 如: 自动回复客户咨询 / 大额交易需要审批
Level 3: 监督型自主 (金融行业的合理上限)
→ Agent自主执行 + 人实时监督 + 异常时介入
→ 如: 量化交易 → 自动下单但有人工盯盘 + 风控熔断
Level 4: 完全自主 (目前不适合金融)
→ Agent自主决策，无人干预
→ 监管不允许 + 责任无法界定 + 风险不可控
金融Agent的设计原则:
1. 默认Level 1 → 可以建议，不能直接操作
2. 明确的权限边界 → 什么能做/什么不能做
3. 可审计 → 所有决策过程留痕
4. 熔断机制 → 异常时自动停止 + 通知人类
5. 渐进放权 → 从L1验证可靠后逐步升级到L2
这和传统银行的审批层级体系是一样的道理:
柜员可以批5万以下 → 主管批50万 → 行长批500万 → 总行批更高
Agent也需要类似的"权限层级"
思考3: 选框架的决策本质是什么？
初学者的常见误区:
"我应该学LangChain还是CrewAI？"
→ 这是错误的问题
正确的思考框架:
1. 先明确你的业务场景和约束
2. 再看哪个框架最匹配
3. 框架是会变的，架构思维不会变
不变的Agent架构原则:
├── Observe-Think-Act循环 → 所有框架都基于这个
├── 工具定义标准化 → JSON Schema / MCP → 跨框架通用
├── 状态管理 → 无论用什么框架都需要
├── 错误恢复 → 生产级Agent的核心
└── 可观测性 → 知道Agent在做什么、为什么这样做
金融PM视角的选型建议:
如果你是PM做技术选型评审:
→ 不要问"用什么框架"
→ 要问"Agent的可靠性如何保证？"
→ 要问"Agent的决策过程是否可审计？"
→ 要问"Agent失控时如何熔断？"
→ 要问"数据安全和隐私如何保证？"
→ 这些问题比框架选择重要100倍
框架会迭代 → LangChain已经大改3次了
但安全、可审计、可控这些需求不会变
面试表达
"请解释什么是AI Agent，和Chatbot有什么区别？"
30秒版本:
AI Agent是以LLM为大脑，配备记忆、工具和规划能力的自主系统。
和Chatbot的核心区别是：Chatbot只能回答问题，Agent能完成任务。
Agent通过Observe-Think-Act循环，自主调用工具、执行操作、
并根据结果动态调整策略。比如在金融场景中，Chatbot能告诉你什么是基金定投，
但Agent能帮你对比3个平台的费率后自动设置定投计划。
2分钟版本:
补充: ReAct模式(推理+行动交替) → 为什么比纯推理或纯工具调用更好,
Tool Use/Function Calling的技术实现(LLM生成调用意图→应用执行→结果回传),
Planning策略(简单任务用ReAct，复杂任务先规划再执行),
以及Memory系统(工作记忆/短期/长期)如何让Agent跨对话记住上下文。
追问准备:
Q: 你会选择什么Agent框架？
A: 取决于场景——生产级单Agent用Pydantic AI(类型安全/简洁),
复杂工作流用LangGraph(状态机/可视化),
多Agent协作用CrewAI(角色分工),
安全合规场景用Claude Agent SDK(内置安全护栏+MCP原生)。
不过框架选择不是最关键的决策，可靠性、可审计性和错误恢复才是。
Q: Agent在金融行业有什么落地挑战？
A: 三大挑战——一是可靠性(Agent幻觉导致错误操作，金融场景容错率极低),
二是合规(Agent决策过程必须可审计，监管要求"可解释AI"),
三是自主性边界(Agent应该做到什么程度？建议型还是自主型？)。
实际落地建议: 先从Level 1(建议型)开始，验证可靠后渐进放权，
关键操作必须Human-in-the-Loop。
Q: ReAct和Planning什么时候用哪个？
A: ReAct适合步骤少(1-5步)、不需要全局视角的任务，如查价格、搜新闻。
Planning适合步骤多(5-20步)、需要全局规划的任务，如做尽调报告、设计方案。
生产中通常组合: 简单请求直接ReAct，复杂请求先Plan-and-Execute，
执行中遇到意外则Re-plan。
学习资源
必读论文
| 论文 | 说明 |
|---|---|
| ReAct: Synergizing Reasoning and Acting (Yao et al., 2022) | ReAct开山之作，必读 |
| Toolformer (Schick et al., 2023) | LLM自学使用工具 |
| HuggingGPT (Shen et al., 2023) | LLM调度专业模型 |
| Voyager: LLM-Powered Agent (Wang et al., 2023) | Minecraft中的自主Agent |
| AutoGen: Multi-Agent Conversations (Wu et al., 2023) | 多Agent对话框架 |
| The Landscape of Emerging AI Agent Architectures (2024) | Agent架构综述 |
| A Survey on LLM-based Agents (2024) | 最全面的Agent综述 |
技术文档与博客
| 资源 | 说明 |
|---|---|
| OpenAI Function Calling Guide | 官方Tool Use文档 |
| Anthropic Tool Use Docs | Claude Tool Use文档 |
| LangGraph Documentation | LangGraph官方文档 |
| CrewAI Documentation | CrewAI官方文档 |
| Pydantic AI Documentation | Pydantic AI官方文档 |
| Lilian Weng: LLM-Powered Agents | 经典综述博客 |
| Chip Huyen: Building AI Agents | 工程实践视角 |
| Anthropic: Building Effective Agents | Anthropic官方Agent最佳实践 |
视频教程
| 资源 | 说明 |
|---|---|
| DeepLearning.AI: AI Agents in LangGraph | Andrew Ng合作课程 |
| LangChain YouTube: Agent tutorials | 官方教程 |
| AI Jason: Agent Framework比较 | 中文Agent框架对比 |
明日预告
Day 13: MCP协议与Tool生态
核心问题:
Agent需要工具 → 但每个LLM厂商的工具定义格式不同
→ OpenAI一套JSON Schema, Anthropic另一套
→ 工具开发者要为N个平台写N个适配
→ 像USB出现之前每个设备用不同的接口一样混乱
MCP (Model Context Protocol) = AI世界的USB-C
→ 统一的工具定义和通信协议
→ 一次开发，所有Agent都能用
→ 2025-2026最重要的AI基础设施标准
预习内容:
MCP的Server/Client架构
→ MCP Hub生态(GitHub/Slack/数据库/区块链等MCP Server)
→ 自定义MCP Server开发
→ MCP vs Function Calling vs API的对比
→ 安全考量: MCP如何防止Agent滥用工具
与今日关系:
Day 12 Agent框架 → 定义了Agent如何思考和行动
Day 13 MCP协议 → 定义了Agent如何发现和使用工具
→ Agent框架 + MCP = 完整的Agent系统
→ 就像操作系统(框架) + 驱动程序(MCP) = 能用各种设备的电脑
Day 12 总结: AI Agent是2025-2026年最热门的AI应用范式——它让LLM从"只能聊天"进化为"能做事"。核心架构是LLM(大脑)+Memory(记忆)+Tools(工具)+Planning(规划)，通过Observe-Think-Act循环自主完成多步任务。ReAct模式通过推理和行动的交替执行，既避免了纯推理的幻觉问题，又避免了纯工具调用的盲目性。Tool Use/Function Calling让LLM能安全地调用外部API——关键是LLM只生成调用意图，实际执行由应用代码控制。Planning策略方面，简单任务用ReAct逐步执行，复杂任务需要Plan-and-Execute加动态重规划。2025-2026框架生态百花齐放——LangGraph适合复杂工作流，CrewAI适合多Agent协作，Pydantic AI适合生产级类型安全开发，Claude Agent SDK适合安全合规场景。但框架选择不是最重要的决策——对金融行业而言，可靠性、可审计性、权限控制和Human-in-the-Loop才是Agent能否落地的关键。Agent不该追求完全自主，而应该像银行的审批层级体系一样，按风险等级渐进放权。