• Part 1 · Large Language Models
• Part 2 · AI Agents

金融领域应用场景

金融工程专业应用案例

强项

• 写作、代码、数学推理、工具调用/多模态：整体强且均衡
• 适合把研究想法快速变成原型（清洗 → 特征 → 回测 → 报告）
• 复杂任务编排：分解任务、迭代改稿、生成可维护代码更稳

更适合的金融任务

• 论文/研报写作与结构化
• 研究方案设计、实证与回测代码（Python/R/SQL）
• “口头需求 → 可执行实现”的端到端落地

注意

• 最新数据/公告需要检索或你提供数据源；避免“无来源数字”

强项

• 长文档阅读/归纳/对比突出（年报、招股书、条款）
• 措辞更克制，合规意识强，风险提示更自然

更适合的金融任务

• 尽调材料提炼：风险点、关键假设、条款差异
• 会议纪要整理、研究框架梳理、“论证链”检查
• 对外文本：更稳健的表述与免责声明草拟

注意

• 工程化代码细节可能需要更多迭代；可与更偏工程模型搭配

强项

• 多模态处理：图表、PPT、图片、表格、文档汇总更顺
• 与 Google 生态工具结合时效率高（取决于你使用入口/权限）

更适合的金融任务

• 图表 + 文字 + 表格的材料汇总与讲稿生成
• 课堂/组会材料快速生成
• 截图财报图、宏观图等多模态理解场景

注意

• 同家族下“轻量/旗舰”差异大：选型要看你实际能用到哪一档

强项

• 成本友好，适合高频调用与规模化处理
• 代码/技术任务常表现突出（视具体版本）

更适合的金融任务

• 大规模文本清洗、抽取、标注流水线
• 批量生成因子/特征计算脚本、ETL 自动化
• 内部工具/Agent 的低成本部署与跑批

注意

• 高风险结论需更严格校验：交叉验证、单测、规则约束、人工复核

1. 目标与成功标准（Goal + Success Criteria）

• 原理：先讲清楚“要解决什么问题”以及“什么样算做得好”，减少跑偏与幻觉
• 示例：

 差："分析美团的财报。"

 好：
目标：为投资研究讨论准备要点（5分钟可讲完）
成功标准：给出可验证的关键数字、口径说明、同业对比与风险点；不确定处标注“需核实”
材料：我将粘贴美团2023Q4财报要点（或提供链接/摘录）

任务：作为互联网行业卖方分析师，分析美团2023年Q4业绩，重点：
1) 营收增长驱动（分业务，如到店/外卖/新业务）
2) 毛利率/经营利润率变化的原因（价格、补贴、履约成本）
3) 经营现金流与资本开支
4) 竞争格局与管理层指引
5) 与Uber同季度的关键指标对比（口径差异需说明）

输出要求：
- 先给“结论摘要”5条（每条≤25字）
- 再给“数据表”（指标/本期/同比/环比/口径说明/出处）
- 最后给“风险与待验证清单”

2. 指令清晰 + 约束（Do/Don’t + Constraints）

• 原理：用可执行动词 + 明确边界（字数、受众、格式、是否给代码、是否引用来源）
• 示例：

 差："讲讲量化投资。"

 好：
受众：金融工程大三学生（有概率统计与Python基础）
范围：只讲动量因子（不展开其他因子）
输出结构：
A. 数学定义（含符号说明）≤150字
B. 3种常见实现方法：时间序列动量/横截面动量/行业中性动量（各≤120字）
C. A股 vs 美股差异：数据频率、交易成本、做空约束、极端行情（≤180字）
D. Python片段：用pandas计算12-1动量并构造分组收益（可运行、含注释）
约束：
- 不编造历史收益结论；如需举例用“示意数据/假设”
- 术语首次出现给一句解释

3. 结构化输出 + 可追溯引用（Structure + Citations/Traceability）

• 原理：强制结构能显著提升可读性；金融内容要尽量“可追溯”（来源/口径/假设）
• 示例：

 差："比较CAPM和Fama-French三因子模型。"

 好：
请用Markdown表格对比CAPM与Fama-French三因子模型，维度包括：
- 理论假设
- 数学表达式（用LaTeX）
- 风险因子含义与构造
- 实证优缺点（避免给具体数值，除非我提供文献）
- 主要局限
- 适用场景（研究/风控/绩效归因）

附加要求：
1) 表格后给“学习提示”3条（常见误区）
2) 如果引用经典论文，请列出作者-年份-标题（不确定则标注“需核实”）

金融应用最佳实践（按厂商建议补强：示例驱动、校验、拒答边界）

1. Few-shot 示例（含标签定义 + 不确定性处理）

• 原理：先定义标签口径；允许“信息不足/需更多上下文”以降低误判

任务：将金融新闻分类为【利好 / 利空 / 中性 / 信息不足】

标签定义：
- 利好：大概率提升相关资产现金流或降低折现率
- 利空：大概率损害现金流或提高不确定性/折现率
- 中性：影响有限或已充分预期
- 信息不足：缺少主体、幅度、时间、适用范围等关键要素

示例1：
新闻："央行宣布下调存款准备金率0.5个百分点"
分类：利好
理由：流动性改善，融资成本下行（宏观层面）

示例2：
新闻："某科技公司季度营收符合预期，但利润率略有下滑"
分类：中性
理由：一好一坏且幅度未知，需看指引与成本结构

现在分类：
新闻："监管部门对多家互联网金融平台启动反垄断调查，最高或面临年收入10%的罚款"
输出格式：
- 分类：
- 影响路径（≤3条）：
- 关键信息缺口（如有）：
- 需要进一步核实的数据点：

2. 金融角色提示（加入“先提问再回答”与“合规边界”）

• 原理：厂商普遍建议：信息不足时先问澄清问题；高风险内容给风险提示并避免确定性措辞

 差："讲解期权定价。"

 好：
你是资深期权交易员，面向金融工程实习生讲解期权定价。流程：
Step 1：先问我3个澄清问题（标的类型/到期/是否分红/利率环境/用途：定价还是对冲）
Step 2：在假设明确后再输出内容：

请包含：
1) 用类比解释Black-Scholes关键假设，并说明何时失效
2) 波动率微笑的三类机制（偏度风险、跳跃、供需/仓位）
3) 二叉树定价Python简化示例（可运行，含参数注释）
4) Delta、Gamma在对冲与风险限额中的用法（给一个小例子）

约束：
- 不提供“保证盈利”的交易建议
- 所有公式符号清晰定义；关键结论附一句风险提示

3. 迭代优化（加入“自检清单/反证/可复现”）

• 原理：厂商建议用“分步迭代 + 自我校验”；尤其金融要加“可复现与证据链”

- 初始提示：
"分析比特币价格"

- 第一次优化（补时间范围与视角）：
"分析2024年比特币价格走势及主要驱动因素（宏观、链上、市场结构）"

- 最终优化（加结构 + 证据 + 约束 + 复现）：
你是量化分析师，请写一份2024年比特币技术分析备忘录。要求：

输入：
- 我将提供BTC日频价格数据（CSV）与关键事件清单（如ETF、减半时间）
- 若缺数据，请先列出你需要的字段与频率

输出结构：
1) 结论摘要（5条，每条≤20字）
2) 关键位：支撑/阻力（说明方法：斐波那契+历史高低点；给出计算步骤）
3) 趋势信号：10/50/200日均线交叉（给出发生日期与后验表现需标注“仅回溯不代表未来”）
4) 动量指标：RSI、MACD解释 + 当前读数（如无数据则给计算方式）
5) 资金流：ETF资金流（若我未提供则列“需数据源”）
6) 减半机制：用供给变化路径解释，不做确定性价格预测
7) 风险提示：流动性、监管、极端波动、尾部风险

代码要求：
- 给出可运行Python代码片段：读取CSV→计算指标→输出最近一日信号
自检清单（输出末尾）：
- 是否有无来源数字？有则标“需核实”
- 是否把相关性当因果？如有，加入反例或替代解释
- 结论是否可复现（数据/参数/窗口）？

可选加页：通用“防跑偏”提示模板（适用于金融作业/研报）

在回答前请先输出：
1) 你对任务的理解（≤3句）
2) 你将采用的步骤（列表）
3) 你需要我补充的数据/假设（如有）

在回答后请输出：
- 关键假设与口径
- 不确定点与待核实清单
- 若用于投资决策的风险提示

金融应用关键提示：

1. 金融应用硬件配置参考

2. 金融专用模型选择建议

3. 金融应用部署方式对比

1. 主流金融应用部署框架对比

2. 金融应用特性对比

3. 金融开发框架选择

部署便捷性

Ollama > FastChat > Text Gen WebUI > LangChain > vLLM

金融分析性能

vLLM > LangChain > FinNLP > FastChat > Ollama

数据集成能力

LangChain > FinNLP > vLLM > FastChat > Ollama

学习曲线

Ollama > FastChat > Text Gen WebUI > LangChain > FinNLP

金融工程应用选型建议

1. 应用场景分类

2. 金融应用决策树

个人课程项目 → Ollama
小组研究项目 → FastChat/LangChain
实验室研究 → LangChain/FinNLP
企业级应用 → vLLM + LangChain

基础市场分析 → Ollama
量化策略开发 → LangChain
财经文本分析 → FinNLP
高性能交易支持 → vLLM

3. 框架组合应用

1. 主要参数总览

2. 参数效果对比

3. 常用参数组合推荐

场景化配置

学术/专业问答:
- Temperature: 0.2
- Top_p: 0.8
- Presence_penalty: 0.1
- Max_tokens: 1000

创意写作:
- Temperature: 0.8
- Top_p: 0.95
- Frequency_penalty: 0.5
- Presence_penalty: 0.2

代码生成:
- Temperature: 0.1
- Top_k: 40
- Presence_penalty: 0.0
- Max_tokens: 2000

对话聊天:
- Temperature: 0.7
- Top_p: 0.9
- Frequency_penalty: 0.3
- Presence_penalty: 0.3

4. 高级应用技巧

5. 最佳实践建议

背景分析

金融行业人才能力新要求

大模型技术特点及金融应用价值

大模型核心局限性

金融工程应用场景详析：大学生学习场景

金融工程应用场景详析：专业人士工作场景

金融工程应用场景详析：学术研究场景

应对大模型局限的策略：幻觉问题

• 多源验证法

  • 交叉检查原则：通过多个独立来源验证模型提供的金融信息
  • 一级文献优先：直接参考原始学术论文、监管文件核实关键结论
  • 权威来源确认：使用官方金融机构网站、数据库验证数据和法规

• 批判性接收策略

  • 零信任原则：对模型提供的所有金融数据和公式持怀疑态度
  • 假设性采用：将模型输出视为假设而非结论
  • 一致性测试：通过重复和变形问题测试回答一致性

应对大模型局限的策略：时效性问题

• 信息更新机制

  • 时间标记意识：明确识别模型知识的截止日期
  • 增量信息补充：向模型提供训练截止日后的关键金融事件
  • 差异化分析：对比模型输出与最新情况的差异

• 实时数据融合

  • 工具链接合机制：结合实时金融数据API与模型使用
  • 最新数据引导：在提示中包含最新的关键数据点
  • 数据时效性标记：明确区分历史数据与最新数据

应对大模型局限的策略：数值和计算能力

• 专业工具协同

  • 计算任务分离：复杂金融计算交给专业软件(MATLAB、R、Python)
  • 结果验证机制：使用多种工具交叉验证计算结果
  • 模块化处理：将数值处理与概念分析任务分离

• 精度控制框架

  • 精度要求前置：明确指定所需的计算精度
  • 单位一致性检查：验证金融计算中的单位一致性
  • 边界条件测试：测试模型在边界条件下的计算可靠性

应对大模型局限的策略：专业深度问题

• 专业知识补充

  • 专业背景提供：向模型提供具体金融细分领域的专业背景
  • 术语精确定义：明确定义专业金融术语的使用范围
  • 最新研究引入：引入最新研究成果作为参考点

• 人机协作体系

  • 专家审核环节：建立专业人员审核模型输出的固定环节
  • 互补能力分工：明确人类专家与模型各自负责的领域
  • 决策责任明确：保持人类对关键金融决策的最终责任

最佳实践建议：大学生

• 学习增强策略

  • 概念递进学习法：先基础解释，再逐步深入复杂内容
  • 主动提问训练：培养提出高质量问题的能力
  • 知识验证习惯：交叉验证模型提供的金融知识点
  • 幻觉识别训练：学习识别模型输出中的不准确内容

• 技能构建方法

  • 代码解释先于复制：要求模型解释生成的金融算法代码
  • 项目迭代法：利用模型反馈多次优化学习项目
  • 混合资源学习：结合教材、模型指导和实践的多维度学习
  • 错误分析能力：培养识别和纠正模型错误的能力

最佳实践建议：专业人士

• 工作流优化

  • 任务分解策略：将复杂金融分析任务分解为模型可处理单元
  • 人机协作流程：明确划分人类判断与AI辅助环节
  • 专业提示词库：构建金融专业领域的高效提示词集
  • 风险控制体系：制定AI辅助决策的风险防范措施

• 专业能力提升

  • 工具互补原则：结合专业金融软件与大模型各自优势
  • 定制化使用模式：根据具体金融业务场景调整使用方式
  • 局限性映射：明确识别模型在特定金融任务中的局限

最佳实践建议：学术研究

• 研究辅助策略

  • 创意激发技术：使用模型进行研究思路头脑风暴
  • 多角度分析法：获取对研究问题的多维度解读
  • 文献整合框架：构建研究领域知识图谱
  • 幻觉防控机制：系统化检验模型生成的研究内容

• 学术伦理实践

  • 贡献明确区分：清晰区分AI与研究者贡献
  • 透明使用原则：在论文方法部分明确说明AI辅助情况
  • 人类主导决策：保持研究方向和关键判断的人类主导性
  • 研究诚信维护：确保AI辅助不影响学术诚信标准

金融工程领域AI伦理

未来展望与挑战

[规则系统] → [机器学习] → [深度学习] → [LLM] → [AI Agent]
   ↓             ↓            ↓          ↓          ↓
  固定逻辑    特征工程     端到端学习   通用理解   自主行动

Agent的核心突破：

• 从"理解"到"行动"的跨越
• 从"单次响应"到"多步规划"的转变
• 从"被动问答"到"主动探索"的进化

"Agent是LLM从'会说话'到'会做事'的关键一步" — OpenAI

关键数据点（来自案例研究）：

• FinRpt-Gen：人工评估一致性达90%
• FinAgent：Sharpe比率2.63（vs SPY 1.86）
• TSci：相对LLM基线MAE平均降低38.3%

OODA循环（Observe-Orient-Decide-Act）：

Environment ←──→ [Observe] → [Orient] → [Decide] → [Act] → Tools/APIs
     ↑                                                        ↓
     └─────────────────── Feedback Loop ──────────────────────┘

Agent的四个必要能力：

1. 观察能力：感知环境变化（工具返回、用户反馈）
2. 定向能力：根据观察更新内部状态模型
3. 决策能力：在多个可能动作中做出选择
4. 行动能力：执行决策并获得反馈

缺失任何一环，系统就退化为传统Workflow

判断标准：

• 流程图是DAG（无回路）→ Workflow
• 流程图有"若失败则..."的自循环 → Agent
• 跳转逻辑由LLM动态决定 → Agent

              自治性 (Autonomy)
                    ▲
                   /|\
                  / | \
                 /  |  \
                /   |   \
               /    |    \
              /     |     \
             /      |      \
            /       |       \
           ▼        ▼        ▼
     可控性              可观测性
   (Control)          (Observability)

核心问题：

• 给Agent多少决策权？
• 如何保证行为可追踪？
• 出错时如何干预？

核心控制机制：

### MCP控制消息结构
control_message = {
    "node_type": "alpha_generation",
    "task_id": "uuid-xxx",
    "declared_inputs": {"schema": "..."},
    "policy_flags": {...},
    "timeout": 300,  ### 秒
    "retry_budget": 3
}

安全特性：

• 心跳监控：检测Agent健康状态
• UUID审计：每个决策唯一标识，支持全链路追踪
• 数据隔离：隐藏realized returns，防止信息泄漏
• Walk-forward验证：严格分离训练/回测/实时数据

多体协作的核心优势：

设计模式选择：

• Sequential Pipeline：有明确依赖关系（TSci）
• Parallel Ensemble：需多视角分析（MoMoE）
• Hierarchical Tree：复杂问题分解（SciAgent）

┌──────────┐     ┌──────────┐     ┌────────────┐     ┌──────────┐
│ Curator  │ ──→ │ Planner  │ ──→ │ Forecaster │ ──→ │ Reporter │
│ 数据治理  │     │ 模型选择  │     │  预测执行   │     │ 报告生成  │
└──────────┘     └──────────┘     └────────────┘     └──────────┘
     ↓                ↓                 ↓                 ↓
  清洗数据        选择模型组合        执行预测        生成解释性报告
  特征工程        超参优化           集成策略        可视化输出
  可视化          验证评估

设计亮点：

• Leakage-safe：集成权重仅依赖验证集
• 可解释性：自然语言解释每个决策
• 性能提升：MAE相对LLM基线降低38.3%

核心思想： 将复杂任务分解为标准化角色和职责

Task Definition → Role Assignment → I/O Schema → Quality Gates

核心架构：

Thought → Action → Observation → Thought → ...

DeepAnalyze-8B的五动作Token实现：

创新点： 动作内化到模型Token中，无需外部编排框架

SciAgent的三层架构：

                    ┌──────────────┐
                    │ Coordinator  │  ← 元推理：域判断+难度评估+路由
                    │    Agent     │
                    └──────────────┘
                           │
           ┌───────────────┼───────────────┐
           ↓               ↓               ↓
    ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
    │Math Worker  │ │Physics Worker│ │Chem Worker │  ← 领域专家
    │  System     │ │   System    │ │   System   │
    └─────────────┘ └─────────────┘ └─────────────┘
           │               │               │
     Sub-agents      Sub-agents      Sub-agents     ← 具体执行

性能数据： IMO 2025得分36/42，超过金牌均值35.94

Denario的Idea模块实现：

┌─────────────┐         ┌─────────────┐
│  Idea Maker │ ──────→ │  Idea Hater │
│   生成创意    │         │   批判评估   │
└─────────────┘         └─────────────┘
       ↑                       │
       └───────── 改进 ────────┘

循环机制：

1. Idea Maker生成研究创意
2. Idea Hater批判可行性、科学价值
3. Idea Maker根据反馈修订
4. 重复N次迭代

应用场景： 质量控制、减少幻觉、提升一致性

MoMoE架构：

          Input Prompt
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
┌─────────┐┌─────────┐┌─────────┐
│ LLaMoE  ││ GPT-4o  ││DeepSeek │  ← 并行处理
└─────────┘└─────────┘└─────────┘
     │         │         │
     └────┬────┴────┬────┘
          ↓
    ┌───────────┐
    │Final Agent│  ← 综合决策
    │  (GPT-4o) │
    └───────────┘

性能： 金融情绪分类SOTA（Acc 75.5%, F1 76.6%）

风险： "多数错误偏置"——两个Agent同错会影响最终决策

代表：FinAgent

核心组件：

┌─────────────┐    ┌──────────────┐    ┌─────────────┐
│ MCP Gateway │───│ Agent Pool   │───│ Memory Agent│
│  (协议层)    │    │ (A2A通信)    │    │  (审计日志)  │
└─────────────┘    └──────────────┘    └─────────────┘

关键特性：

• MCP协议：标准化Agent与环境交互
• 心跳监控：检测健康状态，自动故障转移
• UUID审计：每个决策唯一标识，全链路追踪
• Walk-forward：严格数据隔离，防止泄漏

适用场景： 需要100%合规与可追溯的金融交易

代表：FinRpt-Gen

9 Agent分工架构：

Information Extraction → Domain Analysis → Prediction
         ↓                     ↓               ↓
┌─────────────────┐    ┌─────────────┐    ┌──────────┐
│ News Extraction │    │Finance Anal │    │Prediction│
│ Income Extract  │ →  │ News Anal   │ →  │  Agent   │
│ Balance Extract │    │ Status Anal │    └──────────┘
│ Cash Extraction │    │ Risk Anal   │
└─────────────────┘    └─────────────┘

性能数据：

• 生成效率：3-4分钟/报告
• 人评一致性：90%与分析师一致
• 推荐准确率：55%

代表：DeepAnalyze-8B

核心创新： 将动作训练进模型Token

### 五动作Token示例
response = model.generate(
    "分析数据集...",
    actions=["⟨Analyze⟩", "⟨Understand⟩", "⟨Code⟩", 
             "⟨Execute⟩", "⟨Answer⟩"]
)
### 模型自动在动作间切换，无需外部编排

训练方法：

1. 课程学习：单能力微调 → 多能力训练
2. 轨迹合成：推理轨迹 + 交互轨迹
3. 强化学习：GRPO + 混合奖励

性能： DataSciBench得分59.91，超过大多数专有模型

• 定位：从 raw data → signal → risk → portfolio → execution → audit 的完整交易系统
• 架构：多 agent pools（data/alpha/risk/portfolio/execution…）由 orchestrator 通过 MCP 控制；池内协作用 A2A；memory agent 记审计状态
• 机制：MCP 控制消息含 task_id/schema/timeout/retry/heartbeat；walk-forward 回测；隐藏 realized returns 等防泄漏；UUID 记录可回放
• 亮点：强治理、强可追溯、强防泄漏；数值计算与 LLM 推理分离
• 局限：可能牺牲部分收益换风控（股票实验 EW 回报高于 agentic）；BTC 评估窗口短

Raw Data → Data Agents → Alpha Agents → Risk Agents 
    ↓           ↓            ↓             ↓
  清洗对齐    信号构建     风险计算      约束检查
                                           ↓
                 ← Portfolio Agents ← Execution
                        ↓
                   组合构建      订单执行

关键洞察： Agent策略牺牲部分收益换取更严格的风险控制

数据泄漏防护机制：

### 上下文协议：严格排除敏感数据
context_protocol = {
    "exclude": [
        "raw_price_series_test_period",
        "future_timestamps_labels",
        "evaluation_window_objectives"
    ],
    "include_only": [
        "published_literature",
        "training_window_summaries"
    ]
}

UUID记忆机制：

UUID = SHA256(role || task || params || time)
### 支持：不可变性、身份匹配、安全检索、命名空间隔离

任务定义： ERR (Expert Recommendation Rationale) 生成

• 定位：研报/投顾“推荐理由（ERR）”生成与评测基准（FinRpt）
• 架构：三段式：信息抽取→综合分析→预测；9 个角色（新闻/三表抽取、财务/新闻/经营/风险分析、预测）+ Judge
• 机制：采集数据 (S=[O,F,A,N,P,M])；Judge Agent（GPT-4o）pairwise 对比+交换顺序算 Adjusted Win Rate
• 亮点：数据增强三件套（Rating Corrector / ERR Corrector / Polisher）；11 指标评测；3–4 分钟/报告
• 局限：多 API/爬虫链路；优化与评测仍含自动指标与 LLM judge 偏差风险

创新点：首个LLM驱动的通用时序预测框架

Q = {
    "statistics": {"mean", "std", "min", "max", "trend"},
    "missing_info": M,
    "outlier_info": O,
    "process_strategy": π
}

V = {
    "time_series_overview",      ### 移动平均+标准差
    "decomposition_analysis",    ### 趋势/季节/残差
    "autocorrelation_analysis"   ### ACF/PACF
}

基准测试结果（8个公开数据集）：

平均改进：相对LLM基线MAE降低38.3%

• 定位：基于本体知识图谱的科研假设/提案生成 + 新颖性评估
• 架构：Human/Planner/Assistant/GroupChatManager + Ontologist/Scientist/Critic + 多个字段扩写专用 agent
• 机制：从 KG 路径采样（含随机 waypoint）生成子图上下文；产出 7 字段 JSON（hypothesis/outcome/…）；Semantic Scholar API 评 Novelty/Feasibility（1–10）
• 亮点：把“知识图→多代理扩写→批判→文献新颖性校验”做成可复用流水线
• 局限：偏 ideation/plan，闭环验证仍依赖外部仿真/实验引擎与资源

知识图谱驱动：

• 33,159节点 + 48,753边
• 来自约1,000篇生物材料论文
• 92个社区（主题聚类）

多Agent协作流程：

Human → Planner → Ontologist → Scientist 1 → Scientist 2 → Critic
  ↓         ↓          ↓            ↓              ↓          ↓
 提问    规划步骤    定义关系     生成假设       扩展细节    批判改进

新颖性评估：

• Novelty Assistant调用Semantic Scholar API
• 检索相关文献，评估重叠度
• 输出Novelty/Feasibility评分（1-10）

Agent = Model + Tools + Instructions

┌─────────────────────────────────────┐
│           Instructions              │  ← 行为约束和目标定义
│  (系统提示、安全护栏、输出格式)       │
├─────────────────────────────────────┤
│              Tools                  │  ← 能力扩展
│  (函数调用、API集成、代码执行)       │
├─────────────────────────────────────┤
│              Model                  │  ← 推理核心
│  (GPT-4、Claude、Gemini等)          │
└─────────────────────────────────────┘

关键原则：

1. 从简单开始，逐步增加复杂性
2. 验证和升级机制不是可选的
3. 使用guardrails确保安全可靠

"Agents are suitable for complex decision-making, unstructured data, and workflows where traditional rule-based systems fall short." — OpenAI

核心建议： 优先使用简单、可组合的模式

上下文的四个维度：

┌─────────────────────────────────────────┐
│              Context Window             │
├──────────┬──────────┬──────────┬────────┤
│ System   │ Task     │ Memory   │ Tools  │
│ Prompt   │ Context  │ State    │ Info   │
│ 角色定义  │ 当前任务  │ 历史记忆  │ 工具说明│
└──────────┴──────────┴──────────┴────────┘

最佳实践：

1. 精简系统提示：只包含必要的角色和约束
2. 动态任务上下文：根据阶段调整信息量
3. 结构化记忆：压缩历史，保留关键决策
4. 清晰工具描述：明确输入输出格式

三层认知模型：

┌─────────────────────────────────────┐
│        Orchestration Layer          │  ← 规划与协调
│     (ReAct, Plan-and-Execute)       │
├─────────────────────────────────────┤
│          Memory Layer               │  ← 状态与历史
│   (Short-term, Long-term, Entity)   │
├─────────────────────────────────────┤
│          Tools Layer                │  ← 环境交互
│   (APIs, Databases, Executors)      │
└─────────────────────────────────────┘

规划策略：

• ReAct：交替思考和行动
• Plan-and-Execute：先整体规划再执行
• Self-Reflection：执行后反思改进

1. 死循环与成本爆炸

### Denario的解决方案
config = {
    "nfails": 5,      ### 最大失败次数
    "nrounds": 20,    ### 最大对话轮次
    "timeout": 3600   ### 超时秒数
}

2. 多数偏置（MoMoE的教训）

• 风险：多个Agent犯相同错误 → 最终决策被带偏
• 对策：引入外部验证器（如Semantic Scholar API）

3. 幻觉传播

• 单Agent幻觉 → 多Agent放大
• 对策：分阶段验收 + Judge Agent

FinAgent的Memory Agent设计：

class SystemState:
    def __init__(self):
        self.global_state = {}      ### 全局共享状态
        self.agent_states = {}      ### 各Agent私有状态
        self.message_queue = []     ### 消息队列
        self.checkpoint_stack = []  ### 状态快照栈
    
    def create_checkpoint(self, checkpoint_id: str):
        """创建状态检查点，支持回滚"""
        snapshot = {
            'id': checkpoint_id,
            'timestamp': time.now(),
            'global_state': deepcopy(self.global_state),
            'agent_states': deepcopy(self.agent_states)
        }
        self.checkpoint_stack.append(snapshot)

参考Denario的故障处理：

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_count = 0
        self.state = 'CLOSED'  ### CLOSED, OPEN, HALF_OPEN
    
    def call(self, func, *args):
        if self.state == 'OPEN':
            if time.now() - self.last_failure < self.timeout:
                raise CircuitBreakerOpenException()
            self.state = 'HALF_OPEN'
        
        try:
            result = func(*args)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e

三层指标设计：

告警规则示例：

- alert: AgentHighErrorRate
  expr: agent_error_rate > 0.1
  for: 5m
  labels:
    severity: critical

范式转变：

Prompt Engineering → Context Engineering → Flow Engineering
     ↓                      ↓                    ↓
   单次交互              多轮对话             多步工作流

新兴评估框架：

MLflow 3功能：

• Agent性能追踪
• 提示策略比较
• 多步工作流评估

挑战： 开放性任务评估仍依赖LLM-as-Judge

选型决策框架

                    ┌─────────────────┐
                    │ 任务容错率如何？ │
                    └────────┬────────┘
                             │
              ┌──────────────┴──────────────┐
              ↓                              ↓
        低容错（金融）                   高容错（研究）
              ↓                              ↓
     ┌────────┴────────┐          ┌─────────┴─────────┐
     │ 流程是否确定？  │          │ 需要多大自主性？  │
     └────────┬────────┘          └─────────┬─────────┘
              │                              │
        ┌─────┴─────┐                 ┌──────┴──────┐
        ↓           ↓                 ↓             ↓
     确定性      需要适应          强自主         可控自治
        ↓           ↓                 ↓             ↓
    FinRpt-Gen  FinAgent        AI Scientist    Denario

场景-框架推荐表

实践建议

给金融专业学生的建议：