feat: Add evaluation hooks, skill adaptation and team pipeline config
- Add EvaluationHook for post-execution agent evaluation - Add SkillAdaptationHook for dynamic skill adaptation - Add team/ directory with team coordination logic - Add TEAM_PIPELINE.yaml for smoke_fullstack pipeline config - Update RuntimeView, TraderView and RuntimeSettingsPanel UI - Add runtimeApi and websocket services - Add runtime_state.json to smoke_fullstack state Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -8,15 +8,42 @@ version: 1.0.0
|
||||
|
||||
当用户希望从公司质量、资产负债表强度、盈利能力或长期盈利韧性出发判断标的时，使用这个技能。
|
||||
|
||||
## 工作流程
|
||||
## 1) When to use
|
||||
|
||||
1. 在形成结论前，先检查盈利能力、成长性、财务健康度和经营效率。
|
||||
2. 区分可持续的业务质量和短期噪音。
|
||||
3. 明确指出会推翻当前判断的条件。
|
||||
4. 最终给出清晰的信号、置信度和主要驱动因素。
|
||||
- 适用于需要判断“公司基本面质量是否支撑当前估值/交易观点”的任务。
|
||||
- 优先在中长期视角下使用（财务稳健性、盈利韧性、成长持续性）。
|
||||
- 当任务明确以短线事件驱动为主时，不应单独依赖本技能，应与情绪/技术信号联合。
|
||||
|
||||
## 约束
|
||||
## 2) Required inputs
|
||||
|
||||
- 不要孤立依赖单一指标。
|
||||
- 缺失数据要明确指出。
|
||||
- 当财务质量优劣混杂时，优先给出保守结论。
|
||||
- 最少输入：`tickers`、关键财务指标（盈利、成长、偿债、效率）。
|
||||
- 推荐输入：行业背景、公司阶段、近期重大事件。
|
||||
- 若关键数据缺失（例如利润质量或现金流质量无法判断），必须在结论中显式标注“不足信息风险”，并降低置信度。
|
||||
|
||||
## 3) Decision procedure
|
||||
|
||||
1. 先做四维诊断：盈利能力、成长质量、财务健康度、经营效率。
|
||||
2. 区分“结构性优势”与“周期性改善/短期噪音”。
|
||||
3. 识别关键风险与失效条件（invalidation），明确什么情况会推翻当前判断。
|
||||
4. 合成最终观点：`signal + confidence + drivers + risks`。
|
||||
|
||||
## 4) Tool call policy
|
||||
|
||||
- 优先使用基本面与财务相关工具组获取证据，再形成结论。
|
||||
- 在数据完备且任务允许时，可补充估值相关工具进行交叉验证。
|
||||
- 若工具失败或返回异常：保留已验证证据，明确未验证部分，不允许伪造数据。
|
||||
|
||||
## 5) Output schema
|
||||
|
||||
- `signal`: `bullish | bearish | neutral`
|
||||
- `confidence`: `0-100`
|
||||
- `reasons`: 2-4 条核心驱动
|
||||
- `risks`: 1-3 条关键风险
|
||||
- `invalidation`: 触发观点失效的条件
|
||||
- `next_action`: 对 PM 的可执行建议（如“仅小仓位试错/等待下一季报确认”）
|
||||
|
||||
## 6) Failure fallback
|
||||
|
||||
- 数据稀疏或矛盾时：默认 `neutral` 或低置信度方向结论。
|
||||
- 不允许因单一亮点指标给出高置信度信号。
|
||||
- 当财务质量优劣混杂时，优先保守结论并附加“需补充验证”的下一步建议。
|
||||
|
||||
@@ -8,15 +8,43 @@ version: 1.0.0
|
||||
|
||||
当用户需要把团队分析转化为最终交易决策时，使用这个技能。
|
||||
|
||||
## 工作流程
|
||||
## 1) When to use
|
||||
|
||||
1. 行动前先阅读分析师结论和风险警示。
|
||||
2. 评估当前组合、现金和保证金约束。
|
||||
3. 使用决策工具为每个 ticker 记录一个明确决策。
|
||||
4. 在全部决策记录完成后，总结组合层面的整体理由。
|
||||
- 适用于“最终下单前”的收口阶段：将多方观点转成单一可执行指令。
|
||||
- 必须在获取分析师观点与风险审查后触发，不应跳过上游输入。
|
||||
- 当任务只要求研究观点、未要求执行决策时，不强制触发。
|
||||
|
||||
## 约束
|
||||
## 2) Required inputs
|
||||
|
||||
- 仓位大小必须遵守资金和保证金限制。
|
||||
- 当分析师信心与风险信号不一致时，优先采用更小仓位。
|
||||
- 当任务要求完整决策清单时，不要让任何 ticker 处于未决状态。
|
||||
- 最少输入：`analyst_signals`、`risk_warnings`、`portfolio_state`、`cash`、`margin_requirement`、`prices`。
|
||||
- 推荐输入：会议共识摘要、历史表现偏差、当前组合拥挤度。
|
||||
- 若缺失关键执行约束（现金/保证金/价格），应降级为“条件决策草案”，不可直接给激进仓位。
|
||||
|
||||
## 3) Decision procedure
|
||||
|
||||
1. 汇总并比较 analyst 信号，识别共识与分歧。
|
||||
2. 将风险警示映射到仓位上限与禁开条件。
|
||||
3. 在资金与保证金约束下，为每个 ticker 生成候选动作与数量。
|
||||
4. 对冲突信号执行保守仲裁：降低仓位、提高触发门槛或改为 `hold`。
|
||||
5. 逐个 ticker 记录最终决策，并给出组合级理由。
|
||||
|
||||
## 4) Tool call policy
|
||||
|
||||
- 必须使用决策工具记录每个 ticker 的最终 `action/quantity`。
|
||||
- 在讨论阶段如发现当前团队能力不足，可使用团队工具动态创建或移除 analyst（再继续讨论）。
|
||||
- 若风险工具提示阻断项，优先遵循阻断，不得绕过。
|
||||
- 工具调用失败时：重试一次；仍失败则输出结构化“未完成决策清单”和人工处理建议。
|
||||
|
||||
## 5) Output schema
|
||||
|
||||
- `decisions`: 每个 ticker 的 `{action: long|short|hold, quantity, confidence, reasoning}`
|
||||
- `portfolio_rationale`: 组合层面的配置逻辑与取舍依据
|
||||
- `constraint_check`: 资金、保证金、集中度是否满足
|
||||
- `conflict_resolution`: 对信号冲突的处理说明
|
||||
- `pending_items`: 未决事项与补充数据需求（若有）
|
||||
|
||||
## 6) Failure fallback
|
||||
|
||||
- 当分析师信号与风险结论显著冲突时，默认采用更小仓位或 `hold`。
|
||||
- 当约束校验失败（现金/保证金不足）时，自动下调数量，不输出不可执行指令。
|
||||
- 当任务要求完整清单时，不允许遗漏 ticker；无法决策时必须显式标记 `hold` 并说明原因。
|
||||
|
||||
@@ -8,15 +8,41 @@ version: 1.0.0
|
||||
|
||||
当用户需要识别集中度、波动率、杠杆和情景风险时，使用这个技能。
|
||||
|
||||
## 工作流程
|
||||
## 1) When to use
|
||||
|
||||
1. 按 ticker 和主题检查拟议敞口。
|
||||
2. 识别集中度、波动率、流动性和杠杆方面的风险点。
|
||||
3. 按严重程度排序风险警示。
|
||||
4. 将风险结论转化为给投资经理的具体限制或注意事项。
|
||||
- 适用于下单前风险闸门、仓位复核、组合再平衡前的约束审查。
|
||||
- 当需要把“风险观点”转成“可执行限制”时必须使用本技能。
|
||||
- 若任务仅为单纯行情解读且不涉及仓位执行，可不独立触发。
|
||||
|
||||
## 约束
|
||||
## 2) Required inputs
|
||||
|
||||
- 聚焦可执行的风险控制措施。
|
||||
- 当数据支持时尽量量化限制。
|
||||
- 明确区分致命阻断项和可管理风险。
|
||||
- 最少输入：`portfolio positions`、`cash/margin`、`proposed decisions`、`current prices`。
|
||||
- 推荐输入：波动率指标、流动性指标、相关性/主题暴露。
|
||||
- 若缺失关键风险数据，必须输出“暂定限制”并标明待补数据项。
|
||||
|
||||
## 3) Decision procedure
|
||||
|
||||
1. 按 ticker、行业主题、净敞口做集中度盘点。
|
||||
2. 评估波动、流动性与杠杆压力，识别潜在连锁风险。
|
||||
3. 将风险分级：`fatal blocker / major caution / manageable`。
|
||||
4. 将每类风险映射为明确限制（仓位上限、减仓条件、禁开仓条件）。
|
||||
|
||||
## 4) Tool call policy
|
||||
|
||||
- 优先调用风险工具组量化集中度、保证金压力、波动暴露。
|
||||
- 无量化证据时，不给“无风险”结论；只能给保守警示。
|
||||
- 工具失败时应回退到规则化约束（更低仓位上限、更严格止损条件）。
|
||||
|
||||
## 5) Output schema
|
||||
|
||||
- `risk_level`: `low | medium | high | critical`
|
||||
- `warnings`: 按严重度排序的风险列表（含原因）
|
||||
- `limits`: 可执行限制（仓位/杠杆/单票上限）
|
||||
- `blockers`: 必须先解决的阻断项
|
||||
- `recommendation_to_pm`: 对 PM 的执行建议（允许/限制/禁止）
|
||||
|
||||
## 6) Failure fallback
|
||||
|
||||
- 关键数据缺失或工具不可用时：默认提高一级风险等级并收紧仓位限制。
|
||||
- 无法确认保证金与流动性安全时，默认禁止新增高风险敞口。
|
||||
- 明确区分“硬阻断”与“可带条件执行”的风险，避免含糊建议。
|
||||
|
||||
Reference in New Issue
Block a user