Agent 框架设计：用广告竞价系统类比决策引擎

是什么：Agent 的本质定义

大模型 Agent 不是“有记忆的聊天机器人”，而是一个自主决策+执行系统：

用户目标: "帮我分析上周广告数据，找出 ROI 下降的原因"
         │
    ┌────▼────┐
    │  LLM    │  ← 推理引擎（大脑）
    │  "需要查数据"  │
    └────┬────┘
         │
    ┌────▼────┐
    │ Tool Call│  ← 执行层（手脚）
    │ get_ad_data() │
    └────┬────┘
         │
    ┌────▼────┐
    │  LLM    │  ← 二次推理
    │  "CTR正常，CVR下降 → 落地页问题"  │
    └────┬────┘
         │
    ┌────▼────┐
    │ 输出结论 │
    └─────────┘

Agent = LLM（推理） + Tools（执行） + Memory（状态） + Orchestrator（调度）。

广告系统类比

Agent                         广告竞价系统
─────                         ──────────
LLM 推理引擎           →      广告排序模型（pCTR/pCVR）
Tool Calling           →      广告检索（去倒排索引查候选）
Memory（上下文）        →      用户画像 / 广告历史数据
Orchestrator（调度）    →      竞价引擎（OCPC 出价决策）
最终输出               →      展示哪个广告 / 多少钱出

这不是比喻，是同构映射——两个系统都是“输入目标 → 检索信息 → 决策 → 执行 → 反馈”的闭环。

---

为什么需要 Agent 框架？

Step 1：裸 LLM 的局限

裸 LLM：

用户："上周的 ROI 降了多少？"
LLM："抱歉，我没有上周的数据，我是基于截止到..."

LLM 只有训练时的知识，没有实时数据访问能力。就像一个广告系统没有索引、没有用户画像、没有出价模型——它能说话，但不能做事。

Step 2：加上 Tool Calling

用户："上周的 ROI 降了多少？"
Agent：
  1. 识别需要调用数据查询工具
  2. 生成 SQL: "SELECT roi FROM metrics WHERE week = 'last'"
  3. 执行查询 → 拿到结果
  4. 用 LLM 把结果翻译成自然语言
  "上周 ROI 从 2.3 降到 1.8，下降了 22%。"

Tool Calling = 广告系统的倒排检索——你不想每次都说“帮我查索引”，系统自动判断需要查哪条索引、查什么字段。

Step 3：多步推理 + 记忆

用户："帮我优化上周效果差的广告"
Agent：
  Step 1：查哪些广告 ROI 下降     → 工具：get_low_roi_ads()
  Step 2：分析下降原因           → 工具：analyze_ctr_cvr()
  Step 3：生成优化方案           → LLM 推理
  Step 4：执行优化（提价/换创意）  → 工具：adjust_bid()
  Step 5：记录操作，等待反馈      → Memory

这和广告系统的 OCPC 出价闭环一模一样：

广告出价闭环：
  Step 1：监测实际 ROI
  Step 2：对比目标 ROI
  Step 3：计算出价调整量
  Step 4：执行出价
  Step 5：等待下一轮数据反馈

---

去掉 Agent 框架的代价

裸 LLM 就是一个“聪明的哑巴”：

场景	裸 LLM	Agent
数据查询	“我没有这个数据”	自动调 SQL 工具查
多步任务	一次回答，不能连续操作	ReAct：思考→行动→观察→思考
错误恢复	不会	Tool 调用失败→重试/换策略
安全约束	无	执行前检查权限和预算
长期记忆	无	向量数据库存历史经验

这就像广告系统：

裸 LLM  = 只有 pCTR 模型，没有索引、没有出价引擎、没有预算控制
Agent   = 完整的广告投放系统：可以检索、出价、竞价、反馈优化

---

Agent 的核心架构：一层一层拆

Layer 1：ReAct 模式（Think → Act → Observe）

┌────────────────────────────────────┐
│           ReAct Loop               │
│                                    │
│  Thought: "我需要查上周的数据"       │
│     ↓                              │
│  Action: call get_ad_data()        │
│     ↓                              │
│  Observation: "ROI: 1.8, CTR: 2.1%"│
│     ↓                              │
│  Thought: "CTR正常，CVR低 → 落地页"  │
│     ↓                              │
│  Action: call analyze_landing_page()│
│     ↓                              │
│  Observation: "加载时间 4.2s，偏高"  │
│     ↓                              │
│  Final Answer: "ROI下降原因是落地页加载慢"│
└────────────────────────────────────┘

Layer 2：Tool Registry（工具注册表）

tools = [
    {
        "name": "get_ad_metrics",
        "description": "查询广告指标",
        "parameters": {"ad_id": "int", "metric": "str", "days": "int"},
    },
    {
        "name": "adjust_bid",
        "description": "调整出价",
        "parameters": {"ad_id": "int", "new_bid": "float"},
        "constraints": {"max_adjustment": 0.30}  # 单次不超过30%
    },
]

Layer 3：Memory（长期 + 短期）

短期记忆（上下文窗口）：
  当前对话的前 N 轮历史
  本轮调用的工具和结果

长期记忆（向量数据库）：
  历史优化方案的效果记录
  常见问题的解决模式
  → 类似广告系统的用户画像和历史行为数据

Layer 4：Safety Guard（安全护栏）

执行前检查：
  - 出价调整是否超过 30%？
  - 是否在暂停的广告上操作？
  - 操作频率是否过高？

执行后记录：
  - 所有工具调用写入审计日志
  - 效果跟踪（操作后24h监测ROI变化）

→ 这就是广告系统的预算控制和风控逻辑搬到了Agent

---

覆盖多少场景？

场景	Agent 类型	广告系统类比
数据问询	单步 Tool Call	广告报表查询
诊断优化	多步 ReAct	广告效果归因分析
自动调控	带 Safety Guard 的 Agent	OCPC 自动出价
多 Agent 协作	Multi-Agent	召回/排序/出价各模块独立又协同
人机协同	Human-in-the-loop	人工审核+自动执行分层

---

不变的本质

Agent 框架四条元原理：

1. 推理 + 执行 = 闭环

LLM 提供推理能力，Tool 提供执行能力。两者缺一不可。

对应广告系统：pCTR 模型提供预估，出价引擎提供执行。光有模型没有出价 = 光有 LLM 没有 Tool。

2. 反馈即学习

Agent 的质量取决于反馈闭环的质量。执行→观察→分析→再执行。

对应广告系统：OCPC 的本质就是反馈闭环——实际 ROI vs 目标 ROI → 调整出价 → 观察新的 ROI。

3. 安全边界 = 系统可靠性的底线

没有护栏的 Agent 就像一个没有预算上限的广告账户——它可以在一分钟内把你所有的预算花光。

4. 分层 = 复杂度管理

Agent 的分层：
  Orchestrator（做什么）→ Tool（怎么做）→ Memory（记住什么）→ Safety（什么不能做）

广告系统的分层：
  竞价策略（出多少钱）→ 召回（哪些广告）→ 排序（哪个最好）→ 预算控制（花多少钱）

---

元结构映射

广告竞价系统                          Agent 框架
────────                           ──────
OCPC 出价策略                →      Orchestrator 决策引擎
广告检索（倒排+正排）         →      Tool Calling
用户画像 / 行为历史          →      Memory（短期+长期）
预算控制 / 风控              →      Safety Guard
pCTR/pCVR 预估模型          →      LLM 推理
出价执行引擎                →      Tool 执行层
投放效果反馈闭环            →      ReAct Loop
多广告位独立竞价             →      Multi-Agent 协作
广告主目标 (ROI/曝光)       →      User Goal

最深层的同构：两者都是**“给定目标，在约束条件下，通过检索+推理+执行，最大化目标函数”**。

---

关联我的经验

1. OCPC 出价 → Agent 决策

OCPC 的本质是：观察实际 ROI → 对比目标 → 计算调整量 → 执行出价 → 等待反馈。Agent 的 ReAct Loop 只是把“出价”换成了“工具调用”——框架完全一样。

2. 检索漏斗 → Tool Selection

广告检索：哪些广告候选值得进入漏斗？Agent 的 Tool Selection：面对 50 个工具，用哪个？两者都需要在不完整信息下做快速初筛。

3. 预算控制 → Safety Guard

广告系统的预算控制有三层：日预算上限、单次出价上限、异常消耗熔断。Agent 的 Safety Guard 完全对应：操作权限分级、单次调整上限、异常行为熔断。

4. 客户沟通语言

向芯片客户解释昆仑芯在 Agent 场景的价值：“Agent 场景的推理模式是 LLM 反复调用 Tool——每次 Tool 调用中间需要一次 LLM 推理来做下一步决策。这个推理延迟决定了 Agent 的整体响应速度。昆仑芯的低延迟推理能力，让你的 Agent 从’给出一个问题 10 秒后开始执行’变成’1 秒后开始执行’——这在客户体验上是从’不可用’到’可用的质变。”

---

一句话总结本质

Agent = 广告竞价系统换了个外壳：Orchestrator 是 OCPC 出价引擎，Tool Calling 是检索漏斗，Memory 是用户画像，Safety Guard 是预算控制——四个齿轮咬合，形成自主决策+执行+反馈的闭环。