一、背景：别再按行业背模板，按能力学架构
第一波 agent 资料是按行业组织的：医疗 agent、金融 agent、编程 agent，好像每个垂直领域都是一套独门配方。但把三者的架构图摆在一起会发现：感知复杂文档、分层拆解、从记忆里找相似案例、多路投票、每条结论挂出处、关键节点交人、审计副作用——画出来几乎一模一样。换掉 prompt 和工具集，等于把 agent 平移到另一个行业，设计本身没变。
所以真正通用的不是领域模板，而是八大能力：感知、推理、规划、记忆、工具使用、协作、学习、对齐。从“定时总结收件箱的 cron+prompt”到“写并购文件的多智能体系统”，全是这八种能力的不同配比。记住 60 个模式，任何 agent 都能现配；只背领域模板，每换一个行业都要重新学一遍。
本文把 60 模式一次讲清：8 个核心模式讲透（含可跑代码骨架），其余 52 个列表速览、给出归属和一句话定位。
二、原理：模式的统一讲法与工程观
每个模式都可以用同一套八问来掌握：解决什么具体问题、天真做法为什么 Alright（看起来对、实际错）、机制是哪几步架构动作、代码骨架长什么样、代价与替代、生产环境先坏在哪、真实案例、常和谁组合（Pairs with）。两点工程观先立住：
- agent 是软件制品，不是准人类：有输入契约、输出契约、内部控制循环和副作用，要构建、测试、观测、下线。“感知/记忆/推理”只是分类词，不是本体。
- 模式与模型无关：三代前沿模型换下来，这些架构形状几乎没变。代码里的
llm.call(...)都是占位符，换成你的 SDK 即可。
60 模式在八大能力下的分布（括号内为精选讲透的代表）：
- 感知（Provenance Tracker）、推理（Self-Consistency Voter）、规划（Hierarchical Decomposer / Plan-then-Execute）、记忆（Curated Recall Store）、工具（Tool Router）、协作（Subagent Delegator / Reflector-Critic）、学习（Drift Detector）、对齐（Refusal Calibrator / Side-Effect Auditor / Constitution Gate）。另有评估贯穿全局（Evaluator-Generator Loop）。
三、环境准备
python -V # 3.10+
pip install pydantic pytest
本文代码均为可直接跑的极简骨架（同步、零外部依赖），llm.call 用确定性桩代替，换成真实 SDK 即可进生产形状。
# common.py：所有模式共用的桩
import hashlib, json
class LLM:
def call(self, prompt: str, **kw) -> str:
h = hashlib.md5(prompt.encode()).hexdigest()[:8]
return f"[llm:{h}] {prompt[:60]}"
llm = LLM()
四、分步实战：8 个核心模式讲透
模式 1：ReAct（推理+行动交错）——归属：推理/规划
问题：一次性生成长链条动作，中间错一步全错，且无法用环境反馈纠偏。
天真做法：CoT 写完再执行；工具返回报错也只能重头来。
机制：Thought → Action → Observation 循环，每步都把观测喂回下一步推理，设步数上限与停机条件。
# react.py
from common import llm
def react(task, tools, max_steps=6):
trace = [f"TASK: {task}"]
for i in range(max_steps):
thought = llm.call("THINK " + "\n".join(trace))
trace.append(f"THOUGHT{i}: {thought}")
# 桩式选路：按关键词选工具，真实实现让模型输出 JSON action
name = "search" if "search" in thought.lower() else "finish"
obs = tools[name]("q") if name in tools else "DONE"
trace.append(f"OBS{i}: {obs}")
if name == "finish":
return {"answer": obs, "trace": trace}
return {"answer": "TIMEOUT", "trace": trace}
if __name__ == "__main__":
tools = {"search": lambda q: "found: Q3 revenue 12.4B", "finish": lambda q: "Q3 revenue 12.4B"}
print(react("查Q3营收", tools)["answer"])
** trade-off：步数=成本×延迟；观测噪声会带偏后续推理。简单问答退化为单次调用即可。
生产坏点：工具报错信息过长灌满上下文——对 observation 做截断+摘要。
Pairs with**：Tool Router、Provenance Tracker。
模式 2：Plan-then-Execute（计划执行分离）——归属：规划
问题：边想边干容易漂移，错到第 6 步才发现第 2 步理解错了。
机制：先产出带校验命令的分步计划（每步写清动哪些文件、先写哪个测试、用什么命令验证、何时提交），执行阶段只许按计划走，偏离即停。
# plan_exec.py
from common import llm
plan = [
{"step": 1, "do": "加 validator", "verify": "pytest tests/test_validate.py"},
{"step": 2, "do": "加 handler", "verify": "pytest tests/test_api.py"},
]
def run(plan):
for s in plan:
print(f"STEP{s['step']}: {s['do']} -> verify: {s['verify']}")
# 真实实现：调 agent 执行 + 跑 verify 命令，不通过则回滚本步
return "ALL STEPS DONE"
if __name__ == "__main__":
print(run(plan))
Pairs with：Evaluator-Generator、Constitution Gate。
模式 3：Reflector-Critic（反思修正环）——归属：协作/推理
问题：初稿总有错，一次生成质量封顶。
机制：Generator 出草稿 → Critic 按检查表挑刺 → Generator 只改被点名处，循环到检查通过或轮数上限。Critic 与 Generator 用不同 prompt（甚至不同模型）防止同构盲区。
# reflect.py
from common import llm
def generate(draft=""): return llm.call("WRITE answer for: revenue?" + draft)
def critique(text): return [] if "12.4B" in text else ["missing figure"]
draft = generate()
for _ in range(3):
issues = critique(draft)
if not issues: break
draft = generate(" fix: " + ";".join(issues))
print("FINAL:", draft)
模式 4：Subagent Delegator（子代理分工）——归属：协作
问题：主上下文被“读 100 个文件找答案”灌爆，后续推理被稀释。
机制：主 agent 只派任务、收摘要；探索型工作下放 subagent，各自独立上下文，最后合并结构化摘要。
# subagents.py
from concurrent.futures import ThreadPoolExecutor
from common import llm
def subagent(zone): return {"zone": zone, "summary": llm.call("audit " + zone)}
zones = ["frontend", "api", "infra"]
with ThreadPoolExecutor(3) as ex:
reports = list(ex.map(subagent, zones))
print({r["zone"]: r["summary"] for r in reports})
生产坏点：子代理返回全文而非摘要——强制输出 schema（发现/证据/置信度三栏）。
模式 5：Curated Recall Store（记忆检索）——归属：记忆
问题：每次从零推理，组织的老答案、判例、踩坑记录用不上。
机制： curated 语料（只收被验证过的）+ 混合检索（向量+关键词）+ 引用回贴。写记忆与读记忆分离权限。
# memory.py
import math
DOCS = [{"id": "c1", "text": "退款超500需人工审批", "tags": ["refund"]},
{"id": "c2", "text": "Q3营收12.4B", "tags": ["revenue"]}]
def recall(q):
def score(d): return sum(1 for t in d["tags"] if t in q)
return sorted(DOCS, key=score, reverse=True)[:1]
if __name__ == "__main__":
print(recall("revenue 退款"))
坏点：垃圾进垃圾出——记忆写入必须走“验证后方可入库”门禁，否则漂移。
模式 6：Tool Router（工具路由）——归属：工具使用
问题：工具一多，模型选错、参数填错、调了只读工具却想写。
机制：工具注册表（名称/读写等级/参数 schema/费用）+ 路由层（按意图+权限+成本选工具）+ 参数校验。危险工具默认拒，显式放行。
# router.py
TOOLS = {"db.read": {"write": False}, "db.write": {"write": True}}
def route(intent, allow_write=False):
cand = TOOLS[intent]
if cand["write"] and not allow_write:
raise PermissionError("write tool needs approval")
return intent
print(route("db.read"));
try: route("db.write")
except PermissionError as e: print("BLOCKED:", e)
模式 7：Constitution Gate + Refusal Calibrator（对齐双子）——归属：对齐
问题：要么过度拒绝（正常需求也说不），要么该拒不拒。
机制：Constitution 列出不可违背条目（决策点必须交人、写操作必须审计），Gate 在模型调用前后各检查一次；Refusal Calibrator 定期用“应拒/应答”黄金集校准拒绝率，拒绝时给出替代方案而非硬顶。
# guard.py
CONSTITUTION = ["refund>500 -> human", "db.write -> audit"]
def gate(action):
for rule in CONSTITUTION:
key = rule.split(" ->")[0]
if key in action and "approved" not in action:
return f"ESCALATE per [{rule}]"
return "ALLOW"
for a in ["refund>500", "refund>500 approved", "db.write"]:
print(a, "=>", gate(a))
模式 8：Evaluator-Generator Loop（评估闭环）——归属：学习/评估
问题：没标尺的 agent 越跑越飘，回归无人知。
机制：黄金任务集 + 自动评分器（规则+模型双评）+ 阈值门禁。每次改 prompt/换模型都跑一遍，分数跌了就拦。
# eval_loop.py
CASES = [("2+3=?", "5"), ("capital of FR?", "Paris")]
def agent(q): return "5" if "2+3" in q else "Paris"
score = sum(1 for q, a in CASES if agent(q) == a) / len(CASES)
print(f"score={score:.2f}", "PASS" if score >= 1.0 else "BLOCK")
五、其余 52 模式列表速览
感知：Chunk-and-Fuse（长文档分块再融合）、Schema-First Extractor（先定字段再抽）、Provenance Tracker（每断言挂出处，详见模式7组合）、Multimodal Normalizer（图音表统一转文本）、Noise Stripper（去样板只留信号）。
推理：Self-Consistency Voter（多路投票取多数）、Decomposer-Checker（拆题+验算分离）、Constraint-Satisfaction（约束求解式推理）、Abstention Head（低置信直接认怂转人）、Counterfactual Prober（反事实追问防幻觉）。
规划：Hierarchical Decomposer（任务树逐层拆）、Opportunistic Replanner（遇障局部重排）、Budget-Aware Planner（按 token/钱排计划）、Checkpoint-Restore（断点续跑）、Dry-Run Simulator（先模拟再真调）。
记忆：Episodic Log（会话流水全记）、Semantic Snapshot（定期压成摘要）、Hierarchical Memory（热温冷三层）、Forgetting Policy（过期主动忘）、Cross-Agent Share（记忆跨体共享需授权）。
工具：Schema Validator（参数先验后调）、Idempotency Wrapper（重试安全幂等）、Cost-Latency Scheduler（贵慢工具排后面）、Fallback Chain（主备链降级）、Sandbox Executor（先沙箱再生产）。
协作：Debate Panel（多代理辩论取胜方）、Handoff Protocol（结构化交接单）、Blackboard（共享黑板协同）、Leader-Follower（主从分权）、Market Bidding（任务竞价分配）。
学习：Drift Detector（输入分布漂移告警）、Online Finetuner（线上增量微调）、Preference Distiller（人工偏好蒸成规则）、Failure Miner（故障聚类找根因）、Canary Rollout（金丝雀放量）。
对齐：Side-Effect Auditor（写操作全审计，配 Tool Router）、Off-Switch（人工一键断）、Provenance Tracker（出处链，医疗/金融强合规位）、Privacy Scrubber（PII 先脱敏再推理）、Red-Team Suite（定期红队攻击评估）、Audit Ledger（不可篡改操作台账）、Appeal Channel（拒绝可申诉）。
评估与工程：Golden Dataset（黄金集版本化）、Regression Harness（改 prompt 必跑回归）、Latency Budget（延迟预算到步骤级）、Trace Observer（全链路追踪）、Kill-Criteria（达阈值自停）。另有：Summarize-and-Act、Verify-then-Commit、Human-in-the-Loop Escalation、Prompt Versioning、Tool Mock Lab、Load Shedding、Quota Guard 等，按需查原书对应章节。
选型口诀：简单问答 ReAct+路由即可；要动数据必加审计+门禁；多源长文必加出处链；长期运行必加漂移检测+评估回归。
六、常见坑
- 无评估先上多智能体：系统越复杂越要先有黄金集，否则每个改动都是盲飞。
- 记忆不设写入门禁：把幻觉也入库，越用越毒。入库必须“验证通过”才放行。
- 对齐只做 prompt 里的一句话：调用前后的 Gate 代码位才是真 enforcement。
- 子代理返回全文：主上下文被灌爆。强制摘要 schema。
- 工具无读写分级：只读意图调到写工具。路由层默认拒写、显式批。
- 计划与执行混在一起：漂移了都不知道从哪步偏的。先落字为计划再执行。
七、附录：从 8 个到 60 个的组装路线图与重点模式导读
最小闭环先跑起来，再按故障补积木。第一周上推理加行动循环、工具路由与评估黄金集，先让单体智能体可用且可测，黄金集二十条左右即可，覆盖最核心的问答与工具调用链路。第二周加上计划执行分离、两轮反思与宪法门禁，长任务不再漂移，输出有质量下限。第三周引入子代理、精选记忆与出处追踪，解决规模问题与知识沉淀问题。之后每出一次生产故障就反查模式列表：幻觉多补反事实追问，重试雪崩补幂等包装，重试太烧钱补成本调度，合规告警补审计台账，故障是最好的选型顾问。成本公式要记在心里：总成本约等于步数乘单步消耗乘轮数，推理步数、反思轮数、子代理数量是三个最贵的旋钮，评估分数不涨就拧紧它们。
重点模式导读：长文档场景必配分块融合与出处追踪，前者解决装不下，后者解决不敢信，每条结论都能点回原文，医疗金融这类强合规领域全靠它过审。低置信场景配认怂头，不确定就转人工，一次硬撑答错的损失远大于十次转人工的成本。多代理协作优先用结构化交接与共享黑板，自由辩论听起来美好，实践中账单先爆炸。长期运行的系统必须配漂移检测与回归套件，输入分布一变老经验全错，没有回归门禁的改动全是盲飞。在线学习类需求先上偏好蒸馏，把人工的赞踩变成可版本化的规则，再谈增量微调。安全红线四个件套要配齐：副作用审计、人工总开关、隐私脱敏、申诉通道，缺一个都可能在深夜被叫醒。评估侧记住黄金集版本化，数据集一变分数就不可比，改提示词必跑回归，延迟预算要拆到步骤级，全链路追踪保留到能复盘每一次异常调用为止。工程落地还有三件套：提示词版本化让每次改动可回滚，工具仿真实验室让评估不花真钱，配额守卫防止某个失控循环一夜烧掉预算。负载高峰用降载策略先保核心链路，达到自停阈值就停，不要让智能体在死胡同里无限重试。这些工程模式不直接提分，但决定了系统在生产环境能活多久。选型最后再送一句口诀：简单问答推理循环加路由即可，要动数据必加审计与门禁，多源长文必加出处链，长期运行必加漂移检测与评估回归，对照着配基本不会错。最后补充协作模式的取舍细节：辩论面板适合高风险决策前的多视角碰撞，但日常任务用它就是烧钱，主从分权适合执行链路清晰的流水线，任务竞价适合异构智能体池的动态分配，共享黑板适合状态复杂的多步协同。记忆侧热温冷三层要配遗忘策略，过期不忘的记忆库会变成垃圾场，跨体共享记忆必须经过授权，隐私与安全的底线不能让。学习侧故障聚类值得投入，把每一次失败按根因归类，攒够样本后高频根因自然浮现，这比拍脑袋定优化方向靠谱得多。金丝雀放量是上线新版本前的必备动作，先小流量验证再全量，出问题回滚的半径可控。
八、总结
60 模式的本质是八大能力的积木：感知决定输入质量，推理决定答案形状，规划决定执行不漂，记忆决定越用越强，工具决定手脚利索，协作决定规模上限，学习决定长期不腐，对齐决定不出大事。先照 8 个核心模式搭出最小闭环（ReAct+计划+反思+子代理+记忆+路由+门禁+评估），再按故障反查 52 列表补积木。能力 literacy 通吃所有行业，领域模板只管一时。 点击阅读原文
参考资料：Vahe Aslanyan《The AI Agent Engineer’s Guide: 60 Patterns for Building Autonomous Systems》。 点击阅读原文
相关文章
