技术

持续合规 是通过自动化确保软件开发过程和技术持续满足监管和安全标准的实践。手动合规检查可能会减缓开发速度并引入人为错误，而自动化检查和审计提供更快的反馈、更清晰的证据和简化的报告。 通过集成安全策略即代码工具（如 Open Policy Agent）并在 CD 管道中生成 SBOM——与 SLSA 指导保持一致——团队可以及早发现和解决合规问题。将规则和最佳实践编码化可以在不造成瓶颈的情况下，在团队间一致地执行标准。开放安全控制评估语言(OSCAL) 也显示出作为大规模自动化合规框架的前景。 持续合规的实践和工具现在已经足够成熟，应该被视为合理的默认选择，因此我们将推荐级别提升至“采纳”。AI 在编码中日益增多的使用——以及随之而来的对 AI 生成代码的自满风险，使得将合规性融入开发流程比以往任何时候都更加重要。

对于积极在软件交付中使用 AI 的团队，下一步是超越个人提示词，转向为软件团队精选共享指令。此做法通过分享经过验证的高质量指令，让你能够将 AI 高效地运用于所有交付任务——而不仅仅是编码。最直接的实现方式，是像提交 AGENTS.md 之类的指令文件一样，将它们直接纳入项目仓库。大多数 AI 编码工具——包括 Cursor、Windsurf 和 Claude Code——都支持通过自定义斜杠命令或工作流共享指令。对于非编码任务，你可以建立开箱即用的组织级提示词库。这种系统化方法便于持续改进：每当有提示词被优化，全体成员都可受益，从而确保大家始终使用最佳的 AI 指令。

Git hooks 已经存在很长一段时间了，但我们认为它们仍然被低估和未充分使用。随着 AI 辅助编码和自主智能编程的兴起，意外提交机密信息或有问题代码的风险有所增加。虽然已有许多代码验证机制，例如 持续集成，但 pre-commit hooks 是一种简单且有效的防护措施，值得更多团队采用。不过，如果在 hooks 中加入运行缓慢的检查任务，可能会让开发者不愿意使用它们。因此，最好的做法是让这些 hooks 保持精简，专注于那些在此阶段最有效检测的风险，例如密钥扫描。

在最近几个月里，我们已经看到明确的证据表明 使用生成式 AI 来理解遗留代码库 可以显著加速对大型复杂系统的理解。诸如 Cursor、Claude Code、Copilot、Windsurf、Aider、Cody、Swimm、Unblocked 和 PocketFlow-Tutorial-Codebase-Knowledge 等工具帮助开发者发现业务规则、总结逻辑并识别依赖关系。它们与开放框架和直接结合LLM提示词一起使用，大大减少了理解遗留代码库所需的时间。 我们在多个客户中的经验表明，借助 GenAI 辅助理解遗留系统如今已成为一种实用的默认方案，而非实验性质。设置工作量因方法而异，特别是对于 GraphRAG 等高级方法，并且往往与正在分析的代码库的大小和复杂性成比例。尽管如此，其对生产力的影响是持续且显著的。生成式 AI 已经成为我们探索和理解遗留系统方式的重要组成。

AGENTS.md 是一个为 AI 编码智能体在项目中提供操作指引的通用格式。本质上，它相当于面向智能体的 README 文件，除 Markdown 格式外没有强制的字段或特定格式，完全依赖于基于 LLM 的编码代理能够理解人类编写的、易于理解的指导。典型用法包括：如何使用编码环境中的工具、测试说明以及管理提交的最佳实践建议。虽然 AI 工具支持多种上下文工程方法，但 AGENTS.md 的价值在于创建了一个简单的文件规范作为起点。

代码迁移的形式多种多样，从语言重写到依赖项或框架升级，几乎都不是一件小事，往往需要数月的人力投入。我们有一个团队在升级 .NET 框架版本时，尝试用 AI 缩短这一流程。过去，我们曾推荐 OpenRewrite 这类确定性、基于规则的重构工具。单靠 AI 自动升级通常代价高昂，且易陷入无效对话。于是，团队把传统升级流水线与智能编码助手结合，推进复杂的转型。区别于全程交由 AI 升级，他们将流程细化为可验证的小步骤：分析编译错误、生成迁移差异、反复验证测试。这种混合方法让 AI 编码智能体成为软件维护中的实用协作者。业界案例，如 Google 的大规模 int32 到 int64 迁移，也展现出同样趋势。尽管这一实践在节省时间方面结果好坏参半，但减少开发者重复劳动的潜力十分明显，值得持续探索。

Liquid clustering 是 Delta Lake 表的一种可作为分区和 Z 排序的替代方案的技术。在过去，优化 Delta 表的读取性能需要在表创建时基于预期的查询模式定义分区和 Z 排序键。后续修改这些键需要完整的数据重写。相比之下，聚类采用基于树的算法根据指定的键对数据进行聚类，可以增量更改而无需重写所有数据。这提供了更大的灵活性来支持多样化的查询模式，从而降低计算成本并增强读取性能。此外，Delta Lake 的 Databricks Runtime 通过分析历史查询工作负载、识别最优列并相应地聚类数据来支持自动 liquid clustering。独立的 Delta Lake 和 Databricks Runtime 用户都可以利用 liquid clustering 来优化读取性能。

我们使用术语 使用 GenAI 的自助式 UI 原型设计 来描述一种新兴技术，其中工具如 Claude Code、Figma Make、Miro AI 和 v0 使产品经理能够直接通过文本提示生成交互式、可供用户测试的原型。团队无需手动绘制线框图，即可在几分钟内生成可运行的 HTML、CSS 和 JS 工件——具备草图般的速度，却拥有真实的交互性和更高的保真度。这些“一次性”原型以快速学习为目的，牺牲了精细度，非常适合在设计冲刺的早期验证阶段使用。然而，较高的保真度可能导致团队过度关注细节或对上线所需工作量产生不切实际的期望——因此，明确的目标设定与期望管理至关重要。 当与用户研究结合使用时，该技术能通过将抽象想法转化为可感知的体验来加速探索过程。然而，团队应谨慎，避免让这些工具取代研究过程本身。如果运用得当，自助式原型设计能缩短反馈循环、降低非设计人员的参与门槛，并帮助团队在速度与质量之间实现健康平衡。

从LLMs获取结构化输出 是指通过对大语言模型进行约束，使其输出符合预定义格式（如 JSON 或特定的编程类）。这一技术对构建可靠、生产级应用至关重要，它能将 LLM 通常不可预测的文本转化为机器可读、确定性的数据契约。基于我们的生产实践成果，我们将该技术从“评估”阶段提升为“试用”阶段。 相关方法覆盖从简单的提示词格式化、模型原生结构化输出，到更为健壮、借助 Outlines 和 Instructor 等工具实现的约束解码方式，这些工具通常通过有限状态机来确保输出的合法性。我们已经成功运用这一技术，从各类文档中提取复杂的非结构化数据并转换为结构化的 JSON，以便后续业务逻辑处理。

测试 Test && 提交 Commit || 回退 Revert（TCR）是一种源自测试驱动开发的编程工作流，通过一个简单规则促进非常小的、连续的步骤：每次修改后，如果测试通过，则提交更改；如果测试未通过，则回退更改。实现 TCR 非常直接：只需定义一个脚本，在代码库中自动执行此循环。TCR 最初由 Kent Beck 在一篇经典 文章 中提出。我们发现 TCR 强化了诸如 YAGNI 和 KISS 等积极的编码实践。在我们尝试使用生成式 AI 构建软件的新工作流时，这值得评估。

在上一期技术雷达中，AI 驱动的 UI 测试 主要集中于探索性测试，我们当时指出 LLM 的非确定性可能会引入不稳定性。随着 MCP 的兴起，我们看到主流的 UI 测试框架如 Playwright 和 Selenium 正在引入各自的 MCP 服务器（playwright-mcp、mcp-selenium）。这些服务器通过其原生技术提供可靠的浏览器自动化，使编码助手能够在 Playwright 或 Selenium 中生成更可靠的 UI 测试。尽管 AI 驱动的 UI 测试仍是一个快速演进的领域——例如最新版本的 Playwright 已引入 Playwright Agents——但我们对这些进展感到振奋，并期待看到更多实践经验与落地指南的出现。

过去我们曾在雷达上提到过定制服务模板模式，该模式通过提供合理的默认值来引导新服务并与现有基础设施无缝集成，帮助组织部署微服务。然而，随着时间的推移，随着新依赖项、框架和架构模式的出现，这些模板与现有服务之间的代码漂移往往会增长。为了保持良好的实践和架构一致性——特别是在编码智能体团队时代——我们一直在试验将编码智能体锚定到参考应用。这种模式通过提供实时的、可编译的参考应用而不是静态提示示例来指导生成式代码智能体。模型上下文协议（MCP）服务器暴露参考模板代码和提交差异，使智能体能够检测漂移并提出修复建议。这种方法将静态模板转换为 AI 可以智能引用的活的、适应性强的蓝图——在系统演进过程中保持一致性、减少分歧并改善对 AI 驱动脚手架的控制。

上下文工程 是在推理过程中，对提供给大语言模型的信息进行系统性设计与优化，以稳定可靠地产出期望结果。它涉及对上下文要素的结构化、选择与编排——例如提示词、检索数据、记忆、指令以及环境信号——以便让模型的内部层处于最优状态。不同于只关注提示措辞的提示工程，上下文工程关注的是上下文的整体配置：即如何组织与传递相关知识、指令以及先前上下文，以实现最有效的结果。 当下，工程师采用的多种不同技术大体可分为三个方面：上下文设置 涵盖诸如使用最小系统提示词、规范的少样本示例以及令牌高效的工具等策略，用于决定性行动。针对长周期任务的上下文管理 通过上下文摘要 和 结构化笔记 来持久化长期记忆，并通过子代理架构 来隔离和总结复杂的子任务，从而应对有限的上下文窗口。动态信息检索 依赖于即时（JIT）上下文检索，其中智能体仅在需要时才自主加载外部数据，从而最大化效率与准确性。

用于前向工程的生成式 AI 是一种新兴技术，通过 AI 生成的遗留代码库描述来现代化遗留系统。它引入了一个明确步骤，专注于遗留代码做了什么（即其规格说明），同时刻意隐藏当前的实现方式。这与 规范驱动开发 相关，但特别应用于遗留系统的现代化。 通过在重写代码之前生成和迭代功能描述，团队可以利用生成式 AI 揭示隐藏的逻辑、依赖关系和可能被忽略的边界情况。强调问题空间而非现有系统，也允许生成式 AI 模型探索更具创造性和前瞻性的解决方案。该工作流遵循反向工程 → 设计/解决方案 → 前向工程的循环，使人类和 AI 智能体在提交实现前能够在更高层次进行推理。 在 Thoughtworks，我们看到多个团队成功应用这一方法来加速遗留系统的重写。其目标并非完全隐藏实现细节，而是引入一个临时抽象，帮助团队和智能体在不受现有结构限制的情况下探索替代方案。这一技术在生成更清晰、更易维护和面向未来的代码方面显示出良好前景，同时也减少了理解现有实现所需的时间。

将 GraphQL 作为 LLM 的数据访问模式 是一种新兴方法，用于创建统一、适合模型的数据访问层，从而增强上下文工程。它使团队能够暴露结构化、可查询的数据，而无需授予模型直接访问数据库的权限。与通常会过度获取数据或需要为每个用例创建新端点或过滤器的 REST API 不同，GraphQL 允许模型仅获取所需数据——减少噪音、提高上下文相关性并降低 token 使用量。 定义良好的 GraphQL 架构还提供元数据，使 LLM 能够推理可用实体和关系，从而支持智能体用例的动态、架构感知查询。这种模式在 REST 与 SQL 之间提供了安全的中间方案，在治理控制与灵活访问之间取得平衡。 然而，该方法依赖于结构良好的架构和有意义的字段名称。解释架构语义和处理复杂结构仍然具有挑战性——对人类难以推理的内容通常对 LLM 也同样困难。同时，需要注意增加的 DoS 攻击向量，以及 GraphQL 常见挑战，如缓存和版本管理。

我们经常被问到一个问题：“如何改进团队之间的信息共享方式？” 管理组织知识的技术在不断演进，我们发现一个借鉴自系统思维的有价值视角：知识流量与知识存量。这一框架源自经济学，鼓励团队将组织知识视为一个系统——存量代表累积的知识，流量代表知识在组织中如何流动与演化。增加外部知识流入往往会提升创新。一种经受时间考验的提升流动性的方式是建立实践社区，它一贯显示出可量化的收益。另一种方法是有意识地寻求多样化的外部洞见来源。随着生成式 AI 工具让现有的知识存量更易获取，我们需要记住，培育新思想和外部视角与采用新技术同样关键。

使用 LLM 作为评审——评估另一个系统（通常是基于 LLM 的生成器）的输出——因其在生成式 AI 中提供可扩展、自动化评估的潜力而备受关注。然而，为了反映新近发现的复杂性和风险，我们将此讨论从“试验”阶段移至“评估”阶段。 尽管该技术提供速度和规模，但它常常无法作为人类判断的可靠代理。评估容易受到位置偏差、冗长偏差和低稳健性影响。更严重的问题是 规模污染：当LLM作为评判者用于奖励建模的训练流程时，它会引入自我增强偏差（即模型族倾向于自身的输出）和偏好泄漏，从而模糊训练和测试之间的界限。这些缺陷导致过拟合结果，使性能指标虚高但缺乏现实有效性。已有 研究 对这一模式进行了更严格的调查。为应对这些缺陷，我们正在探索改进技术，例如使用 LLM 作为陪审团（通过多个模型达成共识）或在评估过程中使用链式思维推理。尽管这些方法旨在提高可靠性，但也增加了成本和复杂性。我们建议团队谨慎对待此技术——在将 LLM 评审用于关键工作流前，确保有人类验证、透明性和伦理监管。该方法仍然有效，但不如之前认为的那样成熟。

设备端信息检索 是一种使搜索、上下文感知和检索增强生成（RAG）能够完全在用户设备上运行——譬如移动设备、桌面设备或边缘设备，并优先考虑隐私和计算效率的技术。它将轻量级本地数据库与针对设备端推理优化的模型相结合。一个有前景的实现是将 sqlite-vec（一个支持嵌入式数据库内向量搜索的 SQLite 扩展）与 EmbeddingGemma（一个基于 Gemma 3 架构构建的 3 亿参数嵌入模型）进行配对。这种组合针对效率和资源受限环境进行了优化，将数据保持在边缘附近，从而减少对云 API 的依赖，并改善延迟和隐私。我们建议团队评估这种技术用于本地优先应用和其他数据主权、低延迟和隐私至关重要的场景。

SAIF（Secure AI Framework，安全 AI 框架）是由 Google 开发的一套框架，旨在为管理 AI 安全风险提供实用指南。它通过清晰的风险地图、组件分析和可操作的缓解策略，系统性地应对常见威胁，如数据投毒和提示注入。我们认为，SAIF 对构建智能体系统过程中不断演变的风险的关注，恰逢其时且极具价值。SAIF 提供了一份简明且可执行的操作手册，帮助团队强化 LLM 使用及 AI 驱动应用的安全实践。

随着基于 sidecar 的服务网格在成本和运维复杂性方面的持续存在，我们很高兴看到另一种 无边车服务网格（Service mesh without sidecar） 方案的出现：Istio ambient 模式。Ambient 模式引入了一种分层架构，将职责划分为两个关键组件：每个节点的 L4 代理（ztunnel）和每个命名空间的 L7 代理（Waypoint proxy）。ztunnel 确保 L3 和 L4 流量能够高效且安全地传输。它通过为所有节点身份获取证书并处理往返于启用 Ambient 模式工作负载的流量重定向，从而支撑整个 Ambient 数据平面。Waypoint proxy 是一个可选的 Ambient 模式组件，可启用更丰富的 Istio 功能，如流量管理、安全性和可观测性。我们在小规模集群中已经获得了良好的使用体验，并期待随着采用的增长，能在大规模集群中获得更多实践洞察和最佳实践。

我们观察到 小语言模型 (SLMs) 在多个版本的科技雷达中稳步发展。随着对构建智能体解决方案的兴趣不断增长，我们看到了越来越多的证据表明 SLMs 可以高效地支持智能体 AI。目前大多数智能体工作流都集中在狭窄、重复的任务上，不需要高级推理，这使得它们与 SLMs 非常匹配。SLMs 的持续进展，如 Phi-3、SmolLM2 和 DeepSeek，表明 SLMs 在这些任务中提供了足够的功能——与 LLMs 相比，具有更低成本、更低延迟和更低资源消耗的好处。值得考虑 SLMs 作为智能体工作流的默认选择，只在必要时保留更大、更资源密集的 LLMs。

规范驱动开发（Spec-driven development) 是 AI 辅助编码流程中的一种新兴方法。虽然该术语的定义仍在不断演化，但一般而言，它指的是以结构化的功能规范为起点的开发流程，随后通过多个步骤将规范拆解为更小的部分、方案和任务。规范本身可以有多种形式：可以是一份文档、一组文档，或是以结构化工件捕捉不同功能方面的信息。 我们看到许多开发者已经采用了这种风格（我们在 Thoughtworks 也有一套内部分享的规范）。最近有三款工具分别探索了规范驱动开发的不同实现方式：亚马逊的 Kiro 引导用户经历三个工作流阶段——需求、设计和任务创建；GitHub 的 spec-kit 也采用了类似的三步过程，但增加了更丰富的编排、可配置的提示词以及一份“宪章”，定义了始终必须遵循的不可变原则；Tessl Framework（截至 2025 年 9 月仍处于内测阶段）则采纳了一种更为激进的方式，将规范本身而非代码作为维护对象。 我们认为这一领域极具吸引力，尽管目前的开发流程依然较为繁琐且带有很强的主观性。这些工具的行为因任务的规模和类型而迥异：有些工具会生成冗长难以审阅的规范文件；当它们产出 PRD 或用户故事时，有时也不清楚目标受众是谁。我们也许正在重蹈惨痛教训——为人工智能手工编写详细的规则最终无法实现规模化。

编码智能体团队 指的是开发者协同编排多个具备不同角色的 AI 编码智能体（例如架构师、后端专家、测试人员等）共同完成开发任务的一种技术实践。这一做法已被 Claude Code、Roo Code、Kilo Code 等工具支持，它们提供了子代理（subagents）机制和多种运行模式。基于给大型语言模型（LLM）分配具体角色和身份能够提升输出质量的成熟理念，该方法旨在通过协调多个具备特定职能的智能体（而非依赖单一通用型智能体）以获得更佳的开发成果。当前，最优的智能体角色划分方式仍在探索中；这种方法甚至可以突破传统团队角色的一对一映射。这一思路标志着业界正向更加可编排、细致分工的多步骤 AI 辅助开发流程转变。

GPU 和 LPU 不再是独立设备，而是紧密耦合的加速器网络，其性能取决于放置位置和拓扑。在 NVIDIA 的 NVL72 等机架级系统中，72 个 GPU 共享超过 13 TB 的显存，并作为单一加速器运行——直到工作负载跨交换机网络，集体操作才会成为瓶颈。类似地，Groq 的编译时、软件调度架构假设数据移动是确定性的；随机调度会破坏这些假设和可预测性。即便在同一数据中心内，GPU 性能也可能存在显著差异，这就产生了对拓扑感知调度的需求，在作业放置时同时考虑硬件布局和性能波动。 忽略 NVLink、PCIe 或 NIC 拓扑的简单调度器，往往会随意分散多 GPU 工作负载，导致步骤时间和效率下降。训练工作负载是同步且带宽受限的，更适合在连续的 NVLink 网络上调度，确保所有 reduce 和流水线阶段拥有统一、高带宽路径。这些作业应基于互连带宽进行协同调度，避免跨交换机跳转，并将链路、交换机和节点边界视为故障域。相比之下，推理工作负载受延迟和 SLO 限制，通常在跨域高可用复制与分片之间平衡，以保持专家混合（MoE）和 KV 缓存的局部性在最短路径上。针对预填充与解码阶段、微批处理以及租户隔离优化放置，可进一步提升效率。我们认为，随着加速器性能越来越依赖网络和数据中心拓扑，拓扑感知调度将成为必需。我们的团队已在评估 Kueue 及相关项目，以提高放置精度、提升性能并确保客户的可靠扩展。

现在广为流传的玩笑——MCP 中的 S 代表“安全”——代表了一个非常真实的问题。当智能体通过工具调用或 API 调用彼此通信时，它们可能很快遭遇被称为致命三威胁的情况：访问私有数据、接触不可信内容，以及能够进行外部通信。具备这三项的智能体极易受到攻击。由于 LLM 倾向于遵循输入中的指令，包含向不可信源导出数据指令的内容很容易导致数据泄露。一种新兴的缓解风险技术是 有害流程分析，它通过检查智能体系统的流程图来识别潜在不安全的数据路径，以便进一步调查。虽然仍处于早期阶段，但有害流程分析代表了若干有前景的方法之一，用于检测智能体系统和 MCP 服务器日益暴露的新攻击向量。

AI 正在降低非专业开发人员自行构建和集成软件的门槛，使他们无需等待 IT 部门响应自己的需求。尽管我们对这种技术带来的潜力感到兴奋，但同时也开始关注到 AI 加速影子 IT（AI-accelerated Shadow IT） 的初步迹象。一些无代码（No-code）工作流自动化平台已支持对 AI API（如 OpenAI 或 Anthropic）的集成，这使得用户可能倾向于将 AI 用作“胶带”，将此前难以实现的系统集成临时拼凑起来，例如通过 AI 将聊天消息转换为 ERP 系统的 API 调用。同时，越来越多具有自主 Agent 能力的 AI 编码助手，甚至允许仅经过基础培训的非技术人员创建内部工具应用。

这些迹象呈现出类似于电子表格（Spreadsheets）当年迅速扩散的特征：虽然为企业关键流程提供了快速解决方案，但在长期运行后往往会造成规模更大的技术债（Tech Debt）。如果不加管控，这种新型影子 IT 将导致未经治理的应用程序激增，安全隐患加剧，数据分散在不同系统内。我们建议企业对此风险保持警觉，并谨慎评估快速问题解决与长期技术稳定性之间的平衡与取舍。

现代软件开发实践成功的关键在于保持对工作流的关注。流对齐团队专注于单一、有价值的工作流——例如一个用户旅程或产品——从而能够高效地交付端到端价值。然而，我们注意到一个令人担忧的趋势，即出现了 容量驱动开发（Capacity-driven development）。在这种模式下，这些团队在有空余产能时，会接手来自其他产品或工作流的功能开发。虽然这在短期内看似高效，但实际上是一种局部优化，仅适用于应对突发的需求高峰。当这种做法被常态化后，会增加认知负荷和技术债务；在最糟糕的情况下，随着跨产品上下文切换的成本不断累积，可能导致整体的拥塞崩溃。拥有空余产能的团队更应专注于提升系统健康度。为了更有效地管理产能，可以通过设置 WIP 限制来控制相邻工作流之间的工作量；在高需求时期考虑跨技能培训；并在必要时采用动态重组团队等技术手段。

我们看到诸多数据与研究表明，随着 AI 编码助手和智能体的普及，人们对 自满于 AI 生成的代码 的担忧也在加剧。尽管有充分证据显示，这类工具可显著加快开发速度——尤其是在原型开发和全新项目场景中——但研究结果也表明，随着时间推移，代码质量可能会出现下降。 GitClear 2024 年的研究发现，重复代码和代码的反复变动比预期增长更多，而提交历史中的重构活动则有所下降。类似趋势也出现在微软研究中：知识型员工因 AI 助手而增强的自信，往往以批判性思维能力下降为代价——我们也注意到，长期使用编码助手后容易出现惰性和过度依赖的现象。 随着编码智能体推动更大范围的自动化变更，这一风险也被放大，因为由 AI 生成的更大代码变更集更加难以评审。正如任何系统一样，流水线中的某一环提速后，其他环节的压力也会随之增加。我们的团队发现，要在生产环境中高效安全地使用 AI，必须重新关注和强化代码质量。我们建议继续落实如 TDD（测试驱动开发）和静态分析等成熟实践，并将这些措施直接集成进开发流程，例如通过为软件团队精选共享指令等方式实现。

许多组织都希望让 AI 智能体能够与现有系统交互，常见的做法是尝试将内部 API 直接无缝转换为 模型上下文协议（MCP）。越来越多的工具，如 MCP link 和 FastAPI-MCP，都在支持这种转换。 然而我们并不建议直接进行这种天真的API到MCP转换。API 通常是为人类开发者设计的，往往包含许多细粒度、原子性的操作；如果让 AI 代理串联调用这些操作，可能会导致Token过度消耗、上下文污染，以及智能体性能下降。此外，这些 API（尤其是内部接口）常常会暴露敏感数据或允许执行危险操作。对于人类开发者，此类风险可以通过架构模式和代码审核来缓解，但如果将 API 直接暴露给通过 MCP 协议集成的智能体，则无法可靠地阻止自治 AI 智能体误用这些接口。因此，我们建议针对智能体工作流，专门设计并构建安全的 MCP 服务器架构，在现有 API 基础上进行适配。

组织独立数据工程团队来开发和拥有数据管道和产品——与它们服务的流对齐业务域分离——是一种会导致效率低下和业务成果薄弱的反模式。这种结构重复了过去隔离 DevOps、测试 或 部署 功能的错误，创造了知识孤岛、瓶颈和浪费的精力。若没有密切协作，数据工程师往往缺乏设计有意义的数据产品所需的业务和领域上下文，限制了采用的可能性和价值。相比之下，数据平台团队应该专注于维护共享基础设施，而由跨职能业务团队遵循数据网格原则构建和落地他们的数据产品。我们将这种做法置于“暂缓”状态，旨在劝退各自为政的组织模式——尤其是在对领域信息丰富、可用于人工智能的数据的需求持续增长的情况下。

Text to SQL 利用大语言模型（LLM）将自然语言翻译为可执行的 SQL，但其可靠性往往低于预期。我们已将此技术的状态调整为 “Hold”，以劝阻在无人监督的工作流中使用——例如，动态转换用户生成的查询，而输出结果被隐藏或自动化。在这些情况下，LLM 由于对数据库模式或领域理解有限，常常会产生幻觉，导致错误的数据检索甚至意外的数据修改。此外，LLM 输出的非确定性特征也使得调试和审计错误变得更加困难。 我们建议Text to SQL，并要求对所有生成的查询进行人工审核。对于智能化商业分析场景，应避免直接访问数据库，而应通过受治理的数据抽象语义层来实现，例如 Cube 或 dbt 的语义层；或者使用具有更强语义表达能力的访问层，如GraphQL 或 MCP。