Agent 框架 · LangChain / LangGraph / AutoGen / CrewAI

🏠 返回 README ｜ ⬅️ 02-RAG检索增强-向量库与Chunking.md ｜ ➡️ 01-AI辅助开发-Cursor-Copilot与Claude-Code.md
风格说明 ：本篇是 设计型 ------沿「框架抽象 → 编排范式 → 状态图 → 工具契约 → 生产陷阱」展开 L1→L4；不重复 RAG 索引细节与 Playbook checklist，分别见 02-RAG检索增强-向量库与Chunking.md 与 02-Agent工程实践-生产落地Playbook.md。

前置阅读 ：01-Prompt工程-Few-Shot-CoT与Tool-Use.md（ReAct / Tool Use / Plan-and-Execute 模式底座）。 后续展开 ：02-Agent工程实践-生产落地Playbook.md（12 能力域落地）、01-Spring-AI与LangChain4j.md（Java 栈等价物）、04-Agent参考架构-Staff级多视图设计.md（七视图白板母题）。

官方对照（编写依据）

组件	官方文档	本篇边界
LangChain / LangGraph	LangChain Docs · LangGraph Interrupts · PostgresSaver	生产 HITL 用 `interrupt()` + `Command(resume=...)` ；`interrupt_before` 仅调试断点
AutoGen	microsoft/autogen（maintenance）	新项目见 Microsoft Agent Framework
CrewAI	docs.crewai.com	Role/Task/Crew 抽象
MCP	modelcontextprotocol.io	工具发现与传输

L1 · 是什么 · Agent 框架的工程定位

1.1 一句话定义

Agent 框架 ：在 LLM 之上提供 状态机 / 消息总线 / 工具注册 / 人机协同（HITL）/ 可观测 trace 的编排层，把「多步推理 + 副作用工具调用」从 prompt 字符串升级为 可测试、可熔断、可回放 的控制器。

1.2 Agent vs Chatbot vs Workflow

维度	Chatbot（单轮）	Workflow（DAG）	Agent（有界循环）
步骤数	1	固定 N	动态 N（有上限）
工具	可选 0--1 次 RAG	每节点预绑定	运行时选 tool
状态	无 / 仅 session	引擎持久化	显式 state + checkpoint
失败模式	答错一句	节点失败重试	循环、成本爆炸、幂等写重复
支付场景	FAQ 检索	KYC 固定表单	退款研判、对账、工单升级

支付域铁律 ：涉及 资金写操作（退款、代扣、调账） 的节点必须在框架层挂 HITL + 幂等键 + 风险分级，不能只在 system prompt 里写「请勿擅自退款」。

1.3 四大框架一张表（2025--2026 生产口径）

框架	核心抽象	甜区	支付/电商典型用法	主要风险
LangChain	Runnable / LCEL 链	快速原型、RAG 链、单 Agent	Payment FAQ = RAG chain + 可选 1 tool	抽象层过厚、版本碎
LangGraph	StateGraph + checkpoint	生产编排、HITL、可恢复	Refund Agent 状态机、L2/L3 审批边	图设计复杂、需懂 reducer
AutoGen	多 Agent 对话 / GroupChat	研发协作、代码生成、辩论式规划	对账助手 + 审计 Agent 双角色	官方 maintenance ；新项目用 Agent Framework
CrewAI	Role + Task + Crew	营销文案、报告生成、角色分工	运营周报、非资金类 SOP	不适合资金写路径

flowchart TB subgraph l1 [LangChain 层] LC[LCEL / Runnable] LC --> RAG[RAG Retriever Chain] LC --> AgentLC[AgentExecutor 旧形态] end subgraph l2 [LangGraph 层] SG[StateGraph] SG --> CP[Checkpoint Postgres] SG --> HITL[interrupt() HITL 节点] end subgraph l3 [多 Agent 层] AG[AutoGen GroupChat] CR[CrewAI Crew] end User[用户 / 事件] --> GW[API Gateway] GW --> SG GW --> LC SG --> Tools[Payment / Order / RAG Tools] LC --> Tools

1.4 为什么支付域不能「裸 prompt 循环」

text 复制代码

裸 while-loop Agent（反模式）:
  while not done:
      response = llm.chat(history + tools)
      if tool_call: execute(tool)
      history.append(response)

缺失能力:
  - 无 checkpoint → HITL 等待 4h 后 worker 重启丢上下文
  - 无 max_step 硬熔断 → 大促 1% 会话陷入 20 轮 = 8 QPS 占满池
  - 无 reducer → messages 线性膨胀，第 12 轮 input 80k tokens
  - 无 interrupt 钩子 → L3 退款无法接工单系统
  - 无 trace 逐步 span → 重复退款 MTTR 以小时计

框架的价值不是「少写 50 行 Python」，而是把 Staff 答辩能画出来的控制流 变成 可版本化、可 diff、可 eval 的图。

L2 · 原理与编排 · ReAct、Plan-Execute、StateGraph、Tool Calling

2.1 ReAct vs Plan-and-Execute（支付域选型）

范式	控制流	Token / 延迟	可解释性	支付推荐
ReAct	Thought → Action → Observation 循环	每步全上下文，步数×成本	轨迹可读	L1 FAQ 辅助、 exploratory 查单
Plan-and-Execute	先 Plan（子目标列表）再逐步 Execute	Plan 一次，执行可换小模型	Plan 可审计	退款、对账、争议处理
DAG Workflow	无 LLM 或固定节点	最低	最高	幂等 API 编排、状态机已知

量化账本（GPT-4o 级，单笔 Agent 任务）：

text 复制代码

Payment FAQ（RAG only）:
  - 1× LLM 8k in + 500 out ≈ $0.03--0.05 / 请求
  - P95 延迟 1.2--2.5s（含向量检索 80--200ms）

Refund Agent（Plan-Execute + 3 tools + HITL）:
  - Plan: 1× 6k in + 800 out
  - Execute: 3× (4k in + 300 out) + 1× HITL 等待（不计 token）
  - 合计 ≈ $0.12--0.22 / 成功路径；失败重试 ×1.5 常见
  - 必须设 max_iterations=8、max_tool_calls=12

ReAct 无界（反例）:
  - 15 轮 × 平均 5k in ≈ 75k input tokens → $0.35+ 且 45s+ 延迟
  - 大促客服峰值 800 QPS → 若 1% 陷入循环 ≈ 8 QPS 长任务拖垮池化

sequenceDiagram participant U as User participant O as Orchestrator participant P as Planner LLM participant E as Executor LLM participant T as PaymentTool participant H as HITL Queue U->>O: 申请退款 orderId=O123 O->>P: 生成 Plan 子步骤 P-->>O: 1查订单 2查支付 3规则匹配 4建议金额 O->>E: Step1 查订单 E->>T: get_order(O123) T-->>E: status=SHIPPED amount=299 E-->>O: observation O->>E: Step2 查支付 E->>T: get_payment(O123) T-->>E: captured=true channel=WECHAT O->>H: interrupt L3 退款金额>200 H-->>O: approve refund=299 O->>T: create_refund idempotent_key=IK-uuid T-->>U: refund_id=R456

异常路径（Staff 必画）：

sequenceDiagram participant O as Orchestrator participant T as PaymentTool participant CB as CircuitBreaker participant H as HITL O->>T: create_refund(timeout=300ms) T-->>O: 504 Gateway Timeout Note over O: ReAct 反模式: 同 Action 重试无幂等键 O->>CB: record_failure CB-->>O: open after 3 failures O->>H: escalate L2 人工结案 H-->>O: manual_refund ticket=TK-889 Note over O: LangGraph 正解: checkpoint 保存,<br/>写 tool 仅单节点 + 幂等键

2.2 LangGraph StateGraph 机制（Staff 必讲清）

StateGraph = 有向图 + 共享 state 字典 + reducer 合并节点输出 + conditional_edges 路由。

概念	含义	支付实现要点
`State`	TypedDict / Pydantic，字段如 `messages`, `order_id`, `risk_level`	资金字段用强类型，禁止自由文本解析金额
`node`	纯函数 `(state) -> partial_state`	副作用放 tool node，不在 planner node 写库
`reducer`	`messages` 常用 `add_messages`	控制 history 长度，避免 context 爆炸
`checkpoint`	每 super-step 持久化	审批等待 24h 后 resume 不重放全链
`interrupt()`	节点内动态暂停，resume 用 `Command`	L2/L3 生产 HITL （官方推荐）
`interrupt_before`	compile 时静态断点	仅调试/单步；官方不推荐用于 HITL

stateDiagram-v2 [*] --> intake: 用户意图 intake --> classifyRisk: NLU+规则 classifyRisk --> L1auto: risk=L1 classifyRisk --> L2review: risk=L2 classifyRisk --> L3block: risk=L3 L1auto --> planNode: Plan L2review --> hitlL2: 人工坐席 L3block --> hitlL3: 资深风控 hitlL2 --> planNode: 批准 hitlL3 --> planNode: 批准 planNode --> toolOrder: get_order toolOrder --> toolPay: get_payment toolPay --> policyCheck: 规则引擎 policyCheck --> toolRefund: create_refund toolRefund --> [*]: 完成 policyCheck --> deny: 拒绝 deny --> [*]

与 LangChain AgentExecutor 对比 ：AgentExecutor 把循环藏在类里；LangGraph 把每条边显式化 ------适合 Staff 答辩「你如何证明不会无限循环」：图上 max_step + 边条件 + 全局 token budget。

2.2.1 Refund Agent 图骨架（伪代码）

python 复制代码

from typing import Annotated, Literal, TypedDict
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.prebuilt import ToolNode
from langgraph.types import interrupt, Command

class RefundState(TypedDict):
    messages: Annotated[list, add_messages]
    order_id: str
    risk_level: Literal["L1", "L2", "L3"]
    plan_steps: list[str]
    refund_cents: int | None
    hitl_ticket: str | None
    step_count: int
    trace_id: str

def classify_risk(state: RefundState) -> RefundState:
    # 规则引擎 + 小模型；金额/跨境/欺诈信号 → L1/L2/L3
    ...

def plan_node(state: RefundState) -> RefundState:
    # Plan-and-Execute：输出固定 schema plan_steps
    ...

def policy_check(state: RefundState) -> RefundState:
    # 确定性代码：max_refund_cents、订单状态机
    ...

def route_after_policy(state: RefundState) -> str:
    if state.get("deny_reason"):
        return "deny"
    if state["risk_level"] in ("L2", "L3"):
        return "hitl"
    return "create_refund"

def hitl_node(state: RefundState) -> RefundState:
    # interrupt 返回后 human 输入写入 state
    approval = interrupt({"ticket": state["hitl_ticket"], "amount": state["refund_cents"]})
    return {"hitl_approved": approval["approved"], "refund_cents": approval["amount_cents"]}

graph = StateGraph(RefundState)
graph.add_node("classify", classify_risk)
graph.add_node("plan", plan_node)
graph.add_node("tools", ToolNode([get_order, get_payment, create_refund]))
graph.add_node("policy", policy_check)
graph.add_node("hitl", hitl_node)
graph.add_conditional_edges("policy", route_after_policy, {"hitl": "hitl", "create_refund": "tools", "deny": END})
graph.set_entry_point("classify")
# 生产 HITL：节点内 interrupt()；勿用 interrupt_before（静态断点，仅调试）
app = graph.compile(checkpointer=PostgresSaver(conn))

Checkpoint resume 语义：

text 复制代码

thread_id = f"user:{uid}:session:{sid}"
config = {"configurable": {"thread_id": thread_id}}

# 用户提交退款 → 图运行至 hitl_node 的 interrupt() → 持久化 checkpoint
app.invoke(input, config)

# 4h 后坐席批准 → 同一 thread_id，用 Command(resume=...) 续跑
app.invoke(Command(resume={"approved": True, "amount_cents": 29900}), config)

2.3 Tool Calling：Function Calling vs ReAct 文本

方式	协议	模型要求	生产建议
OpenAI Function Calling	JSON schema，`tool_calls[]`	GPT-4o / Claude 3.5+	默认：解析稳定、易 schema 校验
ReAct 文本	`Action: tool\nAction Input: {...}`	弱模型也可	调试 / 可解释 demo；需 regex 容错
MCP	标准工具发现 + SSE	跨 IDE / Agent	支付工具暴露走内网 MCP Server + mTLS

工具契约四件套（支付）：

幂等：create_refund(idempotency_key)，key 由 order_id + reason_code + window 派生；
最小权限 ：Tool scope = refund:read vs refund:write 分拆；
输出 schema 固定 ：金额 int cents，禁止 LLM 口算「退 299.00」；
超时与熔断：单 tool P99 300ms，连续失败 3 次 → 降级人工。

flowchart LR LLM[LLM] -->|tool_calls JSON| Router[Tool Router] Router --> AuthZ[OPA / 内部鉴权] AuthZ --> PayAPI[Payment Core API] AuthZ --> OrderAPI[Order Service] Router --> RAGTool[RAG FAQ Tool] RAGTool --> VDB[(Vector DB)] PayAPI --> Audit[Audit Log + Trace]

Tool 定义示例（OpenAI schema）：

json 复制代码

{
  "name": "create_refund",
  "description": "Create refund for captured payment. Amount must come from policy engine.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "pattern": "^O[0-9]{10}$"},
      "refund_cents": {"type": "integer", "minimum": 1},
      "reason_code": {"type": "string", "enum": ["QUALITY", "LATE_SHIP", "DUPLICATE"]},
      "idempotency_key": {"type": "string", "maxLength": 64}
    },
    "required": ["order_id", "refund_cents", "reason_code", "idempotency_key"]
  }
}

2.4 LangChain vs LangGraph vs AutoGen vs CrewAI（架构师选型）

结论先行：

资金路径、需 HITL、需 checkpoint → LangGraph（可嵌在 LangChain 生态）；
单域 FAQ、检索+一次生成 → LangChain LCEL 足够，见 03；
多角色辩论、研发自动化 → AutoGen；
无写操作的内容生产 → CrewAI。

面试反常识	纠正
「LangChain = Agent」	LangChain 是组件库；Agent 是其中一种 Runnable
「AutoGen 适合生产支付」	对话式多 Agent 难设硬边界，资金写应 LangGraph + 单执行器
「CrewAI 能编排退款」	Role 分工无强状态机与幂等，仅适合非资金 SOP
「Plan-Execute 一定更省」	Plan 漂移时需 re-plan；要 North Star + 步级 verify

维度	LangChain	LangGraph	AutoGen	CrewAI
状态持久化	需自建	一等 checkpoint	会话级	弱
HITL	需自建	interrupt	人工 Agent 模拟	无原生
多 Agent	有限	子图 / Send	GroupChat 核心	Role 核心
生产案例密度	高（RAG）	高（编排）	中（研发）	中（内容）
学习曲线	中	高	中	低
支付写操作	不推荐单独用	推荐	禁用在线	禁用

2.5 支付域三场景映射

2.5.1 Refund Agent（LangGraph + Plan-Execute）

text 复制代码

State 字段示例:
  order_id: str
  risk_level: Literal["L1","L2","L3"]
  plan_steps: list[str]
  refund_cents: int | None
  hitl_ticket: str | None
  trace_id: str

边条件:
  risk_level in {L2,L3} → hitl_node 内 interrupt()，审批后 Command(resume)
  policy_engine.deny → END with reason_code
  step_count >= max_iterations → END escalate_human

2.5.2 Payment FAQ（LangChain LCEL + RAG Tool）

不做 Agent 循环 ：retrieve → rerank → generate，工具 0--1 次；
检索链路与 chunk 策略见 03 §5--§8；
幻觉防线：强制 citation[]，无检索命中 → 拒答模板。

python 复制代码

# LangChain LCEL --- Payment FAQ（无 Agent 循环）
faq_chain = (
    {"context": retriever | rerank_top5, "question": RunnablePassthrough()}
    | prompt_template
    | llm.with_structured_output(FaqAnswer)  # citations + confidence
    | guardrails_refuse_if_low_confidence
)

2.5.3 HITL 分级（L2 / L3）

级别	触发条件	框架行为	SLA
L1	金额 < 50 且规则命中自动退	无中断，全链路 < 5s	自动
L2	50--500 或首次争议	`interrupt` → 坐席工作台	15 min
L3	>500 / 可疑欺诈 / 跨境	资深风控 + 二次审批	4 h

实现：langgraph.types.interrupt + 外部 Case Management；禁止用 time.sleep 阻塞 worker。

text 复制代码

HITL 集成模式:
  1. interrupt 抛出 → API 返回 202 + ticket_id
  2. 工单系统 UI 展示 state 快照（order_id, 建议金额, 轨迹链接）
  3. 人工批准 → webhook 调 resume API，携带 thread_id + approval payload
  4. 图从 checkpoint 续跑 create_refund 单节点

L3 · 边界与陷阱 · 无限循环、成本、版本与竞品

3.1 生产七大坑（带数字）

#	现象	根因	量化影响	修复
1	无限 ReAct 循环	无 `max_iterations`、无「完成」判定	单会话 $0.5--2、60s+	图上加 `END` 条件 + 步数熔断
2	重复退款	Tool 无幂等、retry 重放	资损直接	`idempotency_key` + 状态机 `REFUNDING`
3	Context 爆炸	全量 messages 追加	第 10 步 input 80k+	`trim_messages` + 结构化 state
4	Plan 漂移	未绑定 North Star	查单变「劝用户放弃」	Plan 后 policy_check 硬规则
5	Tool 幻觉参数	LLM 编造 orderId	错单退款	schema 校验 + 存在性检查
6	RAG 间接注入	FAQ chunk 含恶意指令	绕过护栏	检索后 chunk 消毒 + 分隔符
7	观测缺失	无 trace_id	MTTR 小时级	Langfuse / OTel 逐步 span

3.2 无限循环：三类根因与框架层对策

flowchart TD Loop[会话陷入循环] --> R1{模型不输出 FINISH?} R1 -->|是| F1[加 structured output<br/>done=true 字段] R1 -->|否| R2{Observation 无信息量?} R2 -->|是| F2[tool 返回结构化 error_code<br/>禁止空字符串] R2 -->|否| R3{边条件缺失?} R3 -->|是| F3[显式 END 边 + step_count>=N] F1 --> Guard[全局 token_budget 熔断] F2 --> Guard F3 --> Guard Guard --> Human[降级 HITL / RAG-only]

循环类型	典型症状	检测指标	框架对策
工具空转	同一 tool 连续 5 次	`tool_repeat_rate`	同参去重 + 换策略边
Plan 死磕	replan 超 3 次仍失败	`replan_count`	硬上限 → HITL
模型自嗨	无 tool 纯文本 8 轮	`text_only_turns`	max_iterations + 拒答

3.3 成本治理参数（可直接写进配置）

yaml 复制代码

agent:
  max_iterations: 8
  max_tool_calls_per_turn: 4
  token_budget_per_session: 32000
  token_budget_daily_per_user: 200000
  model_routing:
    plan: gpt-4o
    execute: gpt-4o-mini
    classify: gpt-4o-mini
  circuit_breaker:
    error_rate_threshold: 0.15
    window_seconds: 60
    cooldown_seconds: 120

FinOps 指标 ：$/successful_task（不是 $/1k tokens）；支付客服目标 < $0.08/解决∗∗（FAQ），退款∗∗<0.08 / 解决**（FAQ），退款 **<$ 0.08/解决∗∗（FAQ），退款∗∗<0.25 / 结案（含 HITL 人力另算）。

3.4 框架版本与依赖陷阱

LangChain 0.1 → 0.2+ 大迁移：旧 AgentExecutor 示例泛滥，生产新项目 直接 LangGraph；
Python GIL ：高 QPS 用 多 worker + 异步 IO，重 CPU 工具放 sidecar；
Java 栈 ：Spring AI / LangChain4j 对标见 14，State 机可用 Spring Statemachine + AI 节点。

3.5 与 Dify / 低代码边界

Dify Workflow：固定 DAG 适合运营配置 FAQ；
资金 Agent：代码级 LangGraph + PR 评审 + 轨迹 eval（06）；
迁移路径：Dify 验证 prompt → 导出 DSL → 工程师落 LangGraph（16）。

L4 · 架构师视角 · 控制面、落地清单与坐标系

4.1 三层平面（对齐 Playbook）

flowchart TB subgraph control [控制面] IAM[IAM / 租户] Policy[风险策略 L1-L3] Budget[Token 预算] HITL[HITL 工单] end subgraph data [数据面 LangGraph] Planner[Planner] Executor[Executor] Tools[Tools] end subgraph obs [观测面] Trace[OpenTelemetry] Eval[Trajectory Eval] Cost[Cost Ledger] end User --> IAM IAM --> Planner Policy --> Planner Budget --> Executor Planner --> Executor Executor --> Tools Tools --> Trace HITL -.-> Executor

详表见 13 §0------本篇只强调 框架选型服务于控制面，而非反过来。

4.2 Payment FAQ × Refund Agent 双链架构

flowchart TB subgraph faq [FAQ 链 LangChain LCEL] Q1[User Query] --> R1[Retrieve Top20] R1 --> RR[Rerank Top5] RR --> G1[Generate + Citation] end subgraph refund [Refund 链 LangGraph] Q2[Refund Intent] --> C[classify L1-L3] C --> P[Plan] P --> X[Tools + Policy] X --> H[HITL L2/L3] H --> W[create_refund] end Router{Intent Router} --> faq Router --> refund

Router 用小模型 + 规则：refund|退货|争议 → refund 图；否则 FAQ。误路由代价高 → 低 temperature + 人工纠错回流训练。

4.3 上线 Checklist（框架层 15 项）

5. 真实事故复盘（电商交易 · 支付客服 Agent）

5.1 STAR-M-P

S (Situation) ：某跨境支付平台大促次日，Payment FAQ + Refund Agent 灰度 5% 流量；峰值 1.2k Agent QPS ，客诉「退款慢 / 重复到账」上升；财务对账发现 23 笔重复退款 ，合计 ¥47,200 ，时间窗 14:00--16:30。
T (Trigger) ：14:12 监控 agent.tool_calls 环比 ×3.4；14:18 payment.refund.duplicate_idempotency 告警；14:25 客服班长反馈「AI 一直说正在处理」。
A (Approach)：
1. 用 trace_id 抽样 20 条失败会话 → 发现 ReAct 路径 在 create_refund 超时后 自行重试 同一 Action，未带幂等键；
2. 对比 LangGraph 路径（已灰度 5%）→ 无重复，说明 编排层差异 非支付核心 BUG；
3. 查 token 曲线 → 循环会话 平均 14 轮 / 72k input tokens ，是正常 FAQ 的 11×；
4. 核对发布记录 → 前日将 max_iterations 从 6 提到 20「提高成功率」，与循环共振；
5. RAG 侧并行查 03 索引 → 非主因（退款走 tool 非 FAQ）。
R (Resolution)：
- 止血（30 min） ：全量 max_iterations=6；关闭 ReAct 路径 feature flag，100% LangGraph ；支付 API 侧启用 24h 幂等窗口 硬拦截；
- 根治（2 周） ：退款迁 Plan-Execute + interrupt L2/L3 ；create_refund 仅 LangGraph 单节点调用；轨迹 eval 新增 「tool 超时不得重试写」 50 case；上线 ** $/task∗∗告警>/task** 告警 >$ /task∗∗告警>0.35。
M (Metrics) ：重复退款 0 （连续 90 天）；Agent 循环率 8.1% → 0.4% ；P95 延迟 38s → 6.2s （退款路径）；单会话 token −62% ；$/successful_refund $0.41→0.41 →$ 0.41→0.19（不含人力）。
P (Prevention) ：框架变更入 checklist （13 §16）；所有 write tool PR 必附 幂等单测 ；每周 轨迹 diff 回归；Architect 评审禁止「为提高成功率」单方面放宽迭代上限。

6. 真实面试现场题（5 道带公司风格标记）

6.1 🟧 阿里 --- LangChain vs LangGraph 生产怎么选？支付退款 Agent 如何画状态图？

(1) 标准答案

资金副作用路径用 LangGraph StateGraph + checkpoint + interrupt HITL ；FAQ 用 LangChain LCEL + RAG 即可。LangChain 是组件库，不是生产编排终点；退款必须显式边、幂等 tool 节点、L2/L3 中断，拒绝 AgentExecutor 黑盒循环。

(2) 原理 walk

定义 RefundState：order_id, risk_level, plan_steps, refund_cents, messages；
节点：classify_risk → plan → get_order → get_payment → policy_check → create_refund；
条件边：risk_level in {L2,L3} → hitl 节点内 interrupt()，审批后 Command(resume=...)；
Reducer：messages 用 add_messages，并行字段用 last_value；
Checkpoint：Postgres thread_id 对应用户会话，审批后 invoke(None, config) resume。

text 复制代码

选型决策:
  有 write + 需审批 + 需 resume? → LangGraph
  仅 retrieve + generate? → LCEL
  多角色内容协作无 write? → CrewAI / AutoGen

(3) 权衡与量化数字

LangGraph 研发成本 +30% 首版，但 MTTR −50%（边可见）；
退款 P95：6s （Graph）vs 38s（无界 ReAct 循环样本）；
Checkpoint 存储：~2KB/step ，1w 并发日增 ~500MB（可 TTL 7d）。

(4) 落地清单

监控	阈值	配置
`agent.graph.step_count`	p99 > 10 告警	`max_iterations=8`
`agent.hitl.wait_seconds`	L2 > 900s	工单 SLA
`payment.refund.duplicate`	> 0 页级	幂等键强制
`$/successful_refund`	> $0.30	模型降级 mini

回滚：feature flag refund_graph_v2 → v1 DAG。

(5) 追问

Q：Plan 漂移怎么办？

A ：Plan 后加 deterministic policy_check（金额上限、状态机）；漂移率 >5% 触发 re-plan 上限 2 次，仍失败 → HITL。
Q：Java 栈不用 Python？

A ：Spring AI + 自建 Statemachine 同构；LangGraph 是参考实现，边界在 状态持久化与 HITL，不在语言。
Q：与 Seata 分布式事务？

A ：Agent 不替分布式事务；create_refund 走支付核心 TCC/本地消息表 ；Agent 只发起 一次幂等调用。

6.2 🟦 字节 --- ReAct 和 Plan-Execute 哪个更省 Token？什么时候会反噬？

(1) 标准答案

简单多 tool 探索 ReAct 省在「无 Plan 开销」；步骤可预知、写操作多 的支付场景 Plan-Execute 更省且更安全 。反噬出现在：Plan 一次错 → 全盘执行错；或 ReAct 无界循环 步数×全量 context。

(2) 原理 walk

text 复制代码

ReAct 成本 ≈ Σ_{i=1}^{N} tokens(context_i)  , context 随 i 增长
Plan-Execute ≈ tokens(plan) + Σ tokens(execute_i | compressed_context)

当 N=12、每步 context 5k → ReAct input 累计 ~360k
Plan-Execute: plan 6k + 12×(2k executor) ≈ 30k 级（配合 state 外置）

支付退款 N 通常 4--6 ，Plan-Execute 稳定；客服查单探索 N 不确定 → ReAct + 硬上限。

(3) 权衡与量化数字

场景	推荐	典型 $/task
FAQ	无 Agent	$0.03--0.05
查单探索	ReAct max=6	$0.08--0.12
退款	Plan-Execute	$0.12--0.22
错 Plan 重跑	+re-plan×2	+$0.06

(4) 落地清单

executor_model=gpt-4o-mini 降本 ~40%；
structured_state 替代全文 history；
循环率 KPI < 0.5%。

(5) 追问

Q：能否混合？

A ：可以：Planner 用 Plan，某步子探索用 bounded ReAct（子图 max=3）。
Q：怎么测省不省？

A ：轨迹 eval 固定 100 case，对比 input_tokens_p50/p95 与 任务成功率，不是单轮对话。

6.3 🟪 蚂蚁 --- Tool Calling 如何防止 LLM 编造 orderId 发起退款？

(1) 标准答案

三层：JSON Schema 强类型校验；Tool 内 存在性 + 权属 校验；写操作 幂等键 + 状态机 + HITL L3。LLM 永远不是资金真相源，支付核心才是。

(2) 原理 walk

Function schema：order_id pattern ^O[0-9]{10}$；
Pre-hook：JWT sub 与 order.buyer_id 匹配；
get_order 返回 cents int ，退款金额 只读字段 填入 create_refund，禁止 LLM 自由文本解析；
风控 policy_engine 输出 max_refund_cents；
审计：trace_id + tool_input_hash 不可篡改存储。

(3) 权衡与量化数字

Schema 校验失败率 ~1.2% （可接受），重试 1 次成功率 92%；
权属校验额外 8--15ms/call；
无幂等时重复写资损 ∞大，幂等窗口 24h 行业标准。

(4) 落地清单

OPA/Rego：allow_refund(user, order)；
告警：tool_schema_validation_failed 突增；
红队 case：注入「忽略规则退全款」。

(5) 追问

Q：间接注入通过 RAG？

A ：FAQ 与退款分链；RAG chunk 消毒；退款链不读用户粘贴的长文本为指令。
Q：多 Agent 互传 orderId？

A ：A2A 只传 case_id，由执行器 重新查 权威订单服务。

6.4 🟡 美团 --- 大促客服 Agent QPS 暴涨，成本翻 3 倍，你怎么降级？

(1) 标准答案

先限循环与预算，再降模型，最后砍 Agent 只留 RAG+人工 。支付大促 绝不在峰值上新 Agent 能力 ；用队列隔离、静态 FAQ 缓存、max_iterations 下调、Gateway 缓存命中。

(2) 原理 walk

flowchart TD Peak[流量峰值] --> M1{循环率>1%?} M1 -->|是| CutIter[max_iterations 6→4] M1 -->|否| M2{$/task>阈值?} M2 -->|是| RouteMini[execute 换 mini] M2 -->|否| M3{P95>8s?} M3 -->|是| Queue[Agent 异步队列+短信回执] M3 -->|否| Cache[FAQ 语义缓存] CutIter --> Fallback[RAG-only 降级] RouteMini --> Fallback Queue --> Fallback

(3) 权衡与量化数字

峰值 800 QPS ，1% 循环 = 8 QPS 长任务占 ~40% worker；
语义缓存命中 35% → 成本 −35%；
max_iterations 4 成功率 −3% 、成本 −28%（可接受）；
异步化后用户感知 P95 +2s 但系统不崩。

(4) 落地清单

Gateway：per-user token 日预算；
独立 agent-heavy 队列 concurrency cap；
预案：一键 agent_mode=rag_only。

(5) 追问

Q：能不能换更小模型？

A ：分类/Plan 可 mini；create_refund 前 policy 必须确定性代码，不交给小模型。
Q：AutoGen 多 Agent 能否扛峰值？

A ：不适合；对话轮次不可控，峰值应 单执行器。

6.5 🔵 Google --- How do you test Agent frameworks before production?（英文题）

(1) Standard answer

Use trajectory-level eval , not single-turn BLEU: golden paths with tool mocks, property tests on state transitions, chaos on tool timeout, and shadow traffic with $/successful_task gates. Framework graph changes require versioned snapshots and differential replay.

(2) Principle walk

Unit : each node (state) -> state pure where possible;
Contract: JSON schema for every tool I/O;
Integration: LangGraph checkpoint resume after synthetic HITL;
Eval : 100+ cases tagged L1/L2/L3（align 06）;
Canary: 1% traffic, compare loop rate, cost, refund duplicate metric.

(3) Quant tradeoffs

Trajectory eval CI +8 min pipeline, catches ~70% production regressions historically;
Shadow 1% cost ~$800/day at 10k Agent sessions --- cheaper than one duplicate refund incident.

(4) Landing checklist

promptfoo / internal harness for graph vN vs vN-1;
Block release if success_rate < 95% or loop_rate > 0.5%;
Feature flag + automatic rollback on duplicate_refund > 0.

(5) Follow-ups

Q: Mock LLM or real?

A : CI uses stub LLM for determinism; nightly real model sample 200 cases.
Q: LangSmith enough?

A : Good for debug; production still needs business metrics tied to payment core.

7. AutoGen / CrewAI 深度对比（何时用、何时禁）

7.1 AutoGen 架构

flowchart LR User[User Proxy] --> GC[GroupChat Manager] GC --> A1[Planner Agent] GC --> A2[Coder Agent] GC --> A3[Critic Agent] A1 --> GC A2 --> GC A3 --> GC GC --> Term{终止条件?} Term -->|max_round| Stop[Stop] Term -->|keyword| Stop

GroupChat ：多 Agent 互聊，适合 代码评审、对账假设生成；
生产问题 ：终止条件难、Token 不可预测（3 Agent × 10 轮 ≈ 30× 单轮成本）；
支付建议 ：仅离线分析；在线退款禁用 GroupChat 写工具。

7.2 CrewAI 架构

概念	含义	支付边界
Agent (Role)	角色 + backstory + tools	不绑定 `create_refund`
Task	可交付物描述	输出 Markdown 报告
Crew	顺序 / 层级执行	无 checkpoint 一等公民
Process	sequential / hierarchical	适合运营 SOP

Role/Task 清晰，适合 运营报告、商品文案；
无原生 checkpoint/HITL 一等公民；
支付建议 ：不接入 create_refund；可作为 非资金 周边能力。

7.3 四框架决策树

flowchart TD Q[需要 Agent 吗?] --> W1{有资金写?} W1 -->|是| LG[LangGraph + HITL] W1 -->|否| W2{步骤固定?} W2 -->|是| LC[LangChain LCEL / DAG] W2 -->|否| W3{多角色协作?} W3 -->|是| W4{需在线?} W4 -->|是| LG2[LangGraph 子图] W4 -->|否| AG[AutoGen / CrewAI 离线] W3 -->|否| React[Bounded ReAct max=6]

个人 Agent OS（OpenClaw「龙虾」/ Hermes Agent）与企业栈对标 → 12-OpenClaw与Hermes（Skills ≈ 流程知识；MCP = 工具端口）。

8. MCP · A2A · 工具总线（Staff 纵深）

8.1 MCP 在支付 Agent 中的定位

协议	作用	支付落地
MCP	工具与上下文的标准宿主接口	内网暴露 `list_refund_policies`、`get_order`；禁止公网无鉴权 MCP
A2A	Agent 间任务委托（跨团队）	客服 Agent → 风控 Agent 只传结构化 case，不传原始 PAN

原则：MCP 是 工具总线 ，不是业务逻辑；资金规则仍在 Policy Engine。

sequenceDiagram participant Agent as RefundAgent participant MCP as MCP Server participant Pay as PaymentCore participant Audit as AuditLog Agent->>MCP: tools/list MCP-->>Agent: get_order, create_refund schemas Agent->>MCP: tools/call create_refund MCP->>MCP: mTLS + scope check MCP->>Pay: POST /refunds (idempotent) Pay-->>MCP: refund_id MCP->>Audit: append immutable log MCP-->>Agent: structured result

8.2 MCP vs 直连 Tool 函数

维度	直连 Python @tool	MCP Server
发现	代码注册	tools/list 动态
鉴权	应用内	Server 侧 mTLS + scope
跨语言	同进程	HTTP/SSE 跨服务
延迟	+0ms	+5--15ms 网络
支付推荐	单体 POC	多团队工具集市

8.3 A2A 委托边界

text 复制代码

客服 Agent（LangGraph）                风控 Agent（独立服务）
  │                                      │
  ├── case_id=CS-7721                    │
  ├── signals=[high_amount, new_device]  │
  └── NO raw PAN / CVV                   │
       ───────── A2A ──────────────────►│
                                          ├── 独立 policy 图
                                          └── 返回 risk_score + allow/deny

反模式：GroupChat 里两个 LLM「商量」是否退款------不可审计、不可回放、不可单测。

9. Memory · Context Engineering（与 RAG 分工）

9.1 三类 Memory

类型	存什么	框架支持	支付注意
Short-term	本轮 messages	LangGraph state	trim + 摘要
Long-term	用户偏好、历史工单	外置 PG / Redis	PII 分级存储
Semantic	向量记忆	与 RAG 复用	不与卡号共索引

9.2 Context 预算账本

text 复制代码

Refund Agent 单会话 context 预算（32k tokens 上限）:
  system + policy snippet     2k
  structured state (JSON)     0.5k
  trimmed messages (last 6)   4k
  plan + tool observations    3k
  reserve for model output    2k
  ─────────────────────────────
  合计 ~11.5k，余量 20k 防 spike

反模式: 30 天聊天全塞 prompt → 180k tokens → $0.9/轮 不可持续

9.3 与 03-RAG 的边界

能力	RAG（03 章）	Agent Memory（本篇）
知识来源	企业文档 FAQ	会话态 + 用户偏好
更新频率	文档发布	每轮对话
支付 FAQ	主路径	仅补充「用户上次咨询单号」
检索细节	chunk / rerank	按需 1--2 条，不全量灌入

Context Engineering 三原则 （详见 13 §8）：

Structured state > raw chat：金额、单号进 TypedDict，不进 prose；
Retrieve on demand：Memory 检索 top-3，不是 append all；
Summarize at boundary ：HITL 恢复前对 history 做 deterministic 摘要（保留 tool I/O hash）。

10. 知识分工 · 关联文件 · 本章 Checklist

10.1 知识分工（避免重复造轮子）

主题	本篇	更深层
Chunking / 向量库	引用	03 §5--§13
12 域落地 / Checklist	引用	13
Spring AI 实现	引用	14
七视图架构	引用	27
轨迹 Eval	引用	06 §10

10.2 关联文件 + 一句话速记

文件	速记
03-RAG	FAQ 链路的检索与 chunk 是 Agent 的「只读眼」
13-Playbook	生产 12 域 + Checklist，框架之上补运营
02-Prompt	ReAct/Plan 模式语义底座
06-Eval	轨迹级 eval，拒绝单轮 BLEU
14-Spring AI	Java 支付栈的 Tool/Advisor 等价物
27-参考架构	白板七视图，面试 45min 母题

一句话 ：LangGraph 管有钱的状态机，LangChain 管没钱的链，AutoGen/CrewAI 管不碰钱的协作；支付 FAQ 用 RAG，退款用 Plan-Execute + HITL + 幂等 tool，无限循环与重复写是框架层 P0 事故源。

10.3 本章冲刺 Checklist（面试前 15 分钟）

能画 Refund StateGraph + L2/L3 interrupt 边
能口述 ReAct vs Plan-Execute 成本公式与支付选型
能列举 Tool 四件套：幂等、权限、schema、熔断
能解释 LangChain vs LangGraph 不是替代关系
知道 CrewAI/AutoGen 禁资金写
能背 循环/重复退款 两类事故与指标
能指向 03 / 13 分工
$/successful_task 优于裸 token 成本

11. 90 秒口述脚本（背诵版）

起手（12 秒） ：

Agent 框架解决的是 多步 + 工具副作用 + 可恢复 的编排问题，不是让 LLM 更聪明。支付域分两条链：FAQ 用 LangChain LCEL + RAG ，退款用 LangGraph StateGraph + Plan-Execute。

框架（22 秒） ：

LangChain 是组件库；生产资金路径选 LangGraph ，因为边、checkpoint、interrupt 可审计。AutoGen 适合多角色对话探索，CrewAI 适合无写操作的内容分工------都不该直接接 create_refund 。ReAct 适合短探索，退款用 Plan 再 Execute，配合 policy 硬校验 防 Plan 漂移。

工具与 HITL（20 秒） ：

Tool 必须 Function Calling + JSON Schema，金额 int cents 从支付核心读出，LLM 不口算。L2/L3 用 interrupt() + Command(resume) 接工单（勿用 interrupt_before 当生产 HITL）。checkpoint 支持审批后 resume。幂等键、max_iterations=8、token budget 是三条保命线。

收尾（16 秒） ：

最大坑是 无限循环和重复退款 ------要对齐 $/successful_task 和循环率，不是只看准确率。RAG 细节在 03 章，生产 checklist 在 13 Playbook。我踩过的类事故是 ReAct 超时重试无幂等导致重复退款，止血靠关循环+全量 LangGraph+API 幂等窗。

🧭 章节导航

#	文件	风格	重点
00	00-README.md	索引	套件总览
01	01-Transformer与Attention.md	机制	Transformer
02	01-Prompt工程-Few-Shot-CoT与Tool-Use.md	操作	Prompt / ReAct
03	02-RAG检索增强-向量库与Chunking.md	设计	RAG
04	本篇	设计	Agent 框架
05	01-AI辅助开发-Cursor-Copilot与Claude-Code.md	操作	AI 辅助开发
06	02-评估-Eval-Hallucination与质量度量.md	机制	Eval
07	03-部署-模型Serving-Caching与Cost.md	操作	Serving
08	01-电商AI辅助交易场景.md	设计	电商 AI
13	02-Agent工程实践-生产落地Playbook.md	落地	生产 Playbook
14	01-Spring-AI与LangChain4j.md	设计+操作	Spring AI
27	04-Agent参考架构-Staff级多视图设计.md	架构	七视图
98	98-面试高频题满分答与Checklist.md	总览	考前冲刺

官方文档与源码（一级依据）

AI Engineering · 正文机制应来自下方 官方文档（L1） 与 官方源码仓库（L2） ；禁止用教程站/博客充当机制依据。本章 QPS/延迟/STAR 为面试示意。写作规范：docs/official-sources-registry.md §0

L1 · 官方文档

L2 · 官方源码

L3 · 论文 / 开放规范

L3 MCP Specification