Observability Design 关注的是多智能体系统的可观测性设计。其核心理念是：看不见的东西就无法改进。通过让多智能体系统的内部运作变得可见，设计师可以理解用户体验问题，开发者可以调试失败，团队可以随时间持续改进系统。
一、需要观测的内容
该方法建议将以下方面纳入可观测范围：
- 工作流执行：涉及哪些智能体、以什么顺序执行、产生了什么结果。
- 决策点：做出了哪些决策、考虑过哪些备选方案、为什么选择其中一个。
- 交接细节：智能体之间传递了什么上下文、是否有信息丢失。
- 时间：每个智能体耗时多久、瓶颈出现在哪里。
- 失败：什么失败了、如何恢复、用户经历了什么。
- 质量信号：输出质量评分、用户满意度信号、任务成功标记。
二、面向不同受众的可观测性
针对不同角色，可观测性提供不同的视图：
面向设计师：
- 用户旅程视图：用户在整个工作流中经历了什么。
- 痛点识别：用户在哪里遇到困难、放弃或表达不满。
- 质量模式：哪些输出质量高、哪些质量低，以及原因。
面向开发者：
- 执行追踪：智能体动作的逐步日志。
- 错误日志：什么失败了、在哪里失败。
- 性能指标：延迟、吞吐量、资源使用。
面向产品经理：
- 使用模式：哪些工作流使用最多、哪些被放弃。
- 成功指标：任务完成率、用户满意度趋势。
- 成本分析：每个工作流的资源消耗。
面向用户（可选）：
- 进度指示：系统在工作流中处于什么位置。
- 智能体透明度：哪个智能体正在处理其请求。
- 审计轨迹：系统代表用户做了什么。
三、可观测性界面的设计
资料中提到的界面类型包括：
- 仪表盘：系统健康与性能的实时和历史视图。
- 追踪查看器：单个工作流执行的详细逐步视图。
- 告警系统：指标超过阈值时的通知。
- 搜索与过滤：按条件查找特定执行记录的能力。
- 对比工具：跨时间段、版本或群体比较性能。
四、避免可观测性过载
数据过多与数据过少同样糟糕。建议采用：
- 分层细节：从高层摘要开始，按需下钻。
- 智能默认：优先展示最重要的信息。
- 异常高亮：自动浮现不寻常的模式。
- 情境化视图：针对不同问题提供不同视图。
五、设计产出物
该方法涉及的设计产出物包括：
- 可观测性架构图
- 各受众的仪表盘规格
- 追踪模式定义
- 告警阈值配置
- 可观测性工具需求
关于该技能的具体安装方式、运行环境、依赖条件、收费模式、平台支持等信息，资料中暂未提供。