Agent / LLM App / Full-stack
2026
角色: Agent 角色设计、决策流程设计、风控机制定义、面向面板展示的产品定义
Multi-Agent Quant Research System
一个多 Agent 研究工作流，用于检查市场信号、生成带风控意识的建议，并复盘策略周期，而不是把一切压缩成单一交易结论。
影响: 展示了 Agent 拆解如何让金融决策支持更透明，把市场判断、风控审查、组合建议和周期复盘拆成可见步骤。
概览
这个项目把量化研究重新定义为可检查的决策支持流程。我没有让单个 LLM 直接给最终答案，而是引入面向市场判断、质询、复盘和下一步建议的专用 Agent，再把这些输出展示在可供人审阅的仪表板中。
问题
量化研究涉及噪声信号、不确定假设、变化的市场状态和风险约束。如果让单个 LLM 直接输出最终结论，系统容易隐藏不确定性、跳过风险质询，也让整个流程难以审计。
解决方案
我只在“能产生明显产品价值”的推理节点使用 LLM Agent，比如信号质询、可读复盘和下一步实验设计；确定性工作流逻辑则保持独立。这样系统更省成本、更可控，也更容易向非技术评审解释清楚。
架构
协调器负责管理工作流状态，将结构化上下文路由给专用 Agent，收集中间输出，并综合为研究备忘录，突出信号依据、风险点、分歧、置信度和下一步实验建议。
核心功能
- 用于执行前信号质询的 Critic Agent
- 用于周期后研究总结的 Review Agent
- 用于提出后续策略实验的 Evolution Agent
- 工作流阶段之间的结构化交接负载
- 保留冲突而不是强行共识的综合机制
- 便于人工审核和决策检查的输出格式
技术栈
- TypeScript
- LLM API
- Agent Orchestration
- Workflow State
实现细节
- 将接入 LLM 的 Agent 与确定性工作流组件分离，使系统不必在每一步都依赖 LLM。
- 为质询、复盘和策略进化分别设计角色化提示词，而不是使用单一通用金融分析提示词。
- 使用结构化中间输出，使 Agent 推理更容易比较、审计和调试。
- 在最终备忘录中保留分歧和低置信度信号，而不是强行生成一个漂亮但脆弱的答案。
- 将系统定位为研究和决策辅助工具，而不是自动交易建议工具。
挑战
- 如果角色契约和输出结构不清晰，Agent 工作流很容易制造虚假的严谨感。
- 过多 Agent 会增加延迟和成本，因此每一次 LLM 调用都必须有明确存在理由。
- 金融研究类输出需要谨慎定位，只能辅助分析，不能包装成确定性的投资建议。
收获
- Agent 系统真正有价值的地方在于提升流程透明度，而不是简单模仿人类组织架构。
- 对于研究工作流，保留分歧往往比压缩成一个自信结论更有价值。
- 好的 LLM 产品设计不仅要决定在哪里使用模型，也要决定哪里不应该使用模型。