首页 / 方法论

Agent 系统

如何用 Claude Code + 自建 Agent 体系构建 24/7 投研认知中枢。

核心理念

Agent 不是工具，是数字分身。 目标不是"帮我查数据"，而是模仿我的思维方式、放大我的能力边界、观察我的盲点、在该反对时反对。

四层能力：

  1. 模仿 — 用我的投资哲学、提问方式、决策框架来思考

  2. 放大 — 24/7 监控、多线程并行研究、秒级检索、完整记忆

  3. 观察 — 发现我看不到的盲点、低效模式、系统异常

  4. 挑战 — 该反对就反对，关心结果比讨好重要

整体架构

┌─────────────────────────────────────────────────────┐
│                     Fred（决策者）                     │
│         大决策 / 投资判断 / 对外沟通 → 我来           │
│         执行细节 / 技术方案 / 巡检 → Agent 来         │
└────────────────────┬────────────────────────────────┘
                     │
┌────────────────────▼────────────────────────────────┐
│              ClawFred 🦀（调度层）                    │
│    Claude Code 主 session，路由任务到对应 Agent       │
│    读 AGENTS.md 路由表 → 读 agents/*.md 角色合同      │
│    → spawn sub-agent 或自己执行                      │
└────────┬───────────┬────────────┬───────────────────┘
         │           │            │
    ┌────▼───┐  ┌────▼───┐  ┌────▼───┐
    │研究 Agent│  │监控系统 │  │自动化   │
    │stock    │  │monitors│  │cron    │
    │crypto   │  │heartbeat│ │sentinel│
    │sector   │  │health   │ │digest  │
    └────────┘  └────────┘  └────────┘
         │           │            │
    ┌────▼───────────▼────────────▼───────────────────┐
    │              Cortex（知识库）                      │
    │  0-journal / 2-meta / 3-universe / 4-data        │
    └─────────────────────────────────────────────────┘

配置文件体系

所有配置集中在 .claude/ 目录，是整个系统的唯一源头。

.claude/rules/ — 每个 session 自动加载的规则

文件 核心功能 关键 Insight
soul.md Agent 的人格定义 不是"你是一个助手"，而是"你是我的数字分身"。四层能力模型（模仿→放大→观察→挑战）。决策冲突时的优先级：安全 > 意图 > 诚实 > 行动
user.md 我的思维模式画像 Agent 要模仿的对象。包含投资哲学、提问方式、决策风格、工作偏好、思维盲点。会随交互持续更新
agents.md 路由表 + 执行规范 哪个任务由哪个 Agent 做、怎么 spawn、6 条协作铁律。核心原则：默认主 session 自己做，spawn 只为隔离上下文/保护主线/并行执行
memory.md 跨 session 长期记忆 环境信息、端口分配、关键教训、cron 调度表。精炼的事实，不是对话记录
heartbeat.md 健康巡检架构 两层：Python 健康检查（每 10 分钟）+ AI 巡检（每天首次）。全正常则静默，异常才告警
todo.md 任务追踪 分 Blocked / Ready(P1-P3) / Autonomous / Done 四档

.claude/agents/ — Agent 角色合同

通用 Agent（13 个）：

Agent 用途
research (stock-lead) 对一个标的做完整深度研究
challenge 质疑一个观点或论点
suggest 分析当前组合，看要不要调仓
exit 判断一个持仓要不要退出
news 整理当天重要信息
twitter-writer 把观点变成高传播推文
repo-research 快速评估一个开源项目
solution-finder 全网调研方案 + 推荐报告
pm-forensics 预测市场异常账户取证
pm-bot-strategy 地址视角分析交易策略

研究管道 Agent（按标的类型分组）：

  • Stock（8 个）： valuation / earnings / 6 个 knowledge 模块（history, business, financials, industrial, management, strategy）/ 5 个 perspectives 模块（7powers, order, ecology, genesis, disruptor）
  • Sector（6 个）： sector-lead → intro → competition → opportunities → judgment → research，完整赛道研究管道
  • Crypto（6 个）： crypto-lead → intro / valuation / airdrop / opportunity / hidden

.claude/skills/ — 按需加载的执行知识包

Skills 和 Agents 的区别：Agent 是角色合同（"你是谁，做什么"），Skill 是工具说明书（"这个操作怎么执行"）。

关键 Skills：data-sources（数据获取）、asm-operations（资产管理）、defi-eval（DeFi 评估）、profile-analyst（人格分析）、playwriter（浏览器自动化）、doc-check（文档质检）等。

.claude/settings.local.json — 运行时配置

两个关键 Hook： - PreCompact — Compact 前提醒 Agent 列出值得记录的信息，确保 compact 不丢失关键上下文 - PostCompact — Compact 后自动写入 daily notes + 更新长期记忆

这解决了 AI 对话的根本问题：对话会消失，但认知必须沉淀。

核心自动化系统

Sentinel — 每日投研情报管道

每天 6AM 自动运行，~30 分钟，~150+ 次 LLM 调用。

信源采集 → 相关性过滤 → 按标的聚合研究（含主动搜索）
    → 逐拐点判断 → 对抗审查 → AI 首席分析师裁量 → 等人决策

四层 LLM 设计：

  1. Research — 今天发生了什么？（含主动搜索验证）

  2. Judgment — 哪个拐点该变？持仓怎么调？

  3. Challenge — 判断对吗？（对抗审查，削减过度自信）

  4. AI Proposal — 最终结论是什么？（全局裁量）

关键设计决策： - 置信度是数学算的（加权拐点分数），不是 AI 拍脑袋 - Hypothesis 决策一律等人 review，不 auto-apply - 信源过滤链 6921 → 2794 → ~600 → 精选，逐步收窄 - 详细流程图：5-ability/sentinel/sentinel-intro.html

Agent Evolution — Agent 自迭代系统

经典控制论闭环：目标函数 → 传感器（采集执行数据）→ 比较器（actual vs target）→ 控制器（生成优化提案）→ 执行器（改 agent prompt）→ 人在回路确认。

让 Agent 的每次执行变成可量化、可追溯、可优化的闭环。

健康巡检 — 两层自愈

层 频率 方式 做什么
Layer 1 每 10 分钟 Python 脚本 检查 7 个服务健康状态，异常自动 launchctl 重启，连续 3 次失败才告警
Layer 2 每天首次 Claude Opus 分析趋势性问题（服务反复重启），检查 cron 触发是否正常

核心原则：全正常则静默。 只有真正需要关注的才推送。

Cron 调度表

全部走 LaunchD，plist 在 5-ability/cron/plist/。

时间 任务 输出
每 10 分钟 健康巡检 静默（异常才告警）
每 10 分钟 predict-orderbook-monitor 静默（有新市场才推）
6×/天 twitter-feed-digest #twitter-feed
6:00 AM sentinel-pipeline 静默（产物写文件）
7:00 AM agent-evolution-daily #daily（有 proposal 才推）
7:30 AM binance-daily-snapshot #binance-account
9:00 AM daily-briefing #daily
10:00 AM daily-coaching #daily
7:00 PM company-sentinel #company-sentinel
每周一 9AM weekly-workspace-review #daily
3:30 AM asm-sync 静默（备份+导出）
4:00 AM auto-sync 静默（git commit+push）

协作 6 条铁律

从真实事故中提炼，每条都有血的教训：

  1. 大需求先 Plan — 预计 >30min 或 >3 步，先出方向和边界让我确认（教训：报告 5 轮重写、ASM 返工、Hypothesis Engine 推倒重来）

  2. 新功能先问"你会用吗" — 没有具体使用场景就不做（一个月砍了 7+ 个白做的功能）

  3. 复杂系统出流程图 — 避免反复问"这是什么"

  4. Sub-agent 写禁止列表 + 删前验证 — spawn 时写明不能删/改什么（教训：误删导致 5h 中断 ×2）

  5. 推送默认静默 — 只有有价值的新信息才推送，调试/进度走 log

  6. 回答先 commit 结论 — 一句话 take + 理由，不确定就说不确定

三路反馈闭环

所有重要输出经过三路验证：

  1. 环境反馈 — 健康检查、监控告警、用户反馈

  2. 执行错误 — 关键路径有 fallback，错误自动修复 + 告警

  3. 自我验证 — 投研报告 spawn verification agent 挑刺；关键数字交叉验证；重大判断附反向论证

设计原则

  • 迁移优先 — 每做一件事先问：明天换平台，能带走吗？记忆文件、独立服务、方法论 = 带得走。平台特定调度 = 框架依赖
  • 独立可运行 — 每个项目能脱离平台独立跑
  • 纯文本优先 — 记忆、文档、Agent spec 都用 Markdown
  • 推送直连 — 不走中间层
  • 写下来 > 记心里 — 只存在对话里 = 不存在
  • 从开环转向闭环 — 不是 pipeline 跑完就完了，要有目标函数 → 传感器 → 比较器 → 执行器 → 反馈

关键教训

事故 教训 防护措施
误删 GitHub repo 删 repo 前必须检查所有本地 git remote 流程约束
Twitter follow 被封号 激进执行要考虑平台限制 频率控制
误删生产脚本 (5h ×2) Sub-agent 必须写禁止列表 Spawn 合同
venv 被系统升级破坏 cron 一律显式用 venv/bin/python3 隔离依赖
git add -A 误删文件 add 前必须 git diff --stat PreCommit hook
LaunchD plist 更新不生效 必须 unload+load，symlink 更新 ≠ loaded config 更新 操作规范
凌晨日期切换 bug 涉及日期切换的逻辑必须测凌晨边界 测试边界