title: “One Three One Rule — 1-3-1 decision briefs: problem, three options, one pick” sidebar_label: “One Three One Rule” description: “1-3-1 decision briefs: problem, three options, one pick”

{/* 本页面由 website/scripts/generate-skill-docs.py 根据技能对应的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}

1-3-1 规则

1-3-1 决策简报：明确问题、提供三种方案，并选定一个最优解。

技能元数据

参考：完整 SKILL.md 内容

:::info 以下是当触发该技能时 Hermes 会加载的完整技能定义。当技能处于激活状态时，智能体将依据此内容执行操作。

::

1-3-1 沟通规则

这是一种结构化的决策框架，适用于面对具有多种可行方案的任务且用户需要明确建议的场景。它能够清晰地阐述问题、列出三种带有利弊分析的选项，并为所推荐的方案提供可操作的行动计划。

适用场景

• 用户明确要求获得“1-3-1”格式的回复。
• 用户在面临技术决策时请求“列出可选方案”或“告诉我有哪些选择”。
• 某项任务存在多种可行方案，且各方案之间存在显著的权衡因素（如架构设计、工具选型、迁移策略等）。
• 用户需要一份可转发给团队或利益相关方的建议方案。 请勿将此流程用于那些答案显而易见的简单问题、调试环节，或是用户已确定解决方案的任务。

操作步骤

1. 问题描述（一句话）

   • 用一句简洁的话明确核心决策或期望达成的结果。
   • 重点描述“做什么”，而非“怎么做”——无需提及实现细节、工具名称或具体技术。
   • 表述要简明扼要。如果需要使用“和”字，说明你实际上是在描述两个问题。

2. 可选方案（恰好三个）

   • 列出三种不同的可行方案，分别标记为A、B、C。
   • 每个方案需附有简要描述、优点及缺点。
   • 这些方案应是真正不同的策略，而非同一方法的不同变体。

3. 推荐方案（一个选项）

   • 根据用户的实际情况和优先级，说明你推荐的方案及其理由。
   • 表达要直接——这是你的专业判断，无需含糊其辞。

4. 完成标准

   • 列出所推荐方案的具体成功标准。
   • 这些应是具体且可验证的结果，而非模糊的期望。
   • 若用户选择其他方案，需相应修改此部分内容。

5. 实施计划

   • 执行所推荐方案的具体步骤。
   • 如有必要，需包含具体的命令、工具或操作内容。
   • 若用户选择其他方案，需相应修改此部分内容。

验证方式

• 响应中仅包含一个问题描述句。
• 响应中恰好包含三个选项（A、B、C），每个选项均需列出其优缺点。
• 响应中需给出一项推荐意见，明确选定其中一个选项并说明理由。
• “完成标准”与“实施计划”需与所推荐的选项保持一致。
• 若用户选择其他选项，则推荐意见、“完成标准”及“实施计划”均需相应调整。

示例

用户：“请为我提供一种为 API 客户端添加重试逻辑的 1-3-1 方案。”

智能体回复：

问题： 在高负载情况下，对外部服务的 API 调用会间歇性失败，需要实现优雅的重试机制。

选项：

• 选项 A：在共享工具中采用带抖动机制的指数退避策略。
  优点：方案简单且易于理解；只需实现一次，所有调用方均可复用。
  缺点：不支持断路保护；调用方在重试过程中仍会阻塞。

• 选项 B：在每个接口调用上使用重试库（如 tenacity）作为装饰器。
  优点：可针对每个接口单独配置；内置断路保护和速率限制功能。
  缺点：会增加依赖项；装饰器模式可能会使控制流程变得复杂。

• 选项 C：基于队列的异步重试机制，并配有死信处理功能。
  优点：非阻塞式处理；可追踪失败调用并重新执行；具备良好的扩展性。
  缺点：复杂度显著提升；需要队列后端支持；对于调用量较低的服务而言属于过度设计。

推荐意见： 选择选项 A。当前的调用量无需引入队列架构，而通过共享工具结合指数退避与抖动机制即可有效处理故障，且不会增加新的依赖项。

完成标准：

• api_retry() 工具用于处理短暂的 HTTP 错误（如 429、502、503、504 状态码）。
• 它会以指数退避策略并加入随机抖动，最多尝试重试 3 次。
• 所有的外部 API 调用都会通过该重试工具进行处理。
• 每次重试尝试都会被记录下来，包括对应的接口地址及尝试次数。
• 测试案例涵盖了重试次数耗尽、立即成功以及先出现短暂错误后再成功的各种场景。

实施计划：

1. 创建 utils/api_retry.py 文件，其中可配置最大重试次数、基础延迟时间以及支持重试的状态码列表。
2. 通过使用 random.uniform(0, base_delay) 实现随机抖动，以避免大量请求同时发起造成的冲击。
3. 在 api_client.py 中将现有的 API 调用用该重试工具封装起来。
4. 为每种重试场景编写单元测试，使用模拟对象来模拟 HTTP 响应。
5. 通过针对不稳定接口的简单压力测试，验证系统在高负载下的表现。