从多个专家到一份研究：多层 Agent 协作的下一站（2026 展望）
2026 年 10 月 24 日的架构展望，不是已完工的整体效果复盘。 本文保留这一时点的目标、假设、取舍与未验收事项。等完整场景取得新的真实证据后，我们会另写对照复盘，保留这篇原始版本，而不是悄悄把当初的期待改写成“早已实现”。
问 AI：“这只半导体 ETF 值得买吗？”得到一份有行业前景、费率与风险提示的报告，今天已经不算特别难。
但换一个问题：“我已经持有几只基金，再买这只会不会买到更多相同的公司？这笔钱半年后可能要用；如果你建议买入，什么证据会让你改变判断？”事情就不一样了。
这需要的不只是阅读一份资料，而是把产品披露、组合持仓、资金约束、计算结果、相反观点和后续复核连接起来。投资者最终希望收到的，也不是六份不同专家的报告，而是一份说清楚“已经知道什么、为什么这样判断、还缺什么”的研究。
ETF Agent 已有通用 Subagent、六种投资方法、有界 Bull/Bear 对话和用户自定义角色的实现基础。我们正在探索的是下一层能力：这些东西放在一项真实研究里，能否比一个能力足够强的 Main Agent 更有帮助？
截至本文写作时，还不能把答案写成“能”。分项机制经过不同程度的工程验证，完整金融研究质量、跨能力协作和成本收益的独立验收仍有缺口。这正是本文值得作为展望留存的原因。
一、普通投资者为什么可能需要多层协作？
个人投资问题很少只有一个维度。看似简单的调仓，可能同时牵涉三种性质完全不同的工作。
第一种是确认事实。 当前组合里有哪些产品？候选 ETF 跟踪什么指数？底层持仓是什么日期？披露了全部持仓，还是只有前十大？这类工作要查来源、辨认时点与覆盖范围。
第二种是计算变化。 用现金买入与卖出旧基金换入，对现金比例、资产暴露和费用有什么不同？需要复算，而不是听一个模型说“分散化更好”。
第三种是判断理由。 这次操作究竟为了提高成长暴露，还是为了降低风险？如果两者矛盾，哪项是用户明确确认的目标？有没有证据推翻我们最初的论证？
一个 Main 加合格工具，本来也可以完成这些工作。多层协作的潜在价值在于：复杂局部工作各自深入，不把全部搜索与调试过程压回主上下文；不同分析方法复用同一组事实；重大反证能在最终综合前真正进入讨论。
注意这里说的是潜在价值，不是已经测得的速度、正确率或收益提升。
二、已经具备哪些积木，还缺哪一块？
此前三篇文章分别解释了自定义 Agent、多空直接对话、投资视角 Agent。把它们摆到同一张图上，很容易误以为这是四级上下级：Web Agent 指挥 Python Agent，Python Agent 再指挥投资大师 Agent，最后由 Bear 审判。
我们没有采用这种结构。Type 是执行侧重，Perspective 是研究方法，Role 是合法配对时的对抗职责，用户 Profile 是用户保存的个人方法指引。它们可以在规则允许的情况下绑定到某次 Child 执行中；不是每增加一种角色就新造一套执行器、数据库、预算和交易权限。
真正的缺口不在于“还差一位专家”，而在于整体的研究协作是否有价值。具体边界如下：
| 已有基础 | 能支持怎样的局部行为 | 本文不能据此宣称什么 |
|---|---|---|
| 通用 Main/Child 与 Web/PDF/Python | 任务委派、隔离上下文、局部成果交回、受原预算与授权约束 | 任意复杂研究都能顺利完成 |
| 六种受信投资方法 | 同一 Child 执行底座装配不同的金融研究方法 | 六种方法参与就一定更正确 |
| 有界 Bull/Bear 对话 | 独立 opening、真实公开消息、限轮交互与持久恢复的限定工程行为 | 模型一定发现更有效的金融反证 |
| 可选 Research Reviewer Child | 复查原文、计算与研究缺口，并提出非权威的继续、调整或收尾建议 | 已完成限定工程验收，不代表真实金融审查质量或必经终审 |
| 用户自定义 Profile | 设置、版本化记录、Run 冻结和 Child 选用已进入主干 | 账户/PG/浏览器/多空组合的完整验收已通过 |
| 投资论点与 History | 保留原假设、版本、证伪条件及可选反证关联 | 后续模型稳定理解并正确改变观点 |
Research Reviewer 与金融事后审查不是同一功能。 前者是原 Run 中的可选 Child，后者对选定的已发布答案另行生成金融语义审查报告，只有显式请求才执行。两者都不能授权交易、重写原正文或充当审批门禁。
几件事情单独可行，不等于它们串起来后已经形成一份可以供投资者使用的完整研究。这一点我们希望未来回来看时还能记得。
三、一项有用的研究，可能怎样协作？
仍以一个纯合成的 ETF 问题为例。用户想增加科技暴露，但担心自己已经持有太多相同公司的股票，而且半年后需要现金。
一个合理的设计路径可能是：Main 先澄清投资目标和资金来源；对已确认数据做穿透与计算；在确实有新增价值时选择组合风险、长期纪律或持有成本等投资视角；如果一个决定取决于某条脆弱假设，再让 Bull/Bear 直接质询；最后 Main 给出有条件的分析，保留论点版本以便未来复核。
关键是“可能”。我们不希望强制每个问题都走完六位专家、两轮辩论和完整报告生成；这是一个可按需要省略的协作方案，不是固定执行 DAG。
关键是“可能”。我们不希望强制每个问题都走完六位专家、两轮辩论和完整报告生成；这是一个可按需要省略的协作方案，不是固定执行 DAG。
flowchart TD
U[投资者提出问题] --> M[Main 确认目标与已获准资料]
M --> A{材料足以回答当前问题?}
A -- 是 --> H[Main 整理有依据的判断]
A -- 否 --> B[按需委派取证与金融计算]
B --> C{来源与计算口径可核实?}
C -- 否 --> G[保留未知并缩小结论]
C -- 是 --> D{需要独立金融研究方法?}
D -- 否 --> H
D -- 是 --> E[按需绑定合适的投资视角]
E --> F{核心假设值得反证?}
F -- 否 --> H
F -- 是 --> P[可选 Bull Bear 交叉质疑]
P --> H
G --> H
H --> Q{值得启动独立 Reviewer 吗?}
Q -- 否 --> T[关联论点证据与版本]
Q -- 是 --> V[可选 Reviewer 复查原证据与缺口]
V --> W{Main 决定再补查吗?}
W -- 是 --> B
W -- 否 --> T
T --> R[向用户发布并保留可读历史]
图中的 Reviewer 不是每次收尾前的强制审批。它只在已准入且值得额外成本时提供独立审阅意见；Main 可以采纳、补查或保留限制后交付。代码默认自动审阅为关闭，operator 模板选择 advisory 并不等于实际生产部署或质量已验收。
假设未来能够成功跑通，投资者理应看到的是类似这样的结果，而不是一场“专家表演”（以下为目标输出示例，不是实际运行记录）：
已核实：候选 ETF 的指数与持仓对应某一明确披露日期；用本次已获准的组合数据可以核对部分暴露变化。
尚未知：原组合若有基金仅披露前十大，则不能声称已得到精确总重叠比例；也不能把行业权重直接当作组合整体波动率。
已改变的理由：“多买一只基金就更分散”缺少支持，必要时需要撤回或改成更精确的主张。
需要用户确认：半年后现金需求的金额和用途；没有确认前，不替用户编造风险承受能力。
结论：说清可核对的变化、限制与下一次复核条件，不自动生成买入订单。
这份理想答案其实不复杂。但要让系统实际、稳定地产生它，比同时启动几个 Agent 难得多。
四、几处真正困难的交接，在哪里？
1. 计算交出去了，Main 拿到的究竟是什么？
“Python Child 已经计算过”不能直接变成最终正文里的某个数字。Main 至少需要知道计算输入、日期、收益或持仓口径、实际结果身份和缺失范围；数据已保存不等于 Main 实际读取了它。
我们已有 ResultRef、授权来源与计算工具的独立职责。整体协作要确认的是：下游专家接收到的确实是相应的可读原结果，而不是 Main 的一句未经核实的转述。这里不能让每位专家凭感觉自己再造一份 Portfolio 事实。
2. 反方已经发言，原论点真的改变了吗？
Bull/Bear 可以在原授权下发送公开消息，不意味着 Main 的结论已经采用了其中重要反证。系统应能指出：挑战针对哪一条原 Thesis、采用哪份证据、对方实际回应了什么、Main 最后怎样说明分歧。
一条讨论消息和“Investment Thesis 已被证伪”不是一回事。是否执行了真实评估、评估后是 Supported、Challenged、Invalidated 还是 Inconclusive，都要有原作者、日期和版本。根本未评估则不能伪装成 Inconclusive。
3. 用户已经编辑角色，旧任务应该跟着变吗？
自定义 Profile 的名称、描述和指引允许修改，但一个正在运行的任务必须知道自己采用的是哪一版方法。我们已经有 Run 冻结和版本身份的实现路径；它解决身份与恢复的工程问题，不自动证明模型按要求进行了金融分析。
用户角色也不是新的系统权限。即便指引写着“永远买入”或“可以访问一切”，Host 仍必须遵守原数据、资源、通信与交易授权。跨账户或来源不明的材料不能经由一句 Peer Message 获得更高信任级别。
4. 一位专家失败了，整项研究应该怎么办？
一个 PDF 没找到、一个 Child 超时或 Bear 没法取得足够资料，不应把此前已经合法得到的独立研究成果全部清空。Main 可以保留已完成部分、说明缺口并结束本次研究。但如果用户明确要求的核心资料完全没有获得，也不能把一份漂亮的文字包装成“完整交付”。
我们的目标是局部错误局部降级，全局完成取决于实际任务要求。这些正常与失败路径，还需要在同一完整真实问题下核验。
5. 审查发现遗漏，谁决定下一步？
Bear 检验特定 Thesis，Research Reviewer 则可以独立查阅整个研究已获得的真实原始材料与计算，发现之前各专家共同遗漏的关键事实。它不要求 Main 必须再做一次调查；finalize 也只是非权威建议。审查失败、过期或资料不足不应抹去此前合法取得的研究成果。
已实现的 off、shadow、advisory 模式也需要区分：shadow 可以执行并记录建议却不自动投递给 Main，但仍占用原 Root 预算；advisory 才可能把自动建议放进后续合法的 Main 请求。它们的真实模型效果、误报漏报和成本收益尚未通过完整验收。
五、我们为什么不新增一个万能的“专家总控”？
多 Agent 越多，越容易想再加一个 Orchestrator：专门选专家、管理消息、汇总计算、宣布赢家，甚至签发交易建议。
我们不倾向于这样解决问题。已有 Main 负责研究语义和综合；Child 生命周期拥有委派及 Peer 消息事实；原资源治理控制预算与终止；来源与结果模块保存原数据身份；正文发布和历史读取也有各自职责。
新增协作能力应优先深化已有模块之间必要的交接，而不是复制第二套消息账本、结果权威和终结裁决。
这不是说现在的组合已经足够简单。Main 仍可能重复委派、选错研究方法，或者消耗很多 Token 却没有获得新的信息。即使局部 Runtime 绿灯，也不能证明这些语义决策优于一个直接使用工具的 Main。
我们选择保留这些成本为可观察、可评估的事实，而不是引入新的全局“语义评分裁判”掩盖它们。
六、将来怎样证明这套协作值得？
最值得检验的问题其实是：一个工具足够强、上下文安排得当的 Main，是不是已经能完成同一项研究？
我们希望在相同原题、相同来源可用性和计算口径下，比较三种路径。执行中应保留真实失败、partial、费用和无法判断的项，而不是只展示最漂亮的一次。
| 研究路径 | 应验证的能力 | 额外成本与风险 |
|---|---|---|
| 单 Main + 工具 | 是否自行发现重要事实、错误假设并形成可用结论 | 长上下文、局部调试噪音、遗漏挑战 |
| Main + 按需 Child | 局部取证与计算是否更易完成，并真正被 Main 消费 | 委派成本、重复读取、交接丢失 |
| Main + 投资方法 + 可选 Bull/Bear | 是否新增实质性的反证、修正错误理由和保留分歧 | 更多模型请求、等待、错误观点互相锚定 |
对这三种研究路径，还需要分别记录 Reviewer 未启用、独立审阅已触发、Main 实际看见并使用建议 的事实。只有同题比较才能知道 Reviewer 有没有发现其他 Agent 漏掉的关键问题、是否带来新的误判和额外成本；不能把它的潜在收益直接算到 Bull/Bear 头上。
首先应判断绝对可用性：是否真的回答投资者原问题、引用来源是否适用、金融数字能否复算、关键判断是否受证据支持、缺口和用户授权是否明确。然后才比较相对价值：额外专家是否发现了单 Main 没有找到的有效问题？新增加了哪些错误？多花多少时间、Token、费用及人工复核？
在这些证据出现之前，“多 Agent 更聪明”“我们提升了准确率”“成本降低了多少”都只能是未被证实的猜想。即使未来结果显示额外协作通常不划算，那也很有价值：系统可以把更多普通问题留在 Main，只有真正复杂、确实需要独立质疑时才付出额外成本。
七、等未来完工，我们应该回来对照什么？
这篇展望值得保留，不是因为它预测未来必然成功，而是因为它在结果出现之前，已经写清楚了我们的取舍和判断标准。
未来复盘至少应回答四个问题：
- 完整交付了吗？ 同一正常 Chat 研究，从当前来源到计算、专家意见、正文、文件与新会话 History，能否实际读回？未完成和 unknown 有没有被保留？
- 观点真的互相影响了吗？ 哪条假设被有效挑战、谁实际作出修订，还是仅仅多生成了几段意见？
- 成本值得吗？ 相对单 Main，新增的时间、模型使用量、工具调用和人工复核有没有带来足够的质量收益？
- 如果不值得，能退回简单结构吗？ 关闭可选视角与多空新准入时，正常研究与既有历史是否依旧可用？
届时，应该新写一篇带同题对照和真实失败记录的复盘，链接回本文，而不是覆盖本文原始日期下的判断。这能把系统设计从“事后总能解释正确”，变成愿意被现实结果检验的工程探索。
真正的多 Agent 协作，不是让更多 Agent 同时忙碌，而是让每个参与者为同一个投资问题承担必要的工作，并把真正重要的依据、异议与未知完整带回投资者面前。
截至 2026 年 10 月 24 日，这是我们的方向与待验证假设，还不是已经完成的业务效果。
已有实践与证据边界
想先理解已实现的单项机制，可读Subagent 从隔离到专业化协作、有界多空直接对话、多视角 Agent 与投资假设检验。自定义 Agent 另有独立文章草稿，尚未计入正式文集。
目前工程事实与独立待验收范围，可分别核对 ETF Agent 的投资方法规范、多空对话验收、自定义 Profile 验证记录、Research Reviewer 限定验收，以及金融研究质量待验任务。这些来源支持分项事实，不构成整条流程完成的证明。
更多实践文章见 ETF Agent 文集，欢迎 Star。本篇为工程架构展望，不构成投资建议，也不表示已完成真实业务质量验收。