ThoughtWorks 技术雷达
§1摘要与结论
Thoughtworks 技术咨询委员会每年发布两次的技术快照，以技术/方法条目（blip）经四象限与四环（Adopt/Trial/Assess/Caution）组织，表达对技术采用程度的带观点推荐，并明确不追求全面、不接受厂商付费影响。
别名：ThoughtWorks Technology Radar、Thoughtworks Technology Radar、技术雷达、Technology Radar、blip、Q:S3-VEN-06、Q:S3-VEN-07、Q:S3-VEN-08 | 英文：ThoughtWorks Technology Radar | 类型：技术 / adoption-radar
§2局部关系图
§3原理 · 为什么
技术在不断变化，团队需要一种把行业经验压缩为可行动采用建议的机制。Thoughtworks Technology Radar 的价值不在于罗列全部技术，而在于提供一个有观点（opinionated）的采用视角：它把在软件开发中扮演角色的技术或方法记为 blip，用象限表示类型、用环表示推荐程度，让团队能快速了解某项技术处于应认真采用、可试用、需评估还是需谨慎的阶段。官方明确定位为不追求全面、也不对市场做完整调查，且不接受厂商付费影响收录，因此它是一种主观编辑判断而非行业标准。四环由内向外为 Adopt、Trial、Assess、Caution；进入 Trial 须已有生产使用经验，进入 Adopt 则意味着在合适情境下不用它可能是糟糕甚至不负责任的选择。
§4机制 · 如何运作
雷达以两个维度组织：四象限（Techniques 技术/方法、Platforms 平台、Tools 工具、Languages and Frameworks 语言与框架）表示 blip 的类型，官方称其仅为话题切分方式、重要性低于环；四环表示采用推荐程度，其中 Adopt 为成熟且被证实、适当情境下应认真考虑，Trial 为可用于生产但验证不如 Adopt 充分、须在可承担风险的项目试用，Assess 为值得关注探索但尚不宜试用，Caution 表示行业可能已接受但存在重大顾虑、须结合具体情境审慎评估。blip 默认只保留一期，除非在环间移动，旧条目虽存于归档但不再更新。第四环在 Vol 33（2025-11）及更早名为 Hold，Vol 34（2026-04）更名为 Caution。环位并非评分，也不代表技术优劣排序：它只表达在当前语境下的采用建议，且每期的判断都可能随团队经验与生态变化而调整。
§5工程 · 怎么落地
落地时建议把雷达作为技术选型的输入而非结论：先识别团队当前关注的技术，查其在最新一期的环位与条目说明，再结合自身语境判断是否采用；引用时必须注明期号与日期，因为 blip 生命周期短、环位会移动。可把雷达条目与团队的技术选型记录、技术债台账、ADR 联动，对进入 Caution 的既有技术制定替换或隔离计划。建立定期复核机制（随每期发布），避免把某一期的推荐固化为长期规范。对于跨团队或跨组织的采用决策，应把雷达的观点与内部试点、量化评估结合，防止盲目跟随。对已进入 Adopt 的技术，仍须理解其适用情境与迁移成本，避免把采用建议直接当作强制标准；对 Caution 条目则应记录具体顾虑，作为替换或隔离决策的输入。
§6权衡卡
- 雷达是咨询机构的带观点快照，不是中立标准，也不追求完整性：未被收录不代表技术不好，被收录也不代表必然适合本团队。
- 它的时效性很强，blip 默认一期即退、环位频繁移动，若把某期结论当作长期定义会造成误导。
- 四环的推荐基于 Thoughtworks 在客户项目中的经验，可能与特定组织的约束、合规或规模不匹配，不能替代内部试点与量化评估。
- 第四环的名称与语义在版本间也会变化（Hold 更名 Caution），引用时须核对版本。
- 因此应把雷达用于拓宽视野与发现候选，而不是替代技术选型的够用原则与基于场景的验证；同类第三方评估可能与其结论不同，应交叉参照。
- 最后，雷达的结论来自特定咨询机构的客户经验，样本与偏见无法完全避免，把它与内部试点数据、社区反馈和厂商文档交叉验证，才能降低单一视角带来的判断偏差。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | ThoughtWorks 技术雷达 | Azure 架构中心 |
|---|---|---|
| 定位 / 依据层 | ThoughtWorks 技术雷达 · ThoughtWorks Technology Radar | Azure 架构中心 · Azure Architecture Center |
| 核心定义（原文） | Thoughtworks 技术咨询委员会每年发布两次的技术快照，以技术/方法条目（blip）经四象限与四环（Adopt/Trial/Assess/Caution）组织，表达对技术采用程度的带观点推荐，并明确不追求全面、不接受厂商付费影响。 | Microsoft 维护的 Azure 架构中心，汇集云架构风格目录（N 层、微服务、事件驱动等，含适用性、收益与挑战）与安全部署实践，指导按业务驱动与非功能需求选择风格并安全发布变更。 |
| 首条机制断言（原文） | 技术在不断变化，团队需要一种把行业经验压缩为可行动采用建议的机制。 | 架构风格是对设计的约束——它规定系统可出现哪些元素以及元素间允许的关系，因而会直接放大或削弱特定的质量属性。 |
| 对照关系 | Azure 稳定工程清单对照雷达时效快照（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 雷达是咨询机构的带观点快照，不是中立标准，也不追求完整性：未被收录不代表技术不好，被收录也不代表必然适合本团队。 | 另一个常见误区是把风格目录当作设计起点而非决策工具：真正的起点是业务驱动与质量属性，风格只是满足约束的候选手段之一。 |
| 处置要点（原文） | 落地时建议把雷达作为技术选型的输入而非结论：先识别团队当前关注的技术，查其在最新一期的环位与条目说明，再结合自身语境判断是否采用；引用时必须注明期号与日期，因为 blip 生命周期短、环位会移动。 | 落地时建议：先用业务驱动与非功能需求排序确定候选风格，再逐风格核对依赖管理方式与适用领域，避免为架构纯洁强行套用微服务等高复杂度风格；把每种风格的挑战显式写入 ADR 与风险清单；对已选风格在子域或 bounded context 内局部调整，允许异构组合。 |
§8案例带
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
控制理论⊗Agent 设计
将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。
§9信源与核验
核验结论：Vol 33（2025-11）及更早第四环名为 Hold（Proceed with caution），Vol 34（2026-04）更名并改述为 Caution（Proceed with care）；Adopt/Trial/Assess/Hold 表述已过时 [VEN-008]
核验结论：官方明确定位为有观点的技术全景指南，不追求全面、不接受厂商付费影响；blip 生命周期短、时效性强，属咨询机构的主观编辑判断 [VEN-006]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 案例印证 | ← CAS-X-12 | MCP 四件套选型对比 E-17 | 印证：带观点的分级接入推荐，与雷达四环同构 |
| 组合 | ← TEC-G-03 | Azure 架构中心 E-890 | 风格目录与技术雷达组合用于技术选型 |
| 对照 | ← TEC-G-03 | Azure 架构中心 E-888 | Azure 稳定工程清单对照雷达时效快照 |
| 实现 | → MTH-O-03 | 技术选型的够用原则 E-885 | 技术雷达采用环支撑技术选型够用原则 |