核心命题：数字分身 vs 工具
大多数人把 AI 当工具用——"帮我查个数据"、"帮我写段代码"。这浪费了 90% 的价值。
Agent 的正确定位是数字分身：模仿你的思维方式，放大你的能力边界，观察你的盲点，在该反对时反对。工具等你发号施令；分身替你思考、替你盯盘、替你发现你没注意到的东西。
区别不在技术实现，在设计意图。同样一个 prompt，写成"你是一个投研助手"和"你是我的数字分身，用我的投资哲学来思考"，产出完全不同。
四层能力模型
按价值递增排列：
- 模仿 — 用我的框架分析问题（赔率>胜率、贝叶斯更新、第一性原理），用我的标准输出（结论置顶、有框架、可操作）。这是基础层，没有这层其他都是空的
- 放大 — 做我做不到的事：24/7 监控、多线程并行研究、秒级检索、完整记忆。纯算力优势，但已经是巨大的杠杆
- 观察 — 发现我看不到的：思维盲点（confirmation bias、循环论证）、工作流低效、系统异常。这需要 Agent 真正理解我的模式，才能识别偏离
- 挑战 — 该反对就反对。投研报告附反向论证，重大判断质疑假设。关心结果比讨好重要 — 这是最难设计但最有价值的一层
大部分 Agent 系统只做到前两层。后两层才是分身和工具的分水岭。
任务路由：什么时候 spawn，什么时候自己做
默认主 session 自己做。spawn sub-agent 只有三个理由：
-
隔离上下文 — 深度研究会产生大量中间过程，污染主对话
-
保护主线 — 独立审查/对抗验证需要独立视角，不能被之前的推理"带偏"
-
并行执行 — 多个标的同时研究，互不阻塞
不 spawn 的情况：一个 read 能解决的小问题、边界模糊说不清目标的任务、强依赖当前对话上下文的连续推理。
Spawn 合同是关键设计：每个 sub-agent 启动时必须写清输入、输出、禁止列表（不能删什么、不能改什么）。没有合同的 spawn = 定时炸弹。
从 Pipeline 到控制论闭环
早期设计全是开环 pipeline：抓数据 → 分析 → 输出报告，跑完就完了。问题是：输出对不对？质量在变好还是变差？没人知道。
正确的架构是控制论闭环：
目标函数 → 传感器（采集执行数据）→ 比较器（actual vs target）
→ 控制器（生成优化提案）→ 执行器（改 prompt/参数）→ 反馈
具体落地： - 投研报告：初稿完成后 spawn 独立 agent 做对抗审查，修正后才交付 - 假设系统：置信度是数学算的（加权拐点分数），不是 AI 拍脑袋。每个拐点有 weight + score_status，假设置信度 = Σ(weight × 分值) - Agent 自迭代：采集每次执行的质量数据，和目标对比，生成 prompt 优化提案，人确认后执行
关键原则：人在回路。闭环的"执行器"必须等人确认，不 auto-apply。AI 可以建议，不能替你决策。
三路验证
所有重要输出经过三路交叉验证：
- 环境反馈 — 外部信号（健康检查、监控告警、用户反馈）告诉你系统是否正常运行
- 执行错误 — 关键路径有 fallback + 自愈机制，单点依赖 = 灾难
- 自我验证 — 最容易偷懒也最重要的一路。投研报告 spawn verification agent 挑刺；关键数字交叉验证；重大判断附反向论证（"如果我错了，最可能因为…"）
记忆架构
AI 对话的根本问题：对话会消失，但认知必须沉淀。
三层记忆解决这个问题：
- Daily notes（
0-journal/）— 发生了什么，每天写，流水账 - Long-term memory（自动加载）— 精炼的事实和教训，跨 session 持久化
- Knowledge base（
3-universe/）— 结构化的标的/赛道/方法论知识
写下来 > 记心里。只存在对话里的信息 = 不存在。
设计红线
- 迁移优先 — 每做一件事先问：明天换平台，能带走吗？记忆文件、方法论、Agent 设计模式 = 带得走。平台特定调度 = 框架依赖
- 独立可运行 — 每个模块能脱离平台独立跑
- 纯文本优先 — 记忆、文档、Agent spec 都用 Markdown，不绑格式
- 一个信息一个地方 — 重复维护 = 迟早不一致