feat: 增强 DecisionSignal 后验复盘并反馈到 Agent 记忆

[ZhuLinsen]

功能描述 / Feature Description

把现有 DecisionSignal 的 outcome / feedback 从“可查询统计”升级成“可学习的复盘资产”，让下一次分析、Agent 问股和策略权重能看到历史判断为什么对、为什么错。

大白话：现在系统已经能记录 AI 建议，也能事后算 hit/miss；但这些结果还没有真正变成“经验”。这个 issue 目标是让系统能说：上次为什么看错、哪类信号容易错、同类股票下次应该更保守还是更积极。

现状 / Current State

• docs/decision-signals.md 已定义 DecisionSignal 只记录建议、证据摘要、风险、观察条件、生命周期和来源，不执行下单。
• DecisionSignalOutcomeService 已支持 1d/3d/5d/10d 后验评估、outcome stats、用户 feedback，以及 action/market/phase/source/quality/holding_state breakdown。
• AgentMemory 已有开关 AGENT_MEMORY_ENABLED，能读取历史分析和 Backtest summary，并做 confidence calibration。
• BaseAgent 已能注入 memory context，并在样本足够时调整 agent opinion confidence。
• 但当前 memory 更偏 AnalysisHistory + BacktestResult，没有充分消费 DecisionSignal outcome / feedback，也没有沉淀“失败原因”和“同类条件下的校准建议”。
• 相关但不同的 issue：feat: 新增按决策风格聚合的后验校准统计 #1758 聚焦按 decision_profile 做聚合后验统计；本 issue 聚焦把后验结果反馈到分析/Agent 决策闭环。

使用场景 / Use Case

1. 用户查看某只股票时，系统能提示：“最近同类 buy 信号 5d 表现偏弱，本次应降低置信度”。
2. Agent 问股时，不只看到历史报告，还能看到历史信号 outcome 和用户反馈。
3. DecisionAgent 最终合成时可以引用低敏复盘摘要，而不是重复犯同类错误。
4. Skill / strategy 权重能基于真实 tagged outcome 慢慢校准，样本不足时保持中性。
5. Web AI 建议页可以展示“复盘摘要”：命中、错判、unable 原因、常见失败模式。

期望实现 / Proposed Solution

P0：定义 ReviewMemory 低敏契约

建议新增一个面向 Agent/分析消费的低敏结构，例如：

{
  "stock_code": "600519",
  "scope": "stock|market|action|factor|skill",
  "sample_size": 42,
  "completed": 31,
  "hit_rate_pct": 58.1,
  "avg_return_pct": 1.7,
  "common_miss_reasons": ["追高后回撤", "大盘退潮", "数据质量偏低"],
  "confidence_adjustment": "neutral|downgrade|upgrade",
  "notes": ["样本不足，仅供观察"]
}

要求：

• 只使用低敏字段。
• 不输出完整 evidence、metadata、raw diagnostics、Prompt、新闻正文或私密持仓。
• 有样本阈值，样本不足时只做观察提示，不改变结论。

P1：Outcome + Feedback 进入 AgentMemory

• AgentMemory.get_stock_history() 可以合并最近 DecisionSignal outcome：action、horizon、outcome、return、unable_reason、feedback。
• 增加 AgentMemory.get_decision_signal_review(...) 或类似服务，支持按股票、action、market_phase、source_agent、data_quality_level 查询低敏统计。
• BaseAgent._build_memory_context() 注入更有用的复盘摘要，而不是只注入历史 signal/score/price。

P2：复盘结果影响置信度，但必须保守

• 若样本充足，允许对 agent confidence 做小幅校准。
• 样本不足、unable rate 高、数据质量差时，只提示风险，不做强校准。
• 校准要可解释：输出 raw_confidence、adjustment_reason、sample_size、calibration_source。
• 不允许把 hit_rate 直接当仓位比例或买卖强度。

P3：Web 和 API 可见复盘摘要

• DecisionSignal 详情页可展示该信号的 outcome、feedback 和同类信号摘要。
• 可提供只读 review summary API，避免前端自己拼复杂统计。
• 支持从某个历史报告 / signal deep link 查看“这条建议后来怎么样”。

P4：和因子库 / multi-agent 增强联动

• 如果 feat: 建立 DSA 内部因子库与候选池评估闭环 #1902 因子库落地，复盘摘要可以按因子标签拆分。
• 如果 multi-agent 分歧归因落地，复盘摘要可以按 agent/source_agent/skill_consensus 拆分。
• 在这些字段不存在时必须 fail-open，不影响现有 outcome 计算。

非目标 / Non-goals

• 不改变 DecisionSignal “不下单、不调仓”的边界。
• 不做实盘交易、自动止盈止损或 copy trading。
• 不在样本不足时给“这个策略有效/无效”的强结论。
• 不把用户 feedback 当作真实收益结果；feedback 只能作为主观可用性信号。
• 不把后验统计做成黑箱自动改 Prompt；所有校准都要有可见理由和回滚路径。

验收标准 / Acceptance Criteria

• 有 ReviewMemory 或同等低敏复盘摘要契约，字段来源和脱敏边界清晰。
• AgentMemory 能读取 DecisionSignal outcome / feedback，并在开启 AGENT_MEMORY_ENABLED=true 时注入低敏摘要。
• 样本不足、unable rate 高、数据质量差时不做强校准，只提示限制。
• 置信度校准可解释，包含样本量、来源、调整方向和原因。
• DecisionSignal Web/API 至少能展示单条信号 outcome + 同类复盘摘要的 MVP。
• 原有 POST /api/v1/decision-signals/outcomes/run、feedback、stats 行为保持兼容。

建议影响路径 / Suggested Affected Areas

• src/services/decision_signal_outcome_service.py
• src/repositories/decision_signal_outcome_repo.py
• src/services/decision_signal_summary.py
• src/agent/memory.py
• src/agent/agents/base_agent.py
• src/services/backtest_service.py
• api/v1/endpoints/decision_signals.py
• api/v1/schemas/decision_signals.py
• apps/dsa-web/src/pages/DecisionSignalsPage.tsx
• apps/dsa-web/src/components/decision-signals/*
• docs/decision-signals.md

验证建议 / Verification

• 后端：覆盖 outcome/feedback 为空、unable、样本不足、样本充足、按股票/action/phase 聚合等路径。
• Agent：覆盖 AGENT_MEMORY_ENABLED=false 完全无行为变化；开启后只注入低敏摘要。
• 前端：覆盖详情页复盘摘要、loading/error/empty 状态。
• 文档：更新 DecisionSignal 专题和 full-guide；如新增用户可见复盘视图，同步 changelog。

回滚方式 / Rollback

• 首版应保持只读/低敏消费，回滚可通过关闭 AGENT_MEMORY_ENABLED 或 revert 对应 PR。
• 若新增 sidecar 表或索引，PR 需说明旧 outcome/feedback 数据保留和手动清理策略。
• 回滚后现有 DecisionSignal、feedback、outcome 数据不应被删除，普通分析/告警/通知/组合风险链路继续可用。

[ZhuLinsen]

结论
可以按“只读低敏 ReviewMemory + 保守置信度校准”推进，复用现有 DecisionSignal outcome/feedback 能力，不改变下单边界。#1758 更偏 decision_profile 聚合统计，本 issue 应聚焦 AgentMemory/BaseAgent 消费复盘摘要；#1271 是 ntfy 通知渠道，和这里的实现无直接关系。

建议排查

• 先在 api/v1/schemas/decision_signals.py 或服务层定义 ReviewMemory 摘要契约，字段限定为 sample_size、completed、hit_rate_pct、avg_return_pct、common_miss_reasons、confidence_adjustment、notes 等低敏信息。
• 在 decision_signal_outcome_repo.py、decision_signal_outcome_service.py 增加按股票、action、market phase、source agent、data quality 的聚合查询；样本不足、unable rate 高或数据质量差时只返回观察提示。
• 在 memory.py 增加 get_decision_signal_review(...)，并由 base_agent.py 注入 memory context；AGENT_MEMORY_ENABLED=false 时必须保持现有行为完全不变。
• 置信度校准只做小幅 upgrade/downgrade/neutral，同时输出 raw_confidence、adjustment_reason、sample_size、calibration_source，避免把 hit rate 直接映射成买卖强度。
• API/Web MVP 可放在 decision_signals.py 和 DecisionSignalsPage.tsx、components/decision-signals/*：单条信号展示 outcome/feedback，同类摘要由后端只读接口返回；同步更新 docs/decision-signals.md、docs/CHANGELOG.md，测试覆盖空 outcome、unable、样本不足、样本充足和 AGENT_MEMORY_ENABLED 开关路径。

---

🤖 此回复由 OpenReview Bot 自动生成，仅供参考。如有疑问请 @维护者。

[kebaptx4869]

Hi, I'd like to contribute to #1903. I noticed AgentMemory only reads AnalysisHistory/BacktestResult today — DecisionSignal outcomes/feedback (hit/miss/unable_reason) are computed but never fed back into analysis.

My plan: add a read-only, low-sensitivity ReviewMemory contract (stock_code,hit_rate_pct, common_miss_reasons, confidence_adjustment), computed via a new get_stock_stats(code), and injected through BaseAgent's existing memory context.
Sample < threshold stays "observe only", no confidence change.

Would you be open to this as a P0 (contract+query) then P1 (inject) PR? Any existing plan or naming preference?

[ZhuLinsen]

Conclusion
Your plan is aligned with the intended scope for #1903. The key constraint is to keep this as a read-only, low-sensitivity feedback loop into AgentMemory and BaseAgent, without changing the existing DecisionSignal non-trading boundary or breaking current outcome/feedback APIs.

Suggested next steps

• Start by defining the MVP ReviewMemory contract in api/v1/schemas/decision_signals.py and keep it limited to low-sensitivity fields such as stock_code, scope, sample_size, completed, hit_rate_pct, avg_return_pct, common_miss_reasons, confidence_adjustment, and notes; do not expose raw evidence, prompt text, diagnostics, or holdings.
• Build the aggregation in src/services/decision_signal_outcome_service.py and src/repositories/decision_signal_outcome_repo.py, not inside the agent layer. AgentMemory should consume a pre-summarized review payload, so the outcome logic stays reusable for API/Web and the calibration rules stay consistent in one place.
• In src/agent/memory.py, merge recent DecisionSignal outcome/feedback into memory as a separate review section rather than mixing it into existing AnalysisHistory text. Then in src/agent/agents/base_agent.py, inject that section only when AGENT_MEMORY_ENABLED=true, and make calibration conservative: sample too small, unable rate high, or weak data quality should produce a caution note, not a confidence shift.
• Keep the confidence adjustment explainable and bounded. The agent-visible output should always include the raw confidence, adjustment direction, sample size, and a short reason, and the adjustment should be small enough that historical hit rate cannot act like an implicit position-sizing signal.
• For MVP API/Web, add a read-only summary endpoint in api/v1/endpoints/decision_signals.py backed by the same service summary, then surface it in apps/dsa-web/src/pages/DecisionSignalsPage.tsx. Minimum validation should cover empty outcome/feedback, unable_reason, insufficient sample, sufficient sample, and AGENT_MEMORY_ENABLED=false preserving current behavior.

---

🤖 This reply was automatically generated by OpenReview Bot and is provided for reference. Please @ a maintainer if you have questions.

[kebaptx4869]

Hi @ZhuLinsen — quick status update on #1903. Implementation is done locally per your Aug 29 blueprint, split into two PRs as proposed earlier.

P0 (opening this week): read-only DecisionSignalReviewMemory contract in api/v1/schemas/decision_signals.py (only the 9 low-sensitivity fields you listed), aggregation in decision_signal_outcome_service.py + decision_signal_outcome_repo.py (reusing _aggregate, adding a stock_codes filter to list_stats_rows), plus a read-only GET /stocks/{stock_code}/review endpoint. No agent-layer changes, no writes.

P1 (stacked on P0): AgentMemory.get_decision_signal_review() as a separate review section, injected via BaseAgent only when AGENT_MEMORY_ENABLED=true; insufficient samples / high unable rate / weak data quality → caution note only, no confidence shift.

Tests cover the 5 paths you named (empty outcome, unable_reason, insufficient/sufficient sample, flag-off unchanged): 19 new tests green, 319 existing related tests unaffected. Will link both PRs here.

[ZhuLinsen]

Conclusion
Your split is consistent with the intended implementation for #1903. P0 is a good first PR if it stays strictly read-only and low-sensitivity, and P1 should be limited to AgentMemory / BaseAgent consumption plus conservative confidence calibration behind AGENT_MEMORY_ENABLED.

Suggested next steps

• In P0, keep the contract centered in api/v1/schemas/decision_signals.py and make the aggregation path reusable from src/services/decision_signal_outcome_service.py or src/services/decision_signal_summary.py, so Web/API and Agent code do not fork review-summary logic.
• Treat feedback as a subjective usefulness signal only; do not mix it into hit_rate_pct or realized return calculations, and keep unable_reason / data-quality limits visible in the summary so low-quality samples fail open.
• In P1, inject only compact review summaries into src/agent/memory.py and src/agent/agents/base_agent.py; do not pass raw evidence, prompt text, diagnostics, or private holding details through memory context.
• Keep calibration explainable and small: include raw confidence, adjustment direction, sample size, and reason, and make sure insufficient samples or high unable rate produce a warning-style note instead of a stronger buy/sell opinion.
• Minimum regression coverage should include AGENT_MEMORY_ENABLED=false as a no-op path, empty outcome/feedback data, insufficient-sample summaries, and compatibility of existing POST /api/v1/decision-signals/outcomes/run, feedback, and stats behavior; if those pass, the two-PR rollout is reasonable.

---

🤖 This reply was automatically generated by OpenReview Bot and is provided for reference. Please @ a maintainer if you have questions.