把一个智能体写成一段超长的提示词，短期能跑，长期一定不稳。任务一多，它会漏要求，会忘上下文，工具一开始报错，整条流程就卡死在那里。
真正能长期运行的智能体，靠的是一组可复用的设计模式。这些模式解决的是同一类麻烦：怎么把活拆开，怎么调工具，怎么记住东西。还有怎么检查输出，怎么兜住失败，哪些环节必须让人点头。
下面这 21 个模式来自一线工程实践，能归成五大类。每个模式都按同样的顺序讲：为什么需要它，具体怎么做，好在哪，坑在哪，什么场景该用。不用全上，先看你现在最疼的是哪一环。
先拆任务：从提示链到反思的四个模式
提示链：别把二十件事塞进一句提示词
把一个智能体写成一段巨型提示词，短期能跑，长期一定不稳。提示链的做法是把复杂任务切成连续的小步骤。每一步都留下稳定的中间产物，再交给下一步。
先写清”完成”的判定标准，再把活拆成 2 到 6 个子步骤。每一步的中间输出长什么样，也要提前定。固定结构很有用，条目、表格或者结构化数据都行。执行时按顺序走，把中间产物记下来，关键位置加一道校验，比如必填字段有没有缺。
它的好处是能调试。哪一步出错，翻那一步的产物就行。代价有两个。延迟和成本会上去，而且前面的错会顺着往下传。
适合多步骤转换。先总结，再提取，然后计算，最后格式化，这种活就该拆成链。
路由：先决定这活该谁干
系统里有好几条工作流，有好几个工具，也有好几个智能体。这时候第一件事不是回答，是判断请求该交给谁。判断依据可以是用户意图，也可以是复杂度或者风险高低。
做法是先把信号提出来。用户的意图要提，问题的领域要提，紧急程度和置信度也得看。然后按规则或者分类器做选择，两者混着用也行。执行完选中的工作流，要留一条后备路线。拿不准的时候，追问一句、走个安全默认值，或者直接升级处理，都比硬猜强。硬猜最贵。
好处是不靠一个巨型提示词也能扩展，每条路由都能单独调优。坏处是路由错了，后面的活全白干。
工具和智能体多到需要自动选的时候，就该上它。
并行化：不互相等的活一起跑
子任务之间没有依赖关系，就没必要排队。并行化把它们同时发出去，最后再把结果合起来。
先找出互不依赖的活，然后用异步任务或者多个工作进程并发跑。汇合那一步要处理合并，去重是一种，排序是一种，有时还要投票或者总结。合并冲突要提前想好规则。
它的收益主要在延迟上。缺点是出了问题更难查，几个分支一起出错的时候尤其难受。
取多个结果再合并的活，最适合并行。
反思：第一版别急着交
模型一次生成的输出，直接交付风险很高。反思模式让系统反复走同一个循环。先生成，再批评，然后修订，直到结果达到预设标准。
做法是先出一版草稿，再做一次批评检查。重点看有没有漏掉要求，逻辑上有没有漏洞，格式对不对。然后按明确列出的问题去改。循环要有停止条件，比如最多几轮，或者评分过线就停。没有它，循环会失控。
这条路能明显提高质量，代价是延迟和消耗都会涨。没有停止规则，很容易陷进去出不来。
写作和写代码值得加一轮反思。推理和结构化输出也一样。
把手接出去：工具和规划，还有协作与记忆
工具使用：模型记不住的事，让它自己去查
光靠模型记忆，覆盖不了真实数据，也做不了外部操作。工具使用模式让智能体去调接口，去查数据库，去算数或者读文件。拿到准确结果，再继续决策。
做法是先定义每个工具的数据结构，把权限白名单也定下来。然后让模型自己选工具并给出参数，工具跑完把结果回传，模型据此回答，或者决定下一步。
它的价值是把能力扩展到记忆之外，也算得更准。风险在权限。白名单没控住，一次误调用就可能出事。工具故障也必须处理。别假设它永远成功。
凡是要外部真实信息或者精确计算的活，都绕不开它。
规划：有依赖的活先排顺序
面对带依赖关系的复杂目标，先明确子目标和执行顺序，再一步步推进。规划模式把这件事显式写出来。
做法是把请求翻译成目标和约束，生成一份计划，把步骤、依赖和需要的工具都列清楚。执行时每步之后检查一次进度，遇到新信息或者失败就改计划。
它的好处是复杂目标更可靠，进度可追踪也可审计。缺点同样明显，计划本身可能就错，或者模糊到没法执行。编排和状态跟踪也要多花成本。
步骤之间有前后依赖的问题，都该先规划。
多智能体协作：别让一个智能体演全套
把研究交给一个智能体，把构建交给另一个，把验证交给第三个。再由一个协调器合并结果，往往比一个全能智能体稳。
协调器先把任务拆开，再分给对应的专业智能体。每个智能体产出自己的东西，可能是笔记，也可能是代码或者批评意见。协调器负责合并和解决冲突，必要时再迭代一轮。
分工能改善质量，专门的审查和验证角色也能把稳定性拉高。代价是协调开销。协议没约定好，成本和延迟反而比单打独斗更高。
任务横跨多种技能的时候，分工才划算。
记忆管理：该记什么、该取什么
跨会话或者长任务里的一致性，靠的是记忆管理。系统要决定哪些信息值得存，怎么打标记，还有当前这个请求真正需要取回哪些。
该存的东西不难判断。用户的偏好要留，确认过的事实要留，做过的决策和阶段摘要也该留。存的时候带上元数据，时间戳、标签和来源都算。取的时候只捞和当前提问相关的部分，注入上下文还要给边界，保持简短，分段清晰。
好处是连续性有了，也不用反复问用户同样的问题。风险在隐私和噪声，检索回来一堆不相关的东西，模型反而更糊涂。
做助手的场景靠它撑着。项目里的编程助手靠它撑着。跨天的工作流也靠它撑着。
学与用：越用越好，也得有兜底
学习与适应：把评分和返工变成改动
用得多的智能体会不断积累评分、编辑记录和成功失败日志。学习与适应模式把这些反馈转成对提示词、路由或者检索策略的改动。必要的时候才动模型微调，上线前一定先验证。
做法是先捕获反馈信号，再分析失败案例和用户偏好。然后更新提示词、路由或者检索策略。改动要在评估里验证过才能上线。
它的价值是越用越准，重复犯的错会减少。隐患是漂移，从错误的反馈里学歪了更麻烦。治理和评估纪律少不了。
用量大、改进收益能持续累积的智能体，适合走这条路。
模型上下文协议：工具多了就统一接一次
工具和资源一多，各接各的会写出一堆胶水代码。模型上下文协议（MCP）的思路是拿一个标准化连接层把能力统一暴露出去。
工具和资源托管在服务端，客户端负责发现和调用。认证和策略集中放在服务端这一层，不用每个工具都做一遍。
集成确实更简洁，工具数量上去之后也好维护。代价是多了一层基础设施，访问控制和审计日志一样都不能省。
工具和资源很多，又希望走标准接法的时候，用它。
目标设定与监控：把”做完”写清楚
自主执行不能只盯着最终目标，还要一路检查进度。目标设定与监控把成功标准显式写出来，执行过程中持续跟踪状态、预算和风险。
做法是先定义成功标准，能衡量就尽量衡量。每一步之后看一次进度信号，偏离轨道就调整计划或者升级处理，达到标准就停下。
它让自主运行更可靠，也能更早发现失败。麻烦在主观任务上，指标很难定。监控本身也有开销。
长时间运行的工作流和自主智能体，值得加这一层。
异常处理与恢复：工具一定会坏
真实环境里的工具调用一定会失败。异常处理与恢复要求你提前想好三件事。超时怎么办，数据结构不对怎么办，工具直接挂掉又怎么办。同时准备好重试和换路线这两手，必要时还能回滚或者升级。
做法先检测错误。属于暂时性故障的就退避重试，同时限定次数。重试不行就切到替代工具，或者切到替代路由，必要时修复状态甚至回滚。高风险场景或者持续失败，直接升级处理。
做好了，生产环境会稳很多，一个小工具抽风不至于中断整条工作流。代价是更多工程活，重试、幂等和可观测性都得补上，测试也要跟上。
只要用到外部工具，就该留一条恢复路径。
人工回路：该让人点头的地方别省
敏感操作不适合全自动。人工回路（HITL）让智能体先交方案和理由。由人来批准、编辑或者拒绝，获批之后才真正执行。
做法是让智能体起草方案并说明理由，人看完选择批准、修改或者否决，只有获批的操作才会被执行。人给的反馈要存下来，用来改善后续行为。
高风险操作会安全很多，信任和问责也更清楚。代价是慢，还要有个好用的审查界面，人得及时参与。
涉及钱和合规的场景，不可逆的操作，还有直接面向客户的动作，都该挂上人工回路。
外部知识、通信与安全：从检索到防护栏
知识检索：先查资料再回答
回答企业文档、政策或者合同这类问题时，外部知识比模型记忆更可靠。知识检索（RAG）先捞出相关内容，再把上下文交给模型生成答案。
做法是先构造一条好的检索查询，把它向量化或者重写都行。然后从存储里取出最相关的前几段，可选做一次重排和过滤提高相关性。再用这些内容组装提示词，生成有依据的输出，必要时附上来源。
它的好处是回答更贴事实，幻觉少，知识更新也不用重新训练。难处在检索质量上，切块方式、噪声和缺失数据都会拖后腿，延迟和索引开销也跟着涨。
像文档问答和企业知识库这类场景，政策手册也算，基本都靠它。
智能体间通信：跨团队的活怎么派
多个智能体跨团队或者跨框架协作时，需要一个结构化协议。这个协议要说清自己能做什么，怎么派任务，结果怎么回传，进度怎么更新。这就是 A2A。
做法是每个智能体先声明自己的能力。调用方按约定发结构化任务请求，接收方返回结果或者进度，调用方合并之后继续往下走。
它让互操作和模块化成为可能，任务委派也清楚。前提是安全和认证必须做扎实，协调层一旦出错会被放大到整条链路。
多个智能体跨团队协作的场景，值得先定协议再动手。
资源感知优化：不是每个请求都值得上大模型
请求有难有易，全都用最贵的模型是浪费。资源感知优化按复杂度和重要性挑算力档位，风险也算进去。质量、延迟和成本三者之间，找一个平衡点。
做法是先估复杂度，再看重要性和风险，然后选模型档次和工作流等级。上下文也要减负，总结能省，裁剪能省，按重要性排序也能省。上线后持续看开销和延迟，回头调路由。
做好了大笔省钱，质量也不会掉太多，大规模生产环境尤其受用。省下来的是真金。选错档位就掉质量，调优还是得靠监控和评估。
请求难度差异大，模型成本又高，服务等级还严的场景，最适合。
推理技术：拆开算，再验证
复杂推理任务往往一步到位答不好。推理技术先把问题拆开，再借助工具计算或者查事实。中间结果还要过一遍约束检查、测试或者交叉验证。
做法是分解问题并选一种推理策略，用工具算数或者查资料。然后通过约束、测试和交叉检查来验证，验证不过就继续迭代。
数学题和调试这类任务表现会好很多，规划类的活也一样。验证环节能提高可靠性。代价是消耗和延迟更高，循环过程必须有护栏。
一次回答经常翻车的复杂推理任务，加上它。
防护栏：输入和权限，还有输出这三道口
生产级智能体需要分层安全控制。输入先做风险检查，工具权限收紧，输出还要检查策略合规、格式和数据泄漏。
做法是在输入端筛查风险意图和缺失信息，在提示词和路由里执行策略约束。工具侧的收紧手段有只读模式，有白名单，有沙箱和速率限制。输出端验证合规性、格式和数据泄漏，必要时升级或者直接拒绝。
系统会更安全，有害结果和数据泄漏都会少。副作用是可能拦过头，正常请求被挡在外面，维护也得持续投入。
只要面向客户或者调用工具，这一层不能省。
评估、排序与探索：收尾的那几个模式
评估与监控：拿数据说话
质量和成本指标要持续跟踪，安全指标也一样。改动要用生产轨迹来验证，评测数据集和对照测试都算。别凭感觉。
做法是先定义指标，准确率和有据性最常见，延迟、成本和拒绝率也常看。然后建评测集，标准答案和对抗案例都要有。生产轨迹和告警长期盯着，改动全面上线前先做对照测试。
这套东西能让系统长期可靠，迭代也敢放开手脚。代价是基础设施投入，还有指标设计本身就很考人，标准答案有时根本定不出来。
受监管的领域，或者任何要长期跑的生产系统，都该有它。
优先级排序：谁先谁后也是系统行为
任务同时涌进来的时候，执行顺序本身就是系统行为的一部分。优先级排序按紧急程度和价值给任务打分，风险高低和依赖关系也算进去。条件变了就重新算。
做法是把工作转成明确的任务，用一套策略打分，先执行分最高的那个。条件变化时持续重评。
它的作用是避免把算力浪费在低价值任务上，紧急需求和服务等级也能保住。风险在评分本身，规则错了，重要任务可能长期排在后面没人管。
多用户智能体用得上，任务池长期积压的也用得上。异步任务系统同理。
探索与发现：不知道方向时先提假设
有些问题一开始根本不知道正确方向。探索与发现先提出候选假设，再用搜索、实验或者工具调用去收集证据。淘汰弱的方案，一轮轮迭代。
做法是先生成假设或者候选方案，再跑实验或者搜索去拿证据，工具调用也算。评估之后淘汰较弱的假设，重复到置信度足够或者预算用完为止。
开放式研究和诊断未知问题，这条路很对路，也可能挖出意想不到的解法。它贵，多轮迭代烧钱。停止条件和评估规则必须先定。
调查和调试这类活，还有创新类分析，适合它。
团队真正在用的组合配方
单个模式解决单个问题，实际项目里是把几个模式搭起来用。下面这几种搭配，是团队交付时最常出现的形态。
先检索，再起草，然后检查内容有没有依据，最后修订。这是检索加反思。
先分类，再调对工具，然后给答案。这是路由加工具。
先规划，再执行，工具失败就恢复，接着往下走。这是规划加恢复。
专业智能体起草，审查者打分，协调器合并。这是多智能体加评估。
工具走白名单，敏感操作等人批准。这是防护栏加人工回路。
选模式不用贪多。先看看你现在最疼的是哪一环，是输出质量不稳，还是工具老失败，又或者是记忆一长就乱。找到那一环，再从这 21 个里挑对应的两三个上。先挑两三个。比一次性全铺开更管用。日常搭 AI工具做工作流也是这个思路。工具越少越可控，模式越少越容易维护。
如果你在做 AI编程类的活，最先见效的往往是路由和工具使用这两组。写代码这件事，AI对话式的单轮交互撑不了多久。把记忆管理和反思接上，稳定性会有肉眼可见的变化。
