分类： AI技术架构

发布于

氛围编程：IT领导者须知

执行摘要

  • 氛围编程能加速开发与创新，但企业高管必须加强治理、安全与审查流程以保护业务。
  • 团队能快速测试想法并交付最小可行产品，从而缩短上市时间并提升对业务需求的响应能力。
  • 开发人员与非技术人员能更高效地协作，降低入门门槛并促进创新。

想象一下，您可以通过摩擦一盏神灯，用简单直白的语言向精灵描述您的需求，它就能为您生成一个功能齐全的应用程序。虽然神灯并不存在，但AI编程助手在很大程度上实现了这个愿望——无论其影响是好是坏。借助大语言模型，开发人员可以输入自然语言提示，并生成任何编程语言的代码。OpenAI联合创始人安德烈·卡帕西在2025年创造了"氛围编程"一词，用以描述"完全沉浸在感觉中，拥抱指数级增长，甚至忘记代码本身的存在"。

这种新范式标志着从深思熟虑、逐行编写代码，转向更流畅、更直观的人机意图与执行之间的协作。

氛围编程并非要取代开发人员，而是一种加速数字化转型的战略推动器，它能提高生产率，并且是打造快速上市工具的一种经济高效的选择。然而，IT高管必须将治理与赋能相结合，以最大化其价值，同时控制氛围编程带来的风险。

氛围编程如何运作？

开发人员首先选择一个AI编程助手，并描述他们想要的功能或特性。接着，AI会回应代码建议，开发人员可以审查、接受或优化这些建议。然后，开发人员继续迭代，通过向AI发出具体指令来添加新功能或进行调整，从而创建一个动态的、对话式的工作流程。

氛围编程 vs. 传统编程

传统上，编程过程非常结构化和有条不紊，而氛围编程描述的则是一种更具创造性或基于流程的方法。以下是这两种方法差异的细目分类：

氛围编程 传统编程
语言 自然语言 编程语言
焦点 宏观大局 / "感觉" 细节导向
审查流程 信任AI 同行代码审查
界面 AI代理 键入代码 / IDE
开发速度 几分钟到几小时 数天到数周甚至更长
入门门槛 无需具备代码知识 需要懂得如何编写所有代码
创作过程 探索与实验，如同即兴弹奏吉他 有计划、精确且可重复，如同创作交响乐

氛围编程的优势

氛围编程提供了若干关键优势，特别是对于那些希望快速将想法付诸实施并减少重复性任务的开发人员。

  • 更快的开发速度。 经验丰富的开发人员使用氛围编程可以在几小时内完成一个应用程序，而传统的开发时间则需要数天或数周。
  • 更低的入门门槛。 开发人员进行氛围编程所需的唯一语言是他们自己的自然口语。氛围编程使开发人员能够在不懂编码的情况下启动一个功能正常的项目。AI对于正在学习编码或理解应用程序工作原理的开发人员来说，也是一个强有力的工具。
  • 快速原型制作。 氛围编程的速度使开发团队能够快速创建功能性的最小可行产品。这使得氛围编程非常适合在争抢市场先机时向投资者展示项目。此外，它还通过实验实现了更快的功能迭代。
  • 爱好或内部项目。 如果无需考虑公共访问或安全问题，氛围编程是理想选择。其速度和易用性使开发人员能够快速解决问题并构建解决方案。
  • 多模态编程。 氛围编程将代码生成扩展到集成开发环境之外的键入方式，包括语音到文本提示。
  • 员工协作与生产力。 开发人员从编写代码转向审查和优化代码。其他员工，如分析师和产品经理，也可以对编程提供意见，从而实现业务和IT部门的跨职能协作。

氛围编程的局限性

氛围编程听起来是否好得令人难以置信？这取决于它的使用方式。使其成为小型应用程序和原型强大工具的特点，在大型代码库或安全性优先的场景中，却可能成为其负担。

  • 错误与幻觉。 生成代码的AI与任何其他流行的AI工具一样容易出现幻觉。几位计算机科学研究人员的一项研究发现，商业AI模型平均有5.2%的情况下会推荐不存在的软件包。相比之下，开源模型的这一比例跃升至21.7%。
  • 有限的技术复杂性。 提供给AI的每个提示都有一个有限的上下文窗口——类似于内存——其中包含大量关于您环境的数据，例如您打开的标签页内容。这为AI提供了上下文，使其能够做出明智的决策。然而，不同AI模型的上下文窗口大小不同，并且较大的上下文大小可能会影响AI的性能。项目越复杂，AI理解项目所需的上下文就越多。
  • 难以调试和维护。 未经审查就接受AI生成的代码，可能会导致创建一个无人理解代码作用及缘由的代码库。如果AI引入了其自身无法修复的错误，而开发人员又无法理解其输出，那么进展将完全受阻。
  • 缺乏原创性。 编码AI基于现有的代码示例进行训练，只能生成它所知道的内容。它无法完全靠自己提出革命性的过程或想法。

企业高管应将氛围编程生成的代码视为快速原型。然而，程序仍然需要经过审查。对于面向客户的服务，必须进行审查；如果涉及其他敏感数据，则必须检查其是否符合法规要求。

氛围编程的安全顾虑

一位名叫Leo的开发人员在X上宣布，他发布了一个完全通过氛围编程构建的SaaS应用程序。两天内，他的应用程序就遭到了黑客的攻击，Leo发帖称出现了各种随机问题。在整个项目中如此重度依赖AI会导致安全问题层出不穷。原因如下：

  • LLM或平台中的漏洞。 任何依赖外部组件的软件产品都会继承潜在的漏洞。AI编码平台也不例外。最近，安全研究人员在氛围编程平台Base44中发现了暴露的API端点，使得攻击者能够使用非机密的app_id值创建新账户来访问私有应用程序，从而绕过所有身份验证机制。
  • 开发人员错误。 氛围编程工具会精确地生成开发人员所要求的内容。如果开发人员在其提示中未包含安全实践，AI将不会生成遵循最佳安全实践的代码。
  • 数据隐私。 LLM通过摄取数据作为训练数据来改进模型。如果项目涉及敏感数据，例如支付信息、健康记录、专有代码或商业机密，则AI工具必须实施严格的数据隔离，以防止AI在其他应用程序中使用受保护的信息。

如何实施氛围编程

考虑到其局限性，在将氛围编程集成到项目中时最好谨慎行事，以充分利用其优势。

  1. 规划项目。 氛围编程和传统编程共有的一个特点是，两者在从一开始就有清晰计划指导时最为有效。确定您要构建什么，并将步骤分解为易于消化的小部分。牢记您希望为项目采用的安全和代码标准。
  2. 决定您的"氛围"策略。 真正的氛围编程定义为将所有决定交给AI。AI辅助编码是一种混合方法，开发人员向AI提示代码，然后在批准前仔细检查输出。找到最符合您优先事项的平衡点。
  3. 选择AI编程助手。 并非所有模型都构建得一样。有些专门用于代码生成，而其他则能解决更复杂的问题。不同模型在数据隔离、隐私以及成本方面有不同的政策。请仔细选择最适合您项目的AI代理。
  4. 使用源代码控制。 这对任何类型的编码都是个好主意，但对于氛围编程尤其重要。当您的项目处于良好工作状态时，为自己创建检查点，以便您可以根据需要轻松调整。
  5. 迭代。 一次创建一个功能，并在每个提示中提供尽可能多的细节和上下文。优化和重构您的代码，直到它符合您的设想。
  6. 测试。 确保您的项目在每个步骤中都正常工作。AI非常擅长生成自动化测试，但请确保您也执行手动测试，包括依赖项验证和自动化测试，以阻止合并未知/无效的软件包。
  7. 设定防护措施。 务必建立安全审查和编码标准。氛围编程项目仍应审查其准确性和合规意识，因此审批工作流是必要的。

IT高管可追踪的指标

这些指标应衡量交付速度、缺陷率和生产率的改进。以下是高管可用于追踪氛围编程的几个指标示例：

  • 原型制作时间（引入氛围编程工具前后对比）。

  • AI生成的拉取请求在自动化关卡失败的比例，例如测试、代码 lint 检查和软件成分分析。

  • 幻觉检测率，包括无效软件包或不良依赖项。

  • 每月归因于AI生成代码的安全事件。

  • 每个正常工作的原型的成本，以客观显示投资回报率。

发布于

AI智能体是加速器，而非开发者替代品

将AI集成到应用开发中的核心挑战，不在于其协助能力，而在于我们能在多大程度上放心地将控制权委托给它。

尽管AI智能体可以完美地执行那些曾被认为人类专属的任务，但它们同样可能在紧接着的下一段代码中犯下令人震惊的错误。

这些错误尖锐地提醒我们，即使是最先进的AI编程助手，仍然缺乏对世界运行方式的理解。这一根本区别将当前的生成式AI与通用人工智能（AGI）的愿景区分开来。考虑到这一点，让我们来看看AI智能体如何成为出色的开发加速器，却无法取代人类开发者。

LLM的推理并非逻辑推理

即使是复杂的智能体AI——构建于拥有日益庞大的上下文窗口和复杂工作流程的大型语言模型（LLM）之上——也依赖于语义模式匹配。它们无法对底层的因果关系和相互依赖提供真正的洞见。

让人类难以理解这一点的是，LLM在阐述其决策过程时具有令人信服的方式，常常模仿一种逻辑递进，暗示其对因果关系的理解，而实际上它们并不具备这种理解。它们通过拼凑统计上可能性高的人类推理文本片段来实现这一点。虽然这看起来像是逻辑推理，但它基于从训练数据中得出的概率计算，而非对步骤之间因果关系的直接理解。

LLM模仿逻辑推理，但无法掌握因果关系。

将这比作一位主演医疗电视剧的演员，他多年来记住了数千小时的对话、纪录片和真实咨询记录。他可以完美地进行鉴别诊断，像经验丰富的医生一样自信地用专业词汇滔滔不绝地说出症状、检测结果和治疗方案。他知道"向左臂放射的胸痛"通常出现在关于心脏病的场景中，"全血细胞计数和代谢指标组"跟在"我们来做些检查"之后，而担忧的表情伴随着关于肿瘤的讨论。

一位对医疗话题表现出表面理解的医疗剧演员，是比喻AI无法掌握因果关系的绝佳例子。

他们的表演如此令人信服，以至于任何观众都会相信他们懂医。但他们根本不知道阿司匹林为什么能稀释血液，心脏病发作时会发生什么，或者为什么一种治疗有效而另一种会致命。他们只是在背诵他们记住的各种医疗对话的变体，拼凑那些在统计上共同出现的片段，却不理解这些模式代表了真实的生物过程，其中顺序和因果关系 literally 意味着生与死。翻译到应用开发中，这通常意味着出色的结果之后紧接着灾难性的失败，反之亦然。

统计模式而非因果真相

LLM非常擅长在难以想象的大量文本中寻找并连接模式。尽管这些文本中有许多描述了世界的运作方式，但LLM并不理解这些描述的实际含义。相反，它将文本转换成数字——向量——这些数字捕获的是统计关系，而非因果真相。然后，模型将这些数字翻译回人类语言，而在这一切之下，它始终只是在跟踪和 shuffling 数字，而不是意义。例如，"charge"、"payment"和"credit card"这些词可能在向量空间中位置接近，因为它们经常在文本中共同出现，而"profile"、"lookup"和"fetch"则形成另一个集群——但模型实际上并不知道一组涉及金钱，而另一组不涉及。

LLM只处理词组之间的统计关系。

事物并非表面所见

由于编程语言是高度结构化的，这种数值上的 shuffling 可以产生优秀的代码。虽然AI模型并不像开发者那样"理解"代码，但它可以可靠地将输入模式映射到输出，将框架映射到样板代码，将语法映射到语义，其方式常常看起来与人类代码无异。例如，当被要求"用Python和Flask构建一个REST API"时，模型无法推理HTTP或数据库——它只是回忆起@app.route通常出现在函数定义之前，GET请求常常映射到返回jsonify，而错误处理经常涉及try/except块。结果往往是结构良好的Flask代码，即使它源于模式回忆而非真正的理解。

人类需要保持在循环中，以应对AI缺失的上下文和推理能力。

例如，为重试逻辑加固微服务听起来很简单——然而实际情况并非如此。要求AI助手"在失败时添加重试"，你可能会得到一段在任何错误时都重试所有操作的代码。这对于幂等的（或无状态的）读取操作（例如"获取配置文件"）来说没问题，因为重复调用只会返回相同的数据。
将相同的逻辑应用于非幂等操作——扣款、创建订单、发送电子邮件、查询数据库——你就会招致灾难：重复扣款、重复订单、通知风暴、数据库中的重复记录。解决方法并非魔术，而是判断力。人类首先对操作进行分类——幂等与非幂等——仅在瞬态错误时重试，并且对于任何有副作用的操作，都需要幂等性密钥和服务端去重。虽然这仍然为人类开发者节省大量时间，但他们仍然需要将其技能和专业知知融入其中，否则灾难可能并且将会随机发生。

理解模式匹配的局限性很棘手

原则上，模式匹配难道不能识别出对信用卡扣款需要采用与检索客户资料或产品信息不同的API调用重试方法吗？是的，它可以，但人类无法事先知道这一点，因为这取决于该特定模型的训练数据是否包含了执行标准POST或GET请求的重试函数。
模型未能建立操作类型与其现实后果之间的联系；它仅仅回忆统计关联。为了让模型避免这个错误，训练数据需要包含清晰、一致且重复出现的配对，将操作类型与重试策略及其后果联系起来。
理想情况下，数据会明确对比可以安全重试的代码与必须避免重试的代码。或许它还包括了事后分析或警告，描述了误用重试时发生的情况。然而，模型是否摄入了足够的训练数据来做出这种区分，我们人类无法确定。更棘手的是，由于其概率性质，模型可能在某一次做出了区分，但在接下来的三次尝试中却没有。
这个例子说明了为什么简单地添加更多训练数据通常不是答案，因为必要的数据可能并不以书面形式存在。或者更糟的是，训练数据可能包含了强化错误概括的内容。无论哪种情况，人类用户都无法知道是否如此，并且需要全面理解特定问题应如何解决。

AI的价值是真实的，开发团队可以受益

只要清楚地理解其局限性，AI智能体可以显著提高人类开发者在整个开发生命周期中的生产力。从收集需求并将其转化为用户故事，一直到检测并部署应用程序，AI智能体可以为人类提供建议、自动化验证和快速原型设计，从而显著缩短迭代周期。
AI智能体应被视为力量倍增器，可以处理开发的机械性方面，例如基于现有示例和文档生成样板代码、编写测试用例和记录API。另一方面，人类则负责真正理解业务影响、决定架构权衡，以及解决需要应用抽象逻辑能力的复杂问题。

AI对SDLC的生产力影响

下表分析了AI对软件开发生命周期（SDLC）中不同活动的生产力影响，以及AI对每项活动的能力、所需的人力参与程度和每项活动的风险水平。

AI对SDLC活动的生产力影响

活动 AI的生产力影响 AI能力描述 人力参与需求 风险水平
需求收集 低 – 中 根据笔记、会议记录、电子邮件和其他材料生成用户故事。 高 – 确保故事在成本、风险和回报方面与当前业务优先级保持一致。 高 – 被误解的需求将贯穿整个项目。
架构与设计 低 建议模式、识别瓶颈并生成初始图表，作为人类构建的坚实起点。 关键 – 考虑系统范围影响、做出战略权衡并监控技术趋势。 高 – 糟糕的架构决策难以逆转且成本高昂。
代码生成 高 构建定义良好的样板代码并解决精确定义的问题。保持文档更新。 中 – 掌控业务逻辑和边缘情况。 中 – 通常难以完全掌控AI编写的代码。
代码审查 中 捕获语法错误、发现安全漏洞、发现性能问题并建议优化。 高 – AI会遗漏依赖于上下文的问题和架构问题。 中 – 人类需要对审查负全责。
测试 高 创建单元测试、集成测试、自动化回归测试并发现边缘情况。 低 – 对于测试生成，但 高 – 对于测试策略。 中 – 人类必须对测试的完整性和相关性负责。
调试 高 分析堆栈跟踪并就已知错误建议修复方法。 中 – 指导调试过程。 低 – 错误的修复通常很容易发现。
文档编写 高 生成API文档、自述文件、内联注释、用户指南和变更日志。 低 – 对于面向用户的文档。 低 – 不正确的文档通常可以在没有重大影响的情况下得到纠正。
部署与CI/CD 中 创建部署清单、构建IaC模板、生成流水线配置。 高 – 生产部署需要仔细检查。 高 – 任何问题都会直接影响生产环境。
监控 中 添加检测、分析日志并生成警报规则。 中 – AI在没有上下文的情况下难以确定优先级。 中 – 误报会浪费时间。

来源：Torsten Volk, Omdia • 获取数据 • 使用 Datawrapper 创建

结论

宣布AI智能体正在接管开发者工作的技术领导者们，对AI当前能力产生了不切实际的期望。这导致许多企业高管认为开发者工时不再是他们所能构建内容的限制因素。金融分析师可以创建自己的投资组合再平衡工具；医疗保健管理员可以构建患者排班系统；供应链经理可以开发库存优化仪表板；或者营销总监可以构建个性化的活动自动化平台，而无需编写一行代码。虽然他们可以为许多此类业务任务实现概念验证，但架构、开发和交付企业级软件仍然极大地依赖于人类开发者的技能和经验。
然而，AI智能体可以通过为人类开发者完成大量基础性工作来显著加速SDLC。创建测试用例、用监控代理自动检测复杂软件、记录数万行主机代码以及精确定义复杂的基础设施清单，仅仅是AI智能体可以帮助人类开发者的几个例子。
人类与AI智能体之间的SDLC必须是协作的、迭代的并接受持续监督。确定如何最优地调整流程、开发工具和企业文化以满足这些要求，是智能体辅助应用开发的下一个前沿领域。弄清楚如何为人类编码者提供最佳AI支持，其回报有望带来显著的生产力提升，使人类开发团队能够更快、更高质量地交付更多功能。

[注]本文译自: AI agents are accelerators, not developer replacements

发布于

构建复合AI系统以实现可扩展工作流

了解如何利用复合AI系统架构化模块化且安全的智能体工作流，以实现可扩展的企业自动化。

生成式AI、大语言模型和多智能体编排的融合催生了一个变革性的概念：复合AI系统。这些架构超越了单个模型或助手，代表了智能代理的生态系统，它们通过协作来大规模交付业务成果。随着企业追求超自动化、持续优化和个性化参与，设计智能体工作流已成为关键的差异化因素。

本文探讨复合AI系统的设计，重点聚焦模块化AI代理、安全编排、实时数据集成和企业治理。旨在为解决方案架构师、工程领导者和数字化转型高管提供一个实用的蓝图，用于在各个领域（包括客户服务、IT运营、营销和现场自动化）构建和扩展智能代理生态系统。

复合AI的兴起

传统的AI应用通常是孤立的，一个机器人专用于服务，另一个专注于分析，还有一个用于营销。然而，真实世界的工作流是相互关联的，需要共享上下文、移交意图并进行自适应协作。复合AI系统通过以下方式解决这一问题：

  • 启用自主但协作的代理（例如，规划器、检索器、执行器）
  • 促进多模态交互（文本、语音、事件）
  • 支持企业级的可解释性、隐私和控制指南

这反映了复杂系统在人类组织中的运作方式：每个单元（代理）都有其角色，但它们共同创造了一个价值链。

企业级智能体工作流的设计原则

设计有效的复合AI系统需要深思熟虑的方法，以确保模块化、可扩展性并与企业目标保持一致。以下是指导智能体工作流开发的关键原则：

1. 模块化代理设计

每个AI代理都应遵循单一职责原则，设计为具有特定、明确界定的职责。这种模块化使维护、测试和可扩展性变得更加容易。例如：

  • 规划器代理：将总体目标分解为可管理的子任务。
  • 检索器代理：从不同来源检索和收集相关数据。
  • 执行器代理：根据规划器的指令执行操作。
  • 评估器代理：评估结果并提供反馈以持续改进。

通过明确定义职责，代理可以独立运作，同时在系统内协同工作。

2. 事件驱动和以意图为中心的架构

从静态的、同步的工作流转向动态的、事件驱动的架构，可增强响应能力和适应性。实施以意图为中心的设计使系统能够有效解释用户或系统意图并据此行动。关键组件包括：

  • 意图路由器：对意图进行分类并将其引导至相应的代理。
  • 事件代理：通过事件消息促进代理之间的通信。
  • 记忆模块：随时间推移保存上下文，使代理能够基于历史数据做出明智决策。

这种架构实现了可扩展性和弹性，这对企业环境至关重要。

3. 企业数据集成与检索增强生成

集成结构化和非结构化数据源可确保AI代理在全面的上下文中运行。利用检索增强生成技术使代理能够访问外部知识库，从而提高其决策能力。策略包括：

  • 数据连接器：创建与企业数据库和API的安全连接。
  • 向量数据库：增强语义搜索和相关信息的检索。
  • 知识图谱：提供数据实体之间关系的结构化表示。

这种集成确保了代理信息灵通、具有上下文意识，并能提供准确的结果。

4. 安全与治理框架

确保智能体系统的安全性和合规性至关重要。实施强大的治理框架有助于维持信任和问责制。关键实践包括：

  • 访问控制：建立并强制执行数据和代理交互的权限。
  • 审计追踪：记录代理活动以实现透明度和合规性。
  • 合规性检查：根据GDPR和HIPAA等监管标准定期评估系统。

结构良好的治理模型可以防范风险，并确保AI的合乎道德的部署。

5. 可观测性与持续监控

实施可观测性实践能够实时监控和诊断代理行为及系统性能。关键组件包括：

  • 日志记录：记录代理行动和决策的全面日志。
  • 指标收集：收集性能指标，如响应时间和错误率。
  • 警报系统：及时向利益相关者通知异常或系统故障。

持续监控允许进行主动维护和持续改进。

6. 人在回路机制

纳入人工监督可确保AI代理在可接受的范围内运行，并适应细微的场景。HITL方法包括：

  • 审批工作流：确保关键决策或行动得到人工验证。
  • 反馈循环：使用户能够就代理性能提供输入，指导其未来行为。
  • 干预协议：允许人员在必要时修改或调整代理行动。

平衡自动化与人工判断可增强系统可靠性并建立用户信任。

7. 可扩展性与性能优化

设计能够有效扩展以处理不断增长工作负载的系统至关重要。实现这一目标的策略包括：

  • 负载均衡：在代理和资源之间均匀分配工作负载。
  • 异步处理：使代理能够独立运行，最大限度地减少瓶颈。
  • 资源管理：有效监控和分配计算资源以维持性能。

针对可扩展性进行优化可确保系统在需求增加时保持响应能力和有效性。

通过遵循这些设计原则，企业可以创建稳健、高效、可靠的智能体工作流，这些工作流既符合组织目标，又能适应不断变化的挑战。

实际应用案例：现场服务代理网格

场景：一家公用事业组织可以利用三个专门的AI代理来增强现场响应操作：

  • 规划器代理：评估收到的用户投诉并制定解决计划。
  • 检索器代理：获取资产位置、历史工单数据和合规性检查清单。
  • 执行器代理：安排技术人员并向移动服务团队发送警报。

影响：提高任务分配效率、缩短解决周期并提高技术人员生产率。

结论

复合AI系统正在通过促进智能、适应性强且可扩展的工作流来改变企业架构。设计模块化、可编排的智能体系统有助于组织：

  • 加速AI驱动的转型
  • 增强运营弹性和灵活性
  • 为客户和员工体验提供更好的结果

未来在于从孤立的AI任务转向复合的代理生态系统，这是一种将创新与强大治理及领域相关性相结合的战略。

【注】本文译自：Architecting Compound AI Systems for Scalable Workflows