不止一个投资专家：多视角 Agent 如何共同检验投资假设
多 Agent 投研协作 · 第三篇｜同一份事实，不同的研究方法，以及真正有价值的分歧
想象这样一个场景：你已经持有几只基金，最近看上了一只科技 ETF，想问 AI：“再买一些，能不能让组合更分散？”
AI 很容易写出一篇看似周全的报告：行业前景不错、也有估值风险，基金有费用，投资要审慎。但你真正想知道的，是它与我已有的基金买了多少相同的东西？如果有人说这会改善分散化，谁来检查这句话到底对不对？
这也是我们给 ETF Agent 增加多种投资视角、Bull/Bear 反方研究的原因。不是为了让六位“投资大师”同时发表意见，而是为了把一个含糊的判断拆成不同的问题，让有用的专家真正参与研究，允许它们提出异议，最后由 Main Agent 负责给出一份有证据、有条件的结论。
本文专门讨论多视角 Agent 怎样选用、怎样共享事实、怎样处理冲突。复杂的 Peer Message、等待唤醒和冷恢复，在上一篇多空 Runtime 文章中展开。个人投研全链路的组织方式则留到下一篇架构展望。
一、问题不是缺少专家，而是容易漏掉关键问题
投资者问“这只基金怎么样”，通常需要产品介绍、费用、指数与风险披露。但问“该不该加入我的组合”，就要考虑新增后占比怎么变、资金从哪里来、长期计划是否会受影响。
这些问题没有一个万能指标。高增长不等于价格便宜；持有更多基金不等于底层资产更加分散；历史波动较低也不等于没有极端损失。
我们想让多视角研究为用户做三件事：找到原问题中的关键假设；用合适的方法检查同一组事实；在异议成立时修改理由，而不是把不同声音排成一张投票表。
因此，系统不该默认“每次都叫齐所有专家”。如果问题只是查某只 ETF 的管理费，一次获准的查询就可能足够。只有存在方法上的分歧、重大的不确定性或重要的反证价值时，额外的 Child Agent 才可能值得它消耗的时间与成本。
二、六种投资方法，究竟有什么不同？
我们在现有 Child 执行机制上注册了六种固定投资研究方法。名字借用对应投资理论和研究传统，但不是让 AI 冒充投资大师本人，更不是让它捏造大师当下的观点。
| 研究视角 | 它最先问什么 | 不能因此推断什么 |
|---|---|---|
| Markowitz：组合配置 | 新持仓怎样改变相关性、边际风险和风险贡献？ | 没有相同口径的收益序列，不能凭行业标签算出最优配置 |
| Taleb：尾部与脆弱性 | 极端行情、流动性受限或跨境渠道变化时会发生什么？ | 历史 VaR 不代表所有黑天鹅风险，也不能凭想象给出概率 |
| Bernstein：长期纪律 | 这次调整符合期限、现金需求和既定投资计划吗？ | 当前仓位不自动证明真实风险承受能力 |
| Bogle：成本与实现 | 目标指数、跟踪差异、重叠和持有总成本是否合理？ | 价格最便宜不一定最适合，不能忽略跟踪与交易条件 |
| Marks：价格与风险补偿 | 资产质量不错，当前价格是否补偿了所承担的风险？ | 不凭一段宏观叙事准确预测市场拐点 |
| Fama–French：因子解释 | 历史收益可能来自哪些具有可比数据的风险因子？ | 解释性回归不是选股能力、因果关系或未来 Alpha 预测 |
比如研究“新增科技 ETF 是否合理”，如果已有完整持仓穿透，Markowitz 可以进一步关注与原有资产的相关性；Bernstein 则可能提醒半年后要使用的现金不应被随意假定可投入；Bogle 检查用哪一只产品获得同一暴露更合适。三者不需要得出同一句话，因为它们回答的本来就不是同一个问题。
投资者得到的不是“六个人都很专业”，而是同一项决定有哪些不同的检验标准。
三、真正的独立分析，为什么要先共享事实？
让几个 Agent 分别写一篇报告并不难，困难在于：它们可能读了不同日期的资料、采用不同口径，最后得出看似矛盾的意见。
我们的取舍是：优先复用 Main 已经取得的本次获准的来源与确定性计算结果，再让不同 Child 用各自的方法解释。原本的 inputRefs 与 Result/Lineage 机制能把真实结果身份带给 Child，不需要为每位专家再建一套数据抓取或独立事实库。
更细一点，这里需要分清三件事：
- 事实：某个时点的持仓、产品披露或一个真实执行过的计算结果，有原始来源和口径。
- 假设：例如“科技基金加入后能改善分散化”，是待检验的主张。
- 观点：Markowitz 或 Taleb 基于事实和假设作出的分析，是有归属的研究判断。
如果 Main 先告诉所有专家“我认为买入会改善分散化”，再把这句话塞进它们的材料当成事实，那么所谓独立视角可能只是重复 Main 的立场。更好的做法是给它们同一份原始资料与用户约束，让每位研究者明确自己在检查什么；需要评价已有观点时，要标注它只是待核验观点。
同样，结果共享不等于共享一切权限。一个 Child 取得了受限文件，不代表另一个 Child 可以通过阅读它的摘要绕过原始数据许可。真实工具、数据与预算权限，仍由 Host 的授权和资源机制裁决。
四、用同一份组合，看看多 Agent 应该如何工作
下面只用纯合成教学数据。为了说明研究方法，假设组合原本为宽基股票基金 50%、债券 30%、现金 20%；宽基内部的科技行业权重为 30%，候选科技 ETF 的科技行业权重为 80%。我们暂且假定日期、行业分类、持仓覆盖相同且完整，债券和现金没有本例定义的股票科技行业暴露。
| 方案 | 宽基基金 | 科技 ETF | 债券 | 现金 | 科技行业暴露 |
|---|---|---|---|---|---|
| A：保持不动 | 50% | 0% | 30% | 20% | 15% |
| B：用现金买入 | 50% | 10% | 30% | 10% | 23% |
| C：从宽基换入 | 40% | 10% | 30% | 20% | 20% |
这里的确定性计算只是 各基金在组合中的权重 × 该基金的科技行业比例 后相加。它不需要调用三位“专家”各算一次。重要的是，他们如何使用同一个合格数字，回答不同的问题。
- 配置视角会注意到：方案 B 不仅把科技行业暴露从 15% 提高到 23%，也增加了股票总权重，减少了现金；但没有同口径收益数据和协方差，就不能断言整体波动率必然上升。
- 长期纪律视角会问：现金减少的 10 个百分点是不是本来就要用于近期支出？投资者没有确认之前，应将这个条件保留为未知。
- 成本实现视角会问：如果投资者的真实目标是主动增加科技暴露，候选 ETF 的指数、费用、流动性和与原基金的重叠，是否值得这次替换？没有实际费率就不能给出“更划算”的数字结论。
到这里，我们可以反驳一个具体主张：“多了一只基金，科技行业暴露就不会上升。”但并没有证明所有分散化指标都恶化，更没有据此判定该买或该卖。
这也暴露了多 Agent 投研最容易犯的错误：把三位专家讲的内容拼在一起，就称之为“综合研究”。真正的综合，是让它们围绕同一项选择解释哪些条件成立、哪些尚不能判断。
五、什么时候该让 Bull 和 Bear 真正交锋？
不同方法并不必然需要辩论。如果问题只是“持仓重叠率是多少”，取数与计算更重要。但当研究中出现影响决策的可证伪假设，独立反方会更有价值。
假设原主张 H1 是：“方案 B 不提高科技行业占比。”我们记录它的原始证伪条件：采用可比、完整的行业穿透数据，B 的科技行业占比高于 A。
一个简化的教学对话可能是：
Bull： 增加科技 ETF 可能带来目标成长资产，但我尚未核实“基金变多就更分散”的理由。
Bear： 根据这份同口径数据，B 的科技暴露从 15% 提至 23%，满足 H1 的原证伪条件。你是否应当撤回这个具体主张？
Bull： 我撤回 H1。若用户想主动加大科技配置，还要重新讨论价格、现金与整体风险；不能把这次变动描述成已验证的分散化改善。
这是一段说明交互价值的合成示例，不是实际模型运行摘录。有效变化不在于 Bear “赢了”，而在于 Bull 修改了一个明确的理由。
我们保留普通的 Main→Child 委派与 Child→Main 成果交接，同时允许经过原授权的同一对 Bull/Bear 直接发送公开质询和回应；Main 不必逐条转述。并且双方可以主动提前结束，没有任何理由为了看起来激烈而强制凑满轮数。真正的消息投递、轮次、等待和恢复机制，已经在多空 Runtime 文章单独说明。
六、Main 不是“投票裁判”，而是对用户负责的综合者
读者可能会问：既然已经有不同意见，到底听谁的？
我们的答案是：不能用票数、平均数或一个“共识分”替代投资判断。 如果一位专家说需要核对相关性，另一位提醒现金用途未确认，那么把“买 10%”和“不买”折中成“买 5%”，并没有回答任何一个关键问题。
Main 应综合三类东西：有来源的事实和已执行计算；各专家真实提出、能够归属的分析及重大分歧；仍需用户补充或仍无数据的条件。某位专家超时、取消或没有交付，Main 也不能虚构它参与投票；已有独立有效的结果仍可以交付。
一个合理的输出可能是：
已核实的变化：在本例完整合成数据下，方案 B 将科技行业权重从 15% 提高到 23%，现金从 20% 降到 10%。
原主张的修正：新增一只基金本身并未证明科技暴露得到分散；该理由应撤回。
未解决的问题：总组合波动率、真实现金用途、候选 ETF 费用和估值资料尚不足。
下一步：如果真正目标是主动提高科技暴露，再按这个目标讨论配置与成本；不自动产生交易指令。
它对用户的收益并不是“AI 看起来更自信”，而是知道哪条理由已经改变、其他条件还欠什么。至于是否提高真实决策质量，还需要独立对照验证，不能仅凭这个合成案例断言。
可选 Research Reviewer：检查研究，而不是加入投票
投资视角解决“从哪种方法看问题”，Bull/Bear 解决“谁来质疑这条假设”。我们还实现了独立的 Research Reviewer 子代理，负责检查一轮研究原始证据是否充分、是否存在明显遗漏，以及该补查还是收尾。它不是第七位投资大师，也不是 Bull/Bear 的第三位辩论者。
例如 Main 准备解释“新增科技 ETF 让组合更加分散”，Reviewer 可以在原有授权下核对真实持仓、计算结果和披露日期，而不只读 Main 的摘要：是否把行业占比当成整体波动率？是否漏掉半年后的现金需求？如有必要，它可用继承的获准工具补查，并提出 continue、pivot、finalize 或 suspend 等建议。
它复用 Child 执行、预算与恢复路径。Main 可在手动咨询开启时调用 consult_research_reviewer；Runtime 也能在配置和事实候选满足条件时自动准入检查。Reviewer 的建议不负责批准答案、决定投资真值或阻止 Main 合法发布；没有审阅也可以交付已有充分依据的研究。
这条路径已有限定工程验收，但真实模型自动审阅的金融质量收益与额外成本仍待独立验证。另有对已发布答案显式触发的事后金融语义审查报告，它是独立评审工具，不属于当前 Run 的 Reviewer Child，也不是强制终审。
七、技术往深处看：一套 Child，怎样装配不同方法？
我们没有为 Markowitz、Taleb、Bernstein、Bogle、Marks、Fama–French 分别开发六套 Runtime。常规 web/pdf/python 是执行专长；perspectiveId 是可选的投资方法；peer.role 是多空对抗职责；用户保存的 subagentProfileId 是另一个独立来源的角色指引。它们是可组合的维度，不是四级上下级。 自定义角色的完整使用链仍在独立验收中。
一个帮助理解的概念示意如下（字段组合不是某次真实请求的原样回执）：
{
"type": "python",
"task": "Review the marginal risk of the proposed technology allocation",
"perspectiveId": "investment-perspective/markowitz@1",
"inputRefs": ["the-current-run-authorized-calculation"]
}这个结构的关键不是 JSON，而是来源与权限：
- Host 注册的投资方法有固定 ID、版本和内容哈希。恢复旧 Child 时，不能悄悄换成一份同名但内容不同的方法。
- Main 应尽量复用真实的
inputRefs及原始出处，不把自己的暂定论点伪装为原始事实。 - 用户自定义 Profile 仅是有身份的用户方法指引；它不能变成高优先级系统指令，也不自动获得 peer 通信、资金交易、额外工具或预算。
- Child 交回有归属的发现与缺口；Main 对研究结论和最终正文负责。若一个额外视角失败，不因此否决已有合法成果。
架构关系图
flowchart TD
U[用户提出投资问题] --> M[Main 确认目标与现有证据]
M --> Q{一个研究路径已足够?}
Q -- 是 --> R[Main 直接研究与交付]
Q -- 否 --> P[按需选择投资方法与 Child]
P --> S[各 Child 读取同一组获准事实]
S --> D{存在需要检验的关键分歧?}
D -- 否 --> H[专家交回发现与缺口]
D -- 是 --> B[可选 Bull Bear 反证交流]
B --> H
H --> T[Main 结合依据与未解决条件]
T --> R
这张图是协作关系的概括，并非产品必须执行的固定 DAG。其价值在于减少无意义的转派，同时保留真正重要的观点差异。
八、工程闭环与金融效果，必须分别说清
当前六种方法已有冻结注册、原 Child 请求和恢复等限定工程证据；多空对话也有真实配对、公开消息与冷恢复等独立证据。但这些仍不代表“不同投资方法的组合让用户投资更正确”。
真实模型还可能选错专家、重复委派、将分析假设误写成事实，或者花了很长时间最后只给出更多文字。Subagent 的成本包括模型调用、等待、重复资料读取与 Main 重新综合，不一定比单 Main 便宜、快。
后续更有意义的比较是：相同投资问题、相同获准数据与口径下，单 Main 能否发现关键反证？加入某个专家是否增加新的有效发现？多空是否真的修正了原来的错误理由？研究时间和资源增长是否值得？目前这种全面金融质量对照仍是独立开放工作。
我们做多视角 Agent，并不是为了制造更多声音，而是希望每个声音都能用自己擅长的方法检查同一份可核查的事实，在必要时相互质疑，最后共同服务于投资者的实际问题。
延伸阅读
已有的Subagent 基础机制讲上下文隔离与成果交接；多空对话 Runtime讲直接通信、等待与恢复；多层 Agent 协作展望记录尚待完成的跨能力整体验收与未来如何比较。研究理由的历史管理可继续阅读Investment Thesis 与长期周报。
以上例子均为教学构造，不涉及真实个人组合或交易建议。完整代码与演进资料参见 ETF Agent，更多文章见文集，欢迎 Star。