一、背景与核心痛点
在构建复杂的 Agent（如量化投资、金融研报 Agent）时，由于业务逻辑极深，通常会积累大量的 Skills（文本指令） 和 运行脚本（Python / Tool Calls）。
大多数团队在做这类系统时，往往会埋头堆 Skills、堆 Tool Call，直到某一天 Token 爆炸、或者主 Agent 在长任务中后期开始出现幻觉------才意识到这其实是个架构层面的问题。
具体来说，主要会撞到两个痛点：
痛点 1：上下文负担 (Context Bloat)
若将所有 Skills 放入主 Agent，Token 消耗极快，且会稀释模型对核心目标的注意力。
痛点 2：逻辑耦合
复杂任务中，不同技能间的交互轨迹会互相干扰，导致主 Agent 在执行中后期出现幻觉。
二、两种解决策略
方案 1：动态生成模式 (Just-in-Time Sub-Agent)
逻辑 ：主 Agent 作为一个"工厂"，根据当前复杂需求，现场编写 SOP 并实例化一个临时的 Sub-Agent，将相关的 Skills 和工具分配给它。
优势：
- 极高的灵活性，能处理非标准化、长尾的复杂任务
- 主 Agent 只需关注结果，不参与具体执行过程
劣势：
- 稳定性较弱（依赖主 Agent 的元编程能力）
- 响应时延高
方案 2：静态预制模式 (Pre-defined Sub-Agent)
逻辑 ：将业务中确定性高、独立性强的板块（如：数据抓取、财务建模、合规审查）直接封装成固定的 Sub-Agent，主 Agent 仅作为路由进行调度。
优势：
- 可靠性高（可进行独立单元测试）
- Token 消耗紧凑且成本可控
劣势：
- 灵活性受限
- 面对全新场景需要人工介入开发
三、本质区别：绑定时间 (Binding Time)
这两个方案的核心差别可以用一句话说清楚------执行逻辑是什么时候被确定的。
| 方案 | 类型 | 归属范畴 |
|---|---|---|
| 方案 1 | 运行时绑定 | 执行逻辑在运行那一刻由模型临时合成 ------「AI 自演进」 |
| 方案 2 | 设计时绑定 | 执行逻辑是架构师预先固化的 ------「微服务化软件工程」 |
四、成本与效率的深度拆解
很多人在选方案 1 时，只看到"灵活"这一面。
但在非理想状态下，方案 1 的真实成本结构需要拆开来算清楚：
1. 元推理开销 (Meta-Reasoning)
方案 1 需要主 Agent 生成大量的"指令性文本"来教会 Sub-Agent。
这种 "写手册"的 Token 远多于方案 2 的 "下订单"指令。
2. 缓存命中率 (Prompt Caching)
- 方案 2：Sub-Agent 指令是固定的 → 可利用 API 服务商的缓存折扣（大幅降价）
- 方案 1：指令动态生成，几乎每次都是全额计费
3. 错误连锁反应
方案 1 一旦动态生成的 SOP 有误，会导致 Sub-Agent 执行失败，进而引发主 Agent 的重试推理，产生翻倍的 Token 支出。
五、决策参考模型
| 任务特征 | 推荐方案 | 理由 |
|---|---|---|
| 高度标准化、高频触发 | 方案 2（静态） | 追求极致的确定性和成本优化 |
| 高度定制化、低频、未知领域 | 方案 1（动态） | 追求泛化解决能力，不惜牺牲部分稳定性 |
| 混合大型系统 | 第三种路径：半动态检索 | 预制大量静态模块，由主 Agent 根据需求动态检索并加载（RAG for Skills） |
六、关注点回顾 (Checklist)
在做架构决策前，对照下面 3 个问题逐一确认：
- 上下文隔离：Sub-Agent 是否真正承担了长轨迹的交互，从而释放了主 Agent 的空间？
- 评估元能力：当前使用的大模型是否有足够的能力生成高质量、无歧义的 SOP？
- ROI 权衡：开发一个静态 Sub-Agent 的人工成本，是否低于长期运行动态生成方案带来的 Token 浪费？
后续思考
在金融策略等严谨场景 下，建议优先采用 "方案 2 为主，方案 1 为辅" 的混合策略。
即：用静态 Agent 解决 80% 的确定性工作流，仅在遇到无法覆盖的边际场景时，允许主 Agent 尝试"动态组装"并输出一个待审核的临时方案。