Agent设计模式

1. 深拷贝与浅拷贝

浅拷贝（Shallow Copy）

只复制对象的第一层，内部嵌套的子对象仍然共享同一份引用。

深拷贝（Deep Copy）

递归地复制对象的所有层级，生成一个完全独立的副本。两者之间没有任何共享的引用。

对新复制的对象修改地址（引用）会不会对原对象影响，浅拷贝会影响。

---

2. 三大设计模式

	创建型模式	结构型模式	行为型模式
解决的问题	对象怎么创建	对象怎么组合	对象之间怎么交互与分配职责
关注焦点	创建过程的封装与解耦	整体结构的灵活性	通信与控制流
核心关键词	实例化、工厂、单例	适配、组合、代理、装饰	策略、观察者、状态流转
粒度	类与对象的诞生	类与对象的装配	类与对象的协作
典型收益	降低创建方与具体类的耦合	灵活扩展结构而不改已有代码	行为可替换、可扩展

类别	本质
创建型	把 new 藏起来，让创建逻辑可替换
结构型	把对象 拼起来，让整体结构可扩展
行为型	让对象之间 对话，让交互逻辑可配置

---

3. 解耦——耦合

解耦就是让模块之间减少依赖，使得改动一个模块时，不会牵连其他模块。

---

4. 分布式

分布式 = 多台计算机通过网络协作，对外表现得像一个整体来完成任务。

---

5. yield

yield 是 Python 中的一个关键字，用于定义**生成器（Generator）**函数。核心思想：函数执行到 yield 时会暂停并返回值，下次调用时从暂停处继续执行。

关键区别：

• 普通函数遇到 return 就结束，所有结果一次性返回
• 生成器函数遇到 yield 就暂停，保留现场，下次从暂停处继续

---

6. RDBMS 关系型数据库

四个特性

A — Atomicity（原子性）

事务是一个不可分割的整体，要么全部成功，要么全部回滚，不会停留在中间状态。

类比 · 银行转账 — A 向 B 转 100 元，扣款和加款必须同时发生，不能只做了一半。

C — Consistency（一致性）

事务执行前后，数据库都必须处于合法状态，满足所有约束规则（如主键、外键、唯一性、业务规则等）。

类比 · 转账前后，两个账户的总金额应该不变。

I — Isolation（隔离性）

多个事务并发执行时，互不干扰。每个事务感觉不到其他事务在同时运行，结果与串行执行等价。

类比 · 两个人同时从同一个账户取钱，系统要确保不会因为并发而多吐钱。

D — Durability（持久性）

事务一旦提交成功，数据就被永久保存，即使之后发生系统崩溃、断电等故障也不会丢失。

类比 · 你在 ATM 上操作成功后，钱不会因为服务器重启而”变没”。

---

7. API（Application Programming Interface，应用程序编程接口）

功能必须解耦为服务，服务必须通过协议进行通信

对比项	API	API Key
是什么	一套接口规范	一串身份凭证
类比	餐厅的菜单 + 服务员	你的会员卡号
作用	定义”你能请求什么、怎么请求”	证明”你是谁、有没有权限”
长什么样	一段文档 + 一个网络地址	sk-a1b2c3d4e5f6...

---

8. 微服务架构

将一个大型应用程序拆分为一组小型、独立部署的服务，每个服务负责一项特定的业务能力。

核心特征

1. 服务独立

每个微服务运行在自己的进程中，可以独立开发、测试、部署和扩展，互不影响。

2. 围绕业务能力组织

每个服务对应一个明确的业务领域，比如”用户管理""订单处理""支付服务”等。

3. 轻量级通信

服务之间通常通过 HTTP/REST、gRPC 或消息队列（如 Kafka、RabbitMQ）进行通信，而不是直接共享内存或数据库。

4. 去中心化治理

每个服务可以使用最适合自身场景的编程语言、框架和数据存储，没有统一技术栈的强制约束。

5. 独立数据库

每个服务拥有自己的数据库（Database per Service），避免数据层的耦合。

适用场景与代价

适合：

• 团队规模较大，需要并行开发
• 系统复杂度高，业务领域边界清晰
• 需要高可用、弹性伸缩
• 追求持续交付和快速迭代

代价：

• 分布式系统复杂度（网络延迟、数据一致性、分布式事务）
• 运维成本显著增加
• 服务间依赖管理和测试难度上升
• 对团队的 DevOps 能力要求较高 (DevOps 是 Development（开发） 和 Operations（运维） 的组合词，代表一种将软件开发与 IT 运维深度融合的文化理念、实践方法和工具体系。)

---

9. 背压

完全由下游消费者控制数据拉取的节奏，避免上游生产速度远大于下游处理速度导致的缓冲区溢出、系统崩溃问题。

示例 · Java（Project Reactor）：由消费者主导拉取节奏

// 响应式流：由消费者主导处理节奏
Flux.range(1, 1000)  // 创建一个发出 1 到 1000 共 1000 个 Integer 元素的 Flux
    .onBackpressureDrop() // 当消费者处理不过来时，自动丢弃多余数据，防止系统过载
    .subscribe(new BaseSubscriber<Integer>() {
        protected void hookOnSubscribe(Subscription subscription) {
            request(1); // 明确声明：每次只请求一个元素，按需消费
        }

        protected void hookOnNext(Integer value) {
            // 处理当前元素
            System.out.println("Processing: " + value);
            // 处理完后再请求下一个元素
            request(1);
        }
    });

当生产速度 >> 消费速度时，有三种常见策略：

策略	行为	适用场景
onBackpressureBuffer()	缓存溢出数据，排队等处理	数据不能丢，但可延迟
onBackpressureDrop()	直接丢弃多余数据	可容忍丢失，如实时监控
onBackpressureLatest()	只保留最新一条	只关心最新状态，如股票价格

这里选的 onBackpressureDrop() 意味着：

• 当消费者还没准备好接收时，生产者产生的数据被默默丢弃
• 可选地注册一个丢弃回调：.onBackpressureDrop(dropped -> log("丢弃: " + dropped))

---

10. CI / CD / CT

CI：持续集成

要解决的问题：代码合并在最后才做，合并完全是 bug。

做法：

• 每个人每天多次提交代码
• 每次提交都自动编译 + 自动测试
• 有问题？5分钟就发现，当场改
• 没问题？自动合并进主线

一句话：不要攒着，每天都合，每次都验。

CD：持续交付与持续部署

CD——持续交付（Continuous Delivery）、持续部署（Continuous Deployment）。

CT：持续测试

要解决的问题：只在上线前测一次，测试像走过场。

做法：

• 写代码时：静态分析 + 本地单测
• 提交时：完整测试套件
• 构建时：安全扫描
• 预发布：集成测试 + E2E + 性能测试
• 上线后：监控 + 告警 + 自动回滚

一句话：测试不是一个步骤，而是一层无处不在的安全网。

---

11. 损失函数

梯度告诉你哪里在上升，你就反方向走。减去梯度（乘以学习率），就是在让参数朝着损失最小的方向一步步移动。

---

12. 幻觉

幻觉是特性，而非bug。模型本质上是在进行有损压缩与模糊联想。幻觉正是这种联想能力的“副作用”——创造力与胡乱胡言乱语往往如同一枚硬币的两面。

输出验证器模式，“生成”可以是概率性的，但“验证”必须是确定性的。这是应对幻觉最有效的手段之一——为agent构建一个具备怀疑能力的反馈回路。通过确定性的环境反馈，不断坍缩概率性生成的空间，从而引导模型输出趋向准确与可靠。

---

13. MLOps

MLOps（Machine Learning Operations）是一套将机器学习模型高效、可靠地部署到生产环境并持续运维的实践、流程和工具集合。

维度	传统软件	机器学习项目
开发对象	代码	代码 + 数据 + 模型
测试方式	单元测试、集成测试	还需要数据验证、模型评估
版本管理	代码版本	代码版本 + 数据版本 + 模型版本
上线后	相对稳定	模型会随数据漂移而衰退，需要持续监控和重训

MLOps 就是为了系统性地管理这些额外复杂性而诞生的。它告诉我们要放下对确定性的执念，转而构建基于统计的质量护栏。明天同时我们不仅要监控软件”跑的快不快“，更要监控它”想的对不对“。

MLOps 的关键环节

1. 数据管理
   • 数据版本控制（如 DVC）
   • 数据质量校验与特征工程流水线
2. 实验管理与模型训练
   • 超参数追踪、实验记录（如 MLflow、Weights & Biases）
   • 可复现的训练流程
3. CI/CD for ML
   • 不仅对代码做持续集成，还对数据和模型做持续集成
   • 自动化训练 → 评估 → 部署流水线
4. 模型部署与服务化
   • 模型打包（容器化）
   • 在线推理服务、批量推理、边缘部署
5. 监控与反馈
   • 模型性能监控（准确率、延迟等）
   • 数据漂移（data drift）和概念漂移（concept drift）检测
   • 自动触发重训的闭环

---

14. AgentOps

AgentOps 是一个面向 AI 智能体（Agent） 的可观测性与运维平台，可以理解为 AI Agent 时代的 “APM（应用性能监控）” 工具。

随着越来越多的 AI Agent 被构建和部署（如基于 LangChain、AutoGen、CrewAI 等框架），开发者面临一系列运维难题：Agent 到底做了什么？调用了哪些工具？为什么出错？成本花在哪？AgentOps 就是为了解决这些 “黑箱” 问题而生的。

功能	说明
会话回放（Session Replay）	完整记录 Agent 的每一步决策、工具调用、LLM 交互，像”录屏回放”一样重现 Agent 行为
成本追踪	监控每次 LLM 调用的 Token 消耗和费用
错误与异常检测	自动捕获 Agent 运行中的失败、超时、幻觉等问题
性能分析	延迟、吞吐量、调用链路等指标
多 Agent 可观测	支持多 Agent 协作场景下的整体行为追踪

示例 · Python：接入 AgentOps

import agentops
agentops.init(api_key="your_key")
# 之后 Agent 的所有 LLM 调用、工具使用等会自动被记录

Agent架构师的核心竞争力，正是通过确定性的工程框架，驾驭并约束概率性的智能核心，从而构建出高可靠性的系统。

在软件2.0时代，Agent架构师面临的根本性矛盾：用户以及下游的API要求的是百分百确定的结构化数据（如JSON数据），而大模型本质上倾向于生成充满可能性、富有创造性的文本。

为解决该矛盾，“三明治架构”是一种有效的策略，这种架构的核心理念是通过两层确定性的逻辑和工程框架来包围中间那层基于概率的模型。

---

15. 沙箱

沙箱就是一个与真实环境隔离的、安全、可控的实验环境，让程序、应用或用户可以自由测试和运行，而不会对正式系统造成影响。

---

16. HITL 接口（Human-In-The-Loop）

HITL（Human-In-The-Loop，人在回路中）接口是一种设计模式：在自动化流程中嵌入人类参与的环节，让人类在关键节点进行审核、决策或干预，而不是让系统完全自主运行。

---

17. OODA 软件化

示意 · OODA 循环（纯文本流程）

┌─────────────┐
│  Observe    │ 观察
│  (感知信息)  │
└──────┬──────┘
       │
┌──────▼──────┐
│  Orient     │ 判断
│  (理解态势)  │
└──────┬──────┘
       │
┌──────▼──────┐
│  Decide     │ 决策
│  (选择行动)  │
└──────┬──────┘
       │
┌──────▼──────┐
│  Act        │ 行动
│  (执行方案)  │
└──────┬──────┘
       │
       └──────→ 回到 Observe（循环往复）

1. Observe（观察）—— 数据采集层

目标：把环境中的一切变化转化为结构化数据。

传统方式	软件化方式
人看仪表盘	自动化监控（Prometheus、Grafana）
人读报告	日志采集（ELK、Fluentd）
人打听消息	API 轮询、消息队列（Kafka）、IoT 传感器
人看新闻	爬虫 + 实时数据流

关键技术：数据湖/数据仓库、流计算（Flink）、边缘计算、时序数据库

2. Orient（判断）—— 态势理解层

目标：把原始数据转化为对当前局势的理解。

这是 OODA 中最重要也最难软件化的一环——Boyd 称之为”快速突变”（Fast Transients）的核心。

原始数据	态势理解
CPU 95%	服务 A 过载，即将触发级联故障
订单量 ×3	疑似促销活动带来的流量高峰
连续登录失败 ×50	正在遭受暴力破解攻击
用户停留时长下降	新版本可能引入了体验问题

关键技术：图数据库（知识图谱）、因果推理、异常检测模型、RAG 检索增强

3. Decide（决策）—— 策略选择层

目标：基于态势理解，选择最优行动方案。

态势理解	决策输出
服务过载，95%置信度	自动扩容 + 限流
遭受攻击，90%置信度	封禁 IP + 告警安全团队
体验下降，60%置信度	通知产品团队，不自动操作

关键技术：规则引擎（Drools）、决策树、强化学习、HITL 接口

4. Act（行动）—— 自动执行层

目标：把决策转化为实际操作，并反馈结果。

关键技术：自动化运维（Ansible、Terraform）、工作流引擎、API 网关、Saga 分布式事务

领域	Observe	Orient	Decide	Act
自动驾驶	摄像头+激光雷达	感知+预测其他车辆行为	路径规划	转向/刹车/加速
智能运维	监控指标+日志	异常检测+根因分析	自愈策略选择	自动扩容/回滚/限流
量化交易	行情数据流	因子分析+信号识别	买卖策略决策	下单执行
AI Agent	用户输入+环境状态	意图理解+上下文分析	工具选择+计划生成	调用 API/执行代码
网络安全	流量镜像+日志	威胁情报关联+行为分析	防御策略选择	封禁IP/隔离主机
推荐系统	用户行为埋点	用户画像+兴趣建模	排序策略选择	返回推荐列表

1. Observe：接收用户消息 + 检索上下文 + 获取工具返回值
2. Orient：LLM 理解意图 + 推理当前状态 + 评估目标进度
3. Decide：LLM 选择下一步动作 + 选择调用哪个工具
4. Act：执行工具调用 / 生成回复 / 操作环境

→ 结果作为新的 Observe 输入 → 循环

---

18. 元认知与Agent

简单来说，元认知就是 “关于认知的认知”——也就是你对自己思维过程的觉察、监控和调节能力。可以把它理解为”思考自己是如何思考的”。

元认知能力	对应到 Agent 的设计问题
我知道什么、不知道什么	Agent 如何评估自身能力边界？
我当前的策略有效吗	Agent 如何在执行中自我监控？
我应该换一种方法	Agent 何时决定反思和回溯？
这个任务我有多大把握	Agent 如何给出置信度判断？

你会发现，一个高质量的 Agent 系统，几乎每一环都在做某种形式的”元认知”

构建 Agent 系统，元认知视角带来几个关键设计原则：

设计原则	具体做法
显式建模能力边界	让 Agent 在规划时声明”我能做什么、不能做什么”
内置监控断点	不要让 Agent 一口气跑完全程，设置检查和回溯点
外部化反思	用独立的”评审 Agent”来审视工作 Agent 的输出
校准不确定性	训练 Agent 区分”我知道”和”我不确定”
失败记忆	将反思结果持久化，避免重复犯错

---

19. RPD API 接口限流

RPD = Requests Per Day

每日请求次数，大模型 API 配额指标，和 RPM (每分钟请求)、TPM (每分钟 token) 并列。

• 含义：接口一天最多允许调用多少次；打满返回 429 限流错误，午夜重置配额。
• 示例：RPD=200 → 该账号每天最多发起 200 次 API 请求。

大模型论文里的 RPD

① Relative Performance Drop 相对性能下降率

• 衡量输入加噪声 / 扰动后模型性能掉多少；RPD 越小，鲁棒性越强。常用于评估提示词迁移、对抗鲁棒性。

② Reasoning Path Divergence 推理路径散度

• CoT 思维链专用指标，衡量多条推理步骤之间的差异，用来评估模型思考的多样性。

---

20. 认知的边际效应递减

你投入的每一份认知努力（时间、注意力、思考深度），所带来的认知增量，会随着投入总量的增加而逐步下降。

大致呈现三个阶段：

1. 指数增长期 — 从零到一，每一单位投入回报巨大。一个完全不懂编程的人，花10小时学到的东西堪称颠覆性。
2. 线性增长期 — 基础建立后，投入和产出大致成正比，但增速明显放缓。
3. 边际趋近于零 — 你已经是某个领域的专家，再花100小时可能只是把98分推到99分。更糟的是，有时甚至进入负边际回报——过度钻研导致”知识的诅咒”，反而丧失了判断力和直觉。

也有例外。有些领域的认知回报是阶梯式而非平滑递减的——长期的积累看似毫无进展，却在某个临界点突然跃迁（所谓”量变到质变”）。语言学习、哲学思考、艺术创作中这种现象比较常见。表面上的边际递减，可能只是你在为下一次跃迁积蓄势能。

所以这个规律真正的启示也许不是”少投入”，而是——知道自己此刻处于哪条曲线上，然后决定是继续深耕，还是转向新的指数增长区。

---

21. 正则表达式

常用元字符

\d → 数字 (0-9)

\w → 字母、数字、下划线

\s → 空白字符（空格、换行等）

. → 任意字符

+ → 前面的元素出现 1 次或更多

* → 前面的元素出现 0 次或更多

? → 前面的元素出现 0 或 1 次

{n,m} → 出现 n 到 m 次

[] → 字符集合，匹配其中任一个

() → 分组捕获

| → 或

^ → 行首

$ → 行尾

常见匹配示例

你想匹配的内容	正则表达式	解释
手机号码	1[3-9]\d{9}	以1开头，第二位3-9，后面跟9位数字
邮箱地址	\w+@\w+\.\w+	字符串@字符串.字符串
日期格式	\d{4}-\d{2}-\d{2}	四位数字-两位数字-两位数字
HTML标签	<[^>]+>	尖括号包裹的任意内容

示意 · 正则在 Agent 流程中的作用（纯文本流程）

用户输入
│
▼
┌──────────────┐
│  意图识别     │ ◄── 正则做初步分类
└──────┬───────┘
▼
┌──────────────┐
│  LLM 思考    │
└──────┬───────┘
▼
┌──────────────┐
│  解析输出     │ ◄── 正则提取 Action / Thought / Final Answer
└──────┬───────┘
▼
┌──────────────┐
│  调用工具     │ ◄── 正则校验参数
└──────┬───────┘
▼
┌──────────────┐
│  解析结果     │ ◄── 正则从工具返回值中提取关键信息
└──────┬───────┘
▼
┌──────────────┐
│  输出给用户   │ ◄── 正则做格式化和脱敏
└──────────────┘

---

22. 压缩策略

最开始的上下文蒸馏，具体机制包括从双评分到算子选择现在到一个预算管理器。

最先进的agent架构已不再使用固定的压缩率。这类agent引入了类似于流媒体的自适应循环：系统内置一个预算管理器，根据问题难度动态调整”思考深度”。硬问题用更多 token 推理，简单问题快速跳过。

• Token 预算管理：在多步推理中实时跟踪已消耗的 token/成本/时间，动态调整后续行为（比如切换到更便宜的模型、缩短输出、减少工具调用次数）
• 成本感知路由（Cost-aware Routing）：简单查询走小模型，复杂任务走大模型，由一个路由层决定

---

23. 语义场

语义场理论的演进脉络：

示意 · 语义场理论演进脉络（纯文本）

Trier (1930s)          Firth (1950s)          Transformer (2017+)
结构语义场             分布语义场              注意力语义场
│                     │                       │
人工分类体系          统计共现模式            动态上下文表示
静态、离散            半动态、稀疏            动态、连续
词级关系              词-上下文关系           任意粒度的关系
│                     │                       │
└─────────────────────┴───────────────────────┘
│
核心洞见从未改变：
意义 = 关系网络中的位置
理解 = 进入正确的语义场
推理 = 在语义场之间导航

对于多模态融合不仅是算法问题，更是数据流对齐的问题。我们需要构建一个漏斗形架构将纷繁复杂的物理信号收敛为统一的语义表征。

1. 编码层：提供的各个独立编码器是agent的不同感官。他们将原始的波形和像素转化为高维特征向量。
2. 对齐层：多模态融合模式的灵魂，他负责解决“语义鸿沟”如何让计算机明白，像素空间里的猫的形状和文本空间里的单词cat指向的是同一个实体。
3. 融合层：通过融合策略决定“感官”融合的时机。可以像CLIP对比是语言图像预训练一样各自独立编码，最后只在输出层握手。也可以像Gemini一样在深层的神经网络的每一层都进行交织。

---

24. 主流对齐机制

示意 · 对齐技术的四个阶段（纯文本）

对齐技术谱系

┌──────────────────────────────────────────────┐
│                第一阶段：行为克隆               │
│  SFT（监督微调）                               │
│  用人类示范数据直接模仿                         │
└──────────────────┬───────────────────────────┘
                   │ 不够——只能模仿表面模式
                   ▼

┌──────────────────────────────────────────────┐
│                第二阶段：偏好优化               │
│  RLHF → DPO → KTO → ORPO                    │
│  从人类偏好信号中学习"什么是好的回答"            │
└──────────────────┬───────────────────────────┘
                   │ 人类标注成本高且不一致
                   ▼

┌──────────────────────────────────────────────┐
│                第三阶段：自我对齐               │
│  Constitutional AI → Self-Play → RLAIF       │
│  模型依据原则自我改进，减少人类介入               │
└──────────────────┬───────────────────────────┘
                   │ 如何保证原则本身是对的？
                   ▼

┌──────────────────────────────────────────────┐
│                第四阶段：可扩展监督               │
│  Debate → IDA → Recursive RM → ARC 方法       │
│  解决超人类AI的对齐难题                          │
└──────────────────────────────────────────────┘

1. SFT：监督微调

收集高质量的 (指令, 回答) 数据对，让模型直接模仿。

SFT 的根本局限：

给定一个问题 Q，可能存在多个同样优秀的回答 A1, A2, A3…

SFT 只给了 A1 作为示范

→ 模型认为只有 A1 是对的

→ 排斥了同样合理的 A2, A3

→ 过度拟合于示范者的偏好

问题	说明
分布外泛化差	没见过的指令类型表现骤降
表面模仿	学会了格式而非深层推理
无法覆盖偏好	“好的回答”有多维度，SFT 只给一个标准答案
幻觉强化	如果示范数据包含错误，模型会”自信地”学会错误

2. RLHF：基于人类反馈的强化学习

不再告诉模型”正确答案是什么”，而是告诉模型”A 比 B 好”。

阶段 1：SFT 预训练

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

基座模型 + 指令数据 → SFT 模型

(教会模型遵循指令的基本格式)

阶段 2：奖励模型训练

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SFT 模型 → 对同一问题生成多个回答

↓

人类标注者对回答排序: A > B > C > D

↓

训练奖励模型 RM: prompt + response → scalar score

Loss = -log σ(r(x, y_w) - r(x, y_l))

其中 y_w = 人类偏好的回答

y_l = 人类不偏好的回答

阶段 3：PPO 强化学习优化

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SFT 模型作为策略 π

RM 作为奖励函数

目标: max E[RM(x, y)] - β·KL(π || π_SFT)

↑

KL 惩罚项

防止模型偏离 SFT 太远（“遗忘”）

问题 1：奖励黑客（Reward Hacking）

─────────────────────────────────────

模型发现了 RM 的漏洞——产生 RM 给高分但人类认为无意义的回答

示例:

RM 偏好长回答 → 模型学会啰嗦重复但不增加信息量

RM 偏好自信语气 → 模型对不确定的事也表现得非常确定

实际案例: InstructGPT 发现模型学会在回答末尾

添加”根据最新研究…”来骗取高分

问题 2：标注不一致性

─────────────────────────────────────

不同标注者对同一对回答的偏好可能相反:

标注者 A: “简洁回答好” → 选择短回答

标注者 B: “详细回答好” → 选择长回答

→ RM 学到了噪声信号

问题 3：训练不稳定

─────────────────────────────────────

PPO 本身是一个复杂的算法:

• 需要 4 个模型同时在 GPU 上：参考策略 π_ref, 当前策略 π, RM, 价值函数 V
• 超参数敏感
• 训练容易崩溃

3. DPO：直接偏好优化

RLHF 路径:

数据 → 训练 RM → RM 指导 PPO → 优化策略

(4个模型, 2阶段训练, 超参数复杂)

DPO 路径:

数据 → 直接优化策略

(2个模型, 1阶段训练, 超参数简单)

说明 · DPO 训练目标（纯文本）

意思是:
  "好回答"的奖励 = 新模型给它概率相对参考模型提升了多少
  "差回答"的奖励 = 新模型给它概率相对参考模型提升了多少

训练目标: 让好回答的相对提升 >> 差回答的相对提升

DPO 不需要一个显式的打分器，它让模型自己”拉开”好回答和差回答之间的隐式评分差距。

DPO vs RLHF 对比

维度	RLHF (PPO)	DPO
训练阶段	3 阶段	2 阶段
需要的模型	4 个	2 个（策略 + 参考）
显式 RM	需要训练	不需要
训练稳定性	较差（PPO 敏感）	好（标准交叉熵）
超参数数量	多	少（主要是 β）
计算成本	高	低
在线/离线	在线（需要采样）	离线（直接用数据集）
长尾分布覆盖	好（可以探索）	有限（受限于离线数据）

1. 分布偏移问题

   ━━━━━━━━━━━━━━

   DPO 用离线数据训练，数据中的 (y_w, y_l) 是由旧策略生成的

   随着策略更新，这些数据不再反映当前策略的分布

   解决方案:

   • Iterative DPO / Online DPO: 定期用当前策略重新采样
   • 在线 RLHF 没有这个问题（但成本高）

2. 隐式 RM 的局限

   ━━━━━━━━━━━━━━

   DPO 的隐式奖励不如显式 RM 灵活

   • 无法用于 Best-of-N 采样
   • 无法用于数据过滤
   • 无法跨任务迁移

3. 对数据质量更敏感

   ━━━━━━━━━━━━━━

   没有 RM 的泛化缓冲，噪声标注直接损害策略

4. Constitutional AI：自我对齐

Anthropic 的方案

核心思想：用一组明确的原则（宪法）来指导模型自我改进，大幅减少人类标注的参与。

示意 · CAI 与 RLHF 路径对比（纯文本）

传统 RLHF:  人类写示范 → 人类做偏好判断 → RL 优化
CAI:        人类写原则 → 模型自我判断   → RL 优化

                人类的角色从"裁判"变为"立法者"

5. 过程奖励模型（PRM）

ORM（传统）: 只看最终答案对不对

PRM（新兴）: 看推理过程中每一步对不对

示例 — 数学题:

ORM: 答案是 42 → 对/错（0/1 信号）

PRM:

Step 1: 设 x = … → 正确 ✓ (+0.2)

Step 2: 代入方程 → 正确 ✓ (+0.2)

Step 3: 化简得… → 错误 ✗ (-0.1) ← 关键: 定位到具体哪一步出错

Step 4: 因此 x = 42 → 继续错误

PRM 的优势: 信号更密集、可解释、指导性更强

---

25. 主动感知模式实现流程

实现主动感知模式的核心有两个问题：何时停、去哪儿找。

一、基于元认知的触发机制

不能对所有请求都开启主动感知（成本过高），系统需要先识别触发条件：

• 显式触发：当用户查询包含“分析”“查询”等动词时，需要显式触发主动感知。
• 隐式触发：模型在尝试回答时发现缺失关键实体，需要隐式触发主动感知。

二、渐进式信息检索

类似于人类在图书馆找书，agent的感知路径通常遵循以下策略：

• 后退一步：如果问题太具体导致查不到，agent应主动生成一个更宽泛的查询，先获取大文档。
• 深挖一步：获取大文档后，不再进行搜索而是通过机器阅读理解精准定位具体数值。

---

26. 记忆系统

记忆系统正在从SDK发展到框架，从云服务抽象层发展到平台能力。MaaS（记忆即服务）有望成为未来重要的跨agent、跨应用的云端记忆基础设施。

它将用户画像、长期偏好、行为模式、任务历史、语义图模型统一封装为可调用服务，使不同的agent共享同一个认知底座。MaaS可称为原生记忆。

---

27. 推理模式

将推理抽象为3个层次：

1. 结构层
2. 流程层
3. 反思层

根据任务的歧义程度、探索深度与约束条件，推理可呈现为4种经典模式：

1. 链式：思维链

流程：引导机制 → 推理缓冲 → 逻辑自检 → 答案提取器

核心作用：

1. 概率的重新分配：收敛了答案空间
2. 显式分解：将复杂问题序列转换为一系列原子步骤。“降维”
3. 自我校准：构建一种微型的短期记忆回路，有助于抑制幻觉的积累。

2. 树式：思维树

将 LLM的推理过程建模为状态空间中的搜索。通过搜索、评估和回溯，它能够有效应对那些需要全局规划或容易陷入局部最优的复杂问题。

生成层：负责发散，它接收初始问题并生成若干可能的下一步行动方案。保证思维的多样性，通常设置较高的temperature或者用专门的prompt，仅负责生产部判断方案的对错。

评估层：负责收敛，他接受生成层输出的思路，并计算其价值函数。该层核心是状态评估器评估方式有多种，根据评估结果，低分路径被剪枝，高分路径被选中深入推理，中等分路径可能被暂存，留后续可能待回溯时再进行考虑。

搜索层：是思维的推进中心，负责对评估层判定为有潜力的路径进行进一步探索。该核心是**搜索控制器。**他决定下一步是继续深入当前路径、回溯并切换至其他路径，还是并行探索多个分支。该组件由非模型的确定性逻辑代码实现，负责内存管理以及整体搜索方法的调度和协调。

其核心本质是将LLM的概率生成过程重构为思维空间中的启发式搜索过程。这一过程依赖三个核心原语——分解、生成与评估。

• 分解：节点的粒度
• 生成：多次采样，探索状态空间
• 评估：定义价值函数

---

蒙特卡洛树搜索：四个关键步骤——选择、扩展、模拟、回溯。

示意 · MCTS 四个关键步骤（纯文本）

┌─────────────────────────────────────────────┐
│ 1. 选择（Selection） │
│ 从根节点出发，用 UCB1 公式选最有前途的子节点 │
│ 平衡"已有高分路径"vs"未充分探索的路径" │
├─────────────────────────────────────────────┤
│ 2. 扩展（Expansion） │
│ 让 LLM 在该节点生成 K 个候选下一步 │
│ 比如：(4,5,6,7) → 4+5 / 4×5 / 5-4 / ... │
├─────────────────────────────────────────────┤
│ 3. 模拟（Simulation / Rollout） │
│ 从新节点开始，让 LLM 快速推到底，看结果好不好 │
│ 类似下棋时"随便下几步看看大概局面" │
├─────────────────────────────────────────────┤
│ 4. 回溯（Backpropagation） │
│ 把模拟结果往回传，更新路径上每个节点的得分 │
│ 好结果 → 提高该路径被再次选中的概率 │
└─────────────────────────────────────────────┘

计算成本昂贵，通常应用在高价值、低频次、低容错率的场景，在这些场景下通过推理实际算一算力换取更高的准确率是值得的。

思维树的模式组合示例

思维树的核心痛点在于搜索空间的指数级爆炸。为有效应对这一问题，需要借助其他模式辅助减脂或提供更准确的评估信号，从而显著收敛搜索范围、提升推理效率。

• 思维树模式与RAG模式的组合=检索增强思维树：若思维树的生成器缺乏领域知识则容易在错误路径上持续深入，引发幻觉。引入RAG相当于让侦察兵在探路前先查阅地图提升推理路径的相关性与准确性。
• 思维树模式与工具编排模式的组合=验证器引导搜索：LLM在自我评估方面存在短板，尤其当涉及数值计算或代码逻辑时，其内部评分往往不可靠。该组合以确定性工具提供的反馈，替代模型概率性评分。将原本依赖直觉的搜索过程转化为严谨的假设验证闭环。
• 对比思维链 分支能力、评估能力、回溯能力、启发能力。

3. 图式：思维图

思维图模式将推理过程建模为有向图，允许思维在非线性的拓扑结构中流动。它引入了思维链和思维树所不具备的“合并”与“循环”的能力，特别适用于需要综合多重视角、跨文档整合信息或反复迭代优化的复杂任务。

4. 类比式

当问题新颖、数据稀缺或缺乏先验规则时，通过映射已知情境的结构来启发对未知问题的理解。

---

28. 工具编排模式

关键组件：工具注册表、语义路由器、协议适配器。

协议适配器：主要负责在不同协议之间进行转换，下游的API可能使用特定的数据格式，确保系统各部分之间能够无缝对接。

三大核心机制

工具编排模式远不止将API简单注入模型，为确保高准确率与鲁棒性，必须引入以下三大机制。语义路由应对规模挑战、结构化强制解决格式问题、错误自修复处理逻辑问题，这三者共同构筑了工具编排模式的护城河。

1. 语义路由

当prompt无法容纳所有工具的定义时，我们需要引入动态上下文机制，对所有工具的描述进行向量化处理。

• 用户查询：用户输入意图，触发工具选择流程。
• 向量检索：对用户查询进行嵌入化处理，在工具库中检索最相关的工具。
• Top K工具筛选根据相似度呃对结果进行排序，选取前K总最有可能被调用的工具。
• 提示注入：将候选工具的说明、 sketchma及调用格式动态注入prompt，引导模型最做出最终的工具调用决策。

2. 结构化强制

语言模型天生倾向于聊天儿，儿而非填表。为确保API调用的成功率，必须在推理阶段引入语法约束。

• JSON模式：强制模型输出的token严格符合JSON语法。
• 语法约束解码：在采样阶段直接屏蔽不符合schema的token概率，从根本上杜绝格式错误。

3. 错误自我修复

例如，当模型生成一个答案是，API就会返回对应的错误。编排器捕获该错误，并将错误信息作为prompt的一部分反馈给模型。模型根据此识别出的错误，重新生成正确回答。

---

29. 自适应策略模式

自适应策略模式是“进化论”的产物。Agent被置于一个充满未知的环境中，它必须通过试错、反馈和选择，逐渐演化出最优的决策策略。

关键要素：

• 基因：agent的策略参数，包括property模板、工具选择权重和推理路径。
• 环境：用户请求及外部工具的反馈。
• 适应度：用于衡量策略优劣的奖励信号（如用户点赞、任务成功率和响应速度等指标）。

通过应用强化学习或多臂老虎机等机制，agent在探索与利用之间动态寻求最优平衡。

核心机制：

• 探索：主动尝试未充分了解的策略，虽然短期内可能会踩坑降低性能，但从长期来看有望发现更优甚至全局最优的解决方案。
• 利用：始终选择当前最好的策略，这种做法容易使系统陷入局部最优解，视野受限难以发现潜在优势。

常见解决方案是采用贪心算法来平衡探索与利用：以90%概率选择当前认为最优的动作，以10%的概率随机尝试其他动作，缺乏环境动态变化的精细适应性。

更优的方法是采用Thompson采样算法，该算法通过根据每个动作的后验概率分布进行采样，并选择采样结果最优的动作来实现策略选择。其核心理念在于：某个动作的不确定性越高（如方差越大），就越值得去探索。这种算法能够自适应的调节探索长度，根据环境的动态变化灵活调整策略。它在理论和实践中均表现出色，已成为当前agent策略选择的主流算法之一。

---

30. 多臂老虎机——探索+利用平衡问题

• Epsilon-Greedy（ε-贪心）
• UCB1（Upper Confidence Bound）— MCTS 用的就是这个
• Thompson Sampling（汤普森采样）

策略对比

方法	原理	优点	缺点
ε-Greedy	确定性 + 随机	简单	后期浪费
UCB1	乐观面对不确定性	理论保证强	需要记录次数
Thompson	贝叶斯采样	实战效果最好	需要维护分布

---

31. 护栏机制

在自我修正时期，通常会经过反复的迭代循环测试，这时候护栏机制显得十分重要。

在企业级 AI 系统中，护栏并非为了束缚模型，而是为了让模型在安全边界内更自由、更充分地发挥其能力。护栏的作用可以概括为3点：一是限制模型能做什么，明确其行为边界；二是确保其按规则执行，保障运行的规范性；三是在出错时及时拦截，避免问题扩大。越是强大的 Agent 系统，越需要更坚固、更智能的护栏机制。

护栏机制包含以下4种实施方式：

1. 权限护栏（Capability/Permission Guardrail）

模型只能执行其被明确授权的操作。具体落地方式包括：为每个 Agent 配置权限表，并在调用工具前进行白名单检查。

2. 策略护栏（Policy Guardrail）

模型必须严格遵守业务规范与合规要求。此类护栏并非依赖 “AI 技术”，而是依赖 “规则工程”，具体规则包括以下禁止性与强制性条款：不得输出敏感数据；不得生成带有偏见或歧视性的内容；不得提供超出其资质范围的建议（如医疗诊断、法律意见等）；不得修改未授权的数据；不得绕过 HITL 节点。具体落地方式包括：在输出前进行内容过滤、对高风险任务强制触发 “人类审核”，并在模型 Prompt 中内嵌明确规则，例如，“你不得做…… 你必须做……”。

3. 行为护栏（Runtime Guardrail）

在模型出错时自动 “踩刹车”，实现实时干预。此类护栏主要用于 “运行时拦截”。具体落地方式包括：沙箱执行，限制模型在代码执行过程中可使用的 CPU、I/O 和网络资源；安全监控，实时检测异常行为，如输出长度突增、行为模式偏离正常范围、生成危险指令或连续多次失败等。一旦监视器判定模型 “跑偏”，就立即中断当前流程，并触发回退机制。回退机制包括自动切换至更可靠的模型、转交人工处理，或降级至更保守的执行路径。

4. 审计护栏（Audit Guardrail）

确保所有操作全程可追溯。具体落地方式包括：记录每次推理链的完整过程；记录所有 Agent 之间的交互内容，包括数据传输和指令传递；记录每次对外部 API 的调用，涵盖完整的输入与输出内容；记录每次失败的根本原因以及系统执行的自动修复动作。

---

32. 反思记忆模式

基于一个记忆的递归架构，包含两个循环路径，一个用于执行任务，一个负责积累经验。

反思循环：负责观察执行循环的表现，提炼经验，并更新执行循环的上下文，也会存在记忆里。

核心机制：

• 语言的强化学习： 通过自然语言理解什么是好的行文。
• 启发式提取：从具体的实例中抽象出普适的原则。
• 记忆检索：举一反三，实现经验的跨任务迁移。

目前已经存在Expel，跨任务学习。

---

33. prompt的优化

• DPRO：它利用模型作为编译器，分析历史轨迹，推测下一个更优的prompt，类似于遗传算法，提升元性能。黑盒，容易随机突变。
• DSPy：编程式优化语言模型（LLM）提示词和权重的框架。

将prompt参数化，将prompt视为权重，不手动编写，定义逻辑接口； 具体的prompt由系统生成，其类似于模型的权重。

传统方式：
  手写 Prompt → 测试 → 不行 → 改 Prompt → 再试 → 反复折腾...

DSPy 方式：
  定义"做什么"（声明式） → DSPy 自动帮你优化 Prompt → 找到最优版本

适用场景
RAG（检索增强生成）的多步推理链
需要多轮 LLM 调用的复杂 pipeline
从少量标注数据出发，自动优化 Prompt
需要在不同 LLM 之间快速切换

• TextGrad：通过反向传播，用评估器生成一段文本反馈（语义梯度），指出推理中错误的原因。优化器根据反馈，修改system prompt中的相应部分。

---

34. 协作模式

本节中的纯文本块用于展示流程与规则示意，并非可执行代码。

1. 辩论（对抗）

借助多 Agent 之间的对抗性交互（adversarial interaction），揭示单体 Agent 思维中的盲点与幻觉，迫使信息在多轮推理的准确性与全面性。

在这一模式中，冲突不再是需要消除的缺陷，而是一种核心特征。通过主动引入对抗，我们迫使模型走出 “概率舒适区”，深入探索更深层的逻辑一致性。

辩论并非各说各话，而是一种回合制的零和博弈：每一轮的输出都必须直接应对对手的发言，进行有针对性的反驳或防御。

- 回合 1：正方提出初始方案。
- 回合 2：反方必须引用正方的原文，对其逻辑、事实或假设发起精准攻击，不得回避或转移话题。
- 回合 3：正方必须承认反方指出的客观错误，并据此修正或完善原方案。

这一机制强制 Agent 在多轮交互中维持高度的上下文一致性与逻辑连贯性，避免空泛陈述或自说自话。

链式思维的一致性校验

DeepMind 的研究表明，让模型进行辩论可显著提升其在数学和逻辑问题上的准确率。其核心原因在于：编造一个谎言很容易，但要维持一个逻辑自洽的谎言极为困难。在多轮高强度的质询下，幻觉往往因前后矛盾、无法形成闭环而 “自爆”；而真实、正确的结论则因其内在一致性得以经受住挑战，屹立不倒。 辩论模式的核心在于，通过 “多视角的交集” 逼近真理。通过主动制造认知冲突，系统能够有效过滤掉那些经不起推敲的概率性生成内容，从而保留具有逻辑坚实性与内在一致性的确定性结论。

2. 委托（层级）

通过 “分而治之”，委托模式有效缓解了单体 Agent 上下文窗口限制和注意力分散导致的能力瓶颈。同时，借助层级结构引入 HITL 机制，确保系统在关键节点上保持可控性。

委托模式的拓扑结构不再是扁平的网络，而是严格的有向树。

• 核心机制

  • 递归分解

  复杂任务往往无法通过单层分解完成。
  
  - Manager：接到 “写财报” 任务后，将其分解为 “写第 1 章”“写第 2 章” 等子任务。
  - Worker A：接到 “写第 1 章” 子任务后，发现该子任务仍过于复杂，于是转变为 Sub-Manager，进一步将该子任务分解为 “写 1.1 节”“写 1.2 节” 等更细粒度的子任务。
  
  这种分层式的递归结构，使 Agent 系统在理论上具备处理任意复杂度任务的能力。

  • Map-Reduce

  这是处理长文档或大规模数据的标准委托模式。
  
  - Map（分发）：Manager 将 100 份财报分发给 10 个 Worker 并行处理，每个 Worker 只负责提取 “净利润” 这一项数据。
  - Reduce（归约）：Manager 汇总 10 份提取结果，融合生成一份综合报告。
  
  Map-Reduce 模式显著突破了单体 Agent 的 Token 速率限制。

  • 审批流

  为了防止 Agent “暴走”（如循环调用付费 API 或误删数据库等），必须设计中断机制。
  
  - 被动中断：当 Agent 执行的操作风险评分超过阈值时，自动挂起并通知人类介入。
  - 主动中断：Agent 每完成一个里程碑，就主动暂停，等待人类确认后方可继续执行。

委托模式的运行机制由 3 部分组成：通过递归分解处理任意复杂度的任务，通过 Map-Reduce 应对大规模并行任务，并通过审批流构建可靠的人机安全边界。

3. 路由（分发）

路由器，专家池，聚合器

核心机制：

• 语义路由：① 嵌入相似度匹配 ②模型意图分类

• A2A协议： 在 2024 年备受瞩目的 MoA（Mixture of Agents，Agents 混合）架构中，路由器不再局限于选择单一专家，而是将同一问题并行分发给 3 个专家。随后，引入一个聚合 Agent，对 3 个专家的回答进行综合分析、取长补短，最终融合生成一个更全面、更高质量的答案。 语义路由提升了任务分发的精度，A2A 协议保障了 Agent 之间的互操作性，Agent 混合聚合则突破了单点智能的能力上限。三者协同，共同构建了一个开放、高效、可扩展的智能生态系统。 A2A 协议要解决的核心问题：让每个 Agent 像微服务一样，通过统一的消息格式和标准化的能力描述进行相互调用，从而将协作模式从 “企业内部编排” 升级为跨系统协同。

  - 发现(Discovery);路由器广播查询，例如，“谁懂Python?"
  - 能力声明（Capability Statement）：专家 A 响应 ——“我懂，我的接口 Schema 是……”
  - 握手（Handshake）：路由器发送符合标准格式的请求载荷。
  - 响应（Response）：专家返回结构统一的标准结果。

MoA 与 MoE

MoA 与 MoE 名称相似，但含义不同，这里简单说明一下。

MoE（Mixture of Experts，专家混合）解决的是模型内部的效率问题：它在一个模型中集成多个 “专家子网络”，并通过一个门控机制动态决定在每次推理时激活哪些专家，其核心目标是节省计算资源、提升推理效率，本质上属于参数层面的工程优化策略。 MoA 解决的是系统层面的问题：它并非在模型内部划分专家，而是让多个 Agent 并行协作 —— 有的负责分析，有的负责质疑，有的负责总结，最终将各自的输出融合为一个更稳健、可靠的答案，其核心关注点在于认知分工与决策质量的提升。 MoE 关注的是 “一个大脑如何更省力地计算” 的问题，而 MoA 关注的是 “多个大脑如何协同思考、把事情想对”。在 Agent 时代，MoA 更贴近真实世界中的协作模式，强调群体智能与认知互补；而 MoE 则是底层模型的一种高效计算加速机制。二者并非替代关系，而是分别作用于系统架构的不同层次。

4. 群体（涌现）

在委托模式中，一旦 Manager 失效，项目进程就会停滞不前。然而，在群体模式中，即使有 10 个 Agent 失效，剩下的 90 个依然能够协作完成任务。这正是分布式系统的终极优势 —— 高容错性和鲁棒性。

群体模式采用的是网状或场状的拓扑结构。在这种架构中，架构师不再专注于设计传统的 “指令流”，而是构建一个促进互动的 “交互场”，如图 9-11 所示。在这个交互场中，每个 Agent 不仅是任务的执行者，同时也扮演着路由器的角色，根据局部信息和环境状态进行决策和信息传递。

群体模式的架构没有层级，只有环境和个体。

- 个体（Individual）：通常是轻量级、擅长遵循指令的 Agent。它们不需要理解 “全部目标"
- 环境（Environment）：作为群体模式的 “通信介质”，环境承载着 Agent 之间的信息交换与状态共享。在 OpenAI 的 Swarm 中，它体现为上下文变量；在更复杂的系统中，它通常表现为一种共享黑板、即时通信群组或虚拟仿真世界。
- 交接机制（Handoff Mechanism）：群体模式的关键连接点可类比为 “突触”。例如，当 Agent A 完成其任务后，可直接将控制权或上下文传递至 Agent B，不需要经过路由器或 Manager 的审批。
- 局部规则（Local Rule）：硬编码在 Agent 的 System Prompt 中的简单、明确的行为准则，例如，“如果你发现他人的代码存在 bug，就直接修复，不需要请示”。

核心机制：

留痕

“留痕” 一词源于昆虫学中的 Stigmergy（由希腊词 Stigma “痕迹” 与 Ergon “工作” 组合而成），意指个体 通过修改共享环境来实现与其他个体的间接通信与协作。 例： 假设我在维基页面上修改了一行文字，你随后看到并在此基础上继续编辑 —— 我们之间不需要直接对话或协调，“维基页面” 本身便充当了通信介质。 Agent 之间不需要建立直接的 TCP 连接。例如： 这一机制的工程本质是 解耦：生产者不需要知晓消费者的身份或位置，只需要将 “痕迹”（即状态或事件）写入共享环境；消费者则根据自身职责对环境中的变化作出响应。

• Agent A 在共享内存（如 Redis 或 Blackboard）中将订单状态更新为 {"status":"approved"}
• Agent B 持续监听环境变化，一旦检测到该状态变更，便自动触发 “打款” 操作

动态交接

动态交接是 OpenAI 的 Swarm 的核心机制之一。

例如，在客服场景中，当客服 Agent 正在服务客户时，如果发现客户提出的问题涉及极其底层的代码错误，它不会将问题上报给 Manager，而是直接返回一条指令：Transfer(target="TechAgent")。 随后，执行流可在毫秒级时间内完成切换，并携带完整的上下文信息，实现无缝流转。 这种机制不仅使系统响应极为迅速，还显著降低了维护成本 —— 因为 谁最懂业务，就由谁决定转交给谁。

• 在传统的路由模式中，信息流转的路径是：Router（中央集权）→ Agent。
• 在 Swarm 所采用的路由模式中，信息流转的路径是：Agent（去中心化）→ Agent。

涌现

涌现是系统论中一种神奇而迷人的现象，堪称系统论的 “魔法”。 从微观的视角来看，每个 Agent 似乎都显得有些 “笨拙”，它们仅能执行一些简单的 if-else 语句。例如，如果检测到差评，Agent 就会生成一封道歉信。 然而，从宏观的视角来看，当有成百上千个这样的 Agent 并行协作时，整个系统却能够展现出令人惊叹的 “审慎的决策能力” 和 “自我修复能力”。 可以借用以下公式来定义涌现： 涌现无法被直接设计，只能通过培育来实现。我们需要设定良好的初始条件和有效的反馈机制，为涌现的产生创造有利的土壤。

涌现 = 简单的局部规则 × 大量互动 × 开放环境

留痕解决了 “如何表达” 的问题，动态交接解决了 “如何传递” 的问题，而涌现则决定了 “能做什么”。三者紧密结合，使群体模式成为应对高并发、高动态性和高抗毁性要求任务的最佳选择。