构建 AI Agent 系统：从复杂 Agent Skills到企业级 AI Agent

这是 AI 理财系列的第 2 篇。本系列讲述如何用 Claude Code 和 LLM Wiki 构建个人理财 AI 系统。

这篇文章写给正在构建 AI 系统的开发者。具体来说：如何开发复杂的、多步骤的 Claude Code Skills，并将它们组合成 Workflow------以及把一个能用的个人工具真正变成企业级 Agent 需要什么。

虽然具体领域是股票投资，但这些模式本身是通用的。这篇文章可以独立阅读。如果你想先了解 Claude Code 是什么、LLM Wiki 如何工作、如何从零搭建知识库，可以看第 1 篇，但不是必须的。

起点：RWH 提供什么

RWH 是 kgajjala 开发的开源 LLM Wiki，专注于蓝筹股分析。名字代表 Richer, Wiser, Happier（更富有、更睿智、更快乐）------对于一个投资知识库来说，这是个理想的目标。它将财报摘要、分析师评级和行业背景聚合到一个基于 Markdown 的知识库中，LLM 可以直接在其上进行推理。每只 ticker 对应一个结构化文件，包含基本面数据、近期分析师观点和论点笔记。整体设计围绕 Karpathy 的 LLM Wiki 模式：原始材料被提炼成长青的 wiki 条目，你查询 wiki 得到有事实依据的分析，而不是 LLM 的随机回忆。

RWH 的价值：

由 kgajjala 持续更新维护
结构统一，对所有股票都适用
对蓝筹股覆盖完整------财报超预期/不及预期、分析师升降评级、竞争格局变化
CLAUDE.md 记录了每只 ticker wiki 条目背后的分析框架，给操作它的 LLM 提供了清晰的推理框架

但它也有一些局限性：

覆盖范围。 RWH 覆盖蓝筹股。我还追踪主题性仓位------电网基础设施、电池储能、光互联、LEO 卫星宽带。这些需要行业层面的综合分析，而不是单只股票的摘要。

个性化。 通用分析告诉你发生了什么。考虑了你的成本基础、账户集中度和税务情况的分析才能告诉你该怎么做。RWH 不是为了了解你的投资组合而设计的。

决策工作流。 我需要按计划产出可执行的决策，而不只是在我问的时候呈现信息。这需要把 Skills 组合成 Workflow，有明确的输入、输出和一致的逻辑。

我做了什么

RWH-overlay 是一个独立的 repo，在RWH基础上添加了四层内容。每晚的合并 Pipeline 从 RWH 的 repo 拉取 wiki 内容，与我的 overlay 分析合并------两个 repo 保持独立。

行业和个股分析。 在 RWH 的逐股覆盖之外，我为追踪的主题增加了行业层面的综合分析。它会拉取整个行业的近期新闻、财报信号和分析师评级变化，生成结构化摘要。这样RWH给 LLM 在单个企业上的推理提供了基础；行业层提供了"这对主题意味着什么"的推理------把公司层面的事件连接到多年期资本部署的故事。

finance-skills 集成。 finance-skills 是一个开源的 Claude Code Skill 集合，覆盖金融数据获取和分析，包括财报日历、期权流、技术指标计算等。Claude Code Skill 有两种模式：Command自用模式（存储在项目的 .claude/commands/）和 Plugin 模式（全局安装，跨项目共享）。我用 Plugin 模式使用 finance-skills，自动获得他们的更新而无需管理代码。其中 finance-market-analysis:sepa-strategy 提供完整的 SEPA 技术分析，是我 /morning-check Command 的核心输入之一。

自定义集成 Command。 Overlay 添加了将 RWH wiki 内容、finance-skills 数据获取和我的私有数据连接起来的 Command。完整的 Command 清单：

Command	用途
`/kb-sync`	构建并同步合并后的完整知识库（RWH + Overlay）
`/stock-analyze <TICKER>`	新股票完整研究 Pipeline：15 节论文，含 BAIT、Moneyball PW EV、Asset Type
`/stock-refresh <TICKER>`	财报或重大新闻后的论点更新
`/stock-entry <TICKER>`	单只股票的入场/退出点分析
`/morning-check <TICKER>`	开盘决策：论点检查、SEPA 状态、入场/止损/目标价
`/morning-check ALL`	批量扫描所有持仓；标记需要处理的信号
`/etf-analyze <TICKER>`	ETF 深度分析：持仓审查、费率、流动性、行业纯净度
`/etf-check`	事件驱动的行业 ETF 定投决策------检查触发条件
`/chen-integrate`	解析 Chen Yun 观点，标记需要研究的 Ticker
`/chen-validate <TICKER>`	将 Chen Yun 提及的 Ticker 对照投资框架交叉验证
`/market-daily`	每日市场报告和行业健康摘要
`/market-weekly`	应税账户周度行动计划：TLH 机会、蓝筹候选、DCA 执行
`/market-monthly`	月度持仓和论点回顾
`/market-quarterly`	季度持仓和策略回顾

每个 Command 从三个来源读取：RWH 的 wiki（公开，Upstream）、我的 overlay 行业分析（公开，自建）、以及持仓信息 data/positions.md + data/profile.md（私有，git-ignored）。这个组合让输出是针对个人的可操作的投资意见。

自动合并 Pipeline。 每晚，脚本将 RWH 的 wiki 内容和我的 overlay 分析合并到 stock-kb 目录，通过 Quartz 渲染为可浏览的网站。Wiki 是可公开分享的。output/ 也是------它放的是有日期标签的市场报告，不含个人持仓数据。只有 data/ 是私有的------持仓规模、成本基础、账户余额都在这里，git-ignored，永远不上 GitHub。

Workflow 才是产品

单个 Skill 是工具。Workflow 才是让它们变得有价值的东西，成为真正的Agent。

Roth IRA 新建仓的实际决策流程，展示 Skill 如何组合：

ini 复制代码

[想法进入]
    │
    ├─ 行业扫描 / Chen Yun 信号 / 财报惊喜
    │
    ↓
[/stock-analyze <TICKER>]
    │
    ├─ 读取 rwh wiki 条目（蓝筹）+ 行业分析
    ├─ 应用 BAIT 框架：识别错误定价类型
    ├─ 运行 Moneyball PW EV：牛/基/熊情景 → 加权期望价值
    ├─ 应用 Asset Type 框架：确认正确的估值视角
    │
    ↓ PW EV > 当前价 15%，上行/下行比 > 2:1？
    │
    ├─ 否 → 观察列表，等下一个催化剂后重评
    └─ 是 ↓
         │
    [/morning-check <TICKER>]
         │
         ├─ finance-market-analysis:sepa-strategy 检查 Stage 2 + 趋势模板
         ├─ 识别形态（VCP / 杯柄 / 平台整理）和 Pivot 点
         ├─ 检查市场环境（SPY/QQQ vs 200MA）
         │
         ↓ 输出：Execute / Chase 50% / Wait / Skip

/morning-check ALL 每天早上在所有持仓上运行这套逻辑，标记接近止损位的仓位、即将达到目标价的仓位，以及论点破坏信号。

应税账户有由 /market-weekly 驱动的并行 Workflow：每周日生成结构化行动计划，涵盖税损收割机会（检查 Wash Sale 合规性）、来自 RWH 最新 Initiate/Add 推荐的蓝筹候选，以及 VTI/QQQ 的定投执行。计划写入私有文件，永不提交 Git。

Workflow------而不是任何单个 Command------才是让系统有价值的东西。Command 是可复用的组件；Workflow 是产品。

总计：4 个核心 Workflow（个股入场、每日监控、ETF 行业定投、Chen Yun 整合），14 个 Command 覆盖研究、仓位管理和定期回顾，以及每晚将 Upstream RWH wiki 和 Overlay 分析合并的构建脚本。

这四个 Workflow 合在一起，构成了一个从想法生成到仓位管理的六阶段投资流程。完整的流程在第 3 篇：投资操作系统里有详细说明，不看也不影响理解本文。

五条经验

1. 彻底与 Upstream 解耦

第一条规则：永远不要直接修改 RWH 的内容文件。唯一例外是 root index，它由 wiki 结构自动生成。

"就在这里加个注释"的诱惑是持续存在的。代价是：Upstream 合并变得痛苦------你在对比自己改过的文件，最终只能 Fork 而不是 Overlay。这意味着失去 kgajjala 的免费改进。

收益是：拉取 RWH 更新是干净的 git merge。我的工作在一个持续维护的基础上复利增长。

实现：RWH 和 RWH-overlay 是两个独立的 repo。每晚的合并 Pipeline 从 RWH 的 repo 拉取内容，脚本不回写 RWH 的文件。这条边界靠 Pipeline 约定来维护，而不是 repo 结构------这意味着需要我主动保持这个纪律。

2. 从痛点出发构建 Agent Workflow，而不是从功能出发

每个 Command 都源于一个具体的痛点。/morning-check 的初始思想是："开盘前，我需要知道哪些仓位接近止损，本周哪些有财报会影响论点，哪些形态在突破。我需要在五分钟内知道，而不是三十分钟。"

另一种方式------设计一个全面的 AI 投资顾问再反向工作------会产生功能完整但与你实际思考投资组合方式不符的系统。我见过这种模式多次失败：系统功能齐全，获取的数据没有一个真正被用到，两周后被放弃。

需求驱动的设计还会揭示 RWH 和 finance-skills 真正能给你什么。开始我并没有打算使用 finance-market-analysis:sepa-strategy------我是在寻找自动化 SEPA Stage Analysis 的方法时发现它的，那是我每天早上最耗时的步骤。痛点指向了用什么工具。

3. 脚本负责数据，LLM 负责解释

效果好的 Command 需要有一个清晰的整合规则：确定性脚本获取并结构化数据；LLM 解释它。

以财报信号为例：Python 脚本调用相关 API，将输出规范化到结构化的暂存文件。Claude 读取暂存文件并推理------这个超预期是否在趋势背景下有意义？它改变了论点吗？脚本不回答这些问题。LLM 不能获取结构化财务数据。

这很重要，因为 LLM 会在事实上产生幻觉，但在给定事实上推理能力优秀。让 LLM 从记忆中回忆一个具体的 EPS 数字，你在找麻烦。把这个数字给它，让它在 Context 中解释含义，你就走在正确的路上了。"数据获取"和"解释"之间的连接处是大多数 AI 系统 Bug 的藏身之处。

对于复杂 Command，我使用了 Superpowers 的 Brainstorm/Plan/TDD Workflow：独立测试脚本逻辑，然后围绕已验证的结构化输出接入 LLM 推理。脚本部分完全可测试；LLM 部分不可测试------这正是你想让 LLM 只碰解释层的原因，在那里"正确答案"本来就是判断而不是确定性事实。

4. 目录边界决定了项目质量

四个目录的区分看起来是组织细节，实际上是结构性决策。

raw/：源材料，只进不出。

wiki/：长青内容，按 ticker 和行业组织，可公开分享。你愿意放进公开 repo 的分析。

output/：有日期标签的分析报告------每日市场总结、行业快评------不含持仓信息，同样可公开分享。

data/：私有层。仓位规模、成本基础、账户余额、税收批次详情，以及结合持仓的深度分析。Git-ignored。永不可分享。

关键区分在 wiki + output（公开）和 data（私有）之间。模糊这条线会导致两种失败：你意外暴露私人数据，或者你无法分享知识成果因为它与个人数据纠缠在一起。

这条边界还强制厘清 LLM 要做什么。写入 wiki 或 output 时，它在做分析------你愿意公开的推理。写入 data 时，它在针对你的具体情况做综合。分开维护让系统更容易审查，出了问题也更容易理解发生了什么。

5. 了解 LLM Wiki 的扩展上限

LLM Wiki 方式在 ticker 范围有界时效果良好。在 150 只股票规模下，Context Window 管理仍然可行------尤其是每个 Command 选择性读取而不是加载完整 wiki。如果你试图同时推理数千个数据点时（作为这个真正的商用产品）那就有问题了。

那时就要选RAG了。wiki 的文件结构让分块变得自然，Quartz 渲染的输出提供了检索入口。架构本身已为此做好准备：今天适用于 LLM-in-Context 的文件组织，未来切换到RAG向量检索时不需要重构知识库。

从 Command 到 Agent：真正的工程挑战

当前系统已经基本自主（符合Agent的特征）------Command 按计划运行、产生结构化输出，我审查并决策。Claude Code 是 Runtime LLM的基座。

自然的下一个问题：把这个变成不依赖我的 Claude Code Session 的独立 Agent------一个能服务多个用户的产品------需要什么？

业务逻辑是容易的那部分。它已经得到验证：这些 Workflow 我跑了好几个礼拜，决策逻辑经过实战检验，框架有文档记录。把验证过的业务逻辑转化为独立 API 很容易。

难的是让 Agent 可扩展可控可信任：

脚本架构不能免费迁移。 为单用户本地执行写的脚本有隐藏的假设------本地文件路径、顺序执行、共享环境变量。让它们无状态可容器化，意味着把那些假设显式化并消除。调用 /morning-check 的脚本天然假设只有一个用户的 data/positions.md。多用户意味着从一开始就要做基于租户的数据隔离。

非确定性变成治理问题。 个人使用时，如果同样输入今天的推荐和昨天稍有不同，我会注意到并调整。规模化后，用户期望一致性，监管机构可能要求可解释性，调试需要可复现性。这意味着要加入 Prompt 版本控制、结构化输入/输出日志、对关键操作的人工审批门控------这些在当前实现中都没有。

测试需要不同的方式。 在本地测试 Command 很简单------运行然后看结果。为生产系统做适当的测试需要：

沙盒市场数据（历史价格，不是实时）
基于 Fixture 的 LLM 响应，用于确定性行为测试
跨完整 Workflow 的端到端集成测试
一个镜像生产环境但不影响真实仓位的 Staging 环境

Superpowers TDD Workflow 已经在脚本逻辑上强制了干净的测试。但完整的 Agent 路径需要更严格的环境------一个能验证行为的 Staging 层，而不是消耗真实 API Token 或做真实决策。

可观测性对 Agent 是不同的概念。 当 Agent 产出一个错误的推荐，你需要知道：它读了什么数据、用了哪个框架、考虑了哪些备选、为什么选择了它选择的。标准日志不能捕获这些。你需要结构化的 Agent Tracing------记录每个 Agent 决策的完整 Context，而不只是输入和输出。这是"日志显示推荐了 Exit"和"日志显示因为 BAIT 只有 1 个重叠（不足）、Moneyball PW EV 低于当前价、Stage 2 标准未通过，所以推荐了 Exit"之间的区别。

Agent 需要被当作一等基础设施。 在生产环境运行 Agent 意味着要回答个人使用时不会出现的问题：发布一个新版本的 Command 意味着什么？如果 /morning-check 开始产出糟糕的输出，怎么回滚？Agent 调用很贵，怎么执行花费上限？对于输出天然不确定的系统，怎么监控 Agent 是否在"正常工作"？

开发方法论也需要根本性转变。 构建 Claude Code Command 很大程度上是 Prompt 驱动的------Superpowers 的 Brainstorm/Plan/TDD Workflow 足以处理这里的复杂性，你几乎不需要写多少代码就能迭代。独立 Agent 是一个软件产品：它需要 Spec Driven Development、合理的软件架构，以及构建真实服务所需的全套代码级工程能力。"我可以用 Prompt 描述我想要什么"和"我可以构建并可靠维护一个生产级代码库来实现它"之间的差距是真实存在的，而且往往是这条迁移路径中最被低估的部分。

对于 RWH-overlay 来说：产品化路径是清楚的，但真正的瓶颈不是工程。投资建议是受监管的活动。从个人工具到为他人服务的产品，涉及与代码库毫无关系的合规工作，这些可能是商用化真正难得地方。

目前来说，个人使用的价值是毋庸置疑。我运行了几个礼拜的项目，非常有效果。