Agent工程视角 (B#) - 21种：覆盖目标理解、推理规划、协作执行、治理评估的全生命周期
B#1：提示词链 (Prompt Chaining)
B#2：路由 (Routing)
B#3：并行化 (Parallelization)
B#4：反思 (Reflection)
B#5：工具使用 (Tool Use)
B#6：规划 (Planning)
B#7：多Agent协作 (Multi-Agent Collaboration)
B#8：记忆管理 (Memory Management)
B#9：学习和适应 (Learning and Adaptation)
B#10：模型上下文协议 (MCP) (Model Context Protocol)
B#11：目标设定和监控 (Goal Setting and Monitoring)
B#12：异常处理和恢复 (Exception Handling and Recovery)
B#13：人机协同 (Human-in-the-Loop)
B#14：知识检索 (RAG) (Knowledge Retrieval)
B#15：Agent间通信 (Agent-to-Agent Communication)
B#16：资源感知优化 (Resource-Aware Optimization)
B#17：推理技术 (Reasoning Techniques)
B#18：Guardrails / 安全模式 (Guardrails / Safety Patterns)
B#19：评估和监控 (Evaluation and Monitoring)
B#20：优先级排序 (Priority Ordering)
B#21：探索和发现 (Exploration and Discovery)
模式卡 #B1：提示词链（Prompt Chaining）
| 项目 | 内容 |
|---|---|
| 分类 | II. 输入/输出结构化与接口标准化层（Agent工程视角） |
| 意图 | 将复杂任务拆解为一系列顺序执行的子任务，每个子任务的 LLM 输出经结构化处理后作为下一任务的输入，形成可控、可测试的推理流水线 |
| 适用场景 | - 多跳问答（如“先查数据，再分析趋势，最后生成报告”）- 需要中间结果校验或人工介入的流程- 提示工程需分阶段优化（如先摘要再翻译） |
| 工作机制 | 1. 定义任务分解图（DAG 或线性链）2. 为每个子任务设计专用提示模板与输出格式约束3. 执行引擎按序调用 LLM，解析前序输出并注入下一提示4. 支持失败重试、跳过或降级策略 |
| 优势 | - 将不可靠的端到端生成转化为可靠分步推理- 每步可独立测试、监控与优化- 支持混合人工/自动节点（Human-in-the-Loop） |
| 局限 | - 增加延迟与 token 消耗- 错误在链中传播，需健壮的异常处理- 链式依赖限制并行优化空间 |
| 典型组合 | + 提示/响应优化器（A#3）+ 异常处理和恢复（B#12）+ 资源感知优化（B#16） |
| 反模式警示 | 1. 在可单步完成的任务中强行拆链，造成性能浪费2. 未对中间输出做格式校验，导致下游提示注入脏数据 |
| 伪代码示意 |
chain = [
{"prompt": "Summarize: {input}", "output_key": "summary"},
{"prompt": "Translate to French: {summary}", "output_key": "translation"}
]
context = {"input": user_query}
for step in chain:
response = llm(step["prompt"].format(**context))
parsed = json_or_regex_parse(response) # Enforce structure
context[step["output_key"]] = parsed
final_output = context["translation"]
模式卡 #B2：路由（Routing）
| 项目 | 内容 |
|---|---|
| 分类 | I. 目标理解与任务入口层（Agent工程视角） |
| 意图 | 根据用户请求的语义特征、复杂度或上下文，动态选择最优处理路径（如直连 LLM、调用专用模块、转交专家 Agent） |
| 适用场景 | - 系统支持多种能力（聊天、工具调用、文档问答）- 需区分简单查询与复杂任务以优化资源- 多租户或多业务线场景下的请求分发 |
| 工作机制 | 1. 接收原始用户输入2. 使用轻量模型/规则/嵌入相似度判断任务类型3. 将请求路由至对应处理器（如 RAG 模块、代码解释器、客服 Agent）4. 可支持 fallback 机制（如主路由失败转备用） |
| 优势 | - 提升系统整体效率与资源利用率- 实现能力解耦，便于模块独立演进- 支持灰度发布与 A/B 测试 |
| 局限 | - 路由逻辑本身可能出错，导致任务错配- 增加系统架构复杂度- 需持续维护路由规则或训练分类模型 |
| 典型组合 | + 被动/主动目标创建者（A#1/A#2）+ 目标设定和监控（B#11）+ 工具使用（B#5） |
| 反模式警示 | 1. 路由规则过于简单（如关键词匹配），无法处理语义相近但意图不同的请求2. 未设置默认路由，导致未知请求被丢弃 |
| 伪代码示意 |
def route_request(query: str):
intent = lightweight_classifier(query) # e.g., "tool_use", "chat", "rag"
if intent == "tool_use" and has_tool_match(query):
return ToolExecutor().handle(query)
elif intent == "rag" and mentions_documents(query):
return RAGModule().handle(query)
else:
return SimpleLLMChat().handle(query) # default path
模式卡 #B3：并行化（Parallelization）
| 项目 | 内容 |
|---|---|
| 分类 | VIII. 执行调度与资源优化层（Agent工程视角） |
| 意图 | 识别任务中可独立执行的子任务，通过多线程、异步 IO 或分布式执行加速整体流程，提升吞吐与响应速度 |
| 适用场景 | - 多工具调用无依赖（如同时查天气、股票、新闻）- Ensemble 推理（多个模型并行生成）- 批量处理多个用户请求或子问题 |
| 工作机制 | 1. 分析任务依赖图，识别无前驱的可并行节点2. 启动并发执行单元（线程池、async task、worker 进程）3. 收集所有结果，按需聚合或排序4. 处理部分失败（如超时、错误）而不阻塞整体 |
| 优势 | - 显著降低端到端延迟- 提高硬件资源利用率- 支持弹性扩缩容 |
| 局限 | - 并非所有任务可并行（存在数据或逻辑依赖）- 增加内存与协调开销- 调试与日志追踪更复杂 |
| 典型组合 | + 工具使用（B#5）+ 多Agent协作（B#7）+ 资源感知优化（B#16） |
| 反模式警示 | 1. 对强依赖任务强行并行，导致结果不一致或死锁2. 未限制并发数，在高负载下耗尽系统资源 |
| 伪代码示意 |
async def parallel_execute(actions):
tasks = [asyncio.create_task(tool_executor(action)) for action in actions]
results = await asyncio.gather(*tasks, return_exceptions=True)
return [r for r in results if not isinstance(r, Exception)] # handle partial failure
模式卡 #B4：反思（Reflection）
| 项目 | 内容 |
|---|---|
| 分类 | V. 反思、记忆与持续学习层（Agent工程视角） |
| 意图 | 在任务完成后执行系统性复盘，基于执行轨迹生成结构化改进建议，并更新策略、记忆或配置，实现行为优化闭环 |
| 适用场景 | - 任务失败或用户反馈负面- 成功案例需沉淀为经验- 长期运行的自主 Agent 需持续进化 |
| 工作机制 | 1. 记录完整执行轨迹（目标、动作、观察、结果）2. 触发反思模块（自动或手动）3. 调用 LLM 分析成败原因：“哪里出错？如何改进？”4. 将结论写入长期记忆或调整决策参数（如提高某工具调用阈值） |
| 优势 | - 将一次性经验转化为可复用知识- 减少重复错误，提升长期可靠性- 支持个性化适应（如用户偏好学习） |
| 局限 | - 反思质量依赖 LLM 判断，可能归因错误- 需设计安全机制防止策略退化- 存储与检索反思记录带来额外开销 |
| 典型组合 | + 自我/交叉/人类反思（A#9–A#11）+ 记忆管理（B#8）+ 学习和适应（B#9） |
| 反模式警示 | 1. 未验证反思结论就直接更新策略，导致系统不稳定2. 反思仅记录不行动，沦为“日志存档”而非“学习机制” |
| 伪代码示意 |
def post_task_reflection(execution_trace):
if execution_trace.failed or user_gave_negative_feedback():
critique = llm(f"""
Analyze this failed task:
Goal: {trace.goal}
Actions: {trace.actions}
Observations: {trace.observations}
What went wrong? How to improve?
""")
memory.store(reflection=critique, task_type=trace.task_type)
strategy.update_policy(critique) # e.g., adjust tool selection logic
模式卡 #B5：工具使用（Tool Use）
| 项目 | 内容 |
|---|---|
| 分类 | III. 动态知识获取与工具集成层（Agent工程视角） |
| 意图 | 使 Agent 能够在运行时调用外部函数、API 或服务以扩展其能力边界，将 LLM 的“思考”转化为可执行的“行动” |
| 适用场景 | - 需要实时数据（如天气、股价、数据库查询）- 执行物理或数字操作（如发邮件、控制设备、生成图表）- 弥补 LLM 知识截止或计算能力不足（如数学求解、代码执行） |
| 工作机制 | 1. 定义工具集合及其接口规范（名称、参数、描述）2. LLM 根据任务上下文决定是否调用工具及调用哪个工具3. 执行引擎解析 LLM 输出的工具调用指令（如 JSON）4. 调用真实工具并获取结构化结果5. 将结果作为新观察注入对话历史，供后续推理使用 |
| 优势 | - 突破 LLM 静态知识限制，实现“活”的智能体- 支持闭环任务完成（感知→决策→行动→反馈）- 可组合多个工具构建复杂工作流 |
| 局限 | - 工具调用增加延迟与失败风险- 错误的参数传递可能导致系统异常- 需处理认证、限流、错误码等工程细节 |
| 典型组合 | + 增量模型查询（A#6）+ 路由（B#2）+ 工具/Agent注册中心（A#15）+ 异常处理和恢复（B#12） |
| 反模式警示 | 1. 允许 LLM 自由生成任意函数调用，导致安全漏洞（如 exec("rm -rf /")）2. 未对工具输出做校验，直接拼接进提示，引发格式污染 |
| 伪代码示意 |
tools = {
"get_weather": lambda city: weather_api(city),
"send_email": lambda to, body: smtp_client.send(to, body)
}
action = llm(f"Task: {task}\nAvailable tools: {list(tools.keys())}")
if is_tool_call(action):
tool_name, args = parse_tool_call(action) # e.g., {"name": "get_weather", "args": {"city": "Beijing"}}
observation = tools[tool_name](**args)
history += f"\nAction: {tool_name}({args})\nObservation: {observation}"
模式卡 #B6：规划（Planning）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（Agent工程视角） |
| 意图 | 在任务执行前或执行中生成结构化的行动计划（如步骤列表、状态机、DAG），指导 Agent 分阶段、有条件地完成复杂目标 |
| 适用场景 | - 多步骤任务（如“组织会议：查日历→发邀请→准备材料”）- 需要条件分支或回滚机制（如“若 API 失败则重试或换备用”）- 合规或审计要求预声明操作序列 |
| 工作机制 | 1. LLM 基于目标生成初始计划（线性或带分支）2. 规划引擎解析计划为可执行单元（如任务图）3. 按计划顺序或依赖关系调度执行4. 支持运行时重规划（如遇障碍重新生成子计划） |
| 优势 | - 提升复杂任务的可预测性与可控性- 支持人类预审或干预关键节点- 便于日志记录与事后分析 |
| 局限 | - 初始规划可能脱离实际环境状态- 动态重规划增加系统复杂度- 过度规划可能导致“分析瘫痪” |
| 典型组合 | + 单/多路径规划生成器（A#7/A#8）+ 目标设定和监控（B#11）+ 图/状态机编排（B#6 的工程实现载体） |
| 反模式警示 | 1. 在开放域探索任务中强制使用静态计划，丧失适应性2. 计划未包含失败处理路径，导致流程中断 |
| 伪代码示意 |
plan = llm(f"Generate a step-by-step plan to: {goal}. Output as JSON list of actions.")
task_graph = TaskGraph.from_json(plan)
for task in task_graph.topological_order():
result = execute(task)
if task.on_failure and not result.success:
execute(task.on_failure) # fallback action
模式卡 #B7：多Agent协作（Multi-Agent Collaboration）
| 项目 | 内容 |
|---|---|
| 分类 | VI. 多智能体协作与通信层（Agent工程视角） |
| 意图 | 通过多个专业化 Agent 的分工、通信与协调，共同完成单个 Agent 无法胜任的复杂、跨领域任务 |
| 适用场景 | - 需要多领域专家（如研究员+程序员+编辑）- 任务天然可分解（如市场分析→产品设计→技术实现）- 构建辩论、投票或审查机制以提升决策质量 |
| 工作机制 | 1. 定义 Agent 角色、能力与通信协议（如 MCP、消息队列）2. 设计协作拓扑（流水线、环形、星型、去中心化）3. 实现消息传递、任务委派与状态同步机制4. 支持动态加入/退出、负载均衡与故障转移 |
| 优势 | - 利用群体智能解决超复杂问题- 提升系统模块化与可维护性- 支持弹性扩展与容错 |
| 局限 | - 通信开销与协调成本显著增加- 需解决一致性、死锁、信息过载等问题- 调试与可观测性挑战大 |
| 典型组合 | + 基于角色/投票/辩论的合作（A#13/A#12/A#14）+ Agent间通信（B#15）+ 目标设定和监控（B#11） |
| 反模式警示 | 1. 无明确协作协议，导致 Agent 互相覆盖或忽略彼此输出2. 所有 Agent 共享同一上下文，造成信息冗余与 token 浪费 |
| 伪代码示意 |
researcher = Agent(role="Researcher", tools=[web_search])
writer = Agent(role="Writer", tools=[doc_generator])
# Sequential collaboration
research_result = researcher.run("Find latest AI trends in 2026")
report = writer.run(f"Write a report based on: {research_result}")
# Or via message bus
message_bus.publish("research_done", research_result)
writer.listen("research_done", lambda data: generate_report(data))
模式卡 #B8：记忆管理（Memory Management）
| 项目 | 内容 |
|---|---|
| 分类 | V. 反思、记忆与持续学习层（Agent工程视角） |
| 意图 | 为 Agent 提供短期（上下文）与长期（持久化）记忆能力，支持信息检索、经验复用与个性化适应 |
| 适用场景 | - 多轮对话需保持上下文连贯- 用户偏好或历史行为需长期记住（如“用户喜欢简洁风格”）- 从过往成功/失败案例中学习策略 |
| 工作机制 | 1. 短期记忆：维护对话历史窗口（如最近 5 轮）2. 长期记忆：将关键信息向量化并存入向量数据库3. 在每次请求前，检索相关记忆片段注入提示4. 支持记忆更新、遗忘（TTL）与隐私擦除 |
| 优势 | - 显著提升用户体验连续性与个性化水平- 减少重复提问，提高效率- 为反思与学习提供数据基础 |
| 局限 | - 记忆检索可能引入噪声或无关信息- 存储与索引带来额外成本- 隐私与合规风险（如 GDPR “被遗忘权”） |
| 典型组合 | + RAG（A#4）+ 人类反思（A#11）+ 学习和适应（B#9）+ Guardrails（B#18）（控制记忆写入权限） |
| 反模式警示 | 1. 无差别记录所有对话，导致隐私泄露或存储爆炸2. 未对记忆内容做摘要或过滤，检索返回大量低价值信息 |
| 伪代码示意 |
# On new user message
relevant_memories = vector_db.search(embed(user_message), k=3)
prompt = f"User context:\n{relevant_memories}\n\nCurrent query: {user_message}"
response = llm(prompt)
# After interaction, decide what to remember
if is_important_event(response):
memory_entry = summarize_interaction(user_message, response)
vector_db.store(embed(memory_entry), metadata={"user_id": uid, "ttl": 30_days})
模式卡 #B9：学习和适应（Learning and Adaptation）
| 项目 | 内容 |
|---|---|
| 分类 | V. 反思、记忆与持续学习层（Agent工程视角） |
| 意图 | 使 Agent 能够基于交互历史、用户反馈或环境变化，动态调整其行为策略、知识表示或决策逻辑，实现长期性能提升与个性化适配 |
| 适用场景 | - 用户偏好随时间演变（如写作风格、信息密度）- 系统需从错误中自动修复（如工具调用失败后改用替代方案）- 多租户环境中为不同组织定制行为模式 |
| 工作机制 | 1. 收集反馈信号（显式评分、隐式行为、任务成功率）2. 触发学习机制（在线微调、提示模板更新、策略规则修改）3. 将新策略持久化至配置或记忆系统4. 在后续任务中应用更新后的策略，并持续评估效果 |
| 优势 | - 提升用户体验粘性与满意度- 减少人工维护成本，实现自优化- 支持情境感知的智能响应 |
| 局限 | - 学习过程可能不稳定或收敛到局部最优- 需防止过拟合个别用户或噪声反馈- 涉及模型更新时存在版本管理与回滚挑战 |
| 典型组合 | + 记忆管理（B#8）+ 人类反思（A#11）+ 目标设定和监控（B#11）+ Guardrails（B#18）（约束学习边界） |
| 反模式警示 | 1. 未设置学习速率或置信度阈值，导致策略频繁震荡2. 允许恶意用户通过负反馈“毒化”系统行为 |
| 伪代码示意 |
if user_feedback == "too verbose":
current_profile = load_user_profile(user_id)
current_profile["response_style"] = "concise"
update_prompt_template(current_profile)
save_user_profile(user_id, current_profile)
# Or via reinforcement signal
if task_success:
reinforce_tool_selection(tool_used, context)
else:
penalize_tool_selection(tool_used, context)
模式卡 #B10：模型上下文协议（MCP）（Model Context Protocol）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 系统集成、治理与可观测性层（Agent工程视角） |
| 意图 | 提供标准化接口协议，使 LLM 能安全、高效地发现、调用和组合外部工具、数据源或服务，实现“一次定义，多处使用”的能力集成 |
| 适用场景 | - 构建可插拔的工具生态系统（如企业内部 API 市场）- 多客户端（IDE、聊天界面、桌面代理）共享同一组工具- 需要细粒度权限控制与审计日志的生产环境 |
| 工作机制 | 1. 工具提供者实现 MCP Server，暴露 Tools/Resources/Prompts2. Agent（MCP Host）通过 MCP Client 发现并调用能力3. 通信基于 JSON-RPC 2.0，支持 Stdio、HTTP SSE 或 WebSocket4. 平台处理认证、限流、日志与错误标准化 |
| 优势 | - 解耦 Agent 逻辑与具体工具实现- 支持跨平台、跨语言工具复用- 内置安全与治理能力（只读/执行控制、会话隔离） |
| 局限 | - 需要工具开发者遵循 MCP 规范- 增加协议解析与网络开销- 调试分布式调用链更复杂 |
| 典型组合 | + 工具使用（B#5）+ 工具/Agent注册中心（A#15）+ Agent适配器（A#16）（将非 MCP 服务包装为 MCP Server） |
| 反模式警示 | 1. 在单体应用中强行引入 MCP，增加不必要的架构复杂度2. 未配置身份验证，允许任意 Agent 调用高危操作（如删除数据库） |
| 伪代码示意 |
# Tool provider (MCP Server)
@mcp.tool
def query_sales_db(region: str) -> list:
return db.execute("SELECT * FROM sales WHERE region = ?", region)
# Agent (MCP Host)
client = MCPClient("http://sales-tool-server/mcp")
result = client.call_tool("query_sales_db", {"region": "APAC"})
模式卡 #B11：目标设定和监控（Goal Setting and Monitoring）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（Agent工程视角） |
| 意图 | 将高层用户意图转化为可度量、可追踪的数字化目标，并在执行过程中持续监控进度、检测偏差，触发修正或告警 |
| 适用场景 | - 长周期任务（如“提升用户留存率”）- 多步骤工作流需确保里程碑达成- 高风险操作需实时合规检查（如金融交易限额） |
| 工作机制 | 1. 解析用户意图，生成 SMART 目标（具体、可衡量、可实现、相关、有时限）2. 将目标分解为子目标与关键结果（OKR）3. 在执行中采集指标（如工具输出、状态变化）4. 计算当前状态与目标的偏差，若超阈值则 replan、escalate 或终止 |
| 优势 | - 防止 Agent “迷失方向”或陷入无效循环- 提供任务进展可视化与可解释性- 支持主动干预与资源重分配 |
| 局限 | - 目标形式化本身具有挑战性（尤其模糊请求）- 监控指标设计不当会导致误判- 频繁检查影响性能 |
| 典型组合 | + 主动/被动目标创建者（A#2/A#1）+ 增量模型查询（A#6）+ 异常处理和恢复（B#12） |
| 反模式警示 | 1. 目标未量化（如“做得更好”），导致无法监控2. 仅监控最终结果，忽略中间过程风险（如合规违规） |
| 伪代码示意 |
goal = parse_to_smart_goal("Improve customer satisfaction")
monitor = GoalMonitor(goal, metrics=["csat_score", "response_time"])
while not monitor.is_achieved():
agent.step()
current_state = get_current_metrics()
deviation = monitor.calculate_deviation(current_state)
if deviation > threshold:
trigger_replan_or_alert(deviation)
模式卡 #B12：异常处理和恢复（Exception Handling and Recovery）
| 项目 | 内容 |
|---|---|
| 分类 | VIII. 执行调度与资源优化层（Agent工程视角） |
| 意图 | 在 Agent 执行过程中捕获、分类并响应各类异常（工具失败、LLM 幻觉、网络中断等），通过重试、降级、切换路径或人工介入保障任务鲁棒性 |
| 适用场景 | - 调用不可靠外部服务（如第三方 API）- LLM 输出格式错误或逻辑矛盾- 系统资源不足（如 token 超限、内存溢出） |
| 工作机制 | 1. 定义异常类型与严重等级（可恢复 vs 致命）2. 在关键节点设置 try-catch 或超时机制3. 根据异常类型执行恢复策略： - 重试（带退避） - 切换备用工具/模型 - 降级功能（如返回缓存结果） - 请求人类协助4. 记录异常日志用于后续分析 |
| 优势 | - 显著提升系统可用性与用户体验稳定性- 防止小错误引发级联故障- 支持优雅降级而非直接崩溃 |
| 局限 | - 恢复逻辑本身可能出错- 过度重试可能导致资源耗尽- 某些异常无法自动恢复（如权限缺失） |
| 典型组合 | + 工具使用（B#5）+ 增量模型查询（A#6）+ 人类反思（A#11）（作为最终恢复手段） |
| 反模式警示 | 1. 忽略异常或仅打印日志而不处理，导致任务静默失败2. 对所有异常无差别重试，加剧系统负载 |
| 伪代码示意 |
try:
result = tool_api.call(params, timeout=10)
except TimeoutError:
result = tool_api.call_backup(params) # fallback
except InvalidOutputError:
result = llm(f"Fix this invalid output: {raw_output}")
except CriticalError as e:
alert_human_operator(e)
raise
模式卡 #B13：人机协同（Human-in-the-Loop）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 安全、评估与运行时治理层（Agent工程视角） |
| 意图 | 在关键决策点或高风险操作前自动暂停执行，请求人类确认、修正或授权，确保系统行为符合人类意图、伦理规范与业务规则 |
| 适用场景 | - 执行不可逆操作（如删除文件、转账、发布内容）- 输出涉及法律、医疗、金融等高风险领域- LLM 置信度低或存在多解歧义- 需要用户个性化偏好介入（如“按您的风格润色”） |
| 工作机制 | 1. 系统识别高风险上下文（通过规则、模型或策略引擎）2. 自动暂停执行流，生成清晰的待决事项摘要3. 通过 UI/通知通道向人类发起交互请求（批准、修改、拒绝）4. 接收人类反馈后，继续、调整或终止任务流程 |
| 优势 | - 防止自动化系统造成重大损失或伦理事故- 增强用户控制感与信任度- 为模型提供高质量监督信号（用于后续学习） |
| 局限 | - 引入人为延迟，降低自动化效率- 依赖人类响应及时性与判断质量- 需设计良好的交互界面以降低认知负荷 |
| 典型组合 | + 多模态护栏（A#17）+ 异常处理和恢复（B#12）+ 人类反思（A#11）+ Guardrails（B#18） |
| 反模式警示 | 1. 过度依赖人工确认，导致“伪自动化”体验2. 请求信息不清晰（如仅问“是否继续？”），使人类无法有效判断 |
| 伪代码示意 |
if is_high_risk_action(action) or llm_confidence < threshold:
summary = generate_human_review_summary(action, context)
decision = request_human_approval(summary) # e.g., "Approve sending $1000 to Alice?"
if decision == "APPROVE":
execute(action)
elif decision == "MODIFY":
revised_action = get_human_revision()
execute(revised_action)
else:
abort_task()
模式卡 #B14：知识检索（RAG）（Knowledge Retrieval）
| 项目 | 内容 |
|---|---|
| 分类 | III. 动态知识获取与工具集成层（Agent工程视角） |
| 意图 | 实现检索增强生成（RAG）的工程化组件，包括索引构建、查询重写、结果排序与上下文融合，为 LLM 提供准确、实时的外部知识支持 |
| 适用场景 | - 回答依赖私有文档库（如企业知识库、产品手册）- 需要引用来源或避免幻觉- 知识更新频繁，超出 LLM 训练数据时效 |
| 工作机制 | 1. 对外部知识源（PDF、数据库、网页）进行文本提取与分块2. 使用嵌入模型将块向量化并构建索引（如 FAISS、Pinecone）3. 用户查询经重写/扩展后生成嵌入4. 检索 Top-K 相关块，按相关性排序5. 将检索结果拼接进提示上下文供 LLM 生成答案 |
| 优势 | - 显著提升事实准确性与可追溯性- 支持动态知识更新而无需重训练模型- 可控制信息来源范围，提升安全性 |
| 局限 | - 检索质量受分块策略、嵌入模型与查询表述影响- 长文档或多跳推理场景效果有限- 增加系统延迟与存储成本 |
| 典型组合 | + 检索增强生成（A#4）+ 提示/响应优化器（A#3）（规范引用格式）+ 资源感知优化（B#16）（控制检索深度） |
| 反模式警示 | 1. 未对检索结果做相关性过滤，将噪声注入 LLM 上下文2. 分块过小导致语义断裂，过大导致无关信息混入 |
| 伪代码示意 |
def rag_retrieve(query: str, top_k: int = 3):
# Optional: query expansion
expanded_query = llm(f"Rewrite for better retrieval: {query}")
query_emb = embed(expanded_query)
results = vector_index.search(query_emb, k=top_k * 2) # over-retrieve
# Re-rank by cross-encoder or LLM
reranked = rerank_with_llm(query, results[:top_k])
return "\n".join([r.text for r in reranked])
模式卡 #B15：Agent间通信（Agent-to-Agent Communication）
| 项目 | 内容 |
|---|---|
| 分类 | VI. 多智能体协作与通信层（Agent工程视角） |
| 意图 | 定义多个 Agent 之间交换消息、状态与任务的标准化机制，确保协作过程的一致性、可靠性和可追溯性 |
| 适用场景 | - 基于角色的流水线协作（如研究员→分析师→撰稿人）- 投票或辩论式多 Agent 决策- 分布式 Agent 系统（跨进程、跨机器） |
| 工作机制 | 1. 定义通信协议（消息格式、字段、语义）2. 选择传输机制（内存队列、消息总线、HTTP、WebSocket）3. 支持同步/异步、广播/点对点、请求-响应/事件驱动模式4. 实现消息序列化、身份认证、去重与 ACK 机制 |
| 优势 | - 使多 Agent 协作可编程、可测试、可监控- 解耦 Agent 实现，支持异构系统集成- 支持复杂协作拓扑（如环形、星型、去中心化） |
| 局限 | - 通信开销可能成为性能瓶颈- 网络分区或消息丢失需额外容错设计- 协议演进需版本兼容管理 |
| 典型组合 | + 多Agent协作（B#7）+ 模型上下文协议（MCP, B#10）+ 基于角色/辩论/投票的合作（A#13/A#14/A#12） |
| 反模式警示 | 1. 使用非结构化自然语言直接传递消息，导致解析错误2. 未限制消息大小或频率，在高负载下引发雪崩 |
| 伪代码示意 |
class A2AMessage:
def __init__(self, sender: str, receiver: str, content: dict, msg_type: str = "task"):
self.sender = sender
self.receiver = receiver
self.content = content # e.g., {"task": "analyze data", "data_id": "123"}
self.timestamp = time.time()
self.msg_id = uuid4()
# Send via message bus
message_bus.publish(
topic="agent_tasks",
message=A2AMessage("planner", "executor", {"action": "run_simulation"})
)
# Receive and process
def on_message(msg: A2AMessage):
if msg.receiver == self.id:
handle_task(msg.content)
模式卡 #B16：资源感知优化（Resource-Aware Optimization）
| 项目 | 内容 |
|---|---|
| 分类 | VIII. 执行调度与资源优化层（Agent工程视角） |
| 意图 | 在任务执行过程中动态监控和管理计算、时间与财务资源（如 token 消耗、延迟、API 成本），通过模型切换、上下文裁剪或降级策略，在预算约束内实现服务质量与效率的最优平衡 |
| 适用场景 | - 高并发免费聊天机器人需控制 API 成本- 实时系统对响应延迟敏感（如客服对话）- 边缘设备部署需节省电量与带宽- 企业平台按部门/用户设置资源配额 |
| 工作机制 | 1. 为任务设定资源预算（token 上限、响应时间、费用封顶）2. 实时监控资源消耗速率（如每步 token 增长）3. 当接近阈值时触发优化策略： - 切换至轻量模型（如 GPT-4o → GPT-4o Mini） - 裁剪历史上下文（保留核心信息） - 启用缓存（命中则跳过 LLM 调用） - 降级功能（返回摘要而非全文）4. 记录资源使用日志用于后续分析 |
| 优势 | - 显著降低运营成本（案例显示可降本 50%–70%）- 保障服务在高负载下的稳定性与 SLA- 支持精细化成本分摊与预算控制 |
| 局限 | - 降级可能导致用户体验波动- 阈值与路由策略需大量调优- 增加系统监控与决策逻辑复杂度 |
| 典型组合 | + 动态模型切换（A#16 的工程实现）+ 提示/响应优化器（A#3）+ 异常处理和恢复（B#12）（处理超支异常） |
| 反模式警示 | 1. 未设置合理缓冲区，导致频繁触发降级2. 在关键任务（如医疗诊断）中为省成本强制降级，牺牲准确性 |
| 伪代码示意 |
budget = ResourceBudget(max_tokens=2000, max_cost=0.01)
context = trim_history_if_needed(context, budget.remaining)
if budget.near_limit():
llm_model = "gpt-4o-mini" # fallback model
else:
llm_model = "gpt-4o"
response = call_llm(prompt, model=llm_model)
budget.consume(tokens_used(response), cost(response))
模式卡 #B17：推理技术（Reasoning Techniques）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（Agent工程视角） |
| 意图 | 将高级推理方法（如思维链 CoT、程序辅助、符号推理）工程化为可配置、可复用的模块，提升 LLM 在复杂任务中的逻辑性、可解释性与正确率 |
| 适用场景 | - 数学/代码/逻辑推理任务- 需要透明推理过程以供审计（如金融风控）- 多跳问答或抽象模式识别（如 ARC 任务） |
| 工作机制 | 1. 根据任务类型选择推理范式： - CoT：强制 LLM 生成 ... 中间步骤 - ToT（Tree of Thought）：维护多个推理路径并评估 - Program-Aided：生成可执行代码并运行验证2. 在提示中注入推理模板与格式约束3. 对推理过程进行解析、校验与后处理4. 支持混合模式（如简单任务直出，复杂任务启用 CoT） |
| 优势 | - 显著提升复杂任务准确率（尤其数学与代码）- 生成可追溯、可调试的推理链- 支持人类介入修正中间步骤 |
| 局限 | - 增加 token 消耗与延迟- 推理质量依赖提示工程与模型能力- 过度枚举可能导致“复读机”现象 |
| 典型组合 | + 自我反思（A#9）+ 增量模型查询（A#6）+ 提示/响应优化器（A#3）（规范推理格式） |
| 反模式警示 | 1. 在无需推理的任务（如翻译）中强制启用 CoT，浪费资源2. 未设置 N-gram 重复检测，导致无限循环输出 |
| 伪代码示意 |
def apply_reasoning_technique(task: str, mode: str = "cot"):
if mode == "cot":
prompt = f"""
<think>
Let's solve this step by step.
</think>
Question: {task}
"""
response = llm(prompt)
# Extract final answer after </think>
return parse_final_answer(response)
elif mode == "code":
code = llm(f"Generate Python code to solve: {task}")
result = execute_sandboxed_code(code)
return f"Result: {result}"
模式卡 #B18：Guardrails / 安全模式（Guardrails / Safety Patterns）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 安全、评估与运行时治理层（Agent工程视角） |
| 意图 | 在 Agent 输入、输出及执行全流程中实施多层次安全策略，防止生成有害、偏见、违规或不实内容，确保系统符合法律、伦理与业务规范 |
| 适用场景 | - 面向公众的聊天机器人需过滤不当言论- 企业内部助手需遵守数据保密政策- 生成内容需符合品牌指南或行业标准- 多模态输入需检测 NSFW 或隐私泄露 |
| 工作机制 | 1. 输入过滤：检测恶意提示、越狱攻击、隐私数据2. 运行时约束：在提示中注入安全指令（如“不要生成暴力内容”）3. 输出审查：使用规则引擎、分类模型或评判 LLM 检查输出4. 执行拦截：阻止高危工具调用（如删除文件、外发数据）5. 触发动作：屏蔽、修正、告警或转人工 |
| 优势 | - 降低法律与声誉风险- 提升用户信任与合规性（如 GDPR、AI Act）- 支持细粒度策略（按用户、场景、内容类型） |
| 局限 | - 过度过滤可能损害用户体验或创造力- 对抗性攻击可能绕过静态规则- 多模态内容检测仍存在漏检风险 |
| 典型组合 | + 多模态护栏（A#17）+ 人机协同（B#13）（高风险内容转人工）+ 异常处理和恢复（B#12）（处理违规事件） |
| 反模式警示 | 1. 仅依赖关键词黑名单，无法识别语义变体（如谐音、编码）2. 未对工具调用参数做安全校验，导致“合法工具，非法使用” |
| 伪代码示意 |
def apply_guardrails(input_text, output_text, tool_calls):
if contains_pii(input_text) or is_jailbreak_attempt(input_text):
raise BlockedInputError("Input violates policy")
if has_harmful_content(output_text):
corrected = llm(f"Rewrite safely: {output_text}")
if still_unsafe(corrected):
return "I cannot assist with that request."
else:
output_text = corrected
for call in tool_calls:
if call.tool_name in ["delete_file", "send_email"] and not user_has_permission():
raise PermissionDeniedError()
return output_text
模式卡 #B19：评估和监控（Evaluation and Monitoring）
| 项目 | 内容 |
|---|---|
| 分类 | VII. 安全、评估与运行时治理层（Agent工程视角） |
| 意图 | 建立自动化指标体系与可观测性管道，对 Agent 的性能、行为合规性与业务影响进行持续量化评估，支撑 A/B 测试、漂移检测与系统优化 |
| 适用场景 | - 生产环境部署后需监控解决率、延迟、错误率- 需验证新提示策略或模型版本是否优于基线- 检测因数据分布变化导致的性能退化（概念漂移）- 生成合规审计报告以满足监管要求 |
| 工作机制 | 1. 定义多维指标（准确性、流畅性、安全性、效率、成本）2. 在执行流程中埋点采集原始数据（输入、输出、工具调用、token 消耗）3. 应用自动评估器（规则、嵌入相似度、评判 LLM）计算指标4. 将结果写入时序数据库或日志系统（如 Prometheus、Datadog）5. 设置告警阈值，触发通知或自动回滚 |
| 优势 | - 实现 Agent 能力的客观、可比、可追溯度量- 支持数据驱动的迭代优化与快速故障定位- 满足企业级治理与合规审计需求 |
| 局限 | - 自动评估难以覆盖主观质量（如创造力、同理心）- 高质量标注数据获取成本高- 指标设计偏差可能导致优化目标偏离真实需求 |
| 典型组合 | + Agent评估器（A#18）+ 自我/交叉反思（A#9/A#10）+ 异常处理和恢复（B#12）（作为告警响应） |
| 反模式警示 | 1. 仅监控延迟与吞吐量，忽略输出质量与安全性2. 评估数据集与线上分布不一致，导致“测试表现好，线上效果差” |
| 伪代码示意 |
def monitor_and_evaluate(agent, task):
start_time = time.time()
output = agent.run(task)
latency = time.time() - start_time
# Auto-evaluation
accuracy_score = llm_judge(f"Rate accuracy of: {output} vs {task.gold_answer}")
safety_score = safety_classifier(output)
token_usage = count_tokens(output)
# Log to monitoring system
metrics_logger.log({
"latency_sec": latency,
"accuracy": accuracy_score,
"safety_violation": safety_score < 0.5,
"tokens_used": token_usage
})
if accuracy_score < threshold:
alert_team("Performance degradation detected")
模式卡 #B20：优先级排序（Priority Ordering）
| 项目 | 内容 |
|---|---|
| 分类 | VIII. 执行调度与资源优化层（Agent工程视角） |
| 意图 | 根据任务的重要性、紧迫性、依赖关系与资源约束，动态为待处理任务或子目标分配执行优先级，确保关键操作优先完成 |
| 适用场景 | - 客服系统需优先处理高价值客户或系统故障报告- 云计算平台在资源紧张时优先保障核心业务- 个人助理按截止日期与用户偏好排序提醒事项- 网络安全系统对高危威胁告警优先响应 |
| 工作机制 | 1. 为每个任务定义优先级维度（紧急性、重要性、依赖、成本/收益）2. 使用规则引擎或轻量模型计算综合优先级分数3. 将任务插入优先级队列（如 heapq、Kafka topic 分区）4. 调度器按优先级顺序拉取并执行任务5. 支持动态重排序（如新高优任务插入） |
| 优势 | - 提升关键任务的响应速度与成功率- 优化有限资源的分配效率- 增强系统在负载高峰下的韧性 |
| 局限 | - 优先级计算逻辑可能复杂且需持续调优- 低优先级任务可能被长期饥饿- 多目标冲突时难以权衡（如“紧急但不重要”） |
| 典型组合 | + 目标设定和监控（B#11）+ 资源感知优化（B#16）+ 规划（B#6）（用于子任务排序） |
| 反模式警示 | 1. 仅按提交时间排序，忽视业务价值2. 未设置最低优先级保障，导致低优任务永远不被执行 |
| 伪代码示意 |
def calculate_priority(task):
urgency = 1.0 if task.deadline < 1_hour else 0.5
importance = user_tier_weight.get(task.user_id, 1.0)
dependency_ready = 1.0 if all(dep.done for dep in task.dependencies) else 0.0
return urgency * importance * dependency_ready
# Insert into priority queue
priority_queue.put((-calculate_priority(task), task)) # max-heap via negative
# Scheduler
while not priority_queue.empty():
_, task = priority_queue.get()
execute(task)
模式卡 #B21：探索和发现（Exploration and Discovery）
| 项目 | 内容 |
|---|---|
| 分类 | IV. 多步规划、推理与探索层（Agent工程视角） |
| 意图 | 在未知或开放域环境中，通过试错、假设生成与信息搜集，主动发现新知识、可行路径或潜在解决方案，突破预设任务边界的限制 |
| 适用场景 | - 科研助手需自主提出新研究方向- 游戏 NPC 在动态世界中寻找新策略- 故障诊断系统尝试非常规修复方法- 创意生成任务需跳出常规思维框架 |
| 工作机制 | 1. 识别当前知识或路径的不足（如“无可用工具”“多次失败”）2. 启动探索模式：生成假设、提出新问题、搜索新信息源3. 执行低成本试探性动作（如网络搜索、模拟推演）4. 评估探索结果，若有效则纳入主流程，否则回退或继续探索5. 记录发现的新知识至长期记忆 |
| 优势 | - 增强 Agent 在开放域问题中的适应性与创造性- 发现人类未预见到的解决方案- 支持持续学习与知识扩展 |
| 局限 | - 探索过程不可控，可能陷入无效循环- 增加资源消耗与失败风险- 需要强健的回退机制防止失控 |
| 典型组合 | + RAG（B#14）（用于信息发现）+ 规划（B#6）（生成探索路径）+ 学习和适应（B#9）（沉淀探索成果） |
| 反模式警示 | 1. 在封闭域任务（如“查订单状态”）中启用探索，导致偏离目标2. 未设置探索预算（时间/次数），造成无限发散 |
| 伪代码示意 |
if task.failed_attempts > 3 and no_known_solution(task):
hypotheses = llm(f"Generate 3 novel approaches to solve: {task}")
for hypothesis in hypotheses:
# Low-cost simulation or search
result = simulate_or_search(hypothesis)
if is_promising(result):
new_plan = llm(f"Create plan based on: {hypothesis}, evidence: {result}")
execute(new_plan)
memory.store_discovery(hypothesis, result) # Learn from exploration
break
Agent 工程视角模式卡决策树
构建 Agent 工程视角的模式卡决策树（B类决策树）的目标是： 帮助工程师、架构师或 DevOps 人员在实现一个 AI Agent 系统时，根据具体的工程需求、系统约束和运行环境，快速选择合适的 B#1–B#21 工程模式组合。与 A 类（LLM 视角）决策树关注“做什么”不同，B 类决策树聚焦于“怎么做”——即如何以可靠、高效、安全、可维护的方式实现 Agent 的能力。
开始：你正在实现一个 AI Agent 系统
│
├─ 1. 是否需要将复杂任务拆解为多个步骤并结构化交互？
│ ├─ 是 → **B#1：提示词链**
│ └─ 否 → 跳过
│
├─ 2. 用户请求是否需动态分发到不同处理模块？
│ ├─ 是 → **B#2：路由**
│ └─ 否 → 单一入口
│
├─ 3. 任务中是否存在可并行执行的子操作？
│ ├─ 是 → **B#3：并行化**
│ └─ 否 → 串行执行
│
├─ 4. 是否需要调用外部工具、API 或服务？
│ ├─ 是 →
│ │ ├─ 需标准化集成？ → **B#10：模型上下文协议 (MCP)**
│ │ └─ 需工程化调用？ → **B#5：工具使用**
│ └─ 否 → 仅内部推理
│
├─ 5. 是否涉及多跳知识依赖或私有文档问答？
│ ├─ 是 → **B#14：知识检索 (RAG)**
│ └─ 否 → 跳过
│
├─ 6. 任务是否需要显式生成执行计划？
│ ├─ 是 → **B#6：规划**
│ └─ 否 → 无计划
│
├─ 7. 是否使用多个专业化 Agent 协同工作？
│ ├─ 是 →
│ │ ├─ 需通信机制？ → **B#15：Agent间通信**
│ │ └─ 需协作框架？ → **B#7：多Agent协作**
│ └─ 否 → 单 Agent
│
├─ 8. 是否需记住用户历史、偏好或长期上下文？
│ ├─ 是 → **B#8：记忆管理**
│ └─ 否 → 无状态
│
├─ 9. 系统是否需从反馈中自动改进行为？
│ ├─ 是 → **B#9：学习和适应**
│ └─ 否 → 静态策略
│
├─ 10. 是否存在高风险操作或需人类监督？
│ ├─ 是 → **B#13：人机协同 (Human-in-the-Loop)**
│ └─ 否 → 全自动
│
├─ 11. 是否需在运行时监控目标进展？
│ ├─ 是 → **B#11：目标设定和监控**
│ └─ 否 → 无目标追踪
│
├─ 12. 系统是否可能遇到失败（工具超时、LLM 幻觉等）？
│ ├─ 是 → **B#12：异常处理和恢复**
│ └─ 否 → 假设全成功
│
├─ 13. 是否受资源（token、延迟、成本）限制？
│ ├─ 是 → **B#16：资源感知优化**
│ └─ 否 → 无限资源假设
│
├─ 14. 任务是否涉及复杂逻辑推理（数学、代码、多跳）？
│ ├─ 是 → **B#17：推理技术**
│ └─ 否 → 直接生成
│
├─ 15. 是否需防止有害、偏见或违规内容？
│ ├─ 是 → **B#18：Guardrails / 安全模式**
│ └─ 否 → 无安全过滤
│
├─ 16. 是否需量化评估 Agent 性能或进行 A/B 测试？
│ ├─ 是 → **B#19：评估和监控**
│ └─ 否 → 无度量
│
├─ 17. 系统是否需处理多个任务且存在优先级差异？
│ ├─ 是 → **B#20：优先级排序**
│ └─ 否 → FIFO 或随机
│
└─ 18. 任务是否处于开放域或需主动发现新路径？
├─ 是 → **B#21：探索和发现**
└─ 否 → 封闭域求解
决策树的核心判别维度
| 维度 | 关键问题 | 对应 B 类模式 |
|---|---|---|
| 交互结构 | 是否需分步、链式交互？ | B#1 |
| 流量分发 | 是否需智能路由？ | B#2 |
| 执行效率 | 是否可并行？ | B#3 |
| 能力扩展 | 是否调用外部工具？ | B#5, B#10 |
| 知识获取 | 是否需检索私有知识？ | B#14 |
| 任务分解 | 是否需生成计划？ | B#6 |
| 群体智能 | 是否多 Agent 协作？ | B#7, B#15 |
| 状态保持 | 是否需记忆？ | B#8 |
| 自进化 | 是否需从反馈学习？ | B#9 |
| 人机边界 | 是否需人工介入？ | B#13 |
| 过程控制 | 是否需目标追踪？ | B#11 |
| 鲁棒性 | 是否需容错？ | B#12 |
| 成本控制 | 是否受资源限制？ | B#16 |
| 认知深度 | 是否需高级推理？ | B#17 |
| 安全性 | 是否需内容过滤？ | B#18 |
| 可观测性 | 是否需性能评估？ | B#19 |
| 调度策略 | 是否需任务优先级？ | B#20 |
| 开放性 | 是否需主动探索？ | B#21 |
本文所述观点基于当前实践与有限实验，且难免存在疏漏或偏颇之处。AI Agent 领域日新月异，架构设计亦无“银弹”。欢迎各位读者在评论区或社区中交流探讨。
