为复杂工作流选择单个 agent 还是多 agent 系统。
默认使用带有工具的单个 agent。仅当任务边界清晰、上下文溢出或不同模型层级适合不同子任务时，才拆分为多个 agent。
原因: 每个新增的 agent 都会增加延迟、错误暴露面和编排成本；大多数工作负载通过一个配备完善的 agent 即可成功。
最后审核：2026年6月
NCP-AAI 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。
为复杂工作流选择单个 agent 还是多 agent 系统。
默认使用带有工具的单个 agent。仅当任务边界清晰、上下文溢出或不同模型层级适合不同子任务时，才拆分为多个 agent。
原因: 每个新增的 agent 都会增加延迟、错误暴露面和编排成本；大多数工作负载通过一个配备完善的 agent 即可成功。
编排器必须将异构子任务分派给专家。
使用一个 supervisor agent，它分解目标，将任务路由给带有自己 prompt 和工具的 worker agent，并聚合结果。
原因: 集中控制保持状态一致，并使决策边界可审计，而不是一个自由混乱的群体。
agent 流具有条件分支、循环和并行扇出。
将工作流建模为节点和边的显式图，而不是自由形式的循环，这样控制流是确定性且可恢复的。
原因: 图使分支可测试，并允许您在故障后从任何节点检查点和重放。
传入请求的类型和成本差异很大。
在系统前端使用一个轻量级 router agent，它分类意图并将请求分派给最便宜的、有能力的下游 agent 或工具。
原因: 路由避免了为琐碎请求支付前沿模型成本，并隔离了每个路径的关注点。
多个 agent 必须读写共同的工作流状态。
将状态外部化到一个以会话为键的共享存储（键值或文档），而不是在 agent 之间传递完整的记录。
原因: 共享存储限制了上下文增长，并防止 agent 之间出现分歧的状态副本。
为横向扩展设计 agent。
保持 agent 计算无状态；将会话和内存外部持久化，以便任何副本都可以处理任何请求。
原因: 无状态节点可以干净地自动扩展，并在 pod 重启后生存，而不会丢失正在进行的工作。
子 agent 或工具在工作流中途失败。
设计具有重试/退避机制的幂等步骤，为副作用提供补偿措施，并在重试耗尽时提供回退路径或人工升级。
原因: agent 系统会部分失败；恢复必须是首要设计考虑，而不是事后才想到的。
子 agent 由不同的团队开发。
将每个 agent's 的输入/输出契约定义为类型化 schema，并将 agent 视为稳定接口后的服务。
原因: 明确的契约允许 agent 独立演进并进行独立单元测试。
agent 在困难任务上的输出质量不一致。
添加一个评论/反思步骤，根据标准审查草稿并在返回之前触发有界重试。
原因: 自我批评可以廉价地捕获错误，但要限制迭代次数以避免失控循环和成本。
agent 必须与外部 API、数据库或文件交互。
将功能暴露为类型化的函数/工具定义；模型发出工具调用，您的代码执行它并返回结果，然后循环继续。
原因: 结构化工具调用比解析自由文本指令更可靠、更可审计。
agent 必须在再次行动之前对观察结果进行推理。
实现一个 ReAct 循环：模型产生一个想法，选择一个工具，接收观察结果，然后重复直到满足停止条件。
原因: 交错的推理和行动暴露了调试链，并提高了多步骤的准确性。
模型误用或虚构工具参数。
编写精确的工具描述，限制参数类型和枚举，并为每个工具提供一到两个使用示例。
原因: 大多数工具调用错误都可以追溯到模糊的 schema；描述就是工具的 prompt。
下游代码需要 agent 提供可靠的 JSON。
将生成约束到 JSON schema（结构化输出），而不是解析自由文本，并在使用前进行验证。
原因: schema 约束的解码消除了脆弱的正则表达式解析和无声的格式漂移。
在 NVIDIA 堆栈上构建生产 agent。
使用 NeMo Agent Toolkit 组合 agent、工具和工作流，将模型调用连接到 NIM 服务后端。
原因: 该 toolkit 标准化了 agent 的内部连接，并与 NVIDIA 服务原生集成。
工具返回错误或超时。
将错误作为工具结果返回给模型，以便它可以重试、调整参数或选择替代路径。
原因: 将故障暴露给 agent 可以实现恢复；吞噬故障会让 agent 盲目。
在一个步骤中需要多次独立的工具调用。
当模型支持且调用没有顺序依赖时，并行发出工具调用，然后合并结果。
原因: 并行执行可以减少扇出工作（如多源查找）的实际延迟。
专业能力应在不同工作流中可重用。
将子 agent 封装在一个单一的工具接口后面，这样父级就可以像调用任何其他工具一样调用它。
原因: 将子 agent 视为工具可以保持组合的统一性并隐藏内部复杂性。
agent 偏离任务或忽略约束。
在简洁的 system prompt 中固定角色、允许的工具、输出格式和硬约束；在接近末尾处重申关键规则。
原因: 紧凑的 system prompt 是控制 agent 行为最便宜、最高效的方法。
衡量 agent 是否正确解决了多步骤任务。
根据带标签的数据集，评估最终答案和轨迹——工具调用准确性、步骤顺序和不必要的操作。
原因: 来自错误轨迹的正确答案是脆弱的；轨迹评分可以捕获潜在故障。
开放式 agent 输出没有真实标签。
使用带有评分标准的 LLM-as-judge 对输出进行评分，并根据少量人工标注样本进行校准。
原因: 判别模型可以扩展评估，但必须进行校准，否则它们会引入自己的偏见。
您需要在每次发布前捕获回归。
构建一个离线评估工具，带有一套固定的场景，在每次更改时运行，并根据通过阈值来控制部署。
原因: agent 行为会随着 prompt 或模型变化而微妙地改变；回归测试套件是安全网。
agent 选择了错误的工具或错误的参数。
将工具选择的精确度/召回率和参数有效性作为独立指标进行跟踪，而不仅仅是最终任务的成功。
原因: 隔离工具调用层可以精确查明故障是来自选择还是来自 schema。
更改后评估通过率下降。
检查失败案例的完整轨迹，对失败模式进行聚类，并首先修复主要聚类。
原因: 聚合分数隐藏了根本原因；按轨迹聚类揭示了实际缺陷。
agent 表现不佳，您必须改进它。
首先迭代 prompt 和工具描述；只有当 prompt 更改效果达到平台期时，才升级到更大的模型或进行微调。
原因: prompt 迭代快速且便宜；模型更换会增加成本，应基于证据驱动。
比较两种都达到准确性目标的 agent 设计。
在评估中添加每任务成本和 p95 延迟，以便更便宜、更快速的设计在平局时获胜。
原因: 生产可行性是准确性加成本加延迟，而不仅仅是准确性。
为生产环境中的 agent 提供模型推理服务。
将模型部署为 NIM 微服务，为 agent 提供标准化的、GPU 加速的推理端点，并内置批处理功能。
原因: NIM 将优化后的推理封装在稳定的 API 后面，因此 agent 无需管理服务内部机制。
agent 流量高峰和不可预测。
将 agent 和服务容器化，在 Kubernetes 上运行，并根据并发性或 GPU 利用率进行自动扩展，设置合理的最小/最大边界。
原因: 自动扩展吸收流量高峰，而最小副本避免了关键路径上的冷启动延迟。
在负载下 GPU 推理成本过高。
在 NIM 层启用动态/连续批处理，以在增加硬件之前提高每 GPU 每秒的 token 吞吐量。
原因: 批处理显著提高了 GPU 利用率；首先扩展节点会浪费容量。
agent 启动无限制的并行工具和模型调用。
应用每个 agent 和全局并发限制，并带有队列，以便系统在负载下平稳降级。
原因: 无限制的扇出会耗尽 GPU 和下游配额，从而导致级联故障。
为 agent 推理工作负载选择 GPU 硬件。
根据模型占用空间和延迟目标进行调整——H100 适用于已成熟的大型模型，Blackwell 适用于内存带宽和推理吞吐量占主导地位的场景。
原因: 将硬件与模型匹配可以避免资源不足和为闲置容量付费。
安全发布新的 agent 或模型版本。
通过 canary 部署到一小部分流量，将实时指标与基线进行比较，然后推进或回滚。
原因: agent 行为变化很难完全离线预测；canary 部署限制了影响范围。
长 agent 链存在请求挂起的风险。
设置每步和端到端超时预算；超出时取消并回退。
原因: 没有预算，一个慢速工具可能会占用一个 GPU 插槽并饿死其他请求。
任务需要许多相互依赖的步骤。
使用计划-执行模式：首先生成一个明确的计划，然后执行步骤，当假设被打破时重新规划。
原因: 预先规划减少了漫无目的，并在进行工具调用之前提供了一个验证检查点。
分解质量是瓶颈。
将规划步骤路由到 Nemotron 推理模型，同时使用更便宜的模型进行执行。
原因: 将推理级计算用于重要之处——计划——而不是用于每个常规子步骤。
agent 必须在长时间会话中记住事实。
在工作上下文中保留最近的对话；将持久事实保存到按需检索的长期记忆存储中。
原因: 将所有内容塞入上下文会增加成本和延迟，并最终使窗口溢出。
选择如何存储 agent 记忆。
将情节交互历史与语义事实分开存储；通过相似性检索语义记忆，通过新近度/会话检索情节记忆。
原因: 不同的访问模式需要不同的存储；一个桶对于两者都检索不佳。
长时间运行的对话接近上下文限制。
将较旧的对话轮次总结成紧凑的运行摘要，并丢弃原始历史记录，只保留最近的逐字对话。
原因: 滚动摘要在保持连续性的同时，限制了 token 成本并避免了截断错误。
agent 必须将答案基于私有企业数据。
为 agent 提供一个基于 vector store 的检索工具，这样它就可以决定何时以及检索什么，而不是始终预置上下文。
原因: agent 检索只在需要时获取，减少了 token 和不相关的上下文。
在 NVIDIA 上构建高质量的检索管道。
使用 NeMo Retriever embedding 和 reranking NIM 微服务来实现加速的、生产级的 RAG。
原因: NeMo Retriever 提供了在 GPU 上高效服务的经过调优的 embedding/rerank 模型。
纯 vector search 会遗漏精确匹配和关键词查询。
将密集 vector search 与稀疏/关键词检索结合起来，并对合并后的候选结果进行重新排序。
原因: 混合检索可以恢复 embedding 模糊的精确术语（ID、代码）。
检索到的块过于粗糙或过于零碎。
在语义边界上进行分块，适度重叠并附加元数据；根据 embedding 模型和查询类型调整大小。
原因: 块粒度直接影响检索相关性；两个极端都会降低基础质量。
agent 从索引返回过时信息。
在源更改时进行增量重新索引，并用时间戳标记文档以实现按新近度感知的排序。
原因: 如果没有新鲜度处理，RAG 会自信地将答案基于过时数据。
为 agent 推理选择模型后端。
选择一个与推理负载相匹配的 Nemotron 模型，并通过 NIM 提供服务，以获得标准化端点。
原因: Nemotron 推理变体针对 agent 规划和工具使用进行了调优；NIM 标准化了服务。
将 agent 需求映射到正确的 NVIDIA 组件。
使用 NeMo Agent Toolkit 进行编排，NIM 进行服务，NeMo Retriever 进行 RAG，NeMo Guardrails 进行安全，Nemotron 进行推理。
原因: 了解哪个组件负责哪个方面是反复出现的考试和设计决策。
在 NVIDIA 上组装端到端 agent 应用程序。
在 agent 层后面组合离散的 NIM 微服务（LLM、embedding、rerank、guardrails），并独立扩展每个服务。
原因: 微服务分解使每个功能都能独立扩展和版本化。
数据驻留规则禁止将数据发送到外部 API。
在自有的 GPU 基础设施上自托管 NIM 微服务，以便模型和数据保留在边界内。
原因: NIM's 的可移植封装支持满足驻留要求的本地部署。
生产 agent 行为异常，您必须诊断它。
发出分布式跟踪，捕获每个模型调用、工具调用和决策，然后端到端检查失败的轨迹。
原因: agent 故障是多步骤的；如果没有完整的跟踪，您无法定位推理出错的地方。
agent 的 token 消耗和延迟随着时间推移而增加。
跟踪每个 agent 和每个工具的 token、成本和 p95 延迟，并在超出阈值时发出警报。
原因: 随着 prompt 和流量的演变，成本和延迟会悄无声息地漂移；指标可以及早发现。
质量在没有代码更改的情况下逐渐下降。
持续对生产样本运行评估套件，并在指标偏离基线时发出警报。
原因: 数据和上游模型漂移在发布之间无形中侵蚀质量。
agent 必须保持主题一致并拒绝不安全请求。
在 agent 周围应用带有输入、输出、主题和对话防护栏的 NeMo Guardrails。
原因: 可编程防护栏独立于模型自身的行为强制执行策略，并作为其后盾。
不可信内容可能通过检索到的或工具数据劫持 agent。
将所有外部内容视为不可信，将其与指令隔离，并限制工具权限，以防止注入的命令升级。
原因: 注入利用了 agent 的能力；防御是最小权限加上指令/数据分离。
agent 处理受管制或个人数据。
在模型调用之前编辑或标记 PII，并编写 agent 操作和工具调用的防篡改审计日志。
原因: 合规性要求既要最大限度地减少暴露，又要证明 agent 做了什么。
agent 可以执行高风险操作，如支付或删除。
在不可逆或高影响的工具调用之前插入人工审批门，暂停工作流直到确认。
原因: 对于可逆步骤，自主性是好的；而后果严重的行动需要人工参与。
agent 不确定或反复未能完成任务。
定义一个置信度/失败阈值，当达到该阈值时，将任务升级给具有完整上下文的人员，而不是进行猜测。
原因: 在风险较高的工作中，优雅的移交胜过自信的错误答案。
利益相关者不信任 agent 的输出。
显示 agent's 的推理摘要、来源和使用的工具，以便人工可以审查和推翻决策。
原因: 可解释性建立了信任，并且通常是监督和审计所必需的。