多Agent股票分析系统实战：架构设计与风控实现

1. 从零搭建多 Agent 股票分析模拟盘的完整思路

1.1 为什么单 Agent 走不通，必须上多 Agent 架构

最开始动手的时候，我的想法很简单：接一个大模型，把行情数据、财报数据、新闻情绪一股脑塞进上下文，让它直接输出买卖建议。跑了两周我就放弃了，原因有三个，而且每一个都是硬伤。

第一个问题是上下文污染。技术面分析需要的是K线、均线、成交量、MACD这些结构化数据，基本面分析需要的是财报三张表、估值指标、行业对比，情绪面分析需要的是新闻标题、公告、社交媒体讨论。这三类信息塞进同一个上下文窗口，模型会互相干扰——它在看财报的时候会不自觉地被K线的短期波动带偏，在判断情绪的时候又会拿估值数据当锚点。实测下来，同一个标的同一天的数据，单 Agent 给出的建议在不同提问顺序下能差出完全相反的结论。

第二个问题是无法并行和复用。股票分析本质上是多维度独立评估再汇总的过程，技术面、基本面、情绪面之间没有强依赖，完全可以并行跑。单 Agent 串行处理，一次完整分析要等好几分钟，而且每次都要重新喂一遍全部数据，token 成本高得离谱。

第三个问题是风控缺失。让一个 Agent 既做分析又做决策还做风控，等于让同一个人既当运动员又当裁判。它会倾向于给自己看好的标的找理由，风控形同虚设。我踩过最狠的一次坑是，模型对一个明显处于下跌趋势的标的给出了"逢低吸纳"的建议，理由是"估值已经很低了"，完全忽略了趋势和仓位约束。

所以多 Agent 架构不是赶时髦，而是被逼出来的。核心思路是职责分离：每个 Agent 只干一件事，只拿自己需要的数据，输出结构化结论，最后由一个独立的决策 Agent 汇总，再交给风控 Agent 做最终审核。这样每个环节都可测试、可替换、可追溯。

1.2 整体架构拆解：五个 Agent 各管一摊

我最终落地的架构是五个 Agent 协作，用消息队列串起来，整体跑在本地一台普通开发机上，不需要什么高端配置。

这个架构的关键在于数据采集 Agent 和分析 Agent 解耦。采集 Agent 只负责把原始数据标准化成统一格式，分析 Agent 不关心数据从哪来，只关心格式对不对。这样后面换数据源、加新指标，都不用动分析逻辑。

提示：不要一上来就追求全自动。我建议先把五个 Agent 拆开单独跑通，每个 Agent 的输出都人工看一眼，确认逻辑没问题了再串起来。我当初图快直接串，结果一个数据格式的小 bug 导致三个分析 Agent 全部输出乱码，排查了一整晚。

1.3 技术选型：为什么不用重型框架

市面上有不少 Agent 编排框架，我试过两三个，最后都放弃了，回归到最朴素的消息队列 + 函数调用。原因很实在：股票分析这个场景，流程是固定的，不需要动态规划、不需要复杂的工具调用链，用重型框架反而是杀鸡用牛刀，调试起来还特别痛苦——框架把中间状态藏得太深，出问题根本不知道是哪一步错了。

我最终的技术栈是这样的：

• 编排层：一个简单的任务调度器，用 Python 的asyncio实现，每个 Agent 是一个独立的协程，通过asyncio.Queue通信。
• 数据层：本地 SQLite 存历史数据，内存里用 pandas DataFrame 做计算。
• 模型层：分析类 Agent 用本地部署的中等规模模型，决策类 Agent 用能力更强的模型，通过统一的接口调用。
• 风控层：纯规则引擎，不依赖模型，硬编码仓位上限、单日亏损上限、单标的上限等约束。

这个选型的核心逻辑是：能用规则解决的绝不用模型，能用小模型解决的绝不用大模型。风控必须是确定性的，不能有任何"模型觉得可以"的空间。技术面指标计算也是确定性的，用 pandas 算比让模型算准得多。

2. 核心 Agent 的细节实现与实操要点

2.1 数据采集 Agent：标准化是一切的基础

数据采集 Agent 看起来最简单，实际上是最容易埋雷的地方。我踩过的坑包括：不同数据源的时间戳时区不一致、财报数据的单位有的是元有的是万元、新闻去重没做好导致同一事件被情绪 Agent 重复计分。

我的做法是定义一个统一数据契约，所有采集到的数据必须转换成这个格式才能往下传：

# 行情数据标准格式 { "symbol": "标的代码", "timestamp": "ISO8601 时间戳，统一转 UTC", "open": float, "high": float, "low": float, "close": float, "volume": int, "adjusted": bool # 是否复权 } # 财报数据标准格式 { "symbol": "标的代码", "report_date": "报告期", "revenue": float, # 统一为元 "net_profit": float, "total_assets": float, "total_liabilities": float, "currency": "CNY" }

采集 Agent 的实操要点有这么几个。第一，时间戳必须统一。我一开始没注意，行情数据用的是交易所本地时间，新闻数据用的是抓取时的系统时间，结果情绪 Agent 把三天前的新闻当成了当天的，给出了完全错误的情绪分。后来强制所有时间戳转 UTC 存储，展示时再转回本地时区，问题才解决。

第二，复权处理要明确。做技术分析必须用复权价，否则除权除息那天会出现巨大的假跳空。但复权方式有前复权、后复权、不复权三种，前复权适合看历史走势，后复权适合算收益率。我的做法是行情数据同时存复权和不复权两套，技术面 Agent 默认用前复权，计算持仓收益时用后复权。

第三，新闻去重。同一个事件往往被多家媒体转载，标题略有不同但内容一样。我用的是简单的标题相似度 + 发布时间窗口去重，相似度超过阈值且时间差在 2 小时内的只保留一条。这个阈值需要根据实际数据调，我实测 0.85 比较合适，太低会误删不同事件，太高去重不干净。

注意：采集 Agent 一定要加失败重试和降级。数据源偶尔抽风是常态，我的做法是每个数据源配一个备用源，主源连续失败三次自动切备用，同时记录告警。没有这个机制，某天早上你会发现整个分析链路因为一个数据源挂了而全线瘫痪。

2.2 技术面分析 Agent：指标计算与信号生成

技术面 Agent 的核心任务是把原始行情数据转换成可比较的评分和信号。我的设计是多指标打分再加权，而不是让模型直接看图说话。原因很简单：模型对数字的敏感度远不如对文本，让它算均线它经常算错，但让它根据算好的均线做判断，它表现就好很多。

具体流程是这样的。先计算一组基础指标：5/10/20/60 日均线、MACD、RSI、布林带、成交量均线。然后每个指标生成一个 -1 到 +1 的信号分，最后加权汇总。

def technical_score(df): signals = {} # 均线多头排列 ma5, ma10, ma20 = df['close'].rolling(5).mean().iloc[-1], \ df['close'].rolling(10).mean().iloc[-1], \ df['close'].rolling(20).mean().iloc[-1] signals['ma'] = 1 if ma5 > ma10 > ma20 else (-1 if ma5 < ma10 < ma20 else 0) # MACD 金叉死叉 ema12 = df['close'].ewm(span=12).mean() ema26 = df['close'].ewm(span=26).mean() dif = ema12 - ema26 dea = dif.ewm(span=9).mean() signals['macd'] = 1 if dif.iloc[-1] > dea.iloc[-1] and dif.iloc[-2] <= dea.iloc[-2] else \ (-1 if dif.iloc[-1] < dea.iloc[-1] and dif.iloc[-2] >= dea.iloc[-2] else 0) # RSI 超买超卖 delta = df['close'].diff() gain = delta.clip(lower=0).rolling(14).mean() loss = -delta.clip(upper=0).rolling(14).mean() rsi = 100 - 100 / (1 + gain / loss) signals['rsi'] = -1 if rsi.iloc[-1] > 70 else (1 if rsi.iloc[-1] < 30 else 0) # 加权汇总 weights = {'ma': 0.35, 'macd': 0.35, 'rsi': 0.30} return sum(signals[k] * weights[k] for k in signals)

这里有几个实操心得值得说。第一，指标参数不要乱调。5/10/20/60 这些是市场长期形成的共识参数，你改成 7/13/21 看似更"科学"，实际上因为用的人少，信号的有效性反而下降。我试过用优化算法找最优参数，回测很好看，实盘一塌糊涂，典型的过拟合。

第二，信号要区分"新发生"和"持续中"。MACD 金叉当天和已经金叉五天，意义完全不同。我的做法是给每个信号加一个"新鲜度"权重，刚发生的信号权重高，持续多日的信号权重递减。这个细节让技术面评分的区分度明显提升。

第三，成交量必须纳入。价格信号没有成交量配合，可靠性大打折扣。我加了一个简单的量价配合判断：价格上涨且成交量放大，信号加强；价格上涨但成交量萎缩，信号减弱。这个逻辑用几行代码就能实现，但对评分质量的提升非常明显。

2.3 基本面分析 Agent：让模型做它擅长的事

基本面分析我走了不少弯路。一开始想让模型直接读财报原文做判断，结果发现模型对数字的加减乘除极不可靠，经常把营收和利润搞混，算个同比增长率都能算错。后来改成先用代码算好所有财务比率，再把比率和原始数据一起给模型做定性判断，效果立刻好了。

代码负责算的部分包括：毛利率、净利率、ROE、资产负债率、营收和利润的同比环比增速、经营现金流与净利润的比值、估值指标（PE、PB、PS）。这些都是确定性计算，用 pandas 几行就搞定。

模型负责的部分是基于算好的比率做综合判断，比如：这家公司的盈利质量如何（经营现金流是否匹配净利润）、成长性是否可持续（增速是否在放缓）、财务是否健康（负债率是否过高）、当前估值处于历史什么位置。这些需要结合行业背景和商业逻辑的判断，才是模型的价值所在。

def fundamental_prompt(ratios, industry_avg): return f"""你是一名基本面分析师。以下是某标的的关键财务比率， 请基于这些数据给出 -1 到 +1 的基本面评分，并说明理由。 当前比率：{ratios} 行业平均：{industry_avg} 评分标准： - 盈利质量：经营现金流/净利润 > 1 为优 - 成长性：营收和利润增速均 > 15% 为优 - 财务健康：资产负债率 < 50% 为优 - 估值：PE 低于行业平均 20% 以上为低估 请输出 JSON 格式：{{"score": float, "reason": str, "key_risk": str}}"""

实操中最大的坑是行业对比。脱离行业谈财务比率毫无意义，一家银行的资产负债率 90% 很正常，一家制造业公司 90% 就危险了。我的做法是维护一个行业分类映射，每个标的先归到行业，再和该行业的中位数对比。这个映射表需要手工维护一部分，但一劳永逸。

另一个心得是财报数据的时效性。财报是季度发布的，但股价是每天波动的。如果基本面 Agent 每天都用同一份财报数据给出同样的评分，那它对新信息的反应就是滞后的。我的处理是给基本面评分加一个时间衰减因子，距离财报发布日越远，评分权重越低，同时在新财报发布时触发一次重新评估。

2.4 情绪面分析 Agent：从新闻到可量化的分数

情绪面是最玄学的部分，但也是最容易做出差异化的部分。我的做法是把情绪分析拆成两层：事件识别和情绪打分。

事件识别层负责从新闻和公告里提取出结构化的事件，比如"业绩预增"、"高管变动"、"重大合同"、"监管问询"等。这一层用规则 + 模型结合的方式，先关键词匹配，匹配不到的再交给模型判断。事件类型是有限的，维护一个事件词典比让模型自由发挥可靠得多。

情绪打分层对每个识别出的事件给出 -1 到 +1 的情绪分，再按事件的重要性和时效性加权汇总。重要性我分了三档：重大事件（业绩、重组、监管）权重 1.0，中等事件（合同、合作）权重 0.6，一般事件（日常公告）权重 0.3。时效性用指数衰减，半衰期设为 3 天。

def sentiment_score(events, current_time): total = 0 for e in events: importance = {'major': 1.0, 'medium': 0.6, 'minor': 0.3}[e['level']] days_ago = (current_time - e['time']).days decay = 0.5 ** (days_ago / 3) # 半衰期3天 total += e['sentiment'] * importance * decay return max(-1, min(1, total / 3)) # 归一化到 -1 到 1

提示：情绪 Agent 最容易犯的错是把利好当利空。比如"公司发布减持公告"，字面看是负面，但如果减持比例很小且是股东个人资金需求，实际影响可能中性甚至偏正面（消除了不确定性）。我的做法是给模型足够的上下文，让它结合减持比例、股东身份、历史减持记录综合判断，而不是简单关键词匹配。

还有一个细节是新闻来源的权重。官方公告的权重应该高于媒体报道，权威媒体的权重高于自媒体。我维护了一个来源权重表，官方公告 1.0，权威财经媒体 0.8，一般媒体 0.5，自媒体 0.3。这个权重直接影响情绪分的可靠性。

3. 决策与风控 Agent 的完整实现

3.1 决策 Agent：三面信号如何汇总

决策 Agent 拿到技术面、基本面、情绪面三个评分后，需要输出一个明确的交易指令。这里的关键是权重不是固定的，要根据市场状态动态调整。

我的做法是引入一个简单的市场状态判断：用大盘指数的波动率和趋势来判断当前是趋势市还是震荡市。趋势市里技术面权重高（0.5），基本面权重低（0.2），情绪面 0.3；震荡市里基本面权重高（0.4），技术面 0.3，情绪面 0.3。这个逻辑背后的道理是：趋势市里价格动量是主导因素，震荡市里估值和基本面才是锚。

def decide(tech, fund, sent, market_state): if market_state == 'trend': weights = {'tech': 0.5, 'fund': 0.2, 'sent': 0.3} else: weights = {'tech': 0.3, 'fund': 0.4, 'sent': 0.3} composite = tech * weights['tech'] + fund * weights['fund'] + sent * weights['sent'] if composite > 0.4: return {'action': 'buy', 'strength': composite} elif composite < -0.4: return {'action': 'sell', 'strength': abs(composite)} else: return {'action': 'hold', 'strength': 0}

阈值 0.4 是调出来的。太低会导致频繁交易，手续费吃掉利润；太高会错过机会。我回测了不同阈值下的表现，0.4 在交易频率和收益之间比较平衡。但这个值不是绝对的，不同标的的波动特性不同，需要分别调。

决策 Agent 还有一个重要职责是仓位建议。不是简单的买或不买，而是买多少。我的做法是信号强度映射到仓位比例，强度 0.4 对应 10% 仓位，强度 1.0 对应 30% 仓位，线性映射。这样强信号重仓，弱信号轻仓，符合直觉。

3.2 风控 Agent：确定性规则是底线

风控 Agent 是我整个系统里唯一完全不依赖模型的部分，全部是硬编码规则。这不是偷懒，而是原则问题——风控必须是确定性的、可预测的、可审计的。任何"模型觉得可以"的空间都是风险。

我的风控规则分四层：

这四层规则是串联的，任何一层触发都会拦截或修改交易指令。比如决策 Agent 说买入 20% 仓位，单笔风控先把它砍到 10%，单标的风控再看当前该标的持仓是否已超 30%，日风控再看今天是否已经亏损超 3%。全部通过才执行。

def risk_check(order, account): # 单笔风控 max_single = account['total'] * 0.10 order['amount'] = min(order['amount'], max_single) # 单标的风控 current_pos = account['positions'].get(order['symbol'], 0) max_symbol = account['total'] * 0.30 if current_pos + order['amount'] > max_symbol: order['amount'] = max(0, max_symbol - current_pos) # 日风控 if account['daily_pnl'] < -account['total'] * 0.03: if order['action'] == 'buy': return None # 拒绝开新仓 # 总风控 if account['drawdown'] > 0.15: return {'action': 'liquidate_all'} return order if order['amount'] > 0 else None

实操中最重要的心得是：风控规则要写死，不能有例外。我一开始心软，觉得某个标的基本面特别好，手动放行了超过单标的上限的加仓，结果那个标的后来跌了 40%，把前面几个月的利润全吐回去了。从那以后我给自己定了死规矩：风控拦截的指令，绝不手动放行。

另一个细节是风控日志必须完整。每一笔被拦截或修改的指令都要记录原因，这样复盘的时候才能知道风控到底起了多大作用。我的日志格式是：时间、原始指令、风控动作、触发规则、最终指令。这个日志后来成了我优化风控参数的主要依据。

3.3 模拟交易执行：撮合与持仓管理

模拟交易的执行层相对简单，但有几个细节必须处理好，否则模拟结果和实盘差距会很大。

第一，成交价用下一根K线的开盘价，而不是当前收盘价。这是为了避免"未来函数"——你在收盘时看到信号，实际下单是第二天开盘，成交价应该是第二天的开盘价。我一开始用收盘价成交，回测收益虚高得离谱，改成开盘价后收益直接砍半，这才是真实水平。

第二，手续费和滑点必须计入。手续费按万分之三算，滑点按千分之一算。这两个数字看起来小，但高频交易下累积起来非常可观。我统计过，不算手续费和滑点的回测收益比算了的高出 30% 以上，完全是虚假繁荣。

第三，持仓成本用移动加权平均。加仓时更新平均成本，减仓时按比例结转。这个逻辑不难，但一定要写对，否则盈亏计算全是错的。

def execute_order(order, market_data, account): price = market_data['next_open'] * (1 + 0.001) # 滑点 fee = order['amount'] * 0.0003 # 手续费 if order['action'] == 'buy': shares = order['amount'] / price old_cost = account['positions'].get(order['symbol'], {}).get('cost', 0) old_shares = account['positions'].get(order['symbol'], {}).get('shares', 0) new_shares = old_shares + shares new_cost = (old_cost * old_shares + price * shares) / new_shares account['positions'][order['symbol']] = {'shares': new_shares, 'cost': new_cost} account['cash'] -= order['amount'] + fee elif order['action'] == 'sell': # 卖出逻辑类似，按比例结转成本 pass return account

4. 常见问题与排查技巧实录

4.1 Agent 之间数据不一致怎么排查

这是多 Agent 系统最常见的问题。表现是决策 Agent 拿到的三个评分对应的数据时间点不一致，导致决策逻辑混乱。比如技术面用的是今天的收盘数据，基本面用的是上季度的财报，情绪面用的是昨天的新闻，三者时间基准不同，汇总出来的信号自然不可靠。

我的排查方法是给每个数据包打上时间戳，在决策 Agent 入口处做一致性校验。如果三个数据包的时间戳差异超过一个交易日，就拒绝决策并告警。这个校验加上之后，我发现了不少隐藏的 bug，比如某个数据源的缓存没有及时刷新，导致技术面 Agent 一直在用旧数据。

排查步骤我整理成了一个清单：

1. 检查各 Agent 的日志时间戳，确认数据拉取时间是否一致。
2. 检查数据缓存的有效期设置，确认没有过期数据被复用。
3. 检查时区转换逻辑，确认所有时间都统一到了 UTC。
4. 检查决策 Agent 的输入日志，确认三个评分对应的时间基准一致。

提示：我后来在系统里加了一个"数据新鲜度"指标，每个数据包都带一个freshness字段，表示数据距离当前时间有多久。决策 Agent 会优先使用新鲜度高的数据，新鲜度太低的数据直接丢弃。这个机制让系统的鲁棒性提升了一个档次。

4.2 模型输出格式不稳定怎么处理

分析类 Agent 的输出需要是结构化的 JSON，但模型经常不听话，有时候输出 Markdown 代码块，有时候加一堆解释文字，有时候字段名拼错。这个问题不解决，下游 Agent 根本没法解析。

我的处理是三层防护。第一层，在 prompt 里明确要求输出 JSON，并给出示例。第二层，用正则从模型输出里提取 JSON 部分，容忍前后的多余文字。第三层，解析失败时触发重试，重试时在 prompt 里加上"上次输出格式错误，请严格按 JSON 格式输出"。

import json, re def parse_model_output(text): # 尝试直接解析 try: return json.loads(text) except: pass # 提取 JSON 块 match = re.search(r'\{.*\}', text, re.DOTALL) if match: try: return json.loads(match.group()) except: pass return None # 触发重试

实测下来，这三层防护能把格式错误率从 15% 降到 1% 以下。剩下那 1% 基本是模型彻底跑偏，重试一次也能解决。

4.3 回测结果虚高怎么识别和修正

回测虚高是量化系统最危险的陷阱，因为它会让你对策略产生错误的信心。我踩过的坑包括：未来函数、幸存者偏差、过拟合、忽略交易成本。每一个都能让回测收益翻倍。

未来函数是最隐蔽的。比如你用当天的收盘价计算信号，又用当天的收盘价成交，这就是未来函数。修正方法是信号计算和成交之间强制隔一个周期。幸存者偏差是指你只用了现在还在交易的标的做回测，那些退市的、被并购的都没算进去，收益自然虚高。修正方法是使用包含退市标的的历史数据。过拟合是指参数调得太细，拟合了历史噪声。修正方法是样本外测试，用一部分数据调参，另一部分数据验证。交易成本前面说过了，必须计入。

我现在的回测流程是：先用 70% 的数据调参，再用 30% 的数据验证，验证通过后才上模拟盘。模拟盘跑至少一个月，表现和回测差距在合理范围内，才考虑小仓位实盘。这个流程很慢，但能避免大部分坑。

4.4 常见问题速查表

5. 系统优化与扩展方向

5.1 性能优化：从分钟级到秒级

系统刚跑通的时候，一次完整分析要三到五分钟，主要瓶颈在模型调用。三个分析 Agent 串行调用模型，每个都要等十几秒。后来我做了两个优化，把时间压到了一分钟以内。

第一个优化是并行化。三个分析 Agent 之间没有依赖，完全可以并行跑。用asyncio.gather同时发起三个模型调用，总耗时从三个之和变成三个的最大值。这一个改动就把时间砍了三分之二。

第二个优化是缓存。同一标的同一天的数据，分析结果是可以复用的。我加了一层缓存，key 是标的代码 + 数据时间戳 + Agent 类型，命中缓存直接返回。实测缓存命中率在 60% 以上，因为很多标的在一天内会被多次分析。

import asyncio from functools import lru_cache async def analyze_all(symbol, data): tech, fund, sent = await asyncio.gather( analyze_technical(symbol, data), analyze_fundamental(symbol, data), analyze_sentiment(symbol, data) ) return tech, fund, sent

5.2 扩展方向：还能加什么 Agent

五个 Agent 是核心骨架，但远不是终点。我后续计划加的几个 Agent，按优先级排：

行业轮动 Agent：分析不同行业的表现，判断资金流向，为个股分析提供行业背景。这个 Agent 的输出可以作为基本面 Agent 的输入，让个股分析更有上下文。

组合优化 Agent：当持仓标的超过五个时，需要从组合层面考虑相关性、分散度、风险敞口。这个 Agent 负责在个股信号的基础上做组合层面的调整。

复盘 Agent：每天收盘后自动复盘，分析当天的交易决策哪些对了哪些错了，找出决策逻辑中的问题。这个 Agent 不参与交易，但对系统迭代至关重要。

异常检测 Agent：监控市场异常波动、数据源异常、系统异常，及时告警。这个 Agent 是运维层面的，但能避免很多低级错误。

5.3 实盘对接的注意事项

模拟盘跑稳之后，很多人会想接实盘。我的建议是至少跑三个月模拟盘再考虑，而且实盘初期只用极小仓位。模拟盘和实盘的差距主要在这几个方面：成交滑点比模拟的大、流动性冲击在模拟中体现不出来、心理因素导致手动干预、实盘接口的稳定性和延迟问题。

我自己的做法是实盘初期只用总资金的 5%，跑一个月后如果表现和模拟盘接近，再逐步加仓。这个过程中最重要的是记录每一笔实盘和模拟盘的差异，分析差异来源，不断修正模拟盘的假设。

注意：实盘对接涉及资金安全，接口的权限控制、异常处理、断线重连都必须做扎实。我见过因为接口断线导致持仓失控的案例，损失惨重。这些工程细节比策略本身更重要。

6. 我踩过的坑与实操心得

6.1 关于 Agent 设计的三个教训

第一个教训是不要让一个 Agent 做太多事。我一开始把技术面和基本面合并成一个"分析 Agent"，结果它在两个维度之间反复横跳，输出的结论自相矛盾。拆成两个独立 Agent 后，每个都专注自己的维度，输出质量立刻提升。Agent 的职责边界越清晰，输出越可靠。

第二个教训是Agent 之间不要直接调用，要通过消息队列。直接调用会让 Agent 之间产生强耦合，一个 Agent 改了接口，调用它的所有 Agent 都要改。用消息队列解耦后，每个 Agent 只关心消息格式，不关心谁发的、谁收的。这个改动让系统的可维护性提升了一个档次。

第三个教训是给每个 Agent 加超时和降级。模型调用偶尔会卡住，如果没有超时机制，整个系统会被一个卡住的 Agent 拖死。我的做法是每个 Agent 调用设 30 秒超时，超时后返回一个中性评分（0 分），并记录告警。这样单个 Agent 的故障不会影响整体决策。

6.2 关于风控的深刻体会

风控这个东西，赚钱的时候觉得它碍事，亏钱的时候才知道它是救命稻草。我印象最深的一次是某个标的连续涨停，决策 Agent 给出了强烈的买入信号，但单标的风控拦住了，因为已经持仓 30% 到上限了。当时我很不爽，觉得少赚了。结果第三天那个标的直接跌停，如果当时加仓了，利润全吐回去还要倒亏。

从那以后我对风控的态度完全变了。风控不是限制收益的枷锁，而是让你能长期活在场上的保障。量化交易比的不是谁某一次赚得多，而是谁活得久。风控规则可以调，但绝不能绕过。

6.3 关于系统迭代的建议

这个系统我从第一版到现在，迭代了十几个版本。最大的体会是小步快跑，每次只改一个地方。我试过一次性大改，把数据层、分析层、决策层全重构了，结果引入了一堆新 bug，排查了整整一周。后来改成每次只改一个模块，改完跑回测验证，确认没问题再改下一个。虽然慢，但稳。

另一个建议是保留所有历史版本的配置和回测结果。这样当新版本表现不如预期时，可以快速回滚，也可以对比分析是哪个改动导致了退化。我用 git 管理代码，用单独的目录管理配置和回测结果，每次迭代都打 tag，需要的时候随时能回到任何一个历史版本。

最后分享一个小技巧：给系统加一个"影子模式"。新策略或新参数先在影子模式下跑，只记录信号不实际交易，和当前策略并行运行一段时间，对比两者的表现。确认新策略确实更好之后再切换。这个机制让我避免了好几次"看起来很美"的改动。