如果说过去两年的 AI 转型是“给马车装上火箭推进器”，那么今天 CIO 们面临的挑战则是“重新设计一架既能自动驾驶、又绝对不会偏离轨道的混合动力飞机”。
大多数企业已经过了最初的 AI 炒作期（比如搞个生成式应用的原型，或者买个现成的 AI Agent 平台）。现在，摆在研发负责人面前的真实需求是：构建融合了 AI 智能与传统代码规则的全新混合应用。
这种混合环境带来了一个极其复杂的中间地带：如何平衡 AI 的“概率性（猜得准）”和传统逻辑的“确定性（不犯错）”？以下是帮助 CIO 们划定界限、组织团队的 4 个关键策略：
第一步，必须明确哪种技术适合哪个场景。
让 AI 处理“模糊性”：解释意图、总结内容、提供决策支持。
让传统代码处理“底线”：数据验证、交易处理、合规逻辑。
架构原则：双重表示架构。正如 EDB 的 CTO Quais Taraki 所建议的：“让 Agent 负责提建议，让传统逻辑负责守护系统记录。” 根据对失败的容忍度来决定主导权。如果你在做一个创新探索项目，可以“以 Agent 为核心，用传统代码做制衡”；如果是在金融或医疗等高容错极低的场景，则必须反过来操作。
混合应用需要混合技能。如果你把研发团队分为“只懂大模型的 AI 人”和“只写 Java 的传统人”，那么你将面临迅速累积的整合债务（Integration Debt）。
关键破局点：培养“桥梁工程师”。CIO 需要重新思考团队结构，引入既懂传统软件架构（如微服务、数据库），又精通生成式设计模式的工程师。此外，要把 Agent 看作是“能力极强、权限极大的数字员工”，打破 AI 与传统开发的隔阂，将编排（Orchestration）和可观测性（Observability）作为核心基础设施来建设。
虽然 AI Agent 可以加速代码编写，但你省下的时间绝不能用来睡大觉。你必须把这些时间重新投入到：
上游设计：更谨慎的架构规划。
下游监控：混合系统引入了巨大的复杂性。概率性组件（AI）的执行路径是可变的，成本是基于 Token（代币）的，这完全颠覆了传统的容量规划和 QA（质量检测）框架。
你要明白：Agent 时代的总体拥有成本（TCO）不仅是 API 的调用费，更是管理大规模非确定性系统所需的运营成本。
当你刚搞明白如何混合 AI 与传统代码时，目标又变了。随着时间的推移，混合系统的重心正在迅速向 Agent 偏移。一年后，你可能不再是“在遗留系统上叠加 Agent”，而是“围绕 Agent 能力构建系统，并用传统代码来管理风险”。
为了确保系统的弹性，务必为每个 Agent 步骤设定“确定性的回退方案（Deterministic Fallback）”。这样，即使大模型出现幻觉或宕机，你的平台依然能平稳降级，保持核心功能的可用。
结语
在生成式 AI 与传统软件开发的交汇处，没有一劳永逸的现成公式。未来的赢家，将是那些懂得在“智能的狂野”与“规则的严谨”之间巧妙切换的架构师和领导者。
原文：4个提示帮助新晋创新者应对AI与传统代码的挑战
一个典型的困境是在两个选项之间做出选择。然而，如今的创新者和首席信息官面临一个不同的挑战，即处理概率性和确定性的代码，不是单独处理，而是在一个新的混合应用环境中共同处理。
图源：Credit: Gorodenkoff / Shutterstock
大多数人原本认为这将是生成式AI的又一年，但如今却迅速转向更加务实的焦点：同时处理概率性（由AI/机器学习驱动）和确定性（基于传统规则）代码。这并非是同时拥有两者，而是一些混合应用需求的不断增加，这些应用需要巧妙且熟练地整合“猜测”和“确定”两者的优势。
许多首席信息官不再处理专注于特定现成AI应用或仅在智能体构建平台内构建的定制生成式应用的试点和原型。他们现在面临的是新的应用开发需求，需要将AI和传统代码结合起来。
这些应用程序不是在现有应用上附加AI，而是从头开始设计的全新应用。首席信息官们迅速发现了其中的复杂中间地带，他们需要决定在哪里划定界限以及如何组织团队。
以下是首席信息官在决定如何最好地整合生成式、概率性和传统确定性代码时的四个建议，特别是在需要谨慎整合两者的软件开发项目中。
一、划定界限并设立护栏
第一步是了解每项技术的最佳适用场景，并为开发和整合团队制定架构指南和最佳实践。
AI和数据公司EDB的首席技术官Quais Taraki（奎斯·塔拉基）建议，使用确定性代码处理企业的权威规则，使用概率性代码处理人类意图的复杂模糊性。他说：“关键是一个双重表示架构，其中智能体提供建议，但传统逻辑保护记录系统。通过将它们整合到一个平台上，你可以消除将AI附加到现有系统上时通常会带来的集成税，同时保持对数据和逻辑的绝对主权。”
Arion Research LLC的首席分析师Michael Fauscette（迈克尔·福斯西特）表示，首席信息官的关键决策框架是在必须可预测、可审计和可重复的场景中使用确定性代码，而将生成式和概率性方法用于需要大规模推理、判断或处理模糊性的任务。他说：“在实际操作中，这意味着让智能体处理工作流程的复杂中间环节，例如解释、总结和决策支持；而传统代码则负责数据验证、交易处理、合规逻辑和结构化输出生成。”
然而，AI战略顾问、作家Sangeet Paul Choudary（桑吉特·保罗·乔达里）认为这实际上取决于对失败的容忍度与创新收益之间的权衡。他说：“智能体可以帮助提出编码人员未曾想到的创新解决方案，因此在这些有价值的地方，我会以智能体为核心进行设计，将代码作为制衡机制。但在对失败容忍度较低的场景中，我会反过来做。”
如果你正在从事生成式代码方面的工作，作为新软件开发项目的一部分，优化你的生成式代码和输出也很重要。在决定何时何地引入传统代码的护栏之前，你通常希望尽可能准确且可重复地完成这一点。例如，糟糕的提示或针对特定用例的次优大语言模型可能会改变边界，甚至会让你在寻找传统代码安全性的过程中未能充分利用智能体的力量。
二、为新的混合团队组织架构
这些新的混合应用也需要具备混合技能集的团队。Taraki（塔拉基）建议首席信息官将智能体视为公司内部能力极强的员工。他说：“就像任何拥有重要权限和自主权的员工一样，它们具有很大的影响力，可能会对你的业务产生深远的影响，无论好坏。成功需要消除AI和传统开发团队之间的隔阂，确保编排和可观测性被视为关键基础设施。”
Fauscette（福斯西特）建议首席信息官重新思考团队构成，增加桥梁角色——既了解传统软件架构又掌握生成式设计模式的工程师，因为孤立的AI团队和工程团队会产生迅速累积的整合债务。
据Choudary（乔达里）称，重要的是要减少被动的质量检测，更多地在开发和工具环境中进行主动检查，让智能体与编码人员并肩工作。
总体而言，生成式代码与传统代码之间的转换和交汇并不总是像API调用和结构化输出那样简单。因此，不仅要考虑人与AI之间的宏观工作流程，还要考虑概率性代码和确定性代码之间的众多接口。就像人与机器之间的交接一样，我们还需要在AI和传统代码之间设置恰当的交接点，并培养了解其中权衡的工程师。
三、为治理和成本建模投入时间
虽然混合应用可能会加速软件开发，但节省的时间和成本需要重新分配到上游软件设计和架构以及下游测试、监控和成本建模上。
Fauscette（福斯西特）表示，在治理和总拥有成本方面，混合系统在测试、监控和成本建模中引入了新的复杂性。因为概率性组件具有可变的执行路径和基于代币的成本结构，这些并不完全符合传统的容量规划或质量检测框架。
在成本建模方面，尽管推理成本可能需要制定新的业务规则来为终端用户设定使用边界，但Taraki（塔拉基）表示，从根本上讲，智能体时代的总拥有成本不仅仅是推理成本，还包括管理大规模非确定性系统所需的运营严谨性。
四、认识到多智能体工作流将进一步模糊界限
构建包含生成式代码和传统代码的混合系统的新设计考量和组织需求还不够复杂，我们还要面对不断变化的目标，因为智能体正在不断发展。
Choudary（乔达里）补充说，混合系统内部的重心每年都在向代理转移。他说：“我们最初是让智能体在遗留代码之上工作，但现在我们越来越多地看到，创新需求驱动的系统围绕智能体能力进行设计并使用代码进行性能和风险管理。”
Fauscette（福斯西特）还建议，在任务是端到端的认知工作（如研究、分析和规划）时选择多智能体工作流；而在需要对输出进行精确控制、符合监管要求或与现有记录系统集成时选择混合AI和传统方法。他说：“展望未来，随着生成式框架的成熟并提供更好的原生支持用于确定性检查点、结构化输出和人工干预控制，这两种模式之间的界限将在未来一年到十八个月内逐渐模糊，混合模式将成为默认的标准架构模式。”
Taraki（塔拉基）的建议是通过确保每个代理步骤都有确定性的回退方案来实现优雅降级，这样即使模型失败，你的平台也能保持弹性和可用性。他补充道：“生成式的未来将不再是有代理性的粘合剂，而更像是一个具有服务等级协议、可审计性和标准化检索、工具使用和安全模式的自主平台。我们的研究表明，优先考虑数据和AI主权的全球企业中，有13%的企业已经实现了五倍的投资回报率，并且在主流生产中运行的用例数量是同行的两倍。”
