简介：智能体框架大多默认从 Python 或 TypeScript 起步，但在银行、制造、科研等大型组织中，COBOL、Fortran、Perl、Lua、Erlang 等长尾运行时才是核心业务的真正载体。本文围绕“智能体应如何进入多语言遗留系统”这一核心问题，对比分析“桥接封装”与“智能体下沉”两类架构方案的技术差异、适用场景与信任构建方式，帮助架构师和技术负责人在不触发大规模重写的前提下，判断哪些能力应原生嵌入运行时，哪些应留在桥接之后。
当前主流的智能体开发框架，其设计起点通常是一个干净、同构的应用环境：开发者新建项目、安装 SDK、接入模型、定义工具，然后通过流式输出完成一次对话或任务执行。这套模式在创业公司、原型验证和全新项目中运转良好，因为从第一天起，所有代码都可以围绕智能体的调用方式、状态管理和工具权限来设计。
但大型组织的真实技术底座远非如此。一家银行的夜间批处理可能已经运行了二十年，由 COBOL 编写，串联起作业调度、对账、总账和报表整条链路。每一环都有负责人，每一次变更都受审计约束，每一个异常都有既定处理流程。风险模型可能由 Fortran 编写，系统间的胶水脚本可能是 Perl，嵌入式控制面可能是 Lua，消息服务可能是 Erlang，研究团队则可能使用 Julia 或 R。这些系统不是为了“接入智能体”而设计的，很多也无法重写——因为重写的代价不只是代码改写，还包括监管审查、审计追踪、迁移验证和长期的变更控制。
由此产生了一个根本性的问题：智能体能否进入这些多语言、长生命周期的运行时，同时不绕过它们已有的治理边界？这个问题的核心不是“某种语言流不流行”，而是“智能体循环应该落在哪里才值得信任”。
围绕上述问题，业界逐渐分化出两种有代表性的解决方案。为了便于分析，本文将二者分别定义为“桥接封装方案”与“智能体下沉方案”。
桥接封装方案的核心思路是：在遗留系统外部构建一个具备完整智能体能力的独立进程或服务，通过 API、消息队列、文件交换或屏幕操作等方式，与 COBOL、Fortran 等运行时通信。智能体本身仍然运行在 Python 或 TypeScript 环境中，所有模型调用、工具执行、策略判断、检查点管理和审计事件生成都发生在外部层。遗留系统只负责暴露有限的接口，响应外部指令。
智能体下沉方案的核心思路则是：将受限的、受治理的智能体循环直接嵌入目标运行时内部，让核心业务系统自身具备调用模型、执行策略和发出审计事件的能力。例如，在一个 COBOL 批处理任务中，当出现一笔异常交易时，本地循环可以直接读取上下文、调用工具、请求人工审批、写入检查点，而无需将控制权反复交还给外部的 Python 进程。
这两种方案并非非此即彼的替代关系，而是代表了集成深度、治理边界和技术复杂度之间的不同取舍。理解它们之间的差异，有助于架构师在具体场景中做出条件化判断，而不是盲目跟随某一种“最佳实践”。
尽管架构取向不同，两种方案在目标层面存在若干共通之处。
其一，尊重遗留系统的核心地位。 无论是桥接封装还是智能体下沉，都不主张将 COBOL、Fortran 等系统“迁移”到新语言，也不将“重写”作为接入智能体的前置条件。二者都承认，这些系统承载着不可替代的业务价值和监管责任。
其二，都强调审计与可追踪性。 对于银行批处理这类场景，任何智能体行为都必须可追踪、可回放、可审批。两种方案都需要在系统中建立清晰的检查点和审计事件链，确保每一步决策都有记录、有责任归属。
其三，都面临“跨语言状态一致性”的难题。 无论智能体循环位于运行时内部还是外部，一旦涉及人工审批、长时等待或多步骤任务，就需要在跨进程、跨语言的边界上保持一致的状态语义。这并非某一种方案独有的挑战，而是所有多语言智能体系统都要面对的基础问题。
其四，都需要对模型调用实施策略约束。 在核心业务系统中，模型不能自由地做任何事。哪些工具可以调用、哪些操作需要人工确认、哪些输出可以进入生产数据流，都必须在系统设计阶段明确。两种方案都需要提供相应的策略执行机制，区别只在于策略执行的位置。
桥接封装方案的架构边界非常清晰：遗留系统在一侧，智能体平台在另一侧，中间通过明确的接口契约连接。这种清晰性带来了较低的侵入性——遗留系统本身几乎不需要改造，只需暴露一些只读接口或受控写入口。但代价是，策略、工具授权、检查点、事件关联和人工审批机制都需要在桥接层重新建立。你可以在 Python 环境中获得完整的智能体能力，但这些能力与 COBOL 批处理内部的实际执行状态之间，始终隔着一层语义转换。
智能体下沉方案则打破了这种清晰边界。它主张将精简的智能体循环嵌入运行时内部，使模型调用和策略判断发生在离数据最近的地方。这意味着 COBOL 进程不必把每一笔异常交易的完整上下文都序列化后发给外部服务，再由外部服务返回指令；它可以在本地完成判断，只在需要人工介入时发出请求。但这也意味着，策略执行、审计轨迹和模型调用行为必须由 COBOL 侧（或其他原运行时侧）承担一部分责任。这对语言生态和团队能力提出了更高的要求。
桥接封装方案在功能完整性上拥有天然优势。因为智能体循环位于 Python 或 TypeScript 环境，所有主流的模型客户端、工具调用协议、向量检索库、结构化输出解析器都可以直接使用。开发效率高，生态支持完善。但这些能力中，有很大一部分在核心业务场景下并不需要，甚至可能成为治理负担。一个夜间批处理中的异常处理循环，并不需要全量的插件市场和动态提示词能力，它需要的是受控的、可审计的、确定性优先的任务执行路径。
智能体下沉方案则要求功能被大幅裁剪和本地化。下沉到 COBOL 或 Fortran 中的“智能体循环”，更准确地说是一种“受治理的任务执行器”：接收预定义类型的事件，根据策略选择动作，调用本地工具，生成审计记录，必要时挂起等待人工审批。它不是通用智能体，而是特定业务路径上的可控决策节点。这种裁剪不是缺憾，而是治理的要求。
桥接封装方案的接入方式相对温和。团队可以在不修改 COBOL 批次主流程的情况下，通过旁路模式读取日志、监控输出文件或订阅消息队列，在外部发现异常后进行干预。对于探索性项目和试点场景，这种方式周期短、风险低。但要将干预结果写回生产流程，就必须在遗留系统侧开放受控写入口，这在合规审核中往往需要额外论证。
智能体下沉方案的接入改造量则显著更大。它要求在 COBOL 批处理的特定节点嵌入调用逻辑，在 Fortran 仿真程序中加入策略判断分支，在 Erlang 消息服务中增加检查点语义。这些改造不仅涉及代码，还涉及作业调度、变更窗口和回归测试。但从长期来看，如果智能体需要参与关键决策路径，这种原生性可以减少跨进程转换带来的复杂度。
在桥接封装方案中，智能体的审计事件在外部平台中生成，与遗留系统自身的作业日志往往分离。虽然可以通过关联 ID 将两套日志合并，但当故障发生时，追溯一条决策的完整生命周期需要跨系统拼接。这种拼接本身就有误差风险。
在智能体下沉方案中，审计事件可以在运行时内部直接生成，并与批次作业日志自然关联。一个检查点的写入、一次人工审批的请求、一次工具调用的结果，都能嵌入原有的作业上下文。对于受严格监管的场景，这种原生审计能力具有显著优势。但它要求运行时本身具备足够的日志与事件基础设施，否则下沉的优势无法体现。
桥接封装方案将智能体相关的运维工作集中在外部平台，这与现有 DevOps 体系更容易整合。模型升级、策略调整、工具配置都可以独立于遗留系统进行，对生产批处理的影响面较小。但反过来，多了一个需要监控、告警和容量规划的独立组件，也增加了系统间依赖关系的复杂度。一旦外部智能体服务不可用，遗留系统的主流程不应因此中断，这就要求设计降级路径——这在实践中并不容易做到位。
智能体下沉方案的运维边界与遗留系统本身重合。模型调用逻辑、策略配置和工具授权都纳入既有运维流程。对于已经维护了几十年批处理系统的团队来说，这意味着不需要额外养活一套新的平台。但模型客户端、依赖库和安全更新也进入了原本封闭的运行环境中，带来供应链风险。这需要更严格的版本管理和安全评审流程。
桥接封装方案的初期成本较低，因为不需要对遗留系统做深入改造，探索和验证速度较快。但长期成本中，跨系统集成维护、事件关联治理、双轨审计以及额外基础设施的运维开销会持续存在。
智能体下沉方案的初期成本较高，主要集中在运行时内部的改造、回归测试和治理机制建设。一旦完成，日常运行不需要频繁的跨进程交互，集成成本会逐步降低。但它对团队的多语言能力要求更高——你需要既理解 COBOL 批处理的作业语义，又理解智能体循环的治理要求。
| 对比维度 | 桥接封装方案 | 智能体下沉方案 |
|---|---|---|
| 侵入性 | 低，遗留系统改动少 | 高，需在运行时内嵌入逻辑 |
| 功能完整性 | 高，可复用完整智能体生态 | 低，需裁剪为受治理的执行器 |
| 审计能力 | 外部审计，需跨系统关联 | 原生审计，与作业日志同源 |
| 接入周期 | 短，适合试点 | 长，需变更窗口和回归测试 |
| 运维边界 | 独立于遗留系统 | 与遗留系统重合 |
| 状态一致性 | 跨进程语义转换复杂 | 本地上下文完整，一致性较好 |
| 长期成本 | 集成维护开销持续存在 | 前期投入高，后期集成成本低 |
| 团队要求 | 偏重新语言与智能体框架 | 偏重多语言与治理机制 |
| 适用场景 | 探索、旁路监控、非关键路径 | 核心决策路径、强审计场景 |
优先考虑桥接封装方案的场景：
优先考虑智能体下沉方案的场景：
需要特别指出的是，现实中的很多场景并不会完全落在某一端。更常见的模式是混合架构：在非关键路径上使用桥接封装快速获得智能体能力，在关键路径上逐步下沉受治理的循环，两者共享统一的审计事件模型和身份体系。
无论选择哪种方案，以下问题都应在设计阶段加以评估：
第一，工具授权的边界。 智能体在遗留系统中能调用哪些程序、读取哪些文件、写入哪些队列，必须通过明确的策略声明。授权模型应尽量与遗留系统已有的用户和角色体系对齐，避免另立一套独立权限。
第二，人工审批节点的位置。 在批处理链路中，人工审批不是外挂的 Web 页面，而是嵌入作业流的状态节点。智能体请求审批后，批处理应能挂起等待，审批通过后从检查点继续，而不是从头重跑。这要求作业调度系统支持长时等待和状态恢复。
第三，检查点语义的跨语言一致性。 检查点不仅要记录“执行到哪一步”，还要记录上下文数据版本、外部依赖状态和可回滚范围。在桥接方案中，这类信息需要在两个进程间反复同步；在下沉方案中，则必须融入运行时原有的数据结构。
第四，降级策略。 一旦模型服务不可用、工具调用超时或策略引擎故障，批量作业不能中断整体链路。应提前定义降级路径：是跳过该智能体节点转为人工笔录，还是终止任务并报警，需要在设计阶段明确。
第五，测试与回归。 智能体的引入会改变原有作业的非确定性。即使模型输出被严格约束，其执行路径也可能因版本升级或策略调整而变化。因此需要建立可重复的测试集，覆盖典型异常场景和边界输入，并纳入已有的变更管理流程。
“当智能体遇见 COBOL”这个命题，真正拷问的不是某一种语言的存废，也不是智能体技术能否在老旧系统中运行。它拷问的是：在一个由审计、变更控制和长时间运行构成的世界里，什么样的智能体循环才值得信任？
桥接封装方案给出了一个快速、低侵入的答案，但它将信任建立在外部平台上，跨进程的治理缺口需要持续投入来弥补。智能体下沉方案给出了一个更原生、更内聚的答案，但它要求团队具备同时理解遗留运行时和智能体治理的双重能力，且前期改造成本不可忽视。
最终的选择不取决于哪一方在技术上“更先进”，而取决于智能体在业务链路中的位置、审计要求、团队能力和变更窗口。对于观察性场景，桥接封装足以胜任；对于决策性场景，下沉的受控循环更可能通过治理审查。而在大多数大型组织中，二者共存的混合架构，才是逐步建立信任的现实路径。