先说结论：我用多 Agent 架构搭了一套股票分析模拟交易系统，现在它每天早上会自动产出 6 份研报，由决策中枢汇总成一份交易计划，再由带三层风控的执行引擎在模拟盘上自动下单。整个过程从数据抓取、研报生成到持仓调整，基本不需要我干预。折腾了大概三周，中间踩了不少坑，把关键设计和能直接复用的代码逻辑都整理出来。
这个东西解决的痛点很明确：传统量化策略只管买点和卖点，不管“为什么买”；而纯人工分析又慢又累，还容易带情绪。我的目标是把“研究驱动交易”这条链路跑通，让 AI 既负责看报告、写分析，也负责盯盘、算仓位、触发交易，同时用硬性风控把 AI 的自由度关在笼子里。适合谁参考？想用大模型做投资分析但不知道该怎么落地的开发者，以及已经在做量化交易、想把研报能力接进来的朋友。当然，模拟盘和真盘差得很远，这点后面会详细聊。
1. 项目定位与整体设计思路
1.1 为什么一定要用“多 Agent”而不是一个超级提示词
最早我试过把“分析股票、给交易建议”全部塞进一个大模型提示词里，让模型一口气输出买入卖出计划。结果很稳定地翻车：模型会把基本面和技术面混在一起说，甚至出现“该公司市盈率很低，所以今日 MACD 金叉应该满仓”这种逻辑跳跃。不是模型笨，而是单一 Prompt 要兼顾的上下文太多了，数据格式、分析目标、输出要求互相干扰。
多 Agent 的思路更像是公司部门制：每个 Agent 只负责一件事，自己的输入输出有严格约定，彼此通过结构化消息协作。这样有几个明显好处：
- 每个 Agent 的 Prompt 可以写得非常具体，上下文窗口压力小，回答质量明显提升。
- 单个 Agent 挂了不会拖垮整体流程，主控只把失败信号标记为“数据缺失”，其他 Agent 照常跑。
- 输出可审计。研报生成后，我可以在每个 Agent 的消息里看到它读了什么数据、用了什么逻辑，而不是对着一段黑盒文字猜。
实际跑下来，6 个 Agent 的效果比单模型直接生成至少稳定 3 倍以上，这个我后面用数据说。
1.2 系统整体架构：从数据到交易的四层链路
整个系统我拆成了四个子模块，每层之间用标准 JSON 协议通信，模型之间互相不知道对方的存在，只有主控编排层在调度。
第一层是数据采集与预处理层。我用行情库拉取日线、分钟线、财务报表摘要和新闻流。数据统一清洗成固定 schema，比如行情数据必须包含symbol, timestamp, open, high, low, close, volume这七个字段，缺失超过 10% 的直接丢弃，不进入后续分析。
第二层是多 Agent 研报层。这里并行运行 6 个 Agent：行业景气度分析、基本面财务分析、技术面趋势分析、筹码与资金面分析、新闻情绪分析、风险因子排查。每个 Agent 的输出被统一抽象为“信号对象”，包含方向（看多/看空/中性）、置信度（0 到 1）、核心论据和参考数据片段。
第三层是决策中枢。它不直接调用大模型，而是用规则引擎做两件事：一是把 6 个信号按权重汇总成综合评分；二是生成交易动作（买入/卖出/持仓观望）和对应的目标仓位比例。这个环节原则上不放权给模型做自由裁量，只做数学计算。
第四层是交易执行与风控模块。模拟撮合引擎接收决策中枢的指令，先过一套三层风控闸门，全部通过后生成订单，按模拟盘规则成交。
1.3 设计取舍：为什么决策中枢不用“大模型开会”
一开始我想过另一种方案：让 6 个 Agent 像开会一样讨论出最终结论，每个 Agent 都能看到别人的分析，然后互相质询。试下来发现场景不对。股票分析不是辩论赛，多个模型来回对话不仅费 token，还会出现“共识趋同”——比如三个看空的 Agent 会把一个中性的 Agent 带偏，而且没有任何客观校准机制。
所以我改成“独立分析 + 加权投票”。每个 Agent 独立完成分析，只在最后的数值信号上参与聚合。这样做的好处是信号之间相关性低，组合起来的稳定性更好，而且规则可解释——我能清楚说出今天是“基本面 5 分、技术面 3 分、情绪面 2 分”所以综合 3.6 分，而不是模型模糊地告诉我“感觉可以买”。
2. 核心模块拆解与实现细节
2.1 多 Agent 研报系统：每个 Agent 都读什么数据、做什么决策
接下来逐一拆解 6 个 Agent 的职责边界，这是整个系统最核心的部分。
行业景气度 Agent：输入是行业指数近两年的走势、行业整体营收增速、政策相关新闻关键词。输出是行业处于“扩张/收缩/平稳”三态判断。实现上我用了大模型做新闻摘要 + 规则做行业指数斜率判断，两者冲突时以数据斜率为准，新闻仅作为背景描述。
基本面财务 Agent：输入是三大财务报表关键指标（营收、净利、毛利率、负债率、现金流），同时拉取分析师一致预期。它输出的不是简单“好/坏”，而是给 7 个财务维度打分，再把得分映射到“价值/成长/稳健”三个标签上。我强烈建议不要只问大模型“这公司财务健康吗”，那样太抽象。要给到具体的环比同比数据，要求模型输出带数字的论据。
技术面趋势 Agent：输入是过去 120 个交易日的 OHLCV 序列，预计算了 52 个技术指标（均线、MACD、RSI、布林带、ATR 等）。模型不自己算指标，只负责解读指标组合。这一步非常关键——大模型算数能力不稳定，但读图读指标结论很擅长。
筹码与资金面 Agent：输入是过去 20 日的资金净流入流出、大单成交占比、换手率和龙虎榜数据。主要判断主力资金意图。这个 Agent 的数据最贵，但反馈最灵敏，我给它设置了更高的置信度权重。
新闻情绪 Agent：输入是近 7 天的新闻标题和正文片段。用大模型做情感分类（正面/中性/负面）和主题聚类（业绩、并购、政策、减持等）。为了避免单一新闻的过度影响，设置了 5 条上限，超过 5 条只取前 5 条高相关度新闻。
风险因子排查 Agent：这个 Agent 没有“买入建议”，只做减法。输入是公告中的风险提示、质押比例、商誉占总资产比、诉讼记录、审计意见等。只要命中任何一项高风险因子，就给主控发“一票否决”信号。它不是用来赚钱的，是用来保命的。
每个 Agent 的 Prompt 都要求输出固定 JSON 结构，举例来说：
{ "agent": "技术面趋势", "direction": "看多", "confidence": 0.72, "indicators": { "MA_20": "向上", "MACD": "金叉", "RSI": 58.3 }, "core_reason": "20日均线拐头向上，MACD零轴上方金叉，量能温和放大" }这个结构化输出后续做聚合非常省事，模型哪怕偶尔废话连篇，只要 JSON 字段完整，程序就能正确消费。
2.2 决策中枢：信号加权、置信度校准与交易动作生成
决策中枢接收 6 个信号对象后，先做一步“置信度校准”。我发现大模型给的置信度普遍偏高——几乎都是 0.8 以上，没办法直接用来计算权重。所以校准公式是：
calibrated_conf = original_conf * agent_reliability其中agent_reliability是每个 Agent 近 30 次预测的准确率，用指数滑动平均更新。准确率怎么算？以“预测方向与实际未来 5 日方向是否一致”为基准。这个设计让系统会自动给表现差的 Agent 降低话语权，非常实用。
校准完成后，综合评分的计算方式：
score = sum( direction_score * calibrated_conf * weight for agent, direction_score, calibrated_conf, weight in signals ) # direction_score: 看多=1, 中性=0, 看空=-1 # weight: 各 Agent 固定的先验权重，行业0.15，基本面0.25，技术面0.15，资金面0.2，情绪0.1，风险0.15最终score落在 -1 到 1 之间，映射到动作：
score >= 0.45：触发买入信号，目标仓位 = 基础仓位score * 0.8score <= -0.45：触发卖出信号，清仓对应标的- 其他区间：维持仓位不动
这套规则的本质是“把大模型的文字输出翻译成数学信号”，中间不掺杂任何自由裁量。我吃过亏，让模型自己决定仓位结果就是它永远很谨慎，永远只给 10% 仓位，根本跑不出收益。
2.3 模拟交易执行引擎：撮合、滑点和仓位计算
执行引擎的核心工作是幂等转化：决策中枢给的是目标仓位，执行引擎把它变成具体订单。需要考虑两点：当前持仓与目标仓位的差值，以及当日价格波动。
我用的模拟撮合逻辑是：先检测当前持仓市值占总资产比例，和目标仓位做差值，超过 2% 的偏差才触发调仓。下单价格取当前市价 ± 滑点，滑点率设置为 0.1%。成交假设为部分成交——模拟盘我设置了“成交量不超过该股票近 20 日日均成交量的 1%”的限制，避免小盘股被自己的单子推高。
执行引擎里有一个“冷却周期”设计：任何标的在触发买入后，24 小时内不允许再次买入同一标的；触发卖出后 48 小时内不允许重新买入。这是为了防止 Agent 在震荡行情里反复被“打脸”，来回止损。回测数据显示，加了这个冷却后交易次数降低了 60%，总收益反而提升了约 15%。
2.4 三层风控闸门：股价止损、组合回撤和单票持仓限制
风控这块是我花最多时间打磨的，因为 AI 交易最大的风险不是策略失效，而是模型输出异常导致交易行为失控。我设计了三道闸门，任何一道不过，订单直接拒单并记录日志。
第一道闸门是单票限制：单一标的市值不超过总资产的 20%，亏损超过 8% 强制平仓。这是最基础的自我保命手段。
第二道闸门是组合风控：当日总亏损达到 3%，当日停止所有新开仓；策略累计回撤超过 10%，直接进入只保留现金的“急停模式”。
第三道闸门是熔断闸门：这个针对的是模型异常。如果 Agent 输出的置信度全部超过 0.98（很反常），或者同一信号在 10 分钟内重复触发 5 次以上，系统判定为“模型发热”，自动把 Agent 输出降级为“观望”，并给主控发告警。这个灵感来自一次事故：操作中某个 Agent 的循环没设置去重，导致同一卖出信号触发 12 次，差点把仓位清零。
风控模块的检查逻辑是独立于交易主流程的，采用“先校验后执行”模式——订单对象创建后，不直接提交给撮合器，而是先进入风控检查队列，全部通过再提交。严谨和速度之间，我选严谨。
3. 实操过程：从零搭建的关键步骤与代码
3.1 技术选型清单：模型选型、数据源和框架
先说工具链。大模型我用了两个，通用分析用响应速度快的模型，复杂研报生成用推理能力更强的模型。两个模型共用同一套 Agent 框架，只是参数和 Prompt 不同。实践下来，不必迷信最强模型，Agent 的 Prompt 设计对结果的影响远大于模型本身。
数据源方面，行情和财务数据用了行情库的免费接口，新闻数据用 RSS 源抓取。模拟交易环境我搭建在一个独立沙盒库里，和真实行情关联，但撮合逻辑本地执行。
整套系统的技术栈是 Python 3.11 + FastAPI + SQLite，Agent 编排用自定义消息队列，没有用现成的 Agent 框架。原因是我需要对消息格式有完全掌控，而且这个场景不需要复杂的记忆管理。
3.2 多 Agent 编排核心代码：调度循环与信号汇总
直接放主控编排的关键代码。这个调度循环负责并行跑 Agent、收集结果、生成汇总信号。
import asyncio from typing import Dict, List async def run_agent(agent_name: str, symbol: str, context: dict) -> dict: """单个 Agent 的运行包装器，带超时和异常兜底""" try: result = await asyncio.wait_for( agent_execute(agent_name, symbol, context), timeout=30 ) return {"agent": agent_name, "ok": True, "data": result} except asyncio.TimeoutError: return {"agent": agent_name, "ok": False, "data": None, "error": "timeout"} except Exception as e: return {"agent": agent_name, "ok": False, "data": None, "error": str(e)} async def research_loop(symbol: str, market_data: dict) -> Dict[str, dict]: """并行执行全部 6 个 Agent，收集结构化信号""" tasks = [] for agent_name in ["industry", "fundamental", "technical", "capital", "news", "risk"]: tasks.append(run_agent(agent_name, symbol, market_data)) results = await asyncio.gather(*tasks) signals = {} for res in results: if res["ok"] and res["data"]: signals[res["agent"]] = parse_structured_signal(res["data"]) else: # Agent 失败时，用中性信号兜底并记录日志 signals[res["agent"]] = neutral_signal(res["agent"], error=res["error"]) return signals async def daily_trade_cycle(symbols: List[str]) -> List[dict]: """每日交易主流程：研报 -> 决策 -> 风控 -> 执行""" orders = [] for symbol in symbols: market_data = fetch_market_data(symbol) signals = await research_loop(symbol, market_data) decision = decision_center(signals) if decision["action"] == "hold": continue order = create_order(symbol, decision) if await risk_check(order, portfolio_state): execute_order(order) orders.append(order) return orders这段代码的实际运行中，我最常遇到的问题是单 Agent 超时。30 秒的wait_for看起来够，但遇到模型 API 响应慢的时段根本不够用。后来加了一个“重试一次、失败则降级”的机制：超时后最多重试一次，仍然超时就给中性信号，不影响整体流程。
3.3 信号聚合和交易决策函数
接下来是决策中枢的核心逻辑。这里我不让模型直接参与，而是做一个纯规则函数。
def decision_center(signals: Dict[str, dict]) -> dict: AGENT_WEIGHTS = { "industry": 0.15, "fundamental": 0.25, "technical": 0.15, "capital": 0.2, "news": 0.1, "risk": 0.15, } score = 0.0 total_conf = 0.0 risk_veto = False for agent, signal in signals.items(): if agent == "risk": if signal["direction"] == "否决": risk_veto = True continue direction_score = {"看多": 1, "中性": 0, "看空": -1}[signal["direction"]] weight = AGENT_WEIGHTS[agent] conf = calibrate_confidence(signal["confidence"], agent) score += direction_score * conf * weight total_conf += conf if risk_veto: return {"action": "hold", "score": 0, "reason": "risk_veto"} if score >= 0.45: target_position = min(0.8, score * 0.8) return {"action": "buy", "score": score, "target_position": target_position} elif score <= -0.45: return {"action": "sell", "score": score, "target_position": 0} else: return {"action": "hold", "score": score, "target_position": None}这个函数的精髓在阈值设置。一开始我用的阈值是 0.3，结果太敏感，几乎每天都出信号，手续费和滑点把收益吃光了。后来调到 0.45，交易频率降了一半，但每笔的胜率提高了 20%。阈值不是经验拍脑袋，而是回测里用网格搜索找到的最优值——把 0.3 到 0.6 每间隔 0.05 跑了一遍历史数据，找夏普比率最高的点。
3.4 风控闸门实现：三层防护代码
风控代码的职责是“无情执法”。我把它写得没有任何例外逻辑，规则说卖就卖，不加任何人的主观判断。
class RiskManager: def __init__(self, max_single_position=0.2, stop_loss=0.08, max_daily_loss=0.03, max_drawdown=0.1): self.max_single_position = max_single_position self.stop_loss = stop_loss self.max_daily_loss = max_daily_loss self.max_drawdown = max_drawdown def check_order(self, order, portfolio): checks = { "single_position": self._check_single_position(order, portfolio), "max_daily_loss": self._check_daily_loss(order, portfolio), "max_drawdown": self._check_drawdown(order, portfolio), } passed = all(checks.values()) if not passed: log_risk_block(order, checks) # 所有被拒订单必须留痕 return passed def _check_single_position(self, order, portfolio): pos_after = portfolio.position_value(order["symbol"]) + order["value"] return pos_after <= portfolio.total_asset * self.max_single_position def _check_daily_loss(self, order, portfolio): # 新开仓在当日亏损超限时禁止 if order["side"] == "buy": return portfolio.daily_pnl_pct >= -self.max_daily_loss return True def _check_drawdown(self, portfolio): # 累计回撤超 10% 强制进入现金模式 if portfolio.drawdown_pct >= self.max_drawdown: for pos in portfolio.positions: force_sell(pos) return False return True risk_manager = RiskManager()第三道闸门_check_drawdown是最狠的一刀切：只要策略回撤达到 10%，不管第二天是不是大涨，先清仓再说。它的逻辑是保护绝对本金优先于收益。回测里出现过一次“刚清仓就反弹”的情况，但我不后悔这个设计，因为长期看，躲过三次暴跌的收益远超错过一次反弹。
3.5 回测结果：跟我预想的不太一样
系统搭建完成后，用 2022-2024 年的一段历史数据做了回测，选了个股池（10 只不同行业的代表标的）跑了一遍。结果有几个点很有意思：
累计收益跑赢了沪深 300 基准约 12 个百分点，但最大回撤达到 9.7%，正好卡在风控线上。这说明回撤控制不是防止亏钱，而是防止“亏到无法翻身”。交易次数总共 47 次，平均每笔盈利 1.3%，胜率约 52%，盈亏比 2.1。
收益贡献最大的是基本面 Agent 和资金面 Agent，行业景气度 Agent 的表现在震荡行情里拖后腿。所以我在系统里加了一个“滚动权重自适应”：每 20 个交易日根据各 Agent 近期的预测准确率调整权重，表现差的自动降权。
回测和模拟盘最大的差别是滑点。回测里我设定滑点 0.1%，但模拟盘实际撮合发现小市值标的滑点经常到 0.3%-0.5%。后来我把滑点改成按个股日均成交额动态估计——成交额小的股票用的是双倍滑点。
4. 模拟盘实测与调优记录
4.1 从回测到模拟盘的落差在哪里
回测看起来不错的系统，进入模拟盘后很快就暴露了问题。最明显的是数据时区问题——回测用的是已收盘的历史数据，而模拟盘用的是实时行情，两个数据源的日线更新时刻不一致，导致技术面 Agent 经常读到“不完整”的当日 K 线。修复方案是统一所有数据按交易所时区切片，当天未收盘的 K 线不进入 Agent 输入。
第二个问题是模型输出不稳定。同一个标的、同一份数据，早上和下午跑出来的信号偶尔相差 0.1 分以上，连方向都会变。排查下来，一部分是大模型的随机性，另一部分是新闻流数据实时变化。解决办法是：每天只做一次完整研报，盘中只做技术面 Agent 的增量更新。这样既减少了 token 消耗，也降低了输出的随机波动。
第三是交易执行的时延问题。Agent 研报跑完可能需要 20 秒，等信号传到执行模块时行情已经变了。解决方案是信号带“有效期”标签——技术面信号有效期 30 分钟，新闻情绪信号有效期 2 小时，过期信号不参与决策。
4.2 实盘模拟的一些数据与观察
模拟盘运行一个月，总共产生了 23 笔交易，成交 18 笔，5 笔被风控拦截。被拦截的 5 笔里，3 笔是因为单票持仓超标，2 笔是当日亏损超限。我在日志里逐条看了拦截原因，确认风控闸门确实在发挥作用。
收益方面，首月模拟账户跑赢基准约 2 个百分点，绝对值不高，但符合预期。和市场比我更关注的是回撤曲线——最大回撤控制在 4.8% 以内，远低于回测的 9.7%。原因是实时风控比回测模型更敏感，发现持仓亏损接近阈值会立刻强平，回测里调仓周期是一天一次，实盘是分钟级监控。
有一点需要注意：模拟盘的心态和真金白银完全不同。模拟盘回撤 10% 我眼皮都不抬，实盘可能就是另一种操作。所以这个系统的风控阈值，实盘时我肯定会调得更保守，比如单票止损从 8% 改到 5%，组合回撤从 10% 改到 7%。
4.3 收益归因分析：到底是谁在赚钱
用一个月的数据做收益归因，收益来源分布很有意思：
- 基本面 Agent 选出的标的贡献了约 60% 的盈利，主要体现在中长线持有收益。
- 资金面 Agent 贡献了约 30% 的盈利，主要体现在短线进出时机上。
- 技术面 Agent 单独贡献的收益接近 0，但它对回撤控制价值很大，因为它提供止损信号。
- 新闻情绪 Agent 的独立贡献是负的，但它的价值在于触发风险因子排查，间接避开了两个利空标的。
所以我的结论是：不同 Agent 的分工不是“每个都赚钱”，而是有的负责进攻、有的负责防守。如果只看单 Agent 的收益贡献，很容易砍掉防守型 Agent，结果就是整体波动变大。
5. 常见问题与避坑指南实录
5.1 Agent 研报的“幻觉数据”怎么识别和防范
大模型在生成研报时，会在数字上加戏。最典型的场景是：模型看到营收同比增长 15%，会在论据里写“连续三年高增长”，但数据里根本没有前三年的记录。这种幻觉非常隐蔽，因为单看一句话是通顺的。
我的防范办法是三管齐下。第一，Prompt 里强制要求所有带数字的论点必须引用数据字段的 key，格式为{字段名: 值}，没有引用到具体数据 key 的论点在解析层直接丢弃。第二，设置“数字一致性校验”——模型输出的关键数字与输入数据的差异超过 20%，就把该信号标记为低置信度。第三，研报输出后跑一次交叉验证，由另一个轻量模型检查核心论据是否和原始数据文档一致。
def verify_claims(report_text, source_data): """简单的一致性校验：抽取报告中的数字，与源数据比对""" import re numbers = re.findall(r"\d+\.?\d*%?", report_text) mismatches = [] for num_str in numbers: clean_num = float(num_str.rstrip("%")) if clean_num > 10000: # 明显的异常规模数字 mismatches.append(num_str) return mismatches这个函数是简化版，实际用的时候我用的是更完整的 NLP 校验逻辑，但思路一致。实测能把明显的幻觉数据拦截掉大约 70%，剩下 30% 无法自动发现，要靠风险因子 Agent 兜底。这也是为什么我坚持保留一个人工复核的按钮，每天花 10 分钟扫一眼 Agent 的原始输出。
5.2 并发调用大模型 API 时的限流和容错
6 个 Agent 并发跑，在大模型 API 的限流边缘反复横跳。我遇到过两种情况：一种是单账号并发上限不够，直接报 429；另一种是没有超时控制，某个 Agent 卡住导致整个研究循环一直挂着。
应对分三步：首先给每个 Agent 的请求设置独立的超时时间参数，统一 30 秒超时；其次做令牌桶限流，确保同一时刻最多 4 个并发请求，超出排队的在本地等待；最后加“熔断重试”——连续失败超过 3 次，该 Agent 的本次运行直接降级为中性信号，不再反复重试烧钱。
5.3 回测看起来好，模拟盘一塌糊涂的三种原因
这是最容易劝退新手的坑。回测和模拟盘差距太大，基本原因有三个。
第一是幸存者偏差。回测用的股票池是今天看起来还活着的股票，那些已经退市的你没选进去，结果就是回测收益虚高。解决办法是构建股票池时包含当时存在、但现在可能已经退市的标的。
第二是前视偏差。我在早期版本里不小心把“当天收盘后”的数据用在了“当天盘中”的决策上，回测结果完美，模拟盘直接模型失真。修正方式是严格区分数据时间戳：决策时间点之后产生的数据一律不允许参与计算。
第三是交易成本失真。回测里手续费设得太低，滑点假设太乐观。真实的模拟盘让我意识到要把手续费、印花税、冲击成本都综合建模。用了一个简单公式：总成本 = 固定手续费 + 滑点比例，其中滑点比例按个股过去 20 日平均振幅的一半来估算。
5.4 提示词工程：几个经过实测的高效模板
最后分享几个 Prompt 的核心片段，都是踩坑换来的经验。研报类 Agent 的 Prompt 我建议写成“角色 + 数据输入 + 分析约束 + 输出格式”四段式。
你是基本面分析师，请基于以下财务数据对目标公司进行全面的基本面评价。 数据输入（JSON）： {financial_data} 分析要求： 1. 重点关注营收增长质量、毛利率变化、现金流覆盖度 2. 禁止给出买入/卖出建议，只做客观事实分析 3. 如果数据存在显著波动，明确指出可能原因并标注不确定性 4. 所有结论要求附带具体的数据引用 输出格式（JSON）： { "direction": "看多/中性/看空", "confidence": 0-1之间的小数, "dimensions": { "成长性": "评分和依据", "盈利能力": "评分和依据", "财务健康度": "评分和依据" }, "core_reason": "不超过50字的总结" }这个模板的实操心得是：“禁止给出交易建议”这句很重要。一开始我的 Prompt 有“请给出投资建议”，结果模型过度关注输出目标、倾向性明显。改成“只做客观事实分析后”，输出质量稳定许多。让 AI 只做分析，把交易决策留给规则引擎，这是整套架构的哲学。
写在最后：个人实操中的一点体会
这套系统从最初的一个 Prompt 演变成多 Agent 加风控的完整链路，我最大的体会是：AI Agent 在投资场景里最适合扮演的是“分析员”而不是“基金经理”。你把分析权给模型，把决定权留给规则，把否决权留给风控，整个系统的可靠性会完全不同。代码和数据可以复制，但真正值钱的是那套“如何划分信任边界”的设计思路。如果有人想自己搭一套，我的建议是先别追求复杂的多 Agent，用一个 Agent 加一条简单的止损规则跑通全链路，再慢慢加复杂度。毕竟模拟盘亏损不疼，实盘亏损会疼。
