大模型视角 (A#) - 18种：覆盖从目标理解、推理规划、协作机制到系统治理的全栈能力，可作为构建企业级 AI Agent 系统的核心设计参考。
A#1：被动目标创建者 (Passive Goal Creator)
A#2：主动目标创建者 (Active Goal Creator)
A#3：提示/响应优化器 (Prompt/Response Optimizer)
A#4：检索增强生成 (RAG) (Retrieval-Augmented Generation)
A#5：单次模型查询 (Single Model Query)
A#6：增量模型查询 (Incremental Model Query)
A#7：单路径规划生成器 (Single-Path Planning Generator)
A#8：多路径规划生成器 (Multi-Path Planning Generator)
A#9：自我反思 (Self-Reflection)
A#10：交叉反思 (Cross-Reflection)
A#11：人类反思 (Human Reflection)
A#12：基于投票的合作 (Voting-Based Collaboration)
A#13：基于角色的合作 (Role-Based Collaboration)
A#14：基于辩论的合作 (Debate-Based Collaboration)
A#15：工具/Agent注册中心 (Tool/Agent Registry)
A#16：Agent适配器 (Agent Adapter)
A#17：多模态护栏 (Multimodal Guardrails)
A#18：Agent评估器 (Agent Evaluator)
以下是 “模式卡（Pattern Card）” 清单：每张卡片包含：名称、分类、意图、适用场景、工作机制、优势、局限、典型组合、伪代码/流程示意、反模式警示，便于工程团队快速理解、评估与复用。
模式卡 #A1：被动目标创建者（Passive Goal Creator）
| 项目 | 内容 |
|---|---|
| 分类 | I. 目标理解与任务入口层（LLM视角） |
| 意图 | 由用户通过显式、明确的指令直接表达任务目标，系统据此初始化执行上下文，不进行意图推断或需求挖掘 |
| 适用场景 | - 用户清楚知道要做什么（如“写一封辞职信”）- 任务边界清晰、无需上下文补全- 高确定性、低模糊性的交互场景（如命令行工具、表单填写） |
| 工作机制 | 1. 用户输入完整、结构化的任务指令2. 系统解析指令中的动词-宾语结构或预设模板3. 直接将该指令作为初始目标注入执行流程4. 后续模块基于该静态目标推进任务 |
| 优势 | - 实现简单，延迟低- 行为可预测，易于测试与审计- 减少因误推断导致的目标漂移风险 |
| 局限 | - 无法处理模糊、隐含或碎片化请求- 对用户表达能力要求高- 不支持上下文感知的动态目标演化 |
| 典型组合 | + 路由（B#2）+ 目标设定和监控（B#11）+ 提示/响应优化器（A#3） |
| 反模式警示 | 1. 在用户仅提供线索（如“最近有点累”）时仍强制要求明确指令，导致体验断裂2. 将本应主动推断的场景（如桌面助手识别截图意图）错误归为被动模式 |
| 伪代码示意 |
def handle_passive_goal(user_input: str):
if is_explicit_command(user_input):
goal = parse_goal_from_instruction(user_input)
context = initialize_execution_context(goal)
return execute_agent(context)
else:
raise NeedClarificationError("Please specify your request clearly.")
模式卡 #A2：主动目标创建者（Active Goal Creator）
| 项目 | 内容 |
|---|---|
| 分类 | I. 目标理解与任务入口层（LLM视角） |
| 意图 | 系统基于上下文线索（如历史行为、界面状态、环境信号）主动推断用户未明说的潜在需求，并生成可执行目标 |
| 适用场景 | - 用户表达模糊或不完整（如“帮我看看这个”）- 多模态上下文存在（如屏幕截图、剪贴板内容）- 个性化助手场景（如根据日程自动建议会议纪要生成） |
| 工作机制 | 1. 收集多源上下文（对话历史、UI状态、传感器数据等）2. 利用LLM进行意图推理：“用户当前最可能想做什么？”3. 生成一个或多个候选目标4. 可选：向用户确认或直接启动执行 |
| 优势 | - 提升用户体验流畅度，降低认知负荷- 支持情境智能（Contextual Intelligence）- 适用于高自由度交互场景（如桌面AI代理） |
| 局限 | - 推断可能出错，导致目标偏差- 增加系统复杂性与隐私敏感性- 难以解释“为何选择此目标” |
| 典型组合 | + 路由（B#2）+ 目标设定和监控（B#11）+ 记忆管理（B#8）（用于历史行为建模） |
| 反模式警示 | 1. 在高风险场景（如金融操作）中未经确认自动执行推断目标2. 忽略用户显式否定信号，坚持己见式推断 |
| 伪代码示意 |
def infer_active_goal(context: Context) -> Goal:
prompt = f"""
Based on the following context, what is the user most likely trying to achieve?
- Last message: "{context.last_user_message}"
- Clipboard: "{context.clipboard_content}"
- Current app: {context.active_application}
- Recent actions: {context.recent_actions}
Respond with a clear, actionable goal statement.
"""
inferred_goal_text = llm(prompt)
return Goal.from_text(inferred_goal_text)
模式卡 #A3：提示/响应优化器（Prompt/Response Optimizer）
| 项目 | 内容 |
|---|---|
| 分类 | II. 输入/输出结构化与接口标准化层（LLM视角） |
| 意图 | 通过对输入提示施加模板约束、输出格式规范及后处理逻辑，确保LLM交互结果结构可靠、程序可解析 |
| 适用场景 | - 需要机器可读输出（如JSON、YAML、函数调用参数）- 多轮对话中需保持格式一致性- 防止LLM生成无关、冗余或格式错误内容 |
| 工作机制 | 1. 定义输入模板（含角色、任务、约束、示例）2. 在提示中嵌入输出格式指令（如“请用JSON格式返回”）3. 对LLM原始输出进行解析、校验、重试或修正4. 若失败，触发重试机制或降级策略 |
| 优势 | - 显著提升输出可靠性与可集成性- 减少下游解析错误- 支持自动化测试与契约验证 |
| 局限 | - 过度约束可能抑制LLM创造力- 模板维护成本随业务复杂度上升- 对复杂结构（如嵌套列表）仍可能失效 |
| 典型组合 | + 提示词链（B#1）+ Guardrails（B#18）+ 异常处理和恢复（B#12） |
| 反模式警示 | 1. 在创意生成类任务中强行要求固定格式，扼杀多样性2. 仅依赖正则匹配解析LLM输出而不做语义校验，导致静默错误 |
| 伪代码示意 |
def optimized_prompt_invoke(task: str, schema: dict) -> dict:
prompt = f"""
{SYSTEM_PROMPT}
Task: {task}
Output must be valid JSON matching this schema: {schema}
Do not include any other text.
"""
raw_output = llm(prompt)
try:
parsed = json.loads(raw_output)
assert validate_schema(parsed, schema)
return parsed
except (JSONDecodeError, AssertionError):
return retry_with_stricter_prompt(prompt, max_retries=2)
模式卡 #A4：检索增强生成（RAG）（Retrieval-Augmented Generation）
| 项目 | 内容 |
|---|---|
| 分类 | III. 动态知识获取与工具集成层（LLM视角） |
| 意图 | 通过从外部知识库检索相关文档片段，并将其作为上下文注入LLM提示，以增强回答的准确性、时效性与事实依据 |
| 适用场景 | - 回答依赖私有或动态数据（如企业文档、产品手册）- 需要引用来源或避免幻觉- 知识超出LLM训练截止日期 |
| 工作机制 | 1. 将用户查询转化为检索关键词或嵌入向量2. 在向量数据库或搜索引擎中检索Top-K相关文档3. 将检索结果拼接进提示（通常置于指令之后、问题之前）4. 调用LLM生成基于检索内容的回答 |
| 优势 | - 显著减少事实性错误与幻觉- 支持私有知识问答- 可追溯信息来源，提升可信度 |
| 局限 | - 检索质量直接影响生成质量（“垃圾进，垃圾出”）- 增加延迟与系统复杂度- 对多跳推理支持有限（需结合规划机制） |
| 典型组合 | + 知识检索（B#14）+ 工具使用（B#5）（用于实时API查询）+ 提示/响应优化器（A#3）（规范引用格式） |
| 反模式警示 | 1. 在通用常识问题上滥用RAG，造成性能浪费2. 未对检索结果做相关性过滤，引入噪声干扰LLM判断 |
| 伪代码示意 |
def rag_generate(query: str, top_k: int = 3) -> str:
query_embedding = embed(query)
retrieved_docs = vector_db.search(query_embedding, k=top_k)
context = "\n".join([doc.text for doc in retrieved_docs])
prompt = f"""
Use ONLY the following context to answer the question.
If you don't know, say "I don't know based on provided context."
Context:
{context}
Question: {query}
Answer:
"""
return llm(prompt).strip()
模式卡 #A5：单次模型查询（Single Model Query）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（LLM视角） |
| 意图 | 将整个任务一次性提交给 LLM，在单次调用中完成理解、推理与输出，不进行中间步骤拆解或工具交互 |
| 适用场景 | - 任务简单、上下文完整且无需外部信息（如“总结这段文字”）- 对延迟敏感的实时交互（如聊天回复）- 输出形式固定、无需结构化验证的场景 |
| 工作机制 | 1. 构建包含完整指令与上下文的提示2. 单次调用 LLM 获取最终响应3. 直接返回结果，无中间状态管理或迭代逻辑 |
| 优势 | - 实现最简，开销最低- 延迟可控，适合高并发场景- 避免多步协调带来的复杂性 |
| 局限 | - 无法处理需工具调用、检索或长链推理的任务- 容易因上下文过长或模糊导致输出质量下降- 不支持过程可观测性与中途干预 |
| 典型组合 | + 提示/响应优化器（A#3）+ Guardrails（B#18）+ 资源感知优化（B#16）（用于控制 token 使用） |
| 反模式警示 | 1. 在复杂任务（如“分析销售数据并生成报告”）中强行使用单次查询，导致 LLM 幻觉或遗漏关键步骤2. 忽略输出格式校验，直接将原始文本暴露给下游系统 |
| 伪代码示意 |
def single_model_query(prompt: str) -> str:
response = llm(prompt)
return response.strip()
模式卡 #A6：增量模型查询（Incremental Model Query）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（LLM视角） |
| 意图 | 将复杂任务拆解为多个依赖步骤，通过多次调用 LLM 逐步推进，每步基于前序上下文进行推理 |
| 适用场景 | - 需要工具调用、检索或多跳推理的任务（如“查天气并建议穿搭”）- 任务流程存在分支或条件判断- 需要过程可追溯、可中断或可重试的生产级系统 |
| 工作机制 | 1. 初始化任务目标2. LLM 生成“思考→行动”指令3. 执行工具并获取观察结果4. 将观察加入上下文，重复 2–3 直至完成或超限 |
| 优势 | - 支持复杂任务分解与外部工具集成- 提升可控性与错误恢复能力- 便于日志记录、审计与用户反馈介入 |
| 局限 | - 增加延迟与 token 消耗- 需设计健壮的状态管理与异常处理机制- 多轮累积误差可能导致目标漂移 |
| 典型组合 | + 工具使用（B#5）+ 异常处理和恢复（B#12）+ 目标设定和监控（B#11） |
| 反模式警示 | 1. 在静态、确定性任务中强行使用（如“生成一段欢迎语”），导致性能浪费2. 未设置最大步数，可能陷入无限循环 |
| 伪代码示意 |
while not done and step < max_steps:
thought, action = llm(query + history)
if action == "FINISH":
done = True
else:
observation = tool_executor(action)
history += f"\nThought: {thought}\nAction: {action}\nObservation: {observation}"
模式卡 #A7：单路径规划生成器（Single-Path Planning Generator）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（LLM视角） |
| 意图 | 由 LLM 一次性生成一条线性、无分支的执行计划（如步骤列表），后续按顺序逐项执行，不支持运行时重规划 |
| 适用场景 | - 任务流程高度确定（如“部署服务的 checklist”）- 用户希望预览完整计划后再执行- 合规或审计要求所有操作必须预先声明 |
| 工作机制 | 1. LLM 根据目标生成结构化计划（如 JSON 数组）2. 系统解析计划为有序动作序列3. 按顺序依次执行每个动作，失败则终止或告警4. 不根据执行结果动态调整后续步骤 |
| 优势 | - 计划透明，用户可预审- 实现简单，适合脚本化任务- 易于与工作流引擎集成 |
| 局限 | - 无法应对执行中的意外（如工具不可用、数据缺失）- 缺乏灵活性，难以处理条件分支或并行子任务- 对 LLM 初始规划质量依赖极高 |
| 典型组合 | + 提示/响应优化器（A#3）（规范计划格式）+ 工具使用（B#5）+ 目标设定和监控（B#11） |
| 反模式警示 | 1. 在开放域任务（如“研究某个技术趋势”）中使用单路径规划，导致计划脱离实际2. 未对计划步骤做可行性校验，直接执行导致系统崩溃 |
| 伪代码示意 |
plan = llm(f"Generate a step-by-step plan to: {goal}. Output as JSON list.")
steps = parse_json(plan)
for step in steps:
execute_action(step["action"], step["args"])
if failed: break # no replanning
模式卡 #A8：多路径规划生成器（Multi-Path Planning Generator）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（LLM视角） |
| 意图 | 生成包含分支、并行或备选方案的非线性计划图（如决策树、状态机），并在执行中根据环境反馈动态选择路径 |
| 适用场景 | - 任务存在多种可行策略（如“故障排查：先查日志 or 先重启？”）- 需要根据运行时条件动态调整流程- 支持用户在关键节点介入选择 |
| 工作机制 | 1. LLM 生成带条件分支的计划图（如 if-else、fallback 链）2. 执行引擎按当前状态评估分支条件3. 选择激活路径并执行4. 若执行失败或条件变化，触发重规划或切换备选路径 |
| 优势 | - 高适应性，能应对不确定性- 支持复杂业务逻辑（如审批流、诊断树）- 可集成人类-in-the-loop 决策点 |
| 局限 | - 计划表示与执行引擎复杂度高- 需要强大的状态管理与条件评估机制- 可能因分支爆炸导致维护困难 |
| 典型组合 | + 图/状态机编排（B#6）+ 异常处理和恢复（B#12）+ 路由（B#2）（用于子路径分发） |
| 反模式警示 | 1. 在简单线性任务中过度设计多路径，增加不必要的复杂性2. 分支条件模糊（如“如果效果不好”），导致执行引擎无法判断 |
| 伪代码示意 |
plan_graph = llm(f"Generate a decision graph for: {goal}. Use conditions and fallbacks.")
state = initial_state()
while not terminal(state):
next_node = evaluate_conditions(plan_graph, state)
result = execute_node(next_node)
update_state(state, result)
if need_replan(result):
plan_graph = llm(f"Replan from current state: {state}")
模式卡 #A9：自我反思（Self-Reflection）
| 项目 | 内容 |
|---|---|
| 分类 | V. 反思、验证与持续改进层（LLM视角） |
| 意图 | 让 LLM 在完成任务后对自身输出进行内部评估、识别错误并生成改进建议，通过迭代优化提升结果质量 |
| 适用场景 | - 高准确性要求任务（如代码生成、数学证明、法律文书）- 输出需满足多维质量标准（逻辑性、安全性、一致性）- 无法依赖外部验证器但需自我校正的封闭环境 |
| 工作机制 | 1. LLM 生成初始响应（“初稿”）2. 同一或另一 LLM 实例基于预设标准对该响应进行批判性评估3. 生成结构化反思日志（如“未处理空输入”“事实与文档冲突”）4. 将反思作为上下文注入下一轮生成，重复直至达标或超限 |
| 优势 | - 显著提升复杂任务的正确率与鲁棒性- 无需外部测试即可实现闭环优化- 支持可解释的错误归因（反思日志可用于调试） |
| 局限 | - 增加延迟与计算成本（多轮 LLM 调用）- 反思质量依赖提示工程，可能流于形式（如“答案不够好”）- 无法纠正模型根本性知识盲区 |
| 典型组合 | + 增量模型查询（A#6）+ 异常处理和恢复（B#12）+ Guardrails（B#18）（提供反思标准） |
| 反模式警示 | 1. 在简单任务（如“翻译一句话”）中启用反思，造成资源浪费2. 反思提示未明确质量维度，导致模型无法生成可操作建议 |
| 伪代码示意 |
response = llm(task)
for _ in range(max_reflections):
critique = llm(f"Task: {task}\nResponse: {response}\nCritique it specifically:")
if is_satisfactory(critique):
break
response = llm(f"Task: {task}\nPrevious response: {response}\nCritique: {critique}\nImprove:")
return response
模式卡 #A10：交叉反思（Cross-Reflection）
| 项目 | 内容 |
|---|---|
| 分类 | V. 反思、验证与持续改进层（LLM视角） |
| 意图 | 多个异构 Agent（或同一 Agent 的不同实例）相互评审彼此的输出，通过观点碰撞发现单一视角盲点，提升整体决策质量 |
| 适用场景 | - 需要高置信度判断的场景（如医疗诊断辅助、金融风控）- 任务存在主观性或多解空间（如创意评估、政策影响分析）- 构建 Ensemble 或辩论式多智能体系统 |
| 工作机制 | 1. N 个差异化 Agent 并行生成对同一任务的响应2. 每个 Agent 接收其他 Agent 的输出作为评审对象3. 各 Agent 生成对他者方案的批评或补充意见4. 融合引擎整合原始响应与交叉反馈，生成最终答案（如投票、加权、元决策） |
| 优势 | - 利用多样性降低个体偏见与系统性错误- 激发“认知多样性”，发现更优解- 提升系统鲁棒性，尤其在对抗性或模糊输入下 |
| 局限 | - 资源消耗呈线性增长（N 倍 LLM 调用）- 需精心设计 Agent 差异化策略（模型、提示、工具集）- 融合逻辑复杂，可能引入新偏差 |
| 典型组合 | + Ensemble 模式（B#19）+ 多智能体协作（B#7）+ 自我反思（A#9）（作为子环节） |
| 反模式警示 | 1. 使用完全同质的 Agent 实例进行交叉反思，丧失多样性价值2. 未定义清晰的评审标准，导致批评流于情绪化或无意义 |
| 伪代码示意 |
responses = [agent.run(task) for agent in heterogeneous_agents]
critiques = []
for i, resp in enumerate(responses):
others = [r for j, r in enumerate(responses) if j != i]
critique = agents[i].llm(f"Review these responses to '{task}': {others}. Critique response {i}: {resp}")
critiques.append(critique)
final_output = fusion_engine(responses, critiques) # e.g., weighted vote or meta-LLM synthesis
模式卡 #A11：人类反思（Human Reflection）
| 项目 | 内容 |
|---|---|
| 分类 | V. 反思、验证与持续改进层（LLM视角） |
| 意图 | 将人类反馈（显式评分、修正、自然语言评论）作为反思信号，引导 LLM 调整后续行为，实现人在回路（Human-in-the-Loop）的持续学习 |
| 适用场景 | - 高风险决策需人工审核（如法律合同、医疗建议）- 用户个性化偏好难以编码为规则（如写作风格、审美）- 系统上线初期需快速收集高质量反馈以优化策略 |
| 工作机制 | 1. Agent 生成响应并交付用户2. 用户提供反馈（如“太啰嗦”“数据有误”“请更正式”）3. 系统将反馈结构化并注入下一次任务上下文4. LLM 基于人类反馈调整输出策略，形成人机协同优化闭环 |
| 优势 | - 直接对齐真实用户意图与业务目标- 可捕获模型无法自知的隐性需求- 支持个性化与情境化适应 |
| 局限 | - 依赖人类参与，无法全自动运行- 反馈稀疏、噪声大或不一致- 需设计高效反馈采集与表示机制 |
| 典型组合 | + 异常处理和恢复（B#12）（触发人工介入）+ 记忆管理（B#8）（持久化用户偏好）+ Guardrails（B#18）（将反馈转化为规则） |
| 反模式警示 | 1. 强制用户每次提供详细反馈，导致体验疲劳2. 未对人类反馈做可信度过滤，被恶意或低质反馈误导 |
| 伪代码示意 |
response = agent.run(task)
feedback = request_human_feedback(response) # e.g., thumbs up/down + comment
if feedback:
structured_feedback = llm(f"Extract actionable instruction from: '{feedback}'")
user_profile.update_preference(structured_feedback)
# Next task will include: "User previously said: {structured_feedback}"
模式卡 #A12：基于投票的合作（Voting-Based Collaboration）
| 项目 | 内容 |
|---|---|
| 分类 | VI. 多智能体协作与通信层（LLM视角） |
| 意图 | 多个同构或异构 Agent 独立生成对同一任务的解决方案，通过聚合机制（如多数决、加权投票）确定最终输出，以提升结果鲁棒性与准确性 |
| 适用场景 | - 需要高置信度答案但无明确验证标准（如开放域问答、主观评估）- 降低单点模型偏见或随机性影响- 快速集成多个模型/提示策略形成 Ensemble |
| 工作机制 | 1. 广播任务至 N 个参与 Agent（可使用不同模型、提示或工具集）2. 各 Agent 独立生成响应，互不通信3. 收集所有响应，按预设规则聚合（如简单多数、置信度加权、一致性筛选）4. 输出得票最高或综合得分最优的结果 |
| 优势 | - 实现简单，易于并行化- 有效抑制个体错误，提升整体稳定性- 可自然支持模型/策略多样性 |
| 局限 | - 资源消耗随 Agent 数量线性增长- 在低共识场景下可能选出“平庸解”而非最优解- 无法处理需深度协同的复杂任务（如分工流水线） |
| 典型组合 | + 多Agent协作（B#7）+ Agent间通信（B#15）（用于结果收集）+ 自我反思（A#9）（作为各 Agent 的前置优化） |
| 反模式警示 | 1. 使用完全同质的 Agent 进行投票，丧失多样性收益2. 在需要创造性或唯一解的任务中强行聚合，导致结果平庸化 |
| 伪代码示意 |
responses = []
for agent in agents:
resp = agent.run(task)
responses.append(resp)
# Simple majority vote (for categorical outputs)
from collections import Counter
final_output = Counter(responses).most_common(1)[0][0]
# Or weighted vote based on agent confidence
weighted_scores = {resp: sum(agent.confidence for agent, r in zip(agents, responses) if r == resp)}
final_output = max(weighted_scores, key=weighted_scores.get)
模式卡 #A13：基于角色的合作（Role-Based Collaboration）
| 项目 | 内容 |
|---|---|
| 分类 | VI. 多智能体协作与通信层（LLM视角） |
| 意图 | 为不同 Agent 分配专业化角色（如规划者、执行者、验证者、研究员），通过职责分离构建结构化协作流水线，实现复杂任务的高效分解与整合 |
| 适用场景 | - 任务天然具备阶段划分（如“研究→分析→撰写”）- 需要专业能力隔离（如安全审查 vs 内容生成）- 构建可维护、可扩展的团队式 Agent 架构 |
| 工作机制 | 1. 根据任务需求定义角色集合及其职责边界2. 为每个角色实例化专用 Agent（配备对应工具、知识、提示）3. 设计协作流程（顺序、并行或反馈环）4. 通过标准化协议（如 MCP）传递上下文，协调执行 |
| 优势 | - 提升任务处理的专业性与效率- 降低单个 Agent 的认知负荷- 支持模块化开发、测试与替换 |
| 局限 | - 需预先设计清晰的角色模型与交互协议- 角色间接口耦合可能增加维护成本- 动态任务可能难以映射到固定角色 |
| 典型组合 | + 多Agent协作（B#7）+ 模型上下文协议（MCP, B#10）+ 目标设定和监控（B#11）（用于全局协调） |
| 反模式警示 | 1. 角色划分过细导致通信开销大于收益2. 角色职责重叠或存在盲区，造成任务遗漏或冲突 |
| 伪代码示意 |
# Define roles
planner = RoleAgent(role="Planner", tools=[])
executor = RoleAgent(role="Executor", tools=[file_tool, api_tool])
verifier = RoleAgent(role="Verifier", tools=[validator])
# Collaborative workflow
plan = planner.run(f"Plan how to {task}")
result = executor.run(f"Execute plan: {plan}")
final_output = verifier.run(f"Verify result: {result}. If valid, output it; else, request fix.")
模式卡 #A14：基于辩论的合作（Debate-Based Collaboration）
| 项目 | 内容 |
|---|---|
| 分类 | VI. 多智能体协作与通信层（LLM视角） |
| 意图 | 多个 Agent 围绕同一问题展开结构化辩论，通过提出论点、反驳对方、提供证据等方式，逐步收敛至更可靠、逻辑严密的共识或最优方案 |
| 适用场景 | - 存在争议性或高风险决策（如伦理判断、投资建议）- 需要显式推理链与可审计论证过程- 探索多角度观点以避免群体思维 |
| 工作机制 | 1. 初始化辩题与立场分配（可随机、对立或指定）2. Agent 轮流发言：陈述主张 → 引用证据 → 反驳对手3. 辩论持续若干轮或直至收敛4. 由裁判 Agent 或外部机制（如用户、规则引擎）裁定胜方或综合结论 |
| 优势 | - 暴露逻辑漏洞与隐藏假设，提升推理深度- 生成可解释、可追溯的决策依据- 有效应对模糊、对抗性或价值冲突问题 |
| 局限 | - 通信轮次多，延迟高- 依赖高质量提示引导理性辩论，否则易陷入循环或情绪化- 裁决机制设计复杂，可能引入新偏见 |
| 典型组合 | + 多Agent协作（B#7）+ Agent间通信（B#15）（支持多轮消息交换）+ Guardrails（B#18）（防止攻击性或违规言论） |
| 反模式警示 | 1. 在事实明确、无需讨论的任务中启用辩论，浪费资源2. 未限制辩论轮数或发言长度，导致无限循环或信息过载 |
| 伪代码示意 |
pro_agent = DebateAgent(stance="PRO")
con_agent = DebateAgent(stance="CON")
transcript = []
for round in range(max_debate_rounds):
pro_arg = pro_agent.debate(transcript, stance="support")
transcript.append(("PRO", pro_arg))
con_arg = con_agent.debate(transcript, stance="oppose")
transcript.append(("CON", con_arg))
if consensus_reached(transcript):
break
judge = JudgeAgent()
final_output = judge.evaluate(transcript)
模式卡 #A15：工具/Agent注册中心（Tool/Agent Registry）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 系统集成、治理与可观测性层（LLM视角） |
| 意图 | 提供一个集中化的元数据目录，用于注册、发现和管理可用的工具或子 Agent，使主控 Agent 能动态调用外部能力而无需硬编码依赖 |
| 适用场景 | - 系统需支持插件化扩展（如新增天气查询、数据库连接器）- 多 Agent 协作环境中需服务发现与能力匹配- 企业级平台要求统一鉴权、版本控制与生命周期管理 |
| 工作机制 | 1. 工具/Agent 提供者提交结构化元数据（含 name、description、parameters、auth_type、endpoint 等）2. 注册中心验证并存储元数据，生成唯一标识3. 主控 Agent 在运行时通过语义匹配（如“查北京天气”→get_weather）查询注册表4. 平台按规范调用目标服务，处理认证与参数映射 |
| 优势 | - 解耦主逻辑与具体实现，提升系统可维护性- 支持热插拔与灰度发布- 为 MCP（主控程序）提供标准化的能力视图 |
| 局限 | - 需维护元数据一致性与版本兼容性- 增加系统启动与发现开销- 错误的元数据定义会导致功能失效（如参数不匹配） |
| 典型组合 | + 模型上下文协议（MCP, B#10）+ 工具使用（B#5）+ Agent适配器（A#16）（用于异构系统接入） |
| 反模式警示 | 1. 元数据未遵循 JSON Schema 规范，导致 LLM 无法正确解析参数2. 注册中心缺乏权限控制，允许任意服务注册高危操作（如删除数据库） |
| 伪代码示意 |
# Registration
registry.register({
"name": "send_email",
"description": "Send email via SMTP",
"parameters": {"type": "object", "properties": {"to": {"type": "string"}, "body": {"type": "string"}}},
"auth_type": "api_key",
"execute_endpoint": "https://internal/api/email"
})
# Discovery & Invocation
tool_meta = registry.find_tool_by_intent("notify user via email")
response = call_tool(tool_meta, args={"to": "user@example.com", "body": "Hello!"})
模式卡 #A16：Agent适配器（Agent Adapter）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 系统集成、治理与可观测性层（LLM视角） |
| 意图 | 将外部异构系统（如遗留 API、非标准 Agent、第三方服务）封装为符合内部协议（如 MCP）的标准化接口，实现无缝集成 |
| 适用场景 | - 接入无原生 Agent 支持的旧系统（如 SOAP 接口、命令行工具）- 统一多厂商 Agent 的交互格式（如不同云厂商的智能体）- 在沙箱或安全边界内代理高风险操作 |
| 工作机制 | 1. 为外部服务定义适配器类，实现标准接口（如 execute(input) → output）2. 适配器负责协议转换、参数映射、错误标准化与日志埋点3. 将适配器注册至工具/Agent 注册中心4. 主控 Agent 通过统一方式调用，无需感知底层差异 |
| 优势 | - 屏蔽底层复杂性，提升系统兼容性- 集中处理安全、重试、限流等横切关注点- 支持渐进式现代化改造 |
| 局限 | - 每个新系统需开发专属适配器，增加初期成本- 适配层可能成为性能瓶颈或故障点- 双向转换（输入/输出）易引入语义损失 |
| 典型组合 | + 工具/Agent注册中心（A#15）+ 异常处理和恢复（B#12）+ Guardrails（B#18）（在适配层实施策略） |
| 反模式警示 | 1. 适配器仅做透传，未处理错误码或超时，导致主流程崩溃2. 未对敏感操作（如资金转账）在适配层增加二次确认或审批钩子 |
| 伪代码示意 |
class LegacyCRMAdapter:
def execute(self, input: dict) -> dict:
# Map internal schema to legacy format
legacy_req = {"cust_id": input["customer_id"], "action": "update"}
try:
raw_resp = requests.post("http://old-crm/update", json=legacy_req)
return {"status": "success", "data": raw_resp.json()}
except Exception as e:
return {"status": "error", "message": str(e)}
# Register adapter as a standard tool
registry.register_tool("update_customer", LegacyCRMAdapter())
模式卡 #A17：多模态护栏（Multimodal Guardrails）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 系统集成、治理与可观测性层（LLM视角） |
| 意图 | 在多模态输入（文本、图像、音频、视频）和输出场景中，实施内容安全、合规性与事实性校验，防止有害、偏见或幻觉内容传播 |
| 适用场景 | - 用户上传图片生成描述（需防 NSFW、隐私泄露）- 语音助手响应需过滤不当言论- 多模态 RAG 中验证图文一致性- 生成带图的营销内容需符合品牌规范 |
| 工作机制 | 1. 对输入模态进行预过滤（如图像 NSFW 检测、语音转文本审核）2. 在 LLM 生成过程中注入安全提示（如“不要生成暴力内容”）3. 对输出进行多模态后验校验（如检测生成图像是否含违规 logo）4. 触发拦截、修正或人工审核流程 |
| 优势 | - 覆盖全链路多模态风险，提升系统可信度- 支持细粒度策略（如医疗 vs 社交场景不同规则）- 符合 GDPR、AI Act 等监管要求 |
| 局限 | - 多模态检测模型本身可能存在偏差或漏检- 增加端到端延迟- 高保真生成（如写实图像）更难校验真伪 |
| 典型组合 | + Guardrails（B#18）+ 检索增强生成（A#4）（校验检索内容安全性）+ Agent评估器（A#18）（用于护栏效果度量） |
| 反模式警示 | 1. 仅对文本应用护栏，忽略图像/音频中的违规信息2. 护栏规则过于宽松（如仅关键词过滤），无法识别隐喻或变体攻击 |
| 伪代码示意 |
def multimodal_guardrails(input_modality, output_modality):
if input_modality.type == "image":
if nsfw_detector(input_modality.data).is_nsfw:
raise BlockedContentError("NSFW image detected")
llm_output = llm(prompt_with_safety_instructions)
if output_modality.type == "image":
if brand_compliance_checker(llm_output.image).violation:
return fallback_safe_image()
return llm_output
模式卡 #A18：Agent评估器（Agent Evaluator）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 系统集成、治理与可观测性层（LLM视角） |
| 意图 | 通过自动化指标（准确性、效率、安全性）与人类反馈，对 Agent 的行为、输出及协作效果进行量化评估，驱动持续优化 |
| 适用场景 | - A/B 测试不同提示策略或模型版本- 监控生产环境 Agent 性能漂移- 构建强化学习奖励信号（如基于用户满意度）- 合规审计与责任追溯 |
| 工作机制 | 1. 定义评估维度（如任务完成率、幻觉率、响应时间）2. 收集执行轨迹（thought-action-observation 序列）3. 应用自动评估器（规则引擎、评判 LLM、参考答案比对）4. 结合人类评分（如 Likert 量表）形成综合得分5. 输出评估报告并触发优化闭环（如重训练、策略调整） |
| 优势 | - 实现 Agent 能力的客观度量与横向对比- 支持数据驱动的迭代改进- 为 SLA 与风险管理提供依据 |
| 局限 | - 自动评估难以覆盖主观质量（如创意性、同理心）- 评估指标设计不当可能导致优化目标偏离真实需求- 高质量人类反馈成本高昂 |
| 典型组合 | + 记忆管理（B#8）（存储评估历史）+ 自我反思（A#9）（利用评估结果自我修正）+ 多模态护栏（A#17）（作为安全维度输入） |
| 反模式警示 | 1. 仅依赖单一指标（如准确率）评估复杂任务，忽视用户体验2. 评估数据集与真实场景分布不一致，导致“测试表现好，线上效果差” |
| 伪代码示意 |
def evaluate_agent(agent, test_cases):
scores = []
for case in test_cases:
trace = agent.run(case.task)
auto_score = llm_judge(f"Evaluate this response: {trace.output} against {case.gold_answer}")
human_score = get_human_rating(trace) if random() < 0.1 else None
scores.append(combine_scores(auto_score, human_score))
return aggregate_metrics(scores) # e.g., avg accuracy, latency, safety violation rate
模式卡决策树
帮助系统设计者或开发者在面对一个具体的 Agent 应用场景时，通过一系列结构化问题，快速定位应采用哪种或哪几种设计模式。
| 判别维度 | 关键问题 | 对应模式 |
|---|---|---|
| 目标来源 | 用户是否明确表达目标？ | A#1 vs A#2 |
| 任务复杂度 | 是否可单次完成？ | A#5 vs A#6/A#7/A#8 |
| 外部依赖 | 是否需工具、检索、记忆？ | A#4, A#6, A#15, A#16 |
| 规划需求 | 是否需显式生成步骤？ | A#7, A#8 |
| 质量要求 | 是否需验证/改进输出？ | A#9, A#10, A#11 |
| 协作规模 | 是否多 Agent 参与？ | A#12, A#13, A#14 |
| 系统治理 | 是否需注册、适配、安全、评估？ | A#15–A#18 |
开始：你正在设计一个基于 LLM 的 Agent 系统
│
├─ 1. 用户是否明确表达了完整任务目标？
│ ├─ 是 → 考虑 **A#1：被动目标创建者**
│ └─ 否 → 考虑 **A#2：主动目标创建者**
│
├─ 2. 任务是否只需单次 LLM 调用即可完成？
│ ├─ 是 → 考虑 **A#5：单次模型查询** + （若需结构化输出）→ **A#3：提示/响应优化器**
│ └─ 否 → 进入“多步推理”分支
│
├─ 3. 是否需要调用外部工具、API 或检索知识？
│ ├─ 是 →
│ │ ├─ 需要多次交互？ → **A#6：增量模型查询**
│ │ └─ 需要长期记忆或上下文增强？ → **A#4：RAG**
│ └─ 否 → 仅内部推理
│
├─ 4. 任务是否需要生成执行计划？
│ ├─ 是 →
│ │ ├─ 计划是线性、无分支？ → **A#7：单路径规划生成器**
│ │ └─ 计划包含条件、备选或并行路径？ → **A#8：多路径规划生成器**
│ └─ 否 → 无需显式规划
│
├─ 5. 是否要求高可靠性或需验证输出质量？
│ ├─ 是 →
│ │ ├─ 由 LLM 自我检查？ → **A#9：自我反思**
│ │ ├─ 多个 Agent 互相评审？ → **A#10：交叉反思**
│ │ └─ 需要人类介入反馈？ → **A#11：人类反思**
│ └─ 否 → 跳过反思层
│
├─ 6. 是否涉及多个 Agent 协同工作？
│ ├─ 是 →
│ │ ├─ 各 Agent 独立作答后聚合？ → **A#12：基于投票的合作**
│ │ ├─ 各 Agent 扮演不同角色？ → **A#13：基于角色的合作**
│ │ └─ Agent 之间辩论以达成共识？ → **A#14：基于辩论的合作**
│ └─ 否 → 单 Agent 模式
│
└─ 7. 系统是否需集成外部能力或保障安全合规？
├─ 需要动态发现和调用工具/Agent？ → **A#15：工具/Agent注册中心**
├─ 需接入非标准或遗留系统？ → **A#16：Agent适配器**
├─ 处理图像、语音等多模态内容且需安全过滤？ → **A#17：多模态护栏**
└─ 需要量化评估 Agent 性能？ → **A#18：Agent评估器**
本文所述观点基于当前实践与有限实验，且难免存在疏漏或偏颇之处。AI Agent 领域日新月异，架构设计亦无“银弹”。欢迎各位读者在评论区或社区中交流探讨。
