纠错：不要原地覆盖#

原地 UPDATE 是最直觉也最糟的做法——你丢失了「曾经认为是什么」，而排查问题时恰恰需要这个。

正确做法是 append-only + 失效标记（tombstone），每条记忆带完整的 provenance：

1
{
2
  "id": "mem_8f3a",
3
  "content": "项目主库是 MySQL",
4
  "source": "session_412 第 7 轮用户发言",
5
  "confidence": 0.8,
6
  "created_at": "2026-06-14T10:22:00Z",
7
  "invalidated_by": "mem_c91d",
8
  "invalidated_at": "2026-09-12T09:15:00Z"
9
}

冲突仲裁按三级优先：用户显式确认 > 来源可信度 > 时间新近。注意顺序——不能无脑「新的覆盖旧的」，否则模型一次幻觉就能把用户亲口说过的事实冲掉。

高风险记忆（用户身份、权限、关键配置）的写入应该走确认流程，而不是让 agent 自主写。

共享：分层，不要全共享#

全共享的真正风险不是冲突，是错误放大——一个 agent 的幻觉会污染所有 agent，而且事后没人知道源头在哪。

1
┌─────────────────────────────────┐
2
│ 全局事实层  写入需仲裁，只读为主   │  用户身份、项目约束
3
├─────────────────────────────────┤
4
│ 任务层     同一任务内的 agent 共享 │  当前任务的中间结论
5
├─────────────────────────────────┤
6
│ 私有层     agent 独占             │  自己的推理草稿
7
└─────────────────────────────────┘

向上提升要带证据和仲裁，向下读取自由。这样单个 agent 出错的影响被限制在它自己的层里。

争抢的资源#

按踩坑频率排序：

隔离#

上下文隔离是默认且必须的——每个 agent 独立的 context window，互不可见。这不只是防污染，也是省钱：共享上下文意味着每个 agent 都要为其他 agent 的对话付 token 费。

状态隔离用消息传递，不要用共享内存。agent 之间通过结构化消息通信，需要共享的状态收敛到一个有明确所有权的地方（比如一个协调者），而不是让多个 agent 直接读写同一块数据。

1
❌ agent A ──写──→ 共享状态 ←──写── agent B      竞态，且难以追溯
2
✅ agent A ──消息──→ 协调者 ←──消息── agent B     单点写入，有序

副作用必须幂等。agent 重试是常态，同一个操作执行两次不能产生两份结果——用幂等键去重（见第 11 题）。

存储#

长期记忆要双写：向量库存语义可检索的表述，结构化表存精确事实（用户 ID、偏好枚举、配置项）。前者用于「想起相关的事」，后者用于「精确查询某个字段」——不要指望向量检索能可靠地答出「用户的邮箱是什么」。

短期记忆窗口满了要摘要压缩而不是直接截断：把最老的 N 轮对话压缩成一段摘要，保留结论丢弃过程。

过期#

只靠 TTL 不够，要按分数衰减：

1
score = importance * exp(-λ * days_since_access) * log(1 + access_count)
2
# score 低于阈值 → 归档（不是删除）

重要但很久没访问的记忆不该被清掉（用户的过敏史、关键约束），所以 importance 是乘数而不是加数。归档而非硬删除，留一条回溯的路。

去重#

三层，从便宜到贵：

1. 精确：内容规范化（去空白、统一大小写、标点）后算 SHA256
2. 近似：SimHash / MinHash，抓「改了两个字」的重复
3. 语义：embedding 余弦 > 0.92 判定重复

命中重复时的正确动作是 upsert 更新——合并 provenance、刷新访问时间、提升 confidence，而不是新增一条。否则同一个事实会在库里堆成十几条，检索时全部挤进 top-k，把其他记忆挤出去。

① 约束解码 / Structured Outputs（首选）#

在采样阶段就限制 token 空间，让不符合 schema 的 token 概率归零。这是从根本上不可能出错，不是「出错概率低」：

1
response = client.messages.create(
2
    model="claude-sonnet-5",
3
    tools=[{
4
        "name": "extract",
5
        "input_schema": {
6
            "type": "object",
7
            "properties": {
8
                "sentiment": {"type": "string", "enum": ["正面", "负面", "中性"]},
9
                "score": {"type": "number"}
10
            },
11
            "required": ["sentiment", "score"]
12
        }
13
    }],
14
    tool_choice={"type": "tool", "name": "extract"},
15
    messages=[{"role": "user", "content": text}],
16
)
17
data = response.content[0].input          # 已经是 dict，无需解析

② 工具调用#

本质上也是 schema 约束，模型对工具调用格式的训练强度通常高于自由文本里的 JSON。

③ Prompt + 校验重试（兜底）#

如果只能走这条，关键是把 validation error 原文喂回去：

1
for attempt in range(3):
2
    raw = llm(prompt)
3
    try:
4
        return Model.model_validate_json(extract_json(raw))
5
    except ValidationError as e:
6
        prompt += f"\n\n上次输出的错误：\n{e}\n请修正后重新输出。"

把具体错误告诉模型，比重复一遍「请输出合法 JSON」有效得多。

工程细节#

• 降温度到 0~0.2，结构化输出不需要多样性
• 避免深嵌套，超过两层显著掉准确率——扁平化或拆成多次调用
• 避免长自由文本字段，未转义的引号和换行是解析失败的主因
• 流式场景用增量 JSON parser（partial-json）
• max_tokens 给足，截断产生的半截 JSON 是最难排查的一类失败

① 硬预算（必须有）#

1
@dataclass
2
class Budget:
3
    max_steps: int = 50
4
    max_tokens: int = 500_000
5
    max_seconds: int = 600
6
    max_cost_usd: float = 5.0

任何一项超限立即停止。这是最后一道防线，其他机制都失效时靠它兜底。

② 重复检测#

工具名 + 参数规范化后哈希，连续 N 次相同即判定循环：

1
sig = hashlib.sha256(
2
    f"{tool_name}:{json.dumps(args, sort_keys=True)}".encode()
3
).hexdigest()
4
if history[-3:] == [sig] * 3:
5
    raise LoopDetected(f"连续 3 次相同调用：{tool_name}")

注意要规范化参数——{"a":1,"b":2} 和 {"b":2,"a":1} 是同一个调用。

③ 无进展检测#

比重复检测更狠一层：调用不重复，但世界状态没变。比如反复用不同关键词搜索却一无所获，或者反复修改同一个文件却改不对。

判据是外部可观测状态的哈希（文件 mtime + 内容哈希、测试通过数、任务清单完成项），连续 N 轮不变即判定卡住。

④ 升级策略（最容易漏）#

检测到循环之后干什么？这才是关键：

1
换方案 → 缩小问题范围 → 请求人工介入 → 放弃并如实报告

没有 escalation 的 agent 会在预算耗尽时静默失败，然后返回一个看起来完成了的假结果。这比循环本身危害大得多——循环至少是可见的。

① 记忆有时间维度和主体性#

RAG 语料是静态、无主的——一份产品文档不属于谁，也不会「过期」（版本更新是另一回事）。记忆则是某个人在某个时刻说的某句话，脱离时间和主体就失去意义。

上面第三个演示就是这个：把 recency 和 importance 权重拖到 0，它就退化成普通 RAG——然后三个月前那条「项目用 MySQL」会盖过上周的「已迁移到 PostgreSQL」，因为前者和「数据库」这个 query 的字面相关性更高。

1
score = w_rel * relevance + w_rec * exp(-λ*Δt) + w_imp * importance

② 记忆会自相矛盾#

文档库里两份文档说法不一致，是数据质量问题。记忆里两条记录说法不一致，是正常现象——用户改主意了。所以记忆系统必须有仲裁逻辑（第 2 题），RAG 通常不需要。

③ 召回常常没有显式 query#

RAG 是「用户问了问题 → 去检索」。记忆召回很多时候没有人在提问，是根据当前上下文自动触发的联想——用户刚说到部署，系统应该主动想起「这个项目禁止手动上传」。

这意味着记忆召回的 query 是从上下文构造的，而且要控制触发频率，否则每轮都塞一堆无关记忆进去。

④ 记忆是 agent 自己写的#

这是最关键的差异。RAG 语料是外部给定的，质量由人把关。记忆是系统自己写进去的——一次幻觉写入会被后续检索反复强化，形成自我确认的错误闭环。

所以记忆必须有 confidence 和 provenance，而 RAG 的 chunk 通常不需要。

核心：把任务建模成可持久化的状态机#

不要让任务状态只活在内存和对话历史里。显式建模成 DAG，每个节点有明确的输入、输出和状态：

1
@dataclass
2
class Step:
3
    id: str
4
    status: Literal["pending", "running", "done", "failed"]
5
    input_hash: str        # 输入变了要重跑
6
    output: Any | None
7
    attempts: int = 0

每步完成立即落 checkpoint，恢复时跳过 done 的步骤直接复用其 output。

三个关键点#

① 步骤必须幂等

恢复时不确定上次那步到底做完没有——可能结果已经产生但 checkpoint 没写成功。所以外部副作用要带幂等键：

1
# 同一个 idempotency_key 重复调用只生效一次
2
create_order(payload, idempotency_key=f"{task_id}:{step_id}")

② 区分可重试和不可重试的失败

网络超时、429、5xx → 自动退避重试。 参数错误、权限不足、业务规则拒绝 → 重试一万次也是同样结果，直接升级给人。

把这两类混在一起自动重试，会在必然失败的操作上烧掉整个预算。

③ checkpoint 存摘要，不存全量对话

这是最容易踩的坑。把完整对话历史序列化进 checkpoint，恢复时一次性塞回上下文——直接爆窗口。

checkpoint 里应该存的是结构化的任务状态（哪些步骤完成了、产出是什么、关键决策及其理由），恢复时用这些重建一个精简的上下文，而不是重放原始对话。

SSE 就是一个普通的 HTTP 响应#

这一点决定了一切：

1
GET /v1/chat/stream
2
Accept: text/event-stream
3

4
HTTP/1.1 200 OK
5
Content-Type: text/event-stream
6
Cache-Control: no-cache
7

8
data: {"delta":"你"}
9

10
data: {"delta":"好"}
11

12
data: [DONE]

既然是普通 HTTP，那么现有的鉴权中间件、CDN、API 网关、访问日志、限流、WAF 全部直接复用。WebSocket 走的是 Upgrade 协议切换，上面这些基本都要重做一遍——鉴权怎么做（URL 带 token 会进日志）、网关支不支持、日志怎么记、限流怎么算。

浏览器原生支持且自动重连#

1
const es = new EventSource('/v1/chat/stream');
2
es.onmessage = e => render(JSON.parse(e.data));
3
// 断线自动重连，并自动带上 Last-Event-ID 请求头续传

WebSocket 的重连、心跳（keep-alive ping）、指数退避全要自己写，而且写对不容易。

其他现实因素#

• 企业代理和防火墙经常拦 WebSocket，SSE 是标准 HTTP 流量
• HTTP/2 下 SSE 复用连接，没有旧 HTTP/1.1 时代 6 连接上限的问题
• 中断只需要 es.close() 或 AbortController，不需要额外协议约定

什么时候才该用 WebSocket#

真正的双向低延迟场景：实时语音对话（音频流双向）、协同编辑（多客户端互相广播）、需要客户端高频推送状态的场景。

判据很直接：客户端是否需要在流传输过程中持续向服务端发送数据。如果只是「发一个请求、收一串 token」，SSE 就是正确答案。

一个常见误解：SSE 不能发 POST。确实，EventSource 只支持 GET，但用 fetch + ReadableStream 读 text/event-stream 就能配合 POST——现在主流 SDK 都是这么做的。

铁律：在检索层过滤，不在生成层过滤#

1
❌ 检索全库 → 把所有结果给模型 → prompt 里说"只引用有权限的"
2
✅ 带 ACL 条件检索 → 只有有权限的内容进入 prompt

让模型「看到了但别说」是幻想。 提示词注入、模型幻觉、多轮追问都能把内容套出来。唯一可靠的做法是让无权限内容根本不进入上下文。

pre-filter，不是 post-filter#

这是本文第二个演示的内容，建议拖一下滑块看效果：

• post-filter：先取全库 top-k，再剔除无权限的 → 剩几条全看运气
• pre-filter：把 ACL 作为检索条件下推，top-k 始终取满

权限比例 30%、top-k = 20 时，post-filter 平均只剩 6 条。权限越稀疏，塌陷越严重——这时候用户体验是「系统查不到东西」，而不是「没权限」，排查起来很费劲。

pgvector 下 pre-filter 就是一个 WHERE：

1
SELECT chunk_id, content, embedding <=> :q AS dist
2
FROM chunks
3
WHERE acl_groups && :user_groups      -- 数组相交，先过滤
4
ORDER BY embedding <=> :q
5
LIMIT 20;

注意索引设计——要让 ACL 条件能有效过滤，否则查询计划可能退化成全表扫描后再排序。

四个隐蔽的泄漏点#

① ACL 快照过期 索引里存的是构建时的权限。用户离职、文档改密级之后，索引没更新 = 越权。要么实时查权限系统，要么保证 ACL 变更立即触发索引更新。

② 引用列表泄漏元数据 正文过滤了，但「参考来源：《2027 年裁员计划.docx》」还在——标题本身就是敏感信息。引用列表要走同一套过滤。

③ 跨用户缓存 用 query 文本做缓存键，A 用户的结果会被 B 用户命中。缓存键必须包含权限维度：hash(query + sorted(user_groups))。

④ Embedding 反演 向量可以被反推出近似原文。如果向量本身是多租户共存的，要么按租户分库/分 namespace，要么确保向量存储层本身也有访问控制。

审计#

每次检索记录：谁、什么 query、命中哪些 chunk、用了哪个 ACL 快照版本。出事之后能回答「到底泄漏了什么」——没有这条日志，事故响应时你只能猜。

本质是构建 DAG，不是线性列表#

大多数实现把工具调用当成一个队列顺序执行，这是性能浪费的主因。正确的模型是有向无环图：能并行的并行，有依赖的串行。

分三层：

① 模型层：一轮内返回多个 tool_use block，表达「这几件事互不依赖」。

② 依赖判定：靠数据流，不要靠模型自述。如果 B 的参数引用了 A 的输出，就是依赖；否则独立。让模型显式声明依赖关系不可靠——它经常漏标或多标。稳妥做法是模型只声明意图，依赖由执行器从参数引用中静态推导：

1
# 模型输出里用 ${step_id.field} 表示引用
2
{"id": "s1", "tool": "search_user",  "args": {"name": "张三"}},
3
{"id": "s2", "tool": "get_orders",   "args": {"uid": "${s1.user_id}"}},   # 依赖 s1
4
{"id": "s3", "tool": "get_holidays", "args": {"year": 2026}},             # 独立
5

6
def deps_of(step):
7
    return {m.group(1) for m in re.finditer(r'\$\{(\w+)\.', json.dumps(step["args"]))}

③ 执行层：拓扑排序分层，同层并发。

1
async def run_dag(steps):
2
    done, results = set(), {}
3
    while len(done) < len(steps):
4
        ready = [s for s in steps
5
                 if s["id"] not in done and deps_of(s) <= done]
6
        if not ready:
7
            raise CircularDependency(...)          # 环检测，必须有
8
        outs = await asyncio.gather(
9
            *(invoke(resolve(s, results)) for s in ready),
10
            return_exceptions=True,
11
        )
12
        for s, o in zip(ready, outs):
13
            results[s["id"]] = o
14
            done.add(s["id"])
15
    return results

三个必须处理的约束#

并行只对只读工具安全。 两个写操作并行修改同一份资源就是竞态。给工具打标记，readonly 的才进并发批次，写操作串行或加锁：

1
if any(not TOOLS[s["tool"]].readonly for s in ready):
2
    ready = ready[:1]        # 有写操作，本层退化成串行

部分失败不能全批回滚。 用 return_exceptions=True 收集结果，失败的步骤及其下游标记为 blocked，其他分支继续跑完，最后把「哪些成功、哪些失败、失败原因」一起交给模型决策。直接抛异常中断整批，会浪费掉已经完成的工作。

并发度要限流。 无上限的 gather 会瞬间打爆 API 配额（第 5 题）。加个信号量，通常 3~5 就够——再高的收益被 rate limit 吃掉了。

① 增量索引：靠内容哈希，不靠时间戳#

时间戳不可靠（文件复制、批量脚本、时区都会污染它）。用内容哈希判定变更，只重算真正变了的 chunk：

1
for doc in source_docs:
2
    h = sha256(normalize(doc.content))
3
    if index.get_hash(doc.id) == h:
4
        continue                                  # 没变，跳过
5
    index.delete_chunks(doc_id=doc.id)            # 先删旧 chunk
6
    index.upsert(chunk(doc), doc_hash=h)          # 再写新的

注意 delete 必须在 upsert 之前，且要按 doc_id 全删。如果文档从 10 个 chunk 改成 8 个，只做 upsert 会残留 2 个孤儿 chunk——它们指向已经不存在的内容，而且会一直被召回。这是「旧内容阴魂不散」最常见的成因。

② 缓存失效：全局版本号，不要精确失效#

精确失效（算出「这次变更影响哪些缓存项」）听起来优雅，实际上算不准，而且算漏了就是脏数据。更稳的做法是缓存键里带一个全局索引版本号：

1
cache_key = f"{index_version}:{hash(query)}:{hash(sorted(user_groups))}"

索引一变，index_version 自增，所有旧缓存自然失效。代价是变更后有一波缓存穿透——比起返回过期答案，这个代价值得付。

（注意这个 key 里也带了权限维度，原因见第 13 题的跨用户缓存泄漏。）

③ 旧文档仍被召回：逐个排查这五个原因#

这是最阴的一类问题，因为「删了还能搜到」在日志上完全看不出异常。按发生频率排：

兜底手段是给每个 chunk 带时间区间，检索时过滤：

1
WHERE valid_from <= now() AND (valid_to IS NULL OR valid_to > now())

这样即使某一层漏删，过期内容也进不了结果集。

另外要有对账任务：定期比对向量库的 ID 集合与源库的 ID 集合，差集就是泄漏点。没有这个对账，你永远不知道索引里躺着多少僵尸数据。

四个手段#

① 语义召回：把 skill 的 description + 典型触发场景做成 embedding，按当前上下文召回 top-N，只把这 N 个放进候选。占用不再随 skill 总数增长（见下一题的演示）。

② 领域路由：先定域再选 skill。一级路由只看 10 个领域（数据库 / 部署 / 前端 / 数据分析…），进域后才加载该域的 skill 列表。两跳换来候选集的数量级下降。

③ 负向边界：这是最被低估的一条。description 里必须写清楚什么时候不该用：

1
description: >
2
  修改数据库 schema 时使用——加减字段、改索引、改类型。
3
  不要用于纯数据修正（UPDATE/DELETE 业务数据），不要用于只读查询。

命中率低的真实原因，十有八九是 description 之间语义重叠，而不是描述得不够详细。加细节只会让重叠更严重，划清边界才有效。

④ 评测集：每个 skill 配 10~20 条样本，一半应触发、一半不应触发（尤其是那些容易误触的近邻场景），回归时同时跑命中率和误触率。只看命中率会导致你不断放宽描述，然后误触率失控。

怎么找出重叠的 skill#

把所有 description 做 embedding，两两算余弦，> 0.85 的挑出来人工看：

1
sims = embs @ embs.T
2
np.fill_diagonal(sims, 0)
3
for i, j in zip(*np.where(sims > 0.85)):
4
    if i < j:
5
        print(f"{names[i]} ←→ {names[j]}  {sims[i,j]:.3f}")

结果通常很难看——100 个 skill 里往往有 20~30 对高度重叠，其中一部分根本就是重复造的。合并比改写更有效。

处理流程#

① 回滚到干净状态

1
git stash   # 或 git checkout -- .

不要在层层叠加的失败补丁上继续。这些补丁本身已经成为新的干扰变量——后面即使找对了原因，也会被它们掩盖。

② 强制先复现，复现不了不许改

要求产出一个能稳定复现的最小用例。这一步能过滤掉一大半的「反复修不好」——很多时候模型压根没搞清楚 bug 到底是什么现象，就开始改代码了。

③ 要求先给假设和验证方法，再动手

1
当前假设：连接池在高并发下被耗尽
2
验证方法：在 acquire 前后打印池的活跃连接数，压测到 50 QPS
3
预期观察：如果假设成立，活跃数会顶到 max_size 且不回落

验证完再改。这个约束能把「猜着改」变成「查着改」。

④ 换策略，不要换措辞

• 二分定位：git bisect 找引入提交；或注释掉一半代码看现象是否消失
• 加观测而非猜测：在关键路径打日志/断点，让数据说话
• 缩小范围：把可疑模块单独抽出来写个最小脚本复现
• 换模型或换人：不同模型的失败模式不同，卡住时换一个常常立刻见效

最容易被忽略的一点#

要求它明确说出「我不知道问题在哪」。

模型的默认行为是持续生成看似合理的补丁——因为「我不知道」在训练数据里出现得少。但一个诚实的「当前证据不足以定位，我需要 X 信息」，比第 5 个错误补丁有价值得多。

把这条写进 skill 或系统提示里：连续两次修复失败后，停止修改，改为输出已排除的可能性和下一步需要的信息。

① 预算制：启动时就分配好#

不要等到溢出才处理。开局就把窗口切成配额，并规定超额时挤压谁：

1
BUDGET = {
2
    "system":   3_000,     # 不可压缩
3
    "skills":   8_000,     # 可裁剪（第 19 题）
4
    "history": 40_000,     # 可压缩
5
    "rag":     25_000,     # 可截断
6
    "output":   8_000,     # 必须预留
7
}

输出预留最容易被忘。 上下文塞到 99% 才发现没地方生成了，模型会直接截断——产出一个半截的 JSON（第 7 题），而且这类失败非常难排查。

② 压缩：对话摘要化 + 工具输出截断#

工具返回值是溢出的头号来源，而且经常被忽略。一个 cat 大文件、一次没有 LIMIT 的查询，就能瞬间吃掉几万 token。必须在工具层强制截断，而不是指望模型自觉：

1
MAX_TOOL_OUT = 4_000
2
def wrap(out: str, ref: str) -> str:
3
    if len(out) <= MAX_TOOL_OUT:
4
        return out
5
    path = save_artifact(out, ref)             # 全文落盘
6
    return (out[:MAX_TOOL_OUT]
7
            + f"\n\n...已截断，共 {len(out)} 字符。"
8
              f"完整内容见 {path}，可用 grep/read 按需查询。")

关键在最后半句——告诉模型完整内容在哪、怎么按需取，它就不会因为信息缺失而反复重试。

对话历史则做滚动摘要：最老的 N 轮压缩成一段结论，保留决策丢弃过程。

③ 外部化：上下文只留指针#

任务状态、中间产物、长文档写进文件或数据库，上下文里只保留路径和摘要。需要细节时再按需读取。这和第 11 题的 checkpoint 设计是同一个思路：上下文是工作台，不是仓库。

④ 分治：子 Agent 各自独立窗口#

超长任务拆成子任务，每个子 agent 有自己完整的窗口，主 agent 只接收结构化摘要。这是唯一能真正突破单窗口上限的办法，代价是协调成本和信息损耗——摘要必然丢信息，要设计好摘要的 schema。

兜底：溢出时的降级顺序#

真的撞上限了，按固定顺序丢弃，不要随机截断：

1
工具输出详情 → 老对话轮次 → RAG 结果中排名靠后的 → 非活跃 skill

永远不丢：系统指令、当前任务目标、最近 2~3 轮对话。丢掉任务目标的 agent 会开始做无关的事，比报错还糟。

按代价从低到高实施#

① 渐进披露（先做这个）

只有 name + description 常驻，正文命中后才加载。单个 skill 的常驻成本从约 1400 token 降到约 45 token——一步就能省掉 90% 以上，而且不需要任何额外基础设施。

1
skills/
2
  db-migration/
3
    SKILL.md          # frontmatter 里的 description 常驻
4
    reference.md      # 按需读取
5
    validate.py       # 脚本，模型调用而非阅读

大部分「skill 塞爆窗口」的问题做完这一步就解决了。

② 动态注入

按当前上下文实时检索，只注入最相关的约 12 个 description。占用不再随总数增长——这是第一个真正与 N 解耦的方案。代价是要维护一套检索层，而且检索失误会导致该用的 skill 没被注入（回到第 16 题的命中率问题）。

③ 分层路由

一级 router 只看领域，进域后才加载该域的 skill 清单。用一次额外的路由跳转换取候选集数量级下降。适合 skill 能清晰分域的场景；分不清域的话，路由本身就成了新的准确率瓶颈。

④ 子 Agent 拆分

按领域拆成独立 agent，各自持有自己的 skill 集，主 agent 只负责分发和汇总。最彻底，但引入了协调成本、上下文隔离、消息传递（第 5 题的全套问题）。不到 200+ skill 不建议走这一步。

别忘了治理#

技术手段之外，先做一次审计——通常收获比重构还大：

• 使用率统计：三个月没被调用过的 skill，合并或下线
• 重叠合并：用第 16 题的余弦聚类找出高度相似的对
• 长尾处理：调用量占比不到 1% 的 skill，合并进通用 skill 或改成文档

100 个 skill 里往往有 30 个是重复造的，20 个从来没被用过。先删再优化，比直接上架构重构划算得多。

① Chain（固定管道）#

1
A → B → C → D

步骤写死，没有决策点。严格说这不算 agent，是 workflow——但它是基线，能用它解决的就不要往上走。

② Router（分类分发）#

1
        ┌→ 处理器 A
2
输入 → 分类 ─→ 处理器 B
3
        └→ 处理器 C

唯一的决策点是「走哪条路」，路径本身是固定的。成本低、可测、失败可定位。生产系统里用得最多的模式，没有之一。

③ ReAct（思考-行动-观察循环）#

1
Thought → Action → Observation ─┐
2
   ↑                            │
3
   └────────────────────────────┘

最通用的 agent 模式，也是最容易死循环的（第 8 题）。适合路径无法预先枚举的探索型任务。代价是 token 消耗随步数线性增长，且中间任何一步出错都会污染后续推理。

④ Plan-and-Execute（先规划后执行）#

先一次性产出完整计划，再逐步执行。相比 ReAct 省 token（不用每步都重新推理全局），但计划一旦制定就僵化——执行中发现计划有问题，要么硬着头皮走完，要么重新规划。

实用的折中是允许重规划：执行器发现偏差时触发 replan，但限制重规划次数（否则又回到死循环）。

⑤ Reflection（自我反思）#

产出结果后自评并修正。问题在于模型评自己的作业存在系统性偏差——它倾向于认为自己写的是对的，尤其是错误比较微妙的时候。

⑥ Evaluator-Optimizer（生成器 / 评判器分离）#

1
生成器 → 产出 → 评判器 → 打分 + 反馈 ─┐
2
   ↑                                  │
3
   └──────────────────────────────────┘

比 Reflection 可靠得多，因为评判器有独立的 prompt、独立的上下文、甚至可以用不同的模型。关键是评判器要有客观依据——测试结果、schema 校验、lint 输出，而不是「你觉得写得好不好」。

有客观信号的场景（代码、结构化输出）效果很好；纯主观场景（文案质量）收益有限。

⑦ Orchestrator-Worker（编排者 - 执行者）#

主 agent 分解任务，多个 worker 并行执行，主 agent 汇总。唯一能真正突破单窗口上限的模式（第 18 题），代价是协调成本和摘要信息损耗。

适合可并行分解的任务（多文件重构、多来源调研）；任务之间有强依赖时并行度上不去，收益还不如串行。

⑧ Debate（多方辩论）#

多个 agent 持不同立场互相质疑。学术上效果不错，实践中很少进生产——成本是单 agent 的 N 倍，收益不稳定，而且经常出现「互相说服到一起错」的情况。

怎么选#

三个判据：

实践中最常见的生产组合是 Router + ReAct + Orchestrator-Worker：路由定域，域内用 ReAct 探索，需要并行时拆 worker。

唯一判据：任务路径能否预先枚举#

能枚举 → workflow。不能枚举 → 才考虑 agent。

agent 的全部优势只有一个：能处理你没预见到的情况。 如果任务根本不存在「没预见到的情况」，agent 的所有代价都是白付。

反模式：用 agent 做本来能写死的流程#

这是最常见的浪费。「解析用户上传的 CSV，校验字段，写入数据库」——这个流程完全确定，用 agent 做意味着：

• 成本高一个数量级（每次都要推理）
• bug 不可复现（同样的输入走了不同路径）
• 出错时不知道错在哪（要读完整对话轨迹）

写成 workflow，需要智能的地方（比如字段名模糊匹配）单独调一次 LLM 就够了。

真正的答案：两者不对立#

生产系统绝大多数是混合形态——workflow 做主干，agent 做局部节点：

1
[固定] 接收工单
2
   ↓
3
[固定] 提取结构化信息（单次 LLM 调用）
4
   ↓
5
[Router] 判断工单类型
6
   ↓
7
[Agent] ← 只有这一步需要探索：排查问题根因
8
   ↓
9
[固定] 生成回复
10
   ↓
11
[固定] 人工审核 → 发送

在确定的骨架里放不确定的关节。 这样既有 workflow 的可观测性和成本可控，又在真正需要灵活性的地方保留了 agent 的能力。

演进策略：先 workflow，再局部替换#

不要一开始就上 agent。先写 workflow，遇到分支爆炸时再把那一段换掉：

判断信号：某个节点的 if/else 超过十几个分支，而且还在持续增加——说明这里的路径确实枚举不完，该换 agent 了。

反过来也成立：agent 跑稳定之后，观察它的实际轨迹，如果发现 90% 的请求都走同一条路径，就把那条路径固化成 workflow，只留剩下 10% 给 agent。这能省掉大部分成本。

机制：用输出 token 换计算深度#

这是最本质的解释。Transformer 单次前向传播的计算深度是固定的——层数是多少就是多少，不会因为问题难就多算几层。

CoT 的作用是把一步映射拆成多步计算：每生成一个 token,就多一次完整的前向传播，中间结果写进上下文，下一步可以基于它继续算。

1
无 CoT：  问题 ──(固定深度)──→ 答案          深度不够就答错
2
有 CoT：  问题 → 步骤1 → 步骤2 → 步骤3 → 答案  深度 × N

所以 CoT 对需要多步串行推理的任务有效（数学、逻辑、多跳问答），对单步映射的任务无效（情感分类、格式转换、实体抽取）——后者本来一次前向就够，加 CoT 纯属浪费 token 和延迟。

四个实际用处#

1. 提升多步推理准确率 —— 核心价值
2. 可解释 —— 能看到它怎么想的（但见下面的局限）
3. 可干预 —— 发现中间某步错了，可以直接纠正那一步再继续，而不是重来
4. 过程监督信号 —— 训练时对中间步骤打分，比只对最终答案打分有效得多

第 3 点在工程上很有用：agent 的中间推理暴露出来之后，可以在关键决策点插入校验或人工确认。

两个必须知道的局限#

① CoT 不等于真实推理过程（忠实性问题）

模型写出来的推理链，未必是真正导致那个答案的计算过程。有研究表明，在 prompt 里植入暗示后，模型会给出被暗示的答案，但推理链里完全不提这个暗示——而是编造一套看起来合理的理由。

这意味着：不能把 CoT 当作审计证据。 「模型解释了为什么这么做」和「模型真的是这么做的」是两回事。在合规、风控这类需要真实归因的场景里，这一点很致命。

② 推理模型已经内化了 CoT

现在的推理模型（reasoning model）在训练时就学会了内部展开推理，再手动加「让我们一步步思考」收益接近零，有时还会干扰它自己的推理模式。

相关的一点：给推理模型施加「简短回答」的约束，可能会压缩它的推理空间从而降低准确率。要短的话，让它推理完再压缩输出，而不是限制它推理。

什么时候不该用#

• 简单单步任务 —— 分类、抽取、翻译，纯浪费
• 低延迟场景 —— CoT 显著增加首字延迟和总 token 数
• 需要真实归因的场景 —— 见忠实性问题
• 已经是推理模型 —— 重复施加通常无益

和 ReAct 的关系#

顺带厘清一个容易混的概念：

1
CoT   ：Thought → Thought → Thought → Answer        纯内部推理
2
ReAct ：Thought → Action → Observation → Thought …  推理 + 外部交互

ReAct 就是 CoT 加上了工具调用和外部观察。 CoT 只能在模型已有知识内推理，ReAct 能通过 Observation 引入外部事实——这也是它能纠正自己错误假设的原因（第 22 题）。