多语言智能体框架落地难点与架构对比

一、对比背景：智能体离真实业务系统还有多远

当前，智能体相关的能力演示大多集中在相对理想化的环境中：新建一个项目，选择 Python 或 TypeScript，安装 SDK，接入模型，定义工具，然后完成流式输出。这种路径对创业团队或全新应用开发是可行的，因为它从零开始，技术栈统一，仓库干净，依赖可控。

但如果把智能体放进一家已经运行多年的大型组织，情况会完全不同。大型组织内部的信息系统普遍不是单一语言，而是由多个时代、多个团队、多种运行环境组合而成。例如：

• 夜间批量处理可能运行在 COBOL 上；
• 风险计算模型可能由 Fortran 编写；
• 系统之间的数据交换脚本可能使用 Perl；
• 嵌入式控制面可能依赖 Lua；
• 消息处理服务可能用 Erlang 实现；
• 研究部门可能使用 Julia、R 或 D 语言；
• 某个关键组件可能由 Zig 编写，而维护者只有一个人。

这些系统不是为了智能体而设计的，也不会因为智能体出现就被整体重写。真正需要回答的问题不是“某门语言是否流行”，而是：智能体能否进入这些既有系统，同时不破坏它们周围的权限、审计、变更控制和运行约束。

这正是本文要讨论的核心：在多语言混合的遗留环境中，智能体应该以什么方式接入。核心对比对象是两种完全不同的落位策略，一种是独立智能体服务，另一种是智能体下沉到现有语言运行时中。

二、对比对象定义

1. 方案A：独立智能体服务

这种方案的特点是智能体框架运行在独立进程中，通常使用 Python、TypeScript 等现代语言构建。它不直接修改遗留系统，而是通过 HTTP、消息队列、文件交换、数据库轮询或旁路桥接等方式与旧系统交互。

这类方案的代表做法是“给遗留系统包一层 API”，或者让智能体作为 sidecar 旁路进程存在。它默认智能体拥有自己的运行环境、自己的依赖版本、自己的模型调用逻辑和自己的工具注册体系。

2. 方案B：智能体下沉到现有运行时

这种方案的思路完全不同。它不执着于“把旧语言改成新语言”，而是问另一个问题：智能体应该住在离数据、交易、审核流最近的地方。

如果一笔异常交易的处理逻辑在 COBOL 批处理中，那么受治理的智能体循环就应该靠近 COBOL 批处理；如果仿真模型在 Fortran 中，那么 Fortran 进程应该能够自己调用模型并执行策略；如果一个控制面由 Lua 驱动，那么决策与审批步骤也可以由 Lua 承载。

方案B并不是要求所有语言都实现完整智能体框架，而是让智能体的关键控制点嵌入现有执行链路，以现有语言可以调用的方式存在。

三、两种方案的相同点

尽管两种路径在部署方式上差异很大，但它们仍然共享一些目标与约束：

1. 都需要解决工具调用与模型交互问题。无论智能体运行在独立服务还是嵌入旧系统，都需要调用模型、执行工具、解析输出并进入下一步决策。
2. 都需要处理人工审批与检查点。银行、证券、制造、能源等行业的系统往往需要人在环路中审批，智能体必须支持暂停、恢复、记录状态。
3. 都需要审计事件。谁在什么时候通过智能体执行了什么操作，必须能被追踪。
4. 都不能绕过权限与治理边界。无论智能体部署在哪里，都不应该获得超越现有系统边界的权限。
5. 都面临多语言交互问题。方案A需要跨进程调用旧系统，方案B需要在旧语言内部实现部分能力，二者都需要应付语言生态差异。

这些相同点说明，问题的核心不只是“能不能调用模型”，而是能不能在既有治理框架中安全地调用模型与工具。

四、核心差异分析

1. 集成边界差异

方案A的集成边界在旧系统外部。它通过接口调用、文件交换、消息订阅等机制与旧系统通信。乍看上去很整洁，因为旧系统不需要大改。但代价是：智能体所需的策略、授权、检查点、事件关联与人工审批流程也必须跨进程重建。一次模型调用触发一个审批，审批状态如何传回独立智能体服务，这本身就是新的集成问题。

方案B的集成边界在旧系统内部。它让现有运行时直接发起受控的智能体循环，审批、检查点、审计事件可以复用旧系统已有的状态机制。虽然改造成本更高，但治理连续性更好。

维度	方案A：独立智能体服务	方案B：智能体下沉到现有运行时
部署位置	旧系统外部，独立进程	旧系统内部，靠近数据与交易
接口方式	API、消息、文件、轮询	进程内调用、批处理步骤内嵌
权限治理	需跨进程重建	可复用现有权限与变更流
审批与检查点	需自行实现或映射	可接入现有作业流
审计关联	易断裂，需跨系统关联	更易保持同一上下文
改造成本	对旧系统改动小	对旧系统改动较大
运行耦合度	较低	较高

2. 治理与审计差异

治理是大型组织最难绕开的问题。方案A中，智能体作为一个新加入的独立进程，本质上是一个新的“系统参与者”。它需要新的身份、新的授权入口、新的审计通道。即使旧系统原有的权限模型很成熟，智能体也可能无法直接复用。

方案B中，智能体不是新的系统参与者，而是现有作业链中的一个步骤。如果批处理程序已经具备作业级权限、步骤级检查点与审计日志，那么智能体步骤可以继承这些机制，而不必另起一套。

例如，一个异常交易在批处理中被识别后，方案B可以在同一作业中进入智能体决策步骤，调用模型给出建议，再进入人工审批步骤，最后写回检查点。整条链路的上下文天然连续。

3. 故障恢复与状态管理差异

独立智能体服务需要考虑进程崩溃后如何恢复。它需要保存所有未完成任务的检查点，包括哪些工具已经执行、哪些审批正在等待、哪些审计事件已经发出。如果旧系统本身没有面向智能体的状态接口，那么这些状态只能保存在智能体服务内部，造成状态分散。

下沉式路径则可以借助现有作业调度器的恢复能力。批处理作业本身就有重启、续跑与回滚机制，智能体步骤如果内嵌其中，就能与作业级恢复策略保持一致。

4. 技术与生态差异

方案A的最大优势是语言生态成熟。Python 等语言在模型调用、工具注册、向量检索、流式输出等方面具备丰富组件，接入主流模型也相对方便。方案B则受限于旧语言生态。COBOL、Fortran、Lua 等语言不一定具备成熟的智能体编排库，也可能缺乏异步模型调用所需的网络能力。

但这并不意味着方案B不可行。它通常采取“最小必要能力”策略：旧语言只承担决策循环中最关键的一小段，模型调用仍可通过外部网关或内部服务完成。旧语言只需能发起调用、解析结果、执行动作、记录审计即可。

五、典型场景选择

1. 适合方案A的场景

• 智能体任务与旧系统交互深度较浅，比如读取记录、发送通知、生成报告；
• 旧系统不能轻易变更，但可以提供安全可靠的只读接口；
• 组织希望对智能体实验保持较大隔离度，避免影响生产链路；
• 团队以现代语言开发为主，运维能支持新增服务。

2. 适合方案B的场景

• 智能体决策必须紧贴核心交易链路，例如异常处理、审批流转、风险判断；
• 旧系统已具备成熟作业调度、检查点、人工审批与审计机制；
• 组织要求智能体行为必须与旧系统使用同一套治理逻辑；
• 数据敏感性高，不适合跨进程传递过多上下文。

3. 混合场景

在实践中，很多组织最终会选择混合路径。例如，用现代语言构建智能体控制面，但在关键执行点由旧语言系统发起调用并写入本地检查点。两条路径不是非此即彼，关键在于明确哪些环节必须留在旧系统内，哪些环节可以外置。

六、选型判断条件

在做选择时，建议从以下条件判断：

1. 治理要求是否强于集成便利。如果系统监管严格，优先考虑下沉式路径。
2. 旧系统改造窗口是否开放。如果变更控制严格，独立服务可能是短期现实。
3. 状态管理复杂度。如果智能体任务涉及多步骤、长时间等待、人工审批，状态管得越靠近旧系统越有利。
4. 团队对旧语言的处理能力。下沉式方案需要开发人员理解旧运行时特性，否则改造风险很高。
5. 是否需要快速试错。独立服务更容易快速搭建，适合小范围验证模型与提示策略。

七、迁移与使用注意事项

不管决定偏向哪条路径，以下注意事项都值得提前评估：

1. 权限边界要先于功能实现。先明确智能体可以访问哪些数据、执行哪些写操作，再考虑调用模型。
2. 上下文传递策略要显式设计。向模型发送数据前，哪些字段可以外发、哪些必须脱敏，需要在架构中明确。
3. 人工审批不能滞后补录。审批不是事后补一个日志，而是流程中的硬步骤。
4. 跨语言维护成本往往被低估。方案A虽然不动旧代码，但跨进程调试、错误追踪与性能分析都更困难。
5. 旧语言改动需要更严格的回归保障。下沉式接入可能触碰旧系统的敏感路径，需要更谨慎地设计测试，包括模拟模型响应与异常情况。
6. 模型输出应有结构化约束。旧系统不适合解析过于自由的输出，模型返回最好通过固定结构、受控枚举或模板化 JSON 来约束。
7. 模型调用网关可统一管理。即使是下沉式方案，也可以把模型调用抽象为内部网关，在各语言中只保留轻量客户端。

八、总结

智能体进入大型组织最难的部分，不在于选择哪个模型，也不在于如何流式输出，而在于它要在哪个位置接入系统，以及在接入后如何继续遵守既有的治理约束。

“新建一个智能体服务”和“把智能体下沉到现有语言运行时”，本质上是两种对风险和治理的不同回答。前者以隔离和快速迭代换取了治理重建成本；后者以更高的系统内改造换取了更连贯的审计与状态管理。

真正成熟的方案不会一刀切。让关键决策留在关键系统内部，让模型交互保持受控，让人工审批与审计贯穿全链路，才是多语言智能体框架最需要解决的工程问题。