生产级 AI 系统工程方法论

Production AI Engineering Methodology

版本 v1.0 | 2026-10-27 适用读者：AI/LLM 工程师、AI 产品架构师、AI 技术管理者 摘要：基于 60 天系统研究（Phase 3）+ 一个生产级金融 Agent 完整闭环总结的 AI 产品工程方法论。 作者背景：10 年金融零售 PM+BA+开发，2026 年完成 90 天 Web3 + 120 天架构 + 60 天 AI 系统三段式学习。

---

目录

第 1 章 引言：为什么需要"工程化" AI
第 2 章 LLM 选型与多模型策略
第 3 章 Prompt 工程 SOP
第 4 章 RAG vs Long Context vs Fine-tuning（决策框架）
第 5 章 RAG 架构的 5 个层级
第 6 章 Agent 设计模式（5 种）
第 7 章 Eval 体系：4 层防线
第 8 章 Cost 优化的 8 个杠杆
第 9 章 Latency 优化的 6 个技巧
第 10 章 Safety & Guardrails 三层防御
第 11 章 LLMOps 工具栈
第 12 章 Web3 × AI Agent 特殊考量
第 13 章 团队组成与开发流程
第 14 章 展望与开放问题
附录 A. 工具链推荐表
附录 B. 关键 prompt 模板
附录 C. 推荐阅读

---

第 1 章 引言：为什么需要"工程化" AI

1.1 LLM 应用的 5 个独特工程挑战

传统软件工程，输入相同则输出相同；只要写好契约、单测、CI/CD，质量就有保障。LLM 应用打破了几乎所有这些假设。

这 5 件事本质上是说：你不能用传统 QA 思路保证 LLM 应用质量。需要重建一套从"写代码 → 测试 → 上线"的工程链路。

关键转变：质量保障的中心从"unit test"转移到"eval"，从"deterministic assertion"转移到"distributional metric"。

1.2 从 demo 到生产的鸿沟

我把 LLM 产品的成熟度分 5 级（参考 GitHub Copilot / Cursor / Anthropic 内部实践，结合自己的 60 天落地）：

Demo → 生产通常意味着从 L1 跳到 L4 或 L5。本方法论的核心目标，就是让你不必再迷信"魔法 prompt"或"哪个最强模型"，而是按工程化路径稳定爬到 L4-L5。

1.3 本方法论的定位与边界

本方法论涵盖：

• LLM/RAG/Agent 应用层工程
• Prompt / Eval / 部署 / 监控的端到端实践
• 决策框架（什么时候用什么）
• 金融场景作为案例（合规/数值精度/低幻觉特殊要求）
• Web3 Agent 特殊考量

本方法论不涵盖：

• 模型预训练、底层架构（attention / MoE / state-space），见 Day 121-126 笔记
• 推理引擎实现细节（vLLM / SGLang），见 Day 165 笔记
• 具体业务的 PRD（每个产品自己写）

适用阶段：从 0 到 1 想做 LLM 产品，到现有产品做规模化优化。如果你只想把 ChatGPT 嵌到自己产品里随便跑跑，第 2、3、7 章就够了。如果你要做生产级 agent，全 14 章都需要。

1.4 方法论的 6 条总原则

我把 60 天学到的所有具体技术，能压成 6 条原则：

1. Eval-first：还没 eval 之前不要写更多功能。
2. 多模型而不是单模型：cheap 路 + expensive 路并存。
3. 缓存先于重算：prompt cache / kv cache / semantic cache，能省 70% cost。
4. 分层防御：input → runtime → output 三层。
5. 失败可观察：每条 trace 都能回放、归因、复盘。
6. 可逆部署：prompt 改动如同代码改动，可灰度可回滚。

关键洞察：以上 6 条都不是 AI-specific，是工程通用原则。LLM 工程师最大的失败模式是把这 6 条扔掉，去追"prompt 玄学"。

---

第 2 章 LLM 选型与多模型策略

2.1 模型评估的 5 个维度

每次评估一个新模型，按 5 维打分：

陷阱：单看 benchmark 选模型是经典错误。你的 golden eval 才是真理。我曾经在金融数值抽取任务上发现 Claude Haiku 4.5 比 GPT-4o-mini 高 9 个百分点（前者更稳定输出 JSON），但 MMLU 上 Haiku 落后 3 个点。

2.2 主流模型选型矩阵 (2026-10)

数据为撰写时点估算，月级别会变，请用最新 pricing 校准。

2.3 多模型路由策略

单模型反模式：所有 query 都用 Opus → cost 爆炸；都用 Haiku → 复杂 query 失败。

Cheap-route + expensive-route 的双层路由：

┌─────────────────────────────────────────────────┐
│  user query                                      │
│         │                                         │
│         ▼                                         │
│  [classifier (Haiku, $0.001/req)]                │
│         │                                         │
│         ├─→ 简单 / 高频 → cheap route (Haiku)    │
│         ├─→ 一般推理 → main route (Sonnet)       │
│         └─→ 复杂 / 关键 → premium route (Opus)   │
│                                                   │
│  retry / disagreement → escalate to next tier    │
└─────────────────────────────────────────────────┘

实测数据 (我的金融 agent v1.2)：

整体平均 $0.041，比"全 Sonnet" $0.087 便宜 53%。

Disagreement-based escalation：当 Haiku 输出 confidence 低 (例如 logprobs 提取或 self-rated < 0.7) → 升级 Sonnet 重跑。比单一固定路由还能再省 10-15%。

关键洞察：路由层的成本远低于其节省额。一个 $0.001 的 classifier 调用能省下 $0.05 的 main 调用，ROI 50×。

---

第 3 章 Prompt 工程 SOP

Prompt 工程是 AI 工程里被神化最多、被工程化最少的环节。本章提供一个标准作业流程。

3.1 Prompt 设计 6 步法

┌────────────────────────────────────────────────────┐
│ Step 1: 明确任务的 input / output schema           │
│         (写下来！output 用 JSON schema 定义)       │
│                                                    │
│ Step 2: 写 5 条 happy path golden examples         │
│                                                    │
│ Step 3: 写 5 条 edge case (空输入/异常/越界)        │
│                                                    │
│ Step 4: 起 prompt v0：role + task + format + 1 ex  │
│                                                    │
│ Step 5: 跑 10 条 → 看失败 → 改 prompt → 跑 10 条   │
│         (循环至 stable, 通常 3-5 轮)                │
│                                                    │
│ Step 6: 上 30-100 条扩展 eval, A/B vs baseline     │
└────────────────────────────────────────────────────┘

反模式：直接从 step 4 开始，写 1 个 prompt，看 1 个 example，"感觉不错"就上线。

3.2 Structured Output 最佳实践

LLM 输出非结构化文本是 90% 集成痛苦的根源。生产级 prompt 必须输出可解析格式。

模板（Anthropic tool use）：

tools = [{
    "name": "extract_finance_metrics",
    "description": "Extract structured financial metrics from a 10-K paragraph.",
    "input_schema": {
        "type": "object",
        "properties": {
            "ticker": {"type": "string"},
            "revenue_usd_m": {"type": "number"},
            "yoy_growth_pct": {"type": "number"},
            "fiscal_period": {"type": "string", "pattern": "^FY\\d{4}Q[1-4]$"},
            "as_of": {"type": "string", "format": "date"},
        },
        "required": ["ticker", "revenue_usd_m", "fiscal_period"],
    },
}]

让模型"调用"这个 tool 即得到结构化 JSON，schema 不符 SDK 会自动 retry。

3.3 Prompt 版本管理与 CI

反模式：prompt 写在代码里 hard-code，改一次改 git diff 一次。

生产做法：

• prompt 单独存 prompts/ 目录，每个 prompt 一个 .md 文件 + frontmatter（version/author/date/owner）
• 每次 prompt 改动作为代码改动走 PR，必须附带：
  • 改动说明
  • 在 golden eval 上跑出的 v_old vs v_new 对比
  • 至少 1 个新增 eval case
• CI 自动跑 30 条 smoke eval，failed 阻塞 merge
• 上线后 7 天 A/B，新版本 win 才提为 stable

工具推荐：Langfuse Prompts、PromptLayer、Helicone。

关键洞察：把 prompt 当成代码 vs 当成配置文件，是 LLM 团队成熟度的最重要分水岭。

---

第 4 章 RAG vs Long Context vs Fine-tuning（决策框架）

这是最常见的、也是最容易判断错的选型。

4.1 三种方法的本质区别

4.2 决策树

┌──────────────────────────────────────────────┐
│  你的问题是什么？                              │
└──────────┬───────────────────────────────────┘
           │
           ▼
   ┌──── 知识不在模型训练数据里？───┐
  YES                              NO
   │                                │
   ▼                                ▼
   ┌── 文档 < 200K tok 且高频复用？─┐    ┌── 输出格式 / 风格特殊？──┐
  YES                              NO   YES                       NO
   │                                │    │                         │
   ▼                                ▼    ▼                         ▼
Long context              RAG (默认)    Fine-tune                直接 prompt
(配 prompt cache)         (Section 5)    (LoRA)                  (Section 3)

4.3 量化阈值（实测）

4.4 何时混用

几乎所有真实生产系统都是混用的：

[LoRA fine-tune base model on company-specific output style]
        +
[RAG for changing knowledge base (docs, products)]
        +
[Long context + prompt cache for stable, high-traffic doc]
        +
[Prompt engineering on top]

4.5 决策案例：金融研究 agent

关键洞察：选型不是单选题，是组合题。"X vs Y vs Z" 这种问法本身就反映对 production 缺乏经验。

---

第 5 章 RAG 架构的 5 个层级

我把 RAG 系统按复杂度分 5 级 (L1-L5)。每跨一级，工程成本 2×，但场景适配也更深。

5.1 L1: Naive RAG

[doc] → chunk(512) → embed → vector_db
[query] → embed → top_k=5 → concat → LLM

适用：< 100 文档，单语种，简单 factoid query。

limit：semantic search 经常召回不够准；chunk 切分破坏语义。

典型 metric：Recall@5 ~70%，answer accuracy ~75%。

5.2 L2: Hybrid + Rerank

[query] → BM25 + dense_embedding (parallel) → 50 candidates
       → cross-encoder rerank → top 5 → LLM

升级点：

• BM25 (lexical) 补 dense embedding 漏的精确匹配（如代码、专业术语）
• Cross-encoder reranker（如 Cohere rerank-v3, Voyage rerank-1, BGE-reranker-v2）

典型 metric：Recall@5 ~85%, answer accuracy ~85%。

实测（Day 138 我的金融 RAG）：升级 L1→L2 在金融 QA 上 accuracy +12 个点。

5.3 L3: Hierarchical / Multi-vector

不再只 embed 整段，而是为每个 chunk 生成多个 embedding：

• summary embedding（粗粒度匹配大主题）
• propositional embedding（每个 atomic fact 一个 embedding）
• HyDE (Hypothetical Document Embedding)：用 LLM 生成 query 假想答案再 embed

适用：长文档（10-K，法律合同），query 与文档语言风格差距大。

实测：Recall@5 ~92%。

5.4 L4: Agentic RAG

不再"一次查询"，而是 agent 多轮检索：

[query] → agent 思考: 需要查什么？
        → search_tool(q1)  →  fact1
        → 还缺信息？search_tool(q2) → fact2
        → 反思：足够了吗？
        → synthesize answer

工具：LangGraph、Anthropic agent loop、自实现 ReAct (Day 150)。

适用：复杂 multi-hop query (e.g. "对比 A 公司 2023 财报里的 Cloud 收入与 B 公司同口径")。

代价：cost 3-5×，latency 2-4×。只有在 L3 失败的 query 上才升 L4。

5.5 L5: GraphRAG / 知识图谱辅助

把文档抽出实体 + 关系 → 构建知识图谱 → query 时既走 vector search 也走 graph traversal。

代表：Microsoft GraphRAG, Neo4j+Bedrock, LightRAG。

适用：实体关系密集 (生命科学、企业组织结构、家族关系)。

代价：构建图本身可能贵过 RAG 全程。GraphRAG 索引 10K 文档可能 $500-$2000。

实测：在 enterprise QA 上比 L4 再 +5-8 个点 accuracy；但 50% 的 query 用不到图。

5.6 选型建议

< 100 docs, prototype       → L1
1-10K docs, 通用 QA          → L2 (默认)
长文档为主 (>50K tok 单文档) → L3
复杂 multi-hop query 多      → L4
实体关系密集 + 预算充足      → L5

关键洞察：你的 RAG 在 L2 就能解决 80% 的问题。先把 L2 做扎实再考虑 L3+。我见过太多团队跳过 hybrid + rerank 直接上 GraphRAG，结果效果不如 L2。

---

第 6 章 Agent 设计模式（5 种）

参考 Anthropic 2024 年发布的 agent design patterns 综述（Day 149-155 详细学过），加上我的实战修正，分 5 种核心模式 + 1 种 anti-pattern。

6.1 模式一：Workflow（固定步骤）

[input] → step1 (LLM) → step2 (tool) → step3 (LLM) → output

特征：步骤、顺序、条件分支都在代码里写死。LLM 只负责"局部填空"。

适用：流程稳定、可预测的任务（合同条款抽取、客服 FAQ 路由）。

优点：cheap、fast、可预测、可单测。

缺点：不灵活，新场景需改代码。

6.2 模式二：Single Agent + Tools

[query] → LLM (loop: 选 tool → 执行 → 加入 context → 继续)
        → 直至 LLM 输出 final answer

适用：query 类型多样，但单 agent 能 hold 住的简单工具调用（≤5 个 tool）。

实现：Anthropic tool use loop / OpenAI function calling loop。

典型坑：tool 太多 (>10) 时 LLM 选错；tool 描述写得差时表现暴跌。

6.3 模式三：ReAct Agent

Thought: 我需要先查 X
Action: search_tool(X)
Observation: ...
Thought: 现在我知道...还需要 Y
Action: ...

强制"先思考再行动"，思考链路显式。Yao et al. 2022 论文证明比纯 act 准 30%。

适用：需要可审计的推理链路；中等复杂度任务。

坑：在过于开放的任务上不收敛（参考 Day 179 Case 1）。需要硬性 max_steps + critic check。

6.4 模式四：Plan-and-Execute

[query] → planner LLM 输出: [step1, step2, step3, ...]
        → executor 逐步执行（每步可能本身就是个 ReAct sub-agent）
        → re-planner 在中途失败时重新规划

适用：复杂任务（金融研究、code generation、deep research）。

优点：planner 与 executor 解耦，便于优化、监控、缓存。

缺点：plan 错则全错；需要好的 plan critique。

实测 (Day 156, 我的金融 agent)：plan-execute 比 single agent 在 L3 query 上 accuracy +14 点。

6.5 模式五：Multi-Agent Hierarchy

[orchestrator]
   ├── researcher (RAG)
   ├── analyst (math/calc)
   ├── chain_query (onchain)
   └── reporter (synthesizer)

适用：明确角色分工的复杂任务；需要并行；需要不同 agent 不同 prompt/model。

优点：每个 agent prompt 简单聚焦；可并行。

缺点：通信协议设计麻烦；memory 管理复杂；失败传染（一个 agent 错传染下游）。

参考实现：CrewAI, AutoGen, LangGraph。我自己用裸 SDK + asyncio 也能撑（Day 152）。

6.6 反模式：Multi-Agent Debate

让 N 个 agent 互相 argue 直到 consensus。学术上有效，生产基本不可用：cost 是单 agent 的 5-10×，latency 也 5-10×，gain 通常 < 5%。仅在监管/裁判类高价值场景值得。

6.7 选型决策树

任务流程稳定？──是──→ Workflow
   │
   否
   ▼
单步可解？──是──→ Direct prompt
   │
   否
   ▼
工具数 ≤ 3？──是──→ Single Agent + Tools
   │
   否
   ▼
需要可审计推理？──是──→ ReAct
   │
   否
   ▼
任务可分阶段？──是──→ Plan-and-Execute
   │
   否
   ▼
需要明确角色分工 + 并行？──是──→ Multi-Agent Hierarchy
   │
   否
   ▼
回到 Plan-and-Execute（最通用 fallback）

关键洞察：90% 团队的第一版 agent 应该是 Plan-and-Execute，不是 multi-agent，更不是 debate。看到面试官说"我做了 multi-agent debate"，请追问 metric 与 cost。

---

第 7 章 Eval 体系：4 层防线

LLM 产品的质量保障 = eval 体系。没 eval = 没法迭代 = 没法上规模。

7.1 4 层防线总览

┌─────────────────────────────────────────────────┐
│ L1: Deterministic (unit tests, regex, JSON)      │
│   速度: ms      成本: 0       覆盖: 格式 / 关键词 │
├─────────────────────────────────────────────────┤
│ L2: LLM-as-judge                                  │
│   速度: 秒      成本: 中      覆盖: 语义 / 质量   │
├─────────────────────────────────────────────────┤
│ L3: Golden datasets                               │
│   速度: 分      成本: 高      覆盖: 完整 e2e      │
├─────────────────────────────────────────────────┤
│ L4: 用户反馈 + 回归 + 红队                        │
│   速度: 天-周   成本: 最高    覆盖: 真实分布      │
└─────────────────────────────────────────────────┘

每层都不可替代。典型反模式：只做 L1 (单测) 或只做 L4 (用户反馈)，跳过 L2/L3。

7.2 L1: Deterministic Tests

每个 LLM 调用应该有一组 deterministic 断言：

def test_extract_ticker_returns_valid_format():
    out = extract_ticker("Apple's revenue...")
    assert re.fullmatch(r"[A-Z]{1,5}", out)
    assert out in KNOWN_TICKERS  # whitelist

覆盖：格式 / 类型 / 长度 / 关键词存在性 / 数值范围。

作用：CI 阶段拦下 90% 的低级错误（输出非 JSON、字段缺、数字越界）。

7.3 L2: LLM-as-Judge

不能用 deterministic 表达的"语义对不对"，让另一个 LLM 判分。

关键防偏措施（Day 167 详细）：

Inter-judge agreement：每 20-50 条人工抽样 + Cohen's κ 评估。κ < 0.6 说明 rubric 有歧义。

模板 see 附录 B。

7.4 L3: Golden Datasets

生产级 eval 的核心资产。100 条起步，1000 条理想。

分层：

Normal (60-70%)      正常分布的 query
Edge (15-25%)        边界 (空 / 极长 / 异常输入)
Adversarial (5-10%)  红队攻击 (prompt injection / jailbreak)
Regression (5-15%)   过去线上故障 case 永久保留

版本管理：dataset 同 schema 入 git，schema 包括 query / expected / category / severity / source。

漂移检测：定期把生产 query 抽样 1000 条，与 golden 做 embedding 距离。漂移大 → 扩 golden。

7.5 L4: 用户反馈与回归

• 每条 response 加 thumbs up/down
• 收集低评分 case → 进 golden（regression bucket）
• 每月跑一次完整 golden 回归
• A/B 新版本至少 7 天

用户反馈数据 → eval 信号 → prompt 改 → 部署 闭环要在天级别完成，月级别就晚了。

7.6 实战：金融 agent 的 eval pipeline

PR opened
   │
   ▼
[L1] 30 条 smoke unit test (50ms)
   │
   ▼ pass
[L2] 50 条 golden subset + LLM judge (5min, $0.5)
   │
   ▼ score Δ ≥ -2%
[L3] 100 条 full golden (15min, $4)
   │
   ▼ pass
human review (Slack approval)
   │
   ▼
deploy to canary (5% traffic)
   │
   ▼ 1 day, p95 metrics ok
deploy to 100%

关键洞察：

Eval 不是"有空再做"，是"先做 eval 再做功能"。Eval 体系没建好就堆功能，每堆一个 feature 就把质量推向更不可知的角落。

---

第 8 章 Cost 优化的 8 个杠杆

LLM 成本可以在不损失质量的前提下降 70-90%。下面是按收益排序的 8 个杠杆。

8.1 Prompt Caching （收益 ~40-90%）

Anthropic prompt cache、OpenAI cached input：长 system prompt + few-shot 标记为 cache → 第二次起命中率高时收 0.1× 价格。

适用：system prompt > 1024 tok，且同一 system 在 5 分钟内被重复调用 ≥3 次。Agent loop 完美匹配。

system=[{"type":"text","text":LONG_PROMPT,"cache_control":{"type":"ephemeral"}}]

实测（金融 agent v1.1）：cost 节省 40%。

8.2 Batch API （收益 ~50%）

Anthropic / OpenAI 都提供批量 API，价格 0.5×（24h 内交付）。适用：非实时任务（embedding 全量重生成、夜间报告、bulk classification）。

我把 nightly knowledge graph rebuild 全切到 batch → 月成本从 $400 → $200。

8.3 模型梯度路由 （收益 ~30-60%）

cheap-route / main / premium 三层（Section 2.3）。绝大多数 query 不需要 Opus。

8.4 Context 压缩 （收益 ~20-40%）

• 把 long history 用小模型 summarize
• 移除 repetitive structure (markdown table 序列化)
• 用 LLMLingua 做 prompt compression（实测可压 4-6× 而 accuracy 仅降 2-3%）

8.5 缓存层 (Redis / 语义缓存) （收益 ~15-30%）

热点 query 直接返回上次答案。语义缓存（embedding 距离 < 0.05 算同一 query）能把 hit rate 从 5% 拉到 20%+。

注意失效策略：金融场景 TTL 不能太长 (1h-1d)。

8.6 早终止 / Cost cap （收益 long tail 控制）

每个 query 设软 cap（$0.10）+ 硬 cap（$0.25）。实测 P99 cost 从 $1.02 → $0.31。

8.7 Token-aware Retrieval （收益 ~15-25%）

按 query 类型动态调 top_k：

而不是无脑 top_k=10。

8.8 Rate Limit Smoothing

避免突发 burst 触发 priority pricing。用 token bucket 平滑请求。次要但稳定收益。

8.9 综合实测

我的金融 agent v1.0 → v1.2 cost 从 $0.087 → $0.041, 降 53%。其中：

• prompt caching: -40%
• token-aware retrieval: -22%
• cost cap: -tail
• 三者复合（不是简单相加）

关键洞察：

Cost 优化的天花板是单条 query 的 marginal value。如果你的 query 给企业产生 $10 价值，花 $0.05 完全可以；如果你卖 $9.9/月 SaaS，每月用户产 100 query，单条就要 < $0.01。先算单位经济，再设计架构。

---

第 9 章 Latency 优化的 6 个技巧

用户感知的"慢"来自 TTFT (time to first token) + TPOT (time per output token) + tool wait。

9.1 Streaming （TTFT 的视觉解决）

Server-Sent Events 把 token 边生成边推到前端。用户感知 latency 从 10s 变 1s（虽然总时间不变）。

任何用户面对的 LLM 应用都应该开 streaming。这是 first-class UX 要求。

9.2 Speculative Decoding （30-50% TPOT 提升）

draft model (小模型，例如 Llama-1B) 快速猜 N 个 token → big model 一次 verify。Verify 通过则吃下，不通过回退。

vLLM、TensorRT-LLM 都支持。在自部署模型上效果最佳。

9.3 Parallel Tool Calls （Agent latency 减半）

让 LLM 一轮发起多个独立 tool call，asyncio 并发。

tool_uses = [b for b in resp.content if b.type == "tool_use"]
results = await asyncio.gather(*[run_tool(t) for t in tool_uses])

实测金融 agent: P50 11.4s → 5.9s（-48%）。

9.4 Sub-agent 并发

Multi-agent 架构中，独立 sub-agent 并发跑（researcher + chain_query + news 三个角色同时启动）。

9.5 Pre-fetching Context

预测下一步要的数据提前 fetch。例如用户搜了 "AAPL Q4"，预 fetch "AAPL Q3" 与 "MSFT Q4" 数据放 cache，等用户问对比时 0 延迟返回。

9.6 Edge Caching / CDN

embedding 向量、static knowledge 放 edge。Cloudflare Vectorize、Vercel KV 都支持。延迟从 100ms → 10ms。

9.7 综合实测

我的金融 agent v1.0 → v1.2 P50 从 11.4s → 5.4s, P95 从 38s → 19s。

关键洞察：

并行化是 latency 优化的"量级武器"。其他都是"百分比武器"。第一条 latency 优化建议永远是：能并行的都并行。

---

第 10 章 Safety & Guardrails 三层防御

LLM 应用上线遇到的事故 95% 在这 3 个方向：prompt injection、PII 泄露、合规违规。Safety 不是一个功能，是 day-1 设计。

10.1 三层防御总览

┌──────────── 用户输入 ────────────┐
│                                   │
│   ┌─────────────────────────┐    │
│   │ L1: Pre-prompt           │    │
│   │  - input sanitization    │    │
│   │  - intent classifier     │    │
│   │  - PII detection         │    │
│   │  - injection detection   │    │
│   └────────────┬────────────┘    │
│                │ pass             │
│                ▼                  │
│   ┌─────────────────────────┐    │
│   │ L2: Runtime              │    │
│   │  - policy filter         │    │
│   │  - tool whitelist        │    │
│   │  - rate limit            │    │
│   │  - constitutional self-  │    │
│   │    critique              │    │
│   └────────────┬────────────┘    │
│                │ pass             │
│                ▼                  │
│   ┌─────────────────────────┐    │
│   │ L3: Post-output          │    │
│   │  - PII redaction         │    │
│   │  - compliance check      │    │
│   │  - output classifier     │    │
│   └────────────┬────────────┘    │
└────────────────│──────────────────┘
                 ▼
            最终用户答案

10.2 L1: Pre-prompt 防御

经典坑：用 keyword blocklist。会误杀（参考 Day 179 Case 4），改用 intent classifier。

10.3 L2: Runtime 防御

NeMo Guardrails 的 Colang DSL 是写这层规则的好工具：

define user ask financial advice
  "should I buy AAPL?"
  "is BTC a good investment?"

define bot warn no advice
  "I can analyze data but cannot give personalized financial advice."

define flow advice safety
  user ask financial advice
  bot warn no advice

10.4 L3: Post-output 防御

金融场景特殊：如果输出涉及"buy/sell recommendation"，强制加 disclaimer。

10.5 红队测试

上线前必跑 200 条红队 case，目标 ASR (Attack Success Rate) < 5%。

工具：

• PyRIT (Microsoft)
• Garak (NVIDIA)
• 自写 + Anthropic constitutional 自动生成 attack

参考 Day 175 我的红队报告：从 ASR 18% → 4%。

关键洞察：

Safety 是层叠的。任何单层都会被 bypass。三层互补 + 红队验证才有意义。"我们用了 LLM Guard 所以 safe" 是错觉。

---

第 11 章 LLMOps 工具栈

把 60 天用过的 / 测过的工具按职能整理。

11.1 总览图

┌──────────── LLM Application ────────────┐
│                                          │
│  Prompt Mgmt → Langfuse / PromptLayer    │
│  Eval        → Ragas / TruLens / 自实现  │
│  Tracing     → Langfuse / Helicone /     │
│                LangSmith / OTel          │
│  Vector DB   → Pinecone / Weaviate /     │
│                Chroma / pgvector         │
│  Embedding   → OpenAI / Voyage / Cohere /│
│                BGE-M3 (self-host)        │
│  Reranker    → Cohere / Voyage /         │
│                BGE-reranker              │
│  Inference   → vLLM / TGI / SGLang       │
│  Agent FW    → 裸 SDK > LangGraph /      │
│                CrewAI / AutoGen          │
│  Guards      → LLM Guard / NeMo /        │
│                Presidio                  │
│                                          │
└──────────────────────────────────────────┘

11.2 Tracing：必备的"飞行记录仪"

没 tracing 你 debug 不了 LLM 应用。这是 day-1 必装。

对比：

我自己用 self-host Langfuse + OTel。Day 170 有完整接入指南。

11.3 Eval 工具

我的选择：自写 judge + Ragas 子集。原因：自由度高、不绑生态、可解释。

11.4 Prompt Versioning

• Langfuse Prompts (推荐)
• PromptLayer
• 简单方案：git 加 frontmatter

11.5 CI/CD for AI Products

# .github/workflows/ai-ci.yml
on: [pull_request]
jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - run: pytest tests/unit  # L1
      - run: python eval/run.py --subset smoke  # L2 30 cases
      - if: failure() then exit 1
  full-eval:
    if: github.event.pull_request.labels.*.name == 'eval-required'
    needs: smoke
    runs-on: ubuntu-latest
    steps:
      - run: python eval/run.py --full  # L3 100 cases
      - run: python eval/compare.py --base main  # 对比 baseline

11.6 A/B Testing for LLM Apps

工具：Statsig / GrowthBook / 自建 + Langfuse session tag。

关键差异（vs 传统 A/B）：

• conversion 信号弱（thumbs up/down rate 1-5%）→ 需要更长时间窗 + 更大流量
• LLM 回答 nondeterministic → 同 user 同 query 多次也不同 → bucket 在 query 维度而非 user
• 高方差 → 需要 multi-arm bandit 而非传统 t-test

关键洞察：

LLMOps 不是新发明的工程，是把 MLOps + APM + DevOps 三套合一。已经有 SRE 文化的团队迁移到 LLM 比从零起步快 5 倍。

---

第 12 章 Web3 × AI Agent 特殊考量

我同时学 Web3 和 AI 两条线，所以这里加一章合一。Web3 + Agent 现在很多团队在做（Virtuals / ai16z / Olas / Bittensor），但绝大多数把它当 web2+1 做，忽略链上特殊性。

12.1 链上数据集成

链上数据是 AI Agent 的"金矿"——public、可验证、time-series 完整。

实战：把 Dune query / Etherscan API 包装成 MCP tool 给 agent 使用。Day 156-159 详细。

12.2 x402 / Session Keys / Smart Account

关键基础设施，让 AI Agent 能安全地代表用户花钱/签 tx。

• x402：HTTP 402 Payment Required，agent 自动支付微小费用（每次工具调用 $0.001）。Coinbase 推动。
• Session Keys (ERC-7715)：临时密钥，限制权限范围（only swap < $100, only trusted contracts），过期自动失效。
• ERC-4337 / Smart Accounts：批量交易、社交恢复、agent 友好 abstractions。

无这三件事，Web3 Agent 等于"AI 拿你私钥裸奔"，一次 prompt injection 就清零。

12.3 Agent 经济模型

链上 Agent 三种价值捕获：

1. Agent token (Virtuals, ai16z 路线)
   - token = ownership / governance / fee share
   - 风险: 多数项目最终是 memecoin 包装

2. Pay-per-call (x402, Olas)
   - 每次 agent 调用 $0.0X
   - 风险: 用户算账难

3. AUM/AUC fee (DeFAI)
   - agent 帮你管理资产，按 AUM 收费
   - 风险: 信任最难

12.4 链上 Agent 合规

• 美国 SEC 对 AI 提供 investment advice 已有 enforcement (2024-2025)
• EU AI Act 把 financial advice agent 列为 high-risk
• KYC: 链上 agent 与 fiat off-ramp 触合规

设计 agent 时必加 disclaimer + 不做"个性化投资建议"。

12.5 Web3 Agent 的特殊 eval

关键洞察：

Web3 + AI 看似 1+1，实际是 1+1=3 的复杂度。链上的可验证性是 AI 输出 grounding 的最强武器（每个数字都能 trace 到 block），但合规与安全也叠加了。先把 Web2 AI agent 做扎实，再加链上——绝大部分 Web3 AI 项目栽在没有 eval 体系。

---

第 13 章 团队组成与开发流程

10 人以下的 AI 产品团队应该如何组？

13.1 角色

反模式：让 AI Researcher 同时做 engineer + eval + PM。一开始可以，规模化必失败。

13.2 与传统 ML / 工程团队的差异

LLM 工程师 ≠ ML 工程师，也 ≠ 普通后端工程师。是新工种，靠 60-90 天专项学习训练出来。

13.3 6 阶段开发节奏

阶段 1: Discovery (1-2 周)
  - 用户访谈
  - 写 PRD (含 5-10 条 example query)
  - 选模型 (Section 2)
  - 评估 RAG vs FT vs prompt (Section 4)
  - 写 30 条 golden seed

阶段 2: Prototype (2-3 周)
  - Naive 实现
  - 跑 30 条 → 找到主要失败模式
  - 决定 architecture (workflow / agent / RAG L?)

阶段 3: Hardening (3-4 周)
  - 扩 golden 到 100+
  - 接 tracing
  - 写 L1/L2 防御
  - 做 prompt cache + parallel

阶段 4: Eval & Optimize (2-3 周)
  - L3 完整 golden 跑
  - cost / latency 优化
  - LLM judge + inter-judge 校准

阶段 5: Red Team (1-2 周)
  - 200 条红队 case
  - 修漏洞至 ASR < 5%

阶段 6: Launch & Iterate (持续)
  - canary 5% → 50% → 100%
  - 用户反馈 → golden 回写
  - 月级 review

总周期：3-4 个月达到 L4 成熟度。

13.4 给 PM/架构师的特别建议

来自我自己 10 年金融零售 PM 的经验，加 60 天 AI 学习：

• 学会读论文：每周至少 1 篇 (Anthropic / OpenAI / DeepMind blog 优先)
• 学会读 trace：能从一条 Langfuse trace 看出 cost / latency / 错误来源
• 学会写 eval rubric：rubric 写不清，judge 必有偏
• 学会与 researcher 沟通：用"failure case"语言而不是"我觉得"语言
• 学会算单位经济：每条 query 多少钱、多少 ROI

关键洞察：AI 产品的 PM 比传统 PM 需要更深的技术理解，否则会被 researcher 牵着走、被工程牵着走、被用户牵着走。

---

第 14 章 展望与开放问题

诚实记录本方法论的边界和我对未来的看法。

14.1 Agent 的 Scaling Laws 尚未明确

我们知道 LLM 有 scaling law (Chinchilla, Hoffmann 2022)；但 Agent 复杂度 vs 性能 的曲线还没人画清楚。

• 加更多 tool → 一开始线性提升，到某个点反而下降（tool 选错率上升）
• 加更深的 plan → 同上
• 加更多 sub-agent → 协调成本平方级

我的猜测（非定论）：

• 单 agent 最优 tool 数 ~5-8
• Plan 最优深度 ~3-5 步
• Multi-agent 最优 sub-agent ~3-5 个

但这些都是直觉，没有 paper 能给确定答案。

14.2 Multi-Agent 协调的开放问题

• Agent 之间的通信协议没有标准（A2A、ACP、Coral 等都有提议但未收敛）
• Memory sharing 怎么做（每个 agent 自己 memory？共享？）
• 失败传染怎么 contain
• 调度 (orchestrator) 是 LLM 还是 deterministic 更好？

我认为 2027-2028 才会出现成熟的 multi-agent 框架。现在做 multi-agent debate 的论文都偏 demo。

14.3 安全 / 对齐的工程化路径

学术界 (Anthropic, DeepMind, MIRI) 在做对齐研究；工程界还在用 prompt 防御。中间巨大的 gap：

• 如何把"宪法 AI"工业化
• 如何低成本验证 safety property
• 如何在 finetuning 时保留 safety
• 如何应对 supply chain attack（prompt injection 通过文档进来）

这些题 5-10 年都未必解决。工程界的理性立场：layered defense + red team + monitoring + incident response，不奢求"绝对安全"。

14.4 GPU 价格 / 推理价格曲线

过去 2 年单 token 价格降 95% (从 GPT-4 launch 价到 Sonnet 4.5 价)。预计未来 2 年再降 80%。意味着今天觉得太贵的 use case 明年大概率可行。在架构设计时预留 cost-down 空间（不要把成本结构死锁在 expensive 模型上）。

14.5 监管的影响

• EU AI Act 2025 全面生效，high-risk 类应用合规成本大增
• 美国 Executive Order on AI 持续演进
• 中国生成式 AI 服务管理办法已落地

对工程的影响：

• 训练数据透明度
• 输出可解释性
• 关键决策必有人在 loop
• 数据本地化 (中国 / 欧盟)

设计架构时为这些预留：hot-swappable 模型、可审计 trace、可解释 reasoning step、可禁用 user data。

14.6 哪些技术我故意没写

• Distillation / quantization (太底层，不属于应用层)
• 多模态深入 (vision / audio agent，会单出方法论)
• 强化学习 fine-tune (RLHF / DPO，门槛高，绝大多数团队不需要)
• AutoML / neural architecture search

这些都重要，但属于另一份方法论。

---

附录 A. 工具链推荐表

每类工具我推荐 1 个默认 + 1 个备选，避免选择瘫痪。

---

附录 B. 关键 Prompt 模板

B.1 LLM-as-Judge (Faithfulness)

SYSTEM: You are a strict factuality auditor.

INPUT:
- USER_QUERY
- AGENT_ANSWER
- TOOL_TRACE (JSON list of tool calls and outputs)

For each numeric / entity claim in AGENT_ANSWER:
1. Find a citation in TOOL_TRACE.
2. Verify the citation actually supports the claim.
3. If absent or mismatched, list under "issues".

Numerical tolerance: 1%. Date tolerance: exact period.
Output: strict JSON.

{
  "claims": [{"claim": "...", "cited": bool, "supported": bool}],
  "faithfulness_score": float [0,1],
  "critical_errors": [string]
}

B.2 LLM-as-Judge (Pairwise Quality)

SYSTEM: You compare two answers (A, B) to a query.
Rate which is better on:
  - correctness
  - completeness
  - clarity
  - useful brevity (NOT verbose-favored)

Length is NOT a signal. Position is randomized.

Output JSON:
{
  "winner": "A"|"B"|"tie",
  "reasons": [string],
  "confidence": float [0,1]
}

B.3 ReAct Loop System Prompt

You are a financial research agent. Use the following tools:
{tools_doc}

Format your reasoning as:
Thought: <what you need to figure out>
Action: <tool_name(args)>
Observation: <will be filled by tool>
... (repeat as needed)
Final Answer: <answer with citations>

Rules:
- After 3 retrievals on same topic, synthesize with available info.
- Always cite tool_call_N.output for every numeric claim.
- If tool data is older than 24h, prefix answer with [stale data].
- Refuse to give personalized investment advice; provide analysis only.

B.4 Plan-and-Execute Planner Prompt

You are a planner. Given a query, output a JSON plan.

Schema:
{
  "steps": [
    {"id": int, "task": string, "tool": string|null,
     "depends_on": [int], "parallelizable_with": [int]}
  ],
  "synthesis_strategy": string
}

Rules:
- Maximum 5 steps; if more needed, use sub-tasks.
- Mark independent steps as parallelizable.
- Last step is always synthesis.

B.5 Self-Critique (Constitutional)

You are a critic. Given DRAFT_ANSWER and TOOL_TRACE, find:
- Numeric claims without citation
- Claims contradicting TOOL_TRACE
- Speculation framed as fact
- Missing disclaimers (advice / risk)
- PII leak

Output:
{
  "issues": [{"type": string, "severity": "low|med|high",
              "fix_suggestion": string}],
  "rewrite_required": bool
}

B.6 Intent Classifier (for input guard)

Classify user query into:
{
  "intent": "explain"|"how_to"|"attempt"|"casual",
  "topic": string,
  "risk": "low"|"med"|"high",
  "reason": string
}

High-risk topics: insider_trading, market_manipulation,
illegal_activities, identity_theft, personal_advice_finance.

Block only when intent in {how_to, attempt} AND risk = high.

---

附录 C. 推荐阅读

C.1 论文（必读 10 篇）

1. Attention Is All You Need — Vaswani 2017 (Transformer 起点)
2. ReAct — Yao 2022 (Reason + Act)
3. Constitutional AI — Bai (Anthropic) 2022
4. Chain-of-Thought — Wei 2022
5. Self-Consistency — Wang 2022
6. Toolformer — Schick 2023
7. Lost in the Middle — Liu 2023 (长 context 真相)
8. HyDE — Gao 2022 (RAG query rewrite)
9. Reflexion — Shinn 2023 (self-reflection)
10. Anthropic Engineering blogs — 整个 2024-2025 系列

C.2 工程类（必读 5 篇）

1. Anthropic — Building Effective Agents (2024 blog)
2. OpenAI — Practices for Governing Agentic AI (2024)
3. Eugene Yan — Patterns for Building LLM-based Systems & Products
4. Hamilton's Building Great LLM Apps series
5. AI Engineering by Chip Huyen (2024 book)

C.3 课程（自学路径）

• Andrej Karpathy — Neural Networks Zero to Hero
• DeepLearning.AI — Building Systems with the ChatGPT API
• Anthropic — Skilljar 课程
• LangChain Academy (优缺点都有)

C.4 社区 & 持续追踪

• Anthropic Engineering blog
• OpenAI Cookbook
• LangChain blog (尽管有偏，仍信息密集)
• Hacker News [LLM] tag
• /r/LocalLLaMA
• Twitter: @karpathy, @swyx, @hwchase17, @amjadmasad, @hamel_hussain

---

结语

这份方法论花了我 60 天系统学习 + 1 个完整生产 agent 闭环试错。回头看，最重要的不是任何单一技术（cache / RAG L4 / multi-agent），而是 6 条总原则 + 4 层 eval 防线 + 失败 case 复盘文化。

如果你只能从这份文档带走一句话：

AI 工程的差距不在"会不会写 prompt"，在"有没有 eval 体系"。

如果是两句话，再加一句：

从 demo 到生产，90% 的提升来自工程化决策，10% 来自模型/prompt 的"魔法"。

剩下的就是反复的 build → eval → optimize → ship 循环。

---

版本: v1.0 字数: ~22 页 (~1700 行) 作者: 基于 Phase 3 (Day 121-179) 学习与一个生产级金融 Agent 项目总结 许可: 个人作品集；引用请注明出处 联系: 见仓库 README 下次更新: v1.1 计划 2027 Q1，将加入：vision agent / 多模态 / on-device LLM / Web3 agent 经济实测数据